可能是全網最全的http面試答案

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 發佈！

可能是全網最全的http面試答案

HTTP有哪些方法？

這些方法的具體作用是什麼？

GET和POST有什麼區別？

PUT和POST都是給服務器發送新增資源，有什麼區別？

PUT和PATCH都是給服務器發送修改資源，有什麼區別？

http的請求報文是什麼樣的？

http的響應報文是什麼樣的？

聊一聊HTTP的部首有哪些？

聊一聊HTTP的狀態碼有哪些？

同樣是重定向307，303，302的區別？

HTTP的keep-alive是幹什麼的？

爲什麼有了HTTP爲什麼還要HTTPS？

HTTPS是如何保證安全的？

HTTP2相對於HTTP1.x有什麼優勢和特點？

二進制分幀

服務器推送

頭部壓縮

多路複用

公衆號

實現雙向綁定Proxy比defineproperty優劣如何?

可能是全網最全的http面試答案

實現雙向綁定Proxy比defineproperty優劣如何?

面試官: 寫過『通用前端組件』嗎?

一篇文章搞定前端性能優化面試

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結