Old-School Networking

In part 10 of the front-end series, the claim form learned to send a claim to the server with fetch and get a claim number back. From the page's side it is one line. Underneath that line, though, several jobs are running: looking up a name, finding the other machine, setting up a connection, and carrying the data in small pieces. In this series we look at them layer by layer.

• Get the big picture — the seven layers of the OSI reference model and the four TCP/IP layers that actually run. Which devices and protocols live on which layer
• Go down, then up — from the physical layer (cables, radio) in part 2 to HTTP in part 10
• Use it day to day — part 11 covers Docker and cloud networks, part 12 troubleshooting when things won't connect
• Measure every time — record real packets on a practice network and explain with those numbers

In a sentence, a network is a way of connecting computers and delivering data between them. Roughly drawn, the road from Arai's PC to the server looks like this.

The network inside a home or office is a LAN (local area network). At the edge of the LAN sits a router; beyond it is the provider's (ISP's) network, then other networks, and so on. That network of networks is the internet. The server, too, lives on a LAN in a data centre.

The devices along the way don't push the data through in one go. They split it into small parcels called packets and hand them from one device to the next. Rather than reserving a dedicated line to the other end like a phone call, it works like the post: each parcel carries its own address and takes whatever road is free. Many conversations can share one line, so nothing goes to waste.

So that sender and receiver read the data the same way, there are agreements on its format and the steps to follow. These are called protocols. HTTP, TCP, IP and Ethernet are all names of protocols.

There is a lot to do before anything arrives, so networking splits the work into layers. Think about posting a letter.

What goes in the letter is the writer's business. “To: Accounts” on the envelope decides who gets it inside the building. The street address decides which building. The van only reads the address and takes the letter to the next post office; it never reads the letter. The road has no idea what the van is carrying.

Networks work the same way, with a job for each layer. This brings three benefits.

• Swappable parts — switch from a cable to Wi-Fi and the way you write HTTP doesn't change. Replace a lower layer and the upper ones keep working
• Think about your own layer only — nobody worries about cable voltages while writing fetch
• Narrow down faults — if the name resolved but the connection fails, look below the naming layer (part 12)

The best-known “ruler” for splitting the layers is the OSI reference model. The International Organization for Standardization (ISO) started on it in 1977 and published it in 1984 as ISO 7498. It divides communication into seven layers.

When sending, data is handed from the upper layers down; when receiving, from the bottom up. Each layer has its own main devices and protocols. On one table it looks like this (each part goes into detail).

The name for the data changes with the layer too: a segment at layer 4, a packet at layer 3, a frame at layer 2 and bits at layer 1. In everyday talk people often call all of them packets, but when discussing layers it pays to keep them apart.

What actually runs the internet today, however, is not the OSI protocols but TCP/IP. Vint Cerf and Bob Kahn sketched it in a 1974 paper, and on 1 January 1983 the ARPANET of the day switched over to TCP/IP all at once. From the late 1980s into the early 1990s, opinion was split on whether OSI or TCP/IP would win (the “Protocol Wars”); TCP/IP is the one that spread.

The TCP/IP way of thinking was summed up in four layers in RFC 1122 (1989). Next to the OSI ruler it looks like this.

There are two big differences. First, the work of OSI layers 5 and 6 is folded into the application layer in TCP/IP: TLS encryption and character encoding are jobs for the app and its libraries. Second, OSI layers 1 and 2 are merged into a single link layer.

Even so, the OSI numbers are part of everyday vocabulary. “L2 switch”, “L3 switch”, “L4 load balancer” and “routing at L7” all use OSI layer numbers. In this series too we will talk TCP/IP but count in OSI.

With the map in hand, let's look at the real thing. On a Linux machine in the cloud I used network namespaces to build a small network of three machines (part 11 shows how).

The server is called api.keihi.example (.example is a name reserved for documentation). With tcpdump recording on both the PC side and the server side, I sent one claim. curl stands in for the browser, and the content is a small JSON rather than the full form from part 10.

# On Arai's PC (10.0.1.10), the same submission reproduced with curl
$ curl -X POST -H 'Content-Type: application/json' \
    --data-binary '{"title":"ニューヨーク出張","total":46851}' \
    http://api.keihi.example:3000/api/expenses
{"id":"EXP-2026-0012","status":"submitted"}
# A claim number came back (HTTP status 201 Created)

Claim number EXP-2026-0012 came back. During that time, 14 packets in all crossed Arai's PC.

# Everything recorded on Arai's PC for one submission (no., elapsed time, source, destination, protocol, bytes, info)
# 1. ARP: ask everyone for the router's (10.0.1.1) MAC address
 1   0.000ms  02:00:00:00:01:10 -> broadcast         ARP   42  Who has 10.0.1.1? Tell 10.0.1.10
 2   0.012ms  02:00:00:00:01:01 -> 02:00:00:00:01:10 ARP   42  10.0.1.1 is at 02:00:00:00:01:01
# 2. DNS: ask the router's DNS for the IP address of api.keihi.example
 3   0.014ms  10.0.1.10         -> 10.0.1.1          DNS   77  query A api.keihi.example
 4   0.350ms  10.0.1.1          -> 10.0.1.10         DNS   93  response A api.keihi.example A 10.0.2.20
