Linux TCP數據包接收處理 --- 轉

在接收流程一節中可以看到數據包在讀取到用戶空間前，都要經過tcp_v4_do_rcv處理，從而在receive queue中排隊。

在該函數中，我們只分析當連接已經建立后的數據包處理流程，也即tcp_rcv_established函數。

 

tcp_rcv_established函數的工作原理是把數據包的處理分為2類：fast path和slow path，其含義顯而易見。這樣分類

的目的當然是加快數據包的處理，因為在正常情況下，數據包是按順序到達的，網絡狀況也是穩定的，這時可以按照fast path

直接把數據包存放到receive queue了。而在其他的情況下則需要走slow path流程了。

 

在協議棧中，是用頭部預測來實現的，每個tcp sock有個pred_flags成員，它就是判別的依據。

 

可以看出頭部預測依賴的是頭部長度字段和通告窗口。也就是說標志位除了ACK和PSH外，如果其他的存在的話，就不能用

fast path處理，其揭示的含義如下：

1 Either the data transaction is taking place in only one direction (which means that we are the receiver

and not transmitting any data) or in the case where we are sending out data also, the window advertised

 from the other end is constant. The latter means that we have not transmitted any data from our side for

quite some time but are receiving data from the other end. The receive window advertised by the other end is constant.

 

2. Other than PSH|ACK flags in the TCP header, no other flag is set (ACK is set for each TCP segment). 

This means that if any other flag is set such as URG, FIN, SYN, ECN, RST, and CWR, we
know that something important is there to be attended and we need to move into the SLOW path.

 

3. The header length has unchanged. If the TCP header length remains unchanged,
we have not added/reduced any TCP option and we can safely assume that
there is nothing important to be attended, if the above two conditions are TRUE.

 

fast path工作的條件

 

 

1 沒有亂序數據包

2 接收窗口不為0

3 還有接收緩存空間

4 沒有緊急數據

 

反之，則進入slow path處理；另外當連接新建立時處于slow path。

 

從fast path進入slow path的觸發條件（進入slow path 后pred_flags清除為0）：

1 在tcp_data_queue中接收到亂序數據包

2 在tcp_prune_queue中用完緩存并且開始丟棄數據包

3 在tcp_urgent_check中遇到緊急指針

4 在tcp_select_window中發送的通告窗口下降到0.

 

從slow_path進入fast_path的觸發條件：

1 When we have read past an urgent byte in tcp_recvmsg() . Wehave gotten an urgent byte and we remain

  in the slow path mode until we receive the urgent byte because it is handled in the slow path in
  tcp_rcv_established() .

2 當在tcp_data_queue中亂序隊列由于gap被填充而處理完畢時，運行tcp_fast_path_check。

3 tcp_ack_update_window()中更新了通告窗口。

 

fast path處理流程

A 判斷能否進入fast path

 

TCP_HP_BITS的作用就是排除flag中的PSH標志位。只有在頭部預測滿足并且數據包以正確的順序（該數據包的第一個序號就是下個要接收

的序號）到達時才進入fast path。

 

該代碼段是依據時戳選項來檢查PAWS（Protect Against Wrapped Sequence numbers）。

 

如果發送來的僅是一個TCP頭的話（沒有捎帶數據或者接收端檢測到有亂序數據這些情況時都會發送一個純粹的ACK包）

 

主要的工作如下：

1 保存對方的最近時戳 tcp_store_ts_recent。通過前面的if判斷可以看出tcp總是回顯2次時戳回顯直接最先到達的數據包的時戳，

  rcv_wup只在發送數據（這時回顯時戳）時重置為rcv_nxt，所以接收到前一次回顯后第一個數據包后，rcv_nxt增加了，但是

  rcv_wup沒有更新，所以后面的數據包處理時不會調用該函數來保存時戳。

2 ACK處理。這個函數非常復雜，包含了擁塞控制機制，確認處理等等。

3 檢查是否有數據待發送 tcp_data_snd_check。

 

如果該數據包中包含了數據的話

 

 

tcp_event_data_recv函數

 

rcv_ssthresh是當前的接收窗口大小的一個閥值，其初始值就置為rcv_wnd。它跟rcv_wnd配合工作，

當本地socket收到數據報，并滿足一定條件時，增長rcv_ssthresh的值，在下一次發送數據報組建TCP首部時，

需要通告對方當前的接收窗口大小，這時需要更新rcv_wnd，此時rcv_wnd的取值不能超過rcv_ssthresh的值。

兩者配合，達到一個滑動窗口大小緩慢增長的效果。

__tcp_ack_snd_check用來判斷ACK的發送方式

 

注釋很清楚，無需解釋。

 

 

這里有個疑問，就是當ucopy應用讀到需要讀取到的數據包后，也即在一次處理中

 

 

的第二個條件的等號為真 len - tcp_header_len == tp->ucopy.len，然后執行流程到后面eaten為1，所以函數以釋放skb結束，沒有

調用sk_data_ready函數。假設這個處理調用流程如下：

