plantegg

java tcp mysql performance network docker Linux

一文搞懂域名解析DNS相关问题

本文希望通过一篇文章解决所有域名解析中相关的问题

最后会通过实际工作中碰到的不同场景下几个DNS问题的分析过程来理解DNS

这几个Case描述如下:

  1. 一批ECS nslookup 域名结果正确,但是 ping 域名 返回 unknown host
  2. Docker容器中的域名解析过程和原理
  3. 中间件的VipClient服务在centos7上域名解析失败
  4. 在公司网下,我的windows7笔记本的wifi总是报dns域名异常无法上网(通过IP地址可以上网)

因为这些问题都不一样,但是都跟DNS服务相关所以打算分四篇文章挨个介绍,希望看完后能加深对DNS原理的理解并独立解决任何DNS问题。

下面我们就先开始介绍下DNS解析原理和流程。

Linux下域名解析流程

  • DNS域名解析的时候先根据 /etc/host.conf、/etc/nsswitch.conf 配置的顺序进行dns解析(name service switch),一般是这样配置:hosts: files dns 【files代表 /etc/hosts ; dns 代表 /etc/resolv.conf】(ping是这个流程,但是nslookup和dig不是)
  • 如果本地有DNS Client Cache,先走Cache查询,所以有时候看不到DNS网络包。Linux下nscd可以做这个cache,Windows下有 ipconfig /displaydns ipconfig /flushdns
  • 如果 /etc/resolv.conf 中配置了多个nameserver,默认使用第一个,只有第一个失败【如53端口不响应、查不到域名后再用后面的nameserver顶上】

image.png

上述描述主要是阐述的图中 stub resolver部分的详细流程。这部分流程出问题才是程序员实际中更多碰到的场景

所以默认的nsswitch流程是

image.png

以下是一个 /etc/nsswitch.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# cat /etc/nsswitch.conf |grep -v "^#" |grep -v "^$"
passwd: files sss
shadow: files sss
group: files sss
hosts: files dns myhostname <<<<< 重点是这一行三个值的顺序
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files sss
netgroup: nisplus sss
publickey: nisplus
automount: files nisplus sss
aliases: files nisplus

这个配置中的解析顺序是:files->dns->myhostname, 这个顺序可以调整和配置。

Linux下域名解析流程需要注意的地方

Linux下域名解析诊断工具

  • ping
  • nslookup (nslookup domain @dns-server-ip)
  • dig (dig +trace domain)
  • tcpdump (tcpdump -i eth0 host server-ip and port 53 and udp)
  • strace

img

1
2
//指定本地 ip 端口:192.168.0.201#20202,将 dns 解析任务发送给 172.21.0.10 
dig +retry=0 -b192.168.0.201#20202 aliyun.com @172.21.0.10

案例

如下,向 /etc/hosts 中添加两条记录,一条是test.unknow.host 无法解析到,但是另一条 test.localhost 可以解析到,为啥呢?

$head -2 /etc/hosts
127.0.0.1  test.unknow.host
127.0.0.1   test.localhost
$ping test.unknow.host
ping: unknown host test.unknow.host
$ping -c 1 test.localhost
PING test.localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from test.localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.016 ms

为什么 test.unknow.host 没法解析到? 可能有哪些因素导致这种现象?尝试 ping -c 1 test.localhost 的目的是做什么?

看完前面的理论我的猜测是两种可能导致这种情况:

  • /etc/hosts 没有启用
  • 有本地缓存记录了一个unknow host记录

验证

strace -e trace=open -f ping -c 1 test.localhost

可以通,说明 /etc/hosts 是在起作用的,所以最好验证 /etc/hosts 在起作用的方法是往其中添加一条新纪录,然后验证一下

那接下来只能看本地有没有启动 nscd 这样的缓存了,见后发现也没有,这个时候就可以上 strace 追踪ping的流程了
undefined

从上图可以清晰地看到读取了 /etc/host.conf, 然后读了 /etc/hosts, 再然后读取到我们添加的那条记录,似乎没问题,仔细看这应该是 ip地址后面带的是一个中文字符的空格,这就是问题所在。

到这里可能的情况要追加第三种了:

  • /etc/hosts 中添加的记录没生效(比如中文符号)

dhcp

如果启用了dhcp,那么dhclient会更新在Network Manager启动的时候更新 /etc/resolv.conf

dnsmasq

一般会在127.0.0.1:53上启动dns server服务,配置文件对应在:/run/dnsmasq/resolv.conf。集团内部的vipclient就是类似这个原理。

微服务下的域名解析、负载均衡

微服务中多个服务之间一般都是通过一个vip或者域名之类的来做服务发现和负载均衡、弹性伸缩,所以这里也需要域名解析(一个微服务申请一个域名)

域名解析通过jar、lib包

基本与上面的逻辑没什么关系,jar包会去通过特定的协议联系server,解析出域名对应的多个ip、机房、权重等

域名解析通过dns server

跟前面介绍逻辑一致,一般是/etc/resolv.conf中配置的第一个nameserver负责解析微服务的域名,解析不到的(如baidu.com)再转发给上一级通用的dns server,解析到了说明是微服务自定义的域名,就可以返回来了

如果这种情况下/etc/resolv.conf中配置的第一个nameserver是127.0.0.1,意味着本地跑了一个dns server, 这个服务使用dns协议监听本地udp 53端口

验证方式: nslookup 域名 @127.0.0.1 看看能否解析到你想要的地址

kubernetes 和 docker中的域名解析

一般是通过iptables配置转发规则来实现,这种用iptables和tcpdump基本都可以看清楚。如果是集群内部的话可以通过CoreDNS来实现,通过K8S动态向CoreDNS增删域名,增删ip,所以这种域名肯定只能在k8s集群内部使用

nginx 中的域名解析

nginx可以自定义resolver,也可以通过读取 /etc/resolv.conf转换而来,要注意对 /etc/resolv.conf中 注释的兼容

https://github.com/blacklabelops-legacy/nginx/issues/36 可能是nginx读取 /etc/resolv.conf没有处理好 # 注释的问题

进一步的Case学习:

  1. 一批ECS nslookup 域名结果正确,但是 ping 域名 返回 unknown host
  2. Docker容器中的域名解析过程和原理
  3. 中间件的VipClient服务在centos7上域名解析失败
  4. 在公司网下,我的windows7笔记本的wifi总是报dns域名异常无法上网(通过IP地址可以上网)

参考文章:

GO DNS 原理解析

Linux 系统如何处理名称解析

Anatomy of a Linux DNS Lookup – Part I

史上最全 SSH 暗黑技巧详解

我见过太多的老鸟、新手对ssh 基本只限于 ssh到远程机器,实际这个命令我们一天要用很多次,但是对它的了解太少了,他的强大远远超出你的想象。当于你也许会说够用就够了,确实没错,但是你考虑过效率没有,或者还有哪些脑洞大开的功能会让你爱死他,这些功能又仅仅是一行命令就够了。

疫情期间一行SSH命令让我节省了70%的出差时间,来,让我们一起走一遍,看看会不会让你大开眼界

本文试图解决的问题

  • 如何通过ssh命令科学上网
  • docker 镜像、golang仓库总是被墙怎么办
  • 公司跳板机要输入动态token,太麻烦了,如何省略掉这个token;
  • 比如多机房总是要走跳板机,如何绕过跳板机直连;
  • 我的开发测试机器如何免打通、免密码、直达;
  • 如何访问隔离环境中(k8s)的Web服务 – 将隔离环境中的web端口映射到本地
  • 如何让隔离环境的机器用上yum、apt
  • 如何将服务器的图形界面映射到本地(类似vnc的作用)
  • ssh如何调试诊断,这才是终极技能……

注意事项

  • ssh是指的openSSH 命令工具
  • 本文适用于各种Linux、macOS下命令行操作,Windows的话各种可视化工具都可以复制session、配置tunnel来实现类似功能。
  • 如果文章中提到的文件、文件夹不存在可以直接创建出来。
  • 所有配置都是在你的笔记本上(相当于ssh client上)

科学上网

有时候科学上网还得靠自己,一行ssh命令来科学上网:

1
nohup ssh -qTfnN -D 127.0.0.1:38080 root@1.1.1.1 "vmstat 10" 2>&1 >/dev/null &

上面的 1.1.1.1 是你在境外的一台服务器,已经做好了免密登陆(免密见后面,要不你还得输一下密码),这句话的意思就是在本地启动一个38080的端口,上面收到的任何东西都会转发给 1.1.1.1:22(做了ssh加密),1.1.1.1:22 会解密收到的东西,然后把他们转发给google之类的网站(比如你要访问的是google),结果依然通过原路返回

127.0.0.1:38080 socks5 就是要填入到你的浏览器中的代理服务器,什么都不需要装,非常简单

image.png

原理图如下(灰色矩形框就是你本地ssh命令,ssh 线就是在穿墙, 国外服务器就是命令中的1.1.1.1):
undefined

科学上网之http特殊代理–利用ssh 本地转发是HTTP协议

前面所说的代理是socks5代理,一般浏览器都有插件支持,但是比如你的docker(或者其他程序)需要通过http去拉取镜像就会出现如下错误:

Sending build context to Docker daemon 8.704 kB
Step 1 : FROM k8s.gcr.io/kube-cross:v1.10.1-1
Get https://k8s.gcr.io/v1/_ping: dial tcp 108.177.125.82:443: i/o timeout

如果是git这样的应用内部可以配置socks5和http代理服务器,请参考另外一篇文章,但是有些应用就不能配置了,当然最终通过ssh大法还是可以解决这个问题:

sudo ssh -L 443:108.177.125.82:443 root@1.1.1.1 //在本地监听443,转发给远程108.177.125.82的443端口

然后再在 /etc/hosts 中将域名 k8s.gcr.io 指向 127.0.0.1, 那么本来要访问 k8s.gcr.io:443的,变成了访问本地 127.0.0.1:443 而 127.0.0.1:443 又通过ssh重定向到了 108.177.125.82:443 这样就实现了http代理或者说这种特殊情况下的科学上网。这个方案不需要装任何东西,但是每个访问目标都要这样处理,好在这种情况不多

内部堡垒机、跳板机都需要密码+动态码,太复杂了,怎么解?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$ cat ~/.ssh/config 
#reuse the same connection --关键配置
ControlMaster auto
ControlPath ~/tmp/ssh_mux_%h_%p_%r

#查了下ControlPersist是在OpenSSH5.6加入的,5.3还不支持
#不支持的话直接把这行删了,不影响功能
#keep one connection in 72hour
#ControlPersist 72h
#复用连接的配置到这里,后面的配置与复用无关

#其它也很有用的配置
GSSAPIAuthentication=no
#这个配置在公网因为安全原因请谨慎关闭
StrictHostKeyChecking=no
TCPKeepAlive=yes
CheckHostIP=no
# "ServerAliveInterval [seconds]" configuration in the SSH configuration so that your ssh client sends a "dummy packet" on a regular interval so that the router thinks that the connection is active even if it's particularly quiet
ServerAliveInterval=15
#ServerAliveCountMax=6
ForwardAgent=yes

UserKnownHostsFile /dev/null

在你的ssh配置文件增加上述参数,意味着72小时内登录同一台跳板机只有第一次需要输入密码,以后都是重用之前的连接,所以也就不再需要输入密码了。

加了如上参数后的登录过程就有这样的东东(默认没有,这是debug信息):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
debug1: setting up multiplex master socket
debug3: muxserver_listen: temporary control path /home/ren/tmp/ssh_mux_10.16.*.*_22_corp.86g3C34vy36tvCtn
debug2: fd 3 setting O_NONBLOCK
debug3: fd 3 is O_NONBLOCK
debug3: fd 3 is O_NONBLOCK
debug1: channel 0: new [/home/ren/tmp/ssh_mux_10.16.*.*_22_corp]
debug3: muxserver_listen: mux listener channel 0 fd 3
debug1: control_persist_detach: backgrounding master process
debug2: control_persist_detach: background process is 15154
debug2: fd 3 setting O_NONBLOCK
debug1: forking to background
debug1: Entering interactive session.
debug2: set_control_persist_exit_time: schedule exit in 259200 seconds
debug1: multiplexing control connection

/home/ren/tmp/ssh_mux_10.16.._22_corp 这个就是保存好的socket,下次可以重用,免密码。 in 259200 seconds 对应 72小时

我有很多不同机房(或者说不同客户)的机器都需要跳板机来登录,能一次直接ssh上去吗?

比如有一批客户机房的机器IP都是192.168.., 然后需要走跳板机100.10.1.2才能访问到,那么我希望以后在笔记本上直接 ssh 192.168.1.5 就能直接连上

$ cat /etc/ssh/ssh_config

Host 192.168.*.*
ProxyCommand ssh -l ali-renxijun 100.10.1.2 exec /usr/bin/nc %h %p

上面配置的意思是执行 ssh 192.168.1.5的时候命中规则 Host 192.168.. 所以执行 ProxyCommand 先连上跳板机再通过跳板机连向192.168.1.5 。这样在你的笔记本上就跟192.168.. 的机器仿佛在一起,ssh可以上去,但是ping不通这个192.168.1.5的ip

划重点:公司的线上跳板机做了特殊限制,限制了这个技能。日常环境跳板机支持这个功能

比如我的跳板配置:

#到美国的机器用美国的跳板机速度更快
Host 10.74.*
ProxyCommand ssh -l user us.jump exec /bin/nc %h %p 2>/dev/null
#到中国的机器用中国的跳板机速度更快
Host 10.70.*
ProxyCommand ssh -l user cn.jump exec /bin/nc %h %p 2>/dev/null
   
Host 192.168.0.*
ProxyCommand ssh -l user 1.1.1.1 exec /usr/bin/nc %h %p

其实我的配置文件里面还有很多规则,懒得一个个隐藏IP了,这些规则是可以重复匹配的

来看一个例子

ren@ren-VirtualBox:/$ ping -c 1 10.16.1.*
        PING 10.16.1.* (10.16.1.*) 56(84) bytes of data.^C
    --- 10.16.1.* ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms
    
ren@ren-VirtualBox:~$ ssh -l corp 10.16.1.* -vvv
OpenSSH_6.7p1 Ubuntu-5ubuntu1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/ren/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 28: Applying options for *
debug1: /etc/ssh/ssh_config line 44: Applying options for 10.16.*.*
debug1: /etc/ssh/ssh_config line 68: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/ren/tmp/ssh_mux_10.16.1.*_22_corp" does not exist
debug1: Executing proxy command: exec ssh -l corp 139.*.*.* exec /usr/bin/nc 10.16.1.* 22

本来我的笔记本跟 10.16.1.* 是不通的(ping 不通),但是ssh可以直接连上,实际ssh登录过程中自动走跳板机139...* 就连上了

-vvv 参数是debug,把ssh登录过程的日志全部打印出来。

将隔离环境中的web端口映射到本地(本地代理)

远程机器部署了WEB Server(端口 8083),需要通过浏览器来访问这个WEB服务,但是server在隔离环境中,只能通过ssh访问到。一般来说会在隔离环境中部署一个windows机器,通过这个windows机器来访问到这个web server。能不能省掉这个windows机器呢?

现在我们试着用ssh来实现本地浏览器直接访问到这个隔离环境中的WEB Server。

假设web server是:10.1.1.123:8083, ssh账号是:user

先配置好本地直接 ssh user@10.1.1.123 (参考前面的 ProxyCommand配置过程,最好是免密也配置好),然后在你的笔记本上执行:

ssh -CNfL 0.0.0.0:8088:10.1.1.123:8083 user@10.1.1.123

或者:(root@100.1.2.3 -p 54900 是可达10.1.1.123的代理服务器)

ssh -CNfL 0.0.0.0:8089:10.1.1.123:8083 root@100.1.2.3 -p 54900

这表示在本地启动一个8088的端口,将这个8088端口映射到10.1.1.123的8083端口上,用的ssh账号是user

然后在笔记本上的浏览器中输入: 127.0.0.1:8088 就看到了如下界面:

image.png

反过来,也可以让隔离环境机器通过代理上网,比如安装yum

为什么有时候ssh 比较慢,比如总是需要30秒钟后才能正常登录

先了解如下知识点,在 ~/.ssh/config 配置文件中:

GSSAPIAuthentication=no

禁掉 GSSAPI认证,GSSAPIAuthentication是个什么鬼东西请自行 Google(多一次没必要的授权认证过程,然后等待超时)。 这里要理解ssh登录的时候有很多种认证方式(公钥、密码等等),具体怎么调试请记住强大的命令参数 ssh -vvv 上面讲到的技巧都能通过 -vvv 看到具体过程。

比如我第一次碰到ssh 比较慢总是需要30秒后才登录,不能忍受,于是登录的时候加上 -vvv明显看到控制台停在了:GSSAPIAuthentication 然后Google了一下,禁掉就好了

当然还有去掉每次ssh都需要先输入yes

批量打通所有机器之间的ssh登录免密码

Expect在有些公司是被禁止的

ssh免密码的原理是将本机的pub key复制到目标机器的 ~/.ssh/authorized_keys 里面。可以手工复制粘贴,也可以 ssh-copy-id 等

如果有100台机器,互相两两打通还是比较费事(大概需要100*99次copy key)。 下面通过 expect 来解决输入密码,然后配合shell脚本来批量解决这个问题。

这个脚本需要四个参数:目标IP、用户名、密码、home目录,也就是ssh到一台机器的时候帮我们自动填上yes,和密码,这样就不需要人肉一个个输入了。

再在外面写一个循环对每个IP执行如下操作:

if代码部分检查本机~/.ssh/下有没有id_rsa.pub,也就是是否以前生成过密钥对,没生成的话就帮忙生成一次。

for循环部分一次把生成的密钥对和authorized_keys复制到所有机器上,这样所有机器之间都不需要输入密码就能互相登陆了(当然本机也不需要输入密码登录所有机器)

最后一行代码:

ssh $user@$n "hostname -i"

验证一下没有输密码是否能成功ssh上去。

思考一下,为什么这么做就可以打通两两之间的免密码登录,这里没有把所有机器的pub key复制到其他所有机器上去啊

答案:其实这个脚本做了一个取巧投机的事,那就是让所有机器共享一套公钥、私钥。
有时候我也会把我的windows笔记本和我专用的某台虚拟机共享一套秘钥,这样任何新申请的机器打通一次账号就可以在两台机器上随便登录。请保护好自己的私钥

如果免密写入 authorized_keys 成功,但是通过ssh pubkey认证的时候还是有可能失败,这是因为pubkey认证要求:

  • authorized_keys 文件权限要对
  • .ssh 文件夹权限要对
  • /home/user 文件夹权限要对 —-这个容易忽视掉

留个作业:第一次ssh某台机器的时候总是出来一个警告,需要yes确认才能往下走,怎么干掉他?

StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null

如果按照文章操作不work,推荐就近问身边的同学。问我的话请cat 配置文件 然后把ssh -vvv user@ip (user、ip请替换成你的),再截图发给我。**

测试成功的同学也请留言说下什么os、版本,以及openssl版本,我被问崩溃了


这里只是帮大家入门了解ssh,掌握好这些配置文件和-vvv后有好多好玩的可以去挖掘,同时也请在留言中说出你的黑技能

~/.ssh/config 参考配置

下面是我个人常用的ssh config配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
$cat ~/.ssh/config
#GSSAPIAuthentication=no
StrictHostKeyChecking=no
#TCPKeepAlive=yes
CheckHostIP=no
# "ServerAliveInterval [seconds]" configuration in the SSH configuration so that your ssh client sends a "dummy packet" on a regular interval so that the router thinks that the connection is active even if it's particularly quiet
ServerAliveInterval=15
#ServerAliveCountMax=6
ForwardAgent=yes

UserKnownHostsFile /dev/null

#reuse the same connection
ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r

#keep one connection in 72hour
ControlPersist 72h

Host 192.168.1.*
ProxyCommand ssh user@us.jump exec /usr/bin/nc %h %p 2>/dev/null
Host 192.168.2.*
ProxyCommand ssh user@cn.jump exec /usr/bin/nc %h %p 2>/dev/null
#ProxyCommand /bin/nc -x localhost:12346 %h %p

Host 172
HostName 10.172.1.1
Port 22
User root
ProxyJump root@1.2.3.4:12345

Host 176
HostName 10.176.1.1
Port 22
User root
ProxyJump admin@1.2.3.4:12346

