web請求過程

標籤：資料   分布   系統   資料類型   get   author   lte   核心   oom   

 

1 B/S網路架構概述

當一個使用者在瀏覽器輸入URL：www.google.com時，將會發生如下操作：

1.瀏覽器請求DNS把網域名稱解析成對應的IP地址；

2.根據IP地址在互連網上找到對應的伺服器，建立Socket串連，向這個伺服器發起一個HTTP Get請求；

3.負載平衡裝置平均分配所有使用者的請求給具體的某台伺服器；

4.還有請求的資料是儲存在分布式緩衝裡還是一個靜態檔案中，或是在資料庫裡；

5.當資料返回瀏覽器時，瀏覽器向CDN發起另外的HTTP請求擷取靜態資源（如：css，js或者圖片）

以上流程，：

2.HTTP協議解析

常見的HTTP要求標頭
常見的HTTP回應標頭
常見的HTTP狀態代碼

2.1瀏覽器緩衝機制

在請求Head中增加了兩個請求項Pragma:no-cache和Cache-Control:no-cache

 

1.Cache-Control/Pragma

這個HTTP Head欄位用於指定所有緩衝機制在整個請求/響應鏈中必須服從的指令，如果知道該頁面是否為緩衝，不僅可以控制瀏覽器，還可以控制和HTTP協議相關的緩衝或Proxy 伺服器。

Cache-Control/Pragma欄位的可選值：

Cache-Control 使瀏覽器遵守

Pragma 使伺服器遵守

2.Expires 緩衝到期時間

3.Last-Modified/Etag 最後修改時間

3 WEB工作流程

對於正常的上網過程，系統其實是這樣做的

瀏覽器本身是一個用戶端，當你輸入URL的時候，首先瀏覽器會去請求DNS伺服器，通過DNS擷取相應的網域名稱對應的IP，然後通過IP地址找到IP對應的伺服器後，要求建立TCP串連，等瀏覽器發送完HTTP Request（請求）包後，伺服器接收到請求包之後才開始處理請求包，伺服器調用自身服務，返回HTTP Response（響應）包；用戶端收到來自伺服器的響應後開始渲染這個Response包裡的主體（body），等收到全部的內容隨後斷開與該伺服器之間的TCP串連。

Web請求的工作原理可以簡單地歸納為：

瀏覽器通過DNS網域名稱解析到伺服器IP；

客戶機通過TCP/IP協議建立到伺服器的TCP串連；

用戶端向伺服器發送HTTP協議請求包，請求伺服器裡的資來源文件；

伺服器向客戶機發送HTTP協議應答包，如果請求的資源套件含有動態語言的內容，那麼伺服器會調用動態語言的解釋引擎負責處理“動態內容”，並將處理得到的資料返回給用戶端；

客戶機與伺服器斷開。由用戶端解釋HTML文檔，在用戶端螢幕上渲染圖形結果；

4 DNS網域名稱解析4.1 DNS網域名稱解析過程
DNS解析過程

1.瀏覽器緩衝檢查（本機）

2.作業系統緩衝檢查（本機）+hosts解析（本機）

3.本地地區名伺服器解析（LDNS）

這個專門的網域名稱解析伺服器效能都會很好，它們一般都會緩衝網域名稱解析結果，大約80%的網域名稱解析都到這裡就已經完成了，所以LDNS主要承擔了網域名稱的解析工作。

4.根網域名稱伺服器解析（Root Server）

如果LDNS沒有找到對應的條目，則由電訊廠商的DNS代我們的瀏覽器發起迭代DNS解析請求。它首先是會找根域的DNS的IP地址，找到根域的DNS地址，就會向其發起請求。

5.根網域名稱伺服器返回給本地區名伺服器一個所查詢域的主網域名稱伺服器(gTLD Server)地址，gTLD是國際頂級網域名稱伺服器，如.com、.cn、.org等，全球只有13台左右。

6.本地區名伺服器(Local DNS Server)再向上一步返回的gTLD伺服器發送請求。

於是電訊廠商的DNS就得到了com域的IP地址，又向com域的IP地址發起了請求（請問www.google.com這個網域名稱的IP地址是多少?），com域這台伺服器告訴電訊廠商的DNS我不知道www.google.com這個網域名稱的IP地址，但是我知道google.com這個域的DNS地址，你去找它去。

7.接受請求的gTLD伺服器尋找並返回此網域名稱對應的Name Server網域名稱伺服器的地址，這個Name Server通常就是你註冊的網域名稱伺服器，例如你在某個網域名稱服務 (DNS)供應商申請的網域名稱，那麼這個網域名稱解析任務就由這個網域名稱供應商的伺服器來完成。

