Linux - TCP connect() 失败并出现 ETIMEDOUT

发布于 2024-12-20 21:07:46 字数 458 浏览 1 评论 0原文

对于 TCP 客户端对 TCP 服务器的 connect() 调用。Richard

Stevens 的《UNIX® 网络编程》一书中有如下内容：

如果客户端 TCP 未收到对其 SYN 段的响应，则返回 ETIMEDOUT。 4.4BSD，例如，调用 connect 时发送一个 SYN，6 秒后发送另一个 SYN，然后再发送一个 SYN 24 秒后（TCPv2 第 828 页）。如果总共 75 秒后未收到响应，则返回错误。

在Linux中我想知道什么是重试机制（多少次和间隔多远）。询问是因为对于 TCP 客户端 connect() 调用，我收到 ETIMEDOUT 错误。该套接字具有 O_NONBLOCK 选项，并由 epoll() 监视事件。

如果有人能指出我在代码中的何处实现了重试逻辑，那也会很有帮助。我尝试从 net/ipv4/tcp_ipv4.c 中的 tcp_v4_connect() 开始，但很快就迷失了方向。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

晨曦÷微暖 2024-12-27 21:07:46

超时根据测量的往返时间进行调整。

tcp_connect() 设置计时器：

    /* Timer for repeating the SYN until an answer. */
    inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
                              inet_csk(sk)->icsk_rto, TCP_RTO_MAX);

icsk_rto 将使用每个目标重传超时;如果来自目标的先前指标可从先前的连接获得，则将重新使用它。（有关详细信息，请参阅 tcp(7) 中的 tcp_no_metrics_save 讨论。）如果未保存任何指标，则内核将回退到默认 RTO 值：

#define TCP_RTO_MAX     ((unsigned)(120*HZ))
#define TCP_RTO_MIN     ((unsigned)(HZ/5))
#define TCP_TIMEOUT_INIT ((unsigned)(1*HZ))     /* RFC2988bis initial RTO value */
#define TCP_TIMEOUT_FALLBACK ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value, now
                                                 * used as a fallback RTO for the
                                                 * initial data transmission if no
                                                 * valid RTT sample has been acquired,
                                                 * most likely due to retrans in 3WHS.
                                                 */

tcp_retransmit_timer () 在底部附近有一些代码用于重新计算延迟：

    inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX);
    if (retransmits_timed_out(sk, sysctl_tcp_retries1 + 1, 0, 0))
            __sk_dst_reset(sk);

retransmits_timed_out() 将首先执行线性退避，然后执行指数退避。

我认为总而言之，您可以合理地预期大约 120 秒后才会从 connect(2) 返回 ETIMEDOUT 错误，除非内核有充分的理由怀疑远程对等点应该早点回复。

The timeout is scaled based on the measured round-trip time.

tcp_connect() sets up a timer:

    /* Timer for repeating the SYN until an answer. */
    inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
                              inet_csk(sk)->icsk_rto, TCP_RTO_MAX);

The icsk_rto will use a per-destination re-transmission timeout; if previous metrics from the destination is available from previous connections, it is re-used. (See the tcp_no_metrics_save discussion in tcp(7) for details.) If no metrics are saved, then the kernel will fall back to a default RTO value:

#define TCP_RTO_MAX     ((unsigned)(120*HZ))
#define TCP_RTO_MIN     ((unsigned)(HZ/5))
#define TCP_TIMEOUT_INIT ((unsigned)(1*HZ))     /* RFC2988bis initial RTO value */
#define TCP_TIMEOUT_FALLBACK ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value, now
                                                 * used as a fallback RTO for the
                                                 * initial data transmission if no
                                                 * valid RTT sample has been acquired,
                                                 * most likely due to retrans in 3WHS.
                                                 */

tcp_retransmit_timer() has some code near the bottom for recalculating the delay:

    inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX);
    if (retransmits_timed_out(sk, sysctl_tcp_retries1 + 1, 0, 0))
            __sk_dst_reset(sk);

retransmits_timed_out() will first perform a linear backoff then an exponential backoff.

I think the long and the short of it is that you can reasonably expect roughly 120 seconds before getting ETIMEDOUT error returns from connect(2) unless the kernel has good reason to suspect that the remote peer should have replied sooner.

回复收藏 0 原文