network

TCP连接的建立和关闭详解

  1. 1. TCP建立连接（三次握手）
    1. 1.1. tcpdump三次握手
    2. 1.2. tcp同时打开
  2. 2. TCP释放连接（四次挥手）
    1. 2.1. tcpdump四次挥手
    2. 2.2. tcp同时关闭
  3. 3. TCP的半关闭(half-close)
  4. 4. TCP的半打开(half-open)
  5. 5. TCP的复位报文段
  6. 6. TCP的延迟关闭
  7. 7. TCP状态说明
  8. 8. 参考

1. TCP建立连接（三次握手）

下面两个图是从协议和接口两个角度来解释TCP的三次握手过程（分别摘自计算机网络-谢希仁和UNIX网络编程卷1）：

1.1. tcpdump三次握手

下面通过tcpdump来查看tcp建立连接的过程：用nc命令来进行测试，

1
2
3
4
server：nc –l 9000
client：nc 9000

[anonymalias@qcloud ~]$sudo tcpdump -i lo port 9000 -X –S

tcpdump默认情况下，只会在SYN报文段中显示绝对的sequence number， 其他报文段只会显示相对的sequence number，所以需要加上-S才能在握手以外的阶段显示绝对sequence number。-X参数用于解析和显示每一个包的包头和包体。这里只显示IP header + TCP packet， 不显示链路层link level的头部。

图中第一个tcp建立连接的请求包中6个控制位字段：URG|ACK|PSH|RST|SYN|FIN，SYN置为1，表示是一个连接请求包；
图中第二个tcp包为服务器对连接请求的应答包，6个控制位字段：URG|ACK|PSH|RST|SYN|FIN，ACK和SYN均置为1，表示连接请求的应答包。TCP协议规定，链接建立后，所有的报文的ACK控制位必须置为1；
图中第三个tcp包为客户端对应答包的确认包，6个控制位字段：URG|ACK|PSH|RST|SYN|FIN，ACK置为1。

对于tcp建立链接的过程，控制位SYN只有在链接建立前两次握手中会置为1， 其他阶段的包该控制位不能设置。控制位ACK，在第二次握手开始及以后会一直置为1，直到最后一个报文包。

  • 为什么要采用三次握手，而不是两次握手

三次握手每次都是接收到数据包的一方可以得知对方的情况，但发送方其实没有任何头绪。我虽然有发包的动作，但是我怎么知道我有没有发出去，而对方有没有接收到呢？所以经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。

其次还是是为了防止已失效的连接请求报文段突然又传送到服务器，产生错误。
已失效的连接请求报文段的产生原因：当客户A发送连接请求，但因连接请求报文丢失而未收到确认。于是A会再次重传一次连接请求，此时服务器端B收到再次重传的连接请求，建立了连接，然后进行数据传输，数据传输完了后，就释放了此连接。假设A第一次发送的连接请求并没有丢失，而是在网络结点中滞留了太长时间，以致在AB通信完后，才到达B。此时这个连接请求其实已经是被A认为丢失的了。如果不进行第三次握手，那么服务器B可能在收到这个已失效的连接请求后，进行确认，然后单方面进入ESTABLISHED状态，而A此时并不会对B的确认进行理睬，这样就白白的浪费了服务器的资源。

1.2. tcp同时打开

TCP协议也是支持同时打开的，尽管这个概率是非常小的，因为这要求通信双方都知道对方的端口号，这需要双方都事先bind()各自的端口，并同时发出SYN包。TCP针对同时打开的情况，仅建立一条连接而不是两条连接。
对于同时打开连接的双方，在发送SYN包后，都进入SYN_SEND状态，在收到对端的SYN包后，进入SYN_RCVD状态，并对此SYN包再次回复SYN包进行确认，当双方都收到对端的SYN包ack后，就会进入ESTABLISHED状态。如下：

tcp同时打开需要4次握手，比正常的建立连接多了一个包。

2. TCP释放连接（四次挥手）