於是電訊廠商的DNS又向google.com這個網域名稱的DNS地址（這個一般就是由網域名稱註冊商提供的，像萬網，新網等）發起請求（請問www.google.com這個網域名稱的IP地址是多少？），這個時候google.com域的DNS伺服器一查，果真在我這裡，於是就把找到的結果發送給電訊廠商的DNS伺服器，這個時候電訊廠商的DNS伺服器就拿到了www.google.com這個網域名稱對應的IP地址。

8.Name Server網域名稱伺服器會查詢儲存的網域名稱和IP的映射關係表，正常情況下都根據網域名稱得到目標IP記錄，連同一個TTL值返回給DNS Server網域名稱伺服器。

9.返回該網域名稱對應的IP和TTL值，Local DNS Server會緩衝這個網域名稱和IP的對應關係，緩衝的時間由TTL值控制。

10.把解析的結果返回給使用者，使用者根據TTL值緩衝在本地系統緩衝中，網域名稱解析過程結束。

通過上面的步驟，我們最後擷取的是IP地址，也就是瀏覽器最後發起請求的時候是基於IP來和伺服器做資訊互動的。在實際的DNS解析過程中，可能還不止這10個步驟，如Name Server也可能有多級，或者有一個GTM來負載平衡控制，這都有可能會影響網域名稱解析的過程。根據以上解析流程，DNS解析整個過程，分為：遞迴查詢過程和迭代查詢過程。：

幾種網域名稱解析方式

1. A記錄，A代表的是Address，用來指定網域名稱對應的IP地址

   如將item.taobao.com指定到115.238.23.241，將switch.taobao.com指定到121.14.24.241。A記錄可以將多個網域名稱解析到一個IP地址，但是不能將一個網域名稱解析到多個IP地址。

2. MX記錄，表示的是Mail Exchange，就是可以將某個網域名稱下的郵件伺服器指向自己的Mail Server

   如taobao.com網域名稱的A記錄IP地址是115.238.25.245，如果MX記錄設定為115.238.25.246，是[email protected]的郵件路由，DNS會將郵件發送到115.238.25.246所在的伺服器，而正常通過Web請求的話仍然解析到A記錄的IP地址。

3. CNAME記錄，全稱是Canonical Name（別名解析），所謂的別名解析就是可以為一個網域名稱設定一個或者多個別名

   如將taobao.com解析到xulingbo.net，將srcfan.com也解析到xulingbo.net，其中xulingbo.net分別是taobao.com和srcfan.com的別名。前面的跟蹤網域名稱解析中的“www.taobao.com. 1542 IN CNAME www.gslb.taobao.com”就是CNAME解析。

4. NS記錄，為某個網域名稱指定DNS解析伺服器，也就是這個網域名稱有指定的IP地址的DNS伺服器去解析

   前面的“google.com. 172800 IN NS ns4.google.com.”就是NS解析。

5. TXT記錄，為某個主機名稱或網域名稱設定說明

   如可以為google.com設定TXT記錄為“Google|中國”這樣的說明。

 

5 發起TCP的3次握手

拿到網域名稱對應的IP地址之後，User-Agent（一般是指瀏覽器）會以一個隨機連接埠（1024 < 連接埠 < 65535）向伺服器的WEB程式（常用的有httpd,nginx等）80連接埠發起TCP的串連請求。這個串連請求（原始的http請求經過TCP/IP4層模型的層層封包）到達伺服器端後（這中間通過各種路由裝置，區域網路內除外），進入到網卡，然後是進入到核心的TCP/IP協議棧（用於識別該串連請求，解鎖包，一層一層的剝開），還有可能要經過Netfilter防火牆（屬於核心的模組）的過濾，最終到達WEB程式，最終建立了TCP/IP的串連。

1. Client首先發送一個串連試探，ACK=0 表示確認號無效，SYN = 1 表示這是一個串連請求或串連接受報文，同時表示這個資料報不能攜帶資料，seq = x 表示Client自己的初始序號（seq = 0 就代表這是第0號包），這時候Client進入syn_sent狀態，表示用戶端等待伺服器的回複。

2. Server監聽到串連請求報文後，如同意建立串連，則向Client發送確認。TCP報文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到對方下一個報文段的第一個資料位元組序號是x+1，同時表明x為止的所有資料都已正確收到（ack=1其實是ack=0+1,也就是期望用戶端的第1個包），seq = y 表示Server自己的初始序號（seq=0就代表這是伺服器這邊發出的第0號包）。這時伺服器進入syn_rcvd，表示伺服器已經收到Client的串連請求，等待client的確認。

