Chapter 5 Transport Layer

1. Overview of the transport layer

• The physical layer , data link layer , and network layer in the computer network architecture introduced in the previous courses jointly solve the problems faced by interconnecting hosts through heterogeneous networks and realize host-to-host communication.

• But the real entities that actually communicate in a computer network are the processes in the hosts at both ends of the communication.

• How to provide direct communication services for application processes running on different hosts is the task of the transport layer, and the transport layer protocol is also called an end-to-end protocol.

The transport layer directly provides services for logical communication between application processes

The transport layer shields the high-level users from the details of the underlying network core (such as network topology, routing protocol adopted, etc.), which makes the application process see as if there is an end-to-end logical communication between two transport layer entities channel.

According to different application requirements, the transport layer of the Internet provides two different transport protocols for the application layer, namely connection-oriented TCP and connectionless UDP. These two protocols are the main contents to be discussed in this chapter.

2. The concept of transport layer port number, multiplexing and demultiplexing

• Processes running on a computer are identified by a process identifier PID .

• Computers on the Internet do not use a unified operating system, and different operating systems (windows, Linux, Mac OS) use process identifiers in different formats .

• In order to enable network communication between application processes of computers running different operating systems, a unified method must be used to identify the application processes of the TCP/IP system.

• The transport layer of the TCP/IP system uses port numbers to distinguish different application processes in the application layer.

  • The port number is represented by 16 bits, and the value range is 0~65535;
  • Familiar port numbers: 0~1023, IANA assigns these port numbers to some of the most important application protocols in the TCP/IP system, for example: FTP uses 21/20, HTTP uses 80, and DNS uses 53.
  • Registered port numbers: 1024~49151, used by applications without well-known port numbers. The use of such port numbers must be registered in IANA in accordance with the prescribed procedures to prevent duplication. Example: Microsoft RDP Microsoft Remote Desktop uses port 3389.
  • Temporary port number: 49152~65535, reserved for the client process to choose to use temporarily. When the server process receives the message from the client process, it knows the dynamic port number used by the client process. After the communication is over, this port number can be used by other client processes later.
  • The port number has only local significance , that is, the port number is only used to identify the processes in the application layer of the computer . In the Internet, the same port number in different computers is not related.

Multiplexing at the sender and demultiplexing at the receiver

• The well-known port number of the transport layer used by the common protocols of the application layer of the TCP/IP system

3. Comparison between UDP and TCP

UDP supports unicast, multicast, and broadcast

TCP only supports unicast

UDP is application-oriented

TCP is byte stream oriented

UDP provides connectionless and unreliable transmission services to the upper layer (suitable for real-time applications such as IP telephony and video conferencing)

TCP provides connection-oriented reliable transmission services to the upper layer (suitable for applications requiring reliable transmission, such as file transmission)

4. TCP flow control

• In general, we always want data to be transferred faster.

  • But if the sender sends the data too fast, the receiver may not have time to receive it, which will cause data loss.

• The so-called flow control (flow control) is to make the sender's sending rate not too fast, so that the receiver has time to receive.

• The flow control of the sender can be easily implemented on the TCP connection by using the sliding window mechanism.

