專屬程序員的西遊記，不是程序員讀不懂哦？

這是一個有關計算機網絡協議的故事

1、我佛造經傳極樂

話說我佛如來爲度化天下蒼生，有三藏真經，可勸人爲善。

就如圖中所示，真經所藏之處，在於雲端。佛祖所管轄之下，有四個區域Region，稱爲四大部洲， 一是東勝神洲，二是南贍部洲，三是西牛賀洲，四是北俱盧洲。

我佛所在西牛賀洲，是主站點。

在每一個區域Region，爲保證真經永固，設置多個藏經樓，稱爲可用區（Available Zone）。

每一個藏經樓裏面是一排一排的櫃子，稱爲機櫃，裏面有一排一排的格子，稱爲服務器，經文就擺放在格子中。

在藏經樓中，櫃子根據經文分門別類的組織起來，由不一樣的神仙進行管理，管理一個櫃子的經文的神仙，訪問這裏面經文的鑰匙就在他手裏，稱爲接入層神仙（接入層交換機）。

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。

多個接入層神仙被一組匯聚層神仙（匯聚層交換機）管着，多個匯聚層的神仙被一組核心層神仙（核心交換機）管着。

神仙體系組織嚴格，井井有條，不一樣的接入層神仙交換經文，要經過匯聚層神仙贊成，不一樣的匯聚層神仙交換經文，須要核心層神仙贊成。

經文的看守要萬無一失，於是每一層都是分組看護，互相監督，互相備份，稱爲堆疊。

雖然說每一個櫃子裏面放滿了經文，爲了防止經文被偷聽偷看，經文的內容是被仙術封裝在一個虛擬的私密空間裏面，雖然有人可能會偷到物質的經文，可是沒有仙術打開這個私密空間，看到的經文如同空白的同樣。這個虛擬的私密空間稱爲VPC。

要解讀經文，須要使用每一格中一個不起眼的法寶，就是稱爲Openvswitch的虛擬交換機，顧名思義就是起到經文在虛擬私密空間和物理空間之間的轉換做用。

Openvswitch如何轉換呢？使用的是一種稱爲VXLAN的封裝技術，可是必需要事先知道芝麻開門的ID，也即VXLAN ID，才能看到經文的真正內容。

在虛擬的空間中，放着真正能夠解讀的真經。

真經有法一藏，談天；論一藏，說地；經一藏，度鬼；三藏共計三十五部，該一萬五千一百四十四卷，乃是修真之徑，正善之門。

看來已經前中後臺分離，分爲基礎服務層，組合服務層，Controller層，共三十五個模塊，一萬五千多個服務，真是微服務架構啊。

如何可以不要迷失在這個一萬五千卷經文中，也是頗有挑戰的事情，須要一個索引和指南，這就是常說的RPC框架和服務註冊與發現中心。

爲了方便諸多僧侶前來取經，靈山腳下會有一個統一的入口地址，這裏有一個神仙，稱爲金頂大仙，專門來接應取經人的。

因爲前來取經的人不少，同時經文也不少，因此金頂大仙多起到負載均衡的做用，將不一樣的取經人引領到不一樣的藏經樓，訪問不一樣的經文。

金頂大仙所在的靈山腳下，是一個世界知名的地址，稱爲外網IP地址，這個地址是全球可定位的，全部的取經人都先到這個地方，金頂大仙經過NAT規則，將外網IP地址，變成藏經樓的私有IP地址，例如2號藏經樓三樓，4號藏經樓五樓等。在靈山藏經樓裏面，是經過私有IP地址定位的。

真經已經準備好，就差東土取經人了。

2、觀音奉旨上長安

但是佛祖愁啊，是這樣說的：我待要送上東土，叵耐那方衆生愚蠢，毀謗真言，不識我法門之要旨，怠慢了瑜迦之正宗。怎麼得一個有法力的，去東土尋一個善信．教他苦歷千山，遠經萬水，到我處求取真經，永傳東土，勸他衆生，卻乃是個山大的福緣，海深的善慶、誰肯去走一遭來？

真經就在靈山，能夠東土之人愚鈍，不知道靈山咋辦呢？要一個法力無邊的人告訴他們呀。並且最好可以告訴全世界，靈山這裏有真經。

好在有觀音菩薩，道：「弟子不才，願上東土尋一個取經人來也。」，觀音菩薩有什麼法力呢？固然是BGP協議了。

剛纔那張圖畫的是一個可用區的狀況，對於多個可用區的狀況，咱們能夠隱去計算節點的狀況，將外網訪問區域放大。

外網IP是放在虛擬網關的外網網口上的，這個IP如何讓全世界知道呢？在覈心交換外面是安全設備，而後就是邊界路由器。邊界路由器會和多個運營商鏈接，從而每一個運營商都可以訪問到這個網站。邊界路由器能夠經過BGP協議，將本身數據中內心面的外網IP向外廣播，也就是告訴全世界，若是要訪問這些外網IP，都來我這裏。

