前端基礎篇之HTTP協議

HTTP · 發表 2019-05-15 15:09:43

摘要：《圖解HTTP》一文中這樣描述HTTP在網路中的地位： Web使用一種名為HTTP（HyperText Transfer Protocol，超文字傳輸協議）的協議作為規範，完成從客戶端到伺服器等一系列運作流程。而協議是指規則的約定。可以說，Web是建立在HTTP協議上通訊的。 HTTP...

《圖解HTTP》一文中這樣描述HTTP在網路中的地位：

Web使用一種名為HTTP（HyperText Transfer Protocol，超文字傳輸協議）的協議作為規範，完成從客戶端到伺服器等一系列運作流程。而協議是指規則的約定。可以說，Web是建立在HTTP協議上通訊的。

HTTP最初的目的是為了讓研究者共享知識資訊，所以它的主要作用就是文件傳輸，它是一種用於傳輸文件的協議。

HTTP是不儲存狀態的協議，既無狀態協議，協議本身對於請求或響應之間的通訊狀態不進行儲存，因此連線雙方不能知曉對方當前的身份和狀態。這也是Cookie技術產生的重要原因之一：客戶端的狀態管理。瀏覽器會根據從伺服器端傳送的響應報文內 Set-Cookie 首部欄位資訊自動保持 Cookie。而每次客戶端傳送 HTTP 請求，都會在請求報文中攜帶 Cookie，作為服務端識別客戶端身份狀態的標識。

TCP/IP 協議族

為了更好的瞭解HTTP協議，我們必須先了解一下 TCP/IP 協議族。TCP/IP 協議族是Internet最基本的協議，HTTP協議是它的一個子集。TCP/IP協議族按層次分為以下四層（網路基礎，最好記住）：

應用層

應用層規定了向用戶提供應用服務時通訊的協議，如：

TCP/IP 協議族內預存了各類通用的應用服務協議。比如，FTP（File Transfer Protocol，檔案傳輸協議）和DNS（Domain Name System，域名系統）服務就是其中的兩類以及HTTP協議。

DNS域名系統提供域名（如：www.baidu.com）到IP地址（如：119.75.217.109）之間的解析服務。

傳輸層

傳輸層對接上層應用層，提供處於網路連線中兩臺計算機之間的資料傳輸所使用的協議。

在傳輸層有兩個性質不同的協議：TCP（Transmission Control Protocol，傳輸控制協議）和UDP（User Data Protocol，使用者資料報協議）。

TCP協議是雙全工的，即傳送資料和接收資料是同步進行的，就好像我們打電話一樣，說話的同時也能聽見。TCP協議在建立和斷開連線時有三次握手和四次揮手，因此在傳輸的過程中更穩定可靠但同時就沒UDP那麼高效了。

UDP協議是面向無連線的，也就是說在正式傳遞資料之前不需要先建立連線。UDP 協議不保證有序且不丟失的傳遞到對端，也就是說不夠穩定，但也正因如此，UDP協議比TCP更加高效和輕便。

網路層

網路層規定了資料通過怎樣的傳輸路線到達對方計算機傳送給對方（IP協議等）。

與對方計算機之間通過多臺計算機或網路裝置進行傳輸時，網路層所起的所用就是在眾多的選項內選擇一條傳輸路線。就跟攜程提供的回家路線圖作用一樣。

鏈路層

用來處理連線網路的硬體部分，包括控制作業系統、硬體的裝置驅動、NIC（Network Interface Card，網路介面卡，即網絡卡），及光纖等物理可見部分（還包括聯結器等一切傳輸媒介）。硬體上的範疇均在鏈路層的作用範圍之內。

一般的web應用的通訊傳輸流是這樣的：

傳送端在層與層之間傳輸資料時，每經過一層時會被打上一個該層所屬的首部資訊。反之，接收端在層與層之間傳輸資料時，每經過一層時會把對應的首部資訊去除。

序列連線、持久連線、管道化持久連線、http/2.0多路複用簡介

