上一节 我们大概介绍了一下Envoy中有关速率限制（限流）的一些内容，这一节我们看一下对于外部的 gRPC限流服务它又是如何工作和配置的。

在 Envoy 中对服务限流的配置除了可以在 Envoy 本身中实现外，还可以在通过外部服务实现，此时 Envoy 将通过 gRPC 协议调用外部限流服务，官方对此实现有一套现成的解决方案，主要是redis数据库+令牌桶算法实现，可参考官方

本文中的限制器或限流器均是同一个意思。

Envoy 实现限流

此实现是基于令牌桶算法实现，本身比较的简单，比较适合一般的使用场景。

这里是官方提供的一个配置示例

13          http_filters:
14          - name: envoy.filters.http.local_ratelimit
15            typed_config:
16              "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
17              stat_prefix: http_local_rate_limiter
18              token_bucket:
19                max_tokens: 10000
20                tokens_per_fill: 1000
21                fill_interval: 1s
22              filter_enabled:
23                runtime_key: local_rate_limit_enabled
24                default_value:
25                  numerator: 100
26                  denominator: HUNDRED
27              filter_enforced:
28                runtime_key: local_rate_limit_enforced
29                default_value:
30                  numerator: 100
31                  denominator: HUNDRED
32              response_headers_to_add:
33              - append_action: OVERWRITE_IF_EXISTS_OR_ADD
34                header:
35                  key: x-local-rate-limit
36                  value: 'true'
37              local_rate_limit_per_downstream_connection: false

重点关注配置项 token_bucket ，这里的配置表示当前最多有 10000 个令牌可以被使用，其中令牌在使用的过程中，只要桶中不足10000 个令牌时，则会以每秒再产生 1000 个令牌的速度产生新的令牌并放入令牌桶中，这样就可以实现后期每秒 1000个请求的需求。

在 Envoy 架构中 Rate limit service 共支持 global rate limiting 和 local rate limit filter 两种速率限制。推荐使用 https://github.com/envoyproxy/ratelimit 库。

Global rate limiting

Envoy 提供了两种全局限速实现

1. 每个连接 或 每个HTTP请求 速率限制检查。
2. 基于配额，具有定期负载报告，允许在多个 Envoy 实例之间公平共享全局速率限制。此实现适用于每秒请求负载较高的大型 Envoy 部署，这些负载可能无法在所有 Envoy 实例之间均匀平衡。

Per connection or per HTTP request rate limiting

Envoy 直接与全局 gRPC rate limiting service 集成，配置参考 https://www.envoyproxy.io/docs/envoy/latest/configuration/other_features/rate_limit#config-rate-limit-service。

速率服务可以使用任何 RPC/IDL 协议实现，但Envoy 提供了一个用 Go 编写的参考实现，它使用 Redis 作为后端。速率集成有以下两种特征:

1. Network 级别过滤器：对应 Per connection ，Envoy 将为安装过滤器的侦听器上的每个 新连接 调用速率限制服务。该配置指定一个特定的域名和描述符设置为速率限制。这具有限制每秒传输侦听器的连接速率的最终效果。配置参考 https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/rate_limit_filter#config-network-filters-rate-limit

2. HTTP 级别过滤器: 对应 Per HTTP request，Envoy 将为安装过滤器的 Listener 以及路由表指定应调用全局速率限制服务的侦听器上的每个 新请求 调用速率限制服务。对目标上游集群的所有请求以及从原始集群到目标集群的所有请求都可以进行速率限制。配置参考 https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/rate_limit_filter#config-http-filters-rate-limit

oh-my-zsh 是一款非常不错的shell配置，最近几年一直是重度用户。由于一些原因经常登录一些服务器，这里根据自己的习惯做一个笔记，以后不用每一次都要重新从各个地方找安装脚本了。

安装 zsh

安装zsh

一般系统默认的都是bash，所以我们先安装 zsh。如果不清楚当前使用的哪一类shell的，可通过以下命令查看

$ cat $SHELL
/bin/bash

我这里使用的默认shell。根据平台选择相应的安装zsh命令, 我这里是Ubuntu系统。

Linux、Debian平台

sudo apt install -y zsh

macOS

brew install zsh

Centos/RHE

sudo yum update && sudo yum -y install zsh

确认版本

