web-dev-qa-db-ja.com

トラフィックの何％がHTTP / Sリクエストのネットワークオーバーヘッドです

もし私達：
1）ネットワークアダプターレベルでバイト/ビットをカウントします（NICを介した生のビット数）。
2）すべてのHTTP/S要求/応答のバイト数をカウントします。

HTTP/Sトラフィックのみがボックスにあり、統計的に関連する量の「典型的な」Webトラフィックがあると仮定します。

余分なネットワークオーバーヘッドのために、HTTP/Sレベル（httpヘッダーとすべてをカウント）よりもNICレベルで多くのトラフィックがカウントされることを知りたいです。

networkingbandwidthweb-trafficnetwork-traffic
30
David Parks

HTTPの下のレイヤーに関する知識はありません。 HTTP要求がTCP/IPを介して配信されるとは考えられません。たとえそうであっても、ネットワーク層によって追加されるオーバーヘッドについての知識はありません。または、ルートの信頼性とパケットのドロップ/再送によるオーバーヘッドはどうなりますか。

Update：コメントに基づいて、ナプキンの裏にある推定値をいくつか示します：

最大セグメントサイズ （TCPまたはIPヘッダーを含まない）は、通常、レイヤー間で [〜＃〜 ] mtu [〜＃〜] マイナスヘッダーサイズイーサネットMTUの場合、通常1500バイトで構成されます。 TCPヘッダー は160ビット、つまり20バイトです。-の固定部分 IPv4ヘッダー は160ビット、つまり20バイトです IPv6ヘッダー の固定部分は320ビット、または40バイトです。

  • hTTP over TCP/IPv4の場合

オーバーヘッド= TCP + IP = 40バイト

ペイロード= 1500-40 = 1460バイト

オーバーヘッド％= 2％（40 * 100/1460）

  • hTTP over TCP/IPv6の場合

オーバーヘッド= TCP + IP = 60バイト

ペイロード= 1500-60 = 1440バイト

オーバーヘッド％= 4％（60 * 100/1440）

前提条件は次のとおりです。

  • Amazonは、NICパケットではなく、EthernetヘッダーのないNICペイロードをカウントします
  • hTTP応答がTCP/IPパケットを完全に利用している-通常のページサイズ+ HTTPヘッダーにより、1つ以上の完全なTCP/IPパケットと、50％を超えるペイロードが使用されます
  • キャッシュされたコンテンツに明示的な有効期限を設定して、302応答を最小化する
  • リダイレクトを回避するか、URLがペイロードを埋めるのに十分な長さである
21
Franci Penov

100Mbit/sイーサネットでは、94.1Mbit/sで大きなファイルが転送されます。

これは6％のオーバーヘッドです。反対方向に流れるTCP ACKもカウントすると、9％に近くなります。ギガビットイーサネットの場合、オーバーヘッド（パーセント）は同じままです。仮定：TCP/IPv4およびファイルサイズ> 100kB（このサイズでは、初期HTTPとTCP setup。）を無視できます。）

ダウンロード速度を比較するときは、ビットからバイトまでの係数8に注意してください。イーサネットのプリアンブルやフレーム間ギャップについては誰も請求しませんが、「ペイロード」を文字どおりに受け取るべきではありません。

計算：ペイロード/全体
ペイロード= 1500-20-32（Ethernet_MTU-IPv4-TCP）
overall = 8 + 14 + 1500 + 4 + 12（プリアンブル+ Ethernet_header + Ethernet_MTU + CRC + Interframe_gap）

最近のイーサネットは常に全二重であるため、時折TCP ACKが逆方向に流れることで転送レートが変更されることはありません。2つのデータフレームごとに1つのACKをオーバーヘッドに追加すると（ Wiresharkで確認したように、総オーバーヘッドは8.5％になります。また、MTUサイズは通常1500バイトですが、一部のネットワークでは小さくなり、パス内のすべての機器が設定されている場合はさらに大きくなります。

10
maxy

余分なネットワークオーバーヘッドは何ですか？ [〜＃〜] tls [〜＃〜] 鍵交換のHTTP量のオーバーヘッド。あなたが気づくのは、主に処理のオーバーヘッドです。

http://en.wikipedia.org/wiki/HTTP_Secure#Difference_from_HTTP

ライン（サーバーの後）のwanアクセラレータまたはプロキシは、トラフィックがキャッシュ可能または圧縮可能でないため、トラフィックを区別しません。

1
reconbot