下面两个图是从协议和接口两个角度来解释TCP的释放过程（分别摘自计算机网络-谢希仁和UNIX网络编程卷1）

2.1. tcpdump四次挥手

和建立连接的三次握手一样，在链接建立后，然后关闭链接，tcpdump的结果如下：

tcpdump的结果如下:
图中第一个tcp的请求包中6个控制位字段：URG|ACK|PSH|RST|SYN|FIN，ACK和FIN控制位置为1， client发起关闭tcp连接的请求。
图中第二个tcp包，为服务器响应客户端的关闭包，其中6个控制位字段：URG|ACK|PSH|RST|SYN|FIN， ACK和FIN控制位置为1， 且回包的ack = 前一个包seq + 1，
图中第三个tcp包，为客户端对服务器关闭链接的应答，其中6个控制位字段：URG|ACK|PSH|RST|SYN|FIN，ACK控制位被置为1，这个包代表链接正式关闭；

TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。
TCP关闭时的状态两点需要说明：

  • CLOSE_WAIT状态
    在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态，此时该tcp连接就处于半关闭状态。
  • TIME_WAIT状态
    在客户端收到服务器端最后的连接释放报文段后，客户端不会立即进入CLOSED状态。必须经过2MSL（Maximum Segment Lifetime）后，才进入CLOSED状态。
    • 为了确保客户端发送的最后一个ACK报文能够到达服务器端。
    • 防止TCP连接过程中所说的“已失效的连接请求报文段“出现在本连接中。客户端在发送完最后一个ACK报文后，再经过2MSL，就可以是本连接持续时间内的所有报文都在从网络中消失。这样就可以使下一个新的连接中不会出现旧的连接请求报文。

2.2. tcp同时关闭

TCP协议是允许通信的双方同时执行关闭操作，即同时发送FIN包，当双方发送FIN包后，都进入FIN_WAIT_1状态(双方互不知对方已发送FIN，所以和正常关闭一样)，当双方都收到FIN包后，TCP协议层就会知道是双方是同时关闭，然后就会进入CLOSING状态，并对对方的SYN包进行ack确认，当双方收到对方的ack确认后，就会进入TIME_WAIT状态。过程如下图：

3. TCP的半关闭(half-close)

TCP之所以在释放链接的时候进行四次挥手，是因为TCP链接是全双工的，因为每个方向的链接都需要单独关闭。这个是TCP协议的最基本原则，这个原则要求：当一方完成数据的发送后，就发送FIN包来终止这个方向的链接。
所以，TCP的半关闭就是：在连接一端发送结束并关闭后，还拥有可以从另一端接收数据的能力。

不过这个功能只有很少数的应用会使用它，我们平时基本上都是通过close()直接全关闭一个链接。如果应用程序要使用这个功能，可以通过调用shutdown，且第二个参数传1

下面介绍一下：shutdown 与 close 函数 的区别

1
int close(int sockfd);

close一个TCP的socket，默认行为是把该套接字标记成已关闭，然后立即返回到调用进程，该套接字描述符不能再由调用进程使用，也就是说它不能被read或write，否则会报错，bad file descriptor，然后TCP将尝试发送已排队等待发送到对端的任何数据，发送完毕后发生的是正常的TCP终止序列。
server端调用close()函数后，该链接不再是半关闭，而是全关闭。调用方TCP协议层会把该链接的FD标识为全关闭。server发送完FIN包后，对于客户端并不知道所谓的全关闭， 因为client只会收到一个FIN包， 按照tcp协议规定： client只会知道server到client方向的数据传输已经关闭，所以client理论上是允许再次向server端发送数据。
如果，此时client再次向server发送数据会成功，send()只负责把数据交给内核TCP发送缓冲区，然后就成功返回了，所以不会出错。但是client的tcp内核协议层会收到server的一个RST回包，表示server已不能接收数据，连接被重置。client的tcp内核协议层收到这个RST回包，无法立刻通知应用层，只是保存这个状态，如果client再次进行：

  • read()操作：返回0，表示链接已关闭。
  • write()操作：tcp协议层已经处于RST状态了，会直接触发SIGPIPE信号，默认该信号会终止程序。
    1
    int shutdown(int sockfd, int how);
    shutdown()可以选择关闭TCP全双工的单向或双向的连接。第二参数how值如下：
