趣谈网络协议
刘超
网易研究院云计算技术部首席架构师
立即订阅
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
qpm1 设备缓存会导致延时？
假如经过设备的包都不需要进入缓存，那么得到的速度是最快的。进入缓存且等待，等待的时间就是额外的延时。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
MoFanDon5的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
NullBBR 不填满缓存还是不填缓存？不填缓存那么缓存干啥用，如果填了了，即使不满，但是不是还有延迟。。。作者回复: 填的少，延迟就少了，当然做不到完全避免，毕竟缓存是路径上每一个设备自己的事情。缓存是每个设备自己的设计选择，BBR算法是两端的算法。
就像买火车票，我建议网上购买，身份证刷进去，这样速度快，但是对于火车站还是要设置人工窗口，因为不是每个人都会选择速度快的方式的。2019-03-27 3
茫农有一个值 ssthresh 为 65535 个字节，，这个是什么意思？作者回复: slow start threshold
2018-10-23 3
lyzjira太真实了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-132018-11-22 2
陈栋第三部分和第四部分分界线写错了，应该是lastByteSent+advertisedWindow作者回复: 没错的，advertisewindow是那个黑框，不是接下来能发的部分
2018-06-19 2
收起评论