linux工作必备 tcpdump抓包工具常用命令\ netcat(nc)命令\TCP洪水攻击（SYN Flood）的诊断和处理\TCP连接数、Linux问题定位、history历史操作记录

一、linux工作必备 tcpdump抓包工具常用命令

1. tcpdump 安装

yum install tcpdump

2. tcpdump常用选项

• -i 指定要捕获的目标网卡名，网卡名可以使用前面章节中介绍的 ifconfig 命令获得；如果要抓所有网卡的上的包，可以使用 any 关键字。
• -X 以 ASCII 和十六进制的形式输出捕获的数据包内容，减去链路层的包头信息；
• -n 不要将 ip 地址显示成别名的形式；-nn 不要将 ip 地址和端口以别名的形式显示。
• -S 以绝对值显示包的 ISN 号（包序列号），默认以上一包的偏移量显示。
• -vv 抓包的信息详细地显示；-vvv 抓包的信息更详细地显示。
• -w 将抓取的包的原始信息（不解析，也不输出）写入文件中，后跟文件名：tcpdump -i any -w filename
• -r 从利用 -w 选项保存的包文件中读取数据包信息。

3. 工作常用命令举例

1. 抓某个端口的数据
   抓取源或者目标端口都是80的包

    tcpdump -i any -n -nn port 80
   

   抓取192.168的包(不管是source还是destination )

   tcpdump -i any -n -nn host 192.168
   

   -i any的选项，表示抓取所有网络接口上的包

   - 抓取所有经过 eth1，目的或源地址是 192.168.1.1 的网络数据
   # tcpdump -i eth1 host 192.168.1.1
   - 源地址
   # tcpdump -i eth1 src host 192.168.1.1
   - 目的地址
   # tcpdump -i eth1 dst host 192.168.1.1
   

2. 查看当前机器有哪些网络接口
   tcpdump -D

   root@VM-0-2-ubuntu:~# tcpdump -D
   1.br-dbae824b85db [Up, Running]
   2.eth0 [Up, Running]
   3.veth98a5be0 [Up, Running]
   4.vethed2bad5 [Up, Running]
   5.vethf708274 [Up, Running]
   6.lo [Up, Running, Loopback]
   7.any (Pseudo-device that captures on all interfaces) [Up, Running]
   8.docker0 [Up]
   9.bluetooth-monitor (Bluetooth Linux Monitor) [none]
   10.nflog (Linux netfilter log (NFLOG) interface) [none]
   11.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
   
   

二、netcat(nc)

netcat(nc)是一个简单而有用的工具，被誉为网络安全界的“瑞士军刀”，不仅可以通过使用TCP或UDP协议的网络连接读写数据，同时还是一个功能强大的网络调试和探测工具，能够建立你需要的几乎所有类型的网络连接。

yum install nc

unbuntu使用传统的nc
Ubuntu上默认安装的是netcat-openbsd,而不是经典的netcat-traditional.
网上例子很多都是以netcat-traditional为例.
sudo apt-get -y install netcat-traditional
设置默认的nc,选择/bin/nc.traditional:
sudo update-alternatives --config nc

使用nc -l 9999 来监听端口，并发送数据
nc -lk 8888

再开一台主机，进行测试：　
netstat -anop |grep 8888 //在连接之前查看端口是否存在
nc localhost 8888　　　　　　　　//连接端口进行聊天

三、tcpdump、nc验证网络环境实例

实例一 ：连接一个正常的侦听端口

1. 用 nc 命令在一个 shell 窗口创建一个服务器程序并在这个地址上进行侦听
   使用nc -l 来监听端口，并发送数据

nc -lk 8888
netstat -anop |grep 8888        //在连接之前查看端口是否存在

在另外一个 shell 窗口开启 tcpdump 抓包

tcpdump -i any 'port 8888' -XX -nn -vv

2. 再开一台主机，进行测试：

nc x.x.x.x 8888　　　　　　　　//连接端口进行聊天

我们抓到的包如下：

由于我们没有在客户端和服务器之间发送任何消息，其实抓到的包就是 TCP 连接的三次握手数据包，分析如下：

