HTTP 的15個常見知識點複習

前言

自從入職新公司到現在，我們前端團隊內部一直在做 ?每週一練 的知識複習計劃，我之前整理了一個 每週一練 之 資料結構與演算法 學習內容，大家也快去看看~~

最近三週，主要複習 網路基礎 相關的知識，今天我把這三週複習的知識和參考答案，整理成本文，歡迎各位朋友互相學習和指點，覺得本文不錯，也歡迎點贊哈??。

特別喜歡現在的每週學習和分享，哈哈哈~~?

?推薦一個 github 倉庫 —— 《awesome-http》，內容挺棒的。

注：本文整理資料來源網路，有些圖片/段落找不到原文出處，如有侵權，聯絡刪除。

一. 簡述瀏覽器輸入 URL 地址後發生的事情

1.1 描述

1. 瀏覽器向 DNS 伺服器查詢輸入 URL 對應的 IP 地址。
2. NS 伺服器返回網站的 IP 地址。
3. 瀏覽器根據 IP 地址與目標 web 伺服器在 80 埠上建立 TCP 連線。
4. 瀏覽器獲取請求頁面的 HTML 程式碼。
5. 瀏覽器在顯示視窗內渲染 HTML 。
6. 視窗關閉時，瀏覽器終止與伺服器的連線。

1.2 TCP 知識點補充

參考文章：《TCP三次握手和四次揮手協議》

建立 TCP 需要三次握手才能建立，而斷開連線則需要四次握手。整個過程如下圖所示：

TCP三次握手：

所謂的三次握手，是指建立一個 TCP 連線時，需要客戶端和伺服器端總共傳送三個包，三次握手的目的是連線伺服器的指定埠，建立 TCP 連線，並同步連線雙方的序列號和確認號並交換 TCP 視窗大小資訊，在 SOCKET 程式設計中，客戶端執行 connect() 時，將會觸發三次握手：

TCP四次揮手：

TCP連線的拆除需要傳送四個包，客戶端或者伺服器端均可主動發起揮手動作，在SOCKET程式設計中，任何一方執行close()即可產生揮手操作。

2. 請介紹常見的 HTTP 狀態碼(至少五個)

狀態碼是由 3 位陣列成，第一個數字定義了響應的類別，且有五種可能取值:

1xx：指示資訊–表示請求已接收，繼續處理。

• 100 客戶必須繼續發出請求

• 101 客戶要求伺服器根據請求轉換HTTP協議版本

2xx：成功–表示請求已被成功接收、理解、接受。

• 200 （成功） 伺服器已成功處理了請求。 通常，這表示伺服器提供了請求的網頁。

• 201 （已建立） 請求成功並且伺服器建立了新的資源。

• 202 （已接受） 伺服器已接受請求，但尚未處理。

3xx：重定向–要完成請求必須進行更進一步的操作。

• 300 （多種選擇） 針對請求，伺服器可執行多種操作。 伺服器可根據請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。

• 301 （永久移動） 請求的網頁已永久移動到新位置。 伺服器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。

• 302 （臨時移動） 伺服器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。

4xx：客戶端錯誤–請求有語法錯誤或請求無法實現。

• 400 （錯誤請求） 伺服器不理解請求的語法。

• 401 （未授權） 請求要求身份驗證。 對於需要登入的網頁，伺服器可能返回此響應。

• 403 （禁止） 伺服器拒絕請求。

5xx：伺服器端錯誤–伺服器未能實現合法的請求。

• 500 （伺服器內部錯誤） 伺服器遇到錯誤，無法完成請求。

• 501 （尚未實施） 伺服器不具備完成請求的功能。 例如，伺服器無法識別請求方法時可能會返回此程式碼。

• 502 （錯誤閘道器） 伺服器作為閘道器或代理，從上游伺服器收到無效響應。

• 503 （服務不可用） 伺服器目前無法使用（由於超載或停機維護）。 通常，這只是暫時狀態。

• 504 （閘道器超時） 伺服器作為閘道器或代理，但是沒有及時從上游伺服器收到請求。

