很多朋友刚接触网络编程的时候，第一反应是去翻函数手册，socket、bind、listen、accept、connect挨个看一遍，然后照着示例抄一个客户端和服务端，跑通了就觉得入门了。等真正碰到问题——服务端重启报 Address already in use、客户端连不上一台明明开着服务的机器、数据接收端一直接不到完整报文——才意识到这些 Socket API 背后的协议原理，才是真正需要啃下来的门槛。

这篇内容就是把网络编程里最基础、也最绕不开的那部分知识做一个系统梳理：TCP/IP 协议栈为什么分层、Socket 这个抽象到底是怎么回事、三次握手和四次挥手分别在干什么、一个能跑通的最小示例怎么做，以及几个高频问题的排查思路。适合刚学完 Python 或 C 语言基础、正准备上手写网络程序的读者，也适合那些写过一阵子网络代码、但没系统看过底层原理的朋友。

1. 网络编程的核心框架：协议栈与通信模型

1.1 为什么要分层：把工程问题拆成接力赛

你随便打开一本计算机网络的书，一定会看到那张经典的协议栈图：应用层、传输层、网络层、链路层。很多初学者会觉得这只是在背概念，其实分层的真正动机非常朴素——它把一个无比复杂的通信问题，拆成了几个可以独立设计、独立替换的小问题。

打个比方，你往外地寄一个包裹。你只需要写好收件人地址，交给快递员；快递员负责把包裹送上货车，货车司机负责在高速上跑，到了目的地再由另一个快递员派送。你完全不需要关心货车怎么转弯、油够不够、走哪条高速，每一层只需要跟自己的上下两层打交道。网络分层一模一样：应用层只关心"我发的数据对方应用能不能收到"，传输层关心"数据能不能可靠地端到端送达"，网络层关心"数据从这台机器怎么路由到那台机器"，链路层关心"数据在相邻两台设备之间怎么传输"。

这种拆法带来了一个很实在的好处：每一层都可以独立演进。比如你在应用层从 HTTP/1.1 换到 HTTP/3（它底层甚至把传输层换成了 UDP 上的 QUIC），其他层完全不用跟着改。举个更直观的例子，链路层从以太网换到 Wi-Fi，你上层的 TCP 程序什么都不用改就能继续跑。这就是分层的威力。

虽然 OSI 参考模型分了七层，但实际工业界跑的是 TCP/IP 四层模型，核心就四个层级。对写应用代码的人来说，大多数时候只需要跟两样东西打交道：传输层的协议（TCP 还是 UDP）和 Socket 接口。但不懂网络层和链路层等于不知道数据从你的机器出发后经历了什么，排障的时候会非常被动。

1.2 IP 地址、端口与五元组：网络世界的门牌号

网络编程里第一个绕不开的概念就是 IP 地址和端口。IP 地址定位的是"哪台机器"，端口定位的是"这台机器上的哪个进程"。如果把一台服务器比作一栋大楼，IP 地址就是楼的门牌号，端口就是楼里的各个房间号。数据包到了楼门口，还要靠端口才能找到具体要找的人。

端口是一个 16 位的数字，范围是 0 到 65535。其中 0 到 1023 是知名端口，通常被系统进程占用，比如 80（HTTP）、443（HTTPS）、22（SSH）、3306（MySQL）。自己开发程序时，习惯上用 1024 以上的端口，避免跟系统服务冲突。我早期经常看到有人把服务监听在 80 端口上，一启动就报权限错误，其实就是在 Linux 上非 root 用户默认没有权限绑定 1024 以下的端口。这个细节在本地开发时很容易踩中。

真正要理解的是五元组的概念：源 IP、源端口、目的 IP、目的端口、协议类型。这五个元素组合起来可以唯一确定一条连接。举个例子，一台服务器上同时有一万个客户端连接着 8080 端口，为什么服务器能区分这些连接？就是因为每个连接的源 IP 和源端口不同。服务端 accept 之后拿到的 socket fd，实际上就是连接四元组（源 IP、源端口、目的 IP、目的端口）的抽象。很多人一开始想不明白"服务器只有一个端口，怎么支持这么多连接"，想通五元组这层就豁然开朗了。

