前言 上一篇文章《ebpf-go 初體驗》中，我們提到了一個小插曲，就是當 map 的 key 這樣寫的時候 struct tuple key = {ip, bpf_ntohs(sport)}，map 的 key 看起來會重複，有些令人詫異，於是我用另外一台機器 B 測了下（內核 6.6，clang 14.0.0）。發現了報錯："invalid indirect read from stack R
前面我們分析了《數據包如何遊走於 Iptables 規則之間》，那麼在容器網絡這種更復雜的場景中數據包是如何在 iptables 的各個規則之間遊走的呢？ 為了搞清楚這個問題，我們首先有一些前置概念需要了解。 前置概念 network namespace namespace 是容器隔離的基礎，而 network namespace 則使得每個 namespace 獨享 IP address、por
在前文《Linux 路由三大件》中，我們提到了 iptables 可以修改數據包的特徵從而影響其路由。這個功能無論是傳統場景下的 防火牆，還是雲原生場景下的 服務路由（k8s service）、網絡策略(calico network policy) 等都有依賴。 雖然業界在積極地推進 ipvs、ebpf 等更新、更高效的技術落地，但是出於各種各樣的原因（技術、成本、管理等），iptables 仍然
對於 Linux 網絡，好奇心強的同學一定思考過兩個問題： 當我們發出一個包的時候，Linux 是如何決策該從哪個網卡（假設有多個網卡）、哪個下一跳發出這個包，用什麼 IP 作為 source...... 當 Linux 收到一個包時，又是如何決定往哪裏送的，是發送給本地程序、其他虛擬接口，還是轉發到其他機器...... 今天，我們就來分析這兩個問題的核心所在：路由。 我們學習計算機網絡的
