1.在瀏覽器中輸? URL 地址到顯示主頁的程序？

1.瀏覽器決議URL

URL = 協議 + 存放資源的主機域名 + 檔案路徑名
如果沒有檔案路徑名，則訪問index.html、default.html這些默認檔案，

2.生成Http請求訊息

請求報文 = 請求行 + 訊息頭 + 訊息體
回應報文 = 狀態行 + 訊息頭 + 訊息體

3.查詢服務器域名對應的IP地址——DNS決議——迭代查詢

1.客戶端首先會發出一個DNS請求，問www.server.com的IP是啥，并發給本地DNS服務器（即，客戶端的 TCP/IP 設定中填寫的 DNS 服務器地址）；
2.本地DNS服務器收到客戶端的請求后，如果快取里的表格能找到 www.server.com，則它直接回傳 IP 地址，

• 如果沒有本地DNS服務器會去請求根DNS服務器；

3.根 DNS 收到來自本地 DNS 的請求后，發現后置是 .com，會把 .com 頂級DNS服務器地址給本地 DNS；
4.本地 DNS 收到**.com 頂級DNS服務器的地址后，對其發起請求；
5..com 頂級DNS服務器收到本地DNS請求后，回應給他一個www.server.com 區域的權威 DNS 服務器的地址；
6.本地DNS收到之后，會向www.server.com區域的權威 DNS 服務器發起請求，就會收到對應的 IP 地址**；
7.本地 DNS 再將 IP 地址回傳客戶端，客戶端和目標建立連接，

4.TCP連接

瀏覽器獲得域名對應的IP地址后，向服務器請求連接，發起TCP三次握手；

5.發送Http請求

TCP連接建立起來后，瀏覽器向服務器發起Http請求；

6.服務器處理請求并回傳Http報文

服務器收到客戶端的請求，并根據路徑引數映射到特定的請求處理器進行處理，并將處理結果及對應視圖回傳給瀏覽器；

7.瀏覽器決議渲染頁面

瀏覽器決議并渲染視圖，若遇到js檔案、css檔案及圖片等靜態資源的參考，則重復上述步驟向服務器請求資源，向用戶呈現完整頁面；

8.連接結束

2.Http常見面試題

2.1.Http基本概念

1.Http是什么？

• 超文本傳輸協議，是一個在計算機世界里專門在**「兩點」之間「傳輸」文字、圖片、音頻、視頻等「超文本」資料的「約定和規范」**，

2.Http常見狀態碼？

2xx：成功，報文已收到并被正確處理；

• 200，OK
• 204，OK，但是回應頭沒有body資料；

3xx：重定向，資源位置發生變動，需要客戶端重新發送請求；

• 301，永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問，
• 302，臨時重定向，請求的資源還在，但暫時需要用另一個 URL 來訪問，

4xx：客戶端錯誤

• 403，表示服務器禁止訪問資源，并非客戶端請求出錯；
• 404，表示請求的資源在服務器上找不到；

5xx：服務端錯誤

• 501，客戶端請求的功能還不支持
• 503，表示服務器很忙，暫時無法回應

3.Http 常見欄位有哪些？

Host：指定服務器的域名；

Host: www.baidu.com

Content-Length 欄位：表明本次回傳資料的長度；
Connection欄位：客戶端要求服務器使用 TCP 長連接;

Connection: keep-alive

Content-Type 欄位：表示本次資料的編碼方式;

Content-Type: text/html; charset=utf-8

Content-Encoding 欄位：表示資料的壓縮方法;

Content-Encoding: gzip

2.2.Get、Post

1.Get、Post兩者區別

1.Get 方法：含義是請求從服務器獲取資源，這個資源可以是靜態的文本、頁面、圖片視頻等，
2.Post 方法：它向 URI 指定的資源提交資料，資料就放在報文的 body 里，

2.GET 和 POST 方法都是安全和冪等的嗎？

Get：安全且冪等，
POST：不安全、不冪等， 因為是「新增或提交資料」的操作，會修改服務器上的資源，且多次提交資料就會創建多個資源，

2.3.HTTP特性

1.http優點

• 簡單、靈活和易于擴展、應用廣泛和跨平臺

2.http缺點

• 明文傳輸（不加密），內容可能會被竊聽，比如，賬號資訊容易泄漏，那你號沒了，
• 不驗證通信方的身份，因此有可能遭遇偽裝，比如，訪問假的淘寶、拼多多，那你錢沒了，
• 無法證明報文的完整性，所以有可能已遭篡改，比如，網頁上植入垃圾廣告，視覺污染，眼沒了，

2.4.Https與Http

1.HTTP 與 HTTPS 有哪些區別？

1.Https在TCP和Http網路層之間加入了SSL/TLS安全協議，使得報文能夠加密傳輸；（防明文傳輸）
2.Https在Tcp三次握手之后，還要進行SSL/TLS的握手程序，才可以進行加密報文傳輸；（防篡改）
3.Https協議要向CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的，
4.Https的埠號是443,Http埠號是80，

2.Https解決了Http的哪些問題？

