TCP/IP的底層隊列是如何實現(xiàn)的？-創(chuàng)新互聯(lián)

自從上次學習了TCP/IP的擁塞控制算法后，我越發(fā)想要更加深入的了解TCP/IP的一些底層原理，搜索了很多網(wǎng)絡(luò)上的資料，收益頗多。今天就總結(jié)一下。

我們提供的服務(wù)有：成都網(wǎng)站制作、成都網(wǎng)站設(shè)計、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、瀘溪ssl等。為1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學管理、有技術(shù)的瀘溪網(wǎng)站制作公司

我自己比較了解Java語言，對Java網(wǎng)絡(luò)編程的理解就止于Netty框架的使用。Netty的源碼貢獻者Norman Maurer對于Netty網(wǎng)絡(luò)開發(fā)有過一句建議，"Never block the event loop, reduce context-swtiching"。也就是盡量不要阻塞IO線程，也盡量減少線程切換。我們今天只關(guān)注前半句。

為什么不能阻塞讀取網(wǎng)絡(luò)信息的IO線程呢？這里就要從經(jīng)典的網(wǎng)絡(luò)C10K開始理解，服務(wù)器如何支持并發(fā)1萬請求。C10K的根源在于網(wǎng)絡(luò)的IO模型。Linux 中網(wǎng)絡(luò)處理都用同步阻塞的方式，也就是每個請求都分配一個進程或者線程，那么要支持1萬并發(fā)，難道就要使用1萬個線程處理請求嘛？這1萬個線程的調(diào)度、上下文切換乃至它們占用的內(nèi)存，都會成為瓶頸。解決C10K的通用辦法就是使用I/O 多路復用，Netty就是這樣。

Netty有負責服務(wù)端監(jiān)聽建立連接的線程組(mainReactor)和負責連接讀寫操作的IO線程組(subReactor)，還可以有專門處理業(yè)務(wù)邏輯的Worker線程組(ThreadPool)。

三者相互獨立，這樣有很多好處。一是有專門的線程組負責監(jiān)聽和處理網(wǎng)絡(luò)連接的建立，可以防止TCP/IP的半連接隊列(sync)和全連接隊列(acceptable)被占滿。二是IO線程組和Worker線程分開，雙方并行處理網(wǎng)絡(luò)I/O和業(yè)務(wù)邏輯，可以避免IO線程被阻塞，防止TCP/IP的接收報文的隊列被占滿。當然，如果業(yè)務(wù)邏輯較少，也就是IO 密集型的輕計算業(yè)務(wù)，可以將業(yè)務(wù)邏輯放在IO線程中處理，避免線程切換，這也就是Norman Maurer話的后半部分。

TCP/IP怎么就這么多隊列?。拷裉煳覀兙蛠砑毧匆幌耇CP/IP的幾個隊列,包括建立連接時的半連接隊列(sync)，全連接隊列(accept)和接收報文時的receive、outoforder、prequeue以及backlog隊列。

建立連接時的隊列

如上圖所示，這里有兩個隊列：syns queue(半連接隊列)和accept queue(全連接隊列)。三次握手中，服務(wù)端接收到客戶端的SYN報文后，把相關(guān)信息放到半連接隊列中，同時回復SYN+ACK給客戶端。?第三步的時候服務(wù)端收到客戶端的ACK，如果這時全連接隊列沒滿，那么從半連接隊列拿出相關(guān)信息放入到全連接隊列中，否則按tcp_abort_on_overflow的值來執(zhí)行相關(guān)操作，直接拋棄或者過一段時間在重試。

接收報文時的隊列

相比于建立連接，TCP在接收報文時的處理邏輯更為復雜，相關(guān)的隊列和涉及的配置參數(shù)更多。

應用程序接收TCP報文和程序所在服務(wù)器系統(tǒng)接收網(wǎng)絡(luò)里發(fā)來的TCP報文是兩個獨立流程。二者都會操控socket實例，但是會通過鎖競爭來決定某一時刻由誰來操控，由此產(chǎn)生很多不同的場景。例如，應用程序正在接收報文時，操作系統(tǒng)通過網(wǎng)卡又接收到報文，這時該如何處理？若應用程序沒有調(diào)用read或者recv讀取報文時，操作系統(tǒng)收到報文又會如何處理？

我們接下來就以三張圖為主，介紹TCP接收報文時的三種場景，并在其中介紹四個接收相關(guān)的隊列。

接收報文場景一

上圖是TCP接收報文場景一的示意圖。操作系統(tǒng)首先接收報文，存儲到socket的receive隊列，然后用戶進程再調(diào)用recv進行讀取。

