tcp長連接（tcp長連接保持多久）

HTTP的長連接和短連接本質(zhì)上是TCP長連接和短連接。

短連接

短連接，顧名思義，與長連接的區(qū)別就是，客戶端收到服務(wù)端的響應(yīng)后，立刻發(fā)送FIN消息，主動釋放連接。也有服務(wù)端主動斷連的情況，凡是在一次消息交互（發(fā)請求-收響應(yīng)）之后立刻斷開連接的情況都稱為短連接。

長連接/http keep-alive

也叫持久連接，即一個TCP連接服務(wù)多次請求，在TCP層握手成功后，不立即斷開連接，并在此連接的基礎(chǔ)上進行多次消息（包括心跳）交互，直至連接的任意一方（客戶端OR服務(wù)端）主動斷開連接，此過程稱為一次完整的長連接。

在HTTP/1.0中得到了初步的支持，客戶端在請求header中攜帶Connection:Keep-Alive，即是在向服務(wù)端請求持久連接。如果服務(wù)端接受持久連接，則會在響應(yīng)header中同樣攜帶Connection: Keep-Alive，這樣客戶端便會繼續(xù)使用同一個TCP連接發(fā)送接下來的若干請求。（Keep-Alive的默認參數(shù)是[timout=5, max=100]，即一個TCP連接可以服務(wù)至多5秒內(nèi)的100次請求）

HTTP/1.1開始，即使請求header中沒有攜帶Connection: Keep-Alive，傳輸也會默認以持久連接的方式進行，只有加入"Connection: close "后，才關(guān)閉。

http keepalive是客戶端瀏覽器與服務(wù)端httpd守護進程協(xié)作的結(jié)果。

TCP中的KeepAlive

  TCP協(xié)議的實現(xiàn)中，提供了KeepAlive報文，用來探測連接的對端是否存活。在應(yīng)用交互的過程中，可能存在以下幾種情況：

客戶端或服務(wù)器意外斷電，死機，崩潰，重啟；

中間網(wǎng)絡(luò)已經(jīng)中斷，而客戶端與服務(wù)器并不知道；

利用?；钐綔y功能，可以探知這種對端的意外情況，從而保證在意外發(fā)生時，可以釋放半打開的TCP連接。TCP?；顖笪慕换ミ^程如下：

因此，KeepAlive并不適用于檢測雙方存活的場景，這種場景還得依賴于應(yīng)用層的心跳。 應(yīng)用層心跳也具備著更大的靈活性，可以控制檢測時機，間隔和處理流程，甚至可以在心跳包上附帶額外信息。

應(yīng)用層心跳是檢測連接有效性以及判斷雙方是否存活的有效方式 。但是心跳過于頻繁會帶來 耗電和耗流量 的弊病，心跳頻率過低則會影響連接檢測的實時性。業(yè)內(nèi)關(guān)于心跳時間的設(shè)置和優(yōu)化，主要基于如下幾個因素：

理想的情況下,客戶端應(yīng)當(dāng)以略小于NAT超時時間的間隔來發(fā)送心跳包。 根據(jù)微信團隊測試的一些數(shù)據(jù)，一些常用網(wǎng)絡(luò)的NAT超時時間如下表所示：

TCP的KeepAlive機制意圖在于?；?、心跳，檢測連接錯誤

如何快速區(qū)分當(dāng)前連接使用的是長連接還是短連接

1、凡是在一次完整的消息交互（發(fā)請求-收響應(yīng)）之后，立刻斷開連接（有一方發(fā)送FIN消息）的情況都稱為短連接；

2、長連接的一個明顯特征是會有心跳消息（也有沒有心跳的情況），且一般心跳間隔都在30S或者1MIN左右，用wireshark抓包可以看到有規(guī)律的心跳消息交互（可能會存在毫秒級別的誤差）。

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

1、需要頻繁交互的場景使用長連接，如即時通信工具（微信/QQ，QQ也有UDP），相反則使用短連接，比如普通的web網(wǎng)站，只有當(dāng)瀏覽器發(fā)起請求時才會建立連接，服務(wù)器返回相應(yīng)后，連接立即斷開。

2、維持長連接會有一定的系統(tǒng)開銷，用戶量少不容易看出系統(tǒng)瓶頸，一旦用戶量上去了，就很有可能把服務(wù)器資源（內(nèi)存/CPU/網(wǎng)卡）耗盡，所以使用需謹慎。

keep-alive與TIME_WAIT

使用http keep-alvie，可以減少服務(wù)端TIME_WAIT數(shù)量(因為由服務(wù)端httpd守護進程主動關(guān)閉連接)。道理很簡單，相較而言，啟用keep-alive，建立的tcp連接更少了，自然要被關(guān)閉的tcp連接也相應(yīng)更少了。

