介于自己的網(wǎng)絡(luò)方面知識爛的一塌糊涂，所以準(zhǔn)備寫相關(guān)網(wǎng)絡(luò)的文章坟募，但是考慮全部寫在一篇太長了，所以分開寫邑狸，希望大家能仔細(xì)看婿屹，最好可以指出我的錯(cuò)誤，讓我也能糾正推溃。

image

1.講解相關(guān)的整個(gè)網(wǎng)絡(luò)體系結(jié)構(gòu)：

Android技能樹 — 網(wǎng)絡(luò)小結(jié)(1)之網(wǎng)絡(luò)體系結(jié)構(gòu)

2.講解相關(guān)網(wǎng)絡(luò)的重要知識點(diǎn)昂利，比如很多人都聽過相關(guān)網(wǎng)絡(luò)方面的名詞，但是僅限于聽過而已铁坎，什么tcp ,udp ,socket ,websocket, http ,https ,然后webservice是啥蜂奸，跟websocket很像，socket和websocket啥關(guān)系長的也很像硬萍，session,token,cookie又是啥扩所。

Android技能樹 — 網(wǎng)絡(luò)小結(jié)(2)之TCP/UDP

Android技能樹 — 網(wǎng)絡(luò)小結(jié)(3)之HTTP/HTTPS

Android技能樹 — 網(wǎng)絡(luò)小結(jié)(4)之socket/websocket/webservice

相關(guān)網(wǎng)絡(luò)知識點(diǎn)小結(jié)- cookie/session/token（待寫）

3.相關(guān)的第三方框架的源碼解析，畢竟現(xiàn)在面試個(gè)大點(diǎn)的公司朴乖，okhttp和retrofit源碼是必問的祖屏。

Android技能樹 — 網(wǎng)絡(luò)小結(jié)(6)之 OkHttp超超超超超超超詳細(xì)解析

Android技能樹 — 網(wǎng)絡(luò)小結(jié)(7)之 Retrofit源碼詳細(xì)解析

正文

在網(wǎng)絡(luò)體系結(jié)構(gòu)小結(jié)中我們知道了大概的網(wǎng)絡(luò)結(jié)構(gòu)層級，這篇文章側(cè)重的講一些平時(shí)大家聽到的熟悉的詞匯TCP 與 UDP买羞。

1. TCP與UDP：

在網(wǎng)絡(luò)體系結(jié)構(gòu)小結(jié)中我們提過TCP/IP的四層網(wǎng)絡(luò)層級：

image

而TCP (Transmission Control Protocol袁勺，即 傳輸控制協(xié)議)和 UPD （User Datagram Protocol，即用戶數(shù)據(jù)報(bào)協(xié)議）是在傳輸層的畜普，所以我們知道UDP和TCP是用來傳輸數(shù)據(jù)的一種協(xié)議期丰，為主機(jī)中不同的進(jìn)程提供通信，那既然是傳輸數(shù)據(jù)，我們舉例以快遞和寄信的邏輯來說明（反正都是某個(gè)東西從一個(gè)地方到另外一個(gè)地方）钝荡。

TCP像快遞街立，因?yàn)槲覀儸F(xiàn)在寄快遞都能看到具體快遞到哪里了，某個(gè)中轉(zhuǎn)站是否已經(jīng)收到了我的快遞埠通，最后的目的地是否收到了我的快遞赎离，如果快遞丟了也會給你反饋等，幫你重新補(bǔ)寄等端辱。而UDP更像寄信梁剔，我反正寄出去了，收不收得到我也不管掠手。(emmm....可能這個(gè)例子不太恰當(dāng)憾朴。。喷鸽。)

所以我們初步感覺：對比于UDP众雷，TCP的傳輸是可靠的、無差錯(cuò)的做祝。

1.1 TCP通道的連接及斷開

既然是數(shù)據(jù)從一個(gè)地方到另外一個(gè)地方砾省，我們要先建立一個(gè)通道，這樣后面數(shù)據(jù)才能傳輸流動混槐。（PS:這個(gè)比喻可能不恰當(dāng)编兄。如果有更好的比喻，可以留言声登。謝謝）

TCP三次握手狠鸳，四次揮手聽到的是不是很多，沒錯(cuò)悯嗓，這個(gè)就是用來建立這個(gè)通道及斷開通道件舵，我面試的別人的時(shí)候，三次建立脯厨，四次斷開基本都知道铅祸，但是我問他們?yōu)槭裁匆危芏喽即鸩簧蟻砗衔洹榱烁玫挠洃浟俟＃覀冞€是用具體的例子來說明：

三次握手：

1. A發(fā)信息給B：你在不在啊稼跳？急事Ｃ伺印！
2. B發(fā)信息給A：我在啊岂贩，急事茫经？那你快告訴我巷波，我這邊時(shí)刻聽著你說萎津。

不幸的是A這時(shí)候拉肚子卸伞，只能馬上跑去廁所了，然后一拉就是半個(gè)小時(shí)锉屈，然后B就一直等了半個(gè)小時(shí)荤傲。

