RFC 1122 and RFC 1123 define the basics of the TCP/IP Model. The OSI Model may be a bit more useful for defining troubleshooting steps and more popular for discussing network issues, but TCP/IP won the standards war. The TCP/IP model is adverse to layering overall, but it does have layers nonetheless.
The TCP/IP model is based on the DARPA concepts for ARPANET and was adopted for widespread use for military networking in the 80’s. The Internet Engineering Task Force (IETF) maintains the standards and has kept the same 4 layers since the adoptions of RFC 1122. The four layers on the modern internet are the: Link Layer, Internet Layer, Transport Layer, and Application Layer.
Comparing TCP/IP With OSI
The OSI model splits the Application Layer into multiple layers. The Session Layer, Presentation Layer, and Application Layer correspond to the Application Layer in TCP/IP. The Transport Layer is the same between the two. The Link Layer in TCP/IP corresponds to the Data Link Layer in OSI, but the Physical Layer from OSI isn’t covered in the standard definitions TCP/IP. Obviously there is a dependency on physical hardware, but TCP/IP does not address it at all.
TCP/IP simplifies the stack a good bit so that all of the end agent communications are relegated to the Application Layer. The division in the OSI model can help for troubleshooting, but can be a crutch as well. By not dividing these layers, we know that our breakdown is between hosts at an application level rather than trying to finger the exact part of the agent to agent communication. We know that if we hit the Application Layer, the network itself has done its job.
TCP/IP Layers
The TCP/IP protocol is split into the Link Layer, Internet Layer, Transport Layer, and Application Layer. The protocol can also be thought of as a reverse onion.
We start with our link later, and strip off the frame header and footer to get our actual packet for the internet layer. This packet breaks down into an IP header for the transport layer, and finally contains the actual data for our application layer after we strip out our TCP/UDP header. Each layer is made to make the data able to arrive sanely to the endpoint.
Link Layer
The link layer is concerned with how we get a packet to the hardware connected to the originating agent. It can also be thought of the network before routing. This corresponds to our switches and other Layer 2 principles from the OSI model.
The reason we start at the link layer instead of the physical layer is due to the fact that TCP/IP doesn’t care about the actual hardware. The physical implementation doesn’t matter, as long as it can be linked the right way. You can have virtual networks and similar with TCP/IP and have them fully implemented without treading on a missing layer or other abstraction from OSI.
The link layer concerns itself with framing packets to send them across the link layer. Whether this is directly in hardware, in software, or in firmware is irrelevant to the actual process. The infrastructure to make this happen is assumed to exist.
Internet Layer
The internet layer corresponds to layer 3 of the OSI model. This is where routing and similar happens. We want our framed packet to go from network A to network B. This layer concerns itself with the actual packet and encapsulates the packet with an IP header to tell the network where to send it, where it’s from, etc.
We are concerned with identifying where something is going and being routed, as well as addressing what exists and where in our network.
Transport Layer
The transport layer for TCP/IP is analogous to layer 4 of the OSI model. TCP (Transmission Control Protocol) is the most common, most standard transport model in the TCP/IP model. Most everything supports TCP at some level if it uses TCP/IP (so literally all modern, non-specialty network hardware).
There are other transport protocols like UDP (User Datagram Protocol) and similar which either approach things differently on top of IP, or else try to augment TCP in some way (arguably SCTP). IP is a best effort protocol, which is why you hear about “dropped packets” and similar. TCP gives the endpoints a way to know what was sent, what should have been sent, what was received, and what is missing. It basically offers a way to error correct for the internet layer and below.
TCP gives you a degree of reliability, but UDP is more like the mail. You drop your package in and pray. UDP reduces the verbosity of packets and helps lighten the load on the network at the expense of reliability. There are other protocols as well at this level which handle the actual transport methods.
Applications are split up based on ports. Ports can be well-known like SSH on 22, or they can be completely arbitrary. There are assigned numbers, but you don’t necessarily have to follow them. Even though it impacts our application layer, we just care about transporting our data from A to B.
Application Layer
This is where all of the fun happens. The application layer corresponds to all of the higher level layers in the OSI model (5 to 7). DHCP, DNS, SSH, FTP, HTTP, HTTPS, SSL, etc. are all protocols and standards which exist at the application layer in TCP/IP. This layer is abstracted to what the machines want to actually say to one another without concerning themselves with the how.
We can cut all of the fat out of the rest of the protocol and deal with raw data here. How we handle our handshake, our application data exchange, our state, etc. is all reliant on data which the TCP/IP protocol doesn’t care about specifically.
The goal is to abstract our interaction between systems away from the network itself as much as possible. Our applications shouldn’t care about whether the data was delivered TCP or UDP (assuming perfect network conditions); it should just transparently show up where it needs to be. Our lower level of the protocol doesn’t care about what our data is, just that it fits in the packet and gets where it should.
Using TCP/IP
TCP/IP won the specification war even though people still actively reference OSI. OSI helps understand where things break down in the communication process for technicians, and further helps analyze a network, but it doesn’t tell you why you want to use TCP or UDP for an application, or which rule will work in a firewall. Unless you work in a very specialized environment, you will be using TCP/IP.
If you’re developing a network enabled application, it helps to understand TCP/IP, even though you’ll almost certainly abstract away from it. Knowing why certain things work the way they do (why do some applications use certain ports?) can help enable more informed decisions during development. TCP/IP is essential to devops and technical roles at every level. What is the TCP/IP stack and how does it impact your work? Knowing this is essential to functioning as a technician.
Featured image by Michal Jarmoluk from Pixabay