上帝管上帝的，凱撒管凱撒的!耶穌這樣說過。如果這句話傳到包容的羅馬皇帝或者羅馬元老院耳朵里，估計就沒有基督教了吧，只是那可惡的總督本丟.彼拉多和猶太權貴勾結，濫用了職權，才使耶穌成了基督，一起簡單的聚眾布道事件變成了殉難，世界由此不同了...我并不贊成愛德華.吉本的觀點，將羅馬帝國的隕落歸罪于基督教，在我看來，羅馬帝國一直存在至今，雖然采取了更加抽象的方式。

在TCP/IP網(wǎng)絡的世界，分層設計的宗旨就是要實現(xiàn)“上帝管上帝的，凱撒管凱撒的”，然而也有一個本丟.彼拉多，將事情變得復雜，使TCP/IP這個羅馬式的帝國變得不包容，雖然沒有基督式的殉道，也差不多使互聯(lián)網(wǎng)發(fā)展變緩趨于停滯，這個本丟.彼拉多便是TCP!

在TCP/IP剛被設計的年代，即互聯(lián)網(wǎng)的公元元年，主機是固定的，用于編址的IP也是固定的，世界是和平的，可是隨著應用程序以及芯片技術的活力涌現(xiàn)，設備越來越小，App越來越豐富，當你覺得渾身憋得慌的時候，就動起來，移動IP時代來了。可是傳統(tǒng)的TCP并不適合移動IP，傳統(tǒng)的TCP基于TCP/IP協(xié)議頭字段的五元組，而標識設備的IP僅僅標識了設備位置，并沒有標識設備本身(--實際上不管到了什么年代，IP地址都不應該標識設備本身，它就是標識位置的!問題是，TCP不應該用一個標識位置的元素來標識設備。)一旦設備換了位置，其IP 也會改變，進而既有的TCP連接將全部中斷，這對于應用層來講是不可忍受的，于是各種彌補技術就出來了，本文只是大致介紹一下，因為本人很不看好這些技術，本文將留下大量的篇幅介紹本人覺得合理的技術。

解決方案1：向下對IP層動手術

這是傳統(tǒng)意義上的移動IP技術，主要指RFC 3344，主要使用了代理和隧道技術，包含很多的組件和過程，極其復雜，其宗旨就是即使位置改變了，IP改變了，設備之間依然可以使用其發(fā)起連接的時候的 TCP五元組進行通信，這樣就保證了TCP連接感知不到設備的移動，保證其不會中斷。舉例說明一個最簡單的情況，那就是使用隧道技術，將老的IP數(shù)據(jù)報用隧道協(xié)議封裝在新的IP數(shù)據(jù)報里面。

在最初學習該技術的時候，總覺得它怪怪的，雖然它也模擬了很多人類的社會行為，比如搬家，快遞轉交，手機換號通知等，但是這些擬人化的行為無法彌補我的懷疑，傳統(tǒng)移動IP技術本身的設計是絕對棒的，錯不在它，傳統(tǒng)移動IP技術之所以復雜難以駕馭，是因為傳統(tǒng)TCP技術的設計缺陷，巨大的設計缺陷當然需要巨大的代價來彌補，可惜TCP/IP的進化方式并不是***的進化方式，***的進化方式應該像有性生殖生物的進化方式一樣，一切個體從受精卵開始重新被“設計”，重新發(fā)育，生殖細胞重組以及發(fā)育過程中的變異緩慢積累下來接受自然選擇。TCP/IP技術無法做到讓新技術從受精卵開始發(fā)育，它只能做到技術重組的變異累加，所以任何人都無法砍掉一些東西，即使它已經(jīng)很不合理了，能做的只是用一塊合理的布把它包在里面。

說實話，要不是為了兼容傳統(tǒng)TCP，那些大佬們絕對不至于設計出如此的東西來。

解決方案2：向上對應用層動手術

