Getting a Real Feel for the OSI Model — Dissecting a Single HTTP Request Into Its Seven Layers

The OSI model is the thing every networking primer starts with, yet we constantly hear the same complaint: “I can rattle off the names of the seven layers, but honestly, I don’t have a real feel for it.” People memorize physical layer, data link layer, network layer, and so on, but never quite manage to connect that seven-tier diagram to the C# code they’re writing or to the network failure happening right in front of them.

On this blog, we’ve previously covered behavior at L4 (the transport layer) — the misconception that you can Receive in the same units you Send over TCP and diagnosing why TCP retransmission stalls industrial camera communication — but we’d never written an article that pulled together the underlying idea of “layers” itself.

This article’s approach is simple. We build one actual Ethernet frame carrying a single HTTP GET request, and dissect it from the outside in. The seven layers aren’t just something in a conceptual diagram — they exist physically, nested inside 171 bytes flowing across the network. Once you see that with your own eyes, through a hex dump and through Wireshark, the OSI model stops being something you memorize.

The code that appears in this article is published on GitHub as a complete, buildable, runnable sample set (a library for assembling and dissecting frames, exporting a pcap file that opens in Wireshark, and unit tests).

osi-model-packet-anatomy - komurasoft-blog-samples (GitHub)

1. The Bottom Line First

• The OSI model is a “vocabulary,” not an “implementation.” What actually runs on the real internet is the TCP/IP protocol suite (effectively four layers); OSI’s own 7-layer protocols lost the adoption race and never saw real use. What survived is the model as a shared language — phrases like “let’s isolate this at L2” or “this is an L7 problem.”¹²
• The seven layers are physically nested as a byte sequence. In a frame carrying an HTTP GET, the first 14 bytes are the Ethernet header (L2), the next 20 bytes are the IPv4 header (L3), the next 20 bytes are the TCP header (L4), and the rest is the HTTP text (L7). You can confirm directly, in this article’s hex dump and in Wireshark, how each layer’s header begins right after the previous layer’s.
• The only thing your C# code writes directly is the L7 byte sequence. What you hand to Socket.Send is application data alone; the OS’s protocol stack attaches the TCP and IP headers, and the NIC attaches the Ethernet header and the electrical signal. That’s exactly why choosing between HttpClient, SslStream, and Socket is a choice about “which layer and below you delegate to the OS.”³
• L5 (the session layer) and L6 (the presentation layer) don’t exist as independent layers in the real stack. TLS and character encoding shoulder part of that role, but under the TCP/IP model they’re all lumped together as the application layer. If “I don’t get what L6 is supposed to be” describes you, it’s not your fault — that’s exactly where the model and reality diverge.²
• Where the OSI model genuinely earns its keep in practice is troubleshooting and conversation. Narrowing things down with layer vocabulary — “ping gets through but HTTP fails, so L3 is alive and we should suspect L4 or above” — becomes a shared language that works across network engineers, infrastructure teams, and application developers.

2. Why the OSI Model Ends Up Being Just Rote Memorization

Most explanations start with a table like this one.

This table is correct, but every single row is written in such abstract language that reading it never resolves into a mental picture. Tell someone “it transforms the representation format of data,” and nobody will be able to point to which line of their own code that’s supposed to refer to.

There’s another historical fact worth stating plainly here. The OSI model is a standard defined by ISO (the International Organization for Standardization) and the ITU-T (ISO/IEC 7498-1, ITU-T X.200), and it was originally meant to be paired with a matching, ambitious set of OSI protocols for each of the seven layers.¹ But in the adoption race of the 1990s, TCP/IP — which already had working implementations — became the de facto standard, and the OSI protocols themselves ended up barely used at all. RFC 1122, which laid the foundation for the internet, explains the world using effectively four layers — the link layer, the internet layer (IP), the transport layer, and the application layer — with no independent layers corresponding to L5 or L6.²