1.3 客户端-服务器模型与两种服务模式

绝大多数网络程序遵循的都是同一个交互模型：服务器先启动，在某个地址和端口上监听，被动等待；客户端主动发起连接请求，然后双向通信。这个模型之所以成为主流，是因为它符合资源集中在服务端、客户端随时接入的现实需求。你写的第一个回显程序，第一个网页服务器，本质上都是这个模型。

在传输层，有两种截然不同的服务模式：面向连接的和无连接的。面向连接的代表是 TCP，通信前必须先建立连接，数据有确认、有重传、有顺序保证；无连接的代表是 UDP，不建立连接，数据包发出去就完了，不保证一定到达、也不保证到达顺序。你可以把 TCP 想成打电话——拨号、接通、说话、挂断，每一步都有反馈；UDP 想成发短信——编辑完点击发送，对方能不能收到、什么时候收到，你并不确定。

这两个选择直接决定你的 Socket 怎么创建、程序怎么组织。第一次写网络程序的人，建议先从 TCP 入手，因为它的流程清晰、每个 API 的职责边界明显，出错时也有很多现成工具可以观察连接状态。等 TCP 的整套流程跑顺了，再切到 UDP 会非常容易，反过来则会一脸懵。

2. Socket：操作系统给你的一扇网络之门

2.1 从文件描述符说起：网络编程的第一性原理

很多教材会把 Socket 描述得很玄，什么"网络通信的端点""编程接口"，听起来很高大上。但你只要记住一件事：在 Unix 体系下，一切皆文件，网络连接也不例外。Socket 本质上是操作系统内核提供的一个抽象层，它对外表现为一个文件描述符（fd），你拿到一个 int 类型的编号，就能像操作文件一样去读写网络数据。

这就解释了很多令人困惑的现象。比如为什么在 Linux 下，一个进程能使用的 socket 数量是有限制的，因为这个数量本质上受文件描述符上限约束，你用ulimit -n查到的就是能打开的最大句柄数。再比如为什么close()之后连接就断了，因为它就是"关闭文件"这个操作的网络版本。理解了 Socket 是文件描述符，你就能顺理成章地理解读写的语义：read往上收数据，write往下发数据，数据在内核缓冲区里排队。

但这个抽象也隐藏了一些重要细节：你看到的流式读写，底层其实是内核缓冲区在搬运数据。send 把数据从用户态拷贝到内核发送缓冲区，recv 把数据从内核接收缓冲区拷贝到用户态。整个过程涉及两次拷贝和用户态/内核态的切换，这也是为什么高性能网络编程后来会出现 epoll、io_uring 这些机制——它们优化的就是这些环节。

2.2 关键 API 逐个拆解：从 socket 到 send/recv

服务端的调用顺序是固定的：socket -> bind -> listen -> accept，然后进入 read/write 循环。客户端的顺序更简单：socket -> connect，然后直接读写。下面逐个拆。

socket(domain, type, protocol)：创建端点。domain 用AF_INET表示 IPv4，type 用SOCK_STREAM表示 TCP 流式传输，SOCK_DGRAM表示 UDP 数据报。protocol 一般填 0，让内核根据前两个参数自动选择。这个函数返回一个文件描述符，失败返回 -1。

bind(fd, addr, addrlen)：把 socket 绑定到一个本地地址和端口。为什么必须 bind？因为服务器要固定在一个已知的端口上等待客户端，不 bind 的话内核会随机分配端口，客户端就找不到你了。服务端 bind 的 IP 可以是全零地址（INADDR_ANY），表示监听本机所有网卡上的这个端口，这在多网卡服务器上很常用。

