你管这破玩意儿叫TCP

你是一台电脑,你的名字叫 A
你管这破玩意儿叫TCP
只要你知道另一位伙伴 B 的 IP 地址,且你们之间的网络是通的,无论多远,你都可以将一个数据包发送给你的伙伴 B
你管这破玩意儿叫TCP
这就是物理层、数据链路层、网络层这三层所做的事情。
站在第四层的你,就可以不要脸地利用下三层所做的铺垫,随心所欲地发送数据,而不必担心找不到对方了。
你管这破玩意儿叫TCP
虽然你此时还什么都没干,但你还是给自己这一层起了个响亮的名字,叫做传输层
你本以为自己所在的第四层万事大吉,啥事没有,但很快问题就接踵而至。


问题来了

前三层协议只能把数据包从一个主机搬到另外一台主机,但是,到了目的地以后,数据包具体交给哪个程序(进程)呢?

你管这破玩意儿叫TCP

所以,你需要把通信的进程区分开来,于是就给每个进程分配一个数字编号,你给它起了一个响亮的名字:端口号

你管这破玩意儿叫TCP

然后你在要发送的数据包上,增加了传输层的头部,源端口号目标端口号
你管这破玩意儿叫TCP
OK,这样你将原本主机到主机的通信,升级为了进程和进程之间的通信
你没有意识到,你不知不觉实现了 UDP 协议
(当然 UDP 协议中不光有源端口和目标端口,还有数据包长度和校验值,我们暂且略过)
就这样,你用 UDP 协议无忧无虑地同 B 进行着通信,一直没发生什么问题。
你管这破玩意儿叫TCP
但很快,你发现事情变得非常复杂……


丢包问题

由于网络的不可靠,数据包可能在半路丢失,而 A 和 B 却无法察觉。
你管这破玩意儿叫TCP
对于丢包问题,只要解决两个事就好了。
第一个,A 怎么知道包丢了?
答案:让 B 告诉 A
第二个,丢了的包怎么办?
答案:重传
于是你设计了如下方案,A 每发一个包,都必须收到来自 B 的确认(ACK),再发下一个,否则在一定时间内没有收到确认,就重传这个包。
你管这破玩意儿叫TCP
你管它叫停止等待协议。只要按照这个协议来,虽然 A 无法保证 B 一定能收到包,但 A 能够确认 B 是否收到了包,收不到就重试,尽最大努力让这个通信过程变得可靠,于是你们现在的通信过程又有了一个新的特征,可靠交付


效率问题

停止等待虽然能解决问题,但是效率太低了,A 原本可以在发完第一个数据包之后立刻开始发第二个数据包,但由于停止等待协议,A 必须等数据包到达了 B ,且 B 的 ACK 包又回到了 A,才可以继续发第二个数据包,这效率慢得可不是一点两点。
于是你对这个过程进行了改进,采用流水线的方式,不再傻傻地等。
你管这破玩意儿叫TCP


顺序问题


但是网路是复杂的、不可靠的。
有的时候 A 发出去的数据包,分别走了不同的路由到达 B,可能无法保证和发送数据包时一样的顺序。
你管这破玩意儿叫TCP
在流水线中有多个数据包和ACK包在乱序流动,他们之间对应关系就乱掉了。
难道还回到停止等待协议?A 每收到一个包的确认(ACK)再发下一个包,那就根本不存在顺序问题。应该有更好的办法!
A 在发送的数据包中增加一个序号(seq),同时 B 要在 ACK 包上增加一个确认号(ack),这样不但解决了停止等待协议的效率问题,也通过这样标序号的方式解决了顺序问题。
你管这破玩意儿叫TCP
而 B 这个确认号意味深长:比如 B 发了一个确认号为 ack = 3,它不仅仅表示 A 发送的序号为 2 的包收到了,还表示 2 之前的数据包都收到了。这种方式叫累计确认累计应答
你管这破玩意儿叫TCP
注意,实际上 ack 的号是收到的最后一个数据包的序号 seq + 1,也就是告诉对方下一个应该发的序号是多少。但图中为了便于理解,ack 就表示收到的那个序号,不必纠结。


流量问题

