通過一個字符的傳輸來講解網(wǎng)絡(luò)通信

我們開發(fā)的面向普通用戶的應(yīng)用程序，目前看來幾乎都是互聯(lián)網(wǎng)應(yīng)用程序，也就是說，用戶操作的應(yīng)用程序，不管是瀏覽器還是移動App，核心請求都會通過互聯(lián)網(wǎng)發(fā)送到后端的數(shù)據(jù)中心進行處理。

這個數(shù)據(jù)中心可能是像微信這樣的自己建設(shè)的、在多個地區(qū)部署的大規(guī)模機房，也可能是阿里云這樣的云服務(wù)商提供的一個虛擬主機。

但是不管這個數(shù)據(jù)中心的大小，應(yīng)用程序都需要在運行期和數(shù)據(jù)中心交互。比如我們在淘寶的搜索框隨便輸入一個字符“a”，就會在屏幕上看到一大堆商品。那么我們的手機是如何通過互聯(lián)網(wǎng)完成這一操作的？

這個字符如何穿越遙遠的空間，從手機發(fā)送到淘寶的數(shù)據(jù)中心，在淘寶計算得到相關(guān)的結(jié)果，然后將結(jié)果再返回到我們的手機上，從而完成自己的互聯(lián)網(wǎng)之旅呢？

雖然我們在編程的時候，很少要自己直接開發(fā)網(wǎng)絡(luò)通信代碼，服務(wù)器由Tomcat這樣的WEB容器管理網(wǎng)絡(luò)通信，服務(wù)間網(wǎng)絡(luò)通信通過Dubbo這樣的分布式服務(wù)框架完成網(wǎng)絡(luò)通信。

但是由于我們現(xiàn)在開發(fā)的應(yīng)用主要是互聯(lián)網(wǎng)應(yīng)用，它們構(gòu)建在網(wǎng)絡(luò)通信基礎(chǔ)上，網(wǎng)絡(luò)通信的問題可能會出現(xiàn)在系統(tǒng)運行的任何時刻。

了解網(wǎng)絡(luò)通信原理，了解互聯(lián)網(wǎng)應(yīng)用如何跨越龐大的網(wǎng)絡(luò)構(gòu)建起來，對我們開發(fā)一個互聯(lián)網(wǎng)應(yīng)用系統(tǒng)很有幫助，對我們解決系統(tǒng)運行過程中各種因為網(wǎng)絡(luò)通信而出現(xiàn)的各種問題更有幫助。

DNS

我們先從DNS說起。

構(gòu)成互聯(lián)網(wǎng)Internet的最基本的網(wǎng)絡(luò)協(xié)議就是互聯(lián)網(wǎng)協(xié)議Internet Protocol，簡稱IP協(xié)議。IP協(xié)議里面最重要的部分是IP地址，各種計算機設(shè)備之間能夠互相通信，首先要能夠找到彼此，IP地址就是互聯(lián)網(wǎng)的地址標識。

手機上的淘寶App能夠訪問淘寶的數(shù)據(jù)中心，就是知道了淘寶數(shù)據(jù)中心負責(zé)請求接入的服務(wù)器的IP地址，然后建立網(wǎng)絡(luò)連接，進而處理請求數(shù)據(jù)。

那么手機上的淘寶App如何知道數(shù)據(jù)中心服務(wù)器的IP地址呢？當(dāng)然淘寶的工程師可以在App里寫死這個IP地址，但是這樣做會帶來很多問題，比如影響編程的靈活性以及程序的可用性等。

事實上這個IP地址是通過DNS域名解析服務(wù)器得到的。當(dāng)我們打開淘寶App的時候，淘寶要把App首頁加載進來，這時候就需要連接域名服務(wù)器進行域名解析，將xxx.taobao.com這樣的域名解析為一個IP地址，然后連接目標服務(wù)器。

CDN

事實上DNS解析出來的IP地址，并不一定是淘寶數(shù)據(jù)中心的IP地址，也可能是淘寶CDN服務(wù)器的IP地址。

