HTTP面試題整理（附答案，持續更新）

這是我參與8月更文挑戰的第6天，活動詳情查看：8月更文挑戰

計算機網絡的面試題已在程序員面試中家常便飯，這裏面的概念紛繁複雜，並且平時工做中不多用到，看了後很容易忘。

因而，我針對計算機網絡面試題作了一系列的整理，我參考了大量網絡上的資源以及經典參考書，爭取能把具體的面試題目給講明白講透徹，強調理解記憶，拒絕八股文！！。這一篇內容，既是自個人學習總結，也但願能幫助到正在複習面試的朋友。

本系列文章一共分爲兩篇，TCP篇，HTTP篇

HTTP篇

在瀏覽器中輸入url地址到顯示頁面的過程（重點）

整體來講分爲如下幾個過程:

• DNS解析
• TCP鏈接
• 發送HTTP請求
• 服務器處理請求並返回HTTP報文
• 瀏覽器解析渲染頁面
• 鏈接結束

文章能夠參考：segmentfault.com/a/119000000…

若是是Django應用能夠回答：

DNS查詢——TCP握手——HTTP請求——反向代理Nginx——uwsgi/gunicorn——web app響應——TCP揮手

HTTPS和HTTP有什麼區別（重點）

• 端口 ：HTTP的URL由http://起始且默認使用端口80，而HTTPS的URL由https://起始且默認使用端口443。
• 安全性和資源消耗： HTTP協議運行在TCP之上，全部傳輸的內容都是明文，客戶端和服務器端都沒法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS 運行在TCP之上。全部傳輸的內容都通過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。因此說，HTTP 安全性沒有 HTTPS高，可是 HTTPS 比HTTP耗費更多服務器資源。
  • 對稱加密：密鑰只有一個，加密解密爲同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
  • 非對稱加密：密鑰成對出現（且根據公鑰沒法推知私鑰，根據私鑰也沒法推知公鑰），加密解密使用不一樣密鑰（公鑰加密須要私鑰解密，私鑰加密須要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

HTTPS怎麼創建鏈接的（重點）

• 瀏覽器將支持的加密算法信息發送給服務器
• 服務器選擇一套瀏覽器支持的加密算法，以證書的形式回發瀏覽器
• 瀏覽器驗證證書合法性，並結合證書公鑰加密信息發送給服務器
• 服務器使用私鑰解密信息，驗證哈希，加密響應消息回發瀏覽器
• 瀏覽器解密響應消息，並對消息進行驗真，以後進行加密交互數據

更詳細的步驟以下：

HTTPS 在 HTTP 與 TCP 層之間加⼊了 TLS 協議。

HTTPS 是應⽤層協議，須要先完成 TCP 鏈接建⽴，而後⾛ TLS 握⼿過程後，才能建⽴通訊安全的鏈接。

事實上，不一樣的密鑰交換算法，TLS 的握⼿過程可能會有⼀些區別。

這⾥先簡單介紹下密鑰交換算法，由於考慮到性能的問題，因此雙⽅在加密應⽤信息時使⽤的是對稱加密密鑰，⽽對稱加密密鑰是不能被泄漏的，爲了保證對稱加密密鑰的安全性，因此使⽤⾮對稱加密的⽅式來保護對稱加密密鑰的協商，這個⼯做就是密鑰交換算法負責的。

TLS第一次握手

• 客戶端⾸先會發⼀個「Client Hello」消息。
• 消息⾥⾯有客戶端使⽤的 TLS 版本號、⽀持的密碼套件列表，以及⽣成的隨機數（Client Random），這個隨機數會被服務端保留，它是⽣成對稱加密密鑰的材料之⼀。

TLS第二次握手

• 當服務端收到客戶端的「Client Hello」消息後，會確認 TLS 版本號是否⽀持，和從密碼套件列表中選擇⼀個密碼套件，以及⽣成隨機數（Server Random）。
• 接着，返回「Server Hello」消息，消息⾥⾯有服務器確認的 TLS 版本號，也給出了隨機數（Server Random），而後從客戶端的密碼套件列表選擇了⼀個合適的密碼套件。其實這兩個隨機數是後續做爲⽣成「會話密鑰」的條件，所謂的會話密鑰就是數據傳輸時，所使⽤的對稱加密密鑰。
• 而後，服務端爲了證實⾃⼰的身份，會發送「Server Certificate」給客戶端，這個消息⾥含有數字證書。
• 隨後，服務端發了「Server Hello Done」消息，⽬的是告訴客戶端，我已經把該給你的東⻄都給你了，本次打招呼完畢。

TLS 第三次握⼿

