上一篇《利用eBPF實現(xiàn)socket level重定向》，二哥從整體上介紹了 eBPF 的一個應(yīng)用場景 socket level redirect：如果一臺機器上有兩個進程需要通過 loopback 設(shè)備相互收發(fā)數(shù)據(jù)，我們可以利用 ebpf 在發(fā)送進程端將需要發(fā)送的數(shù)據(jù)跳過本機的底層 TCP/IP 協(xié)議棧，直接交給目的進程的 socket，從而縮短數(shù)據(jù)在內(nèi)核的處理路徑和時間。

這個流程如圖 1 所示。本篇我們來詳細看下圖 1 右側(cè)在內(nèi)核里的實現(xiàn)細節(jié)。

圖 1：利用 ebpf 進行 socket level redirect，從而跳過 TCP/IP 協(xié)議棧和 lo 設(shè)備

先來一張全局圖，我們再依次剖析這張圖上面的關(guān)鍵知識點。

圖 2：利用 ebpf 進行 socket level redirect 全局細節(jié)圖

一、準備階段

1、插入 bpf_sock_ops 到 sock_hash map

我們的故事從圖 3 所示的插入 bpf_sock_ops 到 sock hash map 開始。這里給出一些代碼片段，完整可編譯、可執(zhí)行的代碼位于 https://github.com/LanceHBZhang/socket-acceleration-with-ebpf 。另外，完整的 ebpf 程序的安裝過程還涉及到 cgroup，我就不展開來講這個話題了。

下面代碼中用到一種特殊的 map 類型：BPF_MAP_TYPE_HASH，也即本文提及的 sock_hash。在它里面存儲的是 KV 類型數(shù)據(jù)，而 value 實際對應(yīng)的是數(shù)據(jù)結(jié)構(gòu) struct bpf_sock_ops。除了存儲 bpf_sock_ops，在這類 map 上還可以 attach 一個用戶編寫的 sk_msg 類型的 bpf 程序，以便來查找接收數(shù)據(jù)的 socket，attach 語句請參考 github 代碼。

static inline
void bpf_sock_ops_ipv4(struct bpf_sock_ops *skops)
{
    struct sock_key key = {};
    int ret;

    extract_key4_from_ops(skops, &key);

    ret = sock_hash_update(skops, &sock_ops_map, &key, BPF_NOEXIST);
    if (ret != 0) {
        printk("sock_hash_update() failed, ret: %d\n", ret);
    }

    printk("sockmap: op %d, port %d --> %d\n",
            skops->op, skops->local_port, bpf_ntohl(skops->remote_port));
}

__section("sockops")
int bpf_sockmap(struct bpf_sock_ops *skops)
{
    switch (skops->op) {
        case BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB:
        case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB:
            if (skops->family == 2) { //AF_INET
                bpf_sock_ops_ipv4(skops);
            }
            break;
        default:
            break;
    }
    return 0;
}

當(dāng)我們通過 attach 一種 sock_ops 類型的 bpf 函數(shù)，即下面代碼中的 bpf_sockmap()，到 cgroupv2 的根路徑后，當(dāng)發(fā)生一些 socket 事件，如主動建立連接或者被動建立連接等，這個時候 bpf 函數(shù) bpf_sockmap() 將會被調(diào)用。這個過程如圖 3 執(zhí)行點 1 所示，更具體地說 1發(fā)生的事情就是三次握手(SYN / SYNC-ACK / ACK)，既然是三次握手，當(dāng)然是與通信雙方都有關(guān)系，所以 bpf_sockmap() 函數(shù)里 bpf_sock_ops_ipv4(skops) 會被調(diào)用兩次 。

bpf_sockmap() 所做的事情非常簡單：以 source ip / source port / dest ip / dest port / family 為 key ，將 struct bpf_sock_ops 對象放入到 sock_hash 中。這個過程如圖 3 執(zhí)行點 1.2 所示。為了表示 bpf_sockmap() 與 ebpf 有關(guān)，我特意在2 處畫出了 ebpf 的 logo。

