HTTP/S请求中网络开销占总流量的百分比是多少？

Question

HTTP/S请求中网络开销占总流量的百分比是多少？

networkingbandwidthweb-trafficnetwork-traffic

36

如果我们： 1）在网络适配器层面计算字节/位（通过NIC传输的原始位数）并且， 2）计算所有HTTP/S请求/响应中的字节。

假设仅在该盒子上存在HTTP/S流量，并且假设有足够多“典型”的Web流量：我想知道因为额外的网络开销，将在NIC级别计算比在HTTP/S级别（包括HTTP头和所有内容）计算的流量要多多少。

- David Parks

仅针对TCP/IP开销的位/字节（不包括HTTP/S的额外开销，也不按百分比计算开销），我发现https://dev59.com/E1_Va4cB1Zd3GeqPS2Ra#8902667的回答非常有帮助。 - Destiny Architect

3个回答

15

以100Mbit/s以太网为例，大型文件传输速率为94.1Mbit/s。

这相当于6%的开销。如果还要计算TCP ACK在相反方向上流动的情况，则接近9%。对于千兆以太网，开销（百分比）保持不变。假设：TCP / IPv4和文件大小> 100kB。（在此大小下，我们可以忽略初始HTTP和TCP设置。）

在比较下载速率时，应注意从位到字节的系数为8。我想没人会因以太网前导码或帧间隔而向你收费，但“有效载荷”不应被字面理解。

计算：有效载荷/总体
有效负载= 1500-20-32（Ethernet_MTU-IPv4-TCP）
整体 = 8 + 14 + 1500 + 4 + 12（前导码+以太网头+Ethernet_MTU+CRC+帧间隔）

由于现在以太网始终是全双工的，偶尔的TCP ACK流向其他方向并不会改变传输速率。如果将每两个数据帧添加一个ACK到开销中（这是我在Wireshark中观察到的），则总开销为8.5％。尽管MTU大小通常为1500字节，但在某些网络中可能会更小，或者如果路径中的每个设备都配置为较大的MTU，则可以更大。

- maxy

1

什么额外的网络开销？TLS在HTTP之上的开销只涉及密钥交换。你主要会注意到它带来的是处理开销。

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

在服务器之后，沿着线路，WAN加速器或代理将以不同的方式处理您的流量，因为它不能被缓存或压缩。

- reconbot

1

我想询问的是 TCP/IP 的开销，而不是 HTTPS 和 HTTP 之间的比较。假设有一定数量的 HTTP 和 HTTPS 流量，请问在 NIC 级别监控时计算出的典型 TCP/IP 开销与服务器计算出的 HTTP 字节数相比，哪个更 typica。 - David Parks

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Franci Penov · Accepted Answer

您对HTTP下面的层没有任何了解。您甚至不能假设HTTP请求将通过TCP/IP传递。即使是通过TCP/IP传递，您也无法了解网络层添加的开销。或者路由的可靠性以及由于丢失/重发数据包而产生的开销。

更新: 基于您的评论，以下是一些草稿估计:

最大分段大小（不包括TCP或IP标头）通常在协议层之间进行协商，等于MTU的大小减去标头的大小。对于以太网MTU通常配置为1500字节。TCP标头为160位，即20字节。IPv4标头的固定部分也是160位，即20字节。 IPv6标头的固定部分为320位，即40字节。因此：

对于在TCP/IPv4上的HTTP

开销 = TCP + IP = 40字节

有效载荷 = 1500 - 40 = 1460字节

开销% = 2.7% (40 * 100 / 1460)

对于在TCP/IPv6上的HTTP

开销 = TCP + IP = 60字节

有效载荷 = 1500 - 60 = 1440字节

开销% = 4.2% (60 * 100 / 1440)

这里是一些假设：

亚马逊计算 NIC 负载时不包括以太网头部，而不是整个 NIC 数据包。
您的 HTTP 响应完全利用 TCP/IP 数据包 - 您的典型页面大小 + HTTP 标头会产生一个或多个完整的 TCP/IP 数据包和一个使用了 50% 以上有效负载的数据包。
您设置缓存内容的显式过期日期，以最小化 302 响应。
避免重定向或使 URL 足够长以填满有效负载。