Linux Set TCP_QUICKACK and TCP_NODELAY
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7286592/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Set TCP_QUICKACK and TCP_NODELAY
提问by donalmg
If you set the TCP_QUICKACK setting on every call on the socket, having previously set TCP_NODELAY, will the QUICKACK option overwrite the NODELAY call?
If you set the TCP_QUICKACK setting on every call on the socket, having previously set TCP_NODELAY, will the QUICKACK option overwrite the NODELAY call?
On connect:
On connect:
int i = 1;
setsockopt( iSock, IPPROTO_TCP, TCP_NODELAY, (void *)&i, sizeof(i));
On each write:
On each write:
int i = 1;
setsockopt( iSock, IPPROTO_TCP, TCP_QUICKACK, (void *)&i, sizeof(i));
Will the call to TCP_QUICKACK null the previous call to TCP_NODELAY?
Will the call to TCP_QUICKACK null the previous call to TCP_NODELAY?
采纳答案by Fei
There's no direct relationship between those two options, they are just for different purposes.
There's no direct relationship between those two options, they are just for different purposes.
TCP_NODELAYis intended to disable/enable segment buffering so data can be sent out to peer as quickly as possible, so this is typically used to improve network utilisation. TCP_QUICKACKis used to send out acknowledgements as early as possible than delayed under some protocol level exchanging, and it's not stable/permanent, subsequent TCP transactions (which may happen under the hood) can disregard this option depending on actual protocol level processing or any actual disagreements between user setting and stack behaviour.
TCP_NODELAYis intended to disable/enable segment buffering so data can be sent out to peer as quickly as possible, so this is typically used to improve network utilisation. TCP_QUICKACKis used to send out acknowledgements as early as possible than delayed under some protocol level exchanging, and it's not stable/permanent, subsequent TCP transactions (which may happen under the hood) can disregard this option depending on actual protocol level processing or any actual disagreements between user setting and stack behaviour.
NOTETCP_NODELAYis portable while TCP_QUICKACKis not (only works under Linux 2.4.4+).
NOTETCP_NODELAYis portable while TCP_QUICKACKis not (only works under Linux 2.4.4+).
回答by Mats
TCP_QUICKACK and TCP_NODELAY affects different operations in TCP. The tcp(7)man page describes which socket options for TCP that interfere with each other, e.g. TCP_CORK and TCP_NODELAY.
TCP_QUICKACK and TCP_NODELAY affects different operations in TCP. The tcp(7)man page describes which socket options for TCP that interfere with each other, e.g. TCP_CORK and TCP_NODELAY.
回答by rofrol
Use TCP_QUICKACK, not TCP_NODELAY
Use TCP_QUICKACK, not TCP_NODELAY
Turning on TCP_NODELAY has similar effects, but can make throughput worse for small writes. If you write a loop which sends just a few bytes (worst case, one byte) to a socket with "write()", and the Nagle algorithm is disabled with TCP_NODELAY, each write becomes one IP packet. This increases traffic by a factor of 40, with IP and TCP headers for each payload. Tinygram prevention won't let you send a second packet if you have one in flight, unless you have enough data to fill the maximum sized packet. It accumulates bytes for one round trip time, then sends everything in the queue. That's almost always what you want. If you have TCP_NODELAY set, you need to be much more aware of buffering and flushing issues. None of this matters for bulk one-way transfers, which is most HTTP today. (I've never looked at the impact of this on the SSL handshake, where it might matter.) Short version: set TCP_QUICKACK. If you find a case where that makes things worse, let me know. John Nagle
Turning on TCP_NODELAY has similar effects, but can make throughput worse for small writes. If you write a loop which sends just a few bytes (worst case, one byte) to a socket with "write()", and the Nagle algorithm is disabled with TCP_NODELAY, each write becomes one IP packet. This increases traffic by a factor of 40, with IP and TCP headers for each payload. Tinygram prevention won't let you send a second packet if you have one in flight, unless you have enough data to fill the maximum sized packet. It accumulates bytes for one round trip time, then sends everything in the queue. That's almost always what you want. If you have TCP_NODELAY set, you need to be much more aware of buffering and flushing issues. None of this matters for bulk one-way transfers, which is most HTTP today. (I've never looked at the impact of this on the SSL handshake, where it might matter.) Short version: set TCP_QUICKACK. If you find a case where that makes things worse, let me know. John Nagle
