一、HTTP

HTTP協(xié)議是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的應(yīng)用層協(xié)議，萬維網(wǎng)都要遵守HTTP協(xié)議。

HTTP/1.0

HTTP/1.0版本實現(xiàn)了HTTP協(xié)議的基本功能，但是1.0版本性能問題比較明顯，因為HTTP協(xié)議是基于TCP協(xié)議的，所以HTTP的性能問題大多數(shù)都來自于TCP協(xié)議，在每次使用HTTP協(xié)議傳輸數(shù)據(jù)之前都要先建立TCP連接，建立TCP連接要進行三次握手，并且TCP的慢啟動機制使新建立的TCP連接的傳輸速率比較慢，當(dāng)HTTP請求量增大時，HTTP協(xié)議的性能問題就出現(xiàn)了。

HTTP/1.1

1. HTTP/1.1版本默認開啟了長連接，客戶端可以復(fù)用之前的TCP連接請求服務(wù)器，減少了建立TCP連接和TCP慢啟動的時間。在HTTP請求比較多，網(wǎng)絡(luò)情況不好時，長連接可能會發(fā)生隊頭阻塞，所以在長連接的基礎(chǔ)上，HTTP/1.1還支持管道化模式，解決了請求隊頭阻塞的情況，但是在接受響應(yīng)時還是可能造成隊頭阻塞。
2. HTTP/1.1頭部信息增加HOST字段，一臺物理服務(wù)器上可以存在多個虛擬主機，并且它們共享一個IP地址，HTTP/1.1的請求頭和響應(yīng)頭都應(yīng)該添加HOST字段。
3. HTTP/1.1添加和100響應(yīng)碼，HTTP協(xié)議請求會先發(fā)送頭部信息，如果服務(wù)器返回100響應(yīng)碼，再將請求體發(fā)送到服務(wù)器，如果返回401響應(yīng)碼，放棄發(fā)送響應(yīng)體，節(jié)約帶寬。
4. HTTP/1.1引入了Chunked transfer-coding機制，發(fā)送方將消息分割成若干個任意大小的數(shù)據(jù)塊，每個數(shù)據(jù)塊在發(fā)送時都會附上塊的長度，最后用一個零長度的塊作為消息結(jié)束的標志。這種方法允許發(fā)送方只緩沖消息的一個片段，避免緩沖整個消息帶來的過載，利用Chunked transfer-coding機制可以實現(xiàn)斷點續(xù)傳。
5. HTTP/1.1更新了緩存的處理機制，添加了AGE頭部表示緩存的有效期。

HTTPS

HTTPS協(xié)議是HTTP協(xié)議的安全版本，在HTTP協(xié)議和TCP協(xié)議之前添加了SSL/TSL協(xié)議，在TCP握手之后進行SSL/TSL握手。

HTTP/2: HTTP/2是基于HTTPS的，HTTP/2相對于HTTP/1.x更專注于性能，相對于HTTP/1.x做了許多性能上的優(yōu)化：二進制傳輸，多路復(fù)用，Heard壓縮，服務(wù)器推送，安全

1. 二進制傳輸

明文傳輸不安全。HTTP/1使用明文傳輸，不安全。那么HTTP/2就用二進制分幀層來解決這個問題，幀是數(shù)據(jù)傳輸?shù)淖钚挝?，以二進制傳輸代替原本的明文傳輸，原本的報文消息被劃分為更小的數(shù)據(jù)幀。

2. 多路復(fù)用

HTTP/2采用了多路復(fù)用技術(shù)，在一個 TCP 連接上，我們可以向?qū)Ψ讲粩喟l(fā)送幀，每幀的stream_id標明這一幀屬于哪個流，然后在對方接收時，根據(jù) stream_id拼接每個流的所有幀組成一整塊數(shù)據(jù)。把 HTTP/1.1 每個請求都當(dāng)作一個流，那么多個請求變成多個流，請求響應(yīng)數(shù)據(jù)分成多個幀，不同流中的幀交錯地發(fā)送給對方，這就是 HTTP/2 中的多路復(fù)用。同時呢，我們知道HTTP/1的body長度是在header帶過來的，那么如果是以HTTP/2 的形式去傳輸肯定會出問題，所以HTTP/2 將body加上了length字段，每一個流都有自己的長度，最后根據(jù)流的頭部長度是否等于各個流的長度來確定是否合包。同時呢，這樣分包合包也解決了線頭阻塞的問題。TCP會保證包的有序性且保證了包不會丟失。