每一個運營商也有不少的路由器、不少的點，因而就能夠將如何到達這些IP地址的路由信息，廣播到全國乃至全世界。

厲害吧，這是我佛如來告訴觀音菩薩的：「這一去。要踏看路道，不準在霄漢中行，須是要半雲半霧；目過山水，謹記程途遠近之數，叮嚀那取經人。「

就是說你去東土的路上，通過了哪些道路，要記住路徑，要記住遠近，才能告訴取經人這一路應該怎麼走。

3、玄奘秉誠建大會

當觀音菩薩來到東土大唐，正看到玄奘法師正坐在高臺上，帶領衆人誦經，念一會《受生度亡經》，談一會《安邦天寶篆》，又宣一會《勸修功卷》

菩薩近前來，叫道：「那和尚，你只會談小乘教法，可會談大乘麼？」玄奘聞言，心中大喜，翻身跳下臺來，對菩薩起手道：「老師父，弟子失瞻，多罪。見前的蓋衆僧人，都講的是小乘教法，殊不知大乘教法如何。」菩薩道：「你這小乘教法，度不得亡者超升，只可渾俗和光而已。我有大乘佛法三藏，能超亡者昇天，能度難人脫苦，能修無量壽身，能做無來無去。」

你看，在西方極樂淨土，我佛已經有了更牛的佛經，遙遠的東方，還在讀本土的僧人早期從西方傳過來的經。

這種模式，稱爲CDN。

咱們部署應用的時候，通常會把靜態資源保存在兩個地方，一個是nginx後面的varnish緩存裏面，通常是靜態頁面；對於比較大的、不常常更新的靜態圖片，會保存在對象存儲裏面。這兩個地方的靜態資源都會配置CDN，將資源下發到邊緣節點。

最初佛祖傳經，都是口口相傳，經文都會記在高僧大德的內心，隨着高僧雲遊天下，隨着廟宇遍及天下，佛經從而遍及天下。這就至關於將佛經緩存在邊緣節點。

配置了CDN以後，權威DNS服務器上，會爲靜態資源設置一個CNAME別名，指向另一個域名cdn.com，返回給本地DNS服務器。

當本地DNS服務器拿到這個新的域名時，須要繼續解析這個新的域名。這個時候，再訪問的時候就不是原來的權威DNS服務器了，而是 cdn.com 的權威DNS服務器。這是CDN本身的權威DNS服務器。

在這個服務器上，仍是會設置一個CNAME，指向另一個域名，也即CDN網絡的全局負載均衡器。

本地DNS服務器去請求CDN的全局負載均衡器解析域名，全局負載均衡器會爲用戶選擇一臺合適的緩存服務器提供服務，將IP返回給客戶端，客戶端去訪問這個邊緣節點，下載資源。緩存服務器響應用戶請求，將用戶所需內容傳送到用戶終端。

若是這臺緩存服務器上並無用戶想要的內容，那麼這臺服務器就要向它的上一級緩存服務器請求內容，直至追溯到網站的源服務器，將內容拉到本地。

CDN的全局負載均衡策略，就至關於當僧人們想讀佛經的時候，沒必要要都去西天，而是能夠就近去問，周圍有沒有廟宇，而後向廟宇的師傅去請教佛經。

然而緩存的佛經固然是比不上西天取到的經文更新，因此東土因爲離西天較遠，緩存的仍是小乘佛教，要讀大乘佛教，就要去西天取經，稱爲回源。

4、觀音顯像化金蟬 小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。

觀音菩薩打算度化玄奘法師，回源去西天取經。

但是怎麼去呢，地址在哪裏呢？玄奘法師只據說西天，不知道具體的地址，這就要問觀音菩薩了。

這個時候，你們才知道，西天在靈山大雷音寺，距此十萬八千里。

這個過程稱爲DNS解析。

當在手機上面打開一個App的時候，首先要作的事情就是解析這個網站的域名。

在手機運營商所在的互聯網區域裏，有一個本地的DNS，手機會向這個DNS請求解析DNS。當這個DNS本地有緩存，則直接返回；若是沒有緩存，本地DNS才須要遞歸地從根DNS服務器，查到.com的頂級域名服務器，最終查到權威DNS服務器。

若是你使用雲平臺的時候，配置了智能DNS和全局負載均衡，在權威DNS服務中，通常是經過配置CNAME的方式，咱們能夠起一個別名，例如 vip.yourcomany.com ，而後告訴本地DNS服務器，讓它請求GSLB解析這個域名，GSLB就能夠在解析這個域名的過程當中，經過本身的策略實現負載均衡。

GSLB經過查看請求它的本地DNS服務器所在的運營商和地址，就知道用戶所在的運營商和地址，而後將距離用戶位置比較近的Region裏面，將三個本地負載均衡的公網IP地址，返回給本地DNS服務器。本地DNS解析器將結果緩存後，返回給客戶端。

