karn

欢迎去gitbook（https://legacy.gitbook.com/@rogerzhu/）看到完整版。 如果对和程序员有关的计算机网络知识，和对计算机网络方面的编程有兴趣，虽然说现在这种“看不见”的东西真正能在实用中遇到的机会不多，但是我始终觉得无论计算机的语言，热点方向怎么变化，作为一个程序员，很多基本的知识都应该有所了解。而当时在网上搜索资料的时候，这方面的资料真的是少的可怜，所以，我有幸前两年接触了这方面的知识，我觉得我应该把我知道的记录下来，虽然写的不一定很好，但是希望能给需要帮助的人多个参考。我的计划是用半年时间来写完这一系列文章，这个标题也是我对太多速成文章的一种态度，好了，废话不再多扯了，下面是其中的一节内容，更多内容可以去gitbook上找到。 在 TCP中，超时重传机制是和应答确认机制一样组成TCP可靠传输的关键设计。而超时重传机制中最最重要的就是超时计时器的时间选择的了，很明显，在工程上，在数据发送的过程中，如果用一个固定的值一直作为超时计时器的时长是非常不经济也非常不准确的方法，所以这一篇就来说说TCP中的超时计时器的设计哲学。 太短不行，太长也不行 超时超时，首先你得定义什么是正常的时间，才能知道有没有超过正常的时间。先假设一个非常理想的环境，这个环境理想到和以前很多物理题一样，不考虑摩擦力。我们假设网络很通畅且速率稳定，而且处理包的速度忽略不计

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 上一篇介绍 TCP 的文章「 TCP 三次握手，四次挥手和一些细节 」反馈还不错，还是蛮开心的，这次接着讲一讲关于超时和重传那一部分。 我们都知道 TCP 协议具有重传机制，也就是说，如果发送方认为发生了丢包现象，就重发这些数据包。很显然，我们需要一个方法来「 猜测 」是否发生了丢包。最简单的想法就是，接收方每收到一个包，就向发送方返回一个 ACK ，表示自己已经收到了这段数据，反过来，如果发送方一段时间内没有收到 ACK，就知道 很可能 是数据包丢失了，紧接着就重发该数据包，直到收到 ACK 为止。 你可能注意到我用的是「猜测」，因为即使是超时了，这个数据包也可能并没有丢，它只是绕了一条远路，来的很晚而已。毕竟 TCP 协议是位于 传输层 的协议，不可能明确知道数据链路层和物理层发生了什么。但这并不妨碍我们的超时重传机制，因为接收方会自动忽略重复的包。 超时和重传的概念其实就是这么简单，但内部的细节却是很多，我们最先想到的一个问题就是， 到底多长时间才能算超时呢 ？ 超时是怎么确定的？ 一刀切的办法就是，我 直接把超时时间设成一个固定值 ，比如说 200ms，但这样肯定是有问题的，我们的电脑和很多服务器都有交互，这些服务器位于天南海北，国内国外，延迟差异巨大，打个比方： 我的个人博客搭在国内，延迟大概