前端面試-http協議

什麼是http協議

Web使用一種名爲HTTP（HyperText Transfer Protocol，超文本傳輸協議）的協議做爲規範，完成從客戶端到服務器等一系列運做流程。而協議是指規則的約定。能夠說，Web是創建在HTTP協議上通訊的。

如今是http3.0

TCP/IP 協議族

http是它們的一個子集。按層次分別分爲如下四層：

• 應用層（http、DNS）
• 傳輸層（數據傳輸，tcp的三次握手和四次揮手）
• 網絡層（選擇傳輸路線，IP協議）
• 數據鏈路層（處理硬件部分）

IP協議

做用是把各類數據包傳送給對方（根據IP地址、MAC地址）

TCP協議

爲了更容易傳送大數據，把數據分割成以報文段爲單位的數據包進行管理，可以確認數據是否到達對方（發起三次握手）

什麼是https，和http有什麼區別

HTTPS基於HTTP協議，經過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護&

- 內容加密：採用混合加密技術，中間者沒法直接查看明文內容
- 驗證身份：經過證書認證客戶端訪問的是本身的服務器
- 保護數據完整性：防止傳輸的內容被中間人冒充或者篡改  
複製代碼

區別：

• http使用明文通訊，https會對內容進行加密
• http不驗證通訊方的身份，https會經過認證來驗證
• http沒法證實報文的完整性，有可能已經被篡改，https保護數據完整性：防止傳輸的內容被中間人冒充或者篡

TCP的三次握手

一個由客戶端發出的請求,會通過 http協議包裝一層，TCP協議包裝一層，IP協議包裝一層，以太網再包裝一層，和發快遞是同樣的，這個過程稱爲封裝，包裝好以後就上路了（經過物理層傳輸），到達服務器就開始拆開這個快遞，從外到內。這個過程任何人沒法絕對掌握數據是否可靠，因此要經過TCP三次握手

一、發送端發送一個帶SYN（synchronize）標誌的數據包給對方

二、接收端收到後，回傳一個帶有SYN/ACK（acknowledgement）標誌的數據包已示傳達確認信息

三、發送端再回傳一個帶ACK標誌的數據包，表明握手結束

若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包

TCP的四次揮手

客戶端或服務器都可主動發起揮手動做。

（1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送。

（2）服務器B收到這個FIN，它發回一個ACK

（3）服務器B關閉與客戶端A的鏈接，發送一個FIN給客戶端A。

（4）客戶端A發回ACK報文確認。

HTTP2.0和HTTP1.X相比的新特性

狀態碼

表示客戶端HTTP請求的返回結果、標識服務器處理是否正常、代表請求出現的錯誤等。

• 1XX 接收的請求正在處理

• 2XX 成功（這系列代表請求被正常處理了）

  • 200 OK，表示從客戶端發來的請求在服務器端被正確處理
  • 204 表示請求成功，服務器沒有資源返回（響應報文不含實體的主體部分）
  • 206 客戶端進行範圍請求，請求成功

• 3XX 重定向（代表瀏覽器要執行特殊處理） -301 moved permanently，永久性重定向，表示資源已被分配了新的 URL

  • 302 found，臨時性重定向，表示資源臨時被分配了新的 URL
  • 303 see other，表示資源存在着另外一個 URL，應使用 GET 方法獲取資源（對於301/302/303響應，幾乎全部瀏覽器都會刪除報文主體並自動用GET從新請求）
  • 304 not modified，服務端資源沒改變，返回客戶端緩存文件。
  • 307 臨時重定向，和302含義相似，可是指望客戶端保持請求方法不變向新的地址發出請求

• 4XX 客戶端錯誤，代表客戶端是發生錯誤的緣由所在

  • 400 請求報文存在語法錯誤
  • 401 unauthorized，（未受權） 請求要求身份驗證。 對於須要登陸的網頁，服務器可能返回此響應。
  • 403 forbidden，服務器拒絕請求。
  • 404 not found，表示在服務器上沒有找到請求的資源

