Reference tutorial: 5.6 Selection of TCP timeout retransmission time_bilibili_bilibili
6. Selection of TCP timeout retransmission time
1. Calculate the timeout retransmission time based on RTT samples
(1) As shown in the figure below, assume that hosts A and B are two hosts on the Internet. A TCP connection has been established between them. The ordinate is time.
(2) Host A sends TCP data segment 0 to host B and records the current time. After receiving it, host B sends the corresponding confirmation message segment to host A. After receiving the confirmation message segment, host A records the current time. The difference between the two times recorded by host A is the round-trip time RTT of the message segment.
(3) If the value of the timeout retransmission time RTO is set smaller than RTT0 (the round-trip time of segment 0), it will cause unnecessary retransmission of the segment and increase the network load; if the timeout retransmission is set, Setting the value of time RTO much larger than RTT0 will delay retransmission for too long, increase the idle time of the network, and reduce transmission efficiency.
(4) The value of the timeout retransmission time RTO should be set to a value slightly larger than the round-trip time RTT of the message segment. However, the lower layer of TCP is a complex Internet environment. The message segment sent by host A may only pass through a high-speed LAN. It may also pass through multiple low-rate networks, and the forwarding route of each IP datagram may be different.
(5) As shown in the figure below, host A now sends TCP data segment 1 to host B. After receiving it, host B sends the corresponding confirmation segment to host A. The round-trip time of the segment measured by host A this time is RTT1. Obviously, RTT1 is much larger than RTT0. If the retransmission timeout RTO is still slightly larger than RTT0 as determined before, this is inappropriate for data segment 1 and will cause unnecessary retransmission of the segment.
(6) It can be seen that the RTT sample obtained from a certain measurement cannot be directly used to calculate the timeout retransmission time RTO , but the RTT sample obtained from each measurement can be used to calculate the weighted average round-trip time (also known as the smoothed round-trip time).
① When the first RTT sample is measured, the value of is directly taken as the value of the first RTT sample. Every time a RTT sample is measured in the future, a new
value is calculated according to the formula shown in the figure below.
②The weighted average round-trip time RTTS obtained by this method is smoother than the measured RTT value.
③Obviously, the timeout retransmission time RTO should be slightly larger than the weighted average round trip time .
(7) RFC6298 recommends using the following formula to calculate the timeout retransmission time RTO:
2. The measurement of round trip time RTT is relatively complicated.
(1) As shown in the figure below, host A sends a TCP data segment to host B, but the segment is lost during transmission. When the retransmission timer times out, host A retransmits the segment. . After receiving the data segment, host B sends a confirmation segment to host A.
① After receiving the confirmation segment, host A cannot determine whether it is an acknowledgment of the original segment or a retransmission segment.
② This message segment is actually a confirmation of the retransmitted message segment, but if host A mistakenly regards this confirmation as a confirmation of the original message segment, the calculated RTTS and RTO will be too large, reducing improve transmission efficiency.
(2) As shown in the figure below, host A sends a TCP data segment to host B. After receiving the data segment, host B sends a confirmation message segment to host A. However, for some reason, the confirmation message segment does not Reaching host A within the normal time will inevitably cause host A to timeout and retransmit the previously sent data segment.
① After receiving the late acknowledgment segment, host A cannot determine whether the segment is an acknowledgment of the original segment or a retransmission segment.
② This message segment is actually a confirmation of the original message segment, but if host A mistakenly regards this confirmation as a confirmation of the retransmitted message segment, the calculated RTTS and RTO will be too small. This It will cause unnecessary retransmission of message segments and increase the network load.
(3) When the sender times out and retransmits, when receiving the confirmation segment, it will be unable to determine whether the segment is a confirmation of the original segment or a confirmation of the retransmission segment, that is, it cannot be accurately measured. RTT, and thus cannot correctly calculate the timeout retransmission time RTO.
(4) In response to the problem that the round-trip time RTT cannot be accurately measured when timeout retransmission occurs , Karn proposed an algorithm: when calculating the weighted average round-trip time RTT s , as long as the message segment is retransmitted, its round-trip time RTT sample will not be used , that is, when a retransmission occurs, the RTT will not be recalculated, and the timeout retransmission time RTO will not be recalculated.
① However, the algorithm proposed by Karn has caused new problems: If the delay of the message segment suddenly increases a lot, and this delay will remain for a long time, then within the original retransmission time, The acknowledgment message segment will not be received, so the message segment will be retransmitted. However, according to the Karn algorithm, the round-trip time sample of the retransmitted message segment is not considered. In this way, the timeout retransmission time cannot be updated, which will cause the message Segments are repeatedly retransmitted.
② Therefore, the Karn algorithm needs to be modified: every time a message segment is retransmitted, the timeout retransmission time RTO is increased . A typical approach is to set the new RTO value to twice the old RTO value.
3. Calculation example of TCP timeout retransmission time
7. Implementation of TCP reliable transmission
1. Examples of TCP achieving reliable transmission
(1) The figure below shows two hosts on the Internet. A TCP connection has been established between them. It is assumed that data transmission is only carried out in one direction, and it is assumed that there is no congestion problem in the network.
(2) TCP’s sliding window is measured in bytes . The figure below shows the sequence number of the data bytes to be sent by the sender.
(3) Assume that the sender receives a confirmation segment from the receiver:
①The value of the window field rwnd in the header of the message segment is 20, which means that the receiver indicates that the size of its receiving window is 20 bytes; the value of the confirmation number field ack is 31, which indicates that the receiver hopes to receive the next The sequence number of the data is 31, and all data up to sequence number 30 have been received correctly.
②The sender constructs its own sending window based on the values of these two fields , sets its own sending window size to 20, and moves it to sequence numbers 31~50.
(4) If the sender does not receive confirmation from the receiver, it can send all the data in the sending window in sequence. All data that has been sent must be temporarily retained before receiving the confirmation so that it can be processed after timeout. Used when retransmitting.
①The back part of the trailing edge of the sending window is the sequence number of the data bytes that have been sent and received confirmation . These data bytes obviously no longer need to be stored in the sending buffer and can be deleted. There are two possibilities for the movement of the trailing edge of the sending window:
[1] No new confirmation is received, and the trailing edge of the sending window does not move.
[2] When a new confirmation is received, the trailing edge of the sending window moves forward.
②The front part of the leading edge of the sending window is the sequence number of the data bytes that are currently not allowed to be sent . There are four possibilities for the movement of the sending window front edge:
[1] Normally, the front edge of the sending window is constantly moving forward.
[2] If no new confirmation is received, the window size of the other party's notification does not change, and the frontier does not move forward.
[3] A new confirmation is received, but the window of the other party's notification is reduced, just so that the front edge of the sending window does not move.
[4] The window for notification from the other party shrinks, and the front edge of the sending window may shrink backwards. (TCP standard strongly does not support this case)
(5) Now assume that the sender encapsulates the data with serial numbers 31~41 in the sending window and sends it in several different message segments. At this time, the position of the sending window has not changed, and the data with serial numbers 31~41 in the sending window has been Sent but no confirmation received, and data with serial numbers 42 to 50 are allowed to be sent but have not yet been sent.
(6) If you want to program the sliding window mechanism, for marking and maintaining the status of the sending window, you can use three pointers P1, P2, and P3 to point to the corresponding byte serial numbers respectively :
①The part less than P1 is the part that has been sent and confirmed .
②Anything greater than or equal to P3 is not allowed to be sent .
③ P3-P1 is the size of the sending window .
④ P2-P1 can determine the number of bytes that have been sent but have not yet received confirmation .
⑤ P3-P2 can obtain the number of bytes that are allowed to be sent but have not yet been sent .
(7) The size of the receiver window is currently 20. The data outside the receiving window until the 30th is the data that has been sent corresponding confirmation and delivered to the application process. Therefore, there is no need to retain these data and they can be removed from the receiving cache. has been deleted; data No. 31~50 within the receiving window is allowed to be received; data No. 51 and its subsequent data outside the receiving window are currently not allowed to be received.
(8) Then the message segments encapsulated with data No. 32 and No. 33 previously sent by the sender arrive at the receiver. Since the data sequence numbers fall within the receive window, the receiver receives them and stores them in the receive buffer, but They are data that arrived out of sequence because data No. 31 has not arrived yet (data No. 31 may be lost or may still be stuck in other networks).
(9) Since the receiver can only confirm the highest sequence number in the data received in sequence , the confirmation sequence number in the confirmation message segment sent by the receiver is still 31, that is, it hopes to receive data No. 31; window The value of the field is still 20, indicating that the receiver has not changed the size of its receiving window.
(10) After the sender receives the confirmation message segment and finds that it is a duplicate confirmation for data No. 31, it knows that the receiver has received data that arrived out of sequence. Since this is the first duplicate confirmation for data No. 31, this will not cause the sender to quickly retransmit the data. In addition, the window size notified by the receiver is still 20, so the sender still keeps its sending window size at 20.
(11) Now assume that the message segment encapsulated with data No. 31 arrives at the receiver. The receiver receives the message segment and stores the encapsulated data No. 31 in the receiving cache. The receiver can now store the received data 31~33. The data is delivered to the application process, then the receiving window is moved forward by 3 sequence numbers, and a confirmation message segment is sent to the sender.
(12) The receiver sends a confirmation message segment, in which the confirmation sequence number is 34, which indicates that the receiver has received all data up to sequence number 33, and now hopes to receive data number 34; the value of the window field is still 20, indicating that the receiver The size of the receiving window is not changed.
(13) Now assume that several more data message segments arrive at the receiver. They are encapsulated with data No. 37, 38 and 40. Although the sequence numbers of these data fall within the receiving window, they are all data that arrive out of sequence. , can only be temporarily stored in the receive cache first.
(14) Then the confirmation message segment (ack=34) previously sent by the receiver arrives at the sender. After receiving it, the sender slides the sending window forward by 3 sequence numbers, and the size of the sending window remains unchanged, so that there is a new sequence number. 51~53 falls into the sending window, and sequence numbers 31~33 move out of the sending window. Now the data No. 31~33 can be deleted from the sending buffer, because the recipient's confirmation for them has been received.
(15) The sender continues to encapsulate the data with sequence numbers 42 to 53 in the sending window in several different message segments and sends them out. Now the sequence numbers in the sending window have been used up, and the sender has not received confirmation from the receiver. In this case, no new data can be sent; if the sent data whose sequence number falls within the sending window is not received for a long time, a timeout will occur and retransmission will occur .
2. Things to note when implementing reliable transmission with TCP
(1) Although the sender's sending window is set according to the receiver's receiving window, at the same moment, the sender's sending window is not always as large as the receiver's receiving window .
① This is because the network transmission window value needs to experience a certain time lag, and this time is still uncertain.
② In addition, the sender may also appropriately reduce the size of its sending window according to the current congestion situation of the network.
(2) TCP has no clear regulations on how to handle data that arrives out of order .
① If the receiver discards all data that arrives out of order, the management of the receiving window will be simpler, but this will be detrimental to the utilization of network resources because the sender will repeatedly transmit more data.
②TCP usually temporarily stores data arriving out of order in the receiving window, and then delivers it to the upper-layer application process in order after the missing bytes in the byte stream are received .
(3) TCP requires the receiver to have cumulative acknowledgment and piggyback acknowledgment mechanisms , which can reduce transmission overhead. The receiver can send a confirmation at the appropriate time, or it can send the confirmation information along when it has data to send.
① The receiver should not delay sending the confirmation too much , otherwise it will cause the sender to needlessly time out and retransmit, which in turn wastes network resources. The TCP standard stipulates that the acknowledgment delay should not exceed 0.5 seconds. If a series of segments with the maximum length is received, an acknowledgment must be sent for every other segment [RFC 11221].
②Piggy acknowledgment actually doesn't happen very often because most applications rarely send data in both directions at the same time.
(4) TCP communication is full-duplex communication . Each party in the communication is sending and receiving message segments. Therefore, each party has its own sending window and receiving window. When talking about these windows, be sure to understand Make it clear whose window it is.
8. TCP transport connection management
1. Overview of TCP transport connection management
(1) TCP is a connection-oriented protocol that transmits TCP segments based on transport connections.
(2) The establishment and release of TCP transport connections is an essential process in every connection-oriented communication.
(3) TCP transport connection has the following three stages:
①Establish a TCP connection , that is, establish a TCP connection through the "three-message handshake". (The process of establishing a TCP connection is compared to a "handshake")
②Data transmission , that is, reliable data transmission based on the established TCP connection.
③ Release the connection , that is, release the TCP connection through "four message waving" after the data transmission is completed. (Compare the process of TCP releasing the connection to "waving hands")
(4) TCP's transport connection management is to ensure that the establishment and release of transport connections can proceed normally.
2. TCP connection establishment
(1) TCP connection establishment must solve the following three problems:
①Enable both TCP parties to know the existence of the other party.
② Enable TCP parties to negotiate some parameters (such as the maximum window value, whether to use window expansion options and time cutoff options, and quality of service, etc.).
③Enable TCP parties to allocate transportation entity resources (such as cache size, items in the connection table, etc.).
(2) The specific process of TCP using the "three-message handshake" to establish a connection:
① The figure below shows two hosts that need to communicate based on TCP. An application process in one host actively initiates the establishment of a TCP connection . This process is called a TCP client . The other host passively waits for the establishment of a TCP connection. The application process is called a TCP server . The "handshake" (i.e. establishing a TCP connection) requires the exchange of three TCP segments between the TCP client and the TCP server .
②Initially, the TCP processes at both ends are closed. At the beginning, the TCP server process first creates a transmission control block to store some important information in the TCP connection, such as the TCP connection table, pointers to the send and receive buffers, pointers to the retransmission queue, current send and receive sequence numbers, etc. After that, the TCP server process enters the listening state, waiting for the connection request from the TCP client process . The TCP server process passively waits for the connection request from the TCP client process instead of actively initiating it, so it is called passively opening the connection .
③ The TCP client process also first creates a transmission control block , and then sends a TCP connection request segment to the TCP server process when intending to establish a TCP connection , and enters the synchronized sent state . The synchronization bit SYN in the header of the TCP connection request segment is set to 1 , indicating that this is a TCP connection request segment; the sequence number field seq is set to an initial value x , as the initial sequence number selected by the TCP client process ( TCP It is stipulated that the message segment with SYN set to 1 cannot carry data, but a sequence number will be consumed ). Since TCP connection establishment is initiated by the TCP client, it is called actively opening the connection .
④ After the TCP server process receives the TCP connection request segment , if it agrees to establish a connection, it sends a TCP connection request confirmation segment to the TCP client process and enters the synchronized received state . The synchronization bit SYN and the confirmation bit ACK in the header of the TCP connection request confirmation message segment are both set to 1 , indicating that this is a TCP connection request confirmation message segment; the sequence number field seq is set to an initial value y , as the TCP server process The selected initial sequence number ; the value of the confirmation number field ack is set to x+1 , which is a confirmation of the initial sequence number selected by the TCP client process ( since SYN is set to 1, this segment cannot carry data. A serial number is consumed at the same time ).
⑤ After the TCP client process receives the TCP connection request confirmation message segment , it also sends an ordinary TCP confirmation message segment to the TCP server process and enters the connection established state . The acknowledgment bit ACK in the header of the TCP acknowledgment message segment is set to 1 , indicating that this is an ordinary TCP acknowledgment message segment; the sequence number field seq is set to x+1 , because the first TCP sent by the TCP client process The sequence number of the message segment is x and does not carry data, so the sequence number of the second message segment is x+1 ; the confirmation number field ack is set to y+1 , which is the initial sequence number selected by the TCP server process Acknowledgment ( TCP stipulates that ordinary TCP acknowledgment message segments can carry data, but if they do not carry data, the sequence number is not consumed. In this case, the sequence number of the next data segment sent is still x+1 ).
⑥ The TCP server process also enters the connection established state after receiving the ordinary TCP confirmation message segment . Now, both TCP parties have entered the connection established state, and they can perform reliable data transmission based on the established TCP connection.
(3) The ordinary TCP confirmation message segment sent to the TCP server process after the TCP client process receives the TCP connection request confirmation message segment is not redundant . The following example illustrates this point.
① The TCP client process sends a TCP connection request segment, but the segment remains in some network nodes for a long time, which will inevitably cause the segment to be retransmitted over time .
② Assuming that the retransmitted message segment is received normally by the TCP server process, the TCP server process sends a TCP connection request confirmation message segment to the TCP client process and enters the connection established state.
③ If a "two-message handshake" is adopted, that is, the TCP client process does not need to send an ordinary TCP confirmation message segment, then the TCP server process will enter the connection established state after sending the TCP connection request confirmation message segment.
④After receiving the TCP connection request confirmation message segment, the TCP client process enters the TCP connection established state, but will not send a normal confirmation message segment for this message segment to the TCP server process.
⑤ Now, both TCP parties are in the connection established state, and they can transmit data to each other. Afterwards, the connection can be released through "four message wave", and the TCP of both parties will enter the closed state.
⑥After a period of time, the failed TCP connection request segment that was previously stuck in the network reaches the TCP server process. The TCP server process will mistakenly think that this is a new TCP connection request initiated by the TCP client process, so it sends a request to the TCP server process. The client process sends a TCP connection request confirmation message segment and enters the connection established state.
⑦The message segment reaches the TCP client process. Since the TCP client process has not initiated a new TCP connection request and is in a closed state, it will ignore the message segment. However, the TCP server process has entered the connection established state. It thinks that the message segment has entered the connection established state. The new TCP connection has been established and has been waiting for the TCP client process to send data. This will waste a lot of resources on the host where the TCP server process is located.
3. TCP connection release
(1) TCP releases the connection through "four message waves". After the data transmission is completed, both parties in the TCP communication can release the connection.
(2) The specific process of TCP using "four message wave" to release the connection:
① Assume that both the TCP client process and the TCP server process are now in the connection established state. At this time, the application process using the TCP client process notifies it to actively close the TCP connection . The TCP client process will send a TCP connection release message segment and enter the termination wait 1 state . The values of the termination bit FIN and the confirmation bit ACK in the header of this message segment are both set to 1 , indicating that this is a TCP connection release message segment, and it also confirms the previously received message segment; the sequence number field se q The value of ack is set to u , which is equal to the sequence number of the last byte of data that has been transmitted before by the TCP client process plus 1 ; the value of the confirmation number field ack is set to v , which is equal to the data that has been received by the TCP client process before. The sequence number of the last byte is increased by 1 . ( TCP stipulates that a message segment with a termination bit PIN equal to 1 will consume a sequence number even if it does not carry data ).
② After the TCP server process receives the TCP connection release segment, it will send an ordinary TCP confirmation segment and enter the shutdown waiting state . The value of the acknowledgment bit ACK in the header of the segment is set to 1 , indicating that this is an ordinary TCP acknowledgment segment; the value of the sequence number field seq is set to v , which is equal to the value of the data that has been transmitted before by the TCP server process. The sequence number of the last byte is increased by 1 , which also matches the confirmation number in the previously received TCP connection release segment ; the value of the confirmation number field ack is set to u+1 , which is the response to the TCP connection release segment. confirm .
③ The TCP server process should notify the high-level application process at this time that the TCP client process needs to disconnect from its own TCP connection. At this time, the connection from the TCP client process to the TCP server process is released , and the TCP connection at this time is semi-closed. status, that is, the TCP client process has no data to send , but if the TCP server process still has data to send, the TCP client process still needs to receive it. In other words, the connection from the TCP server process to the TCP client process has not Closed, this state may last for some time.
④ After receiving the TCP confirmation message segment, the TCP client process enters the termination wait 2 state and waits for the TCP connection release message segment sent by the TCP server process . If the application process using the TCP server process has no data to send, the application process notifies its TCP server process to release the connection . Since the release of the TCP connection is actively initiated by the TCP client process, the release of the TCP connection by the TCP server process is called passive closing of the connection .
⑤ The TCP server process sends the TCP connection release message segment and enters the final confirmation state . The values of the termination bit FIN and the confirmation bit ACK in the header of this message segment are both set to 1 , indicating that this is a TCP connection release message segment, and it also confirms the previously received message segment; now assume that the sequence number field The value of seq is w . This is because when the TCP connection is half-closed, the TCP server process may have sent some more data (w is equal to the sequence number of the last byte of the data previously transmitted by the TCP server process plus 1 ); confirm The value of the number field ack is u+1 , which is a repeated confirmation of the previously received TCP connection release message segment .
⑥ After the TCP client process receives the TCP connection release message segment, it must send an ordinary TCP confirmation message segment for the message segment, and then enter the time waiting state . The value of the acknowledgment bit ACK in the header of this segment is set to 1 , indicating that this is an ordinary TCP acknowledgment segment; the value of the sequence number field seq is set to u+1 , because the TCP client process previously sent Although the connection release segment does not carry data, it consumes a sequence number ; the value of the confirmation number field ack is set to w+1 , which is a confirmation of the received TCP connection release segment .
⑦ The TCP server process enters the closed state after receiving the ordinary TCP confirmation message segment , while the TCP client process needs to go through 2MSL before it can enter the closed state . MSL means the longest message segment life . The RFC793 document recommends 2 minutes (TCP allows different implementations to use smaller MSL values according to specific circumstances), which means that the TCP client process will have to wait for 4 minutes after entering the time waiting state. minutes to enter the shutdown state.
(3) The TCP client process cannot directly enter the shutdown state after sending the last confirmation message segment . It must first enter the time waiting state . The following example illustrates this point.
① The TCP server process sends the TCP connection release message segment and enters the final confirmation state . After receiving the message segment, the TCP client process sends an ordinary TCP confirmation message segment and enters the closed state instead of the time waiting state. However, the TCP client process The TCP confirmation message segment is lost, which will inevitably cause the TCP server process to timeout and retransmit the previously sent TCP connection release message segment, and the TCP server process is still in the final confirmation state .
②The retransmitted TCP connection release message segment reaches the TCP client process. Since the TCP client process is in a closed state, it ignores the message segment. This will inevitably cause the TCP server process to repeatedly retransmit the TCP connection release message segment and continue to do so. In the final confirmed state and unable to enter the closed state.
③It can be seen that the time waiting state and the 2MSL duration in this state can ensure that the TCP server process receives the last TCP confirmation message segment and enters the closed state. In addition, after the TCP client process sends the last TCP confirmation message segment and then passes 2MSL, all the message segments generated during the duration of this connection will disappear from the network, so that the next new The message segments from the old connection will not appear in the TCP connection.
(4) Keep-alive timer in TCP:
① Assume that both TCP parties have established a connection, and then the host where the TCP client process is located suddenly fails. Obviously, the TCP server process will no longer receive data from the TCP client process in the future. Therefore, there should be measures to prevent the TCP server process from wasting time. If you wait, the measure is the keep-alive timer.
②Every time the TCP server process receives data from the TCP client process, it resets and starts the keep-alive timer . If no data is received from the TCP client process within the keep-alive timer period, when the keep-alive timer expires After that, the TCP server process sends a detection segment to the TCP client process , and then sends it every 75 seconds. If there is still no response from the TCP client process after sending 10 probe segments in a row, the TCP server process will think that the host where the TCP client process is located is faulty, and then close the connection.
9. Header format of TCP segment
1. TCP processing of application messages
(1) In order to achieve reliable transmission, TCP adopts a byte stream-oriented approach. TCP regards the application messages delivered by the application process as byte streams and stores them in the TCP send buffer. But when TCP sends data, it takes out some or all bytes from the sending buffer and adds a header to it to make it a TCP segment before sending it.
(2) A TCP message segment consists of two parts : header and data payload . All functions of TCP are reflected in the role of each field in its header.
2. The role of each field in the TCP segment header
(1) The header format of the TCP segment is similar to the header format of the IP datagram, both consisting of a 20-byte fixed header and a maximum 40-byte extended header.
(2) The source port field occupies 16 bits and is used to write the source port number, and the source port number is used to identify the application process that sent the TCP segment .
(3) The destination port field occupies 16 bits and is used to write the destination port number, and the destination port number is used to identify the application process that receives the TCP segment .
(4) The sequence number field occupies 32 bits and is related to TCP's implementation of reliable transmission. When the sequence number increases to the last one, the next sequence number starts from 0. The value of the sequence number field is used to indicate the sequence number of the first byte of the data payload of this TCP segment .
(5) The confirmation number field occupies 32 bits, which is related to the reliable transmission of TCP. When the confirmation number increases to the last one, the next confirmation number starts from 0. The value of the confirmation number field is used to indicate the sequence number of the first byte of the data payload expected to be received from the other party's next TCP segment. It is also a confirmation of all previously received data (if the confirmation number = n, it indicates All data up to sequence number n-1 have been received correctly, and data with sequence number n is expected to be received).
(6) The confirmation flag bit ACK occupies 1 bit. When the value is 1, the confirmation number field is valid. When the value is 0, the confirmation number field is invalid. (TCP stipulates that all TCP segments transmitted after the connection is established must have ACK set to 1)
(7) The data offset field occupies 4 bits, in 4-byte units, and is used to indicate how far the start of the data payload part of the TCP message segment is from the start of the TCP message segment . This field actually It 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 in binary; plus the maximum extension header of 40 bytes, the maximum length of the header is 60 bytes, so the maximum value of the data offset field is binary 1111.
(8) The reserved field occupies 6 bits and is reserved for future use, but should be set to 0 currently.
(9) The window field occupies 16 bits, in bytes, and is used to indicate the receiving window size of the party sending this message segment . The window value serves as the basis for the receiver to let the sender set its sending window (the size of the sending window is also Depends on the size of the congestion window, that is, the smaller one should be chosen from the receiving window and the congestion window).
(10) The checksum field occupies 16 bits and is used to check whether there are any bit errors during the transmission of the entire TCP message segment. Similar to UDP, when calculating the checksum, a 12-byte pseudo header is added in front of the TCP segment.
(11) The synchronization flag bit SYN occupies 1 bit, which is used to synchronize the sequence number when the TCP connection is established.
① In the TCP connection request segment sent by the TCP client process, the synchronization flag bit SYN in the header is set to 1, indicating that this is a TCP connection request segment.
② In the TCP connection request confirmation segment sent by the TCP server process, the synchronization flag bit SYN in the header is set to 1, and the confirmation bit ACK is also set to 1, indicating that this is a TCP connection request confirmation segment.
(12) The termination flag bit FIN occupies 1 bit, which is used to release the TCP connection. Regardless of whether it is a TCP client process or a TCP server process, the termination flag bit FIN in the header of the TCP connection release segment sent by them is set to 1, indicating that this is a TCP connection release segment.
(13) The reset flag bit RST occupies 1 bit and is 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. RST setting to 1 can also be used to reject an illegal segment or refuse to open a TCP connection.
(14) The push flag bit PSH occupies 1 bit and is used to implement the push operation. The receiver's TCP will hand over the segment to the application process as soon as possible after receiving the message segment with the flag bit 1. It does not have to wait until the receiving buffer is filled before delivering it upward. .
(15) The emergency pointer field occupies 16 bits, in bytes, and is used to indicate the length of emergency data.
①The emergency pointer will indicate how long the emergency data is contained in the data load part of this segment. After the emergency data is ordinary 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.
③ When the receiver receives a message segment with an emergency flag of 1, it will take out the emergency data from the data payload part of the message segment according to the value of the emergency pointer field and hand it over directly to the application process without queuing in the receive buffer.
(16) The emergency flag bit URG occupies 1 bit. When the value is 1, the emergency pointer field is valid. When the value is 0, the emergency pointer field is invalid.
(17) In addition to the fixed part of 20 bytes, the TCP segment header also has an option part of up to 40 bytes. Adding options can increase the functions of TCP. Currently, the following options are available:
①Maximum segment length MSS option: used to indicate the maximum length of the data payload part of the TCP segment.
②Window expansion option: Used to expand the window and improve throughput.
③Time stamp option:
[1] is used to calculate the round trip time RTT.
[2] Used to handle the situation where the serial number is out of range, also known as preventing the serial number from wrapping around PAWS.
④Selection confirmation option: used to implement the selection confirmation function.
(18) Since the length of the option is variable, a padding field is used to ensure that the segment header is divisible by 4 (because the data offset field, that is, the header length field, is in units of 4 bytes).