HTTP相關知識彙總

基礎定義

TCP/IP體系結構（4層）

應用層 （應用層，表示層，會話層）

協議：
HTTP - 提供Internet瀏覽服務
SMTP - 簡單的電子郵件發送服務
DNS - 負責域名和IP地址的映射
POP / IMAP - 對郵箱服務器進行遠程存取郵件的服務（POP-服務端傳給客戶端後刪除、狀態不一樣步；IMAP-服務端存、狀態同步）
FTP - 應用級文件傳輸服務
Telnet - 遠程登陸服務（明文傳輸）
SSH - 遠程登陸服務（加密）
定義應用進程間通訊、交互的規則。（主機中運行的程序、基於CS方式、報文）

運輸層

協議：
TCP - 面向鏈接、可靠的報文服務
UDP - 無鏈接、不可靠的報文服務
爲不一樣主機中的進程間提供通訊服務。傳輸單位：報文段（TCP）、用戶數據報文（UDP）
功能：
爲端到端的鏈接提供傳輸服務。

網絡層

協議：
IP - 提供網絡節點之間的報文傳送服務
ARP - 實現IP地址向物理地址的映射【ARP攻擊】
RARP - 實現物理地址向IP地址的映射
ICMP - 探測、報告傳輸中產生的錯誤
IGMP - 管理多播組測成員關係
其他：IPX、OSPF
爲不一樣主機提供通訊服務：網絡層的分組數據從源端到目的端。傳輸單位：數據報。
功能：

1. 封裝數據成分組/包、路由選擇
2. 流量控制、擁塞控制、差錯控制、網際互聯

網絡接口層（鏈路層、物理層）

協議：STP
負責數據傳輸工做。傳輸單位：幀
功能：

1. 組幀、差錯控制、流量控制和傳輸管理
2. 在廣播式網絡經過介質訪問子層，控制共享信道的訪問

TCP與UDP

TCP協議 （Transmission Control Protocol,傳輸控制協議）

面向鏈接、面向字節流、全雙工通訊、可靠。
屬於傳輸層通訊協議，基於TCP的應用層協議有 HTTP SMTP FTP Telnet POP3。
缺點：效率慢（創建鏈接、發送確認包）

傳送的數據單元：報文段。

報文段 = 首部 + 數據
首部 = 20字節 + 4n個根據須要增長的選項 （最小長度 20 字節）

//共 5 行，每行4字節
源端口  目的端口
序號
確認號
數據偏移  保留  URG ACK PSH RST SYN FIN  窗口
校驗和  緊急指針

序號 - 報文段序號
確認號 - （ACK）指望收到對方下一個報文的序號。ACK=N，表示序號N-1的全部數據都已正確收到
SYN - 同步位，鏈接創建時用於同步序號
FIN - 終止控制位，釋放鏈接

TCP創建鏈接 - 三次握手

C -> S - SYN=1,seq=x
C <- S - SYN=1,ACK=1,seq=y,ack=x+1
C -> S - ACK=1,seq=x+1,ack=y+1

做用：防止接受早已失效的鏈接請求報文，形成死鎖、浪費資源

TCP釋放鏈接 - 四次揮手

C -> S - FIN=1,seq=u
C <- S - ACK=1,seq=v,ack=u+1
     CLOSE_WAIT //通知上層關閉
C <- S - FIN=1,ACK=1,seq=w,ack=u+1
C -> S - ACK=1,seq=u+1,ack=w+1
TIME_WAIT (2MSL)

無差錯控制原理

基礎：

發送窗口

任意時刻，發送方維持的一組連續的、容許發送幀的幀序號（對發送方的進行流量控制）
工做原理：1. 每收到一個確認幀，發送窗口向前滑動一個幀的距離；2. 無可發送幀時，中止發送，等待確認幀。有確認幀且窗口向前滑動時，才繼續發送。

接受窗口

任意時刻，接收方維持的一組連續的、容許接受幀的幀序號（控制可接受、不可接受哪些數據幀，只有收到的幀序號在窗口內才容許收下）
工做原理：收到數據幀後，窗口向前移動一個位置，併發回確認幀。若收到窗口以外的，一概丟棄。

協議

中止-等待協議、後退N幀協議、選擇重傳協議只是在發送窗口大小和接收窗口大小上有所差異

中止-等待協議：發送窗口大小 = 1，接收窗口大小 = 1
後退N幀協議：發送窗口大小 > 1, 接收窗口 = 1
選擇重傳協議：發送窗口大小 > 1,接收窗口 > 1

