[面试]TCP的三次握手| 四次挥手 | TIME_WAIT的2MSL

一、三次握手与四次挥手

三次握手：

第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

四次挥手

与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次挥手”。

第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。

第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。

第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。

第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

 

上面的图比较难懂，如下是我自己画的便于理解

举个栗子：客户端是A，服务器是B
三次握手：
A：我想跟你做好朋友
B：好哇。 我也想跟你做好朋友
A:好的。

四次挥手：
A:我们绝交吧
B:绝交就绝交，who怕who，我还没跟你算帐呢。
B:旧账新账各种算，终于算完了。哼，我也要和你绝交
A:好，绝交。

四次挥手(另一种理解)：
A: hi,我要关闭连接了
B: 好的，我收到了，我不接受你的数据了
B: hi,我也想关闭连接了
A: 好的，我不接收你的数据了。

 

二、常见问题

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：三次握手不可以改成两次握手
（1）如果在seq=x传丢了：post请求-服务器死等
为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（2）如果在ack=x+1,ack=y传丢了：get请求-客户端死等
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

四次挥手最好不要改成三次挥手

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。可以把最后一次省略掉，生存期结束，就果断关掉！但由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。

 

【问题2】如果已经建立了连接，但是客户端突然出现故障了怎么办？
答：TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

【问题3】可以看到时三次握手第二步时，server收到client的SYN包并回复SYN+ACK包后，server会把这条连接放入“半连接队列”。这边有个问题，假设这个client是恶意的，client只发SYN包，收到SYN+ACK后不回复，那在server方面，会一直存有这条“半连接”，client数量达到一定程序，serve就炸了。这就是所谓的SYN FLOOD攻击；那怎么防止这种情况呢？
答：有下面几种方法：（来自RFC 4987）(https://tools.ietf.org/html/rfc4987)
过滤
增加积压
减少SYN-RECEIVED定时
复用古老的半开通TCP
SYN缓存
SYN Cookie
混合方法
防火墙和代理

 

【问题3】为什么tcp四次挥手断开需要TIME_WAIT? 为什么TIME_WAIT状态要维持2MSL？

四次挥手断开需要TIME_WAIT？--- 实现终止tcp全双工连接的可靠性+允许老的重复分组在网络中消逝
1.实现终止tcp全双工连接的可靠性
当最终的ACK丢失，服务器将重发FIN，因此客户端需要维护状态信息以允许它重发最终的ACK。所以需要TIME_WAIT存在以重发丢失的ack，而不是直接关闭。
2.允许老的重复分组在网络中消逝
如果关闭之后短时间内再次重新建立完全相同的ip地址和对应端口的连接，那么上次连接时存在的老重复分组再次发挥作用。为避免这种情况，便需要2个MSL的TIME_WAIT，之所以为两个，首先足够某个方向上的分组最多存活MSL即被丢弃，另一个方向上的应答最多存活MSL也被丢弃，通过两个MSL，能保证当成功建立一个TCP连接时，来自该连接之前的老重复分组都已在网络中消逝。

TIME_WAIT状态要维持2MSL？--- 2个MSL中的第一个MSL是为了等A发出去的最后一个ACK从网络中消失，而第二MSL是防止B收到ACK之前的一刹那可能重传的FIN报文从网络中消失
2MSL原因：假设客户端A和服务器B，四次挥手的最后两次挥手，TIME_WAIT至少需要持续2MSL时长
(MSL=Maximum Segment Lifetime=最长报文段生存时间。这2个MSL中的第一个MSL是为了等A发出去的最后一个ACK从网络中消失，而第二MSL是防止B收到ACK之前的一刹那可能重传的FIN报文从网络中消失)