CDN是內(nèi)容分發(fā)網(wǎng)絡(luò)Content Delivery Network的縮寫。我們能夠用手機或者電腦上網(wǎng)，是因為運營服務(wù)商為我們提供了互聯(lián)網(wǎng)接入服務(wù)，將我們的手機和電腦連接到互聯(lián)網(wǎng)上。App請求的數(shù)據(jù)最先到達的是運營服務(wù)商的機房，然后運營商通過自己建設(shè)的骨干網(wǎng)絡(luò)和交換節(jié)點，將我們請求數(shù)據(jù)的目的地址發(fā)往互聯(lián)網(wǎng)的任何地方。

為了提高用戶請求訪問的速度，也為了降低數(shù)據(jù)中心的負載壓力，淘寶會在全國各地各個主要的運營服務(wù)商的接入機房中部署一些緩存服務(wù)器，緩存那些靜態(tài)的圖片、資源文件等，這些緩存服務(wù)器構(gòu)成了淘寶的CDN。

如果用戶請求的數(shù)據(jù)數(shù)據(jù)是靜態(tài)的資源，這些資源的URL通常以image.taobao.com之類的二級域名進行標識，域名解析的時候就會解析為淘寶CDN的IP地址，請求先被CDN處理，如果CDN中有需要的靜態(tài)文件，就直接返回，如果沒有，CDN會將請求發(fā)送到淘寶的數(shù)據(jù)中心，CDN從淘寶數(shù)據(jù)中心獲得靜態(tài)文件后，一方面緩存在自己的服務(wù)器上，一方面將數(shù)據(jù)返回給用戶的App。

而如果請求的數(shù)據(jù)是動態(tài)的，比如要搜索關(guān)鍵詞為“a”的商品列表，請求的域名可能會是search.taobao.com這樣的二級域名，就會直接被DNS解析為淘寶的數(shù)據(jù)中心的服務(wù)器IP地址，App請求發(fā)送到數(shù)據(jù)中心處理。

HTTP

不管發(fā)送到CDN還是數(shù)據(jù)中心，App請求都會以HTTP協(xié)議發(fā)送。

HTTP是一個應(yīng)用層協(xié)議，當(dāng)我們進行網(wǎng)絡(luò)通信編程的時候，通常需要關(guān)注兩方面的內(nèi)容，一方面是應(yīng)用層的通信協(xié)議，主要是我們通信的數(shù)據(jù)如何編碼，既能使網(wǎng)絡(luò)傳輸過去的數(shù)據(jù)攜帶必要的信息，又使通信的兩方都能正確識別這些數(shù)據(jù)，即通信雙方應(yīng)用程序需要約定一個數(shù)據(jù)編碼協(xié)議。另一方面就是網(wǎng)絡(luò)底層通信協(xié)議，即如何為網(wǎng)絡(luò)上需要通信的兩個節(jié)點建立連接完成數(shù)據(jù)傳輸，目前互聯(lián)網(wǎng)應(yīng)用中最主要的就是TCP協(xié)議。

在TCP傳輸層協(xié)議層面，就是保證建立通信兩方的穩(wěn)定通信連接，將一方的數(shù)據(jù)以bit流的方式源源不斷地發(fā)送到另一方，至于這些數(shù)據(jù)代表什么意思，哪里是兩次請求的分界點，TCP協(xié)議統(tǒng)統(tǒng)不管，需要應(yīng)用層面自己解決。如果我們基于TCP協(xié)議自己開發(fā)應(yīng)用程序，就必須解決這些問題。而互聯(lián)網(wǎng)應(yīng)用需要在全球范圍為用戶提供服務(wù)，將全球的應(yīng)用和全球的用戶聯(lián)系在一起，需要一個統(tǒng)一的應(yīng)用層協(xié)議，這個協(xié)議就是HTTP協(xié)議。

這張圖是HTTP的請求頭的例子，包括請求方法和請求頭參數(shù)。請求方法主要有GET、POST，這是我們最常用的兩種，此外還有DELETE、PUT、HEAD、TRACE等幾種方法；請求頭參數(shù)包括緩存控制Cache-Control、響應(yīng)過期時間Expires、Cookie等等。

