<b> TCP連接配接，聽着太耳熟了，大學時代（計算機相關轉移）、出入職場（網際網路技術圈子），無不提到TCP連接配接。當我們再次談到與TCP相關的長短連接配接時，如果你對此不是很了解，請繼續：</b>
1. TCP<b>連接配接</b>
當網絡通信時采用TCP協定時，在真正的讀寫操作之前，server與client之間必須建立一個連接配接，當讀寫操作完成後，雙方不再需要這個連接配接 時它們可以釋放這個連接配接，連接配接的建立是需要三次握手的，而釋放則需要4次握手，是以說每個連接配接的建立都是需要資源消耗和時間消耗的
經典的三次握手示意圖：
四次揮手斷開如下圖：
<b>2. TCP</b><b>短連接配接</b>
我們模拟一下TCP短連接配接的情況，client向server發起連接配接請求，server接到請求，然後雙方建立連接配接。client向server 發送消息，server回應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起 close操作。為什麼呢，一般的server不會回複完client後立即關閉連接配接的，當然不排除有特殊的情況。從上面的描述看，短連接配接一般隻會在 client/server間傳遞一次讀寫操作短連接配接的優點是：管理起來比較簡單，存在的連接配接都是有用的連接配接，不需要額外的控制手段
<b>3.TCP</b><b>長連接配接</b>
接下來我們再模拟一下長連接配接的情況，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采取的關閉政策，具體的應用場景采用具體的政策，沒有十全十美的選擇，隻有合适的選擇。