上面一節(jié)中我談及了許多個人觀點，那些觀點自然而然被帶到了這一節(jié)，因此就不再重復。所謂向上對應用層開刀指的是在應用軟件和傳統(tǒng)TCP之間加一塊“合理的布”，用于隱藏下面IP的變化，也就是說，應用程序將不會直接面對IP，建立連接的時候，也不用再提供遠端IP地址，只是提供一個類似域名之類的標識即可，如果設備更換了IP，應用發(fā)出的數(shù)據(jù)將暫時被排入隊列，然后中間層迅速重建針對新IP地址的連接，發(fā)出排隊的數(shù)據(jù)，所有的隊列管理，連接重建，連接修復工作全部在這塊“合理的布”下面做。典型的技術是IETF的Multipath TCP，不那么典型的技術也有，包括一些技術愛好者，大牛們自己實現(xiàn)的，其中有云風本人的所謂“更穩(wěn)定的 TCP”http://blog.codingnow.com/2014/02/connection_reuse.html。

如果說解決方案1中所說的傳統(tǒng)移動IP技術需要運營商的支持的話，那么本節(jié)所述的技術則需要App開發(fā)者給與支持，所有的App將必須使用新的API，而不是傳統(tǒng)的socket API，如果說兼容性是TCP/IP要考慮的***要素的話，這種對應用層動手術的方式無疑自己將了自己一軍，已經(jīng)發(fā)布出去的App怎么辦?如何平滑過渡升級?過去的2013年一整年，我考慮的最多的就是平滑過渡升級，保持兼容性，也因此被公司評了優(yōu)秀，沉甸甸的銀子拿在手，我絕對有權說我對兼容性以及平滑升級的理解即使不很到位起碼也值得參考。

改掉TCP，殺掉本丟.彼拉多

TCP深深嵌入了 IP，這種說法也許并不準確，當初是沒有TCP/IP分層的，二者是一體的，后來有人按照分層設計的原則將二者分離成了兩個層次，但是分離的并不徹底，二者并沒有真的做到各司其職，正和本丟.彼拉多和自治的猶太人之間的關系一樣，作為羅馬的行省總督，他不明白自己的權力行使邊界在哪里，雖然沒有給他本人帶來什么災禍，卻讓愛德華.吉本認為給整個古代世界帶來了災禍。我之所以用本丟.彼拉多舉例是因為猶太行省和羅馬帝國之間的關系，正和TCP和IP之間的關系一樣，是自治和承載的關系，正如本丟.彼拉多和猶太貴族之間的關系一樣，TCP和IP的關系并不純粹。

1.TCP作為端到端協(xié)議，將“端”這個概念映射到了IP地址上，用IP地址識別對端;

2.TCP校驗和包含了IP層偽首部，當時使用偽首部的動機以及理由目前已經(jīng)不存在;

既然一切都是TCP這個當今的本丟.彼拉多惹的禍，那就干掉他!

若不是還想保留TCP的語義，我覺得重新設計一個傳輸層協(xié)議也不是不妥，相反，會更好，因為TCP真的太爛了。為了保留TCP的語義，因此，我保留TCP協(xié)議的格式，僅僅改變了TCP校驗和的計算方法以及TCP連接的查找算法：

1.不再使用偽頭部，TCP校驗和僅僅針對TCP數(shù)據(jù)段進行計算;

2.TCP連接的查找不再基于五元組，這個比較復雜，需要詳細說明。

傳統(tǒng)的TCP實現(xiàn)中，TCP數(shù)據(jù)段到達傳輸層之后，會用{源IP地址，目標IP地址，源端口，目標端口}這四元組來將一個TCP數(shù)據(jù)段和一個TCP連接關聯(lián)起來，最終落實到一個socket上，可以看到，其中的源IP地址和目標IP地址的存在，使TCP和IP有了很強的關聯(lián)，導致了移動IP實現(xiàn)技術的復雜，要想簡化移動IP，就需要解除這種上下層之間的相互關聯(lián)，實際上，復雜的并不是本質(zhì)意義上的移動IP，復雜的是移動IP技術對TCP協(xié)議的包容!而這是沒有意義的。取而代之的，我們?yōu)榱藢崿F(xiàn)TCP的端到端語義，就需要找一個真正能標識TCP端點所在設備本身的字段，該字段可以理解為“設備地址”，在編址意義上，該字段是全局唯一的，并且只要設備不變，該字段的值就不變。因此使用設備廠商ID+序列號或者設備網(wǎng)卡的MAC地址都是合理的選擇，需要注意的是，這個字段值的選擇必須標準化，否則的話，設備廠商ID+序列號有可能和某MAC地址重復。總之，在全局唯一性這個需要上，和采用源IP地址，目標IP地址的方式是一樣的，不同的是，新的設計中，該值是和設備綁定的，是不變的，不會像IP地址那樣隨著設備的位置而變化。

