HTTP協議總結

2022 年 4 月 16 日
筆記
TCP/IP

什麼是HTTP

它是一種超文本傳輸協議，用來傳輸超文本

超文本：早期互聯網只有文本被解析成二進位之後進行傳輸，後來互聯網迅速的發展出現了影片、音頻、圖片等等資訊進行傳輸，這種擴大後的語義稱之為超文本。
傳輸：兩台電腦之間進行通訊，超文本會被解析成二進位通過載體：光纖、電纜等等傳輸到另一台電腦。
協議：協議意味著有多個參與者為了達成某個共同的目的而站在了一起，除了要無疑義地溝通交流之外，還必須明確地規定各方的責、權、利」

HTTP是一個用在電腦世界裡的協議，它確立了一種電腦之間交流通訊的規範，以及相關的各種控制和錯誤處理方式。HTTP是構建互聯網的重要基礎技術，它沒有實體，依賴許多其他的技術來實現，但同時許多技術也都依賴於它。

HTTP相關概念

瀏覽器（Web）：用於檢索、查看互聯網上網頁資源的應用程式，本質上是一個HTTP協議中的請求方，使用HTTP協議獲取網路上的各種資源，通常都簡單地稱之為「客戶端」
Web伺服器（Web Service）：包含硬體和軟體兩個含義，硬體可以表現為一台機器。軟體可以表現為提供Web服務的應用程式，用來響應請求返回資訊
CDN（Content Delivery Network）：它可以快取源站的數據，讓用戶找到最近的節點，可以用作網路加速外，還提供負載均衡、安全防護、邊緣計算、跨運營商網路等功能
爬蟲（Crawler）：是一種可以自動訪問Web資源的應用程式
WebService：是一種由W3C定義的應用服務開發規範，使用client-server主從架構，通常使用WSDL定義服務介面，使用HTTP協議傳輸XML或SOAP消息，也就是說，它是一個基於Web（HTTP）的服務架構技術，服務端和客戶端可以採用不同的語言開發，具有跨平台跨語言的優點。
代理（Proxy）：是HTTP協議中請求方和應答方中間的一個環節，既可以轉發客戶端的請求，也可以轉發伺服器的應答
- 正向代理：靠近客戶端，代表客戶端向伺服器發送請求；
- 反向代理：靠近伺服器端，代表伺服器響應客戶端的請求；
DNS（Domain Name System）：也叫域名解析服務，用有意義的名字來作為IP地址的等價替代。

HTTP相關協議

TCP/IP協議：TCP/IP協議實際上是一系列網路通訊協議的統稱，主要包含TCP、IP協議還有一些其他協議

IP協議（InternetProtocol）：主要是解決定址和路由，用IP來定位世界上每一台電腦

TCP協議（Transmission Control Protocol）：它位於IP協議之上，基於IP協議提供可靠的、位元組流形式的通訊，是HTTP協議得以實現的基礎。

HTTPS協議：由HTTP協議+SSL/TLS加密協議組成，使得訪問更加安全了。SSL的全稱是「Secure Socket Layer」，綜合了對稱加密、非對稱加密、摘要演算法、數字簽名、數字證書等技術，相當於在不安全的環境中為HTTP套上一副堅固的盔甲

網路分層模型

TCP/IP協議總共有四層，就像搭積木一樣，每一層需要下層的支撐，同時又支撐著上層。它的層次順序是「從下往上」

數據鏈路層：負責在乙太網、WiFi這樣的底層網路上發送原始數據包，工作在網卡這個層次，使用MAC地址來標記網路上的設備，所以有時候也叫MAC層。
網路層：我們A主機和F主機中間隔了很多其他主機，可能A和F主機就不在同一個子網裡面，也可能在，我們就需要去判斷發送者和接收者是不是在通一個子網，這時候有一個IP協議
傳輸層：在IP地址標記的兩點之間「可靠」地傳輸，是TCP協議工作的層次，包括TCP和UDP
應用層：為應用程式提供服務有各種面向具體應用的協議。例如Telnet、SSH、FTP、SMTP、HTTP等等

MAC層的傳輸單位是幀（frame），IP層的傳輸單位是包（packet），TCP層的傳輸單位是段（segment），HTTP的傳輸單位則是消息或報文（message）。

OIS七層模型：開放式系統互聯通訊參考模型（OpenSystem Interconnection Reference Model）

