HTTP協(xié)議常問(wèn)的面試題（吐血整理）

1、http協(xié)議請(qǐng)求方式 ：

HTTP1.0定義了三種請(qǐng)求方法： GET, POST 和 HEAD方法 HTTP1.1新增了五種請(qǐng)求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT下面是它們的作用（背的時(shí)候可以挑常見(jiàn)的請(qǐng)求去背誦）GET: 通常用于請(qǐng)求服務(wù)器發(fā)送某些資源 POST: 發(fā)送數(shù)據(jù)給服務(wù)器 PUT: 用于新增資源或者使用請(qǐng)求中的有效負(fù)載替換目標(biāo)資源的表現(xiàn)形式 PATCH: 用于對(duì)資源進(jìn)行部分修改 DELETE: 用于刪除指定的資源 HEAD: 請(qǐng)求資源的頭部信息, 并且這些頭部與 HTTP GET 方法請(qǐng)求時(shí)返回的一致. 該請(qǐng)求方法的一個(gè)使用場(chǎng)景是在下載一個(gè)大文件前先獲取其大小再?zèng)Q定是否要下載, 以此可以節(jié)約帶寬資源 OPTIONS: 用于獲取目的資源所支持的通信選項(xiàng) CONNECT: HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器 TRACE: 回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷

2、GET和POST有什么區(qū)別？

數(shù)據(jù)傳輸方式不同：GET請(qǐng)求通過(guò)URL傳輸數(shù)據(jù)，而POST的數(shù)據(jù)通過(guò)請(qǐng)求體傳輸。安全性不同：POST的數(shù)據(jù)因?yàn)樵谡?qǐng)求主體內(nèi)，所以有一定的安全性保證，而GET的數(shù)據(jù)在URL中，通過(guò)歷史記錄，緩存很容易查到數(shù)據(jù)信息。數(shù)據(jù)類型不同：GET只允許 ASCII 字符，而POST無(wú)限制GET無(wú)害： 刷新、后退等瀏覽器操作GET請(qǐng)求是無(wú)害的，POST可能重復(fù)提交表單特性不同：GET是安全（這里的安全是指只讀特性，就是使用這個(gè)方法不會(huì)引起服務(wù)器狀態(tài)變化）且冪等（冪等的概念是指同一個(gè)請(qǐng)求方法執(zhí)行多次和僅執(zhí)行一次的效果完全相同），而POST是非安全非冪等

3、什么是無(wú)狀態(tài)協(xié)議，HTTP 是無(wú)狀態(tài)協(xié)議嗎，怎么解決

無(wú)狀態(tài)協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息。狀態(tài)協(xié)議解決辦法：通過(guò)1、Cookie 2、通過(guò)Session會(huì)話保存。

無(wú)狀態(tài)協(xié)議(Stateless Protocol) 就是指瀏覽器對(duì)于事務(wù)的處理沒(méi)有記憶能力。舉個(gè)例子來(lái)說(shuō)就是比如客戶請(qǐng)求獲得網(wǎng)頁(yè)之后關(guān)閉瀏覽器，然后再次啟動(dòng)瀏覽器，登錄該網(wǎng)站，但是服務(wù)器并不知道客戶關(guān)閉了一次瀏覽器。 HTTP 就是一種無(wú)狀態(tài)的協(xié)議，他對(duì)用戶的操作沒(méi)有記憶能力。可能大多數(shù)用戶不相信，他可能覺(jué)得每次輸入用戶名和密碼登陸一個(gè)網(wǎng)站后，下次登陸就不再重新輸入用戶名和密碼了。這其實(shí)不是 HTTP 做的事情，起作用的是一個(gè)叫做 小甜餅(Cookie) 的機(jī)制。它能夠讓瀏覽器具有記憶能力。

4、UDP 和 TCP 的區(qū)別

