TCP连接建立与断开

TCP协议头

TCP基本协议头占用20个字节，协议中Header Length(4bits)中标明协议头的长度，含义是多少个32bit数据，该字段占用4位，所有整个tcp头最多可以占用60字节。

TCP标志位

CWR & ECN： CWR 全称Congestion Window Reduced，意思是告诉对端我已经按照你的要求，进行阻塞窗口减少了，并启动阻塞算法来控制我的发包速度； ECN 全称 ECN-Echo, Explicit Congestion Notification，意思通知发送方，我接收的报文出现了阻塞，请控制发包速度。也就是说，CWR 和 ECN 必须配合使用，CWR 是收到 ECN 的应答。此外，在tcp三次握手时，这两个标志表明tcp端是否支持ECN。如果建立连接一方支持，则在发送的SYN包，将 ECN 标志置为1，如果服务端也支持，则在ACK包只设置ECN。缘由：tcp建立连接后，报文经过经过路由或网关等网络设备后，在路由器或网关等网络设备出现阻塞时，路由器或网关等设备设置IP层的某个标志表明出现阻塞，这样接收可以明确知道报文出现了阻塞。然而，需要知道阻塞进行阻塞控制的是报文发送方而非接收方。所以接收方会在ACK报文中设置ECN标志，同时发送方在ACK中设置CWR标志，表明已经收到ECN，并进行了减少阻塞窗口操作和启用阻塞算法。

URG：这就是传说中的带外数据。因为tcp是没有消息边界的，假如有一种情况，你已经发送了一些数据，但是此时，你要发送一些数据优先处理，就可以设置这些标志。

PSH： tcp报文的流动，先是发送方塞进发送方的缓存再发送；同样接收方是先塞到接收方的缓存再投递到应用。PSH标志的意思是，无论接收或发送方，都不用缓存报文，直接接收投递给上层应用或直接发送。

SYN(Synchronize), ACK(Acknowledgement), FIN（Finish）和 RST(Reset) 这几个标记比较容易理解。SYN, Synchronize sequence numbers。ACK, Acknowledgement Number有效，应答标记。FIN,发送端结束发送。RST复位连接。

TCP 选项

TCP除了20字节基本数据外，后面还包括了最多40个字节的TCP的选项。tcp选项一般存储为type(1byte) length(1byte) value的格式式，不同的选项具体格式有所不同。这里简单罗列一些常见的tcp选项并做简单介绍。

• MSS(Maximum Segment Size) TCP报文最大传输长度，TCP在三次握手建立阶段，在SYN报文交互该值，注意的是，这个数值并非协商出来的，而是由网络设备属性得出。MSS一个常见的值是1460。

• SACK(Selective Acknowledgements) 选择ACK，用于处理segment不连续的情况，这样可以减少报文重传。比如： A 向B发送4个segment，B收到了1,2,4个segment，网络丢失了3这个segment。B收到1,2segment后，回应ACK 3，表示1,2这两个ACK已经收到，同时在选项字段里面，包括4这个段，表示4这个segment也收到了。于是A就重传3这个segment，不必重传4这个segment。B收到3这个segment后，直接ACK 5，表明3,4都收到了。

• WS(Window Scale) 在tcp头部，Window Size(16Bit)表面接收窗口大小，但是对于现代网络而言，这个值太小了。所以tcp通过选项来增加这个窗口的值。WS值的范围0～14，表示Window Size(16Bit)数值向左移动的位数。这样实际上窗口的大小可达31位。在程序网络设计时，有个SO_RECVBUF，表示设置接收缓冲的大小，然而需要注意的是，这个值和接收窗口的大小不完全相等，但是这个数值和接收窗口存在一定的关系，在内核配置的范围内，大小比较接近。

• TS(Timestamps) Timestamps在tcp选项中包括两个32位的timestamp: TSval(Timestamp value)和TSecr(Timestamp Echo Reply)。如果设置了TS这个选项，发送方发送时，将当前时间填入TSval，接收方回应时，将发送方的TSval填入TSecr即可(注意发送或接收都有设置TSval和TSecr )。TS 选项的存在有两个重要作用：一是可以更加精确计算RTT(Round-Trip-Time)，只需要在回应报文里面用当前时间减去TSecr即可；二是PAWS(Protection Against Wrapped Sequence number, 防止sequence回绕)，什么意思呢？比如说，发送大量的数据：0-10G，假设segment比较大为1G，而sequence最大值为5G，接收端接收1,3,4,5数据段正常接收，收到的发送时间分别1,3,4,5，第2 segment丢失了，由于SACK，导致2被重传，在接收6时，sequence由于回绕变成了1，这时收到的发送时间为6，然后又收到迷途的2，seq为2，发送时间为2，这个时间比6小，是不合法的，tcp直接丢弃这个迷途的报文。