• 505 （HTTP 版本不受支援） 伺服器不支援請求中所用的 HTTP 協議版本。

3. 請介紹常見的 HTTP 頭部(至少五個)

3.1 HTTP 頭部

更多完整內容，可以檢視 《HTTP響應頭和請求頭資訊對照表》

首部欄位名	說明
Accept	告訴伺服器，客戶端支援的資料型別。
Accept-Charset	告訴伺服器，客戶端採用的編碼。
Accept-Encoding	告訴伺服器，客戶機支援的資料壓縮格式。
Accept-Language	告訴伺服器，客戶機的語言環境。
Host	客戶機通過這個頭告訴伺服器，想訪問的主機名。
If-Modified-Since	客戶機通過這個頭告訴伺服器，資源的快取時間。
Referer	客戶機通過這個頭告訴伺服器，它是從哪個資源來訪問伺服器的。（一般用於防盜鏈）
User-Agent	客戶機通過這個頭告訴伺服器，客戶機的軟體環境。
Cookie	客戶機通過這個頭告訴伺服器，可以向伺服器帶資料。
Connection	客戶機通過這個頭告訴伺服器，請求完後是關閉還是保持連結。
Date	客戶機通過這個頭告訴伺服器，客戶機當前請求時間

3.2 Request Header

參考文章：《HTTP常用頭部資訊》

舉例：

Request Header	描述
GET /sample.Jsp HTTP/1.1	請求行
Host: www.uuid.online/	請求的目標域名和埠號
Origin: http://localhost:8081/	請求的來源域名和埠號 （跨域請求時，瀏覽器會自動帶上這個頭資訊）
Referer: https:/localhost:8081/link?query=xxxxx	請求資源的完整URI
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36	瀏覽器資訊
Cookie: BAIDUID=FA89F036:FG=1; BD_HOME=1; sugstore=0	當前域名下的Cookie
Accept: text/html,image/apng	代表客戶端希望接受的資料型別是html或者是png圖片型別
Accept-Encoding: gzip, deflate	代表客戶端能支援 gzip 和 deflate 格式的壓縮
Accept-Language: zh-CN,zh;q=0.9	代表客戶端可以支援語言 zh-CN 或者 zh (值得一提的是q(0~1)是優先順序權重的意思，不寫預設為1，這裡 zh-CN 是1， zh 是0.9)
Connection: keep-alive	告訴伺服器，客戶端需要的 tcp 連線是一個長連線

3.3 Response Header

參考文章：《HTTP常用頭部資訊》

舉例：

Response Header	描述
HTTP/1.1 200 OK	響應狀態行
Date: Mon, 30 Jul 2018 02:50:55 GMT	服務端傳送資源時的伺服器時間
Expires: Wed, 31 Dec 1969 23:59:59 GMT	較過時的一種驗證快取的方式，與瀏覽器（客戶端）的時間比較，超過這個時間就不用快取（不和伺服器進行驗證），適合版本比較穩定的網頁
Cache-Control: no-cache	現在最多使用的控制快取的方式，會和伺服器進行快取驗
etag: "fb8ba2f80b1d324bb997cbe188f28187-ssl-df"	一般是Nginx靜態伺服器發來的靜態檔案簽名，瀏覽在沒有 “Disabled cache” 情況下，接收到 etag 後，同一個 url 第二次請求就會自動帶上 “If-None-Match”
Last-Modified: Fri, 27 Jul 2018 11:04:55 GMT	伺服器發來的當前資源最後一次修改的時間，下次請求時，如果伺服器上當前資源的修改時間大於這個時間，就返回新的資源內容
Content-Type: text/html; charset=utf-8	如果返回是流式的資料，我們就必須告訴瀏覽器這個頭，不然瀏覽器會下載這個頁面，同時告訴瀏覽器是utf8編碼，否則可能出現亂碼
Content-Encoding: gzip	告訴客戶端，應該採用gzip對資源進行解碼
Connection: keep-alive	告訴客戶端伺服器的tcp連線也是一個長連線

