TCP protocol (theoretical)

TCP protocol (theoretical) 1. What is different from UDP is that TCP provides a connection-oriented and reliable byte stream service. It is easy to understand connection orientation, that is, the two sides need to establish a connection before communication, which is like a call in real life. The TCP protocol involves many rules to ensure the reliability of the communication link. In summary, the main points are as follows: (1) the application data is divided into data blocks that TCP considers to be the most suitable for sending. This part is controlled by the "MSS" (maximum packet length) option. Generally, this mechanism is also called a negotiation mechanism, MSS specifies the length of the maximum data block that TCP transmits to the other end. It is worth noting that the MSS can only appear in the SYN packet segment. If one party does not receive the MSS value from the other, the MSS is set to 536 bytes. Generally, the larger the MSS value, the better, without segmentation, can improve the network utilization. (2) retransmission mechanism. Set the timer and wait for the confirmation package. (3) Verify the header and data. (4) TCP sorts the received data and submits it to the application layer. (5) The TCP receiver discards repeated data. (6) TCP also provides traffic control. (Provided by the window size declared by each end) 2. TCP packet header: www.2cto.com

(1) If no option field is specified, the TCP Header occupies 20 bytes. (2) The source port number and destination port number are used to find the process of the initiator and acceptor. Generally, a TCP connection can be uniquely identified by the port number and IP address. In network programming, it is usually called a socket interface. (3) serial number is used to identify the Data byte stream sent from the TCP initiator to the TCP receiver. (4) The validation sequence number includes the next sequence number expected to be received by the sending confirmation end. Therefore, the confirmation sequence number should be the byte number that has been successfully received last time plus 1. (5) The Header Length indicates the length of the TCP Header. If no option exists, the value is 20 bytes. (6) flag: URG: Emergency pointer valid ACK: Confirm Serial Number Valid PSH: the receiver should send this packet segment to the application layer RST as soon as possible: Re-connect SYN: the synchronization sequence number is used to initiate a connection FIN: The initiator completes the sending task (Active shutdown)
[Explanation] ◆ TCP provides a solution to enable one end to tell the other end that some "emergency data" has been placed in a common data stream, so that the receiving end can perform special processing on emergency data. At this time, the URG bit is set to 1, and the 16-bit emergency data is set to a positive offset. This offset is used to sum up the serial number field in the TCP header, the sequence number of the last byte of the emergency data can be obtained. common applications include the transmission interruption key (during telnet connection ). ◆ RST: the reset field is used when a packet is sent to a socket interface and an error occurs, TCP sends a reset packet segment. There are several common scenarios: connection requests sent from www.2cto.com to a non-existent port: At this time, the target port of the other party does not listen. For UDP, an ICMP inaccessible error message will be sent, for TCP, a datagram with the RST Reset flag is sent. Terminate a connection abnormally: normally, a TCP connection is closed normally by sending FIN, but a reset packet segment may be sent to release a connection midway through. In socketAPI, set the socket option SO_LINGER to disable this exception. 3. TCP connection and termination process:

(1) three-way handshake: to establish a TCP connection, you must go through the three-way handshake process. One end that sends the first SYN will be automatically opened, receive the SYN and send it back to the other end of the next SYN for passive opening. (2) Four releases: to release a TCP connection, four handshakes are required. This is caused by the half-closed feature of TCP. Because the TCP connection is full-duplex, the TCP ends must be disabled separately. It is worth noting that after sending FIN, the end of the active shutdown end still can normally receive data from the other end, but notifies the other end that no data needs to be sent. Likewise, after receiving the FIN, the end of the passive shutdown side can still send data until it itself sends the same FIN.
(3) TCP connection Timeout: When a TCP connection is completed, a timeout problem is involved. The timeout period of most Berkeley systems is 75 s, and that of Solaris9 is 240 s, therefore, it is generally considered to be. [Extension] in specific implementation, how do users set the socket connection timeout by themselves? [Solution] currently, the socket timeout connection is mainly achieved through select. Specific steps are as follows: ◆ establish a socket ◆ set the socket to non-blocking mode (if the blocking mode is used, the time setting is meaningless) ◆ call connect for connection ◆ use select to check whether the socket is writable, and judge the result at the same time (why is it writable? Because you need to check whether the socket receives ACK .) ◆ Convert socket to blocking mode
(4) the so-called "half-closed" of TCP www.2cto.com refers to the ability of the connection end to receive data sent by the other end after it is sent. Specifically, when one side of the three-way handshake sends a FIN, it enters the semi-closed state. At this time, it disables its sending function, however, it can still receive data from the other party, such as the ACK message sent by the other party. In actual development, how does one implement it? This involves the difference between shutdown and close functions in the system. Int shutdown (int s, int how) <sys/socket. h> shutdown is used to terminate the socket interface specified by parameter s. The parameter how mainly has the following situations: how = 0 terminate read operation how = 1 terminate write operation how = 2 terminate read and write operations the returned errorcode may be: EBADF/* Bad file descriptor */ENOTSOCK/* Socket operation on non-socket */ENOTCONN/* Socket is not connected */
[Reference] Big difference between shutdown and close on a socket is thebehavior when the socket is shared by other processes. A shutdown () affects all copies of the socket whileclose () affects only the file descriptor in one process. even if you close () a TCP socket, it won't necessarily beimmediately reusable anyway, since it will be in a TIME_WAITstate while the OS makes sure E's no outstandingpacke Ts that might get confused as new information if you were to immediatelyreuse that socket for something else. [note] When shutdown closes reading part, it will discard any data in the receiving buffer and close the connection to this end. If it closes writing part, TCP will send the remaining data, then terminate the connection writer. 4. TCP status change diagram:

Several status resolutions: (1) the TIME_WAIT status is also known as the 2MSL waiting state. MSL is the maximum survival time of a packet segment, that is, the maximum time before the packet is discarded in the network. So why do we need to wait twice as long as MSL? This is because after the TIME_WAIT status, you need to take the initiative to close and send ACK, and add the MSL to the upper limit. In order to wait for the feedback from the other party (whether to receive the resending FIN ), this is because after ACK is sent again, ACK may fail to be sent due to many reasons. At this time, the Server will send FIN here. Normally, the corresponding socket cannot be used during the client's 2MSL period, but in the specific implementation (such as Berkeley), you can use the SO_REUSEADDR option to reuse this interface. (2) FIN_WAIT_2 status when the other party confirms the FIN sent by the other party, it enters the FIN_WAIT_2 status. (3) CLOSE_WAIT status and FIN_WAIT_1 status when one party in the connection receives the FIN from the other party, it enters the CLOSE_WAIT status, and the other end enters the FIN_WAIT_1 status. Www.2cto.com 5. traffic control mechanism in TCP-sliding windows are affected by many factors, such as hardware (NIC throughput differences between the two sides) and network environment, which can cause various network congestion, currently, the following two measures are taken: Improve the congestion algorithm and control the traffic at the sending end and the receiving end. This section describes how to control traffic at the receiving end and the sending end. (1) Sliding Window-before the acceptor explains the Sliding Window Protocol, we can review the classic algorithm-Stop wait algorithm, which was originally proposed to implement traffic control at the acceptor, the core idea is: after receiving a datagram, the receiver stops receiving new datagram until ACK (confirmation of the received datagram) is sent. Algorithm ideas and implementations are very simple, but there is a problem of efficiency, especially as the data processing capability of network devices has been greatly improved, the efficiency is particularly low, later, people tried a variety of improvement measures, such as the sliding window in this section. The basic principle is: there is a receiving cache on the receiving end to receive data from the sender. Only when the application process extracts data from the receiving cache (which may be only part of the data) after the ACK is sent, the part of the data is received and the sliding window size is adjusted. The sender calculates the data size that can be sent based on the returned window size. Therefore, it can be understood that the sliding window algorithm is an algorithm used by the receiving end as the active side to actively adjust the sending traffic of the Other Side Based on its own cache and processing capabilities. The following figure shows how the sender processes the received sliding window?

The sender still has a cache (sending cache). The data sent by the sender can be in the following statuses: ◆ send and confirm (1-3) ◆ sent but not confirmed (4-6) www.2cto.com ◆ can be sent (7-9) ◆ cannot be sent (after 10) It is worth noting that, the sliding window is based on the received confirmation serial number. When the sender continuously moves backward Based on the received confirmation serial number and window size, and updates the data status accordingly. (2) Sliding Window: the transmission terminal (congestion window) network congestion occurs due to many reasons. Besides hardware differences between the two transmission and receiving segments, it is also related to network communication links, for example, in the cache of the forwarding router in a communication link, if the sending end and the receiving end have strong processing and throughput capabilities, if it only uses the sliding window size returned by the receiving end, it is difficult to prevent data packets from being discarded due to blocking during router forwarding, because the router connected to the sending end is limited by its own buffer space, packet loss occurs when it is difficult to store and forward so much data. How can this problem be avoided? The best mechanism is that the intermediate router should also participate in the feedback window size for the sender, which is also the congestion window mentioned in this section. Based on the above description, the sender receives two window sizes, respectively from the receiver and the intermediate router. Note that the former appears in each datagram, the latter is only sent by the Intermediate router when the network is congested. At this time, the sender takes the size of the receiving end window and the minimum value in the congestion window as the upper limit for sending.