Tcp--三次握手，四次挥手的理解

个人印象笔记地址 https://app.yinxiang.com/fx/ba73dae0-da3e-45d6-bca4-d9cf6a0b9c18

Tcp--三次握手，四次挥手

TCP协议中，主动发起请求的一端称为『客户端』，被动连接的一端称为『服务端』。不管是客户端还是服务端，TCP连接建立完后都能发送和接收数据。

刚开始的时候，服务器和客户端都为CLOSED状态。在通信开始前，双方都得创建各自的传输控制块（TCB）。

服务器创建完TCB后遍进入LISTEN状态，此时准备接收客户端发来的连接请求。

 

1.第一次握手

客户端向服务端 发送连接请求报文段。该报文段的头部中同步SYN=1，确认ACK=0，同时选择一个初始序号seq=x。请求发送后，客户端便进入SYN-SENT状态。

• SYN=1，ACK=0表示该报文段为连接请求报文
• x为本次TCP通信的字节流的初始序号
• TCP规定：SYN=1的报文段不能有数据部分，但要消耗掉一个序号

2.第二次握手

服务端收到连接请求报文段后，如果同意连接，会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。发送完应答后服务端进入SYN-RCVD状态。

• SYN=1，ACK=1表示该报文段为 连接同意的应答报文
• seq=y表示服务端作为发送者时，发送字节流中的第一个字节序号
• ack=x+1表示服务端希望客户端发送的下一个数据报初始序号是从x+1开始

3.第三次握手

客户端收到服务端连接同意的应答后，还会向服务端 发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。该报文段的头部为：ACK=1，seq=x+1，ack=y+1。

客户端发完这个报文段后便进入ESTABLISHED状态，服务端收到这个应答后也进入ESTABLISHED状态，此时 连接的建立完成！

 

TCP建立连接为什么是三次握手，而不是两次或四次？

不论握手多少次都不能确认一条 信道一定是“可靠”的，

但通过3次握手可以至少确认它是“可用”的，再往上加握手次数不过是提高它是“可用”的这个结论的可信度。

也就是说 任意次的握手都是“不可靠”的，握手成功只能说明握手时的通信是正常的， 并不能保证握手后的通信是正常的。

握手只能保证尽可能的可靠，而不可能保证绝对可靠。

 

那为什么不是两次握手？

是为了 防止已失效的连接请求报文段突然又传送到了服务端，造成服务端资源的浪费 。

 

在一次TCP连接中，客户端A向服务端B发送连接请求SYN报文段，假如这个报文段没有及时被服务端B接收，而是滞留在网络的某处，于是客户端A超时重传，再次发送请求连接并且顺利与服务端B建立了连接，交换数据后断开连接。

滞留在网络中的某处的陈旧报文就变成了失效的连接请求报文。

但如果这个失效的请求SYN报文段，现在又突然传送到了服务端B处，设想这时是使用两次握手而不是三次握手，服务端B就以为客户端A现在建立请求连接，于是服务端B发出确认，新的连接就建立了，服务端B分配资源，等待客户端A传送数据，但客户端A并没有想要建立TCP连接，不会理会服务端B发送的应答，也不会向服务端B传送数据，于是服务端B就白白等待，空耗资源

 

为啥三次握手可以解决这个问题？

使用三次握手可以避免这个情况。

服务端B收到客户端A的失效的陈旧SYN报文段，向客户端A发送SYN报文段，选择自己的序号seq=y，确认收到客户端A的SYN报文段，确认号ack=x+1。

第三次握手客户端A收到B的SYN报文段后，从确认号就可得知不应理睬这个SYN报文段（因为A现在并没有发送seq=x的报文段）。

这时，客户端A会发送复位报文段，这个复位报文段中，RST=1，ACK=1，确认号ack=y+1。

服务端B收到A的复位报文，就知道不建立TCP连接，不会分配资源等待A发送数据。

 

 

 四次挥手是什么？

 

 

• 第一次挥手：客户端发送FIN=1，用来关闭客户端到服务端的数据传送，随机产生一个seq=u，将该数据包发送给服务端，客户端进入FIN_WAIT_1状态。
• 第二次挥手：服务端收到结束标志FIN=1后，发送确认标志ACK=1给客户端，确认号ack=u+1，随机产生一个seq=v，将该数据包发送给客户端，服务端进入CLOSE_WAIT状态。
• 第三次挥手：服务端发送结束标志FIN=1，用来关闭服务端到客户端的数据传送，并发送确认标志ACK=1，随机产生一个seq=w，ack=u+1，将该数据包发送给客户端，服务端进入LAST_ACK状态。
• 第四次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送确认标志ACK=1给服务端，确认号seq=u+1，服务端进入CLOSED状态。

      完成四次挥手，成功断开连接。

 

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

第一：为了保证服务端能收到客户端的确认应答。

第二：防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。

 

 

TCP/IP 模型：

 

TCP协议和UDP协议：