其他
TCP/IP之蓟辽督师
他一进京，顾上休息， 立刻就先去拜见曾经举荐提报自己的恩师孙承宗， 看到自己的爱将风尘仆仆的赶来，虽然心疼， 稍事寒暄过后，还是立刻问起了怎么用幻月宝镜实现可靠传输的问题。
袁崇焕道： “老师有所不知， 这幻月宝镜虽好，但是如果没有失败重传的方法，一切都是白搭。 关外的环境比关内更加恶劣， 除了强盗野兽，还有飘忽不定的清军骑兵，随时打劫你。 ”
“确实是实情， 老夫当年巡视辽东的时候也看到了， 那你发出去物资以后， 是不是要等待对方的回复确认啊？”
“老师说的对，这也是我们刚开始的设想， 请看这张状态图：”
“状态图是什么东西？ 你自己弄的？”
“不， 这是荷兰红毛送红衣大炮的时候教我画的， 他们那边的人很擅长搞这种玩意， 说是‘科学’， 这张图的第一个状态是‘等待发送数据’， 然后发送分组数据进入了第二个状态‘等待反馈’， 此时如果对方发来了反馈说‘收到了’， 那就回到第一个状态， 否则， 重发之前的数据”
“荷兰红毛还是挺厉害的， 这是个描述系统的好方法啊，比纯用我们汉字好多了。 ”
“是的老师， 这个状态图的问题就是：如果对方发回的反馈损坏了改怎么办？”
孙承宗道：“有道理， 如果反馈损坏了， 发送方将无法理解接收方是否收到数据分组， 只好重新发送上一个分组， 但是从接收方来看， 没法区分这个分组是新的还是一次重传， 这就麻烦了。 ”
“所以我和满桂、祖大寿他们商量了下， 我们采用给数据编号的办法来解决这个问题， 第一次发送编号为A的， 然后就等待针对A的反馈， 如果反馈没法识别或者是没收到， 那就重新发送， 如果反馈是‘收到了’， 那就发送分组编号为B的数据。 ”
“老师明鉴， 我们确实遇到了这个问题， 于是就搞了一个沙漏定时器， 针对上面的状态做了改进， 分组一发送就开始计时，如果超时就重新发送同一分组， 像这样：”
孙承宗道：”好复杂啊，老夫这脑子里全是四书五经， 这状态图让人头蒙啊。 “
师生二人正聊着， 下人通报首辅叶大人来了。
同样是老学究的叶首辅看到了袁崇焕画的西洋状态图， 大为吃惊，心想袁崇焕赢得宁远大捷和宁锦大捷，果然是与众不同。
经过袁崇焕连番讲解，叶首辅终于明白了这是怎么回事， 他捻着胡子思忖一下， 马上提出一个问题：“你每次发送一个分组都得等待， 多慢啊， 能不能连续发送？”
孙承宗和袁崇焕对视一眼， 心想果然姜还是老的辣。
袁崇焕道：“叶大人高瞻远瞩， 思虑缜密，属下佩服。 这个问题我们把我们困住了很久才想出一个办法， 这个方法约定，发送方可以连续的发送分组，但是有限制数量，例如只能连续发送4个， 我们称之为窗口， 发送窗口满了就不能发了，需要等待接收方的确认， 当确认来了以后才能继续发送， 向前移动窗口 。”
“这也是红毛们教我的，可以称为交互图， 大人请看， 我们发送到分组4的时候， 窗口满了， 就停止发送， 只有等到分组1的确认（acknowledge, 简称ACK）来了以后，才继续发送下一个分组。”
孙承宗道： “我看到分组3在发送当中丢失了， 超时后重新发送， 可是接收端明明收到了分组4， 5， 6还要丢弃啊。 ”
袁崇焕道：“这个办法是满桂最先提出的， 他是一个粗人， 想出的方法也很粗暴， 非常依赖幻月宝镜， 把失败分组及其以后的全部重新发送， 的确浪费。”
（码农翻身注： 这叫做回退N步协议）
叶首辅道：“很明显， 你们得选择性的重传那些丢失的分组。”
“大人说的对， 请看这个图：”
（码农翻身注：这叫做选择性重传）
叶首辅一拍大腿道： “好 ！应该不错了， 我们就用这种办法来建立大明的可靠传输网络吧“
接着他又郑重的补充到 ： “ 二位要注意， 这些失败重传的方法，是我们三人的秘密， 绝不能让魏阉党知道， 要不然他又要去找皇上邀功请赏了。”
（码农翻身注：这只是可靠性传输的原则， 实际的TCP协议要更复杂，需要考虑双向的全双工通信，想了解详情的可以看《TCP/IP详解 卷1》）
其他相关的文章：TCP/IP之大明内阁TCP/IP之大明邮差我是一个网卡我是一个路由器
你看到的只是冰山一角， 更多精彩文章，尽在“码农翻身” 微信公众号， 回复消息"m"或"目录" 查看更多文章
有心得想和大家分享？ 欢迎投稿 ！ 我的联系方式：微信：liuxinlehan QQ: 3340792577
掘金是一个高质量的技术社区，从 Swift 到 React Native，性能优化到开源类库，让你不错过互联网开发的每一个技术干货。长按图片二维码识别或者各大应用市场搜索「掘金」，技术干货尽在掌握中。