HTTP 的特點和缺點特點：無連接、無狀態、靈活、簡單快速

無連接：每一次請求都要連接一次，請求結束就會斷掉，不會保持連接無狀態：每一次請求都是獨立的，請求結束不會記錄連接的任何信息(提起褲子就不認人的意思)，減少了網絡開銷，這是優點也是缺點靈活：通過服務器的程序規模小，因而通信速度很快缺點：無狀態、不安全、明文傳輸、隊頭阻塞

【資料圖】

無狀態：請求不會記錄任何連接信息，沒有記憶，就無法區分多個請求發起者身份是不是同一個客戶端的，意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大不安全：明文傳輸可能被竊聽不安全，缺少身份認證也可能遭遇偽裝，還有缺少報文完整性驗證可能遭到篡改明文傳輸：報文(header部分)使用的是明文，直接將信息暴露給了外界，WIFI陷阱就是復用明文傳輸的特點，誘導你連上熱點，然后瘋狂抓取你的流量，從而拿到你的敏感信息隊頭阻塞：開啟長連接(下面有講)時，只建立一個TCP連接，同一時刻只能處理一個請求，那么當請求耗時過長時，其他請求就只能阻塞狀態(如何解決下面有講)報文：由請求報文和響應報文組成

請求報文：由請求行、請求頭、空行、請求體四部分組成

響應報文：由狀態行、響應頭、空行、響應體四部分組成

請求行：包含

方法

描述

GET

獲取資源

POST

傳輸資源，通常會造成服務器資源的修改

HEAD

獲得報文首部

PUT

更新資源

PATCH

對PUT的補充，對已知資源部分更新 菜鳥

DELETE

刪除資源

OPTIONS

列出請求資源支持的請求方法，用來跨域請求

TRACE

追蹤請求/響應路徑，用于測試或診斷

CONNECT

將連接改為管道方式用于代理服務器(隧道代理下面有講)

GET 和 POST 的區別GET在瀏覽器回退時是無害的，而POST會再次發起請求GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置GET請求參數會被安逗保留在瀏覽器歷史記錄里，而POST中的參數不會被保留GET請求在URL中傳遞的參數有長度限制(瀏覽器限制大小不同)，而POST沒有限制GET參數通過URL傳遞，POST放在Request body中GET產生的URL地址可以被收藏，而POST不可以GET沒有POST安全，因為GET請求參數直接暴露在URL上，所以不能用來傳遞敏感信息GET請求只能進行URL編碼，而POST支持多種編碼方式對參數的數據類型，GET只接受ASCII字符，而POST沒有限制GET產生一個TCP數據包，POST產生兩個數據包(Firefox只發一次)。GET瀏覽器把 : 指示信息——表示請求已接收，繼續處理

2xx: 成功——表示請求已被成功接收

3xx: 重定向——表示要完成請求必須進行進一步操作

4xx: 客戶端錯誤——表示請求有語法錯誤或請求無法實現

5xx: 服務端錯誤——表示服務器未能實現合法的請求

常見狀態碼：

狀態碼

描述

200

請求成功

206

已完成指定范圍的請求(帶Range頭的GET請求),場景如video,audio播放文件較大,文件分片時

301

永久重定向

302

臨時重定向

304

請求資源未修改，可以使用緩存的資源，不用在服務器取

400

請求有語法錯誤

401

沒有權限訪問

403

服務器拒絕執行請求，場景如不允許直接訪問，只能通過服務器訪問時

404

請求資源不存在

500

服務器內部錯誤，無法完成請求

503

請求未完成，因服務器過載、宕機或維護等

什么是持久連接/長連接協議為無連接的協議)

功能避免了建立或者重新建立連接

如圖：短連接極大的降低了傳輸效率

長連接優缺點優點

減少CPU及內存的使用，因為不需要經常建立和關閉連接支持管道化的請求及響應模式減少網絡堵塞，因為減少了TCP請求減少了后續請求的響應時間，因為不需要等待建立TCP、握手、揮手、關閉TCP的過程發生錯誤時，也可在不關閉連接的情況下進行錯誤提示缺點

一個長連接建立后，如果一直保持連接，對服務器來說是多么的浪費資源呀，而且長連接時間的長短，直接影響到服務器的并發數

