TCP连接的建立与终止

两个序号和三个标志位

TCP在传输之前会进行三次沟通，一般称为“三次握手”，传完数据断开的时候要进行四次沟通，一般称为“四次挥手”。要理解这个过程首先需要理解TCP中的两个序号和三个标志位的含义：
seq：sequencenumber的缩写，表示所传数据的序号。TCP传输时每一个字节都有一个序号，发送数据时会将数据的第一个序号发送给对方，接收方会按序号检查是否接收完整了，如果没接收完整就需要重新传送，这样就可以保证数据的完整性。
ack：acknoledgementnumber的缩写，表示确认号。接收端用它来给发送端反馈已经成功接收到的数据信息的，它的值为希望接收的下一个数据包起始序号，也就是ack值所代表的序号前面的数据已经成功接收到了。
ACK：确认位，只有ACK=1的时候ack才起作用。正常通信时ACK为1，第一次发起请求时因为没有需要确认接收的数据所以ACK为0。
SYN：同步位，用于在建立连接时同步序号。刚开始建立连接时并没有历史接收的数据，所以ack也就没办法设置，这时按照正常的机制就无法运行了，SYN的作用就是来解决这个问题的，当接收端接收到SYN=1的报文时就会直接将ack设置为接收到的seq+1的值，注意这里的值并不是校验后设置的，而是根据SYN直接设置的，这样正常的机制就可以运行了，所以SYN叫同步位。需要注意的是，SYN会在前两次握手时都为1，这是因为通信的双方的ack都需要设置一个初始值。
FIN：终止位，用来在数据传输完毕后释放连接。

三次握手

TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。

第一次握手： 建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

第二次握手： 服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

第三次握手： 客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

举个打电话的例子：

　　A:“喂，你听得到吗？”A->SYN_SEND

　　B:“我听得到呀，你听得到我吗？”应答与请求同时发出 B->SYN_RCVD | A->ESTABLISHED

　　A:“我能听到你，今天balabala……”B->ESTABLISHED

　　建立连接，开始聊天！

为什么TCP连接需要三次握手，两次不可以吗，为什么？

这个问题的本质是, 信道不可靠, 但是通信双方需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.。

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

具体例子：“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

如果客户端不断的发送请求TCP连接会怎样？

• 服务器端会为每个请求创建一个链接，然后向client端发送创建链接时的回复，然后进行等待客户端发送第三次握手数据包，这样会白白浪费资源。

• DDos攻击。简单的说就是向服务器发送TCP连接接请求，首先进行：

• 第一步：客户端向服务器端发送连接请求数据包

• 第二步：服务器向客户端回复连接请求数据包，然后服务器等待客户端发送tcp/ip连接的第三步数据包

• 如果客户端不向服务器端发送最后一个数据包，则服务器须等待30s到2min才能将此链接进行关闭。当大量的请求只进行到第二步，而不进行第三步，服务器有大量的资源等待第三个数据包。则造成DDos攻击。

• DDos预防(没有根治的办法，除非不用TCP/IP连接)：

• • 　　确保服务器的系统文件是最新版本，并及时更新系统补丁

  • 　　关闭不必要的服务

  • 　　限制同时打开SYN的半连接数目

  • 　　缩短SYN半连接的time out时间

  • 　　正确设置防火墙

  • 　　禁止对主机的非开放服务的访问

  • 　　限制特定IP短地址的访问

  • 　　启用防火墙的防DDos的属性

  • 　　严格限制对外开放的服务器的向外访问

  • 　　运行端口映射程序和端口扫描程序，要认真检查特权端口和非特权端口

  • 　　认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更，那这台机器就可能遭到了攻击

  • 　　限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会，主机的信息暴露给黑客，无疑是给了对方入侵的机会

四次挥手

当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接。那对于TCP的断开连接，这里就有了神秘的“四次分手”。

第一次分手： 主机1（可以是客户端，也可以是服务器端），设置Sequence Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次分手： 主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；

第三次分手： 主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；

第四次分手： 主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

四次挥手例子：
A:“喂，我不说了。”A->FIN_WAIT1

B:“我知道了。等下，上一句还没说完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2

B:”好了，说完了，我也不说了。”B->LAST_ACK

A:”我知道了。”A->TIME_WAIT | B->CLOSED

A等待2MSL,保证B收到了消息,否则重说一次”我知道了”,A->CLOSED

为什么要四次分手？

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

为什么要等待2MSL？

MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。
原因有二：

• 保证TCP协议的全双工连接能够可靠关闭

• 保证这次连接的重复数据段从网络中消失

第一点：在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

第二点：如果主机1直接CLOSED，然后又再向主机2发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达主机2，由于新连接和老连接的端口号是一样的，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

总结

TCP的传输是双全工模式，也就是说传输的双方是对等的，可以同时传输数据，所以无论连接还是关闭都需要对双方同时进行。三次握手中前两次可以保证服务端可以正确接收并返回请求，后两次可以保证客户端可以正确接收并返回请求，而且在三次握手的过程中还使用SYN标志初始化了双方的ack值。四次挥手就是双方分别发送FIN标志来关闭连接并让对方确认。
三次握手和四次挥手保证了连接的可靠性，不过凡事有利就有弊，这种模式也有它的缺点，首先是在传输效率上会比较低，另外三次握手的过程中客户端需要发送两次数据才可以建立连接，这种特性可能被一些别有用心的人利用，比如，发出第一次握手（并接到第二次握手）后就不回应第三次握手了，这时服务端会以为是第二次握手的数据在传输过程中丢失了，然后重新发送第二次握手，默认情况下会一直发送五次，如果发送五次后还收不到第三次握手则会丢弃请求，如果是个别这种请求当然也没什么关系，当有大量这种请求时就麻烦了，这时服务器就会浪费大量的资源甚至可能导致无法处理正常的请求，这就是DDOS攻击中的SYNFlood攻击，对于这种攻击的一种应对方法是设置第二次请求的重发次数（tcp_synack_retries），不过重发的次数太小也可能导致正常的请求因为网络没有收到第二次握手而连接失败的情况，具体设置为多少合适，还需要根据实际情况判断，当然如果资金充足也可以使用硬防。
用于传输层的协议除了TCP还有UDP，它们的区别主要是TCP是有连接的，UDP是没有连接的，也就是说TCP协议是在沟通好后才会传数据，而UDP协议是拿到地址后直就传了，这样产生的结果就是TCP协议传输的数据更可靠，而UDP传输的速度更快。TCP就像是打电话，需要先拨通对方号码才能通信，而UDP就像是使用对讲机，拿起来就可以直接讲话。通常视频传输、语音传输等对完整性要求不高而对传输速度要求高并且数据量大的通信使用UDP比较多，而邮件、网页等一般使用TCP协议。
HTTP协议的底层传输默认使用的是可靠的TCP协议，不过它对互联网的高速发展带来了很大的制约，Google制定了一套基于UDP的QUIC（QuickUDPInternetConnection）协议，这种协议基于TCP和UDP之间，不过现在还没有广泛使用。
TCP/IP协议只是一套规则，并不能具体工作，就像是程序中的接口一样，而Socket是TCP/IP协议的一个具体的实现。

参考资料

什么是TCP/IP协议？：https://mp.weixin.qq.com/s/2RcafHBisAS2Mx8qcjGMKw

通俗易懂地讲解TCP建立连接的三次握手和释放连接的四次挥手：https://www.cnblogs.com/xiaoming0601/p/6001021.html

韩路彪：《看透Spring MVC：源代码分析与实践》