HTTP 歷史

HTTP（HyperText Transfer Protocal）是超文本傳輸協(xié)議充尉，于蒂姆.博納斯-李在 1989 年 3 月提出的一種能讓遠(yuǎn)隔兩地的研究者們共享知識的設(shè)想
最初設(shè)想的基本理念是：借助多文檔之間相互關(guān)聯(lián)形成的超文本，連成相互關(guān)聯(lián)的 WWW（World Wide Web）萬維網(wǎng)

HTTP 發(fā)展歷史

瀏覽器如何和服務(wù)器交互的

1. 瀏覽器解析

2. 查詢緩存

3. DNS查詢

   順序如下琅捏，若其中一步成功則直接進(jìn)去建立鏈接部分：

   • 瀏覽器自身DNS (chrome: chrome://net-internals/#dns)
   • 操作系統(tǒng)DNS
   • 本地hosts文件
   • 像域名服務(wù)器發(fā)送請求

4. 建立鏈接

• TCP三次握手(three-way handshaking)
• 發(fā)送方:SYN(synchronize)
• 接收方:SYN/ACK(acknowledgement),確認(rèn)信息傳達(dá)
• 發(fā)送方:ACK - 確認(rèn)接收方在線可收消息冤狡，握手結(jié)束
• Accept

• TCP三次握手的的好處在于孙蒙，發(fā)送方可以確認(rèn)接收方仍然在線项棠，不會因為白發(fā)送而浪費資源悲雳。

  
  
  tcp 三次握手.jpg

5. 發(fā)送HTTP請求

• 報文首部(GET /index.html HTTP/1.1)
• 方法
• URL
• HTTP版本
• 空行(CR+LF)
• 報文主體

注意:
1.HTTP是無連接、無狀態(tài)的香追，即HTTP在傳輸完成后就會斷開合瓢，并且下一次登錄時不會記錄上次的登錄狀態(tài)。
2.關(guān)于CR(Carriage Return,回車)和LF(Line Feed,換行)
Dos和Windows采用CR/LF表示下一行
UNIX/Linux采用LF表示下一行
MAC OS系統(tǒng)則采用CR表示下一行

6. 服務(wù)器發(fā)送響應(yīng)

• 報文首部(HTTP/1.1 200 OK)
• HTTP版本
• 響應(yīng)狀態(tài)碼
• 狀態(tài)碼信息
• 空行(CR+LF)
• 報文主體

7. 客戶端收到頁面

8. 解析HTML

• 構(gòu)建DOM樹
• 下載資源
• CSS - 構(gòu)建CSSOM樹
• js - 等下下載并執(zhí)行后解析

9. 構(gòu)建渲染樹
   根據(jù)DOM和CSSOM樹渲染透典，不可見元素不被會渲染

10. 瀏覽器布局渲染

• 布局 - 根據(jù)渲染樹布局
• 繪制 - 在屏幕上繪制每個點

http 1 和 http 1.1 的區(qū)別

HTTP1.0最早在網(wǎng)頁中使用是在1996年晴楔，那個時候只是使用一些較為簡單的網(wǎng)頁上和網(wǎng)絡(luò)請求上，而HTTP1.1則在1999年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請求中峭咒，同時HTTP1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議税弃。 主要區(qū)別主要體現(xiàn)在：

1. 緩存處理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn)凑队，HTTP1.1則引入了更多的緩存控制策略例如Entity tag则果，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
2. 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用漩氨，HTTP1.0中西壮，存在一些浪費帶寬的現(xiàn)象，例如客戶端只是需要某個對象的一部分叫惊，而服務(wù)器卻將整個對象送過來了款青，并且不支持?jǐn)帱c續(xù)傳功能，HTTP1.1則在請求頭引入了range頭域霍狰，它允許只請求資源的某個部分抡草，即返回碼是206（Partial Content）饰及，這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。
3. 錯誤通知的管理康震，在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼旋炒，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除签杈。
4. Host頭處理瘫镇，在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP地址，因此答姥，請求消息中的URL并沒有傳遞主機名（hostname）铣除。但隨著虛擬主機技術(shù)的發(fā)展，在一臺物理服務(wù)器上可以存在多個虛擬主機（Multi-homed Web Servers）鹦付，并且它們共享一個IP地址尚粘。HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）敲长。

5. 長連接郎嫁，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)祈噪，減少了建立和關(guān)閉連接的消耗和延遲泽铛，在HTTP1.1中默認(rèn)開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創(chuàng)建連接的缺點辑鲤。以下是常見的HTTP1.0：

   
   
   HTTP/1.1