• 5XX 服務器錯誤

  • 500 表示服務器端在執行請求時發生了錯誤
  • 501 表示服務器不支持當前請求所須要的某個功能
  • 503 代表服務器暫時處於超負載或正在停機維護，沒法處理請求

什麼是DNS

位於應用層的協議，提供域名到IP地址之間的解析服務

跨域問題

協議、域名、端口任意一個不一樣，會產生問題是由於瀏覽器的同源策略限制

• cors 跨域資源共享機制，ie10以上可用，有簡單請求和預檢請求兩種。

  • 簡單請求，

    • 請求方法是get、post、head（HEAD就是隻發送請求不會收到響應的一種請求方式），
    • 請求header只有幾個Accept、Accept-Language、Content-Language、Content-Type。
    • Content-Type標頭容許的值只能是： application/x-www-form-urlencoded、 multipart/form-data、 text/plain

    後端適配方案: 在respones header中添加Access-Control-Allow-Origin

  • 預檢請求，會在普通跨域請求前添加了個options請求，用來檢查前端headers的修改是否在後端容許範圍內 首先methods設置 PUT、DELETE、CONNECT、OPTIONS、TRACE會致使預檢請求 設置了Accept、Accept-Language、Content-Language、Content-Type 以外的headers中任一的配置，好比常見的token:authorization,緩存機制cache-contorl Content-Type設置了簡單請求不容許的值，如經常使用的application/json

預檢請求就須要後端設置更多的respones headers

- Access-Control-Allow-Methods表明可接受methods
- Access-Control-Allow-Headers表明可接受的headers修改
- Access-Control-Max-Age表明預檢的殘留時間，表明預檢以後能夠免預檢的時間
複製代碼

juejin.im/post/5c35f6… mp.weixin.qq.com/s/S9NYjMAXq…

• jsonp(JSON with padding) 把請求連接放在script裏

function jsonp(setting){
  setting.data = setting.data || {}
  setting.key = setting.key||'callback'
  setting.callback = setting.callback||function(){} 
  setting.data[setting.key] = '__onGetData__'

  window.__onGetData__ = function(data){
    setting.callback (data);
  }

  var script = document.createElement('script')
  var query = []
  for(var key in setting.data){
    query.push( key + '='+ encodeURIComponent(setting.data[key]) )
  }
  script.src = setting.url + '?' + query.join('&')
  document.head.appendChild(script)
  document.head.removeChild(script)

}

jsonp({
  url: 'http://api.jirengu.com/weather.php',
  callback: function(ret){
    console.log(ret)
  }
})
jsonp({
  url: 'http://photo.sina.cn/aj/index',
  key: 'jsoncallback',
  data: {
    page: 1,
    cate: 'recommend'
  },
  callback: function(ret){
    console.log(ret)
  }
})
複製代碼

缺點：只能get請求，須要後端配合，出錯沒法查找緣由

• nginx反向代理

websocket

用於服務器和客戶端的全雙工通訊，服務器和客戶端發起一次鏈接後，就會一直保持鏈接的狀態

• 服務器無需等待客戶端發起請求，就能夠向客戶端發送數據
• websoket的首部信息量不多，可減小通訊量

http的Upgrade字段：websocket，告知服務器通訊協議發生改變

URI、URL、URN

HTTP協議使用 URI 定位互聯網上的資源。概念：

URI(Universal Resource Identifier：統一資源標識符) URL(Universal Resource Locator：統一資源定位符) URN(Universal Resource Name：統一資源名稱)。

URI是由某個協議方案（http、ftp）表示的/資源的/定位標識符（/用來斷句，方便理解）。URI用字符串標識某一互聯網資源，而URL標示資源的地址（互聯網上所處的位置）。URL是URI的子集

WEB安全防範

xxs攻擊

跨站腳本攻，利用script標籤，將腳本注入到網頁的一種手段

CSRF 攻擊

假如掘金有個加關注的GET接口，id參數是關注人Id，以下：