tcp_recvmsg-> sk_wait_data  -> sk_wait_event -> release_sock -> __release_sock-> sk_backlog_rcv-> tcp_rcv_established

那么即使此時用戶得到了所需的數據，但是在tcp_rcv_established返回前沒有提示數據已得到，

 

 

但是在回到sk_wait_event后，由于__condition為 !skb_queue_empty(&sk->sk_receive_queue)，所以還是會調用schedule_timeout

來等待。這點顯然是浪費時間，所以這個condition應該考慮下這個數據已經讀滿的情況，而不能光靠觀察receive queue來判斷是否等待。

 

接下來分析slow path

 

 

先看看tcp_validate_incoming函數，在slow path處理前檢查輸入數據包的合法性。

 

 

第一步：檢查PAWS tcp_paws_discard

 

 

 PAWS丟棄數據包要滿足以下條件

1 The difference between the timestamp value obtained in the current segmentand last seen timestamp on

the incoming TCP segment should be more than TCP_PAWS_WINDOW (= 1), which means that if the segment that was
transmitted 1 clock tick before the segment that reached here earlier TCP seq should be acceptable.

It may be because of reordering of the segments that the latter reached earlier.

2 the 24 days have not elapsed since last time timestamp was stored,

3 tcp_disordered_ack返回0.

 

以下轉載自CU論壇http://linux.chinaunix.net/bbs/viewthread.php?tid=1130308

 

---

 

 

 

在實際進行PAWS預防時，Linux是通過如下代碼調用來完成的
tcp_rcv_established
    |
    |-->tcp_paws_discard
          |
          |-->tcp_disordered_ack
其中關鍵是local方通過tcp_disordered_ack函數對一個剛收到的數據分段進行判斷，下面我們對該函數的判斷邏輯進行下總結：
大前提：該收到分段的TS值表明有回繞現象發生
a）若該分段不是一個純ACK，則丟棄。因為顯然這個分段所攜帶的數據是一個老數據了，不是local方目前希望接收的（參見PAWS的處理依據一節）
b）若該分段不是local所希望接收的，則丟棄。這個原因很顯然
c）若該分段是一個純ACK，但該ACK并不是一個重復ACK（由local方后續數據正確到達所引發的），則丟棄。因為顯然該ACK是一個老的ACK，并不是由于為了加快local方重發而在每收到一個丟失分段后的分段而發出的ACK。
d）若該分段是一個ACK，且為重復ACK，并且該ACK的TS值超過了local方那個丟失分段后的重發rto，則丟棄。因為顯然此時local方已經重發了那個導致此重復ACK產生的分段，因此再收到此重復ACK就可以直接丟棄。
e）若該分段是一個ACK，且為重復ACK，但是沒有超過一個rto的時間，則不能丟棄，因為這正代表peer方收到了local方發出的丟失分段后的分段，local方要對此ACK進行處理（例如立刻重傳）

這里有一個重要概念需要理解，即在出現TS問題后，純ACK和帶ACK的數據分段二者是顯著不同的，對于后者，可以立刻丟棄掉，因為從一個窗口的某個seq到下一個窗口的同一個seq過程中，一定有窗口變化曾經發生過，從而TS記錄值ts_recent也一定更新過，此時一定可以通過PAWS進行丟棄處理。但是對于前者，一個純ACK，就不能簡單丟棄了，因為有這樣一個現象是合理的，即假定local方的接收緩存很大，并且peer方在發送時很快就回繞了，于是在local方的某個分段丟失后，peer方需要在每收到的后續分段時發送重復ACK，而此時該重發ACK的ack_seq就是這個丟失分段的序號，而該重發ACK的seq已經是回繞后的重復序號了，盡管此時到底是回繞后的那個重復ACK還是之前的那個同樣序號seq的重復ACK，對于local方來都需要處理（立刻啟動重發動作），而不能簡單丟棄掉。

 

---

 

 第2步 檢查數據包的序號是否正確，該判斷失敗后調用tcp_send_dupack發送一個duplicate acknowledge（未設置RST標志位時）。

 

由rcv_wup的更新時機（發送ACK時的tcp_select_window）可知位于序號rcv_wup前面的數據都已確認，所以待檢查數據包的結束序號至少

要大于該值；同時開始序號要落在接收窗口內。

 

第3步 如果設置了RST，則調用tcp_reset處理

第4步 更新ts_recent，

第5步 檢查SYN，因為重發的SYN和原來的SYN之間不會發送數據，所以這2個SYN的序號是相同的，如果不滿足則reset連接。

 

接下來重點分析tcp_data_queue函數，這里就是對數據包的處理了。

 

 

 

 

如果該數據包剛好是下一個要接收的數據，則可以直接copy到用戶空間（如果存在且可用），否則排隊到receive queue

 

下面看看函數tcp_ofo_queue，也即out-of-order queue的處理

 

這里DSACK的處理中為什么即使dsack比end_seq大，還是用dsack作為右邊界呢？

 

 

 

 

@import url(http://m.shnenglu.com/cutesoft_client/cuteeditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

posted on 2013-02-18 14:23 大龍 閱讀(6951) 評論(0)  編輯 收藏 引用