UDP 是什么？UDP 的全稱是 User Datagram Protocol，用戶數(shù)據(jù)報(bào)協(xié)議。它不需要所謂的握手操作，從而加快了通信速度，允許網(wǎng)絡(luò)上的其他主機(jī)在接收方同意通信之前進(jìn)行數(shù)據(jù)傳輸。數(shù)據(jù)報(bào)是與分組交換網(wǎng)絡(luò)關(guān)聯(lián)的傳輸單元。UDP 的特點(diǎn)主要有： UDP 能夠支持容忍數(shù)據(jù)包丟失的帶寬密集型應(yīng)用程序 UDP 具有低延遲的特點(diǎn) UDP 能夠發(fā)送大量的數(shù)據(jù)包 UDP 能夠允許 DNS 查找，DNS 是建立在 UDP 之上的應(yīng)用層協(xié)議。TCP 是什么？TCP 的全稱是Transmission Control Protocol ，傳輸控制協(xié)議。它能夠幫助你確定計(jì)算機(jī)連接到 Internet 以及它們之間的數(shù)據(jù)傳輸。通過(guò)三次握手來(lái)建立 TCP 連接，三次握手就是用來(lái)啟動(dòng)和確認(rèn) TCP 連接的過(guò)程。一旦連接建立后，就可以發(fā)送數(shù)據(jù)了，當(dāng)數(shù)據(jù)傳輸完成后，會(huì)通過(guò)關(guān)閉虛擬電路來(lái)斷開(kāi)連接。TCP 的主要特點(diǎn)有： TCP 能夠確保連接的建立和數(shù)據(jù)包的發(fā)送 TCP 支持錯(cuò)誤重傳機(jī)制 TCP 支持擁塞控制，能夠在網(wǎng)絡(luò)擁堵的情況下延遲發(fā)送 TCP 能夠提供錯(cuò)誤校驗(yàn)和，甄別有害的數(shù)據(jù)包。TCP 和 UDP 的區(qū)別（重點(diǎn)來(lái)了）TCP 是面向連接的協(xié)議 。 UDP 是無(wú)連接的協(xié)議 TCP 在發(fā)送數(shù)據(jù)前先需要建立連接，然后再發(fā)送數(shù)據(jù) 。 UDP 無(wú)需建立連接就可以直接發(fā)送大量數(shù)據(jù) TCP 會(huì)按照特定順序重新排列數(shù)據(jù)包 。 UDP 數(shù)據(jù)包沒(méi)有固定順序，所有數(shù)據(jù)包都相互獨(dú)立 TCP 傳輸?shù)乃俣缺容^慢 。 UDP 的傳輸會(huì)更快 TCP 的頭部字節(jié)有 20 字節(jié) 。 UDP 的頭部字節(jié)只需要 8 個(gè)字節(jié) TCP 是重量級(jí)的，在發(fā)送任何用戶數(shù)據(jù)之前，TCP需要三次握手建立連接。 UDP 是輕量級(jí)的。沒(méi)有跟蹤連接，消息排序等。 TCP 會(huì)進(jìn)行錯(cuò)誤校驗(yàn)，并能夠進(jìn)行錯(cuò)誤恢復(fù) 。 UDP 也會(huì)錯(cuò)誤檢查，但會(huì)丟棄錯(cuò)誤的數(shù)據(jù)包。 TCP 有發(fā)送確認(rèn)。 UDP 沒(méi)有發(fā)送確認(rèn) TCP 會(huì)使用握手協(xié)議，例如 SYN，SYN-ACK，ACK。 UDP無(wú)握手協(xié)議 TCP 是可靠的，因?yàn)樗梢源_保將數(shù)據(jù)傳送到路由器。 UDP 中不能保證將數(shù)據(jù)傳送到目標(biāo)。

5、說(shuō)一下Http協(xié)議中302狀態(tài)？

http協(xié)議中，返回狀態(tài)碼302表示重定向。這種情況下，服務(wù)器返回的頭部信息中會(huì)包含一個(gè)Location字段，內(nèi)容是重定向到的url。

6、Http協(xié)議有什么組成？

請(qǐng)求報(bào)文包含三部分：請(qǐng)求行：包含請(qǐng)求方法、URI、HTTP版本信息；請(qǐng)求首部字段；請(qǐng)求內(nèi)容實(shí)體。

7、cookies機(jī)制和session機(jī)制的區(qū)別是什么？

（1）cookies數(shù)據(jù)保存在客戶端，session數(shù)據(jù)保存在服務(wù)端；

（2）cookies可以減輕服務(wù)器壓力，但是不安全，容易進(jìn)行cookies欺騙；

（3）session安全一點(diǎn)，但是占用服務(wù)器資源。

8、HTTP協(xié)議有什么特點(diǎn)？

（1）http無(wú)連接：限制每次連接只處理一個(gè)請(qǐng)求，服務(wù)端完成客戶端的請(qǐng)求后，即斷開(kāi)連接。（傳輸速度快，減少不必要的連接，但也意味著每一次訪問(wèn)都要建立一次連接，效率降低）；

