myloft
[阁楼](https://blog.iloft.xyz/) 顺便水了两篇文章 [Disqusjs适配Apollo主题](https://blog.iloft.xyz/archives/apollo-disqusjs.html) [使用caddy反代Disqus API服务器](https://blog.iloft.xyz/archives/caddy-proxy-disqus.html)
增加了 cli 的 TCPWaitTimeout option，可以用于控制 Client 关闭 conn 后阻塞在 FIN_WAIT2 的时间，对于一些依赖 TCP 连接状态的协议如（FTP）调小该值可以降低命令回显和数据传输阻塞的时间。调整为 0，当 Client 发送 Fin 关闭连接，tun2socks 会立刻结束该连接。
测试发现可能出现 Client 发送 Fin 报文后，relay 不能及时退出，conn 持续处于 TCP_WAIT2 状态，部分依赖 TCP 连接状态的应用不能及时结束（FTP 传输数据后，客户端需要主动关闭 FTP-DATA TCP 连接来告知 FTP Server 传输完成），导致数据发送失败。
SetReadDeadline 似乎对阻塞在 Read 操作中的连接可能不会生效，不会在 tcp wait timeout 5s 后超时退出。
SetReadDeadline 在不同网络协议里的实现不太一样，不一定能保证让已经开始 Read 的连接超时退出。我是在尝试对接 Quic-Go 时发现的，一旦阻塞到
嗯嗯 是的 gVisor 和 sys 的协议栈都是正确（符合预期）的，我最近在尝试把代理程序和 tun2socks 集成在一起就发现了这个问题，他们的 SetReadDeadline 一般都直接依赖于传输层（Quic、KCP、TCP），而传输层的 SetReadDeadline 的行为就不一定符合预期了。
> 什么叫集中在一起？是通过tcp连在一起，还是直接整合到一个binary里？前者的话应该也是没问题的。 整合在一个 binary，通过实现 DialContext、DialUDP 接口进行数据传输。
嗯 不考虑和其他模块组成一个 binary 使用，这段逻辑我觉得还是需要重新考虑一下，比如使用 FTP 连接会延迟断开 Close 5s，表现就是执行命令回显延迟 5s / 传输完成后需要等待 5s 才能继续，显得十分卡顿。