一、前言

主要包括：1、http基礎(chǔ)：TCP/IP，TCP協(xié)議，IP協(xié)議，DNS協(xié)議，URI與URL；

2、http協(xié)議：http報(bào)文，http方法，http狀態(tài)碼，常見問題

名詞解釋：

（1）HTTP（HyperText Transfer Protocol）超文本傳輸協(xié)議

（2）URL（Uniform Resource Locator）統(tǒng)一資源定位符

（3）URI（Uniform Resource Identifer）統(tǒng)一資源標(biāo)識符

（4）TCP（Transmission Control Protocol）傳輸控制協(xié)議

（5）IP（Internet Protocol）網(wǎng)際協(xié)議

（6）UDP（User Data Protocol）用戶數(shù)據(jù)報(bào)協(xié)議

（7）MAC地址（Media Access Control）媒體訪問控制地址／物理地址／硬件地址

（8）ARP協(xié)議（Address Resolution Protocol）地址解析協(xié)議

二、HTTP基礎(chǔ)

2.1TCP/IP

TCP/IP是互聯(lián)網(wǎng)相關(guān)的各類協(xié)議族的總稱，而http是TCP/IP協(xié)議族中的一個(gè)子集。

TCP/IP協(xié)議族可以分為四層：

（1）應(yīng)用層：決定向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)，TCP/IP協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)，如：http，ftp，dns等。

（2）傳輸層：提供處于網(wǎng)絡(luò)連接中的兩臺計(jì)算機(jī)之間的數(shù)據(jù)傳輸，包含兩個(gè)協(xié)議：tcp，udp。

（3）網(wǎng)絡(luò)層：用來處理網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包，在眾多的選項(xiàng)中選擇一條傳輸線路，將數(shù)據(jù)包傳送到對方計(jì)算機(jī)。包含的協(xié)議：IP協(xié)議。

（4）數(shù)據(jù)鏈路層：用來處理連接網(wǎng)絡(luò)的硬件部分。

2.2 IP協(xié)議

IP協(xié)議屬于網(wǎng)絡(luò)層，負(fù)責(zé)處理網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包。為了保證傳送成功，需要滿足各類條件，其中兩個(gè)重要的條件時(shí)IP地址和MAC地址。

（1）IP地址，指明了節(jié)點(diǎn)被分配到的地址；

（2）MAC地址，指網(wǎng)卡所屬的固定地址；

（3）IP地址可以和MAC地址進(jìn)行配對，IP地址可以變換，但是MAC地址基本上不會(huì)更改；

（4）使用ARP地址解析協(xié)議可以根據(jù)通信方的IP地址反查出對應(yīng)的MAC地址

2.3 TCP協(xié)議

TCP協(xié)議位于傳輸層，提供可靠的字節(jié)流服務(wù)（也就是說，將大數(shù)據(jù)分隔成以報(bào)文段為單位的數(shù)據(jù)包進(jìn)行管理）。

為了確保數(shù)據(jù)準(zhǔn)確無誤的到達(dá)目標(biāo)處，TCP協(xié)議通常采用三次握手策略。

image

如果在握手的過程中某一個(gè)階段莫名的中斷了，TCP協(xié)議會(huì)再次以相同的順序發(fā)送相同的數(shù)據(jù)包。

2.4DNS協(xié)議

DNS協(xié)議位于應(yīng)用層，提供域名到IP地址之間的解析服務(wù)。

2.5 URI和URL

URI是某一個(gè)協(xié)議方案表示的資源的定位標(biāo)識符，協(xié)議方案是指訪問資源所使用的協(xié)議類型，如：http，ftp，file等。

URL用字符串標(biāo)識某一個(gè)互聯(lián)網(wǎng)資源，而URL表示資源的地點(diǎn)，URL是URI的子集。

2.6 HTTP協(xié)議

HTTP協(xié)議用于客戶端和服務(wù)器端之間的通信。請求必定由客戶端發(fā)出，而服務(wù)器端回復(fù)響應(yīng)。

HTTP協(xié)議不保存狀態(tài)，為無狀態(tài)協(xié)議。這是為了更快的處理大量事務(wù)，確保協(xié)議的可伸縮性而特意設(shè)計(jì)的。