HTTP1.0和1.1現(xiàn)存的一些問題

1. 上面提到過的盔腔，HTTP1.x在傳輸數(shù)據(jù)時，每次都需要重新建立連接月褥，無疑增加了大量的延遲時間弛随，特別是在移動端更為突出。
2. HTTP1.x在傳輸數(shù)據(jù)時宁赤，所有傳輸?shù)膬?nèi)容都是明文舀透，客戶端和服務(wù)器端都無法驗證對方的身份，這在一定程度上無法保證數(shù)據(jù)的安全性决左。
3. HTTP1.x在使用時愕够，header里攜帶的內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀径吡⑶颐看握埱骽eader基本不怎么變化链烈，尤其在移動端增加用戶流量。
4. 雖然HTTP1.x支持了keep-alive挚躯，來彌補多次創(chuàng)建連接產(chǎn)生的延遲强衡，但是keep-alive使用多了同樣會給服務(wù)端帶來大量的性能壓力，并且對于單個文件被不斷請求的服務(wù)(例如圖片存放網(wǎng)站)码荔，keep-alive可能會極大的影響性能漩勤，因為它在文件被請求之后還保持了不必要的連接很長時間感挥。

http 常用消息頭

• 通用消息頭

通用消息頭.png

• 請求消息頭

  
  
  請求消息頭.png

• 響應(yīng)消息頭

  
  
  響應(yīng)消息頭.png

• 實體消息頭

  
  
  實體消息頭.png

http 常用狀態(tài)碼

https 是什么究飞，如何和瀏覽器交互的

網(wǎng)景在1994年創(chuàng)建了HTTPS置谦，并應(yīng)用在網(wǎng)景導(dǎo)航者瀏覽器中。 最初亿傅，HTTPS是與SSL一起使用的媒峡；在SSL逐漸演變到TLS時（其實兩個是一個東西，只是名字不同而已）葵擎，最新的HTTPS也由在2000年五月公布的RFC 2818正式確定下來谅阿。簡單來說，HTTPS就是安全版的HTTP酬滤，并且由于當(dāng)今時代對安全性要求更高签餐，chrome和firefox都大力支持網(wǎng)站使用HTTPS，蘋果也在ios 10系統(tǒng)中強制app使用HTTPS來傳輸數(shù)據(jù)盯串，由此可見HTTPS勢在必行氯檐。

image

https 和 HTTP 的區(qū)別

1. HTTPS協(xié)議需要到CA申請證書，一般免費證書很少嘴脾，需要交費男摧。
2. HTTP協(xié)議運行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文译打，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上拇颅，所有傳輸?shù)膬?nèi)容都經(jīng)過加密的奏司。
3. HTTP和HTTPS使用的是完全不同的連接方式，用的默認(rèn)端口也不一樣樟插，前者是80韵洋，后者是443。

4. HTTPS可以有效的防止運營商劫持黄锤，解決了防劫持的一個大問題搪缨。

   
   
   HTTPS 和 HTTP 的區(qū)別

alpn

ALPN (Application Layer Protocol Negotiation)是TLS的擴展，允許在安全連接的基礎(chǔ)上進(jìn)行應(yīng)用層協(xié)議的協(xié)商鸵熟。ALPN支持任意應(yīng)用層協(xié)議的協(xié)商副编，目前應(yīng)用最多是HTTP2的協(xié)商。在2016年流强，ALPN已經(jīng)完全替代NPN了痹届。

在沒有啟用 ALPN 的時候呻待，加載一個 HTTP/2 頁面的步驟是：

Without ALPN, the steps to load a HTTP/2 page would be like:

TLS 握手 (TLS handshake)
瀏覽器/客戶端 發(fā)送帶有 “Upgrade: h2c” 頭的 HTTP/1.1 請求 (Browser/Client speaks HTTP/1.1 to server with “Upgrade: h2c” Header)
服務(wù)器回復(fù) 101 Switching 并將鏈接升級至 HTTP2 (Server responds with 101 Switching to upgrade to HTTP2)
現(xiàn)在服務(wù)器和客戶端采用 HTTP2 協(xié)議交流 (Now they talks via HTTP2)
在啟用了 ALPN 的情況下：

With ALPN, the steps would be:

TLS握手，并且在握手過程中队腐，客戶端告訴服務(wù)器一個客戶端支持的協(xié)議列表蚕捉，然后服務(wù)器回復(fù)客戶端支持 HTTP2 協(xié)議 (TLS handshake and in the handshake client tells the server the list of protocol it supports and server respond in handshake saying that it supports HTTP2 as well)
現(xiàn)在服務(wù)器和客戶端采用 HTTP2 協(xié)議交流 (Now they talks via HTTP2)
可以看出，使用 ALPN 之后柴淘，客戶端和服務(wù)器的交互少了一輪握手（不需要 Upgrade 和 101 Switching）

