TCP/IP協議入門

TCP/IP協議入門

1. 簡介

Transmission Control Protocol/Internet Protocol的簡寫，即傳輸控制協議/因特網互聯協議。它是網絡通訊的一套協議集合。

先來看一下OSI和TCP/IP模型：

應用層

就是應用軟件使用的協議，如郵箱使用的POP3，SMTP、遠程登陸使用的Telnet、獲取IP地址的DHCP、域名解析的DNS、網頁瀏覽的http協議等；這部分協議主要是規定應用軟件如何去進行通訊的。

表現層

決定數據的展示（編碼）形式，如同一部電影能夠採樣、量化、編碼爲RMVB、AVI，一張圖片可以是JPEG、BMP、PNG等。

會話層

爲兩端通訊實體創建鏈接（會話），中間有認證鑑權以及檢查點記錄（供會話意外中斷的時候能夠繼續，相似斷點續傳）。

傳輸層

將一個數據/文件斬件分紅不少小段，標記順序以被對端接收後能夠按順序重組數據，另外標記該應用程序使用的端口號及提供QOS。TCP（傳輸控制協議）和UDP（用戶數據報協議）就是屬於傳輸層協議。

網絡層

路由選路，選擇本次通訊使用的協議（http、ftp等），指定路由策略及訪問控制策略。（IP地址在這一層）

數據鏈路層

根據端口與MAC地址，作分組（VLAN）隔離、端口安全、訪問控制。（MAC地址在這一層）處理VLAN內的數據幀轉發，跨VLAN間的訪問，須要上升到網絡層。

物理層

將數據最終編碼爲用0、1標識的比特流，而後傳輸。（例如將題主頭像的圖片，變爲一串01100111100這樣的數字來表示）。

2. TCP的三次握手和四次揮手

先來看一張經典的圖，這個圖清晰簡明的體現了TCP三次握手和四次揮手的流程。

來解釋其中的名詞：

SYN：即Synchronization，表示同步序號，用來創建鏈接，當SYN=1而ACK=0時，代表這是一個鏈接請求報文。對方若贊成創建鏈接，則應在響應報文中使SYN=1和ACK=1. 所以, SYN置1就表示這是一個鏈接請求或鏈接接收報文。

Seq：即Sequence Number，用來標識從TCP發送端向TCP接收端發送的數據字節流，它表示在這個報文段中的第一個數據字節在數據流中的序號；主要用來解決網絡報亂序的問題。

ACK：此標誌表示應答域有效，就是說前面所說的TCP應答號將會包含在TCP數據包中；有兩個取值：0和1，爲1的時候表示應答域有效，反之爲0；TCP協議規定，只有ACK=1時有效，也規定鏈接創建後全部發送的報文的ACK必須爲1。（注意：和下面的Acknowledgment Number不同，能夠理解ACK是Acknowledgment Number的標誌位）

Acknowledgment Number：32位確認序列號包含發送確認的一端所指望收到的下一個序號，所以，確認序號應當是上次已成功收到數據字節序號加1。不過，只有當標誌位中的ACK標誌（下面介紹）爲1時該確認序列號的字段纔有效。主要用來解決不丟包的問題；

FIN：即finis，終結的意思， 用來釋放一個鏈接。當 FIN = 1 時，代表此報文段的發送方的數據已經發送完畢，並要求釋放鏈接。

三次握手過程

第一次握手：

創建鏈接。客戶端A發送鏈接請求報文段，SYN爲1，seq爲x，而後，客戶端A進入SYN_SEND狀態，等待服務器B的確認，服務端B由SYN=1知道，A要求創建聯機；

第二次握手：

服務端B收到請求後要確認聯機信息，向A發送ack number=(A的seq+1)，SYN=1，ACK=1，隨機產生seq的包，此時服務器進入SYN_RECV狀態；

第三次握手：

客戶端A收到後檢查ack number是否正確，即第一次發送的seq+1,以及位碼ACK是否爲1，若正確，客戶端A會再發送ack number=(服務端B的seq+1)，ack=1，主機B收到後確認seq值與ack=1則鏈接創建成功，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。

完成了三次握手，客戶端和服務器端就能夠開始傳送數據。以上就是TCP三次握手的整體介紹。

三次握手的一個實例：

第一次握手：客戶端A發送位碼syn＝1,隨機產生seq number=3626544836的數據包到服務端B，服務端B由SYN=1知道客戶端A要求創建聯機；

第二次握手：服務端B收到請求後要確認聯機信息，向客戶端A發送ack number=3626544837，yn=1，ack=1，隨機產生seq=1739326486的包；

第三次握手：客戶端A收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否爲1，若正確，客戶端A會再發送ack number=1739326487，ack=1，服務端B收到後確認seq=seq+1,ack=1則鏈接創建成功。

四次揮手過程

第一次揮手：

主機A（可使客戶端，也能夠是服務器端），設置seq和ack number，向主機2發送一個FIN報文段，此時，主機A進入FIN_WAIT_1狀態，這表示主機1沒有數據要發送給主機2了；

第二次揮手：

主機B收到了主機A發送的FIN報文段，向主機1回一個ACK報文段，ack number爲A的seq加1，主機A進入FIN_WAIT_2狀態，主機B告訴主機A，我「贊成」你的關閉請求；

第三次揮手：

主機B向主機A發送FIN報文段，請求關閉鏈接，同時主機2進入LAST_ACK狀態；

第四次揮手：

主機A收到主機B發送的FIN報文段，向主機B發送ACK報文段，而後主機A進入TIME_WAIT狀態，主機B收到主機A的ACK報文段之後，就關閉鏈接，此時，主機A等待2MSL後依然沒有收到回覆，則證實主機B已正常關閉，主機A也能夠關閉鏈接了。

至此，TCP的四次分手就這麼愉快的完成了。

3. 爲何須要三次握手

已失效的鏈接請求報文段」的產生在這樣一種狀況下：client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。因而就向client發出確認報文段，贊成創建鏈接。假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送ack包。（此時由於client沒有發起創建鏈接請求，因此client處於CLOSED狀態，接受到任何包都會丟棄）但server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據。這樣，server的不少資源就白白浪費掉了。採用「三次握手」的辦法能夠防止上述現象發生。例如剛纔那種狀況，client不會向server的確認發出確認。server因爲收不到確認，就知道client並無要求創建鏈接。

4. 爲何須要四次揮手

TCP協議是一種面向鏈接的、可靠的、基於字節流的運輸層通訊協議。TCP是全雙工模式，這就意味着，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經所有發送完畢了；可是，這個時候主機1仍是能夠接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，可是主機2仍是能夠發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，以後彼此就會愉快的中斷此次TCP鏈接。若是要正確的理解四次分手的原理，就須要瞭解四次分手過程當中的狀態變化。

參考：

OSI模型講解：https://www.zhihu.com/questio...

理解TCP的三次握手，四次揮手：https://www.jianshu.com/p/ce6...

三次握手，四次揮手：https://www.jianshu.com/p/092...

在windows經過端口號查詢網絡鏈接能夠看到TCP鏈接的各個狀態：