listen(fd, backlog)：把主动 socket 变成被动监听 socket。backlog 是完成连接队列的长度，内核会为还没被 accept 取走的已完成握手连接排队。这个值不是越大越好，它受系统参数限制，而且过大的队列只会掩盖应用处理不及时的问题。

accept(fd, addr, addrlen)：从完成队列里取一个客户端连接，返回一个新的已连接 socket fd。注意：监听 socket 一直负责招揽连接，真正收发数据的是 accept 返回的这个新 fd。很多人一开始搞混这一点，以为接受连接后还是用原来的 fd 通信，这是初级错误里最常见的。

connect(fd, addr, addrlen)：客户端主动发起连接，底层会触发三次握手。函数返回时握手通常已经完成（严格说客户端侧收到 SYN+ACK 即返回），之后就能直接读写。

send/recv和read/write本质上是同一层封装。send 并不保证把 buffer 里的数据全部发送出去，它返回的是实际发送的字节数，可能小于你请求发送的长度。recv 返回 0 表示对端关闭了连接，返回负数表示出错。这两个返回值是判断连接状态的最重要线索，后面还会细说。

2.3 TCP 与 UDP 的 Socket 差异：创建方式和使用场景

创建 TCP socket 用SOCK_STREAM，创建 UDP socket 用SOCK_DGRAM，但这不只是参数不同，整个使用流程都不同。TCP 因为要建立连接，所以服务端需要 listen + accept 这套机制；UDP 不需要连接，服务端只需要 bind 一个端口，然后用recvfrom/sendto收发数据报，根本不需要 accept，每个数据报自带源地址信息。

UDP 的编程模型比 TCP 简单直观得多：客户端不用 connect（当然也可以 connect，可以理解成预先绑定对端地址），直接 sendto 就能发，recvfrom 就能收。这种简单是有代价的：没有重传、没有顺序、没有流量控制。适合的场景是实时性要求高、能容忍丢包的业务，比如音视频通话、在线游戏的位置同步、DNS 查询。

有一个常见误区是认为"UDP 不可靠，所以业务程序都该用 TCP"。实际上很多高实时性场景宁可丢弃旧数据也不能等待重传，比如直播画面稍微卡顿可以跳帧，但等旧画面重传回来就完全没意义了。选择 TCP 还是 UDP，本质上是问自己：这个业务更怕丢，还是更怕慢？

2.4 字节序问题：一个让新老手都翻过车的大坑

字节序是个非常经典的隐蔽问题。计算机内存有两种字节存储方式：大端（高字节在前）和小端（低字节在前）。x86 架构的机器基本都是小端，而网络传输协议规定的字节序是大端，也叫网络字节序。你在 bind 或 connect 时填的端口号、IP 地址，都必须先从主机字节序转换成网络字节序。

C 语言里有一组函数专门干这个：htons()把 16 位整数从主机序转网络序，htonl()处理 32 位，对应的反向转换是ntohs()和ntohl()。在 C 里亲手填过sockaddr_in结构体的朋友，肯定都被这个坑折磨过：端口填了 8080，抓包却发现是 0x901F 而不是 0x1F90。Python 的 socket 模块封装得比较友好，但只要你手动拼二进制协议头，字节序问题一定会再次出现。

判断对方是否踩了字节序坑有个速检法：客户端能连上、也能发数据，但服务端收来的端口号或长度字段是个天文数字，或者值完全不对，先怀疑字节序，再怀疑字段对齐。我见过有人在解析自定义二进制协议时因为少做一步 ntohs，导致所有包长字段都读错，排查了整整一天。

3. 连接的生命周期：三次握手与四次挥手

3.1 三次握手：为什么必须是三次

TCP 建立连接要经过三次报文交换，这个过程大家都会背：客户端发 SYN，服务端回 SYN+ACK，客户端再回 ACK。但为什么不能是两次？这个问题值得认真想一下。

