HTTP 火鍋【高級前端必備】

時間 2019-11-16

標籤 http 火鍋高級前端必備欄目 HTTP/TCP 简体版

原文原文鏈接

1、網絡基礎 TCP | IP

一般使用的網絡是在 TCP | IP 協議族的基礎上運做的，而 HTTP 屬於其中的一個子集html

協議：通訊，雙方必須基於相同的方法，好比如何探測到通訊目標、由哪一邊先發起通訊、使用哪一種語言進行通訊、怎樣結束通訊等規則都須要事先肯定。不一樣的硬件、操做系統之間的通訊等。
TCP | IP：是在IP協議的通訊過程當中，使用到的協議族的統稱
TCP | IP 分層：
- 應用層：FTP | DNS | HTTP | websocket
- 傳輸層：提供可靠的字節流服務，如TCP | UDP
- 網絡層：在衆多的選項中選擇一條傳輸路線，如 IP
- 數據鏈路層：網絡硬件部分，包括控制操做系統、硬件的設備驅動、網卡、光纖

一、IP協議

負責把各類數據包傳送給對方java

IP地址：指明瞭節點被分配到的地址
MAC地址：指網卡所屬的固定地址
- ARP：是一種用以解析地址的協議，根據通訊方的IP地址就能夠反查出對應的MAC地址

二、TCP

採用三次握手準確無誤地將數據送達目標處node

SYN(synchronize)
ACK(acknowledgement)

三、UDP

UDP是無鏈接的
TCP保證數據正確性，UDP可能丟包
TCP保證數據順序，UDP不保證
TCP鏈接只能是點到點的，UDP支持一對一，一對多，多對一和多對多的交互通訊

四、DNS

提供域名到IP地址之間的解析服務，或逆向從IP地址反查域名的服務web

五、URI 和 URL

URI：Uniform Resource Identifier, 統一資源標識符，用字符串標識某一互聯網資源面試

URL：Uniform Resource Locator，統一資源定位符，表示資源的地點（互聯網上所處的位置）瀏覽器

URL 是 URI 的子集緩存

http://user:pass@www.example.com:80/dir/index.html?uid=1#ch1安全

協議方案名 + 登陸信息（認證）+ 服務器地址 + 服務器端口號 + 帶層次的文件路徑 + 查詢字符串 + 片斷標識符bash

2、HTTP協議格式

一、HTTP請求協議格式

<request line>          // http請求行,用來講明請求類型(method)、要訪問的資源(request-URI)以及使用的HTTP版本
<headers>               // http請求消息報頭,說明服務器要使用的附加信息
<blank line>            // 回車換行
[<request-body>]        // http請求正文
複製代碼

POST /index.html HTTP/1.1 # 請求報文
Host: hackr.jp  # 請求首部字段
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 16
If-Modified_Since：Thu, 12Jul 2012 07:30:00 GMT # 僅返回2012年7月12日7點30分之後更新過的index.html頁面資源，若是未有內容更新，則以304 Not Modified做爲響應返回

name=ueno&age=37 # 內容實體
複製代碼

二、HTTP響應協議格式

<status line>          // http響應狀態行,經過提供一個狀態碼(status code)來講明所請求的資源狀況。及緣由短語（reason-phrase）
<headers>              // http響應消息報頭
<blank line>           // 回車換行
[<response-body>]      // http響應正文
複製代碼

HTTP/1.1 200 OK		# 協議版本 + 狀態碼 + 用以解釋狀態碼的緣由短語 
Date: Tue, 10 Jul 2012 06:50:15 GMT # 可選的響應首部字段
Content-Length: 362
Content-Type: text/html

<html> # 資源實體的主體（entity-body）

複製代碼

3、HTTP 方法

一、GET

獲取資源。GET提交的數據會在地址欄中顯示出來。特定瀏覽器和服務器對URL長度有限制，例如 IE對URL長度的限制是2083字節(2K+35)。對於其餘瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操做系統的支持。所以對於GET提交時，傳輸數據就會受到URL長度的限制。服務器

二、POST

傳輸實體主體。因爲不是經過URL傳值，理論上數據不受限。但實際各個WEB服務器會規定對post提交數據大小進行限制，Apache、IIS6都有各自的配置。

三、PUT

用於傳輸文件，因爲不帶驗證機制，存在安全性問題。若配合Web應用程序的驗證機制，或架構設計採用REST(REpresentational State Transfer, 表徵狀態轉移)標準的同類Web網站，可能會開放使用PUT方法。

四、HEAD

和GET方法同樣，只是不返回報文主體部分，用於確認URI的有效性及資源更新的日期時間等

五、DELETE

用於刪除文件，和PUT同樣不帶驗證機制

六、OPTIONS

用來查詢針對請求URI指定的資源支持的方法：Allow: GET, POST, HEAD, OPTIONS

若是不是訪問特定資源而是對服務器自己發起請求，能夠用一個*來代替請求URL

OPTIONS * HTTP/1.1

七、TRACE

