【大神筆記】一文搞懂什么是TCP/IP協(xié)議
什么是TCP/IP協(xié)議?
計算機與網(wǎng)絡(luò)設(shè)備之間如果要相互通信，雙方就必須基于相同的方法。比如如何探測到通信目標，由哪一邊先發(fā)起通信，使用哪種語言進行通信，怎樣結(jié)束通信等規(guī)則都需要事先確定。不同的硬件，操作系統(tǒng)之間的通信，所有這一切都需要一種規(guī)則。而我們就將這種規(guī)則稱為協(xié)議 (protocol)。
也就是說，TCP/IP 是互聯(lián)網(wǎng)相關(guān)各類協(xié)議族的總稱。
TCP/IP 的分層管理
TCP/IP協(xié)議里最重要的一點就是分層。TCP/IP協(xié)議族按層次分別為：應(yīng)用層，傳輸層，網(wǎng)絡(luò)層，數(shù)據(jù)鏈路層，物理層。當(dāng)然也有按不同的模型分為4層或者7層的。
- 為什么要分層呢？
把 TCP/IP 協(xié)議分層之后，如果后期某個地方設(shè)計修改，那么就無需全部替換，只需要將變動的層替換。而且從設(shè)計上來說，也變得簡單了。處于應(yīng)用層上的應(yīng)用可以只考慮分派給自己的任務(wù)，而不需要弄清對方在地球上哪個地方，怎樣傳輸，如果確保到達率等問題。
如上圖所示，我們將TCP/IP分為5層，越靠下越接近硬件。我們由下到上來了解一下這些分層。
1.物理層
該層負責(zé)比特流在節(jié)點之間的傳輸，即負責(zé)物理傳輸，這一層的協(xié)議既與鏈路有關(guān)，也與傳輸?shù)慕橘|(zhì)有關(guān)。通俗來說就是把計算機連接起來的物理手段。
2.數(shù)據(jù)鏈路層
控制網(wǎng)絡(luò)層與物理層之間的通信，主要功能是保證物理線路上進行可靠的數(shù)據(jù)傳遞。為了保證傳輸，從網(wǎng)絡(luò)層接收到的數(shù)據(jù)被分割成特定的可被物理層傳輸?shù)膸?br/>幀是用來移動數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)包，他不僅包含原始數(shù)據(jù)，還包含發(fā)送方和接收方的物理地址以及糾錯和控制信息。其中的地址確定了幀將發(fā)送到何處，而糾錯和控制信息則確保幀無差錯到達。如果在傳達數(shù)據(jù)時，接收點檢測到所傳數(shù)據(jù)中有差錯，就要通知發(fā)送方重發(fā)這一幀。
3.網(wǎng)絡(luò)層
決定如何將數(shù)據(jù)從發(fā)送方路由到接收方。網(wǎng)絡(luò)層通過綜合考慮發(fā)送優(yōu)先權(quán)，網(wǎng)絡(luò)擁塞程度，服務(wù)質(zhì)量以及可選路由的花費等來決定從網(wǎng)絡(luò)中的A節(jié)點到B節(jié)點的最佳途徑。即建立主機到主機的通信。
4.傳輸層
該層為兩臺主機上的應(yīng)用程序提供端到端的通信。傳輸層有兩個傳輸協(xié)議：TCP(傳輸控制協(xié)議)和 UDP(用戶數(shù)據(jù)報協(xié)議)。其中，TCP是一個可靠的面向連接的協(xié)議，UDP是不可靠的或者說無連接的協(xié)議
5.應(yīng)用層
應(yīng)用程序收到傳輸層的數(shù)據(jù)后，接下來就要進行解讀。解讀必須事先規(guī)定好格式，而應(yīng)用層就是規(guī)定應(yīng)用程序的數(shù)據(jù)格式。主要的協(xié)議有：HTTP.FTP,Telent等。
TCP與UDP
TCP/UDP 都是傳輸層協(xié)議，但是兩者具有不同的特效，同時也具有不同的應(yīng)用場景。
- 面向報文
面向報文的傳輸方式是應(yīng)用層交給UDP多長的報文，UDP發(fā)送多長的報文，即一次發(fā)送一個報文。因此，應(yīng)用程序必須選擇合適大小的報文。
- 面向字節(jié)流
雖然應(yīng)用程序和TCP的交互是一次一個數(shù)據(jù)塊(大小不等)，但TCP把應(yīng)用程序看成是一連串的無結(jié)構(gòu)的字節(jié)流。TCP有一個緩沖，當(dāng)應(yīng)該程序傳送的數(shù)據(jù)塊太長，TCP就可以把它劃分短一些再傳送。
TCP的三次握手與四次揮手
具體過程如下：
- 第一次握手：建立連接?？蛻舳税l(fā)送連接請求報文段，并將syn(標記位)設(shè)置為1，Squence Number(數(shù)據(jù)包序號)(seq)為x,接下來等待服務(wù)端確認，客戶端進入SYN_SENT狀態(tài)(請求連接)；
- 第二次握手：服務(wù)端收到客戶端的 SYN 報文段，對 SYN 報文段進行確認，設(shè)置 ack(確認號)為 x+1(即seq+1) ; 同時自己還要發(fā)送 SYN 請求信息，將 SYN 設(shè)置為1, seq為 y。服務(wù)端將上述所有信息放到 SYN+ACK 報文段中，一并發(fā)送給客戶端，此時服務(wù)器進入 SYN_RECV狀態(tài)。
SYN_RECV是指,服務(wù)端被動打開后,接收到了客戶端的SYN并且發(fā)送了ACK時的狀態(tài)。再進一步接收到客戶端的ACK就進入ESTABLISHED狀態(tài) - 第三次握手：客戶端收到服務(wù)端的 SYN+ACK(確認符) 報文段；然后將 ACK 設(shè)置為 y+1,向服務(wù)端發(fā)送ACK報文段，這個報文段發(fā)送完畢后，客戶端和服務(wù)端都進入ESTABLISHED(連接成功)狀態(tài)，完成TCP 的三次握手。
上面的解釋可能有點不好理解，用《圖解HTTP》中的一副插圖 幫助大家。
當(dāng)客戶端和服務(wù)端通過三次握手建立了 TCP 連接以后,當(dāng)數(shù)據(jù)傳送完畢,斷開連接就需要進行TCP的四次揮手。其四次揮手如下所示：
- 第一次揮手
客戶端設(shè)置seq和 ACK ,向服務(wù)器發(fā)送一個 FIN(終結(jié))報文段。此時，客戶端進入 FIN_WAIT_1 狀態(tài)，表示客戶端沒有數(shù)據(jù)要發(fā)送給服務(wù)端了。 - 第二次揮手
服務(wù)端收到了客戶端發(fā)送的 FIN 報文段，向客戶端回了一個 ACK 報文段。 - 第三次揮手
服務(wù)端向客戶端發(fā)送FIN 報文段，請求關(guān)閉連接，同時服務(wù)端進入 LAST_ACK 狀態(tài)。 - 第四次揮手
客戶端收到服務(wù)端發(fā)送的 FIN 報文段后，向服務(wù)端發(fā)送 ACK 報文段,然后客戶端進入 TIME_WAIT 狀態(tài)。服務(wù)端收到客戶端的 ACK 報文段以后，就關(guān)閉連接。此時，客戶端等待 2MSL（指一個片段在網(wǎng)絡(luò)中最大的存活時間）后依然沒有收到回復(fù)，則說明服務(wù)端已經(jīng)正常關(guān)閉，這樣客戶端就可以關(guān)閉連接了。
最后再看一下完整的過程：
如果有大量的連接，每次在連接，關(guān)閉都要經(jīng)歷三次握手，四次揮手，這顯然會造成性能低下。因此。Http 有一種叫做 長連接（keepalive connections） 的機制。它可以在傳輸數(shù)據(jù)后仍保持連接，當(dāng)客戶端需要再次獲取數(shù)據(jù)時，直接使用剛剛空閑下來的連接而無需再次握手。
問題匯總
1. 為什么要三次握手？
為了防止已失效的連接請求報文突然又傳送到了服務(wù)端，因為產(chǎn)生錯誤。
具體解釋：“已失效的連接請求報文段”產(chǎn)生情況：
client 發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)節(jié)點長時間滯留，因此導(dǎo)致延誤到連接釋放以后的某個時間才到達 service。如果沒有三次握手，那么此時server收到此失效的連接請求報文段，就誤認為是 client再次發(fā)出的一個新的連接請求，于是向 client 發(fā)出確認報文段，同意建立連接，而此時 client 并沒有發(fā)出建立連接的情況，因此并不會理會服務(wù)端的響應(yīng)，而service將會一直等待client發(fā)送數(shù)據(jù)，因此就會導(dǎo)致這條連接線路白白浪費。
如果此時變成兩次揮手行不行？
這個時候需要明白全雙工與半雙工，再進行回答。比如：
- 第一次握手：A給B打電話說，你可以聽到我說話嗎？
- 第二次握手：B收到了A的信息，然后對A說：我可以聽得到你說話啊，你能聽得到我說話嗎？
- 第三次握手：A收到了B的信息，然后說可以的，我要給你發(fā)信息啦！
在三次握手之后，A和B都能確定這么一件事：我說的話，你能聽到；你說的話，我也能聽到。這樣，就可以開始正常通信了，如果是兩次，那將無法確定。
2. 為什么要四次揮手？
TCP 協(xié)議是一種面向連接，可靠，基于字節(jié)流的傳輸層通信協(xié)議。TCP 是全雙工模式(同一時刻可以同時發(fā)送和接收)，這就意味著，當(dāng)主機1發(fā)出 FIN 報文段時，只是表示主機1已結(jié)沒有數(shù)據(jù)要發(fā)送了，主機1告訴主機2，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢；但是，這個時候主機1還是可以接受來自主機2的數(shù)據(jù)；當(dāng)主機2返回 ACK報文段時，這個時候就表示主機2也沒有數(shù)據(jù)要發(fā)送了，就會告訴主機1，我也沒有數(shù)據(jù)要發(fā)送了，之后彼此就會中斷這次TCP連接。
3.為什么要等待 2MSL？
MSL：報文段最大生存時間，它是任何報文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長時間。
原因如下：
- 保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉
- 保證這次連接的重復(fù)數(shù)據(jù)從網(wǎng)絡(luò)中消息
第一點：如果主機1直接 關(guān)閉，由于IP協(xié)議的不可靠性或者其他網(wǎng)絡(luò)原因，導(dǎo)致主機2沒有收到主機1最后回復(fù)的 ACK。那么主機2就會在超時之后繼續(xù)發(fā)送 FIN，此時由于主機1已經(jīng)關(guān)閉，就找不到與重發(fā)的 FIN 對應(yīng)的連接。所以，主機1 不是直接進入 關(guān)閉，而是TIME_WAIT 狀態(tài)。當(dāng)再次收到 FIN 的時候，能夠保證對方收到 ACK ，最后正確關(guān)閉連接。
第二點：如果主機1直接 關(guān)閉，然后又再向主機 2 發(fā)起一個新連接，我們不能保證這個新連接與剛才關(guān)閉的連接端口是不同的。也就是說有可能新連接和老連接的端口號是相同的。
一般來說不會發(fā)生什么問題，但還是有特殊情況出現(xiàn)；假設(shè)新連接和已經(jīng)關(guān)閉的老連接端口號是一樣的，如果前一次連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中( Lost Duplicate )，那些延遲數(shù)據(jù)在建立新連接之后才到達主機2，由于新連接和老連接的端口號是一樣的，TCP 協(xié)議就認為哪個延遲的數(shù)據(jù)時屬于新連接的，這樣就和真正的新連接的數(shù)據(jù)包發(fā)生混淆了。所以TCP連接要在 TIME_WAIT 狀態(tài)等待兩倍 MSL ，保證本次連接的所有數(shù)據(jù)都從網(wǎng)絡(luò)中消失。
推薦閱讀
>>>【獨家首發(fā)】新版HCIE考試解讀直播回顧
>>> 重磅！華為HCIE認證改版升級通知！
>>>【命令解析】Linux用戶行為的常用命令
>>> 網(wǎng)工必備通信基礎(chǔ)知識，還不知道你就out了？
>>>【必備干貨】網(wǎng)工入門必會橋接教程，外網(wǎng)+GNS3+Vmware
>>>【技術(shù)指南】5分鐘搞清楚OSPF鏈路狀態(tài)路由協(xié)議
網(wǎng)工界市場認可度極高的華為認證，你考了嗎？
拿下華為HCIE認證之后，你可以：
- 跨越90%企業(yè)的招聘硬門檻
- 增加70%就業(yè)機會
- 拿下BAT全國TOP100大廠敲門磚
- 體系化得到網(wǎng)絡(luò)技術(shù)硬實力
- 技術(shù)大佬年薪可達30w+
最后再附上一些學(xué)習(xí)資料吧，非常適合剛開始接觸學(xué)習(xí)網(wǎng)絡(luò)的朋友，里面更多的是一些基礎(chǔ)的內(nèi)容。
如果對未來的發(fā)展，或者行業(yè)的前景不是很明確的話，可以聽聽看，會對你有很大的幫助。鏈接放在評論區(qū)了，有需自取。
（文章來源網(wǎng)絡(luò) 侵刪）
