Socket on JasperSao的博客

POSIX API 与 TCP 连接生命周期

Mon, 10 Aug 2026 00:00:00 +0800

本篇承接已有的《网络IO》《IO 多路复用与 Reactor》《Reactor 与 epoll：百万并发网络服务器课后笔记》。
socket、fd、服务端基础代码、select/poll/epoll 和 Reactor 不再重复；

一、为什么网络代码可以跨 Linux、Unix 和 macOS

Linux 受到 Unix 设计影响，不同厂商和社区又形成了不同发行版。它们的内核、工具和扩展功能可能不同，但应用程序仍然可以使用一组相似的接口：

socket();
bind();
listen();
accept();
connect();
send();
recv();
close();

重要原因是这些系统广泛支持 POSIX 和 BSD Socket 风格的接口规范。

标准接口主要约定：

函数叫什么
函数接收什么参数
返回值如何表达成功和失败
错误通过什么方式报告
应用程序可以依赖哪些行为

不同系统的内核实现可以不同，但只要对应用程序提供兼容接口，使用标准接口编写的代码就比较容易迁移：

应用程序
 ↓
POSIX / Socket API
 ↓
不同操作系统的内核实现

代码可以直接迁移还要求它没有依赖某个系统的专有能力。例如 socket、bind、listen 是通用 Socket API；epoll 是 Linux 专用机制，迁移到 macOS 时通常要换成 kqueue。

二、客户端和服务端使用的 API

2.1 TCP 客户端

课堂中的客户端调用顺序：

socket();
bind();//optional
connect();
send();
recv();
close();

对应作用：

socket() → 创建 socket 和 fd
bind() → 可选，指定本地 IP 和本地端口
connect() → 指定对端并发起 TCP 连接
send() → 把应用数据交给内核
recv() → 从内核取出收到的数据
close() → 关闭 fd，并推动 TCP 关闭过程

客户端通常不主动调用 bind()。如果直接 connect()，内核会选择合适的本地 IP 和临时端口。

临时端口范围由系统配置决定，不固定为 1024～65535。Linux 上可以查看：

cat /proc/sys/net/ipv4/ip_local_port_range

客户端需要固定源 IP 或源端口时，才会在 connect() 前显式调用 bind()。

2.2 TCP 服务端

课堂中的服务端调用顺序：

socket();
bind();
listen();
accept();
recv();
send();
close();

与 Reactor 结合后还会使用：

epoll_create();
epoll_ctl();
epoll_wait();
fcntl();

这两组 API 位于不同层次：

socket/bind/listen/accept/connect/send/recv/close
 → 管理 TCP socket 和数据传输

epoll_create/epoll_ctl/epoll_wait
 → 管理大量 fd 的就绪事件

fcntl() 常用于把 fd 设置为非阻塞。

三、一次 TCP 连接的三个阶段

1. 建立连接：三次握手
2. 数据传输：序号、确认、流量控制、拥塞控制和重传
3. 断开连接：FIN/ACK 与 TCP 状态迁移

应用程序看到的是：

connect() / accept()
send() / recv()
close()

内核真正执行的是 TCP 协议状态机。

四、socket() 在应用层与内核之间建立了什么

课堂代码：

fd=socket();

socket 的英文含义是插座。可以用“插头和插座”帮助理解应用层 fd 与内核 socket 对象的关系：

应用层
 fd：应用程序使用的整数句柄
 ↓
内核
 socket/TCP相关对象：保存协议、地址、状态、缓冲区等

socket() 成功后主要完成两类事情。

4.1 分配 fd

fd 是当前进程文件描述符表中的一个位置。内核找到可用位置，将它标记为正在使用，然后返回对应整数。

进程fd表
0 → 标准输入
1 → 标准输出
2 → 标准错误
3 → 新创建的socket

调用 close(fd) 后，该 fd 位置会被释放，之后可能被其他文件或 socket 再次使用。

4.2 创建并关联内核 socket 状态

应用程序用 fd 查找内核中的 socket 对象。TCP 相关对象会逐步保存：

本地IP
本地端口
远端IP
远端端口
协议类型
TCP状态
发送缓冲区
接收缓冲区
序号和确认号
窗口及重传信息

课堂中把这组 TCP 连接状态概括为 TCB（Transmission Control Block，传输控制块）。

五元组是：

源IP
源端口
目的IP
目的端口
传输层协议

例如：

192.168.1.10:52000
 → 192.168.1.20:2000
 → TCP

同一个服务端端口可以同时拥有大量连接，因为每条连接的五元组不同。

五、bind()：把本地地址写入 socket

课堂代码：

bind(fd,);

bind() 的作用是给 socket 指定本地 IP 和本地端口：

通过fd找到内核socket对象
 ↓