對於手機APP來講，能夠繞過剛纔的傳統DNS解析機制，直接只要HTTPDNS服務，經過直接調用HTTPDNS服務器，獲得這三個本地負載均衡的公網IP地址。

這個公網IP地址，就是金頂大仙所在的位置。其實這個時候，金頂大仙已經在等待了。

這個時候，李世民忽然開始說話了，曰：「誰肯領朕旨意，上西天拜佛求經？「 並願意買下觀音手中的兩件寶物，「錦瀾袈裟」一領，「九環錫杖」一根，佛祖說過：」如有取經人堅心來此，穿個人袈裟，免墮輪迴；持個人錫枚，不遭毒害。「

玄奘法師回答：「貧僧不才，願效犬馬之勞，與陛下求取真經，祈保我王江山永固。」

這個時候，菩薩說了：「西天路遠，更多虎豹妖魔。只怕有去無回，難保身命。」

玄奘道：「我已發了弘誓大願，不取真經，永墮沉淪地獄。「

其實這裏的對話是頗有意思的，玄奘法師回覆李世民的和回覆觀音菩薩的不一樣。

這個時候，李世民做爲世俗的君王，已經想求取真經了，也就是東土大唐做爲客戶端，要發起對於服務端的請求了。可是玄奘法師知道，唐王李世民去取經，求的是江山永固。因此李世民的請求是應用層的，發起的是HTTP的協議，在HTTP的請求正文中，怕是寫的「江山永固」四個字。

而玄奘法師回覆觀音菩薩的時候，說的就不一樣了，是一種對於真經和佛法自己的堅持。因此玄奘法師是TCP層的，TCP是面向鏈接的，TCP 是靠譜的協議，可是這不能說明它面臨的網絡環境好。從 IP 層面來說，若是網絡情況的確那麼差，是沒有任何可靠性保證的，而做爲 IP 的上一層 TCP 也無能爲力，惟一能作的就是更加努力，不斷重傳，經過各類算法保證。也就是說，對於 TCP 來說，IP 層你丟不丟包，我管不着，可是我在個人層面上，會努力保證可靠性。

這一點在流沙河有了驗證。觀音菩薩度化沙悟淨的時候，沙悟淨說：「菩薩，我在此間吃人無數，向來有幾回取經人來，都被我吃了。凡吃的人頭，拋落流沙，竟沉水底(這個水，鵝毛也不能浮)，唯有九個取經人的骷髏，浮在水面，再不能沉。我覺得異物，將索兒穿在一處，閒時拿來頑耍，這去，但恐取經人不獲得此，卻不是反誤了個人前程也？」菩薩日：「豈有不到之理？你可將骷髏地掛在頭頂下，等候取經入，自有用處。」

因此沙悟淨脖子上這九個骷髏，是唐三藏的前九輩子，一旦吃了，就不斷的重試。

爲了可以實現重試，實現TCP的可靠性，客戶端和服務器須要創建鏈接。

HTTPS協議是基於TCP協議的，於是要先創建TCP的鏈接。在這個例子中，TCP的鏈接是從手機上的App和負載均衡器SLB之間的。也就是唐僧和金頂大仙之間，到了金頂大仙，就不怕了，會指引到佛祖那裏的。

儘管中間要通過不少的路由器和交換機，可是TCP的鏈接是端到端的。

TCP這一層和更上層的HTTPS沒法看到中間的包的過程。儘管創建鏈接的時候，全部的包都逃不過在這些路由器和交換機之間的轉發，轉發的細節咱們放到那個下單請求的發送過程當中詳細解讀，這裏只看端到端的行爲。

對於TCP鏈接來說，須要經過三次握手創建鏈接，爲了維護這個鏈接，雙方都須要在TCP層維護一個鏈接的狀態機。

一開始，客戶端和服務端都處於CLOSED狀態。服務端先是主動監聽某個端口，處於LISTEN狀態。而後客戶端主動發起鏈接SYN，以後處於SYN-SENT狀態。服務端收到發起的鏈接，返回SYN，而且ACK客戶端的SYN，以後處於SYN-RCVD狀態。

客戶端收到服務端發送的SYN和ACK以後，發送ACK的ACK，以後處於ESTABLISHED狀態。這是由於，它一發一收成功了。服務端收到ACK的ACK以後，處於ESTABLISHED狀態，由於它的一發一收也成功了

當TCP層的鏈接創建完畢以後，接下來輪到HTTPS層創建鏈接了，在HTTPS的交換過程當中，TCP層始終處於ESTABLISHED。

對於HTTPS，客戶端會發送Client Hello消息到服務器，用明文傳輸TLS版本信息、加密套件候選列表、壓縮算法候選列表等信息。另外，還會有一個隨機數，在協商對稱密鑰的時候使用。

而後，服務器會返回Server Hello消息，告訴客戶端，服務器選擇使用的協議版本、加密套件、壓縮算法等。這也有一個隨機數，用於後續的密鑰協商。