4. 請列舉常用的 HTTP 方法，並介紹 GET 與 POST 請求之間的區別

4.1 HTTP Request Method

參考文章：《HTTP請求方法對照表》

根據 HTTP 標準，HTTP 請求可以使用多種請求方法。 HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。 HTTP/1.1 新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

序號	方法	描述
1	GET	請求指定的頁面資訊，並返回實體主體。
2	HEAD	類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
3	POST	向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
4	PUT	從客戶端向伺服器傳送的資料取代指定的文件的內容。
5	DELETE	請求伺服器刪除指定的頁面。
6	CONNECT	HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
7	OPTIONS	允許客戶端檢視伺服器的效能。
8	TRACE	回顯伺服器收到的請求，主要用於測試或診斷。
9	PATCH	實體中包含一個表，表中說明與該URI所表示的原內容的區別。
10	MOVE	請求伺服器將指定的頁面移至另一個網路地址。
11	COPY	請求伺服器將指定的頁面拷貝至另一個網路地址。
12	LINK	請求伺服器建立連結關係。
13	UNLINK	斷開連結關係。
14	WRAPPED	允許客戶端傳送經過封裝的請求。
15	Extension-mothed	在不改動協議的前提下，可增加另外的方法。

4.2 GET 與 POST 請求之間的區別

區別內容	GET	POST
點選返回/重新整理按鈕	沒有影響	資料會重新傳送（瀏覽器將會提示“資料被重新提交”）
新增書籤	可以	不可以
快取	可以	不可以
編碼型別（Encoding type）	application/x-www-form-rulencoded	application/x-www-form-rulencoded or multipart/form-data 請為二進位制資料使用 multipart 編碼
歷史記錄	有	沒有
長度限制	有	沒有
資料型別限制	只允許 ASCLll 字元型別	沒有限制，允許二進位制資料
安全性	查詢字串會顯示在位址列的 URL 上，不安全，請不要使用 GET 請求提交敏感資料	因為資料不會顯示在位址列中，也不會快取下來或儲存在瀏覽記錄中，所以 POST 請求比 GET 請求安全，但也不是最安全的方式，如需要傳送敏感資料，請使用資料加密。
可見性	查詢字串在位址列的 URL 中可見	查詢字串在位址列的 URL 中不可見

5. 請分別介紹 Cookie 和 Session 的作用及它們之間的區別

參考文章： 《3分鐘搞懂Cookie與Session》

5.1 Cookie簡單介紹

Cookie是儲存在使用者本地計算機上，用於儲存一些使用者操作的歷史資訊，當使用者再次訪問我們的伺服器的時候，瀏覽器通過HTTP協議，將他們本地的Cookie內容也發到我們們伺服器上，從而完成驗證。

• Cookie 是儲存在瀏覽器客戶的一小片資料；
• Cookie 可以同時被前臺與後臺操作；
• Cookie 可以跨頁面存取；
• Cookie 是不可以跨伺服器訪問的；
• Cookie 有限制； 每個瀏覽器儲存的個數不能超過300個，每個伺服器不能超過20個，資料量不能超過4K；
• Cookie 是有生命週期的，預設與瀏覽器相同，如果程式退出，cookie會被銷燬

5.2 Session

Session 儲存在我們的伺服器上，就是在我們的伺服器上儲存使用者的操作資訊。

當使用者訪問我們的網站時，我們的伺服器會成一個 Session ID，然後把 Session ID 儲存起來，再把這個 Session ID發給我們的使用者，使用者再次訪問我們的伺服器的時候，拿著這個 Session ID就能驗證了，當這個ID能與我們伺服器上儲存的ID對應起來時，我們就可以認為是自己人。

• seesion 資料儲存在伺服器端；
• 每一個會話分配一個單獨的 session_id;
• 該 session_id 通過 cookie 傳送到前臺，預設的 session_id 名稱是PHPSESSIONID;
• 前臺只能看到 Session 的 ID，而不能修改 Session 值;
• 使用 Session之前需要先開啟會話;
• Session儲存在 Session陣列 $_SESSION;
• Session儲存方式比較安全，但是如果 Session數量過多，會導致伺服器效能下降;