设置本地IP
 ↓
设置本地端口

服务端必须有稳定的监听地址，所以通常显式绑定：

0.0.0.0:2000

客户端通常直接调用 connect()；如果之前没有 bind()，内核会自动选择本地地址和临时端口。

六、listen()：让 socket 进入监听状态

课堂代码：

listen(fd,backlog);

listen() 将 socket 变成监听 socket：

普通TCP socket
 ↓ listen()
LISTEN状态

如果服务端只完成 bind() 而没有 listen()，对应端口没有处于 TCP 监听状态，客户端连接通常会被拒绝。

6.1 两类连接队列

监听 socket 的连接可以从两个阶段理解：

收到客户端SYN
 ↓
SYN队列：握手尚未完成
 ↓
收到第三次握手ACK
 ↓
已完成连接队列：等待应用accept()

常见名称：

SYN queue / 半连接队列
accept queue / 已完成连接队列

“半连接”不是只能传一半数据，而是三次握手还没有完成。

6.2 backlog

现代 Linux 中，listen(fd, backlog) 的 backlog 主要限制等待 accept() 的已完成连接队列长度：

listen(fd,backlog);

可以理解成：

应用程序暂时没来得及 accept 时，内核允许多少条已经建立完成的连接排队等待。

SYN 队列还有独立内核配置：

cat /proc/sys/net/ipv4/tcp_max_syn_backlog

实际队列长度还受内核上限、系统配置和 SYN cookies 等机制影响。

七、TCP 三次握手

三次握手由内核 TCP 协议栈完成。应用程序通过 connect() 发起；服务端 listen() 后由内核接收握手；accept() 取出的是已经完成握手的连接。

假设双方初始序号分别是：

客户端初始序号：1234
服务端初始序号：5647

7.1 第一次：客户端发送 SYN

client → server

SYN = 1
SEQ = 1234

含义：

客户端希望建立连接，自己的初始发送序号从 1234 开始。

客户端状态：

CLOSED → SYN_SENT

SYN 会占用一个序号，所以服务端确认时使用 1234 + 1。

7.2 第二次：服务端返回 SYN + ACK

server → client

SYN = 1
ACK = 1
SEQ = 5647
ACK number = 1235

ACK number = 1235 表示客户端序号 1234 的 SYN 已经收到，下一次期望从 1235 开始。

同时，服务端告诉客户端自己的初始发送序号是 5647。

服务端相关连接状态：

LISTEN → SYN_RECEIVED

7.3 第三次：客户端返回 ACK

client → server

ACK = 1
ACK number = 5648

5648 = 5647 + 1，表示服务端的 SYN 已经收到。随后双方进入：

ESTABLISHED

完整过程：

客户端 服务端

SYN, SEQ=1234
 ───────────────────────────────→

 SYN+ACK,
 SEQ=5647, ACK=1235
 ←───────────────────────────────

ACK, ACK=5648
 ───────────────────────────────→

双方进入ESTABLISHED

7.4 为什么要交换序号

双方分别告诉对方自己的初始序号，后续 TCP 才能利用序号和确认号实现：

识别数据顺序
发现数据缺失
排除重复数据
确认已经收到的字节范围
进行超时重传

初始序号不是固定从 0 开始，而是由内核生成。这样可以减少旧连接延迟报文的干扰，也提高序号的不可预测性。

八、connect()、握手和 accept() 的关系

客户端：

connect();

connect() 让内核发起 TCP 三次握手。阻塞 socket 上，connect() 通常要等待连接成功或失败后才返回，因此服务端不可达时可能等待较长时间。

服务端：

listen();
accept();

三次握手不是由 accept() 执行的。握手由服务端内核协议栈在监听状态下完成：

内核完成三次握手
 ↓
连接进入已完成连接队列
 ↓
listenfd出现可读事件
 ↓
应用调用accept()

accept() 主要完成：

从已完成连接队列取出一条连接
 ↓
为它分配新的clientfd
 ↓
让clientfd关联这条已连接socket

因此：

listenfd → 继续监听新连接
clientfd → 与某个客户端收发数据

8.1 Reactor 中的对应关系

listenfd出现EPOLLIN
 ↓
accept_cb()
 ↓
accept()
 ↓
得到clientfd
 ↓
把clientfd注册到epoll

LT 下，如果队列中还有连接，监听 fd 会继续报告可读。

ET 下应循环 accept()，直到当前队列已经取空。课堂代码：

while（1）{
fd =accept();
if(fd==-1){
break

}
}

这段代码表达的核心是：

一次EPOLLIN通知
 ↓
连续accept
 ↓
把当前已经完成的连接全部取出

实际使用非阻塞 fd 时，accept() 返回 -1 且 errno 为 EAGAIN/EWOULDBLOCK，表示本轮队列已经取空。