HTTP請求如果是GET方法，那么就只有請求頭；如果是POST方法，在請求頭之后還有一個body部分，包含請求提交的內(nèi)容，HTTP會在請求頭的Content-Length參數(shù)聲明body的長度。

這是HTTP響應(yīng)頭的例子，響應(yīng)頭和請求頭一樣包含各種參數(shù)，而status狀態(tài)碼聲明響應(yīng)狀態(tài)，狀態(tài)碼是200，表示響應(yīng)正常。

響應(yīng)狀態(tài)碼是3XX，表示請求被重定向，常用的302，表示請求被臨時重定向到新的URL，響應(yīng)頭中包含新的臨時URL，客戶端收到響應(yīng)后，重新請求這個新的URL；狀態(tài)碼是4XX，表示客戶端錯誤，常見的403，表示請求未授權(quán)，被禁止訪問，404表示請求的頁面不存在；狀態(tài)碼是5XX，表示服務(wù)器異常，常見的500請求未完成，502請求處理超時，503服務(wù)器過載。

如果響應(yīng)正常，那么在響應(yīng)頭之后就是響應(yīng)body，瀏覽器的響應(yīng)body通常是一個HTML頁面，App的響應(yīng)body通常是個JSON字符串。

TCP

應(yīng)用程序使用操作系統(tǒng)的socket接口進行網(wǎng)絡(luò)編程，socket里封裝了TCP協(xié)議。應(yīng)用程序通過socket接口使用TCP協(xié)議完成網(wǎng)絡(luò)編程，socket或者TCP在應(yīng)用程序看就是一個底層通信協(xié)議，事實上，TCP僅僅是一個傳輸層協(xié)議，在傳輸層協(xié)議之下，還有網(wǎng)絡(luò)層協(xié)議，網(wǎng)絡(luò)層協(xié)議之下還有數(shù)據(jù)鏈路層協(xié)議，數(shù)據(jù)鏈路層協(xié)議之下還有物理層協(xié)議。

傳輸層協(xié)議TCP和網(wǎng)絡(luò)層協(xié)議IP共同構(gòu)成TCP/IP協(xié)議棧，成為互聯(lián)網(wǎng)應(yīng)用開發(fā)最主要的通信協(xié)議。OSI開放系統(tǒng)互聯(lián)模型將網(wǎng)絡(luò)協(xié)議定義了7層，TCP/IP協(xié)議棧將OSI頂部三層協(xié)議應(yīng)用層、表示層、會話層合并為一個應(yīng)用層，HTTP協(xié)議就是TCP/IP協(xié)議棧中的應(yīng)用層協(xié)議。

物理層負責(zé)數(shù)據(jù)的物理傳輸，計算機輸入輸出的只能是0 1這樣的二進制數(shù)據(jù)，但是在真正的通信線路里有光纖、電纜、無線各種設(shè)備。光信號和電信號，以及無線電磁信號在物理上是完全不同的，如何讓這些不同的設(shè)備能夠理解、處理相同的二進制數(shù)據(jù)，這就是物理層要解決的問題。

數(shù)據(jù)鏈路層就是將數(shù)據(jù)進行封裝后交給物理層進行傳輸，主要就是將數(shù)據(jù)封裝成數(shù)據(jù)幀，以幀為單位通過物理層進行通信，有了幀，就可以在幀上進行數(shù)據(jù)校驗，進行流量控制。數(shù)據(jù)鏈路層會定義幀的大小，這個大小也被稱為最大傳輸單元。

像HTTP要在傳輸?shù)臄?shù)據(jù)上添加一個HTTP頭一樣，數(shù)據(jù)鏈路層也會將封裝好的幀添加一個幀頭，幀頭里記錄的一個重要信息就是發(fā)送者和接受者的mac地址。mac地址是網(wǎng)卡的設(shè)備標識符，是唯一的，數(shù)據(jù)幀通過這個信息確保數(shù)據(jù)送達到正確的目標機器。

