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