還有就是可能造成隊頭堵塞(下面有講)，造成信息延遲

如何避免長連接資源浪費？客戶端請求頭聲明：Connection: close，本次通信后就關閉連接服務端配置：如Nginx，設置keepalive_timeout設置長連接超時時間，keepalive_requests設置長連接請求次數上限系統內核參數設置： net.ipv4.tcp_keepalive_time = 60，連接閑置60秒后，服務端嘗試向客戶端發送偵測包，判斷TCP連接狀態，如果沒有收到ack反饋就在 net.ipv4.tcp_keepalive_intvl = 10，就在10秒后再次嘗試發送偵測包，直到收到ack反饋，一共會 net.ipv4.tcp_keepalive_probes = 5，一共會嘗試5次，要是都沒有收到就關閉這個TCP連接了什么是管線化(管道化)在使用長連接的情況下，建立一個連接通道后，連接上消息的傳遞類似于

請求1 – 響應1 – 請求2 – 響應2 – 請求3 – 響應3

管理化連接的消息就變成了類似這樣

請求1 – 請求2 – 請求3 – 響應1 – 響應2 – 響應3

管線化是在同一個TCP連接里發一個請求后不必等其回來就可以繼續發請求出去，這可以減少整體的響應時間，但是服務器還是會按照請求的順序響應請求，所以如果有許多請求，而前面的請求響應很慢，就產生一個著名的問題隊頭堵塞(下面有講解決方法)

管線化的特點：

管線化機制通過持久連接完成，在應答模式，報文必須是一發一收，就形成了一個先進先出的串行隊列，沒有輕重緩急的優先級，只有入隊的先后順序，排在最前面的請求最先處理，就導致如果隊首的請求耗時過長，后面的請求就只能處于阻塞狀態，這就是著名的隊頭阻塞問題。解決如下：

并發連接因為一個域名允許分配多個長連接，就相當于增加了任務隊列，不至于一個隊列里的任務阻塞了其他全部任務。以前在RFC2616中規定過客戶端最多只能并發2個連接，但是現實是很多瀏覽器不按套路出牌，就是遵守這個標準T_T，所以在RFC7230把這個規定取消掉了，現在的瀏覽器標準中一個域名并發連接可以有6~8個，記住是6~8個，不是6個(Chrome6個/Firefox8個)

如果這個還不能滿足你

繼續，不要停…

域名分片一個域名最多可以并發6~8個，那咱就多來幾個域名

比如a.baidu.com，b.baidu.com，c.baidu.com，多準備幾個二級域名，當我們訪問baidu.com時，可以讓不同的資源從不同的二域名中獲取，而它們都指向同一臺服務器，這樣能夠并發更多的長連接了

而在連接中發送多個請求

說一下 HTTP 代理常見的代理有兩種：普通代理(中間人代理)，隧道代理

普通代理(中間人代理)

如圖：代理服務器相當于一個中間人，一直幫兩邊傳遞東西，好可憐~~

不過它可以在中間可以幫我們過濾、緩存、負載均衡(多臺服務器共用一臺代理情況下)等一些處理

注意，實際場景中客戶端和服務器之間可能有多個代理服務器

隧道代理客戶端通過CONNECT方法請求隧道代理創建一個可以到任意目標服務器和端口號的TCP連接，創建成功之后隧道代理只做請求和響應數據的轉發，中間它不會做任何處理

為什么需要隧道代理呢？

我們都知道握手，然后進行加密傳輸

可能有人會問，那還要代理干嘛，直接請求服務器不是更好嗎

代理服務器，到底有什么好處呢？突破訪問限制：如訪問一些單位或集團內部資源，或用國外代理服務器(翻墻)，就可以上國外網站看片等安全性更高：上網者可以通過這種方式隱藏自己的IP，免受攻擊。還可以對數據過濾，對非法IP限流等負載均衡：客戶端請求先到代理服務器，而代理服務器后面有多少源服務器，IP是多少，客戶端是不知道的。因此，代理服務器收到請求后，通過特定的算法(隨機算法、輪詢、一致性hash、LUR(最近最少使用) 算法這里不細說了)把請求分發給不同的源服務器，讓各個源服務器負載盡量均衡緩存代理：將內容緩存到代理服務器(這個下面一節詳細說)代理最常見的請求頭Via

