发表于 | 更新于 | 分类于 | 评论数：
本文字数： 8.7k | 阅读时长 ≈ 8 分钟

此篇文章为我个人学习笔记，出自倪朋飞老师的Linux性能优化实战，强烈建议购买：https://time.geekbang.org/column/intro/140

# Linux 网络收发流程 ## 网络包的接收流程 当一个网络帧到达网卡后，网卡会通过 DMA 方式，把这个网络包放到收包队列中；然后通过硬中断，告诉中断处理程序已经收到了网络包。 接着，网卡中断处理程序会为网络帧分配内核数据结构（sk_buff），并将其拷贝到 **sk_buff 缓冲区**中；然后再通过软中断，通知内核收到了新的网络帧。
阅读全文 »

发表于 | 更新于 | 分类于 | 评论数：
本文字数： 2.4k | 阅读时长 ≈ 2 分钟

引用内容

2个方法，一是使用官方的blockquote，二是直接使用 >方法，这是markdown的写法。

1
<blockquote>引用内容</blockquote>

引用内容

引用内容

阅读全文 »

发表于 | 分类于 | 评论数：
本文字数： 726 | 阅读时长 ≈ 1 分钟

5T容量申请

打开https://t.odmail.cn/或者http://mail.hrka.net临时邮箱，直接注册https://signup.microsoft.com/signup?sku=faculty即可。注意，临时邮箱必须保存，因为这是登陆账号~

阅读全文 »

发表于 | 分类于 | 评论数：
本文字数： 5.6k | 阅读时长 ≈ 5 分钟

用法

rsync是有2个传输认证模式的，一种是通过ssh，另一种是通过daemon方式。长期使用的话，建议使用daemon；临时使用，可以选择通过ssh的方式来处理。如果需要使用ssh+shell方式同步数据，可以使用ssh-keygen生成密匙或者使用sshpass来实现。

阅读全文 »

发表于 | 更新于 | 分类于 | 评论数：
本文字数： 20k | 阅读时长 ≈ 18 分钟

FIN-WAIT-1过多实战

基础知识

对于FIN-WAIT-1是什么，有什么用，请查看tcpip的内核篇。这里主要介绍conntrack、nc命令以及iptables命令。

NC

使用nc需要安装yum install nmap-ncat包，其官方地址：http://netcat.sourceforge.net/ 主要的参数如下：

1
2
3
4
5
6
7
8
-l	监听模式
-p	开启指定端口
-u	默认是TCP，-u参数调整为udp.
-z	参数告诉netcat使用0 IO,连接成功后立即关闭连接， 不进行数据交换
-v	详细输出
-n	参数告诉netcat 不要使用DNS反向查询IP地址的域名
-w<超时秒数> 设置等待连线的时间
-s<来源地址> 设置本地主机送出数据包的IP地址。

扫描端口：

1
2
3
4
5
6
7
8
[root@localhost ~]# nc -z -v 192.168.1.60 22
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.1.60:22.
Ncat: 0 bytes sent, 0 bytes received in 0.06 seconds.
[root@localhost ~]# nc -z -w 2 192.168.1.60 22 && echo $?
0
[root@localhost ~]# nc -z -w 2 192.168.1.60 2233 ; echo $?
1

服务器监听端口，先在server上开启一个端口：

1
[root@master ~]# nc -l -p 2000 < ipinfo.txt

在client上运行命令：

1
2
3
4
5
[root@localhost ~]# nc 192.168.1.60 2000
eth0 192.168.1.60 255.255.255.0 - 

123
^C

这时可以看到client上面有输出了ipinfo.txt的内容，再在client输入123这个内容，在server上面也是有同步输出的。

iptables

iptables的LOG 将封包相关讯息纪录在 /var/log 中，进行完此处理动作后，将会继续比对其规则。例如： iptables -I OUTPUT -m state --state NEW -j LOG --log-prefix "[OUTPUT] new: "

在/var/log/message日志中就有以下日志：

1
Jun 14 04:28:47 master kernel: [OUTPUT] new: IN= OUT=eth0 SRC=192.168.1.60 DST=14.215.177.39 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=47485 DF PROTO=TCPSPT=36736 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0

conntrack

安装yum install conntrack-tools -y连接跟踪工具。安装完成之后，可以使用conntrack命令来查看系统的连接情况。iptables log其实是借用此功能实现的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 统计总的连接跟踪数 -L 表示列表，-o 表示以扩展格式显示
$ conntrack -L -o extended | wc -l
14289
 
