企业官网建设流程全解析

把网络编程整理成一套能直接上手的知识，比单纯背API要重要得多。这篇是我自己的DAY26学习记录，核心是Linux环境下的网络通信原理、IP与协议的关系、网络配置方式，以及UDP、TCP两套socket编程的实际应用。如果你正好学到Linux网络编程这块，或者面试前想把三次握手、socket流程这些概念串起来，直接跟着这篇文章的思路走就行，代码和命令我都会贴出来。

我先把话放在前头：网络编程里面绕不开的就三样——协议、IP、端口。把这三样在脑子里形成一个清晰模型，后面看什么TCP、UDP、socket都不会懵。今天我尽量用大白话把这些概念讲透，再配合能直接编译运行的C代码，带你把UDP和TCP从建连到收发全都过一遍。

1. 网络通信的底层逻辑：协议、IP与端口先建模型

1.1 协议分层：为什么需要TCP/IP模型

很多人一开始学网络编程，上来就看send、recv、bind这些API，觉得反正填个IP和端口就能用了。一旦遇到问题就抓瞎，因为底层数据包是怎么走的、为什么握手、为什么断连，脑子里全是模糊的。

先补一个最底层的模型。两台机器之间要通信，硬件上靠网卡、网线、交换机、路由器，数据最终是以电信号/光信号在介质里传递的。问题是，信号本身没有“意义”——它不知道自己是网页请求还是视频流。所以需要一套规则，把原始比特流一步步包装成有意义的数据，这就是“协议分层”。

TCP/IP模型一般分成四层，我习惯这样记：

• 网络接口层：管网卡驱动、ARP、以太网帧，解决“数据在同一个局域网里怎么传到对方网卡”的问题。
• 网络层：IP协议在这一层，解决“数据怎么跨网络找到对方主机”的问题。
• 传输层：TCP/UDP在这一层，解决“数据交给这台主机上的哪个程序”的问题。
• 应用层：HTTP、FTP、SSH，还有你自己写的socket程序，都在这一层。

这个分层模型最大的价值是解耦。应用层不用管数据包怎么被拆成帧、走哪条路由，网络层也不用管上层是HTTP还是自定义协议。我记得刚学的时候拿它类比快递系统：应用层是“你要寄的物品”，传输层是“快递单上填的收件人（端口）”，网络层是“收件地址（IP）”，链路层是“货车司机实际走的道路”。这个类比很好用，面试被问“为什么分层”的时候，从这个角度说，逻辑也通顺。

1.2 IP地址、端口与MAC地址的分工

有了分层的概念，我们再拆开看IP和端口。

IP地址是网络层的标识，负责在“整个互联网范围”内定位一台主机。IPv4是32位，通常写成点分十进制，比如192.168.1.100。IPv6是128位，写成16进制段，比如2408:8207:4800:2::3。写程序时，IPv4的地址可以放到一个32位整数里；习惯上我们在代码里先填字符串，再通过inet_pton转成二进制，这样比较稳。

只是IP还不行，一台机器上可能同时跑着SSH、Nginx、MySQL，数据包到了这台机器，内核怎么知道要交给哪个进程？这就靠端口。传输层的TCP和UDP头部都有源端口、目的端口，各占16位，范围0到65535。0到1023是知名端口，HTTP用80，HTTPS用443，SSH用22，自己写测试服务就尽量用5000以上，免得撞车。

还有一个概念容易混淆：MAC地址。MAC是数据链路层的标识，理论上全球唯一，但它只在局域网传输时有用。跨网段转发时靠的是IP路由，到了目标局域网内，才通过ARP协议把IP解析成MAC，然后封装成以太网帧送过去。所以可以简单理解成：IP负责“找到哪台机器”，端口负责“找到机器上的哪个进程”，MAC负责“局域网内最后一跳的物理投递”。

1.3 socket本质：把网络通信抽象成文件读写

Linux里面有个经典思想：一切皆文件。普通文件可以open/read/write/close，网络连接也可以这样操作，这个抽象就是socket（套接字）。

