## 1.抓包过滤器语法和实例

抓包过滤器类型Type(host、net、port)、方向Dir(src、dst)、协议Proto(ether、ip、tcp、udp、http、icmp、ftp等)、逻辑运算符(&&且、||或、!非)

### 1.1 协议过滤

直接输入协议名即可，

TCP,只显示TCP协议

HTTP,只显示HTTP协议

ICMP,只显示ICMP协议

### 1.2 IP过滤

host 192.168.23.1 抓取主机地址为192.168.23.1的数据包

src host 192.168.23.1 抓取源地址为192.168.23.1的数据包

dst host 192.168.23.1 抓目标地址为192.168.23.1的数据包

### 1.3 port过滤

port 80 抓取端口为80的数据包

src port 80 抓取源端口为80的数据包

dst port 80 抓取目标端口为80的数据包

### 1.4 逻辑运算符

src host 192.168.23.1 && dst port 80 抓取源地址为192.168.23.1且目标端口为80的数据包

host 192.168.23.1 || host 192.168.23.2 抓取主机地址为192.168.23.1或者192.168.23.2的数据包

## 2.显示过滤器语法和实例

### 2.1 比较操作符

==(等于)、!=(不等于)、>(大于)、<(小于)、>=(大于等于)、<=(小于等于)

### 2.2 协议过滤

直接输入协议名即可，这里的协议名需要小谢

tcp,只显示TCP协议

htp,只显示HTTP协议

icmp,只显示ICMP协议

### 2.3 IP过滤

ip.addr==192.168.23.1 显示主机地址为192.168.23.1的数据包

ip.srcr==192.168.23.1 显示源地址为192.168.23.1的数据包

ip.dstr==192.168.23.1 显示目标地址为192.168.23.1的数据包

### 2.4 port过滤

tcp.port==80 显示TCP协议端口为80的数据包

tcpsrc.port==80 显示TCP协议源端口为80的数据包

tcpdst.port==80 显示TCP协议目标端口为80的数据包

### 2.5 http模式过滤

http.request.method=='GET'：只显示http请求get方法的数据包

### 2.6 关键字过滤

选中某一条特定的数据包，可以使用关键词搜索的方式进行过滤

data contains "aaa" 搜索data数据包中包含关键词aaa的部分的内容

WireShark抓包

## 前言

> 在服务器上安装的各种中间件，一般都需要配置成开机自启动。但是有些中间件的安装过程中并没有提供相关配置开机自启动的说明文档。
> 今天总结一下 Centos 下配置服务开机自启动的 3 种方式。

### 一、Centos 上配置开机自启动的几种方式

- 方式一：直接在 / etc/rc.d/rc.local 中添加服务启动命令
- 方式二：通过 chkconfig 配置服务自启动
- 方式三：Centos7 通过 systemctl enble 配置服务自启动

### 二、实践演示

1、在 / etc/rc.d/rc.local 中添加服务启动命令

> /etc/rc.d/rc.local 脚本会在 Centos 系统启动时被自动执行，所以可以把需要开机后执行的命令直接放在这里。

示例：配置开机启动 [apollo]

```
vi /etc/rc.d/rc.local
```