3. Client收到確認後還需再次發送確認，同時攜帶要發送給Server的資料。ACK 置1 表示確認號ack= y + 1 有效（代表期望收到伺服器的第1個包），Client自己的序號seq= x + 1（表示這就是我的第1個包，相對於第0個包來說的），一旦收到Client的確認之後，這個TCP串連就進入Established狀態，就可以發起http請求了。

TCP 為什麼需要3次握手

為了防止已失效的串連請求報文段突然又傳送到了服務端，因而產生錯誤

為什麼HTTP協議要基於TCP來實現？

目前在Internet中所有的傳輸都是通過TCP/IP進行的，HTTP協議作為TCP/IP模型中應用程式層的協議也不例外，TCP是一個端到端的可靠的連線導向的協議，所以HTTP基於傳輸層TCP協議不用擔心資料的傳輸的各種問題。

6 建立TCP串連後發起http請求

經過TCP3次握手之後，瀏覽器發起了http的請求（看第?包），使用的http的方法 GET 方法，請求的URL是 / ,協議是HTTP/1.0：

03175340_4j8z.png

下面是第12號包的詳細內容：

03175429_kHoP.png

以上的報文是HTTP請求報文。那麼HTTP請求報文和響應報文會是什麼格式呢？

起始行：如 GET / HTTP/1.0 （請求的方法 請求的URL 請求所使用的協議）

頭部資訊：User-Agent Host等成對出現的值

主體

不管是請求報文還是響應報文都會遵循以上的格式。那麼起始行中的要求方法有哪些種呢？

GET: 完整請求一個資源 （常用）

HEAD: 僅請求響應首部

POST: 提交表單 （常用）

PUT: 上傳

DELETE: 刪除

OPTIONS: 返回請求的資源所支援的方法的方法

TRACE: 追求一個資源請求中間所經過的代理

那什麼是URL、URI、URN？

URI Uniform Resource Identifier 統一資源識別項，如：scheme://[username:[email protected]]HOST:port/path/to/source

URL Uniform Resource Locator 統一資源定位器，如：http://www.magedu.com/downloads/nginx-1.5.tar.gz

URN Uniform Resource Name 統一資源名稱

URL和URN都屬於URI，為了方便就把URL和URI暫時都通指一個東西。

請求的協議有哪些種？有以下幾種：

http/0.9: stateless

http/1.0: MIME, keep-alive (保持串連), 緩衝

http/1.1: 更多的要求方法，更精細的緩衝控制，持久串連(persistent connection) 比較常用

下面是Chrome發起的http請求報文頭部資訊：

03181252_cIE1.png

Accept 就是告訴伺服器端，接受那些MIME類型

Accept-Encoding 這個看起來是接受那些壓縮方式的檔案

Accept-Lanague 告訴伺服器能夠發送哪些語言

Connection 告訴伺服器支援keep-alive特性，TCP串連在發送後將仍然保持開啟狀態，於是，瀏覽器可以繼續通過相同的TCP串連發送請求。保持串連節省了為每個請求建立新串連所需的時間，還節約了網路頻寬。

Cookie 每次請求時都會攜帶上Cookie以方便伺服器端識別是否是同一個用戶端

Host 用來標識請求伺服器上的那個虛擬機器主機，比如Nginx裡面可以定義很多個虛擬機器主機，那這裡就是用來標識要訪問那個虛擬機器主機。

User-Agent 使用者代理程式，一般情況是瀏覽器，也有其他類型，如：wget curl 搜尋引擎的蜘蛛等

條件要求標頭部：If-Modified-Since是瀏覽器向伺服器端詢問某個資源檔如果自從什麼時間修改過，那麼重新發給我，這樣就保證伺服器端資源檔更新時，瀏覽器再次去請求，而不是使用緩衝中的檔案。

安全要求標頭部：Authorization: 用戶端提供給伺服器的認證資訊；

什麼是MIME？

MIME（Multipurpose Internet Mail Extesions 多用途互連網郵件擴充）是一個互連網標準，它擴充了電子郵件標準，使其能夠支援非ASCII字元、二進位格式附件等多種格式的郵件訊息，這個標準被定義在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 由RFC 822轉變而來的RFC 2822，規定電子郵件標準並不允許在郵件訊息中使用7位ASCII字元集以外的字元。正因如此，一些非英語字元訊息和二進位檔案，映像，聲音等非文字訊息都不能在電子郵件中傳輸。

MIME規定了用於表示各種各樣的資料類型的符號化方法。此外，在全球資訊網中使用的HTTP協議中也使用了MIME的架構，標準被擴充為互連網媒體類型。

MIME 遵循以下格式：major/minor 主類型/次類型 例如：

image/jpg

image/gif

text/html

video/quicktime

appliation/x-httpd-php

web請求過程