讓服務器將以前的請求通訊環回給客戶端的方法，客戶端經過該方法能夠查詢發送出去的請求是怎樣被加工/篡改的。容易引起XST（Cross-Site Tracing）攻擊

八、CONNECT

要求用隧道協議鏈接代理，主要使用SSL|TLS把通訊內容加密後經網絡隧道傳輸

SSL: 安全套接層 Secure Sockets Layer
TLS：傳輸層安全 Transport Layer Security

CONNECT 代理服務器名：端口號 HTTP版本
複製代碼

4、HTTP 狀態碼

1. 狀態碼類別

1XX: 信息性狀體碼接收的請求正在處理
2XX: 成功狀態碼請求正常處理完畢
3XX: 重定向狀態碼須要進行附加操做以完成請求
4XX: 客戶端錯誤狀態碼服務器沒法處理請求
5XX: 服務器錯誤狀態碼服務器處理請求出錯

2. 14種常見狀態碼

當返回30一、30二、303，幾乎全部的瀏覽器都會把POST改成GET，並刪除請求報文內的主體，以後請求會自動從新發送

200 OK: 請求被正常處理
204 NO Content: 請求處理成功，但無資源可返回；在只須要從客戶端往服務器發送信息，而對客戶端不須要發送新信息內容的狀況下使用
206 Partial Content: 成功處理範圍請求
301 Moved Permanently: 永久性重定向，表示請求的資源已被分配了新的URI。當指定資源路徑的最後忘記添加‘/’，就會返回該狀態碼
302 Found：臨時性重定向，表示請求的資源存在另外一個URI；當替代303使用時，表示客戶端應當採用GET方法獲取資源
304 NOT Modified: 容許請求訪問資源，但未知足條件（指請求首部包含If-Match，If-Modified-Since,If-None-Match, If-Range,If-Unmodified-Since），響應不包含任何響應的主體部分。和重定向沒有關係
400 Bad Request: 請求報文中存在語法錯誤，需修改請求內容後再次發送請求
401 Unauthorized: 表示發送的請求須要有經過HTTP認證（BASIC認證、DIGEST認證）的認證信息。響應必須包含一個適用於被請求資源的WWW-Authenticate首部用以質詢(challenge)用戶信息
403 Forbidden: 不容許訪問那個資源
404 Not Found: 服務器上沒有請求的資源。也能夠在服務器端拒絕請求且不想說明理由時使用
500 Internal Server Error: 服務器端在執行請求時發生了錯誤
503 Service Unavailable: 代表服務器暫時處於超負載或正在進行停機維護，沒法處理請求。最好寫入Retry-After首部字段再返回給客戶端

5、HTTP 首部

若首部字段重複了，根據瀏覽器內部處理邏輯的不一樣，結果可能不一致。有些會優先處理第一次出現的首部字段，有些則會優先處理最後出現的首部字段。

HTTP 要確保它的報文被正確傳送、識別、提取以及適當處理：

能夠被正確地識別(經過Content-Type首部說明媒體格式，Content-Language首部說明語言)，以便瀏覽器和其餘客戶端能正確處理內容
能夠被正確的解包(經過Content-Length首部和Content-Encoding首部)
是最新的(經過實體驗證碼和緩存過時控制)
符合用戶的須要(基於Accept系列的內容協商首部)
在網絡上能夠快速有效地傳輸(經過範圍請求、差別編碼以及其餘數據壓縮方法)
完整到達、未被篡改(經過傳輸編碼首部和Content-MD5校驗和首部)

報文是箱子，實體是貨物

1. 通用首部字段

Cache-Control: 控制緩存的行爲
Connection：逐跳首部、鏈接的管理
Date：建立報文的日期時間
Pragma：報文指令
Trailer：報文末端的首部一覽
Transfer-Encoding：指定報文主體的傳輸編碼方式
Upgrade：升級爲其餘協議
Via：代理服務器的相關信息
Warning：錯誤通知

2. 請求首部字段

Accept: 用戶代理可處理的媒體類型
Accept-Charset: 優先的字符集
Accept-Encoding: 優先的內容編碼
Accept-Language: 優先的語言（天然語言）
Authorization: Web認證信息
Expect: 期待服務器的特定行爲
From: 用戶的電子郵箱地址
Host: 請求資源所在服務器
If-Match: 比較實體標記(ETag)
If-None-Match: 比較實體標記
If-Modified-Since(IMS請求): 比較資源的更新時間
If-Unmodified-Since: 比較資源的更新時間
If-Range: 資源未更新時發送實體Byte的範圍請求
Max-Forwards: 最大傳輸逐跳數
Proxy-Authorization: 代理服務器要求客戶端的認證信息
Range: 實體的字節範圍請求
Referer: 對請求中URI的原始獲取方
TE: 傳輸編碼的優先級
User-Agent: HTTP客戶端程序的信息

3. 響應首部字段

Accept-Ranges: 是否接受字節範圍請求
Age: 推算資源建立通過時間
ETag: 資源的匹配信息
Location: 令客戶端重定向至指定URI
Proxy-Authenticate: 代理服務器對客戶端的認證信息
Retry-After: 對再次發起請求的時機要求
Server: HTTP服務器的安裝信息
Vary: 代理服務器緩存的管理信息
WWW-Authenticate: 服務器對客戶端的認證信息
Last-Modified: 最後修改日期