有的时候,A 发送数据包的速度太快,而 B 的接收能力不够,但 B 却没有告知 A 这个情况。
你管这破玩意儿叫TCP
怎么解决呢?
很简单,B 告诉 A 自己的接收能力,A 根据 B 的接收能力,相应控制自己的发送速率,就好了。
B 怎么告诉 A 呢?B 跟 A 说’我很强’这三个字么?那肯定不行,得有一个严谨的规范。
于是 B 决定,每次发送数据包给 A 时,顺带传过来一个值,叫窗口大小(win),这个值就表示 B 的接收能力。同理,每次 A 给 B 发包时也带上自己的窗口大小,表示 A 的接收能力。
你管这破玩意儿叫TCP
B 告诉了 A 自己的窗口大小值,A 怎么利用它去做 A 这边发包的流量控制呢?
很简单,假如 B 给 A 传过来的窗口大小 win = 5,那 A 根据这个值,把自己要发送的数据分成这么几类。
你管这破玩意儿叫TCP
图片过于清晰,就不再文字解释了。
当 A 不断发送数据包时,已发送的最后一个序号就往右移动,直到碰到了窗口的上边界,此时 A 就无法继续发包,达到了流量控制。
你管这破玩意儿叫TCP
但是当 A 不断发包的同时,A 也会收到来自 B 的确认包,此时整个窗口会往右移动,因此上边界也往右移动,A 就能发更多的数据包了。
你管这破玩意儿叫TCP
以上都是在窗口大小不变的情况下,而 B 在发给 A 的 ACK 包中,每一个都可以重新设置一个新的窗口大小,如果 A 收到了一个新的窗口大小值,A 会随之调整。
如果 A 收到了比原窗口值更大的窗口大小,比如 win = 6,则 A 会直接将窗口上边界向右移动 1 个单位。
你管这破玩意儿叫TCP
如果 A 收到了比原窗口值小的窗口大小,比如 win = 4,则 A 暂时不会改变窗口大小,更不会将窗口上边界向左移动,而是等着 ACK 的到来,不断将左边界向右移动,直到窗口大小值收缩到新大小为止。
你管这破玩意儿叫TCP
OK,终于将流量控制问题解决得差不多了,你看着上面一个个小动图,给这个窗口起了一个更生动的名字,滑动窗口


拥塞问题

但有的时候,不是 B 的接受能力不够,而是网络不太好,造成了网络拥塞
你管这破玩意儿叫TCP
拥塞控制与流量控制有些像,但流量控制是受 B 的接收能力影响,而拥塞控制是受网络环境的影响。
拥塞控制的解决办法依然是通过设置一定的窗口大小,只不过,流量控制的窗口大小是 B 直接告诉 A 的,而拥塞控制的窗口大小按理说就应该是网络环境主动告诉 A。
但网络环境怎么可能主动告诉 A 呢?只能 A 单方面通过试探,不断感知网络环境的好坏,进而确定自己的拥塞窗口的大小。
你管这破玩意儿叫TCP
拥塞窗口大小的计算有很多复杂的算法,就不在本文中展开了,假如拥塞窗口的大小为  cwnd,上一部分流量控制的滑动窗口的大小为 rwnd,那么窗口的右边界受这两个值共同的影响,需要取它俩的最小值。
窗口大小 = min(cwnd, rwnd)
含义很容易理解,当 B 的接受能力比较差时,即使网络非常通畅,A 也需要根据 B 的接收能力限制自己的发送窗口。当网络环境比较差时,即使 B 有很强的接收能力,A 也要根据网络的拥塞情况来限制自己的发送窗口。正所谓受其短板的影响嘛~


连接问题

有的时候,B 主机的相应进程还没有准备好或是挂掉了,A 就开始发送数据包,导致了浪费。
你管这破玩意儿叫TCP
这个问题在于,A 在跟 B 通信之前,没有事先确认 B 是否已经准备好,就开始发了一连串的信息。就好比你和另一个人打电话,你还没有’喂’一下确认对方有没有在听,你就巴拉巴拉说了一堆。
这个问题该怎么解决呢?
地球人都知道,三次握手嘛!

A:我准备好了(SYN)

B:我知道了(ACK),我也准备好了(SYN)

A:我知道了(ACK)

你管这破玩意儿叫TCP
A 与 B 各自在内存中维护着自己的状态变量,三次握手之后,双方的状态都变成了连接已建立(ESTABLISHED)。
虽然就只是发了三次数据包,并且在各自的内存中维护了状态变量,但这么说总觉得太 low,你看这个过程相当于双方建立连接的过程,于是你灵机一动,就叫它面向连接吧。
注意:这个连接是虚拟的,是由 A 和 B 这两个终端共同维护的,在网络中的设备根本就不知道连接这回事儿!
但凡事有始就有终,有了建立连接的过程,就要考虑释放连接的过程,又是地球人都知道,四次挥手嘛!

A:再见,我要关闭了(FIN)

B:我知道了(ACK)

     给 B 一段时间把自己的事情处理完…

B:再见,我要关闭了(FIN)

A:我知道了(ACK)

你管这破玩意儿叫TCP


总结