九、SYN 队列如何匹配第三次握手

收到第三次握手报文后，内核需要找到它属于哪一条正在建立的连接。

IP 头和 TCP 头能够提供：

源IP
目的IP
源端口
目的端口
协议类型TCP

内核结合五元组、序号和连接状态查找对应的半连接状态，验证 ACK 后，将连接推进到已建立状态并放入已完成连接队列。

连接状态的生命周期不是从 accept() 才开始。服务端收到 SYN 后，内核已经需要保存握手状态；accept() 只是把完成后的连接交给应用程序。

十、SYN Flood

SYN Flood 的基本过程：

攻击者发送大量SYN
 ↓
服务端为握手保存状态
 ↓
攻击者不完成第三次握手
 ↓
半连接状态和相关资源被持续占用

常见防护包括：

SYN cookies。
调整 SYN 队列和重试参数。
防火墙、负载均衡器和云安全组。
限速和异常源识别。
DDoS 清洗服务。

listen() 的 backlog 主要用于已完成连接队列，不能单独解决 SYN Flood。

十一、send() 和 recv() 到底做了什么

课堂中的数据路径：

发送方application
 ↓ send/write
发送方kernel TCP协议栈
 ↓
网络
 ↓
接收方kernel TCP协议栈
 ↓ recv/read
接收方application

11.1 send()

课堂例子：

send（fd,buffer,100,0）;
send（fd,buffer,200,0）;
send（fd,buffer,400,0）;

send() 返回正数，表示本次有多少字节被内核 socket 发送路径接受。它不表示对端应用已经读取这些数据。

后续什么时候组成 TCP 段、什么时候交给 IP 层、何时重传，由内核协议栈处理。

TCP 是字节流，不保留应用层每次 send() 的边界。上面三次调用总共交给 TCP 700 字节，接收端不一定按照 100、200、400 三次收到。

11.2 recv()

课堂例子：

recv（fd，buffer，50,0）
recv（fd，buffer，250,0）
recv（fd，buffer，250,0）
recv（fd，buffer，150,0）

接收端可以按照 50 + 250 + 250 + 150 取出相同的 700 字节。

recv() 把已经到达 socket 接收缓冲区的数据复制到应用层 buffer。一次返回多少字节取决于：

当前已经到达多少数据
应用提供的buffer有多大
socket是否阻塞
协议栈和调度时机

因此：

发送端三次send
不等于
接收端必须三次recv

这也是 TCP 半包、粘包问题的来源。应用层协议需要自己定义消息边界，例如固定长度、长度字段或分隔符。

11.3 一次接收 1000 与十次接收 100

课堂对比：

recv（fd,buffer,1000,0）;

与：

recv（fd,buffer,100,0）;
// 循环10次

复制总数据量可以相同，但十次 recv() 会产生更多系统调用、循环判断和状态处理开销，因此性能并非完全没有差异。

实际代码应以协议完整性和程序结构为主，选择合理缓冲区大小，不必把每次读取切得非常小。

十二、MTU、MSS 与 TCP 分段

MTU 是链路能够承载的最大 IP 包大小。常见以太网 MTU 是 1500 字节，但它包含 IP 头，不等于 TCP 应用数据长度。

TCP 常用 MSS 表示一个 TCP 段最多携带的 payload 大小：

MSS ≈ MTU - IP头 - TCP头

常见 IPv4、无额外选项时：

1500 - 20 - 20 = 1460字节

课堂例子：

send（fd,buffer,1700,0）;

应用一次交给内核 1700 字节，不代表网络上一定只有一个包。协议栈会根据 MSS、网卡卸载、路径 MTU 等条件分段。

接收端 recv() 的边界与网络分段也没有一一对应关系。网络上传输多个 TCP 段，接收端可能一次取出合并后的数据，也可能分多次取出。

十三、TCP 如何可靠并尽量快速地传输

这些机制主要运行在两端内核 TCP 协议栈之间，不由应用程序逐包控制。

13.1 序号与确认号

SEQ → 当前报文携带的数据从哪个字节序号开始
ACK → 下一次期望收到哪个字节序号

如果 ACK number = 1235，可以理解为序号 1235 之前的数据已经连续收到，下一次希望从 1235 开始。

13.2 接收窗口与滑动窗口

接收方通过窗口告诉发送方：

当前接收缓冲区还允许接收多少数据。

发送方可以在没有逐段等待 ACK 的情况下发送窗口范围内的多段数据。ACK 推进后，允许发送的范围继续向前滑动。

它解决：

既要连续发送提高吞吐
又不能超过接收方处理能力

13.3 慢启动

