For this section, we will cover the 4 upper layers of the OSI/TCP/IP Model. As mentioned in an earlier post regarding these two models I will be referring to the OSI model as both for the sake of simplicity since they are essentially the same. Also below is the topology of how things will flow during our inbound and outbound connection for this demo.
When a program such as any piece of software needs to reach the internet, it will start by using the Application layer.
We will demonstrate with how this model interacts with a machine connecting to YouTube.com
Firstly, a web browser will start by sending an HTTP GET request to YouTube servers. This will start on the 7th layer with a HTTPS header with the data requesting data from the server. Then we move on to the Presentation layer. This layer is responsible for Data Format and Encryption. Data format refers to the file types being sent/received. These can be anything (ex. file.jpg, file.pdf, file.rar etc…). For this example, we will be requesting a .HTML (Hypertext Markup Language) file from YouTube. For encryption, this can vary. Today there is a mixture of a protocol called QUIC and SSL (TLS). Now we move onto the Session Layer. This is responsible for starting the conversation between the browser and the web server making sure all data is flowing smoothly with/without encryption (depending on if it’s HTTPS or HTTP). This layer also ignores the other layer’s telemetry. Some examples of the Session protocol can include L2TP (Layer 2 Tunneling Protocol for VPN’s), RTCP (Remote Transport Control Protocol, for voip calls), H.245 (for video calls), and SOCKS (Socket Secure, for proxy’s). Keep in mind that all of this is technically included in the TCP/IP model for the Application layer.
Now we are moving onto the Transport Layer. We have two major protocols for transporting our data. There is TCP and UDP. Both of these protocols will deliver the data to the correct destination but in two totally different ways. More in-depth information regarding these two protocols will be talked about later in further posts. What to know quickly is that TCP constantly checks to make sure the data is delivered to the destination and ensures 0% loss. The protocol will first initiate a 3-way handshake with the server to make sure they are talking on the same page. UDP will deliver the data, but no checks are done to ensure the data has arrived with 0% loss. For accessing YouTube a mixture of these protocols are used. TCP is used to load everything but the video. The video is loaded nowadays typically with QUIC which uses UDP as it’s Transport protocol.
From here they move down to the lower layers which are then piped out to YouTube servers and we have a flowing connection.