# 统计 TCP 协议各个状态的连接跟踪数
$ conntrack -L -o extended | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}'
SYN_RECV 4
CLOSE_WAIT 9
ESTABLISHED 2877
FIN_WAIT 3
SYN_SENT 2113
TIME_WAIT 9283
 
# 统计各个源 IP 的连接跟踪数
$ conntrack -L -o extended | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10
  14116 192.168.0.2
    172 192.168.0.96

跟内核相关的参数有：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@master ~]# sysctl -a |& grep conntrack |egrep "max|count|buckets|timeout_"
net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_count = 7
net.netfilter.nf_conntrack_expect_max = 256
net.netfilter.nf_conntrack_max = 65536
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 43200
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.nf_conntrack_max = 65536
  • net.netfilter.nf_conntrack_count，表示当前连接跟踪数；
  • net.netfilter.nf_conntrack_max，表示最大连接跟踪数；
  • net.netfilter.nf_conntrack_buckets，表示连接跟踪表的大小。

如果message里面有看到 “nf_conntrack: table full” 的错误时，就表明 nf_conntrack_max 太小了。

一般情况下，连接跟踪对象大小为 376，链表项大小为 16，那么连接跟踪表占用的内存大小为：nf_conntrack_max* 连接跟踪对象大小 + nf_conntrack_buckets* 链表项大小=65536*376B + 16384*16B=23.75MB

另外可以看到nf_conntrack_tcp_timeout_fin_wait的时间为120秒，如果系统里面有大量的FIN-WAIT-1/-2的话，可以减少该值，其他的timeout类似。

实验部分

准备工作

在server、client分别安装yum install conntrack-tools -y连接跟踪工具。然后在server上面将conntrack tcp timeout设置得短点：sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=20，以及下放iptables规则：

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
iptables -P INPUT ACCEPT
iptables -F
iptables -X
iptables -Z
# 在日志里记录INPUT chain里过来的每个报文的状态
iptables -A INPUT -p tcp -m state --state NEW -j LOG --log-prefix "[iptables] INPUT NEW: "
iptables -A INPUT -p TCP -m state --state ESTABLISHED -j LOG --log-prefix "[iptables] INPUT ESTABLISHED: "
iptables -A INPUT -p TCP -m state --state RELATED -j LOG --log-prefix "[iptables] INPUT RELATED: "
iptables -A INPUT -p TCP -m state --state INVALID -j LOG --log-prefix "[iptables] INPUT INVALID: "
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 8088 -m state --state NEW -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# 在日志里记录OUTPUT chain里过来的每个报文的状态
iptables -A OUTPUT -p tcp -m state --state NEW -j LOG --log-prefix "[iptables] OUTPUT NEW: "
iptables -A OUTPUT -p TCP -m state --state ESTABLISHED -j LOG --log-prefix "[iptables] OUTPUT ESTABLISHED: "
iptables -A OUTPUT -p TCP -m state --state RELATED -j LOG --log-prefix "[iptables] OUTPUT RELATED: "
iptables -A OUTPUT -p TCP -m state --state INVALID -j LOG --log-prefix "[iptables] OUTPUT INVALID: "
# iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
service iptables save
systemctl restart iptables.service

开始测试

在server端开启监听端口nc -l -p 8088，再打开一个tab页，运行tailf /var/log/messages |grep 8088来查看iptables的日志，然后在client运行nc 192.168.1.60 8088，最后在server运行：

1
2
3
4
5
6
7
8
9
10
11
12
[root@master ~]# conntrack -L |& grep 8088
tcp      6 7 ESTABLISHED src=192.168.1.61 dst=192.168.1.60 sport=43708 dport=8088 src=192.168.1.60 dst=192.168.1.61 sport=8088 dport=43708 [ASSURED] mark=0 use=1
[root@master ~]# lsof -p 29382 -P -n
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
nc      29382 root  cwd    DIR    8,3     4096 537378689 /root
nc      29382 root  rtd    DIR    8,3      224        64 /
nc      29382 root  txt    REG    8,3   380216 806371454 /usr/bin/ncat
....
nc      29382 root    2u   CHR  136,2      0t0         5 /dev/pts/2
nc      29382 root    5u  IPv4  41116      0t0       TCP 192.168.1.60:8088->192.168.1.61:43708 (ESTABLISHED)
[root@master ~]# ss -tn |grep 8088
ESTAB      0      0      192.168.1.60:8088               192.168.1.61:43708

可以看到此连接已经是ESTABLISHED状态了。使用lsof也可以看到此 状态。

不要做任何操作，等待20秒。再运行命令：

