談談一個字符的網(wǎng)路旅程

我們開發(fā)的面向普通用戶的應用程序，目前看來幾乎都是互聯(lián)網(wǎng)應用程序，也就是說，用戶操作的應用程序，不管是瀏覽器還是移動App，核心請求都會通過互聯(lián)網(wǎng)發(fā)送到后端的數(shù)據(jù)中心進行處理。這個數(shù)據(jù)中心可能是像微信這樣的自己建設的、在多個地區(qū)部署的大規(guī)模機房，也可能是阿里云這樣的云服務商提供的一個虛擬主機。

但是不管這個數(shù)據(jù)中心的大小，應用程序都需要在運行期和數(shù)據(jù)中心交互。比如我們在淘寶的搜索框隨便輸入一個字符“a”，就會在屏幕上看到一大堆商品。那么我們的手機是如何通過互聯(lián)網(wǎng)完成這一操作的？這個字符如何穿越遙遠的空間，從手機發(fā)送到淘寶的數(shù)據(jù)中心，在淘寶計算得到相關的結果，然后將結果再返回到我們的手機上，從而完成自己的互聯(lián)網(wǎng)之旅呢？

雖然我們在編程的時候，很少要自己直接開發(fā)網(wǎng)絡通信代碼，服務器由Tomcat這樣的WEB容器管理網(wǎng)絡通信，服務間網(wǎng)絡通信通過Dubbo這樣的分布式服務框架完成網(wǎng)絡通信。但是由于我們現(xiàn)在開發(fā)的應用主要是互聯(lián)網(wǎng)應用，它們構建在網(wǎng)絡通信基礎上，網(wǎng)絡通信的問題可能會出現(xiàn)在系統(tǒng)運行的任何時刻。了解網(wǎng)絡通信原理，了解互聯(lián)網(wǎng)應用如何跨越龐大的網(wǎng)絡構建起來，對我們開發(fā)一個互聯(lián)網(wǎng)應用系統(tǒng)很有幫助，對我們解決系統(tǒng)運行過程中各種因為網(wǎng)絡通信而出現(xiàn)的各種問題更有幫助。

DNS

我們先從DNS說起。

構成互聯(lián)網(wǎng)Internet的最基本的網(wǎng)絡協(xié)議就是互聯(lián)網(wǎng)協(xié)議Internet Protocol，簡稱IP協(xié)議。IP協(xié)議里面最重要的部分是IP地址，各種計算機設備之間能夠互相通信，首先要能夠找到彼此，IP地址就是互聯(lián)網(wǎng)的地址標識。手機上的淘寶App能夠訪問淘寶的數(shù)據(jù)中心，就是知道了淘寶數(shù)據(jù)中心負責請求接入的服務器的IP地址，然后建立網(wǎng)絡連接，進而處理請求數(shù)據(jù)。

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

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

CDN

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

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

為了提高用戶請求訪問的速度，也為了降低數(shù)據(jù)中心的負載壓力，淘寶會在全國各地各個主要的運營服務商的接入機房中部署一些緩存服務器，緩存那些靜態(tài)的圖片、資源文件等，這些緩存服務器構成了淘寶的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)文件后，一方面緩存在自己的服務器上，一方面將數(shù)據(jù)返回給用戶的App。

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

HTTP

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

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

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

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

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

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

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

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

TCP

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

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

物理層負責數(shù)據(jù)的物理傳輸，計算機輸入輸出的只能是0 1這樣的二進制數(shù)據(jù)，但是在真正的通信線路里有光纖、電纜、無線各種設備。光信號和電信號，以及無線電磁信號在物理上是完全不同的，如何讓這些不同的設備能夠理解、處理相同的二進制數(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ù)據(jù)幀通過這個信息確保數(shù)據(jù)送達到正確的目標機器。

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

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

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

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

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

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

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

LB（負載均衡）

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

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

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

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

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

總結

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

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

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

鏈接：https://blog.csdn.net/qq_35030548/article/details/131872192

審核編輯：劉清