2. 程式人生 > >TCP長連線與短連線、心跳機制

TCP長連線與短連線、心跳機制

阿新 • • 發佈：2018-11-05
1. TCP連線 當網路通訊時採用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連線，當讀寫操作完成後，雙方不再需要這個連線時它們可以釋放這個連線，連線的建立是需要三次握手的，而釋放則需要4次握手，所以說每個連線的建立都是需要資源消耗和時間消耗的。 經典的三次握手示意圖： 經典的四次握手關閉圖：   2. TCP短連線 我們模擬一下TCP短連線的情況，client向server發起連線請求，server接到請求，然後雙方建立連線。client向server傳送訊息，server迴應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起close操作。為什麼呢，一般的server不會回覆完client後立即關閉連線的，當然不排除有特殊的情況。從上面的描述看，短連線一般只會在client/server間傳遞一次讀寫操作
短連線的優點是：管理起來比較簡單，存在的連線都是有用的連線，不需要額外的控制手段   3.TCP長連線 接下來我們再模擬一下長連線的情況，client向server發起連線，server接受client連線，雙方建立連線。Client與server完成一次讀寫之後，它們之間的連線並不會主動關閉，後續的讀寫操作會繼續使用這個連線。 首先說一下TCP/IP詳解上講到的TCP保活功能，保活功能主要為伺服器應用提供，伺服器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。如果客戶已經消失，使得伺服器上保留一個半開放的連線，而伺服器又在等待來自客戶端的資料，則伺服器將應遠等待客戶端的資料，保活功能就是試圖在伺服器端檢測到這種半開放的連線。
如果一個給定的連線在兩小時內沒有任何的動作，則伺服器就向客戶發一個探測報文段，客戶主機必須處於以下4個狀態之一： 1.客戶主機依然正常執行，並從伺服器可達。客戶的TCP響應正常，而伺服器也知道對方是正常的，伺服器在兩小時後將保活定時器復位。 2.客戶主機已經崩潰，並且關閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，並在75秒後超時。伺服器總共傳送10個這樣的探測 ，每個間隔75秒。如果伺服器沒有收到一個響應，它就認為客戶主機已經關閉並終止連線。 3.客戶主機崩潰並已經重新啟動。伺服器將收到一個對其保活探測的響應，這個響應是一個復位，使得伺服器終止這個連線。
4.客戶機正常執行，但是伺服器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。 從上面可以看出，TCP保活功能主要為探測長連線的存活狀況，不過這裡存在一個問題，存活功能的探測週期太長，還有就是它只是探測TCP連線的存活，屬於比較斯文的做法，遇到惡意的連線時，保活功能就不夠使了。 在長連線的應用場景下，client端一般不會主動關閉它們之間的連線，Client與server之間的連線如果一直不關閉的話，會存在一個問題，隨著客戶端連線越來越多，server早晚有扛不住的時候，這時候server端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的連線，這樣可以避免一些惡意連線導致server端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連線數，這樣可以完全避免某個蛋疼的客戶端連累後端服務。 長連線和短連線的產生在於client和server採取的關閉策略，具體的應用場景採用具體的策略，沒有十全十美的選擇，只有合適的選擇。   4.心跳包 很多應用層協議都有HeartBeat機制，通常是客戶端每隔一小段時間向伺服器傳送一個數據包，通知伺服器自己仍然線上，並傳輸一些可能必要的資料。使用心跳包的典型協議是IM，比如QQ/MSN/飛信等協議。 心跳包 之所以叫心跳包是因為：它像心跳一樣每隔固定時間發一次，以此來告訴伺服器，這個客戶端還活著。事實上這是為了保持長連線，至於這個包的內容，是沒有什麼特別規定的，不過一般都是很小的包，或者只包含包頭的一個空包。 在TCP的機制裡面，本身是存在有心跳包的機制的，也就是TCP的選項：SO_KEEPALIVE。系統預設是設定的2小時的心跳頻率。但是它檢查不到機器斷電、網線拔出、防火牆這些斷線。而且邏輯層處理斷線可能也不是那麼好處理。一般，如果只是用於保活還是可以的。 心跳包一般來說都是在邏輯層傳送空的echo包來實現的。下一個定時器，在一定時間間隔下發送一個空包給客戶端，然後客戶端反饋一個同樣的空包回來，伺服器如果在一定時間內收不到客戶端傳送過來的反饋包，那就只有認定說掉線了。 其實，要判定掉線，只需要send或者recv一下，如果結果為零，則為掉線。但是，在長連線下，有可能很長一段時間都沒有資料往來。理論上說，這個連線是一直保持連線的，但是實際情況中，如果中間節點出現什麼故障是難以知道的。更要命的是，有的節點（防火牆）會自動把一定時間之內沒有資料互動的連線給斷掉。在這個時候，就需要我們的心跳包了，用於維持長連線，保活。 在獲知了斷線之後，伺服器邏輯可能需要做一些事情，比如斷線後的資料清理呀，重新連線呀……當然，這個自然是要由邏輯層根據需求去做了。 總的來說，心跳包主要也就是用於長連線的保活和斷線處理。一般的應用下，判定時間在30-40秒比較不錯。如果實在要求高，那就在6-9秒。   5.TCP協議的KeepAlive機制 學過TCP/IP的同學應該都知道，傳輸層的兩個主要協議是UDP和TCP，其中UDP是無連線的、面向packet的，而TCP協議是有連線、面向流的協議。 所以非常容易理解，使用UDP協議的客戶端（例如早期的“OICQ”，聽說OICQ.com這兩天被搶注了來著，好古老的回憶）需要定時向伺服器傳送心跳包，告訴伺服器自己線上。 然而，MSN和現在的QQ往往使用的是TCP連線了，儘管TCP/IP底層提供了可選的KeepAlive（ACK-ACK包）機制，但是它們也還是實現了更高層的心跳包。似乎既浪費流量又浪費CPU，有點莫名其妙。 具體查了下，TCP的KeepAlive機制是這樣的，首先它貌似預設是不開啟的，要用setsockopt將SOL_SOCKET.SO_KEEPALIVE設定為1才是開啟，並且可以設定三個引數tcp_keepalive_time/tcp_keepalive_probes/tcp_keepalive_intvl，分別表示連線閒置多久開始發keepalive的ack包、發幾個ack包不回覆才當對方死了、兩個ack包之間間隔多長，在我測試的Ubuntu Server 10.04下面預設值是7200秒（2個小時，要不要這麼蛋疼啊！）、9次、75秒。於是連線就了有一個超時時間視窗，如果連線之間沒有通訊，這個時間視窗會逐漸減小，當它減小到零的時候，TCP協議會向對方發一個帶有ACK標誌的空資料包（KeepAlive探針），對方在收到ACK包以後，如果連線一切正常，應該回復一個ACK；如果連接出現錯誤了（例如對方重啟了，連線狀態丟失），則應當回覆一個RST；如果對方沒有回覆，伺服器每隔intvl的時間再發ACK，如果連續probes個包都被無視了，說明連線被斷開了。 這裡有一篇非常詳細的介紹文章： http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO ，包括了KeepAlive的介紹、相關核心引數、C程式設計介面、如何為現有應用（可以或者不可以修改原始碼的）啟用KeepAlive機制，很值得詳讀。 這篇文章的2.4節說的是“Preventing disconnection due to network inactivity”，阻止因網路連線不活躍（長時間沒有資料包）而導致的連線中斷，說的是，很多網路裝置，尤其是NAT路由器，由於其硬體的限制（例如記憶體、CPU處理能力），無法保持其上的所有連線，因此在必要的時候，會在連線池中選擇一些不活躍的連線踢掉。典型做法是LRU，把最久沒有資料的連線給T掉。通過使用TCP的KeepAlive機制（修改那個time引數），可以讓連線每隔一小段時間就產生一些ack包，以降低被T掉的風險，當然，這樣的代價是額外的網路和CPU負擔。 前面說到，許多IM協議實現了自己的心跳機制，而不是直接依賴於底層的機制，不知道真正的原因是什麼。 就我看來，一些簡單的協議，直接使用底層機制就可以了，對上層完全透明，降低了開發難度，不用管理連線對應的狀態。而那些自己實現心跳機制的協議，應該是期望通過傳送心跳包的同時來傳輸一些資料，這樣服務端可以獲知更多的狀態。例如某些客戶端很喜歡收集使用者的資訊……反正是要發個包，不如再塞點資料，否則包頭又浪費了

