計算機基礎--http的基礎整理和鞏固

1、前言

主要包括：一、http基礎：TCP/IP，TCP協議，IP協議，DNS協議，URI與URL；

二、http協議：http報文，http方法，http狀態碼，常見問題

名詞解釋：

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

（2）URL（Uniform Resource Locator）統一資源定位符

（3）URI（Uniform Resource Identifer）統一資源標識符

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

（5）IP（Internet Protocol）網際協議

（6）UDP（User Data Protocol）用戶數據報協議

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

（8）ARP協議（Address Resolution Protocol）地址解析協議

 

2、HTTP基礎

2.1TCP/IP

TCP/IP是互聯網相關的各種協議族的總稱，而http是TCP/IP協議族中的一個子集。

TCP/IP協議族能夠分爲四層：

（1）應用層：決定向用戶提供應用服務時通訊的活動，TCP/IP協議族內預存了各種通用的應用服務，如：http，ftp，dns等。

（2）傳輸層：提供處於網絡鏈接中的兩臺計算機之間的數據傳輸，包含兩個協議：tcp，udp。

（3）網絡層：用來處理網絡上流動的數據包，在衆多的選項中選擇一條傳輸線路，將數據包傳送到對方計算機。包含的協議：IP協議。

（4）數據鏈路層：用來處理鏈接網絡的硬件部分。

 

2.2 IP協議

IP協議屬於網絡層，負責處理網絡上流動的數據包。爲了保證傳送成功，須要知足各種條件，其中兩個重要的條件時IP地址和MAC地址。

（1）IP地址，指明瞭節點被分配到的地址；

（2）MAC地址，指網卡所屬的固定地址；

（3）IP地址能夠和MAC地址進行配對，IP地址能夠變換，可是MAC地址基本上不會更改；

（4）使用ARP地址解析協議能夠根據通訊方的IP地址反查出對應的MAC地址

 

2.3 TCP協議

TCP協議位於傳輸層，提供可靠的字節流服務（也就是說，將大數據分隔成以報文段爲單位的數據包進行管理）。

爲了確保數據準確無誤的到達目標處，TCP協議一般採用三次握手策略。

若是在握手的過程當中某一個階段莫名的中斷了，TCP協議會再次以相同的順序發送相同的數據包。

 

2.4DNS協議

DNS協議位於應用層，提供域名到IP地址之間的解析服務。

 

2.5 URI和URL

URI是某一個協議方案表示的資源的定位標識符，協議方案是指訪問資源所使用的協議類型，如：http，ftp，file等。

URL用字符串標識某一個互聯網資源，而URL表示資源的地點，URL是URI的子集。

 

2.6 HTTP協議

HTTP協議用於客戶端和服務器端之間的通訊。請求一定由客戶端發出，而服務器端回覆響應。

HTTP協議不保存狀態，爲無狀態協議。這是爲了更快的處理大量事務，確保協議的可伸縮性而特地設計的。

可是隨着Web的不斷髮展，這一特性也引起了一些問題，如：如何保持登陸狀態、如何記錄用戶信息等，爲了解決這一問題，引入了Cookie技術。

2.6.1常見狀態碼

2XX 成功

200 OK，表示從客戶端發來的請求在服務器端被正確處理

204 No content，表示請求成功，但響應報文不含實體的主體部分

205 Reset Content，表示請求成功，但響應報文不含實體的主體部分，可是與 204 響應不一樣在於要求請求方重置內容

206 Partial Content，進行範圍請求

3XX 重定向

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

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

303 see other，表示資源存在着另外一個 URL，應使用 GET 方法獲取資源

304 not modified，表示服務器容許訪問資源，但因發生請求未知足條件的狀況

307 temporary redirect，臨時重定向，和302含義相似，可是指望客戶端保持請求方法不變向新的地址發出請求

4XX 客戶端錯誤

400 bad request，請求報文存在語法錯誤

401 unauthorized，表示發送的請求須要有經過 HTTP 認證的認證信息

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

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

5XX 服務器錯誤

500 internal sever error，表示服務器端在執行請求時發生了錯誤

501 Not Implemented，表示服務器不支持當前請求所須要的某個功能

503 service unavailable，代表服務器暫時處於超負載或正在停機維護，沒法處理請求

 

2.6.2HTTP報文頭部（HTTP首部）

