别被三次握手和四次挥手骗了!

提供的条款可以仔细阅读,它生动地描述了TCP/IP协议的三个握手阶段。

你是机器,我叫A

你知道另一个伙伴B的IP地址,无论你们之间的网络有多遥远,都可以将数据包传送给伙伴B。

物理层、数据链层和网络层都这样做。

你们在四楼,所以你们可以使用三层楼 并随心所欲地传输数据 不必担心无法找到彼此

你当时什么都没做 但你给自己贴了传输层的标签

你误以为自己在四楼,什么事都没发生,但问题终于浮出水面了

问题来了
前三级协议只能将数据包从一个主机传送到另一个主机;但是,到达目的地后,哪一种软件(程序)将接收数据包?

因此,您必须分割通信进程, 所以您为每项活动指定一个数字, 并给它一个响亮的名字: 端口号 。

下一步,在发送的数据包中添加传输层的头、源和目标端口号。

因此,你可能从主机对主机的通讯到过程到过程的通讯。

你不知道你参加联合民主党协议 却不承认!

(当然,UDP协议不仅包括源港口和目标港口,而且还包括我们省略的数据集长度和核查价值。 )

所以,你一直在使用UDP 与B沟通 不用担心, 什么都没有发生。

然而,事情迅速变得困难..

丢包问题
由于网络不可靠,数据包可能会在中间丢失,没有注意A和B。

只有两样东西足以让下沉

第一个是A 你怎么知道它不见了?

让B告诉A答案。

第二个问题是,失踪的袋子怎么了?

答案：重传

于是你设计了以下情景:A,每个包件必须从B处得到确认(ACK),否则包件将在特定时限内重新传送。

停止等待交易是您给它取的名字。 只要A不能保证B会收到包件, A能够确认B是否收到包件, 并且没有收到, 重新尝试并尽力使通信过程可信, 所以现在你有一个新的特性, 等待交易的可靠交付依赖是您的名字。 只要根据该协议, A不能保证B会收到包件, A能够确认B是否收到, 没有收到, 重新尝试并尽力使通信过程可信, 所以现在你有一个新的特性, 可靠的交付。

效率问题
虽然停止等待会解决问题,但A一旦第一个数据包发布,就能够开始发送第二个数据包是效率低下的,但是,由于停止等待协议,A必须等待数据包到达B和B的ACK软件包返回A,而A并不特别缓慢。

所以,你已经强化了过程, 你会使用流动线 而不是等待。

顺序问题
然而,互联网是复杂和不值得信赖的。

当A提供数据包时,可以选择B的替代路径,但可能无法按照数据包发送时的顺序保证。

许多数据包和ACK软件包都以有条不紊的方式在流动线上行长,它们的通信也支离破碎。

您还想停止等待协议吗?A. 每一包裹获得确认和交付到下一包裹的顺序是毫无疑问的。必须有一个更好的办法。

A在交付的数据包中添加序列号(seq),而B在ACK软件包中添加确认号(ack),不仅消除了不等待协议的效率问题,而且消除了通过序列编号产生的订单问题。

例如,B提供了一个ck = 3的识别编号,说明不仅收到了A发送的序列号为2的包件,而且数据包是在2之前收到的。

事实上,cock 的号码实际上是最后收到的数据包的序列号,后加1,即相互通知下一个序列号应该是什么。为清楚起见,图中的数字显示收到的序列号,因此没有必要集中关注。

流量问题
有时A发送货物太快,B无法接收,但B没有通知A。

怎么解决呢？

就像B告诉A自己的接收能力一样容易,A根据B的接收能力 相应地控制自己的发送率,B的接收能力运作良好。

B如何告知A?B告诉A,“我很坚强。”这行不通。必须有一个严格的规则。

因此,B确定,每次你向A发送包件时,你都会提供一个称为窗口大小(win)的号码,这表示B接受包件的能力。同样,每个A类包件对B类包件都使用自己的窗口大小,显示A类的接收能力。

B告诉A 如何利用他自己的赢家规模 来做A的交通管理?

简言之,如果B提供值赢=5,A根据这个数字将打算提供的数据分成这些类别。

图像太清晰,无法用文字描述。

当 A 无法继续发送软件包并完成交通管理时, 将最后的序列号传送到右侧, 直到它到达窗口的上界 。

然而,当A继续发送包件时,A从B处收到确认包,窗口向右推进,导致上边界也向右移动。

上述所有内容的窗口大小相同, 但是 B 可以调整给 A 的 ACK 包中的新窗口大小, 如果 A 获得新的窗口大小, A 将相应更改 。

如果 A 的窗口大小大于初始窗口值, 例如, 赢 = 6, A 一个单位将窗口边框加到右侧 。

如果 A 获得的窗口大小小于初始窗口值的窗口, 如赢= 4, 它不会在一段时间内修改窗口大小, 更不用说将顶端边界移到左侧, 而是要等待 ACK 并移动左边的边界到右侧, 直到窗口大小缩小到新的大小 。

最后,你已经解决了交通控制问题。你看看一个移动的图像, 给这个窗口一个更戏剧化的名称, 一个幻灯片窗口。

拥塞问题
然而,并非总有这样的情况:B接受能力有限;网络往往不足,造成网络拥堵。