socket()函数返回一个文件描述符，内核在内部维护这个socket对应的发送缓冲区、接收缓冲区，以及一系列状态。你往socket里写数据，内核负责按TCP或UDP协议封装成报文发出去；对方有数据过来，内核收下放进接收缓冲区，你的程序用read或recv取出来。

这么设计的直接好处：应用层代码不需要跟网卡驱动、协议栈细节打交道。把socket当做一个“管道”，一边是你，一边是远端程序，非常顺。我学的时候一度想自己构造IP包，后来发现完全没必要，socket已经是操作系统给你封装好的“标准接口”，99%的业务场景用原生socket就足够了。

既然模型清晰了，下一步就进入Linux环境里实际看网络配置，也就是常说的“配IP、查端口”。

2. 环境配置与网络排查：从看IP到tcpdump抓包

2.1 用ip命令替代老旧的ifconfig

早年玩Linux的人习惯用ifconfig查IP，但这个工具在新系统里默认不装了，功能也不够现代。现在推荐用ip命令，它是iproute2包里的，几乎所有发行版都自带。

# 查看所有网卡信息 ip addr show # 精简输出：只看IPv4地址 ip -4 addr show # 查看路由表，确认默认网关 ip route show

输出里重点看几个字段：lo是回环接口，IP固定是127.0.0.1，代表本机自身；eth0或ens33这种是真实网卡，后面跟的inet字段就是这台机器的IP。路由表里的default via一行代表默认网关，访问外网时要靠它把包转发出去。

ifconfig虽然还能用，但有些老的发行版上它看不到CIDR格式的子网掩码，信息不完整。建议尽早养成用ip命令的习惯。

2.2 修改IP地址与永久配置

临时改IP用ip addr add就够了，适合做实验：

# 给eth0添加一个临时IP sudo ip addr add 192.168.1.50/24 dev eth0 # 删除 sudo ip addr del 192.168.1.50/24 dev eth0

但重启网络服务或者重启机器后，临时配置就丢了。想永久生效，不同的发行版配置方式不一样，我用过的两种主流方式：

