Exploring TCP details: TCP timeout/loss retransmission

TCP details: TCP timeout/loss retransmission problem 3: TCP timeout/loss retransmission the Nagle algorithm requires a TCP connection to have at most one unconfirmed packet, and the sender sends one TCP packet, the receiver confirms the message and the sender sends the next message. If the sender fails to receive the message within a certain period of time, the sender resends the message. The Nagle algorithm is relatively simple and error-prone, but reduces the network throughput and increases network traffic. In actual TCP implementation of www.2cto.com, the receiver often confirms a batch of TCP packets at a time and replies with the packets sent from the receiver to the sender to reduce network traffic, on the other hand, the sender can continue to send the next packet when the previous packet is not confirmed. Although this improves the throughput, it brings about another problem, that is, how does the sender confirm that the message is correctly received by the receiver? TCP can be used in two ways to ensure that the message is correctly received: www.2cto.com 1: The sender does not receive the message for confirmation within a certain period of time, and the message is resold. 2: The receiver detects the loss of a message, re-send ACK packets (more than three) to enable the sender to resend the lost packets. This is the fast retransmission mechanism. Generally, the sender retransmits packets not received by the receiver, but does not retransmit packets that have been received by the receiver but are not confirmed. Then, the receiver sorts the received packets and confirms them together. For example, for some reason, the number of data packets sent from the sending end to the receiving end is 1025, and the number of packets with the serial number 1 is lost (250839). At this time, the receiving end confirms the number 1, and the sending end resends the number 1, at this time, the acceptor already has 2484 bytes, and serial number 1 has 1024 bytes, and serial number 1025 contains 1460 bytes. Then, the acceptor replies with an AC packet confirming 2485.