三次握手过程是客户端先给服务器发送一个 SYN，然后服务器应答一个 SYN + ACK，应答的序列号是递增 1的，表示应答哪个请求，即从 3217340359 递增到 3217340360，接着客户端再应答一个 ACK。这个时候，我们发现发包序列号和应答序列号都变成 1了，这是 tcpdump 使用相对序号，我们加上 -S 选项后就变成绝对序列号了。

我们按 Ctrl + C 中断 tcpdump 抓包过程，并停止用 nc 开启的客户端和服务器程序，然后在前面的 tcpdump 命令后面加上 -S选项重新开启抓包，
tcpdump -i any ‘port 8888’ -XX -nn -vv -S
这次得到的包的序号就是绝对序号了。

实例一演示的是正常的 TCP 连接三次握手过程捕获到的数据包。

实例二：连接的服务器 ip 地址存在，但监听端口号不存在

在一个 shell 窗口启动一个 tcpdump 抓包监测，在另外一个 shell 窗口用 nc 命令去连接一个不存在的侦听端口即可。

tcpdump -i any 'port 8886' -XX -nn -vv

另一个窗口

nc x.x.x.x  8886

抓包数据如下：

这个时候客户端发送 SYN，服务器应答 ACK+RST，这个应答包会导致客户端的 connect 连接失败返回。

实例三：连接一个很遥远的 ip，或者网络繁忙的情形

实际情形中，还存在一种情况就是客户端访问一个很遥远的 ip，或者网络繁忙，服务器对客户端发送的 TCP 三次握手的网络 SYN 报文没有应答，会出现什么情况呢？

iptables -F
iptables -I INPUT -p tcp --syn -i lo -j DROP
tcpdump -i any 'port 8885' -XX -nn -vv

另一个窗口

nc x.x.x.x  8885

在开启 tcpdump 抓包之后和设置防火墙规则之后，利用 nc 命令去连接 127.0.0.1:8885 这个地址。整个过程操作效果图如下：

通过抓包数据我们可以看到：如果连接不上，一共重试了 5次，重试的时间间隔是 1 秒，2秒，4秒，8秒，16秒，最后返回超时失败。这个重试次数在 /proc/sys/net/ipv4/tcp_syn_retries 内核参数中设置，默认为 6 。

四、 常见TCP问题定位分析

0. 常用命令

linux查看某一个进程的socket连接数

1. ss -ntp | grep 进程名 | wc -l

2. ls /proc/38648/fd -l | wc -l 38648为进程pid

3. lsof -p 38648 | wc -l 38648为进程pid

netstat -n | grep 5044 | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

 #ulimit -n
1024

这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的标准输入，标准输出，标准错误，服务器监听 socket，进程间通讯的unix域socket等文件，那么剩下的可用于客户端socket连接的文件数就只有大概1024-10=1014个左右。也就是说缺省情况下，基于Linux的通讯程序最多允许同时1024个TCP并发连接。

1、lsof -i:端口号
ls open file -i:端口号

以上为进程ID为8246和8247的nginx应用，占用80端口。

2、netstat -tunlp|grep 端口号
tcp/udp/显示数字/list/进程

Linux文件句柄数查询

单程序句柄数限制

ulimit -n

cat /etc/security/limits.conf
参考配置：

• soft nofile 655360
• hard nofile 655360

全局句柄数限制

cat /proc/sys/fs/file-max

参考配置：
6815744

分析句柄数常用命令
（1）统计各进程打开句柄数：lsof -n|awk ‘{print $2}’|sort|uniq -c|sort -nr
（2）统计各用户打开句柄数：lsof -n|awk ‘{print $4}’|sort|uniq -c|sort -nr
（3）统计各命令打开句柄数：lsof -n|awk ‘{print $1}’|sort|uniq -c|sort -nr

1. TCP洪水攻击（SYN Flood）的诊断和处理

检查系统日志
tail -f /var/log/messages
Apr 18 11:21:56 web5 kernel: possible SYN flooding on port 80. Sending cookies.

检查连接数增多，并且是不是SYN_RECV 连接特别多：

# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 
TIME_WAIT 16855
CLOSE_WAIT 21
SYN_SENT 99
FIN_WAIT1 229
FIN_WAIT2 113
ESTABLISHED 8358
SYN_RECV 48965
CLOSING 3
LAST_ACK 313

根据经验，正常时检查连接数如下：

# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 42349
CLOSE_WAIT 1
SYN_SENT 4
FIN_WAIT1 298
FIN_WAIT2 33
ESTABLISHED 12775
SYN_RECV 259
CLOSING 6
LAST_ACK 432

应急处理
方法1：利用iptables临时封掉最大嫌疑攻击的IP或IP号段

# netstat -na |grep SYN_RECV|more

利用iptables临时封掉最大嫌疑攻击的IP或IP号段，例如对方假冒173...号段来攻击，短期禁用172..*.*这个大号段（要确认小心不要封掉自己的本地IP了！）

# iptables -A INPUT -s  172.0.0.0/8  -p tcp  –dport 80 -j DROP

这样应急处理很容易误伤，甚至可能因为封错了导致ssh登陆不了服务器，并不是理想方式。

方法2：调整系统参数挡攻击

对于服务器端
tcp_synack_retries默认为5，表示重发5次，每次等待30~40秒，即“半连接”默认hold住大约180秒。
参数tcp_synack_retries = 0是关键，表示回应第二个握手包（SYN+ACK包）给客户端IP后，如果收不到第三次握手包（ACK包）后，不进行重试，加快回收“半连接”，不要耗光资源。

不修改这个参数，模拟攻击，10秒后被攻击的80端口即无法服务，机器难以ssh登录； 用命令netstat -na |grep SYN_RECV检测“半连接”hold住180秒；

修改这个参数为0，再模拟攻击，持续10分钟后被攻击的80端口都可以服务，响应稍慢些而已，只是ssh有时也登录不上；检测“半连接”只hold住3秒即释放掉。

修改这个参数为0的副作用：**网络状况很差时，如果对方没收到第二个握手包，可能连接服务器失败，**但对于一般网站，用户刷新一次页面即可。这些可以在高峰期或网络状况不好时tcpdump抓包验证下。

根据以前的抓包经验，这种情况很少，但为了保险起见，可以只在被tcp洪水攻击时临时启用这个参数。

**之所以可以把tcp_synack_retries改为0，因为客户端还有tcp_syn_retries参数，默认是5，即使服务器端没有重发SYN+ACK包，客户端也会重发SYN握手包。**详细解释：
详细解释：
第二个参数net.ipv4.tcp_max_syn_backlog = 200000也重要，具体多少数值受限于内存。内核参数net.ipv4.tcp_max_syn_backlog定义了处于SYN_RECV的TCP最大连接数，当处于SYN_RECV状态的TCP连接数超过tcp_max_syn_backlog后，会丢弃后续的SYN报文。 可以看到当sysctl_max_syn_backlog=2时,根据内核算法，最终1<<3=16。这就是net.ipv4.tcp_max_syn_backlog的最小值
将tcp_syncookies设置为0，并将net.ipv4.tcp_max_syn_backlog设置为2
使用如下脚本模拟syn flood攻击，**当 watch ‘netstat -antp|grep SYN_RECV|wc -l’ 等于16时，换一台机器连接server发现连接超时；**设置 tcp_syncookies=1， 重复上面测试，当 watch ‘netstat -antp|grep SYN_RECV|wc -l’ 等于16时，换一台机器连接server发现此时连接成功。
参考文章： https://cloud.tencent.com/developer/article/1603612

以下配置，第一个参数是最重要的，第二个参数是辅助的：

# vi /etc/sysctl.conf
使配置生效：

# sysctl -p

因为经过试验，大量TIME_WAIT状态的连接对系统没太大影响

[root@centOS6 ~]# cat  /proc/sys/net/ipv4/tcp_syn_retries
5

详细解释：
The tcp_synack_retries setting tells the kernel how many times to retransmit the SYN,ACK reply to
an SYN request. In other words, this tells the system how many times to try to establish a passive
TCP connection that was started by another host.
This variable takes an integer value, but should under no circumstances be larger than 255 for the
same reasons as for the tcp_syn_retries variable. Each retransmission will take aproximately 30-40
seconds. The default value of the tcp_synack_retries variable is 5, and hence the default timeout
of passive TCP connections is aproximately 180 seconds.

2. 提升linux下TCP服务器并发连接数（ulimit )

$ ulimit -n
   1024

这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的标准输入，标准输出，标准错误，服务器监听 socket，进程间通讯的unix域socket等文件，那么剩下的可用于客户端socket连接的文件数就只有大概1024-10=1014个左右。也就是说缺省情况下，基于Linux的通讯程序最多允许同时1014个TCP并发连接。