3. Heard壓縮

Header 內(nèi)容多，而且每次請求 Header 不會變化太多，沒有相應(yīng)的壓縮傳輸優(yōu)化方案。HTTP/2在此用hpack算法來壓縮首部長度，其原理就是維護一個靜態(tài)索引表和動態(tài)索引表的索引空間，hpack其原理就是匹配當(dāng)前連接存在的索引空間，若某個鍵值已存在，則用相應(yīng)的索引代替首部條目，比如 “:method: GET” 可以匹配到靜態(tài)索引中的 index 2，傳輸時只需要傳輸一個包含 2 的字節(jié)即可；若索引空間中不存在，則用字符編碼傳輸，字符編碼可以選擇哈夫曼編碼，然后分情況判斷是否需要存入動態(tài)索引表中，以這種形式節(jié)省了很多的空間。

4. 服務(wù)器推送

為了盡可能減少請求數(shù)，需要做合并文件、雪碧圖、資源內(nèi)聯(lián)等優(yōu)化工作，但是這無疑造成了單個請求內(nèi)容變大延遲變高的問題，且內(nèi)嵌的資源不能有效地使用緩存機制。對于這種情況，HTTP/2推出了服務(wù)端推送，瀏覽器發(fā)送一個請求，服務(wù)器主動向瀏覽器推送與這個請求相關(guān)的資源，這樣瀏覽器就不用發(fā)起后續(xù)請求，其主要是針對資源內(nèi)聯(lián)做出的優(yōu)化。 ##QUIC新功能(HTTP/3)： ###1. 0-RTT建連： 通過使用類似 TCP 快速打開的技術(shù)，緩存當(dāng)前會話的上下文，在下次恢復(fù)會話的時候，只需要將之前的緩存?zhèn)鬟f給服務(wù)端驗證通過就可以進行傳輸了。 ###2. 多路復(fù)用： 雖然 HTTP/2 支持了多路復(fù)用，但是 TCP 協(xié)議終究是沒有這個功能的。QUIC 原生就實現(xiàn)了這個功能，并且傳輸?shù)膯蝹€數(shù)據(jù)流可以保證有序交付且不會影響其他的數(shù)據(jù)流，這樣的技術(shù)就解決了之前 TCP 存在的問題 ###3. 加密認證的報文： 報文頭部都是經(jīng)過認證的，報文 Body 都是經(jīng)過加密的 ###4. 向前糾錯機制： 每個數(shù)據(jù)包除了它本身的內(nèi)容之外，還包括了部分其他數(shù)據(jù)包的數(shù)據(jù)，因此少量的丟包可以通過其他包的冗余數(shù)據(jù)直接組裝而無需重傳，這種技術(shù)只能使用在丟失一個包的情況下，如果出現(xiàn)丟失多個包就不能使用糾錯機制了，只能使用重傳的方式了。

HTTP緩存機制

1.強緩存

緩存規(guī)則信息包含在header中，而強緩存的規(guī)則通常由Expires和Cache-Control這兩個字段標明

Expire

Expires表示到期時間，一般在Response的header中標識，當(dāng)?shù)诙握埱髸r間超過此時間，則判定為緩存過期，需重新向服務(wù)器請求數(shù)據(jù)，否則直接返回緩存數(shù)據(jù)。這個字段存在的問題是這個時間是由服務(wù)器返回的時間，如果客戶端和服務(wù)端時間存在誤差，則會造成緩存機制的誤差。

Expires: Thu, 13 Sep 2018 02:08:54 GMT

