web请求过程
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協議相關的緩存或代理服務器。
Cache-Control/Pragma字段的可選值：
?
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又向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解析整個過程，分為：遞歸查詢過程和迭代查詢過程。如圖所示：
幾種域名解析方式
A記錄，A代表的是Address，用來指定域名對應的IP地址
如將item.taobao.com指定到115.238.23.241，將switch.taobao.com指定到121.14.24.241。A記錄可以將多個域名解析到一個IP地址，但是不能將一個域名解析到多個IP地址。
MX記錄，表示的是Mail Exchange，就是可以將某個域名下的郵件服務器指向自己的Mail Server
如taobao.com域名的A記錄IP地址是115.238.25.245，如果MX記錄設置為115.238.25.246，是xxx@taobao.com的郵件路由，DNS會將郵件發送到115.238.25.246所在的服務器，而正常通過Web請求的話仍然解析到A記錄的IP地址。
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解析。
NS記錄，為某個域名指定DNS解析服務器，也就是這個域名有指定的IP地址的DNS服務器去解析
前面的“google.com. 172800 IN NS ns4.google.com.”就是NS解析。
TXT記錄，為某個主機名或域名設置說明
如可以為google.com設置TXT記錄為“谷歌|中國”這樣的說明。
5 發起TCP的3次握手
拿到域名對應的IP地址之后，User-Agent（一般是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務器的WEB程序（常用的有httpd,nginx等）80端口發起TCP的連接請求。這個連接請求（原始的http請求經過TCP/IP4層模型的層層封包）到達服務器端后（這中間通過各種路由設備，局域網內除外），進入到網卡，然后是進入到內核的TCP/IP協議棧（用于識別該連接請求，解封包，一層一層的剝開），還有可能要經過Netfilter防火墻（屬于內核的模塊）的過濾，最終到達WEB程序，最終建立了TCP/IP的連接。
Client首先發送一個連接試探，ACK=0
表示確認號無效，SYN = 1 表示這是一個連接請求或連接接受報文，同時表示這個數據報不能攜帶數據，seq = x表示Client自己的初始序號（seq = 0 就代表這是第0號包），這時候Client進入syn_sent狀態，表示客戶端等待服務器的回復。
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的確認。
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:password@]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
作者：jerrice
鏈接：https://www.jianshu.com/p/59521f04b68c
來源：簡書
?
總結
- 上一篇： 淘宝大秒系统设计详解 | 许令波
- 下一篇： 我所理解的RESTful Web API