三次握手

当一个TCP连接建立时，发生了以下场景：

最少需要三次包交换，因此称作TCP的三次握手，如下图所示：
图示： TCP 的三次握手

We show the client's initial sequence number as J and the server's initial sequence number as K. The acknowledgment number in an ACK is the next expected sequence number for the end sending the ACK. Since a SYN occupies one byte of the sequence number space, the acknowledgment number in the ACK of each SYN is the initial sequence number plus one. Similarly, the ACK of each FIN is the sequence number of the FIN plus one.

An everyday analogy for establishing a TCP connection is the telephone system [Nemeth 1997]. The socket function is the equivalent of having a telephone to use. bind is telling other people your telephone number so that they can call you. listen is turning on the ringer so that you will hear when an incoming call arrives. connect requires that we know the other person's phone number and dial it. accept is when the person being called answers the phone. Having the client's identity returned by accept (where the identify is the client's IP address and port number) is similar to having the caller ID feature show the caller's phone number. One difference, however, is that accept returns the client's identity only after the connection has been established, whereas the caller ID feature shows the caller's phone number before we choose whether to answer the phone or not. If the DNS is used (Chapter 11), it provides a service analogous to a telephone book. getaddrinfo is similar to looking up a person's phone number in the phone book. getnameinfo would be the equivalent of having a phone book sorted by telephone numbers that we could search, instead of a book sorted by name.

TCP 选项

Each SYN can contain TCP options. Commonly used options include the following:

• MSS option. With this option, the TCP sending the SYN announces its maximum segment size, the maximum amount of data that it is willing to accept in each TCP segment, on this connection. The sending TCP uses the receiver's MSS value as the maximum size of a segment that it sends. We will see how to fetch and set this TCP option with the TCP_MAXSEG socket option (Section 7.9).

• Window scale option. The maximum window that either TCP can advertise to the other TCP is 65,535, because the corresponding field in the TCP header occupies 16 bits. But, high-speed connections, common in today's Internet (45 Mbits/sec and faster, as described in RFC 1323 [Jacobson, Braden, and Borman 1992]), or long delay paths (satellite links) require a larger window to obtain the maximum throughput possible. This newer option specifies that the advertised window in the TCP header must be scaled (left-shifted) by 0–14 bits, providing a maximum window of almost one gigabyte (65,535 x 2¹⁴). Both end-systems must support this option for the window scale to be used on a connection. We will see how to affect this option with the SO_RCVBUF socket option (Section 7.5).

  To provide interoperability with older implementations that do not support this option, the following rules apply. TCP can send the option with its SYN as part of an active open. But, it can scale its windows only if the other end also sends the option with its SYN. Similarly, the server's TCP can send this option only if it receives the option with the client's SYN. This logic assumes that implementations ignore options that they do not understand, which is required and common, but unfortunately, not guaranteed with all implementations.

• Timestamp option. This option is needed for high-speed connections to prevent possible data corruption caused by old, delayed, or duplicated segments. Since it is a newer option, it is negotiated similarly to the window scale option. As network programmers there is nothing we need to worry about with this option.

These common options are supported by most implementations. The latter two are sometimes called the "RFC 1323 options," as that RFC [Jacobson, Braden, and Borman 1992] specifies the options. They are also called the "long fat pipe options," since a network with either a high bandwidth or a long delay is called a long fat pipe. Chapter 24 of TCPv1 contains more details on these options.

TCP 连接的终止

TCP建立时需要三次通知，而终止一个TCP连接时需要四次通知。
One application calls close first, and we say that this end performs the active close. This end's TCP sends a FIN segment, which means it is finished sending data.

1. The other end that receives the FIN performs the passive close. The received FIN is acknowledged by TCP. The receipt of the FIN is also passed to the application as an end-of-file (after any data that may have already been queued for the application to receive), since the receipt of the FIN means the application will not receive any additional data on the connection.

2. Sometime later, the application that received the end-of-file will close its socket. This causes its TCP to send a FIN.

3. The TCP on the system that receives this final FIN (the end that did the active close) acknowledges the FIN.

Since a FIN and an ACK are required in each direction, four segments are normally required. We use the qualifier "normally" because in some scenarios, the FIN in Step 1 is sent with data. Also, the segments in Steps 2 and 3 are both from the end performing the passive close and could be combined into one segment. We show these packets in Figure 2.3.

A FIN occupies one byte of sequence number space just like a SYN. Therefore, the ACK of each FIN is the sequence number of the FIN plus one.

Between Steps 2 and 3 it is possible for data to flow from the end doing the passive close to the end doing the active close. This is called a half-close and we will talk about this in detail with the shutdown function in Section 6.6.

The sending of each FIN occurs when a socket is closed. We indicated that the application calls close for this to happen, but realize that when a Unix process terminates, either voluntarily (calling exit or having the main function return) or involuntarily (receiving a signal that terminates the process), all open descriptors are closed, which will also cause a FIN to be sent on any TCP connection that is still open.

Although we show the client in Figure 2.3 performing the active close, either end—the client or the server—can perform the active close. Often the client performs the active close, but with some protocols (notably HTTP/1.0), the server performs the active close.

TCP 状态转换图

关于TCP连接的建立和终止操作可以由一个状态转换图来详细说明，如下图所示：
图示：TCP 状态转换图

There are 11 different states defined for a connection and the rules of TCP dictate the transitions from one state to another, based on the current state and the segment received in that state. For example, if an application performs an active open in the CLOSED state, TCP sends a SYN and the new state is SYN_SENT. If TCP next receives a SYN with an ACK, it sends an ACK and the new state is ESTABLISHED. This final state is where most data transfer occurs.

The two arrows leading from the ESTABLISHED state deal with the termination of a connection. If an application calls close before receiving a FIN (an active close), the transition is to the FIN_WAIT_1 state. But if an application receives a FIN while in the ESTABLISHED state (a passive close), the transition is to the CLOSE_WAIT state.

We denote the normal client transitions with a darker solid line and the normal server transitions with a darker dashed line. We also note that there are two transitions that we have not talked about: a simultaneous open (when both ends send SYNs at about the same time and the SYNs cross in the network) and a simultaneous close (when both ends send FINs at the same time). Chapter 18 of TCPv1 contains examples and a discussion of both scenarios, which are possible but rare.

One reason for showing the state transition diagram is to show the 11 TCP states with their names. These states are displayed by netstat, which is a useful tool when debugging client/server applications. We will use netstat to monitor state changes in Chapter 5.

观察包（Watching the Packets）

下土显示了一个TCP连接实际发生的包交换情况：连接建立，数据传输和连接终止。在每一端传输的时候，也给出了TCP状态。 
TCP 连接的包交换

The client in this example announces an MSS of 536 (indicating that it implements only the minimum reassembly buffer size) and the server announces an MSS of 1,460 (typical for IPv4 on an Ethernet). It is okay for the MSS to be different in each direction (see Exercise 2.5).

Once a connection is established, the client forms a request and sends it to the server. We assume this request fits into a single TCP segment (i.e., less than 1,460 bytes given the server's announced MSS). The server processes the request and sends a reply, and we assume that the reply fits in a single segment (less than 536 in this example). We show both data segments as bolder arrows. Notice that the acknowledgment of the client's request is sent with the server's reply. This is called piggybacking and will normally happen when the time it takes the server to process the request and generate the reply is less than around 200 ms. If the server takes longer, say one second, we would see the acknowledgment followed later by the reply. (The dynamics of TCP data flow are covered in detail in Chapters 19 and 20 of TCPv1.)

We then show the four segments that terminate the connection. Notice that the end that performs the active close (the client in this scenario) enters the TIME_WAIT state. We will discuss this in the next section.

It is important to notice in Figure 2.5 that if the entire purpose of this connection was to send a one-segment request and receive a one-segment reply, there would be eight segments of overhead involved when using TCP. If UDP was used instead, only two packets would be exchanged: the request and the reply. But switching from TCP to UDP removes all the reliability that TCP provides to the application, pushing lots of these details from the transport layer (TCP) to the UDP application. Another important feature provided by TCP is congestion control, which must then be handled by the UDP application. Nevertheless, it is important to understand that many applications are built using UDP because the application exchanges small amounts of data and UDP avoids the overhead of TCP connection establishment and connection termination.

TIME_WAIT 状态

毫无疑问，关于网络编程中最让人误解点之一就是 TIME_WAIT 状态。 在一端调用了close之后，该端维持这个状态的时间为两倍最大段生存时间（maximum segment lifetime (MSL)）。

Every implementation of TCP must choose a value for the MSL. The recommended value in RFC 1122 [Braden 1989] is 2 minutes, although Berkeley-derived implementations have traditionally used a value of 30 seconds instead. This means the duration of the TIME_WAIT state is between 1 and 4 minutes. The MSL is the maximum amount of time that any given IP datagram can live in a network. We know this time is bounded because every datagram contains an 8-bit hop limit (the IPv4 TTL field in Figure A.1 and the IPv6 hop limit field in Figure A.2) with a maximum value of 255. Although this is a hop limit and not a true time limit, the assumption is made that a packet with the maximum hop limit of 255 cannot exist in a network for more than MSL seconds.

The way in which a packet gets "lost" in a network is usually the result of routing anomalies. A router crashes or a link between two routers goes down and it takes the routing protocols seconds or minutes to stabilize and find an alternate path. During that time period, routing loops can occur (router A sends packets to router B, and B sends them back to A) and packets can get caught in these loops. In the meantime, assuming the lost packet is a TCP segment, the sending TCP times out and retransmits the packet, and the retransmitted packet gets to the final destination by some alternate path. But sometime later (up to MSL seconds after the lost packet started on its journey), the routing loop is corrected and the packet that was lost in the loop is sent to the final destination. This original packet is called a lost duplicate or a wandering duplicate. TCP must handle these duplicates.

There are two reasons for the TIME_WAIT state:

The first reason can be explained by looking at Figure 2.5 and assuming that the final ACK is lost. The server will resend its final FIN, so the client must maintain state information, allowing it to resend the final ACK. If it did not maintain this information, it would respond with an RST (a different type of TCP segment), which would be interpreted by the server as an error. If TCP is performing all the work necessary to terminate both directions of data flow cleanly for a connection (its full-duplex close), then it must correctly handle the loss of any of these four segments. This example also shows why the end that performs the active close is the end that remains in the TIME_WAIT state: because that end is the one that might have to retransmit the final ACK.

To understand the second reason for the TIME_WAIT state, assume we have a TCP connection between 12.106.32.254 port 1500 and 206.168.112.219 port 21. This connection is closed and then sometime later, we establish another connection between the same IP addresses and ports: 12.106.32.254 port 1500 and 206.168.112.219 port 21. This latter connection is called an incarnation of the previous connection since the IP addresses and ports are the same. TCP must prevent old duplicates from a connection from reappearing at some later time and being misinterpreted as belonging to a new incarnation of the same connection. To do this, TCP will not initiate a new incarnation of a connection that is currently in the TIME_WAIT state. Since the duration of the TIME_WAIT state is twice the MSL, this allows MSL seconds for a packet in one direction to be lost, and another MSL seconds for the reply to be lost. By enforcing this rule, we are guaranteed that when we successfully establish a TCP connection, all old duplicates from previous incarnations of the connection have expired in the network.

There is an exception to this rule. Berkeley-derived implementations will initiate a new incarnation of a connection that is currently in the TIME_WAIT state if the arriving SYN has a sequence number that is "greater than" the ending sequence number from the previous incarnation. Pages 958–959 of TCPv2 talk about this in more detail. This requires the server to perform the active close, since the TIME_WAIT state must exist on the end that receives the next SYN. This capability is used by the rsh command. RFC 1185 [Jacobson, Braden, and Zhang 1990] talks about some pitfalls in doing this.

一般网络程序所使用的协议 下图总结了一些： Figure 2.19. Protocol usage of various common Internet applications. The first two applications, ping and traceroute, are diagnostic applications that use ICMP. traceroute builds its own UDP packets to send and reads ICMP replies. The three popular routing protocols demonstrate the variety of transport protocols used by routing protocols. OSPF uses IP directly, employing a raw socket, while RIP uses UDP and BGP uses TCP. The next five are UDP-based applications, followed by seven TCP applications and four that use both UDP and TCP. The final five are IP telephony applications that use SCTP exclusively or optionally UDP, TCP, or SCTP.

 1 #include     "unp.h"

 2 #include     <time.h>


 3 int

 4 main(int argc, char **argv)

 5 {

 6     int     listenfd, connfd;

 7     struct sockaddr_in servaddr;

 8     char    buff[MAXLINE];

 9     time_t ticks;


10     listenfd = Socket(AF_INET, SOCK_STREAM, 0);


11     bzeros(&servaddr, sizeof(servaddr));

12     servaddr.sin_family = AF_INET;

13     servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

14     servaddr.sin_port = htons(13); /* daytime server */


15     Bind(listenfd, (SA *) &servaddr, sizeof(servaddr));


16     Listen(listenfd, LISTENQ);


17     for ( ; ; ) {

18         connfd = Accept(listenfd, (SA *) NULL, NULL);


19         ticks = time(NULL);

20         snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks));

21         Write(connfd, buff, strlen(buff));


22         Close(connfd);

23     }

24 }