$ zsh --version
zsh 5.8.1 (aarch64-unknown-linux-gnu)

查看 /etc/shell 看是否存在zsh

$ cat /etc/shells
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/usr/bin/sh
/bin/dash
/usr/bin/dash
/usr/bin/tmux
/usr/bin/screen
/bin/zsh
/usr/bin/zsh

这里有两个 zsh， 其实它们是同一个, 不用管它。

切换默认shell

chsh -s $(which zsh)

注销用户，重新登录终端，再看确认是否切换默认shell成功。

node2% echo $SHELL
/usr/bin/zsh

现在看到终端提示符发生了变化。

进入终端时，可能会提示让配置 zsh ，最终生成一个 .zshrc 配置文件，根据需要配置一下即可。

在mac上创建了一个ubuntu的虚拟机做为k8s远程开发调试机器，但在编译程序的时候发现磁盘空间不足，于是需要对磁盘进行扩容。

下面为整个硬盘扩容过程。

硬盘扩容

首先将虚拟机关机，在 Vmware Fusion 软件上面菜单，点击 Virtual Machine -> Setting 菜单，然后在突出框框里的找到硬盘 Hard Disk ，点击调整硬盘空间大小，然后点击Apply 应用按钮。

磁盘格式化

查看当前磁盘分区信息

sxf@vm:~/workspace$ sudo fdisk -l
[sudo] password for sxf:
Disk /dev/loop0: 63.29 MiB, 66359296 bytes, 129608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop1: 63.46 MiB, 66531328 bytes, 129944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop2: 91.85 MiB, 96292864 bytes, 188072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop3: 49.86 MiB, 52260864 bytes, 102072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop4: 53.26 MiB, 55844864 bytes, 109072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

## 注意这里由于/dev/sda 磁盘进行了扩容，因此会提示不匹配
GPT PMBR size mismatch (41943039 != 104857599) will be corrected by write.
Disk /dev/sda: 50 GiB, 53687091200 bytes, 104857600 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 433D7B47-01B6-4710-AFAB-7709921A5BBF

Device       Start      End  Sectors  Size Type
/dev/sda1     2048     4095     2048    1M BIOS boot
/dev/sda2     4096  3719167  3715072  1.8G Linux filesystem
/dev/sda3  3719168 41940991 38221824 18.2G Linux filesystem

Disk /dev/mapper/ubuntu--vg-ubuntu--lv: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

查看磁盘 /dev/sda 信息

前段时间使用 iptables 的 DNAT 实现一个业务需求的时候，遇到了一些问题这里将其整个过程记录下来。

需求

这里假设开发机地址为 192.168.3.80，要实现的需求是当用户在开发机访问一个IP地址 192.168.3.196时，将请求转发到另一台机器 192.168.3.58，很明显直接使用 DNAT 来实现即可。

问题现象

iptables 命令如下

sudo iptables -t nat -F
sudo iptables -t nat -A PREROUTING -d 192.168.3.196 -p tcp --dport 8080 -j DNAT --to-destination 192.168.3.58:8080
sudo iptables -t nat -A POSTROUTING -d 192.168.3.58 -p tcp --dport 8080 -j SNAT --to-source 192.168.3.196:8080

这时在开发机器访问

curl http://192.168.3.196:8080

发现提示错误

curl: (7) Failed to connect to 192.168.3.196 port 8080: Connection refused

奇怪了，竟然不能访问，确认路由规则是写入成功的。网上查找了一些资料好像全是这种写法，只不过用法有怕差异，这时直觉告诉我应该对 DNAT 理解不到位，遗漏了一些重要的知识点。

上面这种写法一般都是将开发机当作一个中转服务器或跳板来使用，多种情况下都有一个公网ip，与我们的真正需求有一些不一样。

现在我们再以将其视为中转服务器的角色测试一次，当然这个规则不能直接使用上面的这个，需要把访问的目标ip更换成开发机器的IP地址。

sudo iptables -t nat -F
sudo iptables -t nat -A PREROUTING -d 192.168.3.80 -p tcp --dport 8080 -j DNAT --to-destination 192.168.3.58:8080
sudo iptables -t nat -A POSTROUTING -d 192.168.3.58 -p tcp --dport 8080 -j SNAT --to-source 192.168.3.80:8080

