目錄
1.DNS解析
輸入一個網址並按回車的時候瀏覽器會根據輸入的URL去查找對應的IP，具體過程如下：
（1）首先是查找瀏覽器緩存，瀏覽器會保存一段時間內訪問過的一些網址的DNS信息，域名被緩存的時間限制可以通過TTL屬性來設置。
（2）如果沒有找到對應的記錄，這個時候瀏覽器會嘗試調用操作系統緩存來繼續查找這個網址的對應DNS信息。
（3）如果還是沒找到對應的IP，那麼接着會發送一個請求到路由器上，然後路由器在自己的路由器緩存上查找記錄，路由器一般也存有DNS信息。
（4）如果還是沒有，在本地DNS服務器中尋找，請求的域名基本上都能在這裏找得到。
（5）如果還是沒有的話， ISP的DNS服務器會將請求發向根域名服務器進行搜索。根域名服務器就是面向全球的頂級DNS服務器，共有13臺邏輯上的服務器，從A到M命名，真正的實體服務器則有幾百臺，分佈於全球各大洲。
（6）如果到了這裏還是找不到域名的對應信息，那隻能說明一個問題：這個域名本來就不存在，它沒有在網上正式註冊過。或者域名過期了。
這也就是爲什麼有時候打開一個新頁面會有點慢，因爲如果本地沒什麼緩存，查找域名的過程要這樣遞歸地查詢下去，查找完還要一層層的向上返回。例如"mp3.baidu.com"，域名先是解析出這是個.com的域名，然後跑到管理.com域的服務器上進行進一步查詢，然後是.baidu，最後是mp3， 所以域名結構爲：三級域名.二級域名.一級域名。
所以DNS根據域名查詢IP地址的過程爲：瀏覽器緩存 --> 操作系統緩存 --> 路由器緩存-->本地（ISP）域名服務器緩存 --> 根域名服務器。
2.進行TCP連接
瀏覽器終於得到了IP以後，向服務器發送TCP連接，TCP連接經過三次握手。
3.瀏覽器發送HTTP請求
瀏覽器和服務器建立連接以後，瀏覽器接着給這個IP地址給服務器發送一個http請求，方式爲get，例如訪問www.baidu.com。其本質是在建立起的TCP連接中，按照HTTP協議標準發送一個索要網頁的請求。
這個get請求包含了主機（Host）、用戶代理(User-Agent)，用戶代理就是自己的瀏覽器，它是你的"代理人"，Connection（連接屬性）中的keep-alive表示瀏覽器告訴對方服務器在傳輸完現在請求的內容後不要斷開連接，不斷開的話下次繼續連接速度就很快了。可能還會有Cookies，Cookies保存了用戶的登陸信息，一般保存的是用戶的JSESSIONID，在每次向服務器發送請求的時候會重複發送給服務器。
在建立連接發送請求時每個服務端需要和客戶端保持通信，有很多客戶端都會和服務器進行通信。服務器爲了識別是哪個客戶端與它通信，就必須用一個標識記錄客戶端的信息。客戶端首次訪問服務器，服務端返回響應時通過附帶一個記錄的客戶端信息的標識來返回給客戶端，這個標識就是JSESSIONID，JSESSIONID就放在了客戶端的Cookies裏。當客戶端再次向服務器發送請求時上就使用上次記錄的Cookies裏面的JSESSIONID，這樣服務器就知道是哪個瀏覽器了。這樣他們之間就能保持通信了。
4.封裝
TCP數據包需要設置端口，接收方（百度）的Http端口默認是80，本機的端口是一個1024-65535之間的隨機整數，這裏假設爲1025，這樣TCP數據包由標頭（標識着發方和接收方的端口信息）+HTTP數據包，這樣TCP數據包再嵌入IP數據包中在網絡上傳送。
IP數據包需要知道雙方的IP地址，本機IP地址假定爲192.168.1.5，接受方IP地址爲220.181.111.147（百度），這樣IP數據包由頭部（IP地址信息）+TCP數據包。
IP數據包嵌入到數據幀（以太網數據包）中，以太網數據包需要知道雙方的MAC（物理地址），發送方爲本機的網卡地址，接受方爲網關192.168.1.1的MAC地址（通過ARP地址解析協議得到的）。這樣數據幀由頭部（MAC地址）+IP數據包組成。
ARP地址解析協議工作過程：
當主機A要與主機B通信時，地址解析協議可以將主機B的IP地址（192.168.1.2）解析成主機B的MAC地址，以下爲工作流程：
第1步：根據主機A上的路由表內容，IP確定用於訪問主機B的轉發IP地址是192.168.1.2。然後A主機在自己的本地ARP緩存中檢查主機B的匹配MAC地址。
第2步：如果主機A在ARP緩存中沒有找到映射，它將詢問192.168.1.2的硬件地址，從而將ARP請求幀廣播到本地網絡上的所有主機。源主機A的IP地址和MAC地址都包括在ARP請求中。本地網絡上的每臺主機都接收到ARP請求並且檢查是否與自己的IP地址匹配。如果主機發現請求的IP地址與自己的IP地址不匹配，它將丟棄ARP請求。
第3步：主機B確定ARP請求中的IP地址與自己的IP地址匹配，則將主機A的IP地址和MAC地址映射添加到本地ARP緩存中。
第4步：主機B將包含其MAC地址的ARP回覆消息直接發送回主機A。
第5步：當主機A收到從主機B發來的ARP回覆消息時，會用主機B的IP和MAC地址映射更新ARP緩存。本機緩存是有生存期的，生存期結束後，將再次重複上面的過程。主機B的MAC地址一旦確定，主機A就能向主機B發送IP通信了。
5.服務器處理請求
經過多個網關的轉發到百度服務器220.181.111.147，中間通過各級物理層找到終端服務器IP，並請求對應端口服務，服務接收到發送過來的以太網數包據開始解析請求信息，從以太網數據包中提取IP數據包——>TCP數據包——>HTTP數據包，並組裝爲有效數據交與對應線程池中分配的線程進行處理，在這個過程中，生成相應request、response對象。
處理完畢後，將數據通過response對象內部的out給客戶輸出信息，輸出信息也需要拼接HTTP協議頭部分，標誌out關閉後爲斷開連接（注意動態內容已經在服務器端被翻譯爲靜態內容，到客戶端全部是靜態內容，JS動態組裝不算），斷開後，服務器端自動註銷request、response對象，並將釋放對應線程的使用標識（一般一個請求單獨由一個線程處理，部分特殊情況有一個線程處理多個請求的情況）
發送完請求接下來就是等待迴應了，如下圖：
服務器收到瀏覽器的請求以後），會解析這個請求（讀請求頭），然後生成一個響應頭和具體響應內容。接着服務器會傳回來一個響應頭和一個響應，響應頭告訴了瀏覽器一些必要的信息，例如重要的Status Code，2開頭如200表示一切正常，3開頭表示重定向，4開頭是客戶端錯誤，如404表示請求的資源不存在，5開頭表示服務器端錯誤。響應就是具體的要請求的頁面內容。
6.瀏覽器解析渲染頁面
（1）瀏覽器顯示HTML
當服務器返回響應之後，瀏覽器讀取關於這個響應的說明書（響應頭），然後開始解析這個響應並在頁面上顯示出來。
瀏覽器打開一個網址的時候會慢慢加載這個頁面，一部分一部分的顯示，直到完全顯示，知道最後的旋轉進度條停止。因此在瀏覽器沒有完整接受全部HTML文檔時，它就已經開始顯示這個頁面了。
（2）瀏覽器向服務器發送請求獲取嵌入在HTML中的對象
在瀏覽器顯示HTML時，打開一個網頁的過程中，主頁（index）頁面框架傳送過來以後，瀏覽器還會因頁面上的靜態資源多次發起連接請求，需要獲取嵌入在HTML中的其他地址的資源。這時，瀏覽器會發送一些請求來獲取這些文件。這些內容也要一點點地請求過來，所以標籤欄轉啊轉，內容刷啊刷，最後全部請求並加載好了就終於好了。
這時請求的內容是主頁裏面包含的一些資源，如圖片，視頻，css樣式，JavaScript文件等等。
這在文件屬於靜態文件，首次訪問會留在瀏覽器的緩存中，過期纔會從服務器去取。緩存的內容通常不會保存很久，因爲難保網站不會被改動。
靜態的文件一般會從CDN中去取，CDN根據請求獲取資源的時候可能還會用到負載均衡。
（3）瀏覽器發送異步（AJAX）請求
對於那些動態的請求，動態網頁等就必須要從服務器獲取了。對於靜態的頁面內容，瀏覽器通常會進行緩存，而對於動態的內容，瀏覽器通常不會進行緩存。對於這些動態請求，Nginx可能會專門設置一些服務器用來處理這些訪問動態頁面的請求。
7.關閉TCP連接
當數據完成請求到返回的過程之後，根據Connection的Keep-Alive屬性可以選擇是否斷開TCP連接，HTTP/1.1一般支持同一個TCP多個請求，而不是1.0版本下的完成一次請求就發生斷開。TCP的斷開與連接不一樣，斷開可以分爲主動關閉和被動關閉，需要經過4次握手。
當瀏覽器需要的全部數據都已經加載完畢，一個頁面就顯示完了。