产生一个TCP套接字

10 创建一个TCP套接字，与客户端一样。

绑定服务器的广为人知的端口到该套接字

11–15 服务器通过填充网络套接字结构体中的端口域，以及服务器的网络接口（IP地址），然后进行绑定（调用bind）。在这里指定IP地址为INADDR_ANY，为了让客户端可以连接服务器的任一网络接口（因为服务器可能有多块网卡，也就对应了多个IP地址），也就是说如果服务器有两个IP地址，客户端连接任一IP地址即可。后续章节中介绍了如何限制客户端连接到一个固定的接口上。

转换为监听套接字

16 通过调用listen，一个套接字就转换为监听套接字，这就是说该套接字负责接收来自客户端的连接请求，而并不真正与客户端进行信息传输。
常量LISTENQ 是在头文件unp.h中定义的，它是指能够同时监听客户端连接的个数。不超过LISTENQ的客户端同时连接服务器，它们会在一个队列中排队，来等待服务器的处理。后续章节有更详细的讨论。

接收客户端连接，发送回复

17–21 一般地，服务器进程在调用accept之后进入到睡眠状态，等待着客户端地连接请求. 一个TCP连接通过一个称为三方握手来建立，当三方握手完成之后，accept调用返回。返回值是一个新的套接字描述符（一个整数值connfd），这个新的套接字负责与客户端进行通讯。对于每一个客户端地连接，accept都返回一个新的套接字描述符。整本书使用的无限循环风格是这样的：