實現無差錯傳輸的解決方案

採用可靠傳輸協議，使得 1.出錯重傳，出現差錯時，讓發送方重傳差錯數據；2.速度匹配，當接收方來不及接收可通知發送方下降速率。

自動重傳請求協議ARQ（Auto Repeat reQuest） (針對 出錯重傳)
傳輸出現差錯時，接收方自動請求發送方重傳出錯的數據。
機制：1.確認機制 - 發送方收到應答才發送，接收方收到一個反饋一個，不反饋發送方一直等待；2.超時重傳機制 - 發送方發送後開啓計時器，必定時間內每收到確認，則重發，直到成功爲止。
類型：中止等待式ARQ、後退N幀ARQ、選擇重傳ARQ。

流量控制 & 擁塞控制 （針對 速度匹配）
接收方根據本身接收緩存的大小，動態調整發送方的發送窗口大小。
避免發送太快，接收方來不及。

相關資料：
TCP協議攻略

UDP協議 （User Dataram Protocal, 用戶數據報協議）

屬於傳輸層通訊協議
基於UDP的應用層協議有 TFTP（文件傳輸）、SNMP（網絡管理）、NFS(遠程文件服務器) 與 DNS（域名轉換）

無鏈接的、不可靠的、面向報文、無擁塞協議

不須要創建鏈接，發送後不論是否會到達
以數據報文（包）的形式傳輸，UDP數據報文長度無限制，一次性發送，不拆分

報文段格式

UDP的報文段共有2個字段：數據字段 + 首部字段（8字節，4個字段）

UDP首部：
源端口 - 源端口號，須要 對方回信時使用
目的端口 - 終點交付報文時需使用到
長度 - UDP用戶數據報的長度
檢驗和 - 檢測在傳輸中是否有錯，有錯丟棄

HTTP （HyperText Transfer Protocol, 超文本傳輸協議）

屬於應用層。規定了應用進程間通訊的準則。

特色：
傳輸效率高 - 無鏈接、無狀態、傳輸格式簡單
傳輸可靠性高 - 採用TCP做爲傳輸層協議

請求方法

不一樣的方法規定了不一樣的操做指定的資源的方式。服務端會根據不一樣的請求方法作不一樣的響應。

若服務器時 RESTful 接口，通常會用到 GET、POST、DELETE、PUT

• GET

顯示請求指定資源。只用於數據的讀取。

傳遞參數長度受限制，只容許ASCII字符，安全性差（可見）
應用場景:小量、數據不敏感，從指定資源請求數據

• POST

向指定資源提交數據，請求數據處理。表單數據提交、文件上傳。

傳遞參數長度不受限制，可傳遞任何類型字符，安全性好
應用場景：大量、數據敏感，想指定資源提交數據

• HEAD

向服務器發出指定資源的請求，服務器在響應是不會回傳響應主體（內容）。

能夠在不傳輸所有內容的狀況下，獲取服務器的響應頭信息。經常使用於客戶端查看服務端性能。【請求完整執行？】

• PUT (如下 1.1新增)

向指定資源位置上傳其最新內容，取代指定的資源（已存在）的內容。

• PATCH

當資源不存在時會建立新資源。部分更新。

• DELETE

請求服務器刪除所請求的URI所標識的資源。

• OPTIONS

請求服務器返回該資源所支持的全部HTTP請求方法。

JS的XMLHttpRequest對象進行 CORS（Cross-origin resource sharing, 跨域資源共享） 時，使用OPTIONS方法發送嗅探請求，以判斷是否有對指定資源的訪問權限。

例如：

請求：
OPTIONS /upload HTTP/1.1
Access-Control-Request-Method: POST //提醒接下來的請求會使用的方法
Access-Control-Request-Headers: accept, content-type
Origin: http://xxx.com
...

響應頭中的關鍵字：
Access-Control-Allow-Method: POST
Access-Control-Allow-Origin: http://xxx.com //容許的域名
可設置相應狀態碼爲 204 ，告知客戶端該響應成功了，可是沒有任何響應體。

• CONNECT

預留，能將鏈接方式改成管道方式的代理服務器。一般用於SSL加密服務器的連接與非加密的HTTP代理服務器的通訊。

• TRACE

請求服務器回顯其收到的請求信息，用於HTTP請求的測試或診斷。

HTTP報文詳解

HTTP在應用層交互數據的方式：報文
HTTP的報文分爲：請求報文、響應報文

請求報文：

HTTP的請求報文由 請求行、請求頭、請求體 組成。

