共計 4339 個字符，預計需要花費 11 分鐘才能閱讀完成。

這篇文章主要講解了“HTTP 和 TCP 的長連接和短連接是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“HTTP 和 TCP 的長連接和短連接是什么”吧！

HTTP 協議與 TCP/IP 協議的關系

HTTP 的長連接和短連接本質上是 TCP 長連接和短連接。HTTP 屬于應用層協議，在傳輸層使用 TCP 協議，在網絡層使用 IP 協議。IP 協議主要解決網絡路由和尋址問題，TCP 協議主要解決如何在 IP 層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，并且順序與發出順序一致。TCP 有可靠，面向連接的特點。

如何理解 HTTP 協議是無狀態的

HTTP 協議是無狀態的，指的是協議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。也就是說，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。HTTP 是一個無狀態的面向連接的協議，無狀態不代表 HTTP 不能保持 TCP 連接，更不能代表 HTTP 使用的是 UDP 協議（無連接）。

什么是長連接、短連接？

短連接

連接 - 傳輸數據 - 關閉連接

HTTP 是無狀態的，瀏覽器和服務器每進行一次 HTTP 操作，就建立一次連接，但任務結束就中斷連接。

也可以這樣說：短連接是指 Socket 連接后發送后接收完數據后馬上斷開連接。

長連接

連接 - 傳輸數據 - 保持連接 – 傳輸數據 -。。。- 關閉連接。

長連接指建立 Socket 連接后不管是否使用都保持連接。

在 HTTP/1.0 中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次 HTTP 操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個 HTML 或其他類型的 Web 頁中包含有其他的 Web 資源，如 JavaScript 文件、圖像文件、CSS 文件等；當瀏覽器每遇到這樣一個 Web 資源，就會建立一個 HTTP 會話。

但從 HTTP/1.1 起，默認使用長連接，用以保持連接特性。使用長連接的 HTTP 協議，會在響應頭有加入這行代碼：

Connection:keep-alive

在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸 HTTP 數據的 TCP 連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive 不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如 Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。

HTTP 協議的長連接和短連接，實質上是 TCP 協議的長連接和短連接。

TCP 連接

當網絡通信時采用 TCP 協議時，在真正的讀寫操作之前，server 與 client 之間必須建立一個連接，當讀寫操作完成后，雙方不再需要這個連接 時它們可以釋放這個連接，連接的建立是需要 3 次握手的，而釋放則需要 4 次握手，所以說每個連接的建立都是需要資源消耗和時間消耗的。

經典的三次握手示意圖：

經典的四次握手關閉圖：

TCP 短連接

我們模擬一下 TCP 短連接的情況，client 向 server 發起連接請求，server 接到請求，然后雙方建立連接。client 向 server 發送消息，server 回應 client，然后一次讀寫就完成了，這時候雙方任何一個都可以發起 close 操作，不過一般都是 client 先發起 close 操作。為什么呢，一般的 server 不會回復完 client 后立即關閉連接的，當然不排除有特殊的情況。從上面的描述看，短連接一般只會在 client/server 間傳遞一次讀寫操作

短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。

TCP 長連接

接下來我們再模擬一下長連接的情況，client 向 server 發起連接，server 接受 client 連接，雙方建立連接。Client 與 server 完成一次讀寫之后，它們之間的連接并不會主動關閉，后續的讀寫操作會繼續使用這個連接。

首先說一下 TCP/IP 詳解上講到的 TCP ?；罟δ?，?；罟δ苤饕獮榉掌鲬锰峁掌鲬孟Ｍ揽蛻糁鳈C是否崩潰，從而可以代表客戶使用資源。如果客戶已經消失，使得服務器上保留一個半開放的連接，而服務器又在等待來自客戶端的數據，則服務器將應遠等待客戶端的數據，?；罟δ芫褪窃噲D在服務 器端檢測到這種半開放的連接。

如果一個給定的連接在兩小時內沒有任何的動作，則服務器就向客戶發一個探測報文段，客戶主機必須處于以下 4 個狀態之一：

客戶主機依然正常運行，并從服務器可達。客戶的 TCP 響應正常，而服務器也知道對方是正常的，服務器在兩小時后將?；疃〞r器復位。

客戶主機已經崩潰，并且關閉或者正在重新啟動。在任何一種情況下，客戶的 TCP 都沒有響應。服務端將不能收到對探測的響應，并在 75 秒后超時。服務器總共發送 10 個這樣的探測，每個間隔 75 秒。如果服務器沒有收到一個響應，它就認為客戶主機已經關閉并終止連接。

客戶主機崩潰并已經重新啟動。服務器將收到一個對其?；钐綔y的響應，這個響應是一個復位，使得服務器終止這個連接。

客戶機正常運行，但是服務器不可達，這種情況與 2 類似，TCP 能發現的就是沒有收到探查的響應。