连接开始时，发送方不知道网络能承受多少在途数据，因此从较小的拥塞窗口开始。在慢启动阶段，拥塞窗口按每个 RTT 观察通常接近指数增长。

13.4 拥塞避免

拥塞窗口达到阈值后，增长转为更平缓的方式。检测到丢包或拥塞信号后，具体如何降低窗口取决于拥塞控制算法和丢包检测方式，不能把所有情况都理解为固定“减半重新开始”。

13.5 延迟确认

接收方可以短暂等待，把 ACK 与反向数据一起发送，或者用一个 ACK 确认更多数据，以减少纯 ACK 包数量。

延迟时间由协议实现和当前状态决定，不是所有系统都固定延迟 200 ms。

13.6 超时重传与快速重传

发送方在规定时间内没有收到确认，会认为数据可能丢失并触发重传。连续收到重复 ACK 时，也可能在超时前触发快速重传。

这些机制共同实现：

可靠传输
按序交付
避免重复
适应接收端能力
适应网络拥塞程度

十四、close() 与四次挥手

课堂代码：

close(fd);

close() 首先是通用的 fd 关闭接口。对 TCP socket 来说，当最后一个引用被关闭时，内核会根据 socket 状态和配置推进 TCP 关闭过程。

TCP 关闭使用 FIN 标志，不是 final。

14.1 为什么通常是四次

TCP 是全双工连接，两个方向需要分别关闭：

主动关闭方 被动关闭方

FIN
 ───────────────────────────────→

 ACK
 ←───────────────────────────────

 FIN
 ←───────────────────────────────

ACK
 ───────────────────────────────→

过程：

1. 主动方发送FIN：我没有更多数据要发送
2. 被动方返回ACK：我知道你不再发送
3. 被动方处理完自己的发送后，也发送FIN
4. 主动方返回ACK：确认对方也不再发送

第二步和第三步有时会合并在同一个报文中，所以抓包时不一定总能机械地看到四个独立数据包。

14.2 主动关闭方状态

ESTABLISHED
 ↓ close()，发送FIN
FIN_WAIT_1
 ↓ 收到对方对FIN的ACK
FIN_WAIT_2
 ↓ 收到对方FIN，返回ACK
TIME_WAIT
 ↓ 等待2MSL
CLOSED

14.3 被动关闭方状态

ESTABLISHED
 ↓ 收到FIN，返回ACK
CLOSE_WAIT
 ↓ 本地应用调用close()，发送FIN
LAST_ACK
 ↓ 收到对方ACK
CLOSED

14.4 为什么 recv() 返回 0

被动方收到 FIN 后，如果此前还有已到达的数据，应用应先读出这些数据。全部读完以后，再次调用：

recv(fd,buffer,size,0);

会返回：

它表示对方正常关闭了发送方向，后面不会再有数据。非阻塞 socket 暂时没有数据返回的是 -1/EAGAIN，不是 0。

14.5 数据与 FIN

应用先调用：

send（fd,buffer,100,0）

随后调用：

close(fd);

TCP 会保持字节流顺序：内核已经接受的待发送数据排在 FIN 之前。接收端先读到数据，数据全部读完后才观察到 EOF，即 recv() == 0。

14.6 shutdown()

shutdown() 可以只关闭 TCP 的一个方向：

SHUT_RD → 关闭读方向
SHUT_WR → 关闭写方向，向对端发送FIN
SHUT_RDWR → 关闭读写方向

它适合“我已经发送完，但还要继续接收对方响应”的半关闭协议。普通请求响应程序只使用 close() 也很常见，但 shutdown() 并不是没有用途。

十五、TIME_WAIT、CLOSING 与同时关闭

15.1 TIME_WAIT

通常由最终发送 ACK 的主动关闭方进入 TIME_WAIT。作用：

如果最后一个ACK丢失，可以重新确认对方重发的FIN
让旧连接的延迟报文在网络中消失

服务端出现大量 TIME_WAIT，通常说明服务端经常主动关闭连接，不等于双方一定同时调用了 close()。

15.2 同时关闭

如果双方几乎同时调用 close()：

双方都发送FIN
 ↓
双方都可能在FIN_WAIT_1时收到对方FIN
 ↓
进入CLOSING
 ↓
收到自己FIN对应的ACK
 ↓
进入TIME_WAIT

简化状态：

ESTABLISHED
 ↓ 本地发送FIN
FIN_WAIT_1
 ↓ 先收到对端FIN
CLOSING
 ↓ 收到ACK
TIME_WAIT

如果主动方先收到 ACK，再收到 FIN，则通常经过：

FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT

TCP 状态机用于处理这些不同的报文到达顺序。

十六、同时打开与 TCP P2P

常规应用使用客户端/服务端角色：

客户端调用connect()
服务端调用listen()/accept()