短連接和長鏈接 圖：

參考： https://caofengbin.github.io/2018/03/16/dhcp-and-nat/#4-%E5%BD%B1%E5%93%8D%E5%BF%83%E8%B7%B3%E9%A2%91%E7%8E%87%E7%9A%84%E5%85%B3%E9%94%AE%E5%9B%A0%E7%B4%A0

https://blog.csdn.net/hengyunabc/article/details/44310193

http://wingjay.com/2018/12/05/android-arch-long-link/

https://www.levicc.com/2018/06/30/yi-dong-duan-wang-luo-you-hua/

能被我參考的都很優(yōu)秀，哈哈

三、TCP/IP, UDP, HTTP, WebSocket, RPC及協(xié)議包結(jié)構(gòu)

WebSocket對客戶端和服務(wù)端的要求

參考資料

http://www.websocket.org/index.html

https://segmentfault.com/a/1190000012709475

https://www.liaoxuefeng.com/wiki/1022910821149312/1103303693824096

https://www.cnblogs.com/nnngu/p/9347635.html

https://www.cnblogs.com/bianzy/p/5822426.html

https://www.cnblogs.com/jingmoxukong/p/7755643.html (nginx代理WebSocket)

https://segmentfault.com/a/1190000012948613

https://www.jianshu.com/p/42260a2575f8

https://www.jianshu.com/p/45cbc2252c11 (參考資源)

https://www.jianshu.com/p/9e63767c04e1

https://www.jianshu.com/p/e41a329ef353 (握手等過程參考這里)

TCP 標(biāo)志位

TCP狀態(tài)

建立連接協(xié)議（三次握手）

連接終止協(xié)議（四次握手）

https://blog.csdn.net/yangyangye/article/details/38851271 (詳解)

https://blog.csdn.net/zzhongcy/article/details/21992471

1.為什么建立連接協(xié)議是三次握手，而關(guān)閉連接卻是四次握手呢？

2. 為什么不能用兩次握手進行連接？

3.為什么TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)？

TCP短連接

TCP長連接

TCP長/短連接的優(yōu)點和缺點

TCP長/短連接的應(yīng)用場景

wireshark

https://www.jianshu.com/p/e41a329ef353 (參考這里)

https://www.jianshu.com/p/7c01759c28dd (https加密傳輸參考這里)

使用集線器組成一個網(wǎng)絡(luò)

使用交換機組成一個網(wǎng)絡(luò)

使用路由器連接多個網(wǎng)絡(luò)(組包, 拆包過程)

通信過程

https://www.jianshu.com/p/209576915459

參考資源

https://www.jianshu.com/p/9e63767c04e1 (各種協(xié)議包結(jié)構(gòu))

https://www.jianshu.com/p/29868fb82890 (TCP三次握手四次揮手)

四、TCP長連接出現(xiàn)Too many open files，該怎么處理

這是因為網(wǎng)絡(luò)請求過多，也就導(dǎo)致了系統(tǒng)打開的文件過多。每一個連接都會當(dāng)成“文件”看待的。

于是用命令

ulimit -a

（效果：查看每個用戶允許打開的最大文件數(shù)）

看到最大文件數(shù)是1024，將其更改大點，如

ulimit -n 4096

然后必須重啟下網(wǎng)絡(luò)服務(wù)，我用的是WebLogic，重啟之后便沒有出現(xiàn)異常。

導(dǎo)致 Too many open files ，網(wǎng)絡(luò)請求過多是一種可能，但也有可能是程序上的缺陷，如沒有釋放一些文件句柄，程序open了文件卻忘記了在最后close。但我確信工程中沒有用到打開文件這一環(huán)節(jié)，因此這個可能是排除掉了。

用lsof -p [進程ID] 可以看到某ID的打開文件狀況。進程ID可能用 ps -ef|grep java列出weblogic的進程ID，然后用此ID套入lsof -p ID號，咳，一大堆的請求喲，這顯然是網(wǎng)絡(luò)請求過多造成了 Too many open files。適當(dāng)調(diào)整后便已消除這種現(xiàn)象。

以上就是關(guān)于tcp長連接相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進行咨詢，客服也會為您講解更多精彩的知識和內(nèi)容。

推薦閱讀：

cat讀卡特嗎（catcard）

tcp抓包命令（tcp 抓包）

gptchat怎么讀（gp英語怎么讀）

gpt指標(biāo)多少正常（gpt多少算偏高）

深夜的快手直播間（深夜的快手直播間怎么進）