TCP/IP發明於1970年代，當時除了它還有很多其他的網路協議，整個網路世界比較混亂，國際標準組織（ISO）注意到了這種現象，就想要來個「大一統」。於是設計出了一個新的網路分層模型，想用這個新框架來統一既存的各種網路協議。

相比TCP/IP四層多了物理層、表現層、會話層

物理層：互聯物理鏈路，物理介質。網線，光纖，無線電波等等，以二進位電訊號的形式傳輸數據
會話層：每次斷聯不可能要手動去連接，它實現了斷點續傳、自動收發包的功能，還有自動定址的功能
表現層：翻譯工作，針對不同的系統如Windows、Linux、Mac，提供一種公共語言，進行通訊

兩個分層模型的映射關係

協議工作方式

可以把這個過程想像成發快遞的過程，需要寄一個毛絨玩具，首先需要拿一個包裝袋套一下，然後去到快遞點會加上一個箱子，並且貼上一個快遞面單，貼上之後利用小三輪運到集散中心，然後在集散中心利用大貨車運往目的地

//www.baidu.com 先通過應用層進入傳輸層，在傳輸層封裝一個TCP的頭部埠，這個埠是用來判斷用什麼應用程式來處理。（HTTPS默認埠443），發送給網路層，網路層給頭部增加了一個IP資訊，源主機和目的地址，定址。

然後發送給數據鏈路層，數據鏈路層給頭部增加了源MAC地址。然後發送給物理層，物理層轉化為比特流，發送給百度伺服器。

百度伺服器收到信封自下而上，在物理層收到數據把比特流重組，就能夠到數據鏈路層變成了以太幀的數據，拆封信封根據裡面的源MAC地址傳給網路層，網路層拆開發現有TCP的頭部還含有埠。

網路層看完發送給傳輸層，傳輸層根據的埠號443，交給對應的協議HTTPS，傳輸至應用層，應用層根據請求消息給你一個響應請求，響應請求就是一個百度頁面

域名簡介

HTTP協議是運行在TCP/IP上的，IP協議在MAC層之上，使用IP地址把MAC編號轉換成了四位數字，對數據鏈路層做了一層抽象

IP地址又分為內網外網：

內網：在一個區域網內可以訪問，不能被外界訪問。例如公司內網，出了公司就訪問不了了，內網訪問外網需要經過交換機，路由器之後才連到外網的,內網的類型

A類：10.0.0.0——10.255.255.255

B類：172.16.0.0——172.31.255.255

C類：192.168.0.0——192.168.255.255
外網：在一個廣域網內可以訪問，廣域網並不等同於互聯網，外網就不經路由器或交換機就可以上網的網路。

A類：地址範圍是1.0.0.0 到 127.255.255.255，主要分配給大量主機而區域網網路數量較少的大型網路；

B類：地址範圍是128.0.0.0 到191.255.255.255，一般用於國際性大公司和政府機構；

C類：地址範圍是192.0.0.0 到223.255.255.255，用於一般小公司校園網研究機構等；

D類：地址範圍是224.0.0.0 到 239.255.255.255，用於特殊用途，又稱做廣播地址；

E類：地址範圍是240.0.0.0 到255.255.255.255，暫時保留。

一般網站都是使用域名，再通過域名解析服務解析成IP地址，域名方便記憶，它是一個有層次的結構，用.分割成多個單詞。例如www.baidu.com, www表示萬維網服務，baidu代表百度公司一級域名，com代表網站頂級域名。

域名解析

IP地址必須轉換成MAC地址才能訪問主機一樣，域名也必須要轉換成IP地址，這個過程就是「域名解析」DNS。

根域名伺服器（Root DNS Server）：管理頂級域名伺服器，返回「com」「net」「cn」等頂級域名伺服器的IP地址
頂級域名伺服器（Top-level DNS Server）：管理各自域名下的權威域名伺服器，比如com頂級域名伺服器可以返回apple.com域名伺服器的IP地址
權威域名伺服器（Authoritative DNS Server）：管理自己域名下主機的IP地址，比如apple.com權威域名伺服器可以返回www.apple.com的IP地址。

有了這個系統之後，任何一個域名只需要從上至下查詢，最終就獲得了域名的地址

要訪問「www.apple.com」，就要進行下面的三次查詢：

訪問根域名伺服器，它會告訴你「com」頂級域名伺服器的地址
訪問「com」頂級域名伺服器，它再告訴你「apple.com」域名伺服器的地址
最後訪問「apple.com」域名伺服器，就得到了「www.apple.com」的地址

