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百分號編碼