趣谈网络协议
刘超
网易研究院云计算技术部首席架构师
立即订阅
39583 人已学习
课程目录
已完结 51 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想成为技术牛人?先搞定网络协议!
免费
第一模块 通信协议综述 (4讲)
第1讲 | 为什么要学习网络协议?
第2讲 | 网络分层的真实含义是什么?
第3讲 | ifconfig:最熟悉又陌生的命令行
第4讲 | DHCP与PXE:IP是怎么来的,又是怎么没的?
第二模块 底层网络知识详解:从二层到三层 (5讲)
第5讲 | 从物理层到MAC层:如何在宿舍里自己组网玩联机游戏?
第6讲 | 交换机与VLAN:办公室太复杂,我要回学校
第7讲 | ICMP与ping:投石问路的侦察兵
第8讲 | 世界这么大,我想出网关:欧洲十国游与玄奘西行
第9讲 | 路由协议:西出网关无故人,敢问路在何方
第二模块 底层网络知识详解:最重要的传输层 (4讲)
第10讲 | UDP协议:因性善而简单,难免碰到“城会玩”
第11讲 | TCP协议(上):因性恶而复杂,先恶后善反轻松
第12讲 | TCP协议(下):西行必定多妖孽,恒心智慧消磨难
第13讲 | 套接字Socket:Talk is cheap, show me the code
第二模块 底层网络知识详解:最常用的应用层 (4讲)
第14讲 | HTTP协议:看个新闻原来这么麻烦
第15讲 | HTTPS协议:点外卖的过程原来这么复杂
第16讲 | 流媒体协议:如何在直播里看到美女帅哥?
第17讲 | P2P协议:我下小电影,99%急死你
第二模块 底层网络知识详解:陌生的数据中心 (6讲)
第18讲 | DNS协议:网络世界的地址簿
第19讲 | HTTPDNS:网络世界的地址簿也会指错路
第20讲 | CDN:你去小卖部取过快递么?
第21讲 | 数据中心:我是开发商,自己拿地盖别墅
第22讲 | VPN:朝中有人好做官
第23讲 | 移动网络:去巴塞罗那,手机也上不了脸书
第三模块 热门技术中的应用:云计算中的网络 (5讲)
第24讲 | 云中网络:自己拿地成本高,购买公寓更灵活
第25讲 | 软件定义网络:共享基础设施的小区物业管理办法
第26讲 | 云中的网络安全:虽然不是土豪,也需要基本安全和保障
第27讲 | 云中的网络QoS:邻居疯狂下电影,我该怎么办?
第28讲 | 云中网络的隔离GRE、VXLAN:虽然住一个小区,也要保护隐私
第三模块 热门技术中的应用:容器技术中的网络 (3讲)
第29讲 | 容器网络:来去自由的日子,不买公寓去合租
第30讲 | 容器网络之Flannel:每人一亩三分地
第31讲 | 容器网络之Calico:为高效说出善意的谎言
第三模块 热门技术中的应用:微服务相关协议 (5讲)
第32讲 | RPC协议综述:远在天边,近在眼前
第33讲 | 基于XML的SOAP协议:不要说NBA,请说美国职业篮球联赛
第34讲 | 基于JSON的RESTful接口协议:我不关心过程,请给我结果
第35讲 | 二进制类RPC协议:还是叫NBA吧,总说全称多费劲
第36讲 | 跨语言类RPC协议:交流之前,双方先来个专业术语表
第四模块 网络协议知识串讲 (4讲)
第37讲 | 知识串讲:用双十一的故事串起碎片的网络协议(上)
第38讲 | 知识串讲:用双十一的故事串起碎片的网络协议(中)
第39讲 | 知识串讲:用双十一的故事串起碎片的网络协议(下)
第40讲 | 搭建一个网络实验环境:授人以鱼不如授人以渔
答疑与加餐 (9讲)
协议专栏特别福利 | 答疑解惑第一期
协议专栏特别福利 | 答疑解惑第二期
协议专栏特别福利 | 答疑解惑第三期
协议专栏特别福利 | 答疑解惑第四期
协议专栏特别福利 | 答疑解惑第五期
加餐1 | 测一测:这些网络协议你都掌握了吗?
加餐2 | 创作故事:我是如何创作“趣谈网络协议”专栏的?
加餐3 | “趣谈网络协议”专栏食用指南
第2季回归 | 这次我们来“趣谈Linux操作系统”
结束语 (1讲)
结束语 | 放弃完美主义,执行力就是限时限量认真完成
趣谈网络协议
登录|注册