但 TCP 建立后，双方都是全双工通信端点。客户端和服务端主要描述谁主动连接、谁被动监听，以及应用协议中的角色。

TCP 还定义了“同时打开”：双方都主动发送 SYN，并在 SYN_SENT 状态收到对方 SYN。

双方CLOSED
 ↓ 同时主动打开
双方SYN_SENT
 ↓ 收到对方SYN并返回SYN+ACK
双方SYN_RECEIVED
 ↓ 收到ACK
双方ESTABLISHED

课堂中的 P2P 方向：

fd=socket（）
bind（）//optional
connect（）；

真正跨公网实现 P2P 还需要考虑 NAT、端口映射、防火墙和连接协调。单纯同时调用 connect() 不保证一定能穿透网络设备。

本节需要理解：

TCP 建立后没有“只能客户端发、只能服务端收”的限制，双方都可以 send 和 recv。

十七、把 API 与 TCP 状态对应起来

应用调用或事件	内核中的主要含义
socket()	创建 fd 和 socket 相关内核对象
bind()	设置本地 IP 和端口
listen()	进入 LISTEN，准备接收连接
connect()	主动发起三次握手
收到 SYN	创建或查找握手状态，进入 SYN_RECEIVED
握手完成	连接进入 ESTABLISHED，并等待 accept
accept()	从已完成连接队列取出连接，返回 clientfd
send()	把应用字节交给 socket 发送路径
recv()	把 socket 接收数据复制到应用缓冲区
收到 FIN	对端关闭发送方向，最终让 recv 返回 0
close()	释放 fd 引用，并推动 TCP 关闭过程

完整主线：

socket()
 ↓
bind()
 ↓
listen() / connect()
 ↓
三次握手
 ↓
accept()得到clientfd
 ↓
send()/recv()
 ↓
序号、确认、窗口、拥塞控制、重传
 ↓
close()
 ↓
FIN/ACK与四次挥手
 ↓
TIME_WAIT或CLOSED

十八、本节课需要真正掌握的内容

重点一：API 是入口，协议栈完成真正的 TCP 工作

connect()不是应用自己发送三个包
accept()不负责执行三次握手
send()不等于对端应用已经收到
recv()不对应某一次send()
close()会推动TCP关闭状态机

重点二：监听 fd 和客户端 fd 对应不同状态

listenfd
 → LISTEN状态
 → 管理握手和等待accept的连接

clientfd
 → 对应某条已建立TCP连接
 → 用于send和recv

重点三：TCP 是可靠字节流

没有应用消息边界
使用序号和ACK保证顺序与可靠性
使用接收窗口进行流量控制
使用拥塞窗口适应网络承载能力
使用重传恢复丢失数据

重点四：建立和关闭都是状态机

三次握手：
CLOSED → SYN_SENT/SYN_RECEIVED → ESTABLISHED

主动关闭：
ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT

被动关闭：
ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED

课后实践

准备两台虚拟机，观察 TCP P2P：

1. 双方创建TCP socket
2. 根据实验设计绑定本地地址
3. 协调双方连接时机
4. 抓包观察SYN、SYN+ACK、ACK
5. 建立后让双方都执行send和recv
6. 同时或分别close，观察TCP状态

可以配合：

ss -ant
tcpdump -nn -i any tcp

网络 I/O 与 I/O 多路复用

Thu, 06 Aug 2026 00:00:00 +0800

一、网络 I/O 的使用场景

网络是后端服务开发中的重要环节。生活中大量功能都依赖客户端与服务端之间的网络通信。

1. 微信发送文字、语音和视频

当用户在微信发送消息时，大致过程是：

发送方微信
 ↓
通过网络将数据发送给微信服务器
 ↓
服务器找到接收方
 ↓
将数据转发给接收方微信

文字、语音、图片、视频在网络上传输时，最终都会被转换成字节数据。

网络 I/O 主要关心：

数据从哪里读取
数据向哪里发送
读取了多少字节
发送了多少字节

网络 I/O 本身并不关心这些字节具体表示文字、图片还是视频。

2. 刷抖音

刷视频时：

抖音 App 请求视频
 ↓
服务器返回视频信息和资源地址
 ↓
App 通过网络下载视频数据
 ↓
客户端解码并播放

通常视频会被切分成多个数据块，App 可以一边下载、一边播放。

3. 使用 `git clone`

执行：

git clone 仓库地址

大致过程是：

本地 Git 客户端连接 GitHub
 ↓
向 GitHub 请求仓库数据
 ↓
GitHub 通过网络发送 Git 对象
 ↓
本地接收、校验和解压
 ↓
形成本地仓库

代码能够到达本地，本质上也是客户端和 GitHub 服务端之间进行了网络 I/O。