• UTO(User Timeout) 指发送报文，收到ACK的超时时间，如果在UTO内没有收到，则认为对端已挂。 在网络程序设计的时候，为了探测对端是否存活，经常涉及心跳报文，通过tcp的keepalive和UTO机制也可以实现，两者的区别是，前者可以通过心跳报文实时知道对端是否存活，二后者只有等待下次调用发送或接收函数才可以断定： 1) SO_KEEPALIVE相关选项 设置SO_KEEPALIVE 选项，打开keepalive机制。 设置TCP_KEEPIDLE 选项，空闲时间间隔启动keepalive机制，默认为2小时。 设置TCP_KEEPINTVL选项，keepalive机制启动后，每隔多长时间发送一个keepalive报文。默认为75秒。 设置TCP_KEEPCNT选项，设置发送多少个keepalive数据包都没有正常响应，则断定对端已经崩溃。默认为9。

TCP 建立和终止

连接的建立（三次握手）

使用 connect() 建立连接时，客户端和服务器端会相互发送三个数据包，请看下图：

客户端调用 socket() 函数创建套接字后，因为没有建立连接，所以套接字处于CLOSED状态；服务器端调用 listen() 函数后，套接字进入LISTEN状态，开始监听客户端请求。

这个时候，客户端开始发起请求：

1. 当客户端调用 connect() 函数后，TCP协议会组建一个数据包，并设置 SYN 标志位，表示该数据包是用来建立同步连接的。同时生成一个随机数字 1000，填充“序号（Seq）”字段，表示该数据包的序号。完成这些工作，开始向服务器端发送数据包，客户端就进入了SYN-SEND状态。

2. 服务器端收到数据包，检测到已经设置了 SYN 标志位，就知道这是客户端发来的建立连接的“请求包”。服务器端也会组建一个数据包，并设置 SYN 和 ACK 标志位，SYN 表示该数据包用来建立连接，ACK 用来确认收到了刚才客户端发送的数据包。

服务器生成一个随机数 2000，填充“序号（Seq）”字段。2000 和客户端数据包没有关系。

服务器将客户端数据包序号（1000）加1，得到1001，并用这个数字填充“确认号（Ack）”字段。

服务器将数据包发出，进入SYN-RECV状态。

3. 客户端收到数据包，检测到已经设置了 SYN 和 ACK 标志位，就知道这是服务器发来的“确认包”。客户端会检测“确认号（Ack）”字段，看它的值是否为 1000+1，如果是就说明连接建立成功。

接下来，客户端会继续组建数据包，并设置 ACK 标志位，表示客户端正确接收了服务器发来的“确认包”。同时，将刚才服务器发来的数据包序号（2000）加1，得到 2001，并用这个数字来填充“确认号（Ack）”字段。

客户端将数据包发出，进入ESTABLISED状态，表示连接已经成功建立。

4. 服务器端收到数据包，检测到已经设置了 ACK 标志位，就知道这是客户端发来的“确认包”。服务器会检测“确认号（Ack）”字段，看它的值是否为 2000+1，如果是就说明连接建立成功，服务器进入ESTABLISED状态。

至此，客户端和服务器都进入了ESTABLISED状态，连接建立成功，接下来就可以收发数据了。

TCP数据的传输过程

建立连接后，两台主机就可以相互传输数据了。如下图所示：

此时 Ack 号为 1301 而不是 1201，原因在于 Ack 号的增量为传输的数据字节数。假设每次 Ack 号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确100字节全部正确传递还是丢失了一部分，比如只传递了80字节。因此按如下的公式确认 Ack 号：

Ack号 = Seq号 + 传递的字节数 + 1

与三次握手协议相同，最后加 1 是为了告诉对方要传递的 Seq 号。

TCP四次挥手断开连接

建立连接非常重要，它是数据正确传输的前提；断开连接同样重要，它让计算机释放不再使用的资源。如果连接不能正常断开，不仅会造成数据传输错误，还会导致套接字不能关闭，持续占用资源，如果并发量高，服务器压力堪忧。

下图演示了客户端主动断开连接的场景：

建立连接后，客户端和服务器都处于ESTABLISED状态。这时，客户端发起断开连接的请求：

1. 客户端调用 close() 函数后，向服务器发送 FIN 数据包，进入FIN_WAIT_1状态。FIN 是 Finish 的缩写，表示完成任务需要断开连接。

2. 服务器收到数据包后，检测到设置了 FIN 标志位，知道要断开连接，于是向客户端发送“确认包”，进入CLOSE_WAIT状态。

