目錄
一、HTTP
1.1 HTTP是什么
1.2 HTTP協議的工作過程
1.3 HTTP協議格式
1.3.1 抓包工具的使用
1.3.2 抓包結果
1.4 HTTP請求
1.4.1 URL
1.4.2 認識“方法” (method)
1.4.3 認識請求“報頭”(header)
1.4.4 認識請求“正文”(body)
1.5 HTTP 響應詳解
1.5.1 HTTP 狀態碼
1.5.2 響應“報頭”(header)
1.5.3 響應“正文”(body)
二、HTTPS
2.1 HTTPS的工作過程
一、HTTP
1.1 HTTP是什么
HTTP(全稱“超文本傳輸協議”)是一種應用非常廣泛的 應用層協議。
?我們平時打開一個網站,就是通過HTTP協議來傳輸數據的。
1.2 HTTP協議的工作過程
當我們在瀏覽器中輸入一個“網址”,此時瀏覽器就會給對應的服務器發送一個HTTP請求,對應的服務器收到這個請求經過計算處理,就會返回一個HTTP響應。
事實上,當我們訪問一個網站的時候,可能涉及布置一次的HTTP請求/響應的過程。
可以通過瀏覽器的開發者工具來觀察這個詳細的過程。
當前搜狗主頁是利用了HTTPS協議進行通信的,HTTPS是在HTTP的基礎上做了一個加密解密的工作后面再詳細介紹。
1.3 HTTP協議格式
HTTP是一個文本格式的協議,可以通過瀏覽器的開發者工具或者抓包工具抓包來查看HTTP請求/響應的細節。
1.3.1 抓包工具的使用
這里以Fiddler為例。
左側窗口顯示了所有的HTTP請求/響應,可以選中某個請求查看詳情。
右側上方顯示了HTTP請求的報文內容(切換到RAW標簽頁可以看到詳細的數據格式)
右側下方顯示了HTTP響應的報文內容(切換到RAW標簽頁可以看到詳細的數據格式)
請求和響應的詳細數據,可以通過右下角的View in Notepad 通過記事本打開
1.3.2 抓包結果
以下是一個HTTP請求/響應的抓包結果
首行:[方法] + [url] + [版本]
Header:請求的屬性,冒號分隔的鍵值對;每組數據之間使用 \n 分割;遇到空行表示Header部分結束。
Body:空行后面的內容都是Body。Body允許空字符串,如果Body存在,則在Header部分中有一個Content-Length屬性來標識Body的長度
HTTP響應
首行:[版本號] + [狀態碼] + [狀態碼解釋]
Header:請求的屬性,冒號分隔的鍵值對;每組數據之間使用 \n 分割;遇到空行表示Header部分結束。
Body: 空行后面的內容都是Body. Body允許為空字符串. 如果Body存在, 則在Header中會有?個Content-Length屬性來標識Body的長度; 如果服務器返回了?個html頁面, 那么html頁面內容就是
在body中.
?HTTP 協議并沒有規定報頭部分的鍵值對有多少個. 空行就相當于是 "報頭的結束標記", 或者是
報頭和正文之間的分隔符".
HTTP 在傳輸層依賴 TCP 協議, TCP 是面向字節流的. 如果沒有這個空行, 就會出現 "粘包問題".
1.4 HTTP請求
1.4.1 URL
平時我們俗稱的“網址”其實就是一個URL。
關于query string :query string 中的內容是鍵值對結構,其中的 key 和 value 的取值和個數,完全由程序員自己約定的,我們可以通過這樣的方式來定制傳輸我們需要的信息給服務器。
1.4.2 認識“方法” (method)
GET方法?
GET方法是最常用的HTTP方法,常用于獲取服務器的某個資源。在瀏覽器中直接輸入URL,此時瀏覽器就會發出一個GET請求
在上面的抓包結果中可以看到最上面的
是通過瀏覽器地址欄發送的get請求。
選中這條觀察請求的詳細結果:
GET https://www.sogou.com/ HTTP/1.1
Host: www.sogou.com
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/w
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: SUID=19AA8B7B6E1CA00A000000005F9A2F76; SUV=1603940214073598; pgv_pvi=266
GET請求的特點:
首行第一部分為GET
URL的query string 可以為空也可以不為空
header由若干個鍵值對結構
body部分為空
1.4.3 認識請求“報頭”(header)
header 的整體格式也是“鍵值對” 的結構
Host 表示服務器主機的地址和端口
Content-Length 表示body中數據的長度
Content-Type 表示請求body中的數據格式。常見選項:
application/x-www-form-urlencoded: form 表單提交的數據格式. 此時 body 的格式形如:
?
title=test&content=hello
multipart/form-data: form 表單提交的數據格式(在 form 標簽中加上enctyped="multipart/form-data" . 通常用于提交圖片/文件. body 格式形如:
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3Trw
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--
application/json: 數據為 json 格式. body 格式形如:
?
{"username":"123456789","password":"xxxx","code":"jw7l","uuid":"d110a05ccde64b16"}
User-Agent 表示瀏覽器/操作系統的屬性
Referer 表示這個頁面是從哪個頁面跳轉過來的。如果直接在瀏覽器輸入URL或者直接通過收藏夾訪問是沒有 Referer 的。
Cookie 中存儲了一個字符串,這個數據可能是客戶端(網頁)自行通過JS寫入的,也可能來自于服務器(服務器在HTTP響應的header中通過set-cookie字段給瀏覽器返回數據)。往往可以通過這個字段實現“身份標識”的功能。可以通過抓包觀察登陸的過程。
1.4.4 認識請求“正文”(body)
正文中的內容格式和header 中的 content-type 密切相關。上面也羅列了三種常見情況。
1.5 HTTP 響應詳解
1.5.1 HTTP 狀態碼
狀態碼表示訪問一個頁面的結果(是訪問成功還是失敗還是其他的一些情況...)
以下為一些常見的狀態碼
200 OK 這是最常見的一個狀態碼,表示訪問成功
404 Not Found 沒有找到資源
403 Forbidden 表示訪問被拒絕,有的頁面需要一些權限才能夠訪問(登錄后才能訪問),如果用戶沒有登陸直接訪問,就容易見到 403
405 Method Not Allowed 前面我們已經學習了 HTTP 中所支持的方法,但是對方的服務器不一定支持所有的方法
500 Internal Server Error 服務器出現內部錯誤,一般是服務器的代碼執行過程中遇到了一些特殊情況。
504 Gateway Timeout 當服務器負載比較大的時候,服務器處理單條請求的時候耗時就會比較長,就很可能會出現超時的情況。
302 Move temporarily 臨時重定向。
301 Moved Permanently 永久重定向。
1.5.2 響應“報頭”(header)
響應報頭的基本格式和請求報頭的格式基本?致.
類似于 Content-Type , Content-Length 等屬性的含義也和請求中的含義?致.
響應中的 Content-Type 常見取值有以下幾種:
?text/html : body 數據格式是 HTML
?text/css : body 數據格式是 CSS
?application/javascript : body 數據格式是 JavaScript
?application/json : body 數據格式是 JSON
1.5.3 響應“正文”(body)
text/html:
Server: nginx/1.17.3
Date: Thu, 10 Jun 2021 07:25:09 GMT
Content-Type: text/html; charset=utf-8
Last-Modified: Thu, 13 May 2021 09:01:26 GMT
Connection: keep-alive
ETag: W/"609ceae6-3206"
Content-Length: 12806
<!DOCTYPE html><html><head><meta charset=utf-8><meta http-equiv=X-UA-Compatible
body,
#app {
height: 100%;
margin: 0px;
padding: 0px;
}
.chromeframe {
margin: 0.2em 0;
background: #ccc;
color: #000;
padding: 0.2em 0;
}
#loader-wrapper {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
z-index: 999999;
}
......
text/css:
HTTP/1.1 200 OK
Server: nginx/1.17.3
Date: Thu, 10 Jun 2021 07:25:09 GMT
Content-Type: text/css
Last-Modified: Thu, 13 May 2021 09:01:26 GMT
Connection: keep-alive
ETag: W/"609ceae6-3cfbe"
Content-Length: 249790
@font-face{font-family:element-icons;src:url(../../static/fonts/element-icons.53
......
application/JavaScript
HTTP/1.1 200 OK
Server: nginx/1.17.3
Date: Thu, 10 Jun 2021 07:25:09 GMT
Content-Type: application/javascript; charset=utf-8
Last-Modified: Thu, 13 May 2021 09:01:26 GMT
Connection: keep-alive
ETag: W/"609ceae6-427d4"
Content-Length: 272340
(window["webpackJsonp"]=window["webpackJsonp"]||[]).push([["app"],{0:function(t,
......
application/json:
HTTP/1.1 200
Server: nginx/1.17.3
Date: Thu, 10 Jun 2021 07:25:10 GMT
1 2 3Content-Type: application/json;charset=UTF-8
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
vary: accept-encoding
Content-Length: 12268
{"msg":"操作成功","code":200,"permissions":[] }
二、HTTPS
HTTPS 也是應用層協議,是在HTTP協議的基礎上引入了一個加密層。
HTTP協議內容都是按照文本的方式明文傳輸的,這就導致在傳輸過程中會出現被篡改的情況。臭名昭著的“運營商劫持”。就比如你下載一個天天動聽,未被劫持的情況下你點擊下載按鈕就會彈出天天動聽的下載鏈接,如果已被劫持就會彈出QQ瀏覽器的下載鏈接。
由于我們通過網絡傳輸的任何數據包都會經過運營商的網絡設備,那么運營商的網絡設備就可以解析出你傳輸的數據內容,并進行篡改。點擊 "下載按鈕", 其實就是在給服務器發送了?個 HTTP 請求, 獲取到的 HTTP 響應其實就包含了該 APP 的下載鏈接. 運營商劫持之后, 就發現這個請求是要下載天天動聽, 那么就自動的把交給用戶的響應給篡改成 "QQ瀏覽器" 的下載地址了.
2.1 HTTPS的工作過程
既然要保證數據安全,就需要進行“加密”。
網絡傳輸中不再直接傳輸明文了,而是加密后生成的“密文”。
加密的方法有很多,但是大致可以分為對稱加密和非對稱加密。
HTTPS加密完整流程:
HTTPS ?作過程中涉及到的密鑰有三組.
第?組(非對稱加密): 用于校驗證書是否被篡改. 服務器持有私鑰(私鑰在注冊證書時獲得), 客戶端持有公鑰(操作系統包含了可信任的 CA 認證機構有哪些, 同時持有對應的公鑰). 服務器使用這個私鑰對證書的簽名進行加密. 客戶端通過這個公鑰解密獲取到證書的簽名, 從而校驗證書內容是否是篡改過.
第?組(非對稱加密): 用于協商生成對稱加密的密鑰. 服務器生成這組 私鑰-公鑰 對, 然后通過證書把公鑰傳遞給客戶端. 然后客戶端用這個公鑰給生成的對稱加密的密鑰加密, 傳輸給服務器, 服務器通過私鑰解密獲取到對稱加密密鑰.
第三組(對稱加密): 客戶端和服務器后續傳輸的數據都通過這個對稱密鑰加密解密.