1. HTTP 是什么

HTTP 全稱 “ 超文本傳輸協(xié)議 ”，是一種基于傳輸層 TCP 協(xié)議實現(xiàn)的應用非常廣泛的 應用層協(xié)議

我們平時打開一個網(wǎng)站，就是通過 HTTP 協(xié)議來傳輸數(shù)據(jù)的

當我們在瀏覽器中訪問一個 “ 網(wǎng)址 ”（URL），瀏覽器就會給這個 URL 的服務器發(fā)送一個 HTTP 請求，服務器返回一個 HTTP 響應，這個響應被瀏覽器解析之后，就展現(xiàn)出我們看到的網(wǎng)頁內容

所謂 “ 超文本 ”，就是傳輸?shù)膬热莶粌H僅是文本，還可以是一些圖片、視頻、音頻等二進制的數(shù)據(jù)

HTTP 默認端口號：80

2. HTTP 請求報文和響應報文的格式

1）請求報文格式

1. 請求首行：請求方法 + URL + HTTP協(xié)議版本
2. 請求頭：請求報文的屬性，冒號分隔的鍵值對，每組屬性各占一行
3. 空行
4. 請求體：如果請求體存在，請求頭中會有一個 Content-Length 屬性來表示請求體的長度
   

2）響應報文格式

1. 響應首行：HTTP 協(xié)議版本 + 響應狀態(tài)碼 + 狀態(tài)碼解釋短句
2. 響應頭：響應報文的屬性，冒號分隔的鍵值對，每組屬性各占一行
3. 空行
4. 響應體：如果響應體存在，響應頭中就會有一個 Content-Length 屬性來表示響應體長度，如果服務器返回一個 html 頁面，那么 html 頁面內容就出現(xiàn)在響應體中
   

3）報文中空行的作用

因為 HTTP 協(xié)議沒有規(guī)定報文頭部的鍵值對有多少個，空行就相當于 “ 報頭的結束標志 ” 或者 “ 報頭和主體之間的分隔符 ”

3. HTTP 的長連接和短連接

在 HTTP/1.0 中，默認使用短連接，短連接就是，客戶端訪問的某個 HTML 網(wǎng)頁中包含其他 Web 資源，如 JS 文件、圖像文件、CSS 文件等，客戶端每遇到一個 Web 資源，就會建立一個 HTTP 連接，訪問結束就關閉連接

HTTP/1.1 開始，默認使用長連接，在使用長連接的情況下，客戶端和服務器用于傳輸數(shù)據(jù)的 TCP 連接在一定時間內不會關閉，如果客戶端再次訪問這個服務器上的網(wǎng)頁，會繼續(xù)使用這條已經(jīng)建立的連接。長連接的保持時間可以在不同服務器中進行指定，實現(xiàn)長連接要求客戶端和服務器都支持長連接

HTTP 的長連接和短連接，實質上是 TCP 的長連接和短連接

4. URL

平時我們俗稱的 “ 網(wǎng)址 ” 就是 URL（統(tǒng)一資源定位符）

互聯(lián)網(wǎng)上的每一個文件都有一個唯一的 URL，它包含的信息指出文件的位置以及瀏覽器怎么處理它

基本格式：

1）在瀏覽器中輸入 www.baidu.com 后執(zhí)行的全部過程

1. 域名解析：將 www.baidu.com 解析成 IP 地址

   瀏覽器搜索自己的 DNS 緩存（維護一張域名和 IP 的映射表）；若沒有，則搜索操作系統(tǒng)的 hosts 文件

   若都沒有，則去本地 DNS 服務器進行查詢，本地 DNS 服務器會查詢自己的 DNS 緩存，如果沒有，本地 DNS 服務器會向根域名服務器發(fā)起請求，來查詢域名所對應的 IP 地址，得到結果之后本地 DNS 服務器將結果返回給瀏覽器，同時緩存本次解析的 IP

2. 發(fā)起 TCP 三次握手，建立 TCP 連接。瀏覽器會以一個隨機端口號（1024-65535）向服務器 web 程序的 80 端口發(fā)起 TCP 連接

3. 建立 TCP 連接后，發(fā)起 HTTP 請求

4. 服務器處理請求，對瀏覽器的請求進行響應，瀏覽器得到網(wǎng)頁的 html 文件和一些資源文件

5. 瀏覽器解析 html 文件和資源文件，對頁面進行渲染并呈現(xiàn)出來

5. HTTP 常用的請求方法

6. GET 和 POST 的區(qū)別

• GET 是從服務器上獲取數(shù)據(jù)，POST 是向服務器傳送數(shù)據(jù)
• GET 把參數(shù)包含在 URL 中，POST 的參數(shù)包含在請求體中，因此 POST 相較 GET 更安全些
• GET 請求有長度限制，POST 沒有
• GET 請求是冪等性的，POST 不是。冪等性指對同一個 URL 的多次請求應該返回同樣的結果

