TCP/IP for Noobs
Table of Contents
TCP/IP Explained #
Experimental computer networks have existed since the 50s, but the first one to resemble our modern system was the ARPANET, starting in 1971. What sets the ARPANET apart from previous systems its use of TCP/IP packet switching, which is the method that is still the foundation of today’s Internet. Unlike previous systems, TCP/IP can carry along when networking equipment between the two computers is broken or unreliable. Previous systems would refuse to work or at least drop connections. In fact, the ARPANET was funded by the US Department of Defense mainly because its resilient nature meant that communications could continue after a nuclear bomb strike. So yes, if it was not for the Cold War, you wouldn’t be able to search for funny cat pictures on the Internet like you can today.
Although there are many different physical ways of sending 1s and 0s across the Internet such as satellite or optical fiber cables, these messages must still follow a standard language so different computers can understand them. This is where TCP/IP comes in. TCP (Transmission Control Protocol) is simply a way to ensure reliability in a connection between two computers on a network. Before meaningful data is sent, such as a webpage, the two nodes acknowledge a connection by sending a predefined set of 1s and 0s to each other. After the connection is established, each one will expect the other to behave in a certain way. TLS and other encryption methods are defined after the TCP connection is established, and the TCP connection itself is not aware of them.
Where the nuke-preparedness comes in is with packet switching. As stated before, TCP is tolerant of flaky connections. When you send data with TCP, such as a webpage, the data is not all sent at once; it will be broken into thousands of little segments.
Each segment has extra data tagged onto it called a TCP header. The TCP header contains, among other things, a sequence number and a checksum. Therefore, if the webpage is split into 1000 segments, then all 1000 of them will have an individual sequence number and checksum. With an analogy to real mail, if the data you want to send is a letter, then the TCP header is an envelope. In this analogy, a sequence number would be a number written on the envelope, such that the 563rd letter sent would get number 563. A checksum would be a tamper-evident seal along the opening, so if it was messed with in shipping, this would be known. Checksums do this by adding up all the 1s and 0s of data and writing the sum in the TCP header. Then, when the segment arrives, the receiver will “check” the “sum” by adding the 1s and 0s itself and seeing if it matches the number in the TCP header. If it does not match, then the receiver knows the data is corrupted.
Anyway, since the data is broken up, all the segments must arrive safely to transfer data. This is important because with many digital data types, a couple missing bits will render the entire thing unreadable. Despite this, with TCP, the order or path they use to arrive doesn’t matter. Because of sequence numbers, if computer A receives the packets out of order, it can just rearrange them back to normal. If segment 563 never arrives at node A or if it is corrupted, then A will message B to resend the segment. This means that if the infrastructure between the two malfunctions, the TCP connection will be able to heal itself by resending segments on another route. Well, how do the segments pick a healthy route in the first place?
The answer is with IP (Internet Protocol). On a modern computer network, a TCP segment will be placed inside of an IP packet, which means adding an IP header on top of the whole thing. The IP header contains many fields, most notably the source and destination IP address. Every computer which connects to a network has its own IP address, which, in the letter analogy, is exactly like a street address. When sending an IP packet, the sender writes its own address as the source and the target computer as the destination, analogous to the “From” and “To” fields on an envelope (finding the target IP address is done through DNS, which is for another article).
To physically start the journey of a packet to its destination, the IP packet is sent to a router. All IP networks have a router in them, which is directly connected to all computers on the network via a cable, WiFi, 5G etc. When a packet arrives at the router, the router checks if the destination IP matches any of the devices on your home or office network. This local network is called a LAN (Local Area Network). If so, it sends the traffic directly to that device on the LAN side. If not, it will send the packet out towards the rest of the Internet, called the WAN (Wide Area Network).
The ISP’s router has its own WAN and LAN, though this time the LAN includes all their customer’s IPs instead of a single household. If the destination IP matches anything in the ISP’s LAN, it gets sent to the appropriate address, otherwise it goes to the WAN. There are many layers of these routers, and with each layer the LAN gets more and more IP addresses. Finally, your traffic will reach the “top” layer called BGP (Border Gateway Protocol) routers.
BGP routing is the main reason why the Internet is decentralized, and it is often called the backbone of the Internet. In the LAN below BGP routers, the layers of routers are hierarchical, thus having single points of failure. BGP is different because there is no WAN above a BGP router; there are only peers. Each BGP router has a list of paths to every other BGP router in the world, and there are about 1 million of them. Also, each IP address in the world is included in the LAN of at least one but normally multiple BGP routers. Using complex algorithms, routes between these routers are constantly recalculated. As routes are recalculated, each peer will tell its neighbor so that updates spread quickly like gossip. In this way, large numbers of BGP routers can go down and the system will be able to heal itself by recalculating the routes through healthy routers. Remember that thanks to TCP, any packets that those faulty routers drop will be resent.
When the traffic reaches a BGP router which has the packet’s destination address in its LAN, it will send the traffic down to the correct subordinate router, and this process will repeat until the traffic finally reaches the desired endpoint computer. The receiver will formulate a response to the packet. In its response, it will check the source IP of the received packet and set it as the destination address for the response. The response packet will go on a similar journey through the routers as the first packet did and will end up at the original computer.
Other Header Options #
Although the bulk of the Internet uses TCP, there exists an alternate protocol called UDP (User Datagram Protocol). In UDP/IP, the UDP header takes the place of the TCP header. The main difference is that UDP does not have a sequence number, so the receiver of the data will not wait for all the packets to arrive before processing the data. If data is broken into 1000 segments, UDP will process the data as soon as the first packet arrives, while TCP would wait until all 1000 of them show up. This means that UDP is much lower latency than TCP, but if a packet gets dropped in transit, it is lost forever. UDP will not message the sender to resend lost packets. UDP’s low latency is useful in voice calls, livestreams, and online video games where the latency is more important than getting all the data across.
To contrast the two, pre-recorded video streaming sites like YouTube and Odysee use TCP while live video chat platforms like Zoom and Jitsi use UDP. In YouTube or Odysee, when the connection cuts out, the video pauses and buffers, so it sits in wait for the TCP packets to be resent. If you wait long enough, the entire video will load and you will not miss anything. In Zoom and Jitsi, when the connection cuts out, the video will of course stop updating. However, when the connection resumes, that section of video when you were offline will be lost forever.
There are multiple forms of IP as well, but that is for another article. They are much more similar to each other than TCP is to UDP, but their IP headers are still formatted differently so it is worth mentioning.
Also, the IP and TCP or UDP headers are not normally the only headers attached to a packet of data. Ethernet, for example, which is one of the most common ways of transferring IP packets, adds a header to create an Ethernet frame. When the frame reaches a router, the header is stripped to return it to an IP packet. Wireguard and other VPNs add their own headers, though this time they encrypt the IP packet itself so it is not as simple as just removing the header to get the packet back. There are dozens of other reasons to add more headers and they all have to do with the OSI model, so look into that for further reading. TCP and UDP are on the transport layer while IP is on the network layer.
