(ELi5) OSI Model and TCP/IP Model in Simple Terms?

334 views

I’m not a computer science student. But I want to learn it and grasp these two models in very simple language and terminology.

In: 7

8 Answers

Anonymous 0 Comments

To get a bit more technical (since the other answers focus on definitions):

Say you want two electronic devices to communicate with each other. (we’ll assume digitally as analogue is another story) How? First you have to figure out the basic physical properties – serially, one bit at a time, or multiple bits at once (in parallel). What voltages are you going to use to represent the ones and zeroes (and is a high voltage a ‘1’ or a ‘0’?) what timings do you use, what rate should you expect the bits to be sent at? All these rules are make up the protocol of the first, physical layer.

How do you know when the data being sent starts, and ends? How do you know whether it’s been accurately transmitted, and how do you request a re-transmission if it wasn’t? What if you have multiple machines? How do you ensure they don’t “talk over” each other? This protocol is the ‘link layer’ defines a single link or a local network. These first layers are not really independent, since the link-layer protocol depends on the nature of the link.

Anyway, all you have at this point is a pipe to get data from A to B on a network. And for some applications that’s good enough (say, talk between different components within a device), but for computer networks you want something more general purpose and powerful. Since, at this level we’re no longer concerned with the details of how the data gets from A to B, we can add a ‘network layer’, a layer of abstraction allowing communication through _different_ local networks, by defining a protocol that puts all data into chunks (packets) that all contain the addresses of the sender, receiver and other information. The example of this would be the Internet Protocol, and IP addresses. This is an address which is independent of the type of network you’re on (as opposed to e.g. a MAC address, which is your address within an Ethernet network and only reachable within that Ethernet network)

Now that you can get data from A to B across a whole set of networks (and routers and whatnot in-between), _that_ data still needs to be wrapped in some form of packets, because you want to be able to have multiple programs talking at the same time, or a single one carrying on multiple ‘conversations’. And if you want to send data that doesn’t fit in a single IP packet, it needs to be broken up into chunks and sent as multiple packets and then reassembled. But not everything needs to do that either, so for this purpose you have the ‘transport layer’ protocols (such as UDP and TCP which both go over IP). In short, TCP gives you (from the program POV) a continuous ‘pipe’ of data, and under the hood it handles breaking that data up into chunks and rebuilding them in the correct order (since you don’t know how stuff is routed at this level, you don’t know that packet 1 will arrive before packet 2), retransmitting ones if necessary, confirming reception, maintaining the connection, and such. It’s like a phone conversation whereas UDP is a simpler protocol that just sends single packets (‘datagrams’) and does not retransmit, concern itself with the order or anything, it’s like sending a postcard. This may seem inferior but it’s useful for things like VoIP, where speed is more important than flawless transmisssion, because a packet’s data may have become irrelevant by the time it’s retransmitted.

The next two layers (Session, Presentation) are rather vaugely defined (and not as commonly used when people talk about this stuff anyway) and it gets fuzzier from here. I’ll skip ahead – the top layer is the application layer. And that’s the data the actual program concerns itself with. Now that it can get its data from A to B, doesn’t need to worry about retransmitting and all the stuff going on, it has its ‘pipe’ (if you’re talking TCP) where it’s talking to the right program on the right computer and all that, all that’s left is for the program to have decided a protocol for how it talks. For instance a TCP packet containing “GET /index.htm HTTP/1.1” (followed by a newline) is the HTTP protocol, with a request to retrieve the page “/index.htm” from a server. (protocols don’t have to be text-based though, many protocols are binary data) Client-server communication typically takes the form of some sort of request and response packets.

Now, there are some things that aren’t so application-specific yet higher level than TCP and UDP. For instance (nowadays) you have encryption through the TLS (also known as SSL) protocol. TLS communicates over TCP and is higher level than that, but it is only a means of getting encrypted application data from A to B, it doesn’t ‘know’ or care what the underlying data is once the encrypted connection is established. So this is session-layer.

As for presentation layer.. as said, an application may send binary data or text data or format that data however it wants. However, there exists _families_ of protocols for some purposes, where there’s a common standard of how data is to be sent, which contains metadata about what the format of the data is, so it can be parsed. This layer (if present) is the ‘presentation layer’, and the point then is that the application only needs to concern itself with checking the content, and not the format, of the data it was sent. But this is all a bit indistinct from the application layer.

So if you’re reading this it’s most likely via some modulated 2.4 GHz microwaves that decode (layer 1, WiFi) to form 802.11b Ethernet packets (layer 2) containing IP packets (3) containing TCP packets (4) containing TLS packets (5) containing an HTTP response (7).

You are viewing 1 out of 8 answers, click here to view all answers.