对于想支持更高数量的TCP并发连接的通讯处理程序，就必须修改Linux对当前用户的进程同时打开的文件数量的软限制(soft limit)和硬限制(hardlimit)。其中软限制是指Linux在当前系统能够承受的范围内进一步限制用户同时打开的文件数；硬限制则是根据系统硬件资源状况(主要是系统内存)计算出来的系统最多可同时打开的文件数量。通常软限制小于或等于硬限制。

修改上述限制的最简单的办法就是使用ulimit命令：
ulimit -n <file_num>

上述命令中，在<file_num>中指定要设置的单一进程允许打开的最大文件数。如果系统回显类似于“Operation notpermitted”之类的话，说明上述限制修改失败，实际上是因为在<file_num>中指定的数值超过了Linux系统对该用户打开文件数的软限制或硬限制。因此，就需要修改Linux系统对用户的关于打开文件数的软限制和硬限制。

第一步，修改/etc/security/limits.conf文件，在文件中添加如下行：

* soft nofile 65535
* hard nofile 65535

其中’*'号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；65535则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。

3. 大量 CLOSE_WAIT 的原因及解决方法

linux 设置 tcp_keepalive_time,tcp参数详解之 tcp_keepalive_time
参考URL: https://blog.youkuaiyun.com/weixin_42392367/article/details/117010695
CLOSE_WAIT过多的解决方法
参考URL: https://blog.youkuaiyun.com/hellozhxy/article/details/90030332
关于网络连接CLOSE_WAIT状态的问题
参考URL: https://www.jianshu.com/p/42918db85f19
CLOSE_WAIT过多的解决方法
https://blog.youkuaiyun.com/hellozhxy/article/details/90030332
服务器出现大量close_wait，我们来说说到底是怎么回事？（以tomcat为例）
参考URL: https://www.cnblogs.com/grey-wolf/p/10936657.html
参考URL: http://www.360doc.com/content/20/0620/16/17033725_919572736.shtml

netstat -an|grep CLOSE_WAIT|wc -l 查看当前服务器上处于 CLOSE_WAIT 状态的连接数，根据服务器上的业务量来判断 CLOSE_WAIT 数量是否超出了正常的范围

netstat -an|grep CLOSE_WAIT|wc -l
ss -ntp | grep 端口号 | wc -l

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。
假设终止命令由client端发起。
当clien端传输完成数据，或者需要断开连接时：

1 Client端发送一个FIN报文给Server端。(序号为M)
1.1. 表示要终止Client到Server这个方向的连接。
1.1. 通过调用close(socket) API。
1.3 表示Client不再会发送数据到Server端。(但Server还能继续发给Client端)
1.4 Client状态变为FIN_WAIT_1

2 Server端收到FIN后，发送一个ACK报文给Client端。(序号为M+1)
2.1 Server状态变为CLOSE_WAIT
2.2 Client收到序号为(M+1)的ACK后状态变为FIN_WAIT_2

3 Server端也发送一个FIN报文给Client端。(序号为N)
3.1 表示Server也要终止到Client端这个方向的连接。
3.2. 通过调用close(socket) API。
3.3 Server端状态变为LAST_ACK

4 Client端收到报文FIN后，也发送一个ACK报文给服务器。(序号N+1)
4.1 Client状态变为TIME_WAIT

5 Server端收到序号为(N+1)的ACK
5.1 Server的状态变为CLOSED.

6 等待2MSL之后
6.1 Client的状态也变为CLOSE.

7 至此，一个完整的TCP连接就关闭了。

两个基本问题：

Q: 我们看到CLOSE_WAIT出现在什么时候呢？
A: 在Sever端收到Client的FIN消息之后。
Q: 状态CLOSE_WAIT在什么时候转换成下一个状态呢？
A: 在Server端向Client发送FIN消息之后。

为什么会出现CLOSE_WAIT的状态：如果Server端一直没有向client端发送FIN消息(调用close() API)，那么这个CLOSE_WAIT会一直存在下去。

从上面我们看到出现CLOSE_WAIT，说明Server端没有发起close()操作，这基本上是用户server端程序的问题了；通常情况下，Server都是等待Client访问，如果Client退出请求关闭连接，server端自觉close()对应的连接。

