在許多大公司的面試中，經(jīng)常會重點(diǎn)考察面試者的計(jì)算機(jī)基礎(chǔ)知識。所以對于在計(jì)算機(jī)網(wǎng)絡(luò)、數(shù)據(jù)結(jié)構(gòu)、操作系統(tǒng)上花費(fèi)更多的時(shí)間和精力，是完全值得的。HTTP 作為應(yīng)用最為廣泛的網(wǎng)絡(luò)協(xié)議，不論前端和后端都需要經(jīng)常接觸。最近決定對 HTTP 進(jìn)行了一些學(xué)習(xí)，所以整理一份筆記并分享給大家。

HTTP (HyperText Transfer Protocol) 通常被我們稱為超文本傳輸協(xié)議，又譯為超文本轉(zhuǎn)移協(xié)議。它的命名如何，不需要過于糾結(jié)，我們更應(yīng)該重視它的內(nèi)容。

HTTP 與 TCP/IP

OSI 模型與 TCP/IP 模型對比

OSITCP/IP

應(yīng)用層 表示層 會話層	應(yīng)用層
傳輸層	傳輸層
網(wǎng)絡(luò)層	網(wǎng)絡(luò)層
數(shù)據(jù)鏈路層 物理層	鏈路層

TCP/IP 四層模型分析

HTTP 是 TCP/IP 協(xié)議內(nèi)部的一個(gè)子集，在了解它之前我們需要先了解一下 TCP/IP 相關(guān)的知識。TCP/IP（Transmission Control Protocol/Internet Protocol）協(xié)議分為應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈路層四層，我簡單的來總結(jié)舉例一下。

應(yīng)用層

應(yīng)用層向用戶提供一系列的應(yīng)用服務(wù)。
比如我們熟悉的 DNS（Domain Name Service，域名解析）、FTP（File Transfer Protocol，文件傳輸協(xié)議），當(dāng)然還有我們要講的 HTTP 協(xié)議。
有時(shí)在 App Store 無法下載應(yīng)用時(shí)，就經(jīng)常會把 DNS 設(shè)置為谷歌的 8.8.8.8 或者國內(nèi)的 114.114.114.114，這些都是比較常見的服務(wù)。

傳輸層

傳輸層提供連接兩臺計(jì)算機(jī)之間的數(shù)據(jù)傳輸。
傳輸層有兩種協(xié)議： TCP（Transmission Control Protocol，傳輸控制協(xié)議） UDP（User Datagram protocol，用戶數(shù)據(jù)報(bào)協(xié)議）

網(wǎng)絡(luò)層

網(wǎng)絡(luò)層規(guī)定了通過什么樣的方式將數(shù)據(jù)包傳遞給對方。 網(wǎng)絡(luò)層協(xié)議的代表包括： IP（Internet Protocol，互聯(lián)網(wǎng)協(xié)議）
ICMP（Internet Control Message Protocol，互聯(lián)網(wǎng)消息控制協(xié)議）

因?yàn)?IP 并不是完全可靠，無法保證數(shù)據(jù)被送達(dá)。所以需要 ICMP 傳輸出錯(cuò)報(bào)告控制信息。ICMP 最著名的應(yīng)用應(yīng)該就是 ping 了，比如我們上不去某個(gè)網(wǎng)站，就可以在終端輸入測試一下。

ping www.baidu.com // 然后就可以看到一些返回值 PING www.a.shifen.com (180.149.132.151): 56 data bytes 64 bytes from 180.149.132.151: icmp_seq=0 ttl=55 time=31.431 ms Request timeout for icmp_seq 1 64 bytes from 180.149.132.151: icmp_seq=2 ttl=55 time=30.530 ms 64 bytes from 180.149.132.151: icmp_seq=3 ttl=55 time=30.233 ms 復(fù)制代碼

鏈路層

鏈路層用來鏈接網(wǎng)絡(luò)的硬件部分。
網(wǎng)絡(luò)層傳過來的數(shù)據(jù)在這里被加工成了可被物理層傳輸?shù)慕Y(jié)構(gòu)包——幀。幀中包括 MAC 地址（Media Access Control）和一些其他信息。放一幅在網(wǎng)上找的圖給大家展示一下。

一個(gè)訪問百度網(wǎng)站的例子

在瀏覽器輸入 http://www.baidu.com。

DNS 通過你輸入的地址，找到百度的 IP 地址 14.215.177.38。

通過 ARP 協(xié)議尋找 MAC 地址，建立 TCP 連接。

三次握手

• 發(fā)送端：發(fā)送帶有 SYN 的數(shù)據(jù)包
• 接收端：應(yīng)答，發(fā)送帶有 SYN/ACK 的數(shù)據(jù)包
• 發(fā)送端：應(yīng)答，發(fā)送帶有 ACK 的數(shù)據(jù)包

通過返回的數(shù)據(jù)包顯示網(wǎng)頁

這個(gè)例子簡單總結(jié)一下，深入的話也寫不完（攤手）。

常見的 HTTP 方法

方法說明

GET	獲取資源
POST	傳輸實(shí)體主體
PUT	傳輸替換目標(biāo)資源
DELETE	刪除目標(biāo)資源
HEAD	獲取報(bào)文首部
OPTIONS	獲取支持的方法

常見方法分析

GET 與 POST 的區(qū)別

這也算是面試比較常問的問題了，這里放上一個(gè)表格。

GETPOST