第一条是数据包出去规则，需要做DNAT，第二条是数据包回来规则，必须做一次 SNAT，否则数据包将去无回，无法响应。

环境：

客户端(windows) 192.168.6.21

服务器(Ubuntu): 192.168.6.23

开启iptables调试内核模块

 $ modprobe nf_log_ipv4
 $ sysctl net.netfilter.nf_log.2
 net.netfilter.nf_log.2 = nf_log_ipv4

添加iptables规则

 $ iptables -t raw -A PREROUTING -p icmp -j TRACE
 $ iptables -t raw -A OUTPUT -p icmp -j TRACE

测试规则

客户端执行 ping 命令，

 $ ping 192.168.6.23 -n 1

这里使用 -n 参数指定发送的包数量为1，方便我们分析日志

此时在服务器上执行查看日志命令, 日志文件为：/var/log/syslog 或者 /var/log/kern.log 或者 /var/log/messages

$ tail -f /var/log/syslog
 Jul 20 11:28:40 ubuntu kernel: [ 7606.531051] TRACE: raw:PREROUTING:policy:2 IN=ens37 OUT= MAC=00:0c:29:30:06:44:00:68:eb:c6:60:f2:08:00 SRC=192.168.6.21 DST=192.168.6.23 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=33555 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=608
 Jul 20 11:28:40 ubuntu kernel: [ 7606.531146] TRACE: nat:PREROUTING:rule:1 IN=ens37 OUT= MAC=00:0c:29:30:06:44:00:68:eb:c6:60:f2:08:00 SRC=192.168.6.21 DST=192.168.6.23 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=33555 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=608
 Jul 20 11:28:40 ubuntu kernel: [ 7606.531192] TRACE: nat:DOCKER:return:3 IN=ens37 OUT= MAC=00:0c:29:30:06:44:00:68:eb:c6:60:f2:08:00 SRC=192.168.6.21 DST=192.168.6.23 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=33555 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=608
 Jul 20 11:28:40 ubuntu kernel: [ 7606.531259] TRACE: nat:PREROUTING:policy:2 IN=ens37 OUT= MAC=00:0c:29:30:06:44:00:68:eb:c6:60:f2:08:00 SRC=192.168.6.21 DST=192.168.6.23 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=33555 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=608
 Jul 20 11:28:40 ubuntu kernel: [ 7606.531316] TRACE: filter:INPUT:policy:1 IN=ens37 OUT= MAC=00:0c:29:30:06:44:00:68:eb:c6:60:f2:08:00 SRC=192.168.6.21 DST=192.168.6.23 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=33555 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=608
 Jul 20 11:28:40 ubuntu kernel: [ 7606.531373] TRACE: nat:INPUT:policy:1 IN=ens37 OUT= MAC=00:0c:29:30:06:44:00:68:eb:c6:60:f2:08:00 SRC=192.168.6.21 DST=192.168.6.23 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=33555 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=608
 Jul 20 11:28:40 ubuntu kernel: [ 7606.531424] TRACE: raw:OUTPUT:policy:2 IN= OUT=ens37 SRC=192.168.6.23 DST=192.168.6.21 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=35888 PROTO=ICMP TYPE=0 CODE=0 ID=1 SEQ=608
 Jul 20 11:28:40 ubuntu kernel: [ 7606.531488] TRACE: filter:OUTPUT:policy:1 IN= OUT=ens37 SRC=192.168.6.23 DST=192.168.6.21 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=35888 PROTO=ICMP TYPE=0 CODE=0 ID=1 SEQ=608

可以看到除了流量来源 SRC 和目的 DST, 还有一些 ICMP 协议相关的字段，如 TYPE, CODE; 对于 ICMP协议 TYPE 有多类值，其中CODE 根据 TYPE 值的不同而不同。

一、什么是HTTPS、TLS、SSL

HTTPS，也称作HTTP over TLS。TLS的前身是SSL，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。下图描述了在TCP/IP协议栈中TLS(各子协议)和HTTP的关系。

二、HTTP和HTTPS协议的区别

1、HTTPS协议需要到证书颁发机构(Certificate Authority，简称CA)申请证书，一般免费证书很少，需要交费。

2、HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。

3、HTTP和HTTPS使用的是完全不同的连接方式，使用的端口也不一样,前者是80,后者是443。