Host 10.5.*.*, 10.*.*.*
port 22
user root
ProxyJump plantegg@1.2.3.4:12347

ProxyJump完全可以取代 ProxyCommand,比如ProxyJump 不再依赖nc、也更灵活一些

/etc/ssh/ssh_config 参考配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Host *
Protocol 2
ServerAliveInterval 30
User admin

host 10.10.55.*
ProxyCommand ssh -l admin admin.jump exec /usr/bin/nc %h %p

# uos is a hostname
Host 10.10.1.13* 192.168.2.133 uos
ProxyCommand ssh -l root -p 54900 1.1.1.1 exec /usr/bin/nc %h %p

#debug for git proxy
Host github.com
# LogLevel DEBUG3
# ProxyCommand ssh -l root gfw.jump exec /usr/bin/nc %h %p
# ProxyCommand ssh -oProxyCommand='ssh -l admin gfw.jump:22' -l root gfw.jump2 exec /usr/bin/nc %h %p


ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication no
GSSAPIDelegateCredentials no
Compression yes

其他知识点

参数的优先级是:命令行配置选项 > ~/.ssh/config > /etc/ssh/ssh_config

在SSH的**身份验证阶段,SSH只支持服务端保留公钥,客户端保留私钥的方式,**所以方式只有两种:客户端生成密钥对,将公钥分发给服务端;服务端生成密钥对,将私钥分发给客户端。只不过出于安全性和便利性,一般都是客户端生成密钥对并分发公钥(阿里云服务器秘钥对–服务器将一对密钥中的公钥放在 authorized_keys, 私钥给client登陆用)

服务器上的 /etc/ssh/ssh_host* 是用来验证服务器身份的秘钥对(对应client的 known_hosts), 在主机验证阶段,服务端持有的是私钥,客户端保存的是来自于服务端的公钥。注意,这和身份验证阶段密钥的持有方是相反的。

SSH支持多种身份验证机制,它们的验证顺序如下:gssapi-with-mic,hostbased,publickey,keyboard-interactive,password,但常见的是密码认证机制(password)和公钥认证机制(public key). 当公钥认证机制未通过时,再进行密码认证机制的验证。这些认证顺序可以通过ssh配置文件(注意,不是sshd的配置文件)中的指令PreferredAuthentications改变。

永久隧道

大多时候隧道会失效,或者断开,我们需要有重连机制,一般可以通过autossh(需要单独安装)搞定自动重连,再配合systemd或者crond搞定永久自动重连

比如以下代码在gf开启2个远程转发端口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
remote_port=(30081 30082)
for port in "${remote_port[@]}"
do
line=`ps aux |grep ssh |grep $port | wc -l`
if [[ "$line" -lt 1 ]]; then
#等价: ssh -fN -R gf:$port:127.0.0.1:22 root@gf
autossh -M 0 -fNR gf:$port:127.0.0.1:22 root@gf
fi;
done

line=`ps aux |grep ssh |grep 13129 | wc -l`
if [[ "$line" -lt 1 ]]; then
nohup ssh -fNR gf:13129:172.16.1.2:3129 root@gf
fi;

#cat /etc/cron.d/jump
#* * * * * root sh /root/drds_private_cloud/jump.sh

或者另外创建一个service服务

1
2
3
4
5
6
7
8
9
10
[Unit]
Description=AutoSSH tunnel on 31081 to gf server
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -q -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -NR gf:31081:172.16.1.2:22 -i /root/.ssh/id_rsa root@gf

[Install]
WantedBy=multi-user.target

调试ssh–终极大招

好多问题都是可以 debug 发现的

  • 客户端增加参数 -vvv 会把所有流程在控制台显示出来。卡在哪个环节;密码不对还是key不对一看就知道
  • server端还可以:/usr/sbin/sshd -ddd -p 2222 在2222端口对sshd进行debug,看输出信息验证为什么pub key不能login等. 一般都是权限不对,/root 以及 /root/.ssh 文件夹的权限和owner都要对,更不要说 /root/.ssh/authorized_keys 了
1
/usr/sbin/sshd -ddd -p 2222 

ssh 提示信息

可以用一下脚本生成一个彩色文件,放到 /etc/motd 中就行

Basic colors are numbered:

  • 1 – Red
  • 2 – Green
  • 3 – Yellow
  • 4 – Blue
  • 5 – Magenta
  • 6 – Cyan
  • 7 – White
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#!/bin/sh
export TERM=xterm-256color

read one five fifteen rest < /proc/loadavg
echo "$(tput setaf 2)
Kernel: `uname -v | awk -v OFS=' ' '{print $4, $5}'`

\\ ^__^
\\ (oo)\\_______
(__)\\ )\\\/\\
||----w |
|| ||

本机器为长稳测试环境, 千万不要kill进程, 不要跑负载过重的任务

有任何需要请联系 ** 多谢!

$(tput setaf 4)Load Averages......: ${one}, ${five}, ${fifteen} (1, 5, 15 min)
$(tput setaf 5)
______________
本机器为长稳测试环境, 千万不要kill进程, 不要跑负载过重的任务

有任何需要请联系 ** 多谢!
--------------
\\ ^__^
\\ (oo)\\_______
(__)\\ )\\\/\\
||----w |
|| ||

$(tput sgr0)"

以上脚本运行结果

image-20210902224011450

sshd Banner

Banner指定用户登录后,sshd 向其展示的信息文件(Banner /usr/local/etc/warning.txt),默认不展示任何内容。

或者配置:

1
2
3
4
5
cat /etc/ssh/sshd_config
# no default banner path
#Banner none
#在配置文件末尾添加Banner /etc/ssh/my_banner这一行内容:
Banner /etc/ssh/my_banner

/etc/ssh/my_banner 中可以放置提示内容

验证秘钥对

-y Read a private OpenSSH format file and print an OpenSSH public key to stdout.

cd ~/.ssh/ ; ssh-keygen -y -f id_rsa | cut -d’ ‘ -f 2 ; cut -d’ ‘ -f 2 id_rsa.pub

ssh-keygen -y -e -f <private key>获取一个私钥并打印相应的公钥,该公钥可以直接与您可用的公钥进行比较

github 上你的公钥

github可以取到你的公钥,如果别人让你查看他的服务器,直接给 https://github.com/plantegg.keys 这个链接,让他把下载的key 加到 ~/.ssh/authorized_keys 里面就行了

ssh-keygen

静默生成

1
2
3
4
5
6
7
8
9
ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y

ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y >/dev/null 2>&1

//修改 passphrase
ssh-keygen -p -P "12345" -N "abcde" -f .ssh/id_rsa
//ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
//或者直接通过提示一步步修改:
ssh-keygen -p

删除或者修改 passphrase

run ssh-keygen -p in a terminal. It will then prompt you for a keyfile (defaulted to the correct file for me, ~/.ssh/id_rsa), the old passphrase (enter what you have now) and the new passphrase (enter nothing).

要注意openssh 不同版本使用的不同 format,用openssh 8.0 默认用 “RFC4716” 格式,老的 4.0 默认是 PKCS8 格式

去修改dsa密钥后 openssh 4.0 不认

-m key_format
Specify a key format for the -i (import) or -e (export) conversion options. The sup‐
ported key formats are: “RFC4716” (RFC 4716/SSH2 public or private key), “PKCS8” (PEM
PKCS8 public key) or “PEM” (PEM public key). The default conversion format is
“RFC4716”.

如果用 8.0 去修改 PKCS8 格式的 key 可以指定格式参数

1
ssh-keygen -p  -m "PKCS8" -f ./id_dsa

ssh-agent

私钥设置了密码以后,每次使用都必须输入密码,有时让人感觉非常麻烦。比如,连续使用scp命令远程拷贝文件时,每次都要求输入密码。

ssh-agent命令就是为了解决这个问题而设计的,它让用户在整个 Bash 对话(session)之中,只在第一次使用 SSH 命令时输入密码,然后将私钥保存在内存中,后面都不需要再输入私钥的密码了。

第一步,使用下面的命令新建一次命令行对话。

1
$ eval `ssh-agent`

上面命令中,ssh-agent会先自动在后台运行,并将需要设置的环境变量输出在屏幕上,类似下面这样。

1
2
3
4
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-barrett/ssh-22841-agent; export SSH_AUTH_SOCK;
SSH_AGENT_PID=22842; export SSH_AGENT_PID;
echo Agent pid 22842;

eval命令的作用,就是运行上面的ssh-agent命令的输出,设置环境变量。

第二步,在新建的 Shell 对话里面,使用ssh-add命令添加默认的私钥(比如~/.ssh/id_rsa,或~/.ssh/id_dsa,或~/.ssh/id_ecdsa,或~/.ssh/id_ed25519)。

1
2
3
$ ssh-add
Enter passphrase for /home/you/.ssh/id_dsa: ********
Identity added: /home/you/.ssh/id_dsa (/home/you/.ssh/id_dsa)

上面例子中,添加私钥时,会要求输入密码。以后,在这个对话里面再使用密钥时,就不需要输入私钥的密码了,因为私钥已经加载到内存里面了。

如果添加的不是默认私钥,ssh-add命令需要显式指定私钥文件。

1
$ ssh-add my-other-key-file

上面的命令中,my-other-key-file就是用户指定的私钥文件。

SSH agent 程序能够将您的已解密的私钥缓存起来,在需要的时候用它来解密key chanllge返回给 SSHD https://webcache.googleusercontent.com/search?q=cache:7OfvSBFki10J:https://www.ibm.com/developerworks/cn/linux/security/openssh/part2/+&cd=7&hl=en&ct=clnk&gl=hk keychain介绍

安装sshd和debug

sshd 有自己的一对或多对密钥。它使用密钥向客户端证明自己的身份。所有密钥都是公钥和私钥成对出现,公钥的文件名一般是私钥文件名加上后缀.pub

DSA 格式的密钥文件默认为/etc/ssh/ssh_host_dsa_key(公钥为ssh_host_dsa_key.pub),RSA 格式的密钥为/etc/ssh/ssh_host_rsa_key(公钥为ssh_host_rsa_key.pub)。如果需要支持 SSH 1 协议,则必须有密钥/etc/ssh/ssh_host_key

如果密钥不是默认文件,那么可以通过配置文件sshd_configHostKey配置项指定。默认密钥的HostKey设置如下。

1
2
3
4
5
6
# HostKey for protocol version 1
# HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2
# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_dsa_ke

注意,如果重装 sshd,/etc/ssh下的密钥都会重新生成(这些密钥对用于验证Server的身份),导致客户端重新 ssh 连接服务器时,会跳出警告,拒绝连接。为了避免这种情况,可以在重装 sshd 时,先备份/etc/ssh目录,重装后再恢复这个目录。

调试:非后台(-D)和debug(-d)模式启动sshd,同时监听2222和3333端口

sshd -D -d -p 2222 -p 3333

sshd config 配置多端口

1
2
3
4
5
#cat /etc/ssh/sshd_config
Port 22022
Port 22
#AddressFamily any
#ListenAddress 0.0.0.0

scp设置socks代理

scp -o “ProxyCommand=nc -X 5 -x [SOCKS_HOST]:[SOCKS_PORT] %h %p” [LOCAL/FILE/PATH] [REMOTE_USER]@[REMOTE_HOST]:[REMOTE/FILE/PATH]

其中[SOCKS_HOST]和[SOCKS_PORT]是socks代理的LOCAL_ADDRESS和LOCAL_PORT。[LOCAL/FILE/PATH]、[REMOTE_USER]、[REMOTE_HOST]和[REMOTE/FILE/PATH]分别是要复制文件的本地路径、要复制到的远端主机的用户名、要复制到的远端主机名、要复制文件的远端路径,这些参数与不使用代理时一样。“ProxyCommand=nc”表示当前运行命令的主机上需要有nc命令。

ProxyCommand

Specifies the proxy command for the connection. This command is launched prior to making the connection to Hostname. %h is replaced with the host defined in HostName and %p is replaced with 22 or is overridden by a Port directive.

在ssh连接目标主机前先执行ProxyCommand中的命令,比如 .ssh/config 中有如下配置

1
2
3
4
5
6
7
8
9
host remote-host
ProxyCommand ssh -l root -p 52146 1.2.3.4 exec /usr/bin/nc %h %p

//以上配置等价下面的命令
ssh -o ProxyCommand="ssh -l root -p 52146 1.2.3.4 exec /usr/bin/nc %h %p" remote-host
//or 等价
ssh -o ProxyCommand="ssh -l root -p 52146 -W %h:%p 1.2.3.4 " remote-host
//or 等价 debug1: Setting implicit ProxyCommand from ProxyJump: ssh -l root -p 52146 -vvv -W '[%h]:%p' 1.2.3.4
ssh -J root@1.2.3.4:52146 remote-host

如上配置指的是,如果执行ssh remote-host 命中host规则,那么先执行命令 ssh -l root -p 52146 1.2.3.4 exec /usr/bin/nc 同时把remote-host和端口(默认22)传给nc

ProxyCommand和ProxyJump很类似,ProxyJump使用:

1
2
//ssh到centos8机器上,走的是gf这台跳板机,本地一般和centos8不通
ssh -J gf:22 centos8

ProxyJump

需要 OpenSSH 7.3 以上版本才可以使用 ProxyJump, 相对 ProxyCommand 更简洁方便些

1
2
3
4
5
6
7
8
9
10
11
12
#ssh 116 就可以通过 jumpserver:50023 连上 root@1.116.2.1:22
Host 116
HostName 1.116.2.1
Port 22
User root
ProxyJump admin@jumpserver:50023

#ssh 1.112.任意ip 都会默认走 jumpserver 跳转过去
Host 1.112.*.*
Port 22
User root
ProxyJump root@jumpserver

加密算法

列出本地所支持默认的加密算法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#ssh -Q key                                                            
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com

ssh -Q cipher # List supported ciphers
ssh -Q mac # List supported MACs
ssh -Q key # List supported public key types
ssh -Q kex # List supported key exchange algorithms

比如连服务器报如下错误:

1
2
debug1: kex: algorithm: (no match)
Unable to negotiate with server port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1

表示服务端支持 diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 加密,但是client端不支持,那么可以指定算法来强制client端使用某种和server一致的加密方式

1
2
3
4
5
ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 -l user

或者config中配置:
host server_ip
KexAlgorithms +diffie-hellman-group1-sha1

如果仍然报以下错误:

1
2
3
4
5
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: (no match)
Unable to negotiate with server_ip port 22: no matching host key type found. Their offer: ssh-rsa

那么可以配置来解决:

1
2
3
Host *
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa

When an SSH client connects to a server, each side offers lists of connection parameters to the other. These are, with the corresponding ssh_config keyword:

  • KexAlgorithms: the key exchange methods that are used to generate per-connection keys
  • HostkeyAlgorithms: the public key algorithms accepted for an SSH server to authenticate itself to an SSH client
  • Ciphers: the ciphers to encrypt the connection
  • MACs: the message authentication codes used to detect traffic modification

无所不能的 SSH 三大转发模式

了解完前面的一些小知识,再来看看无所不能的三大杀招。上面的各种代理基本都是由这三种转发模式实现的。

SSH能够做动态转发、本地转发、远程转发。先简要概述下他们的特点和使用场景

三个转发模式的比较

  • 动态转发完全可以代替本地转发,只是动态转发是socks5协议,当科学上网用,本地转发是tcp协议
  • 本地转发完全是把动态转发特例化到访问某个固定目标的转发,类似 iptable 的 port forwarding
  • 远程转发是启动转端口的机器同时连上两端的两个机器,把本来不连通的两端拼接起来,中间显得多了个节点。
  • 三个转发模式可以串联使用

动态转发常用来科学上网,本地转发用来打洞,这两种转发启动的端口都是在本地;远程转发也是打洞的一种,只不过启用的端口在远程机器上。

img

动态转发 (-D) SOCKS5 协议

动态转发指的是,本机与 SSH 服务器之间创建了一个加密连接,然后本机内部针对某个端口的通信,都通过这个加密连接转发。它的一个使用场景就是,访问所有外部网站,都通过 SSH 转发。

动态转发需要把本地端口绑定到 SSH 服务器。至于 SSH 服务器要去访问哪一个网站,完全是动态的,取决于原始通信,所以叫做动态转发

动态的意思就是:需要访问的目标、端口还不确定。后面要讲的本地转发、远程转发都是针对具体IP、port的转发。

1
2
3
$ ssh -D 4444 ssh-server -N
//或者如下方式:
nohup ssh -qTfnN -D *:13658 root@jump vmstat 10 >/dev/null 2>&1

注意,这种转发采用了 SOCKS5 协议。访问外部网站时,需要把 HTTP 请求转成 SOCKS5 协议,才能把本地端口的请求转发出去。-N参数表示,这个 SSH 连接不能执行远程命令,只能充当隧道。

image-20210913143129749

下面是 ssh 隧道建立后的一个使用实例

1
2
3
curl -x socks5://localhost:4444 http://www.example.com
or
curl --socks5-hostname localhost:4444 https://www.twitter.com

上面命令中,curl 的-x参数指定代理服务器,即通过 SOCKS5 协议的本地3000端口,访问http://www.example.com

官方文档关于 -D的介绍

-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding. This works by allocat‐
ing a socket to listen to port on the local side, optionally bound to the specified
bind_address. Whenever a connection is made to this port, the connection is forwarded
over the secure channel, and the application protocol is then used to determine where
to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are
supported, and ssh will act as a SOCKS server. Only root can forward privileged ports.
Dynamic port forwardings can also be specified in the configuration file.

特别注意,如果ssh -D 要启动的本地port已经被占用了是不会报错的,但是实际socks代理会没启动成功

本地转发 (-L)

本地转发(local forwarding)指的是,SSH 服务器作为中介的跳板机,建立本地计算机与特定目标网站之间的加密连接。本地转发是在本地计算机的 SSH 客户端建立的转发规则。

典型使用场景就是,打洞,经过跳板机访问无法直接连通的服务。

它会指定一个本地端口(local-port),所有发向那个端口的请求,都会转发到 SSH 跳板机(ssh-server),然后 SSH 跳板机作为中介,将收到的请求发到目标服务器(target-host)的目标端口(target-port)。

1
$ ssh -L :local-port:target-host:target-port ssh-server  //target-host是ssh-server的target-host, target-host 域名解析、路由都是由ssh-server完成

上面命令中,-L参数表示本地转发,local-port是本地端口,target-host是你想要访问的目标服务器,target-port是目标服务器的端口,ssh-server是 SSH 跳板机。当你访问localhost:local-port 的时候会通过ssh-server把请求转给target-host:target-port

img

上图对应的命令是:

1
ssh -L 53682:remote-server:53682 ssh-server

然后,访问本机的53682端口,就是访问remote-server的53682端口.

1
$ curl http://localhost:53682

注意,本地端口转发采用 HTTP 协议,不用转成 SOCKS5 协议。如果需要HTTP的动态代理,可以先起socks5动态代理,然后再起一个本地转发给动态代理的socks5端口,这样就有一个HTTP代理了,能给yum、docker之类的使用。

这个命令最好加上-N参数,表示不在 SSH 跳板机执行远程命令,让 SSH 只充当隧道。另外还有一个-f参数表示 SSH 连接在后台运行。

如果经常使用本地转发,可以将设置写入 SSH 客户端的用户个人配置文件。

1
2
Host test.example.com
LocalForward client-IP:client-port server-IP:server-port

远程转发(-R)

远程端口指的是在远程 SSH 服务器建立的转发规则。主要是执行ssh转发的机器别人连不上,所以需要一台client能连上的机器当远程转发端口,要不就是本地转发了。

由于本机无法访问内网 SSH 跳板机,就无法从外网发起 SSH 隧道,建立端口转发。必须反过来,从 SSH 跳板机发起隧道,建立端口转发,这时就形成了远程端口转发。

1
ssh -fNR 30.1.2.3:30081:166.100.64.1:3128 root@30.1.2.3 -p 2728

上面的命令,首先需要注意,不是在30.1.2.3 或者166.100.64.1 上执行的,而是找一台能联通 30.1.2.3 和166.100.64.1的机器来执行,在执行前Remote clients能连上 30.1.2.3 但是 30.1.2.3 和 166.100.64.1 不通,所以需要一个中介将 30.1.2.3 和166.100.64.1打通,这个中介就是下图中的MobaXterm所在的机器,命令在MobaXterm机器上执行