如果每台機器都去根節點訪問，那麼速度和壓力可想而知，為了解決這個問題，用到了快取服務，在用戶訪問的時候記錄下來，當下次訪問就直接從快取中拿數據了。知名的DNS有Google的「8.8.8.8」，本地也可以配置主機映射，比如訪問github太慢，直接映射到對應的IP地址，可以加快訪問速度

域名還可以用來做負載均衡，一般一個域名對應多個IP地址，在客戶端實現負載均衡。實現重定向，某台伺服器需要短暫維護，把域名對應的ip地址改為其他的。

HTTP組成

請求報文由三大部分組成：起始行、請求頭部、實體

響應報文也類似，唯一的區別是響應行不同

2.1 起始行

包含請求方法、URL、版本號。例如

GET /index.html HTTP/1.1

2.1.1請求方法

GET:獲取資源，可以理解為讀取或者下載數據
HEAD:獲取資源的元資訊
POST:向資源提交數據，相當於寫入或上傳數據
PUT:類似POST
DELETE:刪除資源
CONNECT:建立特殊的連接隧道
OPTIONS:列出可對資源實行的方法
TRACE:追蹤請求-響應的傳輸路徑

2.1.2 URL

用戶定位互聯網上的具體資源，整個完整URL就是：請求協議+主機+埠

請求協議可以為ftp://、//、ssh://
主機就是host
埠默認http為80、https為443、ssh為22

最後效果就是：//www.baidu.com:443

2.1.3 版本號

HTTP 1.0、HTTP 1.1、HTTP 2.0

HTTP 1.0：1996年引入，用戶名和密碼沒有加密、不支援斷點續傳一次傳送全部數據等等，發送短鏈接都需要三次握手四次揮手效率低，確立了大部分現在使用的技術，但它不是正式標準

HTTP 1.1：1999年引入，使用長連接一次建立可以多次發送數據、可以控制快取失效、並且支援斷點續傳。是目前互聯網上使用最廣泛的協議，功能也非常完善

HTTP 2.0：2015年開發的，使用壓縮演算法壓縮、基於HTTPS更加安全、多路復用。但還未普及

2.2 請求頭部

頭部欄位是key-value的形式，key和value之間用「:」分隔，最後用CRLF換行表示欄位結束。

HTTP頭欄位非常靈活，不僅可以使用標準里的Host、Connection等已有頭，也可以任意添加自定義頭，這就給HTTP協議帶來了無限的擴展可能,基本上可以分為四大類：

通用欄位：在請求頭和響應頭裡都可以出現
請求欄位：僅能出現在請求頭裡，進一步說明請求資訊或者額外的附加條件
響應欄位：僅能出現在響應頭裡，補充說明響應報文的資訊
實體欄位：它實際上屬於通用欄位，但專門描述body的額外資訊

2.3 實體

實體Body中包含一大坨數據，但是很難判斷具體是什麼類型的數據，只能靠猜前面一些位元組來推導，但也有可能判斷失誤並且效率也不太高。HTTP協議正對這種情況誕生了一個解決方案，方案的名字叫做 多用途互聯網郵件擴展（MultipurposeInternetMailExtensions），簡稱為MIME。

MIME把數據分成了八大類，每個大類下再細分出多個子類，標記的欄位為Accept，以下是常見類型

text：即文本格式的可讀數據，我們最熟悉的應該就是text/html了，表示超文本文檔，此外還有純文本text/plain、樣式表text/css等。
image：即影像文件，有image/gif、image/jpeg、image/png等。
audio/video：音頻和影片數據，例如audio/mpeg、video/mp4等。
application：數據格式不固定，可能是文本也可能是二進位，必須由上層應用程式來解釋。常見的有application/json，application/javascript、application/pdf等，另外，如果實在是不知道數據是什麼類型，像剛才說的「黑盒」，就會是application/octet-stream，即不透明的二進位數據。

還需要有一個Encodingtype，告訴數據是用的什麼編碼格式，標記的欄位為Accept-Encoding

gzip：GNUzip壓縮格式，也是互聯網上最流行的壓縮格式
deflate：zlib（deflate）壓縮格式，流行程度僅次於gzip
br：一種專門為HTTP優化的新壓縮演算法（Brotli）

