HTTP/S 请求之上的网络开销占流量的百分比是多少
如果我们：
1) 在网络适配器级别计算字节/位（通过 NIC 的原始位数），
2) 计算所有 HTTP/S 请求/响应中的字节数。
假设机器上只有 HTTP/S 流量，并假设统计上相关的“典型”Web 流量：
我想知道 NIC 级别的流量比 HTTP/S 级别的流量多多少（计算 http标头和所有）因为额外的网络开销。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你对 HTTP 以下各层的了解为零。您甚至不能假设 HTTP 请求将通过 TCP/IP 传送。即使是这样，您对网络层增加的开销也知之甚少。或者路由的可靠性如何，以及由于丢弃/重新发送数据包而导致的开销是什么。
更新：根据您的评论，以下是一些餐巾背面的估计：
最大分段大小（不包括 TCP 或 IP 标头）通常在各层之间协商为 MTU 减去标头大小。对于以太网，MTU 通常配置为 1500 字节。 TCP 标头 为 160 位，即 20 个字节。 IPv4 标头 的固定部分是 160 位，即 20 字节。 IPv6 标头的固定部分是 320 位，即 40 字节。因此：
开销 = TCP + IP = 40 字节
有效负载 = 1500 - 40 = 1460 字节
开销 % = 2.7% (40 * 100 / 1460)
开销 = TCP + IP = 60 字节
负载 = 1500 - 60 = 1440 字节
开销 % = 4.2% (60 * 100 / 1440)
以下是假设：
You have zero knowledge about the layers below HTTP. You can't even assume the HTTP request will be delivered over TCP/IP. Even if it is, you have zero knowledge about the overhead added by the network layer. Or what the reliability of the route will be and what overhead will be due to dropped/resent packets.
Update: Based on your comment, here are some back-of-the-napkin estimates:
The maximum segment size (which does not include the TCP or IP headers) is typically negotiated between the layers to the size of the MTU minus the headers size. For Ethernet MTU is usually configured at 1500 bytes. The TCP header is 160 bits, or 20 bytes. The fixed part of the IPv4 header is 160 bits, or 20 bytes as well. The fixed part of the IPv6 header is 320 bits, or 40 bytes. Thus:
overhead = TCP + IP = 40 bytes
payload = 1500 - 40 = 1460 bytes
overhead % = 2.7% (40 * 100 / 1460)
overhead = TCP + IP = 60 bytes
payload = 1500 - 60 = 1440 bytes
overhead % = 4.2% (60 * 100 / 1440)
Here are the assumptions:
使用 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（前导码 + 以太网标头 + 以太网_MTU + CRC + 帧间间隙）
由于以太网现在始终是全双工的，因此偶尔流向其他方向的 TCP ACK 不会改变传输速率。如果您为每两个数据帧添加一个 ACK 到开销中（这就是我在 Wireshark 中观察到的），您将获得 8.5% 的总开销。虽然 MTU 大小通常为 1500 字节，但在某些网络中它可能更小，或者如果路径中的每台设备都配置了它，则它会更大。
With 100Mbit/s Ethernet, a large file transfers at 94.1Mbit/s.
That's 6% overhead. If you also count the TCP ACKs flowing in the opposite direction, it's closer to 9%. For gigabit Ethernet the overhead (in percent) remains the same. Assumptions: TCP/IPv4 and file size >100kB. (At this size we can neglect the initial HTTP and TCP setup.)
When comparing download rates, beware the factor 8 from bits to bytes. I guess nobody will charge you for Ethernet preamble or interframe gap, but "payload" shouldn't be taken literally.
Calculation: payload / overall
payload = 1500 - 20 - 32 (Ethernet_MTU - IPv4 - TCP)
overall = 8 + 14 + 1500 + 4 + 12 (Preamble + Ethernet_header + Ethernet_MTU + CRC + Interframe_gap)
Because Ethernet is always full-duplex these days, the occasional TCP ACK flowing the other way does not change the transfer rate. If you add one ACK for every two data frames to the overhead (that's what I observed in Wireshark), you get 8.5% total overhead. And while the MTU size is usually 1500 bytes, it can be smaller in some networks, or much larger if every piece of equipment in the path is configured for it.
有哪些额外的网络开销？ HTTP 之上的 TLS 开销相当于密钥交换。您注意到的主要是处理开销。
http://en.wikipedia.org/wiki/HTTP_Secure#Difference_from_HTTP （在服务器之后）WAN 加速器或代理将以不同的方式处理您的流量，因为它不可缓存或可压缩。
What extra network overhead? the TLS overhead on top of the HTTP amounts to the key exchange. It's mostly processing overhead that you notice.
http://en.wikipedia.org/wiki/HTTP_Secure#Difference_from_HTTP
Down the line (after the server) wan accelerator or proxies will treat your traffic differen't as it isn't cacheable or compressible.