HTTP有哪些方法? HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法 HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 這些方法的具體作用是什麼? GET: 通常用於請求伺服器發送某些資源 HEAD: 請求資源的頭 ...
HTTP有哪些方法?
- HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法
- HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT
這些方法的具體作用是什麼?
- GET: 通常用於請求伺服器發送某些資源
- HEAD: 請求資源的頭部信息, 並且這些頭部與 HTTP GET 方法請求時返回的一致. 該請求方法的一個使用場景是在下載一個大文件前先獲取其大小再決定是否要下載, 以此可以節約帶寬資源
- OPTIONS: 用於獲取目的資源所支持的通信選項
- POST: 發送數據給伺服器
- PUT: 用於新增資源或者使用請求中的有效負載替換目標資源的表現形式
- DELETE: 用於刪除指定的資源
- PATCH: 用於對資源進行部分修改
- CONNECT: HTTP/1.1協議中預留給能夠將連接改為管道方式的代理伺服器
- TRACE: 回顯伺服器收到的請求,主要用於測試或診斷
GET和POST有什麼區別?
- 數據傳輸方式不同:GET請求通過URL傳輸數據,而POST的數據通過請求體傳輸。
- 安全性不同:POST的數據因為在請求主體內,所以有一定的安全性保證,而GET的數據在URL中,通過歷史記錄,緩存很容易查到數據信息。
- 數據類型不同:GET只允許 ASCII 字元,而POST無限制
- GET無害: 刷新、後退等瀏覽器操作GET請求是無害的,POST可能重覆提交表單
- 特性不同:GET是安全(這裡的安全是指只讀特性,就是使用這個方法不會引起伺服器狀態變化)且冪等(冪等的概念是指同一個請求方法執行多次和僅執行一次的效果完全相同),而POST是非安全非冪等
PUT和POST都是給伺服器發送新增資源,有什麼區別?
PUT 和POST方法的區別是,PUT方法是冪等的:連續調用一次或者多次的效果相同(無副作用),而POST方法是非冪等的。
除此之外還有一個區別,通常情況下,PUT的URI指向是具體單一資源,而POST可以指向資源集合。
舉個例子,我們在開發一個博客系統,當我們要創建一篇文章的時候往往用POST https://www.jianshu.com/articles
,這個請求的語義是,在articles的資源集合下創建一篇新的文章,如果我們多次提交這個請求會創建多個文章,這是非冪等的。
而PUT https://www.jianshu.com/articles/820357430
的語義是更新對應文章下的資源(比如修改作者名稱等),這個URI指向的就是單一資源,而且是冪等的,比如你把『劉德華』修改成『蔡徐坤』,提交多少次都是修改成『蔡徐坤』
ps: 『POST表示創建資源,PUT表示更新資源』這種說法是錯誤的,兩個都能創建資源,根本區別就在於冪等性
PUT和PATCH都是給伺服器發送修改資源,有什麼區別?
PUT和PATCH都是更新資源,而PATCH用來對已知資源進行局部更新。
比如我們有一篇文章的地址https://www.jianshu.com/articles/820357430
,這篇文章的可以表示為:
article = {
author: 'dxy',
creationDate: '2019-6-12',
content: '我寫文章像蔡徐坤',
id: 820357430
}
當我們要修改文章的作者時,我們可以直接發送PUT https://www.jianshu.com/articles/820357430
,這個時候的數據應該是:
{
author:'蔡徐坤',
creationDate: '2019-6-12',
content: '我寫文章像蔡徐坤',
id: 820357430
}
這種直接覆蓋資源的修改方式應該用put,但是你覺得每次都帶有這麼多無用的信息,那麼可以發送PATCH https://www.jianshu.com/articles/820357430
,這個時候只需要:
{
author:'蔡徐坤',
}
http的請求報文是什麼樣的?
請求報文有4部分組成:
- 請求行
- 請求頭部
- 空行
- 請求體
- 請求行包括:請求方法欄位、URL欄位、HTTP協議版本欄位。它們用空格分隔。例如,GET /index.html HTTP/1.1。
- 請求頭部:請求頭部由關鍵字/值對組成,每行一對,關鍵字和值用英文冒號“:”分隔
- User-Agent:產生請求的瀏覽器類型。
- Accept:客戶端可識別的內容類型列表。
- Host:請求的主機名,允許多個功能變數名稱同處一個IP地址,即虛擬主機。
- 請求體: post put等請求攜帶的數據
http的響應報文是什麼樣的?
請求報文有4部分組成:
- 響應行
- 響應頭
- 空行
- 響應體
- 響應行: 由協議版本,狀態碼和狀態碼的原因短語組成,例如
HTTP/1.1 200 OK
。 - 響應頭:響應部首組成
- 響應體:伺服器響應的數據
聊一聊HTTP的部首有哪些?
內容很多,重點看標『✨』內容
通用首部欄位(General Header Fields):請求報文和響應報文兩方都會使用的首部
- Cache-Control 控制緩存 ✨
- Connection 連接管理、逐條首部 ✨
- Upgrade 升級為其他協議
- via 代理伺服器的相關信息
- Wraning 錯誤和警告通知
- Transfor-Encoding 報文主體的傳輸編碼格式 ✨
- Trailer 報文末端的首部一覽
- Pragma 報文指令
- Date 創建報文的日期
請求首部欄位(Reauest Header Fields):客戶端向伺服器發送請求的報文時使用的首部
- Accept 客戶端或者代理能夠處理的媒體類型 ✨
- Accept-Encoding 優先可處理的編碼格式
- Accept-Language 優先可處理的自然語言
- Accept-Charset 優先可以處理的字元集
- If-Match 比較實體標記(ETage) ✨
- If-None-Match 比較實體標記(ETage)與 If-Match相反 ✨
- If-Modified-Since 比較資源更新時間(Last-Modified)✨
- If-Unmodified-Since比較資源更新時間(Last-Modified),與 If-Modified-Since相反 ✨
- If-Rnages 資源未更新時發送實體byte的範圍請求
- Range 實體的位元組範圍請求 ✨
- Authorization web的認證信息 ✨
- Proxy-Authorization 代理伺服器要求web認證信息
- Host 請求資源所在伺服器 ✨
- From 用戶的郵箱地址
- User-Agent 客戶端程式信息 ✨
- Max-Forwrads 最大的逐跳次數
- TE 傳輸編碼的優先順序
- Referer 請求原始放的url
- Expect 期待伺服器的特定行為
響應首部欄位(Response Header Fields):從伺服器向客戶端響應時使用的欄位
- Accept-Ranges 能接受的位元組範圍
- Age 推算資源創建經過時間
- Location 令客戶端重定向的URI ✨
- vary 代理伺服器的緩存信息
- ETag 能夠表示資源唯一資源的字元串 ✨
- WWW-Authenticate 伺服器要求客戶端的驗證信息
- Proxy-Authenticate 代理伺服器要求客戶端的驗證信息
- Server 伺服器的信息 ✨
- Retry-After 和狀態碼503 一起使用的首部欄位,表示下次請求伺服器的時間
實體首部欄位(Entiy Header Fields):針對請求報文和響應報文的實體部分使用首部
- Allow 資源可支持http請求的方法 ✨
- Content-Language 實體的資源語言
- Content-Encoding 實體的編碼格式
- Content-Length 實體的大小(位元組)
- Content-Type 實體媒體類型
- Content-MD5 實體報文的摘要
- Content-Location 代替資源的yri
- Content-Rnages 實體主體的位置返回
- Last-Modified 資源最後的修改資源 ✨
- Expires 實體主體的過期資源 ✨
聊一聊HTTP的狀態碼有哪些?
2XX 成功
- 200 OK,表示從客戶端發來的請求在伺服器端被正確處理 ✨
- 201 Created 請求已經被實現,而且有一個新的資源已經依據請求的需要而建立
- 202 Accepted 請求已接受,但是還沒執行,不保證完成請求
- 204 No content,表示請求成功,但響應報文不含實體的主體部分
- 206 Partial Content,進行範圍請求 ✨
3XX 重定向
- 301 moved permanently,永久性重定向,表示資源已被分配了新的 URL
- 302 found,臨時性重定向,表示資源臨時被分配了新的 URL ✨
- 303 see other,表示資源存在著另一個 URL,應使用 GET 方法丁香獲取資源
- 304 not modified,表示伺服器允許訪問資源,但因發生請求未滿足條件的情況
- 307 temporary redirect,臨時重定向,和302含義相同
4XX 客戶端錯誤
- 400 bad request,請求報文存在語法錯誤 ✨
- 401 unauthorized,表示發送的請求需要有通過 HTTP 認證的認證信息 ✨
- 403 forbidden,表示對請求資源的訪問被伺服器拒絕 ✨
- 404 not found,表示在伺服器上沒有找到請求的資源 ✨
- 408 Request timeout, 客戶端請求超時
- 409 Confict, 請求的資源可能引起衝突
5XX 伺服器錯誤
- 500 internal sever error,表示伺服器端在執行請求時發生了錯誤 ✨
- 501 Not Implemented 請求超出伺服器能力範圍,例如伺服器不支持當前請求所需要的某個功能,或者請求是伺服器不支持的某個方法
- 503 service unavailable,表明伺服器暫時處於超負載或正在停機維護,無法處理請求
- 505 http version not supported 伺服器不支持,或者拒絕支持在請求中使用的 HTTP 版本
同樣是重定向307,303,302的區別?
302是http1.0的協議狀態碼,在http1.1版本的時候為了細化302狀態碼又出來了兩個303和307。
303明確表示客戶端應當採用get方法獲取資源,他會把POST請求變為GET請求進行重定向。
307會遵照瀏覽器標準,不會從post變為get。
HTTP的keep-alive是乾什麼的?
在早期的HTTP/1.0中,每次http請求都要創建一個連接,而創建連接的過程需要消耗資源和時間,為了減少資源消耗,縮短響應時間,就需要重用連接。在後來的HTTP/1.0中以及HTTP/1.1中,引入了重用連接的機制,就是在http請求頭中加入Connection: keep-alive來告訴對方這個請求響應完成後不要關閉,下一次咱們還用這個請求繼續交流。協議規定HTTP/1.0如果想要保持長連接,需要在請求頭中加上Connection: keep-alive。
keep-alive的優點:
- 較少的CPU和記憶體的使用(由於同時打開的連接的減少了)
- 允許請求和應答的HTTP管線化
- 降低擁塞控制 (TCP連接減少了)
- 減少了後續請求的延遲(無需再進行握手)
- 報告錯誤無需關閉TCP連
為什麼有了HTTP為什麼還要HTTPS?
https是安全版的http,因為http協議的數據都是明文進行傳輸的,所以對於一些敏感信息的傳輸就很不安全,HTTPS就是為瞭解決HTTP的不安全而生的。
HTTPS是如何保證安全的?
過程比較複雜,我們得先理解兩個概念
對稱加密:即通信的雙方都使用同一個秘鑰進行加解密,比如特務接頭的暗號,就屬於對稱加密
對稱加密雖然很簡單性能也好,但是無法解決首次把秘鑰發給對方的問題,很容易被hacker攔截秘鑰。
非對稱加密:
- 私鑰 + 公鑰= 密鑰對
- 即用私鑰加密的數據,只有對應的公鑰才能解密,用公鑰加密的數據,只有對應的私鑰才能解密
- 因為通信雙方的手裡都有一套自己的密鑰對,通信之前雙方會先把自己的公鑰都先發給對方
- 然後對方再拿著這個公鑰來加密數據響應給對方,等到到了對方那裡,對方再用自己的私鑰進行解密
非對稱加密雖然安全性更高,但是帶來的問題就是速度很慢,影響性能。
解決方案:
那麼結合兩種加密方式,將對稱加密的密鑰使用非對稱加密的公鑰進行加密,然後發送出去,接收方使用私鑰進行解密得到對稱加密的密鑰,然後雙方可以使用對稱加密來進行溝通。
此時又帶來一個問題,中間人問題:
如果此時在客戶端和伺服器之間存在一個中間人,這個中間人只需要把原本雙方通信互發的公鑰,換成自己的公鑰,這樣中間人就可以輕鬆解密通信雙方所發送的所有數據。
所以這個時候需要一個安全的第三方頒發證書(CA),證明身份的身份,防止被中間人攻擊。
證書中包括:簽發者、證書用途、使用者公鑰、使用者私鑰、使用者的HASH演算法、證書到期時間等
但是問題來了,如果中間人篡改了證書,那麼身份證明是不是就無效了?這個證明就白買了,這個時候需要一個新的技術,數字簽名。
數字簽名就是用CA自帶的HASH演算法對證書的內容進行HASH得到一個摘要,再用CA的私鑰加密,最終組成數字簽名。
當別人把他的證書發過來的時候,我再用同樣的Hash演算法,再次生成消息摘要,然後用CA的公鑰對數字簽名解密,得到CA創建的消息摘要,兩者一比,就知道中間有沒有被人篡改了。
這個時候就能最大程度保證通信的安全了。
HTTP2相對於HTTP1.x有什麼優勢和特點?
二進位分幀
幀:HTTP/2 數據通信的最小單位消息:指 HTTP/2 中邏輯上的 HTTP 消息。例如請求和響應等,消息由一個或多個幀組成。
流:存在於連接中的一個虛擬通道。流可以承載雙向消息,每個流都有一個唯一的整數ID
HTTP/2 採用二進位格式傳輸數據,而非 HTTP 1.x 的文本格式,二進位協議解析起來更高效。
伺服器推送
服務端可以在發送頁面HTML時主動推送其它資源,而不用等到瀏覽器解析到相應位置,發起請求再響應。例如服務端可以主動把JS和CSS文件推送給客戶端,而不需要客戶端解析HTML時再發送這些請求。
服務端可以主動推送,客戶端也有權利選擇是否接收。如果服務端推送的資源已經被瀏覽器緩存過,瀏覽器可以通過發送RST_STREAM幀來拒收。主動推送也遵守同源策略,伺服器不會隨便推送第三方資源給客戶端。
頭部壓縮
HTTP/1.x會在請求和響應中中重覆地攜帶不常改變的、冗長的頭部數據,給網路帶來額外的負擔。
- HTTP/2在客戶端和伺服器端使用“首部表”來跟蹤和存儲之前發送的鍵-值對,對於相同的數據,不再通過每次請求和響應發送
- 首部表在HTTP/2的連接存續期內始終存在,由客戶端和伺服器共同漸進地更新;
- 每個新的首部鍵-值對要麼被追加到當前表的末尾,要麼替換表中之前的值。
你可以理解為只發送差異數據,而不是全部發送,從而減少頭部的信息量
多路復用
HTTP 1.x 中,如果想併發多個請求,必須使用多個 TCP 鏈接,且瀏覽器為了控制資源,還會對單個功能變數名稱有 6-8個的TCP鏈接請求限制。
HTTP2中:
- 同功能變數名稱下所有通信都在單個連接上完成。
- 單個連接可以承載任意數量的雙向數據流。
- 數據流以消息的形式發送,而消息又由一個或多個幀組成,多個幀之間可以亂序發送,因為根據幀首部的流標識可以重新組裝
拓展閱讀:HTTP/2特性及其在實際應用中的表現
公眾號
想要實時關註筆者最新的文章和最新的文檔更新請關註公眾號程式員面試官,後續的文章會優先在公眾號更新.
簡歷模板: 關註公眾號回覆「模板」獲取
《前端面試手冊》: 配套於本指南的突擊手冊,關註公眾號回覆「fed」獲取
本文由博客一文多發平臺 OpenWrite 發佈!