這時(shí)候你是不是發(fā)現(xiàn)了二次握手的問題了，如果第二次B發(fā)送給A的話后颈渊，A沒有馬上回相應(yīng)的信息給B遂黍，B就可以認(rèn)為A已經(jīng)不在了，從而不再等它俊嗽，也不建立通道雾家。

所以應(yīng)該是這樣：

1. A發(fā)信息給B：你在不在啊绍豁？急事Ｐ具帧！
2. B發(fā)信息給A：我在啊竹揍，急事敬飒？那你快告訴我，我這邊時(shí)刻聽著你說芬位。
3. A發(fā)信息給B：事情是這樣的无拗。你聽我慢慢道來。
balabala.......
balabala.......
balabala.......

然后A和B之間的通道就通了昧碉，然后A這時(shí)候可以給B不停的發(fā)信息了英染。

然后有人會問，TCP 又不會拉肚子被饿，那TCP為啥要三次四康，因?yàn)槿绻?guī)定二次的話: A 發(fā)給B信息，申請建立通道锹漱，因?yàn)榫W(wǎng)絡(luò)延遲箭养，B一直沒收到，這時(shí)候A等的不耐煩了哥牍，直接就退出了毕泌，但是過了一會兒B收到了這個(gè)信息，B以為A是剛發(fā)的請求嗅辣，所以建立了通道撼泛，但是A其實(shí)早就已經(jīng)不在了。這樣防止B形成死鎖澡谭、浪費(fèi)資源等愿题。

image

當(dāng)然上面是我們舉得例子，具體肯定是通過一些值來傳遞：具體的圖是這樣的：

四次揮手：

我們知道TCP連接之后我們可以相互之間發(fā)消息了，這里我們假設(shè)這個(gè)通道里面其實(shí)包含了二個(gè)小通道潘酗，一個(gè)通道是用來A發(fā)給B的杆兵，一個(gè)通道用來是B發(fā)給A的，這樣當(dāng)我們要斷開連接的時(shí)候有二大步：

1. 斷開A發(fā)給B信息的通道
2. 斷開B發(fā)給A信息的通道

我們先看斷開A發(fā)給B信息的通道:

A發(fā)信息給B：我累了仔夺，我先睡了琐脏，88.

B發(fā)信息給A：好的，那你先睡吧缸兔。

這時(shí)候A就睡覺了日裙，A也不會發(fā)信息給B了。但是這時(shí)候B還是可以繼續(xù)給A發(fā)信息惰蜜，B可能深夜突然來個(gè)深情告白

B發(fā)信息給A： 其實(shí)我XXXXXXXX昂拂。

所以我們單純二次揮手是不夠的，還要斷開B發(fā)給A信息的通道：

B發(fā)信息給A：不過你說你要睡了抛猖，我覺得是比較晚了格侯，我也要睡了，晚安樟结。

A發(fā)信息給B： 那你也早點(diǎn)睡养交。晚安

所以連在一起是：

A發(fā)信息給B：我累了，我先睡了瓢宦，88.

B發(fā)信息給A：好的碎连，那你先睡吧

B發(fā)信息給A：不過你說你要睡了，我覺得是比較晚了驮履，我也要睡了鱼辙，晚安。

A發(fā)信息給B： 那你也早點(diǎn)睡玫镐。晚安

那實(shí)際的四次揮手肯定也是傳值通知倒戏，具體的圖是這樣的：

剛開始是雙向通信，然后二次揮手后恐似，A到B的斷了杜跷，所以這時(shí)候變成單向的數(shù)據(jù)傳輸，然后再二次揮手矫夷，把這個(gè)單向數(shù)據(jù)傳輸也關(guān)閉葛闷。

image

image

所以我們看到了TCP的連接和斷開都這么多步，多次確認(rèn)等操作双藕，但是UDP是不需要先建立一個(gè)穩(wěn)定的通道淑趾，直接就把數(shù)據(jù)發(fā)過去了。所以UDP更快忧陪，因?yàn)椴挥孟热ソ⑦B接扣泊。

1.2 TCP的無差錯(cuò)傳輸

我們平時(shí)肯定聽到過TCP傳輸安全近范，UDP傳輸不安全等說法，TCP傳輸保證了數(shù)據(jù)最終能穩(wěn)定安全的到達(dá)目的地延蟹，而UDP只管發(fā)送過去评矩，不負(fù)責(zé)最終是否收到，具體原因是為啥呢等孵？稚照？蹂空？

我還是以下載工具 《迅雷》來進(jìn)行說明（可能迅雷的功能實(shí)現(xiàn)更復(fù)雜俯萌，我就單純用來說明TCP例子了，如果例子寫的不對上枕，歡迎大家指出）：

問題1： 迅雷下載用的是TCP還是UDP咐熙？

下載東西我們肯定經(jīng)歷過下載的內(nèi)容下載到百分之99,可能這個(gè)文件都是沒用的，說明傳輸中我們對下載的文件要求百分百都收到辨萍。這樣肯定是使用TCP來控制棋恼，因?yàn)閁DP發(fā)送后不管你有沒有收到。

