アカウント名:
パスワード:
応答確認とか有るから帯域フルに使って転送とか出来ないと思うんだけど？
TCP等にはスライディングウィンドウってのが有ってだね･･･ざっくり言ってしまえば、ウィンドウサイズ以下なら応答確認を待たずに送信してもいいって仕様があるんですよ。TCPで1パケット1KBとすればウィンドウのデータサイズは512Mbitで、1000Mbpsを使い切るためにはデータを送ってから512/1000=0.512秒以内にACKが帰ってさえ来れば十分使いきれる計算になります。複数のTCP接続を束ねればもっと遅延しても使いきれます。
各ローカル側のスループットが十分なのに通信路を使いきれないとすれば、TCPなどよりも上層のプロトコルでスライディングウィンドウに対応しない応答確認を行っていたりセッションが細切れだったりして、さらにそれらを並列化していなかったりすることが原因です。多少なりとも効率を考慮したプロトコルであれば、小さなセッションは連結したりスライディングウィンドウやキューを活用した上で必要に応じてセッションを並列化しています。# HTTPとかは応答確認をTCPに投げた上でkeep-aliveで連結したり並列化したりが標準だし
LAN内部での運用などを前提としていて通信路の遅延を考慮していないプロトコルの場合は遅延がモロにスループットに跳ね返ってきますが、遅延の有るネットワークでそういうプロトコルを使うほうが間違っているのでそこは無視しても良いと思います。# CIFSとかね･･･改善可能だとか最新版だと改善しているとかは聞くけど、古い機器で何も考えずに使うと涙目
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
プロトコル的に無理では？ (スコア:0)
応答確認とか有るから帯域フルに使って転送とか出来ないと思うんだけど？
Re:プロトコル的に無理では？ (スコア:0)
TCP等にはスライディングウィンドウってのが有ってだね･･･
ざっくり言ってしまえば、ウィンドウサイズ以下なら応答確認を待たずに送信してもいいって仕様があるんですよ。
TCPで1パケット1KBとすればウィンドウのデータサイズは512Mbitで、1000Mbpsを使い切るためにはデータを送ってから512/1000=0.512秒以内にACKが帰ってさえ来れば十分使いきれる計算になります。
複数のTCP接続を束ねればもっと遅延しても使いきれます。
各ローカル側のスループットが十分なのに通信路を使いきれないとすれば、TCPなどよりも上層のプロトコルでスライディングウィンドウに対応しない応答確認を行っていたりセッションが細切れだったりして、さらにそれらを並列化していなかったりすることが原因です。
多少なりとも効率を考慮したプロトコルであれば、小さなセッションは連結したりスライディングウィンドウやキューを活用した上で必要に応じてセッションを並列化しています。
# HTTPとかは応答確認をTCPに投げた上でkeep-aliveで連結したり並列化したりが標準だし
LAN内部での運用などを前提としていて通信路の遅延を考慮していないプロトコルの場合は遅延がモロにスループットに跳ね返ってきますが、遅延の有るネットワークでそういうプロトコルを使うほうが間違っているのでそこは無視しても良いと思います。
# CIFSとかね･･･改善可能だとか最新版だと改善しているとかは聞くけど、古い機器で何も考えずに使うと涙目