标签: tcp

我怀疑我的国家政府正在以某种方式销毁 TCP 连接上收到的 ACK 数据包。

当我尝试在 80 以外的端口上与外部主机建立 TCP 连接时，TCP 握手将不会成功。我捕获了 pcap 文件（gmail.pcap：http ://www.slingfile.com/file/aWXGLLFPwb ），我发现我的计算机在发送 TCP SYN 后会收到 ACK，但它不会回复 SYN ACK，而是发送一个 RST。

我检查了来自外部主机的 ACK 数据包，但它似乎完全合法。序列号和我知道的所有标志都是正确的。谁能告诉我为什么我的计算机（Linux 机器）会发送 RST 数据包？

如何找出在 Linux 上建立当前打开的 TCP 连接的时间？

我知道在这方面有很多 SE 问题，我相信在谈到这一点之前，我已经阅读了尽可能多的问题。

“服务器端TIME_WAIT”是指在服务器端启动其 close() 的服务器端套接字对的状态。

我经常看到这些听起来自相矛盾的陈述：

1. 服务器端TIME_WAIT是无害的
2. 你应该设计你的网络应用程序让客户端启动 close()，因此让客户端承担 TIME_WAIT

我发现这个矛盾的原因是因为TIME_WAIT在客户端可能是一个问题——客户端可能会耗尽可用端口，所以本质上，上面建议将负担转移TIME_WAIT到可能有问题的客户端，从服务器端，这不是问题。

客户端TIME_WAIT当然只是少数用例的问题。大多数客户端 - 服务器解决方案将涉及一台服务器和许多客户端，客户端通常不会处理足够大的连接量以至于不会成为问题，即使他们这样做，也有一些“理智”的建议（而不是SO_LINGER与0超时，或tcp_tw的sysctl插手）作战客户端TIME_WAIT通过避免创建连接过多过快。但这并不总是可行的，例如对于如下类的应用程序：

• 监控系统
• 负载生成器
• 代理

另一方面，我什至不明白服务器端TIME_WAIT有什么帮助。原因TIME_WAIT甚至存在，是因为它可以防止将陈旧的TCP片段注入它们不再属于的流中。对于客户端，TIME_WAIT它是通过简单地使无法创建与ip:port此陈旧连接可能具有的相同对的连接（使用的对被 锁定TIME_WAIT）来实现的。但是对于服务器端，这是无法阻止的，因为本地地址将具有接受端口，并且始终相同，并且服务器不能（AFAIK，我只有经验证明）仅仅因为传入的对等点将创建与套接字表中已存在的地址对相同的地址对。

我确实编写了一个程序，显示服务器端 TIME-WAIT 被忽略。此外，因为测试是在 127.0.0.1 上完成的，内核必须有一个特殊的位来告诉它它是服务器端还是客户端（否则元组将是相同的）。

来源：http : //pastebin.com/5PWjkjEf，在 Fedora 22 上测试，默认网络配置。

$ gcc -o rtest rtest.c -lpthread
$ ./rtest 44400 s # will do server-side close
Will initiate server close
... iterates …

当我使用 ssh 从 172.16.11.5 和 172.16.10.6 连接时，我有一个非对称双桥拓扑，如下所示，但由于 SynProxy 我无法连接。

                  -------
                  |     |
                  ---o--- 172.16.11.5
                     |
                     |
                -----o----- 172.16.11.6
                |         |
                |         | default gw 1.1.1.1
                |         |
     1.1.1.2/30 --o----o--- 2.2.2.2/30
                  |    |
                  |    |
                  |    | (enp10s0f0)
              ----o----o-----
              |             |
              |     XXX     |
              |             |
              |  br1   br0  | synproxy
              |             |
              ----o----o-----
                  |    |
                  |    |
                  |    |
     1.1.1.1/30 --o----o--- 2.2.2.1/30
                |         |
                |         | default gw 2.2.2.2
                |         |
                -----o----- 172.16.10.1
                     |
                     |
                  ---o--- 172.16.10.6
                  |     |
                  ------- …

我使用的是 CentOS 6.7 (Final) 系统，当我尝试以nc监听模式运行时，它会打印以下内容：

# nc -l 1234
nc: Protocol not available

端口未绑定。我也尝试了其他端口号。这个错误似乎已经被报告了：https : //access.redhat.com/solutions/1753753。不幸的是，它不是很详细。

包装信息：

Name        : nc
Arch        : x86_64
Version     : 1.84
Release     : 24.el6

还有什么我需要尝试的吗？

我的 MacOS 出现网络问题，需要进行故障排除。我知道 TCP 套接字有内部超时，如果远程方没有响应（但也没有正常断开连接），它将关闭连接。我可以使用任何命令/工具来检查此超时的确切值吗？

我们有一个服务器应用程序，它在大约 4000 个连接时面临 TCP 耗尽问题。这将每 3 或 4 周（大约）发生一次。创建此服务器应用程序的供应商在检查 netstat -b 的输出后告诉我们，即使客户端已断开，某些连接仍保持打开状态。