这些场景都可以概括成：

客户端发起请求 → 服务端处理请求 → 服务端返回响应

二、什么是网络 I/O

网络 I/O 是建立在客户端和服务端之间的数据传输过程，类似二者之间连接的网络管道。例如十个客户端分别连接服务器，服务端通常会获得十个连接 fd：

客户端 A ←→ fd 4
客户端 B ←→ fd 5
客户端 C ←→ fd 6
...
客户端 J ←→ fd 13

随着客户端数量增加，fd 数量也会增加，于是就产生了一个重要问题：

服务端如何同时管理大量 fd？

这正是后面需要学习 select、poll 和 epoll 的原因。

三、socket 与 fd

在 Linux 中，Linux 通过 socket API 通信。创建 socket：

int sockfd = socket(AF_INET, SOCK_STREAM, 0);

参数的含义：

AF_INET：IPv4
SOCK_STREAM：面向字节流，对应 TCP
0：使用该组合默认的 TCP 协议

fd 本质是进程中的非负整数（此处了解，记忆也没啥用）：

0：标准输入
1：标准输出
2：标准错误
3：监听 socket
4：客户端连接 A
5：客户端连接 B

在当前服务端进程中，一个已连接 socket 的 fd 通常对应一条 TCP 连接。（存在 ACCEPT 的情况）

四、TCP 服务端的简便理解

可以把 TCP 服务端理解成酒店：

socket()：聘请迎宾员
bind()：安排迎宾员在哪个门口工作
listen()：正式开始迎宾
accept()：接待一位到达的客人
recv()：听客人提出需求
send()：将处理结果交给客人
close()：结束服务

说说两类重要 fd：

1. 监听 fd

定义完 sockfd 经过 bind、listen 后，sockfd 就成为监听 fd。主要职责是监听新连接，不负责收发数据。

2. 连接 fd

参考代码中的 int clientfd = accept(sockfd, ...);。accept() 成功后会返回一个新的 fd：

sockfd：负责监听新客户端
clientfd：负责和某个客户端通信

关系如下：

 ┌→ clientfd 4 ←→ 客户端 A
listenfd → accept() ─┼→ clientfd 5 ←→ 客户端 B
 └→ clientfd 6 ←→ 客户端 C

监听 fd 通常只有一个，但每建立一个客户端连接，服务端就会获得一个新的连接 fd。

五、服务端代码执行流程

1. 创建 socket

int sockfd = socket(AF_INET, SOCK_STREAM, 0);

作用：

在内核中创建 socket 对象。
返回一个 fd。
当前还没有绑定 IP 和端口。
当前也没有开始监听。

更准确的变量名可以理解为：

int listenfd;

因为它后面会被设置为监听 socket。

2. 准备服务器地址

struct sockaddr_in servaddr;

servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
servaddr.sin_port = htons(2000);

`sin_family`

servaddr.sin_family = AF_INET;

表示使用 IPv4。

`INADDR_ANY`

servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

INADDR_ANY 表示监听本机所有 IPv4 网络接口，对应：

0.0.0.0

假设服务器有多个 IP：

127.0.0.1
192.168.1.10
10.0.0.10

绑定 0.0.0.0，表示这些本机地址上的 2000 端口都可以接收连接。

`htons()`

servaddr.sin_port = htons(2000);

htons 表示：

host to network short

它把主机字节序的 16 位端口号转换成网络字节序。

同理：

htonl

表示把 32 位数据从主机字节序转换成网络字节序。

端口范围是：

0～65535

通常：

0：让操作系统自动分配端口。
1～1023：传统意义上的特权端口。
1024～65535：普通程序通常可以使用。

但 1024 以上的端口也可能已经被其他程序占用。

3. 绑定 IP 和端口

bind(sockfd,
 (struct sockaddr *)&servaddr,
 sizeof(struct sockaddr));

bind() 将 socket 与本地 IP、端口建立联系：

sockfd ←→ 0.0.0.0:2000

可以理解为：

给迎宾人员安排具体的工作地点。

如果端口已经被其他服务绑定，可能出现：

Address already in use

你的代码通过下面的方式查看错误：

printf("bind error:%s\n", strerror(errno));

不过如果 bind() 失败，程序理论上不应该继续执行 listen()。

4. 进入监听状态

listen(sockfd, 10);

执行成功后，socket 从普通 socket 变成监听 socket。

此时可以使用：

ss -lntp | grep ':2000'

查看监听状态。

可能看到：

LISTEN 0 10 0.0.0.0:2000

5. 接收客户端连接

int clientfd = accept(
 sockfd,
 (struct sockaddr *)&clientaddr,
 &len
);

如果当前没有已经建立完成的客户端连接，阻塞模式下的 accept() 会暂停程序：