spdy

1. 多路復(fù)用 請求優(yōu)化

   SPDY 規(guī)定在一個 SPDY 連接內(nèi)可以有無限個并行請求迫淹，即允許多個并發(fā) HTTP 請求共用一個 TCP會話。這樣 SPDY 通過復(fù)用在單個 TCP 連接上的多次請求为严，而非為每個請求單獨開放連接千绪，這樣只需建立一個 TCP 連接就可以傳送網(wǎng)頁上所有資源，不僅可以減少消息交互往返的時間還可以避免創(chuàng)建新連接造成的延遲梗脾，使得 TCP 的效率更高荸型。此外，SPDY 的多路復(fù)用可以設(shè)置優(yōu)先級炸茧，而不像傳統(tǒng) HTTP 那樣嚴(yán)格按照先入先出一個一個處理請求瑞妇，它會選擇性的先傳輸 CSS 這樣更重要的資源，然后再傳輸網(wǎng)站圖標(biāo)之類不太重要的資源梭冠，可以避免讓非關(guān)鍵資源占用網(wǎng)絡(luò)通道的問題辕狰，提升 TCP 的性能。

2. 支持服務(wù)器推送技術(shù)

   服務(wù)器可以主動向客戶端發(fā)起通信向客戶端推送數(shù)據(jù)控漠，這種預(yù)加載可以使用戶一直保持一個快速的網(wǎng)絡(luò)蔓倍。

3. SPDY 壓縮了 HTTP 頭

   舍棄掉了不必要的頭信息，經(jīng)過壓縮之后可以節(jié)省多余數(shù)據(jù)傳輸所帶來的等待時間和帶寬盐捷。

4. 強制使用 SSL 傳輸協(xié)議

   Google 認(rèn)為 Web 未來的發(fā)展方向必定是安全的網(wǎng)絡(luò)連接偶翅，全部請求 SSL 加密后，信息傳輸更加安全碉渡。

http2

二進(jìn)制分幀層

HTTP/2 所有性能增強的核心在于新的二進(jìn)制分幀層聚谁，它定義了如何封裝 HTTP 消息并在客戶端與服務(wù)器之間傳輸。

二進(jìn)制分幀.png

幀（frame）

HTTP 2.0通信的最小單位滞诺，包括幀首部形导、流標(biāo)識符、優(yōu)先值和幀凈荷等习霹。 

消息（message）

消息是指邏輯上的HTTP消息（請求/響應(yīng)）朵耕。一系列數(shù)據(jù)幀組成了一個完整的消息。比如一系列DATA幀和一個HEADERS幀組成了請求消息淋叶。

流 (stream)

已建立的連接內(nèi)的雙向字節(jié)流阎曹，可以承載一條或多條消息。

二進(jìn)制分幀-流.png

特點

• 所有通信都在一個 TCP 連接上完成，此連接可以承載任意數(shù)量的雙向數(shù)據(jù)流芬膝。
• 每個數(shù)據(jù)流都有一個唯一的標(biāo)識符和可選的優(yōu)先級信息望门，用于承載雙向消息。
• 每條消息都是一條邏輯 HTTP 消息（例如請求或響應(yīng)）锰霜，包含一個或多個幀筹误。
• 幀是最小的通信單位，承載著特定類型的數(shù)據(jù)癣缅，例如 HTTP 標(biāo)頭厨剪、消息負(fù)載，等等友存。 來自不同數(shù)據(jù)流的幀可以交錯發(fā)送祷膳，然后再根據(jù)每個幀頭的數(shù)據(jù)流標(biāo)識符重新組裝。

多路復(fù)用共享鏈接

在 HTTP/1.x 中屡立，如果客戶端要想發(fā)起多個并行請求以提升性能直晨，則必須使用多個 TCP 連接（請參閱使用多個 TCP 連接）。這是 HTTP/1.x 交付模型的直接結(jié)果膨俐，該模型可以保證每個連接每次只交付一個響應(yīng)（響應(yīng)排隊）勇皇。更糟糕的是，這種模型也會導(dǎo)致隊首阻塞焚刺，從而造成底層 TCP 連接的效率低下敛摘。

