支持设置tcp_user_timeout

[psylambda]

Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)
当server端宕机重启恢复后, client端要花较长时间才能成功连上server端。 同以下issue

#1057

原因是tcp重传的backoff机制会导致重传时间越来越长。
例如最终120秒才重传一次, 但可能server端第10秒的时候已经恢复, 导致server端恢复110秒后, client端才请求成功
Describe the solution you'd like (描述你期望的解决方法)
支持tcp_user_timeout, 提早断开连接。
目前grpc已经支持

Describe alternatives you've considered (描述你想到的折衷方案)

Additional context/screenshots (更多上下文/截图)

[gydong]

可以开启一下熔断功能，时间就变成可控的了

[psylambda]

可以开启一下熔断功能，时间就变成可控的了

熔断功能确实可以控制断开连接的时间, 但参数太多太复杂了。tcp_user_timeout相对而言容易理解很多。

[zyearn]

这里有两种情况：

1. 对端出现异常断网/掉电，client端的tcp连接无法感知（可以通过加SO_KEEPALIVE解决），这时如果server不启动，client就会持续发流量，当server一恢复，client就会收到“Connection reset by peer”，然后下一次rpc会重新建tcp连接。
2. 对端正常重启，client端会直接关闭掉当前的socket，下一次rpc也会重建连接。

在上述两个情况下，都会新建tcp连接，所以你描述的“因tcp重传的backoff机制，导致server端恢复110秒后, client端才请求成功“听起来是一直在用同一个tcp连接，但这似乎不会发生，可以具体描述一下导致你下这一结论的数据/现象么

[psylambda]

场景是情况1, server端异常宕机/断电, client端的tcp包会一直重传, 且重传间隔越来越长, 如下图所示。

在上图的例子中, client端在231秒和352秒分别发了一个重传包。 如果server端恰好在232秒恢复正常, 那么client端并不会立刻感知到, 而是在352秒时刻发重传包的时候才感知到, 并重新建tcp连接, 之后的请求才能正常被server端处理。 这意味着232秒到352秒时间内, 虽然server端恢复了, 但是client端的所有请求都持续报错。

• 对于grpc, 可以通过配置tcp_user_timeout, 来控制重传时间, 避免重传间隔过长导致server端恢复后, client端还要较长时间才能感知到
• 对于brpc, 现在有办法避免这个问题么?

@zyearn

[zyearn]

这个需要通过brpc支持SO_KEEPALIVE来实现了。目前可以通过设置rpc超时时间来控制一下这个等待时间。

[wangtuanjie]

这个需要通过brpc支持SO_KEEPALIVE来实现了。目前可以通过设置rpc超时时间来控制一下这个等待时间。

---

有赞TCP网络编程最佳实践

如果TCP发送缓冲区中有数据未发送成功，TCP会进行超时重传，而不会触发TCP Keepalive。也就是说，即使应用设置了很小的TCP Keepalive参数，如time=10s、interval=10s、probes=3，在net.ipv4.tcp_retries2默认配置下，可能还是一直等到15min左右才能感知到网络异常。可能有的人不理解为什么Keepalive会被重传干扰，其实这里就是个优先级的问题。TCP最大重传次数的作用高于Keepalive参数的作用，未达到最大重传次数，不会向应用层报告网络错误信息。如果Keepalive不受重传影响，同样也会对关注重传的人造成干扰，比如为什么还没达到最大重传次数就放弃重传并关闭连接了？我们可以通过netstat -ot或ss -ot命令查看当前连接的计时器信息。

这种场景如果主动设置了TCP_USER_TIMEOUT 会更快的感知超时。