通用字段	做用
Cache-Control	控制緩存的行爲
Connection	瀏覽器想要優先使用的鏈接類型，好比：keep-alive
Date	建立報文時間
Pragma	報文指令
Via	代理服務器相關信息
Transfer-Encoding	傳輸編碼方式
Upgrade	要求客戶端升級協議
Warning	在內容中可能存在錯誤

 

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

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

響應字段	做用
Accept-Ranges	是否支持某些種類的範圍
Age	資源在代理緩存中存在的時間
ETag	資源標識
Location	客戶端重定向到某個 URL
Proxy-Authenticate	向代理服務器發送驗證信息
Server	服務器名字
WWW-Authenticate	獲取資源須要的驗證信息

 

實體字段	做用
Allow	資源的正確請求方式
Content-Encoding	內容的編碼格式
Content-Language	內容使用的語言
Content-Length	request body 長度
Content-Location	返回數據的備用地址
Content-MD5	Base64加密格式的內容 MD5檢驗值
Content-Range	內容的位置範圍
Content-Type	內容的媒體類型
Expires	內容的過時時間
Last_modified	內容的最後修改時間

 

2.6.3 HTTP方法

方法名稱	方法描述
GET	獲取資源
POST	傳輸實體主體
PUT	傳輸文件，自身不帶驗證機制 ，在無驗證機制或不遵照REST標準時不建議使用
DELETE	刪除文件，自身不帶驗證機制
HEAD	獲取報文首部，和GET方法同樣，不返回報文主體部分
OPTIONS	詢問支持的方法，返回服務器所支持的方法
TRACE	追蹤路徑，能夠經過該方法查詢發送出去的請求是如何被加工修改或篡改的。容易引起XST攻擊，不經常使用。
CONNECT	要求用隧道協議鏈接代理

 

三、HTTPS基礎

HTTPS 仍是經過了 HTTP 來傳輸信息，可是信息經過 TLS 協議進行了加密。

3.1 TLS

TLS 協議位於傳輸層之上，應用層之下。首次進行 TLS 協議傳輸須要兩個 RTT ，接下來能夠經過 Session Resumption 減小到一個 RTT。（RTT表示發送端發送數據到接收到對端數據所需的往返時間）

在 TLS 中使用了兩種加密技術，分別爲：對稱加密和非對稱加密。

對稱加密：

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

非對稱加密：

有公鑰私鑰之分，公鑰全部人均可以知道，能夠將數據用公鑰加密，可是將數據解密必須使用私鑰解密，私鑰只有分發公鑰的一方纔知道。

 

3.2 TLS 握手過程以下圖：

（1）客戶端發送一個隨機值，須要的協議和加密方式

（2）服務端收到客戶端的隨機值，本身也產生一個隨機值，並根據客戶端需求的協議和加密方式來使用對應的方式，發送本身的證書（若是須要驗證客戶端證書須要說明）

（3）客戶端收到服務端的證書並驗證是否有效，驗證經過會再生成一個隨機值，經過服務端證書的公鑰去加密這個隨機值併發送給服務端，若是服務端須要驗證客戶端證書的話會附帶證書

（4）服務端收到加密過的隨機值並使用私鑰解密得到第三個隨機值，這時候兩端都擁有了三個隨機值，能夠經過這三個隨機值按照以前約定的加密方式生成密鑰，接下來的通訊就能夠經過該密鑰來加密解密

經過以上步驟可知，在 TLS 握手階段，兩端使用非對稱加密的方式來通訊，可是由於非對稱加密損耗的性能比對稱加密大，因此在正式傳輸數據時，兩端使用對稱加密的方式通訊。

PS：以上說明的都是 TLS 1.2 協議的握手狀況，在 1.3 協議中，首次創建鏈接只須要一個 RTT，後面恢復鏈接不須要 RTT 了。

 

4、GET和POST的區別

從技術上說：

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

二、post相對於get來講，安全一點點，由於get請求都會包含在URL裏，會被瀏覽器保存歷史記錄，post不會，可是在抓包的狀況是同樣的。

三、post能夠request body來傳遞比get更多的數據，get米有這個技術。

四、url長度有限制，會影響get請求，長度限制是瀏覽器限制規定的，不是rfc（互聯網通訊協議）規定的。

五、post支持更多的編碼類型且不對數據類型限制

 

5、參考

一、https://github.com/junruchen/junruchen.github.io/wiki/HTTP-%E5%9F%BA%E7%A1%80%E6%95%B4%E7%90%86#http-text

二、http://www.javashuo.com/article/p-fjendckw-dt.html