Mac OSX 10.9 监听积压工作不正常

Question

我最近一直在处理一些服务器-客户端代码，我发现了一个非常令人困惑的问题。我有一个server 监听端口并设置backlog = 2，而我的客户端创建5个线程到connect。

在man，我注意到了

The backlog parameter defines the maximum length for the queue of pending
 connections.  If a connection request arrives with the queue full, the
 client may receive an error with an indication of ECONNREFUSED.  Alterna-
 tively, if the underlying protocol supports retransmission, the request
 may be ignored so that retries may succeed.

这意味着我的客户端连接将失败或稍后重试。

但是当我的客户端运行时，它只是收到一个 SIGPIPE 信号并失败了。

所以我运行sudo tcpdump -ilo0 port 10000 并得到结果：

summertekiMacBook-Pro:select summer$ sudo tcpdump -ilo0 端口 10000

tcpdump：详细输出被抑制，使用 -v 或 -vv 进行全协议解码监听 lo0，链接类型 NULL（BSD 环回），捕获大小 65535 字节

10:29:16.396240 IP localhost.56347 > localhost.ndmp: 标志 [S], seq 3366561899, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK, eol]，长度为0

10:29:16.396241 IP localhost.56349 > localhost.ndmp: 标志 [S], seq 902832276, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK, eol]，长度为0

10:29:16.396242 IP localhost.56351 > localhost.ndmp: 标志 [S], seq 1956535575, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK, eol]，长度为0

10:29:16.396244 IP localhost.56348 > localhost.ndmp: 标志 [S], seq 2161003109, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK, eol]，长度为0

10:29:16.396246 IP localhost.56350 > localhost.ndmp: 标志 [S], seq 1318035540, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK, eol]，长度为0

10:29:16.396296 IP localhost.ndmp > localhost.56347: 标志 [S.], seq 2871094527, ack 3366561900, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158772,sackOK,eol],长度0

10:29:16.396307 IP localhost.ndmp > localhost.56351: 标志 [S.], seq 3931313020, ack 1956535576, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158772,sackOK,eol],长度0

10:29:16.396332 IP localhost.ndmp > localhost.56349: 标志 [S.], seq 3467781056, ack 902832277, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158772,sackOK,eol],长度0

10:29:16.396349 IP localhost.ndmp > localhost.56348: 标志 [S.], seq 2666080832, ack 2161003110, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158772,sackOK,eol],长度0

10:29:16.396366 IP localhost.ndmp > localhost.56350: 标志 [S.], seq 2467582351, ack 1318035541, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158772,sackOK,eol],长度0

10:29:16.396375 IP localhost.56347 > localhost.ndmp: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396381 IP localhost.56351 > localhost.ndmp: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396386 IP localhost.56349 > localhost.ndmp: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396391 IP localhost.56348 > localhost.ndmp: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396398 IP localhost.56350 > localhost.ndmp: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396408 IP localhost.ndmp > localhost.56347: 标志 [R], seq 2871094528, win 0, length 0

10:29:16.396413 IP localhost.ndmp > localhost.56351: 标志 [R], seq 3931313021, win 0, length 0

10:29:16.396419 IP localhost.56347 > localhost.ndmp: 标志 [P.], seq 1:1001, ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 1000

10:29:16.396424 IP localhost.56351 > localhost.ndmp: 标志 [P.], seq 1:1001, ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 1000

10:29:16.396429 IP localhost.ndmp > localhost.56349: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0 10:29:16.396435 IP localhost.ndmp > localhost.56348: Flags [R], seq 2666080833, win 0, length 0

10:29:16.396441 IP localhost.ndmp > localhost.56350: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396454 IP localhost.ndmp > localhost.56347: 标志 [R], seq 2871094528, win 0, length 0

10:29:16.396460 IP localhost.ndmp > localhost.56351: 标志 [R], seq 3931313021, win 0, length 0

从 unix 网络编程，connect() 将启动 3 次握手程序，并在服务器发送 syn && ack 时返回。

从tcpdump 输出，前 10 行告诉服务器回复 syn & sck 虽然 backlog 为 2。后来，客户端发送 last-time ack 和服务器 先返回。

在我看来，连接返回值 != -1 表示连接已建立并且客户端能够发送数据。但是上面的日志显示它不是那样工作的。

那么谁能告诉我哪个正确？

Answer 1

最后，在花时间谷歌搜索之后，我得到了对上面显示的行为的解释。

我检查了linux manual，它显示：

注意事项

在 Linux 2.2 中，TCP 套接字上的 backlog 参数的行为发生了变化。现在它为完全建立的等待被接受的套接字指定队列长度，而不是不完整连接的数量要求。可以使用 /proc/sys/net/ipv4/tcp_max_syn_backlog 设置不完整套接字队列的最大长度。当 syncookies 被启用时，没有逻辑上的最大长度并且这个设置被忽略。有关详细信息，请参阅 tcp(7)。

另外，freebsd manual（osx's manual 没有提供任何细节，但是因为两个操作系统都是基于 bsd ^.^）：

请注意，在 FreeBSD 4.5 和 同步缓存的引入 之前， backlog 参数也决定了不完整连接的长度 queue，在完成 TCP 的 3-way 的过程中持有 TCP 套接字 握手。这些不完整的连接现在完全在 syncache，它不受队列长度的影响。夸大的积压值 不再需要帮助处理拒绝服务攻击。

总之，改变积压行为的原因似乎是为了保护服务免受syn flood攻击。

Answer 2

当您尝试在损坏/关闭的管道上发送数据时，您会收到一个 SIGPIPE 信号。 根据您的 tcpdump 数据和您的解释：

• 从 5 个不同的客户端端口 (56347-56351) 正确建立了所有 5 个 TCP 连接（使用 3 次握手）。
• 然后服务器从端口 47 和 51 的连接中发送 Reset。这会破坏管道。
• 几乎同时数据从端口 47 和 51（在客户端）发送（[P]，推送）到服务器。当内核决定时，这些数据可能已经在套接字发送缓冲区中准备发送。稍后服务器再次使用 Reset [R] 响应，但这并没有改变任何内容。
• 实际上你的 tcpdump 中的最后 4 行并不影响这个解释。

connect 实际上在您的客户端程序中返回了 OK。我敢肯定，因为所有连接都已建立，3 次握手完成。问题是，在那之后您立即尝试发送数据，我敢打赌您会尝试在每个套接字中多次发送数据。我假设每个线程处理一个套接字。第二次或第三次（或更多）线程尝试在端口 56347 或 56351 的套接字上发送数据时，由于已从服务器接收到 RESET，因此管道中断，并且操作系统将向进程发送信号 SIGPIPE。

listen backlog 似乎在您的服务器上工作正常。似乎 3 个连接被正确处理，只有 2 个被拒绝。可能服务器处理第一个连接的速度足够快，可以为积压中的下一个 2 留出位置。最后两个未能成功，因为积压太小（2）。