握手的目的，是让通信双方都确认一件事：自己发数据没问题，收数据也没问题，对方的收发也没问题。一次握手做不到，两次握手也做不到。假设只有两次握手：客户端发 SYN，服务端回 ACK，服务端这时会认为连接已建立，开始分配资源等待业务数据。问题是客户端收到 ACK 后没有回应，服务端根本不知道客户端是否收到了自己的 ACK。如果客户端压根没收到，说明客户端到服务端的某个环节出了问题，服务端却已经傻傻地进入建立状态，白白占着资源。

三次握手还有一个更实际的意义：处理网络中滞留的旧连接请求。假如客户端第一次发的 SYN 因为网络拥堵迟迟没到达，客户端超时重发了一个新 SYN，老 SYN 又突然在某个时刻到达了服务端。如果没有第三次握手来确认"这个连接是最新的"，服务端就会对老 SYN 也分配资源，造成资源浪费和状态混乱。第三次 ACK 的出现，让服务端可以区分"该响应的请求"和"过期的请求"，直接丢弃迟到者的资源。

有个很直观的记忆方式：三次握手的本质，是客户端和服务端互相确认"我能听到你，你也能听到我"。第一次和第二次确定了客户端收到了服务端的回应，第二次和第三次确定了服务端收到了客户端的回应。双方各自达成闭环，连接才能被双方一致地认为"可靠"。

3.2 四次挥手与 TIME_WAIT：为什么关闭比建立更麻烦

断开连接需要四次挥手，很多人不理解：建立只要三次，关闭为什么要四次？原因在于 TCP 是全双工的，每个方向上的数据流是独立的，两个方向必须各自单独关闭。客户端发 FIN 是告诉服务端"我不再发数据了"，服务端回 ACK 表示"我知道了"，这是第一个半关闭；服务端把剩余数据发完后再发 FIN 表示"我也不再发了"，客户端回 ACK，这是第二个半关闭。所以本质上是两次双向确认，加起来就是四次。

四次挥手最关键的产物是 TIME_WAIT 状态。主动关闭连接的一方（通常是先发 FIN 的那一方），在收到对方的 FIN 并回完 ACK 之后，不会立刻进入 CLOSED，而是进入 TIME_WAIT 并等待 2 个 MSL（报文最大生存时间，通常约 2 分钟）。

为什么要有这个等待？两个原因。第一，客户端回的那个 ACK 可能在网络中丢失，服务端收不到就会重发 FIN，如果客户端早就关了，服务端会一直重试。TIME_WAIT 保证了最后一个 ACK 有充足时间送达。第二，这个连接上的旧数据包可能还在网络中游荡，如果立刻用同一个四元组建立新连接，新连接可能收到旧连接的残留数据，造成数据错乱。2MSL 的时间足够让所有旧报文消亡。

TIME_WAIT 虽然保证了可靠性，但也带来一个让服务器开发者头痛的问题：如果服务端主动关闭连接，它会在 TIME_WAIT 里停留 2 分钟，期间这个端口四元组不能被复用。高并发的短连接场景下，大量 TIME_WAIT 会积压，如果此时重启服务，bind 会直接报 Address already in use。后面我会专门讲解法，这里先记住一个原则：尽量让客户端主动断开连接，把 TIME_WAIT 留到客户端，而不是集中压到服务端。

3.3 状态机速查：用一条命令看明白所有状态

用netstat -anp或者更现代的ss -ant，你能看到所有 TCP 连接的状态，这些状态就是上面整个握手挥手过程的快照。初学阶段最需要认识几个关键状态：

CLOSE_WAIT 是最值得警惕的状态。它表示对端已经关闭连接，但本地应用没有调用 close，导致这个连接始终挂在进程里。很多人排查线上问题时会看到一堆 CLOSE_WAIT，第一反应是网络问题，其实九成是代码问题——某个分支忘了关闭 fd，或者异常路径上没有 finally。这个状态一旦累积，和文件描述符泄漏没什么区别，最终会把连接数打满。