• Debian/Ubuntu（新版）：编辑/etc/netplan/*.yaml，改完执行sudo netplan apply。
• CentOS/RHEL：编辑/etc/sysconfig/network-scripts/ifcfg-eth0，改完执行sudo systemctl restart network。

Ubuntu的netplan配置长这样：

network: version: 2 ethernets: eth0: dhcp4: true addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [223.5.5.5, 8.8.8.8]

这里注意一个常见坑：云服务器或虚拟机的网卡名可能是ens33、ens160，不是eth0，写配置之前一定要ip addr看清楚接口名，否则netplan apply会直接报错。

2.3 连通性与监听端口排查三板斧

配置完网络，第一件事就是验证。我自己常用的三板斧：

# 1. 测连通性 ping 8.8.8.8 ping -c 4 baidu.com # 2. 查看本机监听的端口 ss -lntp # 3. 测试远端端口是否开放 nc -vz 192.168.1.1 22

ss -lntp里面，-l表示只显示监听中的socket，-n不做域名解析，-t只看TCP，-p显示进程名和PID。如果看到0.0.0.0:5000，说明服务在监听所有网卡的5000端口；如果看到127.0.0.1:5000，说明只监听本机回环，外部机器连不上——很多新手排查半天，发现服务起在127.0.0.1上。

nc -vz测端口特别好用，不会真的建立应用层连接，只测试TCP握手能否成功。UDP端口想测连通性，nc -u也可以，但UDP没有握手概念，能不能通得靠业务层数据回应，这点后面UDP编程章节再细说。

2.4 tcpdump：看一眼真实的数据包

排查网络问题只用ping和ss是不够的，有时候协议层面就是不对，得抓包看。tcpdump是Linux下最基础的抓包工具，我常用的几个命令：

# 抓取主机192.168.1.100收到的所有ping包 sudo tcpdump -i eth0 icmp and host 192.168.1.100 # 抓取HTTP 80端口的数据包，并显示内容 sudo tcpdump -i eth0 -A tcp port 80 # 抓取TCP三次握手过程（数据包层面） sudo tcpdump -i eth0 tcp port 5000

比如抓TCP握手，会看到SYN、SYN-ACK、ACK三种标记，这比看任何文字描述都直观。后面我会专门讲如何用抓包结果反推连接异常。

3. UDP编程实战：无连接、速度快，也需要细致处理

3.1 UDP协议特点：简单、轻量、有边界

UDP（User Datagram Protocol）的定位是“尽力而为”的传输。它不需要建立连接，发数据直接封装成数据报扔出去，至于对方收没收到，UDP协议本身不管。这带来两个鲜明的特点：

• 快：没有握手和确认环节，时延低，适合DNS查询、视频通话、在线游戏这类能容忍偶发丢包的场景。
• 有消息边界：每次sendto发出去的一个数据报，对方一次recvfrom收到的就是一个完整的数据报。这个特性跟TCP不一样，TCP是字节流没有边界，UDP天然帮你“分包”了。

代价是可靠性差：网络拥塞时会丢包、乱序，数据也可能在中间被路由器丢弃。重要业务要自己做重传和确认机制，或者直接用上层协议（比如QUIC）。

3.2 UDP编程核心流程

UDP编程比TCP简单，核心API就五个：

• socket(AF_INET, SOCK_DGRAM, 0)：创建UDP socket，注意第二个参数是SOCK_DGRAM。
• bind(fd, addr, len)：绑定本地地址和端口。服务端必须bind，客户端如果想固定端口也可以bind，不bind则内核自动分配。
• sendto(fd, buf, len, 0, dest_addr, addr_len)：向指定地址发数据报。
• recvfrom(fd, buf, len, 0, src_addr, &addr_len)：接收数据报，同时能拿到发送方的地址和端口。
• close(fd)：关闭socket。

流程上，服务端和客户端其实是对称的：两边都要创建socket，服务端bind固定端口，客户端可选bind；然后两边互相用sendto/recvfrom收发。不需要listen，也不需要accept，这就是“无连接”的体现。

3.3 完整的UDP收发代码

我写了一个最小可跑通的例子：服务端绑定127.0.0.1的8888端口，收到客户端消息后原样回一句“server received: xxx”。

服务端代码（udp_server.c）：

#include <stdio.h> #include <string.h> #include <arpa/inet.h> #include <sys/socket.h> #include <unistd.h> int main() { int fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { perror("socket"); return 1; } struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(8888); addr.sin_addr.s_addr = htonl(INADDR_ANY); // 监听所有网卡 if (bind(fd, (struct sockaddr*)&addr, sizeof(addr)) < 0) { perror("bind"); close(fd); return 1; } char buf[1024]; struct sockaddr_in client_addr; socklen_t len = sizeof(client_addr); while (1) { memset(buf, 0, sizeof(buf)); int n = recvfrom(fd, buf, sizeof(buf) - 1, 0, (struct sockaddr*)&client_addr, &len); if (n < 0) { perror("recvfrom"); break; } char ip_str[INET_ADDRSTRLEN]; inet_ntop(AF_INET, &client_addr.sin_addr, ip_str, sizeof(ip_str)); printf("recv %d bytes from %s:%d: %s\n", n, ip_str, ntohs(client_addr.sin_port), buf); // 原样回给客户端 sendto(fd, buf, n, 0, (struct sockaddr*)&client_addr, len); } close(fd); return 0; }

客户端代码（udp_client.c）：

#include <stdio.h> #include <string.h> #include <arpa/inet.h> #include <sys/socket.h> #include <unistd.h> int main() { int fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { perror("socket"); return 1; } struct sockaddr_in server_addr; memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(8888); inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr); char buf[1024] = "hello udp"; sendto(fd, buf, strlen(buf), 0, (struct sockaddr*)&server_addr, sizeof(server_addr)); struct sockaddr_in from_addr; socklen_t from_len = sizeof(from_addr); int n = recvfrom(fd, buf, sizeof(buf) - 1, 0, (struct sockaddr*)&from_addr, &from_len); if (n > 0) { buf[n] = '\0'; printf("server reply: %s\n", buf); } close(fd); return 0; }

编译运行：

gcc udp_server.c -o udp_server gcc udp_client.c -o udp_client # 终端1 ./udp_server # 终端2 ./udp_client

运行后服务端打印recv 10 bytes from 127.0.0.1:xxxxx: hello udp，客户端打印server reply: hello udp。

3.4 用nc和iperf3验证UDP

如果不想写客户端，用nc也能快速发UDP数据：

# 往本机8888端口发一条UDP消息 echo "test from nc" | nc -u 127.0.0.1 8888

服务端同样能收到。这个命令在调试时特别省事，不用反复编译客户端。

想压测UDP带宽，可以用iperf3。UDP模式下它默认以一定速率发包，能统计丢包率、抖动、带宽：

# 服务端 iperf3 -s # 客户端，UDP模式，打流10秒 iperf3 -u -c 127.0.0.1 -b 100M -t 10

输出里会有一行Lost/Total Datagrams，丢包率如果很高，说明网络链路或者服务端处理不过来，需要调优或者换TCP。

3.5 UDP编程的四个坑

结合我实际调试经验，UDP有几个很容易踩的坑：

1. 接收缓冲区太小导致丢包。接收方recvfrom的buf如果小于数据报长度，多余部分会被内核直接丢弃（UDP不像TCP那样能把多出来的留在缓冲区下次读）。所以接收buffer尽量大一些，或者双方约定好单个数据报的最大长度。
2. bind不检查返回值。很多时候bind失败是因为端口被占用，不判断返回值的话，后面收不到任何数据，排查起来很困惑。
3. 防火墙拦UDP。UDP没有握手，防火墙检测难度更大，很多安全策略默认丢弃UDP。在自己机器上测试没问题，跨机器就收不到，多半是防火墙。
4. sendto不报错不代表对方收到。UDP的sendto只是把数据交给内核就返回了，中间丢了谁也不知道。要确认对方有没有收到，必须靠应用层回包。

4. TCP编程实战：可靠连接，状态机是核心

4.1 三次握手与四次挥手

TCP是面向连接的、可靠的字节流协议。可靠性怎么来？靠确认、重传、排序、流量控制这些机制。而在一切开始之前，双方要先“握手”建立连接。

三次握手的全过程：

1. 客户端发送SYN，请求建立连接，这时候带上初始序列号seq=x。
2. 服务端收到后回复SYN+ACK，表示“同意建立，并确认收到你的SYN”，带上seq=y和ack=x+1。
3. 客户端回复ACK，ack=y+1，连接进入ESTABLISHED状态。

为什么必须是三次，不是两次？核心原因是防止已经失效的旧连接请求突然到达服务端，导致错误建立连接。两次握手的话，服务端收到SYN就建立连接，万一这个SYN是网络延迟导致的陈旧数据包，服务端会白等一个根本不存在的请求。加了第三次ACK，客户端如果没有真正发起连接就不会回应，服务端自然超时关闭。

四次挥手跟握手的思路完全不一样：

1. 主动关闭方发送FIN，表示“我的数据发完了”。
2. 被动关闭方回复ACK，表示“收到你的FIN”。
3. 被动关闭方继续发完剩余数据，然后发送FIN，表示“我的数据也发完了”。
4. 主动关闭方回复ACK，连接彻底关闭。

之所以是四次，是因为TCP允许半关闭：一端不发了，另一端还可以继续发数据。服务端的‘ACK’和‘FIN’可能合并成一个包发送，但严格来说概念上是四次。

这个部分面试点特别密集，我在learn笔记里专门画过状态迁移表，核心状态记这几个就行：

4.2 TCP编程核心API流程

TCP编程和服务端的API比UDP多几个关键步骤：

服务端：

• socket(AF_INET, SOCK_STREAM, 0)：第二个参数换成了SOCK_STREAM。
• bind()：绑定地址端口。
• listen(fd, backlog)：把socket变为被动监听状态，backlog表示内核中等待accept的连接队列长度。
• accept(fd, &client_addr, &len)：从连接队列里取一个已完成握手的连接，返回一个新的socket用于通信。

客户端：

• socket()：创建TCP socket。
• connect(fd, &server_addr, len)：发起三次握手，握手成功返回后，连接就建立了。

之后收发数据用read/write或者recv/send都可以，因为TCP是字节流，接口跟文件读写几乎一样。

4.3 完整的TCP示例：fork实现并发echo

我写一个经典例子：TCP echo服务端，每来一个客户端就fork一个子进程处理，子进程里循环接收数据，原样返回。这是理解TCP并发最简单的方式。

服务端代码（tcp_server.c）：

#include <stdio.h> #include <string.h> #include <arpa/inet.h> #include <sys/socket.h> #include <unistd.h> #include <signal.h> #include <sys/wait.h> void handle_client(int cfd) { char buf[1024]; while (1) { int n = read(cfd, buf, sizeof(buf) - 1); if (n <= 0) break; // 客户端关闭或出错 buf[n] = '\0'; printf("echo: %s\n", buf); write(cfd, buf, n); } close(cfd); _exit(0); } int main() { int fd = socket(AF_INET, SOCK_STREAM, 0); if (fd < 0) { perror("socket"); return 1; } // 关键：避免TIME_WAIT状态下端口不可用 int opt = 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(8888); addr.sin_addr.s_addr = htonl(INADDR_ANY); if (bind(fd, (struct sockaddr*)&addr, sizeof(addr)) < 0) { perror("bind"); close(fd); return 1; } if (listen(fd, 128) < 0) { perror("listen"); close(fd); return 1; } signal(SIGCHLD, SIG_IGN); // 自动回收子进程，避免僵尸 printf("TCP server listening on 0.0.0.0:8888\n"); while (1) { struct sockaddr_in client_addr; socklen_t len = sizeof(client_addr); int cfd = accept(fd, (struct sockaddr*)&client_addr, &len); if (cfd < 0) { perror("accept"); continue; } pid_t pid = fork(); if (pid == 0) { close(fd); // 子进程不需要监听fd handle_client(cfd); } else { close(cfd); // 父进程不需要连接fd } } close(fd); return 0; }

客户端代码（tcp_client.c）：

#include <stdio.h> #include <string.h> #include <arpa/inet.h> #include <sys/socket.h> #include <unistd.h> int main() { int fd = socket(AF_INET, SOCK_STREAM, 0); if (fd < 0) { perror("socket"); return 1; } struct sockaddr_in server_addr; memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(8888); inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr); if (connect(fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) { perror("connect"); close(fd); return 1; } char buf[1024]; while (1) { printf("> "); fflush(stdout); if (fgets(buf, sizeof(buf), stdin) == NULL) break; write(fd, buf, strlen(buf)); int n = read(fd, buf, sizeof(buf) - 1); if (n <= 0) { printf("server closed\n"); break; } buf[n] = '\0'; printf("server reply: %s\n", buf); } close(fd); return 0; }

编译运行：

gcc tcp_server.c -o tcp_server gcc tcp_client.c -o tcp_client ./tcp_server ./tcp_client

运行后，在客户端输入任意字符串，服务端原样回显。这个例子虽然简单，但展示了TCP服务端最标准的生命周期：socket→bind→listen→accept→read/write→close。

4.4 TIME_WAIT与SO_REUSEADDR

TCP编程中有一个非常常见的坑：服务端重启时报bind: Address already in use。原因就是主动关闭连接的一方（通常是服务端，如果你直接Ctrl+C停服务）会进入TIME_WAIT状态，持续2MSL（大约1到4分钟，Linux默认60秒左右）。这段时间内，同样的四元组（源IP、源端口、目的IP、目的端口）不能被复用。

解决办法就是setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt))，在bind之前设置。这个选项允许内核在TIME_WAIT状态下重新绑定同一端口。代码里我已经加上了。

另外要注意SIGCHLD信号的忽略。fork出来的子进程如果结束了，父进程不处理waitpid，子进程会变成僵尸进程。简单粗暴的办法是signal(SIGCHLD, SIG_IGN)，让内核自动回收。生产环境里更规范的做法是用sigaction+waitpid循环回收。

4.5 面向高并发：select、poll与epoll

上面的fork模型能解决“同时处理多个客户端”的问题，但每个连接一个进程，代价太高。连接数几百上千还行，上万就不现实了。这里引出Linux下高性能网络编程的核心：IO多路复用。

• select：内核帮你监听一堆fd，有事件就返回。缺点是fd数量有限制（默认1024），而且每次调用都要重新传入整个fd集合，效率不高。
• poll：用链表替代了fd_set，突破了数量限制，但性能模型和select一样，都是“线性扫描”。
• epoll：Linux 2.6以后提供，是当前高性能网络服务的标配。它有两个核心优势：事件驱动，只返回就绪的fd；可扩展性好，百万连接也能支撑。Nginx、Redis、Node.js底层都是epoll。

一个最小化的epoll服务端思路是：

epoll_create -> epoll_ctl(ADD, listen_fd) -> epoll_wait 循环

每次epoll_wait返回一批就绪fd，如果是监听fd就accept并把新连接加入epoll，如果是通信fd就直接读写。这个模型彻底摆脱了“一连接一线程”的尴尬，也是我从学TCP编程到真正理解高并发服务器的一个重要转折点。

4.6 TCP粘包问题：字节流模型决定的

TCP是字节流协议，read读到的数据不一定对应对方一次write写入的数据。比如客户端连续发两次write，内容分别是“hello”和“world”，服务端一次read可能读到“helloworld”，也可能先读到“hel”下一次读到“loworld”。这就是粘包/拆包问题。

解决办法不是靠TCP（它没有消息边界），而是应用层自己定义消息格式。常见的方案：

1. 固定长度：每个消息固定N字节，不够就补位，读满N字节处理一次。
2. 分隔符：消息以\n或特殊字符结尾，读到分隔符才算一条完整消息。
3. 长度前缀：每条消息前面加4字节长度字段，先读长度，再按长度读正文。这是最通用的做法。

我知道有人用Modbus TCP这类工业协议，里面也是固定字节头+长度字段的格式，本质思路是一样的。搞懂了应用层要自己划分“消息边界”这个道理，粘包问题就迎刃而解。

5. 实战排查：连接类问题的定位思路

5.1 常见问题速查表

在这个阶段，我会把排查经验整理成一张速查表，遇到问题直接对照：

5.2 用抓包定位“谁先断开连接”

有一次联调时，服务端A给客户端B发完数据后，B迟迟没有响应。用tcpdump抓包后发现：A发了PUSH-ACK数据包，B回了ACK，然后A发送了FIN。也就是说，是A自己主动关闭了连接，不是B不响应。程序里的原因是一个不需要的close被提前触发。

抓包怎么读？几个关键标志位：SYN=发起连接、ACK=确认、FIN=关闭连接、RST=异常重置。如果看到RST，说明对端直接丢弃或拒绝了连接，而不是正常挥手关闭。RST出现的原因很多：端口没监听、进程崩溃、超时重传被取消等。以后排查连接异常，我先抓包看有没有RST，这比猜快得多。

5.3 网络编程学习路线建议

学到这儿，Linux网络编程的基础链路已经通了。后面想深入的话，我的建议是顺着这条路走：

1. 反复推敲TCP状态机，每次抓包都会看到SYN、FIN、TIME_WAIT，看多了就自然记住。
2. 读unp（Unix Network Programming）关键章节，不用全读，把socket API、IO复用、信号处理这几块啃透。
3. 上手epoll，写一个简单的并发回显服务器，体验从阻塞IO到事件驱动的区别。
4. 看内核参数，比如/proc/sys/net/ipv4/tcp_fin_timeout、tcp_tw_reuse，结合实际问题调优。
5. 有余力再看现代协议栈，比如QUIC、io_uring，这些是建立在基础之上理解才快。

我自己在学的时候，最大的体会是：别在API层面钻牛角尖，要把注意力放在“数据包到底怎么流动”上。理解了包是怎么发的、怎么确认的、怎么重传的，写起代码来反而很自然。

最后再分享一个小技巧：调试TCP服务时，把/proc/net/tcp打开看一下，每一行是一个TCP连接状态。第六列是连接状态，比如01代表ESTABLISHED，06代表TIME_WAIT。当你怀疑服务端有大量TIME_WAIT堆积时，数一数这个文件的行数就知道了，比一个个ss去看心里更有底。网络编程这个领域，经验都是从一次次抓包和排查里攒出来的。