实战：+65行Go实现低延迟隧道

在违法的边缘继续整点活。

---

1. 槽点

尽管上篇我已经反复强调，但是一位不愿意透露姓名的王先生还是不顾劝阻，执意以身试法。

不仅如此，王先生试探以后还吐槽说，虽然上上篇搭上上篇能上了，但是延迟和吞吐不给力啊，有没有办法可以再 去肥增瘦 优化一下？

我躲在王先生宽阔的背影里思索了一下，觉得确实还有很大的优化空间。

---

2. 总览

骚话不多说，我们先来观察一下王先生的不法行为：

王先生的请求先后通过中继A、中继B、socks5代理，才能到达法外之地，整个链路总共需要建立 4 次 TCP 连接。

乍一看有点多，不过好在王先生和中继A通常在同一个网络（甚至中继A可能就跑在王先生的机器上），他俩之间的延迟基本可以忽略，因此我把王先生和中继A用虚线框起来了。

同样用虚线框起来的中继B和socks5代理也一样，它们往往也部署在同一台机器上，因此也可以忽略这里建立TCP连接的耗时。

所以真正影响整个链路的耗时是“A ↔ B”、“socks5代理 ↔ 法外之地”的延迟。假设这俩的 RTT（Round Trip Time）分别是 x、y 毫秒，那么建好整个链路总共需要多久呢？这里先假设网络通畅、没有丢包。

敲黑板，这不是一道送分题，那些张口就想回答 x + y 的同学，

为什么不对呢？

问题在于 socks5 协议，它有一个鉴权协商环节，至少需要一个 RTT （如果使用了鉴权则不止），所以整体上需要 2 * x + y 才能建立起整个链路，然后王先生才可以开始它的试探。

注：可能某些同学会有疑问，TCP创建连接不是三次握手么，为什么不是 3x+1.5y ？这是因为◼️◼️◼️ ◼️◼️◼️ ◼️◼️◼️ ◼️◼️◼️

既然我们已经分析出了延迟的来源，优化方法就呼之欲出了。

---

3. 优化