1) 當網(wǎng)卡接收報文并且判斷為TCP協(xié)議時，經(jīng)過層層調(diào)用，最終會調(diào)用到內(nèi)核的tcp_v4_rcv方法。由于當前TCP要接收的下一個報文正是S1，所以tcp_v4_rcv函數(shù)將其直接加入到receive隊列中。receive隊列是將已經(jīng)接收到的TCP報文，去除了TCP頭部、排好序放入的、用戶進程可以直接按序讀取的隊列。由于socket不在用戶進程上下文中（也就是沒有用戶進程在讀socket），并且我們需要S1序號的報文，而恰好收到了S1報文，因此，它進入了receive隊列。

2) 接收到S3報文，由于TCP要接收的下一個報文序號是S2，所以加入到out_of_order隊列，所有亂序的報文會放在這里。

3) 接著，收到了TCP期望的S2報文，直接進入recevie隊列。由于此時out_of_order隊列不為空，需要檢查一下。

4) 每次向receive隊列插入報文時都會檢查out_of_order隊列，由于接收到S2報文后，期望的的序號為S3，所以out_of_order隊列中的S3報文會被移到receive隊列。

5) 用戶進程開始讀取socket，先在進程中分配一塊內(nèi)存，然后調(diào)用read或者recv方法。socket有一系列的具有默認值的配置屬性，比如socket默認是阻塞式的，它的SO_RCVLOWAT屬性值默認為1。當然，recv這樣的方法還會接收一個flag參數(shù)，它可以設(shè)置為MSG_WAITALL、MSG_PEEK、MSG_TRUNK等等，這里我們假定為最常用的0。進程調(diào)用了recv方法。

6) 調(diào)用tcp_recvmsg方法

7)tcp_recvmsg方法會首先鎖住socket。socket是可以被多線程使用的，而且操作系統(tǒng)也會使用，所以必須處理并發(fā)問題。要操控socket，就先獲取鎖。

8) 此時，receive隊列已經(jīng)有3個報文了，將第一個報文拷貝到用戶態(tài)內(nèi)存中，由于第五步中socket的參數(shù)并沒有帶MSG_PEEK，所以將第一個報文從隊列中移除，從內(nèi)核態(tài)釋放掉。反之，MSG_PEEK標志位會導致receive隊列不會刪除報文。所以，MSG_PEEK主要用于多進程讀取同一套接字的情形。

9) 拷貝第二個報文，當然，執(zhí)行拷貝前都會檢查用戶態(tài)內(nèi)存的剩余空間是否足以放下當前這個報文，不夠時會直接返回已經(jīng)拷貝的字節(jié)數(shù)。

10) 拷貝第三個報文。

11)receive隊列已經(jīng)為空，此時會檢查SO_RCVLOWAT這個最小閾值。如果已經(jīng)拷貝字節(jié)數(shù)小于它，進程會休眠，等待更多報文。默認的SO_RCVLOWAT值為1，也就是讀取到報文就可以返回。

12) 檢查backlog隊列，backlog隊列是用戶進程正在拷貝數(shù)據(jù)時，網(wǎng)卡收到的報文會進這個隊列。如果此時backlog隊列有數(shù)據(jù)，就順帶處理下。backlog隊列是沒有數(shù)據(jù)的，因此釋放鎖，準備返回用戶態(tài)。

13) 用戶進程代碼開始執(zhí)行，此時recv等方法返回的就是從內(nèi)核拷貝的字節(jié)數(shù)。

接收報文場景二

第二張圖給出了第二個場景，這里涉及了prequeue隊列。用戶進程調(diào)用recv方法時，socket隊列中沒有任何報文，而socket是阻塞的，所以進程睡眠了。然后操作系統(tǒng)收到了報文，此時prequeue隊列開始產(chǎn)生作用。該場景中，tcp_low_latency為默認的0，套接字socket的SO_RCVLOWAT是默認的1，仍然是阻塞socket，如下圖。

其中1，2，3步驟的處理和之前一樣。我們直接從第四步開始。

4) 由于此時receive,prequeue和backlog隊列都為空，所以沒有拷貝一個字節(jié)到用戶內(nèi)存中。而socket的配置要求至少拷貝SO_RCVLOWAT也就是1字節(jié)的報文，因此進入阻塞式套接字的等待流程。最長等待時間為SO_RCVTIMEO指定的時間。socket在進入等待前會釋放socket鎖，會使第五步中，新來的報文不再只能進入backlog隊列。

5) 接到S1報文，將其加入prequeue隊列中。

6) 插入到prequeue隊列后，會喚醒在socket上休眠的進程。

7) 用戶進程被喚醒后，重新獲取socket鎖，此后再接收到的報文只能進入backlog隊列。

8) 進程先檢查receive隊列，當然仍然是空的；再去檢查prequeue隊列，發(fā)現(xiàn)有報文S1，正好是正在等待序號的報文，于是直接從prequeue隊列中拷貝到用戶內(nèi)存，再釋放內(nèi)核中的這個報文。

9) 目前已經(jīng)拷貝了一個字節(jié)的報文到用戶內(nèi)存，檢查這個長度是否超過了最低閾值，也就是len和SO_RCVLOWAT的最小值。

