-
TCP protocol detailed (theory)
-
2012-08-20 0 comments Chen Lilong
- collection I want to contribute
-
TCP protocol detailed (theory) 1. Unlike UDP, TCP provides a connection-oriented, reliable byte-stream service. Connection-oriented is a good understanding, that is, the connection between the two before the communication needs to establish a pre-connection, this is like real life calls. To help the reliability, TCP protocol involves a number of rules to ensure the reliability of the communication link, summed up, the main points are as follows: (1) The application data is divided into the data block that TCP thinks is most suitable for sending. This is partly controlled by the "MSS" (maximum packet length) option, which is often referred to as a negotiation mechanism, which specifies the length of the largest chunk of data that TCP travels to the other end. It should be noted that MSS can only appear in the SYN message segment, if one party does not receive the MSS value from the other side, the MSS will be set to 536 bytes. Generally speaking, in the case of no fragmentation, the MSS value is larger the better, this can improve the utilization of the network. (2) retransmission mechanism. Set the timer and wait for the confirmation package. (3) Check the header and data. (4) TCP sorts the received data and then gives it to the application layer. (5) The receiving end of TCP discards duplicate data. (6) TCP also provides flow control. (provided by the window size declared by each end) 2. Header of the TCP packet: www.2cto.com
(1) If the option field is not counted, TCP's header accounts for 20 bytes. (2) The source port number and the destination port number are used to find the process of the originating and receiving end, generally speaking, through the port number and IP address, can uniquely determine a TCP connection, in network programming, is often referred to as a socket interface. (3) The serial number is used to identify the data byte stream sent from the TCP originator to the TCP receiver. (4) Confirm that the serial number contains the next sequence number expected to be received at the end of the sending confirmation, so the confirmation sequence number should be the last time the data byte sequence number plus 1 is received. (5) The header length indicates the length value of the TCP header, and if no option exists, the value is 20 bytes. (6) flag (flag): URG: Emergency pointer effective ACK: Confirm serial Number valid PSH: The receiver should give this segment to the application layer as soon as possible RST: Rebuilding connection SYN: Synchronous sequence number used to initiate a connection FIN: The originator completes the Send task (active shutdown)
The "Explain" TCP provides a workaround to let one end tell the other end that some "emergency data" has been placed in the normal data stream, allowing the receiver to do special processing of emergency data. At this point, the Urg bit is set to 1, and the 16-bit emergency data is set to a positive offset, which is added to the ordinal field in the TCP header, the last byte ordinal of the emergency data can be obtained, and the common application has the transmission interrupt key (during the connection through Telnet). RST: The Reset field is used when a message is sent to a socket interface and an error occurs, and TCP sends a reset message segment. Common occurrences are the following: Www.2cto.com sends a connection request to a port that does not exist: At this point the destination port is not listening, for UDP, will emit ICMP unreachable error message, and for TCP, will be issued to set the RST reset flag bit of the datagram. Abort a connection abnormally: Normally, by sending fin to gracefully close a TCP connection, it is possible to release a connection halfway through sending a reset message segment. In SOCKETAPI by setting the socket option So_linger to turn off this abnormal shutdown situation. 3. TCP connection and termination process:
(1) Three-time handshake: To establish a TCP connection, it must undergo three handshake process, where one end of the sending of the first SYN will perform an active open, receive this SYN and return to the other end of the next SYN to perform a passive open. (2) Four release: to release a TCP connection, you need to pass the four handshake process, which is caused by the semi-shutdown of TCP, because the TCP connection is full-duplex, and therefore requires that the TCP ends be closed separately. It is worth noting that the active shut-off side after the fin is sent, still can normally receive the other party's data, just notify the other side it has no data to send, in the same way, the passive closed one end after receiving fin, still can send data, until it itself issued fin, before the data stop sending.
(3) Timeout Problem of TCP connection: Complete a TCP connection, the middle of a timeout problem, most of the Berkeley system time-out time limit of 75S,SOLARIS9 is 240s, therefore, is generally considered to be between 75-240. "Extended" in the specific implementation, how to complete the user to set the socket connection timeout time? "Workaround" The current implementation of the socket timeout connection is mainly through select to complete. The steps are as follows: setting up a socket to set the socket to non-blocking mode (if blocking mode, then the time setting is meaningless) call connect to connect using Select to check if the socket Writable, and at the same time judging its results (why is it writable?) Because you need to detect if the socket receives an ACK. ) to turn the socket into blocking mode
(4) The semi-shutdown of TCP www.2cto.com, the so-called "semi-shutdown", refers to the ability of one end of a connection to receive data from the other party after it has been sent. In particular, when the two sides of the three-time handshake, one end of the fin, it will enter the semi-closed state, when it closes its own sending function, but it can still receive the other side of the data, such as the other side sent an ACK message. So how is it implemented in real development? This involves the difference between the 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 the parameter s, there are several situations where the parameters are: how = 0 terminating read Operation how = 1 terminating write operation how = 2 terminating read and write operations The returned errorcode may have: EBADF/* Bad file de Scriptor */enotsock/* Socket operation on Non-socket */enotconn * Socket is not connected */
"Reference" Big difference between shutdown and close on a socket are thebehavior when the socket was 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'll be is in a time_waitstate While the OS makes sure there's no outstandingpackets that might get confused as new information if you were to immediate Lyreuse that socket for something else. "Note" When shutdown closes the Read section, it discards any data in the receive buffer and closes the connection to that end, and if the write part is closed, TCP sends the remaining data. The write end of the connection is then terminated. 4. TCP Status Change graph:
Several state resolution: (1) time_wait status This state is also known as the 2MSL wait state, which is the maximum lifetime of a message segment, which is the maximum amount of time a message is dropped before it is discarded in the network. So why wait for twice times the MSL? This is because after the TIME_WAIT state, you need to perform an active shutdown, send an ACK, and also need to add one more MSL, in order to wait for the other side of the feedback (whether to receive the re-issued Fin), this is because after sending an ACK, there may be many reasons for the ACK send failed, At this point the server side sends fin here. Normally, the client will not be able to use the corresponding socket during 2MSL, but in a specific implementation (such as Berkeley), this interface can be reused through the SO_REUSEADDR option. (2) fin_wait_2 status when the other party confirms the FIN that he sent, it will enter the Fin_wait_2 state. (3) close_wait status and fin_wait_1 status when a party in the connection receives a fin from the other, it enters the close_wait state and the other end enters the fin_wait_1 state. www.2cto.com 5. The flow control mechanism in TCP-sliding window is affected by many factors, such as hardware (the difference in throughput between two network cards), network environment, the network is prone to a variety of congestion, At present, the following two kinds of measures are taken: improving congestion algorithm and controlling traffic at the sending and receiving end. This section focuses on how to control traffic at the receiving and sending ends. (1) Sliding window--receiver before explaining the sliding window protocol, we can review the classical algorithm-stop-wait algorithm, which was put forward in order to implement flow control at the receiving end, the core idea is that the receiving end receives a datagram, Stops receiving new datagrams until the ACK (acknowledgement of the received datagram) is issued. Algorithm thought and implementation is very simple, but encountered an efficiency problem, especially with the network equipment data processing ability has been greatly improved, inefficient is particularly obvious, and later people also tried a variety of improvement measures, such as this section of the sliding window is one of them. The basic principle is that there is a receive cache at the receiving endZone, which is used to receive data from the sender, only if the application process takes the data out of the receiving buffer (which may only be part of it) and sends out its ACK, it is counted as this part of the data has been received, and then adjust the sliding window size at this time. The sender calculates the size of the data that can be sent based on the size of the returned window. Therefore, it can be understood that the sliding window algorithm is the receiver as the active party according to its own cache and processing ability to actively adjust the other side of the transmission of the flow of an adjustment algorithm. Below, a sliding window model is shown to understand how the sending party handles the received sliding window?
In the sender there is still a buffer (send buffer), the data sent can be the following states: Send and confirm (1-3) sent but not confirmed (4-6) www.2cto.com can send (7-9) cannot send (10 later) it is worth noting that the sliding window is based on the confirmed serial number received. The sender moves backwards and updates the data status accordingly, based on the acknowledgment Sequence number and window size received. (2) Sliding window--Send side (congestion window) The cause of network congestion is manifold, in addition to sending and receiving two segments of the hardware differences, but also related to network communication links, such as the communication link in the forwarding router cache, imagine such a situation, if the sender and receiver side processing power and throughput is very strong, If it is only through the size of the sliding window returned by the receiver, it is difficult to prevent the datagram from being discarded because of blocking during the router's forwarding process, because the router connected to the sender is unable to store and forward so much data because of its own buffer space. So how can this be avoided? The best mechanism is that the middle router is also involved in sending feedback to the size of the window, which is also the congestion window described in this section. Combined with the above, the sender will receive two window sizes, each from the receiving and intermediate routers, noting that the former will appear in each datagram, while the latter is only sent by the intermediate router when congestion occurs in the network. The sender then takes the window size of the receiving end and the minimum value in the Congestion window as the upper limit.
TCP protocol detailed (theory)
