- TCP連接
當網絡通信時采用TCP協議時,在真正的讀寫操作之前,server與client之間必須建立一個連接,當讀寫操作完成后,雙方不再需要這個連接 時它們可以釋放這個連接,連接的建立是需要三次握手的,而釋放則需要4次揮手,所以說每個連接的建立都是需要資源消耗和時間消耗的
經典的三次握手示意圖:
經典的四次揮手圖:
tcp的十種狀態圖:
注意:
當一端收到一個FIN,內核讓read返回0來通知應用層另一端已經終止了向本端的數據傳送;發送FIN通常是應用層對socket進行關閉的結果。
tcp的2MSL問題
- 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個狀態之一:
客戶主機依然正常運行,并從服務器可達。客戶的TCP響應正常,而服務器也知道對方是正常的,服務器在兩小時后將保活定時器復位。客戶主機已經崩潰,并且關閉或者正在重新啟動。在任何一種情況下,客戶的TCP都沒有響應。服務端將不能收到對探測的響應,并在75秒后超時。服務器總共發送10個這樣的探測 ,每個間隔75秒。如果服務器沒有收到一個響應,它就認為客戶主機已經關閉并終止連接。客戶主機崩潰并已經重新啟動。服務器將收到一個對其保活探測的響應,這個響應是一個復位,使得服務器終止這個連接。客戶機正常運行,但是服務器不可達,這種情況與2類似,TCP能發現的就是沒有收到探查的響應。從上面可以看出,TCP保活功能主要為探測長連接的存活狀況,不過這里存在一個問題,存活功能的探測周期太長,還有就是它只是探測TCP連接的存活,屬于比較斯文的做法,遇到惡意的連接時,保活功能就不夠使了。
在長連接的應用場景下,client端一般不會主動關閉它們之間的連接,Client與server之間的連接如果一直不關閉的話,會存在一個問 題,隨著客戶端連接越來越多,server早晚有扛不住的時候,這時候server端需要采取一些策略,如關閉一些長時間沒有讀寫事件發生的連接,這樣可 以避免一些惡意連接導致server端服務受損;如果條件再允許就可以以客戶端機器為顆粒度,限制每個客戶端的最大長連接數,這樣可以完全避免某個蛋疼的 客戶端連累后端服務。
長連接和短連接的產生在于client和server采取的關閉策略,具體的應用場景采用具體的策略,沒有十全十美的選擇,只有合適的選擇。
什么是“長連接”和“短連接”?
解釋1
所謂長連接指建立SOCKET連接后不管是否使用都保持連接,但安全性較差;
所謂短連接指建立SOCKET連接后發送后接收完數據后馬上斷開連接,一般銀行都使用短連接
解釋2
長連接就是指在基于tcp的通訊中,一直保持連接,不管當前是否發送或者接收數據。
而短連接就是只有在有數據傳輸的時候才進行連接,客戶-服務器通信/傳輸數據完畢就關閉連接。
解釋3
長連接和短連接這個概念好像只有移動的CMPP協議中提到了,其他的地方沒有看到過。通信方式 各網元之間共有兩種連接方式:長連接和短連接。所謂長連接,指在一個TCP連接上可以連續發送多個數據包,在TCP連接保持期間,如果沒有數據包發送,需要雙方發檢測包以維持此連接。短連接是指通信雙方有數據交互時,就建立一個TCP連接,數據發送完成后,則斷開此TCP連接,即每次TCP連接只完成一對 CMPP消息的發送。現階段,要求ISMG之間必須采用長連接的通信方式,建議SP與ISMG之間采用長連接的通信方式。
解釋4
短連接:比如http的,只是連接、請求、關閉,過程時間較短,服務器若是一段時間內沒有收到請求即可關閉連接。長連接:有些服務需要長時間連接到服務器,比如CMPP,一般需要自己做在線維持。
HTTP協議之長、短連接
一、長連接與短連接:
長連接:client方與server方先建立連接,連接建立后不斷開,然后再進行報文發送和接收。這種方式下由于通訊連接一直存在。此種方式常用于P2P通信。短連接:Client方與server每進行一次報文收發交易時才進行通訊連接,交易完畢后立即斷開連接。此方式常用于一點對多點通訊。C/S通信。二、長連接與短連接的操作過程:
短連接的操作步驟是:建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接 長連接的操作步驟是:建立連接——數據傳輸…(保持連接)…數據傳輸——關閉連接 三、長連接與短連接的使用時機:
長連接:長連接多用于操作頻繁,點對點的通訊,而且連接數不能太多的情況。每個TCP連接的建立都需要三次握手,每個TCP連接的斷開要四次握手。如果每次操作都要建立連接然后再操作的話處理速度會降低,所以每次操作后,下次操作時直接發送數據就可以了,不用再建立TCP連接。例如:數據庫的連接用長連接,如果用短連接頻繁的通信會造成socket錯誤,頻繁的socket創建也是對資源的浪費。短連接:web網站的http服務一般都用短連接。因為長連接對于服務器來說要耗費一定的資源。像web網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接更省一些資源。試想如果都用長連接,而且同時用成千上萬的用戶,每個用戶都占有一個連接的話,可想而知服務器的壓力有多大。所以并發量大,但是每個用戶又不需頻繁操作的情況下需要短連接。總之:長連接和短連接的選擇要根據需求而定。四、發送接收方式:
1、異步:報文發送和接收是分開的,相互獨立,互不影響的。這種方式又分兩種情況:異步雙工:接收和發送在同一個程序中,有兩個不同的子進程分別負責發送和接送。異步單工:接送和發送使用兩個不同的程序來完成。2、同步:報文發送和接收是同步進行,即報文發送后等待接送返回報文。同步方式一般需要考慮超時問題,試想我們發送報文以后也不能無限等待啊,所以我們要設定一個等待 時候。超過等待時間發送方不再等待讀返回報文。直接通知超時返回。五、報文格式:
通信報文格式多樣性更多,相應地就必須設計對應的讀寫報文的接收和發送報文函數。阻塞與非阻塞方式
1、非阻塞方式:讀函數不停的進行讀動作,如果沒有報文接收到,等待一段時間后超時返回,這種情況一般需要指定超時時間。2、阻塞方式:如果沒有接收到報文,則讀函數一直處于等待狀態,知道報文到達。循環讀寫方式
1、一次直接讀寫報文:在一次接收或發送報文動作中一次性不加分別地全部讀取或全部發送報文字節。2、不指定長度循環讀寫:這一版發生在短連接進程中,受網絡路由等限制,一次較長的報文可能在網絡傳輸過程中被分解成很多個包,一次讀取可能不能全部讀完一次報文,這就需要循環讀取報文,直到讀完為止。3、帶長度報文頭循環讀寫:這種情況一般在長連接中,由于在長連接中沒有條件能夠判斷循環讀寫什么時候結束。必須要加長度報文頭。讀函數先是讀取報文頭的長度,再根據這個長度去讀報文,實際情況中,報頭碼制格式還經常不一樣,如果是非ASCII的報文頭,還必須轉換成ASCII常見的報文頭編制有:1、n個字節的ASCII碼。2、n個字節的BCD碼。3、n個字節的網絡整型碼。以上是幾種比較典型的讀寫報文方式,可以與通信方式模板一起預先提供一些典型的API讀寫函數。當然在實際問題中,可能還必須編寫與對方報文格式配套的讀寫API. 在實際情況中,往往需要把我們自己的系統與別人的系統進行連接, 有了以上模板與API,可以說連接任何方式的通信程序都不存在問題。
什么時候用長連接,短連接?
長連接多用于操作頻繁,點對點的通訊,而且連接數不能太多情況,。每個TCP連接都需要三步握手,這需要時間,如果每個操作都是先連接,再操作的話那么處理速度會降低很多,所以每個操作完后都不斷開,次處理時直接發送數據包就OK了,不用建立TCP連接。例如:數據庫的連接用長連接, 如果用短連接頻繁的通信會造成socket錯誤,而且頻繁的socket 創建也是對資源的浪費。
而像WEB網站的http服務一般都用短鏈接,因為長連接對于服務端來說會耗費一定的資源,而像WEB網站這么頻繁的成千上萬甚至上億客戶端的 連接用短連接會更省一些資源,如果用長連接,而且同時有成千上萬的用戶,如果每個用戶都占用一個連接的話,那可想而知吧。所以并發量大,但每個用戶無需頻 繁操作情況下需用短連好。總之,長連接和短連接的選擇要視情況而定。
-
內核
+關注
關注
3文章
1363瀏覽量
40228 -
服務器
+關注
關注
12文章
9024瀏覽量
85186 -
數據傳送
+關注
關注
0文章
15瀏覽量
8340 -
TCP通信
+關注
關注
0文章
146瀏覽量
4217
發布評論請先 登錄
相關推薦
評論