而後，服務器會給你一個服務器端的證書，而後說：「Server Hello Done，我這裏就這些信息了。」

客戶端固然不相信這個證書，因而你從本身信任的CA倉庫中，拿CA的證書裏面的公鑰去解密電商網站的證書。若是可以成功，則說明電商網站是可信的。這個過程當中，你可能會不斷往上追溯CA、CA的CA、CA的CA的CA，反正直到一個授信的CA，就能夠了。

其實觀音菩薩手裏的錫杖和袈裟，就至關於佛祖辦法的證書，保證西行路上的安全，玄奘法師這個網絡包別被別人吃了，或者篡改。

就像誤入小雷音一集中，白眉老佛想吃了唐僧肉，本身披上袈裟，西天取經，求得正果。

固然，一開始觀音菩薩拿出錫杖和袈這個證書的時候，你們也不相信，因此須要觀音菩薩現出真身，做爲CA，證實給客戶端，唐王李世民和玄奘法師才下拜。

證書驗證完畢以後，以爲這個服務端是可信的，因而客戶端計算產生隨機數字Pre-master，發送Client Key Exchange，用證書中的公鑰加密，再發送給服務器，服務器能夠經過私鑰解密出來。

接下來，不管是客戶端仍是服務器，都有了三個隨機數，分別是：本身的、對端的，以及剛生成的Pre-Master隨機數。經過這三個隨機數，能夠在客戶端和服務器產生相同的對稱密鑰。

有了對稱密鑰，客戶端就能夠說：「Change Cipher Spec，我們之後都採用協商的通訊密鑰和加密算法進行加密通訊了。」

而後客戶端發送一個Encrypted Handshake Message，將已經商定好的參數等，採用協商密鑰進行加密，發送給服務器用於數據與握手驗證。

一樣，服務器也能夠發送Change Cipher Spec，說：「沒問題，我們之後都採用協商的通訊密鑰和加密算法進行加密通訊了」，而且也發送Encrypted Handshake Message的消息試試。

當雙方握手結束以後，就能夠經過對稱密鑰進行加密傳輸了。

5、唐王素酒送三藏

玄奘這個網絡包要發出了。

太宗設朝，彙集文武，要去送行。李世民送給玄奘三個東西。

上一節說了太宗是應用層，關注保大唐江山永固，玄奘是TCP層，要經過堅決的意志到達西天。

李世民給的第一個東西是通關文牒，這個是IP層的，未來要經過這個文牒經過一個個城關。

第二個東西是紫金鉢盂，這個用於玄奘法師到了某個城市裏面化齋，同時打聽路的時候使用，這個是一個MAC層的。

第三個東西是白馬一匹，做爲遠程腳力，這個是物理層的。

最後，太宗敬了玄奘一杯素酒，言道：寧戀本鄉一捻土，莫愛他鄉萬兩金。三藏方悟捻土之意，復謝恩飲盡，辭謝出關而去。

當客戶端和服務端之間創建了鏈接後，接下來就要發送下單請求的網絡包了。

在用戶層發送的是HTTP的網絡包，由於服務端提供的是RESTful API，於是HTTP層發送的就是一個請求。

HTTP的報文大概分爲三大部分。第一部分是請求行，第二部分是請求的首部，第三部分纔是請求的正文實體。

在請求行中，URL就是 www.geektime.com/purchaseOrder ，版本爲HTTP 1.1。

請求的類型叫做POST，它須要主動告訴服務端一些信息，而非獲取。須要告訴服務端什麼呢？通常會放在正文裏面。正文能夠有各類各樣的格式，常見的格式是JSON。

請求行下面就是咱們的首部字段。首部是key value，經過冒號分隔。

Content-Type是指正文的格式。例如，咱們進行POST的請求，若是正文是JSON，那麼咱們就應該將這個值設置爲JSON。

接下來是正文，這裏是一個JSON字符串，裏面經過文本的形式描述了，要買一個課程，做者是誰，多少錢。

這樣，HTTP請求的報文格式就拼湊好了。接下來瀏覽器或者移動App會把它交給下一層傳輸層。

怎麼交給傳輸層呢？也是用Socket進行程序設計。若是用的是瀏覽器，這些程序不須要你本身寫，有人已經幫你寫好了；若是在移動APP裏面，通常會用一個HTTP的客戶端工具來發送，而且幫你封裝好。

HTTP協議是基於TCP協議的，因此它使用面向鏈接的方式發送請求，經過Stream二進制流的方式傳給對方。固然，到了TCP層，它會把二進制流變成一個的報文段發送給服務器。

在TCP頭裏面，會有源端口號和目標端口號，目標端口號通常是服務端監聽的端口號，源端口號在手機端，每每是隨機分配一個端口號。這個端口號在客戶端和服務端用於區分請求和返回，發給那個應用。

在IP頭裏面，都須要加上本身的地址（即源地址）和它想要去的地方（即目標地址）。當一個手機上線的時候，PGW會給這個手機分配一個IP地址，這就是源地址，而目標地址則是雲平臺的負載均衡器的外網IP地址。

