RT.
TCP protocol is since its reliability, the packets when they didn't get the corresponding timeout time retransmission,
So why often when doing business, need to be in the upper do it again confirm receipt and retransmission mechanism?
Beg explanation! Thank you very much!

In addition, the TCP retransmission mechanism is timing resend many times, The Times have limit? I think there must be a limit?
Not always resend!
O verify!

CodePudding user response:

TCP is a reliable, if can know send success or failure, if send failure business need resend resend
UPD is unreliable, send success failure is unknown, so you need to tell whether the sender receiver business success,

CodePudding user response:

reference

TCP protocol is since its reliability, the packets when they didn't get the corresponding timeout time retransmission,
So why often when doing business, need to be in the upper do it again confirm receipt and retransmission mechanism?

Some humble opinions:
1. The application may need to be performed according to the receipt sequential control, process control, etc., for example, need after receiving the acknowledgement of serial number N, and then send the next frame N + 1, this can have the effect of flow control, the main frame to the receiving end processing
2. The transport layer to ensure maximum extent to send the content of the right to the end, but we can not ensure that the content of the application layer delivery is correct, for example, send a message to the end of length L, in fact only sent a length of 4 messages sent, or else, the application layer must access, through the methods of CRC check, make sure to send the content of the right
Different transport layer protocol only determines the reliability of the transmission channel does not represent the content of the channel transmission must be correct and expectations

CodePudding user response:

TCP sender not received the confirmation message, you will think the loss of data, trigger retransmission mechanism,
Trigger retransmission frequently, can cause the overall utilization rate of bandwidth, namely TCP synchronization

CodePudding user response:

Some of them are logical error retransmission, rather than because of the error in transmission,
Besides, writing code doesn't necessarily understand TCP/IP

CodePudding user response:

TCP retransmission, of course, there is a limit, and TCP timeout retransmission mechanism is also very interesting, concrete can look https://blog.csdn.net/xiongyingzhuantu/article/details/39926325

In short is the first time after a timeout, will soon resend a message; After the second overtime, resend a packet delay is longer than the last time (middle)... After the NTH timeout, return the TCP transmission failure