1
2
3
4
5
6
[root@master ~]# conntrack -L |& grep 8088
[root@master ~]#
[root@master ~]# kill -9 29382
[root@master ~]# ss -tn |grep 8088
State       Recv-Q Send-Q        Local Address:Port                       Peer Address:Port                          
FIN-WAIT-2  0      0              192.168.1.60:8088                       192.168.1.61:43708

可以看到，并没有conntrack里面没有8088端口的状态，可想而知，内核已经将此连接给断掉了，但是lsof还是显示ESTABLISHED状态。

从ss -tn 的输出中可以看到状态变成了FIN-WAIT-2，为什么是这个状态呢？我们看一下messages日志：

1
2
3
4
5
6
7
8
[root@master ~]# tailf /var/log/messages |grep 8088
Jun 15 22:48:45 master kernel: [iptables] INPUT NEW: IN=eth0 OUT= MAC=02:11:32:26:f6:08:02:11:32:20:c1:30:08:00 SRC=192.168.1.61 DST=192.168.1.60 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49894 DF PROTO=TCP SPT=43708 DPT=8088 WINDOW=29200 RES=0x00 SYN URGP=0 
Jun 15 22:48:45 master kernel: [iptables] OUTPUT ESTABLISHEDIN= OUT=eth0 SRC=192.168.1.60 DST=192.168.1.61 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=8088 DPT=43708 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
Jun 15 22:48:45 master kernel: [iptables] INPUT ESTABLISHED:IN=eth0 OUT= MAC=02:11:32:26:f6:08:02:11:32:20:c1:30:08:00 SRC=192.168.1.61 DST=192.168.1.60 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=49895 DF PROTO=TCP SPT=43708 DPT=8088 WINDOW=229 RES=0x00 ACK URGP=0 


Jun 15 22:50:51 master kernel: [iptables] OUTPUT INVALID: IN= OUT=eth0 SRC=192.168.1.60 DST=192.168.1.61 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=14265 DF PROTO=TCP SPT=8088 DPT=43708 WINDOW=227 RES=0x00 ACK FIN URGP=0
Jun 15 22:50:51 master kernel: [iptables] INPUT NEW: IN=eth0 OUT= MAC=02:11:32:26:f6:08:02:11:32:20:c1:30:08:00 SRC=192.168.1.61 DST=192.168.1.60 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=49896 DF PROTO=TCP SPT=43708 DPT=8088 WINDOW=229 RES=0x00 ACK URGP=0

可以看到前三条是建立链接的请求。而是第四条的时候，此连接状态直接变成了OUTPUT INVALID，由于上面的iptable的iptables -A OUTPUT -m state --state INVALID -j DROP是注释的，包是可以发出去的，那为什么最后一条 内核又认为是一个新的请求呢？先思考下。

client是可以正常收到FIN包，之后会回复ACK确认包，但在server看来，这是一条新的请求过来了，但是我已经停止服务8088端口的，所以服务器就不到响应了。下面是抓包看下的内容：

1
2
3
4
5
6
23:25:01.808314 IP 192.168.1.61.43712 > 192.168.1.60.8088: Flags [S], seq 1414242879, win 29200, options [mss 1460,sackOK,TS val 398212597 ecr 0,nop,wscale 7], length 0
23:25:01.810707 IP 192.168.1.60.8088 > 192.168.1.61.43712: Flags [S.], seq 2138733076, ack 1414242880, win 28960, options [mss 1460,sackOK,TS val 398217386 ecr 398212597,nop,wscale 7], length 0
23:25:01.810830 IP 192.168.1.61.43712 > 192.168.1.60.8088: Flags [.], ack 1, win 229, options [nop,nop,TS val 398212600 ecr 398217386], length 0

23:27:09.126103 IP 192.168.1.60.8088 > 192.168.1.61.43712: Flags [F.], seq 1, ack 1, win 227, options [nop,nop,TS val 398344706 ecr 398212600], length 0
23:27:09.197216 IP 192.168.1.61.43712 > 192.168.1.60.8088: Flags [.], ack 2, win 229, options [nop,nop,TS val 398339921 ecr 398344706], length 0

为什么kill进程后socket一直处于FIN_WAIT_1状态，https://yq.aliyun.com/articles/704262，源码级别，有兴趣可以查看。

线上问题实例

在线上一台服务器出现了too many open files的报错（线上业务，对报错信息做了修改，其重点是socket的报错）：

1
2
[2019/06/06 13:36:00] [E] syncHttpClient: Get https://1.1.1.1:59211/: dial tcp 1.1.1.1:59211: socket: too many open files
[2019/06/06 13:36:10] [E] syncHttpClient: Get https://1.1.1.1:59211/ dial tcp 1.1.1.1:59211: socket: too many open files