相關推薦

TCP長連線與短連線、心跳機制

1. TCP連線 當網路通訊時採用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連線，當讀寫操作完成後，雙方不再需要這個連線時它們可以釋放這個連線，連線的建立是需要三次握手的，而釋放則需要4次握手，所以說每個連線的建立都是需要資源消耗和時間消耗的。 經典的三

15.TCP長連線與短連線、心跳機制

轉自： 1. TCP連線 當網路通訊時採用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連線，當讀寫操作完成後，雙方不再需要這個連線時它們可以釋放這個連線，連線的建立是需要三次握手的，而釋放則需要4次握手，所以說每個連線的建立都是需要資源消

Tcp長連線與短連線對高併發的影響

1、Tcp建立連線需要三次握手，斷開連線需要四次握手。 2、tcp建立連線後將會在作業系統核心記憶體中維護四元組物件（源ip，源port，目標ip，目標port）。 3、tcp在斷開連結時，主動斷開方四元組將會處於time_wait狀態，同時源port不可用，此由作業系統限

TCP長連線與短連線的區別

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

長連線與短連線的區別以及使用場景

首先介紹下短連結和長連線的區別： 短連線 連線->傳輸資料->關閉連線 比如HTTP是無狀態的的短連結，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連線，但任務結束就中斷連線。 具體就是 瀏覽器client發起並建立TCP連線 -> client傳送HttpRequest報文

長連線與短連線區別