程序阻塞在 accept()
 ↓
等待客户端连接
 ↓
客户端完成 TCP 三次握手
 ↓
accept() 返回 clientfd

accept() 不会把原来的 sockfd 变成客户端连接。

它会返回一个全新的 clientfd。

六、代码中的三个服务端版本（代码文末附）

第一阶段：只处理一个客户端的一次数据

#if 0
 int clientfd = accept(...);

 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0);

 printf("RECV:%s\n", buffer);

 count = send(clientfd, buffer, count, 0);
#endif

执行过程：

accept 一个客户端
 ↓
recv 一次
 ↓
send 一次
 ↓
后面不再 accept

这个版本只能：

接收一个客户端。
读取一次数据。
返回一次数据。

如果客户端想再次发送，服务端没有循环继续读取。

第二阶段：循环接收客户端，但串行处理

#elif 0
while (1) {
 int clientfd = accept(...);

 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0);

 printf("RECV:%s\n", buffer);

 count = send(clientfd, buffer, count, 0);
}
#endif

这里增加了：

while (1)

因此服务端可以不断接收新客户端。

但是它仍然是串行处理：

accept 客户端 A
 ↓
recv 等待 A 发送数据
 ↓
send 返回给 A
 ↓
重新 accept 客户端 B

关键问题在这里：

recv(clientfd, buffer, 1024, 0);

默认情况下，recv() 是阻塞的。

假设客户端 A 已经连接，但一直没有发送数据：

服务端阻塞在 A 的 recv()

此时即使客户端 B 已经发起连接，应用程序也暂时无法回到 accept() 处理 B。

第三阶段：一个客户端对应一个线程

当前实际编译的是 #else：

#else
while (1) {
 int clientfd = accept(...);

 pthread_t thid;
 pthread_create(
 &thid,
 NULL,
 client_thread,
 &clientfd
 );
}
#endif

每接收一个客户端，创建一个线程。

线程函数：

void *client_thread(void *arg)
{
 int clientfd = *(int *)arg;

 while (1) {
 char buffer[1024] = {0};

 int count = recv(
 clientfd,
 buffer,
 1024,
 0
 );

 printf("RECV:%s\n", buffer);

 count = send(
 clientfd,
 buffer,
 count,
 0
 );
 }
}

运行关系变成：

主线程
 │
 ├─ accept 客户端 A
 │ └─ 创建线程 1 → recv(A)
 │
 ├─ accept 客户端 B
 │ └─ 创建线程 2 → recv(B)
 │
 └─ accept 客户端 C
 └─ 创建线程 3 → recv(C)

主线程只负责：

不断执行 accept()

工作线程负责：

recv() → 处理数据 → send()

这样即使线程 1 阻塞在客户端 A 的 recv()，主线程仍然可以继续 accept() 客户端 B。

准确来说，这是：

一个连接对应一个线程。

不是严格的”一次请求对应一个线程”，因为一个连接线程内部可以通过 while 处理多次请求。

七、对于阶段三一个连接一个线程的问题

这种模型简单直观，但连接数量增大后会产生问题。

1. 线程需要内存

每创建一个线程，都需要线程栈及相关管理资源。连接越多，线程越多，百万并发的时候…

2. 上下文切换成本

CPU 核心数量有限。

假设服务器只有 8 个 CPU 核心，却创建了 5000 个线程，操作系统必须不停地：

保存线程 A 的状态
切换到线程 B
保存线程 B 的状态
切换到线程 C

线程太多时，大量 CPU 时间可能消耗在线程调度上。

3. 大部分线程可能只是在等待

很多网络连接并不是一直都有数据。

例如即时通信中的长连接：

客户端保持在线
但大部分时间没有发送消息

对应线程会长期阻塞在：

recv(clientfd, ...);

如果一个空闲连接占用一个线程，就会浪费大量线程资源。

代码

#include <stdio.h> // printf
#include <string.h> // memset
#include <sys/socket.h>
#include <arpa/inet.h> // htonl, htons
#include <errno.h> // errno
#include <netinet/in.h> // struct sockaddr_in
#include <unistd.h> // close
#include <pthread.h>

void *client_thread(void *arg) {
 int clientfd = *(int *)arg;
 while (1) {
 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0); // 全部阻塞在 recv 上
 printf("RECV:%s\n", buffer);
 count = send(clientfd, buffer, count, 0);
 printf("SEND:%s\n", count);
 }
}

