Is a header added/removed at each layer of the OSI model? - networking

I'm trying to understand the relationship between the OSI and TCP/IP models, and read at the following link that in the OSI model, one header is added/removed at each layer:
https://www.electronicdesign.com/what-s-difference-between/what-s-difference-between-osi-seven-layer-network-model-and-tcpip
That article breaks down the headers that are added/removed at each layer of the TCP/IP model, and it looks like there is one added at each layer.
What I want to know is:
I've read that both the OSI and TCP/IP models are theoretical; in what way are they theoretical and in what way are they each physically accurate? For example, the Applications layer of TCP/IP corresponds to the Application/Presentation/Session layers of OSI; is the header for the Applications TCP/IP layer comprised of three components, each of which is considered the header for Application/Presentation/Session layers of OSI?

The article is misleading. It is not true that each layer is simply adding a header.
Each layer is doing some kind of encapsulation of the layer above. For the layers 3 and 4 this encapsulation is done with a header at least when these two layers are IP and UDP/TCP. But the encapsulation at these layers also includes fragmentation of the content, i.e. spreading of large data over multiple packets.
Application layer encapsulation or encryption of the communication is way more complex than a simple header and depends on the specific application layer or encryption protocol.
in what way are they theoretical and in what way are they each physically accurate?
These are a model only. This means that they are simplified abstractions of the reality. While they kind of accurately describe the layers 2..4 especially the OSI models layer 5..7 does not match today's reality. At the time these models were created the network world was much more simpler and the layers 5..7 in the OSI model looked like a useful approach to develop protocols.
But in reality session, presentation and application is all mixed together in today's protocols: in case of HTTPS content is transferred with the HTTP protocol which then is inside a TLS tunnel but the tunnel might be again inside a SOCKS tunnel or even initiated with a HTTP CONNECT request (HTTP proxy). And a kind of layer 4 protocol like WebSockets is essentially tunneled within a Layer 7 protocol HTTP etc. There are even design where TLS records are exchanged as JSON inside a HTTPS connection.
This means that TCP/IP protocol fits more today's reality simply because it is simpler and does not have some envisioned abstraction layers which turned out not to be used.

Related

TCP/IP and OSI in practice