for ( ; ; ) {
    . . .
}

当前时间和日期通过调用库函数time来获得，并且通过调用ctime进行转换，使得我们能够直观的阅读。如下：
Mon May 26 20:58:40 2003

终止连接

22 客户端调用close之后，服务器关闭连接。这时候引起了一个TCP连接终止序列：一个FIN发送到每一端，同时每一个FIN都要被另一端确认。在后面章节中将会对TCP连接建立时候的三方握手以及TCP连接终止时候的四包交换有更详细的讨论。
   以上给出的客户端和服务器版本都是协议相关的（IPv4），在后面将会给出一个协议无关的版本（IPv4和IPv6都适用，主要通过使用getaddrinfo函数）。
   最后需要补充的一点是，在以上涉及到Socket API调用的时候，每个函数的第一个字母变成了大写，其意义和小写开头的是一样的，只不过多了一个错误处理罢了。

D.3 Standard Error Functions

We define our own set of error functions that are used throughout the text to
 handle error conditions. The reason for using our own error functions is to
let us write our error handling with a single line of C code, as in

if (error condition)
    err_sys (printf format with any number of arguments);

instead of

if (error condition) {
    char buff [2002];
    snprintf(buff, sizeof (buff), printf format 
    with any number of arguments);
    perror(buff);
    exit (1);
}