是一個能用首部，由代理服務器添加，適用于正向和反向代理，在請求和響應首部均可出現，這個消息首部可以用來追蹤消息轉發情況，防止循環請求，還可以識別在請求或響應傳遞鏈中消息發送者對于協議的支持能力，詳情請看MDN

Via: 1.1 vegurVia:

記錄客戶端請求的來源IP，每經過一級代理(匿名代理除外)，代理服務器都會把這次請求的來源IP追加進去

X-Forwarded-For: client,proxy1,proxy2復制代碼注意：與服務器直連的代理服務器的IP不會被追加進去，該代理可能過TCP連接的Remote Address字段獲取到與服務器直連的代理服務器IP

X-Real-IP

一般記錄真實發出請求的客戶端的IP，還有X-Forwarded-Host和X-Forwarded-Proto分別記錄真實發出請求的客戶端的域名和協議名

代理中客戶端IP偽造問題以及如何預防？X-Forwarded-For是可以偽造的，比如一些通過X-Forwarded-For獲取到客戶端IP來限制刷票的系統就可以通過偽造該請求頭達到刷票的目的，如果客戶端請求顯示指定了

X-Forwarded-For：192.168.1.108復制代碼那么服務端收到的這個請求頭，第一個IP就是偽造的

預防

在對外Nginx服務器上配置location / { proxy_set_header X-Forwarded-For $remote_addr}復制代碼這樣第一個IP就是從TCP連接客戶端的IP，不會讀取偽造的

從右到左遍歷X-Forwarded-For的IP，排除已知代理服務器IP和內網IP，獲取到第一個符合條件的IP就可以了正向代理和反向代理正向代理工作在客戶端的代理為正向代理。使用正向代理的時候，需要在客戶端配置需要使用的代理服務器，正向代理對服務端透明。比如抓包工具Fiddler、Charles以及訪問一些外網網站的代理工具都是正向代理

正向代理通常用于

緩存屏蔽某些不健康的網站通過代理訪問原本無法訪問的網站上網認證，對用戶訪問進行授權反向代理工作在服務端的代理稱為反向代理。使用反向代理的時候，不需要在客戶端進行設置，反向代理對客戶端透明。如Nginx就是反向代理

反向代理通常用于：負載均衡、服務端緩存、流量隔離、日志、金絲雀發布

代理中的長連接在各個代理和服務器、客戶端節點之間是一段一段的TCP連接，客戶端通過代理訪問目標服務器也叫逐段傳輸，用于逐段傳輸的請求頭叫逐段傳輸頭。

逐段傳輸頭會在每一段傳輸的中間代理中處理掉，不會傳給下一個代理

標準的逐段傳輸頭有：Keep-Alive、Transfer-Encoding、TE、Connection、Trailer、Upgrade、Proxy-Authorization、Proxy-Authenticate。

Connection頭決定當前事務完成后是否關閉連接，如果該值為keep-alive，則連接是持久連接不會關閉，使得對同一服務器的請求可以繼續在該連接上完成

說一下 緩存在上一篇文章里有了詳細介紹 (建議收藏)為什么第二次打開頁面快？五步吃透前端緩存，讓頁面飛起

緩存代理就是讓代理服務器接管一部分的服務端的http緩存，客戶端緩存過期之后就近到代理服務器的緩存中獲取，代理緩存過期了才請求源服務器，這樣流量大的時候能明顯降低源服務器的壓力

注意響應頭字段

Cache-Control： 值有public時，表示可以被所有終端緩存，包括代理服務器、CDN。值有private時，只能被終端瀏覽器緩存，CDN、代理等中繼服務器都不可以緩存。

了

SSL/TLS一張圖讓你理解SSL和TLS的關系

如圖，TLS是SSL的升級版，而且TLS1.2版本以下都已廢棄，目前主要用的是TLS 1.2和TLS 1.3。而OpenSSL則是開源版本的

那么它到底是個啥呢？

瀏覽器和服務器通信之前會先協商，選出它們都支持的加密套件，用來實現安全的通信。常見加密套件

