多點頭髮，少點代碼
本文已經收錄至我的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值。
RFC 6298推薦的α值爲1/8，即0.125。
數據也不會被無限、反覆地重發。達到一定重發次數之後，如果仍沒有任何確認應答返回，就會判斷爲網絡或對端主機發生了異常，強制關閉連接。並且
通知應用通信異常強行終止。
我是龍叔，一個分享互聯網技術和心路歷程的大叔，感謝你的閱讀。你的小小點贊將成爲我繼續授人以漁的大大動力。