HTTP1.1 Keep-Alive到底算不算長連接?

? ? ? 在基礎(chǔ)架構(gòu)部浸潤了半年，有一些認(rèn)知刷新想和童靴們交代一下， 不一定全面，僅代表此時(shí)的認(rèn)知， 也歡迎筒靴們提出看法。

本文聊一聊口嗨用語：“長連接、短連接”， 文章會(huì)按照下面的思維導(dǎo)圖來講述：

重點(diǎn)圍繞這兩個(gè)難點(diǎn)/思維誤區(qū)來整理知識(shí)體系。

• 長連接 vs 短連接
• Http1.1持久連接 vs ?WebSocket長連接

長連接 vs 短連接

長連接是指一個(gè)連接上連續(xù)發(fā)送多個(gè)數(shù)據(jù)包。

短連接是指雙方要數(shù)據(jù)交互時(shí)，建立一個(gè)連接，數(shù)據(jù)發(fā)送完畢，則斷開連接，即每次連接只完成一個(gè)單元的業(yè)務(wù)傳輸，有需要再建立新連接傳輸數(shù)據(jù)。

實(shí)際上長短連接都是針對(duì)TCP連接而言的，強(qiáng)調(diào)的是應(yīng)用層對(duì)下層TCP連接的使用姿勢，采用哪種連接由應(yīng)用根據(jù)自身情況決定。

長連接多用于操作頻繁、點(diǎn)對(duì)點(diǎn)的通信，而且連接數(shù)不能太多的情況。每次TCP連接都需要三次握手，這需要時(shí)間，如果每個(gè)操作都是短連接，再操作的話那么處理速度會(huì)降低很多，所以每次操作完后都不斷開，下次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接，如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤，而且頻繁的socket 創(chuàng)建也是對(duì)資源的浪費(fèi)。

而常規(guī)web網(wǎng)站一般都是短連接，這是由web站點(diǎn)的特征決定，web站點(diǎn)的客戶端數(shù)量大、訪問時(shí)間/頻次不固定，采用短連接能節(jié)省服務(wù)器資源；如果客戶端都維持長連接，可想而知，會(huì)占用多大的服務(wù)器資源， 所以并發(fā)量大，但每個(gè)用戶無需頻繁操作的時(shí)候使用短連接較好。

HTTP1.1 持久連接

早期HTTP1.0是純粹的TCP短連接的應(yīng)用，每個(gè)連接完成一次Http請(qǐng)求/響應(yīng)模型，這種方式頻繁的創(chuàng)建/銷毀連接無疑是有一定性能損耗的。

目前普遍應(yīng)用的HTTP1.1的Keep-alive官方術(shù)語上叫持久連接(英語：HTTP persistent connection，也稱作HTTP connection reuse)，國內(nèi)口嗨稱為“HTTP長連接”。

HTTP1.1keep-alive，我認(rèn)為是應(yīng)用層HTTP協(xié)議對(duì)于TCP連接的折中使用，是應(yīng)用層對(duì)下層TCP連接的復(fù)用協(xié)商。

• Http1.0 頻繁創(chuàng)建/銷毀連接確實(shí)給通信雙方帶來了不必要的性能損耗 ?#不必要#

• 直接使用典型的長連接又會(huì)給服務(wù)端帶來極大的壓力 ?#不允許#

故HTTP1.1的keep-alive一方面允許多個(gè)HTTP請(qǐng)求復(fù)用一個(gè)TCP連接， 另一方面又將這種復(fù)用時(shí)效交由客戶端/服務(wù)端在應(yīng)用層協(xié)商：應(yīng)用層每次請(qǐng)求/響應(yīng)均攜帶Connection：Keep-Alive標(biāo)頭滑動(dòng)續(xù)約。

HTTP 1.1 Keep-Alive的實(shí)質(zhì)是應(yīng)用層滑動(dòng)續(xù)約復(fù)用TCP連接？

大家不妨回想一下，常見的各種客戶端/服務(wù)器，均有KeepAliveTimeout這樣的參數(shù)

1. 客戶端IE默認(rèn)的KeepAliveTimeout是1分鐘[1]；
2. 服務(wù)器IIS默認(rèn)ConnectionTimeout時(shí)長是2min[2]
3. 服務(wù)器ASP.NetCore Kestrel默認(rèn)的KeepAliveTimeout=130s[3]
4. 服務(wù)器nginx默認(rèn)的keepalive_timeout=60s[4]

這些參數(shù)均能印證 HTTP Keep-Alive 是一種對(duì)于TCP連接的滑動(dòng)續(xù)約復(fù)用。

這里面明眼人一看，1.2.4針對(duì)TCP Connection復(fù)用的滑動(dòng)超時(shí)時(shí)間是拍腦袋決定的，而第3點(diǎn)ASP.NET Core Kestrel作為.NETCore的寄宿服務(wù)器為什么是130s，有點(diǎn)意思，我給你們找出相關(guān)：?KestrelServerLimits.KeepAliveTimeout=130s[5]

典型的長連接Websocket

Websocket是一種典型的長連接，通過第一個(gè)HTTP Request建立了TCP連接之后，之后數(shù)據(jù)交互都不需要發(fā)送HTTP Request了，但是不需要發(fā)送 HTTP header就能交換數(shù)據(jù)顯然和原有的 HTTP 協(xié)議是有區(qū)別的，所以它需要對(duì)服務(wù)器和客戶端都進(jìn)行升級(jí)才能實(shí)現(xiàn)，這個(gè)協(xié)商是在Websocket數(shù)據(jù)傳輸之前就已經(jīng)完成：通過初次HTTP建立TCP連接的時(shí)候攜帶Upgrade標(biāo)頭來通知雙方提升協(xié)議。

Websocket也有keepalive機(jī)制，Websocket的keepalive的作用是在復(fù)雜的網(wǎng)絡(luò)環(huán)境中探測連接對(duì)端是否還存活。

旁白總結(jié)

1. 長短連接都是針對(duì)TCP連接而言，強(qiáng)調(diào)的是應(yīng)用層對(duì)于TCP連接的使用姿勢。
2. HTTP1.1?Keep-Alive是對(duì)TCP連接的折中使用，既不是短連接，也不能稱為典型的長連接。
3. HTTP1.1?Keep-Alive官方稱持久連接，我的觀點(diǎn)是HTTP1.1?Keep-Alive?是在應(yīng)用層對(duì)TCP連接進(jìn)行滑動(dòng)續(xù)約復(fù)用。
4. 典型的長連接Websocket在數(shù)據(jù)傳輸之前就完成了長連接確認(rèn)。
   

參考資料

IE默認(rèn)的KeepAliveTimeout是1分鐘: https://docs.microsoft.com/en-US/troubleshoot/browsers/change-keep-alive-time-out

IIS默認(rèn)ConnectionTimeout時(shí)長2min: https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525597

ASP.Net Core Kestrel默認(rèn)的KeepAliveTimeout=130s: https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.server.kestrel.core.kestrelserverlimits.keepalivetimeout?view=aspnetcore-6.0#Microsoft_AspNetCore_Server_Kestrel_Core_KestrelServerLimits_KeepAliveTimeout

nginx默認(rèn)的keepalive_timeout=60s: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout

KestrelServerLimits.KeepAliveTimeout=130s: https://github.com/dotnet/runtime/issues/52267

點(diǎn)個(gè)在看你最好看

僅代表此刻認(rèn)知，文章永久更新地址，請(qǐng)移步原文！！