HTTP協議詳解

HTTP/1.1協議

瀏覽器發起HTTP請求的典型場景

1. 用戶在瀏覽器中輸入相應的網址，在此過程中如果存在歷史訪問的記錄，瀏覽器引擎查詢其內置的數據庫補全相應網址
2. 瀏覽器引擎調用渲染引擎通過網絡模塊發送第一個請求
3. 瀏覽器接收到第一個響應之后，如果其中存在超鏈接，比如一個JavaScript請求，那么瀏覽器會繼續調用網絡請求響應的js文件，並調用JS解釋器解析相應js文件
4. 瀏覽器接收到所有的html、JavaScript、css、其他媒體文件之后，通過UI后端將完整的界面繪制到用戶界面中

瀏覽器發起HTTP請求的典型場景中背后的細節：

1. 服務器監聽80等web端口，瀏覽器從URL中解析出域名
2. 瀏覽器根據域名查詢DNS從而獲取到對於的IP地址
3. 通過查詢到的IP地址與服務器建立TCP鏈接（如果是https協議還需要萬TLS/SSL握手）
4. 構造HTTP請求，在這個過程中填充上下文至HTTP頭部
5. 瀏覽器發送HTTP請求，服務器收到HTTP請求后將HTML頁面作為包體返回給瀏覽器
6. 瀏覽器引擎解析響應，渲染包體至用戶界面，並根據超鏈接構造其他的HTTP請求

HTTP協議的定義

HTTP(超文本傳輸協議)：一種無狀態的、應用層的、以請求/應答方式運行的協議，它使用可擴展的語義和自描述消息格式，與基於網絡的超文本信息系統靈活的互動。

HTTP協議的格式

ABNF（擴充巴科斯-瑙爾范式）

巴科斯范式的英文縮寫為 BNF，它是以美國人巴科斯 (Backus) 和丹麥人諾爾 (Naur) 的名字命名的一種形式化的語法表示方法，用來描述語法的一種形式體系，是一種典型的元語言。又稱巴科斯 - 諾爾形式 (Backus-Naur form)。它不僅能嚴格地表示語法規則，而且所描述的語法是與上下文無關的。它具有語法簡單，表示明確，便於語法分析和編譯的特點。

ABNF操作符

ABNF核心規則

基於ABNF描述的HTTP協議格式

HTTP請求實例：

GET /wp-content/plugins/Pure-Highlightjs_1.0/assets/pure-highlight.css?v.1.0 HTTP/1.1
HOST: www.taohui.pub

HTTP響應實例：

# 響應
HTTP/1.1 200 OK
Server: openresty/1.13.6.2
Date: Sun, 05 May 2019 15:30:31 GMT
Content-Type: text/css
Content-Length: 108
Last-Modified: Thu, 27 Dec 2018 07:35:33 GMT
Connection: keep-alive
ETag: "5c2480c5-6c"
Expires: Sun, 12 May 2019 15:30:31 GMT
Cache-Control: max-age=604800
Accept-Ranges: bytes

pre.pure-highlightjs {
    background-color: transparent;!important;
    border: none;
    padding: 0;
}

OSI七層概念模型

1. 應用層：負責解決業務問題
2. 表示層：負責把網絡中的消息轉換成應用層可以讀取的消息
3. 會話層：負責建立會話、握手、維持連接、關閉
4. 傳輸層：負責解決進程與進程之間的通信，例如TCP保證報文的可達性和流量的控制
5. 網絡層：負責解決廣域網（Internet）中主機之間數據的傳遞
6. 網絡層
7. 數據鏈路層：負責局域網中根據MAC地址連接的相應的交換機/路由器進行報文的轉發
8. 物理層：物理傳輸介質

TCP/IP模型對照

分層模型的優點在於當前層只需要考慮與其相鄰層的對接交互，即每一層只為其之上的層服務，並使用在其之下的層所提供的服務，而不需要考慮其相鄰層之外的其他層做了什么。分層模型的缺點在於不同層之間數據交互需要耗費更多的時間，從而影響網絡性能。

報文頭部

HTTP協議解決了什么問題？

Form Follows Function 形式服務於功能

解決的是人與機器之間高效的信息交互

解決WWW信息交互必須面對的需求

• 低門檻
• 可拓展性
• 分布式系統下的超文本傳輸
• Internet規模
  • 無法控制的可伸縮性
  • 不可預測的負載、非法格式的數據、惡意消息
  • 客戶端不能保存所有服務器信息，服務器不能保持多個請求間的狀態信息
• 獨立的組件部署：新老組件並存
• 向前兼容

評估Web架構的七大關鍵屬性

1. 性能：影響高可用的關鍵因素

2. 可伸縮性：支持部署可以互相交互的大量組件

3. 簡單性：易理解、易實現、易驗證

4. 可見性：對兩個組件間的交互進行監視或者仲裁的能力。如緩存、分層設計等

5. 可移植性：在不同的環境下運行的能力

6. 可靠性：出現部分故障時對整體的影響程度

7. 可修改性：對系統做出修改的難易程度，由可進化型、可定制性、可擴展性、可配置性、可重用性構成

架構屬性：性能

• 網絡性能
  • 吞吐量：小於等於帶寬
  • 開銷：首次開銷，每次開銷
• 用戶感知到的性能
  • 延遲：發起請求到接收到響應的時間
  • 完成時間：完成一個應用動作所花費的時間
• 網絡效率
  • 重用緩存、減少交互次數、數據傳輸距離更近、COD（按需代碼）

架構屬性：可修改性

• 可進化性：一個組件獨立升級而不影響其他組件
• 可擴展性：向系統添加功能時，不會影響到系統的其他部分
• 可定制性：臨時性、定制性地更改某一要素來提供服務，不對常規客戶產生影響
• 可配置性：應用部署后可通過修改配置提供新的功能
• 可重用性：組件可以不做修改在其他應用中使用

REST架構下的Web

五種架構風格

1. 數據流風格 Data-flow Styles
   優點：簡單性、可進化性、可擴展性、可配置性、可重用性
2. 復制風格 Replication Styles
   優點：用戶可察覺的性能、可伸縮性，網絡效率、可靠性也可以得到提升
3. 分層風格 Hierarchical Styles
   優點：簡單性、可進化性、可伸縮性
4. 移動代碼風格 Mobile Code Styles
   優點：可移植性、可擴展性、網絡效率
5. 點對點風格 Peer-to-Peer Styles
   優點：可進化性、可重用性、可擴展性、可配置性

REST架構的推導

統一接口的分層、緩存、無狀態、客戶端服務器模型+按需代碼構成了REST結構

URI的基本格式以及與URL的區別

當沒有URI時：

有了URI：

什么是URI

Uniform Resource Identifier 統一資源標識符

URI的組成

合法的URI

URI的格式

hier-part

相對URI

URI的編碼

為什么要進行URI編碼

保留字符與非保留字符

URI百分號編碼