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

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.

Answer 2

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% (40 * 100 / 1460)

• for HTTP over TCP/IPv6

overhead = TCP + IP = 60 bytes payload = 1500 - 40 = 1420 bytes overhead % = 4% (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 :-)