一文搞懂(dǒng)什(shén)麽是TCP/IP協議(yì)
2020-8-13新聞
什(shén)麽是TCP/IP協議(yì)?
計算(suàn)機與網絡設備之間如果要相互通(tōng)信,雙方就必須基于相同的(de)方法.比如如何探測到通(tōng)信目标.由哪一邊先發起通(tōng)信,使用(yòng)哪種語言進行通(tōng)信,怎樣結束通(tōng)信等規則都需要事先确定.不同的(de)硬件,操作系統之間的(de)通(tōng)信,所有這(zhè)一切都需要一種規則.而我們就将這(zhè)種規則稱爲協議(yì) (protocol).
也(yě)就是說，TCP/IP 是互聯網相關各類協議(yì)族的(de)總稱。
TCP/IP 的(de)分(fēn)層管理(lǐ)
TCP/IP協議(yì)裏最重要的(de)一點就是分(fēn)層。TCP/IP協議(yì)族按層次分(fēn)别爲 應用(yòng)層，傳輸層，網絡層，數據鏈路層，物(wù)理(lǐ)層。當然也(yě)有按不同的(de)模型分(fēn)爲4層或者7層的(de)。
爲什(shén)麽要分(fēn)層呢(ne)？
把 TCP/IP 協議(yì)分(fēn)層之後，如果後期某個(gè)地方設計修改，那麽就無需全部替換，隻需要将變動的(de)層替換。而且從設計上來(lái)說，也(yě)變得(de)簡單了(le)。處于應用(yòng)層上的(de)應用(yòng)可(kě)以隻考慮分(fēn)派給自己的(de)任務，而不需要弄清對(duì)方在地球上哪個(gè)地方，怎樣傳輸，如果确保到達率等問題。
如上圖所示，我們将TCP/IP分(fēn)爲5層，越靠下(xià)越接近硬件。我們由下(xià)到上來(lái)了(le)解一下(xià)這(zhè)些分(fēn)層。
物(wù)理(lǐ)層
該層負責 比特流在節點之間的(de)傳輸，即負責物(wù)理(lǐ)傳輸，這(zhè)一層的(de)協議(yì)既與鏈路有關，也(yě)與傳輸的(de)介質有關。通(tōng)俗來(lái)說就是把計算(suàn)機連接起來(lái)的(de)物(wù)理(lǐ)手段。
數據鏈路層
控制網絡層與物(wù)理(lǐ)層之間的(de)通(tōng)信，主要功能是保證物(wù)理(lǐ)線路上進行可(kě)靠的(de)數據傳遞。爲了(le)保證傳輸，從網絡層接收到的(de)數據被分(fēn)割成特定的(de)可(kě)被物(wù)理(lǐ)層傳輸的(de)幀。幀是用(yòng)來(lái)移動數據結構的(de)結構包，他(tā)不僅包含原始數據，還(hái)包含發送方和(hé)接收方的(de)物(wù)理(lǐ)地址以及糾錯和(hé)控制信息。其中的(de)地址确定了(le)幀将發送到何處，而糾錯和(hé)控制信息則确保幀無差錯到達。如果在傳達數據時(shí)，接收點檢測到所傳數據中有差錯，就要通(tōng)知發送方重發這(zhè)一幀。
網絡層
決定如何将數據從發送方路由到接收方。網絡層通(tōng)過綜合考慮發送優先權，網絡擁塞程度，服務質量以及可(kě)選路由的(de)花費等來(lái)決定從網絡中的(de)A節點到B節點的(de)最佳途徑。即建立主機到主機的(de)通(tōng)信。
傳輸層
該層爲兩台主機上的(de)應用(yòng)程序提供端到端的(de)通(tōng)信。傳輸層有兩個(gè)傳輸協議(yì)：TCP(傳輸控制協議(yì))和(hé) UDP(用(yòng)戶數據報協議(yì))。其中，TCP是一個(gè)可(kě)靠的(de)面向連接的(de)協議(yì)，udp是不可(kě)靠的(de)或者說無連接的(de)協議(yì)
應用(yòng)層
應用(yòng)程序收到傳輸層的(de)數據後，接下(xià)來(lái)就要進行解讀。解讀必須事先規定好格式，而應用(yòng)層就是規定應用(yòng)程序的(de)數據格式。主要的(de)協議(yì)有：HTTP.FTP,Telent等。
TCP與UDP
TCP/UDP 都是傳輸層協議(yì)，但是兩者具有不同的(de)特效，同時(shí)也(yě)具有不同的(de)應用(yòng)場(chǎng)景。
面向報文
面向報文的(de)傳輸方式是應用(yòng)層交給UDP多(duō)長(cháng)的(de)報文，UDP發送多(duō)長(cháng)的(de)報文，即一次發送一個(gè)報文。因此，應用(yòng)程序必須選擇合适大(dà)小的(de)報文。
面向字節流
雖然應用(yòng)程序和(hé)TCP的(de)交互是一次一個(gè)數據塊(大(dà)小不等)，但TCP把應用(yòng)程序看成是一連串的(de)無結構的(de)字節流。TCP有一個(gè)緩沖，當應該程序傳送的(de)數據塊太長(cháng)，TCP就可(kě)以把它劃分(fēn)短一些再傳送。
TCP的(de)三次握手與四次揮手
具體過程如下(xià)：
第一次握手：建立連接。客戶端發送連接請求報文段，并将syn(标記位)設置爲1，Squence Number(數據包序号)(seq)爲x,接下(xià)來(lái)等待服務端确認，客戶端進入SYN_SENT狀态(請求連接)；
第二次握手：服務端收到客戶端的(de) SYN 報文段，對(duì) SYN 報文段進行确認，設置 ack(确認号)爲 x+1(即seq+1 ; 同時(shí)自己還(hái)要發送 SYN 請求信息，将 SYN 設置爲1, seq爲 y。服務端将上述所有信息放到 SYN+ACK 報文段中，一并發送給客戶端，此時(shí)服務器進入 SYN_RECV狀态。
SYN_RECV是指,服務端被動打開後,接收到了(le)客戶端的(de)SYN并且發送了(le)ACK時(shí)的(de)狀态。再進一步接收到客戶端的(de)ACK就進入ESTABLISHED狀态。
第三次握手：客戶端收到服務端的(de) SYN+ACK(确認符) 報文段；然後将 ACK 設置爲 y+1,向服務端發送ACK報文段，這(zhè)個(gè)報文段發送完畢後，客戶端和(hé)服務端都進入ESTABLISHED(連接成功)狀态，完成TCP 的(de)三次握手。
上面的(de)解釋可(kě)能有點不好理(lǐ)解，用(yòng)《圖解HTTP》中的(de)一副插圖 幫助大(dà)家。
當客戶端和(hé)服務端通(tōng)過三次握手建立了(le) TCP 連接以後,當數據傳送完畢,斷開連接就需要進行TCP的(de)四次揮手。其四次揮手如下(xià)所示：
第一次揮手
客戶端設置seq和(hé) ACK ,向服務器發送一個(gè) FIN(終結)報文段。此時(shí)，客戶端進入 FIN_WAIT_1 狀态，表示客戶端沒有數據要發送給服務端了(le)。
第二次揮手
服務端收到了(le)客戶端發送的(de) FIN 報文段，向客戶端回了(le)一個(gè) ACK 報文段。
第三次揮手
服務端向客戶端發送FIN 報文段，請求關閉連接，同時(shí)服務端進入 LAST_ACK 狀态。
第四次揮手
客戶端收到服務端發送的(de) FIN 報文段後，向服務端發送 ACK 報文段,然後客戶端進入 TIME_WAIT 狀态。服務端收到客戶端的(de) ACK 報文段以後，就關閉連接。此時(shí)，客戶端等待 2MSL（指一個(gè)片段在網絡中最大(dà)的(de)存活時(shí)間）後依然沒有收到回複，則說明(míng)服務端已經正常關閉，這(zhè)樣客戶端就可(kě)以關閉連接了(le)。
最後再看一下(xià)完整的(de)過程：
如果有大(dà)量的(de)連接，每次在連接，關閉都要經曆三次握手，四次揮手，這(zhè)顯然會造成性能低下(xià)。因此。Http 有一種叫做(zuò) 長(cháng)連接（keepalive connections） 的(de)機制。它可(kě)以在傳輸數據後仍保持連接，當客戶端需要再次獲取數據時(shí)，直接使用(yòng)剛剛空閑下(xià)來(lái)的(de)連接而無需再次握手。
一些問題彙總：
1. 爲什(shén)麽要三次握手？
爲了(le)防止已失效的(de)連接請求報文突然又傳送到了(le)服務端，因爲産生錯誤。
具體解釋： “已失效的(de)連接請求報文段”産生情況：
client 發出的(de)第一個(gè)連接請求報文段并沒有丢失，而是在某個(gè)網絡節點長(cháng)時(shí)間滞留，因此導緻延誤到連接釋放以後的(de)某個(gè)時(shí)間才到達 service。如果沒有三次握手，那麽此時(shí)server收到此失效的(de)連接請求報文段，就誤認爲是 client再次發出的(de)一個(gè)新的(de)連接請求，于是向 client 發出确認報文段，同意建立連接，而此時(shí) client 并沒有發出建立連接的(de)情況，因此并不會理(lǐ)會服務端的(de)響應，而service将會一直等待client發送數據，因此就會導緻這(zhè)條連接線路白白浪費。
如果此時(shí)變成兩次揮手行不行？
這(zhè)個(gè)時(shí)候需要明(míng)白全雙工與半雙工，再進行回答(dá)。比如：
第一次握手： A給B打電話(huà)說，你可(kě)以聽(tīng)到我說話(huà)嗎？
第二次握手： B收到了(le)A的(de)信息，然後對(duì)A說： 我可(kě)以聽(tīng)得(de)到你說話(huà)啊，你能聽(tīng)得(de)到我說話(huà)嗎？
第三次握手： A收到了(le)B的(de)信息，然後說可(kě)以的(de)，我要給你發信息啦！
在三次握手之後，A和(hé)B都能确定這(zhè)麽一件事： 我說的(de)話(huà)，你能聽(tīng)到； 你說的(de)話(huà)，我也(yě)能聽(tīng)到。 這(zhè)樣，就可(kě)以開始正常通(tōng)信了(le)，如果是兩次，那将無法确定。
2. 爲什(shén)麽要四次揮手？
TCP 協議(yì)是一種面向連接，可(kě)靠，基于字節流的(de)傳輸層通(tōng)信協議(yì)。TCP 是全雙工模式(同一時(shí)刻可(kě)以同時(shí)發送和(hé)接收)，這(zhè)就意味著(zhe)，當主機1發出 FIN 報文段時(shí)，隻是表示主機1已結沒有數據要發送了(le)，主機1告訴主機2，它的(de)數據已經全部發送完畢；但是，這(zhè)個(gè)時(shí)候主機1還(hái)是可(kě)以接受來(lái)自主機2的(de)數據；當主機2返回 ACK報文段時(shí)，這(zhè)個(gè)時(shí)候就表示主機2也(yě)沒有數據要發送了(le)，就會告訴主機1，我也(yě)沒有數據要發送了(le)，之後彼此就會中斷這(zhè)次TCP連接。
3.爲什(shén)麽要等待 2MSL
MSL：報文段最大(dà)生存時(shí)間，它是任何報文段被丢棄前在網絡内的(de)最長(cháng)時(shí)間
原因如下(xià)：
保證TCP協議(yì)的(de)全雙工連接能夠可(kě)靠關閉
保證這(zhè)次連接的(de)重複數據從網絡中消息
第一點： 如果主機1直接 關閉，由于IP協議(yì)的(de)不可(kě)靠性或者其他(tā)網絡原因，導緻主機2沒有收到主機1最後回複的(de) ACK。那麽主機2就會在超時(shí)之後繼續發送 FIN，此時(shí)由于主機1已經關閉，就找不到與重發的(de) FIN 對(duì)應的(de)連接。所以，主機1 不是直接進入 關閉，而是TIME_WAIT 狀态。當再次收到 FIN 的(de)時(shí)候，能夠保證對(duì)方收到 ACK ，最後正确關閉連接。
第二點：如果主機1直接 關閉，然後又再向主機 2 發起一個(gè)新連接，我們不能保證這(zhè)個(gè)新連接與剛才關閉的(de)連接端口是不同的(de)。也(yě)就是說有可(kě)能新連接和(hé)老連接的(de)端口号是相同的(de)。一般來(lái)說不會發生什(shén)麽問題，但還(hái)是有特殊情況出現；假設新連接和(hé)已經關閉的(de)老連接端口号是一樣的(de)，如果前一次連接的(de)某些數據仍然滞留在網絡中( Lost Duplicate )，那些延遲數據在建立新連接之後才到達主機2，由于新連接和(hé)老連接的(de)端口号是一樣的(de)，TCP 協議(yì)就認爲哪個(gè)延遲的(de)數據時(shí)屬于新連接的(de)，這(zhè)樣就和(hé)真正的(de)新連接的(de)數據包發生混淆了(le)。所以TCP連接要在 TIME_WAIT 狀态等待兩倍 MSL ，保證本次連接的(de)所有數據都從網絡中消失。
