1. 网络诊断的“听诊器”为什么我们需要 netstat在服务器运维、网络排障甚至是日常开发调试中我们常常会遇到一些让人摸不着头脑的问题服务端口明明启动了为什么客户端连不上这台服务器的网络连接数怎么突然飙升是哪个进程在偷偷占用我宝贵的 8080 端口每当这种时候我第一个想到的工具就是netstat。它就像网络世界的“听诊器”能让你清晰地“听”到系统内部每一个网络连接的“心跳”——状态、地址、进程一目了然。netstatnetwork statistics是一个几乎所有类 Unix 系统Linux, macOS, BSD和 Windows 系统都内置的命令行工具。它的核心功能就是显示网络连接、路由表、接口统计信息、伪装连接和多播成员等信息。对于任何需要与网络打交道的工程师来说熟练使用netstat是一项基本功。它不依赖于任何图形界面在纯命令行环境下比如通过 SSH 管理的远程服务器尤其强大。你可以快速获取一份系统网络状态的“快照”基于此进行诊断和分析。很多人觉得netstat命令参数繁多输出看起来杂乱。其实一旦你理解了其输出列的含义和背后的原理它就会成为你手中最得力的武器。本文将不仅详解netstat的每一个常用参数和输出细节更会深入浅出地探讨它是如何“看到”这些信息的——即它的实现原理。理解了原理你就能明白它的能力边界知道在什么情况下该用它什么时候可能需要配合ss、lsof甚至tcpdump等工具。无论你是刚入行的运维新手还是想深化理解的开发老鸟这篇文章都将带你从“会用”走向“精通”。2. 核心功能与常用参数全解析netstat的功能模块主要分为四大块活动连接、监听端口、路由表和接口统计。我们通过不同的参数组合来调用这些功能。2.1 查看活动连接与监听端口-t, -u, -l, -a, -n这是netstat最常用的功能组合。netstat -tunlp这个组合拳堪称经典。我们来拆解一下-t显示 TCP 协议连接。-u显示 UDP 协议连接。-n以数字形式显示地址和端口号不进行主机名、服务名的解析。这是关键参数可以显著加快输出速度尤其在 DNS 解析慢或不可用时。-l仅显示处于 LISTEN监听状态的套接字。这些是服务端等待连接的端口。-p显示占用该连接或端口的进程 ID (PID) 和程序名称。需要 root 权限才能查看其他用户的进程信息。执行sudo netstat -tunlp你会看到类似下面的输出Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1234/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 567/cupsd tcp6 0 0 :::80 :::* LISTEN 789/nginx udp 0 0 0.0.0.0:68 0.0.0.0:* -/dhclientLocal Address:0.0.0.0:22表示监听所有 IPv4 接口的 22 端口127.0.0.1:631表示只监听本机回环地址的 631 端口。Foreign Address:0.0.0.0:*表示对远端地址和端口无限制。State: 对于 TCP常见状态有LISTEN监听、ESTABLISHED已建立连接、TIME_WAIT等待关闭、CLOSE_WAIT远端已关闭等。TIME_WAIT状态过多可能需要注意。PID/Program name: 直接告诉你是谁在监听或连接。netstat -a显示所有连接包括监听和已建立的和所有类型的套接字。信息量很大。netstat -at或netstat -au分别查看所有 TCP 或所有 UDP 连接。注意在较新的 Linux 发行版中netstat已被标记为“过时”obsolete官方推荐使用ss命令替代因为ss直接从内核空间获取信息速度更快显示的信息也更丰富。但netstat的语法直观在几乎所有系统上可用依然是不可替代的通用技能。在排查问题时我通常会先用netstat -tunlp快速定位如果需要更详细的套接字内部信息如内存缓冲区大小再使用ss -tunlp。2.2 查看路由表信息-r路由表决定了数据包从哪个网卡发出去下一跳地址是谁。使用netstat -rn-n同样用于禁止解析可以查看内核的 IP 路由表。Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0Destination: 目标网络或主机。0.0.0.0表示默认路由。Gateway: 网关地址。0.0.0.0表示该路由是直连网络无需网关。Genmask: 网络掩码。Flags:U表示路由是活动的UpG表示使用网关Gateway。Iface: 出口网络接口。这个命令等价于route -n。当你遇到“网络不通”的问题时检查路由表是第一步确保去往目标地址的路由存在且正确。2.3 查看网络接口统计信息-inetstat -i可以查看所有网络接口的简单统计信息如接收/发送的数据包数量、错误数、丢弃数等。这对于监控网络接口的健康状态非常有用。Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 1234567 0 0 0 987654 0 0 0 BMRU lo 65536 789012 0 0 0 789012 0 0 0 LRU如果RX-ERR或TX-ERR持续增长可能表明物理链路或驱动有问题。RX-DRP/TX-DRP增长可能意味着系统负载过高来不及处理数据包。更详细的接口统计可以使用netstat -ie-e是扩展信息其输出类似于ifconfig命令。2.4 其他实用参数-s显示每个协议的汇总统计信息。例如netstat -s会输出海量的 IP、ICMP、TCP、UDP 等协议的详细计数器如发送/接收的段数量、重传、错误等。这是进行深度网络性能分析和排障的宝库。-c持续输出。信息会每秒刷新一次类似于top命令用于实时观察连接变化。--verbose显示详细信息。当与-a等参数结合时可能会显示更多状态信息。按状态过滤虽然netstat本身没有直接参数按状态过滤但可以结合grep。例如查看所有TIME_WAIT连接netstat -an | grep TIME_WAIT。查看ESTABLISHED的 TCP 连接netstat -an | grep ESTABLISHED。3. 输出列深度解读与状态机剖析看懂netstat的输出是诊断的基础。我们重点剖析连接列表中的关键列和 TCP 状态。3.1 关键输出列详解以netstat -tan的输出为例Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 10.0.0.1:22 10.0.0.100:54321 ESTABLISHED tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 1024 10.0.0.1:5432 10.0.0.200:45000 ESTABLISHEDProto协议TCP 或 UDP。Recv-Q和Send-Q这是两个极易被误解但极其重要的列。对于监听套接字LISTENRecv-Q当前全连接队列accept queue的长度即已完成三次握手、等待应用层accept()取走的连接数量。Send-Q全连接队列的最大长度即backlog参数限制受net.core.somaxconn内核参数影响。对于非监听套接字如 ESTABLISHEDRecv-Q内核中已接收、但尚未被应用进程通过read()或recv()取走的数据字节数。如果这个值持续很大可能意味着应用进程处理过慢。Send-Q内核中已发送、但尚未收到对方确认ACK的数据字节数。如果这个值持续很大可能意味着网络拥塞或对端接收缓慢。 在上面的例子中第三行Send-Q为 1024表示有 1024 字节的数据已发出但未确认。Local Address和Foreign Address本地和远端地址。0.0.0.0:*表示绑定到所有 IPv4 地址的任意端口实际是监听端口。::对应 IPv6。State连接状态。这是理解 TCP 行为的关键。3.2 TCP 状态机实战解读TCP 连接的生命周期由状态机定义。netstat让你能窥见这个状态机在某一时刻的快照。LISTEN服务端调用listen()后进入的状态等待客户端发起SYN请求。SYN_SENT客户端调用connect()发送SYN包后进入的状态等待服务端的SYN-ACK。如果你在客户端看到大量SYN_SENT且无法进入ESTABLISHED可能是网络不通、防火墙拦截或服务端未监听。SYN_RECV服务端收到SYN并回复SYN-ACK后进入的状态等待客户端的ACK。这是“半连接队列”中的状态。如果服务器受到 SYN Flood 攻击你会看到大量SYN_RECV。ESTABLISHED三次握手完成连接建立可以进行数据传输。FIN_WAIT1主动关闭方先调用close()的一方发送FIN后进入的状态。FIN_WAIT2主动关闭方收到对方对FIN的ACK后进入的状态等待对方发送FIN。TIME_WAIT主动关闭方收到对方的FIN并发出最终的ACK后进入的状态。这个状态会持续2MSLMaximum Segment Lifetime通常为 60 秒。它的存在有两个重要目的1) 确保最后的ACK能到达对端2) 让旧连接的重复报文在网络中消逝避免影响新连接。服务器上出现大量TIME_WAIT是正常现象通常意味着你的服务器是 HTTP 请求的主动关闭方根据 HTTP 协议服务器在发送响应后可能主动关闭连接。除非它耗尽了可用端口否则一般无需过度优化。CLOSE_WAIT被动关闭方收到FIN后进入的状态。这表示对方已关闭连接但我方应用层还未调用close()。如果服务器上出现大量CLOSE_WAIT几乎总是应用程序的 Bug如未正确关闭 Socket导致连接资源泄漏。这是需要重点排查的问题LAST_ACK被动关闭方在发送自己的FIN后进入的状态等待对方最后的ACK。CLOSED连接完全关闭。这个状态在netstat输出中看不到。理解这些状态你就能通过netstat的输出精准定位问题。例如发现服务响应变慢netstat显示大量ESTABLISHED连接的Recv-Q堆积那问题很可能出在应用处理逻辑上。4. netstat 的实现原理探秘netstat本身是一个用户空间的程序它本身并不“产生”或“管理”这些网络信息。它的工作是作为一个信息展示器从操作系统内核提供的几个关键接口中读取原始数据并以人类可读的格式呈现出来。理解它从哪里读数据是理解其原理的核心。4.1 核心数据源/proc 文件系统Linux在 Linux 系统中netstat的绝大部分信息来源于/proc虚拟文件系统。这是一个内核提供的、以文件形式访问内核数据和状态的接口。连接与端口信息 (/proc/net/tcp,/proc/net/udp,/proc/net/raw)这是netstat获取活动连接和监听端口信息的主要来源。你可以直接cat /proc/net/tcp查看输出是十六进制的原始数据sl local_address rem_address st tx_queue rx_queue tr tm-when retrnsmt uid timeout inode 0: 0100007F:001F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 123456 1 ...local_address: 本地地址和端口十六进制。0100007F7F000001127.0.0.1001F31 端口 49等等这里001F是十六进制十进制是 31但常见服务端口 31 不对。实际上这里存储的是网络字节序大端序的数值。0100007F:001F需要转换IP7F000001-127.0.0.1端口1F00注意字节序-0x001F在内存中是[0x00, 0x1F]大端序解释就是0x001F 31。但netstat在显示时已经帮我们做了转换和端口号解析例如 22 端口显示为 ssh。rem_address: 远端地址和端口。st: 连接状态十进制对应 TCP 状态码如0A 10 LISTEN。tx_queue和rx_queue: 对应netstat输出中的Send-Q和Recv-Q。uid: 所属用户的 ID。inode: 该套接字对应的 inode 号。这是连接到进程信息的关键。进程信息映射 (/proc/[pid]/fd/和/proc/[pid]/net)netstat -p能显示进程名这是如何做到的内核在/proc/net/tcp中只提供了套接字的inode号。netstat需要遍历/proc下所有进程的目录如/proc/1234/fd/检查每个文件描述符。如果某个文件描述符是一个 socket 链接其指向的路径会包含socket:[inode号]。通过匹配这个inode号netstat就能将连接绑定到具体的进程 PID 和名称上。这个过程比较耗时这也是为什么加上-p参数后命令执行会变慢的原因。路由表信息 (/proc/net/route)netstat -r的信息来源于/proc/net/route。这个文件以二进制格式存储内核的路由表。接口统计信息 (/proc/net/dev)netstat -i的信息来源于/proc/net/dev它统计了每个网络接口收发的数据包、字节数、错误数等。4.2 系统调用与备选数据源除了读取/proc文件一些 Unix 变体或老版本的netstat可能会使用ioctl系统调用如SIOCGIFCONF来获取接口信息或者直接读取/etc下的网络配置文件。但在现代 Linux 上/proc是主要且最标准的数据源。4.3 为什么 ss 命令更快netstat的“慢”主要慢在两点1) 遍历/proc所有进程目录来解析-p信息2) 可能进行耗时的 DNS 反向解析如果不加-n。而sssocket statistics工具直接从内核的netlink接口获取信息。netlink是一种用于内核与用户空间进程通信的机制效率远高于遍历文件系统。ss在获取大量连接信息时速度比netstat快一个数量级并且能提供更多内核内部的细节如内存使用、cgroup 信息。因此在需要频繁执行或连接数巨大的生产环境中ss是更好的选择。但netstat的语法对于初学者更友好输出格式也更为人熟知。5. 实战排障案例与高级技巧理论结合实践下面分享几个我用netstat解决实际问题的案例和技巧。5.1 案例一定位端口占用冲突问题启动一个 Spring Boot 应用提示 8080 端口被占用。排查sudo netstat -tunlp | grep :8080输出显示8080端口被一个旧的 Java 进程占用。kill -9 PID结束该进程问题解决。技巧grep :端口号是精准定位的常用手法。记住要加-n避免解析服务名。5.2 案例二诊断服务连接失败问题客户端无法连接到服务器的 3306MySQL端口。排查在服务器执行sudo netstat -tunlp | grep :3306。如果无输出说明 MySQL 服务未启动或未监听在预期的网络接口上可能只监听了127.0.0.1。如果有输出显示LISTEN在0.0.0.0:3306则检查服务器防火墙是否放行了 3306 端口。在客户端尝试telnet 服务器IP 3306。如果失败网络或防火墙问题可能性大。在服务器执行sudo netstat -an | grep :3306查看是否有来自客户端 IP 的连接尝试可能处于SYN_RECV状态。如果有但无法建立可能是服务端处理能力不足半连接队列满了检查net.ipv4.tcp_max_syn_backlog。5.3 案例三分析 CLOSE_WAIT 连接堆积问题服务器监控报警发现某台应用服务器连接数异常高。排查netstat -an | awk /^tcp/ {S[$NF]} END {for(a in S) print a, S[a]}。这个命令可以统计所有 TCP 状态的数量。发现CLOSE_WAIT状态有上千个。netstat -anp | grep CLOSE_WAIT。查看这些连接的具体进程发现都指向同一个 Java 应用。结论该 Java 应用存在 Bug在收到对端如数据库、下游服务的关闭请求FIN后没有正确调用Socket.close()来释放连接资源。这属于典型的资源泄漏。解决重启应用可临时释放连接但根本解决需要修复应用程序代码确保在所有逻辑分支上都正确关闭网络资源。5.4 高级技巧与脚本持续监控连接数变化watch -n 1 “netstat -an | grep ESTABLISHED | wc -l”。每秒刷新一次已建立连接的数量。统计各状态连接数简洁版上面案例三的awk命令非常实用可以写成一个脚本或别名。找出连接数最多的远程IPnetstat -an | grep ESTABLISHED | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -rn | head -10。这有助于发现是否受到某个IP的过度访问或攻击。结合 lsof当netstat -p无法显示进程名权限不足或进程已退出时可以使用lsof -i :端口号来查看。lsof提供了更丰富的文件描述符信息。netstat的魅力在于它的简单和直接。它不提供图形化的曲线也不做复杂的聚合分析但它给你的是最原始、最真实的系统网络状态数据。掌握它就像掌握了一把打开网络黑盒的钥匙。下次当你再遇到网络问题时别急着重启服务先敲一个netstat听听系统想告诉你什么。