HTTP協議再分析

http是基於tcp協議的，需要三次握手，http1.1協議，是keep-alive的。

第一部分，請求行

首先要明白get, post, put，delete這個很簡單不重複，舉幾個例子：

在雲計算中，如果我們的伺服器端要提供乙個基於 http 協議的 api，獲取所有雲主機的列表，這就會使用 get 方法得到，返回的可能是乙個 json 字串。字串裡面是乙個列表，列表裡面是一項的雲主機的資訊。

在雲計算裡，如果我們的伺服器端，要提供乙個基於 http 協議的建立雲主機的 api，也會用到 post 方法。這個時候往往需要將「我要建立多大的雲主機？多少 cpu 多少記憶體？多大硬碟？」這些信息放在 json 字串裡面，通過 post 的方法告訴伺服器端。

雲主機已經建立好了，我想對這個雲主機打乙個標籤，說明這個雲主機是生產環境的，另外乙個雲主機是測試環境的。那怎麼修改這個標籤呢？往往就是用 put 方法。

例如，我們要刪除乙個雲主機，就會呼叫 delete 方法。

第二部分，首部字段

首部是 key value，通過冒號分隔。這裡面，往往儲存了一些非常重要的字段。

accept-charset，表示客戶端可以接受的字符集。防止傳過來的是另外的字符集，從而導致出現亂碼。

content-type是指正文的格式。例如，我們進行 post 的請求，如果正文是 json，那麼我們就應該將這個值設定為 json。

cache-control快取，這裡單講下快取

if-modified-since也是乙個關於快取的。

對於這種高併發場景下的系統，在真正的業務邏輯之前，都需要有個接入層，將這些靜態資源的請求攔在最外面。

nginx 這一層，它如何處理 http 協議呢？對於靜態資源，有 vanish 快取層。當快取過期的時候，才會訪問真正的 tomcat 應用集群。

在 http 頭裡面，cache-control是用來控制快取的。當客戶端傳送的請求中包含 max-age 指令時，如果判定快取層中，資源的快取時間數值比指定時間的數值小，那麼客戶端可以接受快取的資源；當指定 max-age 值為 0，那麼快取層通常需要將請求**給應用集群。

http請求的傳送

還是ip層那一套同閘道器，不同閘道器

tcp 頭裡面還有埠號，http 的伺服器正在監聽這個埠號。於是，目標機器自然知道是 http 服務器這個程序想要這個包，於是將包發給 http 伺服器。http 伺服器的程序看到，原來這個請求是要訪問乙個網頁，於是就把這個網頁發給客戶端。

http返回的構建

狀態碼會反應 http 請求的結果。「200」意味著大吉大利；而我們最不想見的，就是「404」，也就是「服務端無法響應這個請求」。還有30？50？

retry-after表示，告訴客戶端應該在多長時間以後再次嘗試一下。「503 錯誤」是說「服務暫時不再和這個值配合使用」。

有content-type，表示返回的是 html，還是 json。

大致響應的傳送和請求傳送一致

http 1.1 在應用層以純文字的形式進行通訊。每次通訊都要帶完整的 http 的頭，而且不考慮 pipeline 模式的話，每次的過程總是像上面描述的那樣一去一回。這樣在實時性、併發性上都存在問題。

為了解決這些問題，http 2.0 會對 http 的頭進行一定的壓縮，將原來每次都要攜帶的大量 key value 在兩端建立乙個索引表，對相同的頭只傳送索引表中的索引。

更重要的是http2.0將乙個tcp連線切成多個stream(流)，每個strea都有自己的id；並且將傳輸資訊也分割成訊息和幀。

http 2.0 成功解決了 http 1.1 的隊首阻塞問題，同時，也不需要通過 http 1.x 的 pipeline 機制用多條 tcp 連線來實現並行請求與響應；減少了 tcp 連線數對伺服器效能的影響，同時將頁面的多個資料 css、js、 jpg 等通過乙個資料鏈結進行傳輸，能夠加快頁面元件的傳輸速度。

quic協議

有空再看吧，看起來不簡單。

HTTP協議再分析

http協議分析

分析HTTP協議

HTTP協議分析

HTTP協議再分析

http協議分析

分析HTTP協議

HTTP協議分析

相關推薦