HTTP協議概述

時間  2020-12-05
標籤 javascript css html java 算法 json 瀏覽器 緩存 安全 服務器 欄目 HTTP/TCP 简体版
原文   原文鏈接

HTTP歷史

起源javascript

蒂姆·伯納斯·李（Tim Berners-Lee）爵士（1955年出生於英國）是萬維網的發明者，互聯網之父。css

1989 年，歐洲核子研究組織（CERN）的蒂姆·博納斯-李（Tim Berners-Lee）博士提出一個構想：藉助多文檔之間相互關聯造成的超文本（HyperText），連成可參閱的 WWW（World Wide Web，萬維網），以幫助遠隔兩地的研究者們共享知識。在這個構想中，他提出了 3 項 WWW 構建的關鍵技術：HTML, URI, HTTP.html

互聯網之父：蒂姆·伯納斯·李（Tim Berners-Lee）、溫頓·瑟夫(Vint Cerf 原名：Vinton Gray "Vint" Cerf ）、羅伯特·卡恩（Robert Elliot Kahn）等。java

v2_3d104486596041fa8f76865e83a1fde6_img_000
@Tim Berners-Lee算法

HTTP 0.9json

1989年 Tim Berners-Lee 蒂姆·伯納斯-李在其論文中確立了：瀏覽器

1. URI：統一資源標識符
2. HTML：超文本標記語言
3. HTTP：超文本傳輸協議

這個版本的 HTTP 只容許 Get 方法。緩存

HTTP 1.0安全

1996年正式發佈服務器

  1. 增長 HEAD、POST 等新方法；
  2. 增長響應狀態碼（status code），標記可能的錯誤緣由；
  3. 引入了協議版本號概念；
  4. 引入了 HTTP Header 的概念，讓 HTTP 處理請求和響應更加靈活；
  5. 傳輸的數據再也不限於文本；

此時的 HTTP/1.0 還只是一份參考文檔，不是正式標準

HTTP 1.1

1999年 HTTP/1.1 發佈 RFC 文檔 2616，後面拆分紅了 RFC7230

  1. 增長了PUT、DELETE、OPTIONS 等新的方法；
  2. 增長了緩存管理和控制；
  3. 明確了鏈接保持（keep-alive），容許持續鏈接；
  4. 容許響應數據分塊（chunked），利於傳輸大文件；
  5. 強制要求 Host 頭，讓互聯網主機託管成爲可能；

HTTP/1.1 優缺點

  1. HTTP 最大的優勢是簡單、靈活和易於擴展；
  2. HTTP 擁有成熟的軟硬件環境，應用的很是普遍，是互聯網的基礎設施；
  3. HTTP 是無狀態的，能夠輕鬆實現集羣化，擴展性能，但有時也須要用 Cookie 技術來實現「有狀態」；
  4. HTTP 是明文傳輸，數據徹底肉眼可見，可以方便地研究分析，但也容易被竊聽；
  5. HTTP 是不安全的，沒法驗證通訊雙方的身份，也不能判斷報文是否被竄改；
  6. HTTP 的性能不算差，但不徹底適應如今的互聯網，還有很大的提高空間。

HTTP 2

2015年 RFC-7540，起初叫作 SPDY 協議

  1. 二進制協議，再也不是純文本；
  2. 可發起多個請求，廢棄了 1.1 裏的管道；
  3. 使用專用算法壓縮頭部，減小數據傳輸量；
  4. 容許服務器主動想客戶端推送數據；
  5. 加強了安全性，事實上要求加密通訊。

HTTP 2.0 經過頭壓縮、分幀、二進制編碼、多路複用等技術提高性能；
面臨的問題：主要市場仍是在1.1的時代，普及率比較低。
使用 TCP 存在的問題：創建鏈接耗時(1.5RTT); 進行TLS鏈接耗時(1-2RTT); TCP的隊頭阻塞並無完全解決(丟包重傳)

HTTP 3

目前還沒正式發佈，是有 Google 發起的心協議，叫作 QUIC 協議，在2018年，互聯網標準化組織 IETF 將 HTTP over QUIC 更名爲 HTTP 3.
QUIC 協議經過基於 UDP 自定義的相似 TCP 的鏈接、重試、多路複用、流量控制技術，進一步提高性能。

從古至今實時數據傳輸（音頻、視頻、遊戲等）都面臨卡頓、延遲等問題，而 QUIC 基於 UDP 的架構和改進的重傳等特性，可以有效的提高用戶體驗。
目前 B站 也已經接入 QUIC。

HTTPS

HTTPS 協議（HyperText Transfer Protocol over Secure Socket Layer）：通常理解爲 HTTP+SSL/TLS，經過 SSL 證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊進行加密。

由網景公司（Netscape）在1994年首次提出，隨後擴展到互聯網上。
在2000年代末至2010年代初，HTTPS開始普遍使用，以確保各種型的網頁真實，保護帳戶和保持用戶通訊，身份和網絡瀏覽的私密性。

那麼SSL又是什麼？

SSL（Secure Socket Layer，安全套接字層）：1994年爲 Netscape 所研發，SSL 協議位於 TCP/IP 協議與各類應用層協議之間，爲數據通信提供安全支持。

TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，它最初的幾個版本（SSL 1.0、SSL 2.0、SSL 3.0）由網景公司開發，1999年從 3.1 開始被 IETF 標準化並更名，發展至今已經有 TLS 1.0、TLS 1.一、TLS 1.2 三個版本。

SSL3.0和TLS1.0因爲存在安全漏洞，已經不多被使用到。TLS 1.3 改動會比較大，目前還在草案階段，目前使用最普遍的是TLS 1.一、TLS 1.2。

SSL發展史（互聯網加密通訊）

  1. 1994年NetSpace公司設計SSL協議（Secure Sockets Layout）1.0版本，但未發佈。
  2. 1995年NetSpace發佈SSL/2.0版本，很快發現有嚴重漏洞
  3. 1996年發佈SSL/3.0版本，獲得大規模應用
  4. 1999年，發佈了SSL升級版TLS/1.0版本，目前應用最普遍的版本
  5. 2006年和2008年，發佈了TLS/1.1版本和TLS/1.2版本

HTTP 是什麼？

在 HTTP/1.1 最新標準 RFC7230 中，是這麼定義 HTTP 的：

The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible integration with network-based hypertext information systems.

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

關鍵詞：無狀態、引用層、請求/應答、可擴展的語義、自描述、超文本

網絡分層究竟是什麼？

OSI 概念模型

OSI（Open System Interconnection Reference Model），開放式系統互聯通訊參考模型，也就是咱們常說的 7 層模型。從它的名稱就能夠看出來，OSI 只是一個供參考的概念模型，它從未被真正的實現。

786279743fc8a92a9f9e19310350f7bd

TCP/IP 模型

OSI 只是一個概念模型，而日常工做咱們最經常使用的仍是 TCP/IP 模型。TCP/IP 模型其實就是 OSI 模型的簡化版本，也就是咱們平時所說的 4 層模型。

ae5f9d5f4d15cb209d3260b8848f80ef
@ TCP/IP 四層模型

其實 TCP/IP 模型與 OSI 模型十分類似，主要是省略了表示層、會話層與物理層的實現。
下面是一張 OSI 模型與 TCP/IP 模型的層級對照圖，你們能夠經過對照圖來總結 TCP/IP 模型中各層的職責。

8b78d97dbadaf2cbf5243b48ebec8332
@ OSI 七層模型與 TCP/IP 四層模型對比圖

Http報文

請求報文

GET / HTTP/1.1
Host: 127.0.0.1:9090
Connection: keep-alive
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

1d50925993cb03cb5388f7a9ad2582e2
@ HTTP 請求報文

響應報文

HTTP/1.1 200 ok
Connection: keep-alive
Content-Length: 164
Content-Type: text/html
Date: Sat, 06 Jun 2020 01:53:57 GMT

<html>
...

9c1043faba50c472f173e376e83be475
@ HTTP 響應報文

HTTP 協議的無狀態與持久鏈接

一般，爲了保存狀態，服務器發送的響應報文中會有一個 Set-Cookie 的首部字段，客戶端獲取到該報文後，就能夠保存 Cookie。下一次請求時，客戶端會將保存的 Cookie 攜帶在請求報文中發送給服務器，服務器拿到 Cookie 後進行比對，就能夠知道是從哪一個客戶端發來的請求了。

37903d2dc04fb6843eb789205d43eac3
@ 攜帶 Cookie 的 HTTP 傳輸過程

常見HTTP頭

HTTP的實體數據-內容協商

「多用途互聯網郵件擴展」（Multipurpose Internet Mail Extensions），簡稱爲 MIME。

Accept <=> Content-Type

Accept 是客戶端可接受的 MIME type，對應的是響應報文裏 Content-Type。

Content-type：

  1. text：文本格式的可讀數據，text/html、text/plain、text/css
  2. image：圖像文件，image/gif、image/jpeg、image/png
  3. audio/video：音頻和視頻數據，audio/mpeg、video/mp4
  4. application：數據格式不固定，必須由上層應用程序來解釋。application/json、application/javascript、application/pdf；application/octet-stream即不透明的二進制數據。

Accept-Encoding <=> Content-Encoding

Accept-Encoding: 該字段標記的是客戶端支持的壓縮格式

Content-Encoding:

  1. gzip：GNU zip 壓縮格式，也是互聯網上最流行的壓縮格式；
  2. deflate：zlib（deflate）壓縮格式，流行程度僅次於 gzip；
  3. br：一種專門爲 HTTP 優化的新壓縮算法（Brotli）。

Accept-Language <=> Content-Language

對應客戶端支持的語言和響應的語言類型：

type-subtype：en-US 美式英語、en-GB 英式英語、zh-CN 漢語

b2118315a977969ddfcc7ab9d26cb358

1. 數據類型表示實體數據的內容是什麼，使用的是 MIME type，相關的頭字段是 Accept 和 Content-Type；
2. 數據編碼表示實體數據的壓縮方式，相關的頭字段是 Accept-Encoding 和 Content-Encoding；
3. 語言類型表示實體數據的天然語言，相關的頭字段是 Accept-Language 和 Content-Language；
4. 字符集表示實體數據的編碼方式，相關的頭字段是 Accept-Charset 和 Content-Type；
5. 客戶端須要在請求頭裏使用 Accept 等頭字段與服務器進行「內容協商」，要求服務器返回最合適的數據；
6. Accept 等頭字段能夠用「,」順序列出多個可能的選項，還能夠用「;q=」參數來精確指定權重。

Range <=> Acceot-Range

bytes & Content-Range: bytes 0-31/96

Transfer-Encoding: chunked 分塊傳輸的編碼規則:

「Transfer-Encoding: chunked」和「Content-Length」這兩個字段是互斥的，也就是說響應報文裏這兩個字段不能同時出現，一個響應報文的傳輸要麼是長度已知，要麼是長度未知（chunked）。

Cookie <=> Set-Cookie

Cookie屬性

HTTP/1.1 200
Set-Cookie: key=value, Max-Age=10; Expires=Fri, 08-Jun-22 08:19:00 GMT; Domain=www.example.com; Path=/; HttpOnly; SameSite=Strict;

Expires和Max-Age都能控制Cookie的有效期，可是瀏覽器會優先採用 Max-Age計算有效期；

HttpOnly => 防範XSS（跨站腳本）攻擊

在 JS 腳本里能夠用 document.cookie 來讀寫 Cookie 數據，這就帶來了安全隱患，有可能會致使「跨站腳本」（XSS）攻擊竊取數據。

屬性 「HttpOnly」 會告訴瀏覽器，此 Cookie 只能經過瀏覽器 HTTP 協議傳輸，禁止其餘方式訪問，瀏覽器的 JS 引擎就會禁用 document.cookie 等一切相關的 API，腳本攻擊也就無從談起了。

SameSite => 防範XSRF（跨站請求僞造）攻擊

  1. SameSite=Strict：嚴格限制 Cookie 不能隨着跳轉連接跨站發送
  2. SameSite=Lax：容許 GET/HEAD 等安全方法，可是禁止POST跨站發送

Cache-Control

緩存控制頭

HTTP/1.1 200
Cache-Control: max-age=30, no-store, no-cache, must-revalidate, proxy-revalidate, public
  1. max-age：用於控制HTTP緩存，相對於服務器的響應時間；
  2. public/private：public在代理服務器和中間節點都能緩存，可是private只有在目標客戶端能夠緩存；
  3. no-store：<u>不容許緩存</u>，用於變化很是頻繁的數據，例如秒殺頁面；
  4. no-cache：<u>能夠緩存</u>，但在使用以前要去服務器驗證是否過時，是否有最新的版本；
  5. must-revalidate：若是緩存不過時就能夠繼續使用，但過時了還想使用須要找服務器驗證；
  6. proxy-revalidate：與must-revalidate相似，可是隻有公共資源能夠在代理服務器緩存，僅限public的配置的資源；

條件請求

If-Modified-Since: Mon, 27 Jul 2020 10:53:40 GMT
If-None-Match: W/"5f1eb234-b7e"

條件請求的兩個字段須要配合 ETag 和 Last-modified 才能起效，在第一次請求的時候，服務器返回上面兩個字段；再次請求資源的時候，瀏覽器會帶上這兩個資源，使用 If-modified-since 和 If-none-Match 來驗證資源是否過時。若是服務器返回 304 則讀取瀏覽器的緩存文件。

參考

[1] 極客時間 - 《趣談網絡協議》

[2] 極客時間 - 《透視 HTTP 協議》

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程