TCP的三次握手。
第一次握手:建立连接时,客户端 发送 syn 包(syn=j)到 服务器,并进入 SYN_SENT 状态,等待服务器确认;
syn:同步序列号(Synchronize Sequence Numbers)
第二次握手:服务器 收到 客户端 发送的 syn 包,必须确认客户的ACK(ack=j+1),同时自己也发送一个 SYN包(seq=k),即 SYN+ACK包,此时服务器进入 SYN_RECV 状态;
seq: (sequence)
ack: 确认
第三次握手:客户端 收到 服务器 的 SYN+ACK 包,向 服务器 发送确认包 ACK(ack=k+1),此包发送完毕,客户端和服务器进入 ESTABLISHED(TCP连接成功)状态,完成三次握手。
established: 建立成功了
*******************************************************************************************************************************
为啥需要三次,而不是两次?
那么我们必须明白一个事情,握手是为了解决什么问题?
握手要解决的问题其实是:希望服务器端只开一个连接给客户端使用。两次握手不是一定不成功
假设 a 送信给 b(第一次)。
b 收到信,并再次写信告诉 a 她收到信了!(第二次)
这时候 a 并没有再写信给 b(没有第三次)。
表面上 a 和 b 通信已经成功,但这里其实有两种可能:
1. a 没有到 b 的信。
2. a 可以收到 b 的信。
问题就在这里,假设只有两次握手
a 送信给 b, b 收到信后再次写信传给 a(两次握手完毕)。
但是,b 的信给 a 的时候,信丢了(b 到 a 的网络不通)。
此时,a 没有收到信的情况下,会以为信没有发给 b。(因为是两次握手,此时的 b 只是假设 a 收到了包)
b 此时的状态是,开放了一个通道,等 a 再次写信过来。
a 此时的状态是,因为没收到回信,重新发信给 b 。(其实 a 如果收到包,那么两次握手也成功建立了连接)
那么 b 收到信之后又会开一个新通道等 a 发信过来,周而复始,就造成了网络资源浪费!!!
3次握手之后就没有这种问题吗?
3 次握手成功,证明了a 到 b 和 b 到 a 网络是通的。a 发送信息给 b,这时候有个超时时间,如果 b 的信息发送不到 a 那里(这时候会超时),那么 a 按道理会重新发送一个新请求,直到 b 收到信息且返回给 a 为止。
为什么握手的时候不直接发正文信息,因为如果网络不通的情况下,发送正文给服务器,那么服务器很容易拥堵挂掉。
总结:3次握手是为了减少因网络或其他原因造成不必要的资源浪费(a没有收到b的包的情况下)