通過Accept和Accept-Encoding就可以輕鬆識別出body的類型，也就能夠正確處理數據了。

accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9

accept-encoding: gzip, deflate, br

如果求報文里沒有Accept-Encoding欄位，就表示客戶端不支援壓縮數據；如果響應報文里沒有Content-Encoding欄位，就表示響應數據沒有被壓縮

語言類型與編碼

上面兩個欄位解決了識別和壓縮問題，但是不同國家不同的語言類型，以及有不同的編碼規則。不知道對方使用什麼編碼就會導致接收的時候無法識別有效資訊，因此出現了Unicode和UTF-8，一種統一的編碼規則方案

請求頭傳輸欄位：表示想要的數據語言

Accept-Language:zh-CN,zh,en

Accept-Charset:gbk,utf-8

響應頭傳輸欄位：表示實際使用的欄位

Content-Language:zh-CN

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

內容協商的品質值

在使用accept、Accept-Encoding、Accept-Language等請求頭欄位，可以用q設定優先順序，權重的最大值是1，最小值是0.01，默認值是1，如果值是0就表示拒絕。

accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9

accept-encoding: gzip, deflate, br

accept-language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6

HTTP大文件傳輸

有時候網頁裡面包含太多的數據幾百MB或者幾G幾十G那種圖片影片，這樣的數據需要頻寬太高沒發一次性傳輸過來，只能通過類似水管流水一樣輸出。為了完成這種傳輸，HTTP產生了幾種方案

數據壓縮

可以體積變小，對於影片那樣的數據本身就經過壓縮了，作用就不大
分塊傳輸

把一整塊數據分為一小塊分別傳輸，這一頻寬也不會很高
範圍請求

有時候看影片需要跳過部分觀看，其實就是想獲取其中某一段數據，HTTP裡面有一個範圍請求的概念

請求頭裡面有一個欄位,格式是「bytes=x-y」

range:bytes=1512145-1591415

響應頭裡面有個欄位,片段的實際偏移量和資源的總大小，格式是bytesx-y/length

Content-Range: bytes 1512145-1591415/2736753
多段數據

一次請求獲取多個片段

Range:bytes=0-9,20-29

響應報文的數據類型是「multipart/byteranges」，body里的多個部分會用boundary字元串分隔。

HTTP連接效率

HTTP是請求應答模式，每次都會先和伺服器建立連接三次握手，然後收到響應之後會關閉連接四次揮手。這個連接過程很短暫又稱為短連接，相當於重複的開啟關閉步驟這樣非常消耗時間。

針對這個缺點，出現了長連接的方式，就是打開連接之後不會立馬關閉，而是等執行完操作或者等待一定時間才關閉。關於連接的相關欄位是告訴伺服器這是一個長連接

Connetion:Keep-Alive

但是長連接一直不關閉也會消耗伺服器資源，因此可以使用

使用「keepalive_timeout」指令，設置長連接的超時時間，如果在一段時間內連接上沒有任何數據收發就主動斷開連接，避免空閑連接佔用系統資源。
使用「keepalive_requests」指令，設置長連接上可發送的最大請求次數。比如設置成1000，那麼當Nginx在這個連接上處理了1000個請求後，也會主動斷開連接。

HTTP響應碼

伺服器收到請求報文，解析後需要進行處理，最後是拼出一個響應報文發回客戶端。

響應報文由響應頭加響應體數據組成，響應頭又由狀態行和頭欄位構成，狀態碼的意義在於用於表達HTTP數據處理的狀態

1××：提示資訊，表示目前是協議處理的中間狀態，還需要後續的操作；
2××：成功，報文已經收到並被正確處理；
- 200：請求成功，響應頭後有body數據
- 204：請求成功，響應頭後沒有body數據
3××：重定向，資源位置發生變動，需要客戶端重新發送請求；
- 301：永久重定向，說明請求的資源已經不存在了，需改⽤新的 URL 再次訪問
- 302：臨時重定向，資源還在，暫時需要⽤另⼀個 URL 來訪問
- 304:表示資源未修改，定向已存在的緩衝⽂件，也稱快取᯿定向，⽤於緩
  
  存控制
4××：客戶端錯誤，請求報文有誤，伺服器無法處理；
- 400：通用的錯誤碼，表示請求報文有錯誤
- 403：表示伺服器禁止訪問資源
- 404：找不到資源
- 405：不允許使用某些方法操作資源，例如不允許POST只能GET
5××：伺服器錯誤，伺服器在處理請求時內部發生了錯誤
- 500：通用的錯誤碼
- 502：伺服器作為網關或者代理時返回的錯誤碼，
- 503：超時響應