四、實體首部字段

Allow: 資源可支持的HTTP方法
Content-Encoding: 實體主體適用的編碼方式
Content-Language: 實體主體的天然語言
Content-Length: 實體主體的大小
- 對緩存代理服務器尤爲重要，若是緩存服務器收到被截尾的報文卻沒有識別出截尾的話，它可能會存儲不完整的內容並屢次使用它來提供服務。緩存代理服務器一般不會爲沒有顯式Content-Length首部的HTTP主體作緩存，以此來減少緩存已截尾報文的風險。
- 持久鏈接：由於鏈接是持久的，客戶端沒法依賴鏈接關閉來判斷報文的結束。經過該首部就能夠知道報文從何處開始，從何處結束。
- 若是編碼了，則顯示的是編碼後的主體字節長度。
Content-Location: 替代對應資源的URI
Content-MD5: 實體主體的報文摘要
- 發送方能夠在生成初始的主體時，生成一個數據的校驗和，這樣接收方就能夠經過檢查這個校驗和來捕獲全部意外的實體修改
- 看成散列表的關鍵字，用來快速定位文檔並消除沒必要要的重複內容存儲
- 若是編碼了，針對編碼後的文檔
Content-Range: 實體主體的位置範圍
Content-Type: 實體主體的媒體類型(MIME類型)
- 主媒體類型/子類型
- 編碼以前的實體主體類型
- 支持可選的參數進一步說明內容的類型
Expires: 實體主體過時的日期時間
Last-Modified: 資源的最後修改日期時間
ETag: 這份文檔特定實例的惟一驗證碼
Cache-Control: 應該如何緩存該文檔

五、RFC4229 HTTP Header Field Registrations

Cookie: 請求首部字段，服務器接收到的Cookie信息
Set-Cookie: 響應首部字段，開始狀態管理所使用的Cookie信息
- NAME=VALUE：賦予Cookie的名稱和值
- expires=DATE: Cookie的有效期
- path=PATH: 將服務器上的文件目錄做爲Cookie的適用對象(若不指定則默認爲建立Cookie的服務器的域名)
- domain=域名: 做爲Cookie適用對象的域名(若不指定則默認爲建立Cookie的服務器的域名)
- Secure: 僅在HTTPS安全通訊時纔會發送Cookie
- HttpOnly: 加以限制，使Cookie不能被JavaScript腳本訪問
  - 使用JS的document.cookie沒法讀取附加該屬性後的
Content-Disposition

六、逐跳首部(Hop-by-hop Header)

Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
Trailer
TE
Transfer-Encoding
Upgrade

七、端到端首部(End-to-end Header)

除了8個逐跳首部外，其餘全部字段都屬於端到端首部

八、其餘首部字段：HTTP首部字段是能夠自行拓展的

X-Frame-Options：防止點擊劫持攻擊
- DENY: 拒絕
- SAMEORIGIN：僅同源域名下的頁面匹配時許可
X-XSS-Protection：防止跨站腳本攻擊，用於控制瀏覽器XSS防禦機制的開關
- 0: 將XSS過濾設置成無效狀態
- 1: 將XSS過濾設置成有效狀態
DNT：拒絕我的信息被收集

6、HTTP 的缺點

通訊使用明文（不加密），內容可能會被竊聽
不驗證通訊方的身份，所以有可能遭遇假裝
沒法證實報文的完整性，因此有可能已遭篡改

7、HTTPS

HTTPS = 數據加密 + 網站認證 + 完整性驗證 + HTTP

經過證書等信息確認網站的真實性
創建加密的信息通道
數據內容的完整性

CA中心發佈的數字證書經過對稱加密和非對稱加密對咱們網上傳輸的信息進行加密。端口號：443

對稱加密：加密和解密使用同一個密鑰
非對稱加密：
- 公鑰加密：發給查看網站的全部人
- 私鑰解密：只有網站服務器本身擁有

8、HTTP 2.0 的優點

採用二進制格式傳輸數據，而非 HTTP1.1 的文本格式，二進制格式在協議的解析和優化拓展上帶來更多的優點和可能；
對消息頭採用 HPACK 進行壓縮傳輸，可以節省消息頭佔用的網絡流量，而 HTTP1.1 每次都會攜帶大量冗餘頭信息，浪費帶寬，頭壓縮可以很好的解決該問題；
多路複用，就是多個請求都經過一個 TCP 鏈接併發完成，HTTP1.1 雖然經過 pipeline 也能併發請求，可是多個請求之間的響應會被阻塞的，因此 pipeline 至今也沒有被普及應用，而 HTTP2.0 作到了真正的併發請求，同時，流還支持優先級和流量控制；
Server Push, 服務端可以更快的把資源推送給客戶端，例如服務端能夠主動把 JS 和 CSS 文件推送給客戶端，而不須要客戶端解析 HTML；再發送這些請求，當客戶端須要的時候，它已經在客戶端了。