3.1 一种出现情况

我们知道一个进程打开一个socket，然后此进程fork出子进程的时候，父进程已打开的socket是会被继承的，即子进程能够继续访问这个socket。其结果就是，一个socket被两个进程打开，一个父进程和一个子进程，此时socket的引用计数会变成2。

• 调用close(socket)时，内核先检查socket上的引用计数器：如果引用计数大于1，那么将这个引用计数减1，然后直接返回。如果引用计数等于1，那么内核才会真正关闭此socket。(通过发送FIN到对端来关闭TCP连接)
• 调用shutdown(socket，HOW)时，内核不会检查此socket对应的引用计数器，直接向对端发送FIN来关闭TCP连接。
  据此分析，很大可能性是用户服务器的程序实现有问题导致的大量CLOSE_WAIT的socket，比如父进程打开了socket，然后通过fork出子进程来处理业务，父进程继续对网络请求进行监听，永远不会终止；当客户端发FIN过来的时候，处理业务的子进程处理此FIN消息，调用close()对本端进行关闭，然而这个close()调用只是把socket的引用计数器减1，因为父进程还在运行，socket并没关闭，这样就导致系统中又多了一个CLOSE_WAIT的socket，长此以往，就这样了。

3.2 CLOSE_WAIT解决方案和思路

• 检查服务器端代码，是否有没有正常close的地方。
• 修改TCP/IP的参数来缩短CLOSE_WAIT状态时间
  当客户端因为某种原因先于服务端发出了FIN信号，就会导致服务端被动关闭，若服务端不主动关闭socket发FIN给Client，此时服务端Socket会处于CLOSE_WAIT状态（而不是LAST_ACK状态）。通常来说，一个CLOSE_WAIT会维持至少2个小时的时间（系统默认超时时间的是7200秒，也就是2小时）。如果服务端程序因某个原因导致系统造成一堆CLOSE_WAIT消耗资源，那么通常是等不到释放那一刻，系统就已崩溃。

修改tcp_keepalive_*系列参数：
查看相关的参数
sysctl -a|grep tcp_keepalive

[root@centos7 ~]# sysctl -a|grep tcp_keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 1800

• /proc/sys/net/ipv4/tcp_keepalive_time
  当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时。
• /proc/sys/net/ipv4/tcp_keepalive_intvl
  当探测没有确认时，重新发送探测的频度。缺省是75秒。
  探测消息发送的频率，乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒，也就是没有活动的连接将在大约11分钟以后将被丢弃。(对于普通应用来说,这个值有一些偏大,可以根据需要改小.特别是web类服务器需要改小该值,15是个比较合适的值)
• /proc/sys/net/ipv4/tcp_keepalive_probes
  在认定连接失效之前，发送多少个TCP的keepalive探测包。缺省值是9。这个值乘以tcp_keepalive_intvl之后决定了，一个连接发送了keepalive之后可以有多少时间没有回应.
  TCP发送keepalive探测以确定该连接已经断开的次数。(注意:保持连接仅在SO_KEEPALIVE套接字选项被打开是才发送.次数默认不需要修改,当然根据情形也可以适当地缩短此值.设置为5比较合适)

tcp_keepalive_time：
tcp_keepalive_time 值控制 TCP/IP 尝试验证空闲连接是否完好的频率。 如果这段时间内没有活动，则会发送保持活动信号。 如果网络工作正常，而且接收方是活动的，它就会响应。 如果需要对丢失接收方敏感，换句话说，需要更快地发现丢失了接收方，请考虑减小这个值。 如果长期不活动的空闲连接出现次数较多，而丢失接收方的情况出现较少，您可能会要提高该值以减少开销。

缺省情况下，如果空闲连接 7200 秒(2 小时)内没有活动，Linux 就发送保持活动的消息。 通常，1800 秒是首选值，从而一半的已关闭连接会在 30 分钟内被检测到。

请使用以下过程来查看或定制您的值。
 echo 1800 >  /proc/sys/net/ipv4/tcp_keepalive_time

设置相关的参数

sysctl -w net.ipv4.tcp_keepalive_time=1800

也可以直接打开
vi /etc/sysctl.conf
加入

net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15

然后保存退出

让参数生效

sysctl -p

查看是否修改成功

