一. 什么是HTTP

HTTP協(xié)議工作在應用層，端口號是80。HTTP協(xié)議被用于網絡中兩臺計算機間的通信，相比于TCP/IP這些底層協(xié)議，HTTP協(xié)議更像是高層標記型語言，瀏覽器根據(jù)從服務器得到的HTTP響應體中分別得到報文頭，響應頭和信息體（HTML正文等），之后將HTML文件解析并呈現(xiàn)在瀏覽器上。同樣，我們在瀏覽器地址欄輸入網址之后，瀏覽器相當于用戶代理幫助我們組織好報文頭，請求頭和信息體（可選），之后通過網絡發(fā)送到服務器，，服務器根據(jù)請求的內容準備數(shù)據(jù)。
HTTP1.0 和 HTTP1.1都是文本標記型的header，而在HTTP2.0中，會修改為二進制的header。

二. HTTP的通信過程

在HTTP1.0中，一個http請求的通信過程分為以下四步：

• 客戶端通過三次握手和服務端建立連接
• 客戶端向服務端發(fā)送一個請求
• 服務端向客戶端發(fā)送一個回應
• 客戶端接收消息，解析呈現(xiàn)，斷開鏈接。

我們可以看出，在這個通信過程中，每有一個請求都要創(chuàng)建一個http連接，請求完成就斷開，有效的通信包這個過程中占比是很小的。現(xiàn)代前端頁面動輒一個頁面幾十個對象要下載，這樣要建立、斷開幾十次連接，顯然效率比較低。
于是HTTP1.1支持了持久連接，即在一個TCP連接中復用多個請求。這樣可以保持連接建立而發(fā)送多個多請求，提高了TCP連接利用的效率。但是即便如此在效率上仍有值得提高的地方，就是這種連接可能是停等式ARQ模型的，也即上一個request的response回來之后，才能發(fā)送下一個request，這樣對于N個請求而言，可能需要N*RTT的時間才能完成所有請求，這樣效率相對也是比較低的。
HTTP1.1的長連接模型，最常提及的也就是Pipeline，即可以一口氣發(fā)送N個request，然后等幾個response陸續(xù)發(fā)回來。也就是所謂的滑窗ARQ模型（話說我通網好像也就記得這點東西了），理想情況下只有一個RTT的開銷……當然這是理想情況。

三. HTTP的報文結構

結構很簡單，就是報文頭+請求頭（header）+payload，每行結尾都是CRLF，即"\r\n"，header和payload之間用一個空行隔開。

1. 報文頭

reuest的：

METHOD URI VERSION
example:
GET /index.html HTTP1.1

response的：

VERSION STATUS_CODE INFORMATION
example:
HTTP1.1 200 OK

2. header

header都是key:value形式的鍵值對，表示某些選項，選項極多……喪心病狂。下面介紹一幾個（我覺得）常用的。

• Host：指定請求資源的主機和端口號。端口號默認80。

• Connection：值為keep-alive和close。keep-alive使客戶端到服務器的連接持續(xù)有效，不需要每次重連，此功能為HTTP/1.1預設功能。

• Accept：瀏覽器可接收的MIME類型。假設為text/html表示接收服務器回發(fā)的數(shù)據(jù)類型為text/html，如果服務器無法返回這種類型，返回406錯誤。

• Cache-control：緩存控制，Public內容可以被任何緩存所緩存，Private內容只能被緩存到私有緩存，non-cache指所有內容都不會被緩存。

• Cookie：將存儲在本地的Cookie值發(fā)送給服務器，實現(xiàn)無狀態(tài)的HTTP協(xié)議的會話跟蹤。

• Content-Length：請求消息正文長度。

• Content-Type：請求消息正文類型。

• User-Agent: 客戶端信息。

• X-Forward-For: 記錄從客戶端到服務端的代理路徑

3. payload

想要啥隨便寫不謝。

四. HTTP的那些方法

PS：什么是冪等：多次重復同一請求，無論多少次效果都是相同的，即為冪等。

五. HTTP的狀態(tài)碼

這個是按首個數(shù)字分類的，1XX是信息，2XX一般是成功，3XX是重定向，4XX是客戶端錯誤，5XX是服務端錯誤。
常用的狀態(tài)碼列一下：

• 100： 繼續(xù)。

• 200：成功。

• 301：內容已經移動。

• 400：請求不能被服務器理解。

• 403：無權訪問該文件。

• 404：不能找到請求文件。

• 500：服務器內部錯誤。

• 501：服務器不支持請求的方法。