Our error functions use the variable-length argument list facility from ANSI C.
See Section 7.3 of [Kernighan and Ritchie 1988] for additional details.

Figure D.3 lists the differences between the various error functions.
If the global integer daemon_proc is nonzero, the message is passed to
syslog with the indicated level; otherwise, the error is output to standard error.
Figure D.3. Summary of our standard error functions.

Figure D.4 shows the first five functions from Figure D.3.

Figure D.4 Our standard error functions.

lib/error.c

 1 #include    "unp.h"
 2 #include    <stdarg.h>          /* ANSI C header file */
 3 #include    <syslog.h>          /* for syslog() */

 4 int     daemon_proc;            /* set nonzero by daemon_init() */

 5 static void err_doit(int, int, const char *, va_list);

 6 /* Nonfatal error related to system call
 7  * Print message and return */

 8 void
 9 err_ret(const char *fmt, ...)
10 {
11     va_list ap;

12     va_start(ap, fmt);
13     err_doit(1, LOG_INFO, fmt, ap);
14     va_end(ap);
15     return;
16 }

17 /* Fatal error related to system call
18  * Print message and terminate */

19 void
20 err_sys(const char *fmt, ...)
21 {
22     va_list ap;

23     va_start(ap, fmt);
24     err_doit(1, LOG_ERR, fmt, ap);
25     va_end(ap);
26     exit(1);
27 }

