淺談HTTP長鏈接

時間 2019-11-10

標籤淺談 http 鏈接欄目 HTTP/TCP 简体版

原文原文鏈接

淺談HTTP長鏈接

HTTP長鏈接這個說法好久以前就據說過，並且打開F12進行調試的時候也頻繁看到keep-alive的http請求。雖然常常遇到，不過對於長鏈接仍是處於一種懵懂狀態。正好今天上班比較閒，靜下心來仔細研究了一番。html

對長鏈接的理解

現在所使用的HTTP協議基本上都是1.1的，默認爲長鏈接。也就是說一個HTTP請求的響應頭裏面，默認會有這麼一行代碼：Connection:keep-alive。HTTP長鏈接容許了HTTP設備在請求結束以後將TCP鏈接保持在打開的狀態，以便爲以後的HTTP請求重用現存的鏈接。從本質上來說，HTTP僅僅是應用層的協議，TCP纔是真正的傳輸層協議，所以TCP纔有真正的長鏈接短鏈接的說法。json

短鏈接的步驟爲：創建鏈接——數據傳輸——關閉鏈接...創建鏈接——數據傳輸——關閉鏈接瀏覽器

長鏈接的步驟爲：創建鏈接——數據傳輸...(保存鏈接)...數據傳輸——關閉鏈接服務器

長鏈接的帶來的好處是顯而易見的，它複用了TCP通道。通俗的來講，使用短鏈接發起多個HTTP請求時，每次都會去從新創建TCP鏈接，這樣會形成嚴重的資源浪費。若採用長鏈接，什麼三次握手四次揮手可能只須要進行一次，這無疑減小了不少消耗。框架

固然，長鏈接也並非永久無限制的鏈接。服務器可以對長鏈接進行限制。koa

Connection:Keep-Alive
Keep-Alive:max=5,timeout=120

像上面這樣的HTTP響應頭，說明服務器最多還會爲另外5個事務保存鏈接打開的狀態或者保持鏈接打開狀態至空閒120秒後。async

測試

本着治學嚴謹的態度，我對此進行了測試，比較HTTP請求長鏈接與短鏈接之間的耗時。測試

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>Document</title>
</head>
<body>
  <button id="button">點擊發起請求</button>
</body>
<script>
  document.getElementById('button').onclick = () =>{
    let arr = [];
    let i = 1000
    while(i){
      arr.push(fetch('/json'));
      i--;
    }
    let start = new Date().getTime();
    Promise.all(arr).then(()=>{
      let stop = new Date().getTime();
      console.log(stop-start);
    })
  }
</script>
</html>

點擊按鈕，向後臺發起1000次請求，計算出1000次請求的耗時。fetch

後臺使用了koa框架，代碼以下網站

//...以上省略一萬行代碼
//短鏈接
router.get('/json', async (ctx, next) => {
  ctx.set('Connection','close');
  ctx.body = {
    title: 'hello world'
  }
})

//不設置response.header，默認長鏈接
router.get('/json', async (ctx, next) => {
   ctx.body = {
    title: 'hello world'
  }
})

經過測試，短鏈接響應1000次請求的時間平均爲1900ms，長鏈接的平均響應時間爲1500ms。因而可知，長鏈接對於效率的提高是很是顯著的。（這個測試還意外的測試出了火狐瀏覽器對於多請求同時進行方面存在不足）。

若存在理解上的錯誤，歡迎指出，歡迎訪問個人我的網站

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。