networking - HTTP/S 请求之上的网络开销占流量的百分比

Question

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

假设盒子上只有 HTTP/S 流量，并假设“典型”网络流量的统计相关数量：

由于额外的网络开销，我想知道在 NIC 级别计算的流量将比在 HTTP/S 级别（计算 http 标头和所有）多多少。

Answer 1

您对 HTTP 之下的层的了解为零。您甚至不能假设 HTTP 请求将通过 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 足够长以填充有效负载

Answer 2

使用 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 (Preamble + Ethernet_header + Ethernet_MTU + CRC + Interframe_gap)

因为现在以太网总是全双工的，偶尔的 TCP ACK 以另一种方式流动并不会改变传输速率。如果你为每两个数据帧添加一个 ACK​​ 到开销中（这就是我在 Wireshark 中观察到的），你会得到 8.5% 的总开销。虽然 MTU 大小通常为 1500 字节，但在某些网络中它可以更小，或者如果路径中的每个设备都为其配置了它，则它可以更大。

Answer 3

什么额外的网络开销？HTTP 之上的TLS开销相当于密钥交换。您注意到的主要是处理开销。

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

下线（在服务器之后）wan 加速器或代理将处理您的流量，因为它不可缓存或不可压缩。