28 /* Fatal error related to system call
29  * Print message, dump core, and terminate */

30 void
31 err_dump(const char *fmt, ...)
32 {
33     va_list ap;

34     va_start(ap, fmt);
35     err_doit(1, LOG_ERR, fmt, ap);
36     va_end(ap);
37     abort();                    /* dump core and terminate */
38     exit(1);                    /* shouldn't get here */
39 }

40 /* Nonfatal error unrelated to system call
41  * Print message and return */

42 void
43 err_msg(const char *fmt, ...)
44 {
45     va_list ap;

46     va_start(ap, fmt);
47     err_doit(0, LOG_INFO, fmt, ap);
48     va_end(ap);
49     return;
50 }

51 /* Fatal error unrelated to system call
52  * Print message and terminate */

53 void
54 err_quit(const char *fmt, ...)
55 {
56     va_list ap;

57     va_start(ap, fmt);
58     err_doit(0, LOG_ERR, fmt, ap);

59     va_end(ap);
60     exit(1);
61 }

62 /* Print message and return to caller
63  * Caller specifies "errnoflag" and "level" */

64 static void
65 err_doit(int errnoflag, int level, const char *fmt, va_list ap)
66 {
67     int     errno_save, n;
68     char    buf[MAXLINE + 1];

69     errno_save = errno;         /* value caller might want printed */
70 #ifdef HAVE_VSNPRINTF
71     vsnprintf(buf, MAXLINE, fmt, ap);   * safe */
72 #else
73     vsprintf(buf, fmt, ap);     /* not safe */
74 #endif
75     n = strlen(buf);
76     if (errnoflag)
77         snprintf(buf + n, MAXLINE - n, ": %s", strerror(errno_save));
78     strcat(buf, "\n");

79     if (daemon_proc) {
80         syslog(level, buf);
81     } else {
82         fflush(stdout);         /* in case stdout and stderr are the same */
83         fputs(buf, stderr);
84         fflush(stderr);
85     }
86     return;
87 }