序列連線： HTTP有無連線的特性，即每次連線只能處理一個請求，收到響應後立即斷開連線。HTTP/1.0 版本（稱為序列連線或短連線、短輪詢）中每次HTTP通訊後都要斷開TCP連線，所以每個新的HTTP請求都需要建立一個新的連線。但在現在網站動則幾十條HTTP請求的情況下，很容易達到瀏覽器請求上限，並且每次請求都建立新的tcp連線（每次都有三次握手四次揮別）極大的增加了通訊開銷。
持久連線： 為解決這個問題，有人提出了持久連線（也叫長連線、長輪詢）。一定時間內，同一域名下的HTTP請求，只要兩端都沒有提出斷開連線，則持久保持TCP連線狀態，其他請求可以複用這個連線通道。HTTP/1.1 實現並默認了所有連線都是持久連線，這樣客戶端發起多個HTTP請求時就減少了TCP握手造成的網路資源和通訊時間的浪費。但是持久連線採用阻塞模式，下次請求必須等到上次響應返回後才能發起，如果上次的請求還沒返回響應內容，下次請求就只能等著（就是常說的線頭阻塞）。
管道化持久連線： 管道化則可以不用等待響應返回而傳送下個請求並按順序返回響應，現代瀏覽器並未預設開啟管道化。（這方面收集到的資料有限不多說了）
HTTP/2.0多路複用： 每個HTTP請求都有一個序列識別符號，這樣瀏覽器可以併發多個請求，伺服器接收到資料後，再根據序列識別符號重新排序成不同的請求報文，而不會導致資料錯亂（細節參照此文）。同樣，服務端也可以併發返回多個響應給瀏覽器，瀏覽器收到後根據序列標識重新排序並歸入各自的請求的響應報文。並且同一個域名下的所有請求都複用同一個TCP連線，極大增加了伺服器處理併發的上限。
WebSocket： WebSocket是HTML5提出的一種客戶端和服務端通訊的雙全工協議，由客戶端發起請求，建立連線之後不僅客戶端可以主動向服務端傳送請求，服務端可以主動向客戶端推送資訊。

看圖區分三種連結：

如圖中(a)：序列連線每次發起請求都必須建立新的tcp連線。

如圖中(b)：持久連線多個http請求可以複用同一個tcp連線，但是下次請求必須在上次響應返回之後進行。

如圖中(c)：管道化持久連線也可以複用同一個tcp連線，並且可以不用等待發出多個http請求，但是響應必須按順序返回。

URI

HTTP協議使用 URI 定位網際網路上的資源。概念：

URI(Universal Resource Identifier：統一資源識別符號)
URL(Universal Resource Locator：統一資源定位符)
URN(Universal Resource Name：統一資源名稱)。

個人理解URI是一個資原始檔的不同表示方法的總稱。比如一個檔案 a.html ，既可以用這個檔案的名字 a.html 來表示，也可以用檔案路徑www.baidu.com/a.html 來表示，甚至可以用 urn:a:1535-3613 這樣的識別符號來表示。他們的關係如下：

HTTP版本

對於HTTP版本更詳細的區別，筆者不才，請參考這篇文章

HTTP/1.0

最早的http只是使用在一些較為簡單的網頁上和網路請求上，所以比較簡單，每次請求都開啟一個新的TCP連結，收到響應之後立即斷開連線。

HTTP/1.1

Range
Host

HTTP/2.0

在 HTTP/2 中，有兩個非常重要的概念，分別是幀（frame）和流（stream）。幀代表傳輸的最小的資料單位，每個幀都有序列標識表明該幀屬於哪個流，流也就是多個幀組成的資料流，每個流表示一個請求。

新的二進位制格式： HTTP/1.x的解析是基於文字的。基於文字協議的解析存在天然缺陷，文字的表現形式有多樣性，要做到全面性考慮的場景必然很多。二進位制則不同，只識別0和1的組合。基於這種考慮HTTP/2.0的協議解析採用二進位制格式，方便且強大。
多路複用： HTTP/2.0支援多路複用，這是HTTP/1.1持久連線的升級版。多路複用，就是在一個 TCP 連線中可以存在多條流，也就是可以傳送多個請求/響應，對應端可以通過幀中的標識知道屬於哪個請求/響應，通過重新排序還原請求/響應。多路複用允許併發的發起多個請求，每個請求及該請求的響應不需要等待其他的請求或響應，避免了線頭阻塞問題。這樣某個請求任務耗時嚴重，不會影響到其它連線的正常執行,極大的提高傳輸效能。
頭部壓縮： HTTP/1.x的請求和響應頭部帶有大量資訊，而且每次請求都要重複傳送，HTTP/2.0使用encoder來減少需要傳輸的頭部大小，通訊雙方各自cache一份頭部 fields表，既避免了重複頭部的傳輸，又減小了需要傳輸的大小。
服務端推送： 服務端推送就是把客戶端所需要的css/js/img資源伴隨著index.html一起傳送到客戶端，省去了客戶端重複請求的步驟（從快取中取）。