上述代碼中 sock_hash_update() 函數(shù)調(diào)用看起來是在更新 sock_has map，其實它在內(nèi)核中所做的事情更重要：精準動態(tài)替換 TCP 協(xié)議相關(guān)函數(shù)。

圖 3：插入 sock 到 sock_hash map

2、精準動態(tài)替換 prot

如果大家關(guān)注過內(nèi)核協(xié)議棧相關(guān)數(shù)據(jù)結(jié)構(gòu)的話，一定會碰到如下圖所示的幾個關(guān)鍵角色：struct file / struct socket / struct sock / struct proto 。

其中 socket 如同設(shè)計模式里常用的轉(zhuǎn)接器(adaptor)，一方面它適配了面向應(yīng)用層的 struct file ，另一方面又通過引用 struct sock 的方式串聯(lián)起網(wǎng)絡(luò)協(xié)議棧。

仔細看這張圖，我們會發(fā)現(xiàn) struct sock 才是靈魂，你從它所包含的內(nèi)容就能窺得一二了。struct sock 里有一個非常關(guān)鍵地方：對 Networking protocol 的引用，也即你看到的 sk_prot 。為什么說它關(guān)鍵呢?因為 sk_prot 作為一個指針所指向的結(jié)構(gòu)體 tcp_prot 包含了一系列對 TCP 協(xié)議至關(guān)重要的函數(shù)，包括本文需要重點關(guān)注的 recvmsg 和 sendmsg 。從它們的名字你也能看出來它們的使用場景：用于 TCP 層接收和發(fā)送數(shù)據(jù)。

當(dāng)然除了 struct tcp_prot ，sk_prot 還可能指向 struct udp_prot / ping_prot / raw_prot 。

圖 4：file / socket / sock / operations(圖片來源：開發(fā)內(nèi)功修煉公眾號)

那 ebpf 在這里面干了啥事呢?非常的巧妙，它把 struct proto 里面的 recvmsg / sendmsg 等函數(shù)動態(tài)替換掉了。比如把 recvmsg 由原來的 tcp_recvmsg 替換成了 tcp_bpf_recvmsg ，而把 tcp_sendmsg 替換為 tcp_bpf_sendmsg 。

static void tcp_bpf_rebuild_protos(struct proto prot[TCP_BPF_NUM_CFGS], struct proto *base)
{
  prot[TCP_BPF_BASE]      = *base;
  prot[TCP_BPF_BASE].close    = sock_map_close;
  prot[TCP_BPF_BASE].recvmsg    = tcp_bpf_recvmsg;
  prot[TCP_BPF_BASE].sock_is_readable  = sk_msg_is_readable;

  prot[TCP_BPF_TX]      = prot[TCP_BPF_BASE];
  prot[TCP_BPF_TX].sendmsg    = tcp_bpf_sendmsg;
  prot[TCP_BPF_TX].sendpage    = tcp_bpf_sendpage;

  prot[TCP_BPF_RX]      = prot[TCP_BPF_BASE];
  prot[TCP_BPF_RX].recvmsg    = tcp_bpf_recvmsg_parser;

  prot[TCP_BPF_TXRX]      = prot[TCP_BPF_TX];
  prot[TCP_BPF_TXRX].recvmsg    = tcp_bpf_recvmsg_parser;
}

static int __init tcp_bpf_v4_build_proto(void)
{
  tcp_bpf_rebuild_protos(tcp_bpf_prots[TCP_BPF_IPV4], &tcp_prot);
  return 0;
}
late_initcall(tcp_bpf_v4_build_proto);

int tcp_bpf_update_proto(struct sock *sk, struct sk_psock *psock, bool restore)
{
  // ...
  /* Pairs with lockless read in sk_clone_lock() */
  WRITE_ONCE(sk->sk_prot, &tcp_bpf_prots[family][config]);
  return 0;  
}

