Great question—this is one of those tricky OS-level socket behaviors that trips up a lot of folks! Let’s break down exactly what’s happening here:

1. 操作系统会强制缓冲区的最小值 #

大部分操作系统不允许你把套接字缓冲区设得这么小（1字节）。比如在Linux系统中，存在一个系统级的最小接收缓冲区配置项net.core.rmem_min，默认值是4096字节。当你尝试将SO_RCVBUF设为1时，内核会直接忽略这个请求，转而使用系统规定的最小值。这么做是因为极小的缓冲区会破坏TCP/IP的基础功能（比如处理报文分片、ACK确认等）。

2. SO_RCVBUF是“提示”而非严格限制 #

SO_RCVBUF选项更像是给内核的一个建议，而非必须执行的命令。操作系统会根据系统资源、网络状况以及自身内部策略，自行调整缓冲区大小。哪怕你设置的值高于最小值，内核也可能会将其向上取整到最近的页大小（通常是4KB或8KB）以提升效率。

3. TCP流控基于内核缓冲区，而非应用层设置 #

当你运行cat file.txt | nc -l 1489时，nc会以批量方式通过TCP发送数据。你的操作系统TCP栈会把传入的数据暂存在内核的套接字缓冲区中，直到应用层调用recv()读取。由于内核忽略了你设置的1字节请求，使用了更大的缓冲区，所以它能容纳远多于1字节的数据，之后才会通过TCP滑动窗口机制通知发送方暂停传输。

验证实际缓冲区大小 #

你可以通过getsockopt()查看内核实际使用的缓冲区大小，来验证这一点：

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1)
# 获取实际生效的缓冲区大小
actual_rcvbuf = sock.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF)
print(f"实际接收缓冲区大小: {actual_rcvbuf} 字节")

你几乎肯定会看到一个远大于1的值——大概率和你的操作系统最小缓冲区大小一致。

如果你真的想限制接收？ #

如果你的目标是按极小的粒度（比如1字节）处理数据，需要在应用层实现：调用recv(1)而非recv(1000)。但要注意，内核后台仍会缓存部分数据——你无法仅通过SO_RCVBUF完全绕过操作系统级的TCP缓冲。

内容的提问来源于stack exchange，提问作者Nik Konst