image-20210913163036410

执行上面的命令以后,跳板机30.1.2.3 到166.100.64.1的隧道已经建立了,这个隧道是依赖两边都能连通的MobaXterm机器。然后,就可以从Remote Client访问目标服务器了,即在Remote Client上执行下面的命令。

1
$ curl http://30.1.2.3:30081

执行上面的命令以后,命令就会输出服务器 166.100.64.1 的3128端口返回的内容。

如果经常执行远程端口转发,可以将设置写入 SSH 客户端的用户个人配置文件。

1
2
Host test.example.com
RemoteForward local-IP:local-port target-ip:target-port

注意远程转发需要:

  1. sshd_config里要打开AllowTcpForwarding选项,否则-R远程端口转发会失败。
  2. 默认转发到远程主机上的端口绑定的是127.0.0.1如要绑定0.0.0.0需要打开sshd_config里的GatewayPorts选项(然后ssh -R 后加上*:port )。这个选项如果由于权限没法打开也有办法,可配合ssh -L将端口绑定到0.0.0.0

开通远程转发后,如果需要动态代理(比如访问所有web服务),那么可以在30081端口机器上(30.1.2.3)执行:

1
nohup ssh -qTfnN -D *:13658 root@127.0.0.1 -p 30081 vmstat 10  >/dev/null 2>&1

表示在30081机器上(30.1.2.3)启动了一个socks5动态代理服务

调试转发、代理是否能联通

命令行调试

1
2
ssh -o 'ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p' admin@1.1.1.1
ssh -o 'ProxyCommand ssh root@5.5.5.5 nc -X 5 -x 127.0.0.1:1088 %h %p' root@1.1.1.1

curl

curl -I –socks5-hostname localhost:13659 twitter.com

curl -x socks5://localhost:13659 twitter.com

Suppose you have a socks5 proxy running on localhost:13659 .

In curl >= 7.21.7, you can use

1
curl -x socks5h://localhost:13659 http://www.google.com/

In a proxy string, socks5h:// and socks4a:// mean that the hostname is
resolved by the SOCKS server. socks5:// and socks4:// mean that the
hostname is resolved locally. socks4a:// means to use SOCKS4a, which is
an extension of SOCKS4. Let’s make urllib3 honor it.

In curl >= 7.18.0, you can use

1
curl --socks5-hostname localhost:13659 http://www.google.com/

–proxy 参数含义如下:

1
The --socks5 option is basically considered obsolete since curl 7.21.7. This is because starting in that release, you can now specify the proxy protocol directly in the string that you specify the proxy host name and port number with already. The server you specify with --proxy. If you use a socks5:// scheme, curl will go with SOCKS5 with local name resolve but if you instead use socks5h:// it will pick SOCKS5 with proxy-resolved host name.

wget

指定命令行参数,通过命令行指定HTTP代理服务器的方式如下:

wget -Y on -e “http_proxy=http://[HTTP_HOST]:[HTTP_PORT]http://facebook.com/其中:[HTTP_HOST]和[HTTP_PORT]是http proxy的ADDRESS和PORT。

-Y表示是否使用代理,on表示使用代理。

-e执行后面跟的命令,相当于在.wgetrc配置文件中添加了一条命令,将http_proxy设置为需要使用的代理服务器。

wget –limit-rate=2.5k 限制下载速度,进行测试

PKI (Public Key Infrastructure)证书

X.509 只是一种常用的证书格式,一般以PEM编码,PEM 编码的证书通常以 .pem.crt.cer 为后缀。再次提醒,这只是“通常”情况,实际上某些工具可能并不遵循这些惯例。通过pem证书可以访问需要认证的https服务(比如etcd、apiserver等)

  • ASN.1 用于定义数据类型,例如证书(certificate)和秘钥(key)——就像用 JSON 定义一个 request body —— X.509 用 ASN.1 定义。
  • DER 是一组将 ASN.1 编码成二进制(比特和字节)的编码规则(encoding rules)。
  • PKCS#7 and PKCS#12 是比 X.509 更大的数据结构(封装格式),也用 ASN.1 定义,其中能包含除了证书之外的其他东西。二者分别在 Java 和 Microsoft 产品中使用较多。
  • DER 编码之后是二进制数据,不方便复制粘贴,因此大部分证书都是用 PEM 编码的,它用 base64 对 DER 进行编码,然后再加上自己的 label。
  • 私钥通常用是 PEM 编码的 PKCS#8 对象,但有时也会用密码来加密。

通过命令 cat /etc/kubernetes/pki/ca.crt | openssl x509 -text 也可以得到下图信息

image

公钥、私钥常见扩展名

  • 公钥:.pub or .pemca.crt
  • 私钥:.prv, .key, or .pem , ca.key

证书生成过程演示

并不是所有的场景都需要向这些大型的 CA 机构申请公钥证书,在任何一个企业,组织或是团体内都可以自己形这样的“小王国”,也就是说,你可以自行生成这样的证书,只需要你自己保证自己的生成证书的私钥的安全,以及不需要扩散到整个互联网。下面,我们用 openssl命令来演示这个过程。

1)生成 CA 机构的证书(公钥) ca.crt 和私钥 ca.key

1
2
3
4
5
6
openssl req -newkey rsa:2048 \
-new -nodes -x509 \
-days 365 \
-out ca.crt \
-keyout ca.key \
-subj "/C=SO/ST=Earth/L=Mountain/O=CoolShell/OU=HQ/CN=localhost"
  1. 生成 alice 的私钥
1
openssl genrsa -out alice.key 2048

3)生成 Alice 的 CSR – Certificate Signing Request

1
2
openssl req -new -key alice.key -days 365 -out alice.csr \
-subj "/C=CN/ST=Beijing/L=Haidian/O=CoolShell/OU=Test/CN=localhost.alice"

4)使用 CA 给 Alice 签名证书

1
2
3
4
5
openssl x509  -req -in alice.csr \
-extfile <(printf "subjectAltName=DNS:localhost.alice") \
-CA ca.crt -CAkey ca.key \
-days 365 -sha256 -CAcreateserial \
-out alice.crt

参考资料:

http://docs.corp-inc.com/pages/editpage.action?pageId=203555361
https://wiki.archlinux.org/index.php/SSH_keys_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)

https://wangdoc.com/ssh/key.html

https://robotmoon.com/ssh-tunnels/

通过SSH动态转发来建立Socks代以及各种场景应用案例

https://daniel.haxx.se/blog/2020/05/26/curl-ootw-socks5/

SSH Performance

Why when I transfer a file through SFTP, it takes longer than FTP?

一行代码解决scp在Internet传输慢的问题

关于证书(certificate)和公钥基础设施(PKI)的一切

网络数字身份认证术

MySQL知识体系的三驾马车

在我看来要掌握好MySQL的话要理解好这三个东西:

  • 索引(B+树)
  • 日志(WAL)
  • 事务(可见性)

索引决定了查询的性能,也是用户感知到的数据库的关键所在,日常使用过程中抱怨最多的就是查询太慢了;

而日志是一个数据库的灵魂,他决定了数据库为什么可靠,还要保证性能,核心原理就是将随机写转换成顺序写;

事务则是数据库的皇冠。

索引

索引主要是解决查询性能的问题,数据一般都是写少查多,而且要满足各种查,所以使用数据库过程中最常见的问题就是索引的优化。

MySQL选择B+树来当索引的数据结构,是因为B+树的树干只有索引,能使得索引保持比较小,更容易加载到内存中;数据全部放在B+树的叶节点上,整个叶节点又是个有序双向链表,这样非常合适区间查找。

如果用平衡二叉树当索引,想象一下一棵 100 万节点的平衡二叉树,树高 20。一次查询可能需要访问 20 个数据块。在机械硬盘时代,从磁盘随机读一个数据块需要 10 ms 左右的寻址时间。也就是说,对于一个 100 万行的表,如果使用二叉树来存储,单独访问一个行可能需要 20 个 10 ms 的时间,这个查询可真够慢的

对比一下 InnoDB 的一个整数字段B+数索引为例,B+树的杈数一般是 1200。这棵树高是 4 的时候,就可以存 1200 的 3 次方个值,这已经 17 亿了。考虑到树根的数据块总是在内存中的,一个 10 亿行的表上一个整数字段的索引,查找一个值最多只需要访问 3 次磁盘。其实,树的第二层也有很大概率在内存中,那么访问磁盘的平均次数就更少了。

明确以下几点:

  • B+树是N叉树,以一个整数字段索引来看,N基本等于1200。数据库里的树高一般在2-4层。
  • 索引的树根节点一定在内存中,第二层大概率也在内存,再下层基本都是在磁盘中。
  • 每往下读一层就要进行一次磁盘IO。 从B+树的检索过程如下图所示:

image.png

每往下读一层就会进行一次磁盘IO,然后会一次性读取一些连续的数据放入内存中。

一个22.1G容量的表, 只需要高度为3的B+树就能存储,如果拓展到4层,可以存放25T的容量。但主要占内存的部分是叶子节点中的整行数据,非叶子节点全部加载到内存只需要18.8M。

B+树

MySQL的索引结构主要是B+树,也可以选hash

B+树特点:

  • 叶子结点才有数据,这些数据形成一个有序链表
  • 非叶子节点只有索引,导致非叶子节点小,查询的时候整体IO更小、更稳定(相对B数)
  • 删除相对B树快,因为数据有大量冗余,大部分时候不需要改非叶子节点,删除只需要从叶子节点中的链表中删除
  • B+树是多叉树,相对二叉树二分查找效率略低,但是树高度大大降低,减少了磁盘IO
  • 因为叶子节点的有序链表存在,支持范围查找

B+树的标准结构:

Image

innodb实现的B+树用了双向链表,节点内容存储的是页号(每页16K)

Image

联合索引

对于多个查询条件的复杂查询要正确建立多列的联合索引来尽可能多地命中多个查询条件,过滤性好的列要放在联合索引的前面。

MySQL一个查询只能用一个索引。

索引下推(index condition pushdown )

对于多个where条件的话,如果索引只能命中一个,剩下的那个条件过滤还是会通过回表来获取到后判断是否符合,但是MySQL5.6后,如果剩下的那个条件在联合索引上(但是因为第一个条件是模糊查询,没法用全联合索引),会将这个条件下推到索引判断上,来减少回表次数。这叫索引下推优化(index condition pushdown )

覆盖索引

要查询的列(select后面的列)如果都在索引上,那么这个查询的最终结果都可以直接从索引上读取到,这样读一次索引(数据小、顺序读)性能非常好。否则的话需要回表去获取别的列

前缀索引用不上覆盖索引对查询性能的优化,每次索引命中可能需要做一次回表,确认完整列值

回表

什么是回表?

select id, name from t where id>1 and id<10; 假设表t的id列是一个非主键的普通索引,那么这个查询就需要回表。查询执行的时候根据索引条件 id>1 and id<10 找到符合条件的行地址(主键),因为id索引上肯定有id的值,但是没有name,这里需要返回id,name 所以找到这些记录的地址后还需要回表(按主键)去取到name的值;

对应地如果select id from t where id>1 and id<10; 就不需要回表了,假设命中5条记录,这5个id的值都在索引上就能取到为啥还额外去回表呢?回表大概率是很慢的,因为你取到的行地址不一定连续,可能需要多次磁盘read

搞清楚概念后再来看count(*) 要不要回表?既然是统计数据,直接count主键(没有主键会自动添加一个默认隐藏的主键)就好了,多快好省。所以问题的本质是对回表不理解。count(*) 要不要回表不太重要,重要的是理解好什么是回表

那 select id, name from t where id>1 and id<10; 怎么样才能不回表呢?肯定是建立id name的联合索引就可以了

select * from table order by id limit 150000,10 这样limit后偏移很大一个值的查询,会因为回表导致非常慢。

这是因为根据id列上索引去查询过滤,但是select *要求查所有列的内容,但是索引上只有id的数据,所以导致每次对id索引进行过滤都要求去回表(根据id到表空间取到这个id行所有列的值),每一行都要回表导致这里出现了150000+10次随机磁盘读。

可以通过先用一个子查询(select id from order by id limit 150000,10),子查询中只查id列,而id的值都在索引上,用上了覆盖索引来避免回表。

先查到这10个id(扫描行数还是150000+10, 这里的limit因为有deleted记录、每行大小不一样等因素影响,没法一次跳到150000处。但是这次扫描150000行的时候不需要回表,所以速度快多了),然后再跟整个表做jion(join的时候只需要对这10个id行进行回表),来提升性能。

索引的一些其它知识点

多用自增主键是因为自增主键保证的是主键一直是增加的,也就是不会在索引中间插入,这样的话避免的索引页的分裂(代价很高)

写数据除了记录redo-log之外还会在内存(change buffer)中记录下修改后的数据,这样再次修改、读取的话不需要从磁盘读取数据,非唯一索引才能用上change buffer,因为唯一索引一定需要读磁盘验证唯一性,既然读过磁盘这个change buffer的意义就不大了。

1
mysql> insert into t(id,k) values(id1,k1),(id2,k2);//假设k1页在buffer中,k2不在

image.png

Buffer POOL

(1)缓冲池(buffer pool)是一种常见的降低磁盘访问的机制;

(2)缓冲池通常以页(page)为单位缓存数据;

(3)缓冲池的常见管理算法是LRU,memcache,OS,InnoDB都使用了这种算法;

(4)InnoDB对普通LRU进行了优化:

- 将缓冲池分为老生代和新生代,入缓冲池的页,优先进入老生代,页被访问,才进入新生代,以解决预读失效的问题

- 页被访问(预读的丢到old区),且在老生代**停留时间超过配置阈值(innodb_old_blocks_time)**的,才进入新生代,以解决批量数据访问,大量热数据淘汰的问题

图片

只有同时满足「被访问」与「在 old 区域停留时间超过 1 秒」两个条件,才会被插入到 young 区域头部

日志

数据库的关键瓶颈在于写,因为每次更新都要落盘防止丢数据,而磁盘最怕的就是随机写。

Write-Ahead logging(WAL)

写磁盘前先写日志,这样不用担心丢数据问题,写日志又是一个顺序写,性能比随机写好多了,这样将性能很差的随机写转换成了顺序写。然后每过一段时间将这些日志合并后真正写入到表空间,这次是随机写,但是有机会将多个写合并成一个,比如多个写在同一个Page上。

这是数据库优化的关键。

bin-log

MySQL Server用来记录执行修改数据的SQL,Replication基本就是复制并重放这个日志。有statement、row和混合模式三种。

bin-log保证不了表空间和bin-log的一致性,也就是断电之类的场景下是没法保证数据的一致性。

MySQL 日志刷新策略通过 sync_binlog 参数进行配置,其有 3 个可选配置:

  1. sync_binlog=0:MySQL 应用将完全不负责日志同步到磁盘,将缓存中的日志数据刷新到磁盘全权交给操作系统来完成;
  2. sync_binlog=1:MySQL 应用在事务提交前将缓存区的日志刷新到磁盘;
  3. sync_binlog=N:当 N 不为 0 与 1 时,MySQL 在收集到 N 个日志提交后,才会将缓存区的日志同步到磁盘。

redo-log

INNODB引擎用来保证事务的完整性,也就是crash-safe。MySQL 默认是保证不了不丢数据的,如果写了表空间还没来得及写bin-log就会造成主从数据不一致;或者在事务中需要执行多个SQL,bin-log保证不了完整性。

而在redo-log中任何修改都会先记录到redo-log中,即使断电MySQL重启后也会先检查redo-log将redo-log中记录了但是没有提交到表空间的数据进行提交(刷脏)

redo-log和bin-log的比较:

  • redo log 是 InnoDB 引擎特有的;binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。redo-log保证了crash-safe的问题,binlog只能用于归档,保证不了safe。
  • redo log 是物理日志,记录的是“在某个数据页上做了什么修改”;binlog 是逻辑日志,记录的是这个语句的原始逻辑,比如“给 ID=2 这一行的 c 字段加 1 ”。
  • redo log 是循环写的,空间固定会用完;binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。

redo-log中记录的是对页的操作,而不是修改后的数据页,buffer pool(或者说change buffer)中记录的才是数据页。正常刷脏是指的将change buffer中的脏页刷到表空间的磁盘,如果没来得及刷脏就崩溃了,那么就只能从redo-log来将没有刷盘的操作再执行一次让他们真正落盘。buffer pool中的任何变化都会写入到redo-log中(不管事务是否提交)

只有当commit(非两阶段的commit)的时候才会真正把redo-log写到表空间的磁盘上(不一定是commit的时候刷到表空间)。

如果机器性能很好(内存大、innodb_buffer_pool设置也很大,iops高),但是设置了比较小的innodb_logfile_size那么会造成redo-log很快会被写满,这个时候系统会停止所有更新,全力刷盘去推进ib_logfile checkpoint(位点),这个时候磁盘压力很小,但是数据库性能会出现间歇性下跌(select 反而相对更稳定了–更少的merge)。

redo-log要求数据量尽量少,这样写盘IO小;操作幂等(保证重放幂等)。实际逻辑日志(Logical Log, 也就是bin-log)的特点就是数据量小,而幂等则是基于Page的Physical Logging特点。最终redo-log的形式是Physiological Logging的方式,来兼得二者的优势。

所谓Physiological Logging,就是以Page为单位,但在Page内以逻辑的方式记录。举个例子,MLOG_REC_UPDATE_IN_PLACE类型的REDO中记录了对Page中一个Record的修改,方法如下:

(Page ID,Record Offset,(Filed 1, Value 1) … (Filed i, Value i) … )

其中,PageID指定要操作的Page页,Record Offset记录了Record在Page内的偏移位置,后面的Field数组,记录了需要修改的Field以及修改后的Value。

Innodb的默认Page大小是16K,OS文件系统默认都是4KB,对16KB的Page的修改保证不了原子性,因此Innodb又引入Double Write Buffer的方式来通过写两次的方式保证恢复的时候找到一个正确的Page状态。

InnoDB给每个REDO记录一个全局唯一递增的标号LSN(Log Sequence Number)。Page在修改时,会将对应的REDO记录的LSN记录在Page上(FIL_PAGE_LSN字段),这样恢复重放REDO时,就可以来判断跳过已经应用的REDO,从而实现重放的幂等。

binlog和redo-log一致性的保证

bin-log和redo-log的一致性是通过两阶段提交来保证的,bin-log作为事务的协调者,两阶段提交过程中prepare是非常重的,prepare一定会持久化(日志),记录如何commit和rollback,一旦prepare成功就一定能commit和rollback,如果其他节点commit后崩溃,恢复后会有一个协商过程,其它节点发现崩溃节点已经commit,所以会跟随commit;如果崩溃节点还没有prepare那么其它节点只能rollback。

实际崩溃后恢复时MySQL是这样保证redo-log和bin-log的完整性的:

  1. 如果redo-log里面的事务是完整的,也就是有了commit标识,那么直接提交
  2. 如果redo-log里面事务只有完整的prepare,则去检查事务对应的binlog是否完整
    1. 如果binlog完整则提交事务
    2. 如果不完整则回滚事务
  3. redo-log和binlog有一个共同的数据字段叫XID将他们关联起来

组提交

在没有开启binlog时,Redo log的刷盘操作将会是最终影响MySQL TPS的瓶颈所在。为了缓解这一问题,MySQL使用了组提交,将多个刷盘操作合并成一个,如果说10个事务依次排队刷盘的时间成本是10,那么将这10个事务一次性一起刷盘的时间成本则近似于1。

但是开启binlog后,binlog作为事务的协调者每次commit都需要落盘,这导致了Redo log的组提交失去了意义。

image-20211108152328424

Group Commit的方案中,其正确性的前提在于一个group内的事务没有并发冲突,因此即便并行也不会破坏事务的执行顺序。这个方案的局限性在于一个group 内的并行度仍然有限

刷脏

在内存中修改了,已经写入到redo-log中,但是还没来得及写入表空间的数据叫做脏页,MySQL过一段时间就需要刷脏,刷脏最容易造成MySQL的卡顿。

  • redo-log写满后,系统会停止所有更新操作,把checkpoint向前推进也就是将数据写入到表空间。这时写性能跌0,这个场景对性能影响最大
  • 系统内存不够,也需要将内存中的脏页释放,释放前需要先刷入到表空间。
  • 系统内存不够,但是redo-log空间够,也会刷脏,也就是刷脏不只是脏页写到redo-log,还要考虑读取情况。刷脏页后redo-log位点也一定会向前推荐
  • 系统空闲的时候也会趁机刷脏
  • 刷脏的时候默认还会连带刷邻居脏页(innodb_flush_neighbors)

