HTTP的長連接和短連接本質(zhì)上是TCP長連接和短連接。HTTP屬于應(yīng)用層協(xié)議，在傳輸層使用TCP協(xié)議，在網(wǎng)絡(luò)層使用IP協(xié)議。IP協(xié)議主要解決網(wǎng)絡(luò)路由和尋址問題，TCP協(xié)議主要解決如何在IP層之上可靠的
1. HTTP協(xié)議與TCP/IP協(xié)議的關(guān)系
HTTP的長連接和短連接本質(zhì)上是TCP長連接和短連接。HTTP屬于應(yīng)用層協(xié)議，在傳輸層使用TCP協(xié)議，在網(wǎng)絡(luò)層使用IP協(xié)議。IP協(xié)議主要解決網(wǎng)絡(luò)路由和尋址問題，TCP協(xié)議主要解決如何在IP層之上可靠的傳遞數(shù)據(jù)包，使在網(wǎng)絡(luò)上的另一端收到發(fā)端發(fā)出的所有包，并且順序與發(fā)出順序一致。TCP有可靠，面向連接的特點。
TCP/IP是個協(xié)議組，可分為三個層次：網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。
在網(wǎng)絡(luò)層有IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、RARP協(xié)議和BOOTP協(xié)議。
在傳輸層中有TCP協(xié)議與UDP協(xié)議。
在應(yīng)用層有:TCP包括FTP、HTTP、TELNET、SMTP等協(xié)議
UDP包括DNS、TFTP等協(xié)議
2. 如何理解HTTP協(xié)議是無狀態(tài)的
HTTP協(xié)議是無狀態(tài)的，指的是協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。也就是說，打開一個服務(wù)器上的網(wǎng)頁和你之前打開這個服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系。HTTP是一個無狀態(tài)的面向連接的協(xié)議，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無連接）。
3. 什么是長連接、短連接？
短連接
連接->傳輸數(shù)據(jù)->關(guān)閉連接
HTTP是無狀態(tài)的，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。
也可以這樣說：短連接是指SOCKET連接后發(fā)送后接收完數(shù)據(jù)后馬上斷開連接。
長連接
連接->傳輸數(shù)據(jù)->保持連接 -> 傳輸數(shù)據(jù)-> 。。。 ->關(guān)閉連接。
長連接指建立SOCKET連接后不管是否使用都保持連接，但安全性較差。
在HTTP/1.0中，默認(rèn)使用的是短連接。也就是說，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。如果客戶端瀏覽器訪問的某個html或其他類型的 Web頁中包含有其他的Web資源，如JAVAScript文件、圖像文件、css文件等；當(dāng)瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。
但從 HTTP/1.1起，默認(rèn)使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會在響應(yīng)頭有加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。實現(xiàn)長連接要客戶端和服務(wù)端都支持長連接。
HTTP協(xié)議的長連接和短連接，實質(zhì)上是TCP協(xié)議的長連接和短連接。
3.1 TCP連接
當(dāng)網(wǎng)絡(luò)通信時采用TCP協(xié)議時，在真正的讀寫操作之前，server與client之間必須建立一個連接，當(dāng)讀寫操作完成后，雙方不再需要這個連接 時它們可以釋放這個連接，連接的建立是需要三次握手的，而釋放則需要4次握手，所以說每個連接的建立都是需要資源消耗和時間消耗的
經(jīng)典的三次握手示意圖：
經(jīng)典的四次握手關(guān)閉圖：
3.2 TCP短連接
我們模擬一下TCP短連接的情況，client向server發(fā)起連接請求，server接到請求，然后雙方建立連接。client向server 發(fā)送消息，server回應(yīng)client，然后一次讀寫就完成了，這時候雙方任何一個都可以發(fā)起close操作，不過一般都是client先發(fā)起 close操作。為什么呢，一般的server不會回復(fù)完client后立即關(guān)閉連接的，當(dāng)然不排除有特殊的情況。從上面的描述看，短連接一般只會在 client/server間傳遞一次讀寫操作
短連接的優(yōu)點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段
3.3 TCP長連接
接下來我們再模擬一下長連接的情況，client向server發(fā)起連接，server接受client連接，雙方建立連接。Client與server完成一次讀寫之后，它們之間的連接并不會主動關(guān)閉，后續(xù)的讀寫操作會繼續(xù)使用這個連接。
首先說一下TCP/IP詳解上講到的TCP保活功能，保活功能主要為服務(wù)器應(yīng)用提供，服務(wù)器應(yīng)用希望知道客戶主機(jī)是否崩潰，從而可以代表客戶使用資源。如果客戶已經(jīng)消失，使得服務(wù)器上保留一個半開放的連接，而服務(wù)器又在等待來自客戶端的數(shù)據(jù)，則服務(wù)器將應(yīng)遠(yuǎn)等待客戶端的數(shù)據(jù)，保活功能就是試圖在服務(wù) 器端檢測到這種半開放的連接。
如果一個給定的連接在兩小時內(nèi)沒有任何的動作，則服務(wù)器就向客戶發(fā)一個探測報文段，客戶主機(jī)必須處于以下4個狀態(tài)之一：
- 客戶主機(jī)依然正常運(yùn)行，并從服務(wù)器可達(dá)。客戶的TCP響應(yīng)正常，而服務(wù)器也知道對方是正常的，服務(wù)器在兩小時后將保活定時器復(fù)位。
- 客戶主機(jī)已經(jīng)崩潰，并且關(guān)閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應(yīng)。服務(wù)端將不能收到對探測的響應(yīng)，并在75秒后超時。服務(wù)器總共發(fā)送10個這樣的探測 ，每個間隔75秒。如果服務(wù)器沒有收到一個響應(yīng)，它就認(rèn)為客戶主機(jī)已經(jīng)關(guān)閉并終止連接。
- 客戶主機(jī)崩潰并已經(jīng)重新啟動。服務(wù)器將收到一個對其保活探測的響應(yīng)，這個響應(yīng)是一個復(fù)位，使得服務(wù)器終止這個連接。
- 客戶機(jī)正常運(yùn)行，但是服務(wù)器不可達(dá)，這種情況與2類似，TCP能發(fā)現(xiàn)的就是沒有收到探查的響應(yīng)。
4. 長連接和短連接的優(yōu)點和缺點
由上可以看出，長連接可以省去較多的TCP建立和關(guān)閉的操作，減少浪費(fèi)，節(jié)約時間。對于頻繁請求資源的客戶來說，較適用長連接。不過這里存在一個問題，存活功能的探測周期太長，還有就是它只是探測TCP連接的存活，屬于比較斯文的做法，遇到惡意的連接時，保活功能就不夠使了。在長連接的應(yīng)用場景下，client端一般不會主動關(guān)閉它們之間的連接，Client與server之間的連接如果一直不關(guān)閉的話，會存在一個問題，隨著客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要采取一些策略，如關(guān)閉一些長時間沒有讀寫事件發(fā)生的連接，這樣可 以避免一些惡意連接導(dǎo)致server端服務(wù)受損；如果條件再允許就可以以客戶端機(jī)器為顆粒度，限制每個客戶端的最大長連接數(shù)，這樣可以完全避免某個蛋疼的客戶端連累后端服務(wù)。
短連接對于服務(wù)器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關(guān)閉操作上浪費(fèi)時間和帶寬。
長連接和短連接的產(chǎn)生在于client和server采取的關(guān)閉策略，具體的應(yīng)用場景采用具體的策略，沒有十全十美的選擇，只有合適的選擇。
長連接多用于操作頻繁，點對點的通訊，而且連接數(shù)不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，次處理時直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創(chuàng)建也是對資源的浪費(fèi)。
而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因為長連接對于服務(wù)端來說會耗費(fèi)一定的資源，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發(fā)量大，但每個用戶無需頻繁操作情況下需用短連好。
5、容易混淆的概念——TCP的keep alive和HTTP的Keep-alive
TCP的keep alive是檢查當(dāng)前TCP連接是否活著；HTTP的Keep-alive是要讓一個TCP連接活久點。它們是不同層次的概念。
TCP keep alive的表現(xiàn)：
當(dāng)一個連接“一段時間”沒有數(shù)據(jù)通訊時，一方會發(fā)出一個心跳包（Keep Alive包），如果對方有回包則表明當(dāng)前連接有效，繼續(xù)監(jiān)控。
這個“一段時間”可以設(shè)置。
WinHttp庫的設(shè)置：
WINHTTP_OPTION_WEB_SOCKET_KEEPALIVE_INTERVAL
Sets the interval, in milliseconds, to send a keep-alive packet over the connection. The default interval is 30000 (30 seconds). The minimum interval is 15000 (15 seconds). Using WinHttpSetOption to set a value lower than 15000 will return with ERROR_INVALID_PARAMETER.
libcurl的設(shè)置：
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html
CURLOPT_TCP_KEEPALIVE
Pass a long. If set to 1, TCP keepalive probes will be sent. The delay and frequency of these probes can be controlled by the CURLOPT_TCP_KEEPIDLE and CURLOPT_TCP_KEEPINTVL options, provided the operating system supports them. Set to 0 (default behavior) to disable keepalive probes (Added in 7.25.0).
CURLOPT_TCP_KEEPIDLE
Pass a long. Sets the delay, in seconds, that the operating system will wait while the connection is idle before sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)
CURLOPT_TCP_KEEPINTVL
Pass a long. Sets the interval, in seconds, that the operating system will wait between sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)
CURLOPT_TCP_KEEPIDLE是空閑多久發(fā)送一個心跳包，CURLOPT_TCP_KEEPINTVL是心跳包間隔多久發(fā)一個。
打開網(wǎng)頁抓包，發(fā)送心跳包和關(guān)閉連接如下：
從上圖可以看到，大概過了44秒，客戶端發(fā)出了心跳包，服務(wù)器及時回應(yīng)，本TCP連接繼續(xù)保持。到了空閑60秒的時候，服務(wù)器主動發(fā)起FIN包，斷開連接。
Socket是什么
Socket是應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層，它是一組接口。在設(shè)計模式中，Socket其實就是一個門面模式，它把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議。
通信過程：
主機(jī) A 的應(yīng)用程序要能和主機(jī) B 的應(yīng)用程序通信，必須通過 Socket 建立連接，而建立 Socket 連接必須需要底層 TCP/IP 協(xié)議來建立 TCP 連接。建立 TCP 連接需要底層 IP 協(xié)議來尋址網(wǎng)絡(luò)中的主機(jī)。我們知道網(wǎng)絡(luò)層使用的 IP 協(xié)議可以幫助我們根據(jù) IP 地址來找到目標(biāo)主機(jī)，但是一臺主機(jī)上可能運(yùn)行著多個應(yīng)用程序，如何才能與指定的應(yīng)用程序通信就要通過 TCP 或 UPD 的地址也就是端口號來指定。這樣就可以通過一個 Socket 實例唯一代表一個主機(jī)上的一個應(yīng)用程序的通信鏈路了。
建立通信鏈路
當(dāng)客戶端要與服務(wù)端通信，客戶端首先要創(chuàng)建一個 Socket 實例，操作系統(tǒng)將為這個 Socket 實例分配一個沒有被使用的本地端口號，并創(chuàng)建一個包含本地和遠(yuǎn)程地址和端口號的套接字?jǐn)?shù)據(jù)結(jié)構(gòu)，這個數(shù)據(jù)結(jié)構(gòu)將一直保存在系統(tǒng)中直到這個連接關(guān)閉。在創(chuàng)建 Socket 實例的構(gòu)造函數(shù)正確返回之前，將要進(jìn)行 TCP 的三次握手協(xié)議，TCP 握手協(xié)議完成后，Socket 實例對象將創(chuàng)建完成，否則將拋出 IOException 錯誤。
與之對應(yīng)的服務(wù)端將創(chuàng)建一個 ServerSocket 實例，ServerSocket 創(chuàng)建比較簡單只要指定的端口號沒有被占用，一般實例創(chuàng)建都會成功，同時操作系統(tǒng)也會為 ServerSocket 實例創(chuàng)建一個底層數(shù)據(jù)結(jié)構(gòu)，這個數(shù)據(jù)結(jié)構(gòu)中包含指定監(jiān)聽的端口號和包含監(jiān)聽地址的通配符，通常情況下都是“*”即監(jiān)聽所有地址。之后當(dāng)調(diào)用 accept() 方法時，將進(jìn)入阻塞狀態(tài)，等待客戶端的請求。當(dāng)一個新的請求到來時，將為這個連接創(chuàng)建一個新的套接字?jǐn)?shù)據(jù)結(jié)構(gòu)，該套接字?jǐn)?shù)據(jù)的信息包含的地址和端口信息正是請求源地址和端口。這個新創(chuàng)建的數(shù)據(jù)結(jié)構(gòu)將會關(guān)聯(lián)到 ServerSocket 實例的一個未完成的連接數(shù)據(jù)結(jié)構(gòu)列表中，注意這時服務(wù)端與之對應(yīng)的 Socket 實例并沒有完成創(chuàng)建，而要等到與客戶端的三次握手完成后，這個服務(wù)端的 Socket 實例才會返回，并將這個 Socket 實例對應(yīng)的數(shù)據(jù)結(jié)構(gòu)從未完成列表中移到已完成列表中。所以 ServerSocket 所關(guān)聯(lián)的列表中每個數(shù)據(jù)結(jié)構(gòu)，都代表與一個客戶端的建立的 TCP 連接。
備注：
windows 下單機(jī)最大TCP連接數(shù)
調(diào)整系統(tǒng)參數(shù)來調(diào)整單機(jī)的最大TCP連接數(shù)，Windows 下單機(jī)的TCP連接數(shù)有多個參數(shù)共同決定：
以下都是通過修改注冊表[HKEY_LOCAL_macHINE System CurrentControlSet Services Tcpip Parameters]
1.最大TCP連接數(shù) TcpNumConnections
2.TCP關(guān)閉延遲時間 TCPTimedWaitDelay (30-240)s
3.最大動態(tài)端口數(shù) MaxUserPort (Default = 5000, Max = 65534) TCP客戶端和服務(wù)器連接時，客戶端必須分配一個動態(tài)端口，默認(rèn)情況下這個動態(tài)端口的分配范圍為 1024-5000 ，也就是說默認(rèn)情況下，客戶端最多可以同時發(fā)起3977 Socket 連接
4.最大TCB 數(shù)量 MaxFreeTcbs
系統(tǒng)為每個TCP 連接分配一個TCP 控制塊(TCP control block or TCB)，這個控制塊用于緩存TCP連接的一些參數(shù)，每個TCB需要分配 0.5 KB的pagepool 和 0.5KB 的Non-pagepool，也就說，每個TCP連接會占用 1KB 的系統(tǒng)內(nèi)存。
非Server版本，MaxFreeTcbs 的默認(rèn)值為1000 （64M 以上物理內(nèi)存）Server 版本，這個的默認(rèn)值為 2000。也就是說，默認(rèn)情況下，Server 版本最多同時可以建立并保持2000個TCP 連接。
5. 最大TCB Hash table 數(shù)量 MaxHashTableSize TCB 是通過Hash table 來管理的。
這個值指明分配 pagepool 內(nèi)存的數(shù)量，也就是說，如果MaxFreeTcbs = 1000 , 則 pagepool 的內(nèi)存數(shù)量為 500KB那么 MaxHashTableSize 應(yīng)大于 500 才行。這個數(shù)量越大，則Hash table 的冗余度就越高，每次分配和查找 TCP 連接用時就越少。這個值必須是2的冪，且最大為65536.
IBM WebSphere Voice Server 在windows server 2003 下的典型配置
MaxUserPort = 65534 (Decimal)
MaxHashTableSize = 65536 (Decimal)
MaxFreeTcbs = 16000 (Decimal)
這里我們可以看到 MaxHashTableSize 被配置為比MaxFreeTcbs 大4倍，這樣可以大大增加TCP建立的速度。