sysctl -a|grep tcp_keepalive

4. linux下查找占用某端口号的进程

两种方法：
1、lsof -i:端口号
ls open file -i:端口号

[root@localhost sbin]# lsof -i:80
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
nginx   8246   root    6u  IPv4  64233      0t0  TCP *:http (LISTEN)
nginx   8247 nobody    6u  IPv4  64233      0t0  TCP *:http (LISTEN)
[root@localhost sbin]# 

以上为进程ID为8246和8247的nginx应用，占用80端口。

2、netstat -tunlp|grep 端口号
tcp/udp/显示数字/list/进程

5. Linux服务器上11种网络连接状态

Linux服务器上11种网络连接状态
http://www.voidcn.com/article/p-wahewfsn-bhx.html

netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

通常情况下:一个正常的TCP连接，都会有三个阶段:1、TCP三次握手;2、数据传送;3、TCP四次挥手
注:以下说明最好能结合”图:TCP的状态机”来理解。
SYN:(同步序列编号,Synchronize Sequence Numbers)该标志仅在三次握手建立TCP连接时有效。表示一个新的TCP连接请求。
ACK:( 确认编号 ,Acknowledgement Number) 是对 TCP 请求的确认标志 , 同时提示对端系统已经成功接收所有数据。
FIN:( 结束标志 ,FINish) 用来结束一个 TCP 回话 . 但对应端口仍处于开放状态 , 准备接收后续数据。

1)、LISTEN:首先服务端需要打开一个socket进行监听，状态为LISTEN. /* The socket is listening for incoming connections. 侦听来自远方TCP端口的连接请求 */

2)、SYN_SENT:客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT. /*The socket is actively attempting to establish a connection. 在发送连接请求后等待匹配的连接请求 */

3)、SYN_RECV:服务端应发出ACK确认客户端的SYN,同时自己向客户端发送一个SYN. 之后状态置为SYN_RECV /* A connection request has been received from the network. 在收到和发送一个连接请求后等待对连接请求的确认 */

4)、ESTABLISHED: 代表一个打开的连接，双方可以进行或已经在数据交互了。/* The socket has an established connection. 代表一个打开的连接，数据可以传送给用户 */

5)、FIN_WAIT1:主动关闭(active close)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态./* The socket is closed, and the connection is shutting down. 等待远程TCP的连接中断请求，或先前的连接中断请求的确认 */

6)、CLOSE_WAIT:被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to close. 等待从本地用户发来的连接中断请求 */

7)、FIN_WAIT2:主动关闭端接到ACK后，就进入了FIN-WAIT-2 ./* Connection is closed, and the socket is waiting for a shutdown from the remote end. 从远程TCP等待连接中断请求 */

8)、LAST_ACK:被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭连接。这导致它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK . /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原来发向远程TCP的连接中断请求的确认 */

9)、TIME_WAIT:在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态。/* The socket is waiting after close to handle packets still in the network.等待足够的时间以确保远程TCP接收到连接中断请求的确认 */

10)、CLOSING: 比较少见./* Both sockets are shut down but we still don’t have all our data sent. 等待远程TCP对连接中断的确认 */

11)、CLOSED: 被动关闭端在接受到ACK包后，就进入了closed的状态。连接结束./* The socket is not being used. 没有任何连接状态 */

TIME_WAIT状态的形成只发生在主动关闭连接的一方。

主动关闭方在接收到被动关闭方的FIN请求后，发送成功给对方一个ACK后,将自己的状态由FIN_WAIT2修改为TIME_WAIT，而必须再等2倍 的MSL(Maximum Segment Lifetime,MSL是一个数据报在internetwork中能存在的时间)时间之后双方才能把状态 都改为CLOSED以关闭连接。目前RHEL里保持TIME_WAIT状态的时间为60秒。

四、ssh服务器服务登录不上、Linux下检测IP地址冲突及解决方法

Linux下检测IP地址冲突及解决方法

arping命令详解
参考URL： https://www.cnblogs.com/yzgblogs/p/14628913.html

问题背景：
有部分同事远程ssh登陆不上这台linux系统的机器

问题分析：
在Windows系统中，如果本地网络IP地址出现冲突，会出现图标提示。
在Linux系统中，并没有提供相关的功能，如果本地网络采用静态IP地址配置，** 出现比较奇怪的网络连接问题，如ssh连接复位，可以考虑检测一下是否是出现了IP地址冲突问题。**