請求方法 URL 協議版本
頭部字段名：值
頭部字段名：值

請求數據

(換行都rn)
請求行（request line） - 聲明 請求方法、主機域名、資源路徑、協議版本
請求頭（header） - 聲明 客戶端、服務器報文的部分信息
請求體 - 存放須要發送的數據信息

例如：

GET /index.php/archives/3/ HTTP/1.1
Host: liyunzhen.com   （HTTP/1.0 無host字段）
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

請求Header

請求和響應報文的通用header：

Content-Type - 請求體/響應體的類型，如 text/plain,application/json
Accept - 說明接收的類型，能夠多個值，用逗號分開
Content-Length - 請求體/響應體的長度，單位字節
Content-Encoding - 請求體/響應體的編碼格式，如gzip、deflate
Accept-Encoding - 告知對方我方接受的Content-Encoding
ETag - 給當前資源的標識，和 Last-Modified、If-None-Match、If-Modified-Since 配合，用於緩存控制
Cache-Control - 取值通常爲 no-cache 或 max-age=xx(整數，該資源的緩存有效期，秒)

請求Header：

Authorization - 用於設置身份認證信息
User-Agent - 用戶標識，如 OS和瀏覽器的類型、版本
If-Modified-Since - 值爲上一次服務器返回的 Last-Modified 值，用於確認某個資源是否被更改過，沒有更改過（304）就從緩存中讀取
If-None-Match - 值爲上一次服務器返回的 ETag 值，通常和 If-Modified-Since 一塊兒出現
Cookie - 已有的Cookie
Referer - 表示請求引用自那個地址（來源地址）
Host - 請求的主機和端口號

請求體 - 存放須要發送給服務器的數據信息。（可選）

使用方式：

1. 數據交換
 請求體可任意格式類型，須要服務端額外解析。如json格式【protocol buffer 看看是否是】
2. 鍵值對
 鍵=值&鍵=值。如key1=1&key2=2
3. 分部形式
 請求體被分爲多個部分，每段以 -{boundary} 、描述頭、（空行）、內容，以 -{boundary}- 結束

響應報文

HTTP的響應報文包括：狀態行、響應頭、響應體

報文結構：

協議版本 狀態碼 狀態描述
頭部字段名：值
頭部字段名：值

響應正文

狀體行 - 聲明 協議版本、狀態碼、狀態碼描述
響應頭 - 聲明 客戶端、服務端報文的部分信息
響應體 - 存放須要發送的數據信息

例如：

HTTP/1.1 200 OK
Server: openresty
Date: Sun, 12 Aug 2018 02:35:31 GMT
Content-Type: text/html; charset=UTF-8

HTTP狀態碼

3位十進制數字組成，分爲5大類：

1xx - 表示信息通知，如收到了請求正在處理
2xx - 表示成功，如接受或知道了
3xx - 表示重定向，如要完成請求還必須採起進一步行動
4xx - 表示客戶端錯誤，請求包含語法錯誤或沒法實現
5xx - 表示服務器錯誤

舉例：

200 - 請求成功，請求內容與該響應一塊兒返回
202 - 請求已被接受，但還沒處理
204 - 請求執行成功，可是沒有數據（瀏覽器不用刷新頁面，也不用導向新的頁面）
301 - 請求資源已被永久移動到新的位置
302 - 請求的資源被臨時移動到新的位置
304 - 服務端資源未發生改變（If Modified Since和資源更新的時間），只返回HEADER
400 - 請求參數有誤，當前請求沒法被服務器理解
401 - 請求須要驗證用戶
403 - 不容許訪問該地址
404 - Not Found
408 - 請求超時
500 - 服務器內部錯誤
502 - Bad Gateway 網關出錯

協議版本（HTTP/1.0、HTTP/1.一、HTTP/2.0）

HTTP/1.1 特色：
引入持久鏈接，（在同一個TCP的鏈接中可傳送多個HTTP請求、響應）
多個請求、響應可同時進行、可重疊
引入更多請求頭、響應頭（身份認證、狀態管理、cache緩存、host）

HTTP處理長鏈接方式：
HTTP/1.1 默認保持長鏈接，數據傳輸完成後TCP鏈接不斷開，繼續使用該通道傳輸數據。

創建長鏈接：

HTTP頭部字段：Connection
connection:close - 不使用長鏈接
connection:Keep-Alive & Keep-Alive:max=20 - 鏈接失敗超過這個次數就斷開
connection:Keep-Alive & Keep-Alive:time=20 - 超過該時間則斷開