4、HTTP的连接很简单,是无状态的。

5、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全。

从上面可看出，HTTPS和HTTP协议相比提供了

· 数据完整性：内容传输经过完整性校验

· 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥

· 身份认证：第三方无法伪造服务端(客户端)身份

其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。

三、证书

1、什么是证书呢?

2、证书中包含什么信息

证书信息：过期时间和序列号

所有者信息：姓名等

所有者公钥

3、为什么服务端要发送证书给客户端

互联网有太多的服务需要使用证书来验证身份，以至于客户端(操作系统或浏览器等)无法内置所有证书，需要通过服务端将证书发送给客户端。

4、客户端为什么要验证接收到的证书

中间人攻击

5、客户端如何验证接收到的证书

为了回答这个问题，需要引入数字签名(Digital Signature)。

将一段文本通过哈希(hash)和私钥加密处理后生成数字签名。

假设消息传递在Bob，Susan和Pat三人之间发生。Susan将消息连同数字签名一起发送给Bob，Bob接收到消息后，可以这样验证接收到的消息就是Susan发送的

当然，这个前提是Bob知道Susan的公钥。更重要的是，和消息本身一样，公钥不能在不安全的网络中直接发送给Bob。

此时就引入了证书颁发机构(Certificate Authority，简称CA)，CA数量并不多，Bob客户端内置了所有受信任CA的证书。CA对Susan的公钥(和其他信息)数字签名后生成证书。

Susan将证书发送给Bob后，Bob通过CA证书的公钥验证证书签名。

Bob信任CA，CA信任Susan， 使得 Bob信任Susan，信任链(Chain Of Trust)就是这样形成的。

事实上，Bob客户端内置的是CA的根证书(Root Certificate)，HTTPS协议中服务器会发送证书链(Certificate Chain)给客户端。

正式开始HTTPS的内容：

一、HTTPS的基本原理

从上面可知，HTTPS能够加密信息，以免敏感信息被第三方获取。所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

HTTPS其实是有两部分组成：HTTP +SSL/ TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

1. 客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到server的443端口。

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

在一些开源其中，有些文档使用git动画来介绍的话效果会好很多，所以这里把在Linux终端下如何生成git动画效果整理出来，供大家参考。

安装录屏软件 asciinema

Mac

 brew install asciinema

Ubuntu

 sudo apt-add-repository ppa:zanchey/asciinema

Debian

 sudo apt-get install asciinema

Pip安装

 sudo pip3 install asciinema

目前此软件不支持 Windows。更多安装教程参考：

用法介绍

 ❯ asciinema -h
 usage: asciinema [-h] [--version] {rec,play,cat,upload,auth} ...
 ​
 Record and share your terminal sessions, the right way.
 ​
 positional arguments:
   {rec,play,cat,upload,auth}
     rec                 Record terminal session
     play                Replay terminal session
     cat                 Print full output of terminal session
     upload              Upload locally saved terminal session to asciinema.org
     auth                Manage recordings on asciinema.org account
 ​
 optional arguments:
   -h, --help            show this help message and exit
   --version             show program's version number and exit
 ​
 example usage:
   Record terminal and upload it to asciinema.org:
     asciinema rec
   Record terminal to local file:
     asciinema rec demo.cast
   Record terminal and upload it to asciinema.org, specifying title:
     asciinema rec -t "My git tutorial"
   Record terminal to local file, limiting idle time to max 2.5 sec:
     asciinema rec -i 2.5 demo.cast
   Replay terminal recording from local file:
     asciinema play demo.cast
   Replay terminal recording hosted on asciinema.org:
     asciinema play https://asciinema.org/a/difqlgx86ym6emrmd8u62yqu8
   Print full output of recorded session:
     asciinema cat demo.cast
 ​
 For help on a specific command run:
   asciinema <command> -h
 ​

录屏

录屏命令

TUN/TAP 设备

在计算机中TUN与TAP是操作系统内核中的虚拟网络设备。不同于硬件设备这些虚拟的网络设备全部用软件实现，但提供了与硬件设备完全相同的功能。

我们先了解一下物理设备的工作原理

所有主机物理网卡收到的数据包时，会先将其交给内核的 Network Stack 处理，然后通过 Socket API 通知给用户态的用户程序。

