前端校招準備--HTTP相關面試題總結

前言

 上一篇粗糙的總結了一下HTTP中有哪些內容，如今就來看看面試常常會被問到的是哪些問題吧，沒道題我都會給出相應的答案，若是隻是粗糙的解釋的話，我會給出相應的參考資料，下面開始吧~

正文

HTTP中經常使用的請求方法有哪些？哪些請求方法是安全的？爲何？

答：經常使用的請求方法有GET,POST,HEAD,PUT,DELETE。其中GET和HEAD是安全的，由於其餘的三個方法都會對服務器產生動做，GET和HEAD只是請求數據，POST和POUT都會給服務端發送報文主體。

HTTP中POST和GET方法有什麼區別？

答：主要有如下幾點區別：

• GET請求在頁面後退的時候是無害的（即不會再次發送請求），而POST會再次發送請求
• GET請求的參數是放在請求的URL中，而POST方法是放在請求體中
• GET請求在URL中傳遞參數時會有長度限制，而POST無限制（不是絕對的，只是相對來講）
• GET請求會被瀏覽器主動緩存，而POST不會
• GET請求的參數會保存在瀏覽器中，而POST的參數不會保存在瀏覽器中

在瀏覽器中輸入URL到頁面進行渲染的過程當中發生了什麼？

答：能夠參考下面這張圖理解：（圖片來自《HTTP權威指南》）

語言描述：通過了如下幾步

1. 瀏覽器解析主機名
2. DNS進行域名解析，即將語義化的主機名轉換成IP地址
3. 瀏覽器得到端口號
4. 瀏覽器根據獲得的ip地址和端口號發起TCP鏈接
5. 瀏覽器發起HTTP請求
6. 瀏覽器讀取服務器返回的響應報文
7. 瀏覽器對返回的HTML進行渲染
8. 瀏覽器斷開TCP鏈接

請簡單描述一下TCP的三次握手和四次揮手的過程，兩次握手能夠嗎？

答：詳細解答
 TCP的三次握手：

1. 客戶端發送一個SYN報文請求鏈接，變爲SYN_SEND狀態
2. 服務端接收到客戶端發送SYN包，進行確認事後，發送ACK報文，變爲SYN_RECV狀態
3. 客戶端接收到服務端的SYN和ACK報文後，發送ACK包進行確認，而後客戶端和服務端都變成ESTABLISHED狀態

 TCP的四次揮手：

1. 客戶端沒有數據要發送了，請求關閉鏈接，發送一個FIN報文，並進入FIN_WAIT_1狀態
2. 服務端接收到FIN報文後，發送ACK報文，而後進入CLOSE_WAIT狀態；客戶端接收到ACK報文後，進入FIN_WAIT_2狀態
3. 服務端判斷是否有數據發送給客戶端，若是有的話，就將數據發送給客戶端，再發送FIN報文；沒有的話就直接發送FIN報文，請求關閉鏈接，而後進入LAST_ACK狀態；
4. 客戶端接收到服務端的FIN報文後，發送ACK報文，而後客戶端進入TIME_WAIT狀態；服務端接收到ACK報文後，關閉鏈接，變爲CLOSED狀態，客戶端在2MSL後依然沒有收到回覆，也能夠關閉鏈接了。

 兩次握手能夠嗎？

 不能夠，三次握手主要是防止已通過期的請求再次鏈接到服務端而佔用資源形成浪費。若是是兩次握手的話，假設主機A在發送第一次請求時，因爲網絡滯留的問題卡住了，好久後沒有收到主機B的確認信息，因而又發送了第二次請求。過了一段時間後，第一個請求到達了主機B，主機B覺得是一次新的請求，就返回確認信息，可是因爲沒有第三次握手，只要主機B發出確認信息，就會鏈接，這個時候主機B一直等待着主機A發送信息，就會形成資源浪費。（參考資料）

TCP和UDP的區別是什麼？

答：主要有如下幾個方面的區別：