how的值 描述
0 Further receives are disallowed
1 Further sends are disallowed
2 Further sends and receives are disallowed (like close())

当how为0时，shutdown()关闭连接的读通道，并丢弃上层还没有读走的所有数据以及调用shutdown之后到达的数据，并且此时不会发送FIN包。
当how为1时，shutdown()关闭连接的写通道，所有的剩余数据被发送，完成后发送FIN包，执行TCP的半关闭。

这里需要指出(基本不会发生)：
close()不能保证一定会发送FIN包，只有当某个sockfd的引用计数为0，close 才会发送FIN段，否则只是将引用计数减1而已。也就是说只有当所有进程（可能fork多个子进程都打开了这个套接字）都关闭了这个套接字，close 才会发送FIN 段。

4. TCP的半打开(half-open)

TCP的半打开是一种非常常见的链接异常情况：一方已经关闭或异常终止连接，而另外一方去还不知道。
这种情况在：server调用close()关闭连接后，client在收到FIN包后，并没有关闭链接，此时这个TCP链接就是半打开的，此时client再次发送数据对端就会在TCP协议层触发RST回包，例如下面的tcpdump抓包：

当然还有经常会发生的就是，另一端网络断开和断电等导致的TCP处于半打开状态。

因为客户端的多样性已经网络的复杂，服务器端很容易就产生很多半打开的连接，半打开链接的检测，有很多方法，

  • 通过应用层，对每一个连接添加定时器监听，超时无数据就进行关闭操作。
  • 通过TCP协议层的keepalive选项来开始TCP的保活定时器，但保活不是TCP标准规范的(但很多tcp的实现中实现了此功能)，TCP RFC中给出了3个不使用保活定时器的理由：
    • 在出现一个短暂的差错情况下，可能会是一个非常好的连接被释放掉；
    • 保活功能会耗费不必要的带宽；
    • 在按流量计费的情况下，会花掉更多的money；

下面是通过SO_KEEPALIVE选项来设置TCP连接支持保活的代码：

1
2
3
4
5
6
7
8
int open = 1;       // 开启keepalive属性. 缺省值: 0(关闭)  
int idle = 60;    // 如果在60秒内没有任何数据交互,则进行探测. 缺省值:7200(s)  
int interval = 5;  // 探测时发探测包的时间间隔为5秒. 缺省值:75(s)  
int retry_cnt = 2;  // 探测重试的次数. 全部超时则认定连接失效..缺省值:9(次)  
setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &open, sizeof(open));  
setsockopt(s, SOL_TCP, TCP_KEEPIDLE, idle, sizeof(idle));  
setsockopt(s, SOL_TCP, TCP_KEEPINTVL, interval, sizeof(interval));  
setsockopt(s, SOL_TCP, TCP_KEEPCNT, retry_cnt, sizeof(retry_cnt));

5. TCP的复位报文段

TCP的复位报文是一个很常见的数据，引用TCP/IP详解的话：无论何时，一个报文段发往基准的连接(referenced connection)出现错误，TCP都会发出一个复位报文段。
主要有三种情况：

  • 前面提到的半打开状态：一个连接的另一端已经关闭，此时发送数据到对端，就会触发RST回包；
  • 到不存在的端口的连接请求：请求连接一个并没有监听的端口，TCP则会返回RST(UDP将会产生一个ICMP端口不可达的信息)。
  • 异常终止一个连接：在关闭连接的时候不是通过FIN报文进行正常关闭，而是通过直接发送RST进行连接关闭。两者的区别：
    • 通过FIN包进行关闭，又称：有序释放(orderly release)，因为close()/shutdown()都会将缓冲区中的数据全部发送出去之后，才会发送FIN。
    • 通过RST复位包进行关闭，又称：异常释放(abortive release)。异常释放的特点：
      • 丢弃掉发送缓冲区中的全部数据，立刻发送RST报文；
      • RST接收方会区分另一端执行的是正常关闭，还是异常关闭。

