There’s a lot of things that I’ve still got no idea about in this vast technical world – and one of those things is how things work under the hood. When faced with the question “What actually happens when you type www.google.com in your browser?” I found myself staring blank faced at the person who posed the question, which prompted a conversation about networking and how data gets transmitted from one place to another. I’ve attempted to summarise some of the concepts discussed in that conversation in this post.
We started by looking at the OSI (Open Systems Interconnection) model, which breaks down networking (the way computers communicate with one another) into several layers
This helps to understand networking concepts by categorising them into different layers, but also allows for some standardisation on how we communicate across networks, so that different components are able to talk to one another. However, it is criticised because in practice, protocols don’t just fit into one of these layers; rather they often encompass two or three together.
Using the model for understanding
Layer 1 – The Physical Layer
Let’s consider the simpler case of being on a LAN (Local Area Network) and being connected to different computers on that local network through some sort of physical connection.
Layer 2 – The Data Link Layer
Each computer is considered to be a node on that network, and each node has its own unique identifiers. In the case of computers, this is the MAC (Media Access Control) Address and IP (Internet Protocol) Address. The computer then sends out a data packet with the sender’s and receiver’s MAC address contained within it – often in the form of an ethernet frame:
All ethernet frames are structured the same, so that the receiving end knows how to interpret what it’s been given. The first interesting thing to note is that we use the term octets (8 bits) rather than bytes – because not all machines use 8 bits to represent a byte, and networking doesn’t discriminate on this basis!
- Preamble – Think of this like tuning a musical instrument. The preamble is always the same, and allows the receiving machine to recognise how to read the bits and bytes of the rest of the message.
- MAC Address – As mentioned, the MAC address is the identifier of the destination/source machines involved in the data transfer
- Ethertype – Tells you the size and type of data you’re expecting (so the machine knows what and how to read the data its getting
- Data – The diagram shows an IP Datagram which is used in TCP (explained below), but this data can be in a different form
- CRC (Cyclic Redundancy Check) – This is a fast, but quite weak, check that the data has been received correctly.
Layer 3 – The Network Layer
One computer on the network will want to communicate with another. It first finds the IP Address of the computer it is trying to communicate with through DNS (Domain Name System – at a high level this is a mapping between domain names and IP addresses). It then looks for the MAC Address associated with the IP Address of the destination computer in its private ARP (Address Resolution Protocol) cache. If it cannot find the destination computer in its cache, it sends out a broadcast ARP request across the network, and the computer with the relevant IP Address will send a response to allow the sending device to store its MAC address in its cache (and subsequently use it in its data packet)
Layer 4 – The Transport Layer
Layers 2 and 3 are concerned with addressing, i.e. where we want the data to end up. Layer 4 is all about how to actually get the data there. There are two main different protocols that can be used for this layer – TCP and UDP.
The most common Transport Layer Protocol is TCP – Transmission Control Protocol. This is a stateful connection where both parties communicating acknowledge they’re part of the conversation, which will continue until one side removes itself. Whenever we send data we need to reference the conversation that we’re in at the time. When connected to a port there are several different conversations happening all at the same time.
A server socket binds to a port, and then listens for connections. The client initiates a connection by sending a SYN (synchronise) packet. The server accepts the SYN packet and responds with a SYN/ACK. The connection is now open and we can now send data back and forth. Whenever one side sends data, the other side acknowledges that data for every packet that it receives. If no ACK is received, the server sends the data again so as to ensure reliable data transport. To close the connection, the client sends a FIN packet, and the server acknowledges this with a FIN/ACK. The server can also terminate the connection, by sending a rst (reset) packet
Another transport layer protocol is UDP – User Datagram Protocol. This protocol is much more minimalist – whereas the TCP requires a connection and an acknowledgement for each packet sent, UDP is stateless, it simply sends the message and essentially hopes for the best! It therefore cannot guarantee the order the messages will be received in (or indeed whether they were received in the first place!).
Packets have a limited size – which could be a problem if we want to send a larger amount of data across the network. This is possible with TCP, as we can chunk the data up into multiple packets and send them across individually, knowing that they will all be received and in the order we sent them. With UDP, we can’t guarantee that because there is no system of acknowledging messages received.