• 505：服務器不支持請求的版本。

六. HTTPS

就是在HTTP協(xié)議上套了一層TLS協(xié)議用于加密，現(xiàn)在被認為是有效的安全通信機制。
忽然發(fā)現(xiàn)憋不出啥來了……就先這樣吧。
主要就是有CA認證，非對稱加密的公鑰放在公網上用于握手，然后用非對稱加密傳輸對稱加密的秘鑰，通信過程用對稱加密保證安全性。
對了，他用443端口。

七. HTTP的一些安全問題

其實搞前端的應該才會被經常問這些，常問的就兩個，CSRF和XSS。

1. CSRF

CSRF實際上是利用了服務端對已經登錄用戶的信任，比如說你登錄了知乎，然后知乎有個API叫/postarticle?title=xxxxxx之類的可用來發(fā)文章，然后我就在網頁上插個看不到的<button>標簽，范圍全屏，src屬性掛上<button><a href="zhihu.com/postarticle?title=xxxxxx"></a></button>，這樣你一進去，點個鼠標，它就自動給你發(fā)了一篇文（guang）章(gao)，神奇吧？當然只是舉個栗子……而且好久不寫html了，這個標簽寫法對不對我不知道，小朋友不要隨便模仿。
防范方法：驗證token，在自己的網頁上掛個看不到的token，要post的時候帶上這個token，服務端去驗證它是不是對的，有沒有他，就保證了受到信任的源才能用這個API。

2. XSS

XSS就是注入攻擊，就是用戶利用你的漏洞，你讓他傳文章的地方他給你插個<script>標簽進去，然后你也不過濾，發(fā)布出來還帶著這個腳本發(fā)布了，別人一訪問，就觸發(fā)這段腳本，后來的事情大家都知道了。
防范方法：過濾用戶輸入，永遠不信任用戶輸入。

八. cookie 和 session

• cookie:客戶端緩存。瀏覽器側保存信息，每次請求的時候帶在header里發(fā)給服務器來同步狀態(tài)。
• session:服務端保存用戶的狀態(tài)。一般就是有一個session id，服務端這邊拿著做映射，那用戶端怎么同步呢？當然是在cookies里面放著這個session id辣。

九. HTTP 2.0

作者：騰訊云技術社區(qū)
鏈接：https://www.zhihu.com/question/34074946/answer/157909115
來源：知乎
著作權歸作者所有。商業(yè)轉載請聯(lián)系作者獲得授權，非商業(yè)轉載請注明出處。

一、多路復用的單一長連接

1.單一長連接

在HTTP/2中，客戶端向某個域名的服務器請求頁面的過程中，只會創(chuàng)建一條TCP連接，即使這頁面可能包含上百個資源。 單一的連接應該是HTTP2的主要優(yōu)勢，單一的連接能減少TCP握手帶來的時延 。HTTP2中用一條單一的長連接，避免了創(chuàng)建多個TCP連接帶來的網絡開銷，提高了吞吐量。

2.多路復用

HTTP2雖然只有一條TCP連接，但是在邏輯上分成了很多stream。

HTTP2把要傳輸?shù)男畔⒎指畛梢粋€個二進制幀，首部信息會被封裝到HEADER Frame，相應的request body就放到DATA Frame,一個幀你可以看成路上的一輛車,只要給這些車編號，讓1號車都走1號門出，2號車都走2號門出，就把不同的http請求或者響應區(qū)分開來了。但是，這里要求同一個請求或者響應的幀必須是有有序的，要保證FIFO的，但是不同的請求或者響應幀可以互相穿插。這就是HTTP2的多路復用，是不是充分利用了網絡帶寬，是不是提高了并發(fā)度？

二、頭部壓縮和二進制格式

http1.x一直都是plain text,對此我只能想到一個優(yōu)點，便于閱讀和debug。但是，現(xiàn)在很多都走https，SSL也把plain text變成了二進制，那這個優(yōu)點也沒了。

于是HTTP2搞了個HPACK壓縮來壓縮頭部，減少報文大小(調試這樣的協(xié)議將需要curl這樣的工具，要進一步地分析網絡數(shù)據(jù)流需要類似Wireshark的http2解析器)。

三、服務端推動Sever Push

這個功能通常被稱作“緩存推送”。主要的思想是：當一個客戶端請求資源X，而服務器知道它很可能也需要資源Z的情況下，服務器可以在客戶端發(fā)送請求前，主動將資源Z推送給客戶端。

這個功能幫助客戶端將Z放進緩存以備將來之需。