新的瘦身版TCP的“設備地址”字段非常重要，類似LISP協(xié)議，名稱和位置標識符分離。插說幾句，LISP(并非LISP語言)的出爐更多的也是要滿足云環(huán)境中無所不在的設備移動性以及虛擬化的需求。和我的新版TCP 不同，LISP是在網(wǎng)絡層實現(xiàn)的，只是尋址意義上的，如果LISP全面鋪開并且標準化，我的新版TCP也就不需要了，雖然也是在網(wǎng)絡層動手術，但是這個手術比較傳統(tǒng)移動IP技術而言更加成功和徹底。如果采用LISP方案，那么TCP可以保持不動，依然讓偽頭參與校驗和計算，依然采用基于源IP地址，目標 IP地址的TCP連接查找算法，只不過這里使用的IP地址是Location-ID Separation Protocol中的ID這個地址而不是Location地址，你完全可以把Location地址視為現(xiàn)如今我們普遍使用的IP地址，而ID地址則目前在標準IP協(xié)議中還不存在，另外，換一種理解方式，你可以把Location地址視為隧道外層的地址，把ID地址視為隧道內(nèi)層地址。在LISP正式形成規(guī)模前，如果你想達到這樣的效果，只能在TCP層面上做文章，因為沒有運營商的支持，你能控制的只有你自己的端系統(tǒng)。

扯了那么多的LISP，目的是想澄清一種思想，即位置地址和ID地址分離是大勢所趨，并非我憑空想象的。現(xiàn)在回到我的新版TCP實現(xiàn)上來。由于我僅僅修改了校驗和算法和TCP連接查找算法，因此所有TCP的語義被完整保留，諸如流控，擁塞控制，滑動窗口之類的行為全部不變。

為了使得新版的TCP兼容傳統(tǒng)的TCP，我把“設備地址”機制放在了TCP選項中，定義了一種新的選項類型，值就是“設備地址”，如下圖所示：

處理兼容性的時候，只有在TCP段擁有這個設備地址選項的時候，才會以設備地址為鍵來查詢TCP連接，否則執(zhí)行傳統(tǒng)TCP行為，如下圖所示：

注意，這個設備是雙方都擁有的，因此在新版TCP行為的實現(xiàn)中，必須對三次握手的細節(jié)作必要的調(diào)整，開始建立連接的時候，即SYN發(fā)送時，發(fā)起方攜帶自己的設備地址，目標設備的設備地址置為全0，接收方收到SYN后，初始化序列號以及自己的設備地址，在SYN/ACK包中攜帶自己的設備地址以及發(fā)起方的設備地址，同時將該TCP連接以源端口，目標端口，源設備地址，目標設備地址為算子計算一個哈希值，置入哈希表中(注意，此處暫不考慮syn-cookie機制)，此SYN/ACK包和發(fā)起方的SYN包一樣，依然使用IP地址尋址TCP連接，即傳統(tǒng)的TCP方式，發(fā)起方收到接收方的SYN/ACK后，使用源端口，目標端口，源設備地址，目標設備地址為元素計算一個哈希值節(jié)點，替換在SYN包發(fā)起前以源端口，目標端口，源IP地址，目標IP地址為因子計算的哈希值表示的節(jié)點，接下來發(fā)送ACK以及數(shù)據(jù)，三次握手完成，接下來的TCP數(shù)據(jù)段和TCP連接的關聯(lián)完全以設備地址為計算因子，這樣即便是IP變化了，TCP連接依然有效，如下圖所示：