TIME_WAIT 则不同，它是主动关闭方的必经状态，正常且必要。真正的问题只在 TIME_WAIT 大量堆积且需要频繁重启服务时才需要处理，比如把服务端改成不主动断开、开启 SO_REUSEADDR，或在架构层面用连接池复用长连接。

4. 实操：用 Python 写一个完整的 TCP 回显服务

4.1 服务端代码与逐行解读

纸上谈兵到这里，该动手了。下面这个最小回显服务的代码，我建议你亲手敲一遍，然后把注释读一遍，最后再删掉注释自己默写一遍。默写能过，说明基本的调用流程已经进了脑子。

import socket # 1. 创建 TCP socket：AF_INET 表示 IPv4，SOCK_STREAM 表示 TCP server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 2. 允许端口复用，解决服务端重启时的 Address already in use server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 3. 绑定本机 127.0.0.1 的 8080 端口 server.bind(('127.0.0.1', 8080)) # 4. 开始监听，backlog 设为 5 server.listen(5) print('server listening on 127.0.0.1:8080') # 5. 主循环：不断接受新连接 while True: conn, addr = server.accept() print(f'client connected: {addr}') # 6. 每个连接内部循环读写 while True: data = conn.recv(1024) # 一次最多读 1024 字节 if not data: # 对端关闭，recv 返回 b'' break conn.sendall(data) # 原样返回（echo） conn.close() print(f'client disconnected: {addr}')

逐行看几个关键设计。第二步的SO_REUSEADDR是新手最容易漏掉的。前面说过，服务端如果主动断开连接会进入 TIME_WAIT，紧接着重启就 bind 失败，报错信息非常劝退。加上这一行，同样的端口在 TIME_WAIT 期间也能重新绑定，开发调试阶段几乎必写。注意它和SO_REUSEPORT不同，后者允许两个进程同时 bind 同一个端口，用于负载均衡场景，平时用不上。

第四步的listen(5)，这里的 5 是指内核完成队列的长度。如果队列满了，新的连接请求会被内核拒绝或丢弃，客户端表现为连接变慢或失败。这个值不是性能指标，只是背压阀，生产环境通常由系统内核参数控制，应用层设一个大致的合理值即可。

第六步的recv(1024)里 1024 是单次最大读取字节数。这是初学者最容易误解的地方：recv 并不保证一次调用就能收到对方 send 的全部数据，它只保证"最多返回这么多个字节"，实际返回多少由内核缓冲区和网络状况决定。所以收发循环必须依赖返回值来判断数据边界，而不是假设一次调用就收完了。回显服务这里比较特殊，因为收完再原样回发，天然能应付分片。

4.2 客户端代码与联调步骤

客户端的代码更短，但别小看它，它是你验证整个学习成果的探测器。

import socket client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect(('127.0.0.1', 8080)) client.sendall(b'hello, tcp!') # 发送数据 data = client.recv(1024) # 等待回显 print(f'received: {data}') client.close()

测试步骤很简单：先在一个终端启动服务端脚本，再开另一个终端运行客户端。如果一切正常，你会看到客户端打印出received: b'hello, tcp!'，服务端终端打印出连接建立和断开的信息。

这里我强烈建议你在测试时开第三个终端，用ss -ant观察连接状态的变化。运行ss -ant | grep 8080，在客户端 connect 前后各看一眼，你能亲眼看到连接从 LISTEN 变成 ESTABLISHED，客户端断开后看到 TIME_WAIT。把抽象的状态机跟真实场景对应起来，比背十遍状态转移图都管用。Windows 上没有ss，用netstat -ano也能看到同样的状态。

联调通过后，你还可以用系统自带的nc（netcat）充当客户端来做压力毛测试。执行echo "hello" | nc 127.0.0.1 8080，或者直接nc 127.0.0.1 8080进入交互模式，就能向服务端发任意内容看回显。用现成工具代替自己写客户端，在排查服务端问题时能节省大量时间。