HTTP轉發和重定向

瀏覽網站的時候經常有各種鏈接，我們點擊這個鏈接就會跳轉到另一個頁面，這個行為是我們主動控制觸發，卻是伺服器控制的它去請求這個URL然後返回數據，也叫跳轉（Forward）

但是還有一種不是我們能夠控制的，是伺服器主動控制的，客戶端去請求那個URL，URL地址欄會變，這個叫重定向（Redirect）

直接轉發 Forward 就相當於：「A找B借錢，B說沒有，然後B去找C借，借到借不到都會把消息傳遞給A」；

間接轉發 Redirect 就相當於：”A找B借錢，B說沒有，讓A去找C借”。

forward:一般用於用戶登陸的時候,根據角色轉發到相應的模組 redirect:一般用於用戶註銷登陸時返回主頁面和跳轉到其它的網站等

HTTP快取

瀏覽器使用HTTP獲取資源的成本較高，有必要把來之不易的數據快取起來，快取的流程是

瀏覽器發現快取無數據，於是發送請求，向伺服器獲取資源；
伺服器響應請求，返回資源，同時標記資源的有效期；
瀏覽器快取資源，等待下次重用

Cache-Control:max-age=30

這個max-age表示從創建這個響應報文，整個快取的生存時間

HTTP快取有幾種不同的快取類型

no_store：不允許快取，用於某些變化非常頻繁的數據，例如秒殺頁面；
no_cache：它的字面含義容易與no_store搞混，實際的意思並不是不允許快取，而是可以快取，但在使用之前必須要去伺服器驗證是否過期，是否有最新的版本；
must-revalidate：又是一個和no_cache相似的詞，它的意思是如果快取不過期就可以繼續使用，但過期了如果還想用就必須去伺服器驗證。

Last-modified：就是文件的最後修改時間。

真正使用到快取就是在前進後退的時候，這個時候不會發送新的請求，不再進行網路通訊，這個實現的原理就是

HTTP協議定義了一系列「If」開頭的「條件請求」欄位，專門用來檢查驗證資源是否過期，最常用的是if-Modified-Since和If-None-Match這兩個,有兩種不同條件搭配使用

第一次響應報文提供ETag,第二次請求時就可以發出If-None-Match帶上快取里的原值，驗證資源是否是最新的,資源沒有變就返回一個304，表示快取依然有效
第一次響應報文提供Last-modified,第二次請求時就可以發出If-Modified-Since帶上快取里的原值，驗證資源是否是最新的

ETag是「實體標籤」（EntityTag）的縮寫，是資源的一個唯一標識，主要是用來解決修改時間無法準確區分文件變化的問題，ETag就可以精確地識別資源的變動情況，讓瀏覽器能夠更有效地利用快取。

強ETag要求資源在位元組級別必須完全相符，弱ETag在值前有個「W/」標記，只要求資源在語義上沒有變化，但內部可能會有部分發生了改變

HTTP的Cookie機制

HTTP是無狀態的，意味著每個請求都是獨立的，也無法知道前面的資訊，也無法紀錄資訊，但有的場景交互是需要承前啟後的，兩種用於保持 HTTP 連接狀態的技術就應運而生了，一個是 Cookie，而另一個則是 Session。

Cookie是伺服器用於標記客戶端的，讓伺服器記住不同的客戶端身份，用戶第一次訪問瀏覽器，伺服器不知道它的身份，因此會在頭部放置一個Set-Cookie，裡面可以放置多個值，但大小也是有限制的。

請求頭：

Set-Cookie:tst=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT; domain=.zhihu.com; httponly

響應頭：

Cookie: tst=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT; domain=.zhihu.com; httponly

Cookie其他屬性

Expires：過期時間，可以理解為「截止日期
Max-Age：相對時間，多少秒以後過期。Max-Age優先順序更高，會先採用Max-Age
Domain：Cookie的作用域，讓瀏覽器僅發送給特定的伺服器和URI，避免被其他網站盜用
Path：Cookie所屬的路徑
HttpOnly：保證Cookie的安全性，Cookie只能通過瀏覽器HTTP協議傳輸，禁止其他方式訪問
SameSite：防範「跨站請求偽造」（XSRF）攻擊，可以嚴格限定Cookie不能隨著跳轉鏈接跨站發送
Secure：這個Cookie僅能用HTTPS協議加密傳輸，明文的HTTP協議會禁止發送。但Cookie本身不是加密的，瀏覽器里還是以明文的形式存在

