Application layer and Transport layer in detail
This is the continuation of series - Computer networking: how internet works, with 3rd article. So make sure you have read previous articles. with that being said let’s jump in.
Refreshing the server-client architecture, client is one who request. Server is one who take request and do stuff and send response. Now, google.com example which we used till here is boring, now the example we will use next is, You are on amazon app on web browser of laptop which is getting internet from hotspot of mobile. You clicked on checkout, money from your bank account got deducted, your order got placed and you received an confirmation email. Now if you forget, let me remind you we will be looking networking process with TCP/IP model, so there will be only 4 layers.
Application layer:
The application layer is where end-user application and services interact with network.
When you're logged into the Amazon app, a cookie is stored on your device to authenticate your requests, ensuring the server recognizes you as a logged-in user. As you proceed to checkout, the app sends an API request to Amazon's server. To facilitate this, DNS (Domain Name System) translates Amazon's domain name into an IP address, directing the request to the correct server. Request contains the headers which includes many many details, such as, type, url, ip of the server on which resource being hosted. Although DNS convert domain into IP address it may not refers to original IP address of the server which hosting the domain of amazon. what i mean is the IP address you get when you show any remote address at inspect mode, of any websites resources, here Amazon, it may correspond to a nearby server or a load balancer, which directs your request to the most appropriate Amazon server. But at the end you get the idea of how DNS playes the role of determining the IP of domain of amazon url you hit. One of the tricky point here is DHCP.
Dynamic Host Configuration Protocol. which operates at this application layer, although it’s job is to assign the IP addresses to devices automatically, it operates not at the network layer, but application layer. DHCP server basically eliminates the need of dynamically assigning IP to each device. It can be any device on network, it has available pool of IPs which gets assigned to device connect to network.
clap!! clap!! we are still on Application layer, what happened till here is just IP determined, our device has IP assigned by DHCP, and HTTPS request initiated. Now one thing to point out is Every layer has two jobs, 1: sending data to next layer or previous layer 2: recieving data from the next or previous layer. The request includes HTML files, Static files, encrypted JSON data containing details like payment information, product specifics, and shipping address, all transmitted securely using the HTTPS protocol.
On the server side, the Application layer processes this incoming JSON data, handles the payment, updates the order status, and prepares a response. This response, sent back to your app, includes an HTTP status code and a JSON payload with order confirmation details. Once the app receives this response, the Application layer on your device decrypts the data, updates the user interface, and may redirect you to a confirmation page.
Additionally, as part of the checkout process, Amazon's server sends a confirmation email using the SMTP (Simple Mail Transfer Protocol). This email is then retrieved by your email client through IMAP (Internet Message Access Protocol) or POP3 (Post Office Protocol 3), allowing you to view it in your inbox.
There is also more stuff like, caching, OAuth protocols for token authentication. Caching storage, error handling, encryption and decryption etc can be visualized in this layer.
So Application layer has - session management, HTTP/S, SMTP, IMAP or any other transfer protocol for secure data transmission, DNS - Domain Name Service for getting IP from domain name, and DHCP for allocating IPs to devices. That’s it.
Transport layer:
Application layer does app related things, physical and DLL do some physical things, Most important thing of networking process is of these two layers - networking and transport.
The Network layer is responsible for transmitting data between different devices across networks (like from one server/client to another server/client). Once the data reaches its destination device (client or server), the Transport layer takes over to manage the delivery of that data to the correct application on the device, ensuring it reaches the intended process or service. That thing you never knew even after getting A+ grade in your networking course in CS degree, ask yourself buddy.
Now where we left of in Application layer, our authentication got checked by sessions, our data get encrypted using HTTPS, IP of amazon determined using DNS. Now these whole thing is ready to be transmitted to the network, or server of the IP address. Transport layer comes into play. First of all it will send this data to the socket associated with port number.
Repeat after me,
” IP address recognizes devices on the network, Port number recognizes applications on the device”
Again…
” IP address recognizes devices on the network, Port number recognizes applications on the device”
You are running multiple chrome instances, HTTPS requests are by default send to port 443(HTTP to 80). but how does that determine the data transmitted from that particular instance of chrome, is called ephermal ports which is managed by chrome itself.
Right now, open the command prompt, before that run multiple browser instances(tab I mean).
Command: netstat -ano | findstr :443
This is my output. 192.168.42.33 is my local ip, followed by 5 digit number which is ephermal port number of that chrome instance. Next column, these where the public IPs of the websites which you are running on that instance(tab). and followed by general port number, which obvious as they won’t show ephermal port number. Next column is connection indicates the state of connection. And next column is process ID.
Ports will have encrypted data, which will get divided into chunks of bytes - data segments and each associated with a number so the order of the delivery get maintained. Data segments also has checksum, you will get to know why exactly so. Now on the other hand server receives your bits of data, it will re-combine them. Now it will check the checksum and ensure that matches with the original checksum to ensure data received in same order. After that all the process happen of preparing response which we discussed in the application layer. This again received at the port of the application, This response contains https response and an email, port will send this packets of response to particular application(chrome instance and email service) by ports and ephermal ports. And will recombine those data segments and check the checksum to ensure data transmission.
That was the job of Transport layer. Now as in application layer we had https protocol, we have UDP and TCP protocol at transport layer.
We talked about data segments. Which have associated number with it - sequence number. The whole data packet has checksum. Which on the receiver side get checked for purpose to determine data has arrived without any loss and sequence number for re-arranging the data segments in order.
This transmission can be of two types, one is when client-receiver has established connection: TCP, and one is they communicate without establishing the connection: UDP. The example we are taking till now is of TCP. Because HTTP/S built over the TCP. Every http/s request is TCP by default.
See, why we use TCP, it does not prevent the data lose. Again carefully, say it with me, “TCP does not prevent data loss”. It simply know that data lost, so it re-transmit the data.So, while you might say it prevents data loss, but, but, holy but, it doesn't stop the loss from happening in the first place. UDP simply sends the data packets and forget it, while TCP sends data packets and remembers it, verifies it and re sends it if any errors. Now some applications or services which does not require re sending data packets, where re transmission of data does not make any sense, that’s where UDP should be used.
Where do the re transmission of data packets does not make sense? Think about it, get some load on your brain. Video conferences. If in between the video conference there might be an error and no voice or video got transmitted. By the time you realize some packets were lost, the conversation has already moved on, and re-transmitting those packets. So implementing video conference functionality should be in UDP protocol.
One example which will rest the case for this is live gaming. See, game it self has different functionalities, which TCP oriented obviously. But the actual game when it starts, it runs on UDP. Before that like creating game room, joining all that is TCP stuff. You are in free fire game, your connection of internet got weak. But still you will be playing, you are killing someone and you are firing here and there, this data is not actually received by the game server. That’s why this data - means your activity of player is not visible or impacting the game, now does it make sense to re transmit this data again when your connection get stable? No, because if so you have killed many players, you fired here and there, whole game flow is now corrupted. So when you use UDP here, it make perfectly sense, that you continue where you left without worrying about the data you sent - actions you did - while in weak connection which didn’t get sent - action actually didn’t happen in game.
So the for both transmission protocol, data packets would be different. And also the connection establishment. When you join a Zoom meeting, there is an initial connection process that sets up the session. This often involves TCP to manage the login, authentication, and setup process (e.g., establishing a secure connection with the Zoom servers). Once you're in the meeting, the actual audio and video data will be transmitted using UDP.
UDP packet:
It contains the UDP header and data. Header is of 8 bytes: 64 bits. At this moment do not forget, we are still in the Transport layer. IP of server fetched by DNS is not wrapped in any packet yet. At this moment we have only UDP/TCP packets which only knows the ports and the data. Source port destination port length and checksum, that’s pretty much self explanatory I think. See, checksum is still. UDP also knows that. But it simply does not care about it being correct or wrong. Data can be of variable size like 1500 bits or something.
Now see the TCP data packet:
Besides, source port, destination port, checksum, window size, we have other fields which are for either connection establishment or identifying and resolving errors of data transmission for re-transmitting. Three way handshake process happens before actual transmission process get started. Flags here in diagram represents that. SYN ACK flags. It has also sequence number and acknowledgment numbers. While reading below process, please do not confuse the ACK flag and acknowledgment number both are different things
1.…Client sends TCP segment to server which has SYN flag to set, and sequence number with value x, server receives that.
2.… it set SYN and ACK flag to set. It also set it’s sequence number to y, and acknowledgement number to x+1, x is received sequence number from client. Now server sends this segment to client
3.… client receives both SYN & ACK flag as set, and sequence number y. client set it’s acknowledgement number y+1 and sends back to server. So now connection is established.
Quickly, what happened till now,
For client: data got encrypted, server IP determined by DNS, data divided into segments, each data segments got wrapped with TCP or UDP header with details like ports, sequence number etc.
For server: data reached to the server, re-assembled, it got to port mentioned in header, and handed over to application layer, and again response to client which client received in same way as server received.
between this process there is gap, which is process of networking and physical transmission, which will be covered in next article: Network layer and Link layer. Completing the series
Subscribe to my newsletter
Read articles from Danish Khan directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Danish Khan
Danish Khan
I'm a backend devloper using python, django as my stack. I also have beginner level skills in DevOps like Linux, Virtual machines, OS, networking. Right now learning and expanding skills in DevOps