Linux 中 Tun/Tap 驱动程序为应用程序提供了两种交互方式:

• 虚拟网络接口和字符设备 /dev/net/tun。写入字符设备 /dev/net/tun 的数据会发送到虚拟网络接口中；
• 发送到虚拟网络接口中的数据也会出现在该字符设备上;

我们再看下 tun 设备的工作原理

用户态应用往字符设备 /dev/tunX 写数据时，写入的数据都会出现在TUN虚拟设备上，当内核发送一个包给 TUN 虚拟设备时，通过读这个字符设备 /dev/tunX 同样可以拿到包的内容。

用户态应用程序写数据到 tun/tap 设备后进入内核态，内核态通过TCP协议复制到用户态，最后数据再次复制到内核态并通过物理网卡转发出去，期间共经历了三次用户态与内核态的复制操作，相比传统的一次复制操作来说，开销还是比较大的，因此性能会有一定的下降，这正是它的缺点。

TAP 设备与 TUN 设备工作方式完全相同，区别在于：

• TUN 设备的 /dev/tunX 文件收发的是 IP 层数据包，只能工作在 IP 层，无法与物理网卡做 bridge，但是可以通过三层交换（如 ip_forward）与物理网卡连通。
• TAP 设备的 /dev/tapX 文件收发的是 MAC 层数据包，拥有 MAC 层功能，可以与物理网卡做 bridge，支持 MAC 层广播

应用场景

tun/tap 的最主要应用场景就是 vpn。 基实现原理就是用到隧道技术，将无法直接发送的包通先封成允许通过的合法数据包，然后经过隧道的方式传递给对方，对方收到数据包再解包成原始数据包，再继续传递下去，直到接收端收到，然后响应并原路返回。 以下图为例

1. 应用进程（用户态）发起一个请求时，数据包并不是直接通过eth0网卡流出去，而是将请求数据包写入一个 TUN 字符设备，此时字符设备的数据会被发到虚拟网卡上（进入内核态）。根据TUN设置的特点，凡是写到这个设备的数据都可以在设备的另一端被应用程序读出的原理，应用程序客户端VPN(Port:28001)不断的从TUN 设备里将数据包读出来，然后再经过物理的网卡 eth0(IP1) 网卡流出，这一步就是一个普通的应用程序的客户端发起一个请求的过程。
2. 流出的数据包通过 eth0 (IP2)被服务端VPN（Port:38001）接收到，然后再将收到的数据包以同样的方式写入 TUN 设备，此时进入内核态，经过 TCP/IP 协议栈，则再次将数据包经过物理网卡eth0(IP2)出去，经过交换同机或路由器直到最终到达目的主机(目的主机非本机)。
3. 然后目的主机将响应按原来的线路返回给发起请求应用程序。

总结

Open Policy Agent 简称OPA是一个开源的通用策略引擎，可在整个堆栈中实现统一的、上下文感知的策略实施。OPA 已经成为了云原生计算基金会 ( CNCF) 领域的毕业项目，已经在 Kubernetes / Istio 等多个知名项目里使用 。

OPA的核心思想就是策略即代码。

它使用Rego语言开发，Rego 的灵感来自 Datalog，它是一种易于理解、已有数十年的历史的查询语言。Rego 扩展了 Datalog 以支持 JSON 等文档模型。对于它的详细介绍请参考官方文档 ，这里不再介绍，本方主要介绍如何使用Golang 来开发一个opa策略。

概述

OPA 将 策略决策 与 策略执行 分离，当您的软件需要做出策略决策时，它会查询 OPA 并提供结构化数据（例如 JSON）作为输入。 OPA 接受任意结构化数据作为输入。

对于它的输入一般称为 input， 可以为任意类型，输出也一样可以为任意类型，即可以输出布尔值 true 或 false，也可以输出一个 JSON 字符串对象。

示例

我们先从官方提供的一个 playground 开始，它是一个官方提供的在线执行平台。

从界面我们可以看出，窗口主要分四块：