Cookie的作用

有狀態的會話事務和身份識別：可以保持登錄狀態免登錄，還可以作為身份標識
廣告跟蹤：其他網站給你貼小標籤，存儲在它們的Cookie中，也叫第三方Cookie，上其他的網站，別的廣告就能用Cookie讀出你的身份，然後做行為分析，再推給你廣告

HTTP欄位

Host ：指定伺服器域名，例如Host: gitee.com

Content-Length :表明返回body數據的長度，Content-Length: 1000

Connetion :要求伺服器使用持久連接，Connection: keep-alive

Content-Type:用於伺服器響應的時候告訴客戶端是什麼格式的數據，一般是 Content-Type: text/html; charset=utf-8

Content-Encoding:說明欄位的壓縮方式，例如Accept-Encoding: gzip, deflate

User-Agent:是請求欄位，描述發起HTTP請求的客戶端

HTTP代理

HTTP協議中有兩個角色，請求方和應答方，現在還有一個角色就是HTTP代理，代理服務本身不生產內容，而是處於中間位置轉發上下游的請求和響應

代理服務的作用

那麼這個代理的作用是什麼呢？因為代理是中間角色，所以兩邊客戶端和伺服器都不知道對方是具體是誰，又可以分為正向代理和反向代理

正向代理是代理客戶端向伺服器發送消息，例如我們想去訪問國外網站無法直接訪問，需要通過代理伺服器幫我們和目標伺服器進行交互，目標伺服器不知道真正的訪問要訪問的是誰

正向代理的主要作用就是突破訪問限制、隱藏客戶端、提高訪問速度

反向代理是代理伺服器向客戶端發送消息，例如在一線城市租房經常會遇到二房東，所謂二房東就是自己在很多真正的房東那裡把房子承包下來，然後租給租戶，但租戶根本不知道真正的房東是誰。

反向代理可以用來負載均衡、隱藏伺服器、提供安全保障

HTTP中代理需要使用Via欄位表明代理身份，每經過一個代理節點就會在欄位裡面增加一個代理人，但是也不清楚客戶端的資訊。

通常伺服器需要知道客戶端的真實IP地址，最常用的兩個頭欄位是「X-Forwarded-For」和「X-Real-IP」分別表示為誰轉發還有客戶端的IP地址

HTTP快取代理

HTTP代理只是一個中轉的作用，但是對於那種讀多寫少的數據，一秒鐘成千上萬次的請求，如果快取幾秒鐘的的數據就可以降低伺服器的壓力。

在HTTP中，HTTP快取代理很特殊既是伺服器也可以是客戶端，HTTP本身也有快取屬性，為了區分HTTP快取代理使用了新的屬性：private、public

private表示快取只能在客戶端保存，是用戶「私有」的，不能放在代理上與別人共享。而「public」的意思就是快取完全開放，誰都可以存，誰都可以用。

HTTPS相關概念

HTTP整個傳輸過程完全透明，任何人都能夠在鏈路中截獲、修改或者偽造請求/響應報文，數據不具有可信性。這樣對於銀行、購物、個人資訊等等數據都不安全

HTTPS在 HTTP 與 TCP 層之間加⼊了 SSL/TLS 協議，可以很好的解決了上述的⻛險，默認埠號是443，請求-應答模式、報文結構、請求方法、URI、頭欄位、連接管理等等都完全沿用HTTP，但是HTTPS增加了四大安全特性，分別是：

機密性（Secrecy/Confidentiality）：只有可信的人才能訪問
完整性（Integrity）：傳輸過程中沒有被竄改
身份認證（Authentication）：確認對方的真實身份
不可否認（Non-repudiation/Undeniable）：發生的傳輸行為不可抵賴

保障安全的秘密就是這個名字里的「s」，它代表SSL/TLS協議，把HTTP下層的傳輸協議由TCP/IP換成了SSL/TLS

SSL/TLS

SSL即安全套接層（Secure Sockets Layer），在OSI模型中處於第5層（會話層），有v2和v3兩個穩定的版本，在V3時被改名TSL（傳輸層安全，Transport Layer Security），所以TLS1.0實際上就是SSLv3.1。