7. HTTP 常見的響應狀態(tài)碼

• 200：服務器已成功處理了請求。
• 301：請求的網(wǎng)頁已被永久重定向網(wǎng)頁，服務器響應此狀態(tài)碼時，會自動將請求者轉到新位置
• 302：請求的網(wǎng)頁被臨時重定向到其他網(wǎng)頁
• 400：客戶端請求有語法錯誤，不能被服務器所理解
• 403：服務器收到請求，但拒絕提供服務，有的頁面需要一定權限才能訪問，就可能會出現(xiàn) 403
• 404：服務器未找到請求的頁面
• 405：使用了服務器不允許的請求方法
• 500：服務器內部遇到錯誤，無法完成請求
• 504：服務器負載過大，在處理請求時消耗的時間就會很長，就可能導致出現(xiàn)超時的情況

8. HTTPS 是什么

HTTPS 也是一個應用層協(xié)議，是在 HTTP 協(xié)議的基礎上引入了一個加密層

HTTPS 協(xié)議運行在 SSL 協(xié)議之上，SSL 協(xié)議運行在 TCP 協(xié)議之上

HTTP 協(xié)議內容都是按照文本的方式明文傳輸?shù)模@就可能會導致傳輸過程中出現(xiàn)被篡改的情況

在互聯(lián)網(wǎng)上，明文傳輸是比較危險的事情

HTTPS 就是在 HTTP 的基礎上進行了加密，進一步保證用戶的信息安全

HTTPS 默認端口號：443

1）SSL 協(xié)議

SSL 協(xié)議是一種用于保證互聯(lián)網(wǎng)通信中數(shù)據(jù)安全的標準技術，SSL 協(xié)議使用公鑰、私鑰、和對稱密鑰來加密和解密數(shù)據(jù)，還會使用證書來驗證服務器和客戶端的身份

9. HTTPS 怎么進行 “加密”

加密就是把明文（要傳輸?shù)男畔ⅲ┻M行一系列變換，生成密文，在互聯(lián)網(wǎng)上傳輸時，以密文的形式傳輸，在到達接收方時，接收方再進行一系列變換，將密文轉換成明文

在加密解密的過程中，都會有一個被稱為 “密鑰” 的中間數(shù)據(jù)來輔助進行解密或解密

加密的方式有很多，但整體上分為兩大類：對稱加密 和 非對稱加密

1）對稱加密

對稱加密其實就是信息的發(fā)送方和接收方使用同一個密鑰對密文進行加密和解密。

但是在一開始發(fā)送方和接收方是不知道這個密鑰的，所以發(fā)送信息之前還需要先傳輸密鑰，但是如果密鑰在傳輸過程中被截獲，那么后續(xù)的密文傳輸就與明文傳輸就沒什么區(qū)別了

因此就需要引入 非對稱加密 先對對稱密鑰進行加密傳輸

2）非對稱加密

非對稱加密要用到兩個密鑰，一個叫做 “公鑰”，一個叫做 “私鑰”

• 通過公鑰對明文加密，變成密文
• 通過私鑰對密文解密，變成明文

也可以反著用

• 通過私鑰對明文加密，變成密文
• 通過公鑰對密文解密，變成明文

引入非對稱加密之后

• 客戶端在 本地生成對稱密鑰，通過 公鑰加密，發(fā)送給服務器
• 由于中間的其他網(wǎng)絡設備沒有私鑰，即使截獲了數(shù)據(jù)，也無法還原出內部的對稱密鑰
• 服務器通過 私鑰解密，還原出客戶端發(fā)送的對稱密鑰，并且使用這個對稱密鑰加密對客戶端進行響應
• 后續(xù)服務器和客戶端的通信只需要用到對稱密鑰即可

對稱加密的效率比非對稱加密的效率高很多，所以只是在開始傳輸對稱密鑰時使用非對稱加密，后續(xù)的傳輸使用對稱加密

但是還存在一些問題

• 客戶端怎么獲取公鑰
• 怎么確定這個公鑰不是偽造的

這就需要引入 CA 證書

3）CA 證書

CA 證書是在非對稱加密傳輸對稱密鑰時使用的，客戶端和服務器交換對稱密鑰時，使用非對稱加密對對稱密鑰進行加密，非對稱加密中的公鑰就是由 CA 證書提供的，CA 證書在使用之前客戶端會對其進行合法性校驗，確保 CA 證書不是偽造的

CA 證書中包含的信息：

• 公鑰
• 證書持有者的域名等信息
• 證書認證機構的信息
• 數(shù)字簽名以及使用的算法
• 證書有效期