單純的替換其實談不上巧妙，二哥說巧妙是因為這里的替換是“精準動態(tài)替換”。首先為啥叫精準替換呢?你想啊，不是每個服務(wù)都需要通過 loopback 來進行本機進程間通信的，另外即使進程間通信是通過這種方式，也不是每一種場景都需要使用到我們這里說的 socket level redirect ，所以替換操作不能廣撒網(wǎng)，只能在需要的時候替換。所謂“動態(tài)替換”也即不是在編譯內(nèi)核的時候就直接替換掉了，而是在有需要的時候。

那這個“需要的時候”到底是什么時候呢?

答案是將 bpf_sock_ops 存儲到 sock_hash 的時候，也即圖 3 所涉及到過程。當(dāng)系統(tǒng)函數(shù) bpf_sock_hash_update 被調(diào)用時，內(nèi)核會調(diào)用位于 net/core/sock_map.c 中的 sock_hash_update_common 函數(shù)，在它的調(diào)用鏈中完成了替換函數(shù) tcp_bpf_update_proto() 的調(diào)用。實際的替換結(jié)果是 sk->sk_prot 保存了替換后的版本，也即 tcp_bpf_prots[family][config]，而 tcp_bpf_prots 則在很早的時候就已經(jīng)初始化好了。

強調(diào)一遍，這里的替換操作僅僅與確實需要用到 socket level redirect 的 sock 有關(guān)，不會影響到其它 sock，當(dāng)然被替換的 sock 其實是一對，你一定猜到了，圖 3 中 envoy 進程和 Process B 各有一個自己的 sock 參與了這次通信過程，故而它們自己的 recvmsg / sendmsg 都需要被替換掉。

二、sk_psock

在圖 3 中，我們還能看到獨立于 TX queue 和 RX queue 的新 queue：ingress_msg。通信雙方的 socket 層都各有一個這樣的 queue 。queue 里面暫存的數(shù)據(jù)用結(jié)構(gòu)體 struct sk_msg 表示，sk_msg 包含了我們之前非常熟悉的 skb ，我們略過它的具體定義。在下文講述數(shù)據(jù)發(fā)送和接收流程中我們會看到 ingress_msg queue 是如何發(fā)揮作用的。

這個 queue 位于結(jié)構(gòu)體 struct sk_psock {} 里面。同樣被包含在 sk_psock 里面的，還有它的小伙伴 sock / eval / cork 等。

內(nèi)核代碼里面我們會看到大量的 psock->eval 這樣的語句，即為對 sk_psock 的讀寫。另外你看這個結(jié)構(gòu)體里面還有函數(shù)指針 psock_update_sk_prot ，它所指向的即為上一節(jié)所說的函數(shù) tcp_bpf_update_proto() 。

struct sk_psock {
  struct sock      *sk;
  struct sock      *sk_redir;
  u32        apply_bytes;
  u32        cork_bytes;
  u32        eval;
  struct sk_msg      *cork;
  struct sk_psock_progs    progs;
#if IS_ENABLED(CONFIG_BPF_STREAM_PARSER)
  struct strparser    strp;
#endif
  struct sk_buff_head    ingress_skb;
  struct list_head    ingress_msg;
  spinlock_t      ingress_lock;
  unsigned long      state;
  struct list_head    link;
  spinlock_t      link_lock;
  refcount_t      refcnt;
  void (*saved_unhash)(struct sock *sk);
  void (*saved_close)(struct sock *sk, long timeout);
  void (*saved_write_space)(struct sock *sk);
  void (*saved_data_ready)(struct sock *sk);
  int  (*psock_update_sk_prot)(struct sock *sk, struct sk_psock *psock, bool restore);
  struct proto      *sk_proto;
  struct mutex      work_mutex;
  struct sk_psock_work_state  work_state;
  struct work_struct    work;
  struct rcu_work      rwork;
}

三、發(fā)送數(shù)據(jù)

在和 Process B 成功建立起 TCP 連接后，進程 envoy 開始寫數(shù)據(jù)了，如圖 5 中 2.1 所示。