隨便拿出一個加密套件舉例，如：RSA-PSK-AES128-GCM-SHA256，就是長這樣，代表什么意思呢，我們看圖

RSA：表示握手時用RSA算法交換密鑰PSK：表示使用PSK算法簽名AES128-GCM：表示使用AES256對稱加密算法通信，密鑰長度128，分組模式GCM。TLS 1.3中只剩下稱加密算法有AES和CHACHA20，分組模式只剩下GCM和POLY1305SHA256：表示使用SHA256算法驗證信息完整性并生成隨機數。TLS 1.3中哈希摘要算法只剩下SHA256和SHA384了為什么需要用到這么多算法呢？

為了保證安全，TLS需要保證信息的：機密性、可用性、完整性、認證性、不可否認性，每一種算法都有其特定的用處

的證書校驗過程是怎么樣的？證書校驗用到了哪些算法？

對稱加密算法

就是加密和解密使用同一個密鑰。如AES、DES。加解密過程：

瀏覽器給服務器發送一個隨機數client-random和一個支持的加密方法列表服務器給瀏覽器返回另一個隨機數server-random和雙方都支持的加密方法然后兩者用加密方法將兩個隨機數混合生成密鑰，這就是通信雙上加解密的密鑰問題是雙方如何安全的傳遞兩個隨機數和加密方法，直接傳給客戶端，那過程中就很可能被竊取，別人就能成功解密拿到數據，往下看

不對稱加密算法

就是一對密鑰，有公鑰(public key)和私鑰(private key)，其中一個密鑰加密后的數據，只能讓另一個密鑰進行解密。如RSA、ECDHE。加解密過程：

瀏覽器給服務器發送一個隨機數client-random和一個支持的加密方法列表服務器把另一個隨機數server-random、加密方法、公鑰傳給瀏覽器然后瀏覽器用公鑰將兩個隨機數加密，生成密鑰，這個密鑰只能用私鑰解密使用公鑰反推出私鑰是非常困難，但不是做不到，隨著計算機運算能力提高，非對稱密鑰至少要2048位才能保證安全性，這就導致性能上要比對稱加密要差很多

所以！

TLS實際用的是兩種算法的混合加密。通過 非對稱加密算法 交換 對稱加密算法 的密鑰，交換完成后，再使用對稱加密進行加解密傳輸數據。這樣就保證了會話的機密性。過程如下

瀏覽器給服務器發送一個隨機數client-random和一個支持的加密方法列表服務器把另一個隨機數server-random、加密方法、公鑰傳給瀏覽器瀏覽器又生成另一個隨機數pre-random，并用公鑰加密后傳給服務器服務器再用私鑰解密，得到pre-random瀏覽器和服務器都將三個隨機數用加密方法混合生成最終密鑰這樣即便被截持，中間人沒有私鑰就拿不到pre-random，就無法生成最終密鑰。

可又有問題來了，如果一開始就被DNS截持，我們拿到的公鑰是中間人的，而不是服務器的，數據還是會被竊取，所以數字證書來了，往下看，先簡單說一下摘要算法

摘要算法

主要用于保證信息的完整性。常見的MD5算法、散列函數、哈希函數都屬于這類算法，其特點就是單向性、無法反推原文

假如信息被截取，并重新生成了摘要，這時候就判斷不出來是否被篡改了，所以需要給摘要也通過會話密鑰進行加密，這樣就看不到明文信息，保證了安全性，同時也保證了完整性

如何保證數據不被篡改？簽名原理和證書?數字證書(數字簽名)

它可以幫我們驗證服務器身份。因為如果沒有驗證的話，就可能被中間人劫持，假如請求被中間人截獲，中間人把他自己的公鑰給了客戶端，客戶端收到公鑰就把信息發給中間人了，中間人解密拿到數據后，再請求實際服務器，拿到服務器公鑰，再把信息發給服務器

這樣不知不覺間信息就被人竊取了，所以在結合對稱和非對稱加密的基礎上，又添加了數字證書認證的步驟，讓服務器證明自己的身份

數字證書需要向有權威的認證機構(CA)獲取授權給服務器。首先，服務器和CA機構分別有一對密鑰(公鑰和私鑰)，然后是如何生成數字證書的呢？

