TCP層的那些知識，你掌握了多少？

前言

網絡是一個計算機的重要學科，不管是tcp、udp、http還有各類各樣的協議，他們都是網絡的一部分。給一個地址，是我大三上考試前作的一些筆記，固然還有其餘的學習內容。

思惟導圖

網絡體系結構模型

在圖片中咱們可以看到數據鏈路層和物理層可以合併成網際接口層。這是由於TCP/IP模型其實存在兩種的說法，一個是四層模型，一個是五層模型，而他們的區別也就是在此處。

其實在現實生活中，咱們基於的網絡都是基於TCP/IP模型創建的，可是這個章節咱們主要討論的是TCP層，你也一樣能夠叫他傳輸層。

TCP層

在TCP層中，其實存在兩個協議有以下圖兩種：TCP和UDP

TCP/傳輸控制協議

這是咱們網絡基礎中的重中之重

其實知識點不少不少，因此抽出幾個重點內容講解。

三次握手

握手的實現順序：

1. 第一次握手:客戶機向服務器發出包SYN
2. 第二次握手:服務器確認客戶機的包SYN，發送給客戶機包SYN+ACK。
3. 第三次握手:客戶機確認服務器的包SYN+ACK，發送包ACK+Data給服務器。

從第三次握手開始，咱們就已經能夠帶上咱們的數據進行傳輸了。

採用三次握手不是二次握手緣由:

爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤

簡單的說就是:因網絡緣由，客戶端重傳了請求創建鏈接報文，當2號請求報文與服務器創建鏈接並斷開後，1號請求鏈接到達。採用二次握手致使服務器進入鏈接狀態，而客戶端處於關閉狀態，形成資源的消耗。

其實從另一個角度看，這是一個兩軍對壘的問題。

圖畫的有點醜陋，哈哈哈哈哈哈哈！！

講個故事好了，一天吳軍想打魏國，蜀軍這天也想打魏國，他們看到對方，都想借對方隻手滅了魏國，本身坐收漁翁之利。這個時候，吳軍選擇先派出使者去發出同盟請求，並以狼煙做爲信號 （第一次握手開始） ，可是會途徑魏國啊，那可能使者就有掉腦殼或者被偷換的可能了 （數據包丟失或者數據位出錯） ，到了蜀軍之後，蜀軍承認了此次的行動，而後送走了來使 （第一次握手成功，第二次握手開始） ，固然中間又要路過魏國，有可能出現上述狀況。最後吳軍點了狼煙，就衝去滅魏國了。（完成第二次握手，發出數據，開始第三次握手）

四次揮手

四次揮手就沒有這麼精彩的故事了，就平淡點講一下好了。

揮手的實現順序：

1. 第一次揮手:客戶機向服務器發送包FIN
2. 第二次揮手:服務器確認客戶機的包FIN，發送給客戶機包ACK
3. 第三次揮手:服務器向客戶機發送包FIN
4. 第四次揮手:客戶機確認服務器的包FIN+ACK，發送給服務器ACK，完成揮手

爲何要實現4次握手呢？

其實這是爲了關閉雙方的資源，和三次握手並不同，三次握手的主體是客戶端，而四次揮手的主體是二者，由於二者都須要確保本身的資源完成關閉。

如何實現數據的完整性

這是和UDP最大的區別，UDP畢竟是一個容錯的傳輸協議。

看看TCP的包頭結構，幾個地方可以引發咱們的注意，那就是檢驗和，確認號，序號，這確實是他的三個校驗的方式。

可是還有問題，若是我發的包中途丟失，那該怎麼辦呢？，TCP給出的解決方案就是計時器，還有重傳機制。（重傳機制在上方的三個校驗方式中一樣獲得了應用）

UDP/用戶數據報協議

和TCP的包頭相比就簡單了許多，他的校驗方式也確實只存在一種檢查和的確認。

爲何須要這樣的協議？

想來這是絕大多數人思考過的問題，其實緣由有下面幾個：

1. 應用場景的不一樣。 相似語音通話，視頻通話中都全都是用了UDP協議。舉一個很簡單的例子，打語音電話的時候，你會由於別人的一個字缺失而失去對整句話意思的理解嗎？更況且，在語音電話的時候，咱們沒聽清楚的事情是能夠，從新再詢問一遍的。也就是說咱們的溝通之間是容錯的。
2. 傳輸效率的問題。 若是使用的是TCP協議，那麼出現的問題就在於他的流量控制和擁塞控制，他的傳輸速率會受到網絡環境改變的衝擊而隨之改變。可是UDP不同，他沒有三次握手，四次揮手，它只是一股腦的只管發，這個帶寬已經足夠大的時代，徹底是可以承受起這樣的資源佔用的，而效率上也獲得了保障。
3. 使用感覺。 這是效率問題做爲鋪墊的引伸，人的卡頓感是有必定的範圍的，若是使用TCP協議卻由於網絡波動改變數據流量大小，那人們的體驗感會立刻降低，並且數據包到達的速度不理想，能夠一個「開」的語音被拆成了「k」，「ai」，瞬間失去語義。而後還要可能「k」到了，「ai」丟了，重傳等到了3秒之後，那更完了。

總結

其實TCP協議還有流量控制和擁塞控制的特色，分別基於的是滑動窗口機制還有AIMD的算法。他的變化依據最後都來自於波動的網絡中，數據包的來回傳遞時間、丟包率等等。

另外TCP和UDP協議的使用我也說了是考慮使用場景。TCP協議的應用場景其實更多，咱們上網下載個視頻啊，發消息都是使用的TCP協議，由於這些數據咱們是須要保證數據的完整性的。

以上就是個人學習成果，若是有什麼我沒有思考到的地方或是文章內存在錯誤，歡迎與我分享。

---

相關文章推薦：

Android必知必會的四大組件 -- ContentProvider篇

Android必知必會的四大組件 -- Activity篇

Android必知必會的四大組件 -- Broadcast Receiver篇