但是隨著Web的不斷發(fā)展，這一特性也引發(fā)了一些問題，如：如何保持登錄狀態(tài)、如何記錄用戶信息等，為了解決這一問題，引入了Cookie技術(shù)。

2.6.1常見狀態(tài)碼

2XX 成功

200 OK，表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理

204 No content，表示請求成功，但響應(yīng)報(bào)文不含實(shí)體的主體部分

205 Reset Content，表示請求成功，但響應(yīng)報(bào)文不含實(shí)體的主體部分，但是與 204 響應(yīng)不同在于要求請求方重置內(nèi)容

206 Partial Content，進(jìn)行范圍請求

3XX 重定向

301 moved permanently，永久性重定向，表示資源已被分配了新的 URL

302 found，臨時(shí)性重定向，表示資源臨時(shí)被分配了新的 URL

303 see other，表示資源存在著另一個(gè) URL，應(yīng)使用 GET 方法獲取資源

304 not modified，表示服務(wù)器允許訪問資源，但因發(fā)生請求未滿足條件的情況

307 temporary redirect，臨時(shí)重定向，和302含義類似，但是期望客戶端保持請求方法不變向新的地址發(fā)出請求

4XX 客戶端錯(cuò)誤

400 bad request，請求報(bào)文存在語法錯(cuò)誤

401 unauthorized，表示發(fā)送的請求需要有通過 HTTP 認(rèn)證的認(rèn)證信息

403 forbidden，表示對請求資源的訪問被服務(wù)器拒絕

404 not found，表示在服務(wù)器上沒有找到請求的資源

5XX 服務(wù)器錯(cuò)誤

500 internal sever error，表示服務(wù)器端在執(zhí)行請求時(shí)發(fā)生了錯(cuò)誤

501 Not Implemented，表示服務(wù)器不支持當(dāng)前請求所需要的某個(gè)功能

503 service unavailable，表明服務(wù)器暫時(shí)處于超負(fù)載或正在停機(jī)維護(hù)，無法處理請求

2.6.2HTTP報(bào)文頭部（HTTP首部）

| 通用字段 | ** 作用** |
| Cache-Control | 控制緩存的行為 |
| Connection | 瀏覽器想要優(yōu)先使用的連接類型，比如：keep-alive |
| Date | 創(chuàng)建報(bào)文時(shí)間 |
| Pragma | 報(bào)文指令 |
| Via | 代理服務(wù)器相關(guān)信息 |
| Transfer-Encoding | 傳輸編碼方式 |
| Upgrade | 要求客戶端升級協(xié)議 |
| Warning | 在內(nèi)容中可能存在錯(cuò)誤 |

| ** 請求字段** | ** 作用** |
| Accept | 能正確接收的媒體類型 |
| Accept-Charset | 能正確接收的字符集 |
| Accept-Encoding | 能正確接收的編碼格式列表 |
| Accept-Language | 能正確接收的語言列表 |
| Expect | 期待服務(wù)端的指定行為 |
| From | 請求方郵箱地址 |
| Host | 服務(wù)器的域名 |
| If-Match | 兩端資源標(biāo)記比較 |
| If-Modified-Since | 本地資源未修改返回 304（比較時(shí)間） |
| If-None-Match | 本地資源未修改返回 304（比較標(biāo)記） |
| User-Agent | 客戶端信息 |
| Max-Forwards | 限制可被代理及網(wǎng)關(guān)轉(zhuǎn)發(fā)的次數(shù) |
| Proxy-Authorization | 向代理服務(wù)器發(fā)送驗(yàn)證信息 |
| Range | 請求某個(gè)內(nèi)容的一部分 |

| Referer | 示瀏覽器所訪問的前一個(gè)頁面 |
| TE | 傳輸編碼方式 |

| 響應(yīng)字段 | 作用 |
| Accept-Ranges | 是否支持某些種類的范圍 |
| Age | 資源在代理緩存中存在的時(shí)間 |
| ETag | 資源標(biāo)識 |
| Location | 客戶端重定向到某個(gè) URL |
| Proxy-Authenticate | 向代理服務(wù)器發(fā)送驗(yàn)證信息 |
| Server | 服務(wù)器名字 |
| WWW-Authenticate | 獲取資源需要的驗(yàn)證信息 |