目前應用的最廣泛的TLS是1.2，TLS由記錄協議、握手協議、警告協議、變更密碼規範協議、擴展協議等幾個子協議組成，綜合使用了對稱加密、非對稱加密、身份認證等許多密碼學前沿技術，瀏覽器在使用TSL建立連接的時候會使用一套合適的加密演算法,會有一串很長的字元：ECDHE-RSA-AES256-GCM-SHA384，基本的形式是：密鑰交換演算法+簽名演算法+對稱加密演算法+摘要演算法。

對稱加密與非對稱加密

對稱加密：加密和解密時使用的密鑰都是同一個，沒有密鑰無法解密，常用的有：AES、ChaCha20，運算速度快

非對稱加密：有一個公鑰和私鑰，公鑰是公開的，私鑰是保密的，公鑰加密後只能用私鑰解密，反過來，私鑰加密後也只能用公鑰解密,有幾種：DH、DSA、RSA、ECC,但速度慢

把對稱加密和非對稱加密結合起來就得到了又好又快的混合加密，也就是HTTPS里使用的加密方式

HTTPS保障通訊安全的原理

1、混合加密

通訊剛開始的時候使用非對稱演算法，比如RSA、ECDHE，首先解決密鑰交換的問題

用隨機數產生對稱演算法使用的會話密鑰，再用公鑰加密

2、摘要演算法

常見摘要演算法有：MD5（Message-Digest5）、SHA-1（SecureHashAlgorithm1），但是不夠安全，推薦使用SHA-2

SHA-2實際上是一系列摘要演算法的統稱，總共有6種，常用的有SHA224、SHA256、SHA384，分別能夠生成28位元組、32位元組、48位元組的摘要

例如：客戶端在發送前通過SHA256加密傳輸內容，把傳輸內容和通過摘要演算法加密後的傳輸內容一起發送，再通過會話密鑰加密成密文發送給伺服器，伺服器解密成明文，然後伺服器也用SHA256算出加密後的傳輸內容和摘要演算法加密後的傳輸內容進行對比，說明數據是完整的

客戶端發送的時候把「摘要 + 明⽂」⼀同加密成密⽂後，發送給伺服器，伺服器解密後，⽤相同的摘要演算法算出發送過來的明文，然後對比

3、數字證書

私鑰可以保證安全性，但是公鑰卻缺少防偽手段，這時候出現了CA（CertificateAuthority，證書認證機構）。它就像網路世界裡的公安局、教育部、公證中心，具有極高的可信度，由它來給各個公鑰簽名，用自身的信譽來保證公鑰無法偽造，是可信的。它包含序列號、用途、頒發者、有效時間等等，把這些打成一個包再簽名，形成數字證書。作為信任鏈的源頭CA有時也會不可信，解決辦法有CRL、OCSP，還有終止信任。

HTTPS協議基本流程及優化

前面說到HTTPS是 HTTP 與 TCP 層之間加⼊了 SSL/TLS 協議，TCP層之間有三次握手四次揮手，加上SSL/TLS 的握⼿涉及四次通訊，總共是11次。

SSL/TLS 協議基本流程：

客戶端向伺服器發起加密通訊請求包括：客戶端⽀持的 SSL/TLS 協議版本、客戶端⽣產的隨機數、客戶端⽀持的密碼套件列表（生成會話密鑰）
伺服器收到客戶端請求後，向客戶端發出響應：確認 SSL/ TLS 協議版本、伺服器⽣產的隨機數、確認的密碼套件列表、伺服器的數字證書
客戶端回應：查看CA 公鑰確認伺服器的數字證書的真實性、取出伺服器的公鑰然後使⽤它加密報⽂、產生第三個隨機數
伺服器的最後回應：查看第三個隨機數通過加密演算法計算會話秘鑰，伺服器握⼿結束通知，表示伺服器的握⼿階段已經結束

HTTPS優化

HTTPS慢的原因是多了SSL/TLS 的握⼿涉及四次通訊，這裡面又包含建立連接時的非對稱加密握手，第二個是握手後的對稱加密報文傳輸、獲取CA證書等等一些網路耗時，主要優化是根據軟體優化：

採用新版本的協議
使用更快的加密解密演算法
使用證書優化
會話復用，一次建立連接多次通訊

HTTP面試題

GET和POST的區別