前面已經(jīng)提到，網(wǎng)絡(luò)層IP協(xié)議使得互聯(lián)網(wǎng)應(yīng)用根據(jù)IP地址就能訪問到淘寶的數(shù)據(jù)中心，請求離開App后，到達運營服務(wù)商的交換機，交換機會根據(jù)這個IP地址進行路由轉(zhuǎn)發(fā)，可能中間會經(jīng)過很多個轉(zhuǎn)發(fā)節(jié)點，最后數(shù)據(jù)到達淘寶的服務(wù)器。

網(wǎng)絡(luò)層的數(shù)據(jù)需要交給鏈路層進行處理，而鏈路層幀的大小定義了最大傳輸單元，網(wǎng)絡(luò)層的IP數(shù)據(jù)包必須要小于最大傳輸單元才能進行網(wǎng)絡(luò)傳輸，這個數(shù)據(jù)包也有一個IP頭，主要包括的就是發(fā)送者和接受者的IP地址。

IP協(xié)議不是一個可靠的通信協(xié)議，并不會確保數(shù)據(jù)一定送達。要保證通信的穩(wěn)定可靠，需要傳輸層協(xié)議TCP。TCP協(xié)議在傳輸正式數(shù)據(jù)前，會先建立連接，這就是著名的TCP三次握手。

App和服務(wù)器之間發(fā)送三次報文才會建立一個TCP連接，報文中的SYN表示請求建立連接，ACK表示確認。App先發(fā)送 SYN=1，Seq=X的報文，表示請求建立連接，X是一個隨機數(shù)；淘寶服務(wù)器收到這個報文后，應(yīng)答SYN=1，ACK=X+1，Seq=Y的報文，表示同意建立連接；App收到這個報文后，檢查ACK的值為自己發(fā)送的Seq值+1，確認建立連接，并發(fā)送ACK=Y+1的報文給服務(wù)器；服務(wù)器收到這個報文后檢查ACK值為自己發(fā)送的Seq值+1，確認建立連接。至此，App和服務(wù)器建立起TCP連接，就可以進行數(shù)據(jù)傳輸了。

TCP也會在數(shù)據(jù)包上添加TCP頭，TCP頭除了包含一些用于校驗數(shù)據(jù)正確性和控制數(shù)據(jù)流量的信息外，還包含通信端口信息，一臺機器可能同時有很多進程在進行網(wǎng)絡(luò)通信。如何使數(shù)據(jù)到達服務(wù)器后能發(fā)送給正確的進程去處理，就需要靠通信端口進行標識了。HTTP默認端口是80，當(dāng)然我們可以在啟動HTTP應(yīng)用服務(wù)器進程的時候，隨便定義一個數(shù)字作為HTTP應(yīng)用服務(wù)器進程的監(jiān)聽端口，但是App在請求的時候，必須在URL中包含這個端口，才能在構(gòu)建的TCP包中記錄這個端口，也才能在到達服務(wù)器后，被正確的HTTP服務(wù)器進程處理。

如果我們以POST方法提交一個搜索請求給淘寶服務(wù)器，那么最終在數(shù)據(jù)鏈路層構(gòu)建出來的數(shù)據(jù)幀大概是這個樣子，這里假設(shè)IP數(shù)據(jù)包的大小沒有超過鏈路層的最大傳輸單元。

App要發(fā)送的數(shù)據(jù)只是key="a"這樣一個JSON字符串，每一層協(xié)議都會在上一層協(xié)議基礎(chǔ)上添加一個頭部信息，最后封裝成一個鏈路層的數(shù)據(jù)幀在網(wǎng)絡(luò)上傳輸，發(fā)送給淘寶的服務(wù)器。淘寶的服務(wù)器在收到這個數(shù)據(jù)幀后，在通信協(xié)議的每一層進行校驗檢查，確保數(shù)據(jù)準確后，將頭部信息刪除，再交給自己的上一層協(xié)議處理。HTTP應(yīng)用服務(wù)器在最上層，負責(zé)HTTP協(xié)議的處理，最后將key="a"這個JSON字符串交給淘寶工程師開發(fā)的應(yīng)用程序處理。