（2）http無(wú)狀態(tài)：對(duì)于事務(wù)處理沒(méi)有記憶能力。每一次請(qǐng)求都是獨(dú)立的，不記錄客戶端任何行為；

（3）客戶端/服務(wù)端模型：客戶端支持web瀏覽器或其他任何客戶端；

（4）簡(jiǎn)單快速；

（5）靈活：可以傳輸任何類型的數(shù)據(jù)。

9、http和https有什么區(qū)別？

（1）https有ca證書(shū)，http一般沒(méi)有；

（2）http是超文本傳輸協(xié)議，信息是明文傳輸。https則是具有安全性的ssl加密傳輸協(xié)議；

（3）http默認(rèn)80端口，https默認(rèn)443端口。

10、為什么有了HTTP為什么還要HTTPS？

https是安全版的http，因?yàn)閔ttp協(xié)議的數(shù)據(jù)都是明文進(jìn)行傳輸?shù)?#xff0c;所以對(duì)于一些敏感信息的傳輸就很不安全，HTTPS就是為了解決HTTP的不安全而生的。

11、HTTP的keep-alive是干什么的？

在早期的HTTP/1.0中，每次http請(qǐng)求都要?jiǎng)?chuàng)建一個(gè)連接，而創(chuàng)建連接的過(guò)程需要消耗資源和時(shí)間，為了減少資源消耗，縮短響應(yīng)時(shí)間，就需要重用連接。在后來(lái)的HTTP/1.0中以及HTTP/1.1中，引入了重用連接的機(jī)制，就是在http請(qǐng)求頭中加入Connection: keep-alive來(lái)告訴對(duì)方這個(gè)請(qǐng)求響應(yīng)完成后不要關(guān)閉，下一次咱們還用這個(gè)請(qǐng)求繼續(xù)交流。協(xié)議規(guī)定HTTP/1.0如果想要保持長(zhǎng)連接，需要在請(qǐng)求頭中加上Connection: keep-alive。

keep-alive的優(yōu)點(diǎn)：

• 較少的CPU和內(nèi)存的使用（由于同時(shí)打開(kāi)的連接的減少了）
• 允許請(qǐng)求和應(yīng)答的HTTP管線化
• 降低擁塞控制 （TCP連接減少了）
• 減少了后續(xù)請(qǐng)求的延遲（無(wú)需再進(jìn)行握手）
• 報(bào)告錯(cuò)誤無(wú)需關(guān)閉TCP連

12、http的請(qǐng)求報(bào)文是什么樣的？

請(qǐng)求報(bào)文有4部分組成:

• 請(qǐng)求行

• 請(qǐng)求頭部

• 空行

• 請(qǐng)求體

• 請(qǐng)求行包括：請(qǐng)求方法字段、URL字段、HTTP協(xié)議版本字段。它們用空格分隔。例如，GET /index.html HTTP/1.1。

• 請(qǐng)求頭部:請(qǐng)求頭部由關(guān)鍵字/值對(duì)組成，每行一對(duì)，關(guān)鍵字和值用英文冒號(hào)“:”分隔

User-Agent：產(chǎn)生請(qǐng)求的瀏覽器類型。

Accept：客戶端可識(shí)別的內(nèi)容類型列表。

Host：請(qǐng)求的主機(jī)名，允許多個(gè)域名同處一個(gè)IP地址，即虛擬主機(jī)。

• 請(qǐng)求體: post put等請(qǐng)求攜帶的數(shù)據(jù)

13、http的響應(yīng)報(bào)文是什么樣的？

響應(yīng)報(bào)文有4部分組成:

• 響應(yīng)行

• 響應(yīng)頭

• 空行

• 響應(yīng)體

• 響應(yīng)行： 由協(xié)議版本，狀態(tài)碼和狀態(tài)碼的原因短語(yǔ)組成，例如HTTP/1.1 200 OK。

• 響應(yīng)頭：響應(yīng)部首組成

• 響應(yīng)體：服務(wù)器響應(yīng)的數(shù)據(jù)

14、聊一聊HTTP的部首有哪些？

通用首部字段（General Header Fields）：請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的首部

• Cache-Control 控制緩存 ?
• Connection 連接管理、逐條首部 ?

請(qǐng)求首部字段（Reauest Header Fields）:客戶端向服務(wù)器發(fā)送請(qǐng)求的報(bào)文時(shí)使用的首部

• User-Agent 客戶端程序信息 ?