1.GET是從伺服器請求資源，一般是靜態文本、圖片、影片等等，POST則是提交數據，提交內容放在Body裡面

2.GET是不安全的請求url有長度限制2048byte(2kb)，post對把請求參數放在請求體裡面長度沒有限制

3.GET請求在回退時是無害的，而post請求在回退時會被再重新執行一次

4.GET請求的靜態資源會被快取，而post請求不會被快取

HTTP特性

優點

最大的優點是簡單、靈活和易於擴展；

擁有成熟的軟硬體環境，應用的非常廣泛，是互聯網的基礎設施；

是無狀態的，可以輕鬆實現集群化，擴展性能，

缺點

是明文傳輸，數據完全肉眼可見，能夠方便地研究分析，但也容易被竊聽，不安全

是不安全的，無法驗證通訊雙方的身份，也不能判斷報文是否被竄改；

性能不算差，但不完全適應現在的互聯網，還有很大的提升空間。

為什麼HTTP是無狀態協議

HTTP對用戶的操作沒有記憶力，每個請求都是完全獨立的，每個請求包含了處理這個請求所需的完整的數據，發送請求不涉及到狀態變更，因此我們登錄之後再次就可以免登錄不是HTTP的作用，而是Cookie機制，讓瀏覽器具有記憶力。

Cookie

Cookie實際上是一小段的文本資訊。客戶端請求伺服器，如果伺服器需要記錄該用戶狀態，就向客戶端瀏覽器頒發一個Cookie。客戶端會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給伺服器。伺服器檢查該Cookie，以此來辨認用戶狀態。伺服器還可以根據需要修改Cookie的內容

如果不設置過期時間那麼瀏覽器關閉就會消失，如果設置過期時間那麼關閉瀏覽器直到在設定有效期內都有效

但是服務端無法識別具體是哪個客戶端發來的資訊

Session

Session保存在伺服器上，客戶端請求伺服器後，伺服器都會建立一個session並自動分配一個SessionId，用於標識用戶的唯一身份，當客戶端瀏覽器再次訪問時只需要從該Session中查找該用戶的狀態

有了Cookie和Session就可以識別身份了，比如：有很多人來了我家裡喝茶，但是我都不認識那些人。假如我給來喝茶的人頒發一個序號，那麼當他下次來喝茶我就知道這個人之前來過是老朋友了

作用範圍不同，Cookie 保存在客戶端（瀏覽器），Session 保存在伺服器端。
存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意數據類型，一般情況下我們可以在 Session 中保持一些常用變數資訊，比如說 UserId 等。
有效期不同，Cookie 可設置為長時間保持，比如我們經常使用的默認登錄功能，Session 一般失效時間較短，客戶端關閉或者 Session 超時都會失效。
隱私策略不同，Cookie 存儲在客戶端，比較容易遭到不法獲取，早期有人將用戶的登錄名和密碼存儲在 Cookie 中導致資訊被竊取；Session 存儲在服務端，安全性相對 Cookie 要好一些。
存儲大小不同，單個 Cookie 保存的數據不能超過 4K，Session 可存儲數據遠高於 Cookie。

瀏覽器中禁止了 Cookie怎麼辦？

第一種方案，每次請求中都攜帶一個 SessionID 的參數，也可以 Post 的方式提交，也可以在請求的地址後面拼接 ?SessionID=XXX

第二種方案，Token 機制。Token 機制多用於 App 客戶端和伺服器交互的模式，也可以用於 Web 端做用戶狀態管理。

如何解決跨域請求？Jsonp 跨域的原理是什麼？

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

解決跨域請求的常用方法是：

通過代理來避免，比如使用 Nginx 在後端轉發請求，避免了前端出現跨域的問題。
通過 Jsonp 跨域
其它跨域解決方案：Cron

地址欄輸入URL發生了什麼

首先瀏覽器會根據輸入URL地址，去找本地是否被DNS快取，有的話直接返回IP，假如沒有回查詢本機的host文件是否有配置IP地址
如果也沒有那就直接向網路中發起一個DNS查詢，通過DNS根域名伺服器->頂級域名伺服器->權威DNS伺服器獲取到域名對應的IP
瀏覽器需要和目標地址進行TCP連接，經過三次握手
瀏覽器向伺服器發送請求，伺服器響應請求，然後就會進行四次揮手關閉連接

參考資料：

羅劍鋒.透視HTTP協議.極客時間

小林Coding-圖解網路

Tags: TCP/IP