CA機構通過摘要算法生成服務器公鑰的摘要(哈希摘要)CA機構通過CA私鑰及特定的簽名算法加密摘要，生成簽名把簽名、服務器公鑰等信息打包放入數字證書，并返回給服務器服務器配置好證書，以后客戶端連接服務器，都先把證書發給客戶端驗證并獲取服務器的公鑰。

證書驗證流程：

使用CA公鑰和聲明的簽名算法對CA中的簽名進行解密，得到服務器公鑰的摘要內容再用摘要算法對證書里的服務器公鑰生成摘要，再把這個摘要和上一步得到的摘要對比，如果一致說明證書合法，里面的公鑰也是正確的，否則就是非法的證書認證又分為單向認證和雙向認證

單向認證：服務器發送證書，客戶端驗證證書雙向認證：服務器和客戶端分別提供證書給對方，并互相驗證對方的證書

不過大多數服務器都是單向認證，如果服務器需要驗證客戶端的身份，一般通過用戶名、密碼、手機驗證碼等之類的憑證來驗證。只有更高級別的要求的系統，比如大額網銀轉賬等，就會提供雙向認證的場景，來確保對客戶身份提供認證性

連接

TLS連接是怎么回事呢，根據TLS版本和密鑰交換法不同，過程也不一樣，有三種方式

RSA握手早期的TLS密鑰交換法都是使用RSA算法，它的握手流程是這樣子的

瀏覽器給服務器發送一個隨機數client-random和一個支持的加密方法列表服務器把另一個隨機數server-random、加密方法、公鑰傳給瀏覽器瀏覽器又生成另一個隨機數pre-random，并用公鑰加密后傳給服務器服務器再用私鑰解密，得到pre-random，此時瀏覽器和服務器都得到三個隨機數了，各自將三個隨機數用加密方法混合生成最終密鑰然后開始通信

TLS 1.2 版TLS 1.2版的用的是ECDHE密鑰交換法，看圖

瀏覽器給服務器發送一個隨機數client-random、TLS版本和一個支持的加密方法列表服務器生成一個橢圓曲線參數server-params、隨機數server-random、加密方法、證書等傳給瀏覽器瀏覽器又生成橢圓曲線參數client-params，握手數據摘要等信息傳給服務器服務器再返回摘要給瀏覽器確認應答這個版本不再生成橢圓曲線參數cliend-params和server-params，而是在服務器和瀏覽器兩邊都得到server-params和client-params之后，就用ECDHE算法直接算出pre-random，這就兩邊都有了三個隨機數，然后各自再將三個隨機加密混合生成最終密鑰

TLS 1.3版在TLS1.3版本中廢棄了RSA算法，因為RSA算法可能泄露私鑰導致歷史報文全部被破解，而ECDHE算法每次握手都會生成臨時的密鑰，所以就算私鑰被破解，也只能破解一條報文，而不會對之前的歷史信息產生影響，，所以在TLS 1.3中徹底取代了RSA。目前主流都是用ECDHE算法來做密鑰交換的

TLS1.3版本中握手過程是這樣子的

瀏覽器生成client-params、和client-random、TLS版本和加密方法列表發送給服務器服務器返回server-params、server-random、加密方法、證書、摘要等傳給瀏覽器瀏覽器確認應答，返回握手數據摘要等信息傳給服務器簡單說就是簡化了握手過程，只有三步，把原來的兩個RTT打包成一個發送了，所以減少了傳輸次數。這種握手方式也叫1-RTT握手

這種握手方還有優化空間嗎？

有的，用會話復用

會話復用會話復用有兩種方式：Session ID 和 Session Ticket

Session ID：就是客戶端和服務器首次連接手各自保存會話ID，并存儲會話密鑰，下次再連接時，客戶端發送ID過來，服務器這邊再查找ID，如果找到了就直接復用會話，密鑰也不用重新生成

可是這樣的話，在客戶端數量龐大的時候，對服務器的存儲壓力可就大了

所以出來了第二種方式 Session Ticket：就是雙方連接成功后服務器加密會話信息，用Session Ticket消息發給客戶端存儲起來，下次再連接時就把這個Session Ticket解密，驗證有沒有過期，如果沒有過期就復用會話。原理就是把存儲壓力分給客戶端。