• 客戶端驗證完證書後，認爲可信則繼續往下⾛。接着，客戶端就會⽣成⼀個新的隨機數 (pre-master)，⽤服務器的 RSA 公鑰加密該隨機數，經過「Change Cipher Key Exchange」消息傳給服務端。
• 服務端收到後，⽤ RSA 私鑰解密，獲得客戶端發來的隨機數 (pre-master)。
• ⾄此，客戶端和服務端雙⽅都共享了三個隨機數，分別是 Client Random、Server Random、pre-master。
• 因而，雙⽅根據已經獲得的三個隨機數，⽣成會話密鑰（Master Secret），它是對稱密鑰，⽤於對後續的 HTTP請求/響應的數據加解密。
• ⽣成完會話密鑰後，而後客戶端發⼀個「Change Cipher Spec」，告訴服務端開始使⽤加密⽅式發送消息。
• 而後，客戶端再發⼀個「Encrypted Handshake Message（Finishd）」消息，把以前全部發送的數據作個摘要，再⽤會話密鑰（master secret）加密⼀下，讓服務器作個驗證，驗證加密通訊是否可⽤和以前握⼿信息是否有被中途篡改過。
• 能夠發現，「Change Cipher Spec」以前傳輸的 TLS 握⼿數據都是明⽂，以後都是對稱密鑰加密的密⽂

TLS 第四次握⼿

• 服務器也是一樣的操做，發「Change Cipher Spec」和「Encrypted Handshake Message」消息，若是雙⽅都驗證加密和解密沒問題，那麼握⼿正式完成。
• 最後，就⽤「會話密鑰」加解密 HTTP 請求和響應了。

常見狀態碼（重點）

HTTP 狀態碼共有 5 種類型：

分類	分類描述
1XX	指示信息--表示請求正在處理
2XX	成功--表示請求已被成功處理完畢
3XX	重定向--要完成的請求須要進行附加操做
4XX	客戶端錯誤--請求有語法錯誤或者請求沒法實現，服務器沒法處理請求
5XX	服務器端錯誤--服務器處理請求出現錯誤

相應的 HTTP 狀態碼列表：

• 100：Continue 繼續。客戶端繼續處理請求
• 101：Switching Protocol 切換協議。服務器根據客戶端的請求切換到更高級的協議
• 200 OK 請求成功。請求所但願的響應頭或數據體將隨此響應返回
• 201 Created 請求以實現。而且有一個新的資源已經依據需求而創建
• 202 Accepted 請求已接受。已經接受請求，但還未處理完成
• 300 Multiple Choices 多種選擇。被請求的資源有一系列可供選擇的回饋信息，用戶或瀏覽器可以自行選擇一個首選地址進行重定向
• 301 Moved Permanently 永久移動。請求的資源已被永久地移動到新 URI，返回信息會包含新的 URI，瀏覽器會自動定向到新 URI
• 302 Found 臨時移動。與 301 相似。但資源只是臨時被移動，客戶端應繼續使用原有URI
• 303 See Other 查看其它地址。與301相似。使用GET和POST請求查看
• 304 Not Modified 未修改。若是客戶端發送了一個帶條件的 GET 請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼
• 400 Bad Request 客戶端請求的語法錯誤，服務器沒法理解；請求的參數有誤
• 401 Unauthorized 當前請求須要用戶驗證
• 402 Payment Required 該狀態碼是爲了未來可能的需求而預留的
• 403 Forbidden 服務器已經理解請求，可是拒絕執行它
• 404 Not Found 請求失敗，請求所但願獲得的資源未被在服務器上發現
• 405 Method Not Allowed 客戶端請求中的方法被禁止
• 406 Not Acceptable 請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體
• 500 Internal Server 服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理
• 501 Not Implemented 服務器不支持當前請求所須要的某個功能
• 502 Bad Gateway 做爲網關或者代理工做的服務器嘗試執行請求時，從遠程服務器接收到無效的響應
• 503 Service Unavailable 因爲臨時的服務器維護或者過載，服務器當前沒法處理請求，一段時間後可能恢復正常
• 504 Gateway Time-out 充當網關或代理的服務器，未及時從遠端服務器獲取請求
• 505 HTTP Version not supported 服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本

狀態碼301和302的區別？

• 301：永久移動。請求的資源已被永久的移動到新的URI，舊的地址已經被永久的刪除了。返回信息會包括新的URI，瀏覽器會自動定向到新的URI。從此新的請求都應使用新的URI代替。
• 302：臨時移動。與301相似，客戶端拿到服務端的響應消息後會跳轉到一個新的 URL 地址。但資源只是臨時被移動，舊的地址還在，客戶端應繼續使用原有URI。

HTTP2.0是什麼

• 二進制傳輸（增長傳輸效率，減小帶寬佔用）
• 多路複用內容數據，（包1-4 HTML 包5-8 CSS html數據 css數據）
• 服務端推送（訪問html，服務端push css js）

HTTP長鏈接和短鏈接，應用場景

在HTTP/1.0中默認使用短鏈接。也就是說，客戶端和服務器每進行一次HTTP操做，就創建一次鏈接，任務結束就中斷鏈接。當客戶端瀏覽器訪問的某個HTML或其餘類型的Web頁中包含有其餘的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會從新創建一個HTTP會話。

而從HTTP/1.1起，默認使用長鏈接，用以保持鏈接特性。使用長鏈接的HTTP協議，會在響應頭加入這行代碼：

Connection:keep-alive

在使用長鏈接的狀況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經創建的鏈接。Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。實現長鏈接須要客戶端和服務端都支持長鏈接。