Cache-Control Cache-Control標明緩存的持續(xù)時間，是一個相對值，比如max-age= 604800，表示緩存有效期可以持續(xù)604800秒即一周，在一周內(nèi)再次請求這條數(shù)據(jù)，直接返回緩存數(shù)據(jù)。Cache-Control常用取值有private、public、no-cache、max-age，no-store

• max-age：即上面提到的表明緩存的持續(xù)時間；
• private：表示客戶端可以緩存數(shù)據(jù)，默認為private；
• public：表示所有內(nèi)容都將被緩存，客戶端和代理服務(wù)器都可緩存；
• no-cache：字段表示客戶端需驗證服務(wù)器響應(yīng)是否有更改(即下面說到的對比緩存)；
• no-store：不允許緩存

Cache-Control: private, max-age=0, no-cache

2.協(xié)商緩存

與強制緩存不同的是，協(xié)商緩存每次進行再請求時，需要先向服務(wù)器查詢該緩存是否可用，如果緩存可用，則返回304狀態(tài)碼，通知客戶端可以使用緩存，否則響應(yīng)整片資源內(nèi)容。協(xié)商緩存有這幾個字段來標識緩存規(guī)則:Last-Modified / If-Modified-Since 、Etag / If-None-Match

Last-Modified / If-Modified-Since

服務(wù)器在響應(yīng)客戶端請求時，頭部通過Last-Modified 告訴客戶端資源的最后修改時間，客戶端再次請求時，頭部字段攜帶If-Modified-Since告訴服務(wù)器，上次返回的資源最后修改時間，讓服務(wù)器進行對比，若當(dāng)前資源最后修改時間大于If-Modified-Since，則說明資源被改動了，響應(yīng)整片資源，返回200狀態(tài)碼，否則返回304狀態(tài)碼，通知客戶端可以使用緩存。

Etag / If-None-Match

etag是服務(wù)器對資源的一種摘要，客戶端請求時，返回響應(yīng)中該字段告訴客戶端緩存數(shù)據(jù)的標識?？蛻舳嗽俅握埱笸ㄟ^If-None-Match與服務(wù)器匹配，匹配成功說明緩存可用，返回304，若服務(wù)端對數(shù)據(jù)發(fā)生更改，則匹配不成功，重新響應(yīng)資源和緩存規(guī)則信息(優(yōu)先級大于Last-Modified / If-Modified-Since)。 ###3.緩存機制總結(jié)

WebSocket

WebSocket本質(zhì)上一種計算機網(wǎng)絡(luò)應(yīng)用層的協(xié)議

WebSocket和HTTP相同點

1. 都是基于TCP的應(yīng)用層協(xié)議。
2. 都使用Request/Response模型進行連接的建立。
3. 在連接的建立過程中對錯誤的處理方式相同，在這個階段WebSocket可能返回和HTTP相同的返回碼。
4. 都可以在網(wǎng)絡(luò)中傳輸數(shù)據(jù)。

WebSocket和HTTP不同點

1. WebSocket使用HTTP來建立連接，但是定義了一系列新的header域，這些域在HTTP中并不會使用。
2. WebSocket的連接不能通過中間人來轉(zhuǎn)發(fā)，它必須是一個直接連接。
3. WebSocket連接建立之后，通信雙方都可以在任何時刻向另一方發(fā)送數(shù)據(jù)。
4. WebSocket連接建立之后，數(shù)據(jù)的傳輸使用幀來傳遞，不再需要Request消息。
5. WebSocket的數(shù)據(jù)幀有序。 ##使用WebSocket，而不是用Socket的原因： 因為整個瀏覽器都不支持直接調(diào)用系統(tǒng)底層的 Socket，基于瀏覽器的 Web 自然無法調(diào)用，只能使用封裝的高級協(xié)議方案 —— WebSocket

最后

如果你看到了這里，覺得文章寫得不錯就給個贊唄！歡迎大家評論討論！如果你覺得那里值得改進的，請給我留言。一定會認真查詢，修正不足，定期免費分享技術(shù)干貨。喜歡的小伙伴可以關(guān)注一下哦。謝謝！