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

来源:https://www.cnblogs.com/duxinyi/archive/2019/10/15/11676893.html
-Advertisement-
Play Games

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部分組成:

  • 請求行
  • 請求頭部
  • 空行
  • 請求體

2019-06-14-11-24-10

  • 請求行包括:請求方法欄位、URL欄位、HTTP協議版本欄位。它們用空格分隔。例如,GET /index.html HTTP/1.1。
  • 請求頭部:請求頭部由關鍵字/值對組成,每行一對,關鍵字和值用英文冒號“:”分隔
  1. User-Agent:產生請求的瀏覽器類型。
  2. Accept:客戶端可識別的內容類型列表。
  3. Host:請求的主機名,允許多個功能變數名稱同處一個IP地址,即虛擬主機。
  • 請求體: post put等請求攜帶的數據

2019-06-14-11-33-37

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

請求報文有4部分組成:

  • 響應行
  • 響應頭
  • 空行
  • 響應體

2019-06-14-11-37-02

  • 響應行: 由協議版本,狀態碼和狀態碼的原因短語組成,例如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攔截秘鑰。

非對稱加密:

  1. 私鑰 + 公鑰= 密鑰對
  2. 即用私鑰加密的數據,只有對應的公鑰才能解密,用公鑰加密的數據,只有對應的私鑰才能解密
  3. 因為通信雙方的手裡都有一套自己的密鑰對,通信之前雙方會先把自己的公鑰都先發給對方
  4. 然後對方再拿著這個公鑰來加密數據響應給對方,等到到了對方那裡,對方再用自己的私鑰進行解密

非對稱加密雖然安全性更高,但是帶來的問題就是速度很慢,影響性能。

解決方案:

那麼結合兩種加密方式,將對稱加密的密鑰使用非對稱加密的公鑰進行加密,然後發送出去,接收方使用私鑰進行解密得到對稱加密的密鑰,然後雙方可以使用對稱加密來進行溝通。

此時又帶來一個問題,中間人問題:

如果此時在客戶端和伺服器之間存在一個中間人,這個中間人只需要把原本雙方通信互發的公鑰,換成自己的公鑰,這樣中間人就可以輕鬆解密通信雙方所發送的所有數據。

所以這個時候需要一個安全的第三方頒發證書(CA),證明身份的身份,防止被中間人攻擊。

證書中包括:簽發者、證書用途、使用者公鑰、使用者私鑰、使用者的HASH演算法、證書到期時間等

2019-06-14-12-30-18

但是問題來了,如果中間人篡改了證書,那麼身份證明是不是就無效了?這個證明就白買了,這個時候需要一個新的技術,數字簽名。

數字簽名就是用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的連接存續期內始終存在,由客戶端和伺服器共同漸進地更新;
  • 每個新的首部鍵-值對要麼被追加到當前表的末尾,要麼替換表中之前的值。

你可以理解為只發送差異數據,而不是全部發送,從而減少頭部的信息量

2019-06-14-12-52-59

多路復用

HTTP 1.x 中,如果想併發多個請求,必須使用多個 TCP 鏈接,且瀏覽器為了控制資源,還會對單個功能變數名稱有 6-8個的TCP鏈接請求限制。

HTTP2中:

  • 同功能變數名稱下所有通信都在單個連接上完成。
  • 單個連接可以承載任意數量的雙向數據流。
  • 數據流以消息的形式發送,而消息又由一個或多個幀組成,多個幀之間可以亂序發送,因為根據幀首部的流標識可以重新組裝

2019-06-14-12-58-50

拓展閱讀:HTTP/2特性及其在實際應用中的表現


公眾號

想要實時關註筆者最新的文章和最新的文檔更新請關註公眾號程式員面試官,後續的文章會優先在公眾號更新.

簡歷模板: 關註公眾號回覆「模板」獲取

《前端面試手冊》: 配套於本指南的突擊手冊,關註公眾號回覆「fed」獲取

2019-08-12-03-18-41

本文由博客一文多發平臺 OpenWrite 發佈!


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Vue.js是一套構建用戶界面的漸進式框架。與其他重量級框架不同的是,Vue 採用自底向上增量開發的設計。Vue 的核心庫只關註視圖層,並且非常容易學習,非常容易與其它庫或已有項目整合。另一方面,Vue 完全有能力驅動採用單文件組件和Vue生態系統支持的庫開發的複雜單頁應用。 那麼在windows系 ...
  • 一、回調函數 優點:簡單,方便,易用 缺點:易造成回調函數地獄,回調函數中嵌套多個回調函數,因為多個非同步操作造成強耦合,代碼亂做一團,無法管理。 二、事件監聽 優點:與回調函數相比,事件監聽實現了代碼的解耦,方便代碼管理 缺點:使用不方便,每次都要手動地綁定和觸發事件 三、Promise 優點:將回 ...
  • 背景 現在手上在做的 React 項目因為年代久遠,用的 "Redux" ,寫代碼的體驗不太好,所以想升級一下引入 dva。以往使用 dva 都是使用 "dva cli" 直接生成 dva 項目,或者在使用 "ant design pro" 的時候使用 umi 直接生成 react + antd + ...
  • 理解javascript事件執行機制 眾所周知,js是一個單線程的語言,這意味著同一時間只能做一件事,但是我們又說js是非同步的。首先,單線程並不是沒有優點。作為瀏覽器腳本語言,JavaScript 的主要用途是與用戶互動,以及操作 DOM。這決定了它只能是單線程,否則會帶來很複雜的同步問題。比如,假 ...
  • 簡單的描述了淺拷貝和深拷貝的區別後,分別進行實現且所有方法都已進行試驗。 ...
  • CSS樣式 CSS概述 CSS Cascading Style Shees層疊樣式表 HTML定義網頁的內容,CSS定義內容的樣式。 內容和樣式相互分離,便於修改樣式。 CSS語法 註意:1.最後一條聲明可以沒有分號,但是為了以後修改方便,一般也加上分號。 2.為了使用樣式更加容易閱讀,可以將每條代 ...
  • 前言 設計前端組件是最能考驗開發者基本功的測試之一,因為調用Material design、Antd、iView 等現成組件庫的 API 每個人都可以做到,但是很多人並不知道很多常用組件的設計原理。 能否設計出通用前端組件也是區分前端工程師和前端api調用師的標準之一,那麼應該如何設計出一個通用組件 ...
  • 前言 雙向綁定 其實已經是一個老掉牙的問題了,只要涉及到MVVM框架就不得不談的知識點,但它畢竟是Vue的三要素之一. Vue三要素 響應式: 例如如何監聽數據變化,其中的實現方法就是我們提到的雙向綁定 模板引擎: 如何解析模板 渲染: Vue如何將監聽到的數據變化和解析後的HTML進行渲染 可以實 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...