HTTP/3.0

HTTP/2.0 使用了多路複用，一般來說同一域名下只需要使用一個 TCP 連線。但當這個連線中出現了丟包的情況，那就會導致整個 TCP 都要開始等待重傳，也就導致了後面的所有資料都被阻塞了。反而對於 HTTP/1.0 來說，可以開啟多個 TCP 連線，出現丟包反倒只會影響其中一個連線，剩餘的 TCP 連線還可以正常傳輸資料。出現這個原因是因為底層TCP協議導致的問題，但是修改TCP協議是不現實的問題，就像 typeof null === 'object' 一樣，修改這個問題會導致出現更多的問題。既然不能修改你，就新起一個協議取代你。Google 基於 UDP 協議推出了一個的 QUIC 協議，並且使用在了 HTTP/3 上。

QUIC 基於 UDP，但是UDP本書存在不穩定性等諸多問題，所以QUIC在UDP的基礎上新增了很多功能，比如多路複用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重傳等等功能。優點諸多，參考這裡：

避免包阻塞： 多個數據在TCP連線上傳輸時，若一個數據包出現問題，TCP需要等待該包重傳後，才能繼續傳輸其它資料包。但在QUIC中，因為其基於UDP協議，UDP資料包在出問題需要重傳時，並不會對其他資料包傳輸產生影響。
快速重啟會話： 普通基於tcp的連線，是基於兩端的ip和埠和協議來建立的。在網路切換場景，例如手機端切換了無線網，使用4G網路，會改變本身的ip，這就導致tcp連線必須重新建立。而QUIC協議使用特有的UUID來標記每一次連線，在網路環境發生變化的時候，只要UUID不變，就能不需要握手，繼續傳輸資料。

HTTP報文

用於HTTP協議互動的資訊被稱為HTTP報文。客戶端的HTTP報文叫請求報文，服務端的HTTP報文叫響應報文。

請求報文 是由請求行（請求方法、協議版本）、請求首部（請求URI、客戶端資訊等）和內容實體（使用者資訊和資源資訊等，可為空）構成。

響應報文 是由狀態行（協議版本、狀態碼）、響應首部（伺服器名稱、資源標識等）和內容實體（服務端返回的資源資訊）構成。

請求方法

GET：get方法一般用於獲取伺服器資源
POST：post方法一般用於傳輸實體主體
PUT：put方法一般用於傳輸檔案
DELETE：delete方法用於刪除檔案
HEAD：head方法用於獲取報文首部，不返回報文主體
OPTIONS：options方法用於詢問請求URI資源支援的方法

概念很簡單很精闢，還不太理解應用場景的自行百度~~

狀態碼

HTTP狀態碼錶示客戶端HTTP請求的返回結果、標識伺服器處理是否正常、表明請求出現的錯誤等。

2XX	成功（這系列表明請求被正常處理了）
200	OK，表示從客戶端發來的請求在伺服器端被正確處理
204	No content，表示請求成功，但響應報文不含實體的主體部分
206	Partial Content，進行範圍請求成功

3XX	重定向（表明瀏覽器要執行特殊處理）
301	moved permanently，永久性重定向，表示資源已被分配了新的 URL
302	found，臨時性重定向，表示資源臨時被分配了新的 URL
303	see other，表示資源存在著另一個 URL，應使用 GET 方法獲取資源（對於301/302/303響應，幾乎所有瀏覽器都會刪除報文主體並自動用GET重新請求）
304	not modified，表示伺服器允許訪問資源，但請求未滿足條件的情況（與重定向無關）
307	temporary redirect，臨時重定向，和302含義類似，但是期望客戶端保持請求方法不變向新的地址發出請求

4XX	客戶端錯誤
400	bad request，請求報文存在語法錯誤
401	unauthorized，表示傳送的請求需要有通過 HTTP 認證的認證資訊
403	forbidden，表示對請求資源的訪問被伺服器拒絕，可在實體主體部分返回原因描述
404	not found，表示在伺服器上沒有找到請求的資源