5.3 兩者區別

	Cookie	session
定義	瀏覽器儲存使用者資訊的檔案，儲存的數量和字元數都有限制	伺服器把sessionID 和使用者資訊、使用者操作，記錄在伺服器上，這些記錄就稱為session
相同點	都是為了儲存使用者相關的資訊
儲存	客戶端	伺服器
安全性	安全性不高，任何人都能直接檢視	安全性高

5.4 兩者結合使用

• 儲存在服務端：通過 cookie儲存一個 session_id，然後具體的資料則是儲存在 session中。如果使用者已經登入，則伺服器會在 cookie中儲存一個 session_id，下次再次請求的時候，會把該 session_id攜帶上來，伺服器根據 session_id在 session庫中獲取使用者的 session資料。就能知道該使用者到底是誰，以及之前儲存的一些狀態資訊。這種專業術語叫做 server side session。

• 將 session資料加密，然後儲存在 cookie中。這種專業術語叫做 client side session。

6. 請介紹 HTTP 請求報文與響應報文格式

6.1 請求報文

請求報文由請求行、請求頭部和請求正文組成：

• 請求行

格式為：

請求方法 + 空格 + URL + 空格 + 協議版本 + 回車符 + 換行符
複製程式碼

例如：

GET www.baidu.com HTTP/1.1  
複製程式碼

常見的請求方法有：GET，HEAD，PUT，POST，TRACE，OPTIONS，DELETE以及擴充套件方法。

• 請求頭部

格式為：

頭部欄位名 + 冒號（:） + 值 + 回車符 + 換行符
複製程式碼

請求頭部為請求報文新增了一些附加資訊，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。

並且，在請求頭部的最後會有一個空行，表示請求頭部結束，這一行必不可少。

典型的請求頭部有：

請求頭部	說明
Host	接受請求的伺服器地址，可以是IP:埠號，也可以是域名
User-Agent	傳送請求的應用程式名稱
Connection	指定與連線相關的屬性，如Connection:Keep-Alive
Accept-Charset	通知服務端可以傳送的編碼格式
Accept-Encoding	通知服務端可以傳送的資料壓縮格式
Accept-Language	通知服務端可以傳送的語言

• 請求正文

一般使用在 POST 方法中， GET 方法不存在請求正文。
POST 方法適用於需要客戶填寫表單的場合。與請求資料相關的最常使用的請求頭是 Content-Type 和 Content-Length 。

6.2 響應報文

響應報文由狀態行、響應頭部和響應正文組成：

• 狀態行

格式為：

協議版本 + 空格 + 狀態碼 + 空格 + 狀態碼描述 + 回車符 + 換行符
複製程式碼

狀態碼劃分：

100〜199的狀態碼是 HTTP / 1.1 向協議中引入了資訊性狀態碼；
200〜299的狀態碼錶示成功；
300〜399的狀態碼指資源重定向；
400〜499的狀態碼指客戶端請求出錯；
500〜599的狀態碼指服務端出錯；

常見的狀態碼：

狀態碼	說明
200	響應成功
302	跳轉，跳轉地址通過響應頭中的位置屬性指定（JSP中Forward和Redirect之間的區別）
400	客戶端請求有語法錯誤，不能被伺服器識別
403	伺服器接收到請求，但是拒絕提供服務（認證失敗）
404	請求資源不存在
500	伺服器內部錯誤

• 響應頭部

格式為：

頭部欄位名 + 冒號（:） + 值 + 回車符 + 換行符
複製程式碼

常見響應頭部：

響應頭部	說明
Server	伺服器應用程式軟體的名稱和版本
Content-Type	響應正文的型別（是圖片還是二進位制字串）
Content-Length	響應正文長度
Content-Charset	響應正文使用的編碼
Content-Encoding	響應正文使用的資料壓縮格式
Content-Language	響應正文使用的語言