長連接短連接操作過程

短連接的操作步驟是：

建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接

長連接的操作步驟是：

建立連接——數據傳輸…（保持連接）…數據傳輸——關閉連接

長連接和短連接的優點和缺點

由上可以看出，長連接可以省去較多的 TCP 建立和關閉的操作，減少浪費，節約時間。對于頻繁請求資源的客戶來說，較適用長連接。

不過這里存在一個問題，存活功能的探測周期太長，還有就是它只是探測 TCP 連接的存活，屬于比較斯文的做法，遇到惡意的連接時，?；罟δ芫筒粔蚴沽?。

在長連接的應用場景下，client 端一般不會主動關閉它們之間的連接，client 與 server 之間的連接如果一直不關閉的話，會存在一個問題，隨著客戶端連接越來越多，server 早晚有扛不住的時候，這時候 server 端需要采取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可 以避免一些惡意連接導致 server 端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累后端服務。

短連接對于服務器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在 TCP 的建立和關閉操作上浪費時間和帶寬。

長連接和短連接的產生在于 client 和 server 采取的關閉策略，具體的應用場景采用具體的策略，沒有十全十美的選擇，只有合適的選擇。

什么時候用長連接，短連接？

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

而像 WEB 網站的 http 服務一般都用短鏈接，因為長連接對于服務端來說會耗費一定的資源，而像 WEB 網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發量大，但每個用戶無需頻繁操作情況下需用短連好。

長連接和短連接的生命周期有多久？

短連接在建立連接后，完成一次讀寫就會自動關閉了。

正常情況下，一條 TCP 長連接建立后，只要雙不提出關閉請求并且不出現異常情況，這條連接是一直存在的，操作系統不會自動去關閉它，甚至經過物理網絡拓撲的改變之后仍然可以使用。所以一條連接保持幾天、幾個月、幾年或者更長時間都有可能，只要不出現異常情況或由用戶（應用層）主動關閉。

在編程中，往往需要建立一條 TCP 連接，并且長時間處于連接狀態。所謂的 TCP 長連接并沒有確切的時間限制，而是說這條連接需要的時間比較長。

怎樣檢測長連接是否中斷？

1、在應用層使用 heartbeat 來主動檢測

對于實時性要求較高的網絡通信程序，往往需要更加及時的獲取已經中斷的連接，從而進行及時的處理。但如果對方的連接異常中斷，往往是不能及時的得到對方連接已經中斷的信息，操作系統檢測連接是否中斷的時間間隔默認是比較長的，即便它能夠檢測到，但卻不符合我們的實時性需求，所以需要我們進行手工去不斷探測。

2、改變 socket 的 keepalive 選項，以使 socket 檢測連接是否中斷的時間間隔更小，以滿足我們的及時性需求。有關的幾個選項使用和解析如下：

A、我們在檢測對端以一種非優雅的方式斷開連接的時候，可以設置 SO_KEEPALIVE 屬性使得我們在 2 小時以后發現對方的 TCP 連接是否依然存在。用法如下：

keepAlive = 1；setsockopt(listenfd, SOL_SOCKET, SO_KEEPALIVE, (void*) keepAlive, sizeof(keepAlive));

B、如果我們不想使用這么長的等待時間，可以修改內核關于網絡方面的配置參數，也可設置 SOCKET 的 TCP 層（SOL_TCP）選項 TCP_KEEPIDLE、TCP_KEEPINTVL 和 TCP_KEEPCNT。

TCP_KEEPIDLE：開始首次 KeepAlive 探測前的 TCP 空閉時間（默認 2h）

TCP_KEEPINTVL：兩次 KeepAlive 探測間的時間間隔（默認 75s）

TCP_KEEPCNT：斷開前的 KeepAlive 探測次數

如果心跳函數要維護客戶端的存活，即服務器必須每隔一段時間必須向客戶段發送一定的數據，那么使用 SO_KEEPALIVE 是有很大的不足的。因為 SO_KEEPALIVE 選項指 此套接口的任一方向都沒有數據交換。在 Linux 2.6 系列上，上面話的理解是只要打開 SO_KEEPALIVE 選項的套接口端檢測到數據發送或者數據接受就認為是數據交換。因此在這種情況下使用 SO_KEEPALIVE 選項 檢測對方是否非正常連接是完全沒有作用的，在每隔一段時間發包的情況，keep-alive 的包是不可能被發送的。上層程序在非正常斷開的情況下是可以正常發送包到緩沖區的。非正常端開的情況是指服務器沒有收到 FIN 或者 RST 包。

感謝各位的閱讀，以上就是“HTTP 和 TCP 的長連接和短連接是什么”的內容了，經過本文的學習后，相信大家對 HTTP 和 TCP 的長連接和短連接是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！