在IP層，客戶端須要查看目標地址和本身是不是在同一個局域網，計算是不是同一個網段，每每須要經過CIDR子網掩碼來計算。

對於這個下單場景，目標IP和源IP不會在同一個網段，於是須要發送到默認的網關。通常經過DHCP分配IP地址的時候，也會同時配置默認網關的IP地址。

可是客戶端不會直接使用默認網關的IP地址，而是發送ARP協議，來獲取網關的MAC地址，而後將網關MAC做爲目標MAC，本身的MAC做爲源MAC，放入MAC頭，發送出去。

一個完整的網絡包的格式是這樣的。

接下來，網絡包就正式發出了。

若是你是用手機打開APP，下單購物發送網絡包，通常經過手機運營商的網絡。

客戶的手機開機之後，在附近尋找基站eNodeB，發送請求，申請上網。基站將請求發給MME，MME對手機進行認證和鑑權，還會請求HSS看有沒有錢，看看是在哪裏上網。

當MME經過了手機的認證以後，開始創建隧道，建設的數據通路分兩段路，實際上是兩個隧道。一段是從eNodeB到SGW，第二段是從SGW到PGW，在PGW以外，就是互聯網。

PGW會爲手機分配一個IP地址，手機上網都是帶着這個IP地址的。

對於手機來說，默認的網關在PGW上。在移動網絡裏面，從手機到SGW，到PGW是有一條隧道的。在這條隧道里面，會將上面的這個包做爲隧道的乘客協議放在裏面，外面SGW和PGW在覈心網機房的IP地址。網絡包直到PGW（PGW是隧道的另外一端）纔將裏面的包解出來，轉發到外部網絡。

因此，從手機發送出來的時候，網絡包的結構爲：

• 源MAC：手機也即UE的MAC；

• 目標MAC：網關PGW上面的隧道端點的MAC；

• 源IP：UE的IP地址；

• 目標IP：SLB的公網IP地址。

進入隧道以後，要封裝外層的網絡地址，於是網絡包的格式爲：

• 外層源MAC：E-NodeB的MAC；

• 外層目標MAC：SGW的MAC；

• 外層源IP：E-NodeB的IP；

• 外層目標IP：SGW的IP；

• 內層源MAC：手機也即UE的MAC；

• 內層目標MAC：網關PGW上面的隧道端點的MAC；

• 內層源IP：UE的IP地址；

• 內層目標IP：SLB的公網IP地址。

當隧道在SGW的時候，切換了一個隧道，爲從SGW到PGW的隧道，於是網絡包的格式爲：

• 外層源MAC：SGW的MAC；

• 外層目標MAC：PGW的MAC；

• 外層源IP：SGW的IP；

• 外層目標IP：PGW的IP；

• 內層源MAC：手機也即UE的MAC；

• 內層目標MAC：網關PGW上面的隧道端點的MAC；

• 內層源IP：UE的IP地址；

• 內層目標IP：SLB的公網IP地址。

在PGW的隧道端點將包解出來，轉發出去的時候，通常在PGW出外部網絡的路由器上，會部署NAT服務，將手機的IP地址轉換爲公網IP地址，當請求返回的時候，再NAT回來。

於是在PGW以後，至關於作了一次歐洲十國遊型的轉發，網絡包的格式爲：

• 源MAC：PGW出口的MAC；

• 目標MAC：NAT網關的MAC；

• 源IP：UE的IP地址；

• 目標IP：SLB的公網IP地址。

在NAT網關，至關於作了一次玄奘西遊型的轉發，網絡包的格式變成：

• 源MAC：NAT網關的MAC；

• 目標MAC：A2路由器的MAC；

• 源IP：UE的公網IP地址；

• 目標IP：SLB的公網IP地址。

在手機運營商的網絡裏面，網絡情況是比較好的。

對於玄奘法師，在大唐國境以內，仍是比較平安的。原文說：們行了很多天，到了鞏州城。早有鞏州合屬官吏人等，迎接入城中。安歇一晚上，次早出城前去。一路飢餐渴飲，夜住曉行，兩三日，又至河州衛。早有鎮邊的總兵與本處僧道，聞得是欽差御弟法師上西方見佛，無不恭敬，接至裏面供給了，着僧綱請往福原寺安歇。本寺僧人，一一參見，安排晚齋。齋畢，吩咐二從者飽餵馬匹，天不明就行。

真的是有接有送。

行經半日，只見對面處，有一座大山，真個是高接青霄，崔巍險峻。此山喚作兩界山，東半邊屬我大唐所管，西半邊乃是韃靼的地界。過了這座山，就不是大唐的土地了。

6、歷經千山與萬險

離開大唐的國土，接下來的路應該怎麼走呢？

好在此去西天，要通過一個個國家，每一個國家有一個個城關，玄奘法師只要處處問路，只要這些城關的守門人知道大概路怎麼走，就能一個個國家的走下去，若是遇到國家，還有通關文牒，還能保護玄奘法師在國內的安全。

