Header

In short: The block of control data at the beginning of a data packet, containing metadata — e.g. sender, recipient, protocol type, checksum.

In more detail: When sending, every network layer adds its own header (encapsulation): an HTTP request sits in a TCP segment with its own header, which in turn sits in an IP packet with its own header. The recipient reads the headers layer by layer from the outside in.

In Depth

Encapsulation as a nesting-doll principle

Encapsulation through headers is best understood as a Russian nesting doll: when sending, each layer of the OSI model adds its own header IN FRONT OF the payload of the layer above, without changing or interpreting its content — to the Ethernet layer, a TCP header and the HTTP payload inside are simply opaque bytes:

Ethernet header | IP header | TCP header | HTTP header | actual web page data

Each layer only “knows” its own header type and passes everything else on unchanged as pure payload. This is why network protocols can be combined so flexibly: TCP doesn’t care whether it carries HTTP, FTP or a completely proprietary application protocol — it simply transports bytes.

Decapsulation on receipt

On receipt, the process runs exactly the other way round: every device along the way reads only the header relevant to its own layer, removes it (decapsulation) and passes the rest on to the next higher layer. A switch works at layer 2 and therefore only reads the Ethernet header (to know which port to forward to), a router works at layer 3 and additionally reads the IP header, and only the actual target server reads through the complete chain down to the HTTP header and the actual payload. Intermediate stations along the way (routers, switches) are basically only interested in as many header layers as they need for their own forwarding decision — everything beyond that stays untouched payload for them.

Typical header fields

Despite different protocols, the same basic building blocks appear in almost every header: addressing (source/destination IP address or MAC address, depending on the layer), protocol type (a field revealing which protocol follows next in the payload — so the recipient knows how to interpret the wrapped data further), length (how many bytes of payload follow, important for recognising where a packet ends) and often a checksum for error detection, which allows damaged transmissions to be recognised.

Overhead from nested headers

The overhead from these many nested headers is one reason why the actually usable bandwidth of a connection is always somewhat below the pure line capacity — every header takes up space that isn’t available for payload. With very small amounts of payload (e.g. individual sensor readings in IoT applications), the header overhead can even be larger than the actual payload, which is why there are dedicated, particularly lean protocols for such scenarios.

See also: UDP header, Footer, Packet, OSI model