面試之HTTP基礎（不斷完善中）

目錄

• 1. HTTP狀態碼
• 2.Cookie和Session
  • Cookie
  • Session
• 3.短鏈接與長鏈接
• 4.HTTPs
  • 加密
• 5.Http和https的區別
• 6.HTTP/1.0 與 HTTP/1.1 的區別
• 7.HTTP2.0
  • HTTP/1.x 缺陷
  • 二進制分幀層
  • 安全
  • 冪等性
  • 可緩存

HTTP全稱是Hyper Text Transfer Protocol（超文本傳輸協議），它容許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。這也是Web程序之間的最基本的一個通訊協議，也是面試常考點。
@

1. HTTP狀態碼

服務器返回的 響應報文 中第一行爲狀態行，包含了狀態碼以及緣由短語，用來告知客戶端請求的結果。

2.Cookie和Session

Cookie

HTTP 協議是無狀態的，主要是爲了讓 HTTP 協議儘量簡單，使得它可以處理大量事務。HTTP/1.1 引入 Cookie 來保存狀態信息。
Cookie 是服務器發送到用戶瀏覽器並保存在本地的一小塊數據，它會在瀏覽器以後向同一服務器再次發起請求時被攜帶上，用於告知服務端兩個請求是否來自同一瀏覽器。因爲以後每次請求都會須要攜帶 Cookie 數據，所以會帶來額外的性能開銷（尤爲是在移動環境下）。
Cookie 曾一度用於客戶端數據的存儲，由於當時並無其它合適的存儲辦法而做爲惟一的存儲手段，但如今隨着現代瀏覽器開始支持各類各樣的存儲方式，Cookie 漸漸被淘汰。新的瀏覽器 API 已經容許開發者直接將數據存儲到本地，如使用 Web storage API （本地存儲和會話存儲）或 IndexedDB。

Session

用途

1. 會話狀態管理（如用戶登陸狀態、購物車、遊戲分數或其它須要記錄的信息）
2. 個性化設置（如用戶自定義設置、主題等）
3. 瀏覽器行爲跟蹤（如跟蹤分析用戶行爲等）

3.短鏈接與長鏈接

當瀏覽器訪問一個包含多張圖片的 HTML 頁面時，除了請求訪問 HTML 頁面資源，還會請求圖片資源。若是每進行一次 HTTP 通訊就要新建一個 TCP 鏈接，那麼開銷會很大。
長鏈接只須要創建一次 TCP 鏈接就能進行屢次 HTTP 通訊。
從 HTTP/1.1 開始默認是長鏈接的，若是要斷開鏈接，須要由客戶端或者服務器端提出斷開，使用 Connection : close；
在 HTTP/1.1 以前默認是短鏈接的，若是須要使用長鏈接，則使用 Connection : Keep-Alive。

4.HTTPs

HTTP 有如下安全性問題：

1. 使用明文進行通訊，內容可能會被竊聽；
2. 不驗證通訊方的身份，通訊方的身份有可能遭遇假裝；
3. 沒法證實報文的完整性，報文有可能遭篡改。

HTTPs並非新協議，而是讓HTTP先和SSL（Secure Sockets Layer）通訊，再由SSL和TCP通訊，也就是說HTTPs 使用了隧道進行通訊。
經過使用 SSL，HTTPs 具備了加密（防竊聽）、認證（防假裝）和完整性保護（防篡改）

加密

1. 對稱密鑰加密

對稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰。
優勢：運算速度快；
缺點：沒法安全地將密鑰傳輸給通訊方。

2.非對稱密鑰加密

非對稱密鑰加密，又稱公開密鑰加密（Public-Key Encryption），加密和解密使用不一樣的密鑰。
公開密鑰全部人均可以得到，通訊發送方得到接收方的公開密鑰以後，就可使用公開密鑰進行加密，接收方收到通訊內容後使用私有密鑰解密。
非對稱密鑰除了用來加密，還能夠用來進行簽名。由於私有密鑰沒法被其餘人獲取，所以通訊發送方使用其私有密鑰進行簽名，通訊接收方使用發送方的公開密鑰對簽名進行解密，就能判斷這個簽名是否正確。
優勢：能夠更安全地將公開密鑰傳輸給通訊發送方；
缺點：運算速度慢。

5.Http和https的區別

1. http是HTTP協議運行在TCP之上。全部傳輸的內容都是明文，客戶端和服務器端都沒法驗證對方的身份
2. https是HTTP運行在SSL/TLS之上，SSL/TLS運行在TCP之上。全部傳輸的內容都通過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。此外客戶端能夠驗證服務器端的身份
3. 若是配置了客戶端驗證，服務器方也能夠驗證客戶端的身份。
4. https協議須要到ca申請證書，通常免費證書不多，須要交費。
5. http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議
6. http和https使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。
7. http的鏈接很簡單,是無狀態的
8. HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全