正常情況下， write() 系統(tǒng)調(diào)用所傳遞的數(shù)據(jù)最終會由 tcp_sendmsg() 來進行 TCP 層的處理。不過還記得在“精準動態(tài)替換 prot” 一節(jié)我們提到 tcp_sendmsg() 已經(jīng)被替換成 tcp_bpf_sendmsg() 了嗎?所以這里的主角其實是 tcp_bpf_sendmsg() 。

圖 5：發(fā)送數(shù)據(jù)流程

我在圖 5 中畫出了 tcp_bpf_sendmsg() 所干的幾件重要的事情：

1、執(zhí)行點2.3：執(zhí)行 ebp 程序

ebpf 程序其實需要老早就需要準備好，并 attach 到 sock_hash 上(再一次，這個過程請參考前文所附 github 代碼)。程序的入口非常簡單：bpf_redir()。它同樣從 struct sk_msg_md 里面提取出 source ip / source port / dest ip / dest port / family ，并以其為 key 到 sock_hash 里面找到需要重定向的目標，也即通信對端的 struct sock，并將其存放于 psock->sk_redir 處。

static inline
void extract_key4_from_msg(struct sk_msg_md *msg, struct sock_key *key)
{
    key->sip4 = msg->remote_ip4;
    key->dip4 = msg->local_ip4;
    key->family = 1;

    key->dport = (bpf_htonl(msg->local_port) >> 16);
    key->sport = FORCE_READ(msg->remote_port) >> 16;
}

__section("sk_msg")
int bpf_redir(struct sk_msg_md *msg)
{
    struct sock_key key = {};
    extract_key4_from_msg(msg, &key);
    msg_redirect_hash(msg, &sock_ops_map, &key, BPF_F_INGRESS);
    return SK_PASS;
}

代碼中 msg_redirect_hash() 這個名字有點誤導(dǎo)人。乍一看還以為是在這里就完成了重定向過程。其實它只干了 map 查找和確認是否允許重定向這兩個操作，真正的好戲還在后頭。它的代碼不長，我直接全部貼在這里了。

BPF_CALL_4(bpf_msg_redirect_hash, struct sk_msg *, msg, struct bpf_map *, map, void *, key, u64, flags)
{
  struct sock *sk;

  if (unlikely(flags & ~(BPF_F_INGRESS)))
    return SK_DROP;

  sk = __sock_hash_lookup_elem(map, key);
  if (unlikely(!sk || !sock_map_redirect_allowed(sk)))
    return SK_DROP;

  msg->flags = flags;
  msg->sk_redir = sk;
  return SK_PASS;
}

2、 執(zhí)行點2.4：enqueue sk_msg

在這里，我們第一次看到 ingress_msg queue 的使用場景。

struct sk_psock {} 里面有一個成員叫 eval ，從這個關(guān)鍵詞大概就能猜到它與評估結(jié)果有關(guān)，那評估的對象是誰呢?就是 2.3 處所需要執(zhí)行的 ebpf 程序。2.3 處的執(zhí)行結(jié)果會放到 psock->eval 里面供后面使用。

執(zhí)行結(jié)果有三種：__SK_PASS / __SK_REDIRECT / __SK_DROP 。當(dāng) psock->eval 等于我們重點關(guān)注的 __SK_REDIRECT 時，就開始了執(zhí)行點 2.4 的過程：將 sk_msg 放到 psock->ingress_msg 這個 queue 里面。

需要注意的是，這個地方的 psock 還是位于發(fā)送端，也即它是屬于 envoy 進程的，那自然這個 ingress_msg queue 也是屬于 envoy 進程的。

3、執(zhí)行點2.5：拉起新的 task

在執(zhí)行點 2.4 把 sk_msg 放到 psock->ingress_msg 之后，內(nèi)核沒有繼續(xù)往下調(diào)用其它函數(shù)，而是選擇通過 schedule_work(&psock->work) 拉起了一個異步 task，并結(jié)束了發(fā)送數(shù)據(jù)的流程。

