9075 Improve ZFS pool import/load process and corrupted pool recovery
[unleashed.git] / usr / src / man / man7p / tcp.7p
blob1e555956a07ed8b3622f1801b2ca9361e2c898fb
1 '\" te
2 .\" Copyright (c) 2006, Sun Microsystems, Inc. All Rights Reserved.
3 .\" Copyright (c) 2011 Nexenta Systems, Inc. All rights reserved.
4 .\" Copyright 1989 AT&T
5 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
6 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
7 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
8 .TH TCP 7P "Feb 5, 2018"
9 .SH NAME
10 tcp, TCP \- Internet Transmission Control Protocol
11 .SH SYNOPSIS
12 .LP
13 .nf
14 \fB#include <sys/socket.h>\fR
15 .fi
17 .LP
18 .nf
19 \fB#include <netinet/in.h>\fR
20 .fi
22 .LP
23 .nf
24 \fBs = socket(AF_INET, SOCK_STREAM, 0);\fR
25 .fi
27 .LP
28 .nf
29 \fBs = socket(AF_INET6, SOCK_STREAM, 0);\fR
30 .fi
32 .LP
33 .nf
34 \fBt = t_open("/dev/tcp", O_RDWR);\fR
35 .fi
37 .LP
38 .nf
39 \fBt = t_open("/dev/tcp6", O_RDWR);\fR
40 .fi
42 .SH DESCRIPTION
43 .LP
44 \fBTCP\fR is the virtual circuit protocol of the Internet protocol family. It
45 provides reliable, flow-controlled, in order, two-way transmission of data. It
46 is a byte-stream protocol layered above the Internet Protocol (\fBIP\fR), or
47 the Internet Protocol Version 6 (\fBIPv6\fR), the Internet protocol family's
48 internetwork datagram delivery protocol.
49 .sp
50 .LP
51 Programs can access \fBTCP\fR using the socket interface as a \fBSOCK_STREAM\fR
52 socket type, or using the Transport Level Interface (\fBTLI\fR) where it
53 supports the connection-oriented (\fBT_COTS_ORD\fR) service type.
54 .sp
55 .LP
56 \fBTCP\fR uses \fBIP\fR's host-level addressing and adds its own per-host
57 collection of "port addresses." The endpoints of a \fBTCP\fR connection are
58 identified by the combination of an \fBIP\fR or IPv6 address and a \fBTCP\fR
59 port number. Although other protocols, such as the User Datagram Protocol
60 (UDP), may use the same host and port address format, the port space of these
61 protocols is distinct. See \fBinet\fR(7P) and \fBinet6\fR(7P) for details on
62 the common aspects of addressing in the Internet protocol family.
63 .sp
64 .LP
65 Sockets utilizing \fBTCP\fR are either "active" or "passive." Active sockets
66 initiate connections to passive sockets. Both types of sockets must have their
67 local \fBIP\fR or IPv6 address and \fBTCP\fR port number bound with the
68 \fBbind\fR(3SOCKET) system call after the socket is created. By default,
69 \fBTCP\fR sockets are active. A passive socket is created by calling the
70 \fBlisten\fR(3SOCKET) system call after binding the socket with \fBbind()\fR.
71 This establishes a queueing parameter for the passive socket. After this,
72 connections to the passive socket can be received with the
73 \fBaccept\fR(3SOCKET) system call. Active sockets use the
74 \fBconnect\fR(3SOCKET) call after binding to initiate connections.
75 .sp
76 .LP
77 By using the special value \fBINADDR_ANY\fR with \fBIP\fR, or the unspecified
78 address (all zeroes) with IPv6, the local \fBIP\fR address can be left
79 unspecified in the \fBbind()\fR call by either active or passive \fBTCP\fR
80 sockets. This feature is usually used if the local address is either unknown or
81 irrelevant. If left unspecified, the local \fBIP\fR or IPv6 address will be
82 bound at connection time to the address of the network interface used to
83 service the connection.
84 .sp
85 .LP
86 Note that no two TCP sockets can be bound to the same port unless the bound IP
87 addresses are different.  IPv4 \fBINADDR_ANY\fR and IPv6 unspecified addresses
88 compare as equal to any IPv4 or IPv6 address. For example, if a socket is bound
89 to \fBINADDR_ANY\fR or unspecified address and port X, no other socket can bind
90 to port X, regardless of the binding address. This special consideration of
91 \fBINADDR_ANY\fR and unspecified address can be changed using the socket option
92 \fBSO_REUSEADDR\fR. If \fBSO_REUSEADDR\fR is set on a socket doing a bind, IPv4
93 \fBINADDR_ANY\fR and IPv6 unspecified address do not compare as equal to any IP
94 address. This means that as long as the two sockets are not both bound to
95 \fBINADDR_ANY\fR/unspecified address or the same IP address, the two sockets
96 can be bound to the same port.
97 .sp
98 .LP
99 If an application does not want to allow another socket  using the
100 \fBSO_REUSEADDR\fR option to bind to a port its socket is bound to, the
101 application can set the socket level option \fBSO_EXCLBIND\fR on a socket. The
102 option values of 0 and 1 mean enabling and disabling the option respectively.
103 Once this option is enabled on a socket, no other socket can be bound to the
104 same port.
107 Once a connection has been established, data can be exchanged using the
108 \fBread\fR(2) and \fBwrite\fR(2) system calls.
111 Under most circumstances, \fBTCP\fR sends data when it is presented. When
112 outstanding data has not yet been acknowledged, \fBTCP\fR gathers small amounts
113 of output to be sent in a single packet once an acknowledgement has been
114 received. For a small number of clients, such as window systems that send a
115 stream of mouse events which receive no replies, this packetization may cause
116 significant delays. To circumvent this problem, \fBTCP\fR provides a
117 socket-level boolean option, \fBTCP_NODELAY.\fR \fBTCP_NODELAY\fR is defined in
118 \fB<netinet/tcp.h>\fR, and is set with \fBsetsockopt\fR(3SOCKET) and tested
119 with \fBgetsockopt\fR(3SOCKET). The option level for the \fBsetsockopt()\fR
120 call is the protocol number for \fBTCP,\fR available from
121 \fBgetprotobyname\fR(3SOCKET).
124 For some applications, it may be desirable for TCP not to send out data unless
125 a full TCP segment can be sent. To enable this behavior, an application can use
126 the \fBTCP_CORK\fR socket option. When \fBTCP_CORK\fR is set with a non-zero
127 value, TCP sends out a full TCP segment only. When \fBTCP_CORK\fR is set to
128 zero after it has been enabled, all buffered data is sent out (as permitted by
129 the peer's receive window and the current congestion window). \fBTCP_CORK\fR is
130 defined in <\fBnetinet/tcp.h\fR>,  and is set with \fBsetsockopt\fR(3SOCKET)
131 and tested with \fBgetsockopt\fR(3SOCKET). The option level for the
132 \fBsetsockopt()\fR call is the protocol  number  for TCP, available from
133 \fBgetprotobyname\fR(3SOCKET).
136 The \fBSO_RCVBUF\fR socket level option can be used to control the window
137 that \fBTCP\fR advertises to the peer. \fBIP\fR level options may also be used
138 with \fBTCP.\fR See \fBip\fR(7P) and \fBip6\fR(7P).
141 \fBTCP\fR provides an urgent data mechanism, which may be invoked using the
142 out-of-band provisions of \fBsend\fR(3SOCKET). The caller may mark one byte as
143 "urgent" with the \fBMSG_OOB\fR flag to \fBsend\fR(3SOCKET). This sets an
144 "urgent pointer" pointing to this byte in the \fBTCP\fR stream. The receiver on
145 the other side of the stream is notified of the urgent data by a \fBSIGURG\fR
146 signal. The \fBSIOCATMARK\fR \fBioctl\fR(2) request returns a value indicating
147 whether the stream is at the urgent mark. Because the system never returns data
148 across the urgent mark in a single \fBread\fR(2) call, it is possible to
149 advance to the urgent data in a simple loop which reads data, testing the
150 socket with the \fBSIOCATMARK\fR \fBioctl()\fR request, until it reaches the
151 mark.
154 Incoming connection requests that include an \fBIP\fR source route option are
155 noted, and the reverse source route is used in responding.
158 A checksum over all data helps \fBTCP\fR implement reliability. Using a
159 window-based flow control mechanism that makes use of positive
160 acknowledgements, sequence numbers, and a retransmission strategy, \fBTCP\fR
161 can usually recover when datagrams are damaged, delayed, duplicated or
162 delivered out of order by the underlying communication medium.
165 If the local \fBTCP\fR receives no acknowledgements from its peer for a period
166 of time, (for example, if the remote machine crashes), the connection is closed
167 and an error is returned.
170 TCP follows the congestion control algorithm described in \fIRFC 2581\fR, and
171 also supports the initial congestion window (cwnd) changes in \fIRFC 3390\fR.
172 The initial cwnd calculation can be overridden by the socket option
173 TCP_INIT_CWND. An application can use this option to set the initial cwnd to a
174 specified number of TCP segments. This applies to the cases when the connection
175 first starts and restarts after an idle period.  The process must have the
176 PRIV_SYS_NET_CONFIG privilege if it wants to specify a number greater than that
177 calculated by \fIRFC 3390\fR.
180 illumos supports \fBTCP\fR Extensions for High Performance (\fIRFC 7323\fR)
181 which includes the window scale and timestamp options, and Protection Against
182 Wrap Around Sequence Numbers (PAWS). Note that if timestamps are negotiated on
183 a connection, received segments without timestamps on that connection are
184 silently dropped per the suggestion in the RFC. illumos also supports Selective
185 Acknowledgment (SACK) capabilities (RFC 2018) and Explicit Congestion
186 Notification (ECN) mechanism (\fIRFC 3168\fR).
189 Turn on the window scale option in one of the following ways:
190 .RS +4
192 .ie t \(bu
193 .el o
194 An application can set \fBSO_SNDBUF\fR or \fBSO_RCVBUF\fR size in the
195 \fBsetsockopt()\fR option to be larger than 64K. This must be done \fIbefore\fR
196 the program calls \fBlisten()\fR or \fBconnect()\fR, because the window scale
197 option is negotiated when the connection is established. Once the connection
198 has been made, it is too late to increase the send or receive window beyond the
199 default \fBTCP\fR limit of 64K.
201 .RS +4
203 .ie t \(bu
204 .el o
205 For all applications, use \fBndd\fR(1M) to modify the configuration parameter
206 \fBtcp_wscale_always\fR. If \fBtcp_wscale_always\fR is set to \fB1\fR, the
207 window scale option will always be set when connecting to a remote system. If
208 \fBtcp_wscale_always\fR is \fB0,\fR the window scale option will be set only if
209 the user has requested a send or receive window larger than 64K. The default
210 value of \fBtcp_wscale_always\fR is \fB1\fR.
212 .RS +4
214 .ie t \(bu
215 .el o
216 Regardless of the value of \fBtcp_wscale_always\fR, the window scale option
217 will always be included in a connect acknowledgement if the connecting system
218 has used the option.
222 Turn on \fBSACK\fR capabilities in the following way:
223 .RS +4
225 .ie t \(bu
226 .el o
227 Use \fBndd\fR to modify the configuration parameter \fBtcp_sack_permitted\fR.
228 If \fBtcp_sack_permitted\fR is set to \fB0\fR, \fBTCP\fR will not accept
229 \fBSACK\fR or send out \fBSACK\fR information. If \fBtcp_sack_permitted\fR is
230 set to \fB1\fR, \fBTCP\fR will not initiate a connection with \fBSACK\fR
231 permitted option in the \fBSYN\fR segment, but will respond with \fBSACK\fR
232 permitted option in the \fBSYN|ACK\fR segment if an incoming connection request
233 has the \fBSACK \fR permitted option. This means that \fBTCP\fR will only
234 accept \fBSACK\fR information if the other side of the connection also accepts
235 \fBSACK\fR information. If \fBtcp_sack_permitted\fR is set to \fB2\fR, it will
236 both initiate and accept connections with \fBSACK\fR information. The default
237 for \fBtcp_sack_permitted\fR is \fB2\fR (active enabled).
241 Turn on \fBTCP ECN\fR mechanism in the following way:
242 .RS +4
244 .ie t \(bu
245 .el o
246 Use \fBndd\fR to modify the configuration parameter \fBtcp_ecn_permitted\fR. If
247 \fBtcp_ecn_permitted\fR is set to \fB0\fR, \fBTCP\fR will not negotiate with a
248 peer that supports \fBECN\fR mechanism. If \fBtcp_ecn_permitted\fR is set to
249 \fB1\fR when initiating a connection, TCP will not tell a peer that it supports
250 ECN mechanism. However, it will tell a peer that it supports \fBECN\fR
251 mechanism when accepting a new incoming connection request if the peer
252 indicates that it supports \fBECN\fR mechanism in the SYN segment. If
253 tcp_ecn_permitted is set to 2, in addition to negotiating with a peer on ECN
254 mechanism when accepting connections, TCP will indicate in the outgoing SYN
255 segment that it supports \fBECN\fR mechanism when \fBTCP\fR makes active
256 outgoing connections. The default for \fBtcp_ecn_permitted\fR is 1.
260 Turn on the timestamp option in the following way:
261 .RS +4
263 .ie t \(bu
264 .el o
265 Use \fBndd\fR to modify the configuration parameter \fBtcp_tstamp_always\fR. If
266 \fBtcp_tstamp_always\fR is \fB1\fR, the timestamp option will always be set
267 when connecting to a remote machine. If \fBtcp_tstamp_always\fR is \fB0\fR, the
268 timestamp option will not be set when connecting to a remote system. The
269 default for \fBtcp_tstamp_always\fR is \fB0\fR.
271 .RS +4
273 .ie t \(bu
274 .el o
275 Regardless of the value of \fBtcp_tstamp_always\fR, the timestamp option will
276 always be included in a connect acknowledgement (and all succeeding packets) if
277 the connecting system has used the timestamp option.
281 Use the following procedure to turn on the timestamp option only when the
282 window scale option is in effect:
283 .RS +4
285 .ie t \(bu
286 .el o
287 Use \fBndd\fR to modify the configuration parameter \fBtcp_tstamp_if_wscale\fR.
288 Setting \fBtcp_tstamp_if_wscale\fR to \fB1\fR will cause the timestamp option
289 to be set when connecting to a remote system, if the window scale option has
290 been set. If \fBtcp_tstamp_if_wscale\fR is \fB0\fR, the timestamp option will
291 not be set when connecting to a remote system. The default for
292 \fBtcp_tstamp_if_wscale\fR is \fB1\fR.
296 Protection Against Wrap Around Sequence Numbers (PAWS) is always used when the
297 timestamp option is set.
300 SunOS also supports multiple methods of generating initial sequence numbers.
301 One of these methods is the improved technique suggested in \fBRFC\fR 1948. We
302 \fBHIGHLY\fR recommend that you set sequence number generation parameters as
303 close to boot time as possible. This prevents sequence number problems on
304 connections that use the same connection-ID as ones that used a different
305 sequence number generation. The \fBsvc:/network/initial:default\fR service
306 configures the initial sequence number generation.  The service reads the value
307 contained in the configuration file \fB/etc/default/inetinit\fR to determine
308 which method to use.
311 The \fB/etc/default/inetinit\fR file is an unstable interface, and may change
312 in future releases.
315 \fBTCP\fR may be configured to report some information on connections that
316 terminate by means of an \fBRST\fR packet. By default, no logging is done. If
317 the \fBndd\fR(1M) parameter \fItcp_trace\fR is set to 1, then trace data is
318 collected for all new connections established after that time.
321 The trace data consists of the \fBTCP\fR headers and \fBIP\fR source and
322 destination addresses of the last few packets sent in each direction before RST
323 occurred. Those packets are logged in a series of \fBstrlog\fR(9F) calls. This
324 trace facility has a very low overhead, and so is superior to such utilities as
325 \fBsnoop\fR(1M) for non-intrusive debugging for connections terminating by
326 means of an \fBRST\fR.
329 SunOS supports the keep-alive mechanism described in \fIRFC 1122\fR. It is
330 enabled using the socket option SO_KEEPALIVE. When enabled, the first
331 keep-alive probe is sent out after a TCP is idle for two hours If the peer does
332 not respond to the probe within eight minutes, the TCP connection is aborted.
333 You can alter the interval for sending out the first probe using the socket
334 option TCP_KEEPALIVE_THRESHOLD. The option value is an unsigned integer in
335 milliseconds. The system default is controlled by the TCP ndd parameter
336 tcp_keepalive_interval. The minimum value is ten seconds. The maximum is ten
337 days, while the default is two hours. If you receive no response to the probe,
338 you can use the TCP_KEEPALIVE_ABORT_THRESHOLD socket option to change the time
339 threshold for aborting a TCP connection. The option value is an unsigned
340 integer in milliseconds. The value zero indicates that TCP should never time
341 out and abort the connection when probing. The system default is controlled by
342 the TCP ndd parameter tcp_keepalive_abort_interval. The default is eight
343 minutes.
346 socket options TCP_KEEPIDLE, TCP_KEEPCNT and TCP_KEEPINTVL are also supported
347 for compatibility with other Unix Flavors. TCP_KEEPIDLE option specifies the
348 interval in seconds for sending out the first keep-alive probe. TCP_KEEPCNT
349 specifies the number of keep-alive probes to be sent before aborting the
350 connection in the event of no response from peer. TCP_KEEPINTVL specifies the
351 interval in seconds between successive keep-alive probes.
352 .SH SEE ALSO
354 \fBsvcs\fR(1), \fBndd\fR(1M), \fBioctl\fR(2), \fBread\fR(2), \fBsvcadm\fR(1M),
355 \fBwrite\fR(2), \fBaccept\fR(3SOCKET), \fBbind\fR(3SOCKET),
356 \fBconnect\fR(3SOCKET), \fBgetprotobyname\fR(3SOCKET),
357 \fBgetsockopt\fR(3SOCKET), \fBlisten\fR(3SOCKET), \fBsend\fR(3SOCKET),
358 \fBsmf\fR(5), \fBinet\fR(7P), \fBinet6\fR(7P), \fBip\fR(7P), \fBip6\fR(7P)
361 Ramakrishnan, K., Floyd, S., Black, D., RFC 3168, \fIThe Addition of Explicit
362 Congestion Notification (ECN) to IP\fR, September 2001.
365 Mathias, M. and Hahdavi, J. Pittsburgh Supercomputing Center; Ford, S. Lawrence
366 Berkeley National Laboratory; Romanow, A. Sun Microsystems, Inc. \fIRFC 2018,
367 TCP Selective Acknowledgement Options\fR, October 1996.
370 Bellovin, S., \fIRFC 1948, Defending Against Sequence Number Attacks\fR, May
371 1996.
374 D. Borman, B. Braden, V. Jacobson and R. Scheffenegger, Ed., \fIRFC 7323, TCP
375 Extensions for High Performance\fR, September 2014.
378 Postel, Jon, \fIRFC 793, Transmission Control Protocol - DARPA Internet Program
379 Protocol Specification\fR, Network Information Center, SRI International, Menlo
380 Park, CA., September 1981.
381 .SH DIAGNOSTICS
383 A socket operation may fail if:
385 .ne 2
387 \fB\fBEISCONN\fR\fR
389 .RS 17n
390 A \fBconnect()\fR operation was attempted on a socket on which a
391 \fBconnect()\fR operation had already been performed.
395 .ne 2
397 \fB\fBETIMEDOUT\fR\fR
399 .RS 17n
400 A connection was dropped due to excessive retransmissions.
404 .ne 2
406 \fB\fBECONNRESET\fR\fR
408 .RS 17n
409 The remote peer forced the connection to be closed (usually because the remote
410 machine has lost state information about the connection due to a crash).
414 .ne 2
416 \fB\fBECONNREFUSED\fR\fR
418 .RS 17n
419 The remote peer actively refused connection establishment (usually because no
420 process is listening to the port).
424 .ne 2
426 \fB\fBEADDRINUSE\fR\fR
428 .RS 17n
429 A \fBbind()\fR operation was attempted on a socket with a network address/port
430 pair that has already been bound to another socket.
434 .ne 2
436 \fB\fBEADDRNOTAVAIL\fR\fR
438 .RS 17n
439 A \fBbind()\fR operation was attempted on a socket with a network address for
440 which no network interface exists.
444 .ne 2
446 \fB\fBEACCES\fR\fR
448 .RS 17n
449 A \fBbind()\fR operation was attempted with a "reserved" port number and the
450 effective user \fBID\fR of the process was not the privileged user.
454 .ne 2
456 \fB\fBENOBUFS\fR\fR
458 .RS 17n
459 The system ran out of memory for internal data structures.
462 .SH NOTES
464 The \fBtcp\fR service is managed by the service management facility,
465 \fBsmf\fR(5), under the service identifier:
467 .in +2
469 svc:/network/initial:default
471 .in -2
476 Administrative actions on this service, such as enabling, disabling, or
477 requesting restart, can be performed using \fBsvcadm\fR(1M). The service's
478 status can be queried using the \fBsvcs\fR(1) command.