6.HTTP/1.0 與 HTTP/1.1 的區別

詳細內容請見上文
HTTP/1.1 默認是長鏈接
HTTP/1.1 支持管線化處理
HTTP/1.1 支持同時打開多個 TCP 鏈接
HTTP/1.1 支持虛擬主機
HTTP/1.1 新增狀態碼 100
HTTP/1.1 支持分塊傳輸編碼
HTTP/1.1 新增緩存處理指令 max-age

7.HTTP2.0

HTTP/1.x 缺陷

HTTP/1.x 實現簡單是以犧牲性能爲代價的：

1. 客戶端須要使用多個鏈接才能實現併發和縮短延遲；
2. 不會壓縮請求和響應首部，從而致使沒必要要的網絡流量；
3. 不支持有效的資源優先級，導致底層 TCP 鏈接的利用率低下。

二進制分幀層

在通訊系統中，只有一個TCP鏈接存在，它承載了任意數量的數據雙向流（Stream）

• 一個數據流都有一個惟一標識符和可選的優先級信息，用於承載雙向信息。
• 消息（Message）是與邏輯請求或相應消息對應的完整的一系列幀

• 幀（Fram）是最小的通訊單位，來自不一樣數據流的幀能夠交錯發送，而後再根據每一個幀頭的數據流標識符從新組裝。

  服務端推送

  HTTP/2.0 在客戶端請求一個資源時，會把相關的資源一塊兒發送給客戶端，客戶端就不須要再次發起請求了。例如客戶端請求 page.html 頁面，服務端就把 script.js 和 style.css 等與之相關的資源一塊兒發給客戶端。
  

  首部壓縮

  HTTP/1.1 的首部帶有大量信息，並且每次都要重複發送。
  HTTP/2.0 要求客戶端和服務器同時維護和更新一個包含以前見過的首部字段表，從而避免了重複傳輸。
  不只如此，HTTP/2.0 也使用 Huffman 編碼對首部字段進行壓縮。
  

  8.GET 和 POST 比較

  做用

  GET 用於獲取資源，而 POST 用於傳輸實體主體。

  參數

  GET 和 POST 的請求都能使用額外的參數，可是 GET 的參數是以查詢字符串出如今 URL 中，而 POST 的參數存儲在實體主體中。不能由於 POST 參數存儲在實體主體中就認爲它的安全性更高，由於照樣能夠經過一些抓包工具（Fiddler）查看。
  由於 URL 只支持 ASCII 碼，所以 GET 的參數中若是存在中文等字符就須要先進行編碼。例如 中文 會轉換爲 %E4%B8%AD%E6%96%87，而空格會轉換爲 %20。POST 參考支持標準字符集。

  GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1
  POST /test/demo_form.asp HTTP/1.1
  Host: w3schools.com
  name1=value1&name2=value2

安全

安全的 HTTP 方法不會改變服務器狀態，也就是說它只是可讀的。
GET 方法是安全的，而 POST 卻不是，由於 POST 的目的是傳送實體主體內容，這個內容多是用戶上傳的表單數據，上傳成功以後，服務器可能把這個數據存儲到數據庫中，所以狀態也就發生了改變。
安全的方法除了 GET 以外還有：HEAD、OPTIONS。
不安全的方法除了 POST 以外還有 PUT、DELETE。

冪等性

冪等的 HTTP 方法，一樣的請求被執行一次與連續執行屢次的效果是同樣的，服務器的狀態也是同樣的。換句話說就是，冪等方法不該該具備反作用（統計用途除外）。
全部的安全方法也都是冪等的。
在正確實現的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。
GET /pageX HTTP/1.1 是冪等的，連續調用屢次，客戶端接收到的結果都是同樣的：

GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1

POST /add_row HTTP/1.1 不是冪等的，若是調用屢次，就會增長多行記錄：

POST /add_row HTTP/1.1   -> Adds a 1nd row
POST /add_row HTTP/1.1   -> Adds a 2nd row
POST /add_row HTTP/1.1   -> Adds a 3rd row

DELETE /idX/delete HTTP/1.1 是冪等的，即使不一樣的請求接收到的狀態碼不同：

DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1   -> Returns 404

可緩存

若是要對響應進行緩存，須要知足如下條件：

• 請求報文的 HTTP 方法自己是可緩存的，包括 GET 和 HEAD，可是 PUT 和 DELETE 不可緩存，POST 在多數狀況下不可緩存的。
• 響應報文的狀態碼是可緩存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
• 響應報文的 Cache-Control 首部字段沒有指定不進行緩存。