1.資訊加密：互動資訊無法被竊取；
2.校驗機制：防篡改內容，篡改了就不能正常顯示；
3.身份證書：可以證明網站真實性，

3.HTTPS 是如何解決上面的三個風險的？

1.混合加密的方式實作資訊的機密性，解決了竊聽的風險，

• 1.通信建立前，先用非對稱加密的方式交換會話密鑰，后續不再使用非對稱加密；
• 2.通信程序中，全部使用對稱加密的會話密鑰的方式加密解密，
  

2.摘要演算法的方式來實作完整性，它能夠為資料生成獨一無二的「指紋」，指紋用于校驗資料的完整性，解決了篡改的風險，

• 客戶端在發送明文之前會通過摘要演算法算出明文的「指紋」，發送的時候把**「指紋 + 明文」一同加密成密文后，發送給服務器，服務器解密后**，用相同的摘要演算法算出發送過來的明文，通過比較客戶端攜帶的「指紋」和當前算出的**「指紋」做比較**，若「指紋」相同，說明資料是完整的，
  

3.將服務器公鑰放入到數字證書中，解決了冒充的風險，

• 如何保證公鑰不被篡改和信任度？
  借助第三方權威機構 CA （數字證書認證機構），將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的，
  

4.HTTPS 是如何建立連接的？其間互動了什么？

SSL/TLS 協議基本流程：（前兩步也就是 SSL/TLS 的建立程序，也就是握手階段，）

• 1.客戶端向服務器索要并驗證服務器的公鑰，
• 2.雙方協商生產「會話秘鑰」，
• 3.雙方采用「會話秘鑰」進行加密通信，

SSL/TLS 的「握手階段」涉及四次通信，可見下圖：

1. ClientHello
由客戶端向服務器發起加密通信請求，也就是 ClientHello 請求，客戶端主要向服務器發送以下資訊：

• （1）客戶端支持的 SSL/TLS 協議版本，如 TLS 1.2 版本，
• （2）客戶端生產的亂數（Client Random），后面用于生產「會話秘鑰」，
• （3）客戶端支持的密碼套件串列，如 RSA 加密演算法，

2. SeverHello
服務器收到客戶端請求后，向客戶端發出回應，也就是 SeverHello，服務器回應的內容有如下內容：

• （1）確認 SSL/ TLS 協議版本，如果瀏覽器不支持，則關閉加密通信，
• （2）服務器生產的亂數（Server Random），后面用于生產「會話秘鑰」，
• （3）確認的密碼套件串列，如 RSA 加密演算法，
• （4）服務器的CA數字證書，

3. 客戶端回應
客戶端收到服務器的回應之后，首先通過瀏覽器或者作業系統中的 CA 公鑰，確認服務器的數字證書的真實性，
如果證書沒有問題，客戶端會從數字證書中取出服務器的公鑰，然后使用它加密報文，向服務器發送如下資訊：

• （1）一個亂數（pre-master key），該亂數會被服務器公鑰加密，
• （2）加密通信演算法改變通知，表示隨后的資訊都將用「會話秘鑰」加密通信，
• （3）客戶端握手結束通知，表示客戶端的握手階段已經結束，這一項同時把之前所有內容的發生的資料做個摘要，用來供服務端校驗，

上面第一項的亂數是整個握手階段的第三個亂數，這樣服務器和客戶端就同時有三個亂數，接著就用雙方協商的加密演算法，各自生成本次通信的「會話秘鑰」，

4. 服務器的最后回應

服務器收到客戶端的第三個亂數（pre-master key）之后，通過協商的加密演算法，計算出本次通信的「會話秘鑰」，然后，向客戶端發生最后的資訊：

• （1）加密通信演算法改變通知，表示隨后的資訊都將用「會話秘鑰」加密通信，
• （2）服務器握手結束通知，表示服務器的握手階段已經結束，這一項同時把之前所有內容的發生的資料做個摘要，用來供客戶端校驗，

至此，整個 SSL/TLS 的握手階段全部結束，接下來，客戶端與服務器進入加密通信，就完全是使用普通的 HTTP 協議，只不過用「會話秘鑰」加密內容，

5.Http/1.1、Http/1.2、Http/1.3演變

3.Http長連接、短連接的區別與應用場景

1.HTTP短連接

HTTP/1.0 中默認使用短連接，

2.HTTP長連接

HTTP/1.1 起，默認使用長連接，用以保持連接特性，使用長連接的 HTTP 協議，會在回應頭加入這行代碼：

Connection:keep-alive

HTTP ?般會有 httpd 守護行程，??可以設定 keep-alive timeout，當 tcp 鏈接閑置超過這個時間就會關閉，也可以在 HTTP 的 header ??設定超時時間

3.長連接和短連接的應用場景

1.長連接多用于操作頻繁，點對點的通訊，而且連接數不能太多情況，

2.短連接多用于并發量大，但每個用戶無需頻繁操作的場景， WEB 網站的 http 服務一般都用短連接， WEB 網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源， 如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧，

4.全網最透徹HTTPS

5.TCP

6. UDP