Sunday, March 09, 2014

The good old TCP/IP stack

There are theoretical models, such as the ISO/OSI one, that cast the Internet into a set of many levels in an attempt of standardization. The Internet protocol suite, also known as TCP/IP, describes instead what goes on in reality to show you this blog post. The suite is divided into multiple layers, each building on the previous one and containing several protocols that can be theoretically swapped with each other.
I may use some protocol-specific terminology for antonomasia, such as frame.

Link layer

The link layer solves the problem: how do I get a frame of bytes from one physical device to another? Consider that the network resources, such as physical cables and radio frequencies, may be shared so that collision is possible. For the same reason, sometimes routing has to be available to identify who am I sending these bytes to; however this routing is physical, consisting of single point-to-point connections or of network card addresses.
Inside a local network, Ethernet and the wireless IEEE 802.11 standards have the lion's share of the market. Devices are identified by their firmware-based MAC addresses and the network may contain switches sending the frames travelling trough them to the correct recipient.
However, a local network is of limited utility nowadays. To talk with the rest of the world, more complex link layer protocols are needed: they get you from your DSL router to your ISP ones, maybe even involving multiple hops such as a section based on copper wires and one on optical fiber.
The link layer is closely coupled to the hardware available: different protocols work on different mediums such as wires, glass and electromagnetic waves. It is possible in theory to abstract the business logic (say, how to detect a collision) from the medium; however, it's like testing a Repository object by looking at the query that it generates instead of running it against the real database.

Internet layer

In the Internet model, machines may have globally-recognizable addresses that have meaning outside their local network. Thanks to these IP addresses and the related protocols, you can solve the problem of getting packets of data from one node in the world to another.
However, these packets have severe limitations:
  • they are of a limited or fixed size, that cannot be increased more than a few thousand bytes due to the packet switching model.
  • No order is guaranteed: packet may take different paths to get to the target host and arrive in any order.
  • Their transmission is best-effort, as there can be arbitrary packet loss.
Inside the global network, all hops at the Internet layer level have an IP address; the source and target IP addresses are written inside each packet so that each intermediate node can route it towards the neighbor that is probably nearest to the target. You can imagine the complexity of constantly updating this routing table while addresses are (re)assigned every day.
IP (version 4 or 6) is not the only Internet layer protocol. ICMP is one of the other famous ones, used for example by ping and traceroute for troubleshooting.
Finally, note that due to the limitations of the public address ranges containing only 4 billion IPs, NAT and other techniques have been developed to provide private address spaces to local networks. This severely breaks the model of  globally addressable nodes, as for example nodes inside your home or office network cannot accept incoming connections (without resorting to port forwarding). It is a necessary evil due to the ubiquitousness of IPv4 and its 32-bit address fields.

Transport layer

The Internet layer provides global connectivity, but with the limitations described above. To provide a useful bidirectional communication channel, the Transport layer builds upon the unreliable packets of the Internet layer to provide the illusion of a local IO stream, the same you could get by reading a file.
Consider for example the Transmission Control Protocol, TCP; it provides:
  • reliable and ordered communication between hosts. Lost packets are retransmitted and sequence numbers to correct out-or-order arrival.
  • multiplexing of communication channels between two nodes single link via ports. I can connect to the same web server with multiple browsers without the HTML pages and images being returned messing with each other.
Other protocols such as UDP are not optimized for reliable communications, but on other parameters like latency. What matters is that with a transport layer we can build a remote terminal which is conceptually the same as a local one, sending streams of text and receiving other text back.

Application layer

Once we have transformed the mess of wires and network devices into a universal interface made of text and bytes, it's up to the application to do something useful with it. Protocols at the application layer differ in what they offer to the end user:
  • Identification of nodes with an host name even if its IP address changes or they are physically moved elsewhere (DNS).
  • A way to read and create hypertext/hypermedia documents and related resources (HTTP).
  • A secure terminal session on a remote machine (SSH).
  • Updates for the local clock of your machine so that it's always correctly set (NTP).
  • Voice and video chat (proprietary protocols usually).


Why it's important to know how the full stack of the Internet protocols works?
  • When something breaks or slows down, it helps to identify the level at which the failure is happening, and contact the right person such as a your ISP, a system administrator that has to restart a VPN or a programmer not targeting the correct HTTP response code.
  • Layers are isolated from each other, so you can usually swap implementations inside one layer while keeping a system functional, sometimes sacrificing non-functional requirements such as performance. If your DSL line is down, you can use a mobile broadband Interney key without changing software.
  • Some problems are best solved inside a particular layer: congestion control by the transport layer, routing and visibility at the Internet layer. Why wasting energy in segregating responsibilities when there is already a standard division of labor we cannot change...

No comments: