Network layers and protocols

Deciding everything at once would be unworkable, so a network is split into layers. A lower layer does not care what the layer above is carrying. That is what lets the same HTTP run over Wi-Fi or over a cable.

• Application layer … what is being exchanged (HTTP, DNS, SMTP)
• Transport layer … which door at the other end, and whether it really got there (TCP, UDP)
• Internet layer … which machine to deliver to (IP)
• Network interface layer … how to push it onto the actual wire or radio (Ethernet, Wi-Fi)

The exam also uses the OSI reference model, which splits the same thing into seven. From the bottom: physical, data link, network, transport, session, presentation, application.

What decides which machine gets the delivery is the IP address, written as four numbers like 192.168.0.10 (IPv4).

That address splits into two parts: the front is the address of the network, the back is the house number. What decides where to cut is the subnet mask, written like 255.255.255.0. Writing /24 means the same thing — it declares that the first 24 bits are the network part.

The important bit: the one with all zeros after the cut and the one with all ones cannot be given to a machine. The first names the network itself, and the second is reserved for reaching everyone on that network at once.

The IP address gets you to the building. But one machine may be running a web server and a mail server at the same time. What says which door you have business with is the port number.

The common ones are fixed: HTTP is 80, HTTPS is 443. Numbers like these are called well-known ports.

Worth holding on to: on the way out and on the way back, source and destination simply swap. Your browser grabs any free number it likes (say 50001) and talks from there to port 80. The server answers the other way round, from 80 back to 50001. It does not invent a fresh number for the reply.

The transport layer has two options with very different temperaments.

TCP checks that things arrived as it goes. Anything missing gets sent again, anything out of order gets put back in order. That makes it reliable, and it costs time. The web, mail and file transfer all sit on TCP.

UDP just throws. It never checks, so things can go missing, but nothing is ever kept waiting. It is what you use for voice calls and live video, where a small gap matters far less than a stall.

When a question says "real-time matters more than reliability", it is talking about UDP.

People remember fulfledge.example.com, but what a delivery needs is an IP address. DNS is the thing that answers with the address for a name.

It works like a phone book. Before your browser goes to fetch the page, it first asks DNS "what is the address for this name?"

A few names with similar-sounding jobs get muddled, so learn them side by side.

• DNS … name to IP address, and back
• DHCP … lends a free IP address to a machine that has just connected
• NAT … rewrites a private address from inside an office into an outward-facing one

The agreement between your browser and a server is HTTP. "Give me this", "here you are" — written out as text and sent back and forth.

HTTPS is the same thing with the traffic encrypted. What matters here is that it does one more thing besides encrypting: a server certificate lets you check that the other end really is that server.

That is what only HTTPS gives you. Session handling with cookies, logging in with an ID and password, browser caching — HTTP can do all of those. This is an easy one to get tangled up in.

Email uses one protocol to send and a different one to collect. Sending is SMTP; collecting is POP or IMAP.

The body of a message has a header on the front, holding things like From, To, Date and Subject. Email originally could carry nothing but text, so the agreement that extended the header so it could carry pictures and sound is MIME. Attachments work because of it.

One header is special: Bcc. It is an address the other recipients are not meant to see, so it gets deleted along the way. If it stayed visible, Bcc would be pointless.

The boxes that join networks together are named after how far up they look before passing something on. This is the layer idea being asked about directly.

• Repeater … amplifies a fading signal so it reaches further, nothing more (physical layer)
• Bridge … forwards frames by looking at the MAC address (data link layer)
• Router … looks at the IP address and decides which way to send it (network layer)
• Gateway … joins networks that differ above the transport layer and converts between protocols

A bridge does not look at IP, and a router does not forward on MAC. Swapping those two is the classic wrong answer.

When nothing is getting through, there are tools for finding out how far it does get.

• ping … asks the other end "are you there?" and waits for a reply. The standard way to check reachability
• arp … finds the MAC address of something on the same LAN (assuming you know its IP address)
• ipconfig … shows your own address settings
• netstat … lists the connections you currently have open

One more piece of web vocabulary to have ready: CGI. It is the arrangement that lets a web server run an outside program and hand the result back to the browser. Building a fresh page for every request is possible because of it.