skip to content

Over IPv4, what share of a packet is header when TCP carries a 20-byte message versus a full 1,500-byte packet?

level: middleimportance: should knowfreq 26%

answer

  1. headers are per packet, not per byte
  2. minimum IPv4 and TCP headers
  3. MTU minus forty
  4. small payloads are mostly header

basics

~20 s

With minimum 20-byte IPv4 and 20-byte TCP headers, a 20-byte message becomes a 60-byte packet that is two-thirds header. A full packet on a 1,500-byte MTU carries 1,460 bytes of data, so the same 40 bytes are under 3%.

solid answer

~40 s

Headers cost a fixed amount **per packet**, so their share depends on payload size. The minimum IPv4 header is 20 bytes and the minimum TCP header is 20, so 20 bytes of data become a 60-byte IP packet: 40/60, about 67% header, before the link layer adds its own per-frame header and trailer. On a 1,500-byte MTU the largest TCP payload is 1,500 − 40 = 1,460 bytes, so the same 40 bytes are about 2.7%. Options make it worse: the timestamps option adds 10 bytes, padded to 12. IPv6's 40-byte minimum header pushes the small case to 80 bytes, 75% header. The lesson for chatty services is to batch many small messages into fewer, larger segments.

go deeper

for a junior

Recall the minimum sizes, 20 bytes for IPv4, 20 for TCP, 8 for UDP and 40 for IPv6, and that headers are paid once per packet.

for a middle

Do the arithmetic aloud: a 20-byte message in a 60-byte packet, 1,460 bytes of payload on a 1,500-byte MTU, and what options subtract.

for a senior

Turn the numbers into action for a chatty service: count packets per second as well as bytes, and weigh batching against the latency it adds.

for a principal

Frame overhead as a design input: message granularity, batching and protocol choice decide packet rates that drive network, CPU and cost budgets.

## Why overhead is a per-packet cost Encapsulation adds a header at every layer, and each header is paid **once per packet**, whatever the payload size. So the share of the wire spent on headers is: `overhead share = header bytes / (header bytes + payload bytes)` A large payload dilutes the headers; a small one is dominated by them. Interviewers ask this to see whether a candidate can turn "each layer adds a header" into numbers and a design consequence. ## The numbers you need These are **minimum** sizes, with no options: | Header | Minimum size | Source | |---|---|---| | IPv4 | 20 bytes | RFC 8200 §8.3 (minimum-length IPv4 header) | | IPv6 | 40 bytes (20 more than IPv4) | RFC 8200 §8.3 | | TCP | 20 bytes | RFC 8200 §8.3 (minimum-length TCP header) | | UDP | 8 bytes | RFC 768 (minimum UDP length is eight) | The **MTU** is the largest IP packet a link carries. RFC 1122 §2.3.3 gives 1,500 bytes for Ethernet and 1,492 for IEEE 802.3 framing. The link layer's own header and trailer sit **outside** the MTU; for Ethernet their sizes and minimum-frame rules come from IEEE 802.3 and belong with the frame format. ## Worked arithmetic: a 20-byte message 1. **TCP over IPv4:** 20 (IPv4) + 20 (TCP) + 20 (data) = **60-byte** IP packet. Header share 40/60 ≈ **67%**. 2. **TCP over IPv4 with timestamps:** the timestamps option is 10 bytes (RFC 7323), and because the TCP header length is counted in 32-bit words (RFC 9293), it normally occupies 12 bytes with padding. Packet = 72 bytes; header share 52/72 ≈ **72%**. 3. **UDP over IPv4:** 20 + 8 + 20 = **48 bytes**; header share 28/48 ≈ **58%**. 4. **TCP over IPv6:** 40 + 20 + 20 = **80 bytes**; header share 60/80 = **75%**. 5. **A pure TCP acknowledgment** carries no data: 40 bytes over IPv4, **100%** header. ## Worked arithmetic: a full-size packet On a 1,500-byte MTU: - **TCP over IPv4:** RFC 8200 §8.3 computes the MSS as the packet size minus 40 bytes, so the payload is **1,460** bytes and the header share is 40/1,500 ≈ **2.7%**. - **TCP over IPv6:** minus 60 bytes, payload **1,440**, header share 4%. - **With TCP options,** RFC 6691 says the sender must reduce the data length to account for options it includes; with 12 bytes of timestamps the IPv4 payload drops to **1,448**. ## Turning the numbers into judgment - **Packets per second matter as much as bytes.** A service sending a million 20-byte messages a second as separate segments puts about 60 MB/s of IP packets on the wire to deliver 20 MB/s of data, and every one of those packets also costs a link-layer frame, a forwarding decision per router and receive processing per host. - **Batching is the fix.** Packing fifty 20-byte messages into one 1,000-byte segment spends 40 header bytes on 1,000 data bytes, about 3.8%, instead of 67%. Application-level batching, keeping one long-lived connection and TCP's own small-segment coalescing (Nagle's algorithm, RFC 896) all attack the same cost, each trading a little latency. - **Acknowledgments are pure overhead.** A protocol that acknowledges every small message with its own packet can double the packet count. - **IPv6 costs 20 more bytes per packet.** Irrelevant for bulk transfer, noticeable for small-message workloads. ## Common mistakes - Treating overhead as a fixed percentage. It is a fixed **byte count per packet**; the percentage depends on payload size. - Reading a 1,500-byte MTU as 1,500 bytes of application data. The IP and TCP headers come out of the MTU. - Subtracting only the IP header to get the MSS (1,480). TCP's own header also counts. - Forgetting options: a 20-byte TCP header is the minimum, not the typical size of every segment. - Claiming IPv6 headers are smaller because the header checksum was removed. The fixed IPv6 header is twice the IPv4 minimum.

  • How do TCP options change the full-size payload on a 1,500-byte IPv4 path?
    RFC 6691 requires the sender to shrink the data to leave room for any IP or TCP options it includes. The timestamps option is 10 bytes, and the TCP header grows in 32-bit words, so it normally takes 12. The largest payload then drops from 1,460 to 1,448 bytes.
  • A service sends each 20-byte metric as its own TCP segment; what would you change, and what does it cost?
    Batch several metrics per write, so one 40-byte IPv4 and TCP header pair covers many messages: fifty per segment cuts header share from about 67% to about 4%. The cost is latency, since a metric waits for its batch, so bound the wait with a size or time limit.
  • Where does the link layer's cost fit into the overhead arithmetic?
    It adds a header and, on Ethernet, a trailer to every frame, outside the IP packet counted by the MTU. Like the IP and TCP headers it is paid per packet, so it makes small packets even less efficient; its exact size belongs to the link standard.

saying these in an interview costs you the question

  • Header overhead is the same percentage whatever the payload size.
  • A 1,500-byte Ethernet MTU carries 1,500 bytes of application data.
  • The TCP MSS on a 1,500-byte IPv4 path is 1,480 bytes.
  • IPv6 headers are smaller than IPv4 headers because the checksum was removed.
  • A pure TCP acknowledgment costs nothing on the wire.