第12讲 | TCP协议(下):西行必定多妖孽,恒心智慧消磨难

刘超 2018-06-13
我们前面说到玄奘西行,要出网关。既然出了网关,那就是在公网上传输数据,公网往往是不可靠的,因而需要很多的机制去保证传输的可靠性,这里面需要恒心,也即各种重传的策略,还需要有智慧,也就是说,这里面包含着大量的算法

如何做个靠谱的人?

TCP 想成为一个成熟稳重的人,成为一个靠谱的人。那一个人怎么样才算靠谱呢?咱们工作中经常就有这样的场景,比如你交代给下属一个事情以后,下属到底能不能做到,做到什么程度,什么时候能够交付,往往就会有应答,有回复。这样,处理事情的过程中,一旦有异常,你也可以尽快知道,而不是交代完之后就石沉大海,过了一个月再问,他说,啊我不记得了。
对应到网络协议上,就是客户端每发送的一个包,服务器端都应该有个回复,如果服务器端超过一定的时间没有回复,客户端就会重新发送这个包,直到有回复。
这个发送应答的过程是什么样呢?可以是上一个收到了应答,再发送下一个。这种模式有点像两个人直接打电话,你一句,我一句。但是这种方式的缺点是效率比较低。如果一方在电话那头处理的时间比较长,这一头就要干等着,双方都没办法干其他事情。咱们在日常工作中也不是这样的,不能你交代你的下属办一件事情,就一直打着电话看着他做,而是应该他按照你的安排,先将事情记录下来,办完一件回复一件。在他办事情的过程中,你还可以同时交代新的事情,这样双方就并行了。
如果使⽤这种模式,其实需要你和你的下属就不能靠脑⼦了,⽽是要都准备⼀个本⼦,你每交代下属⼀个事情,双方的本子都要记录⼀下。
当你的下属做完⼀件事情,就回复你,做完了,你就在你的本⼦上将这个事情划去。同时你的本⼦上每件事情都有时限,如果超过了时限下属还没有回复,你就要主动重新交代⼀下:上次那件事情,你还没回复我,咋样啦?
既然多件事情可以一起处理,那就需要给每个事情编个号,防止弄错了。例如,程序员平时看任务的时候,都会看 JIRA 的 ID,而不是每次都要描述一下具体的事情。在大部分情况下,对于事情的处理是按照顺序来的,先来的先处理,这就给应答和汇报工作带来了方便。等开周会的时候,每个程序员都可以将 JIRA ID 的列表拉出来,说以上的都做完了,⽽不⽤⼀个个说。

如何实现一个靠谱的协议?

