背景
解析原因
隧道封裝是目前最簡單的穿透docker容器複雜網路環境安全設定的方法
實際上這個問題最重要的原因是與docker容器執行環境的多樣複雜性是直接相關的。我們都知道docker容器可以執行在公有雲、私有雲、虛擬化以及裸機上。為了網路的安全，這些環境上都應該有嚴格的安全組和防火牆設定來保障只有合法流量能夠通過埠。這些帶來了網路安全的同時，也給docker 容器的部署和可移動性帶來了麻煩。每次部署啟動乙個容器，就要將其相應使用的埠上的安全設定更新為開放。尤其是混合雲場景下這個問題就更為麻煩了。我舉乙個具體的例子：當前很多的paas服務提供商都沒有自己的資料中心，他們直接從公有雲的iaas提供商那裡獲得虛擬機器，那麼這個時候就需要paas提供方呼叫公有雲iaas提供方的網路安全設定的api來開啟埠。paas提供商是不會把自己繫結死的，會選擇多家公有雲的 iaas(aws，gce，azure等)，這些iaas提供商的api全都不一樣，這得多麻煩啊。這還沒有考慮私有雲，自己資料中心的虛擬化和裸機環境的埠acl設定的複雜。
結論
通過上面的解析，可以想象，如果是在混合雲場景下，使用隧道封裝技術後，從虛擬機器流出的流量ip和mac都是唯一的，且只使用固定的埠，那docker容器執行環境的安全設定就可以固定下來，簡便多了。
其實，docker網路中使用隧道封裝技術還可以有利於一些其他問題的解決：
1. 容器相較於虛擬機器在一台主機上的密度大大增加，至少多出乙個量級，要說兩個量級我也信。在這樣的情況下機架上的接入交換機的port-mac表容量是否足夠呢，這裡使用了隧道封裝了負載後，就不用擔心這個問題了。
2. 此外，就如同虛擬機器使用了vxlan後一樣，有利於打破ip位址網段對二層網路規模的限制，打造出乙個大二層的網路。
TCP in TCP隧道為什麼不好
tcp in tcp不是不好，而是根本不可用，這源自於tcp協議本身的設計 tcp的可靠性是基於丟包檢測和重傳的，他依賴於tcp的下層鏈路是不可靠的這一事實，如果說tcp的下層鏈路是可靠的話，那麼tcp的重傳機制根本就是不必要的。如果下層鏈路是tcp，則 tcp的可靠性是靠超時重傳來保證的，而超時時...
03 為什麼封裝，為什麼有this？
為什麼封裝？嬰兒太多了，所以我們會考慮將每個出生的嬰兒的 文件 我們都會放於乙個盒子裡 這樣方便以後我們查詢他的身份證資訊。於是在這個盒子上，我們打了乙個孔，叫set 方法，如果是身份證，我們就取名 setcode 方法，這樣就將乙個人的身份證資訊建立 set了。但放進去後，我們有時候還需要檢驗這個...
什麼是容器,什麼是Docker
此文 自行文時有所改動 容器是一種輕量級 可移植 自包含的軟體打包技術，使應用程式可以在幾乎任何地方以相同的方式執行。開發人員在自己筆記本上建立並測試好的容器，無需任何修改就能夠在生產系統的虛擬機器 物理伺服器或公有雲主機上執行。docker是容器的一種，還有其他容器，比如 coreos 的 rkt...