DragonFly On-Line Manual Pages


TCP(4)		      DragonFly Kernel Interfaces Manual		TCP(4)

NAME

tcp -- Internet Transmission Control Protocol

SYNOPSIS

#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> int socket(AF_INET, SOCK_STREAM, 0);

DESCRIPTION

The TCP protocol provides reliable, flow-controlled, two-way transmission of data. It is a byte-stream protocol used to support the SOCK_STREAM abstraction. TCP uses the standard Internet address format and, in addi- tion, provides a per-host collection of ``port addresses''. Thus, each address is composed of an Internet address specifying the host and net- work, with a specific TCP port on the host identifying the peer entity. 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) sys- tem 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 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_NODELAY Under most circumstances, TCP sends data when it is pre- sented; when outstanding data has not yet been acknowl- edged, 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 pack- etization 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, cor- responding to various TCP extensions which are provided in this implementation. The boolean option TCP_NOOPT is pro- vided 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 the TCP_NOPUSH 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_SIGNATURE_ENABLE This option enables the use of MD5 digests (also known as TCP-MD5) on writes to the specified socket. In the current release, only outgoing traffic is digested; digests on incoming traffic are not verified. The current default behavior for the system is to respond to a system advertis- ing this option with TCP-MD5; this may change. One common use for this in a DragonFlyBSD router deployment is to enable based routers to interwork with Cisco equip- ment at peering points. Support for this feature conforms to RFC 2385. Only IPv4 (AF_INET) sessions are supported. In order for this option to function correctly, it is nec- essary 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 must have an SPI of 0x1000 and can therefore only be specified on a per-host basis at this time. If an SADB entry cannot be found for the destination, the outgoing traffic will have an invalid digest option prepended, and the following error message will be visible on the system console: tcpsignature_compute: SADB lookup failed for %d.%d.%d.%d. TCP_KEEPINIT If a TCP connection cannot be established within a period of time, TCP will time out the connection attempt. The TCP_KEEPINIT option specifies the number of milliseconds to wait before the connection attempt times out. The default value for TCP_KEEPINIT is tcp.keepinit milliseconds. For the accepted sockets, the TCP_KEEPINIT option value is inherited from the listening socket. TCP_KEEPIDLE When the SO_KEEPALIVE option is enabled, TCP sends a keepalive probe to the remote system of a connection that has been idle for a period of time. The TCP_KEEPIDLE spec- ifies the number of milliseconds before TCP will send the initial keepalive probe. The default value for TCP_KEEPIDLE is tcp.keepidle milliseconds. For the accepted sockets, the TCP_KEEPIDLE option value is inher- ited from the listening socket. TCP_KEEPINTVL When the SO_KEEPALIVE option is enabled, TCP sends a keepalive probe to the remote system of a connection that has been idle for a period of time. The TCP_KEEPINTVL option specifies the number of milliseconds to wait before retransmitting a keepalive probe. The default value for TCP_KEEPINTVL is tcp.keepintvl milliseconds. For the accepted sockets, the TCP_KEEPINTVL option value is inher- ited from the listening socket. TCP_KEEPCNT When the SO_KEEPALIVE option is enabled, TCP sends a keepalive probe to the remote system of a connection that has been idle for a period of time. The TCP_KEEPCNT option specifies the maximum number of keepalive probes to be sent before dropping the connection. The default value for TCP_KEEPCNT is tcp.keepcnt milliseconds. For the accepted sockets, the TCP_KEEPCNT option value is inherited from the listening socket. 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.

MIB VARIABLES

