TCP 三次握手、四次挥手以及安全传输

TCP协议使用连接管理、流量控制、拥塞控制三大机制来保证可靠性传输

三次握手：

开始客户端处于 close  初始关闭状态

客户端：发送SYN=1(表示请求连接),seq=x(申明自己序号为x)

之后客户端处于 syn_sent  表示已经发送syn报文

开始服务器处于listen    监听状态，可以接受连接

服务器：响应SYN=1（表示可以连接),ACK=1 （响应确认连接），ack=x+1(前x收到，下次从x+1开始发送(下一次访问的序列号))，seq=y(声明自己序号为y)

之后服务器处于syn-rcvd  表示接受到了syn报文

客户端：发送ACK=1（确认连接）, ack=y+1, seq=x+1 (前y个已经收到，下一次从y+1开始发送)

之后客户端和服务器都处于 established，established    表示已经连接了

 

为什么要三次握手，两次不行吗？

结论：

为了防止已经失效的连接请求突然再发到服务端，然后服务端一直等待，浪费资源。

模拟场景：

假设只有两次，客户端向服务器发送请求建立连接的报文，但是这个报文再传输过程中在某个网络节点滞留了很长时间，甚至到连接释放以后才到达服务端，导致其失效，那么这个失效的报文服务端收到之后误认为是一个新的请求建立连接的报文然后向客户端发送确认，这样在两次握手的前提下，一个新的连接就建立成功了，但是客户端不会理会这样的失效报文带来的确认，那么服务端就会一直在等待，浪费资源。

四次挥手：

以客户端向服务器请求关闭为例（当然亦可以是服务器向客户端，请求关闭）

客服端开始处于 established状态  表示已经连接了

客户端发送：FIN=1(表示请求断开),seq=m

之后客户端处于fin-wait-1  表示等待对方的FIN报文

 

开始服务器处于 established 表示已连接了

服务器发送：ACK=1，ack=m+1 （前m个已经收到，下次m+1） seq=n

之后服务器处于close-wait等待关闭  客户端处于fin-wait-2  表示等待对方的FIN报文

 

服务器发送：FIN=1 ACK=1 ack=m+1  seq=w  

之后服务器处于处于last-ack 等待对方ack报文

客户端发送ACK=1,ack=w+1,seq=m+1

客户端处于time-wait 表示收到了对方的报文，等待2msl 即可回到关闭状态

服务器处于close状态

成功的会2msl后客户端处于close状态

为什么需要四次挥手？

结论：

为了保证数据的完全传输。