In other words, the reason we still study the OSI model today isn’t “because this is how things are actually implemented” — it’s to get our hands on the tool of thinking in layers, and on the shared vocabulary for troubleshooting. Once you accept that premise, you no longer need to agonize over “I can’t find the real thing that corresponds to L5 and L6,” and everything suddenly gets a lot clearer.

3. The Main Event: Dissecting a Single HTTP Request

Enough preamble — let’s look at the real thing. The following hex dump is an Ethernet frame (171 bytes total) carrying a single HTTP request, GET /index.html HTTP/1.1. It was assembled by the sample code introduced at the top of this article, and because both the IPv4 header checksum and the TCP checksum are computed correctly, Wireshark displays it as a perfectly normal packet when you load it.

0000  02 00 00 00 00 01 02 00  00 00 00 02 08 00 45 00  ..............E.
0010  00 9d 12 34 40 00 40 06  3b 99 c0 00 02 0a c6 33  ...4@.@.;......3
0020  64 50 cb 84 00 50 00 00  03 e8 00 00 07 d0 50 18  dP...P........P.
0030  ff ff a3 05 00 00 47 45  54 20 2f 69 6e 64 65 78  ......GET /index
0040  2e 68 74 6d 6c 20 48 54  54 50 2f 31 2e 31 0d 0a  .html HTTP/1.1..
0050  48 6f 73 74 3a 20 65 78  61 6d 70 6c 65 2e 63 6f  Host: example.co
0060  6d 0d 0a 55 73 65 72 2d  41 67 65 6e 74 3a 20 4b  m..User-Agent: K
0070  6f 6d 75 72 61 53 6f 66  74 44 65 6d 6f 2f 31 2e  omuraSoftDemo/1.
0080  30 0d 0a 41 63 63 65 70  74 3a 20 74 65 78 74 2f  0..Accept: text/
0090  68 74 6d 6c 0d 0a 43 6f  6e 6e 65 63 74 69 6f 6e  html..Connection
00a0  3a 20 63 6c 6f 73 65 0d  0a 0d 0a                 : close....

Looking at the ASCII column on the right, you can see human-readable text — GET /index.html HTTP/1.1 — starting partway through, at offset 0x36. So what are the 54 bytes before that? Feed it to this sample’s dissector, and here’s what it reports.

