HTTP相關面試題

原文地址

HTTP協議

在 OSI 七層模型中，HTTP協議位於最頂層的應用層中。經過瀏覽器訪問網頁就直接使用了 HTTP 協議。使用 HTTP 協議時，客戶端首先與服務端的 80 端口創建一個 TCP 鏈接，而後在這個鏈接的基礎上進行請求和應答，以及數據的交換。

HTTP 有兩個經常使用版本，分別是 1.0 和 1.1。主要區別在於 HTTP 1.0 中每次請求和應答都會使用一個新的 TCP 鏈接，而從 HTTP 1.1 開始，運行在一個 TCP 鏈接上發送多個命令和應答。所以大幅度減小了 TCP 鏈接的創建和斷開，提升了效率。

經常使用的HTTP方法有哪些？

• GET：用於請求訪問已經被URL（統一資源標識符）識別的資源，能夠經過URL傳參給服務器。
• POST：用於傳輸信息給服務器，主要功能與Get方法相似，但通常推薦POST方式。
• PUT：傳輸文件，報文主體包含文件內容，保存到對應URL位置。
• HEAD：獲取報文首部，與GET方法相似，只是不返回報文主體，通常用於驗證URL是否有效。
• DELET：刪除文件，與PUT方法相反，刪除對應URL位置的文件。
• OPTIONS：查詢相應URL支持的HTTP方法。

get和post的區別

1. get是從服務器上獲取數據，post是向服務器傳送數據。
2. get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中能夠看到。post是經過HTTP 的post機制，將表單內各個字段與其內容放置在HTML header內一塊兒傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對於get方式，服務器端用Request.QueryString獲取變量的值，對於post方式，服務器端用Request.Form獲取提交的數據。
4. get傳送的數據量較小，由於受URL限制，不能大於2KB，可是效率高。

post傳送的數據量較大，通常被默認爲不受限制，因此上傳文件時只能用post。但理論上，IIS4中最大量爲80KB，IIS5中爲100KB。

1. get安全性很是低，由於URL是可見的，可能會泄露私密信息，如密碼等，post安全性較高。可是執行效率卻比Post方法好。
2. get方式只能支持ASCII字符，向服務器傳的中文字符可能會亂碼。

post支持標準字符集，能夠正確傳遞中文字符。

1. get請求能夠被緩存，能夠被收藏爲書籤，但 post 不行。
2. get請求會保留在瀏覽器的歷史記錄中，post 不會。

SO：
一、get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數據提交方式；
二、在作數據查詢時，建議用Get方式；而在作數據添加、修改或刪除時，建議用Post方式

PS： POST 請求僅比 GET 請求略安全一點，它的數據不在 URL 中，但依然以明文的形式存放於 HTTP 的請求頭中。

HTTP請求報文與響應報文格式

請求報文包含三部分：

• 請求行：包含請求方法、URI、HTTP版本信息
• 請求首部字段
• 請求內容實體

響應報文包含三部分：

• 狀態行：包含HTTP版本、狀態碼、狀態碼的緣由短語
• 響應首部字段
• 響應內容實體

常見的HTTP相應狀態碼

200：請求被正常處理
204：請求被受理但沒有資源能夠返回
206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執行GET方法，相應報文中經過Content-Range指定範圍的資源。
301：永久性重定向
302：臨時重定向
303：與302狀態碼有類似功能，只是它但願客戶端在請求一個URI的時候，能經過GET方法重定向到另外一個URI上
304：發送附帶條件的請求時，條件不知足時返回，與重定向無關
307：臨時重定向，與302相似，只是強制要求使用POST方法
400：請求報文語法有誤，服務器沒法識別
401：請求須要認證
403：請求的對應資源禁止被訪問
404：服務器沒法找到對應資源
500：服務器內部錯誤
503：服務器正忙

常見HTTP首部字段

通用首部字段（請求報文與響應報文都會使用的首部字段）
Date：建立報文時間
Connection：鏈接的管理
Cache-Control：緩存的控制
Transfer-Encoding：報文主體的傳輸編碼方式

請求首部字段（請求報文會使用的首部字段）
Host：請求資源所在服務器
Accept：可處理的媒體類型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的內容編碼
Accept-Language：可接受的天然語言

響應首部字段（響應報文會使用的首部字段）
Accept-Ranges：可接受的字節範圍
Location：令客戶端從新定向到的URI
Server：HTTP服務器的安裝信息

實體首部字段（請求報文與響應報文的的實體部分使用的首部字段）
Allow：資源可支持的HTTP方法
Content-Type：實體主類的類型
Content-Encoding：實體主體適用的編碼方式
Content-Language：實體主體的天然語言
Content-Length：實體主體的的字節數
Content-Range：實體主體的位置範圍，通常用於發出部分請求時使用

一次完整的HTTP請求事務包含如下四個環節

1. 創建起客戶機和服務器鏈接。
2. 創建鏈接後，客戶機發送一個請求給服務器。
3. 服務器收到請求給予響應信息。