• 左侧是 Policy窗口，即上方图的黄色部分
• 右上方的为用户提供数据的input 窗口，也可以直接省略不写，大部分情况下为 JSON 或 YAML 数据格式
• 右中间窗口为 Data ，提供数据源部分，一般是一个对接持久化数据库的存储层接口。有时规则里有一些数据需要从数据库里查询提取，如根据 input.user_id 查询出来用户的入职时间，然后在规则里根据这个入职时间进行一些逻辑判断之类。
• 右下方则为评估结果输出区域，在 playground 这种方式中会将全部信息都输出给我们，没有办法指定查询指定的字段值，官方提示的示例中输出为布尔值。

下面我们重点只介绍下 Policy，它才是我们本节关注的重点。

Policy

Rego 策略是使用一组相对较小的类型定义的：Module、Package和Imports、Rule、Expr和Term。从本质上讲，策略由Rule 组成，这些 Rule 由一个或多个Expr对策略引擎可用的文档进行定义Expr由内在值（Term）定义，例如字符串、对象、变量等。源码在 。

从大体中来说，主要为 Package、Imports 和 Rules 三部分，而对于 Rules 是由多个 Rule 组成。

计时器分 Timer 和 Ticker 两种，它们底层基本是一样的，两差的区别请参考 , 这里我们的介绍对象是 Timer 。golang timer

计时器结构体

 // NewTimer creates a new Timer that will send
 // the current time on its channel after at least duration d.
 func NewTimer(d Duration) *Timer {
     c := make(chan Time, 1)
     t := &Timer{
         C: c,
         r: runtimeTimer{
             when: when(d),
             f:    sendTime,
             arg:  c,
         },
     }
     startTimer(&t.r)
     return t
 }

通过调用 NewTimer() 函数创建一个 Timer，首先创建一个长度为1的有缓冲channel，再创建一个Timer的结构体，并将 channel 置于 Timer 结构体内。

注意这里的 runtimeTimer.f 字段是一个函数 sendTime ，其实现如下

eBPF 的全称“扩展的伯克利数据包过滤器 (Extended Berkeley Packet Filter)” 来看，它是一种数据包过滤技术，是从 BPF (Berkeley Packet Filter) 技术扩展而来的。

BPF 提供了一种在 内核事件 和 用户程序 事件发生时安全注入代码的机制，这就让非内核开发人员也可以对内核进行控制。随着内核的发展，BPF 逐步从最初的数据包过滤扩展到了网络、内核、安全、跟踪等，而且它的功能特性还在快速发展中，这种扩展后的 BPF 被简称为 eBPF（早期的 BPF 被称为经典 BPF，简称 cBPF）。实际上，现代内核所运行的都是 eBPF，如果没有特殊说明，内核和开源社区中提到的 BPF 等同于 eBPF 。

使用场景及分类

根据 eBPF 的功能和使用场景，主要分类三类：

跟踪

从内核和程序的运行状态中提取跟踪信息，来了解当前系统正在发生什么。

跟踪类 eBPF 程序主要用于从系统中提取跟踪信息，进而为监控、排错、性能优化等提供数据支撑。

其中 BCC 工具集中包含的绝大部分工具也都属于这个类型。

网络

对网络数据包进行过滤和处理，以便了解和控制网络数据包的收发过程。

网络类 eBPF 程序主要用于对网络数据包进行过滤和处理，进而实现网络的观测、过滤、流量控制以及性能优化等各种丰富的功能。根据事件触发位置的不同，网络类 eBPF 程序又可以分为 XDP（eXpress Data Path，高速数据路径）程序、TC（Traffic Control，流量控制）程序、套接字程序以及 cgroup 程序。

如著名的开源项目 cilium，主要用到了ebpf 中的 XDP （eXpress Data Path，高速数据路径）技术。

安全

第三类是除跟踪和网络之外的其他类型，包括安全控制、BPF 扩展等等。

插桩技术

eBPF支持多种事件源，可以在整个软件栈中提供能见度，其实现目前主要通过两种技术，分别为 动态插桩和 静态插桩，有时候只用其中一种方式是无法实现我们的需求，这时就需要两者相互配合使用了。

动态插桩: kprobes 和 uprobes

动态插桩方式可以做到在程序运行期间，动态的插入观察点，而软件的运行不会受到任何影响，在这点做到了零开销。

在执行 go build 命令的时候，经常需要添加一些参数，或许是为了调试，也或许是为了生成最终部署二进制文件。

在编译特定包时需要传递参数，格式应遵守“包名=参数列表”，如