https://juejin.im?id=5cd0438c6fb9a031ec6d3ab2

那我只須要在個人一個頁面裏面寫一個img標籤：

<img src="https://juejin.im?id=5cd0438c6fb9a031ec6d3ab2" />

CSRF攻擊是源於Web的隱式身份驗證機制！Web的身份驗證機制雖然能夠保證一個請求是來自於某個用戶的瀏覽器，但卻沒法保證該請求是用戶批准發送的。CSRF攻擊的問題通常是由服務端解決，防範 CSRF 攻擊能夠遵循如下幾種規則：

• Get 請求不用於對數據進行修改
• Cookie設置HTTP Only
• 接口設置禁止跨域
• 請求時附帶驗證信息，好比驗證碼或者 Token

點擊劫持

攻擊者將須要攻擊的網站經過 iframe 嵌入本身的網頁中，並將 iframe 設置爲透明，而後誘使用戶在該頁面上進行操做，此時用戶將在不知情的狀況下點擊透明的iframe頁面

防護方法： 使用一個HTTP響應頭——X-Frame-Options。X-Frame-Options能夠說是爲了解決點擊劫持而生的，它有三個可選的值：

• DENY：瀏覽器會拒絕當前頁面加載任何frame頁面；
• SAMEORIGIN：frame頁面的地址只能爲同源域名下的頁面；
• ALLOW-FROM origin：容許frame加載的頁面地址；

中間人攻擊

攻擊方同時與服務端和客戶端創建起了鏈接，並讓對方認爲鏈接是安全的，可是實際上整個通訊過程都被攻擊者控制了。攻擊者不只能得到雙方的通訊信息，還能修改通訊信息。中間人攻擊的本質是客戶端和服務端之間的認證和信任問題。

HTTPS做爲防止中間人攻擊的終極手段，引入證書機制解決了客戶端和服務端的信任問題，從而較爲有效的防止了中間人攻擊。

HTTP2.0和HTTP1.X相比的新特性

• 新的二進制格式： HTTP/1.x的解析是基於文本的。基於文本協議的解析存在自然缺陷，文本的表現形式有多樣性，要作到全面性考慮的場景必然不少。二進制則不一樣，只識別0和1的組合。基於這種考慮HTTP/2.0的協議解析採用二進制格式，方便且強大。
• 多路複用： HTTP/2.0支持多路複用，這是HTTP/1.1持久鏈接的升級版。多路複用，就是在一個 TCP 鏈接中能夠存在多條流，也就是能夠發送多個請求/響應。多路複用容許併發的發起多個請求，每一個請求及該請求的響應不須要等待其餘的請求或響應，避免了線頭阻塞問題。這樣某個請求任務耗時嚴重，不會影響到其它鏈接的正常執行,極大的提升傳輸性能。
• 頭部壓縮： HTTP/1.x的請求和響應頭部帶有大量信息，並且每次請求都要重複發送，HTTP/2.0使用encoder來減小須要傳輸的頭部大小，通信雙方各自cache一份頭部 fields表，既避免了重複頭部的傳輸，又減少了須要傳輸的大小。
• 服務端推送： 服務端推送就是把客戶端所須要的css/js/img資源伴隨着index.html一塊兒發送到客戶端，省去了客戶端重複請求的步驟（從緩存中取）。

HTTP/3.0

• 避免包阻塞： 多個數據在TCP鏈接上傳輸時，若一個數據包出現問題，TCP須要等待該包重傳後，才能繼續傳輸其它數據包。但在QUIC中，由於其基於UDP協議，UDP數據包在出問題須要重傳時，並不會對其餘數據包傳輸產生影響。
• 快速重啓會話： 普通基於tcp的鏈接，是基於兩端的ip和端口和協議來創建的。在網絡切換場景，例如手機端切換了無線網，使用4G網絡，會改變自己的ip，這就致使tcp鏈接必須從新建立。而QUIC協議使用特有的UUID來標記每一次鏈接，在網絡環境發生變化的時候，只要UUID不變，就能不須要握手，繼續傳輸數據。