TCP 就這樣被改造了，接下來你也許要問，怎么保證TCP數(shù)據(jù)段能到達目標主機呢?這是IP的事，即便在傳統(tǒng)TCP中，這也完全是IP的事，你見過中間尋址路由器用TCP協(xié)議字段來做路由尋址的嗎?少扯IP mark以及Policy Routing，我說的是標準的IP路由。事實上，TCP協(xié)議雖然是端到端協(xié)議，但是尋址到端根本沒有TCP什么事，全部是IP的問題，是IP協(xié)議確保了端主機到端主機的可達性，TCP所謂的端到端中的“端”指的是進程而不是主機!

TCP卸載了大量IP相關的計算后，IP變得純粹了，傳統(tǒng)的移動IP技術也將被徹底改寫，幾乎不再具有存在的理由。剩下的問題就只是IP地址在變化的情況下如何做到主機到主機的可達性保證了，說白了就是一個超大規(guī)模的動態(tài)路由問題。

純粹的移動IP

如今***的分布式系統(tǒng)就是人類社會，但是即使人類社會也被分成了各種類型的國家，每個國家擁有自己的政府以及各類社會組織，每個政府以及組織擁有自己的組織結構，并且存在一個核心，該核心執(zhí)行一對多的政策下發(fā)或者公告之類，這表明，如果玩不轉完全的P2P，分布式的話，***有一個中心。因為在節(jié)點數(shù)量巨大的分布式系統(tǒng)中，即使一個微小的設計bug，都將會帶來指數(shù)級爆發(fā)的故障，除非該系統(tǒng)是自組織的，但是據(jù)我所知，目前的IP網(wǎng)絡并不是完全自組織的，特別在某些地區(qū)。

IP協(xié)議，特別是移動IP，需要支持分布式自學習輔助以中心控制。目前，ICMP并沒有被好好挖掘，更多的網(wǎng)關要么不用該協(xié)議，要么干脆屏蔽攔截掉它，在移動IP年代，ICMP將會擁有用武之地。IP的漂移，設備IP的改變，這可以被看作是一種事件，而對這些事件的處理則是控制平面的事情，典型的處理有三種：

1.更新路由表;

2.告知端主機;

3.安全相關(審計，計費...);

第 1點和第3點不是本文考慮的，關鍵是第2點，IP變化了，如何告知參與通信的對端呢?注意，告知對端的目的并不是怕TCP斷掉，在使用了我的新版本TCP 協(xié)議之后，已經(jīng)沒有這個問題了，最關鍵的問題是對端在封裝IP頭的時候需要使用新的IP地址，這個在SDN年代很簡單，IP更新事件逐層報告給一個 Controller，該Controller將該消息逐層下發(fā)給另一端，期間所有的使用老IP的數(shù)據(jù)包，Contraller指示做NAT。然而在非 SDN環(huán)境中，你就必須采用既有的協(xié)議的方式來完成IP地址更新通告，***的就是擴展ICMP協(xié)議。

新的移動IP協(xié)議新增了以下的ICMP消息：

為了支持該消息，需要修改標準的IP協(xié)議處理流程：若地址不可達，則回復新老IP映射或者中心控制器的地址，中心控制器做***的抉擇，它也是新引入的，內(nèi)部保存有一系列組織成哈希表的映射，每條映射保存一個新IP地址和舊IP地址的映射。中心控制器存在多個，組織成樹形層級結構，最壞的情況，則是遍歷所有。事實上這種最壞的情況幾乎是會碰到的，因為移動IP設備基本上都是平滑移動的，移動的路徑在物理上是連續(xù)的，所謂的就近中心控制器對于連續(xù)的幾個IP地址保有段的基站都是就近的，符合局部性原則，即便跨越了一個中心控制器，也可能通過查詢同層的前后兄弟節(jié)點而快速命中，關鍵是中心控制器的部署拓撲以及查找算法問題(實現(xiàn)技術可以多樣化，memcache之類的也可以用)。

