再看网络协议

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)