Protocols

A protocol is a set of rules for how data is structured, sent, received and checked. Two devices can only understand each other if they follow the same rules, the way two people need a shared language. Protocols decide the format of a message, the timing, the order, and what to do when something goes wrong.

Some protocols are stateful (they remember the conversation so far, as TCP does for a connection) and some stateless (every message stands alone, as with HTTP). This section covers the two that carry data between applications (TCP and UDP, at the transport layer) and the ones applications themselves use (HTTP, HTTPS and DHCP).

An IP address gets data to the right computer. A port number gets it to the right program on that computer, like a flat number inside a building. A server can run a web server and a mail server at once, and port numbers tell the operating system which is which. Common ones: HTTP 80, HTTPS 443, SSH 22, SMTP (email sending) 25 or 587, DNS 53.

TCP (Transmission Control Protocol) is connection-oriented. First comes a three-way handshake: the client sends SYN (“want to talk?”), the server answers SYN-ACK (“yes, ready”), the client sends ACK (“then here we go”). After that every segment carries a sequence number so the receiver can reorder them, and a checksum to spot damage. The receiver acknowledges what arrived, and the sender re-sends anything not acknowledged. TCP also controls the flow so it does not swamp a slow receiver, and closes the connection politely at the end (each side sends a FIN and gets an ACK). The result is a reliable, ordered stream, at the cost of extra messages and delay.

UDP (User Datagram Protocol) is connectionless. It just sends each datagram and moves on: no handshake, no acknowledgement, no re-sending, and a tiny header. Packets can be lost or arrive out of order, and UDP does not care. That sounds worse, but for a live video call a re-sent packet would arrive too late to be any use, so speed beats perfection. UDP can also send to many receivers at once (multicast).

HTTP (Hypertext Transfer Protocol) carries the web. It works by request and response: a client such as a browser sends a request (a method like GET to fetch or POST to send data, a header with details such as the file wanted, sometimes a body), and the server replies with a status code, headers and usually the content. A request is plain readable text, such as GET /index.html HTTP/1.1 followed by Host: www.example.com, and the reply starts HTTP/1.1 200 OK. Common codes: 200 OK, 301 moved permanently, 403 forbidden, 404 not found, 500 server error.

HTTP is stateless: the server treats every request as brand new, so it cannot tell that two requests came from the same person. Websites add memory on top: a cookie is a small piece of data the server asks your browser to store and send back with each request, and a server-side session uses it to recognise you. That is how a shop remembers your basket.

HTTPS is HTTP carried inside encryption (TLS, the successor to SSL), on port 443. It gives three things: encryption (nobody on the path can read it), authentication (a digital certificate proves the server is who it says), and integrity (tampering is detected). It defeats eavesdropping and man-in-the-middle attacks (A2.4.4 shows how).

Every device on a network needs an IP address. DHCP (Dynamic Host Configuration Protocol) hands them out automatically, so nobody has to type them in. Four messages, remembered as DORA:

1. Discover: the new device broadcasts “is there a DHCP server? I need an address.”
2. Offer: a server replies with an address from its pool.
3. Request: the device says “yes, I will take that one.”
4. Acknowledge: the server confirms, and the device may now use it.

The address is leased for a set time, then renewed or given to someone else. DHCP also supplies the subnet mask, the default gateway (the router to use for other networks) and the DNS server address. A server can also be told to always give the same address to a particular MAC address, which suits printers and servers.