7. HTTP/1.1 有什麼優缺點

參考文章：《HTTP/1.0 HTTP/1.1 HTTP/2.0 主要特性對比》

對於 HTTP/1.1，不僅繼承了 HTTP1.0簡單的特點，還克服了諸多 HTTP1.0效能上的問題。

7.1 HTTP/1.1 優點

1. 增加永續性連線

也就是多個請求和響應可以利用同一個 TCP 連線，而不是每一次請求響應都要新建一個TCP連線，減少了建立和關閉連線的消耗和延遲。

Connection: keep-alive
複製程式碼

2. 增加管道機制

增加了管道機制，請求可以同時發出，但是響應必須按照請求發出的順序依次返回，效能在一定程度上得到了改善。

3. 分塊傳輸

在 HTTP/1.1 版本中，可以不必等待資料完全處理完畢再返回，伺服器產生部分資料，那麼就傳送部分資料，很明此種方式更加優秀一些，可以節省很多等待時間。

4. 增加 host 欄位

使得一個伺服器能夠用來建立多個 Web 站點。

5. 錯誤提示

HTTP/1.1 引入了一個 Warning 頭域，增加對錯誤或警告資訊的描述，此外，在 HTTP/1.1 中新增了24個狀態響應碼(100，101，203，205，206，301，305… )。

6. 頻寬優化

HTTP/1.1 中在請求訊息中引入了 range頭域，它允許只請求資源的某個部分。

在響應訊息中 Content-Range頭域宣告瞭返回的這部分物件的偏移值和長度。如果伺服器相應地返回了物件所請求範圍的內容，則響應碼為 206（Partial Content），它可以防止 Cache將響應誤以為是完整的一個物件，HTTP/1.1 加入了一個新的狀態碼 100（Continue）。客戶端事先傳送一個只帶頭域的請求，如果伺服器因為許可權拒絕了請求，就回送響應碼 401（Unauthorized）；如果伺服器接收此請求就回送響應碼 100，客戶端就可以繼續傳送帶實體的完整請求了。

注意，HTTP/1.0 的客戶端不支援 100 響應碼。但可以讓客戶端在請求訊息中加入 Expect頭域，並將它的值設定為 100-continue。

7.2 HTTP/1.1 缺點

1. 隊頭阻塞

此版本的網路延遲問題主要由於隊頭堵塞導致，雖然通過永續性連線得到改善，但是每一個請求的響應依然需要按照順序排隊，如果前面的響應處理較為耗費時間，那麼同樣非常耗費效能。

2. 技術不成熟

還有此版本雖然引進了管道機制，但是當前存在諸多問題，且預設處於關閉狀態。

3. 浪費資源

http/1.1 請求會攜帶大量冗餘的頭資訊，浪費了很多寬頻資源。

8. 相比 HTTP/1.1，HTTP/2.0 有哪些新特性

參考文章：《HTTP1.0 HTTP/1.1 HTTP2.0 主要特性對比》

• 二進位制分幀

在應用層（HTTP/2.0）和傳輸層（TCP or UDP）之間增加一個二進位制分幀層，從而突破 HTTP1.1 的效能限制，改進傳輸效能，實現低延遲和高吞吐量。

可見，雖然 HTTP/2.0 的協議和 HTTP1.x 協議之間的規範完全不同了，但是實際上 HTTP/2.0並 沒有改變 HTTP1.x 的語義。

簡單來說，HTTP/2.0 只是把原來 HTTP1.x 的 header 和 body 部分用 frame 重新封裝了一層而已。

• 多路複用（連線共享）

允許同時通過單一的 HTTP/2 連線發起多重的請求-響應訊息，這個強大的功能則是基於“二進位制分幀”的特性。

從圖中可見，所有的 HTTP/2.0 通訊都在一個 TCP 連線上完成，這個連線可以承載任意數量的雙向資料流。

每個資料流以訊息的形式傳送，而訊息由一或多個幀組成。這些幀可以亂序傳送，然後再根據每個幀頭部的流識別符號（stream id）重新組裝。