arping命令提供了检测地址冲突的功能。

1） 方法一：（arping命令）：
只需要在另一台同网段的linux机器上执行下面的命令（不能在本机arping检验自己的ip）:

如果只检查出一个MAC地址，则表示网内A机器的的IP：192.168.9.120是唯一的
如果有以上信息即查出两个MAC地址，则表示网内有一台MAC地址为40:F4:EC:76:79:C2的主机IP地址与A机器相同。

检验原理：
arping命令是以广播地址发送arp packets，以太网内所有的主机都会收到这个arp packets，但是本机收到之后不会Reply任何信息。

ubuntu

apt install iputils-arping 

arping 192.168.9.120

如果只检查出一个MAC地址，则表示网内A机器的的IP：192.168.9.120是唯一的

2） 方法二：arp-scan命令

工具安装命令：
ubuntu安装命令:

sudo apt-get install arp-scan

centos安装命令：

yum install arp-scan

如果报错说没有这个软件包，则需要提前安装epel软件仓库,如下命令自动安装（推荐）

yum install epel-release -y

IP冲突检测命令:

sudo arp-scan –I eth0 -l

1）“arp-scan -l” 命令表示查看与本机在同一局域网内的所有机器的ip使用情况
2）“arp-scan –I eth0 -l” 命令表示查看与本机在同一局域网内的所有主机的eth0网卡的ip使用情况

ssh服务器服务登录不上

ssh服务器端日志相关检查

查看是否有限制IP

cat /etc/hosts.allow
cat /etc/hosts.deny

检查登录日志

more /var/log/secure
who /var/log/wtmp

然后就是检测，ssh ip 和端口是否写对，如果写对，就看是不是ip有冲突了!

五、linux下通过进程名查看其占用端口\linux下查看某一端口被哪个进程占用

1、先查看进程pid

ps -ef | grep 进程名

2、通过pid查看占用端口

netstat -nap | grep 进程pid

linux下查看某一端口被哪个进程占用
方法1: lsof命令,即ls open files

lsof -i:端口号

方法2: netstat命令

netstat -tunpl | grep 端口号

六、 linux查看历史操作记录相关

使用场景：
有时候突然被人拉去定位现场问题，一般情况，我们要熟悉现场问题环境上下文，我们可以 history迅速先查看一下，现场用户都执行哪些命令，帮助我们了解要定位问题的上下文，客户操作到哪一步了。

还有一些场景，比如我们要找出谁什么时间做了破坏行为的命令等。

1. linux查看历史操作记录并且显示执行时间

使用HISTTIMEFORMAT变量来指定命令中增加时间戳。

时间格式是%F %T，HISTTIMEFORMAT使用的是strftime函数的时间格式。

export HISTTIMEFORMAT="%F %T "

结果：

[root@localhost ~]# history  |  tail
  991  2019-12-08 17:26:33 ls
  992  2019-12-08 17:26:33 cd ..
  993  2019-12-08 17:26:33 ;s
  994  2019-12-08 17:26:33 ls
  995  2019-12-08 17:26:33 cd lib
  996  2019-12-08 17:26:33 ls
  997  2019-12-08 17:26:33 su - postgresql
  998  2019-12-08 17:26:33 su - postgres
  999  2019-12-08 17:40:24 export HISTTIMEFORMAT="%F %T "
 1000  2019-12-08 17:40:31 history  |  tail
[root@localhost ~]# 

行号 然后是HISTTIMEFORMAT的执行结果，然后是命令，注意%T后面有空格。

2. 想要记录是哪个IP操作的哪个命令

对HISTTIMEFORMAT变量进行改造
#在后面，增加who am i的执行，就是哪个ip，哪个用户登录的。

export HISTTIMEFORMAT="%F %T `who am i` "  

七、参考

TCP洪水攻击（SYN Flood）的诊断和处理
参考URL: https://www.cnblogs.com/zengkefu/p/5563636.html
linux 内核参数tcp_max_syn_backlog对应的队列最小长度
参考URL: https://cloud.tencent.com/developer/article/1603612
提升linux下TCP服务器并发连接数（limit)
https://cloud.tencent.com/developer/article/1069900