1. 程式人生 > >TCP/IP協議的學習筆記

TCP/IP協議的學習筆記

不同 傳輸層 現象 rda .cn 協議 過程 學習 情況

1.OSI和TCP/IP的協議體系結構

  OSI是開放系統互連參考模型,它的七層體系結構概念清楚,理論也比較完整,但它既復雜又不實用。而TCP/IP是一個四層的體系結構,它包含應用層、傳輸層、網際層和網絡接口層。TCP/IP體系結構雖然 簡單,但它卻得到了廣泛的應用。OSI失敗的原因歸納為:

(1)OSI的專家缺乏實際經驗,他們在完成OSI標準時沒有商業驅動力;

(2)OSI的協議實現過分復雜,而且運行效率很低;

(3)OSI標準的制定周期太長,因而使得按OSI標準生產的設備無法及時進入市場;

(4)OSI的層次劃分不太合理,有些功能多個層次中重復使用

技術分享圖片

2.TCP:傳輸控制協議,一個位於傳輸層的協議

  傳輸層的協議主要是UDP和TCP,UDP協議比較簡單,所以沒有過多的區了解,僅知道UDP是面向無連接的,不可靠傳輸,傳輸數據小,但是速度快。TCP協議是面向連接的,可靠穩定。TCP在傳送數據之前,會有三次握手建立連接;傳遞數據時,有確認、窗口、重傳、擁塞控制機制;在傳輸數據後,還會斷開連接,來釋放系統資源。但是正是因為這樣也存在很多缺點,效率低,占用系統資源高,也容易被人攻擊。UDP、TCP的主要區別,參考 https://www.cnblogs.com/xiaomayizoe/p/5258754.html

(1)TCP報文結構分析

技術分享圖片

(2)TCP三次握手建立連接

1)第一次握手:建立連接時,客戶端

A發送SYN包(SYN=j)到服務器B,並進入SYN_SEND狀態,等待服務器B確認。

2)第二次握手:服務器B收到SYN包,必須確認客戶ASYNACK=j+1),同時自己也發送一個SYN包(SYN=k),即SYN+ACK包,此時服務器B進入SYN_RECV狀態。

3)第三次握手:客戶端A收到服務器BSYNACK包,向服務器B發送確認包ACKACK=k+1),此包發送完畢,客戶端A和服務器B進入ESTABLISHED狀態,完成三次握手。

完成三次握手,客戶端與服務器開始傳送數據。

技術分享圖片

(3)TCP四次揮手斷開連接

1)客戶端A發送一個FIN,用來關閉客戶A到服務器B的數據傳送。

2)服務器B收到這個FIN,它發回一個ACK,確認序號為收到的序號加1。和SYN一樣,一個FIN將占用一個序號。

3)服務器B關閉與客戶端A的連接,發送一個FIN給客戶端A

4)客戶端A發回ACK報文確認,並將確認序號設置為收到序號加1

技術分享圖片

(4)linux查看TCP的狀態命令:

netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}‘ 

(5)TCP協議的三種狀態

SYN_RECV

服務端收到建立連接的SYN沒有收到ACK包的時候處在SYN_RECV狀態

CLOSE_WAIT

發起TCP連接關閉的一方稱為client,被動關閉的一方稱為server。被動關閉的server收到FIN後,但未發出ACKTCP狀態是CLOSE_WAIT。出現這種狀況一般都是由於server端代碼的問題,如果你的服務器上出現大量CLOSE_WAIT,應該要考慮檢查代碼。

TIME_WAIT

根據TCP協議定義的3次握手斷開連接規定,發起socket主動關閉的一方 socket將進入TIME_WAIT狀態。TIME_WAIT狀態將持續2MSL(Max Segment Lifetime),Windows下默認為4分鐘,即240秒。TIME_WAIT狀態下的socket不能被回收使用. 具體現象是對於一個處理大量短連接的服務器,如果是由服務器主動關閉客戶端的連接,將導致服務器端存在大量的處於TIME_WAIT狀態的socket, 甚至比處於Established狀態下的socket多的多,嚴重影響服務器的處理能力,甚至耗盡可用的socket,停止服務。

描述過程:
Client調用close()函數,給Server發送FIN,請求關閉連接;Server收到FIN之後給Client返回確認ACK,同時關閉讀通道(不清楚就去看一下shutdownclose的差別),也就是說現在不能再從這個連接上讀取東西,現在read返回0。此時ServerTCP狀態轉化為CLOSE_WAIT狀態。
Client收到對自己的FIN確認後,關閉 寫通道,不再向連接中寫入任何數據。
接下來Server調用close()來關閉連接,給Client發送FINClient收到後給Server回復ACK確認,同時Client關閉讀通道,進入TIME_WAIT狀態。
Server接收到Client對自己的FIN的確認ACK,關閉寫通道,TCP連接轉化為CLOSED,也就是關閉連接。
ClientTIME_WAIT狀態下要等待最大數據段生存期的兩倍,然後才進入CLOSED狀態,TCP協議關閉連接過程徹底結束。

以上就是TCP協議關閉連接的過程,現在說一下TIME_WAIT狀態。
從上面可以看到,主動發起關閉連接的操作的一方將達到TIME_WAIT狀態,而且這個狀態要保持Maximum Segment Lifetime的兩倍時間。為什麽要這樣做而不是直接進入CLOSED狀態?

原因有二:
一、保證TCP協議的全雙工連接能夠可靠關閉
二、保證這次連接的重復數據段從網絡中消失

先說第一點,如果Client直接CLOSED了,那麽由於IP協議的不可靠性或者是其它網絡原因,導致Server沒有收到Client最後回復的ACK。那麽Server就會在超時之後繼續發送FIN,此時由於Client已經CLOSED了,就找不到與重發的FIN對應的連接,最後Server就會收到RST而不是ACKServer就會以為是連接錯誤把問題報告給高層。這樣的情況雖然不會造成數據丟失,但是卻導致TCP協議不符合可靠連接的要求。所以,Client不是直接進入CLOSED,而是要保持TIME_WAIT,當再次收到FIN的時候,能夠保證對方收到ACK,最後正確的關閉連接。

再說第二點,如果Client直接CLOSED,然後又再向Server發起一個新連接,我們不能保證這個新連接與剛關閉的連接的端口號是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發生什麽問題,但是還是有特殊情況出現:假設新連接和已經關閉的老連接端口號是一樣的,如果前一次連接的某些數據仍然滯留在網絡中,這些延遲數據在建立新連接之後才到達Server,由於新連接和老連接的端口號是一樣的,又因為TCP協議判斷不同連接的依據是socket pair,於是,TCP協議就認為那個延遲的數據是屬於新連接的,這樣就和真正的新連接的數據包發生混淆了。所以TCP連接還要在TIME_WAIT狀態等待2MSL,這樣可以保證本次連接的所有數據都從網絡中消失。

參考地址:https://blog.csdn.net/sunyongye/article/details/79007439

TCP/IP協議的學習筆記