'分析HTTP,TCP的長連接和短連接以及socket'

HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的

1. HTTP協議與TCP/IP協議的關係

HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，並且順序與發出順序一致。TCP有可靠，面向連接的特點。

TCP/IP是個協議組，可分為三個層次：網絡層、傳輸層和應用層。

在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。

在傳輸層中有TCP協議與UDP協議。

在應用層有:TCP包括FTP、HTTP、TELNET、SMTP等協議

UDP包括DNS、TFTP等協議

2. 如何理解HTTP協議是無狀態的

HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。也就是說，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯繫。HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。

3. 什麼是長連接、短連接？

短連接

連接->傳輸數據->關閉連接

HTTP是無狀態的，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。

也可以這樣說：短連接是指SOCKET連接後發送後接收完數據後馬上斷開連接。

長連接

連接->傳輸數據->保持連接 -> 傳輸數據-> 。。。 ->關閉連接。

長連接指建立SOCKET連接後不管是否使用都保持連接，但安全性較差。

在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。

但從 HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：

Connection:keep-alive

在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。

HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。

3.1 TCP連接

當網絡通信時採用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連接，當讀寫操作完成後，雙方不再需要這個連接 時它們可以釋放這個連接，連接的建立是需要三次握手的，而釋放則需要4次握手，所以說每個連接的建立都是需要資源消耗和時間消耗的

經典的三次握手示意圖：

經典的四次握手關閉圖：

3.2 TCP短連接

我們模擬一下TCP短連接的情況，client向server發起連接請求，server接到請求，然後雙方建立連接。client向server 發送消息，server迴應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起 close操作。為什麼呢，一般的server不會回覆完client後立即關閉連接的，當然不排除有特殊的情況。從上面的描述看，短連接一般只會在 client/server間傳遞一次讀寫操作

短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段

3.3 TCP長連接

接下來我們再模擬一下長連接的情況，client向server發起連接，server接受client連接，雙方建立連接。Client與server完成一次讀寫之後，它們之間的連接並不會主動關閉，後續的讀寫操作會繼續使用這個連接。

首先說一下TCP/IP詳解上講到的TCP保活功能，保活功能主要為服務器應用提供，服務器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。如果客戶已經消失，使得服務器上保留一個半開放的連接，而服務器又在等待來自客戶端的數據，則服務器將應遠等待客戶端的數據，保活功能就是試圖在服務 器端檢測到這種半開放的連接。

如果一個給定的連接在兩小時內沒有任何的動作，則服務器就向客戶發一個探測報文段，客戶主機必須處於以下4個狀態之一：

1. 客戶主機依然正常運行，並從服務器可達。客戶的TCP響應正常，而服務器也知道對方是正常的，服務器在兩小時後將保活定時器復位。
2. 客戶主機已經崩潰，並且關閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，並在75秒後超時。服務器總共發送10個這樣的探測 ，每個間隔75秒。如果服務器沒有收到一個響應，它就認為客戶主機已經關閉並終止連接。
3. 客戶主機崩潰並已經重新啟動。服務器將收到一個對其保活探測的響應，這個響應是一個復位，使得服務器終止這個連接。
4. 客戶機正常運行，但是服務器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。

4. 長連接和短連接的優點和缺點

由上可以看出，長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶來說，較適用長連接。不過這裡存在一個問題，存活功能的探測週期太長，還有就是它只是探測TCP連接的存活，屬於比較斯文的做法，遇到惡意的連接時，保活功能就不夠使了。在長連接的應用場景下，client端一般不會主動關閉它們之間的連接，Client與server之間的連接如果一直不關閉的話，會存在一個問題，隨著客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可 以避免一些惡意連接導致server端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累後端服務。

短連接對於服務器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和帶寬。

長連接和短連接的產生在於client和server採取的關閉策略，具體的應用場景採用具體的策略，沒有十全十美的選擇，只有合適的選擇。

長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。

而像WEB網站的http服務一般都用短鏈接，因為長連接對於服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都佔用一個連接的話，那可想而知吧。所以併發量大，但每個用戶無需頻繁操作情況下需用短連好。

5、容易混淆的概念——TCP的keep alive和HTTP的Keep-alive

TCP的keep alive是檢查當前TCP連接是否活著；HTTP的Keep-alive是要讓一個TCP連接活久點。它們是不同層次的概念。

TCP keep alive的表現：

當一個連接“一段時間”沒有數據通訊時，一方會發出一個心跳包（Keep Alive包），如果對方有回包則表明當前連接有效，繼續監控。

這個“一段時間”可以設置。

