Android技能樹 — 網絡小結(2)之TCP/UDP

介於本身的網絡方面知識爛的一塌糊塗，因此準備寫相關網絡的文章，可是考慮所有寫在一篇太長了，因此分開寫，但願你們能仔細看，最好能夠指出個人錯誤，讓我也能糾正。

1.講解相關的整個網絡體系結構：

Android技能樹 — 網絡小結(1)之網絡體系結構

2.講解相關網絡的重要知識點，好比不少人都聽過相關網絡方面的名詞，可是僅限於聽過而已，什麼tcp ,udp ,socket ,websocket, http ,https ,而後webservice是啥，跟websocket很像，socket和websocket啥關係長的也很像，session,token,cookie又是啥。

Android技能樹 — 網絡小結(2)之TCP/UDP

Android技能樹 — 網絡小結(3)之HTTP/HTTPS

Android技能樹 — 網絡小結(4)之socket/websocket/webservice

相關網絡知識點小結- cookie/session/token（待寫）

3.相關的第三方框架的源碼解析，畢竟如今面試個大點的公司，okhttp和retrofit源碼是必問的。

Android技能樹 — 網絡小結(6)之 OkHttp超超超超超超超詳細解析

Android技能樹 — 網絡小結(7)之 Retrofit源碼詳細解析

---

正文

在網絡體系結構小結中咱們知道了大概的網絡結構層級，這篇文章側重的講一些平時你們聽到的熟悉的詞彙TCP 與 UDP。

1. TCP與UDP：

在網絡體系結構小結中咱們提過TCP/IP的四層網絡層級：

而TCP (Transmission Control Protocol，即 傳輸控制協議)和 UPD （User Datagram Protocol，即用戶數據報協議）是在傳輸層的，因此咱們知道UDP和TCP是用來傳輸數據的一種協議，爲主機中不一樣的進程提供通訊，那既然是傳輸數據，咱們舉例以快遞和寄信的邏輯來講明（反正都是某個東西從一個地方到另一個地方）。

TCP像快遞，由於咱們如今寄快遞都能看到具體快遞到哪裏了，某個中轉站是否已經收到了個人快遞，最後的目的地是否收到了個人快遞，若是快遞丟了也會給你反饋等，幫你從新補寄等。而UDP更像寄信，我反正寄出去了，收不收穫得我也無論。(emmm....可能這個例子不太恰當。。。)

因此咱們初步感受：對比於UDP，TCP的傳輸是可靠的、無差錯的。

1.1 TCP通道的鏈接及斷開

既然是數據從一個地方到另一個地方，咱們要先創建一個通道，這樣後面數據才能傳輸流動。（PS:這個比喻可能不恰當。若是有更好的比喻，能夠留言。謝謝）

TCP三次握手，四次揮手聽到的是否是不少，沒錯，這個就是用來創建這個通道及斷開通道，我面試的別人的時候，三次創建，四次斷開基本都知道，可是我問他們爲何要三次，不少都答不上來。爲了更好的記憶，咱們仍是用具體的例子來講明：

三次握手：

1. A發信息給B：你在不在啊？急事！！
2. B發信息給A：我在啊，急事？那你快告訴我，我這邊時刻聽着你說。
複製代碼

不幸的是A這時候拉肚子，只能立刻跑去廁所了，而後一拉就是半個小時，而後B就一直等了半個小時。

這時候你是否是發現了二次握手的問題了，若是第二次B發送給A的話後，A沒有立刻回相應的信息給B，B就能夠認爲A已經不在了，從而再也不等它，也不創建通道。

因此應該是這樣：

1. A發信息給B：你在不在啊？急事！！
2. B發信息給A：我在啊，急事？那你快告訴我，我這邊時刻聽着你說。
3. A發信息給B：事情是這樣的。你聽我慢慢道來。
balabala.......
balabala.......
balabala.......
複製代碼

而後A和B之間的通道就通了，而後A這時候能夠給B不停的發信息了。

而後有人會問，TCP 又不會拉肚子，那TCP爲啥要三次，由於若是規定二次的話: A 發給B信息，申請創建通道，由於網絡延遲，B一直沒收到，這時候A等的不耐煩了，直接就退出了，可是過了一下子B收到了這個信息，B覺得A是剛發的請求，因此創建了通道，可是A其實早就已經不在了。這樣防止B造成死鎖、浪費資源等。

固然上面是咱們舉得例子，具體確定是經過一些值來傳遞：具體的圖是這樣的：

四次揮手：

咱們知道TCP鏈接以後咱們能夠相互之間發消息了，這裏咱們假設這個通道里面其實包含了二個小通道，一個通道是用來A發給B的，一個通道用來是B發給A的，這樣當咱們要斷開鏈接的時候有二大步：

1. 斷開A發給B信息的通道
2. 斷開B發給A信息的通道

咱們先看斷開A發給B信息的通道:

A發信息給B：我累了，我先睡了，88.

B發信息給A：好的，那你先睡吧。
複製代碼

這時候A就睡覺了，A也不會發信息給B了。可是這時候B仍是能夠繼續給A發信息，B可能深夜忽然來個深情告白

B發信息給A： 其實我XXXXXXXX。
複製代碼

因此咱們單純二次揮手是不夠的，還要斷開B發給A信息的通道：

B發信息給A：不過你說你要睡了，我以爲是比較晚了，我也要睡了，晚安。

A發信息給B： 那你也早點睡。晚安
複製代碼

因此連在一塊兒是：

A發信息給B：我累了，我先睡了，88.

B發信息給A：好的，那你先睡吧

