上週晚上在家中，當我搭起熟悉的ss梯子時, 發現不可用了t.t。登陸到控制台檢視，發現國內的ip被block了。
昨天瞎逛，看到乙個開源專案：udp2raw-tunnel，他實現的是將乙個ip報文偽裝成tcp報文，目的是穿過網路中udp防火牆.
哈？！這難道是tcp-in-tcp？ 這玩意兒不是不可用嗎？
很早以前就有人說過了：
why tcp over tcp is a bad idea
為了將問題描述地更清楚，我還是將隧道應用的組網畫出來吧：
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-xu2gtwm8-1569850816579)(/img/remote/1460000020427501?w=667&h=164)]
圖中主機a和主機d通過隧道進行end to end的通訊，而裝置b對原始報文進行加密和封裝，裝置c做解封裝和解密。當然b和c不一定是單獨的裝置，它們可以就整合在主機a和主機d中。
tcp-in-tcp的問題是: 當隧道報文在網路中丟失時，b上的tcp連線**顯然會對報文進行重傳，但要知道a上也有乙個tcp連線**，所以a如果超時也會進行重傳，而從整個網路的角度，這個重傳是不必要的。但a不會理會，因為它是tcp。
tcp的設計原則是下層協議和介質是不可靠的，所以我需要自己保證。所以,tcp-in-tcp這樣的雙保險完全是沒有必要的。不僅沒必要，還有可能造成網路中重傳報文過多而擁塞。
不過也有研究說tcp-in-tcp在一定條件下可以提高網路的有效吞吐率：
**在此 understanding tcp over tcp: effects of tcp tunneling on end-to-end throughput and latency
還是差不多的拓撲：
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-ton6zv1v-1569850816580)(/img/remote/1460000020427502?w=639&h=336)]
**中將傳播延時(propagation delay)考慮進來了, 得出的結論是當ta和tb都比較大時，使用tcp-in-tcp隧道反而比不使用的有效吞吐量更大。為什麼呢？ 原因也比較好解釋：當ta和tb比較大時，顯然在a視角裡的tcp連線的rtt會比b視角裡的大不少，那麼如果隧道報文在網路中丟了，b重傳隧道報文，而a由於超時時間還沒到，就不會重傳原始報文。而如果不使用隧道，那麼重傳的任務就還是a的，顯然b重傳報文的傳播延時要比a重傳的大。
看上去有些道理，不過當網路條件實在不好，a的超時時間也到達後，就還是會回到之前更糟糕的情況…
所以我還是認為tcp-in-tcp不是乙個好主意…
TCP in TCP隧道為什麼不好
tcp in tcp不是不好，而是根本不可用，這源自於tcp協議本身的設計 tcp的可靠性是基於丟包檢測和重傳的，他依賴於tcp的下層鏈路是不可靠的這一事實，如果說tcp的下層鏈路是可靠的話，那麼tcp的重傳機制根本就是不必要的。如果下層鏈路是tcp，則 tcp的可靠性是靠超時重傳來保證的，而超時時...
鍵入url會發生什麼
現在還不知道該發往哪，所以需要dns協議將網域名稱解析為對應的ip位址 填充tcp協議頭，tcp裡面有首部長度，源埠號，目的埠號，還有標誌位，比如syn，ack等，序列號，確認序列號，視窗大小等一些資訊，但是tcp在傳輸之前需要先建立連線，需要進行三次握手 填充ip協議頭，包括版本號，首部長度，源i...
浮動後會發生哪些事情？
浮動問題 參考浮動過後的任何元素都成了block level element 所有內容在浮動，如果不處理，那麼就會很可怕。幸運的是有乙個屬性叫做clear，當將它應用到乙個元素時，它基本上說 停止浮動到這裡 這個元素和它之後的元素都不會浮動，除非你應用乙個新的float到另乙個元素。clear有三個...