TCP三次握手和四次挥手

1 三次握手

TCP协议标示的含义：

• SYN ：同步序号用来发起一个连接
• ACK：确认序号有效
• PSH：接收方应尽快将这个报文交给应用层
• FIN：终止一个连接
• RST：连接重置
• URG：紧急指针有效
• seq：序号

三次握手图解，注意（图片来自网络）：

理解：

• 第一次握手：客户端向服务器发出连接请求报文，此时请求报文首部中的同部位SYN=1，同时会随机生成初始序列号 seq=x。此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态等待服务器响应。注意此时SYN报文段不能携带数据，但需要消耗掉一个序号
• 第二次握手： 服务器收到请求报文后，如果同意连接，则会发出确认报文。确认报文中ACK=1， SYN=1，确认号是ack=x+1，同时也要为自己随机初始化一个序列号 seq=y，此时，服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。这个报文带有SYN(建立连接)和ACK(确认)标志，询问客户端是否准备好
• 第三次握手：客户端进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。此时ACK报文段可以携带数据，但是如果不携带数据则不消耗序号

提问：为什么一定要是三次握手？

• 假设client发送了第一个连接的请求报文，但是由于网络延迟等情况，这个请求没有立即到达服务端，而是在某个网络节点中滞留了，直到某个时间才到达server，本来这已经是一个失效的报文，但是server端接收到这个请求报文后，还是会向client发出确认的报文，表示同意连接。假如不采用三次握手，那么只要server发出确认，新的建立就连接了，但其实这个请求是失效的请求，client是不会理睬server的确认信息，也不会向服务端发送确认的请求，但是server认为新的连接已经建立起来了，并一直等待client发来数据，这将导致不必要的错误和资源的浪费，采用三次握手就是为了防止这种情况的发生，server会因为收不到确认的报文，就知道client并没有建立连接。这就是三次握手的作用。若在握手某个过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包

提问：如何解释只看到过TCP状态位为 ’FIN +ACK’，但从来没有看过状态位只有 ‘FIN’

• 除了第一个握手报文SYN除外，其它所有报文必须将ACK = 1

提问：为什么第一次的seq序列号要随即生成？

• 这样是为了网络安全，如果不是随机产生初始序列号，黑客将会以很容易的方式获取到你与其他主机之间的初始化序列号，并且伪造序列号进行攻击

提问：为什么三次握手，返回时ack 值是 seq 加 1（ack = x+1）？

• 假设对方接收到数据，数据第一个字节编号为1000，最后一个为1999，回应一个确认报文，确认号为2000，意味着编号2000前的字节接收完成，准备接收编号为2000及更多的数据确认收到的序列，并且告诉发送端下一次发送的序列号从哪里开始（便于接收方对数据排序，便于选择重传）

2 四次挥手

四次挥手图解，注意（图片来自网络）：

理解：

• 第一次挥手：TCP发送一个FIN(结束)，用来关闭客户到服务端的连接。客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u。此时，客户端进入FIN-WAIT-1（终止等待1）状态
• 第二次挥手： 服务端收到这个FIN，他发回一个ACK(确认)，确认收到序号为收到序号+1，和SYN一样，一个FIN将占用一个序号。服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
• 第三次挥手： 服务端发送一个FIN(结束)到客户端，服务端关闭客户端的连接。 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
• 第四次挥手：客户端发送ACK(确认)报文确认，并将确认的序号+1，这样关闭完成。 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

提问：为什么必须是四次挥手?

• 为了确保数据能够完成传输。
  关闭连接时，当收到对方的FIN报文后，它仅仅表示对方不再发送数据了但是还能接收数据，但未必自己所有的数据都全部发送给对方了，所以服务器可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接。因此，服务器ACK报文和FIN报文多数情况下都是分开发送的。

提问： 为什么tcp握手的时候ACK和SYN是一起发送，挥手的时候却是分开的时候发送呢？

• 因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个ACK报文，告诉Client端，已受到发的FIN报文。只有Server端所有的报文都发送完了，才能发送FIN报文，因此不能一起发送。

提问：为什么TCP挥手每两次中间有一个 FIN-WAIT2等待时间？

• 当主动关闭的一端发FIN给被动关闭的一端， 并且收到其对FIN的确认ACK后，则进入FIN_WAIT_2状态。可能会出现由于网络故障等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN，这个时候就需要FIN_WAIT_2定时器， 如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么直接释放这个链接，进入CLOSE状态

提问：为什么客户端最后还要有TIME-WAIT的等待2MSL？

• 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，服务器已经发送了FIN+ACK报文，请求断开，客户端却没有回应，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样新的连接中不会出现旧连接的请求报文。1MSL= 30 秒，2MSL = 60s

提问：服务端会有一个TIME_WAIT状态吗？

• 发起链接的主动方基本都是客户端，但是断开连接的主动方服务器和客户端都可以，也就是说，只要是主动断开连接的，就会有 TIME_WAIT状态