- 主题:请教一个关于connect()疑似trigger了TCP SYN的问题
一个很简单的echo server/client可以复现。
被这个问题折腾了好久，请教各位socket programming巨佬。
server端运行在x86上，TCP，打开一个端口，等待连接。
client端运行在arm上，尝试连接这个端口。
运行中client端的connect()函数要么毫秒级立刻返回成功连接。
要么等待8/16/32/64秒后返回成功连接。
要么等待约130秒后返回超时。
这个8/16/32/64太规律了。
google了一下说可能是激发了TCP SYN的问题。
但是我server端端口打开后，只有一个client尝试连接这个端口，远谈不上flood。
请问什么能导致这个？
我知道的是ARM端（运行client）端有些特别的network设置，防止入侵的。
这个有关系吗？
--
FROM 61.188.78.*
通过ip连的还是domain连的
【 在 allegro 的大作中提到: 】
: 一个很简单的echo server/client可以复现。
: 被这个问题折腾了好久，请教各位socket programming巨佬。
: server端运行在x86上，TCP，打开一个端口，等待连接。
: ...................
--
FROM 122.234.57.*
通过IP连接的
因为ARM端（client端）的某些设置，导致只能用IP连接。
【 在 ziqin 的大作中提到: 】
: 通过ip连的还是domain连的
:
--
FROM 64.207.220.*
8/16/32/64这个是tcp sync retry的过程中，发送方自动将重传间隔翻倍的操作
rfc6298
When the retransmission timer expires, do the following:
(5.4) Retransmit the earliest segment that has not been acknowledged
by the TCP receiver.
(5.5) The host MUST set RTO <- RTO * 2 ("back off the timer"). The
maximum value discussed in (2.5) above may be used to provide
an upper bound to this doubling operation.
我觉得你最应该搞明白的不是这个翻倍的问题，而是下面几个问题：
1. 为什么第一个甚至第二个SYN会丢失，造成后面的SYN retry（retry的特征就是时间翻倍）？
是网络存在丢包吗？是否有在两侧抓tcpdump排查一下？必要的话，在中间加一个抓包点，通过tcpdump看看，SYN在哪里开始丢的？
如果是中间丢包，那出理中间的问题，如果是接收方将包丢弃，那看看是否有不合适的防火墙规则
2. 怎么会有这么多次的syn retry？合计130秒的话，这得6次重传了吧，发送方的/proc/sys/net/ipv4/tcp_syn_retries是不是设置太大了，当然，这不会造成SYN丢失，只是设置可能不合适
【 在 allegro 的大作中提到: 】
: 一个很简单的echo server/client可以复现。
: 被这个问题折腾了好久，请教各位socket programming巨佬。
: server端运行在x86上，TCP，打开一个端口，等待连接。
: ...................
--
FROM 113.120.108.*
谢谢你的建议！我得先学习一下tcpdump。
【 在 weiwallz 的大作中提到: 】
: 8/16/32/64这个是tcp sync retry的过程中，发送方自动将重传间隔翻倍的操作
:
: rfc6298
: ...................
--
FROM 64.207.220.*
了解一下tcp连接的指数退避
【 在 allegro 的大作中提到: 】
: 一个很简单的echo server/client可以复现。
: 被这个问题折腾了好久，请教各位socket programming巨佬。
: server端运行在x86上，TCP，打开一个端口，等待连接。
: ...................
--
FROM 27.46.103.*
1. 先用 TCPDUMP 抓包
2. 找一个没有特殊网络和安全设置的 ARM 机器，调试成功后，再到你这个 ARM 设备上调试
【 在 allegro 的大作中提到: 】
: 谢谢你的建议！我得先学习一下tcpdump。
:
--
FROM 218.76.62.*
试了一下抓包，并且了解了一些背景。
ARM系统（client端）是一个IPoIB，然后所有的tcp转到了某个host (call it host_A), 然后host_A再找到路径转到x86的服务端。
server端抓包显示的from都是来自host_A，而不是arm系统。
【 在 speedboy2998 的大作中提到: 】
: 1. 先用 TCPDUMP 抓包
: 2. 找一个没有特殊网络和安全设置的 ARM 机器，调试成功后，再到你这个 ARM 设备上调试
:
--
FROM 64.207.220.*
什么服务器？
把sync选项关闭呢？
【 在 allegro 的大作中提到: 】
: 一个很简单的echo server/client可以复现。
: 被这个问题折腾了好久，请教各位socket programming巨佬。
: server端运行在x86上，TCP，打开一个端口，等待连接。
: ...................
--
FROM 23.16.169.*
听起来像是ip package转ib package的时候出什么问题了
【 在 allegro 的大作中提到: 】
: 试了一下抓包，并且了解了一些背景。
: ARM系统（client端）是一个IPoIB，然后所有的tcp转到了某个host (call it host_A), 然后host_A再找到路径转到x86的服务端。
: server端抓包显示的from都是来自host_A，而不是arm系统。
: ...................
--
FROM 115.205.71.*