![image-20230327101001567](http://pic.nexopera.tech/image-20230327101001567.png)

> 想简单点可以像上面这样直接将服务的启动命令添加到 / etc/rc.d/rc.local 中。

> 也可以自己编写服务启动的脚本。由于重启时是以 root 用户重启，需要保证 root 用户有脚本执行权限。

1）、编写服务启动的脚本
vi /opt/script/autostart.sh

```
#!/bin/bash
/root/Downloads/docker-quick-start/docker-compose up -d
```

2）、赋予脚本可执行权限（/opt/script/autostart.sh 是你的脚本路径）

```
chmod +x /opt/script/autostart.sh
```

3）、打开 / etc/rc.d/rc.local 文件，在末尾增加如下内容

```
/opt/script/autostart.sh
```

3）、在 centos7 中，/etc/rc.d/rc.local 的权限被降低了，所以需要执行如下命令赋予其可执行权限

```
chmod +x /etc/rc.d/rc.local
```

2、通过 [chkconfig] 配置

> 在 CentOS7 之前，可以通过 chkconfig 来配置开机自启动服务。  **chkconfig 相关命令：**

```
chkconfig –-add xxx //把服务添加到chkconfig列表
chkconfig --del xxx //把服务从chkconfig列表中删除
chkconfig xxx on //开启开机自动启动
chkconfig xxx off //关闭开机自动启动
chkconfig --list //查看所有chklist中服务
chkconfig --list xxx 查看指定服务
```

**chkconfig 运行级别 level 和启动顺序的概念：**
`chkconfig --list`![image-20230327101013732](http://pic.nexopera.tech/image-20230327101013732.png)
这里的 0 到 6 其实指的就是服务的 level。

–level <等级代号> 　指定系统服务要在哪一个执行等级中开启或关毕。

```
等级 0 表示：表示关机  
等级 1 表示：单用户模式  
等级 2 表示：无网络连接的多用户命令行模式  
等级 3 表示：有网络连接的多用户命令行模式  
等级 4 表示：不可用  
等级 5 表示：带图形界面的多用户模式  
等级 6 表示：重新启动
```

比如如下命令：

```
//设定mysqld在等级3和5为开机运行服务
chkconfig --level 35 mysqld on 

//设置network服务开机自启动，会把2～5的等级都设置为on
chkconfig network on
```

表示开机启动配置成功。
![image-20230327101024675](http://pic.nexopera.tech/image-20230327101024675.png)

**服务的启动顺序又指的什么呢？**
`服务的启动顺序是指在服务器启动后服务启动脚本执行的顺序。`
以系统默认服务 network 说明：

```
cat /etc/init.d/network
```

![image-20230327101032367](http://pic.nexopera.tech/image-20230327101032367.png)

> 其中 `# chkconfig: 2345 10 90`用来指定服务在各个 level 下的启动顺序。
> 该配置的含义是 network 服务在 2、3、4、5 的 level 下的启动顺序是 10，在 1 和 6 的 level 等级下的启动顺序是 90。

chkconfig 配置的服务启动顺序最后都会在`/etc/rc.d/`目录下体现出来：

```
cd /etc/rc.d/
```

![image-20230327101038931](http://pic.nexopera.tech/image-20230327101038931.png)
`文件中脚本命名规则，首字母K表示关闭脚本，首字母S表示启用脚本，数字表示启动的顺序.`

**chkconfig 配置实例**

> 通常 [kibana]的官方配置是没有介绍如何配置开机自启动的。这里我配置 kibana 开机自启动来说明。

1、在 / etc/init.d 目录下，新建脚本 kibana

```
cd /etc/init.d
vi kibana
```

脚本内容如下：

```
#!/bin/bash

# chkconfig: 2345 98 02
# description:  kibana

KIBANA_HOME=/usr/local/kibana-6.2.4-linux-x86_64
case $1 in
 start)
         $KIBANA_HOME/bin/kibana &
         echo "kibana start"
         ;;
 stop)
    kibana_pid_str=`netstat -tlnp |grep 5601 | awk '{print $7}'`
    kibana_pid=`echo ${kibana_pid_str%%/*}`
    kill -9 $kibana_pid
    echo "kibana stopped"
    ;;
 restart)
    kibana_pid_str=`netstat -tlnp |grep 5601 | awk '{print $7}'`
    kibana_pid=${kibana_pid_str%%/*}
    kibana_pid=`echo ${kibana_pid_str%%/*}`
    kill -9 $kibana_pid
    echo "kibana stopped"

    $KIBANA_HOME/bin/kibana &
    echo "kibana start"
    ;;
 status)
    kibana_pid_str=`netstat -tlnp |grep 5601 | awk '{print $7}'`
    if test -z $kibana_pid_str; then
       echo "kibana is stopped"
    else
       pid=`echo ${kibana_pid_str%%/*}`
       echo "kibana is started,pid:"${pid}
    fi
    ;;
*)
    echo "start|stop|restart|status"
    ;;
esac
```

**注意⚠️：**

> 每个被 chkconfig 管理的服务需要在对应的 init.d 下的脚本加上两行或者更多行的注释。
> 第一行告诉 chkconfig 缺省启动的运行级以及启动和停止的优先级。如果某服务缺省不在任何运行级启动，那么使用 - 代替运行级。
> 第二行对服务进行描述，可以用 \ 跨行注释。

```
#!/bin/bash
#chkconfig:2345 98 02
#description:kibana
```

**解释说明：**

> 配置 kibana 服务在 2、3、4、5 的 level 等级下脚本执行顺序是 98,

1、6 的 level 等级下脚本执行顺序是 01。

2、增加脚本的可执行权限

```
chmod +x kibana
```

3、查看 chkconfig list

```
chkconfig --list
```

4、把服务添加到 chkconfig 列表

```
chkconfig --add kibana
```

![image-20230327101048307](http://pic.nexopera.tech/image-20230327101048307.png)

5、设置 kibana 服务自启动

```
chkconfig kibana on //开启开机自动启动
```

6、查看 kibana 服务自启动状态

```
chkconfig --list kibana
```

`如果2~5都是on，就表明会自动启动了`
![image-20230327101054912](http://pic.nexopera.tech/image-20230327101054912.png)
7、服务的启动、停止、重启和状态查看

```
//查看服务状态
service kibana status
//服务启动
service kibana start
//服务停止
service kibana stop
//服务重启
service kibana restart
```

![image-20230327101102371](http://pic.nexopera.tech/image-20230327101102371.png)

3、Centos7 通过 systemctl enble 配置服务自启动

> 在 Centos7 后，更推荐通过`systemctl`来控制服务。

|         任务         |            旧指令             |                            新指令                            |
| :------------------: | :---------------------------: | :----------------------------------------------------------: |
|   使某服务自动启动   | Chkconfig --level 3 httpd on  |                systemctl enable httpd.service                |
|  使某服务不自动启动  | chkconfig --level 3 httpd off |               systemctl disable httpd.service                |
|     检查服务状态     |     service httpd status      | systemctl status httpd.service （服务详细信息） systemctl is-active httpd.service（仅显示是否 Active) |
| 显示所有已启动的服务 |       chkconfig --list        | systemctl list-unit-files systemctl list-units --type=service |
|      启动某服务      |      service httpd start      |                systemctl start httpd.service                 |
|      停止某服务      |      service httpd stop       |                 systemctl stop httpd.service                 |
|      重启某服务      |     service httpd restart     |               systemctl restart httpd.service                |

1、systemctl 服务的目录介绍

> 知道服务的管理是通过 systemd，而 systemd 的配置文件大部分放置于 `/usr/lib/systemd/`目录内。但是 Red Hat 官方文件指出， 该目录的文件主要是原本软件所提供的设置，建议不要修改！而要修改的位置应该放置于 `/etc/systemd/system/`目录内。

详情查看：https://wizardforcel.gitbooks.io/vbird-linux-basic-4e/content/150.html

Centos 系统服务脚本目录：

```
/usr/lib/systemd/
```

> 有系统（system）和用户（user）之分，如需要开机没有登陆情况下就能运行的程序，存在系统服务（system）里，即：

```
/usr/lib/systemd/system/
```

反之，用户登录后才能运行的程序，存在用户（user）里，服务以. service 结尾。

```
/usr/lib/systemd/user/
```

2、建立 kibana 开机服务
1）、建立 kibana 服务文件

```
cd /etc/systemd/system/
vim kibana.service
```

脚本内容：

```
[Unit]    
Description=kibana    
After=network.target         
[Service]    
Type=forking    
User=root
Group=root
ExecStart=/etc/init.d/kibana start    
ExecReload=/etc/init.d/kibana restart    
ExecStop=/etc/init.d/kibana  stop    
PrivateTmp=true    
[Install]    
WantedBy=multi-user.target
```

**注意⚠️：**

> 这里`ExecStart、ExecReload、ExecStop`的命令还是借助了上文在 / etc/init.d 目录下配置 kibana 脚本来实现。
> [Service] 的启动、重启、停止命令全部要求使用绝对路径
> [Install] 服务安装的相关设置，可设置为多用户

**参数说明：**
Description: 描述服务
After: 描述服务类别

[Service] 服务运行参数的设置
Type=forking 是后台运行的形式
User 服务启动用户
Group 服务启动用户组
ExecStart 为服务的具体运行命令
ExecReload 为重启命令
ExecStop 为停止命令
PrivateTmp=True 表示给服务分配独立的临时空间

2）、赋予执行权限

```
chmod 754 kibana.service
```

依照上面的表格，权限组合就是对应权限值求和，如下：
7 = 4 + 2 + 1 读写运行权限
5 = 4 + 1 读和运行权限
4 = 4 只读权限.

> 这句命令的意思是将 filename 文件的读写运行权限赋予文件所有者，把读和运行的权限赋予群组用户，把读的权限赋予其他用户。

3）、服务的启动、停止、开机启动

- 查看服务状态

```
//重新加载某个服务的配置文件，如果新安装了一个服务，归属于 systemctl 管理，要是新服务的服务程序配置文件生效，需重新加载
systemctl daemon-reload
//查看服务状态
systemctl status kibana.service
```

![image-20230327101112080](http://pic.nexopera.tech/image-20230327101112080.png)

- 启动服务
  ![](http://pic.nexopera.tech/image-20230327101117290.png)

> 其中，`disabled`说明服务还没有开启开机自启动。

- 开启服务开机启动

```
systemctl enable kibana.service
```

![image-20230327101125024](http://pic.nexopera.tech/image-20230327101125024.png)

**服务状态说明：**
`systemctl status 服务名称`

|       状态        |                            说明                             |
| :---------------: | :---------------------------------------------------------: |
|      loaded       |             系统服务已经初始化完成，加载过配置              |
| active（running） |   正有一个或多个程序正在系统中执行， vsftpd 就是这种模式    |
| atcive（exited）  | 僅執行一次就正常結束的服務， 目前並沒有任何程序在系統中執行 |
| atcive（waiting） |      正在執行當中，不過還再等待其他的事件才能继续处理       |
|     inactive      |                          服务关闭                           |
|      enbaled      |                        服务开机启动                         |
|     disabled      |                       服务开机不自启                        |
|      static       |                  服务开机启动项不可被管理                   |
|      failed       |                        系统配置错误                         |

**常用服务文件**
1.nginx.service

```
[Unit]
Description=nginx - high performance web server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop
[Install]
WantedBy=multi-user.target
```

2.mysql.service

```
[Unit]
Description=mysql
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
ExecStart=/usr/local/mysql/support-files/mysql.server start
#ExecReload=/usr/local/mysql/support-files/mysql.server restart
#ExecStop=/usr/local/mysql/support-files/mysql.server stop
#PrivateTmp=true

[Install]
WantedBy=multi-user.target
```

4.redis.service

```
[Unit]
Description=Redis
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
ExecStart=/usr/local/bin/redis-server /etc/redis.conf
ExecStop=kill -INT `cat /tmp/redis.pid`
User=www
Group=www

[Install]
WantedBy=multi-user.target
```

5.supervisord.service

```
[Unit]
Description=Process Monitoring and Control Daemon
After=rc-local.service

[Service]
Type=forking
ExecStart=/usr/bin/supervisord -c /etc/supervisord.conf
SysVStartPriority=99

[Install]
WantedBy=multi-user.target
```

### 总结

本文主要总结了 Centos 上配置开机自启动的 3 种方式

- 方式一：直接在 / etc/rc.d/rc.local 中添加服务启动命令
- 方式二：通过 chkconfig 配置服务自启动
- 方式三：Centos7 通过 systemctl enble 配置服务开机自启动

Centos开机自启动配置方式汇总

所谓丢包，是指在网络数据的收发过程中，由于种种原因，数据包还没传输到应用程序中，就被丢弃了。这些被丢弃包的数量，除以总的传输包数，也就是我们常说的丢包率。丢包率是网络性能中最核心的指标之一。丢包通常会带来严重的性能下降，特别是对 TCP 来说，丢包通常意味着网络拥塞和重传，进而还会导致网络延迟增大、吞吐降低。



## **一、 哪里可能丢包**

接下来，我就以最常用的反向代理服务器 Nginx 为例，带你一起看看如何分析网络丢包的问题。执行下面的 hping3 命令，进一步验证 Nginx 是不是可以正常访问。这里我没有使用 ping，是因为 ping 基于 ICMP 协议，而 Nginx 使用的是 TCP 协议。

```
# -c表示发送10个请求，-S表示使用TCP SYN，-p指定端口为80
hping3 -c 10 -S -p 80 192.168.0.30
 
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=3 win=5120 rtt=7.5 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=4 win=5120 rtt=7.4 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=5 win=5120 rtt=3.3 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=7 win=5120 rtt=3.0 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=6 win=5120 rtt=3027.2 ms
 
--- 192.168.0.30 hping statistic ---
10 packets transmitted, 5 packets received, 50% packet loss
round-trip min/avg/max = 3.0/609.7/3027.2 ms
```

从 hping3 的输出中，我们可以发现，发送了 10 个请求包，却只收到了 5 个回复，50%的包都丢了。再观察每个请求的 RTT 可以发现，RTT 也有非常大的波动变化，小的时候只有 3ms，而大的时候则有 3s。根据这些输出，我们基本能判断，已经发生了丢包现象。可以猜测，3s 的 RTT ，很可能是因为丢包后重传导致的。

那到底是哪里发生了丢包呢？排查之前，我们可以回忆一下 Linux 的网络收发流程，先从理论上分析，哪里有可能会发生丢包。你不妨拿出手边的笔和纸，边回忆边在纸上梳理，思考清楚再继续下面的内容。在这里，为了帮你理解网络丢包的原理，我画了一张图，你可以保存并打印出来使用

从图中你可以看出，可能发生丢包的位置，实际上贯穿了整个网络协议栈。换句话说，全程都有丢包的可能。

- 在两台 VM 连接之间，可能会发生传输失败的错误，比如网络拥塞、线路错误等；
- 在网卡收包后，环形缓冲区可能会因为溢出而丢包；
- 在链路层，可能会因为网络帧校验失败、QoS 等而丢包；
- 在 IP 层，可能会因为路由失败、组包大小超过 MTU 等而丢包；
- 在传输层，可能会因为端口未监听、资源占用超过内核限制等而丢包；
- 在套接字层，可能会因为套接字缓冲区溢出而丢包；
- 在应用层，可能会因为应用程序异常而丢包；
- 此外，如果配置了 iptables 规则，这些网络包也可能因为 iptables 过滤规则而丢包



当然，上面这些问题，还有可能同时发生在通信的两台机器中。不过，由于我们没对 VM2做任何修改，并且 VM2 也只运行了一个最简单的 hping3 命令，这儿不妨假设它是没有问题的。为了简化整个排查过程，我们还可以进一步假设， VM1 的网络和内核配置也没问题。接下来，就可以从协议栈中，逐层排查丢包问题。



## **二、 链路层**

当链路层由于缓冲区溢出等原因导致网卡丢包时，Linux 会在网卡收发数据的统计信息中记录下收发错误的次数。可以通过 ethtool 或者 netstat ，来查看网卡的丢包记录。

```
netstat -i
 
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       100       31      0      0 0             8      0      0      0 BMRU
lo       65536        0      0      0 0             0      0      0      0 LRU
```

RX-OK、RX-ERR、RX-DRP、RX-OVR ，分别表示接收时的总包数、总错误数、进入 Ring Buffer 后因其他原因（如内存不足）导致的丢包数以及 Ring Buffer 溢出导致的丢包数。

TX-OK、TX-ERR、TX-DRP、TX-OVR 也代表类似的含义，只不过是指发送时对应的各个指标。

这里我们没有发现任何错误，说明虚拟网卡没有丢包。不过要注意，如果用 tc 等工具配置了 QoS，那么 tc 规则导致的丢包，就不会包含在网卡的统计信息中。所以接下来，我们还要检查一下 eth0 上是否配置了 tc 规则，并查看有没有丢包。添加 -s 选项，以输出统计信息：

```
tc -s qdisc show dev eth0
 
qdisc netem 800d: root refcnt 2 limit 1000 loss 30%
 Sent 432 bytes 8 pkt (dropped 4, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
```

可以看到， eth0 上配置了一个网络模拟排队规则（qdisc netem），并且配置了丢包率为 30%（loss 30%）。再看后面的统计信息，发送了 8 个包，但是丢了 4个。看来应该就是这里导致 Nginx 回复的响应包被 netem 模块给丢了。

既然发现了问题，解决方法也很简单，直接删掉 netem 模块就可以了。执行下面的命令，删除 tc 中的 netem 模块：

```
tc qdisc del dev eth0 root netem loss 30%
```

删除后，重新执行之前的 hping3 命令，看看现在还有没有问题：

```
hping3 -c 10 -S -p 80 192.168.0.30
 
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=0 win=5120 rtt=7.9 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=2 win=5120 rtt=1003.8 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=5 win=5120 rtt=7.6 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=6 win=5120 rtt=7.4 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=9 win=5120 rtt=3.0 ms
 
--- 192.168.0.30 hping statistic ---
10 packets transmitted, 5 packets received, 50% packet loss
round-trip min/avg/max = 3.0/205.9/1003.8 ms
```



不幸的是，从 hping3 的输出中可以看到还是 50% 的丢包，RTT 的波动也仍旧很大，从 3ms 到 1s。显然，问题还是没解决，丢包还在继续发生。不过，既然链路层已经排查完了，我们就继续向上层分析，看看网络层和传输层有没有问题。



## **三、 网络层和传输层**

在网络层和传输层中，引发丢包的因素非常多。不过，其实想确认是否丢包，是非常简单的事，因为 Linux 已经为我们提供了各个协议的收发汇总情况。执行 netstat -s 命令，可以看到协议的收发汇总，以及错误信息：

```
netstat -s
#输出
Ip:
    Forwarding: 1          //开启转发
    31 total packets received    //总收包数
    0 forwarded            //转发包数
    0 incoming packets discarded  //接收丢包数
    25 incoming packets delivered  //接收的数据包数
    15 requests sent out      //发出的数据包数
Icmp:
    0 ICMP messages received    //收到的ICMP包数
    0 input ICMP message failed    //收到ICMP失败数
    ICMP input histogram:
    0 ICMP messages sent      //ICMP发送数
    0 ICMP messages failed      //ICMP失败数
    ICMP output histogram:
Tcp:
    0 active connection openings  //主动连接数
    0 passive connection openings  //被动连接数
    11 failed connection attempts  //失败连接尝试数
    0 connection resets received  //接收的连接重置数
    0 connections established    //建立连接数
    25 segments received      //已接收报文数
    21 segments sent out      //已发送报文数
    4 segments retransmitted    //重传报文数
    0 bad segments received      //错误报文数
    0 resets sent          //发出的连接重置数
Udp:
    0 packets received
    ...
TcpExt:
    11 resets received for embryonic SYN_RECV sockets  //半连接重置数
    0 packet headers predicted
    TCPTimeouts: 7    //超时数
    TCPSynRetrans: 4  //SYN重传数
  ...
```

etstat 汇总了 IP、ICMP、TCP、UDP 等各种协议的收发统计信息。不过，我们的目的是排查丢包问题，所以这里主要观察的是错误数、丢包数以及重传数。可以看到，只有 TCP 协议发生了丢包和重传，分别是：

- 11 次连接失败重试（11 failed connection attempts）
- 4 次重传（4 segments retransmitted）
- 11 次半连接重置（11 resets received for embryonic SYN_RECV sockets）
- 4 次 SYN 重传（TCPSynRetrans）
- 7 次超时（TCPTimeouts）



这个结果告诉我们，TCP 协议有多次超时和失败重试，并且主要错误是半连接重置。换句话说，主要的失败，都是三次握手失败。不过，虽然在这儿看到了这么多失败，但具体失败的根源还是无法确定。所以，我们还需要继续顺着协议栈来分析。接下来的几层又该如何分析呢？



**四、 iptables**

首先，除了网络层和传输层的各种协议，iptables 和内核的连接跟踪机制也可能会导致丢包。所以，这也是发生丢包问题时我们必须要排查的一个因素。

先来看看连接跟踪，要确认是不是连接跟踪导致的问题，只需要对比当前的连接跟踪数和最大连接跟踪数即可。

```
# 主机终端中查询内核配置
$ sysctl net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_max = 262144
$ sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 182
```

可以看到，连接跟踪数只有 182，而最大连接跟踪数则是 262144。显然，这里的丢包，不可能是连接跟踪导致的。

接着，再来看 iptables。回顾一下 iptables 的原理，它基于 Netfilter 框架，通过一系列的规则，对网络数据包进行过滤（如防火墙）和修改（如 NAT）。这些 iptables 规则，统一管理在一系列的表中，包括 filter、nat、mangle（用于修改分组数据） 和 raw（用于原始数据包）等。而每张表又可以包括一系列的链，用于对 iptables 规则进行分组管理。

对于丢包问题来说，最大的可能就是被 filter 表中的规则给丢弃了。要弄清楚这一点，就需要我们确认，那些目标为 DROP 和 REJECT 等会弃包的规则，有没有被执行到。可以直接查询 DROP 和 REJECT 等规则的统计信息，看看是否为0。如果不是 0 ，再把相关的规则拎出来进行分析。

```
iptables -t filter -nvL
#输出
Chain INPUT (policy ACCEPT 25 packets, 1000 bytes)
 pkts bytes target     prot opt in     out     source               destination
    6   240 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.29999999981
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain OUTPUT (policy ACCEPT 15 packets, 660 bytes)
 pkts bytes target     prot opt in     out     source               destination
    6   264 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.29999999981
```

从 iptables 的输出中，你可以看到，两条 DROP 规则的统计数值不是 0，它们分别在INPUT 和 OUTPUT 链中。这两条规则实际上是一样的，指的是使用 statistic 模块，进行随机 30% 的丢包。0.0.0.0/0 表示匹配所有的源 IP 和目的 IP，也就是会对所有包都进行随机 30% 的丢包。看起来，这应该就是导致部分丢包的“罪魁祸首”了。

执行下面的两条 iptables 命令，删除这两条 DROP 规则。

```
root@nginx:/# iptables -t filter -D INPUT -m statistic --mode random --probability 0.30 -j DROP
root@nginx:/# iptables -t filter -D OUTPUT -m statistic --mode random --probability 0.30 -j DROP
```

再次执行刚才的 hping3 命令，看看现在是否正常

```
hping3 -c 10 -S -p 80 192.168.0.30
#输出
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=0 win=5120 rtt=11.9 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=1 win=5120 rtt=7.8 ms
...
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=9 win=5120 rtt=15.0 ms
 
--- 192.168.0.30 hping statistic ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 3.3/7.9/15.0 ms
```

这次输出你可以看到，现在已经没有丢包了，并且延迟的波动变化也很小。看来，丢包问题应该已经解决了。

不过，到目前为止，我们一直使用的 hping3 工具，只能验证案例 Nginx 的 80 端口处于正常监听状态，却还没有访问 Nginx 的 HTTP 服务。所以，不要匆忙下结论结束这次优化，我们还需要进一步确认，Nginx 能不能正常响应 HTTP 请求。我们继续在终端二中，执行如下的 curl 命令，检查 Nginx 对 HTTP 请求的响应：

```
$ curl --max-time 3 http://192.168.0.30
curl: (28) Operation timed out after 3000 milliseconds with 0 bytes received
```



奇怪，hping3 的结果显示Nginx 的 80 端口是正常状态，为什么还是不能正常响应 HTTP 请求呢？别忘了，我们还有个大杀器——抓包操作。看来有必要抓包看看了。



## **五、 tcpdump**

执行下面的 tcpdump 命令，抓取 80 端口的包

```
tcpdump -i eth0 -nn port 80
#输出
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
```

然后，切换到终端二中，再次执行前面的 curl 命令：

```
curl --max-time 3 http://192.168.0.30
curl: (28) Operation timed out after 3000 milliseconds with 0 bytes received
```

等到 curl 命令结束后，再次切换回终端一，查看 tcpdump 的输出：

```
14:40:00.589235 IP 10.255.255.5.39058 > 172.17.0.2.80: Flags [S], seq 332257715, win 29200, options [mss 1418,sackOK,TS val 486800541 ecr 0,nop,wscale 7], length 0
14:40:00.589277 IP 172.17.0.2.80 > 10.255.255.5.39058: Flags [S.], seq 1630206251, ack 332257716, win 4880, options [mss 256,sackOK,TS val 2509376001 ecr 486800541,nop,wscale 7], length 0
14:40:00.589894 IP 10.255.255.5.39058 > 172.17.0.2.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 486800541 ecr 2509376001], length 0
14:40:03.589352 IP 10.255.255.5.39058 > 172.17.0.2.80: Flags [F.], seq 76, ack 1, win 229, options [nop,nop,TS val 486803541 ecr 2509376001], length 0
14:40:03.589417 IP 172.17.0.2.80 > 10.255.255.5.39058: Flags [.], ack 1, win 40, options [nop,nop,TS val 2509379001 ecr 486800541,nop,nop,sack 1 {76:77}], length 0
```

从 tcpdump 的输出中，我们就可以看到：

- 前三个包是正常的 TCP 三次握手，这没问题；
- 但第四个包却是在 3 秒以后了，并且还是客户端（VM2）发送过来的 FIN 包，说明客户端的连接关闭了

根据 curl 设置的 3 秒超时选项，你应该能猜到，这是因为 curl 命令超时后退出了。用 Wireshark 的 Flow Graph 来表示，

你可以更清楚地看到上面这个问题：

![image-20230327100721458](http://pic.nexopera.tech/image-20230327100721458.png)

这里比较奇怪的是，我们并没有抓取到 curl 发来的 HTTP GET 请求。那究竟是网卡丢包了，还是客户端就没发过来呢？

可以重新执行 netstat -i 命令，确认一下网卡有没有丢包问题：

```
netstat -i
 
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       100      157      0    344 0            94      0      0      0 BMRU
lo       65536        0      0      0 0             0      0      0      0 LRU
```

从 netstat 的输出中，你可以看到，接收丢包数（RX-DRP）是 344，果然是在网卡接收时丢包了。不过问题也来了，为什么刚才用 hping3 时不丢包，现在换成 GET 就收不到了呢？还是那句话，遇到搞不懂的现象，不妨先去查查工具和方法的原理。我们可以对比一下这两个工具：

- hping3 实际上只发送了 SYN 包；
- curl 在发送 SYN 包后，还会发送 HTTP GET 请求。HTTP GET本质上也是一个 TCP 包，但跟 SYN 包相比，它还携带了 HTTP GET 的数据。

通过这个对比，你应该想到了，这可能是 MTU 配置错误导致的。为什么呢？

其实，仔细观察上面 netstat 的输出界面，第二列正是每个网卡的 MTU 值。eth0 的 MTU只有 100，而以太网的 MTU 默认值是 1500，这个 100 就显得太小了。当然，MTU 问题是很好解决的，把它改成 1500 就可以了。

```
ifconfig eth0 mtu 1500
```

修改完成后，再切换到终端二中，再次执行 curl 命令，确认问题是否真的解决了：

```
curl --max-time 3 http://192.168.0.30/
#输出
<!DOCTYPE html>
<html>
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
```

非常不容易呀，这次终于看到了熟悉的 Nginx 响应，说明丢包的问题终于彻底解决了。

linux网络丢包问题排查

#### 一、自动清理节点

```
将节点添加到集群时后，会创建容器、虚拟网络接口等资源和证书、配置文件。从集群中正常删除节点时(如果处于 Active 状态)，将自动清除这些资源，并且只需重新启动节点即可。当节点无法访问且无法使用自动清理，或者异常导致节点脱离集群后，如果需要再次将节点加入集群，那么需要手动进行节点初始化操作。
```

#### 二、手动清理节点

> **警告:** 以下操作将删除节点中的数据，在执行命令之前，请确保已进行数据备份。

```
#!/bin/bash

KUBE_SVC='
kubelet
kube-scheduler
kube-proxy
kube-controller-manager
kube-apiserver
'

for kube_svc in ${KUBE_SVC};
do
  # 停止服务
  if [[ `systemctl is-active ${kube_svc}` == 'active' ]]; then
    systemctl stop ${kube_svc}
  fi
  # 禁止服务开机启动
  if [[ `systemctl is-enabled ${kube_svc}` == 'enabled' ]]; then
    systemctl disable ${kube_svc}
  fi
done

# 停止所有容器
docker stop $(docker ps -aq)

# 删除所有容器
docker rm -f $(docker ps -qa)

# 删除所有容器卷
docker volume rm $(docker volume ls -q)

# 卸载 mount 目录
for mount in $(mount | grep tmpfs | grep '/var/lib/kubelet' | awk '{ print $3 }') /var/lib/kubelet /var/lib/rancher;
do
  umount $mount;
done

# 备份目录
mv /etc/kubernetes /etc/kubernetes-bak-$(date +"%Y%m%d%H%M")
mv /var/lib/etcd /var/lib/etcd-bak-$(date +"%Y%m%d%H%M")
mv /var/lib/rancher /var/lib/rancher-bak-$(date +"%Y%m%d%H%M")
mv /opt/rke /opt/rke-bak-$(date +"%Y%m%d%H%M")

# 删除残留路径
rm -rf /etc/ceph \
    /etc/cni \
    /opt/cni \
    /run/secrets/kubernetes.io \
    /run/calico \
    /run/flannel \
    /var/lib/calico \
    /var/lib/cni \
    /var/lib/kubelet \
    /var/log/containers \
    /var/log/kube-audit \
    /var/log/pods \
    /var/run/calico

# 清理网络接口
no_del_net_inter='
lo
docker0
eth
ens
bond
'

network_interface=`ls /sys/class/net`

for net_inter in ${network_interface};
do
  if ! echo "${no_del_net_inter}" | grep -qE ${net_inter:0:3}; then
    ip link delete $net_inter
  fi
done

# 清理残留进程
port_list='
80
443
6443
2376
2379
2380
8472
9099
10250
10254
'

for port in ${port_list};
do
  pid=`netstat -atlnup | grep -w ${port} | grep -v - | awk '{print $7}' | awk -F '/' '{print $1}' | sort -rnk2 | uniq`
  if [[ -n ${pid} ]]; then
    kill -15 ${pid}
  fi
done

kube_pid=`ps -ef | grep -v grep | grep kube | awk '{print $2}'`

if [[ -n ${kube_pid} ]]; then
  kill -15 ${kube_pid}
fi
```

#### 三、 清理 Iptables 表

```
# 注意：如果节点 Iptables 有特殊配置，以下命令请谨慎操作
sudo iptables --flush
sudo iptables --flush --table nat
sudo iptables --flush --table filter
sudo iptables --table nat --delete-chain
sudo iptables --table filter --delete-chain
systemctl restart docker
```

k8s自动清理节点

今天为大家举例讲解`正则表达式`中常用的匹配符号。

## 7个普通元字符

首先介绍的是7个普通元字符，详细介绍如下图，它们在正则表达式中，都有着自己特殊的含义。

![image-20230327095754620](http://pic.nexopera.tech/image-20230327095754620.png)

#### **1 [ ]符号**

![image-20230327095804496](http://pic.nexopera.tech/image-20230327095804496.png)

**案例如下：**

```
import re

str1 = "acb azb abb a6b aab"

result1 = re.findall("a[a-z]b",str1) ①
result2 = re.findall("a[0-9]b",str1) ②
result3 = re.findall("a[za6]b",str1) ③

print(result1)
print(result2)
print(result3)
```

结果如下：

![image-20230327095811366](http://pic.nexopera.tech/image-20230327095811366.png)

**代码解释：**不管是①②③，表示匹配开头是a，末尾是b。唯一不同的就是[ ]符号中匹配值不同。

- ①处表示中间的字符，只要是a-z字母中任何一个，都可以被匹配到。
- ②处表示中间的字符，只要是0-9数字中任何一个，都可以被匹配到。
- ③处表示中间的字符，只能是z或a或6这三者中任何一个，才能被匹配到。

#### **2 |或运算符**

![image-20230327095820523](http://pic.nexopera.tech/image-20230327095820523.png)

**案例如下：**

```
import re

str2 = "我是孙悟空，您可以称呼我为齐天大圣！"

result1 = re.findall("孙悟空|齐天大圣",str2)

print(result1)
```

结果如下：

![image-20230327095827631](http://pic.nexopera.tech/image-20230327095827631.png)

**代码解释：**要么匹配孙悟空，要么匹配齐天大圣。

#### **3 \转义字符**

![image-20230327095834381](http://pic.nexopera.tech/image-20230327095834381.png)

**案例如下：**

```
import re

str3 = "\n123456" ①
str4 = "\\n123456" ②
str5 = r"\n123456" ③

result3 = re.findall("n",str3)
result4 = re.findall("n",str4)
result5 = re.findall("n",str5)

print(result3)
print(result4)
print(result5)
```

结果如下：

![image-20230327095840502](http://pic.nexopera.tech/image-20230327095840502.png)

**代码解释：**观察①②③处的区别，我们分别注意\的个数和r的用法。

- ①处一个转义字符 + 字母n，是一个特殊整体\n，用于表示换行符，因此匹配不到n这个字母。
- ②处两个转义字符 + 字母n，其中\n是一个特殊整体，再加上一个转义符号\，就将其变为一个普通字母n，因此匹配到了n。
- ③处其实和②的含义一样，也可以将特殊整体\n，变为一个普通字母n，因此同样可以匹配到n。

#### **4 ^和$符号**

![image-20230327095927905](http://pic.nexopera.tech/image-20230327095927905.png)

**案例如下：**

```
import re

str6 = "你来自哪里？我来自湖北省"

result7 = re.findall("^你",str6)
result8 = re.findall("^来",str6)

result9 = re.findall("省$",str6)
result10 = re.findall("湖北$",str6)

print(result7)
print(result8)
print(result9)
print(result10)
```

结果如下：

![image-20230327095949533](http://pic.nexopera.tech/image-20230327095949533.png)

**代码解释：**一个用于匹配开头，一个用于匹配结尾。只有开头或结尾与要匹配的值一致，才能被匹配到。

#### **5 .\*?符号**

![image-20230327100006216](http://pic.nexopera.tech/image-20230327100006216.png)

**案例如下：**

```
import re

str6 = "abcdaabb"

result10 = re.findall("a.b",str7) ①
result11 = re.findall("a*b",str7) ②
result12 = re.findall("a?b",str7) ③

result13 = re.findall("a.*b",str7) ④
result14 = re.findall("a.*?b",str7) ⑤

print(result10)
print(result11)
print(result12)
print(result13)
print(result14)
```

结果如下：

![image-20230327100016175](http://pic.nexopera.tech/image-20230327100016175.png)

**代码解释：**点号一般与*号和?号搭配使用。仔细观察①-⑤处的正则表达式，开头和结尾都是a、b，唯一不同的就是它们之间的符号。

- ①处点号表示匹配（除了换行符）任意单个字符。因此，只要开头是a，结尾是b，中间是任何一个单个字符，都会被匹配上。
- ②处*号表示匹配前面一个字符0或多次，在这里 * 号前面是a。因此，只要结尾是b，前面是>=0个a的值，都会被匹配上。
- ③处?号表示匹配前面一个字符最多一次，在这里 * 号前面是a。因此，前面是大于等于0、小于等于1个a的值，都会被匹配上。
- ④.*组合 ，称为“贪婪匹配”，是因为它会匹配到尽可能多的内容。原本开头是a，那么只要找到b，就是一个返回值。但是贪婪匹配不这样，它会一直朝后面走，直到找到最后一个b才肯罢休，然后返回一个超级长的字符串。
- ⑤.*?组合 ，称为“非贪婪匹配”，就是为了制止贪婪匹配而生的。它不贪得无厌，只要开头是a，你后面不是想要b吗，我碰到第一个就给你返回了。

#### **6 ( )符号**

![image-20230327100027229](http://pic.nexopera.tech/image-20230327100027229.png)

**案例如下：**

```
import re

str8 = "a321b木头人c"

result15 = re.findall("a(\d+)b([\u4e00-\u9fa5]+)c",str8)

print(result15)
```

结果如下：

![image-20230327100033988](http://pic.nexopera.tech/image-20230327100033988.png)

**代码解释：**()表示一个组，只要是()中的内容，最后都会被返回。

## 6个特殊字符

接着介绍的是6个常用字母，它们与转义符号搭配，有着自己独特的含义；

![image-20230327100040481](http://pic.nexopera.tech/image-20230327100040481.png)

## **1 \d与\D**

![image-20230327100049012](http://pic.nexopera.tech/image-20230327100049012.png)

**案例如下：**

```
import re

str1 = "123\n黄同学@#%嘻嘻\t"

result1 = re.findall("\d",str1)
result2 = re.findall("\D",str1)

print(result1)
print(result2)
```

结果如下：

![image-20230327100057534](http://pic.nexopera.tech/image-20230327100057534.png)

**代码解释：**\d仅匹配数字，\D用于匹配非数字，很好理解。

#### **2 \s与\S**

![image-20230327100105707](http://pic.nexopera.tech/image-20230327100105707.png)

**案例如下：**

```
import re

str2 = "\r123\n黄同学@#%嘻嘻\t"

result3 = re.findall("\s",str2)
result4 = re.findall("\S",str2)

print(result3)
print(result4)
```

结果如下：

![image-20230327100117038](http://pic.nexopera.tech/image-20230327100117038.png)

**代码解释：**\s仅匹配空白字符，\S用于匹配非空白字符（这个更常用）。

#### **3 \w与\W**

![image-20230327100124936](http://pic.nexopera.tech/image-20230327100124936.png)

**案例如下：**

```
import re

str3 = "\r123\n黄同学_@#%嘻嘻\t"

result5 = re.findall("\w",str3)
result6 = re.findall("\W",str3)

print(result5)
print(result6)
```

结果如下：

![image-20230327100133676](http://pic.nexopera.tech/image-20230327100133676.png)

**代码解释：**\w相当于[A-Za-Z0-9_]，超好用（值得注意），\W匹配非单词字符，了解即可。

13个案例助你理解 "正则表达式" ！

Nexopera是一个专注于Linux、网络和运维等领域的博客网站。将为读者提供广泛的相关文章，涵盖操作系统、服务器管理、网络配置、安全性等多个主题。如果你是初学者，希望这里有适合你的内容。