Networking HTTP/S请求之上的网络开销占流量的百分比是多少

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

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

---

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

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

---

一直以来（在服务器之后），wan加速器或代理将区别对待您的流量，因为它不可缓存或压缩。

您对HTTP下面的层一无所知。您甚至不能假设HTTP请求将通过TCP/IP传递。即使是这样，您也不知道网络层增加的开销。或者路由的可靠性如何，以及由于丢弃/重新发送数据包而产生的开销如何

更新：根据您的评论，这里是一些餐巾纸背面的估算：

的大小（不包括TCP或IP头）通常在层之间协商到减去头大小的大小。对于以太网，MTU通常配置为1500字节。数据长度为160位或20字节。数据的固定部分是160位，也就是20字节。数据的固定部分为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）

以下是假设：

• Amazon统计没有以太网报头的NIC有效负载，而不是整个NIC数据包
• 您的HTTP响应完全利用TCP/IP数据包-您典型的页面大小+HTTP头会导致一个或多个完整的TCP/IP数据包和一个使用了50%以上负载的数据包
• 您在缓存内容上设置了明确的过期日期，以最小化302响应
• 您避免重定向，或者您的URL足够长，足以填充负载

---

对于100Mbit/s以太网，大文件传输速度为94.1Mbit/s

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

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

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

---

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

我的意思是询问TCP/IP开销，而不是HTTPS与HTTP。假设HTTP和HTTPS流量的典型数量，在NIC级别监控中计算的典型TCP/IP开销与服务器计算的HTTP字节数量相比是多少。我的问题是因为我在amazon的EC2云上运行服务器。他们在NIC上计算字节数，我在服务器上的HTTP级别上得到一个字节日志。我想做一个客座估算，以确定他们比我在日志上看到的要多多少。考虑到所有的变量，我只想在一些估计中插入一个合理的数字。假设一个高流量的典型流量，这应该是可能的。这正是我想要的，你列出的假设提供了一些很好的思考。真的很感激！我有同样的问题，除了我在两个linux系统之间通过蓝牙进行文件传输（服务器端是python http服务器，客户端是wget，物理接口是蓝牙）。还有蓝牙头文件。有什么粗略的想法吗？20字节是TCP头的最小大小；实际上，由于诸如NOP和时间戳之类的TCP选项，TCP头的长度通常约为32字节。还有相当多的其他开销，建立和中断TCP连接的握手和TCP段的确认。仅用于TCP/IP开销的位/字节（因此，不包括HTTP/S的额外开销，也不将开销计算为%），我发现这个答案很有用。