問題2：用它下載東西的時(shí)候锈玉，突然中間一段時(shí)間網(wǎng)絡(luò)很差爪飘，那時(shí)候服務(wù)器的發(fā)送的包都收不到了，但是最終還是下載了一個(gè)完整的包（有點(diǎn)類似迅雷的繼續(xù)下載的感覺）

其實(shí)這個(gè)問題我說的更詳細(xì)點(diǎn)：比如一個(gè)文件被分割成100份拉背，我再收到第3份的時(shí)候如果因?yàn)榫W(wǎng)絡(luò)不好沒收到师崎，它怎么校驗(yàn)我沒收到第三份，而不是頭腦發(fā)熱直接發(fā)第四份第五份給我椅棺。應(yīng)該是發(fā)現(xiàn)我第三份沒收到犁罩，繼續(xù)發(fā)一份第三份給我。同時(shí)如果控制它不是一股腦兒全部100份發(fā)出两疚，而是發(fā)送一些床估，接收方收到一些，然后再發(fā)送一些诱渤。

就像上面說的有100份丐巫，但是接收端到第三份的時(shí)候就沒收到，這時(shí)候發(fā)送端不應(yīng)該繼續(xù)發(fā)送第四份勺美，第五份递胧，說明接收端有給發(fā)送端反饋，就像：

A通過QQ要發(fā)給B 100個(gè)文件励烦，但是這些文件是要有順序的來接受谓着。
這時(shí)候A發(fā)送一個(gè)文件，B接受一個(gè)文件坛掠，然后的界面就會有相應(yīng)提示：

image

這時(shí)候A就知道了B已經(jīng)收到了2個(gè)文件了赊锚，開始發(fā)第三個(gè)治筒。
如果過了一段時(shí)間都沒有收到這個(gè)B成功收到文件的提示，
則B就繼續(xù)發(fā)送一個(gè)3.txt文件舷蒲。


而對于A來說耸袜，如果QQ沒收看到3.txt接受的提示，
而是直接收到了4.txt接受的請求牲平，你肯定就是直接忽略堤框，
而不是去下載4.txt文件，還是重新等待3.txt文件纵柿，
反正只要B沒收到A成功下載3.txt文件的提示超時(shí)后就會重新發(fā)送3.txt蜈抓。

發(fā)送端：

對于發(fā)送端：
每收到一個(gè)確認(rèn)幀，發(fā)送窗口就向前滑動一個(gè)幀的距離
當(dāng)發(fā)送窗口內(nèi)無可發(fā)送的幀時(shí)（即窗口內(nèi)的幀全部是已發(fā)送但未收到確認(rèn)的幀）昂儒，發(fā)送方就會停止發(fā)送沟使，直到收到接收方發(fā)送的確認(rèn)幀使窗口移動，窗口內(nèi)有可以發(fā)送的幀渊跋，之后才開始繼續(xù)發(fā)送
具體如下圖：

image

接收端：

對于接收端：當(dāng)收到數(shù)據(jù)幀后腊嗡，將窗口向前移動一個(gè)位置，并發(fā)回確認(rèn)幀拾酝，若收到的數(shù)據(jù)幀落在接收窗口之外燕少，則一律丟棄。

image

滑動窗口 協(xié)議的重要特性：

• 只有接收窗口向前滑動蒿囤、接收方發(fā)送了確認(rèn)幀時(shí)客们，發(fā)送窗口才有可能（只有發(fā)送方收到確認(rèn)幀才是一定）向前滑動
• 停止-等待協(xié)議、后退N幀協(xié)議 & 選擇重傳協(xié)議只是在發(fā)送窗口大小和接收窗口大小上有所差別：

1.停止等待協(xié)議：發(fā)送窗口大小=1蟋软，接收窗口大小=1镶摘；即 單幀滑動窗口 等于 停止-等待協(xié)議</br>
2.后退N幀協(xié)議：發(fā)送窗口大小>1，接收窗口大小=1岳守。</br>
3.選擇重傳協(xié)議：發(fā)送窗口大小>1凄敢，接收窗口大小>1。

• 當(dāng)接收窗口的大小為1時(shí)湿痢，可保證幀有序接收涝缝。
• 數(shù)據(jù)鏈路層的滑動窗口協(xié)議中，窗口的大小在傳輸過程中是固定的（注意要與TCP的滑動窗口協(xié)議區(qū)別）

1.3 TCP 與 UDP 區(qū)別

結(jié)語：

其實(shí)關(guān)于TCP有很多很多可以將澈吨，比如報(bào)文段格式,擁塞控制等把敢，而我本文更多的是講了大家平時(shí)聽到的更多的知識點(diǎn)，結(jié)合通俗易懂的說明方式講了下棚辽。當(dāng)然我本身網(wǎng)絡(luò)很差技竟，所以有些地方如果講錯(cuò)了歡迎大家指出。

關(guān)于具體的很細(xì)的細(xì)節(jié)屈藐，推薦看：計(jì)算機(jī)網(wǎng)絡(luò)：這是一份全面 & 詳細(xì) 的TCP協(xié)議攻略，部分圖片都是該文引入熙尉。

參考文章：

計(jì)算機(jī)網(wǎng)絡(luò)：這是一份全面 & 詳細(xì) 的TCP協(xié)議攻略