• 首部壓縮

HTTP1.1 不支援 header 資料的壓縮，HTTP/2.0 使用 HPACK 演算法對 header 的資料進行壓縮，這樣資料體積小了，在網路上傳輸就會更快。高效的壓縮演算法可以很大的壓縮 header ，減少傳送包的數量從而降低延遲。

• 伺服器推送

在 HTTP/2 中，伺服器可以對客戶端的一個請求傳送多個響應，即伺服器可以額外的向客戶端推送資源，而無需客戶端明確的請求。

9. 請簡述 HTTPS 工作原理

9.1 HTTPS 簡介

參考文章：《深入淺出講解HTTPS工作原理》

HTTPS 並非是應用層的一種新協議。只是 HTTP 通訊介面部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)協議代替而已。

通常，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL 和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP。

在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證照和完整性保護這些功能。也就是說HTTP 加上加密處理和認證以及完整性保護後即是 HTTPS。

HTTPS 協議的主要功能基本都依賴於 TLS/SSL 協議，TLS/SSL 的功能實現主要依賴於三類基本演算法：雜湊函式 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和金鑰協商，對稱加密演算法採用協商的金鑰對資料加密，基於雜湊函式驗證資訊的完整性。

9.2 HTTPS 工作原理

HTTPS 其實是有兩部分組成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一層處理加密資訊的模組。服務端和客戶端的資訊傳輸都會通過 TLS 進行加密，所以傳輸的資料都是加密後的資料。

1. 客戶端發起HTTPS請求

瀏覽器裡面輸入一個HTTPS網址，然後連線到服務端的443埠上。注意這個過程中客戶端會傳送一個密文族給服務端，密文族是瀏覽器所支援的加密演算法的清單。

2. 服務端配置

採用HTTPS協議的伺服器必須要有一套數字證照，可以自己製作，也可以向組織申請。區別就是自己頒發的證照需要客戶端驗證通過才可以繼續訪問，而使用受信任的公司申請的證照則不會彈出提示頁面。

這套證照其實就是一對公鑰和私鑰，可以這麼理解，公鑰就是一把鎖頭，私鑰就是這把鎖的鑰匙，鎖頭可以給別人對某個東西進行加鎖，但是加鎖完畢之後，只有持有這把鎖的鑰匙才可以解鎖看到加鎖的內容。

3. 傳送證照

這個證照其實就是公鑰，只是包含了很多資訊，如證照的頒發機構、過期時間等等。

4. 客戶端解析證照

這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，如頒發機構、過期時間等等，如果發現異常則會彈出一個警告框，提示證照存在問題。如果證照沒有問題，那麼就生成一個隨機值，然後用證照對該隨機值進行加密。

注意一下上面提到的"發現異常"。證照中會包含數字簽名，該數字簽名是加密過的，是用頒發機構的私鑰對本證照的公鑰、名稱及其他資訊做hash雜湊加密而生成的。客戶端瀏覽器會首先找到該證照的根證照頒發機構，如果有，則用該根證照的公鑰解密伺服器下發的證照，如果不能正常解密，則就是"發現異常"，說明該證照是偽造的。

5. 傳送加密資訊

這部分傳送的是用證照加密後的隨機值，目的就是讓服務端得到這個隨機值，然後客戶端和服務端的通訊就可以通過這個隨機值來進行加密和解密了。

6. 服務端解密資訊

服務端用私鑰解密後，得到了客戶端傳過來的隨機值，至此一個非對稱加密的過程結束，看到TLS利用非對稱加密實現了身份認證和金鑰協商。然後把內容通過該值進行對稱加密。

7. 傳輸加密後的資訊

這部分是服務端用隨機值加密後的資訊，可以在客戶端被還原。

8. 客戶端解密資訊

客戶端用之前生成的隨機值解密服務端傳送過來的資訊，於是獲取瞭解密後的內容，至此一個對稱加密的過程結束，看到對稱加密是用於對伺服器待傳送給客戶端的資料進行加密用的。整個過程即使第三方監聽了資料，也束手無策。