Keep-Alive機制：開啓後，TCP層定時發送響應的探針以肯定鏈接的可用性

結束長鏈接(如何判斷本次傳輸結束)

1. 判斷傳輸數據是否達到了 Content-Length 指示的大小
2. 根據 chunked 編碼判斷，若 chunked 編碼的數據在最後有一個空 chunked 塊，則代表本次傳輸完畢

HTTP/2.0特色
支持請求與響應的多路複用，經過壓縮HTTP頭字段下降開銷，增長請求優先級和服務端推送的支持。

多路複用： 容許同時經過單一的HTTP/2.0鏈接發起多重的請求、響應消息

將HTTP協議通訊的基本單位縮小爲幀。在應用層和傳輸層之間增長了一個二進制分幀層。
在二進制分幀層中，HTTP/2.0會將全部傳輸的消息分割爲更小的消息和幀（frame），並採用二進制格式的編碼。

服務器推送：當對webServer請求數據時，服務器會順便把一些客戶端須要的資源一塊兒推到客戶端，省得客戶端再次建立鏈接請求。適合加載靜態資源。

升級配置：

Nginx從1.9版本開始支持HTTP/2.0,編譯模塊http_v2_module。http2.0協議須要使用https協議

HTTPS

HTTP: 應用層，不加密，80
HTTPS: 傳輸層，加密，443

這是一份全面& 詳細 HTTP知識講解

HTTP相關協議（一次完整的瀏覽器請求流程）

在瀏覽器輸入URL回車後，流程：

1. 域名解析

DNS解析 - 從域名解析到IP地址
搜索瀏覽器自身的DNS緩存 -- 系統緩存 -- 瀏覽器向本地配置的首選DNS服務器發起域名解析請求（經過UDP協議向DNS的53端口發起請求，DNS會遞歸請求，直到拿到IP）

1. 發起TCP三次握手

拿到域名對應的IP後，瀏覽器以一個隨機端口（1024 < < 65535）向服務器的web程序80端口發起TCP鏈接請求。

1. TCP鏈接後發起http請求
2. 服務器響應http請求，瀏覽器獲得html代碼
3. 瀏覽器解析html代碼，並請求html代碼中的資源（js、css、圖片等）
4. 瀏覽器對頁面進行渲染呈現給用戶

加入CDN後的訪問過程：

1. 用戶點擊URL被cname到CDN服務器的IP（全局負載均衡設備IP）（DNS解析）;
2. 用戶向該IP發起內容URL訪問請求；
3. 該全局負載均衡設備根據用戶IP請求內容，選擇一臺用戶所屬區域負載均衡設備。區域負載均衡設備根據 IP地址（判斷服務器距用戶最近）、內容、負載等，返回一臺緩存服務器的IP地址。
4. 用戶用返回的IP向緩存服務器發起請求。若是該緩存服務器上沒有會向上級請求，一直追溯到源服務器。

Cookie與Session

IP地址（IPV4IPV6）

Socket 套接字

一個編程調用接口（API），屬於傳輸層。
一個socket實例惟一表明一個主機上的一個應用程序的通訊鏈路。
成對出現：

Socket = {（IP地址1：PORT端口號），（IP地址2：PORT端口號）}

創建Socket鏈接過程：
客戶端：

1. 建立一個 Socket 實例
2. 操做系統將爲該 Socket 實例分配一個未被使用的本地端口號
3. 操做系統建立一個含 本地、遠程地址、端口號 的套接字數據結構。（系統一直保留該數據結構到鏈接關閉）
4. 在建立 Socket 實例的構造函數正確返回前，進行 TCP 的三次握手協議
5. TCP 握手協議完成後，Socket 實例對象將建立完成。（不然拋出 IOException 錯誤）

服務器：

1. 建立一個 ServerSocket 實例
2. 操做系統爲 ServerSocket 實例建立一個底層數據結構。（包含指定監聽的端口號、監聽地址的通配符[一般是 * ，表示監聽全部地址]）
3. 調用 accept() 方法時，將進入阻塞狀態，等待客戶端請求
4. 當一個新的請求到來時，將爲該鏈接建立一個新的套接字數據結構。（包含 請求原地址和端口，關聯到 ServerSocket 實例的一個未完成的鏈接數據結構列表中）
5. 三次握手完成後，該服務端Socket實例纔會返回，而且將該 Socket 實例對應的數據結構從未完成列表中移到已完成列表中

相關資料：
Socket使用攻略

Ping與ICMP

time_wait與close_wait

調試工具/方法

相關資源

計算機網絡基礎