Home > other >  Why open TCP_NODELAY option or TCP_QUICKACK option can't solve the problem of ACK delay
Why open TCP_NODELAY option or TCP_QUICKACK option can't solve the problem of ACK delay

Time:09-17

:

The client needs to send 2062 bytes of data, and then read the response from the server,

Through wireshark caught, data is divided into 1460 bytes and 602 bytes sent two pieces,
As shown: sent after the first 1460 bytes, the server waiting for an ACK after 40 ms; The client is receiving an ACK sent 602 bytes of the second paragraph,


Phenomenon seems consistent with Nalge algorithm and ACK delay confirmation mechanism, the first paragraph of the client sends data size meet MSS, send immediately, because after you receive the server to wait to receive the rest of the 602 bytes, so didn't send the response data, also cannot carry an ACK, cause delayed ACK, the client in the second period of 602 - byte data is not confirmed for the first piece of data is delayed to send, until after 40 ms receives an ACK,

So, the client reference online tutorial set TCP_NODELAY options:
 int flag=1; 
Result=setsockopt (sockfd, IPPROTO_TCP TCP_NODELAY, & amp; Flag, sizeof (flag));

Server after each recv set TCP_QUICKACK options:
 int quickack=1; 
Result=setsockopt (sockset [socknr] sockfd, IPPROTO_TCP, TCP_QUICKACK, & amp; Quickack, sizeof (int));

Test results did not change, however, there are other factors?

CodePudding user response:

Waiting for a great god, and to learn

Feel it involves too many: physical link, network card driver, protocol stack, data copy and handling, and so on...

CodePudding user response:

Set on both sides
  • Related