HTTP協議與TCP/IP協議的關係 HTTP的長連線和短連線本質上是TCP長連線和短連線。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網路層使用IP協議。 IP協議主要解決網路路由和定址問題，TCP協議主要解決如何在IP層之上可靠地傳遞資料包，使得網路上接收端收到傳

HTTP 長連線與短連線

1. HTTP協議與TCP/IP協議的關係 　　HTTP的長連線和短連線本質上是TCP長連線和短連線。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網路層使用IP協議。IP協議主要解決網路路由和定址問題，TCP協議主要解決如何在IP層之上可靠的傳遞資料包，使在網路上

JAVA長連線與短連線

https://blog.csdn.net/sinat_29970905/article/details/80808765 長連線，指在一個連線上可以連續傳送多個數據包，在連線保持期間，如果沒有資料包傳送，需要雙方發鏈路檢測包。 1、開發的大多數網站action請求資料都是短連線：

C語言socket長連結與短連線

、一個最簡單的長連線與心跳保持的示例程式/*! ****************************************************************************** ****************************************************

會話的長連線與短連線詳解

1. HTTP協議與TCP/IP協議的關係 HTTP的長連線和短連線本質上是TCP長連線和短連線。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網路層使用IP協議。IP協議主要解決網路路由和定址問題，TCP協議主要解決如何在IP層之上可靠的傳遞資料包，使在網路上的

HTTP協議中的長連線與短連線

長連線與短連線 長連線：client方與server方先建立連線，連線建立後不斷開，然後再進行報文傳送和接收。這種方式下由於通訊連線一直存在。此種方式常用於P2P通訊。 短連線：Client方與server每進行一次報文收發交易時才進行通訊連線，交易完畢後立即斷開連線

HTTP協議中長連線與短連線的區別

在HTTP/1.0中, 預設使用的是短連線.也就是說, 瀏覽器和伺服器每進行一次HTTP操作, 就建立一次連線, 但任務結束就中斷連線.如果客戶端瀏覽器訪問的某個HTML或其他型別的 Web 頁中包含有其他的Web資源，如js檔案、影象檔案、CSS檔案等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP

長連線 、短連線、心跳機制與斷線重連（轉載） Socket的長連線和短連線

概述 可承遇到，不知什麼原因，一個夜晚，機房中，大片的遠端呼叫連線斷開。 第二天早上，使用者訪問高峰，大部分伺服器都在獲取連線，造成大片網路阻塞。 服務崩潰，慘不忍睹的景象。 本文將從長連線和短連線的概念切入，再到長連線與短連線的區別，以及應用場景，引出心跳機制和斷線重連，給出程式碼實現。 從原

Python--長連線與短連結(TCP)

HTTP的長連線和短連線本質上是TCP長連線和短連線 1.短連結 瀏覽器和伺服器每進行一次HTTP操作，就建立一次連線，但任務結束就中斷連線。如果客戶端瀏覽器訪問的某個HTML或其他型別的 Web頁中包含有其他的Web資源，如JavaScript檔案、影象檔案

tcp的長連線和短連線

tcp長連線和短連線 TCP在真正的讀寫操作之前，server與client之間必須建立一個連線，當讀寫操作完成後，雙方不再需要這個連線時它們可以釋放這個連線，連線的建立通過三次握手，釋放則需要四次握手，所以說每個連線的建立都是需要資源消耗和時間消耗的。 TCP通訊的整個過程，如下圖: 1. TCP

http和Tcp的長連線和短連線

轉自：https://www.cnblogs.com/fubaizhaizhuren/p/7523374.html http協議和tcp/ip 協議的關係 (1) http是應用層協議，tcp協議是傳輸層協議，ip協議是網路協議。 (2) IP協議主要解決網路路由和定址問題 (3)

go實現高效tcp伺服器（適合短連線）類似fasthttp，長連線的每個連線分配一個協程(標準庫中的http)

package main import ( "fmt" "net" "os" "time" ) const ( MAX_CONN_NUM = 10 ) //服務處理函式，如果處理過程過於複雜，可以啟動一定量的協程來做（協程

tcp長連線，短連線，http短輪詢，長輪詢

短連線和長連線： 長輪詢和短輪詢 所謂輪詢，即是在一個迴圈週期內不斷髮起請求來得到資料的機制。只要有請求的地方，都可以實現輪詢，譬如各種事件驅動模型。它的長短是在於請求的返回週期。 短輪詢 短輪詢指的是在迴圈週期內，不斷髮起請求，每一次請求都立即

TCP(HTTP)長連線和短連線區別和怎樣維護長連線

一、HTTP協議和TCP協議 HTTP的長連線和短連線本質上是TCP長連線和短連線。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網路層使用IP協議。IP協議主要解決網路路由和定址問題，TCP協議

談談HTTP協議中的短輪詢、長輪詢、長連線和短連線

---------------------  作者：左瀟龍  來源：CSDN  原文：https://blog.csdn.net/zuoxiaolong8810/article/details/65441709  版權宣告：本文為博主原創文章，轉載請附上博文連結！