HTTP 是什麼
用於傳輸超文本的協議,以前是 HTML ,現在也包括 Web API 的數據。
HTTP 的工作方式
最直觀的方式:地址欄輸入地址,然後頁面就會顯示結果
實際上是:在地址欄輸入地址,回車後就會向服務器發送請求,然後服務器會進行響應,接着瀏覽器就會將響應的數據進行渲染出來
URL -> HTTP 報文
- 示例:http://www.baidu.com/s?cl=3
- 其中 http 爲協議類型,協議類型都有 http,ftp 等等,這些叫做應用層協議
- //www.baidu.com 爲服務器地址
- /s 及其後面的爲 路徑 path
上面這個地址看起來是一個地址,但是瀏覽器拿到後會分爲三塊進行處理,處理完成後如下所示
-
GET /s?cl=3 HTTP/1.1
Host :www.baidu.com
HTTP 的工作方式
報文格式:Request
其中第一行爲:請求行 ,分別對應三個部分,
- 第一部分 method ,他可以爲 GET ,POST ,PUT 等,代表你的行爲
- 第二部分:path ,路徑,給服務器看到,定位
- 第三部分:版本
第二行往下爲 headers
其中左邊是鍵,右邊是值
最後一行爲 body
在 get 中是不需要 body 的。而在 post 中則需要使用 body了,body 中是你需要向服務器提交的一些數據
報文格式:Response
其中第一行爲狀態行
- 最開始爲 http 的版本
- 中間是 status code,狀態碼
- 最後是狀態信息 status message
中間的是 headers
左邊是鍵,右邊是值
最後一行爲 body
服務器返回的數據
關鍵內容
-
Request method
請求的方法:如 get,post,put 等
-
GET
獲取資源,不會攜帶 body
-
POST
增加或者修改資源,有 body
//請求行 POST /users HTTP/1.1 //headers Host:192.168.43.253 Content-Type:text/html; charset=UTF-8 Date:Mon, 15 Jun 2020 13:20:08 GMT //body { "name": "456", "password": "12345" }
-
PUT
修改資源,只用來修改,有 body
和 get 的共同點:他們都是冪等的。意思就是他們的結果是相等的。例如獲取資源,獲取10 次結果都是一樣的,執行多次和執行一次是一樣的
-
DELETE
刪除資源,沒有body,具有冪等性,刪除一次和刪除多次沒區別
-
HEAD
和 GET 幾乎一樣,區別就是服務器不會返回 body。
-
-
Response status code
對結果做出類型化的描述,如果獲取成功,內容未找到等
- 1xx:臨時性消息
- 2xx:成功
- 3xx:重定向,會進行二次請求,進行請求後會重新定向,接着就會重新請求請求,這個過程感知不到的,但是可以通過狀態碼來查看到。301 永久性遷移,302 臨時遷移,304 內容沒有改變
- 4xx:客戶端錯誤,如 400參數錯誤,404 資源未找到等
- 5xx:服務器錯誤
-
header
作用:
-
HTTP 消息的元數據(metadata)
-
HTTP 中的元數據:例如同 http 提交一個用戶信息,信息中的 name,age 等都是數據本身,他們並不是元數據。元數據是消息的長度,消息的格式,返回的數據集,有沒有壓縮等。可以看做爲數據的屬性
比較常見的
-
Host:服務器地址,但是他不是用來尋址的。在瀏覽器將報文拼好之後,在發出請求之前就已經去進行服務器的尋址了,他會拿着域名通過 DNS 去尋找對應的 ip 地址。一個域名可能會對應多個 ip 地址。找到對應的目標服務器地址後就會將報文發給目標服務器。既然都找到服務器了,爲啥還要發送 host 呢?因爲一個 ip 地址下面可能會有多個服務器存在,他們對外的ip 都是一樣的,當尋找到 ip 進行訪問的時候就沒辦法轉到具體的主機,這個時候就沒辦法正確的響應。所以需要傳入 host,這個 host 一般傳入的是服務器地址+TCP 端口。
-
Content-Type/Content-Length:Body 的類型/長度(字節)
-
text/html
Content-Type:text/html; charset=UTF-8
-
application/x-www-form-urlencoded:普通表單,encoded URL 格式
例如使用 Retrofit 的 post 請求是,需要使用 @FormUrlEncoded ,這種就是表單提交
而且如果要傳文件,還需要使用 @MultPart
-
multpiipart/form-data ; boundary = ********************
多補發形式,一般用於傳輸包含二進制內容的多項內容
使用 Retrofit 就需要使用 @MultPart
boundary 是一個分界線,用來分界 header 值得各個屬性和 body
-
application/json
json 形式,用於 Web Api 的響應或者 POST/PUT 請求
body 中是 json 格式
使用這種方式進行post 請求的時候 body 中的內容可以爲 json 格式,好處就是格式比較自由。
-
image/jped
圖片上傳
-
-
Location:重新定向的目標 URL
-
User-Agent:用戶代理
-
Range/Accept-Range:指定 Body 的內容範圍
如果你的服務器支持你分段取內容/下載 的時候,指定的範圍
例如:從百度上覆制一個圖片地址到 postMan 中進行求,就會加載出圖片,接着你在查看他的 headers,就會找到 Accept-Ranges 這個值如下
Accept-Ranges:bytes
這表示他是支持分段加載的
我們在請求這個圖片的時候在header 中加上如下屬性:
Range:bytes=0-15000
你就會發現這個圖片只被加載了一半
那麼他又什麼作用呢?1,斷點續傳,如果下載中斷,那麼下一次下載的時候只需要指定開始的位置和文件的大小即可。2,分段下載,可以用來多線程下載
-
Cookie/Set-Cookie:發送 Cookie /設置 Cookie
-
Authorization:授權信息
-
Accept:客戶端能接受的數據類型
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
-
Accept-Charset:客戶端能接受的字符集,如 utf-8
-
Accept-Encoding:客戶端能接收的壓縮編碼類型,如 gzip
-
Content-Encoding:壓縮類型,如 gzip
-
Cache-Control:no-cache,no-store,max-age,
- Cache 和 Buffer 的區別:**Cache:**緩存,這個東西創建好我已經用完了,但是等會可能還會使用,所以我把這個東西繼續放在這裏。**Buffer:**緩衝,從來都是針對工作流的。有生產的上游和消費的下游,上游多生產一些,給下游稍後使用,這個叫做 Buffer,一般是兩個原因,1,上游生產太快,下游跟不上,2,下游現在不需要,等會在進行消費。
- no-cache:你可以緩存,當再次使用的時候需要問一下服務器資源是否失效。對於需要向服務器詢問的有兩類,1,資源是否改變:Etag,2,指定的日期是否到達:Last-Modified
- no-store:不可以緩存
- max-age:失效日期直接就可以直接使用
- private/public:我們在請求的時候並不是從客戶端直接連接到服務端,中間還會有一些節點,例如 網關等很多中間節點。private 和 public 的意思是告訴這些中間的節點是否要緩存這個消息,不只是本地機器可以緩存,中間的節點也可以幫助你進行緩存。public 就可以進行緩存,private 則不能緩存
-
Last-Modified:服務器傳過來文件的時候會告訴文件最近修改的日期,當你再次需要這個文件的時候就去請求服務器並且判斷一下這個修改日期是否發生了改變,如果沒有改變,則表示文件是最新的。
- if-Modeified-Since:是否在什麼之前改動過
-
Etag:對比文件本身,在從服務器獲取文件的時候會附加得到一個 tag,下次獲取的時候問一下服務器這個 tag 是否爲最新的即可
- if-Noe-Match:最新的資源還是這個 tag 嗎
-
-
body
要發送給服務器的內容,和服務器返回的數據內容
一下這個修改日期是否發生了改變,如果沒有改變,則表示文件是最新的。
- if-Modeified-Since:是否在什麼之前改動過
-
Etag:對比文件本身,在從服務器獲取文件的時候會附加得到一個 tag,下次獲取的時候問一下服務器這個 tag 是否爲最新的即可
- if-Noe-Match:最新的資源還是這個 tag 嗎
-
body
要發送給服務器的內容,和服務器返回的數據內容
如有問題,還請指出,謝謝