10. HTTP 和 HTTPS 的共同點和區別

1. https 協議需要到 ca 申請證照，一般免費證照較少，因而需要一定費用。

2. http 是超文字傳輸協議，資訊是明文傳輸， https 則是具有安全性的ssl加密傳輸協議。

3. http 和 https 使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。

4. http 的連線很簡單，是無狀態的； HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，比 http 協議安全。

11. 什麼是跨域，如何解決跨域

參考文章：《前端常見跨域解決方案（全）》

11.1 什麼是跨域

跨域，指的是瀏覽器不能執行其他網站的指令碼。它是由瀏覽器的同源策略造成的，是瀏覽器對JavaScript施加的安全限制。

• 什麼是同源策略？

同源策略/SOP（Same origin policy）是一種約定，由Netscape公司1995年引入瀏覽器，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，瀏覽器很容易受到 XSS 、 CSFR 等攻擊。所謂同源是指"協議+域名+埠"三者相同，即便兩個不同的域名指向同一個ip地址，也非同源。

• 同源策略限制了以下行為：

1. Cookie、LocalStorage 和 IndexDB 無法讀取
2. DOM 和 JS物件無法獲取
3. Ajax請求傳送不出去

• 常見跨域場景：

所謂的同源是指：域名、協議、埠均為相同。

• http://www.a.cn/index.html 呼叫 http://www.a.cn/server.php 非跨域。

• http://www.a.cn/index.html 呼叫 http://www.b.cn/server.php 跨域，主域不同。

• http://abc.a.cn/index.html 呼叫 http://def.b.cn/server.php 跨域，子域名不同。

• http://www.a.cn:8080/index.html 呼叫 http://www.a.cn/server.php 跨域，埠不同。

• https://www.a.cn/index.html 呼叫 http://www.a.cn/server.php 跨域,協議不同。

• localhost 呼叫 127.0.0.1 跨域。

11.2 解決跨域

1. jsonp 跨域
2. document.domain + iframe 跨域
3. window.name + iframe 跨域
4. location.hash + iframe 跨域
5. postMessage 跨域
6. 跨域資源共享CORS
7. withCredentials 屬性
8. WebSocket 協議跨域
9. node 代理跨域
10. nginx 代理跨域

具體每一種解決方法，可以參考：《前端常見跨域解決方案（全）》

12. HTTP 中與快取相關的頭部有哪些，它們有什麼區別

頭部	優勢和特點	劣勢和問題
Expires	1、HTTP 1.0 產物，可以在HTTP 1.0和1.1中使用，簡單易用。2、以時刻標識失效時間。	1、時間是由伺服器傳送的(UTC)，如果伺服器時間和客戶端時間存在不一致，可能會出現問題。2、存在版本問題，到期之前的修改客戶端是不可知的。
Cache-Control	1、HTTP 1.1 產物，以時間間隔標識失效時間，解決了Expires伺服器和客戶端相對時間的問題。2、比Expires多了很多選項設定。	1、HTTP 1.1才有的內容，不適用於HTTP 1.0 。2、存在版本問題，到期之前的修改客戶端是不可知的。
Last-Modified	1、不存在版本問題，每次請求都會去伺服器進行校驗。伺服器對比最後修改時間如果相同則返回304，不同返回200以及資源內容。	1、只要資源修改，無論內容是否發生實質性的變化，都會將該資源返回客戶端。例如週期性重寫，這種情況下該資源包含的資料實際上一樣的。2、以時刻作為標識，無法識別一秒內進行多次修改的情況。3、某些伺服器不能精確的得到檔案的最後修改時間。
ETag	1、可以更加精確的判斷資源是否被修改，可以識別一秒內多次修改的情況。2、不存在版本問題，每次請求都回去伺服器進行校驗。	1、計算ETag值需要效能損耗。2、分散式伺服器儲存的情況下，計算ETag的演算法如果不一樣，會導致瀏覽器從一臺伺服器上獲得頁面內容後到另外一臺伺服器上進行驗證時發現ETag不匹配的情況。