這裏有兩個問題要解決，第一個是每一個城關的守門人和每一個國家，是怎麼知道去西天怎麼走的。第二個問題是玄奘如何問路，如何走。

咱們先第一個問題，這個觀音菩薩從西天來東土的時候，已經經過一種法術告訴這些國家和城關了。

菩薩的法術主要分兩種狀況，一種狀況是在一個國家內部如何走，另外一種狀況在國家之間，在野外如何走的問題。

在一個國家內部，菩薩主要遵循最短路徑原則，就是走得路越少越好，道路越短越好。

可是國家之間，菩薩不但要考慮遠近的問題，還要考慮政策的問題。例若有的國家路近，可是路過的國家看不慣僧人，見了僧人就抓。例如滅法國，連光頭都要抓。這樣的狀況即使路近，也最好繞遠點走。

菩薩的法術是什麼呢？我們在大學裏面學習計算機網絡與數據結構的時候，知道求最短路徑經常使用的有兩種方法，一種是 Bellman-Ford 算法，一種是 Dijkstra 算法。在計算機網絡中基本也是用這兩種方法計算的。

距離矢量路由（distance vector routing），它是基於 Bellman-Ford 算法的。

鏈路狀態路由（link state routing），基於 Dijkstra 算法。

最經常使用的兩種路由協議：

OSPF（Open Shortest Path First，開放式最短路徑優先）就是這樣一個基於鏈路狀態路由協議，普遍應用在數據中心中的協議，稱爲內部網關協議（Interior Gateway Protocol，簡稱IGP）

BGP 協議使用的算法是路徑矢量路由協議（path-vector protocol）。它是距離矢量路由協議的升級版，稱爲外網路由協議（Border Gateway Protocol，簡稱BGP）

路由協議是城關之間相互溝通到哪裏應該怎麼走的協議。

第二個問題，也就是玄奘如何問路，如何走。這就是IP協議。

這就要靠通關文牒了，裏面寫着貧僧來自東土大唐（就是源IP地址），欲往西天拜佛求經（指的是目標IP地址）。路過寶地，借宿一晚，明日啓行，請問接下來該怎麼走啊？

在解決第一個問題的時候，每一個城關已經經過菩薩的法術，和鄰近的城關進行溝通，知道了下面的信息。

這個叫路由表，根據這個表格，能夠告訴唐僧怎麼走。

接下來咱們看完整故事。

出了NAT網關，就從核心網到達了互聯網。在網絡世界，每個運營商的網絡成爲自治系統AS。每一個自治系統都有邊界路由器，經過它和外面的世界創建聯繫。

對於雲平臺來說，它能夠被稱爲Multihomed AS，有多個鏈接連到其餘的AS，可是大多拒絕幫其餘的AS傳輸包。例如一些大公司的網絡。對於運營商來講，它能夠被稱爲Transit AS，有多個鏈接連到其餘的AS，而且能夠幫助其餘的AS傳輸包，好比主幹網。

如何從出口的運營商到達雲平臺的邊界路由器？在路由器之間須要經過BGP協議實現，BGP又分爲兩類，eBGP和iBGP。自治系統間，邊界路由器之間使用eBGP廣播路由。內部網絡也須要訪問其餘的自治系統。

邊界路由器如何將BGP學習到的路由導入到內部網絡呢？經過運行iBGP，使內部的路由器可以找到到達外網目的地最好的邊界路由器。

網站的SLB的公網IP地址早已經經過雲平臺的邊界路由器，讓全網都知道了。因而這個下單的網絡包選擇了下一跳是A2，也即將A2的MAC地址放在目標MAC地址中。

到達A2以後，從路由表中找到下一跳是路由器C1，因而將目標MAC換成C1的MAC地址。到達C1以後，找到下一跳是C2，將目標MAC地址設置爲C2的MAC。到達C2後，找到下一跳是雲平臺的邊界路由器，因而將目標MAC設置爲邊界路由器的MAC地址。

你會發現，這一路，都是隻換MAC，不換目標IP地址。這就是所謂下一跳的概念。

在雲平臺的邊界路由器，會將下單的包轉發進來，通過核心交換，匯聚交換，到達外網網關節點上的SLB的公網IP地址。

咱們能夠看到，手機到SLB的公網IP，是一個端到端的鏈接，鏈接的過程發送了不少包。全部這些包，不管是TCP三次握手，仍是HTTPS的密鑰交換，都是要走如此複雜的過程到達SLB的，固然每一個包走的路徑不必定一致。

當網絡包走在這個複雜的道路上，極可能一不當心就丟了，怎麼辦？這就須要藉助TCP的機制從新發送。

既然TCP要對包進行重傳，就須要維護一個Sequence Number，看哪些包到了，哪些沒到，哪些須要重傳，傳輸的速度應該控制到多少，這就是TCP的滑動窗口協議。