当然如果一次性要淘汰的脏页太多,也会导致查询卡顿严重,可以通过设置innodb_io_capacity(一般设置成磁盘的iops),这个值越小的话一次刷脏页的数量越小,如果刷脏页速度还跟不上脏页生成速度就会造成脏页堆积,影响查询、更新性能。

在 MySQL 5.5 及以前的版本,回滚日志是跟数据字典一起放在 ibdata 文件里的,即使长事务最终提交,回滚段被清理,文件也不会变小。我见过数据只有 20GB,而回滚段有 200GB 的库。最终只好为了清理回滚段,重建整个库。

长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据,所以这个事务提交之前,数据库里面它可能用到的回滚记录都必须保留,这就会导致大量占用存储空间。除了对回滚段的影响,长事务还占用锁资源,也可能拖垮整个库。

表空间会刷进去没有提交的事务(比如大事务change buffer和redo-log都不够的时候),这个修改虽然在表空间中,但是通过可见性来控制是否可见。

落盘

innodb_flush_method 参数目前有 6 种可选配置值:

  1. fdatasync;
  2. O_DSYNC
  3. O_DIRECT
  4. O_DIRECT_NO_FSYNC
  5. littlesync
  6. nosync

其中,littlesync 与 nosync 仅仅用于内部性能测试,并不建议使用。

  • fdatasync,即取值 0,这是默认配置值。对 log files 以及 data files 都采用 fsync 的方式进行同步;
  • O_DSYNC,即取值 1。对 log files 使用 O_SYNC 打开与刷新日志文件,使用 fsync 来刷新 data files 中的数据;
  • O_DIRECT,即取值 4。利用 Direct I/O 的方式打开 data file,并且每次写操作都通过执行 fsync 系统调用的方式落盘;
  • O_DIRECT_NO_FSYNC,即取值 5。利用 Direct I/O 的方式打开 data files,但是每次写操作并不会调用 fsync 系统调用进行落盘;

为什么有 O_DIRECT 与 O_DIRECT_NO_FSYNC 配置的区别?

首先,我们需要理解更新操作落盘分为两个具体的子步骤:①文件数据更新落盘②文件元数据更新落盘。O_DIRECT 的在部分操作系统中会导致文件元数据不落盘,除非主动调用 fsync,为此,MySQL 提供了 O_DIRECT 以及 O_DIRECT_NO_FSYNC 这两个配置。

如果你确定在自己的操作系统上,即使不进行 fsync 调用,也能够确保文件元数据落盘,那么请使用 O_DIRECT_NO_FSYNC 配置,这对 MySQL 性能略有帮助。否则,请使用 O_DIRECT,不然文件元数据的丢失可能会导致 MySQL 运行错误。

Double Write

MySQL默认数据页是16k,而操作系统内核的页目前为4k。因此当一个16k的MySQL页写入过程中突然断电,可能只写入了一部分,即数据存在不一致的情况。MySQL为了防止这种情况,每写一个数据页时,会先写在磁盘上的一个固定位置,然后再写入到真正的位置。如果第二次写入时掉电,MySQL会从第一次写入的位置恢复数据。开启double write之后数据被写入两次,如果能将其优化掉,对用户的性能将会有不小的提升。

MySQL 8.0关掉Double Write能有5%左右的性能提升

事务

在 MySQL/InnoDB 中,使用MVCC(Multi Version Concurrency Control) 来实现事务。每个事务修改数据之后,会创建一个新的版本,用事务id作为版本号;一行数据的多个版本会通过指针连接起来,通过指针即可遍历所有版本。

当事务读取数据时,会根据隔离级别选择合适的版本。例如对于 Read Committed 隔离级别来说,每条SQL都会读取最新的已提交版本;而对于Repeatable Read来说,会在事务开始时选择已提交的最新版本,后续的每条SQL都会读取同一个版本的数据。

img

Postgres用Old to New,INNODB使用的是New to Old, 即主表存最新的版本,用链表指向旧的版本。当读取最新版本数据时,由于索引直接指向了最新版本,因此较低;与之相反,读取旧版本的数据代价会随之增加,需要沿着链表遍历。

INNODB中旧版本的数据存储于undo log中。这里的undo log起到了几个目的,一个是事务的回滚,事务回滚时从undo log可以恢复出原先的数据,另一个目的是实现MVCC,对于旧的事务可以从undo 读取旧版本数据。

可见性

是基于事务的隔离级别而言的,常用的事务的隔离级别有可重复读RR(Repeatable Read,MySQL默认的事务隔离级别)和读已提交RC(Read Committed)。

可重复读

读已提交:A事务能读到B事务已经commit了的结果,即使B事务开始时间晚于A事务

重复读的定义:一个事务启动的时候,能够看到所有已经提交的事务结果。但是之后,这个事务执行期间,其他事务的更新对它不可见。

指的是在一个事务中先后两次读到的结果是一样的,当然这两次读的中间自己没有修改这个数据,如果自己修改了就是当前读了。

如果两次读过程中,有一个别的事务修改了数据并提交了,第二次读到的还是别的事务修改前的数据,也就是这个修改后的数据不可见,因为别的事务在本事务之后。

如果一个在本事务启动之后的事务已经提交了,本事务会读到最新的数据,但是因为隔离级别的设置,会要求MySQL判断这个数据不可见,这样只能按照undo-log去反推修改前的数据,如果有很多这样的已经提交的事务,那么需要反推很多次,也会造成卡顿。

总结下,可见性的关键在于两个事务开始的先后关系:

  • 如果是可重复读RR(Repeatable Read),后开始的事务提交的结果对前面的事务可见
  • 如果是读已提交RC(Read Committed),后开始的事务提交的结果对前面的事务可见

当前读

一句话区别:加锁的读 = 当前读;不加锁的读 = 快照读。

1
2
3
4
5
6
7
快照读(Consistent Read)
普通 SELECT → 快照读

当前读(Current Read)
SELECT ... FOR UPDATE → 当前读(加写锁)
SELECT ... LOCK IN SHARE MODE → 当前读(加读锁)
UPDATE / DELETE / INSERT → 当前读

更新数据都是先读后写的,而这个读,只能读当前的值,称为”当前读“(current read)。除了 update 语句外,select 语句如果加锁,也是当前读。

事务的可重复读的能力是怎么实现的?

可重复读的核心就是一致性读(consistent read);而事务更新数据的时候,只能用当前读。如果当前的记录的行锁被其他事务占用的话,就需要进入锁等待。

而读提交的逻辑和可重复读的逻辑类似,它们最主要的区别是:

  • 在可重复读隔离级别下,只需要在事务开始的时候创建一致性视图,之后事务里的其他查询都共
    用这个一致性视图;
  • 在读提交隔离级别下,每一个语句执行前都会重新算出一个新的视图。

幻读

幻读指的是一个事务中前后两次读到的数据不一致(读到了新插入的行)

可重复读是不会出现幻读的,但是更新数据时只能用当前读,当前读要求读到其它事务的修改(新插入行)

Innodb 引擎为了解决「可重复读」隔离级别使用「当前读」而造成的幻读问题,就引出了 next-key 锁,就是记录锁和间隙锁的组合。

  • 记录锁,锁的是记录本身;
  • 间隙锁,锁的就是两个值之间的空隙,以防止其他事务在这个空隙间插入新的数据,从而避免幻读现象。

可重复读、当前读以及行锁案例

案例表结构

1
2
3
4
5
6
7

mysql> CREATE TABLE `t` (
`id` int(11) NOT NULL,
`k` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);

上表执行如下三个事务

img

begin/start transaction 命令并不是一个事务的起点,在执行到它们之后的第一个操作 InnoDB 表的语句,事务才真正启动。如果你想要马上启动一个事务,可以使用 start transaction with consistent snapshot 这个命令。

“start transaction with consistent snapshot; ”的意思是从这个语句开始,创建一个持续整个事务的一致性快照

在读提交隔离级别(RC)下,这个用法就没意义了,等效于普通的 start transaction。

因为以上案例是RR(start transaction with consistent snapshot;), 也就是可重复读隔离级别。

那么事务B select到的K是3,因为事务C已提交,事务B update的时候不会等锁了,同时update必须要做当前读,这是因为update不做当前读而是可重复性读的话读到的K是1,这样覆盖了事务C的提交!也就是更新数据伴随的是当前读。

事务A开始在事务C之前, 而select是可重复性读,所以事务C提交了但是对A不可见,也就是select要保持可重复性读仍然读到的是1.

如果这个案例改成RC,事务B看到的还是3,事务A看到的就是2了(这个2是事务C提交的),因为隔离级别是RC。select 执行时间点事务才开始。

MySQL和PG事务实现上的差异

这两个数据库对MVCC实现上选择了不同方案,上面讲了MySQL选择的是redo-log去反推多个事务的不同数据,这个方案实现简单。但是PG选择的是保留多个不同的数据版本,优点就是查询不同版本数据效率高,缺点就是对这些数据要做压缩、合并之类的。

总结

理解好索引是程序员是否掌握数据库的最关键知识点,理解好索引才会写出更高效的SQL,避免慢查询搞死MySQL。

对日志的理解可以看到一个数据库为了提升性能(刷磁盘的瓶颈)采取的各种手段。也是最重要的一些设计思想所在。

事务则是数据库皇冠。

参考资料

https://explainextended.com/2009/10/23/mysql-order-by-limit-performance-late-row-lookups/ 回表

https://stackoverflow.com/questions/1243952/how-can-i-speed-up-a-mysql-query-with-a-large-offset-in-the-limit-clause

Linux Network Stack

文章目标

从一个网络包进到网卡后续如何流转,进而了解中间有哪些关键参数可以控制他们,有什么工具能帮忙可以看到各个环节的一些指征,以及怎么调整他们。

接收流程

接收流程大纲

在开始收包之前,也就是OS启动的时候,Linux要做许多的准备工作:

  1. 创建ksoftirqd线程,为它设置好它自己的线程函数,用来处理软中断
  2. 协议栈注册,linux要实现许多协议,比如arp,icmp,ip,udp,tcp,每一个协议都会将自己的处理函数注册一下,方便包来了迅速找到对应的处理函数
  3. 网卡驱动初始化,每个驱动都有一个初始化函数,内核会让驱动也初始化一下。在这个初始化过程中,把自己的DMA准备好,把NAPI的poll函数地址告诉内核
  4. 启动网卡,分配RX,TX队列,注册中断对应的处理函数

以上是内核准备收包之前的重要工作,当上面都ready之后,就可以打开硬中断,等待数据包的到来了。

当数据到来了以后,第一个迎接它的是网卡:

  1. 网卡将数据帧DMA到内存的RingBuffer中,然后向CPU发起中断通知
  2. CPU响应中断请求,调用网卡启动时注册的中断处理函数
  3. 中断处理函数几乎没干啥,就发起了软中断请求
  4. 内核线程ksoftirqd线程发现有软中断请求到来,先关闭硬中断
  5. ksoftirqd线程开始调用驱动的poll函数收包
  6. poll函数将收到的包送到协议栈注册的ip_rcv函数中
  7. ip_rcv函数再讲包送到udp_rcv函数中(对于tcp包就送到tcp_rcv)