拥挤控制在某些方面类似于交通控制,但交通控制是由B的接收能力驱动的,而交通控制则受网络环境的影响。

拥堵管理问题的答案是建立窗口大小,但交通控制窗口的大小是B,而拥堵控制窗口的大小是网络环境,积极主动地告诉A。

网络环境如何告诉 A? 只有 A 能够检测网络环境的运行情况,然后计算自己的压缩窗口的大小。

压缩窗口大小的计算需要许多复杂的方法,在本研究中没有实施。 如果压缩窗口是 cwnd 大小的,而流动控制滑动窗口的最后一部分是 rwnd 大小的,那么两个数值都会影响窗口的右边,并且其最小值是必要的。

最小( cwnd, rwnd) 窗口大小

这个想法很简单:当 B 接收能力较低时, 即使网络高度开放, A 也必须根据 B 接收能力限制自己的分配窗口 。 当网络环境更糟时, 即使 B 接收能力大, A 也限制自己的分配窗口 。 这就是我说的。

连接问题
当B主机上的等同程序没有准备好或被拖延时,A开始传送包件,造成浪费。

问题是, A 发送了一系列信息, 却没有先确定 B 是否准备和他沟通。 这就像你在给别人打电话。 你没有说"你好"来确保他们注意, 你在说很多事情。

我们有什么办法来解决这一问题?

大家都知道 举起三拇指!

A:我准备好了。

B:我理解,我准备接受SYN

答:我理解。

一个储存着自己记忆中的状态变量,经过三次握手后,双方的州都相连(STABLISHED)。

尽管只提供了三个数据包,并且保存了各自的记忆中的状态变量,但似乎太低了,你认为这个程序是建立双方联系的过程,所以你很聪明,你会把它贴上标签。

注意:链接是虚拟的,由A和B两个终端维持,网络设备不知道连接!

然而,在加入时,是时候考虑释放该链接的过程了,地球居民对此有四次了解。

A:再见。我要说完。

B:我理解。

在这里,B,花点时间照顾自己..

B:再见。我要说完。

答:我理解。

总结
这些是TCP协议的基本概念,在协议过程中必须传达的信息反映在TCP协议的头部,头部显示的是最典型的TCP头条读数。

我不确定你现在能不能读下一句

TCP 是

连接、可靠和以字节为基础

传输层通信协议

这两个词从上述解释中可以清楚地看出,该解释以字节流为基础。

很简单: TCP 建立连接后必须通知其他 MSS 。

换句话说,如果要转移大量数据,TCP级别必须用管理支助系统分成一个单一的TCP部分。

在切割时,我不管你的原始数据意味着什么,在哪里必须停止,或者其他什么; 我只是把它看作是一个毫无价值的字节集, 一把刀子,我想切开它, 和一个序列号,只要接收器按照这个序列号拼写最后完整的数据。

当我处理TCP传输时,我把它看作是一个字节, 以字节流为基础。

归根结底,你将承担A和B的建模任务,以便建立TCP连接。

问题1:将“aa”传送到B和B,B以A的简单字符串“aa”回应,抓住这个过程。

问题二:发送“aa

这是我的包

三次握手阶段

A -> B [SYN] Seq=0 Win=64240 Len=0

MSS=1460 WS=256

B - >A [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0

MSS=1424 WS=512

A -> B [ACK] Seq=1 Ack=1 Win=132352 Len=0

数据发送阶段

A -> B [ACK] Seq=1 Ack=1 Win=132352 Len=1424

A -> B [ACK] Seq=1425 Ack=1 Win=132352 Len=1424

A -> B [PSH, ACK] Seq=2849 Ack=1 Win=132352 Len=1247

B -> A [ACK] Seq=1 Ack=1425 Win=32256 Len=0

B -> A [ACK] Seq=1 Ack=2849 Win=35328 Len=0

B -> A [ACK] Seq=1 Ack=4096 Win=37888 Len=0

B -> A [PSH, ACK] Seq=1 Ack=4096 Win=37888 Len=7

四次挥手阶段

B -> A [FIN, ACK] Seq=8 Ack=4096 Win=37888 Len=0

A -> B [ACK] Seq=4096 Ack=9 Win=132352 Len=0

A -> B [FIN, ACK] Seq=4096 Ack=9 Win=132352 Len=0（下面少复制了一行ACK，抱歉）

后记
关于TCP, 许多人无疑会想到三节握手和四节波动。

然而,如果你继续走这条线, 你会发现三个握手和四个挥手只是 TCP 所处理的主要传统文化中的一小部分, 仅仅因为它是一个很好的点 在采访中作为一个知识点来看待, 所以许多人似乎认为TCP的核心 是握手和无波的, 如果你继续走这条线, 你会发现三个握手和四个挥手 只是TCP 所处理的主要传统文化中的一小部分, 仅仅因为它是一个很好的点 在采访中作为一个知识点来看待, 所以它就像很多人相信 TCP 的核心是握手和波。

文章希望您能充分理解 TCP 试图解决的问题。 许多概念都是自然的, 与常识一样。 这不难。 我希望您能收到您的愿望 。

源：低并发编程

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/12478.html。