通過一個字符的傳輸來講解網絡通信

我們開發的面向普通用戶的應用程序，目前看來幾乎都是互聯網應用程序，也就是說，用戶操作的應用程序，不管是瀏覽器還是移動App，核心請求都會通過互聯網發送到后端的數據中心進行處理。

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

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

這個字符如何穿越遙遠的空間，從手機發送到淘寶的數據中心，在淘寶計算得到相關的結果，然后將結果再返回到我們的手機上，從而完成自己的互聯網之旅呢？

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

但是由于我們現在開發的應用主要是互聯網應用，它們構建在網絡通信基礎上，網絡通信的問題可能會出現在系統運行的任何時刻。

了解網絡通信原理，了解互聯網應用如何跨越龐大的網絡構建起來，對我們開發一個互聯網應用系統很有幫助，對我們解決系統運行過程中各種因為網絡通信而出現的各種問題更有幫助。

DNS

我們先從DNS說起。

構成互聯網Internet的最基本的網絡協議就是互聯網協議Internet Protocol，簡稱IP協議。IP協議里面最重要的部分是IP地址，各種計算機設備之間能夠互相通信，首先要能夠找到彼此，IP地址就是互聯網的地址標識。

手機上的淘寶App能夠訪問淘寶的數據中心，就是知道了淘寶數據中心負責請求接入的服務器的IP地址，然后建立網絡連接，進而處理請求數據。

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

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

CDN

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

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

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

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

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

HTTP

不管發送到CDN還是數據中心，App請求都會以HTTP協議發送。

HTTP是一個應用層協議，當我們進行網絡通信編程的時候，通常需要關注兩方面的內容，一方面是應用層的通信協議，主要是我們通信的數據如何編碼，既能使網絡傳輸過去的數據攜帶必要的信息，又使通信的兩方都能正確識別這些數據，即通信雙方應用程序需要約定一個數據編碼協議。另一方面就是網絡底層通信協議，即如何為網絡上需要通信的兩個節點建立連接完成數據傳輸，目前互聯網應用中最主要的就是TCP協議。

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

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

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

這是HTTP響應頭的例子，響應頭和請求頭一樣包含各種參數，而status狀態碼聲明響應狀態，狀態碼是200，表示響應正常。

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

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

TCP

應用程序使用操作系統的socket接口進行網絡編程，socket里封裝了TCP協議。應用程序通過socket接口使用TCP協議完成網絡編程，socket或者TCP在應用程序看就是一個底層通信協議，事實上，TCP僅僅是一個傳輸層協議，在傳輸層協議之下，還有網絡層協議，網絡層協議之下還有數據鏈路層協議，數據鏈路層協議之下還有物理層協議。

傳輸層協議TCP和網絡層協議IP共同構成TCP/IP協議棧，成為互聯網應用開發最主要的通信協議。OSI開放系統互聯模型將網絡協議定義了7層，TCP/IP協議棧將OSI頂部三層協議應用層、表示層、會話層合并為一個應用層，HTTP協議就是TCP/IP協議棧中的應用層協議。

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

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

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

前面已經提到，網絡層IP協議使得互聯網應用根據IP地址就能訪問到淘寶的數據中心，請求離開App后，到達運營服務商的交換機，交換機會根據這個IP地址進行路由轉發，可能中間會經過很多個轉發節點，最后數據到達淘寶的服務器。

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

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

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

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

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

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

LB（負載均衡）

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

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

負載均衡服務器的實現手段有很多種，淘寶這樣規模的應用，通常使用Linux內核支持的鏈路層負載均衡。

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

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

總結

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

這些分布式緩存集群或者搜索引擎集群都需要通過RPC遠程過程調用的方式進行調用請求，也就是需要通過網絡進行服務調用，這些網絡服務也都是基于TCP協議進行編程的。

對于互聯網應用，用戶請求數據離開手機通過各種網絡通信，最后到達數據中心的應用服務器進行最后的計算、處理，中間會經過許多環節，事實上，這些環節就構成了互聯網系統的整體架構，所以通過網絡通信，可以將整個互聯網應用系統串起來，對理解互聯網系統的技術架構很有幫助，在程序開發、運行過程中遇到各種網絡相關問題，也可以快速分析問題原因，快速解決問題。