Manual Pages  — TCP

Sockets utilizing the TCP protocol are either "active" or "passive". Active sockets initiate connections to passive sockets. By default, TCP sockets are created active; to create a passive socket, the listen(2) system call must be used after binding the socket with the bind(2) system call. Only passive sockets may use the accept(2) call to accept incoming connections. Only active sockets may use the connect(2) call to initiate connections.

Passive sockets may "underspecify" their location to match incoming connection requests from multiple networks. This technique, termed "wildcard addressing", allows a single server to provide service to clients on multiple networks. To create a socket which listens on all networks, the Internet address INADDR_ANY must be bound. The TCP port may still be specified at this time; if the port is not specified, the system will assign one. Once a connection has been established, the socket's address is fixed by the peer entity's location. The address assigned to the socket is the address associated with the network interface through which packets are being transmitted and received. Normally, this address corresponds to the peer entity's network.

TCP supports a number of socket options which can be set with setsockopt(2) and tested with getsockopt(2):

TCP_INFO	Information about a socket's underlying TCP session may be retrieved by passing the read-only option TCP_INFO to getsockopt(2). It accepts a single argument: a pointer to an instance of struct tcp_info. This API is subject to change; consult the source to determine which fields are currently filled out by this option. FreeBSD specific additions include send window size, receive window size, and bandwidth-controlled window space.
TCP_CCALGOOPT	Set or query congestion control algorithm specific parameters. See mod_cc(4) for details.
TCP_CONGESTION	Select or query the congestion control algorithm that TCP will use for the connection. See mod_cc(4) for details.
TCP_FASTOPEN	Enable or disable TCP Fast Open (TFO). To use this option, the kernel must be built with the TCP_RFC7413 option. This option can be set on the socket either before or after the listen(2) is invoked. Clearing this option on a listen socket after it has been set has no effect on existing TFO connections or TFO connections in progress; it only prevents new TFO connections from being established. For passively-created sockets, the TCP_FASTOPEN socket option can be queried to determine whether the connection was established using TFO. Note that connections that are established via a TFO SYN, but that fall back to using a non-TFO SYN|ACK will have the TCP_FASTOPEN socket option set. In addition to the facilities defined in RFC7413, this implementation supports a pre-shared key (PSK) mode of operation in which the TFO server requires the client to be in posession of a shared secret in order for the client to be able to successfully open TFO connections with the server. This is useful, for example, in environments where TFO servers are exposed to both internal and external clients and only wish to allow TFO connections from internal clients. In the PSK mode of operation, the server generates and sends TFO cookies to requesting clients as usual. However, when validating cookies received in TFO SYNs from clients, the server requires the client-supplied cookie to equal SipHash24(key=16-byte-psk, msg=cookie-sent-to-client) Multiple concurrent valid pre-shared keys are supported so that time-based rolling PSK invalidation policies can be implemented in the system. The default number of concurrent pre-shared keys is 2. This can be adjusted with the TCP_RFC7413_MAX_PSKS kernel option.
TCP_FUNCTION_BLK
	Select or query the set of functions that TCP will use for this connection. This allows a user to select an alternate TCP stack. The alternate TCP stack must already be loaded in the kernel. To list the available TCP stacks, see functions_available in the MIB Variables section further down. To list the default TCP stack, see functions_default in the MIB Variables section.
TCP_KEEPINIT	This setsockopt(2) option accepts a per-socket timeout argument of u_int in seconds, for new, non-established TCP connections. For the global default in milliseconds see keepinit in the MIB Variables section further down.
TCP_KEEPIDLE	This setsockopt(2) option accepts an argument of u_int for the amount of time, in seconds, that the connection must be idle before keepalive probes (if enabled) are sent for the connection of this socket. If set on a listening socket, the value is inherited by the newly created socket upon accept(2). For the global default in milliseconds see keepidle in the MIB Variables section further down.
TCP_KEEPINTVL	This setsockopt(2) option accepts an argument of u_int to set the per-socket interval, in seconds, between keepalive probes sent to a peer. If set on a listening socket, the value is inherited by the newly created socket upon accept(2). For the global default in milliseconds see keepintvl in the MIB Variables section further down.
TCP_KEEPCNT	This setsockopt(2) option accepts an argument of u_int and allows a per-socket tuning of the number of probes sent, with no response, before the connection will be dropped. If set on a listening socket, the value is inherited by the newly created socket upon accept(2). For the global default see the keepcnt in the MIB Variables section further down.
TCP_NODELAY	Under most circumstances, TCP sends data when it is presented; when outstanding data has not yet been acknowledged, it gathers small amounts of output to be sent in a single packet once an acknowledgement is received. For a small number of clients, such as window systems that send a stream of mouse events which receive no replies, this packetization may cause significant delays. The boolean option TCP_NODELAY defeats this algorithm.
TCP_MAXSEG	By default, a sender- and receiver- TCP will negotiate among themselves to determine the maximum segment size to be used for each connection. The TCP_MAXSEG option allows the user to determine the result of this negotiation, and to reduce it if desired.
TCP_NOOPT	TCP usually sends a number of options in each packet, corresponding to various TCP extensions which are provided in this implementation. The boolean option TCP_NOOPT is provided to disable TCP option use on a per-connection basis.
TCP_NOPUSH	By convention, the sender- TCP will set the "push" bit, and begin transmission immediately (if permitted) at the end of every user call to write(2) or writev(2). When this option is set to a non-zero value, TCP will delay sending any data at all until either the socket is closed, or the internal send buffer is filled.
TCP_MD5SIG	This option enables the use of MD5 digests (also known as TCP-MD5) on writes to the specified socket. Outgoing traffic is digested; digests on incoming traffic are verified. When this option is enabled on a socket, all inbound and outgoing TCP segments must be signed with MD5 digests. One common use for this in a FreeBSD router deployment is to enable based routers to interwork with Cisco equipment at peering points. Support for this feature conforms to RFC 2385. In order for this option to function correctly, it is necessary for the administrator to add a tcp-md5 key entry to the system's security associations database (SADB) using the setkey(8) utility. This entry can only be specified on a per-host basis at this time. If an SADB entry cannot be found for the destination, the system does not send any outgoing segments and drops any inbound segments. Each dropped segment is taken into account in the TCP protocol statistics.

The option level for the setsockopt(2) call is the protocol number for TCP, available from getprotobyname(3), or IPPROTO_TCP. All options are declared in <netinet/tcp.h>.

Options at the IP transport level may be used with TCP; see ip(4). Incoming connection requests that are source-routed are noted, and the reverse source route is used in responding.

The default congestion control algorithm for TCP is cc_newreno(4). Other congestion control algorithms can be made available using the mod_cc(4) framework.

V. Jacobson, B. Braden, D. Borman, RFC 1323, TCP Extensions for High Performance,

D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, RFC 7323, TCP Extensions for High Performance,

A. Heffernan, RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option,

K. Ramakrishnan, S. Floyd, D. Black, RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP,