一、HTTP協議

概述

• 超文本傳輸協議(Hypertext Transfer Protocol，簡稱HTTP)是是一個應用層協議，它使用 TCP 連接進行可靠的傳送。
• HTTP 是一種請求/響應式的協議，即一個客戶端與服務器建立連接后，向服務器發(fā)送一個請求;服務器接到請求后，給予相應的響應。

1.1、HTTP請求及響應格式

HTTP請求報文

HTTP 請求報文由請求行、請求頭部、空行 和 請求包體 4 個部分組成，如下圖：

1、請求行：請求行由方法字段、URL 字段 和HTTP 協議版本字段 3 個部分組成，他們之間使用空格隔開。

方法字段：

• GET ：獲取一個資源，同時參數直接跟在URL后面,url長度受限制2048字節(jié)
• POST：不僅可以獲取資源，還可以提交資源（譬如上傳文件），參數放在請求體中，包大小4G
• HEAD：只要響應頭，沒有響應體，通常用于測試URL是否存在
• DELETE：刪除一個資源
• PUT：通常修改一個資源

2、請求頭：請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號“:”分隔。請求頭部通知服務器有關于客戶端請求的信息，

常用的請求頭字段：

• Host：客戶端發(fā)送請求時，用來指定服務器域名。例如：Host: www.A.com

• connection：字段最常用于客戶端要求服務器使用 TCP 持久連接，以便其他請求復用，連接方式(close 或 keepalive);

  注：HTTP/1.1 版本的默認連接都是持久連接，但為了兼容老版本的 HTTP，需要指定 Connection 首部字段的值為 Keep-Alive。

• Cookie：存儲于客戶端擴展字段，向同一域名的服務端發(fā)送屬于該域的cookie;

HTTP 響應報文

TTP 響應報文由狀態(tài)行、響應頭部、空行 和 響應包體 4 個部分組成 ： 如下圖：

1、狀態(tài)行：狀態(tài)行由 HTTP 協議版本字段、狀態(tài)碼和狀態(tài)碼的描述文本 3 個部分組成，他們之間使用空格隔開;

HTTP狀態(tài)碼 ：

狀態(tài)碼由三位數字組成，第一位數字表示響應的類型，常用的狀態(tài)碼有五大類如下所示：

• 1xx：表示服務器已接收了客戶端請求，客戶端可繼續(xù)發(fā)送請求;
• 2xx：表示服務器已成功接收到請求并進行處理;
• 3xx：表示服務器要求客戶端重定向;
• 4xx：表示客戶端的請求有非法內容;
• 5xx：表示服務器未能正常處理客戶端的請求而出現意外錯誤;

狀態(tài)碼描述文本有如下取值：

• 200 OK：表示客戶端請求成功;
• 400 Bad Request：表示客戶端請求有語法錯誤，不能被服務器所理解;
• 401 Unauthonzed：表示請求未經授權，該狀態(tài)代碼必須與 WWW-Authenticate 報頭域一起使用;
• 403 Forbidden：表示服務器收到請求，但是拒絕提供服務，通常會在響應正文中給出不提供服務的原因;
• 404 Not Found：請求的資源不存在，例如，輸入了錯誤的URL;
• 500 Internal Server Error：表示服務器發(fā)生不可預期的錯誤，導致無法完成客戶端的請求;
• 503 Service Unavailable：表示服務器當前不能夠處理客戶端的請求，在一段時間之后，服務器可能會恢復正常;

2、響應頭：

常用的響應頭字段：

• Content-Length：響應體的長度

• Content-Type：字段用于服務器回應時，告訴客戶端，本次數據是什么格式。
  

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

  客戶端請求的時候，可以使用 Accept 字段聲明自己可以接受哪些數據格式。

  Accept: */*

  上面代碼中，客戶端聲明自己可以接受任何格式的數據。

• Content-Encoding：字段說明數據的壓縮方法。表示服務器返回的數據使用了什么壓縮格式 如：Content-Encoding: gzip

  客戶端在請求時，用 Accept-Encoding 字段說明自己可以接受哪些壓縮方法。Accept-Encoding: gzip, deflate

1.2、HTTP1.0 、 HTTP1.1、HTTP2.0

如下是分別介紹HTTP1.0 、 HTTP1.1、HTTP2.0

• HTTP 1.0：默認使用短連接，瀏覽器每次請求都需要與服務器建立一次 TCP 連接，服務器處理完成后立即斷開 TCP 連接（無連接），服務端不記錄客戶端的請求狀態(tài)（無狀態(tài)）。

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

  // Keep-Alive不會永久保持連接，它有一個持續(xù)時間，可以在不同的服務器軟件中設定這個時間。 // 實現長連接需要客戶端和服務端都支持長連接。 Connection:keep-alive

  在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸 HTTP 數據的 TCP 連接不會關閉，客戶端再次訪問這個服務器時，會繼續(xù)使用這一條已經建立的連接。

• HTTP 2.0：引入二進制數據幀和流的概念，支持多路復用、服務器推送，支持使用二進制格式傳輸數據，而 HTTP 1.0 依然使用文本格式傳輸。

二、HTTPS協議

HTTPS的核心就在于SSL和TLS這兩個，注：SSL是TLS的前身，但因為SSL名氣很大所以一般兩個混著叫！

對稱加密： 我們的發(fā)送方和接收方使用**相同的鑰匙**去==快速==加密和解密，但是存在問題：如果加密方式被他人獲取，很容易就會被破解，典型對稱加密算法：DES、AES

非對稱加密：密鑰成對出現（私鑰、公鑰），私鑰只有自己知道，不在網絡中傳輸；而公鑰可以公開。相比對稱加密速度較慢，典型的非對稱加密算法有：RSA、DSA 注意：公鑰和私鑰是一對，如果用公鑰對數據加密，那么只能用對應的私鑰解密。如果用私鑰對數據加密，只能用對應的公鑰進行解密。因為加密和解密用的是不同的密鑰，所以稱為非對稱加密。

以上是對稱加密和非對稱加密的區(qū)別：而我們的SSL/TLS則是兩種加密算法都有用到！

非對稱加密過程 :

(1) A 要向 B 發(fā)送信息，A 和 B 都要產生一對用于加密和解密的公鑰和私鑰。

(2) A 的私鑰保密，A 的公鑰告訴 B；B 的私鑰保密，B 的公鑰告訴 A。

(3) A 要給 B 發(fā)送信息時，A 用 B 的公鑰加密信息，因為 A 知道 B 的公鑰。

(4) A 將這個消息發(fā)給 B (已經用 B 的公鑰加密消息)。

(5) B 收到這個消息后，B 用自己的私鑰解密 A 的消息。其他所有收到這個報文的人都無法解密，因為只有 B 才有 B 的私鑰。

HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協議，如圖：

因此，HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。

問題：HTTPS如何解決：我們溝通的對象是我們想要溝通的對象呢？

例如 : www.bilibili.com 和 www.bi1ibi1i.com 這種問題

HTTPS協議的服務端需要申請SSL證書（其實是TLS，只不過SSL名氣太大！）去證明，B站就是我們要訪問的B站，而不是其他網站偽造的，而想讓SSL整數生效就需要去CA也就是證書頒發(fā)機構（Certificate Authority）去申請，我們的SSL生效以后，我們就可以通過HTTPS去訪問我們的網站了，而且瀏覽器也會把我們HTTP服務器默認的80端口，改為443端口 ！

相關面試題

面試題參考文章

1、HTTP1.0 、 HTTP1.1、HTTP2.0 的主要區(qū)別 ？

• HTTP 1.0：默認使用短連接，瀏覽器每次請求都需要與服務器建立一次 TCP 連接，服務器處理完成后立即斷開 TCP 連接（無連接），服務端不記錄客戶端的請求狀態(tài)（無狀態(tài)）。

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

  // Keep-Alive不會永久保持連接，它有一個持續(xù)時間，可以在不同的服務器軟件中設定這個時間。 // 實現長連接需要客戶端和服務端都支持長連接。 Connection:keep-alive

  在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸 HTTP 數據的 TCP 連接不會關閉，客戶端再次訪問這個服務器時，會繼續(xù)使用這一條已經建立的連接。

• HTTP 2.0：引入二進制數據幀和流的概念，支持多路復用、服務器推送，支持使用二進制格式傳輸數據，而 HTTP 1.0 依然使用文本格式傳輸。

2、GET 和 POST 的區(qū)別？

• URL 中參數可見性：GET 參數可見（通過拼接 URL 進行傳遞參數），POST 參數不可見。
• 是否可緩存：GET 請求是可以緩存的，POST 請求不可以緩存。
• 傳輸數據的大小：GET 一般傳輸數據大小不超過 2k-4k（根據瀏覽器不同，限制不一樣，但相差不大），POST 請求傳輸數據的大小根據 php.ini 配置文件設定，也可以無限大。
• 安全性：GET 不安全，POST 安全。
• 數據包個數：GET 產生一個 TCP 數據包；POST 產生兩個 TCP 數據包。

3、講一下HTTP 的優(yōu)缺點

• HTTP 協議的特性「無狀態(tài)、明文傳輸」既是優(yōu)點也是缺點，同時還有一大缺點「不安全」。

① 無狀態(tài)協議的優(yōu)缺點：

• 無狀態(tài)的好處：服務器不用去記憶 HTTP 的狀態(tài)，不需要額外的資源來記錄狀態(tài)信息，這能減輕服務器的負擔，能夠把更多的 CPU 和內存資源用在對外提供服務上。

• 無狀態(tài)的壞處：服務器沒有記憶能力，它在完成有關聯性的操作時會非常麻煩。

  ? 例如登錄 -> 添加購物車 -> 下單 -> 結算 -> 支付，這系列操作都要知道用戶的身份才行。但服務器不知道這些請求是有關聯的，每次都要確認一遍用戶身份信息。

對于無狀態(tài)的問題，解法方案有很多種，其中比較簡單的方式用 Cookie 技術。

Cookie 通過在請求和響應中寫入 Cookie 信息來控制客戶端的狀態(tài)。相當于，在客戶端第一次請求后，服務器會下發(fā)一個帶有客戶身份信息的「小貼紙」，后續(xù)客戶端請求服務器的時候，帶上「小貼紙」，服務器就能識別了：在這里插入圖片描述

② 明文傳輸的優(yōu)缺點：

• 明文意味著在傳輸過程中的信息，是可方便閱讀的，通過瀏覽器的 F12 控制臺或 Wireshark 抓包都可以直接肉眼查看，為我們調試工作帶了極大的便利性。
• 但是這正是這樣，HTTP 的所有信息都暴露在了光天化日下，相當于信息裸奔。在傳輸的漫長的過程中，信息的內容都毫無隱私可言，很容易就能被竊取，如果里面有你的賬號密碼信息，那你號沒了。

4、HTTPS和HTTP的區(qū)別是什么？

• ① 安全性區(qū)別：HTTP 是超文本傳輸協議，信息是明文傳輸，存在安全風險的問題。HTTPS 可以保證信息傳輸安全，在 TCP 和 HTTP 網絡層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸。
• ② 建里連接流程區(qū)別：HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。
• ③ 端口區(qū)別：HTTP 的端口號是 80，HTTPS 的端口號是 443。
• ④ 是否需要申請數字證書：HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的。而 HTTP 協議不需要。

5、Cookie和Session的作用以及有什么區(qū)別？

Cookie和Session的作用 ？

• Cookie 一般用來保存用戶信息。比如我們在 Cookie 中保存已經登錄過得用戶信息，下次訪問網站的時候頁面可以自動幫你登錄的一些基本信息給填了；
• **Session 的主要作用就是通過服務端記錄用戶的狀態(tài)。**典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因為 HTTP 協議是無狀態(tài)的。服務端給特定的用戶創(chuàng)建特定的 Session 之后就可以標識這個用戶并且跟蹤這個用戶了。

Cookie和Session的區(qū)別 ？

• Cookie 數據保存在客戶端，Session 數據保存在服務器端。
• Cookie 存儲在客戶端中，而Session存儲在服務器上，相對來說 Session 安全性更高。如果要在 Cookie 中存儲一些敏感信息，不要直接寫入 Cookie 中，最好能將 Cookie 信息加密然后使用到的時候再去服務器端解密。
• Cookie ?般?來保存?戶信息，Session 的主要作用就是通過服務端記錄用戶的狀態(tài)。

6、URL和URI的之間有什么區(qū)別？

參考文章：

• https://blog.csdn.net/sinat_38719275/article/details/102607458
• https://blog.csdn.net/qq_32595453/article/details/80563142

• URI：是統一資源標志符，可以唯一標識一個資源。
• URL：是統一資源定位符，可以提供該資源的路徑。URL 是 URI 的一個子集，它不僅唯一標識資源，而且還提供了定位該資源的信息。

URI 的作用像身份證號一樣，URL 的作用更像家庭住址一樣。

7、簡單介紹一下對稱加密算法和非對稱加密算法的區(qū)別？

• 對稱加密算法：雙方持有相同的密鑰，進行加密速度快，典型對稱加密算法：DES、AES。
• 非對稱加密算法：密鑰成對出現（私鑰、公鑰），私鑰只有自己知道，不在網絡中傳輸；而公鑰可以公開。相比對稱加密速度較慢，典型的非對稱加密算法有：RSA、DSA。

8、HTTPS 是如何建立連接的？其間交互了什么？

HTTPS 是在 HTTP 與 TCP 之間加了一層 SSL/TLS 協議 ，所以建里連接流程如下：

① 首先建立 TCP 連接：三次握手。

② 然后建里 SSL/TLS 加密：

SSL/TLS 協議基本流程：

• 客戶端向服務器索要并驗證服務器的公鑰。
• 雙方協商生產「會話秘鑰」。
• 雙方采用「會話秘鑰」進行加密通信。
• 前兩步也就是 SSL/TLS 的建立過程，也就是握手階段。

③ 發(fā)送HTTP 請求。

參考文章：https://csp1999.blog.csdn.net/article/details/117506872

總結

以上是生活随笔為你收集整理的HTTP、HTTPS详解及相关面试题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。