| 實(shí)體字段 | 作用 |
| Allow | 資源的正確請求方式 |
| Content-Encoding | 內(nèi)容的編碼格式 |
| Content-Language | 內(nèi)容使用的語言 |
| Content-Length | request body 長度 |
| Content-Location | 返回?cái)?shù)據(jù)的備用地址 |
| Content-MD5 | Base64加密格式的內(nèi)容 MD5檢驗(yàn)值 |
| Content-Range | 內(nèi)容的位置范圍 |
| Content-Type | 內(nèi)容的媒體類型 |
| Expires | 內(nèi)容的過期時(shí)間 |
| Last_modified | 內(nèi)容的最后修改時(shí)間 |

2.6.3 HTTP方法

三****、HTTPS基礎(chǔ)

HTTPS 還是通過了 HTTP 來傳輸信息，但是信息通過 TLS 協(xié)議進(jìn)行了加密。

3.1 TLS

TLS 協(xié)議位于傳輸層之上，應(yīng)用層之下。首次進(jìn)行 TLS 協(xié)議傳輸需要兩個(gè) RTT ，接下來可以通過 Session Resumption 減少到一個(gè) RTT。（RTT表示發(fā)送端發(fā)送數(shù)據(jù)到接收到對端數(shù)據(jù)所需的往返時(shí)間）

在 TLS 中使用了兩種加密技術(shù)，分別為：對稱加密和非對稱加密。

對稱加密：

對稱加密就是兩邊擁有相同的秘鑰，兩邊都知道如何將密文加密解密。

非對稱加密：

有公鑰私鑰之分，公鑰所有人都可以知道，可以將數(shù)據(jù)用公鑰加密，但是將數(shù)據(jù)解密必須使用私鑰解密，私鑰只有分發(fā)公鑰的一方才知道。

3.2 TLS 握手過程如下圖：

image

（1）客戶端發(fā)送一個(gè)隨機(jī)值，需要的協(xié)議和加密方式

（2）服務(wù)端收到客戶端的隨機(jī)值，自己也產(chǎn)生一個(gè)隨機(jī)值，并根據(jù)客戶端需求的協(xié)議和加密方式來使用對應(yīng)的方式，發(fā)送自己的證書（如果需要驗(yàn)證客戶端證書需要說明）

（3）客戶端收到服務(wù)端的證書并驗(yàn)證是否有效，驗(yàn)證通過會(huì)再生成一個(gè)隨機(jī)值，通過服務(wù)端證書的公鑰去加密這個(gè)隨機(jī)值并發(fā)送給服務(wù)端，如果服務(wù)端需要驗(yàn)證客戶端證書的話會(huì)附帶證書

（4）服務(wù)端收到加密過的隨機(jī)值并使用私鑰解密獲得第三個(gè)隨機(jī)值，這時(shí)候兩端都擁有了三個(gè)隨機(jī)值，可以通過這三個(gè)隨機(jī)值按照之前約定的加密方式生成密鑰，接下來的通信就可以通過該密鑰來加密解密

通過以上步驟可知，在 TLS 握手階段，兩端使用非對稱加密的方式來通信，但是因?yàn)榉菍ΨQ加密損耗的性能比對稱加密大，所以在正式傳輸數(shù)據(jù)時(shí)，兩端使用對稱加密的方式通信。

PS：以上說明的都是 TLS 1.2 協(xié)議的握手情況，在 1.3 協(xié)議中，首次建立連接只需要一個(gè) RTT，后面恢復(fù)連接不需要 RTT 了。

四、GET和POST的區(qū)別

從技術(shù)上說：

1、get請求能緩存，post不能；

2、post相對于get來說，安全一點(diǎn)點(diǎn)，因?yàn)間et請求都會(huì)包含在URL里，會(huì)被瀏覽器保存歷史記錄，post不會(huì)，但是在抓包的情況是一樣的。

3、post可以request body來傳遞比get更多的數(shù)據(jù)，get米有這個(gè)技術(shù)。

4、url長度有限制，會(huì)影響get請求，長度限制是瀏覽器限制規(guī)定的，不是rfc（互聯(lián)網(wǎng)通信協(xié)議）規(guī)定的。

5、post支持更多的編碼類型且不對數(shù)據(jù)類型限制