HTTP協議的長鏈接和短鏈接，實質上是TCP協議的長鏈接和短鏈接。

如何區分不一樣的HTTP請求呢？Content-Length | Transfer-Encoding:chunked

文章參考：

• www.cnblogs.com/gotodsp/p/6…
• blog.csdn.net/luzhensmart…

HTTP/1.1 和 HTTP/1.0 的區別

• 緩存處理：在 HTTP/1.0 中主要使用 header 裏的 if-modified-Since, Expries 來作緩存判斷的標準。而 HTTP/1.1 請求頭中添加了更多與緩存相關的字段，從而支持更爲靈活的緩存策略，例如 Entity-tag, If-Unmodified-Since, If-Match, If-None-Match 等可供選擇的緩存頭來控制緩存策略。
• 節約帶寬： 當客戶端請求某個資源時，HTTP/1.0 默認將該資源相關的整個對象傳送給請求方，但不少時候可能客戶端並不須要對象的全部信息。而在 HTTP/1.1 的請求頭中引入了 range 頭域，它容許只請求部分資源，其使得開發者能夠多線程請求某一資源，從而充分的利用帶寬資源，實現高效併發。
• 錯誤通知的管理：HTTP/1.1 在 1.0 的基礎上新增了 24 個錯誤狀態響應碼，例如 414 表示客戶端請求中所包含的 URL 地址太長，以致於服務器沒法處理；410 表示所請求的資源已經被永久刪除。
• Host 請求頭：早期 HTTP/1.0 中認爲每臺服務器都綁定一個惟一的 IP 地址並提供單一的服務，請求消息中的 URL 並無傳遞主機名。而隨着虛擬主機的出現，一臺物理服務器上能夠存在多個虛擬主機，而且它們共享同一個 IP 地址。爲了支持虛擬主機，HTTP/1.1 中添加了 host 請求頭，請求消息和響應消息中應聲明這個字段，若請求消息中缺乏該字段時服務端會響應一個 404 錯誤狀態碼。
• 長鏈接：HTTP/1.0 默認瀏覽器和服務器之間保持短暫鏈接，瀏覽器的每次請求都須要與服務器創建一個 TCP 鏈接，服務器完成後當即斷開 TCP 鏈接。HTTP/1.1 默認使用的是持久鏈接，其支持在同一個 TCP 請求中傳送多個 HTTP 請求和響應。此以前的 HTTP 版本的默認鏈接都是使用非持久鏈接，若是想要在舊版本的 HTTP 協議上維持持久鏈接，則須要指定 Connection 的首部字段的值爲 Keep-Alive。

HTTP/1.X 和 HTTP/2.0 的區別

• 相比於 HTTP/1.X 的文本（字符串）傳送， HTTP/2.0 採用二進制傳送。客戶端和服務器傳輸數據時把數據分紅幀，幀組成了數據流，流具備流 ID 標識和優先級，經過優先級以及流依賴可以必定程度上解決關鍵請求被阻塞的問題。
• HTTP/2.0 支持多路複用。由於流 ID 的存在， 經過同一個 HTTP 請求能夠實現多個 HTTP 請求傳輸，客戶端和服務器能夠經過流 ID 來標識到底是哪一個流從而定位到是哪一個 HTTP 請求。
• HTTP/2.0 頭部壓縮。HTTP/2.0 經過 gzip 和 compress 壓縮頭部而後再發送，同時通訊雙方會維護一張頭信息表，全部字段都記錄在這張表中，在每次 HTTP 傳輸時只須要傳頭字段在表中的索引便可，大大減少了重傳次數和數據量。
• HTTP/2.0 支持服務器推送。 服務器在客戶端未經請求許可的狀況下，可預先向客戶端推送須要的內容，客戶端在退出服務時可經過發送復位相關的請求來取消服務端的推送。

cookie和session的區別

• Cookie
  • 是由服務器發給客戶端的特殊信息，以文本的形式存放在客戶端
  • 客戶端再次請求的時候，會把cookie回發
  • 服務器接收到後，會解析Cookie生成與客戶端相對應的內容
• Session的簡介
  • 服務器端的機制，在服務器上保存的信息
  • 解析客戶端請求並操做session id，按需保存狀態信息
• Session的實現方式
  • 使用Cookie來實現（JSESSIONID）
  • 使用URL回寫來實現
• Cookie和Session的區別
  • Cookie數據存放在客戶的瀏覽器上，Session數據放在服務器上
  • Session相對於Cookie更安全
  • 若考慮減輕服務器負擔，應當使用Cookie

GET請求和POST請求的區別

• HTTP報文層面：GET將請求信息放在URL（有長度限制）,POST放在報文體中
• 數據庫層面：GET符合冪等性和安全性，POST不符合
• 其餘層面：GET能夠被緩存、被存儲，而POST不行

參考資料

• 《圖解HTTP》
• 《圖解TCP/IP》
• 《網絡是怎樣鏈接的》
• leetcode-cn.com/leetbook/re…
• blog.csdn.net/qzcsu/artic…
• segmentfault.com/a/119000000…