計(jì)算機(jī)網(wǎng)絡(luò)學(xué)習(xí)的核心內(nèi)容就是網(wǎng)絡(luò)協(xié)議的學(xué)習(xí)妨蛹。
網(wǎng)絡(luò)協(xié)議是為計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行數(shù)據(jù)交換而建立的規(guī)則屏富、標(biāo)準(zhǔn)或者說是約定的集合。
本文對(duì)Android程序員需要了解的部分計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)蛙卤，進(jìn)行簡(jiǎn)單梳理狠半。
TCP和UDP
TCP和UDP使用IP協(xié)議從一個(gè)網(wǎng)絡(luò)傳送數(shù)據(jù)包到另一個(gè)網(wǎng)絡(luò)。
把IP想像成一種高速公路颤难，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口神年。
TCP和UDP是高速公路上的“卡車”，它們攜帶的貨物就是像HTTP行嗤，文件傳輸協(xié)議FTP這樣的協(xié)議等已日。TCP和UDP是FTP，HTTP和SMTP之類使用的傳輸層協(xié)議昂验。
雖然TCP和UDP都是用來傳輸其他協(xié)議的捂敌，它們卻有一個(gè)顯著的不同：TCP提供有保證的數(shù)據(jù)傳輸，而UDP不提供既琴。這意味著TCP有一個(gè)特殊的機(jī)制來確保數(shù)據(jù)安全的不出錯(cuò)的從一個(gè)端點(diǎn)傳到另一個(gè)端點(diǎn)占婉，而UDP不提供任何這樣的保證。
TCP :
Transmission Controller Protocol是傳輸控制協(xié)議
提供的是面向連接甫恩、可靠的字節(jié)流服務(wù)逆济。
UDP :
User Data Protocol是用戶數(shù)據(jù)協(xié)議
是一個(gè)簡(jiǎn)單的面向數(shù)據(jù)包的運(yùn)輸層協(xié)議。
TCP和UDP的區(qū)別和優(yōu)缺點(diǎn)
區(qū)別1 是否連接
TCP：連接
客戶端和服務(wù)器交換數(shù)據(jù)之前磺箕，需要在雙方之前建立一個(gè)TCP連接之后才能傳輸數(shù)據(jù)奖慌。
一個(gè)TCP連接需要經(jīng)過三次對(duì)話才能建立起來，這三次對(duì)話的目的是使數(shù)據(jù)包的發(fā)送和接收同步松靡。
UDP：不連接
區(qū)別2 是否可靠
TCP：可靠
建立了連接简僧，TCP提供數(shù)據(jù)超時(shí)重發(fā)，丟棄重復(fù)數(shù)據(jù)雕欺，檢驗(yàn)數(shù)據(jù)岛马，流量控制等功能，保證數(shù)據(jù)從一端傳到另一端屠列。
UDP：不可靠
未建立連接啦逆，只是把應(yīng)用程序傳給IP層的數(shù)據(jù)包發(fā)送出去，也不能保證是否能到達(dá)目的地笛洛，且沒有超時(shí)重發(fā)等機(jī)制夏志。
區(qū)別3 應(yīng)用場(chǎng)合
TCP：傳輸大量數(shù)據(jù)，對(duì)可靠性較高要求苛让，如moba游戲中的游戲大廳沟蔑、商城
UDP：傳輸少量數(shù)據(jù)湿诊，可靠性不高的要求，如moba游戲中的戰(zhàn)斗
總結(jié)
TCP：傳輸控制協(xié)議溉贿，客戶端和服務(wù)器傳輸數(shù)據(jù)前要建立連接枫吧，此連接需要經(jīng)過三次對(duì)話建立，
由于建立了連接宇色，提供數(shù)據(jù)超時(shí)重發(fā)，丟棄重復(fù)數(shù)據(jù)等數(shù)據(jù)颁湖，因此適合傳輸大量數(shù)據(jù)宣蠕，但傳輸速度比較慢。
UDP：用戶數(shù)據(jù)協(xié)議甥捺，不必建立連接抢蚀，客戶端和服務(wù)器之間直接將IP層的數(shù)據(jù)包發(fā)送出去，
不能保證數(shù)據(jù)是否成功到達(dá)目的地镰禾，也沒有超時(shí)重發(fā)等機(jī)制皿曲，但傳輸速度很快，適合小數(shù)據(jù)吴侦，可靠要求不高的數(shù)據(jù)傳輸屋休。
TCP的三次握手和四次揮手
TCP是基于IP的虛電路可靠的全雙工通信服務(wù)，基本上可以分為鏈接建立备韧，數(shù)據(jù)傳輸劫樟，鏈接拆除三個(gè)階段。
在TCP層织堂，有個(gè)FLAGS字段叠艳，這個(gè)字段有以下幾個(gè)標(biāo)識(shí)：SYN, FIN, ACK, PSH, RST, URG.
其中，對(duì)于我們?nèi)粘５姆治鲇杏玫木褪乔懊娴奈鍌€(gè)字段易阳。
它們的含義是：
SYN表示建立連接||FIN表示關(guān)閉連接||ACK表示響應(yīng)||PSH表示有 DATA數(shù)據(jù)傳輸||RST表示連接重置
TCP建立連接需要進(jìn)行的三次握手
- 第一次握手：建立連接時(shí)附较，客戶端A發(fā)送SYN包（SYN=j）到服務(wù)器B，并進(jìn)入SYN_SEND狀態(tài)潦俺，等待服務(wù)器B確認(rèn)拒课。
- 第二次握手：服務(wù)器B收到SYN包，必須確認(rèn)客戶A的SYN（ACK=j+1）黑竞，同時(shí)自己也發(fā)送一個(gè)SYN包（SYN=k）捕发，即SYN+ACK包，此時(shí)服務(wù)器B進(jìn)入SYN_RECV狀態(tài)很魂。
- 第三次握手：客戶端A收到服務(wù)器B的SYN＋ACK包扎酷，向服務(wù)器B發(fā)送確認(rèn)包ACK（ACK=k+1），此包發(fā)送完畢遏匆，客戶端A和服務(wù)器B進(jìn)入ESTABLISHED狀態(tài)法挨，完成三次握手谁榜。
為什么是三次握手？
謝希仁的《計(jì)算機(jī)網(wǎng)絡(luò)》中關(guān)于該問額的解釋：
主要是為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳到了B,因而產(chǎn)生錯(cuò)誤凡纳。假定出現(xiàn)一種異常情況窃植，即A發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某些網(wǎng)絡(luò)結(jié) 點(diǎn)長(zhǎng)時(shí)間滯留了荐糜，一直延遲到連接釋放以后的某個(gè)時(shí)間才到達(dá)B巷怜，本來這是一個(gè)早已失效的報(bào)文段。但B收到此失效的連接請(qǐng)求報(bào)文段后暴氏，就誤認(rèn)為是A又發(fā)出一次 新的連接請(qǐng)求延塑，于是就向A發(fā)出確認(rèn)報(bào)文段，同意建立連接答渔。假定不采用三次握手关带，那么只要B發(fā)出確認(rèn)，新的連接就建立了沼撕，這樣一直等待A發(fā)來數(shù)據(jù)宋雏，B的許多 資源就這樣白白浪費(fèi)了。
Google論壇中對(duì)該問題的討論：
這個(gè)問題的本質(zhì)是, 通過一個(gè)不完全可靠的信道, 最少需要幾次消息傳輸, 信道兩邊的人能夠?qū)σ粋€(gè)問題達(dá)成一致. 對(duì)于TCP來說, 無論有沒有初始
序號(hào)的要求, 想要兩邊都同意開始傳出數(shù)據(jù), 就至少需要3次消息的交換:
0次: 顯然不行
1次: A->B, A不知道B是否同意
2次: A->B, B->A. B不知道A是否收到自己的消息, 因?yàn)樾诺啦煌耆煽?br> 3次: A->B, B->A, A->B. 兩邊都收到了對(duì)方的ACK, 意味著各自都了解了對(duì)方的意圖, 從而可以對(duì)是否開始通信這個(gè)最簡(jiǎn)單的問題達(dá)成一致.
從邏輯上講务豺，三次握手是[最省]的建立TCP鏈路［兩個(gè)通道］規(guī)程機(jī)制了磨总，所以就應(yīng)該三次握手。
TCP拆除連接需要進(jìn)行的四次揮手
由于TCP連接時(shí)全雙工的冲呢，因此舍败，每個(gè)方向都必須要單獨(dú)進(jìn)行關(guān)閉，這一原則是當(dāng)一方完成數(shù)據(jù)發(fā)送任務(wù)后敬拓，發(fā)送一個(gè)FIN來終止這一方向的連接邻薯，收到一個(gè)FIN只是意味著這一方向上沒有數(shù)據(jù)流動(dòng)了，即不會(huì)再收到數(shù)據(jù)了乘凸，但是在這個(gè)TCP連接上仍然能夠發(fā)送數(shù)據(jù)厕诡，直到這一方向也發(fā)送了FIN。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉营勤，而另一方則執(zhí)行被動(dòng)關(guān)閉灵嫌，上圖描述的即是如此。
- 第一次揮手：Client發(fā)送一個(gè)FIN葛作，用來關(guān)閉Client到Server的數(shù)據(jù)傳送寿羞，Client進(jìn)入FIN_WAIT_1狀態(tài)。
- 第二次揮手：Server收到FIN后赂蠢，發(fā)送一個(gè)ACK給Client绪穆，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同，一個(gè)FIN占用一個(gè)序號(hào)），Server進(jìn)入CLOSE_WAIT狀態(tài)玖院。
- 第三次揮手：Server發(fā)送一個(gè)FIN菠红，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)难菌。
- 第四次揮手：Client收到FIN后试溯，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)ACK給Server郊酒，確認(rèn)序號(hào)為收到序號(hào)+1遇绞，Server進(jìn)入CLOSED狀態(tài)，完成四次揮手猎塞。
上面有一個(gè)非常特殊的狀態(tài)time_wait试读，它是主動(dòng)關(guān)閉的一方在回復(fù)完對(duì)方的揮手后進(jìn)入的一個(gè)長(zhǎng)期狀態(tài)，這個(gè)狀態(tài)標(biāo)準(zhǔn)的持續(xù)時(shí)間是2個(gè)MSL荠耽，2個(gè)MSL后才會(huì)進(jìn)入到closed狀態(tài)，釋放套接字資源比藻。不過在具體實(shí)現(xiàn)上這個(gè)時(shí)間是可以調(diào)整的铝量。
它的作用是重傳最后一個(gè)ack報(bào)文，確保對(duì)方可以收到银亲。因?yàn)槿绻麑?duì)方?jīng)]有收到ack的話慢叨，會(huì)重傳fin報(bào)文，處于time_wait狀態(tài)的套接字會(huì)立即向?qū)Ψ街匕l(fā)ack報(bào)文务蝠。
2個(gè)MSL就是4分鐘拍谐。MSL就是maximium segment lifetime——最長(zhǎng)報(bào)文壽命。這個(gè)時(shí)間是由官方RFC協(xié)議規(guī)定的馏段。
Socket和WebSocket
Socket
計(jì)算機(jī)網(wǎng)絡(luò)中的Socket是應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層轩拨，它是一組接口。在設(shè)計(jì)模式中院喜，Socket其實(shí)就是一個(gè)門面模式亡蓉，它把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面，對(duì)用戶來說喷舀，一組簡(jiǎn)單的接口就是全部砍濒，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議。
Socket 接口是TCP/IP網(wǎng)絡(luò)的API，Socket接口定義了許多函數(shù)或例程援所，用以開發(fā)TCP/IP網(wǎng)絡(luò)上的應(yīng)用程序哩照。
WebSocket
WebSocket和Socket的關(guān)系就像Java和Javascript，基本上沒有太大關(guān)系茅茂，但有不能說完全沒有關(guān)系。
WebSocket 是一種網(wǎng)絡(luò)通信協(xié)議忿危。RFC6455 定義了它的通信標(biāo)準(zhǔn)感猛。
WebSocket 是 HTML5 開始提供的一種在單個(gè) TCP 連接上進(jìn)行全雙工通訊的協(xié)議七扰。
WebSocket的出現(xiàn)是用來彌補(bǔ)HTTP協(xié)議在持久通信能力上的不足，它的握手是以HTTP的形式發(fā)起的陪白，通過第一個(gè)request建立連接颈走，之后交換的數(shù)據(jù)都不需要發(fā)送HTTP header就能交換數(shù)據(jù)。
可以把WebSocket想象成HTTP咱士，HTTP和Socket什么關(guān)系立由，WebSocket和Socket就是什么關(guān)系。
更新一張神圖 TCP在三種狀態(tài)下的數(shù)據(jù)傳輸過程
推薦文章：
http://www.reibang.com/p/43a25804b2e8 TCP和UDP協(xié)議
https://blog.csdn.net/Tong_jy/article/details/78477634 學(xué)習(xí)TCP和UDP的總結(jié)
https://groups.google.com/forum/#!topic/pongba/kF6O7-MFxM0/discussion Google論壇關(guān)于TCP建立為什么是三次握手的討論
https://zhuanlan.zhihu.com/p/40667482 【TCP】詳解TCP 三次握手和四次揮手
