TCP http keep-alive CORS

時間 2019-11-06

原文原文鏈接

狀態碼

3位數，5大類
1XX 表示通知信息，如請求收到了或正在進行處理。
2XX 表示成功
- 201 created
- 204 no content
- 206 服務器成功處理了部分 GET 請求
3XX 表示重定向，若是完成ygfigip必須採起進一步的行動。
- 301 永久移動
- 302 臨時重定向 post到get
- 303 See Other一般做爲 PUT 或 POST 操做的返回結果，它表示重定向連接指向的不是新上傳的資源，而是另一個頁面，好比消息確認頁面或上傳進度頁面。而請求重定向頁面的方法要老是使用 GET。
- 304 Not Modified
- 307 與 302 之間的惟一區別在於，當發送重定向請求的時候，307 狀態碼能夠確保請求方法和消息主體不會發生變化。
4XX 表示客戶的差錯，如請求中有錯誤的語法或不能完成。
- 400 服務器不理解請求的語法,當參數錯誤的時候會遇到
- 401 身份驗證錯誤，當訪問受保護路由須要登陸
- 403 Forbidden，當訪問的資源不被容許
- 404 服務器找不到請求的網頁
- 405 Method Not Allowed 方法實現了可是不充許用
- 406 Not Acceptable MIME type
5XX 表示服務器
- 500 後端程序報錯會遇到
- 501 Not Implemented 請求的方法沒有實現
- 502 錯誤網關，服務器做爲網關或代理，從上游服務器收到了無效的響應。
- 503 服務不可用，當服務器宕機
- 504 請求超時
- 505 HTTP 版本不受支持

HTTP 緩存

命中強緩存的狀況下，返回的 HTTP 狀態碼爲 200
Cache-Control 相對於 expires 更加準確，它的優先級也更高。當 Cache-Control 與 expires 同時出現時，咱們以 Cache-Control 爲準。
若是服務端提示緩存資源未改動（Not Modified），資源會被重定向到瀏覽器緩存，這種狀況下網絡請求對應的狀態碼是 304（以下圖）。
Etag 在感知文件變化上比 Last-Modified 更加準確，優先級也更高。當 Etag 和 Last-Modified 同時存在時，以 Etag 爲準。

ETag: W/"2a3b-1602480f459"
If-None-Match: W/"2a3b-1602480f459"

 Last-Modified
 If-Modified-Since
複製代碼

must-revalidate

那麼這樣一來，基本能夠將 no-cache 與 must-revalidate, max-age=0 劃等了，但這二者也有些細節上的區別，即：vue

在執行must-revalidate時，若瀏覽器第二次去請求服務器來作新鮮度驗證，結果服務器掛了，沒法訪問，那麼緩存須要返回一個504 Gateway Timeout的錯誤（這裏應該是像nginx這樣的代理來返回，如果瀏覽器如chrome，將直接是ERR_CONNECTION_REFUSED，即沒法訪問，鏈接被拒絕）。ios

而若是是no-cache，當驗證新鮮度時，服務器撲街，則會照樣使用本地緩存顯示給用戶（有的總比沒的好，固然有可能顯示的就是舊的文檔了）。nginx

因此must-revalidate用在對事務要求比較嚴苛的狀況下使用（好比支付）web

報文分三部分

開始行用於區分是請求報文仍是響應報文，在請求報文中的開始行叫作請求行，而在響應報文中的開始行叫作狀態行。
首部行每一行在結束的地方都要有回車或換行。整個首部行結束時，還有一空行將首部行和後面的實體主體分開。
實體主體

3次握手和4次揮手

6個控制位，用來講明本報文段的性質。說明：確認 ack、推送 psh、復位 rst、同步 syn、終止 fin、窗口算法

爲何A最後還要發送一次確認呢？這主要是爲了防止已失效的鏈接請求報文段忽然又傳到B,於是產生錯誤。

UDP/TCP

用戶數據報協議 UDP

無鏈接，發送數據以前不須要建議鏈接，所以減小了開銷和發送數據以前的時延。
盡最大努力交付，不保證可靠交付。
沒有擁塞控制
支持一對1、一對多、多對一和多對多的交互通訊
首部開銷小，只有8字節，比tcp的20個字節短。

傳輸控制協議 tcp

面向鏈接，在使用以前必須建議鏈接。傳送完後再釋放，就像打電話，掛機。
可靠交付，無差錯、不丟失、不重複、而且按序到達。
全雙工通訊
每一條鏈接只有兩個端點，只能是點對點的。
面向字節流

可靠傳輸的工做原理

中止等待協議，就是每發完一個分組就中止發送，等待對方的確認。在收到確認後再發送下一個分組。
每發送完一個分組，設置一個超時計時器。若是超時沒有收到，認爲丟失了，重傳前面發過的分組，叫作超時重傳。
確認遲到，重複收到到，不向上層交付，而後發送確認。

http1.1 keep-alive

1.1版本新增，對同一個域名同時開6個connection，我發了12個get請求，瀏覽器採用非流水線模式。見下圖：chrome

觀察connection列，第二組與第一組的id是相同的，說明是共用的第一組。express

跨域資源共享(CORS)

