开始之前说点题外话，距离上一篇FlannelCNI的发布已经快一个月了。这篇本想趁着势头在去年底完成的，正好在一个月内完成计划的所有内容。但上篇发布后不久，我中招了花了一个多周的时间才恢复。然而，恢复后的状态让我有点懵，总感觉很难集中精力，很容易精神涣散。可能接近网上流传的“脑雾”吧，而且Cilium也有点类似一团迷雾。再叠加网络知识的不足，eBPF也未从涉足，学习的过程中断断续续，我曾经一度怀疑这篇会不会流产。文章中不免会有问题，如果有发现问题或者建议，望不吝赐教。背景去年曾经写过一篇文章 《使用Cilium增强Kubernetes网络安全》[1] 接触过Cilium，借助Cilium的网络

开始之前说点题外话，距离上一篇FlannelCNI的发布已经快一个月了。这篇本想趁着势头在去年底完成的，正好在一个月内完成计划的所有内容。但上篇发布后不久，我中招了花了一个多周的时间才恢复。然而，恢复后的状态让我有点懵，总感觉很难集中精力，很容易精神涣散。可能接近网上流传的“脑雾”吧，而且Cilium也有点类似一团迷雾。再叠加网络知识的不足，eBPF也未从涉足，学习的过程中断断续续，我曾经一度怀疑这篇会不会流产。文章中不免会有问题，如果有发现问题或者建议，望不吝赐教。背景去年曾经写过一篇文章 《使用Cilium增强Kubernetes网络安全》[1] 接触过Cilium，借助Cilium的网络

在 上篇文章 用了整篇的内容来描述网络数据包在Kubernetes网络中的轨迹，文章末尾，我们提出了一种假设：同一个内核空间中的两个socket可以直接传输数据，是不是就可以省掉内核网络协议栈处理带来的延迟？不论是同pod中的两个不同容器，或者同节点的两个pod间的网络通信，实际上都发生在同一个内核空间中，互为对端的两个socket也都位于同一个内存中。而在上篇文章的开头也总结了数据包的传输轨迹实际上是socket的寻址过程，可以进一步将问题展开：同一节点上的两个socket间的通信，如果可以 快速定位到对端的socket --找到其在内存中的地址，我们就可以省掉网络协议栈处理带来的延迟。互为

在 上篇文章 用了整篇的内容来描述网络数据包在Kubernetes网络中的轨迹，文章末尾，我们提出了一种假设：同一个内核空间中的两个socket可以直接传输数据，是不是就可以省掉内核网络协议栈处理带来的延迟？不论是同pod中的两个不同容器，或者同节点的两个pod间的网络通信，实际上都发生在同一个内核空间中，互为对端的两个socket也都位于同一个内存中。而在上篇文章的开头也总结了数据包的传输轨迹实际上是socket的寻址过程，可以进一步将问题展开：同一节点上的两个socket间的通信，如果可以 快速定位到对端的socket --找到其在内存中的地址，我们就可以省掉网络协议栈处理带来的延迟。互为

大家好，我是二哥。最近一直在研究eBPF，随着研究的深入，我发现之前写的这篇文章有点问题，所以重新修改了一下。图也重新画了，并添加了一些与sidecar-less相关的额外内容。下面是正文。上一篇《​​利用eBPF实现socketlevel重定向​​》，二哥从整体上介绍了eBPF的一个应用场景socketlevelredirect：如果一台机器上有两个进程需要通过loopback设备相互收发数据，我们可以利用ebpf在发送进程端将需要发送的数据跳过本机的底层TCP/IP协议栈，直接交给目的进程的socket，从而缩短数据在内核的处理路径和时间。这个流程如图1所示。本篇我们来详细看下图1右侧在内

大家好，我是二哥。最近一直在研究eBPF，随着研究的深入，我发现之前写的这篇文章有点问题，所以重新修改了一下。图也重新画了，并添加了一些与sidecar-less相关的额外内容。下面是正文。上一篇《​​利用eBPF实现socketlevel重定向​​》，二哥从整体上介绍了eBPF的一个应用场景socketlevelredirect：如果一台机器上有两个进程需要通过loopback设备相互收发数据，我们可以利用ebpf在发送进程端将需要发送的数据跳过本机的底层TCP/IP协议栈，直接交给目的进程的socket，从而缩短数据在内核的处理路径和时间。这个流程如图1所示。本篇我们来详细看下图1右侧在内