| Index: net/socket/tcp_socket.h
|
| diff --git a/net/socket/tcp_socket.h b/net/socket/tcp_socket.h
|
| index 319a6b261d02f78961b3d950648f230dd0733857..58797bb0851ca59cab11cd6ab7aa6c0d5c90dbaf 100644
|
| --- a/net/socket/tcp_socket.h
|
| +++ b/net/socket/tcp_socket.h
|
| @@ -7,7 +7,6 @@
|
|
|
| #include "build/build_config.h"
|
| #include "net/base/net_export.h"
|
| -#include "net/socket/socket_descriptor.h"
|
|
|
| #if defined(OS_WIN)
|
| #include "net/socket/tcp_socket_win.h"
|
| @@ -40,39 +39,6 @@
|
| // Not thread safe. Must be called during initialization/startup only.
|
| NET_EXPORT void CheckSupportAndMaybeEnableTCPFastOpen(bool user_enabled);
|
|
|
| -// This function enables/disables buffering in the kernel. By default, on Linux,
|
| -// TCP sockets will wait up to 200ms for more data to complete a packet before
|
| -// transmitting. After calling this function, the kernel will not wait. See
|
| -// TCP_NODELAY in `man 7 tcp`.
|
| -//
|
| -// For Windows:
|
| -//
|
| -// The Nagle implementation on Windows is governed by RFC 896. The idea
|
| -// behind Nagle is to reduce small packets on the network. When Nagle is
|
| -// enabled, if a partial packet has been sent, the TCP stack will disallow
|
| -// further *partial* packets until an ACK has been received from the other
|
| -// side. Good applications should always strive to send as much data as
|
| -// possible and avoid partial-packet sends. However, in most real world
|
| -// applications, there are edge cases where this does not happen, and two
|
| -// partial packets may be sent back to back. For a browser, it is NEVER
|
| -// a benefit to delay for an RTT before the second packet is sent.
|
| -//
|
| -// As a practical example in Chromium today, consider the case of a small
|
| -// POST. I have verified this:
|
| -// Client writes 649 bytes of header (partial packet #1)
|
| -// Client writes 50 bytes of POST data (partial packet #2)
|
| -// In the above example, with Nagle, a RTT delay is inserted between these
|
| -// two sends due to nagle. RTTs can easily be 100ms or more. The best
|
| -// fix is to make sure that for POSTing data, we write as much data as
|
| -// possible and minimize partial packets. We will fix that. But disabling
|
| -// Nagle also ensure we don't run into this delay in other edge cases.
|
| -// See also:
|
| -// http://technet.microsoft.com/en-us/library/bb726981.aspx
|
| -//
|
| -// This function returns true if it succeeds to set the TCP_NODELAY option,
|
| -// otherwise returns false.
|
| -NET_EXPORT_PRIVATE bool SetTCPNoDelay(SocketDescriptor socket, bool no_delay);
|
| -
|
| } // namespace net
|
|
|
| #endif // NET_SOCKET_TCP_SOCKET_H_
|
|
|