[[2010 Question 39] A TCP connection is established between host A and host B, and the maximum TCP segment length is 1000 bytes. If the current congestion window of host A is 4000 bytes, after host A sends two maximum segments consecutively to host B, it successfully receives the acknowledgment segment of the first segment sent by host B, and the receiving window size announced in the acknowledgment segment is 2000 bytes, then the maximum number of bytes that host A can send to host B at this time is A
A.1000
B.2000
C.3000
D.4000

【Analysis】

The sending window of the TCP sender = min[self congestion window, the receiving window of the TCP receiver]

The topic does not give the initial value of the sending window of the TCP sender, then take the congestion window value as the sending window value

5. TCP congestion control

• In a certain period of time, if the demand for a resource in the network exceeds the available part that the resource can provide, the network performance will deteriorate. This situation is called congestion.

  • Link capacity (that is, bandwidth) in a computer network, caches and processors in switching nodes, etc., are all resources of the network.

• If congestion occurs and is not controlled, the throughput of the entire network will decrease as the input load increases.

The basic principles of these four congestion control algorithms are introduced below, assuming the following conditions:

1. Data is sent in one direction, and only acknowledgments are sent in the other direction.
2. The receiver always has enough buffer space, so the size of the sending window of the sender is determined by the congestion level of the network.
3. The unit of discussion is the number of the maximum message segment MSS, not bytes.

5.1 Slow start and congestion avoidance

• The sender maintains a state variable called the congestion window cwnd, whose value depends on the degree of network congestion and changes dynamically.

  • The maintenance principle of the congestion window cwnd: as long as there is no congestion in the network, the congestion window will increase; but as long as the network is congested, the congestion window will decrease.
  • The basis for judging the occurrence of network congestion: the acknowledgment message that should have arrived was not received on time (that is, a timeout retransmission occurred).

• The sender takes the congestion window as the sending window swnd, ie swnd = cwnd.

• Maintain a slow start threshold ssthresh state variable:

  • When cwnd < ssthresh, use the slow start algorithm;
  • When cwnd > ssthresh, stop using the slow start algorithm and use the congestion avoidance algorithm instead;
  • When cwnd = ssthresh, either the slow start algorithm or the congestion avoidance algorithm can be used.

retransmission timer expired

Judging that the network is likely to be congested, perform the following work:

• Update the ssthresh value to half of the cwnd value when congestion occurs;

• Decrease the cwnd value to 1 and restart the slow start algorithm.

"Slow start" means that there are few segments injected into the network at the beginning, and it does not mean that the congestion window cwnd grows slowly;

"Congestion avoidance" does not mean that congestion can be completely avoided, but that the congestion window is controlled to grow linearly during the congestion avoidance phase, making the network less prone to congestion;

5.2 Fast retransmission and fast recovery

• The slow start and congestion avoidance algorithm is the TCP congestion control algorithm (TCP Tahoe version) proposed in 1988.

• In 1990, two new congestion control algorithms were added (to improve the performance of TCP), which are fast retransmission and fast recovery (TCP Reno version).

  • Occasionally, individual segments are lost in the network, but the network is not actually congested.
    • This will cause the sender to retransmit overtime and mistakenly believe that the network is congested;
    • The sender sets the congestion window cwnd to the minimum value 1, and starts the slow start algorithm by mistake, thus reducing the transmission efficiency.

• The use of the fast retransmission algorithm allows the sender to know the loss of individual message segments as early as possible.

• The so-called fast retransmission is to make the sender retransmit as soon as possible, instead of waiting for the timeout retransmission timer to expire before retransmitting.

  • The receiver is required not to wait for the piggyback confirmation when it sends the data, but to send the confirmation immediately;
  • Even if an out-of-sequence segment is received, a duplicate acknowledgment of the received segment should be issued immediately;
  • Once the sender receives 3 consecutive duplicate acknowledgments, it retransmits the corresponding message segment immediately instead of waiting for the timeout retransmission timer of the message segment to expire before retransmitting.
  • For individual lost segments, the sender will not retransmit overtime, and will not mistakenly believe that there is congestion (and then reduce the congestion window cwnd to 1). Using fast retransmission can increase the throughput of the entire network by about 20%.

• Once the sender receives 3 repeated acknowledgments, it knows that only individual segments are lost. So the slow start algorithm is not started, but the fast recovery algorithm is executed;
  • The sender adjusts the slow start threshold ssthresh value and the congestion window cwnd value to half of the current window; starts to execute the congestion avoidance algorithm.
  • Some fast recovery implementations increase the value of the congestion window cwnd at the beginning of the fast recovery, which is equal to the new = ssthresh + 3.
    • Since the sender has received 3 repeated acknowledgments, it means that 3 data segments have left the network;
    • These three message segments no longer consume network resources but stay in the receiving buffer of the receiver;
    • It can be seen that instead of accumulating message segments in the network, 3 message segments have been reduced. Therefore, the congestion window can be expanded appropriately.

[2009 Question 39] A TCP connection always sends TCP segments with a maximum segment length of 1KB. The sender has enough data to send. When a timeout occurs when the congestion window is 16KB, if the transmission of the TCP segments within the next 4 RTTs (round trip time) is successful, then when all the TCP segments sent within the 4th RTT time get a positive response , the congestion window size is C
A.7KB
B.8KB
C.9KB
D.16KB

6. Selection of TCP timeout retransmission time

• You cannot directly use the RTT sample obtained from a certain measurement to calculate the timeout retransmission time RTO.

• Using the RTT samples obtained from each measurement, weighted average round-trip times RTTs (also known as smoothed round-trip times) are calculated.

• The weighted average round-trip time RTTs obtained in this way are smoother than the measured RTT values.

• Obviously, the overtime retransmission time RTO should be slightly greater than the weighted average round-trip time RTTs.

7. Realization of TCP reliable transmission

• TCP is based on a sliding window in bytes to achieve reliable transmission

• Although the sender's send window is set according to the receiver's receive window, at the same time, the sender's send window is not always as large as the receiver's receive window.

  • The network transmission window value needs to experience a certain time lag, and this time is still uncertain.
  • The sender may also appropriately reduce the size of its sending window according to the congestion situation of the network at that time.

• TCP does not clearly stipulate how to deal with data that arrives out of order.

  • If the receiver discards the data that arrives out of order, then the management of the receiving window will be relatively simple, but this is not good for the utilization of network resources, because the sender will repeatedly transmit more data.

  • TCP usually temporarily stores the data that arrives out of order in the receiving window first, and then delivers the data to the upper layer application process in sequence after receiving the missing bytes in the byte stream.

• TCP requires the receiver to have cumulative acknowledgment and piggyback acknowledgment mechanisms, which can reduce transmission overhead. The receiver can send a confirmation at an appropriate time, or send the confirmation message along with it when it has data to send.

  • The receiver should not delay sending the acknowledgment too much, otherwise it will cause the sender to retransmit unnecessary timeouts, which in turn wastes network resources. The TCP standard stipulates that the confirmation delay should not exceed 0.5 seconds. If a sequence of segments with a maximum length is received, an acknowledgment MUST be sent for every other segment [RFC 1122].
  • Piggybacking doesn't actually happen very often, since most applications rarely send data in both directions at the same time.

• TCP communication is full-duplex communication. Each party in the communication is sending and receiving segments. Therefore, each side has its own send window and receive window. When it comes to these windows, be sure to figure out which side's window it is.

[2009 Question 38] A TCP connection has been established between Host A and Host B. Host A sent two consecutive TCP segments to Host B, containing 300 bytes and 500 bytes of payload respectively. The first segment The serial number is 200. After host B receives two segments correctly, the confirmation serial number sent to host A is D
A.500
B.700
c.800
D.1000

[2011 Question 40] A TCP connection has been established between Host A and Host B. Host A sent 3 consecutive TCP segments to Host B, containing payloads of 300 bytes, 400 bytes, and 500 bytes respectively. The sequence number of the third segment is 900. If host B only receives the first and third segments correctly, the confirmation sequence number sent by host B to host A is B
A.300
B.500
C.1200
D.1400

8. TCP transport connection management

8.1 TCP connection establishment

• TCP is a connection-oriented protocol, which transmits TCP segments based on transport connections.

• The establishment and release of a TCP transport connection is an essential process in every connection-oriented communication.

• A TCP transport connection has the following three phases:

  1. Establish a TCP connection
  2. data transmission
  3. release TCP connection

• TCP's transport connection management is to enable the establishment and release of transport connections to proceed normally.

• The TCP connection establishment needs to solve the following three problems:

  1. Enable both TCP parties to know the existence of each other;
  2. Enable both TCP parties to negotiate some parameters (such as the maximum window value, whether to use window expansion options and timestamp options, and quality of service, etc.);
  3. Enables both TCP parties to allocate transport entity resources (such as buffer size, entries in the connection table, etc.).

TCP uses a "three-message handshake" to establish a connection

[2011 Question 39] Host A sends a TCP segment (SYN=1, seq=11220) to Host B, expecting to establish a TCP connection with Host B, if Host B accepts the connection request, then Host B sends to Host A The correct TCP segment might be C
A.(SYN=0, ACK=0, seq=11221, ack=11221)
B.(SYN=1,ACK=1, seq=11220, ack=11220)
C.(SYN= 1, ACK=1, seq=11221, ack=11221)
D. (SYN=O, ACK=0, seq=11220, ack=11220)

8.2 TCP connection release

9. The header format of the TCP segment

• In order to achieve reliable transmission, TCP adopts a byte stream-oriented approach.

• However, when TCP sends data, it takes some or all bytes from the sending buffer and adds a header to it to make it a TCP segment before sending it.

  • A TCP segment consists of two parts: header and data payload;
  • All the functions of TCP are reflected in the role of each field in its header.

Source port: occupies 16 bits, writes the source port number, and is used to identify the application process that sends the TCP segment.

Destination port: occupies 16 bits, writes the destination port number, and is used to identify the application process that receives the TCP segment.

Serial number: occupying 32 bits, the value range is [0,232-1]. After the serial number increases to the last one, the next serial number returns to 0. Indicates the sequence number of the first byte of the data payload of this TCP segment.

Confirmation number: occupies 32 bits, and the value range is [0,22-1]. After the confirmation number increases to the last one, the next confirmation number will return to 0. Indicates the sequence number of the first byte of the data load expected to be received by the other party's next TCP segment, and is also an acknowledgment of all previously received data. If the confirmation number = n, it means that all the data up to the sequence number n-1 have been received correctly, and it is expected to receive the data with the sequence number n.

Confirmation flag bit ACK: the confirmation number field is valid only when the value is 1; the confirmation number field is invalid when the value is 0. TCP stipulates that after the connection is established, all transmitted TCP segments must set ACK to 1.

Data offset: occupies 4 bits and takes 4 bytes as the unit. It is used to indicate how far the beginning of the data payload part of the TCP segment is from the beginning of the TCP segment. This field actually indicates the header length of the TCP segment.
The fixed length of the header is 20 bytes, so the minimum value of the data offset field is (0101)2 The maximum length of the header is 60 bytes, so the maximum value of the data offset field is (1111)2

Reserved: occupying 6 bits, reserved for future use, but should be set to 0 at present.

Window: occupies 16 bits, in bytes. Indicates the receiving window of the party sending this segment. The window value serves as the basis for the receiver to let the sender set its sending window. This is to control the sending ability of the sender by the receiving ability of the receiver, which is called flow control.

Synchronization flag SYN: Used to synchronize the serial number when the TCP connection is established.

Termination flag FIN: used to release the TCP connection.

Reset flag RST: used to reset the TCP connection. When RST=1, it indicates that the TCP connection is abnormal, and the connection must be released and then re-established. Setting RST to 1 is also used to reject an illegal segment or refuse to open a TCP connection.

Push flag bit PSH: The receiver's TCP will hand over the segment to the application process as soon as possible after receiving the segment with the flag bit set to 1, instead of waiting until the receiving buffer is full before delivering it.

Urgent flag bit URG: when the value is 1, the urgent pointer field is valid; when the value is 0, the urgent pointer field is invalid.

Urgent pointer: occupying 16 bits, in bytes, used to indicate the length of urgent data. When the sender has urgent data, the urgent data can be queued to the front of the sending buffer, and immediately encapsulated into a TCP segment for sending. The urgent pointer will indicate how long the urgent data contains in the data payload of this message segment, and the ordinary data follows the urgent data.

Padding: Since the length of the option is variable, padding is used to ensure that the header of the message segment can be divisible by 4 (because the data offset field, that is, the header length field, is in units of 4 bytes).

reference:

5.9 The header format of a TCP segment_哔哩哔哩_bilibili