# 3. TCP: connect to port 3000 on the server (three messages)
 5   0.680ms  10.0.1.10         -> 10.0.2.20         TCP   74  49914 -> 3000 [SYN] Seq=0
 6   0.808ms  10.0.2.20         -> 10.0.1.10         TCP   74  3000 -> 49914 [SYN, ACK] Seq=0 Ack=1
 7   0.818ms  10.0.1.10         -> 10.0.2.20         TCP   66  49914 -> 3000 [ACK] Seq=1 Ack=1
# 4. HTTP: send the claim, get a claim number back
 8   0.891ms  10.0.1.10         -> 10.0.2.20         HTTP 266  POST /api/expenses HTTP/1.1 + JSON
 9   0.898ms  10.0.2.20         -> 10.0.1.10         TCP   66  3000 -> 49914 [ACK] Seq=1 Ack=201
10   7.011ms  10.0.2.20         -> 10.0.1.10         HTTP 269  HTTP/1.1 201 Created + JSON
11   7.033ms  10.0.1.10         -> 10.0.2.20         TCP   66  49914 -> 3000 [ACK] Seq=201 Ack=204
# 5. TCP: close the connection
12   7.206ms  10.0.1.10         -> 10.0.2.20         TCP   66  49914 -> 3000 [FIN, ACK] Seq=201 Ack=204
13   8.472ms  10.0.2.20         -> 10.0.1.10         TCP   66  3000 -> 49914 [FIN, ACK] Seq=204 Ack=202
14   8.479ms  10.0.1.10         -> 10.0.2.20         TCP   66  49914 -> 3000 [ACK] Seq=202 Ack=205

Seven packets went back and forth before the claim (packet 8) was even sent. First the PC asked everyone for the router's MAC address (ARP), then looked up the server's IP address from its name (DNS), then opened a connection to the server (the three TCP messages), and only then came the POST itself. Once the claim number arrived, the connection was closed. Each of these is the star of a later part.

Packet 8, the claim itself, was 266 bytes. Select the layers one at a time in Wireshark and the bytes each one is responsible for turn blue.

From the start, the Ethernet, IP and TCP headers come one after another, followed by the HTTP text and the JSON body. Written out layer by layer, it looks like this.

# 1. Ethernet II (14 bytes)
#   destination MAC 02:00:00:00:01:01 (the router), source MAC,
#   type 08 00 (IPv4 inside)
02 00 00 00 01 01 02 00 00 00 01 10 08 00
# 2. IPv4 (20 bytes)
#   byte 9 (40) = TTL 64, byte 10 (06) = TCP inside,
#   0a 00 01 0a = from 10.0.1.10, 0a 00 02 14 = to 10.0.2.20
45 00 00 fc 1b f8 40 00 40 06
06 e7 0a 00 01 0a 0a 00 02 14
# 3. TCP (32 bytes)
#   c2 fa = source port 49914, 0b b8 = destination port 3000,
#   then sequence numbers, flags and so on
c2 fa 0b b8 83 5b 4e 23 ab f5 ef c6 80 18 00 3f
18 0c 00 00 01 01 08 0a b7 e2 b8 5b 9f a1 af c2
# 4. HTTP (150 bytes)
#   from here on it is text. Lines end in 0d 0a (\r\n); a blank line ends the headers
POST /api/expenses HTTP/1.1
Host: api.keihi.example:3000
User-Agent: curl/8.5.0
Accept: */*
Content-Type: application/json
Content-Length: 50

# 5. JSON (50 bytes)
#   the claim itself. The Japanese is UTF-8, three bytes per character
{"title":"ニューヨーク出張","total":46851}

On the sending side, each layer from the top down adds its own header in front and passes the result down. HTTP made 200 bytes; TCP added a 32-byte header for 232, IP added 20 for 252, and Ethernet added 14 for 266. This is encapsulation. The receiving side does the reverse: from the bottom up, each layer reads and strips its header and passes the rest up.

Every layer reads only its own header. IP doesn't read the TCP header, and TCP doesn't read the HTTP text. That is what makes the layers swappable.

The 266 bytes Wireshark shows don't include what gets added before and after on the cable itself (an 8-byte signal at the start and 4 bytes for checking damage at the end). We'll see those in parts 2 and 3.

I recorded the same claim packet in two places: before the router (on Arai's PC) and after it (at the server). Here they are side by side.

Both MAC addresses were swapped out. On the PC side it was “PC to router”; on the server side, “router to server”. That is because a MAC address is the address of the next device. The IP addresses, on the other hand, never change: they are the final destination. In postal terms, the letter changes vans at every post office but the address on the envelope is never rewritten.

The TTL is a number that drops by one at every router. A packet whose TTL reaches zero is thrown away, so a lost packet can't circle forever (traceroute in part 5 uses exactly this). Because the TTL changed, the IP header's check value (the checksum) was recalculated too.

Devices open the envelopes to different depths. A switch looks at layer 2, the MAC address, to choose which port to send the frame out of. A router looks up to layer 3, the IP address, to decide where to hand it next, then puts on a new layer 2 and sends it off. Only the two ends, the PC and the server, read TCP and HTTP (some devices, such as firewalls and load balancers, deliberately peek higher).

Throughout the series we will check things with tools like these. All of them work on an ordinary PC.

Wireshark is free and runs on Windows, Mac and Linux (the latest release at the time of writing is 4.6.9 from 23 September 2026; the screenshots here are Ubuntu's 4.2.2). Open this part's capture, select the layers one by one, and you should see what the photo in §7 shows.