TCP连接建立三次握手:
①开始时客户端A和服务器端B都处于“CLOSE(关闭)”状态。随后B先进入“LISTEN(收听)”状态。
②A首先向处于“LISTEN”状态的B发送“连接建立请求报文”,报文不携带任何的数据段,但是SYN=1, seq = x。随后,A进入“SYN-SEND准备发送”状态。
③B收到“连接建立请求报文”后,同意连接,则向A发送“连接建立请求确认报文”,有,SYN=1,ACK=1,ack = x+1,seq = y。随后,B进入“SYN-RCVD准备接收”状态。
④A收到“连接建立请求确认报文”后,客户端发送“连接建立请求确认报文”,有,ACK = 1, ack = y+1, seq = x+1。随后,A进入“ESTABLISHED已建立连接”状态。服务器端B在收到ACK报文后,也进入“ESTABLISHED已建立连接”状态。
为什么不是2次握手:防止失效的连接请求报文段突然又传送到主机B
①A首先发送一个连接请求,但是该请求在网络节点上滞留了,没有收到确认。于是A重传了一次请求,并且收到了B的确认,于是连接建立,数据传输完成后,释放连接,假定A发出的第一个请求报文段并没有丢失,而是在某些网络节点上滞留,本来是一个失效的请求,但B收到后误认为是A再次发出一个新请求,于是向A发送确认,同意建立连接。
②假定采用两次握手,那么只要B发出确认,则新的连接就建立了。由于A并没有发出请求,因此不理会B的确认,也不会向B发送数据,但B却以为新的连接已经建立,并一直等待A的数据,B的许多资源就这样白白浪费了。
③假定采用三次握手,则B发出确认,但A因为并没有发请求,所以不理会B的确认,B没有收到A的确认,则连接建立失败,B知道连接建立失败。会回收资源。
④极端的情况可能由于Client用户端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待,因而造成极大的资源浪费!所以,“三次握手”很有必要。
为什么不采用4次握手:
①握手握的是序列号,四次握手的过程是:(1)A发送给B 同步序号SYN+A的seq为x;2,B收到后确认收到ACK发给A,然后令ack=x+1,确认A的seq按序到达;3,B向A发送SYN+自己的序列号seq为y;4, A收到B的序列号,存储到本地,发送ack=y+1,确认收到了,发送ACK+ack和自己的新序号seq为x+1。
②其中2,3两步是完全可以归为一次发送的,所以不需要四次握手。