图解HTTP学习笔记
前言:
一直覺得自己在HTTP基礎方面都是處于知其然,不知其所以然的樣子。最近利用空閑時間拜讀了一下圖解HTTP,寫篇博客記錄一下讀書筆記。
TCP三次握手:
① 發送端首先發送一個帶SYN標志的數據包給對方
②?接收端收到后,回傳一個帶有SYN/ACK標志的數據包以示傳達確認消息
③?發送端再回傳一個帶ACK標志的數據包,代表“握手結束”注意:若在握手的過程中某個階段莫名中斷,TCP協議會再次以相同的順序發送相同的數據包。
關于Cookie:
?目前我們用的比較多的用戶鑒權的方法有兩種:cookie和Authorization。
?Authorization:用戶登錄成功后在Response Headers或者在URL里面返回Authorization,然后前端拿到Authorization后進行處理,在每次進行HTTP請求時將該Authorization帶在Request Headers上。
Cookie:用戶登錄成功后,Cookie會根據從服務器端發送的響應報文內的一個叫做Set-Cookie的首部字段信息,通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時,客戶端會自動在請求報文中加入Cookie值后再發送出去。 很明顯這兩種方式對于前端來說當然是第二種Cookie的方式更爽點,因為第二種方式前端不需要做任何事情 HTTP首部:?HTTP首部根據實際用途分為:通用首部字段、請求首部字段、響應首部字段、實體首部字段
通用首部字段
| 首部字段名 | 說明 |
| Cache-Control | 控制緩存的行為 |
| Connection | 逐跳首部、連接的管理 |
| Date | 創建報文的日期時間 |
| Pragma | 報文指令 |
| Trailer | 報文末端的首部一覽 |
| Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
| Upgrade | 升級為其他協議 |
| Via | 代理服務器的相關信息 |
| Waring | 錯誤通知 |
?
請求首部字段
| 首部字段名 | 說明 |
| Accept | 用戶代理可處理的媒體類型 |
| Accept-Charset | 優先的字符集 |
| Accept-Encoding | 優先的內容編碼 |
| Accept-Language | 優先的語言(自然語言) |
| Authorization | Web認證信息 |
| Expect | 期待服務器的特定行為 |
| From | 用戶的電子郵箱地址 |
| Host | 請求資源所在服務器 |
| If-Match | 比較實體標記(ETag) |
| If-Modified-Since | 比較資源的更新時間 |
| If-None-Match | 比較實體標記(與 If-Match 相反) |
| If-Range | 資源未更新時發送實體 Byte 的范圍請求 |
| If-Unmodified-Since | 比較資源的更新時間(與If-Modified-Since相反) |
| Max-Forwards | 最大傳輸逐跳數 |
| Proxy-Authorization | 代理服務器要求客戶端的認證信息 |
| Range | 實體的字節范圍請求 |
| Referer | 對請求中 URI 的原始獲取方 |
| TE | 傳輸編碼的優先級 |
| User-Agent | HTTP 客戶端程序的信息 |
?
響應首部字段
| 首部字段名 | 說明 |
| Accept-Ranges | 是否接受字節范圍請求 |
| Age | 推算資源創建經過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定URI |
| Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
| Retry-After | 對再次發起請求的時機要求 |
| Server | HTTP服務器的安裝信息 |
| Vary | 代理服務器緩存的管理信息 |
| WWW-Authenticate | 服務器對客戶端的認證信息 |
實體首部字段?
| 首部字段名 | 說明 |
| Allow | 資源可支持的HTTP方法 |
| Content-Encoding | 實體主體適用的編碼方式 |
| Content-Language | 實體主體的自然語言 |
| Content-Length | 實體主體的大小(單位: 字節) |
| Content-Location | 替代對應資源的URI |
| Content-MD5 | 實體主體的報文摘要 |
| Content-Range | 實體主體的位置范圍 |
| Content-Type | 實體主體的媒體類型 |
| Expires | 實體主體過期的日期時間 |
| Last-Modified | 資源的最后修改日期時間 |
| 1XX | 信息性狀態碼 | 接收的請求正在處理 |
| 2XX | 成功狀態碼 | 請求正常處理完畢 |
| 3XX | 重定向狀態碼 | 需要進行附加操作以完成請求 |
| 4XX | 客戶端錯誤狀態碼 | 服務器無法處理請求 |
| 5XX | 服務器錯誤狀態碼 | 服務器處理請求出錯 |
常用的一些狀態碼:
200 OK:表示從客戶端發來的請求在服務器端被正常處理了
204 No Content:該狀態碼代表服務器接收的請求已成功處理,但在返回的響應報文中不含實體的主體部分。一般用于在需要從客戶端往服務器發送信息,而對客戶端不需要發送新信息內容的情況下下。
206 Partial Content:該狀態碼表客戶端進行了范圍請求,而服務器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定范圍的實體內容
?
301 Moved Permanently:永久性重定向。該狀態碼表示請求的資源已被分配了新的URI,以后應使用資源現在所指的URI。
302 Found:臨時性重定向。該狀態碼表示請求的資源已被分配了新的URI,希望用戶(本次)能使用新的URI訪問。與301的區別是,代表資源不是被永久移動,只是臨時性質的。
303 See Other:該狀態碼表示由于請求對應的資源存在著另一個URI,應使用GET方法定向獲取請求的資源。303和302有著相同的功能,但303狀態碼明確表示客戶端應當采用GET方法獲取資源。
304 Not Modified:該狀態碼表示客戶端發送附帶條件的請求時,服務器端允許請求訪問資源,但未滿足條件的情況。304狀態碼返回時,不包含任何響應的主體部分。304雖然被劃分在3XX類別中,但是和重定向沒有關系。
307 Temporary Redirect:臨時重定向。該狀態碼和302有相同的含義,但是307不會將POST變成GET
?
400 Bad Request:該狀態碼表示請求報文中存在語法錯誤。
401 Unauthorized:該狀態碼表示發送的請求需要有通過HTTP認證(BASIC認證、DIGEST認證)的認證信息。另外若之前已進行過1次請求,則表示用戶認證失敗。
403 Forbidden:該狀態碼表明對請求資源的訪問被服務器拒絕了。
404 Not Found:表明服務器上無法找到請求的資源。
?
500 Internal Server Error:表明服務器端在執行請求時發生了錯誤。
503 Service Unavailable:表明服務器暫時處于超負載或正在進行停機維護,現在無法處理請求。
總結:
第一次將本書讀完后有一種這樣的感覺,書中提到的很多知識點都是有所了解或者都能看懂,但是過了一段時間后發現很多地方又忘了,后面找機會再來拜讀一下這本書。
?
轉載于:https://www.cnblogs.com/heavenYJJ/p/9201790.html
與50位技術專家面對面20年技術見證,附贈技術全景圖總結
以上是生活随笔為你收集整理的图解HTTP学习笔记的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 跟牛牛老师学python自动化的第四天
- 下一篇: C# 继承(2)