一個騰訊在職的朋友問道，當我們在瀏覽器的地址欄輸入 www.baidu.com ，然后回車，這一瞬間頁面發生了什么？下面以谷歌瀏覽器一一解釋．
一.域名解析
首先Chrome瀏覽器會解析www.baidu.com 這個域名對應的IP地址。
1 瀏覽器搜索自身的DNS緩存,看是否有www.baidu.com 對應的條目，如果有且沒有過期則解析到此結束。
2 如果沒有找到對應的條目，那么Chrome會搜索操作系統自身的DNS緩存,如果找到且沒過期則停止搜索解析到此結束.
3 如果在Windows系統的DNS緩存也沒有找到，那么嘗試讀取hosts文件，看有沒有該域名對應的IP地址，如果有則解析成功。
4 如果在hosts文件中也沒有找到對應的條目，瀏覽器就會發起一個DNS的系統調用，就會向本地配置的首選DNS服務器發起域名解析請求，運營商的DNS服務器首先查找自身的緩存，找到對應的條目，且沒有過期，則解析成功。
二.發起TCP的3次握手
拿到域名對應的IP地址后，User-Agent（一般是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務器的WEB程序80端口發起TCP的連接請求。這個連接請求（原始的http請求經過TCP/IP4層模型的層層封包）到達服務器端后，進入到網卡，然后是進入到內核的TCP/IP協議棧，還有可能要經過Netfilter防火牆的過濾，最終到達WEB程序，建立了TCP/IP的連接。在TCP/IP協議中，TCP協議提供可靠的連接服務，采用三次握手建立一個連接:
第一次握手：客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢后，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉連接之前，TCP 連接都將被一直保持下去。斷開連接時服務器和客戶端均可以主動發起斷開TCP連接的請求，斷開過程需要經過“第四次握手”，就是服務器和客戶端交互，最終確定斷開。
三.建立TCP連接后發起http請求
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應，在請求結束后，會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。
1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求后，就自動釋放連接。
2）在HTTP 1.1中則可以在一次連接中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束后再發送下一個請求。由於HTTP在每次請求結束后都會主動釋放連接，因此HTTP連接是一種“短連接”，要保持客戶端程序的在線狀態，需要不斷地向服務器發起連接求。通常 的做法是即時不需要獲得任何數據，客戶端也保持每隔一段固定的時間向服務器發送一次“保持連接”的請求，服務器在收到該請求后對客戶端進行回復，表明知道客戶端“在線”。若服務器長時間無法收到客戶端的請求，則認為客戶端“下線”，若客戶端長時間無法收到服務器的回復，則認為網絡已經斷開。
進過TCP3次握手之后，瀏覽器發起了http的請求，使用的http的方法 GET 方法，請求的URL是 / ,協議是HTTP/1.0。那么HTTP請求報文和響應報文會是什么格式呢？
起始行：如 GET / HTTP/1.0 （請求的方法、請求的URL 請求所使用的協議）
頭部信息：User-Agent Host等成對出現的值
主體
起始行中的請求方法有以下：
GET
GET是http的默認請求方式，一般用來獲取數據，傳輸的數據經過url編碼后放在路徑?之后，多個鍵值對通過&連接，另外get的傳輸長度一般不推薦超過255個字節。
GET方法一般被視為安全方法， 因為它僅用來獲取數據而不會對服務器有其他改動。像HEAD、GET、OPTIONS 和 TRACE這幾種http方法是被認為是“安全的”，它們只會進行獲取數據而不會修改服務器的狀態，可用於記錄日志、創建緩存或者創建其他統計信息。相反，像POST、PUT、DELETE 和 PATCH 等方法是有可能產生副作用。網絡爬蟲等一般不會使用這些方式
POST
POST一般用來上傳文件或者提交一個完整的web表單。瀏覽器中提交表單時，這里與get類似，每個鍵值對都是通過&分割, 其他非字母數字會進行url轉碼。
為什么一些請求會使用POST提交數據?
- GET請求數據都可以在URL中看到
- GET提交的數據都會有長度限制
- 一般規范，POST用來修改數據，GET用來獲取數據
- GET請求提交的數據放置在HTTP請求協議頭中，而POST提交的數據放在實體數據中
其他請求方式
HEAD獲取某個URI響應頭信息，基本與GET相同但是不返回響應主體。
PUT通過提供的URI獲取到特定的內容主體，如果存在則修改內容，如果不存在則創建。
DELETE通過URI刪除指定內容
TRACE返回接受到的請求，用來查看數據經過中間服務器時發生了哪些變動
OPTIONS返回給定URL支持的所有HTTP方法
CONNECT要求使用SSL和TLS進行TCP通信
PATCH請求修改局部數據
那什么是URL、URI、URN？
URI Uniform Resource Identifier 統一資源標識符
URL Uniform Resource Locator 統一資源定位符
格式如下： scheme://[username:password@]HOST:port/path/to/source
http://www.magedu.com/downloads/nginx-1.5.tar.gz
URN Uniform Resource Name 統一資源名稱。URL和URN 都屬於 URI。為了方便就把URL和URI暫時都通指一個東西
下面是Chrome發起的http請求報文頭部信息：
Accept 就是告訴服務器端，我接受那些MIME類型
Accept-Encoding 這個看起來是接受那些壓縮方式的文件
Accept-Lanague 告訴服務器能夠發送哪些語言
Connection 告訴服務器支持keep-alive特性
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
四.服務器端響應http請求，瀏覽器得到html代碼
服務器端WEB程序接收到http請求以后，就開始處理該請求，處理之后就返回給瀏覽器html文件。
1xx: 信息性狀態碼
100, 101
2xx: 成功狀態碼
200：OK
3xx: 重定向狀態碼
301: 永久重定向, Location響應首部的值仍為當前URL，因此為隱藏重定向;
302: 臨時重定向，顯式重定向, Location響應首部的值為新的URL
304：Not Modified 未修改，比如本地緩存的資源文件和服務器上比較時，發現並沒有修改，服務器返回一個304狀態碼，告訴瀏覽器，你不用請求該資源，直接使用本地的資源即可。
4xx: 客戶端錯誤狀態碼
404: Not Found 請求的URL資源並不存在
5xx: 服務器端錯誤狀態碼
500: Internal Server Error 服務器內部錯誤
502: Bad Gateway 前面代理服務器聯系不到后端的服務器時出現
504：Gateway Timeout 這個是代理能聯系到后端的服務器，但是后端的服務器在規定的時間內沒有給代理服務器響應
用Chrome瀏覽器看到的響應頭信息：
Connection 使用keep-alive特性
Content-Encoding 使用gzip方式對資源壓縮
Content-type MIME類型為html類型，字符集是 UTF-8
Date 響應的日期
Server 使用的WEB服務器
Transfer-Encoding:chunked 分塊傳輸編碼 是http中的一種數據傳輸機制，允許HTTP由網頁服務器發送給客戶端應用（通常是網頁瀏覽器）的數據可以分成多個部分，分塊傳輸編碼只在HTTP協議1.1版本（HTTP/1.1）中提供
五. 瀏覽器解析html代碼，並請求html代碼中的資源
瀏覽器拿到index.html文件后，就開始解析其中的html代碼，遇到js/css/image等靜態資源時，就向服務器端去請求下載（會使用多線程下載，每個瀏覽器的線程數不一樣），這個時候就用上keep-alive特性了，建立一次HTTP連接，可以請求多個資源，下載資源的順序就是按照代碼里的順序，但是由於每個資源大小不一樣，而瀏覽器又多線程請求請求資源，順序並不一定是代碼里面的順序。
瀏覽器在請求靜態資源時（在未過期的情況下），向服務器端發起一個http請求（詢問自從上一次修改時間到現在有沒有對資源進行修改），如果服務器端返回304狀態碼（告訴瀏覽器服務器端沒有修改），那么瀏覽器會直接讀取本地的該資源的緩存文件。
六.瀏覽器對頁面進行渲染呈現給用戶
最后，瀏覽器把請求到的靜態資源和html代碼進行渲染，呈現給用戶。
總結
域名解析 --> 發起TCP的3次握手 --> 建立TCP連接后發起http請求 --> 服務器響應http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