4.客戶端瀏覽器將返回的內容解析並呈現，斷開鏈接。

一次完整的HTTP請求所經歷的7個步驟

HTTP通訊機制是在一次完整的HTTP通訊過程當中，Web瀏覽器與Web服務器之間將完成下列7個步驟：

創建TCP鏈接->發送請求行->發送請求頭->（到達服務器）發送狀態行->發送響應頭->發送響應數據->斷TCP鏈接

創建TCP鏈接

在HTTP工做開始以前，Web瀏覽器首先要經過網絡與Web服務器創建鏈接，該鏈接是經過TCP來完成的，該協議與IP協議共同構建 Internet，即著名的TCP/IP協議族，所以Internet又被稱做是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議，根據規則， 只有低層協議創建以後才能，才能進行更層協議的鏈接，所以，首先要創建TCP鏈接，通常TCP鏈接的端口號是80。

Web瀏覽器向Web服務器發送請求行

一旦創建了TCP鏈接，Web瀏覽器就會向Web服務器發送請求命令。例如：GET /sample/hello.jsp HTTP/1.1。

Web瀏覽器發送請求頭

瀏覽器發送其請求命令以後，還要以頭信息的形式向Web服務器發送一些別的信息，以後瀏覽器發送了一空白行來通知服務器，它已經結束了該頭信息的發送。

Web服務器應答

客戶機向服務器發出請求後，服務器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態碼。

Web服務器發送應答頭

正如客戶端會隨同請求發送關於自身的信息同樣，服務器也會隨同應答向用戶發送關於它本身的數據及被請求的文檔。

Web服務器向瀏覽器發送數據

Web服務器向瀏覽器發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據。

Web服務器關閉TCP鏈接

通常狀況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP鏈接，而後若是瀏覽器或者服務器在其頭信息加入了這行代碼：
Connection:keep-alive

TCP鏈接在發送後將仍然保持打開狀態，因而，瀏覽器能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。

HTTP優化

• TCP複用：TCP鏈接複用是將多個客戶端的HTTP請求複用到一個服務器端TCP鏈接上，而HTTP複用則是一個客戶端的多個HTTP請求經過一個TCP鏈接進行處理。前者是負載均衡設備的獨特功能；然後者是HTTP 1.1協議所支持的新功能，目前被大多數瀏覽器所支持。
• 內容緩存：將常常用到的內容進行緩存起來，那麼客戶端就能夠直接在內存中獲取相應的數據了。
• 壓縮：將文本數據進行壓縮，減小帶寬
• SSL加密（SSL Acceleration）：使用SSL協議對HTTP協議進行加密，在通道內加密並加速
• TCP緩衝：經過採用TCP緩衝技術，能夠提升服務器端響應時間和處理效率，減小因爲通訊鏈路問題給服務器形成的鏈接負擔。

HTTP的缺點

• 通訊使用明文不加密，內容可能被竊聽
• 不驗證通訊方身份，可能遭到假裝
• 沒法驗證報文完整性，可能被篡改

HTTP1.1版本新特性

• 默認持久鏈接節省通訊量，只要客戶端服務端任意一端沒有明確提出斷 - 管線化，客戶端能夠同時發出多個HTTP請求，而不用一個個等待響應
• 斷點續傳 （實際上就是利用HTTP消息頭使用分塊傳輸編碼，將實體主體分塊傳輸）

Cookie和Session的區別

HTTP 是一種無狀態的鏈接，客戶端每次讀取 web頁面時，服務器都會認爲這是一次新的會話。但有時候咱們又須要持久保持某些信息，好比登陸時的用戶名、密碼，用戶上一次鏈接時的信息等。這些信息就由 Cookie 和 Session 保存。

Cookie

cookie其實是一小段文本信息。客戶端請求服務器，若是服務器須要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個cookie，客戶端瀏覽器會把cookie保存起來，當瀏覽器再次請求訪問該網站時，瀏覽器把請求的網站連同該cookie一同提交給服務器，服務器檢查該cookie，以此來辨認用戶狀態。

簡單來講，cookie的工做原理可總結以下：
1，client鏈接server
2，client生成cookie（有效期）,再次訪問時攜帶cookie
3, server根據cookie的信息識別用戶身份

Session

Session是服務器端使用的一種記錄客戶端狀態的機制，使用上比Cookie簡單一些。同一個客戶端每次和服務端交互時，不須要每次都傳回全部的 Cookie 值，而是隻要傳回一個 ID，這個 ID 是客戶端第一次訪問服務器的時候生成的，並且每一個客戶端是惟一的。這樣每一個客戶端就有了一個惟一的 ID，客戶端只要傳回這個 ID 就好了，這個 ID 一般是 name爲 JSESIONID 的一個 Cookie。Session依據這個id來識別是否爲同一用戶（只認ID不認人）。

區別：

1. cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
2. cookie不是很安全，別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙
   考慮到安全應當使用session。
3. session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
   考慮到減輕服務器性能方面，應當使用COOKIE。
4. 單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。