1 .\" Copyright (c) 1983, 1991, 1993
2 .\" The Regents of the University of California. All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 3. All advertising materials mentioning features or use of this software
13 .\" must display the following acknowledgement:
14 .\" This product includes software developed by the University of
15 .\" California, Berkeley and its contributors.
16 .\" 4. Neither the name of the University nor the names of its contributors
17 .\" may be used to endorse or promote products derived from this software
18 .\" without specific prior written permission.
20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32 .\" From: @(#)tcp.4 8.1 (Berkeley) 6/5/93
33 .\" $FreeBSD: src/share/man/man4/tcp.4,v 1.11.2.14 2002/12/29 16:35:38 schweikh Exp $
34 .\" $DragonFly: src/share/man/man4/tcp.4,v 1.9 2008/10/17 11:30:24 swildner Exp $
41 .Nd Internet Transmission Control Protocol
47 .Fn socket AF_INET SOCK_STREAM 0
51 protocol provides reliable, flow-controlled, two-way
52 transmission of data. It is a byte-stream protocol used to
55 abstraction. TCP uses the standard
56 Internet address format and, in addition, provides a per-host
59 Thus, each address is composed
60 of an Internet address specifying the host and network, with
63 port on the host identifying the peer entity.
65 Sockets utilizing the tcp protocol are either
69 Active sockets initiate connections to passive
72 sockets are created active; to create a
75 system call must be used
76 after binding the socket with the
79 passive sockets may use the
81 call to accept incoming connections. Only active sockets may
84 call to initiate connections.
88 their location to match
89 incoming connection requests from multiple networks. This
91 .Dq wildcard addressing ,
93 server to provide service to clients on multiple networks.
94 To create a socket which listens on all networks, the Internet
99 port may still be specified
100 at this time; if the port is not specified the system will assign one.
101 Once a connection has been established the socket's address is
102 fixed by the peer entity's location. The address assigned the
103 socket is the address associated with the network interface
104 through which packets are being transmitted and received. Normally
105 this address corresponds to the peer entity's network.
108 supports a number of socket options which can be set with
112 .Bl -tag -width TCP_NODELAYx
114 Under most circumstances,
116 sends data when it is presented;
117 when outstanding data has not yet been acknowledged, it gathers
118 small amounts of output to be sent in a single packet once
119 an acknowledgement is received.
120 For a small number of clients, such as window systems
121 that send a stream of mouse events which receive no replies,
122 this packetization may cause significant delays.
125 defeats this algorithm.
127 By default, a sender\- and receiver-TCP
128 will negotiate among themselves to determine the maximum segment size
129 to be used for each connection. The
131 option allows the user to determine the result of this negotiation,
132 and to reduce it if desired.
135 usually sends a number of options in each packet, corresponding to
138 extensions which are provided in this implementation. The boolean
141 is provided to disable
143 option use on a per-connection basis.
145 By convention, the sender-TCP
148 bit and begin transmission immediately (if permitted) at the end of
155 option is set to a non-zero value,
157 will delay sending any data at all until either the socket is closed,
158 or the internal send buffer is filled.
161 The option level for the
163 call is the protocol number for
166 .Xr getprotobyname 3 ,
169 All options are declared in
174 transport level may be used with
178 Incoming connection requests that are source-routed are noted,
179 and the reverse source route is used in responding.
183 protocol implements a number of variables in the
188 .Bl -tag -width TCPCTL_DO_RFC1644
189 .It Dv TCPCTL_DO_RFC1323
191 Implement the window scaling and timestamp options of RFC 1323
193 .It Dv TCPCTL_MSSDFLT
195 The default value used for the maximum segment size
197 when no advice to the contrary is received from MSS negotiation.
198 .It Dv TCPCTL_SENDSPACE
200 Maximum TCP send window.
201 .It Dv TCPCTL_RECVSPACE
203 Maximum TCP receive window.
205 Log any connection attempts to ports where there is not a socket
206 accepting connections.
207 The value of 1 limits the logging to SYN (connection establishment)
209 That of 2 results in any TCP packets to closed ports being logged.
210 Any value unlisted above disables the logging
211 (default is 0, i.e., the logging is disabled).
213 The Maximum Segment Lifetime for a packet.
215 Timeout for new, non-established TCP connections.
217 Amount of time the connection should be idle before keepalive
218 probes (if enabled) are sent.
220 The interval between keepalive probes sent to remote machines.
223 (default 8) probes are sent, with no response, the connection is dropped.
224 .It tcp.always_keepalive
229 connections, the kernel will
230 periodically send a packet to the remote host to verify the connection
235 unreachable messages may abort connections in
241 reassembly queue if the system is low on mbufs.
243 If enabled, disable sending of RST when a connection is attempted
244 to a port where there is not a socket accepting connections.
248 Delay ACK to try and piggyback it onto a data packet.
250 Maximum amount of time before a delayed ACK is sent.
252 Enable TCP NewReno Fast Recovery algorithm,
253 as described in RFC 2582.
254 .It tcp.path_mtu_discovery
255 Enables Path MTU Discovery. PMTU Discovery is helpful for avoiding
256 IP fragmentation when tranferring lots of data to the same client.
257 For web servers, where most of the connections are short and to
258 different clients, PMTU Discovery actually hurts performance due
259 to unnecessary retransmissions. Turn this on only if most of your
260 TCP connections are long transfers or are repeatedly to the same
265 control-block hashtable
267 This may be tuned using the kernel option
270 .Va net.inet.tcp.tcbhashsize
274 Number of active process control blocks
277 Determines whether or not syn cookies should be generated for
278 outbound syn-ack packets. Syn cookies are a great help during
279 syn flood attacks, and are enabled by default.
280 .It tcp.isn_reseed_interval
281 The interval (in seconds) specifying how often the secret data used in
282 RFC 1948 initial sequence number calculations should be reseeded.
283 By default, this variable is set to zero, indicating that
284 no reseeding will occur.
285 Reseeding should not be necessary, and will break
287 recycling for a few minutes.
288 .It tcp.inet.tcp.rexmit_{min,slop}
289 Adjust the retransmit timer calculation for TCP. The slop is
290 typically added to the raw calculation to take into account
291 occasional variances that the SRTT (smoothed round trip time)
292 is unable to accommodate, while the minimum specifies an
293 absolute minimum. While a number of TCP RFCs suggest a 1
294 second minimum these RFCs tend to focus on streaming behavior
295 and fail to deal with the fact that a 1 second minimum has severe
296 detrimental effects over lossy interactive connections, such
297 as a 802.11b wireless link, and over very fast but lossy
298 connections for those cases not covered by the fast retransmit
299 code. For this reason we suggest changing the slop to 200ms and
300 setting the minimum to something out of the way, like 20ms,
301 which gives you an effective minimum of 200ms (similar to Linux).
302 .It tcp.inflight_enable
305 bandwidth delay product limiting. An attempt will be made to calculate
306 the bandwidth delay product for each individual TCP connection and limit
307 the amount of inflight data being transmitted to avoid building up
308 unnecessary packets in the network. This option is recommended if you
309 are serving a lot of data over connections with high bandwidth-delay
310 products, such as modems, GigE links, and fast long-haul WANs, and/or
311 you have configured your machine to accommodate large TCP windows. In such
312 situations, without this option, you may experience high interactive
313 latencies or packet loss due to the overloading of intermediate routers
314 and switches. Note that bandwidth delay product limiting only affects
315 the transmit side of a TCP connection.
316 .It tcp.inflight_debug
317 Enable debugging for the bandwidth delay product algorithm. This may
318 default to on (1) so if you enable the algorithm you should probably also
319 disable debugging by setting this variable to 0.
321 This puts an lower bound on the bandwidth delay product window, in bytes.
322 A value of 1024 is typically used for debugging. 6000-16000 is more typical
323 in a production installation. Setting this value too low may result in
324 slow ramp-up times for bursty connections. Setting this value too high
325 effectively disables the algorithm.
327 This puts an upper bound on the bandwidth delay product window, in bytes.
328 This value should not generally be modified but may be used to set a
329 global per-connection limit on queued data, potentially allowing you to
330 intentionally set a less than optimum limit to smooth data flow over a
331 network while still being able to specify huge internal TCP buffers.
332 .It tcp.inflight_stab
333 The bandwidth delay product algorithm requires a slightly larger window
334 than it otherwise calculates for stability. This parameter determines the
335 extra window in maximal packets / 10. The default value of 20 represents
336 2 maximal packets. Reducing this value is not recommended but you may
337 come across a situation with very slow links where the ping time
338 reduction of the default inflight code is not sufficient. If this case
339 occurs you should first try reducing tcp.inflight_min and, if that does not
340 work, reduce both tcp.inflight_min and tcp.inflight_stab, trying values of
341 15, 10, or 5 for the latter. Never use a value less than 5. Reducing
342 tcp.inflight_stab can lead to upwards of a 20% underutilization of the link
343 as well as reducing the algorithm's ability to adapt to changing
344 situations and should only be done as a last resort.
347 A socket operation may fail with one of the following errors returned:
350 when trying to establish a connection on a socket which
353 when the system runs out of memory for
354 an internal data structure;
356 when a connection was dropped
357 due to excessive retransmissions;
360 forces the connection to be closed;
361 .It Bq Er ECONNREFUSED
363 peer actively refuses connection establishment (usually because
364 no process is listening to the port);
367 is made to create a socket with a port which has already been
369 .It Bq Er EADDRNOTAVAIL
370 when an attempt is made to create a
371 socket with a network address for which no network interface
373 .It Bq Er EAFNOSUPPORT
374 when an attempt is made to bind or connect a socket to a multicast
389 .%T "TCP Extensions for High Performance"
397 The RFC 1323 extensions for window scaling and timestamps were added