http基本概念

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

一、無連接

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

二、無狀態

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: http://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的握手細節
見下圖

1、clientHello

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

2、serverHello

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

3、客戶端驗證證書（驗證細節見下文），從證書中拿到公鑰， 生成預主鑰（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的私鑰對這段摘要進行加密，加密后得到的結果就是“數字簽名”。

1、防偽造

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

2、防篡改

假設代理通過某種途徑，拿到XX的證書，然后將證書的公鑰偷偷修改成自己的，然后喜滋滋的認為用戶要上鉤了。然而太單純了：
檢查證書，根據CA名，找到對應的CA根證書，以及CA的公鑰。
用CA的公鑰，對證書的數字簽名進行解密，得到對應的證書摘要AA
根據證書簽名使用的hash算法，計算出當前證書的摘要BB
對比AA跟BB，發現不一致--> 判定是危險證書
以上關于https介紹大部分來自于
https://imweb.io/topic/56d67baaca5e865230c1d4fa
http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

http2.0

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

http1.1

特點：

長連接：

即TCP連接默認不關閉，可以被多個請求復用，不用聲明Connection: keep-alive。客戶端和服務器發現對方一段時間沒有活動，就可以主動關閉連接

管道機制：

即在同一個TCP連接里面，客戶端可以同時發送多個請求。這樣就進一步改進了HTTP協議的效率。
其實HTTP管道化就是將客戶端的FIFO隊列移到了服務端。在客戶端可以依次發送所有要發送的請求（當然這些請求是在同一個域下的），一 個請求發送完之后，不必等待這個請求的響應被接受到，下一個請求就可以被再次發出。在服務器端維持的FIFO隊列，這個隊列是按照資源的重要程度排列的。 比如HTML比CSS要先返回，JS,CSS比圖片先返回。
問題

線頭阻塞：

在HTTP1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數量的限制。超過限制數目的請求會被阻塞。
為了避免這個問題，只有兩種方法：一是減少請求數，二是同時多開持久連接。這導致了很多的網頁優化技巧，比如合并腳本和樣式表、將圖片嵌入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消息被分解為獨立的幀，而不破壞消息本身的語義，交錯發出去，在另一端根據流標識符和首部將他們重新組裝起來。
1、可以并行交錯的發送請求和響應，這些請求和響應之間互不影響
2、只使用一個鏈接即可并行發送多個請求和響應
3、消除不必要的延遲，從而減少頁面加載的時間
4、不必再為繞過HTTP1.x限制而多做很多工作
5、多路復用完美的解決了線頭阻塞問題。

請求優先級

每個流都可以帶有一個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 。

轉載于:https://www.cnblogs.com/chenlei987/p/10848784.html

總結

以上是生活随笔為你收集整理的前端需要了解的http知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。