I was studiyng those protocols, and I even understand the basis of each layer they have, but I can't understand how they work in practice.
For example: When an application make a request, isn't it the thing that fill all those informations (like the destination, the port, the protocols used, etc.)? In other words, when my browser make a request to a server, isn't the browser - the application - that fill the entire request layer by layer?
With that in mind I can't see when the application layer gets separated from the other ones, could you explain?
In practice layer up to 4 (TCP and UDP) are implemented inside an OS. The mechanism is called sockets. The application provides IP address and port, and selects transport protocols. Then it provides data, and OS is handling all the filling out. So, separating layers 2, 3, and 4 from the rest makes sense. Separating 2 and 3 from 4 is necessary for the network in between to work.
The rest IMHO does not. In TCP/IP model for example there is only one application layer on top of the transport layer. I do not know if anyone truly understands the intended functionality of session and presentation layer in OSI model. We all learn them and some protocols that are attributed to these layers for some unknown reason (e.g., i don't know why is TLS layer 5 and not 6). IMHO, these layers could make sense if you are designing particular class of applications, but if you consider all current Internet applications, I don't think these generalization makes sense.

How does physically TCP send and receive data?

I'm currently learning about Layer 4 in the tcp/ip model. All of the sources of information that I have stumbled on gave me the following explanation about how the TCP protocol is implemented by the computer: "It establishes connection between the application and the computer via network sockets and transporting the required data between a specific port which is a direct function to the transmitted data."
I found this explanation very vague considering the fact that it does not give any info about how it is actually transporting the data in between the ports, so my question is as follows:
How physically the data is transmitted between layer 5 and 4 using TCP and is this transmission limited only to programs or processes inside the computer?
TCP is layer 4. You need to look at layers 1-3 of the OSI model to understand how it gets around. Layer 1 would discuss how electrical (or light) impulses are encoded on a wire which would be the physical part. All the layers above are various kinds of abstractions of how those impulses (0's and 1's) are interpreted.
Basically data isn't transported between layers. Each layer is enbedded in the layer below it. In other words layer 2 has a payload which holds layer 3 and so forth. So as the data moves up the stack each layer is removed. So layer 4 wouldn't see any of the encapulation for layers 1-3, but would have layers 5+ in its payload which it would pass along once it handles and stripes off its part.

gossip protocol works on tcp or http

The Gossip protocol used by many distributed systems e.g. Cassandra to communicate with other nodes in the ring. So, does it use HTTP or TCP protocol?
Also, what are the pros choosing one over another in distributed systems?
You can use any protocol you want (tcp, http, dns etc) to broadcast information regarding the state of your nodes from a cluster. In my opinion , you should focus on a gossip algorithm, and not really think about the "protocol" word from the naming. At it's core, it's all about broadcasting information between nodes. Each node sending it's own view of the cluster state to a subgroup of nodes, and the broadcast keeps going until all nodes share the same view. There are multiple ways of implmenting such a broadcasting algorithm so research more about it or try your own model :) .
Here is some nice info and pseudo code about gossip model/algorithms
HTTP and TCP are fundamentally different things as they work on different layers of the network stack:
https://en.wikipedia.org/wiki/OSI_model
If you look at the OSI Model TCP works on the transport layer (Layer 4) and HTTP works on the application layer (layer 7), The two perform different jobs. The transport layer is responsible for providing the functional mechanisms for transferring data. The application layer is built on top of the transport (and other) layers and provides items such as partner negotiation, availability and communication synching.
The two are not interchangeable with one another.

layer dependence about network

i have a question about network layer, that is:
as we all know, in layer architecture, the N+2 layer should only depends on the N+1 layer, while knows nothing about N layer. for example, in a typical application, the web layer should only depends on the business logic layer, but not the data access layer
when it comes to computer network, things seem to be different. In application layer, program has to know not only transmition layer(TCP port), but also network layer(IP address)
this confuse me, what do you think about this?
thanks for your help.
generally you are right. Unfortunately borders between layers in networks are kinda blurry, not just because we have a standard which is not used (OSI) and de facto standard which does not enforce the idea you mentioned, but also because the protocols are often not strictly bound to one layer but can do stuff on more then one of them. Good amount of protocols is developed before the OSI model and before they were standardized and then it was already too late to make some radical changes. So there are protocols that are considered to be between two layers (or on both layers) like MPLS, ARP etc. And protocols that are based on another protocol which is on the same layer, like OSPF that runs on top of IP even if they are considered to be on L3.
What you mentioned is another example. The reason for that is that addressing is not done on the most-upper layer (application layer) but on network layer (for host/network adapter) and transport layer (for process/application). So you need to know the IP address and port number (and actually a protocol) to be able to address the remote application. That's where the network sockets come in as an gateway (or API) between application and the network. So, even if you are technically correct about defying the principle of layered model, you are not really doing anything on L3 or L4 (but you can;) ). You don't need to fragment packets, handle retransmissions or worry about error corrections etc., you are just passing down the required addressing information when creating a socket.
TCP/IP is more oriented towards the feasibility of implementation, where OSI is more concerned about the standard then the implementation of that standard. This has it's bad and good sides. The ability to freely implement the protocol can be an advantage if you use that power well and since you are not strictly bound to some specification you can do some things more efficiently... or fail epically. The drawbacks of mixing 'responsibilities' are obvious and great example are protocols like H.323 which embed the IP addresses inside user's payload so if you want to do NAT for example you need to inspect the payload, change IP addresses, recalculate checksums, and stuff like that instead of just handling the translation on network layer.
Why are stuff still like this? Probably because there is no easy way to change any of that because of sheer number of devices and protocols, applications, etc that needs to be updated and this takes a lot of time. Just look at the speed of adopting IPv6 which has been around for more then 15 years.

which OSI layer handles?

some file transfer is in progress. the connection break s and then
later after some time is restored. then on the file transfer continues
from the point where it left off, which OSI layer handles this?
presentation, application, TCP, IP, Sesssion
First of all, TCP/IP is not OSI (see here). And if the connection really breaks, TCP won't be able to allow for continuation of transfer, it has to be done at a higher level (which is not defined in the TCP stack).
You are using FTP client which works at application layer.When any connection is created a session is maintained as per the capabilities of the application.Session management is done at session layer.So when FTP is able to resume the transfer that is because of session layer. OSI model is only a reference model and each layer has different set of protocols. To have more in-depth understanding of the flow in OSI model layers i have created an example. You can refer to this link to understand more.
https://thinkingmonster.wordpress.com/2016/08/20/understanding-osi/
which OSI layer handles this
The OSI session layer would handle it, if you were using OSI layers.
Well, layers are always referred as per OSI model, no matter wether its actually being used as specific stack. I totally agree with #thinkingmonster's answers. To add more on this I would say its the Transport layer ( layer4 PDU as per the OSI ref model) and layer 2 in TCP/IP stack.
This is typically handled by Error recovery mechanism using Sequence and Acknowledgement field in TCP header.TCP achieves reliability in both directions, using the Sequence Number field of one direction combined with the Acknowledgment field in the opposite direction.
This is just a little overview to have an idea, you might want to refer the Doc to have full handshake cycle with client and server.

Resources