整個TCP的發送，一開始會協商一個Sequence Number，從這個Sequence Number開始，每一個包都有編號。滑動窗口將接收方的網絡包分紅四個部分：

• 已經接收，已經ACK，已經交給應用層的包；

• 已經接收，已經ACK，未發送給應用層；

• 已經接收，還沒有發送ACK；

• 未接收，尚有空閒的緩存區域。

對於TCP層來說，每個包都有ACK。ACK須要從SLB回覆到手機端，將上面的那個過程反向來一遍，固然路徑不必定一致，可見ACK也不是那麼輕鬆的事情。

若是發送方超過必定的時間沒有收到ACK，就會從新發送。只有TCP層ACK過的包，纔會發給應用層，而且只會發送一份，對於下單的場景，應用層是HTTP層。

你可能會問了，TCP總是重複發送，會不會致使一個單下了兩遍？是否要求服務端實現冪？從TCP的機制來看，是不會的。只有收不到ACK的包纔會重複發，發到接收端，在窗口裏面只保存一份，因此在同一個TCP鏈接中，不用擔憂重傳致使二次下單。

可是TCP鏈接會由於某種緣由斷了，例如手機信號很差，這個時候手機把全部的動做從新作一遍，創建一個新的TCP鏈接，在HTTP層調用兩次RESTful API。這個時候可能會致使兩遍下單的狀況，於是RESTful API須要實現冪等。

當ACK過的包發給應用層以後，TCP層的緩存就空了出來，這會致使上面圖中的大三角，也即接收方可以容納的總緩存，總體順時針滑動。小的三角形，也即接收方告知發送方的窗口總大小，也即尚未徹底確認收到的緩存大小，若是把這些填滿了，就不能再發了，由於沒確認收到，因此一個都不能扔。

7、功成行滿見真如

唐僧經歷九九八十一難，終於到達了西天。發現金頂大仙已經在等他們了。

網絡包從手機端經歷千難萬險，終於到了SLB的公網IP所在的公網網口。因爲匹配上了MAC地址和IP地址，於是將網絡包收了進來。

到了西天，唐僧度過最後一條河凌雲仙渡的時候，發現滾浪飛流，約有八九里寬闊，四無人跡。好不容易盼來一條船，尚未底。原來駕船的是接引佛祖，玄奘法師的肉體隨着河水飄走，從而脫胎換骨，成就金身。

在虛擬網關節點的外網網口上，會有一個NAT規則，將公網IP地址轉換爲VPC裏面的私網IP地址，這個私網IP地址就是SLB的HAProxy所在的虛擬機的私網IP地址。

從而網絡包也脫胎換骨，實現公網IP到私有網絡IP的轉換。

固然爲了承載比較大的吞吐量，虛擬網關節點會有多個，物理網絡會將流量分發到不一樣的虛擬網關節點。一樣HAProxy也會是一個大的集羣，虛擬網關會選擇某個負載均衡節點，將某個請求分發給它，負載均衡以後是Controller層，也是部署在虛擬機裏面的。

當網絡包裏面的目標IP變成私有IP地址地址以後，虛擬路由會查找路由規則，將網絡包從下方的私網網口發出來。這個時候包的格式爲：

• 源MAC：網關MAC；

• 目標MAC：HAProxy虛擬機的MAC；

• 源IP：UE的公網IP；

• 目標IP：HAProxy虛擬機的私網IP。

在第一部分，咱們 說佛經是存放在一個虛擬空間裏面的，要打開這個虛擬空間，解讀經文，須要一個芝麻開門的ID。接引佛祖會給玄奘法師一個ID。

在虛擬路由節點上，也會有OVS，將網絡包封裝在VXLAN隧道里面，VXLAN ID就是給你的租戶建立VPC的時候分配的。VXLAN ID就是VPC虛擬空間的ID，OVS就是那個可以封裝和解開私密空間的法寶。

包的格式爲：

• 外層源MAC：網關物理機MAC；

• 外層目標MAC：物理機A的MAC；

• 外層源IP：網關物理機IP；

• 外層目標IP：物理機A的IP；

• 內層源MAC：網關MAC；

• 內層目標MAC：HAProxy虛擬機的MAC；

• 內層源IP：UE的公網IP；

• 內層目標IP：HAProxy虛擬機的私網IP。

在物理機A上，OVS會將包從VXLAN隧道里面解出來，發給HAProxy所在的虛擬機。HAProxy所在的虛擬機發現MAC地址匹配，目標IP地址匹配，就根據TCP端口，將包發給HAProxy進程，由於HAProxy是在監聽這個TCP端口的。於是HAProxy就是這個TCP鏈接的服務端，客戶端是手機。對於TCP的鏈接狀態，滑動窗口等，都是在HAProxy上維護的。

在這裏HAProxy是一個四層負載均衡，也即他只解析到TCP層，裏面的HTTP協議他不關心，就將請求轉發給後端的多個Controller層的一個。