图1.1  网络程序: 客户端和服务器

图 1.2 服务器同时处理多个客户端

图 1.3 在同一个以太网使用TCP协议通信的客户端和服务器

图 1.4 广域网上的客户端与服务器（例如Web浏览器和Web服务器）

§1.2 代码示例和解说

1 #include  "unp.h"

2 int
3 main(int argc, char **argv)
4 {
5     int     sockfd, n;
6     char    recvline[MAXLINE + 1];
7     struct sockaddr_in servaddr;

8     if (argc != 2)
9         err_quit("usage: a.out <IPaddress>");

10     if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
11         err_sys("socket error");

12     bzero(&servaddr, sizeof(servaddr));
13     servaddr.sin_family = AF_INET;
14     servaddr.sin_port = htons(13);  /* daytime server */
15     if (inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0)
16         err_quit("inet_pton error for %s", argv[1]);

17     if (connect(sockfd, (SA *) &servaddr, sizeof(servaddr)) < 0)
18         err_sys("connect error");

19     while ( (n = read(sockfd, recvline, MAXLINE)) > 0) {
20         recvline[n] = 0;        /* null terminate */
21         if (fputs(recvline, stdout) == EOF)
22             err_sys("fputs error");
23     }
24     if (n < 0)
25         err_sys("read error");

26     exit(0);
27 }
其中unp.h是自定义的头文件，查看源代码。我们编译并执行以上代码，得到以下输出结果：

包含我们自己的头文件

1 该头文件包含了大多数网络程序所需要的多个头文件以及定义了我们将要使用的一些常量(例如 MAXLINE).

命令行参数

2–3 这是含有命令行参数的主函数定义(即main函数).我们以ANSI C标准来书写代码.

创建TCP套接字

10–11 socket函数调用创建了一个网络流套接字.(Internet (AF_INET) stream (SOCK_STREAM) socket), 该函数返回一个整数值,它描述了该套接字,以后的函数通过该整数值来使用这个套接字(例如connect和read等调用). 其中err_开头的函数是我们自定义的函数,详见这里.

确定服务器IP地址和端口号

12–16 我们填充了网络套接字地址结构(一个名为servaddr的结构体sockaddr_in),填充的信息包括服务器IP地址和端口号.我们把整个结构体首先清零,然后设置地址族为AF_INET(IPV6该项为AF_INET6),端口号为13(时间服务器的端口号,是一个大家都知道的端口号).IP地址由命令行参数指定(argv[1]).IP地址和端口号必须按照指定的格式来填充,我们通过调用htons(主机字节流到网络字节流的转换)和inet_pton(点分十进制到32位整数的转换)两个调用来进行转化到所需要的格式.

在调用inet_pton的时候可而能会遇到问题,因为这是IPv6新增的函数,以前的IPv4版本可以调用inet_addr来替代该函数.

与服务器建立一个连接

17–18 TCP套接字调用connect函数,就与服务器(main函数的第二个参数)建立了一个TCP连接,我们必须指定套接字结构体的第三个参数长度,它总是让编译器通过C的sizeof运算符来计算.

读取和显示服务器的回复

19–25 调用read来读取服务器的回复,利用标准I/O来显示该回复信息.此外,在使用TCP的时候我们必须要注意,因为它是一个没有边界的字节流协议.服务器的回复是一个26字节的串:

Mon May 26 20 : 58 : 40 2003\r\n

\r 是回车, \n 是换行.

终止程序
26 exit 终止程序.Unix在一个进程结束时候总是关闭所有打开的描述符,因此我们的TCP套接字此时关闭了.
后续内容将对此有更深入的讨论.