直接通过发送RST报文进行连接的异常关闭的代码如下，具体细节详见下节的TCP的延迟关闭：

1
2
3
4
5
6
7
8
9
10
11
12
struct linger so_linger;
so_linger.l_onoff = true;
so_linger.l_linger = 0;

ret = setsockopt(events[i].data.fd, SOL_SOCKET, SO_LINGER, &so_linger, sizeof(so_linger));
if(ret < 0)
{
    printf("%s():[ERROR]: setsockopt error, errno:%d, info:%s\n", \
        __FUNCTION__, errno, strerror(errno));
}

close(events[i].data.fd);

6. TCP的延迟关闭

TCP支持通过SO_LINGER选项来设置连接延迟关闭。前面说过close()一个socket的默认行为是把该套接字标记成已关闭，然后立即返回到调用进程，然后TCP协议层将尝试发送已排队等待发送到对端的任何数据，发送完毕后发生的是正常的TCP终止序列。
SO_LINGER选项可以改变close()的默认行为，选项要求传入内核的参数的结构体如下：

1
2
3
4
struct linger{
    int l_onoff;        //0=off, non-zero = on
    int l_linger;       //延迟关闭的时间，单位second
};

l_onoff开启时，l_linger为非0，调用close()关闭连接时，

  • fd阻塞情况下，如果socket的发送缓冲区残留为发送的数据，那么进程将会被投入睡眠，直到所有数据被发送完并收到确定或则l_linger时间超时。如果延迟时间超时发送缓冲区的数据还没有发送完毕，那么close()会返回EWOULDBLOCK错误，并丢弃发送缓冲区的全部数据。
  • fd非阻塞情况下，close()会立即返回，接下来TCP协议层就是和fd阻塞情况一样的操作。

l_onoff开启时，l_linger为0，调用close()关闭连接时，就会触发前面说的异常释放的流程，即发送复位报文进行连接的关闭。具体TCP协议层的操作和这么做的好处请见前文。

下图是close()的行为在有无SO_LINGER选项下的行为对比，截自《UNIX网络编程劵1:套接字网络API》

7. TCP状态说明

TCP连接的双方在连接的不同阶段会处于不同的阶段，对每一个阶段的了解，是很好的使用TCP的一个基础，下表是TCP连接的各个状态：

TCP端口状态 描述
LISTEN 等待从任何远端TCP和端口的连接请求
SYN_SENT 发送完一个连接请求后等待一个匹配的连接请求。
SYN_RECEIVED 发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。
ESTABLISHED 表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。
FIN_WAIT_1 等待远端TCP的连接终止请求，或者等待之前发送的连接终止请求的确认。
FIN_WAIT_2 等待远端TCP的连接终止请求
CLOSE_WAIT 等待本地用户的连接终止请求
CLOSING (同时关闭时)等待远端TCP的连接终止请求确认
LAST_ACK 等待先前发送给远端TCP的连接终止请求的确认（包括它字节的连接终止请求的确认）
TIME_WAIT 等待足够的时间过去以确保远端TCP接收到它的连接终止请求的确认
CLOSED 不在连接状态（这是为方便描述假想的状态，实际不存在）

下图是TCP状态转换图(摘自：UNIX网络编程劵1:套接字网络API)

8. 参考

http://zheming.wang/blog/2013/08/18/4417B74D-F037-414A-A291-CEF7B3CD511D/
http://xstarcd.github.io/wiki/shell/tcpdump_TCP_three-way_handshake.html
http://www.cnblogs.com/lshs/p/6038458.html
http://blog.csdn.net/jnu_simba/article/details/9068059
《UNIX网络编程劵1:套接字网络API》
《TCP/IP详解 劵1：协议》
《计算机网络(谢希仁)》