周一有位朋友咨詢個問題，問題本身不重要，但牽扯出的細節卻是非常有趣。

Linux 內核協議棧的 skb 設計非常高效和精巧，多個 skb 可以指向同一塊 data，這就是 clone，當 data 不止一個 skb 指示時，任何一個 skb 要修改 data 時，必須 unclone，其內部實現就是一個簡單的 cow(copy on write)，這就是 unclone，原理如下：

clone 和 unclone 的含義簡述如下：

• clone，復制一個新 skb，指向相同 data，dataref 遞增；
• unclone，復制一份新 data，原 dataref 遞減，skb 指向新 data；

值得注意的是 skb 的 clone 和 share 的區別：

• clone，針對 skb 的 data；
• share，針對 skb 結構體本身；

因此，kfree_skb 就非常清晰了：

• 先遞減 share 計數，自己是最后一個才繼續釋放 skb 的其它內容；
• 再遞減 data 的 dataref，自己是最后一個才徹底釋放 data 本身；

至于 skb_copy，pskb_copy，自然就不必說，理解 skb_clone，skb_unclone，kfree_skb 就夠了。
下面是 TCP 傳輸和重傳過程的 clone，unclone 序列：

TCP 傳輸和重傳時，紅黑樹(解釋理由)上的本體 skb 結構體始終未變，變的是 clone skb 結構體和 data：

• 每次傳輸或重傳時，均會 clone 一份本體 skb 實際傳輸，clone 過程本體 skb 的 data 不變，dataref 遞增；
• 每次重傳時，如果 dataref 大于 1，本體 skb 會 unclone，復制一份 data ，原 data 的 dataref 遞減，回到 1；

unclone 后留下的原 data 并未游離，因為還有上下文引用它們，可能驅動尚未發送完畢，等發完了一般會有中斷通知，那就留給 clone 它的上下文去 kfree 了。

以下是上面知識在處理朋友問題時的一個應用，該應用過程反過來也能加深上面知識的理解和內化。

問題是這樣的。理論上 TCP 重傳時要從重傳隊列 head 開始，可抓包卻發現先重傳了最后 fin，再次重傳時才重傳隊列更前面的 data。

初步猜測是 tlp，過年期間寫過一個關于 tlp 的，詳見 探秘 TCP TLP：從背景到實現。為幫朋友定位問題，我寫了下面的 pdrill 復現腳本，并打開 tlp：

   // 開啟 tlp//sysctl -q net.ipv4.tcp_early_retrans=4 net.ipv4.tcp_recovery=10 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0+0 bind(3, ..., ...) = 0+0 listen(3, 1) = 0+0 < S 0:0(0) win 32792 <mss 1460,sackOK, nop, nop, nop,wscale 7>+0 > S. 0:0(0) ack 1 <mss 1460,nop, nop, sackOK, nop, wscale 7>+0 < . 1:1(0) ack 1 win 257+0 accept(3, ..., ...) = 4+0 write(4, ..., 1360) = 1360+0 close(4) = 0+10 < . 1:1(0) ack 2821 win 257

通篇沒收到任何 ack， 1360 字節數據和 close 的 fin 均要被重傳，會先重傳最后的 fin，但理論上后續重傳 1360 字節時會將 fin 合并帶上，幾乎可以完全復現場景：

然而抓包卻是這樣：

并沒有合并捎帶 fin。

不合并就不合并了，不是什么大事，本身 tcp collapse 觸發條件就不止一個。但作為 pdrill 本地測試，最基本的場景，立場應該是想讓它 collapse 它就得 collapse，一定是哪里出了問題才導致 1360 字節的報文沒有 collapse fin。

tcp 重傳 collapse 的條件是沒有其它上下文引用該 skb 的 data，即 shinfo->dataref == 1，以下是詳細觀測 skb shinfo->dataref 的腳本：

bpftrace -e '
//kprobe:__tcp_transmit_skb  // 尚未 clone，dataref = 1
//kprobe:__ip_queue_xmit     // 已經 clone，dataref = 2
//kprobe:__dev_queue_xmit
//kprobe:dev_hard_start_xmit
//kprobe:dev_queue_xmit_nit // PACKET 套接字等抓包程序會再次 clone，dataref = 3，處理完成后 dataref = 2
//kprobe:網卡 xmit 回調      // 傳輸完畢由驅動負載 kfree_skb，dataref = 1
{$skb = (struct sk_buff *)arg0;$dev = (struct net_device *)($skb->dev);if (strncmp($dev->name, "tun0", 4) == 0) {$shinfo = (struct skb_shared_info *)($skb->head + $skb->end);$dataref = $shinfo->dataref.counter;printf("tun0 skb=%p dataref=%d\n", $skb, $dataref & 0xffff);}
}
'

結果是到了 tun_net_xmit 時，dataref = 3，但在 dev_hard_start_xmit 時 dataref 還是 2，這中間只有 PACKET 套接字，類似抓包路徑了。而抓包需要 copy data，肯定是需要 clone skb 的。還果然是這個原因：

root@vbox:~# strace -e trace=socket packetdrill ./tlp-with-fin.pkt
...
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6624, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6626, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) = 6

也可在 packetdrill 運行期間通過 procfs 確認：

root@vbox:~# cat /proc/net/packet
sk               RefCnt Type Proto  Iface R Rmem   User   Inode
00000000dafae456 3      2    0003   0     1 0      0      42872

但即使減少了 PACKET 套接字的 1 個 ref，還有 1 個 ref 直到 tun_net_xmit 也沒釋放，原因在于 packetdrill 并未 read tun0fd。

為了避免這種本地測試工具不處理 read 造成的額外混亂，我覺得 tun 驅動應該增加一個 “低效率” 模式，即 skb 進入 tun 驅動的 tun_net_xmit 回調時直接轉交掉，多一次復制，少一份混亂：

static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
{struct tun_struct *tun = netdev_priv(dev);enum skb_drop_reason drop_reason;int txq = skb->queue_mapping;struct netdev_queue *queue;struct tun_file *tfile;int len = skb->len;struct sk_buff *nskb = skb;rcu_read_lock();if (tun-> & 低效) {skb = skb_copy(nskb, GFP_ATOMIC);kfree_skb(nskb);// 這里順帶幫 PACKET 套接字解除一個 ref，實際中不需要atomic_dec(&skb_shinfo(nskb)->dataref);}tfile = rcu_dereference(tun->tfiles[txq]);

再次運行，結果就符合預期了：

如果 skb 發到真實網卡，當網卡中斷通知發送完成，該 skb 即可得到釋放，但本地環回的 skb 生命周期可是要長得多，比如 loopback_xmit，直接用 tx 路徑的 skb 調用 netif_rx 了。

不出本機協議棧的數據包環回處理最好在 ndo_start_xmit 中都轉交 copy 一下 skb，畢竟本地處理不要求性能(要求高性能的抓包也不用 skb)，這樣可避免循環依賴而傷害到協議棧的固有行為，比如我用 pdrill 幾乎無法驗證 collapse 機制。

多年以前我曾因為 tun 網卡沒有調用 sk_mem_uncharge 導致了通過 tun 網卡的 socket 異常行為，但忘記題目了，文章找不到了。

不管這世界多么無知和操蛋，只要給我一本歷史書，給我一個 TCP 疑難問題，或帶我到一座可以攀登的山腳下，我就馬上元氣爆滿！

浙江溫州皮鞋濕，下雨進水不會胖。