10) 由于SO_RCVLOWAT使用了默認值1，拷貝字節(jié)數(shù)大于最低閾值，準備返回用戶態(tài)，順便會查看一下backlog隊列中是否有數(shù)據(jù)，此時沒有，所以準備放回，釋放socket鎖。

11) 返回用戶已經(jīng)拷貝的字節(jié)數(shù)。

接收報文場景三

在第三個場景中，系統(tǒng)參數(shù)tcp_low_latency為1，socket上設(shè)置了SO_RCVLOWAT屬性值。服務(wù)器先收到報文S1，但是其長度小于SO_RCVLOWAT。用戶進程調(diào)用recv方法讀取，雖然讀取到了一部分，但是沒有到達最小閾值，所以進程睡眠了。與此同時，在睡眠前接收的亂序的報文S3直接進入backlog隊列。然后，報文S2到達，由于沒有使用prequeue隊列（因為設(shè)置了tcplowlatency），而它起始序號正是下一個待拷貝的值，所以直接拷貝到用戶內(nèi)存中，總共拷貝字節(jié)數(shù)已滿足SO_RCVLOWAT的要求！最后在返回用戶前把backlog隊列中S3報文也拷貝給用戶。

1) 接收到報文S1，正是準備接收的報文序號，因此，將它直接加入到有序的receive隊列中。

2) 將系統(tǒng)屬性tcp_low_latency設(shè)置為1，表明服務(wù)器希望程序能夠及時的接收到TCP報文。用戶調(diào)用的recv接收阻塞socket上的報文，該socket的SO_RCVLOWAT值大于第一個報文的大小，并且用戶分配了足夠大的長度為len的內(nèi)存。

3) 調(diào)用tcp_recvmsg方法來完成接收工作，先鎖住socket。

4) 準備處理內(nèi)核各個接收隊列中的報文。

5)receive隊列中有報文可以直接拷貝，其大小小于len，直接拷貝到用戶內(nèi)存。

6) 在進行第五步的同時，內(nèi)核又接收到S3報文，此時socket被鎖，報文直接進入backlog隊列。這個報文并不是有序的。

7) 在第五步時，拷貝報文S1到用戶內(nèi)存，它的大小小于SO_RCVLOWAT的值。由于socket是阻塞型，所以用戶進程進入睡眠狀態(tài)。進入睡眠前，會先處理backlog隊列的報文。因為S3報文是失序的，所以進入out_of_order隊列。用戶進程進入休眠狀態(tài)前都會先處理一下backlog隊列。

8) 進程休眠，直到超時或者receive隊列不為空。

9) 內(nèi)核接收到報文S2。注意，此時由于打開了tcp_low_latency標志位，所以報文是不會進入prequeue隊列等待進程處理。

10) 由于報文S2正是要接收的報文，同時，一個用戶進程在休眠等待該報文，所以直接將報文S2拷貝到用戶內(nèi)存。

11) 每處理完一個有序報文后，無論是拷貝到receive隊列還是直接復制到用戶內(nèi)存，都會檢查out_of_order隊列，看看是否有報文可以處理。報文S3拷貝到用戶內(nèi)存，然后喚醒用戶進程。

12) 喚醒用戶進程。

13) 此時會檢查已拷貝的字節(jié)數(shù)是否大于SO_RCVLOWAT，以及backlog隊列是否為空。兩者皆滿足，準備返回。

總結(jié)一下四個隊列的作用。

• receive隊列是真正的接收隊列，操作系統(tǒng)收到的TCP數(shù)據(jù)包經(jīng)過檢查和處理后，就會保存到這個隊列中。

• backlog是“備用隊列”。當socket處于用戶進程的上下文時（即用戶正在對socket進行系統(tǒng)調(diào)用，如recv），操作系統(tǒng)收到數(shù)據(jù)包時會將數(shù)據(jù)包保存到?backlog隊列中，然后直接返回。

• prequeue是“預存隊列”。當socket沒有正在被用戶進程使用時，也就是用戶進程調(diào)用了read或者recv系統(tǒng)調(diào)用，但是進入了睡眠狀態(tài)時，操作系統(tǒng)直接將收到的報文保存在?prequeue中，然后返回。

• out_of_order是“亂序隊列”。隊列存儲的是亂序的報文，操作系統(tǒng)收到的報文并不是TCP準備接收的下一個序號的報文，則放入?out_of_order隊列，等待后續(xù)處理。

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務(wù)器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機房獨有T級流量清洗系統(tǒng)配攻擊溯源，準確進行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動現(xiàn)已開啟，新人活動云服務(wù)器買多久送多久。

網(wǎng)站題目：TCP/IP的底層隊列是如何實現(xiàn)的？-創(chuàng)新互聯(lián)
轉(zhuǎn)載來源：http://bm7419.com/article48/diccep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計公司、網(wǎng)站內(nèi)鏈、用戶體驗、微信小程序、定制開發(fā)、移動網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)