Linux 5
服务器配置
EBPF
eBPF 是一项革命性的技术，起源于 Linux 内核，可以在操作系统的内核中运行沙盒程序。它被用来安全和有效地扩展内核的功能，而不需要改变内核的源代码或加载内核模块。eBPF 通过允许在操作系统内运行沙盒程序，应用程序开发人员可以在运行时，可编程地向操作系统动态添加额外的功能。然后，操作系统保证安全和执行效率，就像在即时编译（JIT）编译器和验证引擎的帮助下进行本地编译一样。eBPF 程序在内核版本之间是可移植的，并且可以自动更新，从而避免了工作负载中断和节点重启。
今天，eBPF 被广泛用于各类场景：在现代数据中心和云原生环境中，可以提供高性能的网络包处理和负载均衡；以非常低的资源开销，做到对多种细粒度指标的可观测性，帮助应用程序开发人员跟踪应用程序，为性能故障排除提供洞察力；保障应用程序和容器运行时的安全执行，等等。可能性是无穷的，而 eBPF 在操作系统内核中所释放的创新才刚刚开始 [3]。
对于浏览器而言，JavaScript 的引入带来的可编程性开启了一场巨大的革命，使浏览器发展成为几乎独立的操作系统。现在让我们回到 eBPF：为了理解 eBPF 对 Linux 内核的可编程性影响，对 Linux 内核的结构以及它如何与应用程序和硬件进行交互有一个高层次的理解是有帮助的
Linux 内核的主要目的是抽象出硬件或虚拟硬件，并提供一个一致的 API（系统调用），允许应用程序运行和共享资源。为了实现这个目的，我们维护了一系列子系统和层，以分配这些责任 [5]。每个子系统通常允许某种程度的配置，以考虑到用户的不同需求。如果不能配置所需的行为，就需要改变内核，从历史上看，改变内核的行为，或者让用户编写的程序能够在内核中运行，就有两种选择:
https://eunomia.dev/zh/tutorials/0-introduce/#ebpf-javascript
https://cloud.tencent.com/developer/article/2312640
https://deepflow.io/zh/ebpf-the-key-technology-to-observability/
四层负载均衡与七层负载均衡简介
所谓四层就是基于 IP + 端口的负载均衡； 七层就是基于 URL 等应用层信息的负载均衡； 同理，还有基于 MAC 地址的二层负载均衡和基于 IP 地址的三层负载均衡
二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址； 三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址； 四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器； 七层通过虚拟的 URL 或主机名接收请求，然后再分配到真实的服务器。
所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量
比如四层的负载均衡，就是通过发布三层的 IP 地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡， 对需要处理的流量进行 NAT 处理，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的， 后续这个连接的所有流量都同样转发到同一台服务器处理。
七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征， 比如同一个 Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量， 还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。 举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的， 那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
- 负载均衡器通常称为四层交换机或七层交换机。 四层交换机主要分析 IP 层及 TCP/UDP 层，实现四层流量负载均衡。 七层交换机除了支持四层负载均衡以外，还有分析应用层的信息，如 HTTP 协议 URI 或 Cookie 信息。
- 负载均衡分为 L4 Switch（四层交换），即在 OSI 第 4 层工作，就是 TCP 层啦。 此种 Load Balancer 不理解应用协议（如 HTTP/FTP/MySQL 等等）。例子：LVS，F5。
- 另一种叫做 L7 Switch（七层交换），OSI 的最高层，应用层。 此时，该 Load Balancer 能理解应用协议。例子： HAProxy，MySQL Proxy。
所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的 TCP 为例，负载均衡设备在接收到第一个来自客户端的 SYN 请求时，即通过上述方式选择一个最佳的服务器， 并对报文中的目标 IP 地址进行修改(改为后端服务器 IP），直接转发给该服务器。 TCP 的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。 在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容， 再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的 TCP 为例，负载均衡设备如果要根据真正的应用层内容再选择服务器， 只能先代理最终的服务器和客户端建立连接（TCP 三次握手）后，才可能接收到客户端发送的真正应用层内容的报文， 然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。 负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立 TCP 连接。 所以从这个技术原理上来看，七层负载均衡明显地对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。
七层应用负载均衡的好处，是使得整个网络更“智能化”, 例如访问一个网站的用户流量，可以通过七层的方式， 将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。 当然这只是七层应用的一个小案例，从技术原理上，这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。 很多在后台(例如 Nginx 或者 Apache )上部署的功能可以前移到负载均衡设备上，例如客户请求中的 Header 重写，服务器响应中的关键字过滤或者内容插入等功能。
另外一个常常被提到功能就是安全性。网络中最常见的 SYN Flood 攻击，即黑客控制众多源客户端，使用虚假 IP 地址对同一目标发送 SYN 攻击， 通常这种攻击会大量发送 SYN 报文，耗尽服务器上的相关资源，以达到 Denial of Service(DoS) 的目的。 从技术原理上也可以看出，四层模式下这些 SYN 攻击都会被转发到后端的服务器上； 而七层模式下这些 SYN 攻击自然在负载均衡设备上就截止，不会影响后台服务器的正常运营。 另外负载均衡设备可以在七层层面设定多种策略，过滤特定报文，例如 SQL Injection 等应用层面的特定攻击手段，从应用层面进一步提高系统整体安全。 现在的 7 层负载均衡，主要还是着重于应用广泛的 HTTP 协议，所以其应用范围主要是众多的网站或者内部信息平台等基于 B/S 开发的系统。 4 层负载均衡则对应其他 TCP 应用，例如基于 C/S 开发的 ERP 等系统。
七层负载考虑的问题：
- 是否真的必要，七层应用的确可以提高流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。 在设计系统时需要考虑四层七层同时应用的混杂情况。
- 是否真的可以提高安全性。例如 SYN Flood 攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备本身要有强大的抗 DDoS 能力， 否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。
- 是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化，但是负载均衡设备需要提供完善的七层功能，满足客户根据不同情况的基于应用的调度。 最简单的一个考核就是能否取代后台 Nginx 或者 Apache 等服务器上的调度功能。 能够提供一个七层应用开发接口的负载均衡设备，可以让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。