What % of traffic is network overhead on top of HTTP/S requests

Question

If we:
1) Count bytes/bits at the network adapter level (raw # of bits through the NIC) and,
2) Count bytes in all HTTP/S request/responses.

Assuming only HTTP/S traffic is on the box, and assuming a statistically relevant amount of "typical" web traffic:

I want to know about how much more traffic will be counted at the NIC level than at the HTTP/S level (counting http headers and all) because of the extra network overhead.

Answer 1

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:

• for HTTP over TCP/IPv4

overhead = TCP + IP = 40 bytes

payload = 1500 - 40 = 1460 bytes

overhead % = 2.7% (40 * 100 / 1460)

• for HTTP over TCP/IPv6

overhead = TCP + IP = 60 bytes

payload = 1500 - 60 = 1440 bytes

overhead % = 4.2% (60 * 100 / 1440)

Here are the assumptions:

• Amazon counts the NIC payload without the Ethernet headers, not the whole NIC packet
• your HTTP responses are fully utilizing the TCP/IP packet - your typical page size + HTTP headers results in one or more full TCP/IP packets and one with more than 50% used payload
• you set explicit expiration date on cached content to minimize 302 response
• you avoid redirects or your URLs are long enough to fill the payload