web客戶端請求是怎么到達服務器的

本篇內容介紹了“web客戶端請求是怎么到達服務器的”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1、數據包

一、HTTP請求和響應步驟

http請求全過程

請求

響應

以上完整表示了HTTP請求和響應的7個步驟，下面從TCP/IP協議模型的角度來理解HTTP請求和響應如何傳遞的。

2、TCP/IP概述

我們以RFC 1180中的圖作為參考

上圖展示了四層TCP/IP協議圖，其中network  applications是應用程序，屬于應用層;TCP和UDP主要是傳輸數據，屬于傳輸層，TCP確保端對端的可靠傳輸并盡量確保網絡健康運行，而UDP是簡單不可靠傳輸;IP主要解決路由問題，屬于網絡層;ARP是網絡地址轉換，主要用來轉換IP地址和MAC地址，介于數據鏈路層和網絡層之間，可以看成2.5層;ENET在這里是數據鏈路層，網卡驅動屬于這一層，主要做具體的介質傳輸，前面示例中的廣告請求抓包就是在數據鏈路層抓取。

值得注意的是，ARP在linux系統里屬于網絡層，而在RFC里是介于數據鏈路層和網絡層之間。在《TCP/IP詳解》一書里，ARP被放到了數據鏈路層。當解決實際問題的時候，我們應該把ARP放到網絡層。

上圖給出使用TCPCopy在不同層發包的使用方法。如果TCPCopy從數據鏈路層發包，由于沒有享受到ARP服務，用戶需要在使用TCPCopy的時候額外加上MAC地址;而如果TCPCopy從IP層發包，則無需指定MAC地址。

本課程主要講述TCP相關案例，沒有特殊說明的話，TCP特指傳輸層的TCP。

3、什么是TCP

TCP即傳輸控制協議，是一種面向連接的、可靠的、基于字節流的通信協議。TCP的主要工作是定義端口標識應用程序的身份，實現端對端的可靠通信，并進行擁塞控制，防止互聯網崩塌。

TCP有如下關鍵特性：

由于TCP是面向連接的協議，所以是一種有狀態的協議，而有狀態的協議往往比較復雜，因此TCP學習起來也比較困難。

通過狀態圖來查看一下TCP狀態的復雜性：

上圖展示了錯綜復雜的TCP狀態圖，然而現實更加復雜。

現實中的TCP狀態圖其實是這樣的：

圖中，不僅SYN_RCVD狀態能夠收到reset數據包(圖中RST，reset數據包是重置連接的數據包，可以使TCP狀態瞬間變為CLOSED狀態，而CLOSED狀態是無法追蹤的)，而且FIN_WAIT1、FIN_WAIT2、ESTABLISHED、SYN_SENT和CLOSE_WAIT都能被reset數據包打回到CLOSED狀態。不僅如此，TCP狀態還受到超時的影響。例如Linux系統，一旦連接處于FIN_WAIT_2，在60秒內(默認)如果沒有接收到對端的FIN數據包，系統會把此連接狀態FIN_WAIT_2直接變到CLOSED狀態。雖然Linux這樣做是為了防止攻擊，但這種超時就干掉連接狀態的做法，很可能誤殺了很多正常連接，從而使問題更加捉摸不定。

在互聯網領域，很多詭異的問題跟TCP狀態有關系，課程后續會有較多案例來講述這些靈異問題。

4、端口

當我們去連接服務器程序時，需要指明服務器端口。為什么需要端口呢?因為系統是通過端口來區分不同應用程序，TCP通過端口找到上層應用。

需要注意的是，端口號是有限的，端口號最大為65535，能夠利用的端口數量隨配置而定。例如在壓力測試過程中，一臺機器可以利用的TCP端口是有限的，能夠利用的連接(客戶端端口，客戶端IP，服務器應用端口，服務器IP地址)是有限的。為了解決這個問題，可以配置多IP地址來擴大可用連接數量。系統支持同一個端口，不同的IP地址來綁定不同的應用。Linux高版本系統下，在綁定同一個IP地址的情況下，我們還可以利用REUSEPORT機制使不同應用程序共享同一個監聽端口，這對高性能服務器開發是非常有用的。我們開發的數據庫中間件cetus就利用這個機制來解決短鏈接風暴的問題。

5、IP

網絡層的主要工作是定義網絡地址，區分網段，子網內MAC尋址，對不同子網的數據包進行路由。IP的主要作用就是在復雜的網絡環境中將數據包發給最終的目標地址。

IP是面向無連接的，是無狀態的協議。IP為什么被設計成無狀態呢?

1. 無狀態協議處理簡單

2. 通信之前無需建立連接

3. TCP已經面向連接服務了，IP層可以委托TCP來解決面向連接的問題

4. 由于不帶有狀態，互聯網路由起來更加自由，容錯性也更強