第一反应是去查看ulimit -n，发现设置的值是12W，并没有什么问题。但去查看tcp连接数的时候就看出异常出来了。FIN-WAIT-1数达到了6W多次，很不正常。

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
[op@localhost ~]$ ss -s
Total: 65847 (kernel 66009)
TCP:   65795 (estab 65707, closed 64, orphaned 12, synrecv 0, timewait 63/0), ports 100

Transport Total     IP        IPv6
*	  66009     -         -
RAW	  2         2         0
UDP	  2         2         0
TCP	  65731     60        65671
INET	  65735     64        65671
FRAG	  0         0         0

[op@localhost ~]$ ss -tn |awk '{a[$1]++}END{for(i in a)print i,a[i]}' |sort -k2 -rn |head -n 10
FIN-WAIT-1 61420
ESTAB 56
SYN-SENT 16
LAST-ACK 9
CLOSE-WAIT 2
State 1
[op@localhost ~]$ ss -tn |grep FIN-WAIT-1 |more
FIN-WAIT-1 0      1         ::ffff:2.2.2.2:22222     ::ffff:183.159.166.48:55020
FIN-WAIT-1 0      1         ::ffff:2.2.2.2:22222   ::ffff:116.24.95.50:16815
FIN-WAIT-1 0      1         ::ffff:2.2.2.2:22222     ::ffff:122.234.71.140:6033
FIN-WAIT-1 0      1         ::ffff:2.2.2.2:22222   ::ffff:112.97.52.91:56463
FIN-WAIT-1 0      1         ::ffff:2.2.2.2:22222  ::ffff:183.230.42.68:44926

为什么不正常呢？这是由于四次挥手时，谁主动发起FIN包，谁就进入了FIN-WAIT-1的状态。从上输出可以看到，都是服务器本身发起的FIN包(假设2.2.2.2为服务器的IP)。所以在怀疑有人在对22222端口做攻击，这时使用iptables来drop掉这个流量，服务器就恢复正常了。

C1M

所谓的C1M指的是服务器要达到100M的并发连接，在这一篇里面，全部参考的是http://www.blogjava.net/yongboy/archive/2013/04/09/397559.html，因为我不是开发，其里面的代码我是看不懂的，我从运维角度来记录一下我的实验过程。

阅读全文 »

发表于 | 更新于 | 分类于 | 评论数：
本文字数： 9.5k | 阅读时长 ≈ 9 分钟

TCP状态

根据原理篇的描述，在TCP三次握手以及四次挥手时，tcp会处于不同的状态，对应netstat -tun或者ss -tun那输出的各种状态，如下：

1
2
3
4
[root@xmxyk ~]#netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
SYN_RECV 78
ESTABLISHED 1
TIME_WAIT 4
阅读全文 »

发表于 | 更新于 | 分类于 | 评论数：
本文字数： 7.9k | 阅读时长 ≈ 7 分钟

简介

Docker 最初是 dotCloud 公司创始人 Solomon Hykes 在法国期间发起的一个公司内部项目，它是基于 dotCloud 公司多年云服务技术的一次革新，并于 2013 年 3 月以 Apache 2.0 授权协议开源，主要项目代码在 GitHub 上进行维护。Docker 项目后来还加入了 Linux 基金会，并成立推动 开放容器联盟（OCI）。

Docker 自开源后受到广泛的关注和讨论，至今其 GitHub 项目已经超过 4 万 6 千个星标和一万多个 fork。甚至由于 Docker 项目的火爆，在 2013 年底，dotCloud 公司决定改名为 Docker。Docker 最初是在 Ubuntu 12.04 上开发实现的；Red Hat 则从 RHEL 6.5 开始对 Docker 进行支持；Google 也在其 PaaS 产品中广泛应用 Docker。

Docker 使用 Google 公司推出的 Go 语言 进行开发实现，基于 Linux 内核的 cgroup，namespace，以及 AUFS 类的 Union FS 等技术，对进程进行封装隔离，属于 操作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。最初实现是基于 LXC，从 0.7 版本以后开始去除 LXC，转而使用自行开发的 libcontainer，从 1.11 开始，则进一步演进为使用 runC 和 containerd。

阅读全文 »

发表于 | 更新于 | 分类于 | 评论数：
本文字数： 2.4k | 阅读时长 ≈ 2 分钟

简介

Scoop是优质的 Windows 包管理器。它不仅轻量，还将软件直接安装到我们的用户目录下，安装过程不需要申请管理员权限（UAC）也不会污染系统环境变量。

阅读全文 »
0%