以上讲述的,就是 TCP 协议的核心思想,上面过程中需要传输的信息,就体现在 TCP 协议的头部,这里放上最常见的 TCP 协议头解读的图。
你管这破玩意儿叫TCP
不知道你现在再看下面这句话,是否能理解:
TCP 是
面向连接的、可靠的、基于字节流的
传输层通信协议
面向连接、可靠,这两个词通过上面的讲述很容易理解,那什么叫做基于字节流呢?
很简单,TCP 在建立连接时,需要告诉对方 MSS(最大报文段大小)。
也就是说,如果要发送的数据很大,在 TCP 层是需要按照 MSS 来切割成一个个的 TCP 报文段 的。
切割的时候我才不管你原来的数据表示什么意思,需要在哪里断句啥的,我就把它当成一串毫无意义的字节,在我想要切割的地方咔嚓就来一刀,标上序号,只要接收方再根据这个序号拼成最终想要的完整数据就行了。
在我 TCP 传输这里,我就把它当做一个个的字节,也就是基于字节流的含义了。
你管这破玩意儿叫TCP


👇🏻 点击下方阅读原文,获取鱼皮的编程学习路线、原创项目教程、求职面试宝典、编程交流圈子。

往期推荐

春招,启动!

10 个解放双手的 IDEA插件,少写冤枉代码

前端调试工具超全汇总,效率翻倍!

哈哈,有人爬我网站,我把他教育了一顿!

动态代理是基于什么原理?

坏了,我把面试重点搞错了!

在上海做程序员这么多年,退休后我的工资是多少?

本内容观点仅代表发布作者本人观点立场,欣文网平台只做信息内容展示和存储。发布作者:全网转载,转转请注明出处:https://www.xinenw.com/44382.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2024年10月11日 23:46
下一篇 2024年10月11日 23:52

相关推荐

  • 可口可乐的新品为什么做不起来?

    炎炎夏日,喝一杯加冰可乐,幸福指数瞬间拉满。 然而最近,这瓶属于夏天的“快乐水”也要涨价了。 据湖北、江西、郑州三家太古可口可乐饮料公司此前披露的告知函显示,包括汽水、果汁、乳味饮料在内的多款产品将要调整价格。 郑州主要调整可乐、雪碧、芬达、醒目等6款500ML汽水产品,建议售价3.5元,较此前3元建议售价涨幅约16.6%。而湖北、江西的调整范围则更广泛,覆…

    2024年6月12日
    16300
  • 三年前的小爆款黄油,满足了玩家在涩涩里找游戏性的需求

    《魔剑梦魇》是一款Brianode制作、Eroge Japan发行的3D建模的横版动作游戏,虽然他的画面并不精细,建模也一般,还能看到很多免费素材的影子,但令人吃惊的是,他的战斗系统还可以,而且有着正经游戏一般的出色手感,算是意外之喜。 小爆款作品 《魔剑梦魇》于2021年8月11日在dl平台发售,至今已卖出超12000份,并拿下了当时的日榜第一和周榜第一,…

    2024年9月1日
    8300
  • 选择买断制后团队解散又奇迹般复活的手游,今天上线了

    今年3月,我们在B站发布了国产横版动作游戏《苍翼:混沌效应》的纪录片,至今已经有超过360万次播放。 而《苍翼:混沌效应》受到如此多关注的原因,是这款游戏背后曲折而又梦幻的幕后故事,堪称中国游戏史上难得一见的,开发者和玩家双向奔赴的奇迹。 从好评如潮到褒贬不一,再到好评如潮;从登上国产游戏畅销榜,到团队全员解散,只剩下制作人一个人,再到团队重新集结,奇迹般的…

    2024年10月10日
    1900
  • 多维视角下的思维变革

    在快速发展的现代社会中,我们每天都在面临各种选择和决策。如何从繁杂的信息中筛选出有价值的内容,如何在激烈的竞争中保持优势,这不仅仅是对个人能力的考验,更是对思维模式的挑战。从成本思维到多维思维,再到专注思维和变量思维,这些思维模式为我们提供了独特的视角和解决问题的策略。 一、成本思维:性价比的智慧 成本思维是一种强调性价比的思维方式。它提醒我们,在做出任何决…

    2024年6月9日
    13900
  • 买家“仅退款”被起诉判赔,为网店商家提供了维权范本

    陈依芸 湖南师范大学 ——2024年度红网“青椒评论”系列作品 近日,广西壮族自治区贺州市钟山县人民法院公安人民法庭快速调解了一起因买家网购后“仅退款不退货”引发的纠纷,最终买家退回11.96元货款以及赔偿店家因维权产生的800元合理费用。(7月16日 光明网) 为保护消费者权益,许多电商平台都推出“仅退款”“七天无理由退货”“运费险”等一系列服务,在某些情…

    2024年7月20日
    12500

发表回复

登录后才能评论

联系我们

400-800-8888

在线咨询: QQ交谈

邮件A:xinenw@qq.com

邮箱B:xinenw@163.com

工作时间:周一至周五,8:30-23:30;周六周日10:30-18:30;节假日休息

关注微信