事實上，純粹版本的移動IP要比你想象的簡單，新的ICMP Checkchange控制消息并不是每種情況都會被用到，IP地址的改變分為以下幾種情況，假設HOST A和HOST B通信：

1.A的地址發(fā)生改變，發(fā)送數(shù)據(jù)到B，B收到數(shù)據(jù)后，用A的新的IP地址作為目標IP作回復;

2.A 的地址發(fā)生改變，等待接收B的數(shù)據(jù)，此時A將IP地址改變事件發(fā)給全局可達的中心控制器(存在多個，類似DNS)，B此時仍然以A的舊地址封裝IP報文，當該地址不可達的時候，不再像傳統(tǒng)IP那樣回復ICMP Unreachable消息，而是回復新的ICMP Checkchange消息，包含中心控制器的地址，B收到后以A的舊IP地址去查詢中心控制器，得到A的新地址，如果中心控制器沒有查到A的新地址，則回復ICMP Unreachable消息;

3.A和B同時改變地址，則同時執(zhí)行上述的情況2的步驟。

由此可見，在移動IP情形下，路由不可達不再是一個絕對化的錯誤了，有可能并不是不可達，而是設備更換了IP地址，具體是哪種情況，還得由中心控制器說了算。在上述說明中，和TCP幾乎是沒有任何關系的，即便是UDP，通過中心控制器也能讓端主機平滑識別和確認對端主機的新IP地址。IP層變成了純粹的轉發(fā)層，不再和傳輸層有任何關聯(lián)，同時最重要的是，不再需要傳統(tǒng)移動IP技術中的那么多復雜的組件和概念了。

動手實踐

抽幾個下雨的夜晚，把上面的變成現(xiàn)實!從設想到實現(xiàn)，我都選擇了下雨天，每逢下雨天或者雨夜，我就比較興奮，效率超級高!直接修改Linux內(nèi)核協(xié)議棧?開始的時候是這么想的，起初以為只改一點點就行，但是改了一點點后發(fā)現(xiàn)牽扯出來的東西還有另外一點點，沒完沒了，每次的panic讓美好的雨夜變成了煎熬!于是改成了uIP，這玩意兒比較好玩，用戶態(tài)輕量級，Linux下繁重的工作轉變成了uIP下蹂躪的快感......

干掉了本丟.彼拉多以后，想了很多。

網(wǎng)絡協(xié)議已經(jīng)慢慢退化成了僅僅的數(shù)據(jù)格式，它已經(jīng)漸漸失去了控制層面上的一切。以往所有的東西都是協(xié)議本身控制的，比如TTL到期后將丟棄，路由不存在將丟棄等等，即使你想讓一個TTL到期的包繼續(xù)前行也不可能，然而在SDN年代，控制邏輯全部由軟件自由定義，協(xié)議已經(jīng)不再有約束力，協(xié)議是什么?協(xié)議是一個數(shù)據(jù)格式，便于操作系統(tǒng)內(nèi)核知道該如何容納數(shù)據(jù)，數(shù)據(jù)有多大，如何分配內(nèi)存，什么數(shù)據(jù)放在什么位置等等，協(xié)議在交換機中僅存的作用就是便于從某個偏移取出某個字段，僅此而已!

也許，你會認為我的想法以及本文描述的移動版TCP/IP都太簡單了，是的，核心的東西就是這么簡單，就應該這么簡單，這樣它才能經(jīng)得起復雜化，我不會像寫博士論文那樣去思考問題，不管什么問題都是如此，技術的，歷史的，哲學的，不會面面俱到，也許還稍許偏激，但是卻是一目了然的，一目了然。

以上，純粹個人的胡思亂想，不辯論，不較真。請不要用個案以及特殊環(huán)境下的個例來反駁，在那種情況下，我的所有想法都是大錯特錯!

原文地址：http://blog.csdn.net/dog250/article/details/19686795