值得注意的是，現實中的IP層往往都帶有安全過濾，甚至有些路由器，防火墻等中途設備還會干涉應用(例如通過reset數據包來干涉TCP會話)，為了更好的做安全檢測，IP層還增加了connection  tracking，在無狀態協議上面來追蹤上層連接。這種方式提高了安全性，但有時也會帶來新的問題，我們后面有案例具體講述connnection  tracking帶來的坑的故事。

6、TCP Socket

應用程序通過TCP socket接口來調用TCP服務，從而達到傳遞數據的目的。每一個TCP socket會被綁定到一個端口，TCP  socket雙向都可以通信，在發送數據的同時，還可以接收數據。

值得注意的是，應用程序發送完數據，只代表通過TCP  socket委托給TCP的工作已經完成，不代表發送給對端完畢，應用發送數據和TCP傳輸數據不是同步的。

7、How TCP/IP Works

當用戶通過TCP socket接口發送請求后，TCP協議模塊接管了請求傳遞，TCP先把請求拆分成一個個更小的數據分段(假設TCP  offload沒有開啟的情況下)，通過IP層發送出去。在IP層，這些數據分段會被封裝成IP數據包，通過數據鏈路層發送給互聯網(見下圖)。這些數據包經過互聯網的多個路由器到達目的地。由于IP網絡是無狀態的協議，每一個數據包走的路徑可能不一樣，而且到達的順序也有可能不一樣，這就要求對端的TCP需要重新組裝數據包，以確保向應用層傳遞的數據是用戶能夠識別的用戶請求，這樣服務器應用程序就可以處理用戶發起的請求了。

下圖中，假設用戶請求拆分成兩個IP數據包

第一個IP數據包可能經過A，B，C，G，如下圖。

第二個數據包可能經過A，B，E，G(在B點選擇了E節點，導致路徑不同)，如下圖。

導致數據包在B節點走向不同路徑的原因可能有很多種，例如C節點暫時不如E節點通暢或者臨時發生了網絡擁塞，這與在高速道路駕駛的原理差不多。

由于網絡環境多變，還可能第二個數據包先到達服務器，這時TCP會負責處理out of  order的情況;如果網絡傳遞過程中，某一個路由器由于過于繁忙，把第一個數據包丟了，那么客戶端的TCP會負責重傳第一個數據包，確保服務器端的TCP能夠不會因為丟包而收不到第一個數據包。

如果用戶請求內容很大，如上傳一個大文件，就會被拆分成大量數據分段，而TCP傳輸這些數據分段的時候，往往還會考慮整個互聯網能夠接收的程度和對方能夠接收的程度，發送數據過于貪婪不僅會連累整個互聯網，對方也未必能夠接收得了，而且還可能使自己速度更慢，這有點像道路駕駛一樣，不能過于自私，遵守一定的交通規則才能使道路通暢。在互聯網傳輸數據方面，這些交通規則算法就是赫赫有名的網絡擁塞控制算法，而對方能否接收得了，則通過發送窗口的方式進行控制。總體來說，一次發送數據的大小是根據對方的接收窗口大小和擁塞控制算法來綜合決定的。

從上面可以看出，IP負責在互聯網傳輸數據，而TCP負責數據傳輸可靠并且盡量使網絡健康運行，兩者合作完成了請求的傳遞，這也是互聯網應用工作的普遍方式。

需要注意的是，TCP負責跟TCP進行交互，應用層無需去實現TCP的功能，只需要委托給TCP來完成數據傳輸，這種隔離的方式給應用層的開發/運維/測試帶來了方便，另外，當出現TCP相關問題時，解決問題的難度也大大增加。

8、TCP經驗知識

在多年實戰過程中，我們發現以下TCP經驗對工作很有幫助。總結如下：

1. 距離越遠，延遲越大，重傳概率越大

2. 網絡狀況好壞，直接影響應用程序性能

3. 不同環境，采用不同的擁塞算法

4. 擁塞控制算法是互聯網的精華，是互聯網大獲成功的關鍵因素之一

5. TCP是有狀態協議，采用異步處理

6. 抓包分析是找到TCP相關問題根本原因的利器

7. TCP客戶端和TCP服務器端之間的交互，是應用層所有應用公共的交互部分，理解了這部分原理，可以解決大量TCP相關問題。

9、IP經驗知識

在IP經驗知識方面，我們大致總結如下：

1. 數據包選擇路徑不是固定的，到達的順序也可能是亂序的

2. 安全過濾，坑多的地方

3. 無狀態協議，簡化互聯網架構，是互聯網大獲成功的關鍵因素之一

4. IP層對TCP傳遞過來的數據包很少分片處理

5. 中途設備不僅僅具備路由功能，而且還會干涉TCP會話(靈異問題的溫床)

“web客戶端請求是怎么到達服務器的”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！