注意：服务器收到请求后并不是立即断开连接，而是先向客户端发送“确认包”，告诉它我知道了，我需要准备一下才能断开连接，可能自己还有数据要发送。

3. 客户端收到“确认包”后进入FIN_WAIT_2状态，等待服务器准备完毕后再次发送数据包。

4. 等待片刻后，服务器准备完毕，可以断开连接，于是再主动向客户端发送 FIN 包，告诉它我准备好了，断开连接吧。然后进入LAST_ACK状态。

5. 客户端收到服务器的 FIN 包后，再向服务器发送 ACK 包，告诉它你断开连接吧。然后进入TIME_WAIT状态。

6. 服务器收到客户端的 ACK 包后，就断开连接，关闭套接字，进入CLOSED状态。

TCP TIME_WAIT 状态作用

FIN包的ACK丢失，重传FIN包

Peer两端，哪一端会进入TIME_WAIT呢？ TCP主动关闭连接的那一方会最后进入TIME_WAIT。那么怎么界定主动关闭方呢？是否主动关闭是由FIN包的先后决定的，就是在自己没收到对端Peer的FIN包之前自己发出了FIN包，那么自己就是主动关闭连接的那一方。如果Peer两边都是主动关闭的一方，两边都会进入TIME_WAIT。为什么是主动关闭的一方进行TIME_WAIT呢，被动关闭的进入TIME_WAIT可以不呢？我们来看看TCP四次挥手可以简单分为下面三个过程

• 过程一.主动关闭方发送FIN；
• 过程二.被动关闭方收到主动关闭方的FIN后发送该FIN的ACK，被动关闭方发送FIN；
• 过程三.主动关闭方收到被动关闭方的FIN后发送该FIN的ACK

被动关闭方等待自己FIN的ACK问题就在过程三中，据TCP协议规范，不对ACK进行ACK，如果主动关闭方不进入TIME_WAIT，那么主动关闭方在发送完ACK就走了的话，如果最后发送的ACK在路由过程中丢掉了，最后没能到被动关闭方，这个时候被动关闭方没收到自己FIN的ACK就不能关闭连接，接着被动关闭方会超时重发FIN包，但是这个时候已经没有对端会给该FIN回ACK，被动关闭方就无法正常关闭连接了，所以主动关闭方需要进入TIME_WAIT以便能够重发丢掉的被动关闭方FIN的ACK。

清除已经关闭的连接残余数据包

