? 碼甲說??

? ? ? 在基礎架構部浸潤了半年，有一些認知刷新想和童靴們交代一下， 不一定全面，僅代表此時的認知， 也歡迎筒靴們提出看法。

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

重點圍繞這兩個難點/思維誤區(qū)來整理知識體系。

• 長連接 vs 短連接

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

長連接 vs 短連接

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

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

實際上長短連接都是針對TCP連接而言的，強調的是應用層對下層TCP連接的使用姿勢，采用哪種連接由應用根據自身情況決定。

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

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

HTTP1.1 持久連接

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

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

HTTP1.1keep-alive，我認為是應用層HTTP協(xié)議對于TCP連接的折中使用，是應用層對下層TCP連接的復用協(xié)商。

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

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

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

HTTP 1.1 Keep-Alive的實質是應用層滑動續(xù)約復用TCP連接？

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

客戶端IE默認的KeepAliveTimeout是1分鐘^[1]；

服務器IIS默認ConnectionTimeout時長是2min^[2]

服務器ASP.NetCore Kestrel默認的KeepAliveTimeout=130s^[3]

服務器nginx默認的keepalive_timeout=60s^[4]

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

這里面明眼人一看，1.2.4針對TCP Connection復用的滑動超時時間是拍腦袋決定的，而第3點ASP.NET Core Kestrel作為.NETCore的寄宿服務器為什么是130s，有點意思，我給你們找出相關：?KestrelServerLimits.KeepAliveTimeout=130s^[5]

典型的長連接Websocket

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

Websocket也有keepalive機制，Websocket的keepalive的作用是在復雜的網絡環(huán)境中探測連接對端是否還存活。

旁白總結

長短連接都是針對TCP連接而言，強調的是應用層對于TCP連接的使用姿勢。

HTTP1.1?Keep-Alive是對TCP連接的折中使用，既不是短連接，也不能稱為典型的長連接。

HTTP1.1?Keep-Alive官方稱持久連接，我的觀點是HTTP1.1?Keep-Alive?是在應用層對TCP連接進行滑動續(xù)約復用。

典型的長連接Websocket在數據傳輸之前就完成了長連接確認。

? ? ? ? ? ? ?文章某些觀點可能讓一些童鞋不適，歡迎表明態(tài)度，理性討論！！！

參考資料

[1]

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

[2]

IIS默認ConnectionTimeout時長2min: https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525597

[3]

ASP.Net Core Kestrel默認的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

[4]

nginx默認的keepalive_timeout=60s: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout

[5]

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

點個在看你最好看

僅代表此刻認知，文章永久更新地址，請移步原文！！

總結

以上是生活随笔為你收集整理的HTTP1.1 Keep-Alive到底算不算长连接？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。