The tcp protocol implements a number of variables in the net.inet branch of the sysctl(3) MIB. TCPCTL_DO_RFC1323 (tcp.rfc1323) Implement the window scaling and time- stamp options of RFC 1323 (default true). TCPCTL_MSSDFLT (tcp.mssdflt) The default value used for the maximum segment size (``MSS'') when no advice to the contrary is received from MSS negotiation. TCPCTL_SENDSPACE (tcp.sendspace) Maximum TCP send window. TCPCTL_RECVSPACE (tcp.recvspace) Maximum TCP receive window. tcp.log_in_vain Log any connection attempts to ports where there is not a socket accepting connections. The value of 1 limits the logging to SYN (connection establishment) packets only. That of 2 results in any TCP packets to closed ports being logged. Any value unlisted above disables the logging (default is 0, i.e., the logging is disabled). tcp.msl The Maximum Segment Lifetime for a packet. tcp.keepinit Timeout for new, non-established TCP connections. tcp.keepidle Amount of time the connection should be idle before keepalive probes (if enabled) are sent. tcp.keepintvl The interval between keepalive probes sent to remote machines. After tcp.keepcnt (default 8) probes are sent, with no response, the connection is dropped. tcp.keepcnt The maximum number of keepalive probes to be sent before dropping the connection. tcp.always_keepalive Assume that SO_KEEPALIVE is set on all TCP connec- tions, the kernel will periodically send a packet to the remote host to verify the connection is still up. tcp.icmp_may_rst Certain ICMP unreachable messages may abort connec- tions in SYN-SENT state. tcp.do_tcpdrain Flush packets in the TCP reassembly queue if the sys- tem is low on mbufs. tcp.blackhole If enabled, disable sending of RST when a connection is attempted to a port where there is not a socket accepting connections. See blackhole(4). tcp.delayed_ack Delay ACK to try and piggyback it onto a data packet. tcp.delacktime Maximum amount of time before a delayed ACK is sent. tcp.newreno Enable TCP NewReno Fast Recovery algorithm, as described in RFC 2582. tcp.path_mtu_discovery Enables Path MTU Discovery. PMTU Discovery is helpful for avoiding IP fragmentation when tranferring lots of data to the same client. For web servers, where most of the connections are short and to different clients, PMTU Discovery actually hurts performance due to unnecessary retransmissions. Turn this on only if most of your TCP connections are long transfers or are repeatedly to the same set of clients. tcp.tcbhashsize Size of the TCP control-block hashtable (read-only). This may be tuned using the kernel option TCBHASHSIZE or by setting net.inet.tcp.tcbhashsize in the loader(8). tcp.pcbcount Number of active process control blocks (read-only). tcp.syncookies Determines whether or not syn cookies should be gener- ated for outbound syn-ack packets. Syn cookies are a great help during syn flood attacks, and are enabled by default. tcp.isn_reseed_interval The interval (in seconds) specifying how often the secret data used in RFC 1948 initial sequence number calculations should be reseeded. By default, this variable is set to zero, indicating that no reseeding will occur. Reseeding should not be necessary, and will break TIME_WAIT recycling for a few minutes. tcp.inet.tcp.rexmit_{min,slop} Adjust the retransmit timer calculation for TCP. The slop is typically added to the raw calculation to take into account occasional variances that the SRTT (smoothed round trip time) is unable to accommodate, while the minimum specifies an absolute minimum. While a number of TCP RFCs suggest a 1 second minimum these RFCs tend to focus on streaming behavior and fail to deal with the fact that a 1 second minimum has severe detrimental effects over lossy interactive con- nections, such as a 802.11b wireless link, and over very fast but lossy connections for those cases not covered by the fast retransmit code. For this reason we suggest changing the slop to 200ms and setting the minimum to something out of the way, like 20ms, which gives you an effective minimum of 200ms (similar to Linux). tcp.inflight_enable Enable TCP bandwidth delay product limiting. An attempt will be made to calculate the bandwidth delay product for each individual TCP connection and limit the amount of inflight data being transmitted to avoid building up unnecessary packets in the network. This option is recommended if you are serving a lot of data over connections with high bandwidth-delay products, such as modems, GigE links, and fast long-haul WANs, and/or you have configured your machine to accommodate large TCP windows. In such situations, without this option, you may experience high interactive latencies or packet loss due to the overloading of intermediate routers and switches. Note that bandwidth delay prod- uct limiting only affects the transmit side of a TCP connection. tcp.inflight_debug Enable debugging for the bandwidth delay product algo- rithm. This may default to on (1) so if you enable the algorithm you should probably also disable debug- ging by setting this variable to 0. tcp.inflight_min This puts an lower bound on the bandwidth delay prod- uct window, in bytes. A value of 1024 is typically used for debugging. 6000-16000 is more typical in a production installation. Setting this value too low may result in slow ramp-up times for bursty connec- tions. Setting this value too high effectively dis- ables the algorithm. tcp.inflight_max This puts an upper bound on the bandwidth delay prod- uct window, in bytes. This value should not generally be modified but may be used to set a global per-con- nection limit on queued data, potentially allowing you to intentionally set a less than optimum limit to smooth data flow over a network while still being able to specify huge internal TCP buffers. tcp.inflight_stab This value stabilizes the bwnd (write window) calcula- tion at high speeds by increasing the bandwidth calcu- lation in 1/10% increments. The default value of 50 represents a +5% increase. In addition, bwnd is fur- ther increased by a fixed 2*maxseg bytes to stabilize the algorithm at low speeds. Changing the stab value is not recommended, but you may come across situations where tuning is beneficial. However, our recommenda- tion for tuning is to stick with only adjusting tcp.inflight_min. Reducing tcp.inflight_stab too much can lead to upwards of a 20% underutilization of the link and prevent the algorithm from properly adapting to changing situations. Increasing tcp.inflight_stab too much can lead to an excessive packet buffering situation.

ERRORS

A socket operation may fail with one of the following errors returned: [EISCONN] when trying to establish a connection on a socket which already has one; [ENOBUFS] when the system runs out of memory for an internal data structure; [ETIMEDOUT] when a connection was dropped due to excessive retransmissions; [ECONNRESET] when the remote peer forces the connection to be closed; [ECONNREFUSED] when the remote peer actively refuses connection establishment (usually because no process is listening to the port); [EADDRINUSE] when an attempt is made to create a socket with a port which has already been allocated; [EADDRNOTAVAIL] when an attempt is made to create a socket with a net- work address for which no network interface exists. [EAFNOSUPPORT] when an attempt is made to bind or connect a socket to a multicast address.

SEE ALSO

getsockopt(2), socket(2), sysctl(3), blackhole(4), inet(4), intro(4), ip(4), setkey(8) V. Jacobson, R. Braden, and D. Borman, TCP Extensions for High Performance, RFC 1323. A. Heffernan, Protection of BGP Sessions via the TCP MD5 Signature Option, RFC 2385.

HISTORY

The tcp protocol appeared in 4.2BSD. The RFC 1323 extensions for window scaling and timestamps were added in 4.4BSD. DragonFly 4.1 February 14, 1995 DragonFly 4.1