不一樣的域、協議或端口請求一個資源時，資源會發起一個跨域 HTTP 請求。瀏覽器限制從腳本內發起的跨源HTTP請求。例如，XMLHttpRequest和Fetch API遵循同源策略。這意味着使用這些API的Web應用程序只能從加載應用程序的同一個域請求HTTP資源，除非響應報文包含了正確CORS響應頭。json

express 設置容許跨域代碼

app.all('*', function(req, res, next) {
	res.header("Access-Control-Allow-Origin", "*");
	res.header("Access-Control-Allow-Headers", "Content-Type,Access-Token,X-Requested-With");
	res.header("Access-Control-Allow-Methods","PUT,POST,GET,DELETE,OPTIONS");
	res.header("X-Powered-By",' 3.2.1')
	res.header("Content-Type", "application/json;charset=utf-8");
	next();
})
複製代碼

預檢請求

與前述簡單請求不一樣，「需預檢的請求」要求必須首先使用 OPTIONS 方法發起一個預檢請求到服務器，以獲知服務器是否容許該實際請求。"預檢請求「的使用，能夠避免跨域請求對服務器的用戶數據產生未預期的影響。axios

使用了下面任一 HTTP 方法,應首先發送預檢請求
- PUT
- DELETE
- CONNECT
- OPTIONS
- TRACE
- PATCH
Content-Type 的值不屬於下列之一:
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain

舉例：OPTIONS /users/ 200 0.883 ms - 13後端

發送post請求到users，S端只收到options請求，B收到響應後，知道不許許跨域，不會再發送真正的post請求

跨域請求發送攜帶身份憑證信息

# vue 中axios 
this.$http.get('http://localhost:3000/users/', {
	withCredentials: true
})

# 響應頭設置
res.header("Access-Control-Allow-Origin", "http://localhost:8080");
res.header("Access-Control-Allow-Headers", "Content-Type,x-xsrf-token");
res.header("Access-Control-Allow-Credentials",true);
複製代碼

對於附帶身份憑證的請求，服務器不得設置 Access-Control-Allow-Origin 的值爲「*」。

功能概述

跨域資源共享標準新增了一組 HTTP 首部字段，容許服務器聲明哪些源站經過瀏覽器有權限訪問哪些資源。另外，規範要求，對那些可能對服務器數據產生反作用的 HTTP 請求方法（特別是 GET 之外的 HTTP 請求，或者搭配某些 MIME 類型的 POST 請求），瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知服務端是否容許該跨域請求。服務器確認容許以後，才發起實際的 HTTP 請求。在預檢請求的返回中，服務器端也能夠通知客戶端，是否須要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關數據）。

五層協議

計算機通訊是兩個運行的進程之間的通訊
五層協議的體系結構只爲介紹網絡原理而設計，實用應用的仍是tcp/ip四層體系結構

HTTPS和HTTP的區別

1、https協議須要到ca申請證書，通常免費證書不多，須要交費。
2、http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議。
3、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
4、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

http2

之因此要遞增一個大版本到 2.0，主要是由於它改變了客戶端與服務器之間交換數據的方式。爲實現宏偉的性能改進目標，HTTP 2.0 增長了新的二進制分幀數據層，而這一層並不兼容以前的 HTTP 1.x 服務器及客戶端——是謂 2.0。

二進制分幀數據層
服務器端推送
全部通訊都在一個TCP鏈接，多路複用
頭部進行壓縮

流是鏈接中的一個虛擬信道，能夠承載雙向的消息;每一個流都有一個惟一的整數標識符(一、2…N)
消息是指邏輯上的 HTTP 消息，好比請求、響應等，由一或多個幀組成
幀是最小的通訊單位，承載着特定類型的數據，如 HTTP 首部、負荷，等等。
有了新的分幀機制後，HTTP 2.0 再也不依賴多個 TCP 鏈接去實現多流並行了。如今，每一個數據流都拆分紅不少幀，而這些幀能夠交錯，還能夠分別優先級。因而，全部 HTTP 2.0 鏈接都是持久化的，並且客戶端與服務器之間也只須要一個鏈接便可。

參考連接

跨域 developer.mozilla.org/zh-CN/docs/…
http1.1流水線 developer.mozilla.org/zh-CN/docs/…
HTTP 緩存 developers.google.com/web/fundame…

持續新增

HTTP Strict Transport Security

（一般簡稱爲HSTS）是一個安全功能，它告訴瀏覽器只能經過HTTPS訪問當前資源，而不是HTTP。

語法

設置在瀏覽器收到這個請求後的<expire-time>秒的時間內凡是訪問這個域名下的請求都使用HTTPS請求。
Strict-Transport-Security: max-age=<expire-time>

若是這個可選的參數被指定，那麼說明此規則也適用於該網站的全部子域名。
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains

查看 預加載 HSTS 得到詳情。不是標準的一部分。
Strict-Transport-Security: max-age=<expire-time>; preload
複製代碼

Chrome、Firefox等瀏覽器裏，當您嘗試訪問該域名下的內容時，會產生一個307 Internal Redirect（內部跳轉），自動跳轉到HTTPS請求。

Upgrade-Insecure-Requests: 1 是一個請求首部，用來向服務器端發送信號，表示客戶端優先選擇加密及帶有身份驗證的響應，

參考：developer.mozilla.org/zh-CN/docs/…