インフラ・運用見積もり
遠いサーバーへの転送は、帯域だけでは決まらない？
使うツール
近くのサーバーには速く送れるのに、遠い相手だと速度が伸びない。回線の契約速度だけでは、この違いを説明できないことがあります。帯域遅延積は、回線の速度と往復時間を掛けて、応答が戻るまでにどれくらいのデータが流れるかを考える目安です。SheepDevは速度や遅延を測定しないため、ここでは仮の条件を入力し、数値がどの条件で増えるかを確かめます。
100Mbps、RTT 40msを入れてみる
100,000,000 bit/s × 0.040 s = 4,000,000 bit
4,000,000 ÷ 8 = 500,000 byte
500 kB = 488.28125 KiB帯域遅延積で帯域100、単位Mbps、RTTを40msにします。結果は500000 byteです。40msは0.040秒へ換算し、bitをbyteへ変えるため8で割っています。40を秒として扱えば1000倍、bitをbyteのつもりで読めば8倍のずれが起こります。数字の大きさだけで判断せず、入力と結果に表示された単位を一緒に確認します。
この500kBは、ダウンロードするファイルの大きさではありません。指定した速度で一往復分の時間に流れる量です。ファイルが1GiBなら、その全体が一度に確認待ちになるという意味でもありません。総転送量と、ある時点で流れている量を分けると、転送時間の計算との役割の違いが分かります。
RTTは片道の時間ではない
RTTは送ってから応答が戻るまでの往復時間です。手元の測定値がすでにRTTなら、さらに二倍にしません。一方、片道遅延しか分からない場合は、上りと下りが同じと勝手に決めず、往復値として何を入力するかを明確にします。このツールは相手へ通信しないので、入力された40msが実際の経路の値かどうかは確認しません。
RTTが時間帯で変わる場合は、単一の値だけでなく、例えば20ms、40ms、100msを試します。平均値と一時的な最大値を混ぜず、どの条件を見積もったかを書き添えます。計算結果の変化を見る目的は、距離だけが原因だと断定することではなく、遅延の変動が必要なデータ量の目安をどう変えるかを理解することです。
速い回線ほど、同じ遅延でも大きな量になる
100 Mbps × 40 ms → 0.5 MB
1 Gbps × 40 ms → 5 MB
1 Gbps × 100 ms → 12.5 MB帯域だけを十倍にすると結果も十倍です。さらにRTTを40から100へすると2.5倍になります。高速化したのに確認待ちで十分な量を送り続けられない場合、回線の最大値を使い切れないことがあります。帯域遅延積は、その状況を考えるための量であり、速度テストの点数や実際に使えるバッファ容量の測定値ではありません。
入力する帯域にも意味があります。契約上1Gbps、実際の経路で共有される帯域、アプリが観測した転送速度は、同じ値ではありません。どれを使うかで問いが変わります。まず仮の上限で量を見積もり、実測に合わせた条件でも計算する、と分けておくと、理論値を実測値として報告せずに済みます。
結果をそのままOSの設定値へ貼らない
TCPの受信ウィンドウなどを考える際の参考にはなりますが、結果のbyte数を一つのOS設定へ入れれば必ず改善するわけではありません。輻輳制御、受信側の状況、接続数、メモリー制限、アプリの読み書きも関係します。自動調整のある環境で一律の固定値へ変えると、別の条件で不都合を作る可能性があります。設定変更は、この計算の作業とは分けて扱います。
この画面はOS設定を変更せず、ネットワークへ測定用の通信もしません。調査メモには帯域、RTT、結果、両方の数値をどこから得たかを残します。『バッファ不足が原因』と結論を急がず、実際の観測で確認する候補として整理すると、計算結果の役割を誤解しにくくなります。
ファイルの所要時間は、別の計算で見積もる
1GiBのファイルを100Mbps、通信効率80%で送る計算なら、データ転送時間で107.3741824秒です。帯域遅延積の500kBをファイルサイズから一回だけ引いたり、そのまま転送秒数として使ったりはしません。所要時間のモデルは総量と実効速度、帯域遅延積のモデルは速度と往復時間を扱っています。二つを混ぜず、何を知りたいかに応じて使い分けます。