• Host 請(qǐng)求資源所在服務(wù)器 ?

• If-Match 比較實(shí)體標(biāo)記（ETage） ?

  If-None-Match 比較實(shí)體標(biāo)記（ETage）與 If-Match相反 ?

  If-Modified-Since 比較資源更新時(shí)間（Last-Modified）?

  If-Unmodified-Since比較資源更新時(shí)間（Last-Modified），與 If-Modified-Since相反 ?

響應(yīng)首部字段（Response Header Fields）:從服務(wù)器向客戶端響應(yīng)時(shí)使用的字段

• Server 服務(wù)器的信息 ?
• Location 令客戶端重定向的URI ?

實(shí)體首部字段（Entiy Header Fields）:針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用首部

• Last-Modified 資源最后的修改資源 ?
• Expires 實(shí)體主體的過(guò)期資源 ?
• Allow 資源可支持http請(qǐng)求的方法 ?

15、聊一聊HTTP的狀態(tài)碼有哪些？

2XX 成功

• 200 OK，表示從客戶端發(fā)來(lái)的請(qǐng)求在服務(wù)器端被正確處理 ?
• 201 Created 請(qǐng)求已經(jīng)被實(shí)現(xiàn)，而且有一個(gè)新的資源已經(jīng)依據(jù)請(qǐng)求的需要而建立
• 202 Accepted 請(qǐng)求已接受，但是還沒(méi)執(zhí)行，不保證完成請(qǐng)求
• 204 No content，表示請(qǐng)求成功，但響應(yīng)報(bào)文不含實(shí)體的主體部分
• 206 Partial Content，進(jìn)行范圍請(qǐng)求 ?

3XX 重定向

• 301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
• 302 found，臨時(shí)性重定向，表示資源臨時(shí)被分配了新的 URL ?
• 303 see other，表示資源存在著另一個(gè) URL，應(yīng)使用 GET 方法丁香獲取資源
• 304 not modified，表示服務(wù)器允許訪問(wèn)資源，但因發(fā)生請(qǐng)求未滿足條件的情況
• 307 temporary redirect，臨時(shí)重定向，和302含義相同

4XX 客戶端錯(cuò)誤

• 400 bad request，請(qǐng)求報(bào)文存在語(yǔ)法錯(cuò)誤 ?
• 401 unauthorized，表示發(fā)送的請(qǐng)求需要有通過(guò) HTTP 認(rèn)證的認(rèn)證信息 ?
• 403 forbidden，表示對(duì)請(qǐng)求資源的訪問(wèn)被服務(wù)器拒絕 ?
• 404 not found，表示在服務(wù)器上沒(méi)有找到請(qǐng)求的資源 ?
• 408 Request timeout, 客戶端請(qǐng)求超時(shí)
• 409 Confict, 請(qǐng)求的資源可能引起沖突

5XX 服務(wù)器錯(cuò)誤

• 500 internal sever error，表示服務(wù)器端在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤 ?
• 501 Not Implemented 請(qǐng)求超出服務(wù)器能力范圍，例如服務(wù)器不支持當(dāng)前請(qǐng)求所需要的某個(gè)功能，或者請(qǐng)求是服務(wù)器不支持的某個(gè)方法
• 503 service unavailable，表明服務(wù)器暫時(shí)處于超負(fù)載或正在停機(jī)維護(hù)，無(wú)法處理請(qǐng)求
• 505 http version not supported 服務(wù)器不支持，或者拒絕支持在請(qǐng)求中使用的 HTTP 版本

16、TCP 三次握手和四次揮手

TCP 三次握手和四次揮手也是面試題的熱門考點(diǎn)，它們分別對(duì)應(yīng) TCP 的連接和釋放過(guò)程。下面就來(lái)簡(jiǎn)單認(rèn)識(shí)一下這兩個(gè)過(guò)程

TCP 三次握手

