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

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

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

解決方案1：向下對IP層動手術(shù)

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

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

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

解決方案2：向上對應(yīng)用層動手術(shù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

純粹的移動IP

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

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

1.更新路由表;

2.告知端主機(jī);

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

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

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

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

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

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

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

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

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

動手實踐

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

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

網(wǎng)絡(luò)協(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é)議在交換機(jī)中僅存的作用就是便于從某個偏移取出某個字段，僅此而已!

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

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

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