5XX	伺服器錯誤
500	internal sever error，表示伺服器端在執行請求時發生了錯誤
501	Not Implemented，表示伺服器不支援當前請求所需要的某個功能
503	service unavailable，表明伺服器暫時處於超負載或正在停機維護，無法處理請求

首部欄位

下面是請求首部和響應首部中的欄位名稱和作用：

通用首部	作用（請求報文和響應報文都可能使用）
Cache-Control	控制快取的行為： `no-cache` （強制向伺服器再次驗證）、 `no-store` （不做任何快取）、 `max-age=111111` （資源可快取最大時間秒）、 `public` （客戶端、代理伺服器都可利用快取）、 `private` （代理伺服器不可用快取）
Connection	瀏覽器想要優先使用的連線型別： `keep-alive close` （開啟和關閉持久連線）
Date	建立報文時間
Pragma	只用於請求報文，客戶端要求中間伺服器不返回快取的資源
Via	代理伺服器相關資訊，每經過一個代理伺服器就會新增相關資訊，用逗號分割
Transfer-Encoding	傳輸編碼方式： `chunked` 分塊傳輸
Upgrade	要求客戶端使用的升級協議，需配合 `Connection: Upgrade` 一起使用： `websocket`
Warning	快取相關問題的警告

請求首部	作用（請求報文專用）
Accept	能正確接收的媒體型別： `application/json` `text/plain`
Accept-Charset	能正確接收的字符集: `unicode-1-1`
Accept-Encoding	能正確接收的編碼格式列表： `gzip deflate`
Accept-Language	能正確接收的語言列表： `zh-cn,zh;1=0.9,en,1=0.8`
Authorization	客戶端認證資訊： `Bearer dSdSdFFlsfdjasd123` ，一般存token用
Cookie	傳送給伺服器的Cookie資訊
Expect	期待服務端的指定行為
From	請求方郵箱地址
Host	伺服器的域名，用於區分單臺伺服器多個域名的虛擬主機，是HTTP/1.1唯一必須包含的欄位。
If-Match	兩端資源標記比較，只有判斷條件為真服務端才會接受請求： `If-Mach: "123456` ，和服務端檔案標記比較
If-Modified-Since	本地資源未修改返回 304（比較時間）
If-None-Match	本地資源未修改返回 304（比較標記）
User-Agent	客戶端資訊
Max-Forwards	限制可被代理及閘道器轉發的次數
Proxy-Authorization	向代理伺服器傳送驗證資訊
Range	請求某個內容的一部分，配合 `If-Range` 使用
Referer	請求發起頁面的原始URI
TE	傳輸編碼方式

響應首部	作用（響應報文專用）
Accept-Ranges	告知客戶端伺服器是否可接受範圍請求，是 `bytes` ，否 `none`
Age	資源在代理快取中存在的時間
ETag	資源標識，資源發生變化時標識也會發生改變
Location	客戶端重定向到某個 URL
Proxy-Authenticate	向代理伺服器傳送驗證資訊
Server	伺服器名字： `Apache Nginx`
WWW-Authenticate	獲取資源需要的認證方案
Set-Cookie	需要存在客戶端的資訊，一般用於識別使用者身份

實體首部	作用（補充請求報文或響應報文相關資訊）
Allow	資源的正確請求方式： `GET HEAD POST`
Content-Encoding	內容的編碼格式： `gzip deflate`
Content-Language	內容使用的語言： `zh-CN`
Content-Length	request body 長度（即實體主體的大小）：
Content-Location	返回資料的備用地址
Content-MD5	Base64加密格式的內容 MD5檢驗值
Content-Range	響應主體的內容範圍
Content-Type	內容的媒體型別
Expires	內容的過期時間
Last_modified	內容的最後修改時間

首部內容較多，重點記憶瀏覽器常用的一些欄位就行了：

WEB伺服器

這裡不關心伺服器是Apache還是Nginx，而是在於伺服器的作用。一臺伺服器可以作為源伺服器，也可以作為中轉伺服器，甚至可以在一臺伺服器上搭建多個不同域名的網站。

虛擬主機

HTTP/1.1規範允許一臺HTTP伺服器搭建多個Web站點。利用虛擬主機的功能，可以在一臺物理伺服器（一個IP地址）上虛擬出多個主機，每個主機對映一個獨立的域名。因此，當用戶訪問域名 http://www.laogeng.com/ 時，DNS域名系統會將其解析成IP地址，根據IP找到物理伺服器，然後再通過請求首部的HOST欄位（現在知道HOST為什麼是HTTP/1.1強制要求攜帶的了吧）確認對應的虛擬主機。

