Yes, I understand what you are saying. However, keep in mind that the IP address identifies the host or the device that is being served by the server. What happens if from my PC I open up four tabs and connect to the same web server? On one tab I click on one particular hyperlink, and on another tab I click on another. Both requests were made from the same IP address, so how does the server know which “session” to respond to? It knows from the port numbers being used within the session layer. That’s why Rene states that each individual session, from web browser tab to web server must be kept track of.
Please correct me if I’m wrong, but aren’t we talking about session multiplexing, which is a Transport layer function? So when multiple users connect to the same web server, doesn’t the server keep track of each user’s activities by using the socket (which is, if I’ve learned it correctly, the combination between the destination IP, destination port, and source ephemeral port)? And within each user’s Transport layer segment, doesn’t the Session layer data keep the streams apart? So if I remember correctly from other resources, it should be the Session layer that makes it possible for me to log in to the same site using different accounts, among other things.
So doesn’t the web server should keep track of the different user sessions by using the sockets (which is a Transport layer function, instead of Session layer as indicated by the article)? I’m still new to the networking field so please apologize if I’m mixing things up.
First of all, you are correct that an application will indeed keep track of each communication based on what is called the internet socket address, which is a combination of the transport protocol, the IP address, and the port number. These three elements can be used to differentiate between communications with a server. This is the case because even if they come from the same host, and the same transport layer protocol, they will still have a different port number (on the host side) making sure that it is separate.
Now I think from here on the confusion takes place due to terminology. The word “session” is often used to refer to a communication created using a socket that uses TCP as the transport layer. So we often talk about a transport layer session or TCP session. But the word session is also used to talk about the Session Layer of the OSI model. In my posts, I was using the word “session” as a transport layer communication, and not the OSI model layer.
Although the OSI model was developed as a framework for all network protocols to adhere to, it has been superseded by the TCP/IP model (which I’ll talk about shortly). Today, the OSI model is primarily used for training purposes. Although there are some OSI-based protocols still in use today, the vast majority use TCP/IP.
In the lesson, the Session Layer does actually preform many of the session functions described in the lesson, however, in most communications today, the Session layer doesn’t exist because we now use the TCP/IP model which is further described in this lesson:
With the TCP/IP model, the separation of sessions is performed exclusively by the socket described above. Does that make sense?
If I understand everything correctly, the following things must happen when I use a website:
I open facebook.com. My computer creates a pair of sockets: one socket consists of my own IP address, the protocol, and an ephemeral port (eg 123.123.123.123, TCP, 49152); and the other socket consists of the server’s IP address, the protocol, and port 80 (eg 157.240.22.35, TCP, 80). When I enter my login credentials and log in to my account, another pair of sockets is created (with the only different piece of information being the ephemeral port). Then, when I click on someone’s profile within Facebook and a new page loads, a third pair of sockets is created (same as before: new ephemeral port, everything else the same). If I then close facebook.com and open networklessons.com, a fourth pair of sockets is created (with a new ephemeral port, and networklessons.com’s public IPv4 address as the destination IP in the socket, everything else is the same).
The information for a socket is gathered from L3 and L4:
the IP addresses are in the packet (source and destination IP) (=L3);
the protocol information is also in the packet (in IPv4: in the Protocol field; and in IPv6: in the Next Header field) (=L3);
the ports are in the Transport layer’s (=L4) segment: both the
(a) well-known/system (0-1023) or the user/registered (1024-49151) port (as the case may be), and
(b) the ephemeral/dynamic/private port.
So session multiplexing is due to Layer 3 and Layer 4. Layer 5, the Session layer, doesn’t play a part. Or am I missing something?
I’ve just now subscribed to the full year membership, in big part due to your many helpful answers.
Have a great weekend!
Attila
(Note to anyone else reading: 123.123.123.123 is of course just a made-up IPv4 address and not my actual public IPv4 address.)
Your description sounds just about right. Just a couple of comments.
Your computer doesn’t create a pair of sockets, even though each communication has two sides to it. Your computer sees the socket as the IP address, transport layer protocol and port of the device it is connecting to. So the socket it sees is 157.240.22.35:80 using TCP. The web server sees the socket as 123.123.123.123:49152 using TCP.
Secondly, when you go to Facebook, each click may be established using a different socket, or it may be part of the same socket. It depends on the way the web site is designed. Typically you will have several sockets created when communicating even with one web site.
Finally, I keep using the word socket as you did as well, but we must keep in mind that this terminology has been largely replaced with the word “session.” So when using TCP, the word session is used to refer to each individual, independent communication that takes place using a particular socket.
Yes, that is correct. The session layer plays no role in this because when using TCP/IP there is no session layer. Above the transport layer we have the Application layer as seen here:
Great to hear that you are finding these conversations useful! It makes our job all the more rewarding.
I hope this has been helpful!
Laz
PS
I remember my first computer which had a 2400 baud modem with WIndows 3.1, we’d use a software utility called Winsock which would create this socket with an Internet provider’s server to gain access to the Internet. Those were the days…
Thank you again for the correspondence.
So when I’m browsing a website on the internet, then I’m probably not the only user of the web server hosting that website. The way this web server keeps track of all the different “sessions” is using the L3 and L4 information that used to be named the sockets, but a more modern term is “session?”
Yes that is correct. Let’s assume that we have a web server at 20.20.20.1, and let’s assume we have five hosts accessing this web server with IP addresses 5.5.5.5, 6.6.6.6, 7.7.7.7, 9.9.9.9, and 10.10.10.10. You will have five separate sessions like so:
The elements used by the webserver to differentiate between these sessions are the source IP, the source port, and the Layer 4 protocol being used. These are unique for each communication and constitute a session.
Notice I put in two sessions from the 9.9.9.9 host with different source ports, to emphasize that a single host may have multiple sessions with the same web server.
Hello Laz,
Thank you. In that case, it isn’t the Layer 5 (Session) of the OSI layer that takes care of this function, but Layer 4 (Transport) and Layer 3 (Network). But the article gives this definiton:
“Session: The session layer takes care of establishing, managing, and terminating sessions between two hosts. When you are browsing a website on the internet, you are probably not the only user of the web server hosting that website. This web server needs to keep track of all the different “sessions.””
So the article seems to assign the function of session multiplexing to Layer 5, but as we’ve discussed, it’s actually Layer 4 and Layer 3 combined which is responsible for session multiplexing. Or am I interpreting something incorrectly?
I understand the confusion. Let me try to clarify.
The OSI model was developed in the 1980s in the hope that all present and future networking protocols would conform to its layers and operate within its framework. However, the TCP/IP model took precedence primarily due to its prevalent use on the Internet, and by the end of the 1990s, the vast majority of networking protocols adhered to the TCP/IP model rather than the OSI model.
However, the OSI model still remains today, primarily as a teaching tool to help students and learners understand the concepts involved in layered models in general. Today, very few protocols in networking strictly adhere to all the layers of the OSI mode. Most conform to the TCP/IP model.
In this lesson, Rene is explaining what the particular layers 5 and 6 deliver within the context of the OSI model. But these descriptions are relevant only to protocols that adhere strictly to these layers. TCP is not one of these protocols, therefore you cannot talk about TCP in the context of the OSI model. It must be discussed within the framework of the TCP/IP model.
When we’re talking about lower layer protocols such as Ethernet, IP and others, there is a general counterpart to the lower layers of the OSI and TCP/IP but once you get to the transport layer, things differ vastly.
The mechanisms found in the Transport, Session, Presentation, and Application layer of the OSI model are distributed between the Transport and Application layers of the TCP/IP model, and you can only talk about particular protocols within the context of the stack they belong to.
So if we’re restricting our discussion to the OSI model, then we can say that multiplexing (which is done using the socket pairs) is done on Layer 3 and Layer 4 of the OSI model?
In that case, what is the function of Layer 5 (Session layer) of the OSI model? There’s a list of what appear to be OSI L5-only protocols here, along with a definition of OSI L5:
If I understand it correctly, OSI L5’s function is to enable the same process to communicate between two different hosts, as if those two hosts were one and the same host.
The multiplexing that is achieved using IP addresses and Transport layer port combinations (socket pairs) is indeed confined to Layer 3 and Layer 4 of the OSI model.
As stated in the link you shared:
The session layer provides the mechanism for opening, closing and managing a session between end-user application processes, i.e., a semi-permanent dialogue. Communication sessions consist of requests and responses that occur between applications.
Now what format that communication takes depends strictly on the protocols being used, and what function they actually provide depends upon the applications that are communicating. For example, take a look at this Wireshark capture of a NetBIOS communication, which is considered Layer 5:
You can see the Layer 4 info where UDP is being used and the Layer 5 info under the NetBIOS heading. There you can see the various parameters of this particular protocol.
Here you can see the PPTP Layer 5 protocol running over TCP as the Layer 4 protocol. Here we have different session mechanisms taking place based on this particular protocol.
Remember that the higher you go in the OSI model the more particular protocol design becomes to the applications being served. For lower-layer protocols, they are not specific to the applications being served. As you go higher, they become more adapted to each individual application, so the definition of their function on a per-layer basis becomes more blurred.
So Layer 5’s function is to manage sessions between end user applications, but not within the same framework as the “session” defined at the Transport layer. Layer 5 sessions and how they operate depend more on the particular applications they are serving. Does that make sense?
Is it correct to say that not all applications make use of OSI L5’s functionalities? Namely, those applications that don’t use any of the Session Layer Protocols listed on the website (and others not listed that also belong to OSI L5).
When it comes to applications that do make use of OSI L5’s functionalities, is it correct to say that without the OSI L5’s information, the individual bits of data could not be uniquely identified, and the two applications on the two separate hosts could not communicate with each other, using only the socket pairs that are contained in L3 and L4?
Yes, that is correct. Here is an example of a protocol that does not use OSI, but uses the TCP/IP model. The HTTP protocol is at the application layer of the TCP/IP model and can be seen here:
Strictly speaking, the application on an end device will be identified using the socket pairs. However, within the functionality of a particular application, and the protocols it leverages, you may require more information to allow sessions to operate correctly. It’s no longer a matter of uniquely identifying the data streams, but more an issue of allowing sessions to operate correctly within the confines of the particular protocol being used.
For example, if you’re using PPTP (which you shouldn’t because it’s obsolete and insecure) then you will need both ends to communicate appropriately to allow that session to take place. The session layer protocols ensure that communication can take place.
So for PPTP, the socket pairs of L3 and L4 are enough to allow identify the particular application being leveraged to communicate, but L5 info is needed to further define the specific functionalities of that protocol.
You will find that as you go higher in the OSI model, the specifics about what actually occurs becomes much broader as protocols are differentiated one from another. So PPTP may perform a particular task in L5 while H.245 which is another L5 protocol, may require somewhat different functionality at L5 to operate.
I am the new one with networking. I am just start reading the lesson CCNA but i have an issue with misunderstanding about OSI Model which part Physical layer: "Physical Data Rate " . So what is Physical Data rate ? I have read twice times but still can’t understand. Can you please help me ?
The physical data rate is the rate at which data is placed on the physical medium for transmission.
For a wired connection using copper UTP cabling, this has to do with how fast the bits of information are translated into voltage pulses and how many bits are actually transmitted over a period of time. The design of Ethernet over UTP for example, offers physical data rates at 10, 100, and 1000 Mbps, as well as 10 and 40 Gbps under special circumstances. These are physical data rates are determined based on the design of the technology.
For wireless communication, the physical data rate is the rate with which bits are encoded into the waveform of electromagnetic waves sent and received on the antennas of the access point and the client. Typical wireless data rates range from 1 Mbps to over 1Gbps, but it depends on which technologies are being leveraged.
For fiber optics, this has to do with how frequent the light pulses are that are sent over the medium. For Ethernet over fiber, it has the same physical data rates as UTP, but it delivers higher rates too, including 40, 100 and 400 Gbps.
In each case, the physical data rate has to do with the physical design characteristics and constraints that affect and determine how much data you can actually send over any period of time. This is why this particular characteristic exists on the physical layer.
Re: Introduction to OSI Model - OSI Model in Action/Wireshark
The filter, http.host==“cisco.com”, isn’t generating any traffic, similar to an earlier post.
In Rene’s response, he suggested using tcp.port==443, but mentioned that it has the tradeoff of encrypted traffic making it less interesting to look at. However, that filter does generate some traffic.
Rene’s suggestion to use http://neverssl.com may have worked then, but the site isn’t active now.
I’ve tried inserting other major websites like http.host==“microsoft.com”, salesforce.com, etc., none of which generate any traffic. I suppose they’ve all moved on to https.
Is there another site you’d recommend using to see unencrypted traffic or is tcp.port==443 good enough? I used the filter “tcp.dstport == 80” that generated HTTP traffic and enable me to follow your lesson. Is this a good workaround?
If Cisco.com and others use https now, is this an option: https.host==“cisco.com”?
Just a clarification first. The filters that are applied don’t actually generate traffic. They are used to filter out particular packets that have specific characteristics on traffic that has already been generated and captured. Because you’re using the term “generate traffic” for these, I just wanted to make sure that your meaning was consistent.
So before you actually put in filters for particular sites or for particular protocols, make sure that you’ve generated and captured traffic that will contain those packets. There’s no use searching for http.host==“microsoft.com” for example if you haven’t captured traffic from an attempt to view their web page.
So when using these filters, you first must generate traffic that will contain packets that will match the filters you are using. Because most sites today use HTTPS for security purposes, to filter out those particular packets, you should use the tcp.port=443 option. If there is HTTPS traffic within the captured packets, then this filter will display them, but you will not be able to see the actual data being transferred as this is encrypted.
There is no such filter as https.host so you can’t use that.
If you want to capture HTTP traffic, simply find a site that still uses HTTP and capture traffic from your web session there. There are still some sites that use HTTP instead of HTTPS, and if you do a search online you should be able to find some. At the time of the writing of this post, I was able to find http://nginx.org/ that still uses HTTP. So try using that one, or find another.
If you generate HTTP traffic, you will be able to use either tcp.dstport==80 to filter out all HTTP traffic regardless of the destination, or you can use http.host=="ngnx.org" to filter out HTTP traffic with a particular domain name destination.
After receiving your reply, I tried to capture http traffic and was able to. I tried a few different websites including http://nginx.org/ and am not sure which sites generated this traffic:
When I enter - http - in the filter, 66 http packets are displayed. By using tcp.dstport==80, two http packets are displayed. With http.host==“ngnx.org”, there aren’t any packets displayed.
Do you know why the http.host==“ngnx.org” filter isn’t showing any results?
How do you identify the website?
Since http uses port 80, what’s the reason that the port 80 filter displays only two packets while the http filter displays a lot more?
What you describe is normal behavior. Remember, communication between a web server and a client takes many forms, and has different characteristics, so the different filters you use will have different results.
The tcp.dstport==80 filter will only show packets with a destination port of 80. By definition, such packets are those sent from the client to the server. Any responses from the server will not have a destination port of 80 but a source port of 80.
If you simply enter http as the filter, then it will include HTTP traffic in both directions.
For the http.host filter, you must keep in mind that this is a filter used to filter out packets based on the Host header field in HTTP requests. Take a look at one of the HTTP request packets in your capture and examine what is found within the HTTP header to see why the filter isn’t working.