13. 分別介紹強快取和協商快取

瀏覽器快取主要分為強快取（也稱本地快取）和協商快取（也稱弱快取）。

13.1 強快取

強快取是利用 http 頭中的 Expires 和 Cache-Control 兩個欄位來控制的，用來表示資源的快取時間。

強快取中，普通重新整理會忽略它，但不會清除它，需要強制重新整理。瀏覽器強制重新整理，請求會帶上 Cache-Control:no-cache 和 Pragma:no-cache。

通常，強快取不會向伺服器傳送請求，直接從快取中讀取資源，在chrome控制檯的network選項中可以看到該請求返回200的狀態碼。分為 from disk cache 和 from memory cache。

• from disk cache ：一般非指令碼會存在記憶體當中，如css，html等

• from memory cache ：資源在記憶體當中，一般指令碼、字型、圖片會存在記憶體當

有快取命中和快取未命中狀態:

13.2 協商快取

協商快取就是由伺服器來確定快取資源是否可用，所以客戶端與伺服器端要通過某種標識來進行通訊，從而讓伺服器判斷請求資源是否可以快取訪問。

普通重新整理會啟用弱快取，忽略強快取。只有在位址列或收藏夾輸入網址、通過連結引用資源等情況下，瀏覽器才會啟用強快取，這也是為什麼有時候我們更新一張圖片、一個js檔案，頁面內容依然是舊的，但是直接瀏覽器訪問那個圖片或檔案，看到的內容卻是新的。

這個主要涉及到兩組 header 欄位： Etag 和 If-None-Match、 Last-Modified和 If-Modified-Since。

向伺服器傳送請求，伺服器會根據這個請求的request header的一些引數來判斷是否命中協商快取。

有快取命中和快取未命中狀態:

13.3 流程

瀏覽器第一次發起請求，本地有快取情況： 在瀏覽器第一次發起請求時，本地無快取，向web伺服器傳送請求，伺服器起端響應請求，瀏覽器端快取。過程如下：

在第一次請求時，伺服器會將頁面最後修改時間通過 Last-Modified標識由伺服器傳送給客戶端，客戶端記錄修改時間；伺服器還會生成一個Etag，併傳送給客戶端。

瀏覽器後續再次進行請求時：

14. 請簡單介紹一下 LRU （Least recently used）演算法

參考文章：《LRU演算法》

14.1 原理

LRU（Least recently used，最近最少使用）演算法根據資料的歷史訪問記錄來進行淘汰資料，其核心思想是“如果資料最近被訪問過，那麼將來被訪問的機率也更高”。

這裡有一張比較卡通的圖片：

14.2 實現

最常見的實現是使用一個連結串列儲存快取資料，詳細演算法實現如下：

1. 新資料插入到連結串列頭部；

2. 每當快取命中（即快取資料被訪問），則將資料移到連結串列頭部；

3. 當連結串列滿的時候，將連結串列尾部的資料丟棄。

14.3 分析

• 命中率

當存在熱點資料時，LRU的效率很好，但偶發性的、週期性的批量操作會導致LRU命中率急劇下降，快取汙染情況比較嚴重。

• 複雜度

實現簡單。

• 代價

命中時需要遍歷連結串列，找到命中的資料塊索引，然後需要將資料移到頭部。

結語

本文主要複習了 HTTP/HTTPS 的一些基礎知識，還有 HTTP 的其他版本的知識，對於面試也好，知識沉澱也好，這些也是我們作為開發者必須懂的。

作為一名前端開發者，說實話對 HTTP/HTTPS 瞭解還是太少，可能和平常工作內容有關。

關於我

本文首發在 pingan8787個人部落格，如需轉載請保留個人介紹

Author	王平安
E-mail	pingan8787@qq.com
博 客	www.pingan8787.com
微 信	pingan8787
每日文章推薦	github.com/pingan8787/…
ES小冊	js.pingan8787.com

微信公眾號