struct sock

sock->sk_receive_queue

協議棧負責把數據放到sk_receive_queue中，進程通過recvmsg_from去從協議棧中讀數據，

在sk_receive_queue中的都是一個完整的從用戶發過來的ｓｋｂ數據包了，裏面有完整的ｔｃｐ的控制信息位於：tcp_skb_cb中，其中有個關鍵的信息就是序列號了，這tcp_skb_cb->seq

這個ｓｋｂ中內容在ＩＰ層和ＭＡＣ層是如何合並的，還有在skb_receive_queue中的數據包都是有順序的嗎？

以下面一條log為例：測試程序codebox:find_ok_skb.stp

解釋下，其中紅色部分標誌的是一個socket，其中藍色部分標誌的是skb的地址，offset為啥是0一下子就很清楚了，是因為在tcp_recvmsg函數中，對一個skb的讀可能是粉塵過了好多次：詳細可以看下面的前四條記錄，這個skb中有102個字節，這102個字節是通過4次copy讀出來的，每次分別讀了5\91\5\1個字節讀出來，其中每一次的offset分別是0/5/96/101，正好對應，這個也從側面表明了到tcp_recvmsg中讀出來sk_receive_queu隊列中的ｓｋｂ都是排好順序了這個時候讀出來的數據都是連續的數據。

Socket Thread ffff8800a5b87800:2383359782 len:1
skb:ffff8800a8b6dd00 curSeq: 2383359782 offset(0) len(102) size(5)


Socket Thread ffff8800a5b87800:2383359787 len:1
skb:ffff8800a8b6dd00 curSeq: 2383359782 offset(5) len(102) size(91)


Socket Thread ffff8800a5b87800:2383359878 len:1
skb:ffff8800a8b6dd00 curSeq: 2383359782 offset(96) len(102) size(5)


Socket Thread ffff8800a5b87800
 
:2383359883 len:1
skb:ffff8800a8b6dd00 curSeq: 2383359782 offset(101) len(102) size(1)


Socket Thread ffff8800a5b87800:2383359884 len:1
skb:ffff8800a8b6cb00 curSeq: 2383359884 offset(0) len(45) size(5)


Socket Thread ffff8800a5b87800:2383359889 len:1
skb:ffff8800a8b6cb00 curSeq: 2383359884 offset(5) len(45) size(40)


Socket Thread ffff8800a5b87800:2383359929 len:1
skb:ffff8800a8b6d200
 
 curSeq: 2383359929 offset(0) len(421) size(5)

再看網絡協議