后退按鈕/刷新	無害	數(shù)據(jù)會被重新提交（瀏覽器會提示）
書簽/緩存/歷史	√	X
編碼類型	application/x-www-form-urlencoded	application/x-www-form-urlencoded 或 multipart/form-data。為二進(jìn)制數(shù)據(jù)使用多重編碼
數(shù)據(jù)長度限制	URL 的最大長度是 2048 個(gè)字符	無限制
數(shù)據(jù)類型限制	只允許 ASCII 字符	無限制
可見性	數(shù)據(jù)在 URL 中對所有人可見、請求會保存在歷史記錄	數(shù)據(jù)保存在主體中、請求不會保存在歷史記錄

PUT 請求

PUT?與?POST 方法的區(qū)別在于，PUT方法是冪等的：調(diào)用一次與連續(xù)調(diào)用多次是等價(jià)的（即沒有副作用），而連續(xù)調(diào)用多次POST方法可能會有副作用，比如將一個(gè)訂單重復(fù)提交多次。

DELETE 請求

如果?DELETE方法成功執(zhí)行，那么可能會有以下幾種狀態(tài)碼：

• 狀態(tài)碼 ?202?(Accepted) 表示請求的操作可能會成功執(zhí)行，但是尚未開始執(zhí)行。
• 狀態(tài)碼?204?(No Content) 表示操作已執(zhí)行，但是無進(jìn)一步的相關(guān)信息。
• 狀態(tài)碼 ?200?(OK) 表示操作已執(zhí)行，并且響應(yīng)中提供了相關(guān)狀態(tài)的描述信息。

HEAD 請求

HEAD 請求就如同前面表格所說的是獲取報(bào)文首部，該請求方法的一個(gè)使用場景是在下載一個(gè)大文件前先獲取其大小再?zèng)Q定是否要下載, 以此可以節(jié)約帶寬資源。

OPTIONS 請求

OPTIONS 請求就是用于獲取目的資源所支持的通信選項(xiàng)，平時(shí)在做 ionic、Angular 的時(shí)候，它就經(jīng)常會在請求前自動(dòng)調(diào)用一個(gè) OPTIONS 方法。

HTTP 狀態(tài)碼

簡單的說，HTTP 狀態(tài)碼就是描述返回的請求結(jié)果。 這里還是拿一個(gè)表格展示一下，由于種類比較多，所以只列舉種類，不進(jìn)行完全列舉。

類別原因

1xx	Informational（信息性狀態(tài)碼）	接收的請求正在處理
2xx	Success（成功狀態(tài)碼）	請求正常處理完畢
3xx	Redirection（重定向狀態(tài)碼）	需要進(jìn)行附加操作以完成請求
4xx	Client Error（客戶端錯(cuò)誤狀態(tài)碼）	服務(wù)器無法處理請求
5xx	Server Error（服務(wù)端錯(cuò)誤狀態(tài)碼）	服務(wù)器處理請求出錯(cuò)

HTTP 報(bào)文首部字段

HTTP 報(bào)文的首部字段，主要是用來傳遞額外的重要信息。

一個(gè)簡單的請求例子

前面講了這么多，這里結(jié)合請求方法、狀態(tài)碼等舉一個(gè)例子。

發(fā)起請求：

GET / HTTP/1.1 Request URL: https://www.baidu.com/favicon.ico Host: www.baidu.com Accept-Language: zh-CN 復(fù)制代碼

服務(wù)端返回：

HTTP/1.1 200 OK Date: Sat, 07 Apr 2018 02:17:48 GMT Server: Apache Last-Modified: Mon, 02 Apr 2018 09:39:34 GMT Accept-Ranges: bytes Content-Length: 984 Content-Type: image/x-icon 復(fù)制代碼

現(xiàn)在我們分析一下這個(gè)例子。

發(fā)起請求

// 請求方法 / HTTP 版本號 GET / HTTP/1.1 // 請求地址 Request URL: https://www.baidu.com/favicon.ico // 請求資源所在服務(wù)器 Host: www.baidu.com // 優(yōu)先選擇的語言（自然語言） Accept-Language: zh-CN 復(fù)制代碼

服務(wù)端返回

// HTTP 版本、HTTP 狀態(tài)碼 200 HTTP/1.1 200 OK // 創(chuàng)建報(bào)文的日期 Date: Sat, 07 Apr 2018 02:17:48 GMT // HTTP 服務(wù)器的安裝信息 Server: Apache // 資源的最后修改時(shí)間 Last-Modified: Mon, 02 Apr 2018 09:39:34 GMT // 支持字節(jié)范圍請求 Accept-Ranges: bytes // 實(shí)體主體的大小 Content-Length: 984 // 實(shí)體主體的類型 Content-Type: image/x-icon 復(fù)制代碼

HTTP 首部字段種類非常多，該例子舉例了常用的一部分，想了解更多可以研究 MDN HTTP Headers 文檔 。

目前里面中文翻譯不夠完整，翻譯水平高的朋友可以點(diǎn)擊幫忙完善一下，為開源事業(yè)出一份力：)

這次就總結(jié)到這里了，由于水平有限，難免有些許紕漏。有什么錯(cuò)誤請指出，不勝感激。

參考文章

為何HTTP被翻譯為“超文本傳輸協(xié)議”是一次歷史上的重大翻譯錯(cuò)誤？ HTTP 協(xié)議入門-阮一峰 TCP/IP 協(xié)議 百度百科 ping 原理與ICMP協(xié)議 漫談網(wǎng)絡(luò)通信——從OSI網(wǎng)絡(luò)模型到TCP/IP協(xié)議族 HTTP 方法-w3school HTTP 請求方法-MDN 《圖解HTTP》

總結(jié)

以上是生活随笔為你收集整理的HTTP 协议知识点总结（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。