[ L2 Ethernet II | offset   0 |  14 bytes | dst=02:00:00:00:00:01 src=02:00:00:00:00:02 type=0x0800 (IPv4)
  [ L3 IPv4        | offset  14 |  20 bytes | 192.0.2.10 -> 198.51.100.80 TTL=64 proto=6 (TCP) checksum=OK
    [ L4 TCP         | offset  34 |  20 bytes | 52100 -> 80 [Psh, Ack] seq=1000 win=65535
      [ L7 HTTP        | offset  54 | 117 bytes | GET /index.html HTTP/1.1

This is the single diagram I most want you to take away from this article. There are three points to it.

1. Each layer starts right where the previous layer ends. The Ethernet header is bytes 0-13, the IPv4 header is bytes 14-33, the TCP header is bytes 34-53, and HTTP starts at byte 54. A layer isn’t a conceptual category — you can point to it as a byte range from the start of the frame.
2. An inner layer is nothing more than the outer layer’s “payload” (cargo). From Ethernet’s point of view, everything after it — IPv4 onward — is just cargo; it has no idea whether the contents happen to be TCP. From IP’s point of view, TCP onward is the cargo; from TCP’s point of view, HTTP is the cargo. Each layer reads only its own header and passes the payload upward untouched. This “not caring” structure is exactly what encapsulation is.
3. L1 (the physical layer) and L5/L6 don’t appear anywhere in this diagram. L1’s job is converting this byte sequence into an electrical signal, light, or radio waves, so it never shows up in a dump; and as covered in the previous chapter, L5 and L6 have no independent entity in plain HTTP/1.1. “Of the seven layers, only four show up in the dump” — that’s the reality.

Let me stress again: there’s nothing special about HTTP here. Whether it’s a database connection, gRPC, or GigE Vision for an industrial camera, every single packet has this exact same nested structure as long as it’s TCP/IP over Ethernet. All that changes is what’s inside the L7 cargo.

4. L2, the Data Link Layer — Delivering to “the Next Node”

Let’s walk through the dissection results from the outside in. The first 14 bytes are the Ethernet II header.

02 00 00 00 00 01   Destination MAC address (6 bytes)
02 00 00 00 00 02   Source MAC address (6 bytes)
08 00               EtherType = 0x0800 (payload is IPv4)

L2’s job is to deliver to the next node within the same network segment. It uses a MAC address to specify the destination. A MAC address is an identifier assigned to a NIC, and in principle it never reaches the other party across a router. A frame sent from an office PC to a web server has, as its destination MAC, not the web server but the default gateway (the router).

This is where a lot of people find themselves wondering, at least once, “if we already have IP addresses, why do we even need MAC addresses?” The answer lies in how the layers divide responsibility. An IP address is an address that points to the “final destination,” while a MAC address is a label pointing to “whoever carries the next single leg.” To use a courier-delivery analogy, the IP address is the delivery address on the shipping label, and the MAC address is the name of “the next relay center.” The shipping label (L3) never changes until the very end, but the label (L2) gets replaced leg by leg. ARP is what looks up a neighboring node’s MAC address from an IP address, and you can check the table your PC remembers with the arp -a command.

In terms of hardware, the device that reads and forwards based on L2 is the switch (switching hub). A switch picks its output port purely by looking at the destination MAC address; it never looks at the IP address riding inside as cargo.

5. L3, the Network Layer — Delivering to the Ends of the Earth

The next 20 bytes are the IPv4 header. Here are the main fields.

45          Version = 4, header length = 5 words (20 bytes)
00 9d       Total length: 157 bytes (IP header + TCP + HTTP; does not include Ethernet's 14 bytes)
40 06       TTL = 64, protocol = 6 (payload is TCP)
3b 99       Header checksum
c0 00 02 0a Source IP    192.0.2.10
c6 33 64 50 Destination IP  198.51.100.80

L3’s job is to deliver to the final destination host, no matter how many routers it takes to get there. While L2 only carries something one segment (one hop) at a time, L3’s destination IP address stays the same from the very start of the communication to the very end. A router looks at a packet’s destination IP, decides “which router do I hand this to next,” and sends it out after rewriting the L2 header.

TTL (Time To Live) is the field that lets you actually see this “crossing routers” motion happening. It decrements by one every time it crosses a router, and once it hits zero, the packet is discarded and an error is returned to the sender. tracert (Windows’s route-tracing command) works by deliberately sending packets with TTL set to 1, 2, 3, and so on, flushing out the routers along the path one at a time. In other words, every single line you see in tracert’s output is the real, physical embodiment of “an L3 hop.”

6. L4, the Transport Layer — Deciding Which Process Gets It

The next 20 bytes are the TCP header.

cb 84       Source port 52100
00 50       Destination port 80
00 00 03 e8 Sequence number
00 00 07 d0 Acknowledgment number
50 18       Header length = 5 words, flags [PSH, ACK]
ff ff       Window size
a3 05       Checksum

By the time L3 is done, the packet has arrived at the destination “host (machine).” But on that machine, a web server, a database, and any number of other processes could all be communicating at the same time. One of L4’s jobs is to use the port number to decide which process (which socket) receives the data. Destination port 80 is, by convention, “the number an HTTP server listens on”; the OS looks at that number and stacks the data into the corresponding process’s receive buffer.

TCP’s other big job is providing a reliable byte stream through sequence numbers, acknowledgments, retransmission, and flow control.⁴ That behavior, and how to work with it, each run deep enough to be their own article, so I’ll point you to the piece on TCP message boundaries and the piece on TCP retransmission for those. What I want you to take away here is this feeling: “above L4, things no longer look like a network at all — they start to look like a pipe connecting one process directly to another.”

Here’s one fun fact that shows a gap between the model’s ideal and reality. TCP’s checksum isn’t defined as being computed over the TCP segment alone — it’s defined as being computed with a “pseudo header” listing L3 information (the source and destination IP addresses) prepended to the front.⁴ If the layers were cleanly independent, there’s no way L3’s addresses should bleed into L4’s calculation. It’s a good example of how the OSI model is only ever a map for organizing your thinking, while real protocols cross layer boundaries whenever it’s convenient.

7. L5 and L6 — Where the Model and Reality Diverge

Now, notice that our dissection diagram had no L5 (the session layer) or L6 (the presentation layer). This is the single biggest reason people feel like they “don’t get OSI,” so let’s say it plainly.

L5 and L6 don’t exist as independent layers in the real TCP/IP stack. Under RFC 1122’s internet model, everything above TCP is just “the application layer.”² The roles the OSI model envisioned have, in reality, been scattered and absorbed as follows.

For HTTPS, for example, TLS is sandwiched on top of TCP (L4), and HTTP flows inside it. “Which layer is TLS, exactly?” is the kind of question that begs to be turned into an exam question, but there’s no practical value in pinning down a single correct answer. What matters more than being able to instantly say “it’s L6” is being able to explain that it sits above L4, below L7, and combines both session management (an L5-ish role) and encryption (an L6-ish role).

In .NET code, this relationship shows up directly in how the classes wrap one another. Wrap the L4 stream you get from TcpClient.GetStream() with SslStream, and whatever plaintext you Write gets encrypted into TLS records before it ever reaches TCP.⁵

using var client = new TcpClient("example.com", 443);
// Wrap the L4 byte stream with TLS (roughly L5/L6)
using var ssl = new SslStream(client.GetStream());
await ssl.AuthenticateAsClientAsync("example.com");
// What you write here is L7 (HTTP) plaintext. Encryption is SslStream's job
await ssl.WriteAsync(Encoding.ASCII.GetBytes("GET / HTTP/1.1\r\n..."));

This shape — a stream wrapping a stream — is encapsulation’s code-level equivalent. If you watch traffic on port 443 in Wireshark, the TCP payload only ever shows up as an opaque blob labeled Application Data, which lets you confirm, from the opposite direction, that “L7 has been wrapped in something equivalent to L6.”

8. Which Layer Is Your C# Code Actually Touching?

Let’s map everything so far onto the tools a Windows app developer actually reaches for.

Two things stand out from this table.

First, choosing an API is choosing “which layer and below you delegate.” Use HttpClient and you can delegate all the way up through assembling L7; use Socket and you end up writing all of L7 yourself. Conversely, an ordinary Windows app almost never touches L3 or below directly (raw sockets come with administrator-privilege requirements and heavy restrictions).

Second, all that Socket.Send is ever handed is the L7 byte sequence — nothing more. The sample’s Part 2 is a demo that actually sends an HTTP request over loopback, and the only thing the application prepares is 60 bytes of HTTP text; the 54 bytes’ worth of headers we saw in Chapter 3 are attached by the OS and the NIC. Your app’s networking code is really only doing the job of building the innermost cargo out of seven layers — that’s the precise relationship between the OSI model and your code.

using var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
await socket.ConnectAsync(IPAddress.Loopback, port);

byte[] request = Encoding.ASCII.GetBytes(
    $"GET / HTTP/1.1\r\nHost: localhost:{port}\r\nConnection: close\r\n\r\n");

// All we hand over is the L7 byte sequence. The TCP/IP/Ethernet headers
// get attached on the far side of this call (by the OS and the NIC)
int sent = await socket.SendAsync(request);

9. Hands-On: Assembling a Frame and Opening It in Wireshark

To turn “I read it and understood it” into “I saw it and understood it,” let’s walk through how to run the sample code.

At the center of the sample is SampleFrameBuilder, which assembles Chapter 3’s frame in exactly the order it gets wrapped from L7 down to L2. What happens at each layer when sending maps directly onto the order in which the methods appear.

public static byte[] BuildHttpGetFrame()
{
    // L7: the only thing the application hands to Send is this byte sequence
    byte[] http = Encoding.ASCII.GetBytes(HttpRequest);

    // L4: the OS's protocol stack prepends the TCP header
    byte[] tcp = WrapInTcp(http);

    // L3: prepend the IPv4 header on top of that
    byte[] ip = WrapInIpv4(tcp);

    // L2: the NIC driver prepends the Ethernet header just before the wire
    return WrapInEthernet(ip);
}

Running the demo shows you the hex dump and the nested view, and also writes this frame out as a pcap file.

dotnet run --project samples/Demo

Try opening the generated sample-http-get.pcap in Wireshark.⁶ The center pane will show four stacked lines — Ethernet II / Internet Protocol Version 4 / Transmission Control Protocol / Hypertext Transfer Protocol — and clicking any one of them highlights just the corresponding byte range in the hex dump below. An industry-standard tool is showing you exactly the same thing as Chapter 3’s nested view. Once you’ve confirmed that much, move on to real traffic: start a capture in Wireshark, set the filter to something like tcp.port == 443, open some website in your browser, and you can confirm that every bit of real communication is built from this same nesting.

There’s also a practical lesson baked into the implementation of the dissector side (PacketDissector). For example, when carving out IPv4’s payload, you need to trust the header’s TotalLength field rather than just taking the rest of the receive buffer, because Ethernet has a minimum frame length (60 bytes) and short packets get meaningless padding tacked onto the end. “Stripping out an outer layer’s concern (padding) using an inner layer’s own length information” — this is another example of how a layer’s division of responsibility shows up in the implementation, and it’s verified with a unit test.

10. Using the OSI Model in Practice — Narrowing Things Down With Layer Vocabulary

Earlier I said “OSI survived as vocabulary.” Let’s look at two places where that vocabulary actually earns its keep.

Troubleshooting. A report of “can’t connect to the server” can be systematically narrowed down once you translate it into layer vocabulary. The standard approach is checking from the bottom up.

For example, if “ping gets through but Test-NetConnection fails,” then everything up through L3 is healthy, and suspicion narrows to something blocking the L4 port — a stopped service, a firewall, a misconfigured port number. If “the TCP connection succeeds but HTTP returns a 400,” the problem isn’t the network at all — it’s L7 (the content of the request). Instead of blindly unplugging and replugging cables, pin down, one layer at a time, how far up things are actually alive — that’s how the OSI model gets used in practice.

A shared language for conversation. A conversation like “this sounds like an L2 problem, could you check the switch port” or “that’s an L7 issue, so it’s on the app team” gets across accurately between network staff, infrastructure staff, and application developers. The layer number is an industry-wide shared coordinate for concisely stating a point of responsibility.

11. Correcting Common Misconceptions

Finally, let’s round up and correct the misconceptions people commonly run into around the OSI model.

• “The internet runs on OSI’s seven layers.” — It doesn’t. What’s actually implemented is TCP/IP (effectively four layers); OSI is a reference model for explanation and conversation.²
• “TCP/IP’s four layers map cleanly onto OSI’s seven.” — The mapping for L5 through L7 is inherently fuzzy. You’ll often see a table claiming “TCP/IP’s application layer = OSI’s L5 + L6 + L7,” but as covered in Chapter 7, L5 and L6’s roles are, in reality, scattered across TLS and serialization formats.
• “TLS is a layer-6 (or layer-5) protocol.” — There’s no value in pinning it to a single layer. The accurate description is that it sits above L4, below L7, and combines roles equivalent to both L5 and L6.
• “You can tell the protocol just by looking at the port number.” — Port 80 doesn’t guarantee HTTP. A port number is a convention; you can’t actually know what’s flowing until you look at the payload. That’s exactly why the sample’s dissector identifies HTTP by looking at the leading characters of the content, not the port number.
• “Switches are L2 devices, routers are L3 devices.” — That’s correct as a starting point, but in reality, devices that straddle multiple layers are perfectly ordinary — L3 switches, load balancers that route at L4, WAFs that inspect L7. It’s more accurate to think in terms of “how far up does this device actually read.”

12. Summary

• The OSI model isn’t an implementation — it’s vocabulary for thinking in layers. What actually runs is TCP/IP (effectively four layers)
• The seven layers aren’t a conceptual diagram — they’re physically nested inside the byte sequence of a single frame (L2: 0-13, L3: 14-33, L4: 34-53, L7: 54 onward)
• Each layer reads only its own header and doesn’t care about the cargo (the inner layers) — that’s encapsulation
• L5 and L6 don’t exist independently in the real stack; TLS and encoding have absorbed their roles
• The only thing your C# code writes is the L7 byte sequence. The OS attaches TCP/IP headers, and the NIC attaches Ethernet
• The practical payoff is troubleshooting by confirming survival one layer at a time from the bottom up, plus a shared language across teams
• Assemble a frame with the sample code and open it in Wireshark, and you can confirm everything in this article with your own eyes

Related Articles

• The Misconception That You Can Receive in the Same Units You Send Over TCP — Designing Receive Logic Around a Byte Stream
• Diagnosing Why TCP Retransmission Stalls Industrial Camera Communication
• A Practical C# async/await Decision Table — Task.Run and ConfigureAwait

Related Consulting Areas

Komura Software LLC handles the design and implementation of Windows applications that communicate over TCP/IP, root-cause investigation of communication issues with industrial equipment (“it occasionally drops” or “it slows down”), and support for troubleshooting using packet captures.

• Windows App Development
• Bug Investigation & Root Cause Analysis
• Technical Consulting & Design Review
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Is the OSI model's 7-layer structure actually used on the real internet?

No, it isn't. What actually runs on the real internet is the TCP/IP protocol suite (effectively four layers); OSI's own 7-layer protocols lost the adoption race in the 1990s and ended up barely used at all. RFC 1122, which laid the foundation for the internet, explains the world in terms of four layers: the link layer, the IP layer, the transport layer, and the application layer. What survived is the model as a shared vocabulary for troubleshooting and conversation — phrases like 'let's isolate this at L2' or 'this is an L7 problem.'

Where do the session layer (L5) and presentation layer (L6) actually exist?

They don't exist as independent layers in the real TCP/IP stack. The roles the OSI model envisioned are scattered and absorbed elsewhere in reality: L5 (establishing and managing a dialogue) corresponds to TLS's handshake or HTTP's cookies and tokens, and L6 (transforming and encrypting data representation) corresponds to TLS encryption, character encoding, and serialization formats like JSON. There's no practical value in pinning down which single layer TLS belongs to — what matters more is being able to explain that it sits above L4 and below L7, combining roles equivalent to L5 and L6.

If there's an IP address, why do we also need a MAC address?

Because the layers divide responsibility differently. The IP address (L3) is the address pointing to the final destination, and it doesn't change from the start of the communication to the end. The MAC address (L2) is the label pointing to whoever carries the next single hop, and it gets replaced every time it crosses a router. A frame sent from an office PC to a web server has, as its destination MAC, not the web server but the default gateway (the router). ARP is what looks up a neighboring node's MAC address from an IP address, and you can check the correspondence table with the arp -a command.

What practical use does the OSI model have?

Troubleshooting and cross-team conversation. A report of 'can't connect to the server' can be systematically narrowed down by checking survival layer by layer from the bottom up: visually checking the link light (L1-L2), pinging the gateway (L3), confirming a TCP connection to the destination port (L4), and sending an HTTP request (L7). For example, if ping succeeds but the TCP connection fails, suspicion narrows to something blocking the L4 port, such as a stopped service or a firewall. It also functions as an industry-wide shared coordinate system for concisely stating a point of responsibility, as in 'this sounds like an L2 problem, could you take a look at the switch.'

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.