TCP 协议使用的也是同样的模式。为了保证顺序性,每一个包都有一个 ID。在建立连接的时候,会商定起始的 ID 是什么,然后按照 ID 一个个发送。为了保证不丢包,对于发送的包都要进行应答,但是这个应答也不是一个一个来的,而是会应答某个之前的 ID,表示都收到了,这种模式称为累计确认或者累计应答cumulative acknowledgment)。
为了记录所有发送的包和接收的包,TCP 也需要发送端和接收端分别都有缓存来保存这些记录。发送端的缓存里是按照包的 ID 一个个排列,根据处理的情况分成四个部分。
第一部分:发送了并且已经确认的。这部分就是你交代下属的,并且也做完了的,应该划掉的。
第二部分:发送了并且尚未确认的。这部分是你交代下属的,但是还没做完的,需要等待做完的回复之后,才能划掉。
第三部分:没有发送,但是已经等待发送的。这部分是你还没有交代给下属,但是马上就要交代的。
第四部分:没有发送,并且暂时还不会发送的。这部分是你还没有交代给下属,而且暂时还不会交代给下属的。
这里面为什么要区分第三部分和第四部分呢?没交代的,一下子全交代了不就完了吗?
这就是我们上一节提到的十个词口诀里的“流量控制,把握分寸”。作为项目管理人员,你应该根据以往的工作情况和这个员工反馈的能力、抗压力等,先在心中估测一下,这个人一天能做多少工作。如果工作布置少了,就会不饱和;如果工作布置多了,他就会做不完;如果你使劲逼迫,人家可能就要辞职了。
到底一个员工能够同时处理多少事情呢?在 TCP 里,接收端会给发送端报一个窗口的大小,叫 Advertised window。这个窗口的大小应该等于上面的第二部分加上第三部分,就是已经交代了没做完的加上马上要交代的。超过这个窗口的,接收端做不过来,就不能发送了。
于是,发送端需要保持下面的数据结构。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《趣谈网络协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(68)

  • 进阶的码农 置顶
    AdvertisedWindow=MaxRcvBuffer-((NextByteExpected-1)-LastByteRead)。
    我根据图中例子计算 14-((5-1)-0) 算出来是10 ,括号里边的-1是减的什么,为啥和图例算出来的结果不一样,还是我计算的有问题,麻烦详细说一下 谢谢

    作者回复: 这里我写的的确有问题,nextbyteexpected其实是6,就是目前接收到五,下一个期望的是六,这样就对了

    2018-06-13
    1
    20
  • qpm
    1 设备缓存会导致延时?
    假如经过设备的包都不需要进入缓存,那么得到的速度是最快的。进入缓存且等待,等待的时间就是额外的延时。BBR就是为了避免这些问题:
    充分利用带宽;降低buffer占用率。

    2 降低发送packet的速度,为何反而提速了?
    标准TCP拥塞算法是遇到丢包的数据时快速下降发送速度,因为算法假设丢包都是因为过程设备缓存满了。快速下降后重新慢启动,整个过程对于带宽来说是浪费的。通过packet速度-时间的图来看,从积分上看,BBR充分利用带宽时发送效率才是最高的。可以说BBR比标准TCP拥塞算法更正确地处理了数据丢包。对于网络上有一定丢包率的公网,BBR会更加智慧一点。
    回顾网络发展过程,带宽的是极大地改进的,而最小延迟会受限与介质传播速度,不会明显减少。BBR可以说是应运而生。

    3 BBR如何解决延时?
    S1:慢启动开始时,以前期的延迟时间为延迟最小值Tmin。然后监控延迟值是否达到Tmin的n倍,达到这个阀值后,判断带宽已经消耗尽且使用了一定的缓存,进入排空阶段。
    S2:指数降低发送速率,直至延迟不再降低。这个过程的原理同S1
    S3:协议进入稳定运行状态。交替探测带宽和延迟,且大多数时间下都处于带宽探测阶段。

    深夜读了BBR的论文和网上大牛的讲解得出的小结,分享给大家,过程比较匆忙,不足之处也望老师能指出指正。
    2018-06-14
    96
  • 大唐江山
    作者辛苦啊,这一章读起来开始有点累了😂
    2018-06-13
    36
  • 华林
    这么说起来,我们经常发现下载速度是慢慢的增加到顶峰,然后就在那个值的附近徘徊,原因就是tcp的流量控制喽?
    2018-06-13
    4
    22
  • 食用淡水鱼
    快速重传那一段有问题。接收端接收6,7,8,9,10时漏掉了7,不是连续发送3个6ack,而是收到6,发送6的确认ack,收到8,9,10各发送一个6的重复ack,发送端检测到3个重复ack时(加上确认ack,总共有4个ack),进入重传机制。包括下面的拥塞控制,也是类似的逻辑
    2019-01-21
    9
  • 谛听
    不太清楚累积应答,比如接收端收到了包1、2、3、4,它的应答应该是5吗?也就是说中间的包就不用应答了吗?

    作者回复: 是的

    2018-09-22
    8
  • MoFanDon
    5的ACK丢包了,出发发送端重发。重发过去后,接收端发现接收过了,丢弃。……如果接收端丢弃5后,没有继续发送ACK,那这样不是发送端永远也也没法接受到5的ACK?
    2018-07-24
    2
    8
  • 好奇什么级别的程序开发需要了解怎么细,开发了好多网络程序都没用到,重传这些都是应用层在做
    2018-06-24
    1
    8
  • 咖啡猫口里的咖啡猫🐱
    老师,TCP协议栈,保证包一定到吗,,哪几种情况下会丢失,,,能不能总结下

    作者回复: 不能保证,只是尽力重试,再重试

    2018-06-13
    5
  • 行者
    问题1,想到BBR可以根据ACK时间来判断,比如同一时刻发送了A、B、C三个包,A、B两个包10ms收到ACK,而C包20ms后收到ACK,那么就认为网络拥堵或被中间设备缓存,降低发送速度。
    问题2,TCP优点在于准确到达,可靠性高,但是速度慢;UDP优点在于简单,但是不确认可达;像后端接口一般使用TCP协议,因为客户端和服务器之间会有多次交互,且请求数据要确认可达;但是如果是直播的话使用UDP会更好,管你网络咋样,反正我赶紧发,让用户等急了就不好了。
    刘老师,有一个问题,接口有时候会受到2次相同时间相同内容的请求,但是客户端仅仅调用了接口一次,会是什么原因导致这个问题呢?TCP重复发送包导致的嘛?
    2018-06-13
    1
    5
  • 扬~
    2个问题:
    1. TCP可靠的连接会不会影响到业务层,比如超时重传导致了服务端函数调用2次,那岂不是业务都要考虑幂等性了,我很懵逼,果然是懂得越多越白痴。
    2. 拥塞控制的窗口跟流量控制的窗口一回事吗,还是流量控制的窗口的出来后就会进入拥塞控制窗口?

    作者回复: 不会,重传的包不会交给应用层。是一个窗口

    2018-11-01
    1
    4
  • Null
    BBR 不填满缓存还是不填缓存?不填缓存那么缓存干啥用,如果填了了,即使不满,但是不是还有延迟。。。

    作者回复: 填的少,延迟就少了,当然做不到完全避免,毕竟缓存是路径上每一个设备自己的事情。缓存是每个设备自己的设计选择,BBR算法是两端的算法。

    就像买火车票,我建议网上购买,身份证刷进去,这样速度快,但是对于火车站还是要设置人工窗口,因为不是每个人都会选择速度快的方式的。

    2019-03-27
    3
  • 茫农
    有一个值 ssthresh 为 65535 个字节,,这个是什么意思?

    作者回复: slow start threshold

    2018-10-23
    3
  • lyz
    jira太真实了
    2018-07-24
    3
  • 秋去冬来
    快速重传那块6.8.9 7丢了为什么会发送3个冗余的6的3个ack

    作者回复: 六的ack里面强调下一个是七

    2018-06-22
    3
  • 旭风
    在传统算法和快速算法的对比描述中,对于快速算法中提到 cwnd减半为cwnd/2,sshthresh=cwnd ,后面cwnd=sshthresh+3,转折点是20变为13,这里的cwnd为10吗?

    2018-06-15

     作者回复

    cwnd先是为10,后面变为13

    继上一个问题,传统算法,cwnd 从1,2,4,8,16指数增长,这时cwnd为16,收发是不是各占8个?然后由16变成17,满8个确认时cwnd+1,就是17,那么增加到20这里,cwnd为20,这时产生拥塞,如果是传统的话,立马降下来,如果是快速,那么减半,也就是10,等待3个确认包+3,,后续每一个确认cwnd就+1吗?还是?这样子理解吗?

    作者回复: 是的

    2018-06-19
    3
  • Abirdcfly
    问个问题。最刚开始ssthres 是65535字节.然后一个mss是1460字节。那么指数增长应该是到44才变慢啊。为啥是16呢?

    作者回复: 举个例子而已,重点是那个曲线,而非数值

    2019-06-13
    2
  • Geek_hustnw
    (1)文章提到下面这段话:
        每收到一个确认后,cwnd 增加 1/cwnd,我们接着上面我们接着上面的过程来,一次发送八个,当八个确认到来的时候,每...
    (2)然后快速重传算法里面提到拥塞时:
        cwnd 减半为 cwnd/2,然后 sshthresh =...

    问题:快速重传拥塞处理里面,为什么遇到3个包返回的时候,是“sshthresh + 3”,而不是“sshthresh + 3/cwnd”

    作者回复: 先慢启动一把

    2019-04-14
    2
  • 产品助理
    问题:

    1、如下公式的 -1 到底是为什么?

    AdvertisedWindow=MaxRcvBuffer-((NextByteExpected-1)-LastByteRead)

       图例中的LastByteRead是0还是1?NextByteExpected是6还是5?MaxRcvBuffer是14吗?

    2、如果按照上述公式,那下面又是为了什么?

    NextByteExpected 加 AdvertisedWindow 就是第二部分和第三部分的分界线,其实也就是 LastByteRead 加上 MaxRcvBuffer。

    按照第一条的公式,NextByteExpected + AdvertisedWindow = NextByteExpected + (MaxRcvBuffer-((NextByteExpected-1)-LastByteRead))
    = MaxRcvBuffer + 1 + LastByteRead

    应该有个+1啊。。

    多谢老师!

    作者回复: 这里我写的的确有问题,nextbyteexpected其实是6,就是目前接收到五,下一个期望的是六,这样就对了
    2018-06-13

    2018-11-22
    2
  • 陈栋
    第三部分和第四部分分界线写错了,应该是lastByteSent+advertisedWindow

    作者回复: 没错的,advertisewindow是那个黑框,不是接下来能发的部分

    2018-06-19
    2
收起评论
68
返回
顶部