HTTP報文

用於HTTP協議交互的信息被稱爲HTTP報文。客戶端的HTTP報文叫請求報文，服務端的HTTP報文叫響應報文。

請求報文 是由請求行（請求方法、協議版本）、請求首部（請求URI、客戶端信息等）和內容實體（用戶信息和資源信息等，可爲空）構成。

響應報文 是由狀態行（協議版本、狀態碼）、響應首部（服務器名稱、資源標識等）和內容實體（服務端返回的資源信息）構成。

請求方法

• GET：get方法通常用於獲取服務器資源
• POST：post方法通常用於傳輸實體主體
• PUT：put方法通常用於傳輸文件
• DELETE：delete方法用於刪除文件
• HEAD：head方法用於獲取報文首部，不返回報文主體
• OPTIONS：options方法用於詢問請求URI資源支持的方法

首部字段

• Cache-Control

控制緩存的行爲：no-cache（強制向服務器再次驗證）、no-store（不作任何緩存）、max-age=111111（資源可緩存最大時間 秒）、public（客戶端、代理服務器均可利用緩存）、private（代理服務器不可用緩存）

• Accept

能正確接收的媒體類型：application/json text/plain

• If-Match 與etag值一致時，服務器會處理請求
• If-Modified-Since 本地資源未修改返回 304（比較時間）
• If-None-Match If-None-Match與etag值不一致時，處理請求
• Set-Cookie 須要存在客戶端的信息，通常用於識別用戶身份
• Expires 內容的過時時間，本地可修改
• Last_modified 內容的最後修改時間
• ETag 資源標識，由服務器分配，資源發生變化時標識也會發生改變
• Content-Type 告訴瀏覽器用什麼方式解析返回的結果

hhtp緩存

強緩存和協商緩存，根據響應的header內容來決定的

強緩存：

不會發起請求。

cache-control(緩存控制): max-age=number(單位是秒)，它規定了一個到期時間，http1.1規範。

expires(到期時間)，它的值是個時間的GMT格式的時間字符串，老規範。

協商緩存：

會發起一次請求。

這兩組搭檔都是成對出現的，即第一次請求的響應頭帶上某個字段（Last-Modified或者Etag），則後續請求則會帶上對應的請求字段（If-Modified-Since或者If-None-Match），若響應頭沒有Last-Modified或者Etag字段，則請求頭也不會有對應的字段。

etag，它會把一個資源打上一個 「二維碼」

客戶端發送值爲ETag的If-None-Match header字段：

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

服務器將客戶端的ETag（做爲If-None-Match字段的值一塊兒發送）與其當前版本的資源的ETag進行比較，若是兩個值匹配（即資源未更改），服務器將返回不帶任何內容的304未修改狀態，告訴客戶端緩存版本可用（新鮮）。

Last-Modified 是一個響應首部，其中包含源頭服務器認定的資源作出修改的日期及時間。 它一般被用做一個驗證器來判斷接收到的或者存儲的資源是否彼此一致.和請求頭If-Modified-Since（若是有的話）對比，沒變返回304

當與 If-Modified-Since 一同使用的時候，If-None-Match 優先級更高（假如服務器支持的話）

強緩存如何清除呢？

這個簡單，只須要在URI後邊加上query字段便可，也就是咱們所謂的版本號。

手寫ajax請求

function callBack () {
  console.log(this.responseText)
}

let xhr = new XMLHttpRequest()
xhr.onload = callBack
xhr.open(method, url, true)
xhr.send()
複製代碼

HTTPS 握手過程當中，客戶端如何驗證證書的合法性

• 校驗證書的頒發機構是否受客戶端信任。
• 經過 CRL 或 OCSP 的方式校驗證書是否被吊銷。
• 對比系統時間，校驗證書是否在有效期內。
• 經過校驗對方是否存在證書的私鑰，判斷證書的網站域名是否與證書頒發的域名一致

參考：juejin.im/post/5cd043… github.com/Advanced-Fr…