国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

【筆記整理】http協議淺析（二）

waltr / 558人閱讀

摘要：作者楊志曉的版本建立在協議之上。網絡上的大多數網站都是基于協議，而可以支持多線程的連接請求，通過這個操作可以減少載入網頁的時間。它可以防止重放攻擊，并確認初始數據交換的完整性。

作者：楊志曉

http的版本：

a.HTTP建立在TCP協議之上。

b.HTTP/0.9 于1991年發布。

c.HTTP/1.0 于1996年發布。

d.HTTP/1.1 于1999年發布。

e.HTTP/2 于2015年發布。

http 1.0 no keep-alive（默認短鏈接）

a.工作原理如圖：
2_1.jpg

b.每次與服務器交互，都需要新開一個連接！

2_2.jpg

c.抓包分析：

demo：4張圖片+html總共5個請求

2_3.jpg

2_4.jpg

每一條tcp鏈接都會直接返回connection close

試想一下：請求一張圖片，新開一個連接，請求一個CSS文件，新開一個連接，請求一個JS文件，新開一個連接。HTTP協議是基于TCP的，TCP每次都要經過三次握手，四次揮手，慢啟動...這都需要去消耗我們非常多的資源的！

http 1.1 默認有 keep-alive

a.相對于持久化連接還有另外比較重要的改動：

HTTP 1.1增加host字段

HTTP 1.1中引入了Chunked transfer-coding，范圍請求，實現斷點續傳(實際上就是利用HTTP消息頭使用分塊傳輸編碼，將實體主體分塊傳輸)

HTTP 1.1管線化(pipelining)理論，客戶端可以同時發出多個HTTP請求，而不用一個個等待響應之后再請求

注意：這個pipelining僅僅是限于理論場景下，大部分桌面瀏覽器仍然會選擇默認關閉HTTP pipelining！

所以現在使用HTTP1.1協議的應用，都是有可能會開多個TCP連接的！

b.工作原理如圖：

只建立一條tcp鏈接，但是每個請求都是串行的，如下圖所示

2_5.jpg

c.對上面同一個demo 在開啟keep-alive后進行抓包分析：(4張圖片+html總共5個請求)

2_6.jpg

5個請求發起一條tcp連接

2_7.jpg

d.圖片增加后抓包如下（開啟keep-alive）：

2_8.jpg

e.通過增加圖片個數抓包后發現，瀏覽器同時建立了6條tcp連接，觀察瀏覽器網絡請求加載圖如下：
2_9.jpg

f.http1.1 支持pipelining（流水線） 條件是：sever端需要支持，同時瀏覽器也要開啟，工作原理如下圖：

2_10.jpg

HTTP Pipelining其實是把多個HTTP請求放到一個TCP連接中一一發送，而在發送過程中不需要等待服務器對前一個請求的響應；只不過，客戶端還是要按照發送請求的順序來接收響應！

g.查詢了 火狐瀏覽器開啟pipelining方法：

在搜索欄輸入 network.http.pipelining ，查詢一下，如果沒有，請右擊鼠標，選擇“新建”——布爾，然后輸入 network.http.pipelining ,賦值true，然后點擊確定。

解釋：激活這個鍵值之后，Pipelining同時發出成倍數的連接請求，從而達到提升連接速度的效果。網絡上的大多數網站都是基于HTTP協議，而HTTP1.1可以支持多線程的連接請求，通過這個操作可以減少Firefox載入網頁的時間。

h.總結：http1.x問題：

在HTTP1.0中，發送一次請求時，需要等待服務端響應了才可以繼續發送請求。

在HTTP1.1中，發送一次請求時，不需要等待服務端響應了就可以發送請求了，但是回送數據給客戶端的時候，客戶端還是需要按照響應的順序來一一接收

所以說，無論是HTTP1.0還是HTTP1.1提出了Pipelining理論，還是會出現阻塞的情況。從專業的名詞上說這種情況，叫做線頭阻塞（Head of line blocking）簡稱：HOLB

http2.0（建立在https基礎上）

a.SSL(Secure Sockets Layer) 安全套接層，是一種安全協議，經歷了 SSL 1.0、2.0、3.0 版本后發展成了標準安全協議 - TLS(Transport Layer Security) 傳輸層安全性協議。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。

TLS 在實現上分為 記錄層 和 握手層 兩層，其中握手層又含四個子協議: 握手協議 (handshake protocol)、更改加密規范協議 (change cipher spec protocol)、應用數據協議 (application data protocol) 和警告協議 (alert protocol)

2_11.jpg

HTTPS = HTTP over TLS.

b.抓包分析：

ClientHello
2_12.jpg

Version: 協議版本（protocol version）指示客戶端支持的最佳協議版本