代理伺服器

代理伺服器就是客戶端和服務端之間的“中間商”，即HTTP請求通過代理伺服器轉發給伺服器，再將伺服器的響應返回給客戶端的行為。代理伺服器可以用來作為快取伺服器，也可以用來隱藏使用者身份（正向代理）或者伺服器身份（反向代理）增加安全性。

所謂正向代理，是從客戶/客戶端角度出發，為了從源伺服器中取得內容，由客戶端向代理伺服器發出請求，並 指定目標訪問伺服器 ，然後，代理伺服器向源伺服器轉交需求，並將獲得的內容返回給客戶端。需要注意的是，在正向代理過程中隱藏了真是請求的客戶端，即服務端不知道正式請求客戶是誰。（科學上網）
所謂反向代理，是從客戶端發向反向代理出請求，反向代理伺服器收到需求後判斷請求走向何處，然後再將結果反饋給客戶端。同樣需要注意的是，在反向代理過程中，隱藏了內部伺服器的資訊，使用者不需要知道是具體哪一臺伺服器提供的服務，只要知道反向代理伺服器是誰就好了，我們甚至可以把反向代理伺服器當做真正伺服器看待。這種形式的代理通常被用作實現負載均衡，比如Nginx就是一種出色的反向代理伺服器。

快取伺服器

快取伺服器指的是將需要頻繁訪問的網路內容存放在離使用者較近、訪問速度更快的伺服器中，以提高內容訪問速度的一種技術。快取伺服器是瀏覽器和源伺服器之間的中間伺服器，瀏覽器先向這個中間伺服器發起HTTP請求，經過處理後（比如許可權驗證，快取匹配等），再將請求轉發到源伺服器。

HTTPS

HTTP本身沒有任何保密性，所以HTTP傳輸的資料相當於都是在網上在以明文的方式裸奔。為了解決這個問題，出現了各種加密技術：

對稱加密：唯一金鑰 key1 可用來加密也可用來解密。這樣的加密需要雙方都擁有金鑰 key1 ，如果第一次傳輸金鑰被第三方截獲就玩完。
非對稱加密：公鑰 key3 和私鑰 key2 都可用於對應的加密和解密，即可用公鑰加密私鑰解密，也可用私鑰加密公鑰解密。服務端會生成一對金鑰，一個私鑰儲存在服務端，僅自己知道，另一個是公鑰，公鑰可以自由釋出供任何人使用。客戶端的明文通過公鑰加密後的密文需要用私鑰解密。非對稱金鑰在加密和解密的過程的使用的金鑰是不同的金鑰，加密和解密是不對稱的，所以稱之為非對稱加密。與對稱金鑰加密相比，非對稱加密無需在客戶端和服務端之間共享金鑰，只要私鑰不發給任何使用者，即使公鑰在網上被截獲，也無法被解密，僅有被竊取的公鑰是沒有任何用處的。
混合加密：服務端先用非對稱加密的私鑰 key2 加密對稱加密的金鑰 key1 並傳給客戶端，客戶端用非對稱加密的公鑰 key3 解密出對稱加密的金鑰 key1 ，雙方都有了金鑰 key1 ，開始利用 key1 加密通訊。缺點：中間人可以自己生成非對稱加密公鑰替換掉服務端公鑰傳送給客戶端，而此時客戶端並無法驗證公鑰的可信性。
SSL：首先需要從證書認證機構申請證書（證書中含有證書籤名和服務端公鑰 key3 ）。在客戶端發起HTTP請求時，服務端將證書傳送給客戶端。客戶端認證證書的真偽，然後解密出服務端公鑰 key3 ，用公鑰加密自己生成的對稱加密金鑰 key1 並傳給服務端，最後利用 key1 加密進行通話。至於安全性，由於私鑰是機構的，可以避免第三方偽造證書。並且就算得到了服務端公鑰，也無法解密出公鑰 key3 加密過的對稱加密金鑰 key1 。

HTTPS基於HTTP協議，通過SSL或TLS（可以看作SSL3.0）提供加密處理資料、驗證對方身份以及資料完整性保護。特點如下：

