前端須要瞭解的http知識

http基本概念

http是一個無狀態 ，無鏈接的基於TCP協議的單向應用層協議

1、無鏈接

無鏈接即每次連接只處理一個請求，請求和應答後就斷開連接

2、無狀態

http的每次請求都是獨立的，不相關的，協議對事物處理沒有記憶功能。 HTTP無狀態的特性嚴重阻礙了這些交互式應用程序的實現，畢竟交互是須要承前啓後的，簡單的購物車程序也要知道用戶到底在以前選擇了什麼商品。因而，兩種用於保持HTTP狀態的技術就應運而生了，一個是Cookie，而另外一個則是Session。

HTTP請求報文

HTTP請求報文由3部分組成（報文行+報文頭+報文體）：

常見的HTTP響應報文頭屬性

Cache-Control
響應輸出到客戶端後，服務端經過該報文頭屬告訴客戶端如何控制響應內容的緩存。 常見的取值有private、public、no-cache、max-age，no-store，默認爲private。 private: 客戶端能夠緩存 public: 客戶端和代理服務器均可緩存（前端的同窗，能夠認爲public和private是同樣的） max-age=xxx: 緩存的內容將在 xxx 秒後失效 no-cache: 須要使用對比緩存來驗證緩存數據 no-store: 全部內容都不會緩存 默認爲private，緩存時間爲31536000秒（365天）也就是說，在365天內再次請求這條數據，都會直接獲取緩存數據庫中的數據，直接使用。

ETag
一個表明響應服務端資源（如頁面）版本的報文頭屬性，若是某個服務端資源發生變化了，這個ETag就會相應發生變化。它是Cache-Control的有益補充，可讓客戶端「更智能」地處理何時要從服務端取資源，何時能夠直接從緩存中返回響應。

Location
咱們在JSP中讓頁面Redirect到一個某個A頁面中，實際上是讓客戶端再發一個請求到A頁面，這個須要Redirect到的A頁面的URL，其實就是經過響應報文頭的Location屬性告知客戶端的，以下的報文頭屬性，將使客戶端redirect到iteye的首頁中： Location: www.iteye.com

Set-Cookie
服務端能夠設置客戶端的Cookie，其原理就是經過這個響應報文頭屬性實現的： Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
更多詳細見 （一個介紹http的地址）

http code

2XX 成功
200 OK，表示從客戶端發來的請求在服務器端被正確處理
204 No content，表示請求成功，但響應報文不含實體的主體部分
205 Reset Content，表示請求成功，但響應報文不含實體的主體部分，可是與 204 響應不一樣在於要求請求方重置內容
206 Partial Content，進行範圍請求
3XX 重定向
301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
302 found，臨時性重定向，表示資源臨時被分配了新的 URL
303 see other，表示資源存在着另外一個 URL，應使用 GET 方法獲取資源
304 not modified，表示服務器容許訪問資源，但因發生請求未知足條件的狀況(緩存)
307 temporary redirect，臨時重定向，和302含義相似，可是指望客戶端保持請求方法不變向新的地址發出請求
4XX 客戶端錯誤
400 bad request，請求報文存在語法錯誤
401 unauthorized，表示發送的請求須要有經過 HTTP 認證的認證信息
403 forbidden，表示對請求資源的訪問被服務器拒絕
404 not found，表示在服務器上沒有找到請求的資源
5XX 服務器錯誤
500 internal sever error，表示服務器端在執行請求時發生了錯誤
501 Not Implemented，表示服務器不支持當前請求所須要的某個功能
503 service unavailable，代表服務器暫時處於超負載或正在停機維護，沒法處理請求

http method

get

GET方法用於使用給定的URI從給定服務器中檢索信息，即從指定資源中請求數據。使用GET方法的請求應該只是檢索數據，而且不該對數據產生其餘影響。

post

POST方法用於將數據發送到服務器以建立或更新資源，它要求服務器確認請求中包含的內容做爲由URI區分的Web資源的另外一個下屬。 POST請求永遠不會被緩存，且對數據長度沒有限制；咱們沒法從瀏覽器歷史記錄中查找到POST請求。 在規範的應用場景上說，Get 多用於無反作用，冪等的場景，例如搜索關鍵字。Post 多用於反作用，不冪等的場景，例如註冊。

put

PUT方法用於將數據發送到服務器以建立或更新資源，它能夠用上傳的內容替換目標資源中的全部當前內容。 它會將包含的元素放在所提供的URI下，若是URI指示的是當前資源，則會被改變。若是URI未指示當前資源，則服務器可使用該URI建立資源。

delete

DELETE方法用來刪除指定的資源，它會刪除URI給出的目標資源的全部當前內容。

head

HEAD方法與GET方法相同，但沒有響應體，僅傳輸狀態行和標題部分。這對於恢復相應頭部編寫的元數據很是有用，而無需傳輸整個內容。

OPTIONS

OPTIONS方法用來描述了目標資源的通訊選項，會返回服務器支持預約義URL的HTTP策略。（cors預請求瞭解一下，阮大神系列http://www.ruanyifeng.com/blog/2016/04/cors.html）

https

HTTP是明文傳輸的，也就意味着，介於發送端、接收端中間的任意節點均可以知道大家傳輸的內容是什麼。這些節點多是路由器、代理等。
HTTPS相對於HTTP有哪些不一樣呢？其實就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。
什麼是TLS/SSL？
通俗的講，TLS、SSL實際上是相似的東西，SSL是個加密協議，負責對HTTP的數據進行加密。TLS是SSL的升級版。如今提到HTTPS，加密協議基本指的是TLS。

先來了解一點概念
對稱加密：
對稱加密就是兩邊擁有相同的祕鑰，兩邊都知道如何將密文加密解密。
非對稱加密：
有公鑰私鑰之分，公鑰全部人均可以知道，能夠將數據用公鑰加密，可是將數據解密必須使用私鑰解密，私鑰只有分發公鑰的一方纔知道。

TLS握手流程

由上圖可知，先進行TCP的三次握手以後，就開始TLS的三次握手，關於TLS的握手細節
見下圖

一、clientHello

發送cipher suites （支持的加密套件列表） 和 random number到服務器

二、serverHello

發送random number， 證書（certificate），選擇的cipher suite 到客戶端

三、客戶端驗證證書（驗證細節見下文）

從證書中拿到公鑰， 生成預主鑰（pre master secret），用公鑰加密預主鑰，傳輸到服務端

咱們也能夠來看看阮大神的愛麗絲版
開始加密通訊以前，客戶端和服務器首先必須創建鏈接和交換參數，這個過程叫作握手（handshake）。
假定客戶端叫作愛麗絲，服務器叫作鮑勃，整個握手過程能夠用下圖說明。

第一步，愛麗絲給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支持的加密方法。
第二步，鮑勃確認雙方使用的加密方法，並給出數字證書、以及一個服務器生成的隨機數（Server random）。
第三步，愛麗絲確認數字證書有效，而後生成一個新的隨機數（Premaster secret），並使用數字證書中的公鑰，加密這個隨機數，發給鮑勃。 第四步，鮑勃使用本身的私鑰，獲取愛麗絲髮來的隨機數（即Premaster secret）。
第五步，愛麗絲和鮑勃根據約定的加密方法，使用前面的三個隨機數，生成"對話密鑰"（session key），用來加密接下來的整個對話過程。

結論： 公鑰加密對稱算法的私鑰傳到服務端，服務端用私鑰解密，這個時候客戶端和服務端都擁有同一個對稱算法的私鑰， 開始加密傳輸吧。

session 恢復鏈接

握手階段用來創建SSL鏈接。若是出於某種緣由，對話中斷，就須要從新握手。
這時有兩種方法能夠恢復原來的session：一種叫作session ID，另外一種叫作session ticket。
session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。若是對話中斷，下次重連的時候，只要客戶端給出這個編號，且服務器有這個編號的記錄，雙方就能夠從新使用已有的"對話密鑰"，而沒必要從新生成一把。

session ID是目前全部瀏覽器都支持的方法，可是它的缺點在於session ID每每只保留在一臺服務器上。因此，若是客戶端的請求發到另外一臺服務器，就沒法恢復對話。session ticket就是爲了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。

客戶端如何驗證證書的真僞

仍是先來了解一點概念

CA 機構

又稱爲證書認證中心 (Certificate Authority) 中心，是一個負責發放和管理數字證書的第三方權威機構，它負責管理PKI結構下的全部用戶(包括各類應用程序)的證書，把用戶的公鑰和用戶的其餘信息捆綁在一塊兒，在網上驗證用戶的身份。CA機構的數字簽名使得攻擊者不能僞造和篡改證書。

CA根證書：

CA自己有本身的證書，江湖人稱「根證書」。這個「根證書」是用來證實CA的身份的，本質是一份普通的數字證書。
瀏覽器一般會內置大多數主流權威CA的根證書。

證書內容

內容很是多，這裏咱們須要關注的有幾個點：
證書包含了頒發證書的機構的名字 -- CA
證書內容自己的數字簽名（用CA私鑰加密）
證書持有者的公鑰
證書籤名用到的hash算法
數字簽名與摘要
簡單的來講，「摘要」就是對傳輸的內容，經過hash算法計算出一段固定長度的串（是否是聯想到了文章摘要）。而後，在經過CA的私鑰對這段摘要進行加密，加密後獲得的結果就是「數字簽名」。

一、防僞造

這種狀況比較簡單，對證書進行檢查：
證書頒發的機構是僞造的：瀏覽器不認識，直接認爲是危險證書
證書頒發的機構是確實存在的，因而根據CA名，找到對應內置的CA根證書、CA的公鑰。
用CA的公鑰，對僞造的證書的摘要進行解密，發現解不了。認爲是危險證書

二、防篡改

假設代理經過某種途徑，拿到XX的證書，而後將證書的公鑰偷偷修改爲本身的，而後喜滋滋的認爲用戶要上鉤了。然而太單純了：
檢查證書，根據CA名，找到對應的CA根證書，以及CA的公鑰。
用CA的公鑰，對證書的數字簽名進行解密，獲得對應的證書摘要AA
根據證書籤名使用的hash算法，計算出當前證書的摘要BB
對比AA跟BB，發現不一致--> 斷定是危險證書
以上關於https介紹大部分來自於
imweb.io/topic/56d67…
www.ruanyifeng.com/blog/2014/0…

http2.0

在寫http2.0以前先看看http1.1的一些特性

http1.1

特色：

長鏈接：

TCP連接會很慢，由於三次握手、滑動窗口、慢啓動等的消耗，儘可能減小TCP連接。 長鏈接即TCP鏈接默認不關閉，能夠被多個請求複用，聲明Connection: keep-alive就能夠了。客戶端和服務器發現對方一段時間沒有活動，就能夠主動關閉鏈接 ，可是這只是解決了請求串行，並無解決並行

管道機制和線頭阻塞：

即在同一個TCP鏈接裏面，客戶端能夠同時發送多個請求。這樣就進一步改進了HTTP協議的效率。 其實HTTP管道化就是將客戶端的FIFO隊列移到了服務端。在客戶端能夠依次發送全部要發送的請求（固然這些請求是在同一個域下的），一 個請求發送完以後，沒必要等待這個請求的響應被接受到，下一個請求就能夠被再次發出。在服務器端維持的FIFO隊列，這個隊列是按照資源的重要程度排列的。 好比HTML比CSS要先返回，JS,CSS比圖片先返回。 若是前面請求的響應花了很長的時間，後面的請求也仍是須要等待（被阻塞），這就是線頭阻塞

因此這個方案並無實際解決同一個TCP併發請求的問題。

瀏覽器限制TCP連接：

在HTTP1.1中，瀏覽器客戶端能夠，可是在同一時間針對同一域名下的TCP連接有必定數量的限制（通常是6-8個TCP連接）。超過限制數目的請求會被阻塞。 爲了不這個問題，只有兩種方法：一是減小請求數，二是同時多開持久鏈接。這致使了不少的網頁優化技巧，好比合並腳本和樣式表、將圖片嵌入CSS代碼、域名分片/發散（domain sharding）等等

spdy協議

SPDY（讀做「SPeeDY」）是Google開發的基於TCP的會話層 協議，用以最小化網絡延遲，提高網絡速度，優化用戶的網絡使用體驗。SPDY並非一種用於替代HTTP的協議，而是對HTTP協議的加強。

定位

將頁面加載時間減小50%。
最大限度地減小部署的複雜性。SPDY使用TCP做爲傳輸層，所以無需改變現有的網絡設施。
避免網站開發者改動內容。 支持SPDY惟一須要變化的是客戶端代理和Web服務器應用程序。

具體技術目標

單個TCP鏈接支持併發的HTTP請求。
壓縮報頭和去掉沒必要要的頭部來減小當前HTTP使用的帶寬。
定義一個容易實現，在服務器端高效率的協議。經過減小邊緣狀況、定義易解析的消息格式來減小HTTP的複雜性。
強制使用SSL，讓SSL協議在現存的網絡設施下有更好的安全性和兼容性。
容許服務器在須要時發起對客戶端的鏈接並推送數據。

http2.0 SPDY的升級版

二進制分幀傳輸

幀：HTTP2.0通訊的最小單位，全部幀都共享一個8字節的首部，其中包含幀的長度、類型、標誌、還有一個保留位，而且至少有標識出當前幀所屬的流的標識符，幀承載着特定類型的數據，如HTTP首部、負荷、等等。
消息：比幀大的通信單位，是指邏輯上的HTTP消息，好比請求、響應等。由一個或多個幀組成
流：比消息大的通信單位。是TCP鏈接中的一個虛擬通道，能夠承載雙向的消息。每一個流都有一個惟一的整數標識符

在二進制分幀層上，HTTP2.0會將全部傳輸信息分割爲更小的消息和幀，並對它們採用二進制格式的編碼將其封裝。其中，HTTP1.X中的首部信息header封裝到Headers幀中，而request body將被封裝到Data幀中。 二進制分幀主要是爲下文中的各類特性提供了基礎。它能把一個數據劃分封裝爲更小更便捷的數據。首先是在單連接多資源方式中，減小了服務端的連接壓力，內存佔用更少，連接吞吐量更大。這一點能夠結合下文中的多路複用來體會。另外一方面，因爲TCP連接的減小而使網絡擁塞狀態得以改善，同時慢啓動時間的減小。使擁塞和丟包恢復的速度更快。 HTTP 2.0 中全部增強性能的核心點在於此

多路複用

基於二進制分幀層，HTTP2.0能夠在共享TCP連接的基礎上同時發送請求和響應。HTTP消息被分解爲獨立的幀，而不破壞消息自己的語義，交錯發出去，在另外一端根據流標識符和首部將他們從新組裝起來。
一、能夠並行交錯的發送請求和響應，這些請求和響應之間互不影響
二、只使用一個連接便可並行發送多個請求和響應
三、消除沒必要要的延遲，從而減小頁面加載的時間
四、沒必要再爲繞過HTTP1.x限制而多作不少工做
五、多路複用完美的解決了線頭阻塞問題。

請求優先級

每一個流均可以帶有一個31bit的優先值：0表示最高優先級；2的31次方-1表示最低優先級。
客戶端明確指定優先級，服務端能夠根據這個優先級做爲交互數據的依據，好比客戶端優先設置爲.css>.js>.jpg。服務端按此順序返回結果更加有利於高效利用底層鏈接，提升用戶體驗。然而，在使用請求優先級時應注意服務端是否支持請求優先級，是否會引發隊首阻塞問題，好比高優先級的慢響應請求會阻塞其餘資源的交互。

頭部壓縮

在 HTTP 1.X 中，咱們使用文本的形式傳輸 header，在 header 攜帶 cookie 的狀況下，可能每次都須要重複傳輸幾百到幾千的字節。 在 HTTP 2.0 中，使用了 HPACK 壓縮格式對傳輸的 header 進行編碼，減小了 header 的大小。並在兩端維護了索引表，用於記錄出現過的 header ，後面在傳輸過程當中就能夠傳輸已經記錄過的 header 的鍵名，對端收到數據後就能夠經過鍵名找到對應的值。

服務器推送

在 HTTP 2.0 中，服務端能夠在客戶端某個請求後，主動推送其餘資源。 能夠想象如下狀況，某些資源客戶端是必定會請求的，這時就能夠採起服務端 push 的技術，提早給客戶端推送必要的資源，這樣就能夠相對減小一點延遲時間。固然在瀏覽器兼容的狀況下你也可使用 prefetch 。