int main() {
 int sockfd = socket(AF_INET, SOCK_STREAM, 0); // create socket 聘请迎宾者
 // 绑定本地端口
 struct sockaddr_in servaddr;
 servaddr.sin_family = AF_INET;
 servaddr.sin_addr.s_addr = htonl(INADDR_ANY); // 0.0.0.0
 servaddr.sin_port = htons(2000); // 0-1023 系统默认，1024 之后都可以用，不能与其他的冲突
 // 在哪个门迎宾，安排的位置
 if (-1 == bind(sockfd, (struct sockaddr *)&servaddr, sizeof(struct sockaddr))) {
 printf("bind error:%s\n", strerror(errno));
 }
 // 登记绑定
 listen(sockfd, 10); // 正式上榜
 printf("listen finished\n");
 struct sockaddr_in clientaddr;
 socklen_t len = sizeof(clientaddr);
#if 0
 printf("accept\n");
 int clientfd = accept(sockfd, (struct sockaddr *)&clientaddr, &len); // 建立链接
 printf("accept finished\n");
 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0);
 printf("RECV:%s\n", buffer);
 count = send(clientfd, buffer, count, 0);
 printf("SEND:%s\n", count);
#elif 0
 while (1) {
 printf("accept\n");
 int clientfd = accept(sockfd, (struct sockaddr *)&clientaddr, &len); // 建立链接
 printf("accept finished\n");
 char buffer[1024] = {0};
 int count = recv(clientfd, buffer, 1024, 0); // 全部阻塞在 recv 上
 printf("RECV:%s\n", buffer);
 count = send(clientfd, buffer, count, 0);
 printf("SEND:%s\n", count);
 } // 多个 io 如何接收数据
#else
 while (1) {
 printf("accept\n");
 int clientfd = accept(sockfd, (struct sockaddr *)&clientaddr, &len); // 建立链接
 printf("accept finished\n");
 pthread_t thid;
 pthread_create(&thid, NULL, client_thread, &clientfd);
 }
#endif
 getchar();
 printf("exit\n");
 return 0;
}

Socket on JasperSao的博客

POSIX API 与 TCP 连接生命周期

一、为什么网络代码可以跨 Linux、Unix 和 macOS

二、客户端和服务端使用的 API

2.1 TCP 客户端

2.2 TCP 服务端

三、一次 TCP 连接的三个阶段

四、socket() 在应用层与内核之间建立了什么

4.1 分配 fd

4.2 创建并关联内核 socket 状态

五、bind()：把本地地址写入 socket

六、listen()：让 socket 进入监听状态

6.1 两类连接队列

6.2 backlog

七、TCP 三次握手

7.1 第一次：客户端发送 SYN

7.2 第二次：服务端返回 SYN + ACK

7.3 第三次：客户端返回 ACK

7.4 为什么要交换序号

八、connect()、握手和 accept() 的关系

8.1 Reactor 中的对应关系

九、SYN 队列如何匹配第三次握手

十、SYN Flood

十一、send() 和 recv() 到底做了什么

11.1 send()

11.2 recv()

11.3 一次接收 1000 与十次接收 100

十二、MTU、MSS 与 TCP 分段

十三、TCP 如何可靠并尽量快速地传输

13.1 序号与确认号

13.2 接收窗口与滑动窗口

13.3 慢启动

13.4 拥塞避免

13.5 延迟确认

13.6 超时重传与快速重传

十四、close() 与四次挥手

14.1 为什么通常是四次

14.2 主动关闭方状态

14.3 被动关闭方状态

14.4 为什么 recv() 返回 0

14.5 数据与 FIN

14.6 shutdown()

十五、TIME_WAIT、CLOSING 与同时关闭

15.1 TIME_WAIT

15.2 同时关闭

十六、同时打开与 TCP P2P

十七、把 API 与 TCP 状态对应起来

十八、本节课需要真正掌握的内容

重点一：API 是入口，协议栈完成真正的 TCP 工作

重点二：监听 fd 和客户端 fd 对应不同状态

重点三：TCP 是可靠字节流

重点四：建立和关闭都是状态机

课后实践

网络 I/O 与 I/O 多路复用

一、网络 I/O 的使用场景

1. 微信发送文字、语音和视频

2. 刷抖音

3. 使用 git clone

二、什么是网络 I/O

三、socket 与 fd

四、TCP 服务端的简便理解

五、服务端代码执行流程

1. 创建 socket

2. 准备服务器地址

sin_family

INADDR_ANY

htons()

3. 绑定 IP 和端口

4. 进入监听状态

5. 接收客户端连接

六、代码中的三个服务端版本（代码文末附）

第一阶段：只处理一个客户端的一次数据

第二阶段：循环接收客户端，但串行处理

第三阶段：一个客户端对应一个线程

七、对于阶段三一个连接一个线程的问题

1. 线程需要内存

2. 上下文切换成本

3. 大部分线程可能只是在等待

代码

3. 使用 `git clone`

`sin_family`

`INADDR_ANY`

`htons()`