內容加密：採用混合加密技術，中間者無法直接檢視明文內容
驗證身份：通過證書認證客戶端訪問的是自己的伺服器
保護資料完整性：防止傳輸的內容被中間人冒充或者篡改

HTTPS協議需要到CA申請證書，一般免費證書很少，需要交費。 HTTP協議執行在TCP之上，所有傳輸的內容都是明文，HTTPS執行在SSL/TLS之上，SSL/TLS執行在TCP之上，所有傳輸的內容都經過加密的。 HTTP和HTTPS使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。 HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。 HTTPS協議需要到CA申請證書，一般免費證書很少，需要交費。 HTTP協議執行在TCP之上，所有傳輸的內容都是明文，HTTPS執行在SSL/TLS之上，SSL/TLS執行在TCP之上，所有傳輸的內容都經過加密的。 HTTP和HTTPS使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。 HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。

WEB安全防範

XSS 攻擊

XSS 攻擊全稱跨站指令碼攻擊，是利用html可以執行 <script>alert(1)</script> 的特性，想盡辦法將指令碼注入頁面中的攻擊手段。XSS攻擊有兩種，一種是通過修改瀏覽器URL導致指令碼被注入到頁面，另一種是通過輸入框將指令碼程式碼注入資料庫。前面一種會被chrome瀏覽器自動防禦攻擊（但最好還是手動也防禦一下），後面一種則需要我們手動防禦，推薦使用'xss'庫的白名單過濾防禦方法：

const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
// -> <h1>XSS Demo</h1><script>alert("xss");</script>
複製程式碼

CSRF 攻擊

CSRF中文名為跨站請求偽造。假如掘金有個加關注的GET介面，id引數是關注人Id，如下：

https://juejin.im?id=5cd0438c6fb9a031ec6d3ab2
複製程式碼

那我只需要在我的一個頁面裡面寫一個img標籤：

<img src="https://juejin.im?id=5cd0438c6fb9a031ec6d3ab2" />
複製程式碼

那麼只要有已經登入掘金的使用者開啟我這個頁面，就會自動關注我。就算是改為POST請求，也可以通過在頁面使用form表單提交的方式自動關注。 CSRF攻擊是源於Web的隱式身份驗證機制！Web的身份驗證機制雖然可以保證一個請求是來自於某個使用者的瀏覽器，但卻無法保證該請求是使用者批准傳送的。CSRF攻擊的問題一般是由服務端解決，防範 CSRF 攻擊可以遵循以下幾種規則：

HTTP Only

點選劫持

點選劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 嵌入自己的網頁中，並將 iframe 設定為透明，然後誘使使用者在該頁面上進行操作，此時使用者將在不知情的情況下點選透明的iframe頁面（偸yck大佬一張圖會不會被抓┭┮﹏┭┮）：

防禦方法：

還是讓後端大佬解決，使用一個HTTP響應頭—— X-Frame-Options 。 X-Frame-Options 可以說是為了解決點選劫持而生的，它有三個可選的值：

DENY：瀏覽器會拒絕當前頁面載入任何frame頁面；
SAMEORIGIN：frame頁面的地址只能為同源域名下的頁面；
ALLOW-FROM origin：允許frame載入的頁面地址；

中間人攻擊

中間人攻擊是攻擊方同時與服務端和客戶端建立起了連線，並讓對方認為連線是安全的，但是實際上整個通訊過程都被攻擊者控制了。攻擊者不僅能獲得雙方的通訊資訊，還能修改通訊資訊。中間人攻擊的本質是客戶端和服務端之間的認證和信任問題。

對稱加密、非對稱加密、混合加密技術都沒有有效防止中間人攻擊，因為中間人可以擷取首次傳輸的金鑰並偷天換日，而客戶端或服務端並無法得知。HTTPS作為防止中間人攻擊的終極手段，引入證書機制解決了客戶端和服務端的信任問題，從而較為有效的防止了中間人攻擊。

小結

以上就是前端需要掌握的HTTP相關知識點，能力所限部分知識點講述可能不甚清晰，還請看官們有不清楚的地方直接批評改正。

前端是一門龐大的學科，雖然對入門門檻要求不高，但是其知識體系之龐大讓人望洋興嘆。小子作為半路出家的前端小白，打算按照大牛的指點（感謝）從頭開始學習前端，每學一個知識點都會作篇總結，加深自己理解並方便他人查閱。