HTTP/2 中新的二進(jìn)制分幀層突破了這些限制，實現(xiàn)了完整的請求和響應(yīng)復(fù)用：客戶端和服務(wù)器可以將 HTTP 消息分解為互不依賴的幀乳愉，然后交錯發(fā)送兄淫，最后再在另一端把它們重新組裝起來。

請求優(yōu)先級

將 HTTP 消息分解為很多獨立的幀之后蔓姚，我們就可以復(fù)用多個數(shù)據(jù)流中的幀捕虽，客戶端和服務(wù)器交錯發(fā)送和傳輸這些幀的順序就成為關(guān)鍵的性能決定因素。為了做到這一點赂乐，HTTP/2 標(biāo)準(zhǔn)允許每個數(shù)據(jù)流都有一個關(guān)聯(lián)的權(quán)重和依賴關(guān)系：

• 可以向每個數(shù)據(jù)流分配一個介于 1 至 256 之間的整數(shù)薯鳍。
• 每個數(shù)據(jù)流與其他數(shù)據(jù)流之間可以存在顯式依賴關(guān)系。

數(shù)據(jù)流依賴關(guān)系和權(quán)重的組合讓客戶端可以構(gòu)建和傳遞“優(yōu)先級樹”挨措，表明它傾向于如何接收響應(yīng)。反過來崩溪，服務(wù)器可以使用此信息通過控制 CPU浅役、內(nèi)存和其他資源的分配設(shè)定數(shù)據(jù)流處理的優(yōu)先級，在資源數(shù)據(jù)可用之后伶唯，帶寬分配可以確保將高優(yōu)先級響應(yīng)以最優(yōu)方式傳輸至客戶端觉既。

服務(wù)端推送

HTTP/2 新增的另一個強大的新功能是，服務(wù)器可以對一個客戶端請求發(fā)送多個響應(yīng)。 換句話說瞪讼，除了對最初請求的響應(yīng)外钧椰，服務(wù)器還可以向客戶端推送額外資源（圖 12-5），而無需客戶端明確地請求符欠。

服務(wù)器推送.png

首部壓縮

每個 HTTP 傳輸都承載一組標(biāo)頭嫡霞，這些標(biāo)頭說明了傳輸?shù)馁Y源及其屬性。 在 HTTP/1.x 中希柿，此元數(shù)據(jù)始終以純文本形式诊沪，通常會給每個傳輸增加 500–800 字節(jié)的開銷。如果使用 HTTP Cookie曾撤，增加的開銷有時會達(dá)到上千字節(jié)端姚。（請參閱測量和控制協(xié)議開銷。）為了減少此開銷和提升性能挤悉，HTTP/2 使用 HPACK 壓縮格式壓縮請求和響應(yīng)標(biāo)頭元數(shù)據(jù)渐裸，這種格式采用兩種簡單但是強大的技術(shù)：
1. 這種格式支持通過靜態(tài) Huffman 代碼對傳輸?shù)臉?biāo)頭字段進(jìn)行編碼，從而減小了各個傳輸?shù)拇笮　?br> 2. 這種格式要求客戶端和服務(wù)器同時維護(hù)和更新一個包含之前見過的標(biāo)頭字段的索引列表（換句話說装悲，它可以建立一個共享的壓縮上下文）昏鹃，此列表隨后會用作參考，對之前傳輸?shù)闹颠M(jìn)行有效編碼衅斩。
利用 Huffman 編碼盆顾，可以在傳輸時對各個值進(jìn)行壓縮，而利用之前傳輸值的索引列表畏梆，我們可以通過傳輸索引值的方式對重復(fù)值進(jìn)行編碼您宪，索引值可用于有效查詢和重構(gòu)完整的標(biāo)頭鍵值對。

壓縮消息頭.png

如何升級使用 http2

參考鏈接

當(dāng)我們在瀏覽器中輸入一個URL后奠涌，發(fā)生了什么宪巨？

HTTP1.0、HTTP1.1和HTTP2.0的區(qū)別

HTTP 2.0與HTTP 1.1區(qū)別

HTTP 2.0 原理詳細(xì)分析

HTTP,HTTP2.0,SPDY,HTTPS你應(yīng)該知道的一些事

http2 測試頁面

http2 協(xié)議翻譯

什么是 ALPN(應(yīng)用層協(xié)議協(xié)商) What is ALPN (Application-Layer Protocol Negotiation)

HTTPS那些協(xié)議：TLS, SSL, SNI, ALPN, NPN

HTTP/2筆記之連接建立

HTTP/2筆記之流和多路復(fù)用

HTTP/2 簡介

HTTP/2 服務(wù)端推送

阮一峰 HTTP 簡介