多点头发，少点代码
本文已经收录至我的GitHub,欢迎大家踊跃star 和 issues。
https://github.com/midou-tech/articles
唠叨几句
前几天在群里问了下大家最近春招的状态。
如果你还在参加春招，不管是社招还是校招。龙叔都想唠叨几句，今年整体经济形势很差，可能有些人还没意识到有多差，但我相信很多人都能感受到。很多公司入不敷出，基本都在裁员和压缩成本，很多公司把原来的扩张计划改成了活下去。
正在找工作的各位，不可对市场预期太高，不要感觉我专业的学长学姐都是非bat不进的，现在市场供求关系变了，需求变得越来越少了，供给却一直在增加，找工作的你也应该调整自己的预期。当然好能力的人还是会非bat不去的，但很重要的点是 好能力，但不可能人人都是好能力的，所以你要有正确的心里预期和不断的打磨自己的能力。
准备跳槽的你也一定要思考清楚在跳，以前每年都是金三银四跳槽季。今年，听到几个准备跳槽的学长说，好多公司都是象征性的面面，根本不发offer。
顺便说一下什么叫象征性的面面，公司是对外的，公司不管在什么时候都会招人的，如果你看到一个公司的对外网站不招人了，基本说明该公司凉了。除非真的倒闭，一般情况下公司都会在官网放出招聘信息，但是真的在招人么？
所以就有了面了好多就是不过，面的也非常好，就是不发offer。如果是这样，不是你不行，是市场不行。如果有个公司真心要你，就好好珍惜吧。
行了，龙叔就唠叨这么多，接下来上干货。今天主要说TCP的可靠性问题，包括一些重点面试题。
正文
计算机网络知识在面试中可算是继数据结构之后问的最为频繁的了。龙叔对这块的知识非常重视，由此校招的时候可是没少被面试官夸，这也是龙叔拿了20几个offer中一个不可或缺的因素。
之前讲了计算机网络的体系架构 计算机网络五层结构的解析 、 TCP粘包问题怎么解 、流量控制&拥塞控制 (戳我即可看到该文章喔)。
今天再讲讲TCP的可靠性问题，网络里面的重要知识点基本都说完了，要是还有什么不懂那就后台获取龙叔微信，悄咪咪的暗示下龙叔。
可靠性很好理解吧，就是可靠。什么是可靠？我们经常听到老师说某某同学很靠谱，同学之间会说谁谁很靠谱，在社会上领导也会很喜欢那些靠谱的下属，老板喜欢靠谱的员工。靠谱就是交代的事情都能如期、保质的完成。
TCP的功能是交付数据，所以TCP的可靠就是保证每次数据按序、按时、不丢数据，顺利的交付给对端。
龙叔必须说清楚一件事情，可靠不等于安全，TCP尽最大可能的保证数据可靠性，但是没有任何措施保证数据的安全性。所谓安全就是你的数据不会被别人看到或者窃取到，TCP上的数据是明文传输的。
TCP如何保证可靠性
TCP是一种可靠传输协议，到底如何保证可靠性呢？TCP协议里面有如下几种机制去保证
一、字节编号机制
编号机制很好理解，就是给TCP的数据段里面的数据部分 ，每个字节都进行编号。
为什么需要编号？
好说，就是为了更清楚的接收和发送。TCP数据是按序的，接收完之后按序组装好，才会交付给上层。
日常生活中也经常遇到这样的情况，你去银行还不得在门口取个号，先取号的先办理，既保证处理事情不乱，也不用大家站着长长的队，叫到号就是你。
二、数据段的确认机制
也就是我们常常听到的确认应答机制，一问一答，保证问的问题，对方一定接收到，如果确实没有接收到就会重复去问。
TCP确认应答就是每一个数据段发送都会收到接收端返回的一个确认号，收到的确认号表示该号前面的数据全部接收。
确认应答机制里面有几个重要的问题，也是面试高频问题，龙叔必须唠叨几句。
- TCP可以一次连续发送多个数据段
TCP可以连续发送多个数据段，具体发送数据段的多少取决于对方返回的窗口大小。只要满足窗口大小可容纳，Negale 算法处于关闭状态就可以连续发送多个数据段。
- 仅对连续接受的数据段进行确认
假设你发送了数据段序号为101、201、301、401、501、601，接收端接收到了101、201、501，此时接收端只会返回201的确认，不会返回501确认，因为301和401还没接收到。当收到301和401之后才会返回501的确认(在不超时的情况下)。
- 不连续序号的数据先缓存下来
如上面的例子，接收端收到101、201、501，此时501不能被确认，因为有不连续的数据，但是501的会被缓存在本地，后面收到301、401立即返回501的确认。
三、TCP的超时重传机制
前面两条都是预防和减少出错，超时重传机制是保证TCP在传输过程中数据丢失了一个回复措施。因此超时重传机制是保证可靠性很重要的机制。
每发送一个TCP数据段都会启动一个超时重传计时器（Retransmission Timer,RTT)。如果在计时器时间内没有收到确认应答号，会启动重传，重新发送该数据段。
这里面还有个点，TCP每发送一个数据段不是立刻把该数据段从缓冲区删除的，收到确认应答以后才会从发送队列丢掉。
超时重传原理看起来比较简单，重传的步骤也比较简单，其实也就是如此简单。有一个难的点是，超时重传计时器的时间是一个很复杂的问题。
表面看起来很简单，不就是一次数据发送到出去到接收端收到消息的时间*2么？
事情并没有那么简单
一次往返中间经过的网络路段是不固定的，网络拥塞程度不确定的。
就像你平时开车，导航不可能只给你一条路线，每次给出的路线也会不同，因为道路的拥堵程度不同。
TCP保证可靠性，因此TCP要求不论处在何种网络环境下都要提供高性能通信，并且无论网络拥堵情况发生何种变化，都必须保持这一特性。
TCP目前采用一种自适应的算法计算RTT值。
给定一个初始的RTT值，初始RTT值是6s，后面每次收到确认应答会进行一次计算，计算本次往返的时间和RTT波动，也就是RTT偏差。最终把RTT+RTT偏差得到新的RTT值。
= (1-α)
+ α 
RFC 6298推荐的α值为1/8，即0.125。
数据也不会被无限、反复地重发。达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且
通知应用通信异常强行终止。
我是龙叔，一个分享互联网技术和心路历程的大叔，感谢你的阅读。你的小小点赞将成为我继续授人以渔的大大动力。