- TCP在真正的讀寫操作之前，server與client之間必須建立一個連接，當讀寫操作完成后，雙方不再需要這個連接
時它們可以釋放這個連接，連接的建立通過三次握手，釋放則需要四次握手，所以說每個連接的建立都是需要
資源消耗和時間消耗的。
三次握手的示意圖：
四次揮手的示意圖：
TCP短連接
-
模擬一下TCP短連接的情況:
- client 向 server 發(fā)起連接請求
- server 接到請求，雙方建立連接
- client 向 server 發(fā)送消息
- server 回應(yīng) client
- 一次讀寫完成，此時雙方任何一個都可以發(fā)起 close 操作
在第 5 點鐘，一般都是 client 先發(fā)起 close 操作。因為一般的 server 不會回復(fù)完 client 后就立即關(guān)閉連接。
當然也不排除有特殊的情況。
從上面的描述看，短連接一般只會在 client/server 間傳遞一次讀寫操作！
短連接的優(yōu)點
- 管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段
TCP長連接
-
再模擬一下長連接的情況:
- client 向 server 發(fā)起連接
- server 接到請求，雙方建立連接
- client 向 server 發(fā)送消息
- server 回應(yīng) client
- 一次讀寫完成，連接不關(guān)閉
- 后續(xù)讀寫操作...
長連接的狀態(tài)保持在下面的TCP保活功能中講解。
長/短連接操作過程
短連接的操作步驟是：
- 建立連接——數(shù)據(jù)傳輸——關(guān)閉連接...建立連接——數(shù)據(jù)傳輸——關(guān)閉連接
長連接的操作步驟是：
- 建立連接——數(shù)據(jù)傳輸...（保持連接）...數(shù)據(jù)傳輸——關(guān)閉連接
TCP?；罟δ?/h2>
?；罟δ苤饕獮榉?wù)器應(yīng)用提供，服務(wù)器應(yīng)用希望知道客戶主機是否崩潰，
從而可以代表客戶使用資源。如果客戶已經(jīng)消失，使得服務(wù)器上保留一個半開放的連接，
而服務(wù)器又在等待來自客戶端的數(shù)據(jù)，則服務(wù)器將應(yīng)遠等待客戶端的數(shù)據(jù)，
?；罟δ芫褪窃噲D在服務(wù)器端檢測到這種半開放的連接。
-
如果一個給定的連接在2小時內(nèi)沒有任何的動作，則服務(wù)器就向客戶發(fā)一個探測報文段，
客戶主機必須處于以下4個狀態(tài)之一：
- 客戶主機依然正常運行，并從服務(wù)器可達?？蛻舻腡CP響應(yīng)正常，而服務(wù)器也知道對方是正常的，
服務(wù)器在兩小時后將保活定時器復(fù)位。
- 客戶主機已經(jīng)崩潰，并且關(guān)閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應(yīng)。
服務(wù)端將不能收到對探測的響應(yīng)，并在75秒后超時。服務(wù)器總共發(fā)送10個這樣的探測 ，每個間隔75秒。
如果服務(wù)器沒有收到一個響應(yīng)，它就認為客戶主機已經(jīng)關(guān)閉并終止連接。
- 客戶主機崩潰并已經(jīng)重新啟動。服務(wù)器將收到一個對其?；钐綔y的響應(yīng)，這個響應(yīng)是一個復(fù)位，
使得服務(wù)器終止這個連接。
- 客戶機正常運行，但是服務(wù)器不可達，這種情況與2類似，TCP能發(fā)現(xiàn)的就是沒有收到探查的響應(yīng)。
長/短連接的優(yōu)點和缺點
長連接可以省去較多的TCP建立和關(guān)閉的操作，減少浪費，節(jié)約時間。
對于頻繁請求資源的客戶來說，較適用長連接。
不過這里存在一個問題，存活功能的探測周期太長，還有就是它只是探測TCP連接的存活，
屬于比較斯文的做法，遇到惡意的連接時，?；罟δ芫筒粔蚴沽恕?br>
在長連接的應(yīng)用場景下，client端一般不會主動關(guān)閉它們之間的連接，
client與server之間的連接如果一直不關(guān)閉的話，會存在一個問題，
隨著客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要采取一些策略，
如關(guān)閉一些長時間沒有讀寫事件發(fā)生的連接，這樣可以避免一些惡意連接導(dǎo)致server端服務(wù)受損；
如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數(shù)，
這樣可以完全避免某個蛋疼的客戶端連累后端服務(wù)。
短連接對于服務(wù)器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。
但如果客戶請求頻繁，將在TCP的建立和關(guān)閉操作上浪費時間和帶寬。
長/短連接的應(yīng)用場景
長連接多用于操作頻繁，點對點的通訊，而且連接數(shù)不能太多情況。
每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，
再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，
再次處理時直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。
例如：數(shù)據(jù)庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，
而且頻繁的socket 創(chuàng)建也是對資源的浪費。
而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因為長連接對于服務(wù)端來說會耗費一定的資源，
而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，
如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，
那可想而知吧。所以并發(fā)量大，但每個用戶無需頻繁操作情況下需用短連好。
http://blog.csdn.net/whuslei/article/details/6667471
https://www.centos.bz/2012/08/tcp-establish-close/
http://www.cnblogs.com/0201zcr/p/4694945.html
http://www.cnblogs.com/beifei/archive/2011/06/26/2090611.html
?；罟δ苤饕獮榉?wù)器應(yīng)用提供，服務(wù)器應(yīng)用希望知道客戶主機是否崩潰，
從而可以代表客戶使用資源。如果客戶已經(jīng)消失，使得服務(wù)器上保留一個半開放的連接，
而服務(wù)器又在等待來自客戶端的數(shù)據(jù)，則服務(wù)器將應(yīng)遠等待客戶端的數(shù)據(jù)，
?；罟δ芫褪窃噲D在服務(wù)器端檢測到這種半開放的連接。
如果一個給定的連接在2小時內(nèi)沒有任何的動作，則服務(wù)器就向客戶發(fā)一個探測報文段，
客戶主機必須處于以下4個狀態(tài)之一：
- 客戶主機依然正常運行，并從服務(wù)器可達?？蛻舻腡CP響應(yīng)正常，而服務(wù)器也知道對方是正常的，
服務(wù)器在兩小時后將保活定時器復(fù)位。 - 客戶主機已經(jīng)崩潰，并且關(guān)閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應(yīng)。
服務(wù)端將不能收到對探測的響應(yīng)，并在75秒后超時。服務(wù)器總共發(fā)送10個這樣的探測 ，每個間隔75秒。
如果服務(wù)器沒有收到一個響應(yīng)，它就認為客戶主機已經(jīng)關(guān)閉并終止連接。 - 客戶主機崩潰并已經(jīng)重新啟動。服務(wù)器將收到一個對其?；钐綔y的響應(yīng)，這個響應(yīng)是一個復(fù)位，
使得服務(wù)器終止這個連接。 - 客戶機正常運行，但是服務(wù)器不可達，這種情況與2類似，TCP能發(fā)現(xiàn)的就是沒有收到探查的響應(yīng)。
長連接可以省去較多的TCP建立和關(guān)閉的操作，減少浪費，節(jié)約時間。
對于頻繁請求資源的客戶來說，較適用長連接。
不過這里存在一個問題，存活功能的探測周期太長，還有就是它只是探測TCP連接的存活，
屬于比較斯文的做法，遇到惡意的連接時，?；罟δ芫筒粔蚴沽恕?br>
在長連接的應(yīng)用場景下，client端一般不會主動關(guān)閉它們之間的連接，
client與server之間的連接如果一直不關(guān)閉的話，會存在一個問題，
隨著客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要采取一些策略，
如關(guān)閉一些長時間沒有讀寫事件發(fā)生的連接，這樣可以避免一些惡意連接導(dǎo)致server端服務(wù)受損；
如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數(shù)，
這樣可以完全避免某個蛋疼的客戶端連累后端服務(wù)。
短連接對于服務(wù)器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。
但如果客戶請求頻繁，將在TCP的建立和關(guān)閉操作上浪費時間和帶寬。
長連接多用于操作頻繁，點對點的通訊，而且連接數(shù)不能太多情況。
每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，
再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，
再次處理時直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。
例如：數(shù)據(jù)庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，
而且頻繁的socket 創(chuàng)建也是對資源的浪費。
而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因為長連接對于服務(wù)端來說會耗費一定的資源，
而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，
如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，
那可想而知吧。所以并發(fā)量大，但每個用戶無需頻繁操作情況下需用短連好。
http://blog.csdn.net/whuslei/article/details/6667471
https://www.centos.bz/2012/08/tcp-establish-close/
http://www.cnblogs.com/0201zcr/p/4694945.html
http://www.cnblogs.com/beifei/archive/2011/06/26/2090611.html
