還是這篇文章：
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
有100個理由說TCP在某種場景下不好，就有100個理由說TCP在同樣的場景了好的不得了，這就好像面對中醫或者傳統武術一樣， 古老陳舊的東西總是被拿來被吹捧或者被打壓。 TCP是個30年前陳舊的協議，在計算機網絡的編年史中，TCP是一個古代的協議。
- TCP在長距離傳輸時窗口打開太慢；
- TCP對丟包無法預測；
- TCP對RTT測不準；
- TCP對網絡擁塞事件反應遲鈍；
- …
這是一個保守的協議。
數據要傳輸到另一個地方，中間要經過一個隧道，如何構建這個隧道是一個技術問題。
考慮TCP over TCP會怎樣？
TCP作爲一個按序接收的有狀態可靠的端到端傳輸協議，是因爲它對下層的鏈路做了一個假設：
- 下層是不可靠的！！
TCP的很多特性都源自於這個 不可靠假設 。所以TCP屏蔽掉這個假設之後， TCP是可靠的！
TCP over TCP？TCP同時作爲鏈路協議和負載協議？是的！
那麼 在TCP over TCP中，不可靠假設就失效了！ ，因爲 TCP是可靠的！
只要內層TCP的RTO超時時間小於外層TCP的RTO超時時間，悲劇就發生了，指數退避會讓連接崩潰。
但是，這很少發生，在支持FACK/SACK/RACK的 現代TCP 中，RTO很少被觸發，依靠各種xACK探測到需要重傳的場景，那便盡是TCP over TCP的優勢了。
爲了演示TCP是如何不適合長距離傳輸的，先看一個標準的丟包恢復：
爲什麼會丟包？
下層的鏈路不可靠唄，那麼如果在丟包的位置替換一條鏈路，使得它成爲可靠的鏈路，會不會更好呢？我們把這條鏈路換成一條TCP隧道，看看會發生什麼：
TCP有助於彌補鏈路不可靠，雖然以TCP來保證可靠也不是很完美，但至少這是一個POC：
- 通過軟件協議來彌補底層鏈路的不可靠性！
其實，代理也可以達到類似的效果，只要縮短TCP端到端的距離即可：
這側面證明了TCP確實是一個長距離不友好的勒瑟協議。
在不可靠的鏈路上構建一個可靠的軟件協議來保證可靠性，確實是一個不錯的想法。TCP協議構建隧道確實也是一個辦法，但我們必須要用TCP構建隧道嗎？
NoNoNoNoNo！
可以用Quic？
NoNoNoNoNo！這些都太重了，都是是煩人的東西。
只需要構建隧道的協議有丟包重傳機制即可，TCP附加的按序接收，連接狀態機維護都是不必要的，甚至只需要並非100%的丟包探測重傳即可即可，即不需要保證一個丟失的數據包被100%重傳，只要能 減少 端到端的丟包重傳開銷，那這條隧道就是成功的。
所以說，隧道不一定非要用TCP構建，只要 能重傳丟包 即可咯。隧道還是有好處的。
於是，構建一個 像TCP但又不是TCP的傳輸協議 就是必要的，當然，這純粹是trick，爲了玩而已，任憑哪個公司都不敢怎麼玩。
- 發送端的Netfilter掛HOOK，收到TCP write下來的數據時，直接ACK！
- 接收端的Netfilter掛HOOK，收到數據後直接copy to user，不再處理OFO！
- …
這個module實現起來非常簡單吧，只要借用TCP的一個殼即可，大家都待見TCP，那就按照你說的來唄…對了，還有Quic，依着你就是了。
都是錢，又TM是雞屎！
浙江溫州皮鞋溼，下雨進水不會胖。