WinHttp庫的設置：

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的設置：

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是空閒多久發送一個心跳包，CURLOPT_TCP_KEEPINTVL是心跳包間隔多久發一個。

打開網頁抓包，發送心跳包和關閉連接如下：

從上圖可以看到，大概過了44秒，客戶端發出了心跳包，服務器及時迴應，本TCP連接繼續保持。到了空閒60秒的時候，服務器主動發起FIN包，斷開連接。

Socket是什麼

Socket是應用層與TCP/IP協議族通信的中間軟件抽象層，它是一組接口。在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數據，以符合指定的協議。

通信過程：

主機 A 的應用程序要能和主機 B 的應用程序通信，必須通過 Socket 建立連接，而建立 Socket 連接必須需要底層 TCP/IP 協議來建立 TCP 連接。建立 TCP 連接需要底層 IP 協議來尋址網絡中的主機。我們知道網絡層使用的 IP 協議可以幫助我們根據 IP 地址來找到目標主機，但是一臺主機上可能運行著多個應用程序，如何才能與指定的應用程序通信就要通過 TCP 或 UPD 的地址也就是端口號來指定。這樣就可以通過一個 Socket 實例唯一代表一個主機上的一個應用程序的通信鏈路了。

建立通信鏈路

當客戶端要與服務端通信，客戶端首先要創建一個 Socket 實例，操作系統將為這個 Socket 實例分配一個沒有被使用的本地端口號，並創建一個包含本地和遠程地址和端口號的套接字數據結構，這個數據結構將一直保存在系統中直到這個連接關閉。在創建 Socket 實例的構造函數正確返回之前，將要進行 TCP 的三次握手協議，TCP 握手協議完成後，Socket 實例對象將創建完成，否則將拋出 IOException 錯誤。

與之對應的服務端將創建一個 ServerSocket 實例，ServerSocket 創建比較簡單隻要指定的端口號沒有被佔用，一般實例創建都會成功，同時操作系統也會為 ServerSocket 實例創建一個底層數據結構，這個數據結構中包含指定監聽的端口號和包含監聽地址的通配符，通常情況下都是“*”即監聽所有地址。之後當調用 accept() 方法時，將進入阻塞狀態，等待客戶端的請求。當一個新的請求到來時，將為這個連接創建一個新的套接字數據結構，該套接字數據的信息包含的地址和端口信息正是請求源地址和端口。這個新創建的數據結構將會關聯到 ServerSocket 實例的一個未完成的連接數據結構列表中，注意這時服務端與之對應的 Socket 實例並沒有完成創建，而要等到與客戶端的三次握手完成後，這個服務端的 Socket 實例才會返回，並將這個 Socket 實例對應的數據結構從未完成列表中移到已完成列表中。所以 ServerSocket 所關聯的列表中每個數據結構，都代表與一個客戶端的建立的 TCP 連接。

備註：

Windows 下單機最大TCP連接數

調整系統參數來調整單機的最大TCP連接數，Windows 下單機的TCP連接數有多個參數共同決定：

以下都是通過修改註冊表[HKEY_LOCAL_MACHINE \\System \\CurrentControlSet \\Services \\Tcpip \\Parameters]

1.最大TCP連接數 TcpNumConnections

2.TCP關閉延遲時間 TCPTimedWaitDelay (30-240)s

3.最大動態端口數 MaxUserPort (Default = 5000, Max = 65534) TCP客戶端和服務器連接時，客戶端必須分配一個動態端口，默認情況下這個動態端口的分配範圍為 1024-5000 ，也就是說默認情況下，客戶端最多可以同時發起3977 Socket 連接

4.最大TCB 數量 MaxFreeTcbs

系統為每個TCP 連接分配一個TCP 控制塊(TCP control block or TCB)，這個控制塊用於緩存TCP連接的一些參數，每個TCB需要分配 0.5 KB的pagepool 和 0.5KB 的Non-pagepool，也就說，每個TCP連接會佔用 1KB 的系統內存。

非Server版本，MaxFreeTcbs 的默認值為1000 （64M 以上物理內存）Server 版本，這個的默認值為 2000。也就是說，默認情況下，Server 版本最多同時可以建立並保持2000個TCP 連接。

5. 最大TCB Hash table 數量 MaxHashTableSize TCB 是通過Hash table 來管理的。

這個值指明分配 pagepool 內存的數量，也就是說，如果MaxFreeTcbs = 1000 , 則 pagepool 的內存數量為 500KB那麼 MaxHashTableSize 應大於 500 才行。這個數量越大，則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建立的速度。

關注小編,小編會每天為你分享有趣的技術文章哦。偷偷告訴你私信小編“學習”會有意想不到的驚喜喲~~!