一文吃透Http協(xié)議

這篇具有很好參考價值的文章主要介紹了一文吃透Http協(xié)議。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點(diǎn)擊"舉報違法"按鈕提交疑問。

1. 初始 Http

Http 協(xié)議 , 是應(yīng)用層最為廣泛使用的協(xié)議 , Http 就是瀏覽器和服務(wù)器之間的橋梁. Http 是基于 TCP 協(xié)議實(shí)現(xiàn)的 ,

一文吃透Http協(xié)議

通常我們輸入搜索框中的網(wǎng)址 (URL) , 瀏覽器就會根據(jù)這個 URL 構(gòu)造出一個 Http 請求 , 發(fā)送給服務(wù)器. 服務(wù)器就會返回一個 Http 響應(yīng)(包含 html, css , js) , 瀏覽器再把得到的 html 等數(shù)據(jù)顯示出來(渲染) , 這也就是為什么 http 被稱為超文本傳輸協(xié)議 , 因?yàn)閭鬏數(shù)牟粌H僅是文本.

一文吃透Http協(xié)議

2. fiddler 抓包

http 協(xié)議的詳細(xì)交互過程 , 可以借助第三方工具 fiddler , 來抓包.

fiddler 本質(zhì)是一個代理程序 , 使用時注意事項(xiàng):

可能和別的代理程序沖突 , 使用時要關(guān)閉其他的代理程序(包括一些瀏覽器插件)
想要正確抓包還需開啟 htpps 功能 , 當(dāng)前互聯(lián)網(wǎng)絕大多數(shù)服務(wù)器都是 https 的 , fiddler 默認(rèn)不能抓 https 的包 , 需要手動啟動 https 并安裝證書.

打開 csdn , fiddler 會抓取很多的請求 , 通常藍(lán)色是 html 主頁 , 綠色是 , 黑色是單純的返回數(shù)據(jù). 瀏覽器再解釋執(zhí)行 html 和 js 的時候 , 遇到一個請求就發(fā)送一個.

一文吃透Http協(xié)議

http 請求 , 有一定的格式. fiddler 會按照格式解析 , 會呈現(xiàn)出不同的效果 , 點(diǎn)擊raw就可以看到最原始的效果. view in Notepad 可以看到更詳細(xì)的頁面.
一文吃透Http協(xié)議

一文吃透Http協(xié)議

觀察抓包結(jié)果 , 可以看到 , 當(dāng)前 http 請求 , 其實(shí)是個行文本格式的數(shù)據(jù).

響應(yīng)數(shù)據(jù)本來也是文本 , 但有的服務(wù)器會對響應(yīng)進(jìn)行壓縮.( 為了節(jié)省帶寬)

一文吃透Http協(xié)議

手動解壓縮之后 , 我們就可以看到 csdn 主頁的文本數(shù)據(jù) , 也就是 html 的內(nèi)容.

一文吃透Http協(xié)議

3. Http 報文格式

學(xué)習(xí)一個協(xié)議 , 本質(zhì)上就是了解它的報文格式.

1. Http 請求

http 請求可以分為 4 部分:

首行
請求頭(header)
空行
正文(body)

首行

一文吃透Http協(xié)議

首行包含三個部分. 之間使用空格來區(qū)分.

GET: http 的方法(method)
URL: 也就是唯一資源定位符. 標(biāo)識互聯(lián)網(wǎng)上唯一資源的位置(在哪個服務(wù)器的哪個目錄下的哪個文件) , URI 唯一資源標(biāo)識符 , 為了和別的資源區(qū)分開. 實(shí)際上 URL 也可以視為是一個 URI. 開發(fā)中常常混用. URL 不是 http 專屬的. 很多協(xié)議都可以使用 URL.
版本號: HTTP/1.1

認(rèn)識URL

一文吃透Http協(xié)議

舉個例子: 假設(shè)我在學(xué)校餐廳租了一個檔口賣重慶小面

一文吃透Http協(xié)議

一個 URL 有些部分是可以省略的:

例如:

端口號可以省略 , 瀏覽器提供默認(rèn)端口. 對于 http 來說默認(rèn)端口是 80 , 對于 https 來說默認(rèn)端口是 443.
/ 代表 http 服務(wù)器的根目錄 , http 服務(wù)器是系統(tǒng)上的一個進(jìn)程. 于是委托這個服務(wù)器管理系統(tǒng)上的一個特定目錄 , 這個目錄里的資源都可以讓外界進(jìn)行訪問.(服務(wù)器管理的根目錄 , 可以是系統(tǒng)上任意一個地方 , 具體根據(jù)服務(wù)器配置)
查詢字符串也是可有可無 .

查詢字符串以 ? 開頭 , 以鍵值對的形式組織 , 鍵值之間用**&分割 , 鍵和值之間用=**分割. 有時 URL 有些字符是由特點(diǎn)含義的 , 就需要對內(nèi)容重新編碼 , 通常使用urlencode(轉(zhuǎn)義字符) , 如果不編碼直接寫中文 , 瀏覽器可能無法識別.

認(rèn)識方法(Method)

一文吃透Http協(xié)議

實(shí)際開發(fā)中 , 這里的方法 , 大部分都是用不到的. 最常見的就是 GET 和 POST.

GET 觸發(fā)場景:

在瀏覽器地址欄直接輸入 URL
html 里的 link , script , img , a…等標(biāo)簽
通過 js 來構(gòu)造 get 請求.

GET 與 POST 的區(qū)別:

如果是 GET 請求 , 沒有 body. POST 請求, 有 body. POST 的 body 中是程序員自定義的內(nèi)容.
GET 給服務(wù)器傳遞消息一般存放在 quert string , POST 傳遞消息則是通過 body.
GET 請求一般從服務(wù)器獲取數(shù)據(jù) , POST 一般是用于給服務(wù)器提交數(shù)據(jù).
GET 通常情況下是冪等的 , POST 則不做要求.(相同的輸入 , 結(jié)果也是確定的 )
GET 可以被緩存 , POST 則一般不能被緩存.(緩存的前提是冪等)

實(shí)際上GET 與 POST 的區(qū)別只是一個習(xí)慣用法 , 很多場景下彼此都可以替換.

認(rèn)識 header

一文吃透Http協(xié)議

header 里的鍵值對都是 http 事先定義好的 , 有特定含義.

HOST: 描述了服務(wù)器所在的地址和端口 , 用來描述你最終要訪問的目標(biāo) , 通常情況下內(nèi)容和 URL一樣.
Content-Length: 表示 body 中的數(shù)據(jù)長度.

一文吃透Http協(xié)議

Content-type: 表示請求的 body 中的數(shù)據(jù)格式. 常見的格式有 json 和 form等.

一文吃透Http協(xié)議

User-Agent (簡稱 UA)

一文吃透Http協(xié)議

描述了瀏覽器和操作系統(tǒng)的版本 , 早起瀏覽器只支持文本 , 后來支持各種圖片 , 音頻, js … 對于網(wǎng)站開發(fā)者來說 , 開發(fā)網(wǎng)頁時是否支持這些新功能是個問題 , 后來提出解決辦法 , 那就是發(fā)布不同的版本來適用各種瀏覽器 , 根據(jù) User-Agent 就可以解決這個問題 , 后來瀏覽器的差別小了 , User-Agent 主要用來區(qū)分是移動端還是PC 端.

Refer: 表示當(dāng)前頁面"來源" , 如果直接在地址欄搜索 , 收藏夾等 , 則沒有Refer.

一文吃透Http協(xié)議

廣告計費(fèi)服務(wù) , 廣告主的頁面會有許多其他網(wǎng)站轉(zhuǎn)過來 , 為了更好的結(jié)算計費(fèi) , 廣告主只需通過 refer 記錄日志即可. 但是 http 本身明文傳輸 , 會遭到運(yùn)營商劫持將refer篡改成其他的.

Cookie: 本質(zhì)上是瀏覽器給網(wǎng)頁提供的本地存儲數(shù)據(jù)機(jī)制 , 為了保證安全 , 網(wǎng)頁默認(rèn)是不允許訪問到計算機(jī)的本地硬盤. cookie 瀏覽器對于訪問硬盤作出了明確限制 , 通過鍵值對方式來組織數(shù)據(jù).

一文吃透Http協(xié)議

Cookie 中具體存啥內(nèi)容 , 由程序員自定義.這里是數(shù)據(jù)是啥意思 , 只能由開發(fā)的程序員知道.

Cookie 從哪里來? Cookie中的數(shù)據(jù)來自服務(wù)器 , 服務(wù)器會通過 ==http 響應(yīng)的報頭==部分(set-cookie 字段) , 來決定瀏覽器的 Cookie 要存什么.

Cookie 存在哪里? 可以認(rèn)為存在于硬盤上 , Cookie 在存的時候 , 是按照瀏覽器 + 域名的緯度來進(jìn)行細(xì)分的. 不同的瀏覽器各自存各自的 cookie , 同一個瀏覽器的不同域名 , 對應(yīng)不同的 Cookie. 同時Cookie 還有過期時間 , eg: 很多網(wǎng)站登錄一次會自動記錄登錄狀態(tài).

Cookie 要到哪里去? 客戶端會通過Cookie 來保存用戶使用的中間狀態(tài) , 當(dāng)客戶端訪問瀏覽器的時候 , 就會自動把 Cookie 中的內(nèi)容帶入到請求中 , 服務(wù)器就知道客戶端的狀態(tài).Cookie 里存的往往是"上下文" 這樣的狀態(tài) , 當(dāng)瀏覽器保存好 cookie后 , 后續(xù)再給服務(wù)器發(fā)送請求時 , 就會自動帶上 . cookie 就像是服務(wù)器在瀏覽器這邊搞的一個寄存處一樣的東西.

認(rèn)識請求正文

正文中的內(nèi)容和header 中的Content-Type密切相關(guān) , 常見以下三種:

application/x-www-form-urlencode
multipart/form-data
application/json

2.Http 響應(yīng)

響應(yīng)由四個部分組成:

1.首行

一文吃透Http協(xié)議

2.header
3.空格表示 header 的結(jié)束標(biāo)記
4.body

Http 狀態(tài)碼: 描述了這次響應(yīng)的結(jié)果.(成功?失敗?失敗原因是啥?)

常見:

200 ok 成功了.
404 NotFound 訪問的資源不存在 , 服務(wù)器上沒找到.
403 Forbidden 訪問被拒絕(沒有權(quán)限)
302 Move temporarily 重定向 , 舊域名跳轉(zhuǎn)到新域名. 302 這樣的響應(yīng)報文 , 會在 header 里帶個 Location 屬性 , 通過這個屬性來描述要跳轉(zhuǎn)到哪個地址.

重定向: 是 http 提供的機(jī)制
一文吃透Http協(xié)議