go build -gcflags -gcflags='log=-N -l' main.go

-gcflags

go build 可以用 -gcflags 给_go_编译器传入参数，也就是传给 go tool compile 的参数，因此可以用 go tool compile –help 查看所有可用的参数。

其中 -m 可以检查代码的编译优化情况，包括逃逸情况和函数是否内联。

-ldflags

go build用 -ldflags 给go链接器传入参数，实际是给go tool link的参数，可以用go tool link –help查看可用的参数。

常用-X来指定版本号等编译时才决定的参数值。例如代码中定义var buildVer string，然后在编译时用go build -ldflags “-X main.buildVer=1.0” … 来赋值。注意-X只能给string类型变量赋值。

Golang中的编译参数

开发中经常使用 go build 命令来编译我们的程序源码，然后将生成二进制文件直接部署，极其方便。

对于 go build 有一些参数，对于针对程序源码进行一些编译优化，下面我们对经常使用的一些参数来介绍一下。

环境变量

环境变量需要在go命令前面设置，如果多个变量的话，中间需要用“空格”分隔。下面我们介绍一个非常常见到的一些环境变量

$ CGO_ENABLED=1 GOARCH=amd64 GOOS=linux go build -o myserver main.go

除了这里给出的这几个变量外，还有一些其它变量，如 GODEBUG、GOFLAGS、GOPROXY 等，所有支持环境变量都可以在  里找到，有兴趣的话可以看看他们的作用。

这里重点介绍一下 CGO_ENABLED 环境变量对我们程序的影响。 CGO_ENABLED是用来控制golang 编译期间是否支持调用 cgo 命令的开关，其值为1或0，默认情况下值为1，可以用 go env 查看默认值。

如果你的程序里调用了cgo 命令，此参数必须设置为1,否则将编译时出错。这里直接用文档  中的一个例子验证。

package main

// #include <stdio.h>
// #include <stdlib.h>
//
// static void myprint(char* s) {
//   printf("%sn", s);
// }
import "C"
import "unsafe"

func main() {
	cs := C.CString("Hello from stdio")
	C.myprint(cs)
	C.free(unsafe.Pointer(cs))
}

然后我们执行一下 启用 CGO_ENABLED=1 的情况

iptables 作为 Linux/Unix 下一款优秀的防火墙软件，在安全方面发挥着极其重要的作用，作为系统管理员来讲一点也不陌生。不过对于一些新手来说，复杂性是一个门槛，Linux厂商为了解决这个问题，于是推出了新的管理工具,如 Centos 下的 Firewalld 和 Ubuntu 下的ufw, 他们对新手十分友好，只需要几个很简单的命令即可实现想要的功能，再不也必为记不住iptables中的四表五键而烦恼了。 那么，是不是有了 firewalld 和 ufw就不需要iptables了呢？并不是的。

首先我们要清楚firewalld、ufw 与iptables的关系，可以理解为两者只是对iptables其进行了一层封装，它们在用户交互方面做了非常多的改进，使其对用户更加友好，不需要再记住原来那么多命令了。

而目前对于一些系统管理员来讲，大概率还是会直接使用 iptables，主要原因是灵活性，当然也有一定的历史原因。对比前面两个管理工具，他们也存在一定的问题，如只能对单条规则进行管理，详细参考相关文档。

另外对于 firewalld 还有图形界面。

除了这三个还有一个 netfilter 的东西，它又是什么呢？

firewalld/ufw 自身并不具备防火墙的功能，而是和 iptables 一样需要通过内核的 netfilter 来实现，也就是说 firewalld 和 iptables 一样，他们的作用都是用于维护规则，而真正使用规则干活的是内核的netfilter。所以iptables服务和firewalld服务都不是真正的防火墙，只是用来定义防火墙规则功能的管理工具，通过iptables将定义好的规则交给内核中的netfilter(网络过滤器来读取)从而实现真正的防火墙功能。不过由于用户一般操作的都是iptables，所以称其为

防火墙也并没有什么不妥的。

总结一下，Netfilter/Iptables 是Linux系统自带的防火墙，Iptables管理规则，Netfilter则是规则的执行者，它们一起实现Linux下安全防护。

以上就是他们四者的关系。

参考资料 https://www.cnblogs.com/kevingrace/p/6265113.html