怎麼用 UDP 實現 TCP？

本篇來自於個人一次真實面試經歷。

背景

本題是我在面試中，技術總監問個人一道真題，當時答得不太好，因此把它揪出來總結了下。後來問了下總監，總監說這是阿里的面試題。。

其實面試官主要是想讓我說出 UDP 和 TCP 的原理上的區別，怎麼給 UDP 加些功能實現 TCP。

看好去很容易就能說出一兩個 TCP 和 UDP 的區別，但若是能用女友都能聽懂的方式該怎麼說呢？

女友：我不想聽課本上講的！我聽不懂呀~

下面我會以大白話的方式來解答上面的問題。

UDP 的特色

UDP 讓我想起了剛畢業參加工做那會，一名畢業菜鳥。

• 溝通簡單

領導安排的任務，直接幹就完了。

UDP 也是，相信網絡世界永遠是美好的，我發送的包是很容易送到的，接收方也是很容易組裝的。數據結構也很簡單，不須要大量的數據結構、處理邏輯、包頭字段。

• 輕信他人

測試人員報的 bug 我也不會和她爭論什麼，永遠相信測試人員是對的，測試人員說啥就是啥，我改就是。

UDP 也是，不會創建鏈接，有個端口號，誰均可以監聽這個端口號往上面發數據。也能夠從這個端口號傳給任何人數據。反正我只管發就是。

• 不會討價還價

產品經理昨天說手機殼須要根據心情變色，測試人員說這個 bug 要把關聯的兩個 bug 一塊兒修掉。那就按照他們說的作吧！

UDP 也是，不懂堅持和退讓。也就是根據網絡狀況進行擁塞控制。不管網絡丟包多嚴重，我仍是照樣發~

UDP 使用場景

針對像我那時候畢業菜鳥的狀況，領導給我安排了三種工做環境讓我選。

• 內部系統，任務簡單，模塊單一，不須要考慮代碼的關聯影響，即便失敗了也沒有關係。

UDP 也是，須要資源少，網絡狀況比較好的內網，或者對於丟包不敏感的應用。

• 有一個強力的團隊支持，都是中高級開發、測試人員，團隊成員打過不少年交道，互相信任。有什麼問題， 吼一嗓子就能夠了！

UDP 也是，不須要一對一溝通來創建鏈接，能夠廣播的應用。

• 一個新項目，須要有激情，對於剛畢業的菜鳥，都是有很強的自主能動性的，也不會耍滑頭，躲在廁所玩手機，帶薪拉shi ？即便項目不忙，我也抓緊時間幹。項目忙，仍是同樣幹！

UDP 也是，猛着發包就是，主要應用在須要處理速度快，時延低，能夠容忍少數丟包的狀況。即便網絡狀況不佳，發包就是~

針對上面的三大場景，UDP 經常使用在實時競技遊戲，IoT 物聯網，移動通訊領域。

TCP 的特色？

• 面向鏈接

TCP 和 UDP 是傳輸層裏面比較重要的兩個協議。大部分面試的時候都會問到二者的區別。而大部分都會兩句，好比 TCP 是面向鏈接的，UDP 是面向無鏈接。

那什麼是面向鏈接？

TCP 三次握手是咱們經常唸叨和背誦的。而在這三次握手成功後，就是創建鏈接成功。

那什麼又叫面向呢？

咱們也常聽到面向對象編程、面向切面編程、面向服務編程。那到底什麼是面向？

在我看來 面向 就是遵循必定的協議、規範、數據結構等來作一系列事情。

好比面向鏈接，就是爲了在客戶端和服務端維護鏈接，而創建必定的數據結構來維護雙方交互的狀態，用這樣的數據來保證所謂的面向鏈接的特性。

知道了 TCP 的是用三次握手來創建鏈接，那咱們是否可讓 UDP 也發三個包來模擬 TCP 創建鏈接？能夠是能夠，可是若是隻是創建，而不是面向鏈接，其實意義不大。

那 TCP 面向鏈接作了哪些事情？

TCP 提供可靠交付，經過 TCP 鏈接傳輸的數據，能夠無差錯、不丟失、不重複、而且按序到達。而 UDP 繼承了 IP 包的特性，不保證不丟失，不保證按順序到達。

• 面向字節流

TCP 是面向字節流，所謂字節流，就是發的是一個流，沒頭沒尾。TCP 本身維護流狀態。

UDP 基於 IP 數據報，一個一個地發，一個一個地收。

• 擁塞控制

TCP 擁有擁塞控制，若是包丟棄了或者網絡環境很差了，就會根據網絡狀況自行控制本身的行爲，看下是發快點仍是發慢點。

UDP 則沒有這麼智能了， 你讓我發，我就發唄，反正是你讓我發的，其餘的一律無論~

• 有狀態服務

TCP 是一個有狀態的服務，有狀態能夠理解爲：我記錄了哪些發送了，哪些沒有發送，哪些接收到了，哪些沒接收到，應該接收哪一個了，一點差錯都不行。TCP 乾的事情可真多！

而 UDP 則不是有狀態的服務，我只管發，其餘的就交給接收端吧，有點任性是吧？

如何讓 UDP 實現 TCP 功能？

創建鏈接上面已經講到了，三次握手和四次握手，UDP 也能夠模擬去作。

那下面還有幾個問題：

• 順序問題

• 丟包問題

• 流量控制

• 擁塞控制

TCP 的數據結構長這樣：

其實若是你能把這些結構講清楚，就已經理解了 TCP 的核心功能。下面我仍是用大白話的方式來說解上面的四個問題。

順序問題和丟包問題能夠利用確認與重發的機制。假如包收到了，能夠作一個確認，發送一個 ACK 給發送端，告訴他我收到了。假若有的包提早到了，就緩存着。假若有包丟失了，就能夠超時重試。超時重試不宜太短，時間必須大於往返時間 RTT，不然會引發沒必要要的重傳。也不宜過長，若是超時時間過長，訪問就變慢了。那怎麼肯定這個時間，能夠經過採樣 RTT 的時間，進行加權平均。還須要根據網絡情況，動態變化。能夠了解下自適應重傳算法。

流量控制就是根據網絡狀況調整發包的速率。利用的是滑動窗口。在對於包的確認中，同時會攜帶一個窗口的大小，只要利用好這個窗口大小，就能很好地調整發包速率，發的報文段不要超過窗口的大小就 OK。（圖片來源網絡）

擁塞控制主要用來避免包丟失和超時重傳，若是出現了這兩種現象，就說明發的速率太快了。那最開始怎麼知道發送速率呢？其實開始時只發送一個報文段數據，若是收到一個確認，則倍增報文段，依次類推。當發現超時重傳時，就又回到只發送一個報文段的狀況，這個就是慢啓動，這種方式不合適。其實還有一種快速重傳算法，簡單來講就是擁塞窗口減半，後續線性增速。針對於算法怎麼實現的，這裏就不展開講述了。（圖片來源網絡）

至此，我用大白話的方式講解了 UDP 和 TCP 的區別，以及 UDP 缺什麼功能，須要怎麼去彌補才能實現 TCP 的功能。相信這樣回答的思路可讓面試官以爲仍是有點東西的。

巨人的肩膀：

《趣談網絡協議》

《計算機網絡》

- END -

建了學習交流羣，能夠掃碼加我，備註[加羣] 一塊兒進階！

我的二維碼

 

我是悟空，努力變強，變身超級賽亞人！

本文分享自微信公衆號 - 悟空聊架構（PassJava666）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。