三次握手简单理解

三次握手 四次挥手

建立TCP连接需要三次握手, 而断开连接需要执行四次挥手.

信号

1. SYN 同步
2. ASK 确认
3. PSH 推送
4. FIN 结束
5. URG 紧急
6. RST 重置

三次握手

1. TCP服务器进程首先创建进程控制块TCB, 服务器进入LISTEN监听状态, 时刻准备接受客户进程的请求
2. 客户端
   • 创建TCB传输控制块. 发出请求报文
   • 同步为SYN=1, 初始序列号seq=x
   • 客户端进入同步发送状态SYN-SEND
   • TCP报文规定, SYN报文段不能携带数据, 但是需要消耗一个序列号
3. 服务器
   • 收到客户单请求报文, 如果同意连接, 发送确认报文
   • 发送报文: ACK=1, SYN=1, 确认号ack_number=x+1, seq=y
   • 服务器进入同步收到状态SYN-RCVD
   • 该报文不能懈怠数据, 但是需要消耗一个序列号
4. 客户端
   • 收到报文后, 还需要向服务器确认
   • 发送: ACK=1, ack_number=y+1
   • 客户端进入ESTABLISHED已经建立连接状态
   • TCP规定: 该报文可以携带数据, 但是如果没有携带数据的话, 不用消耗一个序号
5. 当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

三次握手的目的:

• 消除旧有的连接请求SYN消息, 对新连接的干扰, 同步连接双方的序列号和确认号码, 交换TCP窗口的大小信息
• 如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

四次挥手

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

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

• 第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

• 第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

1. 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

2. 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

1. TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。

2. 服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，

3. 若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP 三次握手 四次挥手.png