一、總體來說分爲以下幾個過程:
- DNS解析
- 建立TCP連接（三次握手）
- 發送HTTP請求
- 服務器處理請求，瀏覽器接收HTTP響應。
- 瀏覽器解析渲染頁面，構建DOM樹。
- 關閉TCP連接（四次揮手）。
（1）DNS解析
域名解析的過程實際是將域名還原爲IP地址的過程。
DNS解析的過程就是尋找哪臺機器上有你需要資源的過程。當你在瀏覽器中輸入一個地址時，例如www.baidu.com，其實不是百度網站真正意義上的地址。互聯網上每一臺計算機的唯一標識是它的IP地址，但是IP地址並不方便記憶。用戶更喜歡用方便記憶的網址去尋找互聯網上的其它計算機，也就是上面提到的百度的網址。所以互聯網設計者需要在用戶的方便性與可用性方面做一個權衡，這個權衡就是一個網址到IP地址的轉換，這個過程就是DNS解析。它實際上充當了一個翻譯的角色，實現了網址到IP地址的轉換。
DNS解析過程（DNS解析是一個遞歸查詢的過程。）：
以解析www.google.com爲例：
- 首先瀏覽器先檢查本地hosts文件是否有這個網址映射關係，如果有就調用這個IP地址映射，完成域名解析。
- 如果沒找到則會查找本地DNS解析器緩存，如果查找到則返回。
- 如果還是沒有找到則會查找本地DNS服務器，如果查找到則返回。
- 遞歸查詢，按上一級DNS服務器->上上級->…逐級向上查詢找到IP地址。如：
按根域服務器 ->頂級域,.com->第二層域，google.com ->子域，www.google.com的順序找到IP地址。
（2）建立TCP連接（三次握手）
- 一次握手：客戶端==>服務端，發送帶有 SYN 標誌的數據包
- 二次握手：服務端==>客戶端，發送帶有 SYN/ACK 標誌的數據包
- 三次握手：客戶端==>服務端，發送帶有帶有 ACK 標誌的數據包
（3）發送HTTP請求
完整的HTTP請求包含請求起始行、請求頭部、請求主體三部分。
請求起始行
常用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。
請求頭部
請求主體
當使用POST, PUT等方法時，通常需要客戶端向服務器傳遞數據。這些數據就儲存在請求正文中。在請求包頭中有一些與請求正文相關的信息，
例如: 現在的Web應用通常採用Rest架構，請求的數據格式一般爲json。這時就需要設置Content-Type: application/json。
（4）服務器處理請求，瀏覽器接收HTTP響應。
HTTP響應報文也是由三部分組成: 狀態碼, 響應報頭和響應報文。
狀態碼
狀態碼是由3位數組成，第一個數字定義了響應的類別，且有五種可能取值:
- 1xx：指示信息–表示請求已接收，繼續處理。
- 2xx：成功–表示請求已被成功接收、理解、接受。
- 3xx：重定向–要完成請求必須進行更進一步的操作。
- 4xx：客戶端錯誤–請求有語法錯誤或請求無法實現。
- 5xx：服務器端錯誤–服務器未能實現合法的請求。
響應報頭
響應頭主要由Cache-Control、 Connection、Date、Pragma等組成。
響應報文
服務器返回給瀏覽器的文本信息，通常HTML, CSS, JS, 圖片等文件就放在這一部分。
（5）瀏覽器解析渲染頁面，構建DOM樹。
如果說響應的內容是HTML文檔的話，就需要瀏覽器進行解析渲染呈現給用戶。整個過程涉及兩個方面：解析和渲染。在渲染頁面之前，需要構建DOM樹和CSSOM樹。
**瀏覽器是一個邊解析邊渲染的過程。**在遇到外部鏈入的腳本標籤或樣式標籤或圖片時，會再次發送 HTTP 請求重複上述的步驟。在收到 CSS 文件後會對已經渲染的頁面重新渲染，加入它們應有的樣式，圖片文件加載完立刻顯示在相應位置。在這一過程中可能會觸發頁面的重繪或重排。
（6）關閉TCP連接（四次揮手）。
- 一次揮手：客戶端==>服務端，發送一個 FIN，用來關閉客戶端到服務器的數據傳送
- 二次揮手：服務端==>客戶端，收到這個 FIN，它發回一 個 ACK，確認序號爲收到的序號加1 。和 SYN 一樣，一個 FIN 將佔用一個序號
- 三次揮手：客戶端==>服務端，關閉與客戶端的連接，發送一個FIN給客戶端
- 四次揮手：服務端==>客戶端，發回 ACK 報文確認，並將確認序號設置爲收到序號加。
二、HTTP長連接,短連接
在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
長連接和短連接的優點和缺點
長連接：
優點：長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶來說
缺點：在長連接的應用場景下，client端一般不會主動關閉它們之間的連接，Client與server之間的連接如果一直不關閉的話，會存在一個問題，隨着客戶端連接越來越多，server早晚有扛不住的時候。
短連接：
優點：對於服務器來說管理較爲簡單，存在的連接都是有用的連接，不需要額外的控制手段。
缺點：如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和帶寬。
總結
短連接的操作步驟是：
建立連接—>數據傳輸—>關閉連接…建立連接—>數據傳輸—>關閉連接
長連接的操作步驟是：
建立連接—>數據傳輸…（保持連接）…數據傳輸—>關閉連接
三、HTTP是不保存狀態的協議,如何保存用戶狀態?
HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。也就是說，打開一個服務器上的網頁和上一次打開這個服務器上的網頁之間沒有任何聯繫。HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。
那麼我們保存用戶狀態呢？
Session 機制的存在就是爲了解決這個問題，Session 的主要作用就是通過服務端記錄用戶的狀態。典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因爲 HTTP 協議是無狀態的。服務端給特定的用戶創建特定的 Session 之後就可以標識這個用戶並且跟蹤這個用戶了（一般情況下，服務器會在一定時間內保存這個 Session，過了時間限制，就會銷燬這個Session）。
在服務端保存 Session 的方法很多，最常用的就是內存和數據庫(比如是使用內存數據庫redis保存)。既然 Session 存放在服務器端，那麼我們如何實現 Session 跟蹤呢？大部分情況下，我們都是通過在 Cookie 中附加一個 Session ID 來方式來跟蹤。
最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的後面。
四、URI和URL的區別是什麼?
- URI(Uniform Resource Identifier) 是同一資源標誌符，可以唯一標識一個資源。
- URL(Uniform Resource Location) 是同一資源定位符，可以提供該資源的路徑。它是一種具體的 URI，即 URL 可以用來標識一個資源，而且還指明瞭如何 locate 這個資源。
URI的作用像身份證號一樣，URL的作用更像家庭住址一樣。URL是一種具體的URI，它不僅唯一標識資源，而且還提供了定位該資源的信息。
五、HTTP 和 HTTPS 的區別？
- 端口 ：HTTP的URL由“http://”起始且默認使用端口80，而HTTPS的URL由“https://”起始且默認使用端口443。
- 安全性和資源消耗： HTTP協議運行在TCP之上，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS 運行在TCP之上。所有傳輸的內容都經過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多服務器資源。
- 對稱加密：密鑰只有一個，加密解密爲同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
- 非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。