The transport layer6 min read networking
Following up on my “Computer networking: a top down approach” summaries, this blog entry will be about the transport layer. Hope you like it!
The transport layer is the layer that sits in the middle of the network layer (where IP addresses live) and the application layer, which we discussed in the previous post. The transport layer gets a message from the application layer through its socket API and encapsulates it into a segment.
The transport layer provides logical communication between processes while the network layer provides logical communication between hosts. This means that the transport layer is in charge of distinguishing from whom the application message that is being delivered belongs (say, port 80 in that host) and the network layer is in charge of distinguishing who in the network that packet belongs to.
Intro to TCP and UDP:
TCP and UDP are the main protocols at the transport layer. Depending on which protocol we use, we can get assured delivery of messages or not. Under the transport protocol is the network protocol which mainly uses IP addresses to deliver packets to end hosts. IP is a best-effort protocol, which means it will try to deliver a packet but is not guaranteed. This is similar to UDP in the way that is not connection-oriented, it can deliver out of order packets, and doesn’t guarantee the integrity of segments.
UDP and TCP provide integrity checking by including error detection fields in the header of the segment and data delivery from process to processes. These are the only two services that UDP provides, while TCP also provides congestion control and reliable data transfer.
Multiplexing and demultiplexing:
When a segment arrives at a host, the transport layer will check the destination port number to deliver the data to the correct socket listening on that port. The process of taking the segment, checking it and passing it to the right socket is called demultiplexing.
The process of getting different chunks of data from the sockets layer, creating a segment by adding a header with information (source and destination ports) and moving that segment downwards to the network layer is called multiplexing.
TCP and UDP require special fields to be able to handle segments, these are source port number and destination port number. The port numbers can be:
- Well-known port numbers: used by applications, such as HTTP (80). They go from 0-1023
- Ephemeral ports: range from 1023 to 65535
These port will be used by the socket layer in order to identify the process that is running there. Each process will have a different port number. When a segment arrives at the host, the transport layer will check the destination port number and based on that will move the segment to the correct process (the one that’s using that port).
A UDP header is 8bytes in size, each of the fields is 2 bytes. The source port and destination port are used for the end host to be able to perform demultiplexing, whereas the checksum is a way to check data integrity at the end-host. The checksum will be checked at the end host and this host will know if the data was altered (noise in the link or while stored inside a router).
The application data (message) is what is received from the application layer through the socket layer. This is generally called the payload. Here’s what a UDP segment looks like:
TCP is said to be connection-oriented because first we need to have a 3-way handshake done before sending data over the channel.
The maximum amount of data that can be encapsulated from the application layer messages into a segment is called the maximum segment size (MSS). The MSS is set by first doing a calculation of the MTU of the local host. This way, we ensure that when the packet (in layer 3) reaches layer 2 to be encapsulated it will fit into a single link-layer frame.
Consists of header fields and data fields. The data field will be filled with application layer data. The MSS comes into play here to control the amount of data that can be fitted into the segment. If the data is too big, TCP will break it into smaller chunks of the size of the MSS.
The fields in the TCP segment are as below:
- The source and destination ports, used for multiplexing/demultiplexing.
- The checksum, to check data integrity at the end host.
- A 4bytes seq number and 4bytes ack number, which is used by the TCP sender and receiver to implement a reliable data transfer and know which segments could be missing.
- A 2bytes receive window, which is used by the receiver to control how much data it can accept.
- A 4-bit header length, which shows the length of the header
- An options field, which is used by sender and receiver to negotiate the MSS for the session.
- The flag field, which has 6 bits. Here we can find the ACK, SYN, FIN and RST flags, each 1 bit in size.
TCP sequence numbers and acknowledgment numbers:
For each segments the sender host sends, it will place in the sequence field the last byte of the segment that has been sent. For example, if host A sends bytes from 0 to 500 of a 5000 bytes data, then it will place a 500 as the sequence number. Then, host B will send an ack with 501 number, which indicates that it has received bytes 0 to 500 and it is waiting for bytes 501 onwards.
What happens if bytes 0-500 get to the host, then 501-1000 don’t and then 1001-1500 do? On this case, host B will send a segment with an ack number of 501, which means that it has received up until that specific point of bytes. Developers now have two options:
- Drop the 1001-1500 bytes of the data that did reach.
- Save the 1001-1500 bytes and wait for the retransmission of the missing information.
The second option is used regularly, this allows to save network resources and is more efficient.
On regular operations, the sequence number will be the first byte in the data field. So if the data is a 1000 bytes and a segment contains byte 50 up to 70, the sequence number of that segment will be 50. The acknowledgment number will then be the last byte of the segment plus 1, on this case 71 will let host A know that host B has received all bytes from 50 to 70 and is waiting for 71 and up.
TCP flow control:
TCP implements flow control in a way that the sender knows when it has to send less data or when it can send more data. Each host will have a send and receive buffer. At the end host, the receive buffer will be where the segments are stored each time one is received and the host is reading another. By using the receive window field in the TCP segment, the receiver can set the amount of buffer it still has available. This lets the sender host know how many data it can send before it overflows the buffer. This will be variable as the free space could change in time, meaning at some points we may see the both applications sending lots of information and if the buffer starts filling then the segments being sent could start being less, then more, then less…
Source of the information: Computer Networking, a top down approach by James F. Kurose, Keith W. Ross.