详细接收流程

  1. 网络包进到网卡,网卡驱动校验MAC,看是否扔掉,取决是否是混杂 promiscuous mode
  2. 网卡在启动时会申请一个接收ring buffer,其条目都会指向一个skb的内存。
  3. DMA完成数据报文从网卡硬件到内存到拷贝
  4. 网卡发送一个中断通知CPU。
  5. CPU执行网卡驱动注册的中断处理函数,中断处理函数只做一些必要的工作,如读取硬件状态等,并把当前该网卡挂在NAPI的链表中;
  6. Driver “触发” soft IRQ(NET_RX_SOFTIRQ (其实就是设置对应软中断的标志位)
  7. CPU中断处理函数返回后,会检查是否有软中断需要执行。因第6步设置了NET_RX_SOFTIRQ,则执行报文接收软中断。
  8. 在NET_RX_SOFTIRQ软中断中,执行NAPI操作,回调第5步挂载的驱动poll函数。
  9. 驱动会对interface进行poll操作,检查网卡是否有接收完毕的数据报文。
  10. 将网卡中已经接收完毕的数据报文取出,继续在软中断进行后续处理。注:驱动对interface执行poll操作时,会尝试循环检查网卡是否有接收完毕的报文,直到系统设置的net.core.netdev_budget上限(默认300),或者已经就绪报文。
  11. net_rx_action
  12. 内核分配 sk_buff 内存
  13. 内核填充 metadata: 协议等,移除 ethernet 包头信息
  14. 将skb 传送给内核协议栈 netif_receive_skb
  15. __netif_receive_skb_core:将数据送到抓包点(tap)或协议层(i.e. tcpdump)// 出抓包点:dev_queue_xmit_nit
  16. 进入到由 netdev_max_backlog 控制的qdisc
  17. 开始 ip_rcv 处理流程,主要处理ip协议包头相关信息
  18. 调用内核 netfilter 框架(iptables PREROUTING)
  19. 进入L4 protocol tcp_v4_rcv
  20. 找到对应的socket
  21. 根据 tcp_rmem 进入接收缓冲队列
  22. 内核将数据送给接收的应用

http://arthurchiao.art/blog/linux-net-stack-implementation-rx-zh:

image-20220725164331535

TAP 处理点就是 tcpdump 抓包、流量过滤。

注意:netfilter 或 iptables 规则都是在软中断上下文中执行的, 数量很多或规则很复杂时会导致网络延迟

软中断:可以把软中断系统想象成一系列内核线程(每个 CPU 一个),这些线程执行针对不同 事件注册的处理函数(handler)。如果你用过 top 命令,可能会注意到 ksoftirqd/0 这个内核线程,其表示这个软中断线程跑在 CPU 0 上。

硬中断发生在哪一个核上,它发出的软中断就由哪个核来处理。可以通过加大网卡队列数,这样硬中断工作、软中断工作都会有更多的核心参与进来。

__napi_schedule干两件事情,一件事情是把struct napi_struct 挂到struct softnet_data 上,注意softnet_data是一个per cpu变量,换句话说,软中断结构是挂在触发硬中断的同一个CPU上;另一件事情是调用__raise_softirq_irqoff 把irq_stat的__softirq_pending 字段置位,irq_stat 也是个per cpu 变量,表示当前这个cpu上有软中断待处理。

Image

从上图可以看到tcpdump在协议栈之前,也就是netfilter过滤规则对tcpdump无效,发包则是反过来:

Image

img

典型的接收堆栈

img

undefined

从四层协议栈来看收包流程

image.png

DMA驱动部分流程图

DMA是一个硬件逻辑,数据传输到系统物理内存的过程中,全程不需要CPU的干预,除了占用总线之外(期间CPU不能使用总线),没有任何额外开销。

img

img

image.png

  1. 驱动在内存中分配一片缓冲区用来接收数据包,叫做sk_buffer;
  2. 将上述缓冲区的地址和大小(即接收描述符),加入到rx ring buffer。描述符中的缓冲区地址是DMA使用的物理地址;
  3. 驱动通知网卡有一个新的描述符;
  4. 网卡从rx ring buffer中取出描述符,从而获知缓冲区的地址和大小;
  5. 网卡收到新的数据包;
  6. 网卡将新数据包通过DMA直接写到sk_buffer中。

Linux network queues overview

linux network queues

可以通过perf来监控包的堆栈:

1
perf trace --no-syscalls --event 'net:*' ping baidu.com -c1

buffer和流控

影响发送的速度的几个buffer和queue,接收基本一样

img

网卡传递数据包到内核的流程图及参数

软中断NET_TX_SOFTIRQ的处理函数为net_tx_action,NET_RX_SOFTIRQ的为net_rx_action

image.png

在网络子系统初始化中为NET_RX_SOFTIRQ注册了处理函数net_rx_action。所以net_rx_action函数就会被执行到了。

image.png

这里需要注意一个细节,硬中断中设置软中断标记,和ksoftirq的判断是否有软中断到达,都是基于smp_processor_id()的。这意味着只要硬中断在哪个CPU上被响应,那么软中断也是在这个CPU上处理的。所以说,如果你发现你的Linux软中断CPU消耗都集中在一个核上的话,做法是要把调整硬中断的CPU亲和性,来将硬中断打散到不同的CPU核上去。

软中断(也就是 Linux 里的 ksoftirqd 进程)里收到数据包以后,发现是 tcp 的包的话就会执行到 tcp_v4_rcv 函数。如果是 ESTABLISHED 状态下的数据包,则最终会把数据拆出来放到对应 socket 的接收队列中。然后调用 sk_data_ready 来唤醒用户进程。

对应的堆栈(本堆栈有问题,si%打满):

image-20211210160634705

igb_fetch_rx_bufferigb_is_non_eop的作用就是把数据帧从RingBuffer上取下来。为什么需要两个函数呢?因为有可能帧要占多个RingBuffer,所以是在一个循环中获取的,直到帧尾部。获取下来的一个数据帧用一个sk_buff来表示。收取完数据以后,对其进行一些校验,然后开始设置sbk变量的timestamp, VLAN id, protocol等字段。接下来进入到napi_gro_receive中,里面还会调用关键的 netif_receive_skb, 在netif_receive_skb中,数据包将被送到协议栈中,上图中的tcp_v4_rcv就是其中之一(tcp协议)

发送流程

  1. 应用调 sendmsg
  2. 数据拷贝到sk_write_queue上的最后一个skb中,如果该skb指向的数据区已经满了,则调用sk_stream_alloc_skb创建一个新的skb,并挂到这个sk_write_queue上
  3. TCP 分片 skb_buff
  4. 根据 tcp_wmem 缓存需要发送的包
  5. 构造TCP包头(src/dst port)
  6. ipv4 调用 tcp_write_xmit 和 tcp_transmit_skb
  7. ip_queue_xmit, 构建 ip 包头(获取目标ip和port,找路由)
  8. 进入 netfilter 流程 nf_hook(),iptables规则在这里生效
  9. 路由流程 POST_ROUTING,iptables 的nat和mangle表会在这里设置规则,对数据包进行一些修改
  10. ip_output 分片
  11. 进入L2 dev_queue_xmit,tc 网络流控在这里
  12. 填入 txqueuelen 队列
  13. 进入发送 Ring Buffer tx
  14. 驱动触发软中断 soft IRQ (NET_TX_SOFTIRQ)

在传输层的出口函数tcp_transmit_skb中,会对这个skb进行克隆(skb_clone),克隆得到的子skb和原先的父skb 指向共同的数据区。并且会把struct skb_shared_info的dataref 的计数加一。

传输层以下各层处理的skb 实际就是这个克隆出来的skb,而原先的skb保留在TCP连接的发送队列上。

克隆skb再经过协议栈层层处理后进入到驱动程序的RingBuffer 中。随后网卡驱动真正将数据发送出去,当发送完成时,由硬中断通知 CPU,然后由中断处理程序来清理 RingBuffer中指向的skb。注意,这里只释放了这个skb结构本身,而skb指向的数据区,由于dataref而不会被释放。要等到TCP层接收到ACK后,再释放父skb的同时,释放数据区。

比如ip_queue_xmit发现无法路由到目标地址,就会丢弃发送包,这里丢弃的是克隆包,原始包还在发送队列里,所以TCP层就会在定时器到期后进行重传

发包卡顿

内核从3.16开始有这样一个机制,在生成的一个新的重传报文前,先判断之前的报文的是否还在qdisc里面,如果在,就避免生成一个新的报文。

也就是对内核而言这个包发送了但是没收到ack,但实际这个包还在本机qdisc queue或者driver queue里,所以没必要重传

对应的监控计数:

1
2
#netstat -s |grep -i spur
TCPSpuriousRtxHostQueues: 4163

这个发包过程在发送端实际抓不到这个包,因为还没有真正发送,而是在发送端的queue里排队,但是对上层应用来说包发完了(回包ack也不需要应用来感知),所以抓包看起来正常,就是应用感觉卡了(卡的原因还是包在发送端内核 queue 排队,一般是 pfifo_fast bug bug2

关于 TCPSpuriousRtxHostQueues 指标的作用:

Host queues (Qdisc + NIC) can hold packets so long that TCP can
eventually retransmit a packet before the first transmit even left
the host.

Its not clear right now if we could avoid this in the first place :

  • We could arm RTO timer not at the time we enqueue packets, but
    at the time we TX complete them (tcp_wfree())

  • Cancel the sending of the new copy of the packet if prior one
    is still in queue.

This patch adds instrumentation so that we can at least see how
often this problem happens.

TCPSpuriousRtxHostQueues SNMP counter is incremented every time
we detect the fast clone is not yet freed in tcp_transmit_skb()

发包卡死

一个Linux 内核 bug 导致的 TCP连接卡死

从四层协议栈来看发包流程

image.png

发包流程对应源代码:

Image

net.core.dev_weight 用来调整 __qdisc_run 的循环处理权重,调大后也就是 __netif_schedule 更多的被调用执

另外发包默认是系统调用完成的(占用 sy cpu),只有在包太多,为了避免系统调用长时间占用 CPU 导致应用层卡顿,这个时候内核给了发包时间一个quota(net.core.dev_weight 参数来控制),用完后即使包没发送完也退出发包的系统调用,队列中未发送完的包留待 tx-softirq 来发送(这是占用 si cpu)

tcp在做tcp_sendmsg 的时候会将应用层msg做copy到内核层的skb,在调用网络层执行tcp_transmit_skb 会将这个 skb再次copy交给网络层,内核态的skb继续保留直到收到ack。

tcp_transmit_skb 还会设置tcp头,在skb中 tcp头、ip头内存都预留好了,只需要填写内容。

然后就是ip层,主要是分包、路由控制,然后就是netfilter(比如iptables规则匹配)。再然后进入neighbour(arp) , 获取mac后进入网络层

sudo ifconfig eth0 txqueuelen ** 来控制qdisc 发送队列长度

image-20210714204347862

粗略汇总一下进出堆栈:

image.png

http://docshare02.docshare.tips/files/21804/218043783.pdf 中也有描述:

img

软中断

一般net_rx 远大于net_tx, 如下所示,这是因为每个包发送完成后还需要清理回收内存(释放 skb),这是通过硬中断触发 rx-softirq 来完成的,无论是收包、还是发送包完毕都是触发这个rx-softirq。

1
2
3
4
5
6
#cut /proc/softirqs -c 1-70
CPU0 CPU1 CPU2 CPU3 CPU4
HI: 3 0 0 0 0
TIMER: 1616454419 1001992045 1013647869 1366481348 884639123
NET_TX: 168326 1717390 7000 6083 5748
NET_RX: 771543422 132283770 96912580 77533029 85143572

发送的时候如果 net.core.dev_weight 配额够的话直接通过系统调用就将包发送完毕,不需要触发软中断

内核相关参数

Ring Buffer

Ring Buffer位于NIC和IP层之间,是一个典型的FIFO(先进先出)环形队列。Ring Buffer没有包含数据本身,而是包含了指向sk_buff(socket kernel buffers)的描述符。
可以使用ethtool -g eth0查看当前Ring Buffer的设置:

$sudo ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:		256
RX Mini:	0
RX Jumbo:	0
TX:		256
Current hardware settings:
RX:		256
RX Mini:	0
RX Jumbo:	0
TX:		256

上面的例子是一个小规格的ECS,接收队列、传输队列都为256。

$sudo ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:		4096
RX Mini:	0
RX Jumbo:	0
TX:		4096
Current hardware settings:
RX:		4096
RX Mini:	0
RX Jumbo:	0
TX:		512

这是一台物理机,接收队列为4096,传输队列为512。接收队列已经调到了最大,传输队列还可以调大。队列越大丢包的可能越小,但数据延迟会增加

调整 Ring Buffer 队列数量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 8
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 8

sudo ethtool -L eth0 combined 8
sudo ethtool -L eth0 rx 8

网卡多队列就是指的有多个RingBuffer,每个RingBufffer可以由一个core来处理

image.png

网卡各种统计数据查看

ethtool -S eth0 | grep errors

ethtool -S eth0 | grep rx_ | grep errors //查看网卡是否丢包,一般是ring buffer太小

//监控
ethtool -S eth0 | grep -e "err" -e "drop" -e "over" -e "miss" -e "timeout" -e "reset" -e "restar" -e "collis" -e "over" | grep -v "\: 0"

网卡进出队列大小调整

//查看目前的进出队列大小
ethtool -g eth0
//修改进出队列
ethtool -G eth0 rx 8192 tx 8192

要注意如果设置的值超过了允许的最大值,用默认的最大值,一些ECS之类的虚拟机、容器就不允许修改这个值。

txqueuelen

ifconfig 看到的 txqueuelen 跟Ring Buffer是两个东西,IP协议下面就是 txqueuelen,txqueuelen下面才到Ring Buffer.

常用的tc qdisc、netfilter就是在txqueuelen这一环节。 qdisc 的队列长度是我们用 ifconfig 来看到的 txqueuelen

发送队列就是指的这个txqueuelen,和网卡关联着。 而每个Core接收队列由内核参数: net.core.netdev_max_backlog来设置

1
2
3
4
5
//当前值通过ifconfig可以查看到,修改:
ifconfig eth0 txqueuelen 2000
//监控
ip -s link
ip -s link show enp2s0f0

如果txqueuelen 太小导致数据包被丢弃的情况,这类问题可以通过下面这个命令来观察:

1
2
3
4
5
6
7
8
9
10
11
$ ip -s -s link ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:16:3e:12:9b:c0 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
13189414480980 22529315912 0 0 0 0
RX errors: length crc frame fifo missed
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
15487121408466 12925733540 0 0 0 0
TX errors: aborted fifo window heartbeat transns
0 0 0 0 2

如果观察到 dropped 这一项不为 0,那就有可能是 txqueuelen 太小导致的。当遇到这种情况时,你就需要增大该值了,比如增加 eth0 这个网络接口的 txqueuelen:

$ ifconfig eth0 txqueuelen 2000

Interrupt Coalescence (IC) - rx-usecs, tx-usecs, rx-frames, tx-frames (hardware IRQ)

可以通过降低终端的频率,也就是合并硬中断来提升处理网络包的能力,当然这是以增大网络包的延迟为代价。

	//检查
	$ethtool -c eth0
	Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 1
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 256

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
	//修改, 
	ethtool -C eth0 rx-usecs value tx-usecs value
	//监控
	cat /proc/interrupts

我们来说一下上述结果的大致含义

  • Adaptive RX: 自适应中断合并,网卡驱动自己判断啥时候该合并啥时候不合并

  • rx-usecs:当过这么长时间过后,一个RX interrupt就会被产生。How many usecs to delay an RX interrupt after a packet arrives.

  • rx-frames:当累计接收到这么多个帧后,一个RX interrupt就会被产生。Maximum number of data frames to receive before an RX interrupt.

  • rx-usecs-irq: How many usecs to delay an RX interrupt while an interrupt is being serviced by the host.

  • rx-frames-irq: Maximum number of data frames to receive before an RX interrupt is generated while the system is servicing an interrupt.

Ethtool 绑定端口

ntuple filtering for steering network flows

一些网卡支持 “ntuple filtering” 特性。该特性允许用户(通过 ethtool )指定一些参数来在硬件上过滤收到的包,然后将其直接放到特定的 RX queue。例如,用户可以指定到特定目端口的 TCP 包放到 RX queue 1。

Intel 的网卡上这个特性叫 Intel Ethernet Flow Director,其他厂商可能也有他们的名字,这些都是出于市场宣传原因,底层原理是类似的。

我们后面会看到,ntuple filtering 是一个叫 Accelerated Receive Flow Steering(aRFS) 功能的核心部分之一,后者使得 ntuple filtering 的使用更加方便。

这个特性适用的场景:最大化数据本地性(data locality),以增加 CPU 处理网络数据时的缓存命中率。例如,考虑运行在 80 口的 web 服务器:

  1. webserver 进程运行在 80 口,并绑定到 CPU 2
  2. 和某个 RX queue 关联的硬中断绑定到 CPU 2
  3. 目的端口是 80 的 TCP 流量通过 ntuple filtering 绑定到 CPU 2
  4. 接下来所有到 80 口的流量,从数据包进来到数据到达用户程序的整个过程,都由 CPU 2 处理
  5. 仔细监控系统的缓存命中率、网络栈的延迟等信息,以验证以上配置是否生效

检查 ntuple filtering 特性是否打开:

1
2
3
4
5
$ sudo ethtool -k eth0
Offload parameters for eth0:
...
ntuple-filters: off
receive-hashing: on

可以看到,上面的 ntuple 是关闭的。

打开:

1
$ sudo ethtool -K eth0 ntuple on

打开 ntuple filtering 功能,并确认打开之后,可以用 ethtool -u 查看当前的 ntuple
rules:

1
2
3
$ sudo ethtool -u eth0
40 RX rings available
Total 0 rules

可以看到当前没有 rules。

我们来加一条:目的端口是 80 的放到 RX queue 2

1
2
3
4
$ sudo ethtool -U eth0 flow-type tcp4 dst-port 80 action 2

删除
ethtool -U eth0 delete 1023

你也可以用 ntuple filtering 在硬件层面直接 drop 某些 flow 的包。当特定 IP 过来的流量太大时,这种功能可能会派上用场。更多关于 ntuple 的信息,参 考 ethtool man page。

软中断合并 GRO

GRO和硬中断合并的思想很类似,不过阶段不同。硬中断合并是在中断发起之前,而GRO已经到了软中断上下文中了。

如果应用中是大文件的传输,大部分包都是一段数据,不用GRO的话,会每次都将一个小包传送到协议栈(IP接收函数、TCP接收)函数中进行处理。开启GRO的话,Linux就会智能进行包的合并,之后将一个大包传给协议处理函数。这样CPU的效率也是就提高了。

1
2
# ethtool -k eth0 | grep generic-receive-offload
generic-receive-offload: on

如果你的网卡驱动没有打开GRO的话,可以通过如下方式打开。

1
# ethtool -K eth0 gro on

这是收包,发包对应参数是GSO

ifconfig 监控指标

  • RX overruns: overruns意味着数据包没到Ring Buffer就被网卡物理层给丢弃了,而CPU无法及时的处理中断是造成Ring Buffer满的原因之一,例如中断分配的不均匀。或者Ring Buffer太小导致的(很少见),overruns数量持续增加,建议增大Ring Buffer ,使用ethtool ‐G 进行设置。
  • RX dropped: 表示数据包已经进入了Ring Buffer,但是由于内存不够等系统原因,导致在拷贝到内存的过程中被丢弃。如下四种情况导致dropped:Softnet backlog full(pfmemalloc && !skb_pfmemalloc_protocol(skb)–分配内存失败);Bad / Unintended VLAN tags;Unknown / Unregistered protocols;IPv6 frames
  • RX errors:表示总的收包的错误数量,这包括 too-long-frames 错误,Ring Buffer 溢出错误,crc 校验错误,帧同步错误,fifo overruns 以及 missed pkg 等等。

overruns

当驱动处理速度跟不上网卡收包速度时,驱动来不及分配缓冲区,NIC接收到的数据包无法及时写到sk_buffer,就会产生堆积,当NIC内部缓冲区写满后,就会丢弃部分数据,引起丢包。这部分丢包为rx_fifo_errors,在 /proc/net/dev中体现为fifo字段增长,在ifconfig中体现为overruns指标增长。

监控指标 /proc/net/softnet_stat

Important details about /proc/net/softnet_stat:

  • Each line of /proc/net/softnet_stat corresponds to a struct softnet_data structure, of which there is 1 per CPU.
  • The values are separated by a single space and are displayed in hexadecimal
  • The first value, sd->processed, is the number of network frames processed. This can be more than the total number of network frames received if you are using ethernet bonding. There are cases where the ethernet bonding driver will trigger network data to be re-processed, which would increment the sd->processed count more than once for the same packet.
  • The second value, sd->dropped, is the number of network frames dropped because there was no room on the processing queue. More on this later.
  • The third value, sd->time_squeeze, is (as we saw) the number of times the net_rx_action loop terminated because the budget was consumed or the time limit was reached, but more work could have been. Increasing the budget as explained earlier can help reduce this. time_squeeze 计数在内核中只有一个地方会更新(比如内核 5.10),如果看到监控中有 time_squeeze 升高, 那一定就是执行到了以上 budget 用完的逻辑
  • The next 5 values are always 0.
  • The ninth value, sd->cpu_collision, is a count of the number of times a collision occurred when trying to obtain a device lock when transmitting packets. This article is about receive, so this statistic will not be seen below.
  • The tenth value, sd->received_rps, is a count of the number of times this CPU has been woken up to process packets via an Inter-processor Interrupt
  • The last value, flow_limit_count, is a count of the number of times the flow limit has been reached. Flow limiting is an optional Receive Packet Steering feature that will be examined shortly.

对应的代码实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
// https://github.com/torvalds/linux/blob/v5.10/net/core/net-procfs.c#L172
static int softnet_seq_show(struct seq_file *seq, void *v) {
struct softnet_data *sd = v;

seq_printf(seq,
"%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n",
sd->processed, sd->dropped, sd->time_squeeze, 0,
0, 0, 0, 0, /* was fastroute */
0, /* was cpu_collision */
sd->received_rps, flow_limit_count,
softnet_backlog_len(sd), (int)seq->index);
return 0;
}

net.core.netdev_budget

一次软中断(ksoftirqd进程)能处理包的上限,有就多处理,处理到300个了一定要停下来让CPU能继续其它工作。单次poll 收包是所有注册到这个 CPU 的 NAPI 变量收包数量之和不能大于这个阈值。

1
sysctl net.core.netdev_budget //3.10 kernel默认300, The default value of the budget is 300. This will cause the SoftIRQ process to drain 300 messages from the NIC before getting off the CPU

如果 /proc/net/softnet_stat 第三列一直在增加的话需要,表示SoftIRQ 获取的CPU时间太短,来不及处理足够多的网络包,那么需要增大这个值,当这个值太大的话有可能导致包到了内核但是应用(userspace)抢不到时间片来读取这些packet。

增大和查看 net.core.netdev_budget

sysctl -a | grep net.core.netdev_budget
sysctl -w net.core.netdev_budget=400 //临时性增大

早期的时候网卡一般是10Mb的,现在基本都是10Gb的了,还是每一次软中断、上下文切换只处理一个包的话代价太大,需要改进性能。于是引入的NAPI,一次软中断会poll很多packet

image.png

来源 This is much faster, but brings up another problem. What happens if we have so many packets to process that we spend all our time processing packets from the NIC, but we never have time to let the userspace processes actually drain those queues (read from TCP connections, etc.)? Eventually the queues would fill up, and we’d start dropping packets. To try and make this fair, the kernel limits the amount of packets processed in a given softirq context to a certain budget. Once this budget is exceeded, it wakes up a separate thread called ksoftirqd (you’ll see one of these in ps for each core) which processes these softirqs outside of the normal syscall/interrupt path. This thread is scheduled using the standard process scheduler, which already tries to be fair.

于是在Poll很多packet的时候有可能网卡队列一直都有包,那么导致这个Poll动作无法结束,造成应用一直在卡住状态,于是可以通过netdev_max_backlog来设置Poll多少Packet后停止Poll以响应用户请求。

image.png

一旦出现slow syscall(如上图黄色部分慢)就会导致packet处理被延迟。

发送包的时候系统调用循环发包,占用sy,只有当发包系统quota用完的时候,循环退出,剩下的包通过触发软中断的形式继续发送,此时占用si

netdev_max_backlog

The netdev_max_backlog is a queue within the Linux kernel where traffic is stored after reception from the NIC, but before processing by the protocol stacks (IP, TCP, etc). There is one backlog queue per CPU core.

如果 /proc/net/softnet_stat 第二列一直在增加的话表示netdev backlog queue overflows. 需要增大 netdev_max_backlog

增大和查看 netdev_max_backlog:
sysctl -a |grep netdev_max_backlog
sysctl -w net.core.netdev_max_backlog=1024 //临时性增大

netdev_max_backlog(接收)和txqueuelen(发送)相对应

softnet_stat

关于/proc/net/softnet_stat 的重要细节:

  1. 每一行代表一个 struct softnet_data 变量。因为每个 CPU core 都有一个该变量,所以每行 其实代表一个 CPU core
  2. 每列用空格隔开,数值用 16 进制表示
  3. 第一列 sd->processed,是处理的网络帧的数量。如果你使用了 ethernet bonding, 那这个值会大于总的网络帧的数量,因为 ethernet bonding 驱动有时会触发网络数据被 重新处理(re-processed)
  4. 第二列,sd->dropped,是因为处理不过来而 drop 的网络帧数量。后面会展开这一话题
  5. 第三列,sd->time_squeeze,前面介绍过了,由于 budget 或 time limit 用完而退出 net_rx_action 循环的次数
  6. 接下来的 5 列全是 0
  7. 第九列,sd->cpu_collision,是为了发送包而获取锁的时候有冲突的次数
  8. 第十列,sd->received_rps,是这个 CPU 被其他 CPU 唤醒去收包的次数
  9. 最后一列,flow_limit_count,是达到 flow limit 的次数。flow limit 是 RPS 的特性, 后面会稍微介绍一下

TCP协议栈Buffer

	sysctl -a | grep net.ipv4.tcp_rmem   // receive
	sysctl -a | grep net.ipv4.tcp_wmem   // send
	//监控
	cat /proc/net/sockstat

接收Buffer

$netstat -sn | egrep "prune|collap"; sleep 30; netstat -sn | egrep "prune|collap"
17671 packets pruned from receive queue because of socket buffer overrun
18671 packets pruned from receive queue because of socket buffer overrun

如果 “pruning” 一直在增加很有可能是程序中调用了 setsockopt(SO_RCVBUF) 导致内核关闭了动态调整功能,或者压力大,缓存不够了。具体Case:https://blog.cloudflare.com/the-story-of-one-latency-spike/

nstat也可以看到比较多的数据

1
2
3
4
5
6
7
8
9
10
11
$nstat -z |grep -i drop
TcpExtLockDroppedIcmps 0 0.0
TcpExtListenDrops 0 0.0
TcpExtTCPBacklogDrop 0 0.0
TcpExtPFMemallocDrop 0 0.0
TcpExtTCPMinTTLDrop 0 0.0
TcpExtTCPDeferAcceptDrop 0 0.0
TcpExtTCPReqQFullDrop 0 0.0
TcpExtTCPOFODrop 0 0.0
TcpExtTCPZeroWindowDrop 0 0.0
TcpExtTCPRcvQDrop 0 0.0

总体简略接收包流程

image-20210511114834433

带参数版收包流程:

image.png

总体简略发送包流程

带参数版发包流程:

image.png

网络包流转结构图

跨机器网络IO

Image

lo 网卡

127.0.0.1(lo)本机网络 IO ,无需走到物理网卡,也不用进入RingBuffer驱动队列,但是还是要走内核协议栈,直接把 skb 传给接收协议栈(经过软中断)

Image

总的来说,本机网络 IO 和跨机 IO 比较起来,确实是节约了一些开销。发送数据不需要进 RingBuffer 的驱动队列,直接把 skb 传给接收协议栈(经过软中断)。但是在内核其它组件上,可是一点都没少,系统调用、协议栈(传输层、网络层等)、网络设备子系统、邻居子系统整个走了一个遍。连“驱动”程序都走了(虽然对于回环设备来说只是一个纯软件的虚拟出来的东东)。所以即使是本机网络 IO,也别误以为没啥开销,实际本机访问自己的eth0 ip也是走的lo网卡和访问127.0.0.1是一样的,测试用ab分别走127.0.0.1和eth0压nginx,在nginx进程跑满,ab还没满两者的nginx单核都是7万TPS左右,跨主机压nginx的单核也是7万左右(要调多ab的并发数)。

如果是同一台宿主机走虚拟bridge通信的话(同一宿主机下的不容docker容器通信):

Image

ab 压 nginx单核(intel 8163 绑核)
127.0.0.1 Requests per second: 69498.96 [#/sec] (mean)
Time per request: 0.086 [ms] (mean)
Eth0 Requests per second: 70261.93 [#/sec] (mean)
Time per request: 0.085 [ms] (mean)
跨主机压 Requests per second: 70119.05 [#/sec] (mean)
Time per request: 0.143 [ms] (mean)

ab不支持unix domain socket,如果增加ab和nginx之间的时延,QPS急剧下降,但是增加ab的并发数完全可以把QPS拉回去。

Unix Domain Socket工作原理

接收connect 请求的时候,会申请一个新 socket 给 server 端将来使用,和自己的 socket 建立好连接关系以后,就放到服务器正在监听的 socket 的接收队列中。这个时候,服务器端通过 accept 就能获取到和客户端配好对的新 socket 了。

Image

主要的连接操作都是在这个函数中完成的。和我们平常所见的 TCP 连接建立过程,这个连接过程简直是太简单了。没有三次握手,也没有全连接队列、半连接队列,更没有啥超时重传。

直接就是将两个 socket 结构体中的指针互相指向对方就行了。就是 unix_peer(newsk) = sk 和 unix_peer(sk) = newsk 这两句。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
//file: net/unix/af_unix.c
static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr,
int addr_len, int flags)
{
struct sockaddr_un *sunaddr = (struct sockaddr_un *)uaddr;

// 1. 为服务器侧申请一个新的 socket 对象
newsk = unix_create1(sock_net(sk), NULL);

// 2. 申请一个 skb,并关联上 newsk
skb = sock_wmalloc(newsk, 1, 0, GFP_KERNEL);
...

// 3. 建立两个 sock 对象之间的连接
unix_peer(newsk) = sk;
newsk->sk_state = TCP_ESTABLISHED;
newsk->sk_type = sk->sk_type;
...
sk->sk_state = TCP_ESTABLISHED;
unix_peer(sk) = newsk;

// 4. 把连接中的一头(新 socket)放到服务器接收队列中
__skb_queue_tail(&other->sk_receive_queue, skb);
}

//file: net/unix/af_unix.c
#define unix_peer(sk) (unix_sk(sk)->peer)

收发包过程和复杂的 TCP 发送接收过程相比,这里的发送逻辑简单简单到令人发指。申请一块内存(skb),把数据拷贝进去。根据 socket 对象找到另一端,直接把 skb 给放到对端的接收队列里了

Image

Unix Domain Socket和127.0.0.1通信相比,如果包的大小是1K以内,那么性能会有一倍以上的提升,包变大后性能的提升相对会小一些。

Image

Image

再来一个整体流转矢量图:

image-20211116101345648

案例

snat/dnat 宿主机port冲突,丢包

image-20230726101807001

  1. snat 就是要把 192.168.1.10和192.168.1.11的两个连接替换成宿主机的ip:port

  2. 主要是在宿主机找可用port分别给这两个连接用

  3. 找可用port分两步

    • 找到可用port
      
    • 将可用port写到数据库,后面做连接追踪用(conntrack)
      
  4. 上述两步不是事务,可能两个连接同时找到一个相同的可用port,但是只有第一个能写入成功,第二个fail,fail后这个包被扔掉

  5. 1秒钟后被扔掉的包重传,后续正常

症状:

  • 问题发生概率不高,跟压力没有关系,跟容器也没有关系,只要有snat/dnat和并发就会发生,只发生在创建连接的第一个syn包

  • 可以通过conntrack工具来检查fail的数量

  • 实际影响只是请求偶尔被拉长了1秒或者3秒

  • snat规则创建的时候增加参数:NF_NAT_RANGE_PROTO_RANDOM_FULLY 来将冲突降低几个数量级—-可以认为修复了这个问题

      sudo conntrack -L -d ip-addr
    

来自:https://tech.xing.com/a-reason-for-unexplained-connection-timeouts-on-kubernetes-docker-abd041cf7e02

容器(bridge)通过udp访问宿主机服务失败

image.png

这个案例主要是讲述回包的逻辑,如果是tcp,那么用dest ip当自己的source ip,如果是UDP,无连接状态信息,那么会根据route来选择一块网卡(上面的IP) 来当source ip

来自:http://cizixs.com/2017/08/21/docker-udp-issue
https://github.com/moby/moby/issues/15127

参考资料

The Missing Man Page for ifconfig–关于ifconfig的种种解释

Linux数据报文的来龙去脉

linux-network-performance-parameters

Linux之TCPIP内核参数优化

https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf

Linux 网络协议栈收消息过程-Ring Buffer : 支持 RSS 的网卡内部会有多个 Ring Buffer,NIC 收到 Frame 的时候能通过 Hash Function 来决定 Frame 该放在哪个 Ring Buffer 上,触发的 IRQ 也可以通过操作系统或者手动配置 IRQ affinity 将 IRQ 分配到多个 CPU 上。这样 IRQ 能被不同的 CPU 处理,从而做到 Ring Buffer 上的数据也能被不同的 CPU 处理,从而提高数据的并行处理能力。

Linux 网络栈监控和调优:发送数据

Linux 网络栈监控和调优:接收数据(2016) 英文版

收到包后内核层面的处理:从网卡注册软中断处理函数到收包逻辑

收到包后应用和协议层面的处理:图解 | 深入理解高性能网络开发路上的绊脚石 - 同步阻塞网络 IOhttps://mp.weixin.qq.com/s/cIcw0S-Q8pBl1-WYN0UwnA 当软中断上收到数据包时会通过调用 sk_data_ready 函数指针(实际被设置成了 sock_def_readable()) 来唤醒在 sock 上等待的进程

http://docshare02.docshare.tips/files/21804/218043783.pdf

https://wiki.linuxfoundation.org/networking/kernel_flow

https://upload.wikimedia.org/wikipedia/commons/thumb/3/37/Netfilter-packet-flow.svg/2000px-Netfilter-packet-flow.svg.png

https://wiki.nix-pro.com/view/Packet_journey_through_Linux_kernel

https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data/

美团redis丢包,调整多队列,绑核,软中断绑定node0

网络通不通是个大问题–半夜鸡叫

半夜鸡叫

凌晨啊,还有同学在为网络为什么不通的问题搏斗着:

undefined

问题描述大概如下:

slb后面配了一台realserver(就叫172吧), 在172上通过curl http://127.0.0.1:80/ 是正常的(说明服务自身是正常的)
如果从开发同学的笔记本直接curl slb-ip 就卡住了,进一步发现如果从北京的办公网curl slb-ip就行,但是从杭州的curl slb-ip就不行。

从杭州curl的时候在172上抓包如下:
undefined

明显可以看到tcp握手包正确到达了172,但是172一直没有回复。也就是如果是杭州访问服务的话,服务端收到握手请求后直接扔掉没有任何回复(回想下哪些场景会扔包)

问题排查

先排除了iptables的问题

略过

route 的嫌疑

因为北京可以杭州不行,明显是某些IP可以,于是检查route 表,解决问题的必杀技(基础知识)都在这里

发现杭州的ip和北京的ip确实命中了不同的路由规则,简单说就是172绑在eth0上,机器还有另外一块网卡eth1. 而回复杭州ip的时候要走eth1. 至于为什么没有从eth1回复等会再说

知道原因就好说了,修改一下route,让eth0成为默认路由,这样北京、杭州都能走eth0进出了

所以到这里,问题描述如下:
undefined

机器有两块网卡,请求走eth0 进来(绿线),然后走 eth1回复(路由决定的,红线),但是实际没走eth1回复,像是丢包了。

解决办法

修改一下route,让eth0成为默认路由,这样北京、杭州都能走eth0进出了

为什么5U的机器可以

开发同学接着反馈,出问题的172是7U2的系统,但是还有一些5U7的机器完全正常,5U7的机器上也是两块网卡,route规则也是一样的。

这确实诡异,看着像是7U的内核行为跟5U不一致,咨询了内核同学,让检查一下 rp_filter 参数。果然看到7U2的系统默认 rp_filter 开着,而5U7是关着的,于是反复开关这个参数稳定重现了问题

1
sysctl -w net.ipv4.conf.eth0.rp_filter=0 

rp_filter 原理和监控

rp_filter参数用于控制系统是否开启对数据包源地址的校验, 收到包后根据source ip到route表中检查是否否和最佳路由,否的话扔掉这个包【可以防止DDoS,攻击等】

​ 0:不开启源地址校验。
​ 1:开启严格的反向路径校验。对每个进来的数据包,校验其反向路径是否是最佳路径。如果反向路径不是最佳路径,则直接丢弃该数据包。
​ 2:开启松散的反向路径校验。对每个进来的数据包,校验其源地址是否可达,即反向路径是否能通(通过任意网口),如果反向路径不通,则直接丢弃该数据包。

那么对于这种丢包,可以打开日志:/proc/sys/net/ipv4/conf/eth0/log_martians 来监控到:

undefined

rp_filter: IP Reverse Path Filter, 在ip层收包的时候检查一下反向路径是不是最优路由,代码位置:

ip_rcv->NF_HOOK->ip_rcv_finish->ip_rcv_finish_core

也就是rp_filter在收包的流程中检查每个进来的包,是不是符合rp_filter规则,而不是回复的时候来做判断,这也就是为什么抓包只能看到进来的syn就没有然后了

开启rp_filter参数的作用

  • 减少DDoS攻击: 校验数据包的反向路径,如果反向路径不合适,则直接丢弃数据包,避免过多的无效连接消耗系统资源。
  • 防止IP Spoofing: 校验数据包的反向路径,如果客户端伪造的源IP地址对应的反向路径不在路由表中,或者反向路径不是最佳路径,则直接丢弃数据包,不会向伪造IP的客户端回复响应。

通过netstat -s来观察IPReversePathFilter

$netstat -s | grep -i filter
	IPReversePathFilter: 35428
$netstat -s | grep -i filter
	IPReversePathFilter: 35435

能明显看到这个数字在增加,如果没开rp_filter 就看不到这个指标或者数值不变

undefined

问题出现的时候,尝试过用 watch -d -n 3 ‘netstat -s’ 来观察过哪些指标在变化,只是变化的指标太多,留意不过来,或者只是想着跟drop、route有关的参数

1
2
3
4
$netstat -s |egrep -i "drop|route"
12 dropped because of missing route
30 SYNs to LISTEN sockets dropped
InNoRoutes: 31

当时观察到这几个指标,都没有变化,实际他们看着像但是都跟rp_filter没关系,最后我打算收藏如下命令保平安:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
$netstat -s |egrep -i "drop|route|overflow|filter|retran|fails|listen"
12 dropped because of missing route
30 times the listen queue of a socket overflowed
30 SYNs to LISTEN sockets dropped
IPReversePathFilter: 35435
InNoRoutes: 31

$nstat -z -t 1 | egrep -i "drop|route|overflow|filter|retran|fails|listen"
IpOutNoRoutes 0 0.0
TcpRetransSegs 20 0.0
Ip6InNoRoutes 0 0.0
Ip6OutNoRoutes 0 0.0
Icmp6InRouterSolicits 0 0.0
Icmp6InRouterAdvertisements 0 0.0
Icmp6OutRouterSolicits 0 0.0
Icmp6OutRouterAdvertisements 0 0.0
TcpExtLockDroppedIcmps 0 0.0
TcpExtArpFilter 0 0.0
TcpExtListenOverflows 0 0.0
TcpExtListenDrops 0 0.0
TcpExtTCPPrequeueDropped 0 0.0
TcpExtTCPLostRetransmit 0 0.0
TcpExtTCPFastRetrans 0 0.0
TcpExtTCPForwardRetrans 0 0.0
TcpExtTCPSlowStartRetrans 0 0.0
TcpExtTCPBacklogDrop 0 0.0
TcpExtTCPMinTTLDrop 0 0.0
TcpExtTCPDeferAcceptDrop 0 0.0
TcpExtIPReversePathFilter 2 0.0
TcpExtTCPTimeWaitOverflow 0 0.0
TcpExtTCPReqQFullDrop 0 0.0
TcpExtTCPRetransFail 0 0.0
TcpExtTCPOFODrop 0 0.0
TcpExtTCPFastOpenListenOverflow 0 0.0
TcpExtTCPSynRetrans 10 0.0
IpExtInNoRoutes 0 0.0

如果客户端建立连接的时候抛异常,可能的原因(握手失败,建不上连接):

  • 网络不通,诊断:ping ip
  • 端口不通, 诊断:telnet ip port
  • rp_filter 命中(rp_filter=1, 多网卡环境), 诊断: netstat -s | grep -i filter ;
  • snat/dnat的时候宿主机port冲突,内核会扔掉 syn包。 troubleshooting: sudo conntrack -S | grep insert_failed //有不为0的
  • 全连接队列满的情况,诊断: netstat -s | egrep “listen|LISTEN”
  • syn flood攻击, 诊断:同上
  • 若远端服务器的内核参数 net.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_timestamps 的值都为 1,则远端服务器会检查每一个报文中的时间戳(Timestamp),若 Timestamp 不是递增的关系,不会响应这个报文。配置 NAT 后,远端服务器看到来自不同的客户端的源 IP 相同,但 NAT 前每一台客户端的时间可能会有偏差,报文中的 Timestamp 就不是递增的情况。nat后的连接,开启timestamp。因为快速回收time_wait的需要,会校验时间该ip上次tcp通讯的timestamp大于本次tcp(nat后的不同机器经过nat后ip一样,保证不了timestamp递增),诊断:是否有nat和是否开启了timestamps
  • NAT 哈希表满导致 ECS 实例丢包 nf_conntrack full

总结

本质原因就是服务器开启了 rp_filter 为1,严格校验进出包是否走同一块网卡,而如果请求从杭州机房发过来的话,回复包的路由走的是另外一块网卡,触发了内核的rp_filter扔包逻辑。

改server的路由可以让杭州的包也走同一块网卡,就不扔掉了。当然将 rp_filter 改成0 关掉这个校验逻辑也可以完全避免这个扔包。

从问题的解决思路来说,基本都可以认定是握手的时候服务器扔包了。只有知道 rp_filter 参数的内核老司机可以直接得出是这里的原因。如果对于一个新手的话还是得掌握如何推理分析得到原因。

就是要你懂网络–一个网络包的旅程


写在最前面的

我相信你脑子里关于网络的概念都在下面这张图上,但是乱成一团麻,这就是因为知识没有贯通、没有实践、没有组织

image.png

上面的概念在RFC1180中讲的无比的通熟易懂和连贯,但是抱歉,当时你也许看懂了,但是一个月后又忘记了,或者碰到问题才发现之前即使觉得看懂了的东西实际没懂,我发现大多人看 RFC1180、教科书基本当时都能看到,但就是一到实践就不会了,这里的鸿沟我分析应该就是缺少实践认知。

所以这篇文章希望解决书本知识到实践的贯通,希望把网络概念之间的联系通过实践来组织起来

从一个网络ping不通的问题开始

当时的网络链路是(大概是这样,略有简化):

容器1->容器1所在物理机1->交换机->物理机2
  • 从容器1 ping 物理机2 不通;
  • 从物理机1上的容器2 ping物理机2 通;
  • 物理机用一个vlan,容器用另外一个vlan
  • 交换机都做了trunk,让两个vlan都允许通过(肯定没问题,因为容器2是通的)
  • 同时发现即使是通的,有的容器 ping物理机1只需要0.1ms,有的容器需要200ms以上(都在同一个交换机下),不合理
  • 所有容器 ping 其它外网IP反而是通的

这个问题扯了一周是因为容器的网络是我们自己配置的,交换机我们没有权限接触,由客户配置。出问题的时候都会觉得自己没问题对方有问题,另外就是对网络基本知识认识不够所以都觉得自己没问题。

这个问题的答案在大家看完本文的基础知识后会总结出来。

开始前大家先想想,假如有个面试题是:输入 ping IP后 敲回车,然后发生了什么?

route 路由表

$route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0     10.125.15.254   0.0.0.0 UG0  00 eth0
10.0.0.0    10.125.15.254   255.0.0.0   UG0  00 eth0
10.125.0.0  0.0.0.0 255.255.240.0   U 0  00 eth0
11.0.0.0    10.125.15.254   255.0.0.0   UG0  00 eth0
30.0.0.0    10.125.15.254   255.0.0.0   UG0  00 eth0
100.64.0.0  10.125.15.254   255.192.0.0 UG0  00 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002   00 eth0
172.16.0.0  10.125.15.254   255.240.0.0 UG0  00 eth0
172.17.0.0  0.0.0.0 255.255.0.0 U 0  00 docker0
192.168.0.0 10.125.15.254   255.255.0.0 UG0  00 eth0

假如你现在在这台机器上ping 172.17.0.2 根据上面的route表得出 172.17.0.2这个IP匹配到下面这条路由:

172.17.0.0  0.0.0.0 255.255.0.0 U 0  00 docker0

那么ping 包会从docker0这张网卡发出去。

但是如果是ping 10.125.4.4 根据路由规则应该走eth0这张网卡。

也就是:route/路由表 来帮我们匹配目标地址(一个目标地址只能匹配一条路由,匹配不到就报no route to host 错误)

现在根据路由我们已经知道目标ip将要走哪个网卡出去,接下来就要判断目标IP是否在同一个子网了

ifconfig

首先来看看这台机器的网卡情况:

$ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
    inet 172.17.42.1  netmask 255.255.0.0  broadcast 0.0.0.0
    ether 02:42:49:a7:dc:ba  txqueuelen 0  (Ethernet)
    RX packets 461259  bytes 126800808 (120.9 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 462820  bytes 103470899 (98.6 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 10.125.3.33  netmask 255.255.240.0  broadcast 10.125.15.255
    ether 00:16:3e:00:02:67  txqueuelen 1000  (Ethernet)
    RX packets 280918095  bytes 89102074868 (82.9 GiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 333504217  bytes 96311277198 (89.6 GiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    loop  txqueuelen 0  (Local Loopback)
    RX packets 1077128597  bytes 104915529133 (97.7 GiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 1077128597  bytes 104915529133 (97.7 GiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

这里有三个IP,三个子网掩码(netmask),根据目标路由走哪张网卡,得到这个网卡的子网掩码,来计算目标IP是否在这个子网内。

如果目标ip在子网内,那就是大家说的在同一个二层网络,直连可以通;如果目标ip和本机不在同一个子网那么本机只管将网络包发给本机网关,剩下的由网关按照以上逻辑不停地往外走直到发送给目标机器(也就是网关拿到这个包后先查自己的路由,然后按照路由扔给下一跳)

直连可通的意思是:本机发广播包对方能收到,这个时候就要来到ARP 广播找对方机器的Mac地址了(如果不是同一个二层,就是转发给网关,那么这里同样也是ARP 广播找网关机器的Mac–本机和网关一定在同一个子网)

ARP协议

网络包在物理层传输的时候依赖的mac 地址而不是上面目的的IP地址,也就是根据mac地址来决定把包发到哪里去。

ARP 协议就是查询某个IP地址的mac地址是多少,由于这种对应关系一般不太变化,所以每个os都有一份arp缓存(一般15分钟过期),也可以手工清理,下面是arp缓存的内容:

$arp -a
e010125011202.bja.tbsite.net (10.125.11.202) at 00:16:3e:01:c2:00 [ether] on eth0
? (10.125.15.254) at 0c:da:41:6e:23:00 [ether] on eth0
v125004187.bja.tbsite.net (10.125.4.187) at 00:16:3e:01:cb:00 [ether] on eth0
e010125001224.bja.tbsite.net (10.125.1.224) at 00:16:3e:01:64:00 [ether] on eth0
v125009121.bja.tbsite.net (10.125.9.121) at 00:16:3e:01:b8:ff [ether] on eth0
e010125009114.bja.tbsite.net (10.125.9.114) at 00:16:3e:01:7c:00 [ether] on eth0
v125012028.bja.tbsite.net (10.125.12.28) at 00:16:3e:00:fb:ff [ether] on eth0
e010125005234.bja.tbsite.net (10.125.5.234) at 00:16:3e:01:ee:00 [ether] on eth0

进入正题,ping后回车后发生什么

首先 OS需要把ping命令封成一个icmp包,需要填上包头(包括IP、mac地址),那么OS先根据目标IP和本机的route规则计算使用哪个interface(网卡),每条路由规则基本都包含目标IP范围、网关、网卡这样几个基本元素。

如果目标IP在同一子网

如果目标IP和本机IP是同一个子网(根据本机ifconfig上的每个网卡的netmask来判断),并且本机arp缓存没有这条IP对应的mac记录,那么给整个子网的所有机器广播发送一个 arp查询

比如我ping 10.125.3.42,然后tcpdump抓包看到的arp请求:

$sudo tcpdump -i eth0  arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:22:01.792501 ARP, Request who-has e010125003042.bja.tbsite.net tell e010125003033.bja, length 28
16:22:01.792566 ARP, Reply e010125003042.bja.tbsite.net is-at 00:16:3e:01:8d:ff (oui Unknown), length 28

Host to Host through a Switch - Switch Functions animation

上面就是本机发送广播消息,10.125.3.42的mac地址是多少,很快10.125.3.42回复了自己的mac地址。
收到这个回复后,先缓存起来,下个ping包就不需要再次arp广播了。
然后将这个mac地址填写到ping包的包头的目标Mac(icmp包),然后发出这个icmp request包,同一个子网,按照MAC地址,正确到达目标机器,然后对方正确回复icmp reply【对方回复也要查路由规则,arp查发送放的mac,这样回包才能正确路由回来,略过】。

来看一次完整的ping 10.125.3.43,tcpdump抓包结果:

$sudo tcpdump -i eth0  arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:25:15.195401 ARP, Request who-has e010125003043.bja.tbsite.net tell e010125003033.bja, length 28
16:25:15.195459 ARP, Reply e010125003043.bja.tbsite.net is-at 00:16:3e:01:0c:ff (oui Unknown), length 28
16:25:15.211505 IP e010125003033.bja > e010125003043.bja.tbsite.net: ICMP echo request, id 27990, seq 1, length 64
16:25:15.212056 IP e010125003043.bja.tbsite.net > e010125003033.bja: ICMP echo reply, id 27990, seq 1, length 64

接着再 ping 一次同一个IP地址,arp有缓存了就看不到arp广播查询过程了。

如果目标IP不是同一个子网

arp只是同一子网广播查询,如果目标IP不是同一子网的话就要经过本IP网关就行转发,如果本机没有缓存网关mac(一般肯定缓存了),那么先发送一次arp查询网关的mac,然后流程跟上面一样,只是这个icmp包发到网关上去了(mac地址填写的是网关的mac)

从本机10.125.3.33 ping 11.239.161.60的过程,因为不是同一子网按照路由规则匹配,根据route表应该走10.125.15.254这个网关,如下截图:

image.png

首先是目标IP 11.239.161.60 符合最上面红框中的路由规则,又不是同一子网,所以查找路由规则中的网关10.125.15.254的Mac地址,arp cache中有,于是将 0c:da:41:6e:23:00 填入包头,那么这个icmp request包就发到10.125.15.254上了,虽然包头的mac是 0c:da:41:6e:23:00,但是IP还是 11.239.161.60.

看看目标IP 11.239.161.60 的真正mac信息(跟ping包包头的Mac是不同的):

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 11.239.161.60  netmask 255.255.252.0  broadcast 11.239.163.255
    ether 00:16:3e:00:04:c4  txqueuelen 1000  (Ethernet)

这个包根据Mac地址路由到了网关上

网关接下来怎么办

为了简化问题,假设两个网关直连

网关收到这个包后(因为mac地址是她的),打开一看IP地址是 11.239.161.60,不是自己的,于是继续查自己的route和arp缓存,发现11.239.161.60这个IP的网关是11.239.163.247,于是把包的目的mac地址改成11.239.163.247的mac继续发出去。

11.239.163.247这个网关收到包后,一看 11.239.161.60是自己同一子网的IP,于是该arp广播找mac就广播,cache有就拿cache的,然后这个包才最终到达目的11.239.161.60上。

整个过程中目标mac地址每一跳都在变,IP地址不变,每经过一次变化可以简单理解从一跳。

实际上可能要经过多个网关多次跳跃才能真正到达目标机器

目标收到这个icmp包后的回复过程一样,略过。

arp广播风暴和arp欺骗

广播风暴:如果一个子网非常大,机器非常多,每次arp查询都是广播的话,也容易因为N*N的问题导致广播风暴。

arp欺骗:同样如果一个子网中的某台机器冒充网关或者其他机器,当收到arp查询的时候总是把自己的mac冒充目标机器的mac发给你,然后你的包先走到他,为了不被发现达到自己的目的后再转发给真正的网关或者机器,所以在里面都点什么手脚,看看你发送的内容都还是很容易的

讲完基础再来看开篇问题的答案

分别在两个物理机上抓包

在物理机2上抓包:

image.png

tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
f4:0f:1b:ae:15:fb > 18:66:da:f0:15:90, ethertype 802.1Q (0x8100), length 102: vlan 134, p 0, ethertype IPv4, (tos 0x0, ttl 63, id 5654, offset 0, flags [DF], proto ICMP (1), length 84)
10.159.43.162 > 10.159.43.1: ICMP echo request, id 6285, seq 1, length 64
18:66:da:f0:15:90 > 00:00:0c:9f:f0:86, ethertype 802.1Q (0x8100), length 102: vlan 134, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 21395, offset 0, flags [none], proto ICMP (1), length 84)
10.159.43.1 > 10.159.43.162: ICMP echo reply, id 6285, seq 1, length 64

这个抓包能看到核心证据,ping包有到达物理机2,同时物理机2也正确回复了(mac、ip都对)

同时在物理机1上抓包只能看到ping包出去,回包没有到物理机1(所以回包肯定不会到容器里了)

所以问题的核心在交换机没有正确把物理机2的回包送到物理机1上面。

同时观察到的不正常延时:
image.png

过程中的其它测试:

  1. 新拿出一台物理机配置上不通的容器的IP,这是通的,所以客户坚持是容器网络的配置;
  2. 怀疑不通的IP所使用的mac地址冲突,在交换机上清理了交换机的arp缓存,没有帮助,还是不通

对于1能通,我认为这个测试不严格,新物理机所用的mac不一样,并且所接的交换机口也不一样,影响了测试结果。

最终的原因

最后在交换机上分析包没正确发到物理机1上的原因跟客户交换机使用了HSRP(热备份路由器协议,就是多个交换机HA高可用,也就是同一子网可以有多个网关的IP),停掉HSRP后所有IP容器都能通了,并且前面的某些容器延时也恢复正常了。

通俗点说就是HSRP把回包拐跑了,有些回包拐跑了又送回来了(延时200ms那些)

至于HSRP为什么会这么做,要厂家出来解释了。

大概结构如下图:

undefined

关于HSRP和VRRP

VRRP是虚拟路由冗余协议的简称,这个协议的目的是为了让多台路由器共同组成一个虚拟路由器,从而解决单点故障。

使用VRRP的网络架构大致如上面这个图所示,其中Master和Slave共同组成了一个虚拟路由器,这台虚拟路由器的IP是1.1.1.1,同时还会有一个虚拟的mac地址,所有主机的默认网关IP都将设置成1.1.1.1。

假设主机H1需要对外发送数据,在发送IP数据包时主机H1需要知道1.1.1.1这个IP对应的物理地址,因此H1会向外广播一个ARP请求,询问1.1.1.1这个IP数据包对应的物理地址。此时,Master将会负责响应这个APR请求,将虚拟的mac地址报告给主机H1,主机H1就用这个物理地址发送IP数据包。

当IP数据包到达交换机Switch A的时候,Switch A需要知道应该把这个数据包转发到哪条链路去,这个时候Switch A也会广播一个ARP请求,看看哪条链路会响应这个ARP请求。同样,Master会响应这个ARP请求,从而Switch A就知道了应该把数据包从自己的eth0对应的这条链路转发出去。此时,Master就是真正负责整个网络对外通信的路由器。

当Master出现故障的时候,通过VRRP协议,Slave可以感知到这个故障(通过类似于心跳的方式),这个时候Slave会主动广播一个ARP消息,告诉Switch A应该从eth1对应的链路转发物理地址是虚拟mac地址的数据包。这样就完成了主备路由器的切换,这个过程对网络中的主机来说是透明的。

通过VRRP不仅可以实现1主1备的部署,还可以实现1主多备的部署。在1主多备的部署结构下,当Master路由器出现故障,多个Backup路由器会通过选举的方式产生一个新的Master路由器,由这个Master路由器来响应ARP请求。

除了利用VRRP屏蔽单点故障之外,还可以实现负载均衡。在主备部署的情况下,Backup路由器其实是空转的,并不负责数据包的路由工作,这样显然是有点浪费的。此时,为了让Backup也负责一部分的路由工作,可以将两台路由器配制成互为主备的模式,这样就形成了两台虚拟路由器,网络中的主机可以选择任意一台作为默认网关。这种互为主备的模式也可以应用到1主多备的部署方式下。比如由3台路由器,分别是R1,R2和R3,用这3台路由器可以组成3台虚拟路由器,一台虚拟路由器以R1为Master,R2和R3为Backup路由器,另外一台以R2为Master,R1和R3为Backup路由器,第三台则以R3为Master,R1和R2为Backup路由器。

通过VRRP,可以实现LVS的主备部署,屏蔽LVS单点故障对应用服务器的影响。

网络到底通不通是个复杂的问题

讲这个过程的核心目的是除了真正的网络不通,有些是服务不可用了也怪网络。很多现场的同学根本讲不清自己的服务(比如80端口上的tomcat服务)还在不在,网络通不通,网络不通的话该怎么办?

实际这里涉及到四个节点(以两个网关直连为例),srcIP -> src网关 -> dest网关 -> destIP.如果ping不通(也有特殊的防火墙限制ping包不让过的),那么分段ping(二分查找程序员应该最熟悉了)。 比如前面的例子就是网关没有把包转发回来

抓包看ping包有没有出去,对方抓包看有没有收到,收到后有没有回复。

ping自己网关能不能通,ping对方网关能不能通

接下来说点跟程序员日常相关的

如果网络能ping通,服务无法访问

那么尝试telnet IP port 看看你的服务监听的端口是否还在,在的话是否能正常响应新的连接。有时候是进程挂掉了,端口也没人监听了。有时候是进程还在但是死掉了,所以端口也不响应新的请求了。

如果端口还在也是正常的话,telnet应该是好的:

$telnet 11.239.161.60 2376
Trying 11.239.161.60...
Connected to 11.239.161.60.
Escape character is '^]'.
^C
Connection closed by foreign host.

假如我故意换成一个不存在的端口,目标机器上的OS直接就拒绝了这个连接(抓包的话一般是看到reset标识):

$telnet 11.239.161.60 2379
Trying 11.239.161.60...
telnet: connect to address 11.239.161.60: Connection refused

一个服务不响应,然后首先怀疑网络不通、丢包的Case

当时的反馈应用代码抛SocketTimeoutException,怀疑网络问题:

  1. tsar检查,发现retran率特别高,docker容器(tlog-console)内达到50,物理机之间的retran在1-2之间。
  2. Tlog连接Hbase,出现大量连接断开,具体日志见附件,Hbase服务器完全正常,Hbase同学怀疑retran比较高导致。
  3. 业务应用连接Diamond 偶尔会出现超时异常,具体日志见附件。
  4. 业务很多这样的异常日志:[Diamond SocketTimeoutException]
  5. 有几台物理机io偶然情况下会飙升到80多。需要定位解决。

其实当时看到tsar监控retran比较高,我也觉得网络有问题,但是我去看的时候网络又非常好,于是我看了一下出问题时间段的网卡的流量信息也非常正常:

image.png

上图是通过sar监控到的9号 10.16.11.138(v24d9e0f23d40) 这个网卡的流量,看起来也是正常,流量没有出现明显的波动(10.16.11.138 出问题容器对应的网卡名:v24d9e0f23d40)

为了监控网络到底有没有问题,接着在出问题的两个容器上各启动一个http server,然后在对方每1秒钟互相发一次发http get请求,基本认识告诉我们如果网络丢包、卡顿,那么我这个http server的监控日志时间戳也会跳跃,如果应用是因为网络出现异常那么我启动的http服务也会出现异常。

实际监控来看,应用出异常的时候我的http服务是正常的(写了脚本判断日志的连续性,没问题):

image.png

这也强有力地证明了网络没问题,所以大家集中火力查看应用的问题。后来的实际调查发现是应用假死掉了(内部线程太多,卡死了),服务端口不响应请求了。

TCP建连接过程跟前面ping一样,只是把ping的icmp协议换成TCP协议,也是要先根据route,然后arp。

总结

网络丢包,卡顿,抖动很容易做背包侠,找到正确的原因解决问题才会更快,要不在错误的路径上怎么发力都不对。准的方向要靠好的基础知识和正确的逻辑以及证据来支撑,而不是猜测

  • 有重传的时候(或者说重传率高的时候),ping有可能是正常的(icmp包网卡直接返回);
  • 重传高,一般是tcp retrans,可能应用不响应,可能操作系统软中断太高等
  • ping只是保证网络链路是否通畅

这些原理基本都在RFC1180中阐述的清晰简洁,图文并茂,结构逻辑合理,但是对于90%的程序员没有什么卵用,因为看完几周后就忘得差不多。对于普通人来说还是要通过具体的案例来加深理解。

一流的人看RFC就够了,差一些的人看《TCP/IP卷1》,再差些的人要看一个个案例带出来的具体知识的书籍了,比如《wireshark抓包艺术》,人和人的学习能力有差别必须要承认。


参考文章:

https://tools.ietf.org/html/rfc1180

https://www.practicalnetworking.net/series/packet-traveling/packet-traveling/

Computer Networking Introduction - Ethernet and IP (Heavily Illustrated) 这篇凑合吧,其实没我这篇写得好,不过这个博客还有些别的文章也不错

netstat定位性能案例

netstat 和 ss 都是小工具,但是在网络性能、异常的窥探方面真的是神器。ss用法见这里

下面的案例通过netstat很快就发现为什么系统总是压不上去了(主要是快速定位到一个长链条的服务调用体系中哪个节点碰到瓶颈了)

netstat 命令

netstat跟ss命令一样也能看到Send-Q、Recv-Q这些状态信息,不过如果这个连接不是Listen状态的话,Recv-Q就是指收到的数据还在缓存中,还没被进程读取,这个值就是还没被进程读取的 bytes;而 Send 则是发送队列中没有被远程主机确认的 bytes 数

$netstat -tn  
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State  
tcp0  0 server:8182  client-1:15260 SYN_RECV   
tcp0 28 server:22    client-1:51708  ESTABLISHED
tcp0  0 server:2376  client-1:60269 ESTABLISHED

netstat -tn 看到的 Recv-Q 跟全连接半连接没有关系,这里特意拿出来说一下是因为容易跟 ss -lnt 的 Recv-Q 搞混淆。

Recv-Q 和 Send-Q 的说明

Recv-Q
Established: The count of bytes not copied by the user program connected to this socket.
Listening: Since Kernel 2.6.18 this column contains the current syn backlog.

Send-Q
Established: The count of bytes not acknowledged by the remote host.
Listening: Since Kernel 2.6.18 this column contains the maximum size of the syn backlog.

通过 netstat 发现问题的案例

自身太慢,比如如下netstat -t 看到的Recv-Q有大量数据堆积,那么一般是CPU处理不过来导致的:

image.png

下面的case是接收方太慢,从应用机器的netstat统计来看,也是client端回复太慢(本机listen 9108端口)

image.png

send-q表示回复从9108发走了,没收到对方的ack,基本可以推断client端到9108之间有瓶颈

实际确实是前端到9108之间的带宽被打满了,调整带宽后问题解决

netstat -s 统计数据

所有统计信息基本都有

Linux Module and make debug

Makefile 中的 tab 键

$sudo make
Makefile:4: *** missing separator.  Stop.

Makefile 中每个指令前面必须是tab(不能是4个空格)!

pwd

$sudo make
make -C /lib/modules/4.19.48-002.ali4000.test.alios7.x86_64/build M= modules
make[1]: Entering directory `/usr/src/kernels/4.19.48-002.ali4000.test.alios7.x86_64'
make[2]: *** No rule to make target `arch/x86/entry/syscalls/syscall_32.tbl', needed by `arch/x86/include/generated/asm/syscalls_32.h'.  Stop.
make[1]: *** [archheaders] Error 2
make[1]: Leaving directory `/usr/src/kernels/4.19.48-002.ali4000.test.alios7.x86_64'
make: *** [all] Error 2

Makefile中的:
make -C /lib/modules/$(shell uname -r)/build M=$(pwd) modules

$(pwd) 需要修改成:$(shell pwd)

makefile调试的法宝

makefile调试的法宝1

$ make --debug=a,m SHELL="bash -x" > make.log  2>&1                # 可以获取make过程最完整debug信息
$ make --debug=v,m SHELL="bash -x" > make.log  2>&1                # 一个相对精简版,推荐使用这个命令
$ make --debug=v  > make.log  2>&1                                 # 再精简一点的版本
$ make --debug=b  > make.log  2>&1                                 # 最精简的版本

推荐版本(会输出执行的具体命令):
make --debug=b SHELL="bash -x"  > make.log.simple  2>&1
or
make V=1

makefile调试的法宝2

上面的法宝1更多的还是在整体工程的makefile结构、makefile读取和makefile内部的rule之间的关系方面有很好的帮助作用。但是对于makefile中rule部分之前的变量部分的引用过程则表现的不是很充分。在这里,我们有另外一个法宝,可以把变量部分的引用过程给出一个比较好的调试信息。具体命令如下。

$ make -p 2>&1 | grep -A 1 '^# makefile' | grep -v '^--' | awk '/# makefile/&&/line/{getline n;print $0,";",n}' | LC_COLLATE=C sort -k 4 -k 6n > variable.log
$ cat variable.log
# makefile (from `Makefile', line 1) ; aa := 11
# makefile (from `Makefile', line 3) ; cc := 11
# makefile (from `Makefile', line 4) ; bb := 9999
# makefile (from `cfg_makefile', line 1) ; MAKEFILE_LIST :=  Makefile cfg_makefile
# makefile (from `cfg_makefile', line 1) ; xx := 4444
# makefile (from `cfg_makefile', line 2) ; yy := 4444
# makefile (from `cfg_makefile', line 3) ; zz := 4444
# makefile (from `sub_makefile', line 1) ; MAKEFILE_LIST :=  sub_makefile
# makefile (from `sub_makefile', line 1) ; aaaa := 222222
# makefile (from `sub_makefile', line 2) ; bbbb := 222222
# makefile (from `sub_makefile', line 3) ; cccc := 222222

makefile调试的法宝3

法宝2可以把makefile文件中每个变量的最终值清晰的展现出来,但是对于这些变量引用过程中的中间值却没有展示。此时,我们需要依赖法宝3来帮助我们。

$(warning $(var123))

很多人可能都知道这个warning语句。我们可以在makefile文件中的变量引用阶段的任何两行之间,添加这个语句打印关键变量的引用过程。

make 时ld报找不到lib

make总是报找不到libc,但实际我执行 ld -lc –verbose 从debug信息看又能够正确找到libc,debug方法

image.png

image.png

实际原因是make的时候最后有一个参数 -static,这要求得装 ***-static lib库,可以去掉 -static

依赖错误

编译报错缺少的组件需要yum install一下(bison/flex)

hping3

构造半连接:

sudo hping3 -i u100 -S -p 3306 10.0.186.79

tcp sk_state

enum {
    TCP_ESTABLISHED = 1,
    TCP_SYN_SENT,
    TCP_SYN_RECV,
    TCP_FIN_WAIT1,
    TCP_FIN_WAIT2,
    TCP_TIME_WAIT,
    TCP_CLOSE,
    TCP_CLOSE_WAIT,
    TCP_LAST_ACK,
    TCP_LISTEN,
    TCP_CLOSING,    /* Now a valid state */

    TCP_MAX_STATES  /* Leave at the end! */
};

kdump

启动kdump(kexec-tools), 系统崩溃的时候dump 内核(/var/crash)

sudo systemctl start kdump

参考:Linux 系统内核崩溃分析处理简介

Kdump 的概念出现在 2005 左右,是迄今为止最可靠的内核转存机制,已经被主要的 linux™ 厂商选用。kdump是一种先进的基于 kexec 的内核崩溃转储机制。当系统崩溃时,kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核,以很小的内存启动以捕获转储镜像。

第一个内核保留了内存的一部分给第二个内核启动用。由于 kdump 利用 kexec 启动捕获内核,绕过了 BIOS,所以第一个内核的内存得以保留。这是内核崩溃转储的本质。

kdump 需要两个不同目的的内核,生产内核和捕获内核。生产内核是捕获内核服务的对象。捕获内核会在生产内核崩溃时启动起来,与相应的 ramdisk 一起组建一个微环境,用以对生产内核下的内存进行收集和转存。

什么是 kexec ?

Kexec 是实现 kdump 机制的关键,它包括 2 一是组成部分:一是内核空间的系统调用 kexec_load,负责在生产内核(production kernel 或 first kernel)启动时将捕获内核(capture kernel 或 sencond kernel)加载到指定地址。二是用户空间的工具 kexec-tools,他将捕获内核的地址传递给生产内核,从而在系统崩溃的时候能够找到捕获内核的地址并运行。

没有 kexec 就没有 kdump。先有 kexec 实现了在一个内核中可以启动另一个内核,才让 kdump 有了用武之地。kexec 原来的目的是为了节省时间 kernel 开发人员重启系统的时间,谁能想到这个“偷懒”的技术却孕育了最成功的内存转存机制呢?

crash

sudo yum install crash -y
//手动触发crash
#echo 1 > /proc/sys/kernel/sysrq
#echo c > /proc/sysrq-trigger
//系统crash,然后重启,重启后分析:
sudo crash /usr/lib/debug/lib/modules/4.19.57-15.1.al7.x86_64/vmlinux /var/crash/127.0.0.1-2020-04-02-14\:40\:45/vmcore

可以触发dump但是系统没有crash, 以下两个命令都可以

1
2
3
4
5
sudo crash /usr/lib/debug/usr/lib/modules/4.19.91-19.1.al7.x86_64/vmlinux /proc/kcore
sudo crash /usr/lib/debug/usr/lib/modules/4.19.91-19.1.al7.x86_64/vmlinux /dev/mem

写内存hack内核,那就在crash命令执行前,先执行下面的命令:
stap -g -e 'probe kernel.function("devmem_is_allowed").return { $return = 1 }'

内核函数替换

image.png

static int __init hotfix_init(void)
{
  unsigned char e8_call[POKE_LENGTH];
  s32 offset, i;

  addr = (void *)kallsyms_lookup_name("tcp_reset");
  if (!addr) {
    printk("一切还没有准备好!请先加载tcp_reset模块。\n");
    return -1;
  }

  _text_poke_smp = (void *)kallsyms_lookup_name("text_poke");
  _text_mutex = (void *)kallsyms_lookup_name("text_mutex");

  stub = (void *)test_stub1;

  offset = (s32)((long)stub - (long)addr - FTRACE_SIZE);

  e8_call[0] = 0xe8;
  (*(s32 *)(&e8_call[1])) = offset;
  for (i = 5; i < POKE_LENGTH; i++) {
    e8_call[i] = 0x90;
  }
  get_online_cpus();
  mutex_lock(_text_mutex);
  _text_poke_smp(&addr[POKE_OFFSET], e8_call, POKE_LENGTH);
  mutex_unlock(_text_mutex);
  put_online_cpus();

  return 0;
}

void test_stub1(void)
{
  struct sock *sk = NULL;
  unsigned long sk_addr = 0;
  char buf[MAX_BUF_SIZE];
  int size=0;
  asm ("push %rdi");

  asm ( "mov %%rdi, %0;" :"=m"(sk_addr) : :);
  sk = (struct sock *)sk_addr;

  printk("aaaaaaaa yes :%d  dest:%X  source:%X\n",
      sk->sk_state,
      sk->sk_rcv_saddr,
      sk->sk_daddr);
/*
  size = snprintf(buf, MAX_BUF_SIZE-1, "rst %lu %d %pI4:%u->%pI4:%u \n",
                     get_seconds(),
                     sk->sk_state,
                     &(inet_sk(sk)->inet_saddr),
                     ntohs(inet_sk(sk)->inet_sport),
                     ntohs(inet_sk(sk)->inet_dport),
                     &(inet_sk(sk)->inet_daddr));
*/
//  tcp_rt_log_output(buf,size,1);

  asm ("pop %rdi");
}

参考文档

https://blog.sourcerer.io/writing-a-simple-linux-kernel-module-d9dc3762c234

https://stackoverflow.com/questions/16710047/usr-bin-ld-cannot-find-lnameofthelibrary

Linux系统中如何彻底隐藏一个TCP连接

定制 Linux Kernel

Linux 里面有一个工具,叫 Grub2,全称 Grand Unified Bootloader Version 2。顾名思义,就是搞系统启动的。

修改启动参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$cat change_kernel_parameter.sh 
#cat /sys/devices/system/cpu/vulnerabilities/*
#grep '' /sys/devices/system/cpu/vulnerabilities/*
#https://help.aliyun.com/document_detail/102087.html?spm=a2c4g.11186623.6.721.4a732223pEfyNC

#cat /sys/kernel/mm/transparent_hugepage/enabled
#transparent_hugepage=always
#noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off
#追加nopti nospectre_v2到内核启动参数中
sudo sed -i 's/\(GRUB_CMDLINE_LINUX=".*\)"/\1 nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off transparent_hugepage=always"/' /etc/default/grub

//从修改的 /etc/default/grub 生成 /boot/grub2/grub.cfg 配置
//如果是uefi引导,则是 /boot/efi/EFI/redhat/grub.cfg
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

#limit the journald log to 500M
sed -i 's/^#SystemMaxUse=$/SystemMaxUse=500M/g' /etc/systemd/journald.conf
#重启系统
#sudo reboot

## 选择不同的kernel启动
#sudo grep "menuentry " /boot/grub2/grub.cfg | grep -n menu
##grub认的index从0开始数的
#sudo grub2-reboot 0; sudo reboot
or
#grub2-set-default "CentOS Linux (3.10.0-1160.66.1.el7.x86_64) 7 (Core)" ; sudo reboot

GRUB 2 reads its configuration from the /boot/grub2/grub.cfg file on traditional BIOS-based machines and from the /boot/efi/EFI/redhat/grub.cfg file on UEFI machines. This file contains menu information.

The GRUB 2 configuration file, grub.cfg, is generated during installation, or by invoking the /usr/sbin/grub2-mkconfig utility, and is automatically updated by grubby each time a new kernel is installed. When regenerated manually using grub2-mkconfig, the file is generated according to the template files located in /etc/grub.d/, and custom settings in the /etc/default/grub file. Edits of grub.cfg will be lost any time grub2-mkconfig is used to regenerate the file, so care must be taken to reflect any manual changes in /etc/default/grub as well.

查看kernel编译参数

一般在 /boot/config-** 文件内放置所有内核编译参数

1
2
3
4
5
6
7
//启用 tcp_rt 模块
cat /boot/config-4.19.91-24.8.an8.x86_64 |grep TCP_RT
CONFIG_TCP_RT=y

//启用 RPS
cat /boot/config-4.19.91-24.8.an8.x86_64 |grep RPS
CONFIG_RPS=y

修改是否启用透明大页

1
2
$cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

制作启动盘

Windows 上用 UltraISO、rufus 烧制,macOS 上就比较简单了,直接用 dd 就可以做好:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ diskutil list
/dev/disk6 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: *31.5 GB disk6

# 找到 U 盘的那个设备,umount
$ diskutil unmountDisk /dev/disk3

# 用 dd 把 ISO 文件写进设备,注意这里是 rdisk3 而不是 disk3,在 BSD 中 r(IDENTIFIER)
# 代表了 raw device,会快很多
$ sudo dd if=/path/image.iso of=/dev/rdisk3 bs=1m

# 弹出 U 盘
$ sudo diskutil eject /dev/disk3

Linux 下制作步骤

1
2
3
umount /dev/sdn1
sudo mkfs.vfat /dev/sdn1
dd if=/data/uniontechos-server-20-1040d-amd64.iso of=/dev/sdn1 status=progress

iommu passthrough

在内核参数中加上iommu.passthrough=1 可以关闭iommu,iommu.strict=0是nostrict模式,iommu.strict=1是strict模式(这种性能较差),也是默认的模式。Strict和nostrict主要是处理 无效TLB中缓存的页表项 的方法不同, 一种是批量处理, 一种是一次处理一个。

在X86中加 intel_iommu=off 去关闭的。

IOMMU 硬件单元

DMA Remapping Feature 的工作是通过 CPU 硬件平台的 IOMMU(I/O MMU,Input/Output Memory Management Unit,I/O 内存管理硬件单元)来完成的。IOMMU 的出现,实现了地址空间上的隔离,使设备只能访问规定的内存区域。

image-20220718111233654

参考资料:https://lenovopress.lenovo.com/lp1467.pdf

image-20220729162624318

1
2
3
4
5
6
7
/*
* This variable becomes 1 if iommu=pt is passed on the kernel command line.
* If this variable is 1, IOMMU implementations do no DMA translation for
* devices and allow every device to access to whole physical memory. This is
* useful if a user wants to use an IOMMU only for KVM device assignment to
* guests and not for driver dma translation.
*/

说明配置了iommu=pt 的话函数iommu_no_mapping返回1,那么驱动就直接return paddr,并不会真正调用到domain_pfn_mapping,直接用了物理地址少了一次映射性能当然会高一些。如果是跑KVM建议 passthrough=0,物理机场景 passthrough=1

iommu=pt并不会影响kvm/dpdk/spdk的性能,这三者本质上都是用户态驱动,iommu=pt只会影响内核驱动,能让内核驱动设备性能更高。

SMMU:

ChatGPT:SMMU代表的是”System MMU”,是一种硬件单元,通常用于处理设备DMA(直接内存访问)请求,以允许安全而有效地使用设备,同时保护系统内存不受意外访问和恶意攻击。SMMU的主要功能是将设备发出的DMA请求映射到正确的物理内存地址,同时确保设备无法访问不属于其权限范围的内存区域。SMMU通常与ARM和其他芯片架构一起使用,以提高系统安全性和性能。

Google: SMMU(System Memory Management Unit)是Arm平台的IOMMU, SMMU为设备提供用设备可见的IOVA地址来访问物理内存的能力,体系结构中可能存在多个设备使用IOVA经过IOMMU来访问物理内存,IOMMU需要能够区分不同的设备,从而为每个设备引入了一个Stream ID,指向对应的STE(Stream Table Entry),所有的STE在内存中以数组的形式存在,SMMU记录STE数组的首地址。在操作系统扫描设备的时候会为其分配独有的Stream ID简称sid,设备通过IOMMU进行访存的所有配置都写在对应sid的STE中。

在非虚拟化场景下使能IOMMU/SMMU会带来性能衰减,主要是因为在DMA场景下要iova 到 pa的翻译,带来开销。当前集团的ARM机型,在非云化环境下都是SMMU OFF的,云化机型才是开启SMMU。

定制内存

物理内存700多G,要求OS只能用512G:

1
2
3
4
5
6
7
8
9
10
11
12
24条32G的内存条,总内存768G
# dmidecode -t memory |grep "Size: 32 GB"
Size: 32 GB
…………
Size: 32 GB
Size: 32 GB
root@uos15:/etc# dmidecode -t memory |grep "Size: 32 GB" | wc -l
24

# cat /boot/grub/grub.cfg |grep 512
linux /vmlinuz-4.19.0-arm64-server root=UUID=dbc68010-8c36-40bf-b794-271e59ff5727 ro splash quiet console=tty video=VGA-1:1280x1024@60 mem=512G DEEPIN_GFXMODE=$DEEPIN_GFXMODE
linux /vmlinuz-4.19.0-arm64-server root=UUID=dbc68010-8c36-40bf-b794-271e59ff5727 ro splash quiet console=tty video=VGA-1:1280x1024@60 mem=512G DEEPIN_GFXMODE=$DEEPIN_GFXMODE

高级版 按numa限制内存

每个numa 128G内存,总共1024G(32条*32G),8个numa node,需要将每个numa node内存限制在64G

在grub中cmdline中加入如下配置,每个node只用64G内存:

1
memmap=64G\$64G memmap=64G\$192G memmap=64G\$320G memmap=64G\$448G memmap=64G\$576G memmap=64G\$704G memmap=64G\$832G memmap=64G\$960G

或者:

1
2
3
4
5
6
7
8
9
10
11
#cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=1024M,high resume=/dev/mapper/klas-swap rd.lvm.lv=klas/root rd.lvm.lv=klas/swap video=efifb:on rhgb quiet quiet noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off iommu.passthrough=1 memmap=64G\\\$64G memmap=64G\\\$192G memmap=64G\\\$320G memmap=64G\\\$448G memmap=64G\\\$576G memmap=64G\\\$704G memmap=64G\\\$832G memmap=64G\\\$960G"
GRUB_DISABLE_RECOVERY="true"

然后执行生成最终grub启动参数
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

比如在一个4node的机器上,总共768G内存(32G*24),每个node使用64G内存

1
linux16 /vmlinuz-0-rescue-e91413f0be2c4c239b4aa0451489ae01 root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet memmap=128G\$64G memmap=128G\$256G memmap=128G\$448G memmap=128G\$640G

128G表示相对地址,$64G是绝对地址,128G\$64G 的意思是屏蔽64G到(64+128)G的地址对应的内存

检查

检查正在运行的系统使用的grub参数:

1
cat /proc/cmdline

内存信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
#dmidecode -t memory
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.2.1 present.
# SMBIOS implementations newer than version 3.2.0 are not
# fully supported by this version of dmidecode.

Handle 0x0033, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Multi-bit ECC
Maximum Capacity: 2 TB //最大支持2T
Error Information Handle: 0x0032
Number Of Devices: 32 //32个插槽

Handle 0x0041, DMI type 17, 84 bytes
Memory Device
Array Handle: 0x0033
Error Information Handle: 0x0040
Total Width: 72 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: DIMM
Set: None
Locator: CPU0_DIMMA0
Bank Locator: P0 CHANNEL A
Type: DDR4
Type Detail: Synchronous Registered (Buffered)
Speed: 2933 MT/s //内存最大频率
Manufacturer: SK Hynix
Serial Number: 220F9EC0
Asset Tag: Not Specified
Part Number: HMAA4GR7AJR8N-WM
Rank: 2
Configured Memory Speed: 2400 MT/s //内存实际运行速度--比如内存条数插太多会给内存降频
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Module Manufacturer ID: Bank 1, Hex 0xAD
Non-Volatile Size: None
Volatile Size: 32 GB

#lshw
*-bank:19
description: DIMM DDR4 Synchronous Registered (Buffered) 2933 MHz (0.3 ns) //内存最大频率
product: HMAA4GR7AJR8N-WM
vendor: SK Hynix
physical id: 13
serial: 220F9F63
slot: CPU1_DIMMB0
size: 32GiB //实际所插内存大小
width: 64 bits
clock: 2933MHz (0.3ns)

内存速度对延迟的影响

左边两列是同一种机型和CPU、内存,只是最左边的开了numa,他们的内存Speed: 2400 MT/s,但是实际运行速度是2133;最右边的是另外一种CPU,内存速度更快,用mlc测试他们的延时、带宽。可以看到V52机型带宽能力提升特别大,时延变化不大

image-20220123094155595

image-20220123094928794

image-20220123100052242

对比一下V62,intel8269 机型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
./Linux/mlc
Intel(R) Memory Latency Checker - v3.9
Measuring idle latencies (in ns)...
Numa node
Numa node 0 1
0 77.9 143.2
1 144.4 78.4

Measuring Peak Injection Memory Bandwidths for the system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using traffic with the following read-write ratios
ALL Reads : 225097.1
3:1 Reads-Writes : 212457.8
2:1 Reads-Writes : 210628.1
1:1 Reads-Writes : 199315.4
Stream-triad like: 190341.4

Measuring Memory Bandwidths between nodes within system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Numa node
Numa node 0 1
0 113139.4 50923.4
1 50916.6 113249.2

Measuring Loaded Latencies for the system
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Inject Latency Bandwidth
Delay (ns) MB/sec
==========================
00000 261.50 225452.5
00002 263.79 225291.6
00008 269.02 225184.1
00015 261.96 225757.6
00050 260.56 226013.2
00100 264.27 225660.1
00200 130.61 195882.4
00300 102.65 133820.1
00400 95.04 101353.2
00500 91.56 81585.9
00700 87.94 58819.1
01000 85.54 41551.3
01300 84.70 32213.6
01700 83.14 24872.5
02500 81.74 17194.3
03500 81.14 12524.2
05000 80.74 9013.2
09000 80.09 5370.0
20000 78.92 2867.2

Measuring cache-to-cache transfer latency (in ns)...
Local Socket L2->L2 HIT latency 51.6
Local Socket L2->L2 HITM latency 51.7
Remote Socket L2->L2 HITM latency (data address homed in writer socket)
Reader Numa Node
Writer Numa Node 0 1
0 - 111.3
1 111.1 -
Remote Socket L2->L2 HITM latency (data address homed in reader socket)
Reader Numa Node
Writer Numa Node 0 1
0 - 175.8
1 176.7 -

[root@numaopen.cloud.et93 /home/admin]
#lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 104
On-line CPU(s) list: 0-103
Thread(s) per core: 2
Core(s) per socket: 26
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
Stepping: 7
CPU MHz: 3199.902
CPU max MHz: 3800.0000
CPU min MHz: 1200.0000
BogoMIPS: 4998.89
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 36608K
NUMA node0 CPU(s): 0-25,52-77
NUMA node1 CPU(s): 26-51,78-103

#dmidecode -t memory
Handle 0x003C, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0026
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: DIMM
Set: None
Locator: CPU1_DIMM_E1
Bank Locator: NODE 2
Type: DDR4
Type Detail: Synchronous
Speed: 2666 MHz
Manufacturer: Samsung
Serial Number: 14998029
Asset Tag: CPU1_DIMM_E1_AssetTag
Part Number: M393A4K40BB2-CTD
Rank: 2
Configured Clock Speed: 2666 MHz
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V

BIOS定制

ipmitool

直接在linux内设置主板bios,然后重启就可以生效:

1
2
3
4
5
6
7
//Hygon C86 7260 24-core Processor 设置numa node(hygon 7280 就不行了)
ipmitool raw 0x3e 0x5c 0x00 0x01 0x81
ipmitool raw 0x3e 0x5c 0x05 0x01 0x81

//查询是否生效, 注意是 0x5d
#ipmitool raw 0x3e 0x5d 0x00 0x01
01 81

ipmitool使用

基本语法:ipmitool raw 0x3e 0x5c index 0x01 value

raw 0x3e 0x5c 固定不需要改,

Index表示需要修改的配置项, 接下来的 0x01 固定不需要改

value 表示值,0x81表示enable; 0x80表示disable

中间件的vipclient服务在centos7上域名解析失败

我们申请了一批ECS,操作系统是centos7,这些ECS部署了中间件的DNS服务(vipclient),但是发现这个时候域名解析失败,而同样的配置在centos6上就运行正确

抓包分析

分别在centos6、centos7上nslookup通过同一个DNS Server解析同一个域名,并抓包比较得到如下截图(为了方便我将centos6、7抓包做到了一张图上):

image.png

绿色部分是正常的解析(centos6),红色部分是解析,多了一个OPT(centos7)

赶紧Google一下OPT,原来DNS协议还有一个extention,参考这里

而centos7默认启用edns,但是vipclient实现的时候没有支持edns,所以 centos7 解析域名就出了问题

通过 dig 命令来查看dns解析过程

在centos7上,通过命令 dig edas.console.cztest.com 解析失败,但是改用这个命令禁用edns后就解析正常了:dig +noedns edas.console.cztest.com

vipclient会启动一个53端口,在上面监听dns query,也就是自己就是一个DNS Service

img

分析vipclient域名解析返回的包内容

image.png

把上图中最后4个16进制翻译成10进制IP地址,这个IP地址正是域名所对应的IP,可见vipclient收到域名解析后,因为看不懂edns协议,就按照自己的理解返回了结果,客户端收到这个结果后按照edns协议解析不出来IP,也就是两个的协议不对等导致了问题

总结

centos7之前默认都不启用edns,centos7后默认启用edns,但是vipclient目前不支持edns
通过命令:dig +noedns edas.console.cztest.com 能解析到域名所对应的IP
但是命令:dig edas.console.cztest.com 解析不到IP,因为vipclient(相当于这里的dns server)没有兼容edns,实际返回的结果带了IP但是客户端不支持edns协议所以解析不到(vipclient返回的格式、规范不对)

0%