4.3 多客户端支持：从单线程到线程化

上面这个回显服务有个明显问题：它是单线程的，处理完一个客户端连接之后才 accept 下一个。这意味着第二个客户端连上来，必须等第一个客户端断开才能开始通信。你可以实测验证一下：开两个客户端，第一个连接后不发送数据，第二个客户端会一直卡在 connect 成功但无法通信的状态。

要解决这个问题，最简单的改造是把每个连接的处理逻辑放到一个线程里。Python 里用threading.Thread就能实现，改动非常小：

import socket import threading def handle_conn(conn, addr): print(f'client connected: {addr}') try: while True: data = conn.recv(1024) if not data: break conn.sendall(data) finally: conn.close() print(f'client disconnected: {addr}') server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind(('127.0.0.1', 8080)) server.listen(5) while True: conn, addr = server.accept() t = threading.Thread(target=handle_conn, args=(conn, addr)) t.start()

注意handle_conn里用了try/finally保证连接一定会关闭，这是对 CLOSE_WAIT 问题最直接的预防。虽然 Python 的多线程因为 GIL 的存在不适合高并发 CPU 密集型任务，但处理 I/O 等待是它的强项——线程在等网络数据时会释放 GIL，所以做这种网络服务完全够用。如果将来需要更高并发，可以从selectors模块起步，再过渡到asyncio，那是一条独立的学习路线，不在这次基础范围内。

5. 常见问题与排查技巧实录

5.1 Connection refused 与 Timeout：两个完全不同的病

"连接被拒绝"和"连接超时"是客户端最常碰到的两个错误，很多人混为一谈，其实两者指向的问题完全不同。

Connection refused，对应 C 语言里的ECONNREFUSED，意思是客户端发 SYN 后，服务端所在主机直接回了一个 RST 包主动拒绝。原因通常是：端口上没有进程在监听，或者服务的 IP 地址写错了（比如服务端绑定的是 127.0.0.1，客户端却用局域网 IP 去连）。这种错误反馈非常快，几乎立刻返回，说明网络是通的，只是对方主机明确说"这里没有这个服务"。

Timeout则完全不同，它表示 SYN 发出去后石沉大海，没有回应也没有拒绝。原因通常是：对方主机的防火墙把包静默丢弃了，或者目的 IP 根本不可达（跨网段、路由不通、云安全组没放行端口）。我之前踩过一次典型的坑：ECS 机器上服务监听在 0.0.0.0，本地也能访问，但从外网怎么都连不上，最后发现是云厂商的安全组没加白名单。

排查这两个问题的命令是通用的：先ping看主机通不通，再用telnet IP 端口或nc -vz IP 端口试探端口。通了说明服务没问题，可能是应用层的问题；不通就沿着防火墙、监听地址、路由逐层查。

5.2 Address already in use 的真相与解法

服务端重启时报Address already in use，是网络编程里知名度最高的报错之一。它的底层原因前面已经说过：上一个进程还处于 TIME_WAIT 状态，端口四元组还没释放，你又要 bind 同一个端口，内核当然不干。

解法也分两层。第一层是代码层面，socket 创建后立刻做SO_REUSEADDR设置，这是开发环境的默认标配。第二层要分清场景：如果你的服务是正常的主动关闭方（比如 HTTP 短连接服务，服务端往往先断开），TIME_WAIT 是合法且必要的，不必强求消除，只要启动时能复用端口不影响重启就行。如果 TIME_WAIT 数量大到影响端口资源池，就应当考虑让客户端断开连接、使用长连接复用、或者调整内核参数net.ipv4.tcp_tw_reuse（注意它是针对客户端连接方向的）。

还有一个容易混淆的情况：两个不同的进程同时 bind 同一个端口，报的也是这个错。SO_REUSEADDR 解决不了这个问题，它只管 TIME_WAIT 状态下的复用。如果确实需要多进程监听同一端口，Linux 内核 3.9 之后的SO_REUSEPORT才是正解，nginx 多 worker 共享端口用的就是它。