這樣就萬無一失了嗎？

No，這樣也存在安全問題。因為每次要用一個固定的密鑰來解密Session Ticket，一旦密鑰被竊取，那所有歷史記錄也就被破解了，所以只能盡量避免這種問題定期更換密鑰。畢竟節省了不少生成會話密鑰和這些算法的耗時，性能還是提升了嘛

那剛說了1-RTT，那能不能優化到0-RTT呢

還真可以，做法就是發送Session Ticket的時候帶上應用數據，不用等服務端確認。這種方式被稱為PSK(Pre-Shared Key)

這樣萬無一失了嗎？

尷了個尬，還是不行。這PSK要是被竊取，人家不斷向服務器重發，就直接增加了服務器被攻擊的風險

雖然不是絕對安全，但是現行架構下最安全的解決文案了，大大增加了中間人的攻擊成本

優缺點優點

內容加密，中間無法查看原始內容身份認證，保證用戶訪問正確。如訪問百度，即使DNS被劫持到第三方站點，也會提醒用戶沒有訪問百度服務，可能被劫持數據完整性，防止內容被第三方冒充或篡改雖然不是絕對安全，但是現行架構下最安全的解決文案了，大大增加了中間人的攻擊成本缺點

要錢，功能越強大的證書費用越貴證書需要綁定IP，不能在同一個IP上綁定多個域名，而且只支持純文本內容，早已過時就不講了

地址缺點：主要是連接緩慢，服務器只能按順序響應，如果某個請求花了很長時間，就會出現請求隊頭阻塞

雖然出了很多優化技巧：為了增加并發請求，做域名拆分、資源合并、精靈圖、資源預取…等等

最終為了推進從協議上進行優化，Google跳出來，推出SPDY協議

SPDY(2009年)SPDY（讀作“SPeeDY”）是Google開發的基于TCP的會話層協議

主要通過幀、多路復用、請求優先級、HTTP報頭壓縮、服務器推送以最小化網絡延遲，提升網絡速度，優化用戶的網絡使用體驗

原理是在SSL層上增加一個SPDY會話層，以在一個TCP連接中實現并發流。通常的為編碼和傳輸數據設計了一個新的幀格式。因為流是雙向的，所以可以在客戶端和服務端啟動

雖然誕生后很快被所有主流瀏覽器所采用，并且服務器和代理也提供了支持，但是SPDY核心人員后來都參加到的支持

中至少三個新特性？

使用新的二進制協議，不再是純文本，避免文本歧義，縮小了請求體積多路復用，同域名下所有通信都是在單鏈接(雙向數據流)完成，提高連接的復用率，在擁塞控制方面有更好的能力提升使用HPACK算法將頭部壓縮，用哈夫曼編碼建立索表，傳送索引大大節約了帶寬允許服務端主動推送數據給客戶端增加了安全性，使用使用虛擬的流傳輸消息，解決了應用層的隊頭阻塞問題缺點

TCP以及TCP+TLS建立連接的延時，協議層的隊頭阻塞還沒有解決。

TCP在丟包的時候會進行重傳，前面有一個包沒收到，就只能把后面的包放到緩沖區，應用層是無法取數據的，也就是說的丟失恢復機制不管用，因此丟失或重新排序的數據都會導致交互掛掉

為了解決這個問題，Google又發明了QUIC協議

并在2018年11月將QUIC正式改名為

特點：

在傳輸層直接干掉TCP，用UDP替代實現了一套新的擁塞控制算法，徹底解決TCP中隊頭阻塞的問題實現了類似TCP的流量控制、傳輸可靠性的功能。雖然UDP不提供可靠性的傳輸，但QUIC在UDP的基礎之上增加了一層來保證數據可靠性傳輸。它提供了數據包重傳、擁塞控制以及其他一些TCP中存在的特性實現了快速握手功能。由于QUIC是基于UDP的，所以QUIC可以實現使用0-RTT或者1-RTT來建立連接，這意味著QUIC可以用最快的速度來發送和接收數據。集成了TLS加密功能。目前QUIC使用的是TLS1.3結語點贊支持、手留余香、與有榮焉

感謝你能看到這里，加油哦！

標簽：