B發信息給A：不過你說你要睡了，我以爲是比較晚了，我也要睡了，晚安。

A發信息給B： 那你也早點睡。晚安
複製代碼

那實際的四次揮手確定也是傳值通知，具體的圖是這樣的：

剛開始是雙向通訊，而後二次揮手後，A到B的斷了，因此這時候變成單向的數據傳輸，而後再二次揮手，把這個單向數據傳輸也關閉。

因此咱們看到了TCP的鏈接和斷開都這麼多步，屢次確認等操做，可是UDP是不須要先創建一個穩定的通道，直接就把數據發過去了。因此UDP更快，由於不用先去創建鏈接。

1.2 TCP的無差錯傳輸

咱們平時確定聽到過TCP傳輸安全，UDP傳輸不安全等說法，TCP傳輸保證了數據最終能穩定安全的到達目的地，而UDP只管發送過去，不負責最終是否收到，具體緣由是爲啥呢？？？

我仍是如下載工具 《迅雷》來進行說明（可能迅雷的功能實現更復雜，我就單純用來講明TCP例子了，若是例子寫的不對，歡迎你們指出）：

問題1： 迅雷下載用的是TCP仍是UDP？

下載東西咱們確定經歷過下載的內容下載到百分之99,可能這個文件都是沒用的，說明傳輸中咱們對下載的文件要求百分百都收到。這樣確定是使用TCP來控制，由於UDP發送後無論你有沒有收到。

問題2：用它下載東西的時候，忽然中間一段時間網絡不好，那時候服務器的發送的包都收不到了，可是最終仍是下載了一個完整的包（有點相似迅雷的繼續下載的感受）

其實這個問題我說的更詳細點：好比一個文件被分割成100份，我再收到第3份的時候若是由於網絡很差沒收到，它怎麼校驗我沒收到第三份，而不是頭腦發熱直接發第四份第五份給我。應該是發現我第三份沒收到，繼續發一份第三份給我。同時若是控制它不是一古腦兒所有100份發出，而是發送一些，接收方收到一些，而後再發送一些。

就像上面說的有100份，可是接收端到第三份的時候就沒收到，這時候發送端不該該繼續發送第四份，第五份，說明接收端有給發送端反饋，就像：

A經過QQ要發給B 100個文件，可是這些文件是要有順序的來接受。
這時候A發送一個文件，B接受一個文件，而後的界面就會有相應提示：
複製代碼

這時候A就知道了B已經收到了2個文件了，開始發第三個。
若是過了一段時間都沒有收到這個B成功收到文件的提示，
則B就繼續發送一個3.txt文件。


而對於A來講，若是QQ沒收看到3.txt接受的提示，
而是直接收到了4.txt接受的請求，你確定就是直接忽略，
而不是去下載4.txt文件，仍是從新等待3.txt文件，
反正只要B沒收到A成功下載3.txt文件的提示超時後就會從新發送3.txt。
複製代碼

發送端：

對於發送端： 每收到一個確認幀，發送窗口就向前滑動一個幀的距離 當發送窗口內無可發送的幀時（即窗口內的幀所有是已發送但未收到確認的幀），發送方就會中止發送，直到收到接收方發送的確認幀使窗口移動，窗口內有能夠發送的幀，以後纔開始繼續發送 具體以下圖：

接收端：

對於接收端：當收到數據幀後，將窗口向前移動一個位置，併發回確認幀，若收到的數據幀落在接收窗口以外，則一概丟棄。

滑動窗口 協議的重要特性：

• 只有接收窗口向前滑動、接收方發送了確認幀時，發送窗口才有可能（只有發送方收到確認幀纔是必定）向前滑動
• 中止-等待協議、後退N幀協議 & 選擇重傳協議只是在發送窗口大小和接收窗口大小上有所差異：

1.中止等待協議：發送窗口大小=1，接收窗口大小=1；即 單幀滑動窗口 等於 中止-等待協議
2.後退N幀協議：發送窗口大小>1，接收窗口大小=1。
3.選擇重傳協議：發送窗口大小>1，接收窗口大小>1。

• 當接收窗口的大小爲1時，可保證幀有序接收。
• 數據鏈路層的滑動窗口協議中，窗口的大小在傳輸過程當中是固定的（注意要與TCP的滑動窗口協議區別）

1.3 TCP 與 UDP 區別

角度	TCP	UCP
是否鏈接	面向鏈接(發送數據前須要創建鏈接)	無鏈接(發送數據無需鏈接)
是否丟包重試	實現了數據傳輸時各類控制功能，能夠進行丟包的重發控制，還能夠對次序亂掉的分包進行順序控制	不會進行丟包重試，也不會糾正到達的順序
模式	流模式(面向字節流)	數據報模式(面向報文)
對應關係	一對一	支持一對一，一對多，多對一和多對多的交互通訊
頭部開銷	最小20字節	只有8字節
可靠性	全雙工很是可靠、無差錯、不丟失、不重複、且按序到達	不保證可靠交付，不保證順序到達
擁塞控制	有控制	有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如IP電話，實時視頻會議等）
資源要求	TCP程序結構較複雜，較多	UDP程序結構簡單，少

結語：

其實關於TCP有不少不少能夠講，好比報文段格式,擁塞控制等，而我本文更多的是講了你們平時聽到的更多的知識點，結合通俗易懂的說明方式講了下。固然我自己網絡不好，因此有些地方若是講錯了歡迎你們指出。

關於具體的很細的細節，推薦看：計算機網絡：這是一份全面 & 詳細 的TCP協議攻略，部分圖片都是該文引入。

參考文章：

計算機網絡：這是一份全面 & 詳細 的TCP協議攻略