TCP/IP之薊遼督師

真正的知識是深刻淺出的，碼農翻身」 公共號將苦澀難懂的計算機知識，用形象有趣的生活中實例呈現給咱們，讓咱們更好地理解。

本文源地址：TCP/IP之薊遼督師

本文續《TCP/IP之大明內閣》，不瞭解背景的同窗能夠先看看上一篇文章，固然這篇也是《TCP/IP之大明郵差》的前傳，主要講一講可靠性傳輸的原理。

袁崇煥奉聖旨進京，也被迫帶來了他的心肝寶貝幻月寶鏡。
他一進京，顧不上休息，馬上就先去拜見曾經舉薦提報本身的恩師孫承宗。孫承宗看到本身的愛將風塵僕僕的趕來，雖然心疼，稍事寒暄事後，仍是馬上問起了怎麼用幻月寶鏡實現可靠傳輸的問題。
袁崇煥道：「老師有所不知，這幻月寶鏡雖好，可是若是沒有失敗重傳的方法，一切都是白搭。關外的環境比關內更加惡劣，除了強盜野獸，還有飄忽不定的清軍騎兵，隨時打劫你。」
「確實是實情，老夫當年巡視遼東的時候也看到了，那你發出去物資之後，是否是要等待對方的回覆確認啊？」
「老師說的對，這也是咱們剛開始的設想，請看這張狀態圖：」

「狀態圖是什麼東西？你本身弄的？」

「不，這是荷蘭紅毛送紅衣大炮的時候教我畫的，他們那邊的人很擅長搞這種玩意，說是‘科學’。這張圖的第一個狀態是‘等待發送數據’， 而後發送分組數據進入了第二個狀態‘等待反饋’，此時若是對方發來了反饋說‘收到了’，那就回到第一個狀態。不然，重發以前的數據。」
「荷蘭紅毛仍是挺厲害的，這是個描述系統的好方法啊，比純用咱們漢字好多了。」
「是的老師，這個狀態圖的問題就是：若是對方發回的反饋損壞了該怎麼辦？」
孫承宗道：「有道理，若是反饋損壞了，發送方將沒法理解接收方是否收到數據分組，只好從新發送上一個分組，可是從接收方來看，無法區分這個分組是新的仍是一次重傳，這就麻煩了。」

「因此我和滿桂、祖大壽他們商量了下。咱們採用給數據編號的辦法來解決這個問題，第一次發送編號爲A的，而後就等待針對A的反饋。若是反饋無法識別或者是沒收到，那就從新發送；若是反饋是‘收到了’，那就發送分組編號爲B的數據。」

「有個關鍵問題，那要是出現了反饋遲遲收不到怎麼辦，你確定不能無限制的等待吧？」

「老師明鑑，咱們確實遇到了這個問題，因而就搞了一個沙漏定時器，針對上面的狀態作了改進。分組一發送就開始計時，若是超時就從新發送同一分組。像這樣：」

孫承宗道：」好複雜啊，老夫這腦子裏全是四書五經， 這狀態圖讓人頭蒙啊。 「

師生二人正聊着，下人通報首輔葉大人來了。
一樣是老學究的葉首輔看到了袁崇煥畫的西洋狀態圖，大爲吃驚，心想袁崇煥贏得寧遠大捷和寧錦大捷，果真是不同凡響。
通過袁崇煥連番講解，葉首輔終於明白了這是怎麼回事。他捻着鬍子思忖一下，立刻提出一個問題：「你每次發送一個分組都得等待，多慢啊！能不能連續發送？」
孫承宗和袁崇煥對視一眼，心想果真姜仍是老的辣。

袁崇煥道：「葉大人高瞻遠矚，思慮縝密，屬下佩服。這個問題咱們把咱們困住了好久纔想出一個辦法，這個方法約定，發送方能夠連續的發送分組，可是有限制數量。例如只能連續發送4個，咱們稱之爲窗口，發送窗口滿了就不能發了，須要等待接收方的確認。當確認來了之後才能繼續發送，向前移動窗口。」

 

「這又是個什麼圖？」 葉首輔問到。
「這也是紅毛們教個人，能夠稱爲交互圖，大人請看，咱們發送到分組4的時候，窗口滿了，就中止發送，只有等到分組1的確認（acknowledge, 簡稱ACK）來了之後，才繼續發送下一個分組。」

孫承宗道：「我看到分組3在發送當中丟失了，超時後從新發送，但是接收端明明收到了分組四、五、6還要丟棄啊。」
袁崇煥道：「這個辦法是滿桂最早提出的，他是一個粗人，想出的方法也很粗暴，很是依賴幻月寶鏡，把失敗分組及其之後的所有從新發送，的確浪費。」---回退N步協議

葉首輔道：「很明顯，大家得選擇性的重傳那些丟失的分組。」
「大人說的對，請看這個圖：」

「這個圖中只發送丟失的分組3，在接收端會暫時緩存分組四、五、6，這樣就省了不少事了。」---選擇性重傳

葉首輔一拍大腿道：「好！應該不錯了，咱們就用這種辦法來創建大明的可靠傳輸網絡吧。」
接着他又鄭重的補充到：「 二位要注意，這些失敗重傳的方法，是咱們三人的祕密，毫不能讓魏閹黨知道，要否則他又要去找皇上邀功請賞了。」
（碼農翻身注：這只是可靠性傳輸的原則，實際的TCP協議要更復雜，須要考慮雙向的全雙工通訊，想了解詳情的能夠看《TCP/IP詳解 卷1》）

「碼農翻身」 公共號 : 由工做15年的前IBM架構師建立，分享編程和職場的經驗教訓。

長按二維碼， 關注碼農翻身