我有7个运行在EC2上的Ubuntu 14.04.4服务器。 一台服务器承载了memcached（端口11211），另外一台是客户端。 在6个客户中，有5个能够连接，一个不能（见注）。 我已经采取了连接两端的TCP转储。 我看到客户端发送了SYN请求，但是没有发送ACK。 对于失败的连接，tcpdump看起来像这样（在这之后，SYN重复多次） 1 0.000000 172.16.1.58 172.16.1.94 TCP 76 43469 → 11211 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=849737 TSecr=0 WS=128 而对于不同服务器的成功连接： 1 0.000000 172.16.1.64 172.16.1.94 TCP 76 44908 → 11211 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=19201098 TSecr=0 WS=128 2 0.000298 172.16.1.64 172.16.1.94 TCP 68 44908 → 11211 [ACK] Seq=1 […]
我试图维护源代码通过我的袜子代理到DMZ。 由于我的连接是TCP，我不能使用反向代理的典型XFF标头方法。 有没有什么标准的方法来完成这个？
系统是CentOs sudo netstat -ntp | grep 103.235.244.98 tcp 0 0 ::ffff:61.184.232.47:35650 ::ffff:103.235.244.98:80 ESTABLISHED 41792/java tcp 0 268800 ::ffff:61.184.232.47:35651 ::ffff:103.235.244.98:80 ESTABLISHED 41792/java 61.184.232.47是pppoe获得的一个ip地址，这个连接configuration为re-dail，ip应该每5分钟更换一次，问题是ip上的TCP连接保持ESTABLISHED大于20分钟，应用程序将被卡住。 如何configuration系统，使这个ESTABLISHED连接在合理的时间之后被发现虚假？ 已经尝试用sysctl -w net.ipv4.tcp_keepalive_intvl=2调整tcp_keepalive_intvl ，但似乎没有运气。
75％的第三方API调用正在下降。 发生这种情况时，将传播到我的调用代码作为请求被中止：无法创buildSSL / TLS安全通道错误。 这是一个Wireshark捕获的RST ACK发生2个调用： 失败的捕获 。 这是一个成功的连接Wireshark捕获比较： 成功捕获 。 我无法弄清楚是什么导致RST ACK标志。 几件我注意到的事情。 TCP DUP ACK在成功和失败之间是常见的。 它似乎有时从它恢复。 服务器似乎不支持SACK_PERM = 1。 不知道这是否有关。 关于为什么TCP RST ACK正在发生的任何想法？
一位客户要求我看看他们的Windows 2008服务器，因为它运行速度非常慢。 服务器运行在Windows防火墙后面（是的，我知道），我相信在服务器上运行的应用程序正在被滥用。 如果进入资源监视器并查看networking> TCP连接，我可以看到应用程序的tcp连接数量非常高。 不过，我想将这些IP地址分组，以便我能够追踪滥用服务器的人。 有没有办法做到这一点？
在PHP中，我基本上有以下几点： set_time_limit(0); foreach ($files_to_send as $file) { $filesize = filesize($file); $blocksize = 1024 * 1024; // 1MB $outputted = 0; // how many bytes already sent $fid = fopen($file, 'r'); while ($outputted < $filesize) { echo fread($fid, $blocksize); $outputted += $blocksize; } } 这很好。 这是一个非常慢的服务器（英特尔凌动双核CPU），但从本地运行wget约20-24MB /秒。 从外部下载基本上填充服务器的上传速度或客户端的下载速度，以较慢者为准。 如预期的那样，500MB的下载需要大约8分钟的10mbps连接。 来自美国的人（服务器在荷兰阿姆斯特丹附近）提到，对他来说下载大约半分钟后就下载了。 他的下载速度大约是100-200KB / s，并且先不下滑。 我正在尝试诊断问题。 我已经检查了Apache的内存使用情况，并且非常稳定，这意味着PHP的输出（ echo […]
我试图匹配在他们的TCP选项字段中的特定值的数据包。 例如，我想匹配MSS值大于1400的所有数据包。 我发现iptables有一个–tcp-option参数，但是这个参数只检查指定的选项是否存在于数据包中。 我也知道我可以使用u32扩展匹配任何字段。 但是由于tcp选项是dynamic的，它们在数据包中的位置可以根据其他选项的存在而改变 而且TCP选项和我想匹配的值将是dynamic的。 因此，我必须能够支持IETF指定的所有TCP选项。
我有一个运行Debian 7（proxmox）的OpenVZ容器的遗留系统，我看到一个麻烦的问题，系统被运行apache前端的VZ容器的打开连接淹没。 发生这种情况时，服务器上的日志将填充数千个“TCP：时间等待桶表溢出（CT233）”错误。 这与来自networking服务器的缓慢响应相结合。 有什么我可以做的，以缓解这个问题？ 经过Googlesearch，我已经对各种conntrack设置做了一些调整，但是我不愿意做任何过激的事情，而没有更好地理解这些影响可能是什么（或者，实际上这是否可能有助于任何情况） 想知道情况是什么，这里是今天发生这种情况时“sysctl -a | grep conntrack”的输出： net.netfilter.nf_conntrack_generic_timeout = 480 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60 net.netfilter.nf_conntrack_tcp_timeout_established = 345600 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close = 10 net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300 net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300 net.netfilter.nf_conntrack_tcp_loose = 1 net.netfilter.nf_conntrack_tcp_be_liberal = 0 net.netfilter.nf_conntrack_tcp_max_retrans = 3 net.netfilter.nf_conntrack_udp_timeout = […]
我有一种情况，三个不同的NFS客户端之一会在一段时间后（某些天数）中断。 我发现破损的主机和服务器不断地发送'ack'数据包（达到100 + mb / s）。 双方都发送相同的数据包，双方都不会重发任何实际的数据。 1最终服务器将重置连接，NFS将在短时间内（2-4分钟）正常运行。 服务器重新启动将修复所有事情，直到数天后再次中断。 环境是其他环境的重复，其他NFS客户端从来没有这个问题（相同的操作系统和应用程序版本）。 在排除故障的同时，我看到wireshark将数据包报告为“TCP ACKed unseen segment”，但我不明白为什么。 数据包＃28517有Ack = 2194563093和数据包＃28513有Seq = 2194563093 …这是数据包被确认，对不对？ 我做了另一个干净的捕捉，看起来是一样的，所以我不明白为什么它显示了这样的。 2 我主要查找debuggingNFS问题（客户端的SLES，服务器端的EMC VNX）的提示，并确认wireshark输出是错误的（否则这是我应该深入研究的实际线索）。 编辑：服务器和客户端在相同的交换机，相同的子网。
我有nginx上游的redis服务器（5台服务器上有4个redis实例），如下所示： upstream redis_cluster { server 10.0.1.8:6379 fail_timeout=0; server 10.0.1.8:6380 fail_timeout=0; server 10.0.1.8:6381 fail_timeout=0; server 10.0.1.8:6382 fail_timeout=0; server 10.0.1.6:6379 fail_timeout=0; server 10.0.1.6:6380 fail_timeout=0; server 10.0.1.6:6381 fail_timeout=0; server 10.0.1.6:6382 fail_timeout=0; … keepalive 16; } 在添加最后一个服务器（实际上是最后4个redis实例）之后，我注意到了一些奇怪的连接： 9684 10.0.0.17:6379 TIME_WAIT 3 10.0.0.17:6380 ESTABLISHED 9677 10.0.0.17:6380 TIME_WAIT 9664 10.0.0.17:6381 TIME_WAIT 6 10.0.0.17:6382 ESTABLISHED 9660 10.0.0.17:6382 TIME_WAIT 4 10.0.1.3:6379 ESTABLISHED 1 […]