TCP 3次握手 4次挥手通俗理解

相信很多人都对 “TCP 3次握手 4次挥手”这个概念不陌生；但谈论到其中具体细节时，可能就吱吱呜呜，说不清楚。
进入正题前，先提几个问题：

1、TCP 3次握手（4次挥手），每次发送的信息是什么？
2、TCP 连接 为啥要进行3次握手？
3、TCP 断开连接 为啥要进行4次挥手？

现在想这样一个问题：
一个讲英语的老外初次到中国玩耍，人生地不熟，想要问路。
老外找到个中年大叔询问：“Excuse me ,I want to ……”，然而中年大叔完全听不懂英语，根本不知道老外说的是啥，摆摆手走了；

老外无奈继续找人，这次他找到了一个中学生继续询问，中学生很认真地听，无奈中学生听力不咋滴，不仅误解了老外的意思，还用蹩脚的中式英语回应了老外，老外傻眼了，完全听不懂他在讲啥；

老外很苦恼，继续找人问路，黄天不负苦心人，这次恰巧找到了一个英语系的大学生，大学生听了之后，知道老外要去哪里，并用纯正的口语指明了道路方向，老外听完后，非常高兴的竖起了大拇指。正好大学生也要去那个地方，俩人一路聊了起来，很是嗨皮。

好了，故事讲到这里，对应的具体细节应该很清楚了；

3次握手

客户端 要和 服务端建立连接，首先要和服务端进行第一次通话，发送SYN（同步序列编号，假设为m）;

这是第1次握手，如果只进行这一次握手，接下来，客户端开始发送数据，能确定服务端可以收到数据吗？想想上面的故事，大叔都摆摆手走了，老外还站在原地，喋喋不休……

服务端 收到 客户端请求，发送数据 SYN（假设为n）和ACK（确认编号，为m+1）；

这是第2次握手，如果握手两次，假设ACK是p，正确的应该是（m+1），想想上面，中学生的蹩脚中式英语，老外都不知道他在讲啥，还有必要继续和他交流下去吗？

客户端 收到 服务端数据SYN（为n）和ACK（为m+1），发送ACK(为n+1);

这是第3次握手，握手成功，老外和大学生相聊甚欢。

总结：
三次握手保证了服务端能够收到客户端消息，并正确理解了客户端的意思；
   同时也保证了客户端能够收到服务端消息，并正确理解了服务端的意思；
经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。

以上是个人理解，看下课本中书面讲解：
已失效的连接请求报文段的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。

4次挥手

4次挥手原理同3次握手原理一样，
区别是第2次握手时，服务端一次将SYN和ACK一起发送给客户端；
而挥手时，是分开发送的，也就是说，一次发送ACK，再用一次发送FIN(完成编号，和SYN一样，换了个说法而已)

注意：
挥手时，客户端和服务端均可发起，当任何一端没有数据发送给对方时，该端可以发送FIN(假设p)，另一方收到该信息后发送ACK(p+1)，告诉对方收到信息了；
如果上述的另一方还有信息没有发送完成，可以继续发送，直到所有信息都发送完了，这时，可以给对方发送FIN(q)，告诉对方，可以结束了，同时，开启计时动作，等待对方返回ACK(q+1)；如果对方在2个MSL（Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间）还未响应，则断开连接；当然，规定时间内返回一样也断开连接；
2个MSL是防止网络不稳定导致FIN或者ACK丢失的情况下产生的；

思考：

挥手不可以3次吗？

正如上面所言，一方没有信息发送了，但另一方还有信息要发送；所以，当一方发送FIN时，另一方发送ACK，告诉对方：“知道了你没话说了，但我还没有说完，让我说完再断开连接”。

好了，读到这里，文章开始的问题也可以有答案了。以上是鄙人对TCP 握手和挥手的粗鄙见解。下面补充点额外知识：

SYN攻击

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为half-open connect（半连接）。此时服务器处于Syn_RECV状态。当收到ACK后，服务器转入ESTABLISHED状态。

Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。

检测SYN攻击

当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。

防范Syn攻击主要方法

• SynAttackProtect保护机制
• SYN cookies技术
• 增加最大半连接数和缩短超时时间