【工作必备知识】Linux系统网络诊断与netstat命令
大家好,我叫秋意零。
今天分享一篇Linux系统中与网络相关的干货(包含相关面试题),有可能对你理解网络有一定帮助。同时工作中网络诊断也时常使用,对排查问题有帮助,绝对干货。
如果有帮助记得点赞三连呀。
netstat 命令
netstat 网络连接状态查看命令,同时也是强大的强大的网络诊断工具,广泛应用于各种网络管理和故障排查场景中。
它还可以查看网络中的传输层(TCP、UDP)信息。所以你首先需要知道传输层对应的相关知识(此处不做过多介绍),由此我们可以引出TCP三次握手和四次挥手。
TCP三次握手
简单介绍:TCP三次握手是数据传输时采用的一种可靠性连接方式(建立连接形象比喻为握手🤝)。
服务器端对应的服务端口一直进入LISTEN监听状态,等待客户端连接。客户端和服务器端最后经过三次握手达到可靠性连接。可能会问:为啥是三次握手,而不是二次握手?后面有介绍哦。
本篇重点:TCP三次握手中客户端或服务器端,每次发送请求后都会进入某种状态(记住这些状态如图),这些状态我们在 Linux 系统中可以通过 netstat 命令进行查看,有助于对网络理解。
相关面试题:为什么TCP客户进程最后还要发送普通的TCP确认报文段呢?是否多余,或者是否可以使用两报文握手建立连接呢?
答案: 并不多余,不能简化为“两报文握手”
场景: 首先我们客户端发送TCP连接请求报文,如果该请求因为网络原因导致卡在了路上服务端没收到,造成了超时重传这时客户端需要重新发送TCP连接请求报文,这次服务器端收到信息后,进入ESTABLISHED 连接已建立状态;
于是返回信息给客户端,同时客户端进入 ESTABLISHED 连接已建立状态,这时就可以传输数据了,数据传输完毕后进行关闭连接;
关闭连接后,这时服务器端收到了第一次TCP连接请求报文,于是服务器端进去ESTABLISHED 连接已建立状态,接着返回给客户端,但是客户端就懵逼了,说我没有发送连接请求,于是不理睬。这就导致服务器端一直进入连接状态并发送连接给客户端,导致资源浪费。
解决方案: 如果采用三次握手就不会出现这种情况,因为服务器端接受到TCP连接请求后是进入SY-RCVD 同步已接受状态,而不是二次握手的 ESTABLISHED 连接已建立状态,SY-RCVD如果没有继续接受到对应的确认连接确认请求,根据超时策略是会中止的。
一句话总结: TCP采用三次握手,是为了防止已失效的连接请求报文段突然又传送到了TCP服务器端进程,导致资源的浪费和错误。
TCP四次挥手
简单介绍:TCP四次挥手是TCP建立连接之后需要进行释放连接的过程(释放建立连接形象比喻为挥手👋拜拜)。
TCP四次挥手同TCP三次握手中客户端或服务器端,每次发送请求后都会进入某种状态(记住这些状态如图),这些状态我们在 Linux 系统中可以通过 netstat 命令进行查看,有助于对网络理解。
相关面试题:TCP客户进程在发送完最后一个确认报文段后,为什么不直接进入关闭状态,而是要进入2MSL时间等待状态,2MSL后才进入关闭状态,这是否有必要呢?
答案:有必要
场景: 假设,这时服务器端进入了 CLOSE-WAIT关闭等待状态;
接着客户端进入FIN-WAIT-2终止等待2状态(等待服务器端将剩下的数据传输完毕);
服务器端数据传输完毕后,发送通知给客户端,同时服务器端进入LAST-ACK最后关闭确认状态(等待客户端确认关闭请求信息);
客户端收到数据传输完毕通知后,发送关闭确认请求信息同时进入CLOSED关闭状态,这时因为网络出现故障,导致最后的关闭确认请求没有到达服务器端,从而服务器TCP连接未被关闭。然而服务器端因为超时发送最后的TCP释放连接请求,然而客户端已然进入了CLOSED关闭状态不理睬该请求,从而导致TCP连接无法正常关闭。
解决方案: 当客户端收到数据传输完毕通知后,发送关闭确认请求信息同时进入TIME-WAIT时间等待状态(一半是2MSL,2分钟),这个时间等待状态就是为了确保最后的关闭确认请求能顺利通知到服务器端;如果在这个等待时间之内没有收到服务器端,因为超时发送最后的TCP释放连接请求时,则视为TCP连接关闭成功。
一句话总结: 确保TCP服务器端进程,可以收到最后一个TCP确认报文段而进入关闭状态。另外,TCP客户进程在发送完最后一个TCP确认报文段后,再经过2MSL时长,就可以使本次连接持续时间内所产生的所有报文段都从网络中消失,这样就可以使下一个新的TCP连接,不会出现在旧连接中。
netstat 命令应用
netstat 命令详解,看我这篇:【工作必备知识】Linux系统netstat命令详解 - 秋意零 (qiuyl.com)
链接:https://www.qiuyl.com/linux/255
基础应用
1)查看SSH远程连接的监听状态
$ netstat -tulnpa
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 44841/docker-proxy
tcp 0 0 192.168.200.7:22 192.168.200.1:53570 ESTABLISHED 44987/sshd: root@pt
tcp 0 0 192.168.200.7:22 192.168.200.1:52043 ESTABLISHED 3284/sshd: root@pts
tcp6 0 0 :::9090 :::* LISTEN 2901/prometheus
udp 0 0 192.168.200.7:68 192.168.200.1:67 ESTABLISHED 784/NetworkManager
udp 0 0 0.0.0.0:111 0.0.0.0:* 1/systemd
udp 0 0 0.0.0.0:5355 0.0.0.0:* 557/systemd-resolve
udp 0 0 127.0.0.1:323 0.0.0.0:* 624/chronyd
...
...上面第二行:
tcp 0 0 192.168.200.7:22 192.168.200.1:53570 ESTABLISHED 44987/sshd: root@pt
可以看到,这是我们SSH远程连接所建立的TCP连接信息;本端地址
192.168.200.7:22
,远端地址192.168.200.1:53570
,以及连接状态ESTABLISHED
PS:这里使用的VMware虚拟机,远端地址192.168.200.1是我宿主机NAT网卡的地址
2)统计tcp连接状态
$ netstat -ant | awk '{print $NF}' | sort | uniq -c
1 established)
3 ESTABLISHED
9 LISTEN
1 State
1 TIME_WAIT
3)判断服务使用了什么协议
在不是-n参数时就能看到,服务使用的协议
-n:以数字形式显示地址和端口号,如果不加则以协议名称显示
相关面试题
1)建立连接的TCP链路,如果客户端主动断开连接,netstat如何查看链路连接状态
netstat -ant | grep "TIME_WAIT"
2)打印本机与9.110.120.130机器的连接信息、及连接数量
# 连接信息,这里以192.168.200.1为例
$ netstat -ant | grep 192.168.200.1 | grep ESTABLISHED
tcp 0 0 192.168.200.7:22 192.168.200.1:52375 ESTABLISHED
tcp 0 36 192.168.200.7:22 192.168.200.1:52371 ESTABLISHED
# 连接数量
$ netstat -ant | grep 192.168.200.1 | grep ESTABLISHED | awk '{print $NF}' | uniq -c
2 ESTABLISHED
更多应用场景
查看活动连接:使用 -a
或--all
选项,可以显示所有当前的TCP和UDP连接,包括监听状态的端口,这对于检查哪些服务正在运行和它们的连接状态非常有用。监控网络状态:结合 -c
或--continuous
选项,netstat
可以周期性地输出网络连接信息,帮助实时监控网络状态的变化,比如检测是否有新的连接建立或旧的连接断开。诊断端口问题:当服务无法启动或客户端无法连接到服务时,使用 -an
或--numeric-all
查看占用端口的进程ID(PID)和详细信息,有助于定位端口冲突或服务未正确绑定的问题。统计网络流量和连接:通过 -s
或--statistics
选项,可以获得每个协议的统计信息,如TCP连接的建立、终止数量,以及数据包的发送、接收、丢失情况,有助于分析网络性能和瓶颈。检查路由表:使用 -r
或--route
选项,可以显示IP路由表,这对于理解数据包如何在网络中转发以及排查路由问题至关重要。多播和组播诊断:使用 -g
或--groups
选项可以显示多播组成员关系,对于诊断多播服务或应用的问题很有帮助。接口统计信息:通过 -i
或--interfaces
,可以查看各个网络接口的发送、接收字节数、错误率等信息,有助于评估网络接口的健康状况。检测SYN洪水攻击:观察处于 SYN_RECV
状态的连接数量,如果异常增多,可能表明系统正遭受SYN洪水攻击。
End
非特殊说明,本博所有文章均为博主原创。
如若转载,请注明出处:https://www.qiuyl.com/linux/253
共有 3 条评论