LB（負載均衡）

HTTP請求到達淘寶數(shù)據(jù)中心的時候，事實上也并不是直接發(fā)送給搜索服務(wù)器處理。因為對于淘寶這樣日活用戶數(shù)億的互聯(lián)網(wǎng)應(yīng)用而言，每時每刻都有大量的搜索請求到達數(shù)據(jù)中心，為了使這些海量的搜索請求都能得到及時處理，淘寶會部署一個由數(shù)千臺服務(wù)器組成的搜索服務(wù)器集群，共同為這些高并發(fā)的請求提供服務(wù)。

因此，搜索請求到達數(shù)據(jù)中心的時候，首先到達的是搜索服務(wù)器集群的負載均衡服務(wù)器，也就是說，DNS解析出來的是負載均衡服務(wù)器的IP地址。然后，由負載均衡服務(wù)器將請求分發(fā)到搜索服務(wù)器集群中的某臺服務(wù)器上。

負載均衡服務(wù)器的實現(xiàn)手段有很多種，淘寶這樣規(guī)模的應(yīng)用，通常使用Linux內(nèi)核支持的鏈路層負載均衡。

這種負載均衡模式也叫直接路由模式，在負載均衡服務(wù)器的Linux操作系統(tǒng)內(nèi)核拿到數(shù)據(jù)包后，直接修改數(shù)據(jù)幀中的mac地址，將其修改為搜索服務(wù)器集群中某個服務(wù)器的mac地址，然后將數(shù)據(jù)重新發(fā)送回服務(wù)器集群所在的局域網(wǎng)，這個數(shù)據(jù)幀就會被某個真實的搜索服務(wù)器接收到。

負載均衡服務(wù)器和集群內(nèi)的搜索服務(wù)器配置相同的虛擬IP地址，也就是說，在網(wǎng)絡(luò)通信的IP層面，負載均衡服務(wù)器變更mac地址的操作是透明的，不影響TCP/IP的通信連接。所以真實的搜索服務(wù)器處理完搜索請求，發(fā)送應(yīng)答響應(yīng)的時候，就會直接發(fā)送回請求的App手機，不會再經(jīng)過負載均衡服務(wù)器。

總結(jié)

事實上，這個搜索字符“a”的互聯(lián)網(wǎng)之旅到這里還沒有結(jié)束。淘寶搜索服務(wù)器程序在收到這個搜索請求的時候，首先在本地緩存中查找是否有對應(yīng)的搜索結(jié)果。如果沒有，會將這個搜索請求，也就是這個字符發(fā)送給一個分布式緩存集群查找是否有對應(yīng)的搜索結(jié)果。如果還沒有，才會將這個請求發(fā)送給一個更大規(guī)模的搜索引擎集群去查找。

這些分布式緩存集群或者搜索引擎集群都需要通過RPC遠程過程調(diào)用的方式進行調(diào)用請求，也就是需要通過網(wǎng)絡(luò)進行服務(wù)調(diào)用，這些網(wǎng)絡(luò)服務(wù)也都是基于TCP協(xié)議進行編程的。

對于互聯(lián)網(wǎng)應(yīng)用，用戶請求數(shù)據(jù)離開手機通過各種網(wǎng)絡(luò)通信，最后到達數(shù)據(jù)中心的應(yīng)用服務(wù)器進行最后的計算、處理，中間會經(jīng)過許多環(huán)節(jié)，事實上，這些環(huán)節(jié)就構(gòu)成了互聯(lián)網(wǎng)系統(tǒng)的整體架構(gòu)，所以通過網(wǎng)絡(luò)通信，可以將整個互聯(lián)網(wǎng)應(yīng)用系統(tǒng)串起來，對理解互聯(lián)網(wǎng)系統(tǒng)的技術(shù)架構(gòu)很有幫助，在程序開發(fā)、運行過程中遇到各種網(wǎng)絡(luò)相關(guān)問題，也可以快速分析問題原因，快速解決問題。