TCP三次握手通信流程

黎小强
2021-09-06 / 0 评论 / 559 阅读 / 正在检测是否收录...

流程

  1. 客户端访问Web站点时,首先会通过DNS服务查询到域名的IP地址。
  2. 然后浏览器生成HTTP请求,并通过TCP/IP协议发送web服务器,
  3. 发送web服务器之前必须双方服务器先建立通讯,才能开始传输数据
  4. web服务器接收到请求后,会根据请求生成响应内容,并通过TCP/IP协议返回给客户端

image.png

TCP的三次握手

使用TCP协议进行通信的双方必须先建立连接,然后才能开始传输数据,为了确保连接双方可靠性,在双方建立连接时,TCP采用了3次握手策略

image.png

image.png

第一次握手

客户端发送带有SYN标识的连接请求报文段,然后进入SYN_SEND状态,等待服务端确认。

第二次握手

服务端接受到客户端的SYN报文段后,需要发送ACK信息对这个SYN报文进行确认,同时,还要发送自己的SYN请求信息。

服务端会将上述的信息放到一个报文段(SYN+ACK报文段)中,一并发送给客户端。

此时服务端将会进入SYN_RECV状态。

第三次握手

客户端接受到服务端的SYN+ACK报文段后,会向服务发送ACK确认报文,这个报文段发送完毕后,客户端和服务端都进入ESTABLISHED状态,完成TCP的三次握手,可以进行数据传输了。

2次就可以完成,为什么要进行3次握手?3次握手的目的是什么?

最根本的目的客户端和通讯端要进行连接,要确认双方都能明确自己和对方收发能力都是正常的

第一次握手

客户端发送网络包,服务端收到了。服务端得出结论 ( 客服端发送能力是正常,我自己的接收能力是正常 ,而客户端什么都不知道,只知道他发出了请求。)

第二次握手

所以服务端给客户端一个确认 ,发了一个包(确认+ 网络包的请求)给客户端。

这样客户端得出结论 ( 服务端的接收能力是正常的 ,因为接收到我上一个数据, 服务端的发送能力也是正常的 ,因为它给我发来新的包。

同时我也知道我自己客户端 前面一定是接收到我的包才给我发的新包, 确认我自己发送跟接收能力都正常的 。)

客户端第一次发送的是正常的,第二次我收到了,我的接收能力也是正常的。

第三次握手

是因为服务端只知道 客户端的发送能力、和服务端的接收能力 不知道自己的发送能力行不行。

当客户端再二次发送的时候,服务端接收到了,就知道了 客户端的接收能力,跟我的发送能力也是正常的

经历3次握手客户端跟服务端都确认了自己的接收、发送是正常的,之后就可以正常的通信了。

每次接收方的一方得到结论,发送的一方没有头绪,想要建立一个连接至少最少要3次或三次以上,2次达不到让双方都知道自己的接收、发送能力。

每一次接收都知道对方发送、我方接收是正常的,每次都是关联的一个过程。能接收到上次我发送的数据才能知道这次的响应。

现实举例

小A跟小B都新买了手机,想要测试下2个的短信功能是否正常

小A先发条信息给小B,说: “ 小B,你能收到我的短息吗?收到回复666 ”

小B过了一会,收到了短信。证明了小A手机的发短信功能是ok的 ,自己的手机接收短信是OK的。

然后小B想知道自己的发送短信行不行,所以回复了一条 : “ 小A我收到了你信息,666,那你能收到我信息吗?收到给我回个 火箭”

这时候小A也收到了小B的回复。其实在没收到短信之前,小A也不知道他的发送短信有没有发出去。

但是一收到回复,就验证知道了。第一条肯定是发送成功 的,不然小B就回复给我回复了。

同时小B也接收到了,他还发出来了,证明了我自己的接收跟发送都OK, 我也知道了小B的收发能力OK)。

小A想了想... 我自己知道了他是没问题的。但是小B不知道他的发送OK是否知道。

要是不回复的话,小B 不知道他短信是否发成功。所以小A最后回复了一条 : “收到了,火箭火箭”。

这时候小B就可以确认,自己的发送和小A的接收都没问题。

这就是三次握手的经过。

1

评论 (0)

取消