5.3 recv 返回 0 与半关闭：连接状态的分水岭

我把recv的返回值当成判断 TCP 连接状态的第一信号。它有三种典型情况：

正值：收到了数据，这个数字就是本次实际读到的字节数。注意可能小于你申请的长度，这是正常的。

0：对端发来了 FIN，连接被有序关闭，没有更多数据。这是最重要的信号——它表示"对方正常关闭了"，不是出错。很多代码在 recv 返回 0 后没有及时处理，继续 recv 会一直返回 0，造成死循环空转。

-1（或异常）：出错，比如连接被重置（对端发了 RST），或本地 socket 已关闭。

与返回 0 紧密相关的概念是半关闭。TCP 是双向通道，close()会立刻销毁整个 socket，而shutdown(SHUT_WR)只关闭发送方向，接收方向仍然可以收数据。这在某些协议里很实用：客户端发完请求后 close 写方向，告诉服务端"我的数据发完了，你可以准备返回结果了"，但客户端还能继续读响应。HTTP 协议早期的 Keep-Alive 设计也和这个机制有关。

实战中，判断"数据是否全部收完"有三种常见策略：基于连接关闭（recv 返回 0）、基于固定长度字段、基于特殊分隔符（比如 HTTP 的\r\n\r\n）。初学者最容易犯的错是以为一次 recv 就能把整个消息读完，然后硬等到超时才继续。记住 TCP 是字节流，没有消息边界，任何业务层的消息边界都必须自己定义。

5.4 send 发不完与 Nagle 算法：两个"拖后腿"的细节

先说出第一个细节：send和recv一样，并不保证一次把所有数据发出去。它返回的字节数有可能比请求少，因为内核发送缓冲区可能放不下。所以严谨的做法是循环发送直到发送完，或者直接用 Python 的sendall（它内部就是循环发送）。C 语言里没有现成的 sendall，你得自己写循环。很多线上诡异的数据缺失问题，最后都定位在"只调了一次 send，没检查返回值"。

第二个细节是 Nagle 算法。TCP 默认开启 Nagle，它的作用是：如果发送缓冲区里还有未确认的小数据包，就把新来的小数据合并到一起再发，减少网络上小包的数量。这对大流量传输是好事，但对实时交互是灾难——比如你实现了一个远程操控协议，每次按键发一个包，Nagle 会把它们攒在一起，用户会觉得操作有明显的卡顿延迟。对延迟敏感的应用，可以设置TCP_NODELAY选项关掉 Nagle，让每个小包都立刻发出。

不过关闭 Nagle 也有代价：小包变多，网络利用率下降，极端情况下会出现"糊涂窗口综合症"。所以正确的做法是按业务场景取舍：交互类、实时类关掉；批处理、文件传输保持默认。多数框架（比如 Netty）默认会关掉 Nagle，因为在它们的定位里低延迟更重要。

另外再提一句tcpdump和 Wireshark，这两个工具虽然不在基础 API 范围内，但我建议你一学完基础知识就上手用。用tcpdump -i lo port 8080 -nn -s 0 -w out.pcap抓一下本机回环流量，再用 Wireshark 打开，你能亲眼看到三次握手的 SYN、SYN+ACK、ACK 三个包，看到挥手时的 FIN 序列。任何对 TCP 状态的疑问，在抓包结果面前都会变得无比清晰。我自己就是在抓包之后，才真正把三次握手从"背流程图"变成"看得到的过程"。

说起来，网络编程的知识体系其实是一棵有主干的树：协议栈是根，Socket 是干，握手挥手是花，各种异常处理是修剪枝叶的功夫。把这几个基础部分串成一个整体去理解，而不是零散地背 API 返回值和参数，后面读框架源码、排查线上问题都会顺很多。希望这篇总结能帮你在起步阶段少走几步弯路。