Random: 一個 32 字節數據，28 字節是隨機生成的 (圖中的 Random Bytes)；剩余的 4 字節包含額外的信息，與客戶端時鐘有關 (圖中使用的是 GMT Unix Time)。在握手時，客戶端和服務器都會提供隨機數，客戶端的暫記作 random_C (用于后續的密鑰的生成)。這種隨機性對每次握手都是獨一無二的，在身份驗證中起著舉足輕重的作用。它可以防止 重放攻擊，并確認初始數據交換的完整性。

Session ID: 在第一次連接時，會話 ID（session ID）字段是空的，這表示客戶端并不希望恢復某個已存在的會話。典型的會話 ID 包含 32 字節隨機生成的數據，一般由服務端生成通過 ServerHello 返回給客戶端。

Cipher Suites: 密碼套件（cipher suite）塊是由客戶端支持的所有密碼套件組成的列表，該列表是按優先級順序排列的

Compression: 客戶端可以提交一個或多個支持壓縮的方法。默認的壓縮方法是 null，代表沒有壓縮

Extensions: 擴展（extension）塊由任意數量的擴展組成。這些擴展會攜帶額外數據

c.繪制流程圖如下：
2_13.jpg

d.HTTP2與HTTP1.1最重要的區別就是解決了線頭阻塞的問題！其中最重要的改動是：多路復用 (Multiplexing)

如圖所示：
2_14.jpg

e.HTTP2所有性能增強的核心在于新的二進制分幀層(不再以文本格式來傳輸了)，它定義了如何封裝http消息并在客戶端與服務器之間傳輸。
2_15.jpg

f.看上去協議的格式和HTTP1.x完全不同了，實際上HTTP2并沒有改變HTTP1.x的語義，只是把原來HTTP1.x的header和body部分用frame重新封裝了一層而已
2_16.jpg

g.問題：被封裝后，不用每次攜帶header，但是header里這個body的長度，這怎么處理呢？

方法：body上加上length解決

Headers Frame: 幀頭
2_17.jpg

h.問題一：body分了許多個strem，怎么確定完結？

抓包分析：
2_18.jpg

2_19.jpg

2_20.png

分了三個包分別為：8192+8192+5281

當前看到的是分包后，最大的包大小是 8192

展示圖如下：
2_21.jpg

i.問題二：怎么確定沒丟包，錯沒錯，秩序亂沒亂，怎么合包

tcp會保證包有序，并且保證了不會丟包

HTTP2所有性能增強的核心在于新的二進制分幀層(不再以文本格式來傳輸了)，它定義了如何封裝http消息并在客戶端與服務器之間傳輸。

j.抓包分析請求：
2_22.jpg

觀察http2的瀏覽器網絡請求加載圖如下：
2_23.jpg

附課堂板書：

2_24.jpg

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/40427.html

相關文章

  • 【筆記整理】http協議淺析（一）

    摘要：作者楊志曉一相關協議類概念和協議屬于傳輸層協議。該協議是一種更加快速的內容傳輸協議。在傳輸層，目前主要使用，但由于本身的問題一個充滿補丁的丑陋的協議，成為了限制應用性能的一個瓶頸。同理，服務端也是將數據拆分為不同幀返回。 作者：楊志曉 一、相關協議類概念： a.TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)...

    Galence 評論0 收藏0

  • 【Nginx源碼研究】Nginx中FastCGI淺析

    摘要：可以通過等方式按照協議通信。上述都需要發送結束包。函數所需的變量在進入該函數之前認為已經初始化完成。和都有自己的，且互不干涉，后續發送的序列號以此為基準。 運營研發團隊 施洪寶 一. FastCGI協議簡介 1.1 簡介 FastCGI(Fast Common Gateway Interface, 快速通用網關接口)是一種通信協議。可以通過Unix Domain Socket, Na...

    Taste 評論0 收藏0

  • Web緩存相關知識整理

    摘要：緩存緩存，也叫網關緩存反向代理緩存。瀏覽器先向網關發起請求，網關服務器后面對應著一臺或多臺負載均衡源服務器，會根據它們的負載請求，動態將請求轉發到合適的源服務器上。雖然這種架構負載均衡源服務器之間的緩存沒法共享，但卻擁有更好的處擴展性。 一、前言? 工作上遇到一個這樣的需求，一個H5頁面在APP端，如果勾選已讀狀態，則下次打開該鏈接，會跳過此頁面。用到了HTML5 的本地存儲 API ...

    rickchen 評論0 收藏0

  • HTTP2和HTTPS來不來了解一下？

    摘要：一端用私鑰加密，另一端用公鑰解密，也確保了來源目前現在好像使用了數字簽名就萬無一失了，其實還有問題。如果公鑰被偽造了，后面的數字簽名其實就毫無意義了。具有校驗機制，一旦被篡改，通信雙方會立刻發現。配備身份證書，防止身份被冒充。 一、前言 只有光頭才能變強 HTTP博文回顧： PC端：HTTP就是這么簡單 PC端：HTTP面試題都在這里 微信公眾號端：HTTP就是這么簡單 微信公眾號端...

    asce1885 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<