[FEATURE] TCP Fast Open

[zonyitoo]

TCP Fast Open is supported in shadowsocks-libev. Since it is one of the most popular shadowsocks servers implementation, it would better to be compatible with it.

TODO

• Network Library Support
  • Mio: Linux: Support TCP_FASTOPEN tokio-rs/mio#638
  • Tokio
  • libc
    • macOS: Add TCP FastOpen support for macOS rust-lang/libc#1632
    • Linux, already supported. But using TCP_FASTOPEN_CONNECT in Kernel >= 4.11 would be a lot more convenient. Add TCP_FASTOPEN_CONNECT for Linux after 4.11 rust-lang/libc#1633
    • Windows. All APIs are already supported in winapi crate.
      • Missing TCP_FASTOPEN definition: Missing TCP_FASTOPEN retep998/winapi-rs#856
      • Don't know how to use ConnectEx, fallback to connect temporary

[zonyitoo]

Since Mio and Tokio don't have plan on supporting TFO, I am going to write a separate crate (mio-tfo, tokio-tfo maybe).

[dev4u]

Why spend time on tfo?
As far as my experience in use, there is no perceptible improvement to the use effect.
It will also cause instability under the mobile network.

[zonyitoo]

Yup. So I have given up.

[0x112]

@zonyitoo 请问这个特性有进展吗？

Why spend time on tfo?
As far as my experience in use, there is no perceptible improvement to the use effect.
It will also cause instability under the mobile network.

我觉得还是作为一个可选项加进来比较好，因为有时候不需要用到移动网络。
当我在使用libev版本的时候，两端开启TFO时并成功生效时，会感觉快一点点，可以用这些命令可以测试TFO是否开启：

grep '^TcpExt:' /proc/net/netstat | cut -d ' ' -f 91-96 | column -t
grep '^TcpExt:' /proc/net/netstat | cut -d ' ' -f 90-95 | column -t

[database64128]

TFO is dead. This issue should be closed.

[zonyitoo]

@zonyitoo 请问这个特性有进展吗？

Nope. I haven't spent any time on it recently. But I have already done in my local branch.

TFO requires lots of changes in API and haven't supported officially by mainstream network libraries in Rust, such as libstd, async-std, tokio, mio. It is quite nasty to make the current API to be compatible with TFO.

IMHO, TFO is dead. I don't see any massive production use case with TFO, maybe because TFO have to be supported by the OS, and it requires applications to support it explicitly by calling different APIs.

Back to this issue, I won't doubt that TFO may have benefits on connection latency, but it shouldn't be a lot that you can "feel" without having pressure tests. The performance test in this paper shows the following conclution:

As expected, TFO improves the PLT when the RTT is high for all the sites we tested. When the RTT is small and the network delay is only a small fraction of PLT, the resource processing time would exceed network time, so the gains from TFO are expected to be small. But even for pages heavy on content and with short emulated RTT (i.e. 20ms), TFO accelerates PLT by 4–5%. Conversely, for simpler pages such as wikipedia, the browser spends most of its time waiting for network transfers rather than processing the retrieved content, and thus TFO offers significant improvements of 16% and 41% with 100ms and 200ms RTTs respectively. The 200ms RTT figures roughly correspond to the expected performance on mobile devices since mobile RTTs are typically on the order of 100–200ms

So it should benefit in high RTT networks, and the network between locals and servers are usually have high RTTs. In other words, TFO may have benefits in this project.

But I would prefer using v2ray-plugin with quic enabled. :)

On the other hand, in this article, https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/ ,

Over the years, Google and Mozilla did more testing and eventually found that TFO wasn’t beneficial. Clients that initiate TFO connections encounter failures requiring them to re-try without TFO so often that, on average, TFO costs more time than it saves. In some networks, TFO never works – for example, China Mobile’s firewall consistently fails to accept TFO requiring every connection to be retried without it, leading to TFO actually increasing roundtrips.

[0x112]

So it should benefit in high RTT networks, and the network between locals and servers are usually have high RTTs. In other words, TFO may have benefits in this project.

我大概清楚了，十分感谢您的解答 :)

[zonyitoo]

Any PRs are welcome. But consider the downside of TFO, I don't think it is urgent.

[zonyitoo]

After a day, I am getting interested in pushing this forward. No matter it is useful or not, just for fun.

[0x112]

After a day, I am getting interested in pushing this forward. No matter it is useful or not, just for fun.

😅😅作为一个Optional Features怎么样？如果需要用到才在编译时加入--features "tcp-fast-open"会不会比较好？

（另外想请教一下，ss-rust的二进制文件比较大，能不能在编译时执行strip？我现在用了这个方法：rust-lang/cargo#3483 (comment) 这是正确的做法吗？）

[zonyitoo]

#276

It is 2021 now, what kind of device couldn't provide 2MB free space?

[0x112]

#276

谢谢 👍

It is 2021 now, what kind of device couldn't provide 2MB free space?

这不是空间的问题，只是想习惯性的削减一下体积

[zonyitoo]

Compile with -s will make generated code to be a lot slower.

[0x112]

Compile with -s will make generated code to be a lot slower.

感谢提醒哈，我原本是以为对性能无影响才想要strip的。。。