做Linux服务端开发这几年，我发现自己绕不开的始终是网络套接字编程。无论是写一个高并发网关，还是调试一个偶发超时的内部服务，最后追到根上，几乎都是socket层的问题。套接字就像操作系统给应用层开的一扇门，数据要从A机器到B机器，最终都必须穿过这扇门。刚开始接触的时候我也觉得晦涩，一堆系统调用、状态转换、缓冲区概念，光是背都背不完。但真正跑过几个项目、踩过几次坑之后会发现，网络编程的门槛其实不在于记住多少函数，而在于能不能把“数据怎么从一端到另一端”这件事想清楚。
这篇文章我想把Linux网络套接字编程这条线完整地捋一遍，从最基础的socket系统调用，到完整的TCP服务端和客户端实现，再到阻塞非阻塞、IO多路复用这些工程上躲不开的模型选择。内容不做纯理论堆砌，尽量结合我实际写代码和服务排查时遇到的场景来讲。适合刚入门网络编程、准备系统补一补Linux服务端基础的同学，也适合写过一些demo但想搞清楚背后原理的开发者。看完之后你至少能独立写一个可用的TCP服务，并且知道遇到连接不上、服务卡死这类问题时该从哪里下手。
1. 动手之前先画图：套接字编程到底在解决什么问题
1.1 一次网络通信的完整链路
先抛开一堆术语，只看一条数据从一台机器到另一台机器发生了什么。假设你的浏览器要访问某台服务器上的网页，应用层发起一个HTTP请求，这个请求先经过socket接口进入内核，内核把数据交给TCP协议栈，TCP在数据前面加上自己的头部，再交给IP层，IP层又加上IP头部，最终通过网卡把数据包发出去。对端网卡收到包之后层层拆解，把数据交回对端应用。
这里面有个容易被忽略的事实：应用进程之间并不直接通信，它们各自只跟自己的内核协议栈通信。客户端写数据，是把数据写进内核的发送缓冲区；服务端读数据，是从内核的接收缓冲区里读。所谓的“连接”，是两端内核维护的一组状态。理解了这一点，很多问题就说得通了。比如你问“为什么服务端不调用accept也能收到数据？”，因为数据是内核收的，跟应用进程有没有accept没有关系。
套接字编程的本质，就是让我们能够：
- 创建这样一个通信端点（socket）
- 给端点绑定一个本地地址和端口（bind）
- 让端点可以被别人找到并发起连接（listen/accept），或者主动去连别人（connect）
- 在这个端点上收发数据（send/recv、read/write）
- 通信结束后释放资源（close）
可以说所有网络编程的问题，最后都能归约到这几个动作上。
1.2 选对传输层协议：TCP还是UDP，先别急着拍板
做技术选型的时候，很多人一上来就问“高并发用什么协议”，其实协议选择跟并发量关系不大，跟业务对可靠性的要求关系才大。
TCP是面向连接的、可靠的字节流协议。所谓面向连接，是说通信双方在收发数据前，要先通过三次握手建立一条逻辑连接。所谓可靠，是TCP会通过序列号、确认应答、超时重传、校验和等机制，保证数据有序、不丢、不重。代价就是协议头部更大、握手有开销、丢包重传会造成延迟抖动。
UDP是无连接的、不可靠的数据报协议。它不保证一定到达，不保证顺序。但没有这些保障机制，它的开销就小，延迟低，适合那些能容忍少量丢包、但对实时性要求高的场景。
判断依据可以简化成两个问题：数据丢了能不能接受？数据乱序了能不能接受？两个都是否，选TCP；至少一个是是，再结合场景考虑UDP。大多数业务服务——HTTP、数据库、缓存、消息队列，全是TCP，所以这篇文章的重点放在TCP上，但保留一节能讲清楚它们底层模型的差异。
1.3 阻塞与非阻塞：编程模型的分水岭
套接字默认是阻塞的。阻塞是什么意思？以recv为例，如果接收缓冲区里没有数据，调用recv的线程会一直挂在那里，直到有数据可读或者出错才返回。这种模型写起来简单：一个线程对应一个连接，代码顺着往下读就是事件发生的顺序。
但问题也很明显，一个线程只能伺候一个连接，如果要同时处理几千个连接，就得有几千个线程，线程切换开销和内存消耗都非常可观。于是就有了非阻塞模式：recv没有数据时立即返回一个错误码（EAGAIN或EWOULDBLOCK），告诉你“现在没货，你待会再来”。进程可以轮询所有连接，看哪个有数据。
轮询也不是个好办法，连接多了CPU全耗在空转上。这就要引入IO多路复用，把这些连接的等待统一交给内核去监听。这部分在第五章详细讲，你只要先记住：单线程要处理大量并发连接，必须配合非阻塞套接字和IO多路复用一起用。这三者是一套组合拳，缺了哪个都会出幺蛾子。
2. 核心系统调用的门道：每一步都不是白写的
2.1 socket()：第一扇门
int socket(int domain, int type, int protocol);第一步是创建一个套接字描述符。三个参数里，domain指定协议家族，IPv4就是AF_INET，IPv6是AF_INET6，本地进程间通信用AF_UNIX。type指定套接字类型，SOCK_STREAM对应TCP，SOCK_DGRAM对应UDP。protocol通常直接写0，让内核根据前两个参数自动选择。
这里有一个我在面试中常问到的问题：为什么有了type还要protocol？因为协议家族和类型并不总是能唯一确定一个协议。比如AF_INET加SOCK_STREAM，在大多数系统上就是TCP，但有些协议族底下存在多个协议实现同一个语义的情况，这时protocol就派上用场了。实际上传0是绝大多数场景的正确选择，不要自作聪明地传IPPROTO_TCP之外的奇怪值。
创建socket之后，默认是一个主动套接字，也就是说它天生适合去发起连接。如果要做服务端被动接受连接，后面还需要通过listen把它变成被动套接字。这个细节看起来不起眼，却是理解服务端编程要点的关键。
2.2 bind()：把名字贴在门上
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);socket创建出来的时候还是匿名的，内核不知道你这个套接字要服务哪个地址和端口。bind的作用就是把一个本地地址绑定到套接字上。对于IPv4服务端，核心是填充一个sockaddr_in结构体，指定IP和端口。
这里有两个经验点需要特别记牢。
第一，端口号和IP的关系。端口号的范围是0到65535，其中0到1023通常需要特权才能绑定，1024到49151是普通用户可用的范围，49152到65535是动态端口范围。写测试程序的时候，选一个1024以上的端口就行，不要手贱去绑80或443，免得跟真实服务冲突。
第二，IP地址填什么。开发中常见的填法有两种。一种是INADDR_ANY，也就是0.0.0.0，表示绑定到本机所有网络接口。如果你的机器有多个网卡，无论是内网IP还是外网IP，只要目标端口对上，都能访问到这个服务。另一种是指定一个具体的IP，表示只接受发往这个地址的连接。做多网卡机器上的服务部署时，绑错地址是最常见的低级错误之一——你明明开了服务，别人通过另一个IP怎么也连不上，一查才发现绑的是127.0.0.1。
2.3 listen()和accept()：被动接收连接的完整姿势
int listen(int sockfd, int backlog); int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);服务端通过listen把套接字从主动转为被动，让内核开始接受发往这个地址和端口的连接请求。backlog参数用来指定全连接队列的长度。
看这个问题之前，先得知道内核维护着两个队列：半连接队列和全连接队列。三次握手过程中，收到SYN后连接进入半连接队列，握手完成之后连接被移入全连接队列，等待应用层调用accept取走。如果应用层处理得慢，全连接队列满了，新的连接就会被内核直接丢弃，客户端表现为连接超时或者被拒。
backlog参数在Linux 2.6以后的影响比较复杂，你可以简单地认为它和全连接队列长度正相关。实际工程中，这个值一般不要设得太大，因为队列里堆积连接本来就不是正常状态，设置太大反而掩盖了应用层处理不过来的问题。我曾经见过一个服务把backlog设成65535，平时没异常没什么感觉，一次下游故障导致大量连接堆积，内存直接被打爆。
accept的作用是从全连接队列里取出一个已经完成握手的连接，返回一个全新的套接字描述符。这里有个新手总是搞混的点：监听套接字和已连接套接字是两个完全独立的东西。监听套接字只负责接受新连接，不负责收发数据，数据操作都发生在accept返回的新套接字上。理解了这一步，才能理解为什么有的服务要开好几个线程，一边accept一边对已连接套接字做读写。
2.4 connect()：主动发起连接
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);客户端的connect调用会触发三次握手。对于阻塞模式的套接字，connect要等到握手完成或者超时出错才返回。对于非阻塞模式，connect立即返回，但此时连接可能还没完成，需要通过轮询或者可写事件来判断连接是否建立成功。这个细节在写高并发客户端时很关键，因为如果让每个连接都阻塞在connect上，大量连接的握手等待时间会直接拖垮整个进程。
connect出错时的errno也值得看一眼。ECONNREFUSED表示目标端口根本没有服务在监听，内核直接回了RST。ETIMEDOUT表示握手超时，常见于目标主机网络不通或者防火墙丢弃了包。EHOSTUNREACH表示网络不可达，比如路由都找不到。排障的时候，这些错误码能帮你快速缩小问题范围。
3. 从零写一个TCP回显服务：完整实操记录
3.1 服务端代码拆解
纸上谈兵再多，不如直接写一遍。这里实现一个最简单的TCP回显服务：客户端发什么，服务端原样返回什么。代码用C写，因为Linux网络编程的经典接口就是C接口，而且可以让你看清每一步系统调用的细节。
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <arpa/inet.h> #include <sys/socket.h> #define PORT 9527 #define BACKLOG 64 #define BUFFER_SIZE 1024 int main() { int listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd == -1) { perror("socket"); exit(1); } int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); struct sockaddr_in server_addr; memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = htonl(INADDR_ANY); server_addr.sin_port = htons(PORT); if (bind(listen_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) == -1) { perror("bind"); close(listen_fd); exit(1); } if (listen(listen_fd, BACKLOG) == -1) { perror("listen"); close(listen_fd); exit(1); } printf("server listening on port %d\n", PORT); while (1) { struct sockaddr_in client_addr; socklen_t client_len = sizeof(client_addr); int conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &client_len); if (conn_fd == -1) { perror("accept"); continue; } char client_ip[INET_ADDRSTRLEN]; inet_ntop(AF_INET, &client_addr.sin_addr, client_ip, sizeof(client_ip)); printf("connection from %s:%d\n", client_ip, ntohs(client_addr.sin_port)); char buffer[BUFFER_SIZE]; ssize_t n; while ((n = read(conn_fd, buffer, sizeof(buffer))) > 0) { write(conn_fd, buffer, n); } close(conn_fd); } close(listen_fd); return 0; }逐段看一下关键点。
socket创建之后，我先调了一次setsockopt，设置SO_REUSEADDR为1。这一步很多人会忽略，但是不设置的话，服务端程序关闭后如果端口还没完全释放，尤其是上次连接处于TIME_WAIT状态时，再次bind会得到Address already in use错误。这个错误我在刚开始做开发的时候踩过不少次，每次改完代码重启服务都要多等一会儿或者换个端口，后来养成了只要是写服务端，就默认加上SO_REUSEADDR的习惯。
bind里有一对函数要注意：htonl和htons。主机字节序和网络字节序通常是不同的，x86这类小端机器上，多字节整数在内存里的排列方式和大端的网络传输顺序不一样。htonl把主机字节序的32位整数转成网络字节序，htons处理16位整数。写网络代码的时候，凡是往sockaddr里填地址和端口，都要过一遍这两个函数，否则会出现一种很诡异的现场：服务端明明绑定了9527端口，用ss一看却是另一个数字。
accept后面的处理是最简单的单线程顺序模型。每来一个连接，先打印客户端的IP和端口，然后循环read和write回显数据。read返回0表示对端关闭了连接，read返回-1表示出错，这里没有细分错误类型，实际工程中至少要把EINTR和EAGAIN单独处理，后面排查章节会再看这个问题。
3.2 客户端代码与一次完整跑通
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <arpa/inet.h> #include <sys/socket.h> #define SERVER_IP "127.0.0.1" #define SERVER_PORT 9527 int main() { int sock_fd = socket(AF_INET, SOCK_STREAM, 0); if (sock_fd == -1) { perror("socket"); exit(1); } struct sockaddr_in server_addr; memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(SERVER_PORT); if (inet_pton(AF_INET, SERVER_IP, &server_addr.sin_addr) <= 0) { perror("inet_pton"); exit(1); } if (connect(sock_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) == -1) { perror("connect"); close(sock_fd); exit(1); } const char *message = "hello, socket"; write(sock_fd, message, strlen(message)); char buffer[1024]; ssize_t n = read(sock_fd, buffer, sizeof(buffer)); if (n > 0) { printf("received: %.*s\n", (int)n, buffer); } close(sock_fd); return 0; }客户端的套路比较固定：socket创建描述符，填充服务端地址后用inet_pton把点分十进制的IP字符串转成32位整数，然后connect。inet_pton和inet_aton、inet_addr这几个函数经常被拿来比较，其中inet_addr不支持IPv6而且有一些边界问题，建议习惯用兼容性更好的inet_pton。
编译运行也很简单：
# 终端A，启动服务端 gcc server.c -o server ./server # 终端B，启动客户端 gcc client.c -o client ./client预期输出是在服务端打印出客户端的IP和端口，在客户端打印出服务端回显回来的字符串。如果要验证并发场景，可以在多个终端各跑一个客户端同时连接，单线程模型下，每个客户端只能串行被处理——一个连接不关闭，后面的连接就只能在accept队列里等着。这是理解后面多路复用内容的一个重要铺垫。
3.3 缓冲区大小和读写行为的选择
代码里的BUFFER_SIZE是1024，这个值在真实项目里需要根据业务数据特征来定。定太小，一个完整消息要分多次读写完成，系统调用次数增加；定太大，每个连接都分配一个大缓冲区，内存消耗会很难看。服务端如果同时有1万个连接，每个连接分配64KB缓冲区，光缓冲区就要640MB，瞬间把内存吃穿。更好的方式是动态分配或者用读缓冲区池。
另外要注意read和write的返回值。read返回的是实际读到的字节数，这个数可能小于你给的缓冲区大小。write也是，它并不保证把buffer里的内容一次性全写出去，返回值才是实际写入的字节数。所以严谨的写法应该是循环write直到把待发送数据写完。回显场景里数据量不大，影响不明显，但一旦开始传大文件或者写网关转发，这个地方不处理干净就会出现数据残缺的诡异bug。
4. 排障手册：连接出问题先从这几处查起
4.1 bind失败：Address already in use的真相
bind返回EADDRINUSE，第一反应不应该是“端口被人占了”这么简单。很多时候，上次运行的进程已经退出，但端口还是被占用，原因就藏在TCP状态TIME_WAIT里。主动关闭连接的一方，连接状态会进入TIME_WAIT，这个状态要持续大约2MSL（Linux上通常60秒左右），目的是确保最后一个ACK能到达对端，以及让网络中残留的报文段自然消失。如果你的服务端每次处理完就主动close连接，之后立刻重启服务，很可能碰到这个错误。
SO_REUSEADDR就是解决这个问题的。它允许bind时复用处于TIME_WAIT状态的本地地址和端口。注意它不等同于SO_REUSEPORT，后者是允许多个套接字绑定到完全相同的地址端口进行负载均衡，两者用途差别很大，不要混为一谈。
排查的时候，可以用socket状态命令确认到底是谁占着端口：
ss -lntp | grep 9527-l是只看监听中的连接，-n不做DNS解析，-t只显示TCP，-p显示进程信息。输出里能看出来端口处于LISTEN还是TIME_WAIT，如果对应着一个进程号，说明进程还活着，找到它处理掉或者确认是否可以共处。
4.2 connect超时与拒绝连接：两种情况要分清
connect返回ECONNREFUSED，说明目标端口上没有进程在监听。这个过程实际上很迅速，因为对端内核收到SYN后会直接回RST。表现为“秒拒”。
而connect超时，通常表现为长时间无响应最后返回ETIMEDOUT或者EHOSTUNREACH，这说明SYN包要么没有到达对端，要么对端内核没有回应。可能的原因包括：目的主机不在线、中间路由有问题、防火墙丢弃了SYN包。这种时候用ping测一下主机通不通，再判断端口有没有被防火墙规则拦截。如果连ping都不通，先把网络连通性解决掉再查应用层。
排查这类问题，还有一个高效工具叫tcpdump：
sudo tcpdump -i any tcp port 9527它能打印出TCP报文的交互过程。你会看到客户端发了SYN，等服务端回SYN+ACK，如果只有SYN没有ACK，说明SYN被丢了，要么是防火墙，要么是服务端程序压根没把listen调用执行成功。我看到很多同事排查了很久应用层代码，最后用tcpdump一眼定位到问题在网络配置层。尽早用抓包工具，可以省掉大量无谓的猜测。
4.3 TIME_WAIT导致的端口资源枯竭
大量短连接场景下，TIME_WAIT是绕不开的坎。客户端频繁发起连接、断开，每次主动断开都会让这个连接进入TIME_WAIT。由于TIME_WAIT期间本地端口不能再次绑定使用，当每秒新建连接数很大时，可用端口会被快速消耗干净，connect会直接报EADDRNOTAVAIL。
应对思路有几条：一是让客户端不要主动关闭，改成服务端主动关，把TIME_WAIT的代价甩给服务端；二是开启SO_REUSEADDR，允许TIME_WAIT状态的端口被重用；三是从业务层面减少无谓的短连接，改用连接池或者长连接。这些方案各有代价，服务端主动关之后，服务端的TIME_WAIT数量会上升，但服务端通常监听端口只有一个，不受本地端口数量限制，所以总体上比客户端承担更划算。
ss命令可以直接统计TIME_WAIT数量：
ss -tan state time-wait | wc -l如果这个数字持续上涨，就要认真考虑连接生命周期策略了。
4.4 粘包与半包：TCP字节流的边界问题
很多从其他语言转过来写TCP服务的人，第一反应是“send一次，recv一次，两边消息应该是一对一的”。事实完全不是这样。TCP是流式协议，它不管你的业务消息边界在哪里。内核缓冲区里来了数据，recv能读多少取决于缓冲区现有多少，而不是你想读多少。
粘包就是多条业务消息被合并到同一次recv里返回了；半包是一条消息被拆成多次recv。处理的办法只有一个套路：应用层自己定义消息协议，明确每条消息的边界。最简单可靠的方式是“长度前缀法”，4个字节的消息长度加消息内容，接收端先读4字节长度，再根据长度读足够多的内容。这个方案注意点是长度字段的字节序要固定，推荐网络字节序，避免跨平台时出现解析错乱。
回显demo里没有这个协议层，因为它不管什么边界直接回原数据。但只要你开始写真正的业务服务，粘包处理就是第一道绕不开的工序。
5. 再进一步：IO多路复用与并发模型的选择
5.1 多线程/多进程模型的瓶颈在哪里
前面那个单线程串行模型，一次只能服务一个连接，肯定不能直接上生产。最简单的改进是来一个连接就创建一个线程去处理，线程内部阻塞读写，互不干扰。这个模型写起来很直观，很多新手项目就是这么做的。
但它有两个明显的天花板。一是线程开销，每建一个线程，默认栈空间就可能是8MB（虚拟内存），几千个连接上来，光是线程栈就把地址空间吃完了；二是线程切换成本，大量线程都在等着IO，CPU时间大片浪费在上下文切换上。一个常规配置的服务器能用这个模型扛住几百个连接已经很勉强了。
线程池只能缓解线程创建销毁的频繁开销，解决不了“大量连接同时没数据时线程空挂”的浪费本质。真正高效的思路是不要每个连接占一个线程，而是用少量线程去管理大量连接，连接有事件了才处理，没事件是靠内核通知。
5.2 select和poll为什么不适合高并发
select和poll都是让内核帮你监听一组描述符，有事件就通知你。select用fd_set位图表示描述符集合，上限通常被限制在1024个，光这一点就宣判了它在高并发场景的死刑。poll改用pollfd数组，没有数量上限，但性能瓶颈还在：每次调用都要把整个描述符集合从用户态拷贝到内核态，内核需要线性扫描全部描述符才能知道哪些有事件，返回后用户态还要再线性扫描一遍找出有事件的描述符。O(n)的复杂度，n是监听的总描述符数量，连接越多，每轮空转的代价越高。
select/poll还有一个麻烦事：每次调用返回后，描述符集合状态会被修改，下次调用前必须重新构建并重新传入。这意味着你要维护一份自己的描述符状态副本，代码写起来啰嗦且容易出错。
5.3 epoll的工程细节：水平触发和边缘触发的选择
epoll和select/poll最大的区别在于事件驱动。你用epoll_ctl把关心的描述符注册到内核，内核只维护这个集合，不重复拷贝。当你调用epoll_wait时，它只返回真正就绪的事件，不需要线性扫描全部监听对象。所以复杂度从O(n)降到了O(就绪事件数)，连接数再多也有余力。
epoll有水平触发（LT）和边缘触发（ET）两种模式。LT模式下，只要缓冲区里还有没读完的数据，epoll_wait就会一直返回这个描述符可读。ET模式下，只有当缓冲区从无数据变为有数据这个“边缘”时刻，epoll_wait才会通知一次。ET要求你把数据一次性读完，直到read返回EAGAIN，否则就会漏数据。
从工程角度看，LT更保守、更不容易写错，适合大多数服务；ET更高效，减少了重复唤醒，但对代码要求很高，读完没读完的判断稍有疏忽就出bug。我的建议是新项目非必要不用ET，先用LT把业务逻辑跑通，性能确实有瓶颈再尝试ET优化。
一个基础epoll模型的骨架大致是这样：
int epfd = epoll_create1(0); struct epoll_event ev, events[64]; ev.events = EPOLLIN; ev.data.fd = listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); while (1) { int n = epoll_wait(epfd, events, 64, -1); for (int i = 0; i < n; i++) { if (events[i].data.fd == listen_fd) { int conn_fd = accept(listen_fd, ...); // 把conn_fd加入epoll监听，设为非阻塞 } else { // 处理已连接描述符上的可读事件 } } }注意一点：epoll_wait返回的事件告诉你可以读了，但读多少是一次性读尽量多还是读一部分，取决于你是LT还是ET。配套使用的非阻塞套接字，是为了一次read能优雅地遇到EAGAIN然后退出循环，而不是卡死在阻塞调用里。
5.4 业务场景决定并发模型
聊了这么多模型，其实没有绝对的最优解。短连接比如零散的HTTP请求，用epoll配合线程池处理，性能和代码复杂度平衡得比较好。长连接比如即时通讯或推送服务，连接大部分时间没有数据，epoll很自然能省掉大量轮询成本。游戏服务器那种大量状态同步的场景，还要考虑每帧处理多少个包、协议怎么设计。
核心思路可以总结成一句话：确认IO操作会不会阻塞、等待的事件从哪来、多个事件之间是否有相互依赖，然后选择让代码最可控的那套模型。技术选型最怕的是为了用某个时髦方案而强行改造业务架构，把简单的代码迭代成谁都看不懂的复杂度。网络编程尤其如此，链路一复杂，线上出问题的时候定位成本会成倍增加。
写得多了之后的一些体会
回看整个学习过程，我觉得有几个习惯对提升网络编程水平帮助很大。一个是不管遇到什么连接问题，先抓包再猜测，数据不会撒谎，比人脑推演可靠得多。另一个是每次改完socket相关代码，都要弄清楚内核在那一刻做了什么，而不是只关注应用层的返回值。很多人栽跟头都栽在“我只知道调用要做什么，不知道内核为什么这么表现”上。
最后再说一个小技巧：调试服务端程序时，把strace -f -e trace=network ./server用起来，它会把程序每次socket、bind、listen、accept、read、write的系统调用和返回值都拉出来，基本相当于给程序装了个监控摄像头。配合ss和tcpdump，一套组合拳下来，大多数网络问题都能在半小时内锁定位。这个组合我至今还在用，推荐你也试试。
：计数、基数、桶排序详解与实战)