TCP连接为什么只能是“3次握手”,不是2次,也不是4次?

栏目: 服务器 · 发布时间: 5年前

内容简介:我们知道客户端(Client)A 和服务器端(Server)B 的通信方式可分为:全双工、半双工、单工:TCP 属于全双工。

我们知道客户端(Client)A 和服务器端(Server)B 的通信方式可分为:全双工、半双工、单工:

  • 单工:A 可以发给 B ,B 不能发给 A ,叫做单工
  • 半双工:A 可以发给 B , B 也可以发给 A ,但是两者的步骤不能同时进行,即 A 给 B 发信息的时候,B 不能给 A 发。
  • 全双工:即客户端 A 在给服务器端 B 发信息的同时,服务器端 B 也可以给客户端 A 发送信息。

TCP 属于全双工。

TCP连接为什么只能是“3次握手”,不是2次,也不是4次?

TCP 的工作原理

下面小编就带你们了解 TCP 的工作原理是啥?

由前面的知识我们学习到 TCP 有三次握手(前文参考:HTTP也有长短之分?HTTP的长连接vs短连接)。

TCP 的三次握手的示意图:

TCP连接为什么只能是“3次握手”,不是2次,也不是4次?

具体的含义理解可以这样看:

1. 第一次握手

客户端想服务器发送一个 SYN 标志位为1的包,以及初始序号X,包装在包的头的序列号字段里。

客户端进入 SYN_SEND 状态,等待服务器端的确认。

2. 第二次握手

服务器发回 ACK(确认包),即将SYN和ACK标志位都命名为1,同时将序列号修改为X+1。

同时自己也发送了一个包,SYN包,序列号(seq =Y),即 SYN +ACK 包。

此时服务器进入 SYN_RECV 状态。

3. 第三次握手

客户端接收到服务器发送过来的(ACK+SYN)包,SYN 标志位为0。ACK 标志位为1。

同时把服务器发过来的 ACK 包序列号字段+1并放在包中,发给服务器即 ACK=Y+1。

通俗解释:

是不是觉得还是很难懂啊,那下面就给你举个例子。

首先我们假设 A和B 是本次进行通信的双方。 而发一次信息就代表着一次握手。

  • 第一次握手: A 给 B 发微信语音聊天,在吗?能听到我讲话吗?
  • 第二次握手:B 收到了 A 发来的微信语音通话,然后对A说:嗯,人在的,我能听见你说的话,你能听得见我说话吗,有什么事情?
  • 第三次握手: A 收到了 B 回复回来的信息语音,我想问你一件事?

然后就开始愉快的聊天了。

两次握手是否可以?

那我们接下来探究 两次握手可不可以?

  • 第一次握手之后: 服务器端B 可以接收到客户端A发来来的信息,但是对于客户端A 来说,它并不能确定自己发送的消息有没有成功。
  • 第二次握手之后: 服务端B 向客户端A 发送的报文信息,服务器端B可以认为我发送的消息成功了。
  • 如果现在没有第三次握手的话,服务器端B 在进行第二次握手之后,会认为我们的连接时成功的。

但是对于,客户端A 呢?并不能保证一定能接收到服务器端B发来的信息吧,如果客户端A没接受到服务器端发来的信息呢?

客户端就会认为我们之间的通信没有建立起来。 这样的通信过程显然是不成功的。

如果存在大量的这种情况发生的话,服务器B 会发生崩溃的。

看样子仅仅两次握手是不行的,完成不了 TCP 的通信工作原理。

两次不行,那四次呢?

四次握手行不行?

我们根据上面的 TCP 通信原理可知道,经过三次握手之后,客户端A 和服务器端B 都可以确认之前他们的所发送的消息,各自都能收到且报文也都成功发送给对方了。

依据上面那个结论可知道,你是四次握手还是五次握手,都是徒劳的。因为经过“三次握手”之后,把该做的事情都做完了。

结论

TCP 的三次握手是经典,计算机上的通信协议也都依据于 TCP 的三次握手和四次挥手。

因为计算机应用直接的通信依据于 HTTP 协议,而 HTTP 实质上是依靠 TCP 协议完成的,这个知识在前面说过。从而形成了:

  • TCP 只能是三次握手,不能是两次,也不能是四次。
  • 少于三次握手,不能保证是否建立了通信连接;
  • 多于三次握手,都是徒劳和浪费的。

我们看出经过三次握手之后,我们可以得出下面的结论:

  • A 可以给B发送消息了,同时A也能接受到B发来的信息;
  • 与此同时对于B而言,B也可以给A发送消息,同时B也能接收到A发来的消息。

以上所述就是小编给大家介绍的《TCP连接为什么只能是“3次握手”,不是2次,也不是4次?》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Realm of Racket

Realm of Racket

Matthias Felleisen、Conrad Barski M.D.、David Van Horn、Eight Students Northeastern University of / No Starch Press / 2013-6-25 / USD 39.95

Racket is the noble descendant of Lisp, a programming language renowned for its elegance and power. But while Racket retains the functional goodness of Lisp that makes programming purists drool, it wa......一起来看看 《Realm of Racket》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具