TIME_WAIT 会持续2*MSL（报文最大生存时间），一般是1到4分钟，防止已经断开的连接1中在链路中残留的FIN包终止掉新的连接2(重用了连接1的所有的5元素(源IP，目的IP，TCP，源端口，目的端口)），这个概率比较低，因为涉及到一个匹配问题，迟到的FIN分段的序列号必须落在连接2的一方的期望序列号范围之内，虽然概率低，但是确实可能发生，因为初始序列号都是随机产生的，并且这个序列号是32位的，会回绕。防止链路上已经关闭的连接的残余数据包(a lost duplicate packet or a wandering duplicate packet) 干扰正常的数据包，造成数据流的不正常。

close()，shutdown()

确切地说，close() / closesocket() 用来关闭套接字，将套接字描述符（或句柄）从内存清除，之后再也不能使用该套接字，与C语言中的 fclose() 类似。应用程序关闭套接字后，与该套接字相关的连接和缓存也失去了意义，TCP协议会自动触发关闭连接的操作。

shutdown() 用来关闭连接，而不是套接字，不管调用多少次 shutdown()，套接字依然存在，直到调用 close() / closesocket() 将套接字从内存清除。

调用 close()/closesocket() 会立即向网络中发送FIN包，不管输出缓冲区中是否还有数据，而shutdown() 会等输出缓冲区中的数据传输完毕再发送FIN包。也就意味着，调用 close()/closesocket() 将丢失输出缓冲区中的数据，而调用 shutdown() 不会。

为什么握手三次，挥手四次？

建立连接，服务端ACK确认包和SYN包可以合成一个SYN ACK包一起发送；
断开连接，由于TCP是全双工的，需要Peer两端分别各自拆除自己通向Peer对端的方向的通信信道，这样需要四次挥手来分别拆除通信信道。

TCP 连接的初始化序列号能否固定

如果初始化序列号（缩写为ISN：Inital Sequence Number）可以固定，我们来看看会出现什么问题。假设ISN固定是1，Client和Server建立好一条TCP连接后，Client连续给Server发了10个包，这10个包不知怎么被链路上的路由器缓存了(路由器会毫无先兆地缓存或者丢弃任何的数据包)，这个时候碰巧Client挂掉了，然后Client用同样的端口号重新连上Server，Client又连续给Server发了几个包，假设这个时候Client的序列号变成了5。接着，之前被路由器缓存的10个数据包全部被路由到Server端了，Server给Client回复确认号10，这个时候，Client整个都不好了，这是什么情况？我的序列号才到5，你怎么给我的确认号是10了，整个都乱了。

RFC793中，建议ISN和一个假的时钟绑在一起，这个时钟会在每4微秒对ISN做加一操作，直到超过2^32，又从0开始，这需要4小时才会产生ISN的回绕问题，这几乎可以保证每个新连接的ISN不会和旧的连接的ISN产生冲突。这种递增方式的ISN，很容易让攻击者猜测到TCP连接的ISN，现在的实现大多是在一个基准值的基础上进行随机的。

总结：容易发生ISN冲突。

初始化连接的 SYN 超时问题

Client发送SYN包给Server后挂了，Server回给Client的SYN-ACK一直没收到Client的ACK确认，这个时候这个连接既没建立起来，也不能算失败。这就需要一个超时时间让Server将这个连接断开，否则这个连接就会一直占用Server的SYN连接队列中的一个位置，大量这样的连接就会将Server的SYN连接队列耗尽，让正常的连接无法得到处理。

目前，Linux下默认会进行5次重发SYN-ACK包，重试的间隔时间从1s开始，下次的重试间隔时间是前一次的双倍，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s，TCP才会把断开这个连接。由于，SYN超时需要63秒，那么就给攻击者一个攻击服务器的机会，攻击者在短时间内发送大量的SYN包给Server(俗称 SYN flood 攻击)，用于耗尽Server的SYN队列。对于应对SYN 过多的问题，linux提供了几个TCP参数：tcp_syncookies、tcp_synack_retries、tcp_max_syn_backlog、tcp_abort_on_overflow 来调整应对。

SYN FLOOD攻击

可以利用建连接时的SYN超时机制发起SYN Flood攻击——给server发一个SYN就立即下线，于是服务器默认需要占用资源63s才会断开连接。发SYN的速度是很快的，这样，攻击者很容易将server的SYN队列资源耗尽，使server无法处理正常的新连接。

针对该问题，Linux提供了一个tcp_syncookies参数解决这个问题——当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳构造一个特别的Sequence Number发回去，称为SYN Cookie，如果是攻击者则不会有响应，如果是正常连接，则会把这个SYN Cookie发回来，然后server端可以通过SYN Cookie建连接（即使你不在SYN队列中）。至于SYN队列中的连接，则不做处理直至超时关闭。请注意，不要用tcp_syncookies参数来处理正常的大负载连接情况，因为SYN Cookie本质上也破坏了建连接的SYN超时机制，是妥协版的TCP协议。

对于正常的连接请求，有另外三个参数可供选择：

• tcp_synack_retries参数设置SYN超时重试次数
• tcp_max_syn_backlog参数设置最大SYN连接数（SYN队列容量）
• tcp_abort_on_overflow参数使SYN请求处理不过来的时候拒绝连接

TCP 的 Peer 两端同时断开连接

由上面的”TCP协议状态机 “图可以看出，TCP的Peer端在收到对端的FIN包前发出了FIN包，那么该Peer的状态就变成了FIN_WAIT1，Peer在FIN_WAIT1状态下收到对端Peer对自己FIN包的ACK包的话，那么Peer状态就变成FIN_WAIT2，Peer在FIN_WAIT2下收到对端Peer的FIN包，在确认已经收到了对端Peer全部的Data数据包后，就响应一个ACK给对端Peer，然后自己进入TIME_WAIT状态。

但是如果Peer在FIN_WAIT1状态下首先收到对端Peer的FIN包的话，那么该Peer在确认已经收到了对端Peer全部的Data数据包后，就响应一个ACK给对端Peer，然后自己进入CLOSEING状态，Peer在CLOSEING状态下收到自己的FIN包的ACK包的话，那么就进入TIME WAIT 状态。于是，TCP的Peer两端同时发起FIN包进行断开连接，那么两端Peer可能出现完全一样的状态转移 FIN_WAIT1——>CLOSEING——->TIME_WAIT，也就会Client和Server最后同时进入TIME_WAIT状态。

同时关闭连接的状态转移如下图所示：

TCP短连接与长连接

TCP长连接和短连接的区别在于client和server采取的关闭策略。

短连接

client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。即短连接一般只会在client/server间传递一次读写操作。

长连接

client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

TCP保活机制

TCP保活机制，保活机制主要为服务器应用提供，确定客户主机是否崩溃，从而可以决定是否断开连接。

如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下4个状态之一：

• 客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。

• 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。

• 客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。

• 客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。

在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；还可以以客户端机器为颗粒度，限制每个客户端的最大长连接数。