HAProxy發出去的網絡包就認爲HAProxy是客戶端了，看不到手機端了。網絡包格式以下：

• 源MAC：HAProxy所在虛擬機的MAC；

• 目標MAC：Controller層所在虛擬機的MAC；

• 源IP：HAProxy所在虛擬機的私網IP；

• 目標IP：Controller層所在虛擬機的私網IP。

固然這個包發出去以後，仍是會被物理機上的OVS放入VXLAN隧道里面，網絡包格式爲：

• 外層源MAC：物理機A的MAC；

• 外層目標MAC：物理機B的MAC；

• 外層源IP：物理機A的IP；

• 外層目標IP：物理機B的IP；

• 內層源MAC：HAProxy所在虛擬機的MAC；

• 內層目標MAC：Controller層所在虛擬機的MAC；

• 內層源IP：HAProxy所在虛擬機的私網IP；

• 內層目標IP：Controller層所在虛擬機的私網IP。

在物理機B上，OVS會將包從VXLAN隧道里面解出來，發給Controller層所在的虛擬機。Controller層所在的虛擬機發現MAC地址匹配，目標IP地址匹配，就根據TCP端口，將包發給Controller層的進程，由於他是在監聽這個TCP端口的。

在HAProxy和Controller層之間，維護一個TCP的鏈接。

Controller層收到包以後，他是關心HTTP裏面是什麼的，因而解開HTTP的包，發現是一個POST請求，內容是下單購買一個課程。

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。

8、取得真經成金身

玄奘法師終於到達西天大雷音寺，見到了我佛如來。

佛祖願意傳經給玄奘，因而讓玄奘去藏經樓取經文，誰知道西天也有西天的規矩，若是不懂這裏的規矩，就很難和管理經文的人溝通，取不到真經。

同理，在電商服務裏面，每每在組合服務層會有一個專門管理下單的服務，Controller層雖然對外暴露的是標準的RESTful協議，可是對內會經過RPC協議調用這個組合服務層。若是不懂這個協議，就無法通訊。

假設咱們使用的是Dubbo，則Controller層須要讀取註冊中心，將下單服務的進程列表拿出來，選出一個來調用。

Dubbo中默認的RPC協議是Hessian2。Hessian2將下單的遠程調用序列化爲二進制進行傳輸。

Netty是一個非阻塞的基於事件的網絡傳輸框架。Controller層和下單服務之間，使用了Netty的網絡傳輸框架。有了Netty，就不用本身編寫複雜的異步Socket程序了。Netty使用的方式，就是我們講Socket編程的時候，一個項目組支撐多個項目（IO多路複用，從派人盯着到有事通知）這種方式。

Netty仍是工做在Socket這一層的，發送的網絡包仍是基於TCP的。在TCP的下層，仍是須要封裝上IP頭和MAC頭。若是跨物理機通訊，仍是須要封裝的外層的VXLAN隧道里面。固然底層的這些封裝，Netty都不感知，它只要作好它的異步通訊便可。

在Netty的服務端，也即下單服務中，收到請求後，先用Hessian2的格式進行解壓縮。而後將請求分發到線程中進行處理，在線程中，會調用下單的業務邏輯。

玄奘師徒好在後來碰到了懂得內情的註冊中心——彌勒佛，從而會到靈山，仍是按照人家的規矩辦了，纔將無字經文，換成有字經文。

下單的業務邏輯比較複雜，每每要調用基礎服務層裏面的庫存服務、優惠券服務等，將多個服務調用完畢，纔算下單成功。下單服務調用庫存服務和優惠券服務，也是經過Dubbo的框架，經過註冊中心拿到庫存服務和優惠券服務的列表，而後選一個調用。

調用的時候，統一使用Hessian2進行序列化，使用Netty進行傳輸，底層若是跨物理機，仍然須要經過VXLAN的封裝和解封裝。

我們以庫存爲例子的時候，講述過冪等的接口實現的問題。由於若是扣減庫存，僅僅是誰調用誰減一。這樣存在的問題是，若是扣減庫存由於一次調用失敗，而屢次調用，這裏指的不是TCP屢次重試，而是應用層調用的屢次重試，就會存在庫存扣減屢次的狀況。

這裏經常使用的方法是，使用樂觀鎖（Compare and Set，簡稱CAS）。CAS要考慮三個方面，當前的庫存數、預期原來的庫存數和版本，以及新的庫存數。在操做以前，查詢出原來的庫存數和版本，真正扣減庫存的時候，判斷若是當前庫存的值與預期原值和版本相匹配，則將庫存值更新爲新值，不然不作任何操做。

這是一種基於狀態而非基於動做的設計，符合REST的架構設計原則。這樣的設計有利於高併發場景。當多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程並不會被掛起，而是被告知此次競爭中失敗，並能夠再次嘗試。

最終，當下單更新到分佈式數據庫中以後，整個下單過程纔算真正告一段落。

固然，這個下單調用要返回一個結果。

咱們下單成功啦！！！！！！

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。