這樣的選擇搭配 queue 非常的合理：一是為了效率，不能讓發(fā)送端(envoy)一直等待;二是為了解耦，通過 queue 來解開發(fā)送端和接收端的耦合;三是為了匹配接收端(Process B)的處理速度，進程 B 可能這個時候正好在處理其它事項來不及消費 skb。

四、接收數(shù)據(jù)

上一節(jié)執(zhí)行點 2.5 我們說到，發(fā)送數(shù)據(jù)流程最終啟動了一個異步 task 。到這里為止結(jié)束了發(fā)送數(shù)據(jù)流程，而從這里也開始了接收數(shù)據(jù)的流程。整個流程涉及到的關(guān)鍵步驟我畫在圖 6 里面了：執(zhí)行點 3.1 / 3.2 / 4.1 / 4.2 。

圖 6：接收數(shù)據(jù)流程

1、 執(zhí)行點3.1: dequeue sk_mskg

異步 task 的切入口是函數(shù) sk_psock_backlog() ，而它首先做的事情是拿到 envoy 所使用的 psock 指針，進而不斷地從 psock->ingress_skb 里面取出 sk_msg 進行消費。

下面代碼中 struct sk_psock *psock = container_of(work, struct sk_psock, work) 即為通過 work 拿到 psock 的邏輯，一個簡單又不失優(yōu)雅的過程。

static void sk_psock_backlog(struct work_struct *work)
{
  struct sk_psock *psock = container_of(work, struct sk_psock, work);
  struct sk_psock_work_state *state = &psock->work_state;
  struct sk_buff *skb = NULL;
  //...

  //...
  while ((skb = skb_dequeue(&psock->ingress_skb))) {
    //...
start:
    ingress = skb_bpf_ingress(skb);
    skb_bpf_redirect_clear(skb);
    do {
      ret = -EIO;
      if (!sock_flag(psock->sk, SOCK_DEAD))
        ret = sk_psock_handle_skb(psock, skb, off,
                len, ingress);
      //...
    } while (len);

    if (!ingress)
      kfree_skb(skb);
  }
end:
  mutex_unlock(&psock->work_mutex);
}

2、 執(zhí)行點3.2: 再次enqueue sk_msg

我們看上面代碼里面 skb_dequeue(&psock->ingress_skb) 這一行。它其實消費的是發(fā)送端 psock 里面的數(shù)據(jù)，也即 sk_msg，那消費的結(jié)果是什么呢?其實非常簡單，在執(zhí)行點 3.2 把 sk_msg 塞到了接收端的 psock->ingress_msg queue 里面了。

其實你也看出來了，這一步結(jié)束后，這個新拉起的 task 也就完成了它的使命。

3、執(zhí)行點4.1和4.2: 處理 skb

好了，如果你耐心地看到這個地方，大概也能猜到接下來發(fā)生什么了。執(zhí)行點 4.1 處所調(diào)用的 read() 操作其實對應(yīng)到 TCP 協(xié)議里面的 recvmsg 函數(shù)。recvmsg 只是一個指向函數(shù)的指針，真正的函數(shù)實現(xiàn)是 tcp_bpf_recvmsg() 。在文首“精準動態(tài)替換”那節(jié)，二哥已經(jīng)鋪墊過啦。

五、備胎

你再回頭看下圖 2 ，會發(fā)現(xiàn)二哥在圖中從 tcp_bpf_sendmsg() 以及 tcp_bpf_recvmsg() 分別拉了一條虛線到 tcp_sendmsg() 和 tcp_recvmsg()。我管 tcp_sendmsg() 和 tcp_recvmsg() 叫備胎。因為 tcp_bpf_sendmsg() 以及 tcp_bpf_recvmsg() 在處理一些異常情況時就直接走老路了。

static int tcp_bpf_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
        int nonblock, int flags, int *addr_len)
{
  // ...
  psock = sk_psock_get(sk);
  if (unlikely(!psock))
    return tcp_recvmsg(sk, msg, len, nonblock, flags, addr_len);
}

圖 7：備胎 tcp_sendmsg() 和 tcp_recvmsg()