• 鏈接方面：TCP是面向鏈接的，而UDP是無鏈接的，即UDP在傳輸數據以前不須要像TCP那樣3次握手創建鏈接
• 可靠性：TCP比UDP更可靠，TCP能夠保證不丟包，會按照順序傳輸數據，這也是致使
• 資源消耗：TCP對系統資源要求比較高，而且消耗資源比較大；UDP要求不高，可是在網絡質量很差的狀況下比較容易丟包，消耗資源相對比較小
• 適用場景：TCP適用於HTTP，FTP以及郵件傳輸等等；而UDP比較適合於語音，視頻等
• 速度問題：TCP傳輸速度比較慢，效率低，在握手和揮手的過程當中會佔用不少時間；UDP傳輸速度比較快，因爲是無鏈接的，只有傳輸數據的過程
• 安全性：安全性和可靠性是不一樣的概念，因爲TCP的機制比較多，更容易受到攻擊；UDP相對來講就比較安全，可是也不能避免受到攻擊
• 鏈接形式：TCP是隻能一對一的發送，而UDP能夠是一對一，一對多，多對多

HTTP中常見的狀態碼有哪些？分別表示什麼意思？

答：常見的狀態碼有：

• 200：接收並響應成功
• 301：請求的資源已經換了URL，須要從新請求（永久重定向）
• 302：請求的資源臨時換了URL，須要從新請求（臨時重定向）
• 304：在緩存中有該資源，能夠直接獲取
• 403：該資源禁止訪問
• 404：該資源不存在

HTTP有什麼特色？

答：

• 簡單高效
• 靈活
• 無鏈接
• 無狀態

HTTP有什麼缺點？

答：有如下缺點：

• 一條鏈接上只能發送一個請求
• 請求只能從客戶端開始，客戶端不能夠接收除響應以外的指令
• 請求/響應首部未經壓縮就發送，首部信息越多形成的延遲越大
• 發送冗長的首部，每次互發相同的首部形成很大的浪費
• 通訊使用明文，內容可能會被竊聽
• 不驗證通訊方的身份，有可能會遭遇假裝
• 沒法驗證報文的完整性，有可能遭遇篡改

請描述AJAX實現原理

答：AJAX的實現核心在於XMLHttpRequest這個API，主要分爲如下幾個步驟（參考文章）：

1. 建立XMLHttpRequst對象
2. 初始化傳進來的參數
3. 使用open方法發送請求
4. 接收請求並調用onreadystatechange方法對返回成功以及失敗的狀況進行定義

什麼是HTTP持久化和管線化？

答：

• HTTP持久化是針對HTTP無鏈接的特色進行改進的，使用的是keep-live首部字段保持長鏈接
• HTTP管線化是針對HTTP每次只能是請求一次回答一次的模式進行改進，使得能夠連續發送屢次請求。

HTTP和HTTPS的關係以及HTTPS的實現原理

答：

• HTTPS和HTTP的關係

 HTTPS在HTTP的基礎上加上了SSL協議，使得HTTP通訊更加安全。針對HTTP沒法驗證通訊方的身份，沒法驗證報文的完整性以及容易被竊聽等安全方面的缺點，HTTPS添加了加密和認證機制，使得HTTP通訊更加安全。

• HTTPS通訊原理（加密機制，不包括認證機制以及驗證報文完整性機制，可參考這裏）

1. 客戶端發送請求
2. 服務端接收請求返回數字證書
3. 客戶端使用內置的CA解密證書，拿到公鑰
4. 若是證書沒有問題，就將本身的對稱祕鑰使用公鑰加密發送給服務端
5. 服務端使用私鑰進行解密
6. 客戶端和服務端使用對稱祕鑰進行通訊

webScoket是什麼？主要做用是什麼？

答：webScoket也是一種協議，用來解決要實現實時更新時，只能經過AJAX輪詢等方式的問題。使用這個協議就改變了只能客戶端發送請求，服務端接收請求的模式，在該協議中客戶端和服務端均可以發送請求和接收請求，從而實現實時推送（服務端有數據更新後就發送數據）的功能，基於該協議能夠大大的減小通訊量。

SSL有幾回握手？具體過程是怎樣的？

答：這個問題和HTTPS的實現原理能夠看作是同樣的，可是比較有針對性，如下是回答：
 SSL有4次握手，握手過程爲：

1. 客戶端請求SSL鏈接
2. 服務端發送包含公鑰的證書
3. 客戶端使用公鑰加密對稱祕鑰併發送給服務端
4. 服務端使用私鑰解密對稱祕鑰

總結

 這篇文章是一個動態更新的文章，看到有相關的問題我就會加上去，但願你們能持續關注喲~