net/socket/tcp_socket.h

// Copyright 2013 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

#ifndef NET_SOCKET_TCP_SOCKET_H_
#define NET_SOCKET_TCP_SOCKET_H_

#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"
#elif defined(OS_POSIX)
#include "net/socket/tcp_socket_posix.h"
#endif

namespace net {

// TCPSocket provides a platform-independent interface for TCP sockets.
//
// It is recommended to use TCPClientSocket/TCPServerSocket instead of this
// class, unless a clear separation of client and server socket functionality is
// not suitable for your use case (e.g., a socket needs to be created and bound
// before you know whether it is a client or server socket).
#if defined(OS_WIN)
typedef TCPSocketWin TCPSocket;
#elif defined(OS_POSIX)
typedef TCPSocketPosix TCPSocket;
#endif

// Check if TCP FastOpen is supported by the OS.
bool IsTCPFastOpenSupported();

// Check if TCP FastOpen is enabled by the user.
bool IsTCPFastOpenUserEnabled();

// Checks if TCP FastOpen is supported by the kernel. Also enables TFO for all
// connections if indicated by user.
// 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_