我的任务是调查特定客户端应用程序为什么没有正确关闭 TCP 连接。我相信如果客户端计算机关闭，它可能无法从服务器报告仍与该客户端建立 TCP 连接。不幸的是，我找不到任何信息来验证我的观点。我不想再浪费时间调查一个我认为根本不是问题的潜在问题。

tldr;

服务器是否可以报告与已关闭计算机的已建立连接？

我有一个带有 nginx 的小型 VPS 设置。我想从中榨出尽可能多的性能，所以我一直在尝试优化和负载测试。

我正在使用 Blitz.io 通过获取一个小的静态文本文件来进行负载测试，并遇到一个奇怪的问题，即一旦同时连接的数量达到大约 2000，服务器似乎正在发送 TCP 重置。我知道这是一个非常大量，但使用 htop 后，服务器在 CPU 时间和内存方面仍有大量空闲时间，所以我想找出这个问题的根源，看看我是否可以进一步推动它。

我在 2GB Linode VPS 上运行 Ubuntu 14.04 LTS（64 位）。

我没有足够的声誉直接发布此图表，因此这里是 Blitz.io 图表的链接：

以下是我为找出问题根源所做的工作：

• nginx 配置值worker_rlimit_nofile设置为 8192
• 已nofile设置为64000为硬性和软性限制root和www-data用户（什么nginx的运行为）/etc/security/limits.conf

• 没有任何迹象表明有任何问题/var/log/nginx.d/error.log（通常，如果您遇到文件描述符限制，nginx 会打印错误消息，这样说）

• 我有 ufw 设置，但没有速率限制规则。ufw 日志表明没有任何内容被阻止，我尝试禁用 ufw 并得到相同的结果。

• 没有指示性错误 /var/log/kern.log
• 没有指示性错误 /var/log/syslog

• 我已将以下值添加到/etc/sysctl.conf并加载它们sysctl -p，但没有任何效果：

  net.ipv4.tcp_max_syn_backlog = 1024
  net.core.somaxconn = 1024
  net.core.netdev_max_backlog = 2000
  

  Run Code Online (Sandbox Code Playgroud)

有任何想法吗？

编辑：我做了一个新的测试，在一个非常小的文件（只有 3 个字节）上增加到 3000 个连接。这是 Blitz.io 图表：

同样，根据 …

我有一个用作iperf3客户端的 linux机器，用 Broadcom BCM5721、1Gb 适配器（2 个端口，但只有 1 个用于测试）测试了 2 个配备相同的 Windows 2012 R2 服务器盒。所有机器都通过一个 1Gb 交换机连接。

在例如 300Mbit 测试 UDP

iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192

导致发送的所有数据包丢失 14%（对于具有完全相同硬件但较旧的 NIC 驱动程序的其他服务器盒，丢失约为 2%），但即使在 50Mbit 时也会发生丢失，尽管不那么严重。使用等效设置的 TCP 性能：

iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192

产生800Mbit以北的传输速度，没有报告重传。

服务器始终使用以下选项启动：

iperf3 -sB192.168.30.161

谁的错？

1. linux 客户端（硬件？驱动程序？设置？）？ 编辑：我刚刚从一个 Windows 服务器盒运行测试到另一个和 300Mbit 的 UDP 数据包丢失甚至更高，为 22%
2. Windows 服务器盒（硬件？驱动程序？设置？）？
3. 连接所有测试机的（单个）开关？
4. 电缆？

编辑：

现在我尝试了另一个方向：Windows -> Linux。结果：丢包率始终为 0，而吞吐量最大约为

• 840Mbit 用于-l8192，即分片的 IP 数据包
• 250Mbit 用于-l1472未分片的 …

我有一个叫长寿命过程中的问题KUBE-代理的存在部分Kubernetes。

问题是有时连接会处于 FIN_WAIT2 状态。

$ sudo netstat -tpn | grep FIN_WAIT2
tcp6       0      0 10.244.0.1:33132        10.244.0.35:48936       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:48340        10.244.0.35:56339       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:52619        10.244.0.35:57859       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:33132        10.244.0.50:36466       FIN_WAIT2   14125/kube-proxy

这些连接会随着时间的推移而堆积，从而使过程行为异常。我已经向 Kubernetes bug-tracker报告了一个问题，但我想了解为什么 Linux 内核没有关闭此类连接。

根据其文档（搜索 tcp_fin_timeout），处于 FIN_WAIT2 状态的连接应该在 X 秒后被内核关闭，其中 X 可以从 /proc 读取。在我的机器上它设置为 60：

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
60

所以如果我理解正确的话，这样的连接应该在 60 秒后关闭。但事实并非如此，他们在这种状态下停留了几个小时。

虽然我也明白 FIN_WAIT2 连接非常不寻常（这意味着主机正在等待来自连接远程端的一些 ACK，但它可能已经消失了）我不明白为什么这些连接没有被系统“关闭” .

有什么我可以做的吗？

请注意，重新启动相关进程是最后的手段。