在了解具體的流程前，我們需要先認(rèn)識(shí)幾個(gè)概念消息類型 描述SYN 這個(gè)消息是用來(lái)初始化和建立連接的。 ACK 幫助對(duì)方確認(rèn)收到的 SYN 消息 SYN-ACK 本地的 SYN 消息和較早的 ACK 數(shù)據(jù)包 FIN 用來(lái)斷開(kāi)連接SYN：它的全稱是 Synchronize Sequence Numbers，同步序列編號(hào)。是 TCP/IP 建立連接時(shí)使用的握手信號(hào)。在客戶機(jī)和服務(wù)器之間建立 TCP 連接時(shí)，首先會(huì)發(fā)送的一個(gè)信號(hào)。客戶端在接受到 SYN 消息時(shí)，就會(huì)在自己的段內(nèi)生成一個(gè)隨機(jī)值 X。 SYN-ACK：服務(wù)器收到 SYN 后，打開(kāi)客戶端連接，發(fā)送一個(gè) SYN-ACK 作為答復(fù)。確認(rèn)號(hào)設(shè)置為比接收到的序列號(hào)多一個(gè)，即 X + 1，服務(wù)器為數(shù)據(jù)包選擇的序列號(hào)是另一個(gè)隨機(jī)數(shù) Y。 ACK：Acknowledge character, 確認(rèn)字符，表示發(fā)來(lái)的數(shù)據(jù)已確認(rèn)接收無(wú)誤。最后，客戶端將 ACK 發(fā)送給服務(wù)器。序列號(hào)被設(shè)置為所接收的確認(rèn)值即 Y + 1。

看了上面是不是人都傻掉了 接下來(lái)我用一個(gè)簡(jiǎn)單的例子去幫大家通俗易懂的去理解😄

小明👩 - 客戶端

小紅👨 - 服務(wù)端

小明給小紅打電話，接通了后，小明說(shuō)喂，能聽(tīng)到嗎，這就相當(dāng)于是連接建立。小紅給小明回應(yīng)，能聽(tīng)到，你能聽(tīng)到我說(shuō)的話嗎，這就相當(dāng)于是請(qǐng)求響應(yīng)。小明聽(tīng)到小紅的回應(yīng)后，好的，這相當(dāng)于是連接確認(rèn)。在這之后小明和小紅就可以通話/交換信息了。

TCP 四次揮手

在連接終止階段使用四次揮手，連接的每一端都會(huì)獨(dú)立的終止。下面我們來(lái)描述一下這個(gè)過(guò)程。

首先，客戶端應(yīng)用程序決定要終止連接(這里服務(wù)端也可以選擇斷開(kāi)連接)。這會(huì)使客戶端將 FIN 發(fā)送到服務(wù)器，并進(jìn)入 FIN_WAIT_1 狀態(tài)。當(dāng)客戶端處于 FIN_WAIT_1 狀態(tài)時(shí)，它會(huì)等待來(lái)自服務(wù)器的 ACK 響應(yīng)。然后第二步，當(dāng)服務(wù)器收到 FIN 消息時(shí)，服務(wù)器會(huì)立刻向客戶端發(fā)送 ACK 確認(rèn)消息。當(dāng)客戶端收到服務(wù)器發(fā)送的 ACK 響應(yīng)后，客戶端就進(jìn)入 FIN_WAIT_2 狀態(tài)，然后等待來(lái)自服務(wù)器的 FIN 消息服務(wù)器發(fā)送 ACK 確認(rèn)消息后，一段時(shí)間（可以進(jìn)行關(guān)閉后）會(huì)發(fā)送 FIN 消息給客戶端，告知客戶端可以進(jìn)行關(guān)閉。當(dāng)客戶端收到從服務(wù)端發(fā)送的 FIN 消息時(shí)，客戶端就會(huì)由 FIN_WAIT_2 狀態(tài)變?yōu)?TIME_WAIT 狀態(tài)。處于 TIME_WAIT 狀態(tài)的客戶端允許重新發(fā)送 ACK 到服務(wù)器為了防止信息丟失。客戶端在 TIME_WAIT 狀態(tài)下花費(fèi)的時(shí)間取決于它的實(shí)現(xiàn)，在等待一段時(shí)間后，連接關(guān)閉，客戶端上所有的資源（包括端口號(hào)和緩沖區(qū)數(shù)據(jù)）都被釋放。還是可以用上面那個(gè)通話的例子來(lái)進(jìn)行描述小明對(duì)小紅說(shuō)，我所有的東西都說(shuō)完了，我要掛電話了。 小紅說(shuō)，收到，我這邊還有一些東西沒(méi)說(shuō)。 經(jīng)過(guò)若干秒后，小紅也說(shuō)完了，小紅說(shuō)，我說(shuō)完了，現(xiàn)在可以掛斷了 小明收到消息后，又等了若干時(shí)間后，掛斷了電話。

總結(jié)

以上是生活随笔為你收集整理的HTTP协议常问的面试题（吐血整理）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。