目錄
學習過Rest API,使用Wireshark、urpsuite抓過包,還是感覺沒有系統的學習http協議,寫下此篇,作爲筆記整理。
所用工具
- Wireshark
- Postman
- Pycharm
- httpbin.org
HTTP簡介
HTTP協議是Hyper Text Transfer Protocol(超文本傳輸協議)的縮寫,是用於從萬維網(WWW:World Wide Web )服務器傳輸超文本到本地瀏覽器的傳送協議,是一個基於TCP/IP通信協議來傳遞數據(HTML文件, 圖片文件, 查詢結果等)。
HTTP 工作原理
HTTP協議工作於C/S(客戶端-服務端)架構上。瀏覽器作爲HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。
Web服務器有:Nginx服務器,Apache服務器,IIS服務器(Internet Information Services)等。
Web服務器根據接收到的請求後,向客戶端發送響應信息。
HTTP默認端口號爲80,你也可以改爲8080或者其他端口,HTTPS默認端口號爲443。
HTTP注意事項
- HTTP是無連接:無連接指限制每次連接只處理一個請求。服務器處理完客戶的請求,並收到客戶的應答後,即斷開連接。採用這種方式可以節省傳輸時間。
- HTTP是媒體獨立的:這意味着,只要客戶端和服務器知道如何處理的數據內容,任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
- HTTP是無狀態:HTTP協議是無狀態協議。無狀態指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息,則它必須重傳,這樣可能導致每次連接傳送的數據量增大。另一方面,在服務器不需要先前信息時它的應答就較快。
下圖表展示了HTTP協議通信流程:
HTTP 消息結構
HTTP使用統一資源標識符(Uniform Resource Identifiers, URI)來傳輸數據和建立連接。
一旦建立連接後,數據消息就通過類似Internet郵件所使用的格式[RFC5322]和多用途Internet郵件擴展(MIME)[RFC2045]來傳送。
客戶端請求消息
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式:請求行(request line)、請求頭部(header)、空行和請求數據四個部分組成。
下圖給出了請求報文的一般格式 :
注意:GET之後是有一個空格的
服務器響應消息
HTTP響應也由四個部分組成,分別是:狀態行、消息報頭、空行和響應正文。
實例
python代碼
import urllib.request
url = "http://httpbin.org/get"
print(url)
# 添加請求的url和方法
req = urllib.request.Request(url, method="GET")
# 接收響應數據
returnData = urllib.request.urlopen(req)
res_json = returnData.read().decode('utf-8')
print(res_json)
HTTP 請求方法
HTTP1.0 定義了三種請求方法: GET, POST 和 HEAD方法。
HTTP1.1 新增了六種請求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
序號 | 方法 | 描述 |
---|---|---|
1 | GET | 請求指定的頁面信息,並返回實體主體。 |
2 | HEAD | 類似於 GET 請求,只不過返回的響應中沒有具體的內容,用於獲取報頭 |
3 | POST | 向指定資源提交數據進行處理請求(例如,提交表單或者上傳文件)。數據被包含在請求體中。POST 請求可能會導致新的資源的建立或已有資源的修改。 |
4 | PUT | 從客戶端向服務器傳送的數據取代指定的文檔的內容。 |
5 | DELETE | 請求服務器刪除指定的頁面。 |
6 | CONNECT | HTTP/1.1 協議中預留給能夠將連接改爲管道方式的代理服務器。 |
7 | OPTIONS | 允許客戶端查看服務器的性能。 |
8 | TRACE | 回顯服務器收到的請求,主要用於測試或診斷。 |
9 | PATCH | 是對 PUT 方法的補充,用來對已知資源進行局部更新 。 |
GET和POST的區別
- GET在瀏覽器回退時是無害的,而POST會再次提交請求。
- GET產生的URL地址可以被Bookmark,而POST不可以。
- GET請求會被瀏覽器主動cache,而POST不會,除非手動設置。
- GET請求只能進行url編碼,而POST支持多種編碼方式。
- GET請求參數會被完整保留在瀏覽器歷史記錄裏,而POST中的參數不會被保留。
- GET請求在URL中傳送的參數是有長度限制的,而POST麼有。
- 對參數的數據類型,GET只接受ASCII字符,而POST沒有限制。
- GET比POST更不安全,因爲參數直接暴露在URL上,所以不能用來傳遞敏感信息。
- GET參數通過URL傳遞,POST放在Request body中。
(源於w3schools)
HTTP的底層是TCP/IP(推薦書籍《TCP/IP詳解》)。所以,GET和POST的底層也是TCP/IP。GET和POST能做的事情是一樣一樣的。如果給GET加上request body,或者給POST帶上url參數,技術上是完全行的通的。也就是說,GET和POST在本質上沒什麼區別。
但是如果真的一點區別都沒有,那麼這個問題也就不存在了,兩者之間最重大的區別就是:
GET產生一個TCP數據包;POST產生兩個TCP數據包。
具體點說來就是:
對於GET方式的請求,瀏覽器會把http header和data一併發送出去,服務器響應200(返回數據);
而對於POST,瀏覽器先發送header,服務器響應100 continue,瀏覽器再發送data,服務器響應200 ok(返回數據)。
HTTP 響應頭信息
就是前面的消息報頭,以key:value形式。
響應頭 | 說明 |
---|---|
Allow |
服務器支持哪些請求方法(如GET、POST等)。 |
Content-Encoding |
文檔的編碼(Encode)方法。只有在解碼之後纔可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮,但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此,Servlet應該通過查看Accept-Encoding頭(即request.getHeader("Accept-Encoding"))檢查瀏覽器是否支持gzip,爲支持gzip的瀏覽器返回經gzip壓縮的HTML頁面,爲其他瀏覽器返回普通頁面。 |
Content-Length |
表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢,可以把輸出文檔寫入 ByteArrayOutputStream,完成後查看其大小,然後把該值放入Content-Length頭,最後通過byteArrayStream.writeTo(response.getOutputStream()發送內容。 |
Content-Type |
表示後面的文檔屬於什麼MIME類型。Servlet默認爲text/plain,但通常需要顯式地指定爲text/html。由於經常要設置Content-Type,因此HttpServletResponse提供了一個專用的方法setContentType。 |
Date |
當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。 |
Expires |
過期時間,應該在什麼時候認爲文檔已經過期,從而不再緩存它? |
Last-Modified |
文檔的最後改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期,該請求將被視爲一個條件GET,只有改動時間遲於指定時間的文檔纔會返回,否則返回一個304(Not Modified)狀態。Last-Modified也可用setDateHeader方法來設置。 |
Location |
表示客戶應當到哪裏去提取文檔。Location通常不是直接設置的,而是通過HttpServletResponse的sendRedirect方法,該方法同時設置狀態代碼爲302。 |
Refresh |
表示瀏覽器應該在多少時間之後刷新文檔,以秒計。除了刷新當前文檔之外,你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。 |
Server |
服務器名字。Servlet一般不設置這個值,而是由Web服務器自己設置。 |
Set-Cookie |
設置和頁面關聯的Cookie。Servlet不應使用response.setHeader("Set-Cookie", ...),而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設置的討論。 |
WWW-Authenticate |
客戶應該在Authorization頭中提供什麼類型的授權信息?在包含401(Unauthorized)狀態行的應答中這個頭是必需的。例如,response.setHeader("WWW-Authenticate", "BASIC realm=\"executives\"")。 |
HTTP狀態碼
HTTP狀態碼分類
分類 | 分類描述 |
---|---|
1** | 信息,服務器收到請求,需要請求者繼續執行操作 |
2** | 成功,操作被成功接收並處理 |
3** | 重定向,需要進一步的操作以完成請求 |
4** | 客戶端錯誤,請求包含語法錯誤或無法完成請求 |
5** | 服務器錯誤,服務器在處理請求的過程中發生了錯誤 |
HTTP狀態碼列表
狀態碼 | 狀態碼英文名稱 | 中文描述 |
---|---|---|
100 | Continue | 繼續。客戶端應繼續其請求 |
101 | Switching Protocols | 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議,例如,切換到HTTP的新版本協議 |
200 | OK | 請求成功。一般用於GET與POST請求 |
201 | Created | 已創建。成功請求並創建了新的資源 |
202 | Accepted | 已接受。已經接受請求,但未處理完成 |
203 | Non-Authoritative Information | 非授權信息。請求成功。但返回的meta信息不在原始的服務器,而是一個副本 |
204 | No Content | 無內容。服務器成功處理,但未返回內容。在未更新網頁的情況下,可確保瀏覽器繼續顯示當前文檔 |
205 | Reset Content | 重置內容。服務器處理成功,用戶終端(例如:瀏覽器)應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域 |
206 | Partial Content | 部分內容。服務器成功處理了部分GET請求 |
300 | Multiple Choices | 多種選擇。請求的資源可包括多個位置,相應可返回一個資源特徵與地址的列表用於用戶終端(例如:瀏覽器)選擇 |
301 | Moved Permanently | 永久移動。請求的資源已被永久的移動到新URI,返回信息會包括新的URI,瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替 |
302 | Found | 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI |
303 | See Other | 查看其它地址。與301類似。使用GET和POST請求查看 |
304 | Not Modified | 未修改。所請求的資源未修改,服務器返回此狀態碼時,不會返回任何資源。客戶端通常會緩存訪問過的資源,通過提供一個頭信息指出客戶端希望只返回在指定日期之後修改的資源 |
305 | Use Proxy | 使用代理。所請求的資源必須通過代理訪問 |
306 | Unused | 已經被廢棄的HTTP狀態碼 |
307 | Temporary Redirect | 臨時重定向。與302類似。使用GET請求重定向 |
400 | Bad Request | 客戶端請求的語法錯誤,服務器無法理解 |
401 | Unauthorized | 請求要求用戶的身份認證 |
402 | Payment Required | 保留,將來使用 |
403 | Forbidden | 服務器理解請求客戶端的請求,但是拒絕執行此請求 |
404 | Not Found | 服務器無法根據客戶端的請求找到資源(網頁)。通過此代碼,網站設計人員可設置"您所請求的資源無法找到"的個性頁面 |
405 | Method Not Allowed | 客戶端請求中的方法被禁止 |
406 | Not Acceptable | 服務器無法根據客戶端請求的內容特性完成請求 |
407 | Proxy Authentication Required | 請求要求代理的身份認證,與401類似,但請求者應當使用代理進行授權 |
408 | Request Time-out | 服務器等待客戶端發送的請求時間過長,超時 |
409 | Conflict | 服務器完成客戶端的 PUT 請求時可能返回此代碼,服務器處理請求時發生了衝突 |
410 | Gone | 客戶端請求的資源已經不存在。410不同於404,如果資源以前有現在被永久刪除了可使用410代碼,網站設計人員可通過301代碼指定資源的新位置 |
411 | Length Required | 服務器無法處理客戶端發送的不帶Content-Length的請求信息 |
412 | Precondition Failed | 客戶端請求信息的先決條件錯誤 |
413 | Request Entity Too Large | 由於請求的實體過大,服務器無法處理,因此拒絕請求。爲防止客戶端的連續請求,服務器可能會關閉連接。如果只是服務器暫時無法處理,則會包含一個Retry-After的響應信息 |
414 | Request-URI Too Large | 請求的URI過長(URI通常爲網址),服務器無法處理 |
415 | Unsupported Media Type | 服務器無法處理請求附帶的媒體格式 |
416 | Requested range not satisfiable | 客戶端請求的範圍無效 |
417 | Expectation Failed | 服務器無法滿足Expect的請求頭信息 |
500 | Internal Server Error | 服務器內部錯誤,無法完成請求 |
501 | Not Implemented | 服務器不支持請求的功能,無法完成請求 |
502 | Bad Gateway | 作爲網關或者代理工作的服務器嘗試執行請求時,從遠程服務器接收到了一個無效的響應 |
503 | Service Unavailable | 由於超載或系統維護,服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中 |
504 | Gateway Time-out | 充當網關或代理的服務器,未及時從遠端服務器獲取請求 |
505 | HTTP Version not supported | 服務器不支持請求的HTTP協議的版本,無法完成處理 |
提幾個常見的狀態碼,100、200前面說過了,3**的我還沒遇到過。
404,頁面不存在,檢查url是否正確
405,方法被禁止,檢查使用方法是否正確
其他的還遇到一些,等碰到了再補充。