tcp長(zhǎng)連接（tcp長(zhǎng)連接保持多久）

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

短連接

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

長(zhǎng)連接/http keep-alive

也叫持久連接，即一個(gè)TCP連接服務(wù)多次請(qǐng)求，在TCP層握手成功后，不立即斷開(kāi)連接，并在此連接的基礎(chǔ)上進(jìn)行多次消息（包括心跳）交互，直至連接的任意一方（客戶(hù)端OR服務(wù)端）主動(dòng)斷開(kāi)連接，此過(guò)程稱(chēng)為一次完整的長(zhǎng)連接。

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

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

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

TCP中的KeepAlive

  TCP協(xié)議的實(shí)現(xiàn)中，提供了KeepAlive報(bào)文，用來(lái)探測(cè)連接的對(duì)端是否存活。在應(yīng)用交互的過(guò)程中，可能存在以下幾種情況：

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

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

利用?；钐綔y(cè)功能，可以探知這種對(duì)端的意外情況，從而保證在意外發(fā)生時(shí)，可以釋放半打開(kāi)的TCP連接。TCP?；顖?bào)文交互過(guò)程如下：

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

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

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

TCP的KeepAlive機(jī)制意圖在于?；?、心跳，檢測(cè)連接錯(cuò)誤

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

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

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

什么時(shí)候用長(zhǎng)連接，短連接？

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

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

keep-alive與TIME_WAIT

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

短連接和長(zhǎ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對(duì)客戶(hù)端和服務(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 (握手等過(guò)程參考這里)

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. 為什么不能用兩次握手進(jìn)行連接？

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

TCP短連接

TCP長(zhǎng)連接

TCP長(zhǎng)/短連接的優(yōu)點(diǎn)和缺點(diǎn)

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

wireshark

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

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

使用集線(xiàn)器組成一個(gè)網(wǎng)絡(luò)

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

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

通信過(guò)程

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

參考資源

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

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

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

這是因?yàn)榫W(wǎng)絡(luò)請(qǐng)求過(guò)多，也就導(dǎo)致了系統(tǒng)打開(kāi)的文件過(guò)多。每一個(gè)連接都會(huì)當(dāng)成“文件”看待的。

于是用命令

ulimit -a

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

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

ulimit -n 4096

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

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

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

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

推薦閱讀：

cat讀卡特嗎（catcard）

tcp抓包命令（tcp 抓包）

gptchat怎么讀（gp英語(yǔ)怎么讀）

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

深夜的快手直播間（深夜的快手直播間怎么進(jìn)）