為了讓服務器的公鑰被客戶端信任，服務器的證書都是由 CA（證書認證機構）簽名的，CA 在網(wǎng)絡中相當于公安局，具有極高的可信度，所以由它來給證書簽名，證書必然是被信任的

CA 對證書簽名的過程：

• 首先 CA 會把證書持有者的公鑰、證書認證機構、證書有效期、持有者的域名等信息進行整合，對這些信息使用特定的 Hash 算法計算 Hash 值
• 然后 CA 會使用自己的私鑰對 Hash 值進行加密，作為證書的簽名

客戶端對證書驗證的過程：

• 客戶端在得到證書之后會使用相同的 Hash 算法獲取證書的 Hash 值
• 通?？蛻舳酥卸紩?CA 的公鑰，客戶端可以使用 CA 的公鑰對簽名進行解密，得到一個 Hash 值
• 對比兩次結果的 Hash 值，如果值相同，則為可以信賴的證書

4）HTTPS 加密的完整流程

HTTPS 的加密過程大致可以分為三個階段：

• 第一階段（非對稱加密）：對證書進行合法性驗證，客戶端內置 CA 的公鑰，服務器在申請證書時同時獲取 CA 的私鑰和自己的公鑰私鑰
• 第二階段（非對稱加密）：對對稱密鑰進行密文傳輸，客戶端使用證書中服務器的公鑰對隨機生成的對稱密鑰進行加密傳輸，服務器使用自己的私鑰進行解密，得到對稱密鑰
• 第三階段（對稱加密）：客戶端與服務端在互通對稱密鑰之后，使用對稱加密傳輸數(shù)據(jù)

10. HTTPS 的優(yōu)缺點

優(yōu)點：

• 安全性：

  HTTPS 在數(shù)據(jù)傳輸過程中保證絕對的密文傳輸，可以防止數(shù)據(jù)在傳輸過程中被竊取或改變，保證數(shù)據(jù)的完整性

缺點：

• 在相同的網(wǎng)絡環(huán)境下，HTTPS 比 HTTP 的響應時間更長
• HTTPS 的安全是有范圍的，在服務器被劫持等情況下幾乎起不到作用
• HTTPS 需要更多的服務器資源，會導致成本升高

11. HTTPS 和 HTTP 的區(qū)別

12. Cookie 和 Session

1）什么是 Cookie

Cookie 是服務器發(fā)送給客戶端并保存到本地的一小塊數(shù)據(jù)，它會在客戶端下一次向同一個服務器發(fā)起請求時被攜帶并發(fā)送到服務器上。用于告知服務器兩次請求來自同一個客戶端，從而在本次請求中響應之前的訪問狀態(tài)

Cookie 的應用：

• 記錄會話的狀態(tài)：如用戶的登錄狀態(tài)
• 記錄個性化設置：如用戶自定義的設置、主題等

2）什么是 Session

Session 代表著服務器和客戶端一次會話的過程，Session 中保存著用戶會話所需的屬性和配置信息，當用戶在應用程序的各個網(wǎng)頁之間跳轉時，存儲在 Session 對象中的屬性和配置信息不會丟失，而是在整個會話中一直存在下去。

3）Cookie 和 Session 的區(qū)別

• Cookie 保存在客戶端，Session 保存在服務端
• Cookie 可以設置長時間保存，Session 一般在客戶端關閉之后就會失效
• Cookie 相對不安全，容易被竊取和偽造，Session 相對安全，因為 Session 數(shù)據(jù)保存在服務端，客戶端無法直接訪問
• Cookie 有大小限制，一般單個 Cookie 不能超過 4 KB，Session 沒有限制

4）Cookie 和 Session 如何配合工作

• 客戶端在首次訪問服務器時，服務器會根據(jù)用戶狀態(tài)信息生成對應的 Session 對象，將唯一的 SessionID 發(fā)送給客戶端
• 客戶端在收到 SessionID 之后，會創(chuàng)建 Cookie 對象，將 SessionID 放入 Cookie 對象，并且在 Cookie 中記錄 此 SessionID 屬于哪個域名
• 在之后訪問同一個域名時，客戶端在發(fā)起請求時會將 Cookie 一并發(fā)送給服務器
• 服務器會根據(jù)得到的 Cookie 得到 SessionID，再通過 SessionID 查找對應的 Session，如果沒找到就說明用戶未登錄或 Session 已經(jīng)過期，需要重新登錄或者創(chuàng)建 Session
• 如果找到了就說明用戶已經(jīng)登錄，服務器就會根據(jù) Session 中對應的用戶信息對網(wǎng)頁進行處理，再將處理后的頁面響應給客戶端

文章來源地址http://www.zghlxwxcb.cn/news/detail-417894.html

到了這里，關于HTTP 和 HTTPS（請求響應報文格式 + 請求方法 + 響應狀態(tài)碼 + HTTPS 加密流程 + Cookie 和 Session）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！