http和socket之長鏈接和短鏈接區別

TCP/IP

TCP/IP是個協議組，可分爲三個層次：網絡層、傳輸層和應用層。 
在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。 
在傳輸層中有TCP協議與UDP協議。 
在應用層有:TCP包括FTP、HTTP、TELNET、SMTP等協議 
UDP包括DNS、TFTP等協議

短鏈接

鏈接->傳輸數據->關閉鏈接 
HTTP是無狀態的，瀏覽器和服務器每進行一次HTTP操做，就創建一次鏈接，但任務結束就中斷鏈接。 
也能夠這樣說：短鏈接是指SOCKET鏈接後發送後接收完數據後立刻斷開鏈接。

長鏈接

鏈接->傳輸數據->保持鏈接 -> 傳輸數據-> 。。。 ->關閉鏈接。 
長鏈接指創建SOCKET鏈接後不論是否使用都保持鏈接，但安全性較差。

http的長鏈接

HTTP也能夠創建長鏈接的，使用Connection:keep-alive，HTTP 1.1默認進行持久鏈接。HTTP1.1和HTTP1.0相比較而言，最大的區別就是增長了持久鏈接支持(貌似最新的 http1.0 能夠顯示的指定 keep-alive),但仍是無狀態的，或者說是不能夠信任的。

何時用長鏈接，短鏈接？

長鏈接多用於操做頻繁，點對點的通信，並且鏈接數不能太多狀況，。每一個TCP鏈接都須要三步握手，這須要時間，若是每一個操做都是先鏈接，再操做的話那麼處理速度會下降不少，因此每一個操做完後都不斷開，次處理時直接發送數據包就OK了，不用創建TCP鏈接。例如：數據庫的鏈接用長鏈接， 若是用短鏈接頻繁的通訊會形成socket錯誤，並且頻繁的socket 建立也是對資源的浪費。

而像WEB網站的http服務通常都用短連接，由於長鏈接對於服務端來講會耗費必定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的鏈接用短鏈接會更省一些資源，若是用長鏈接，並且同時有成千上萬的用戶，若是每一個用戶都佔用一個鏈接的話，那可想而知吧。因此併發量大，但每一個用戶無需頻繁操做狀況下需用短連好。

總之，長鏈接和短鏈接的選擇要視狀況而定。

發送接收方式

一、異步 
報文發送和接收是分開的，相互獨立的，互不影響。這種方式又分兩種狀況： 
(1)異步雙工：接收和發送在同一個程序中，由兩個不一樣的子進程分別負責發送和接收 
(2)異步單工：接收和發送是用兩個不一樣的程序來完成。 
二、同步 
報文發送和接收是同步進行，既報文發送後等待接收返回報文。 同步方式通常須要考慮超時問題，即報文發出去後不能無限等待，須要設定超時時間，超過該時間發送方再也不等待讀返回報文，直接通知超時返回。

在長鏈接中通常是沒有條件可以判斷讀寫何時結束，因此必需要加長度報文頭。讀函數先是讀取報文頭的長度，再根據這個長度去讀相應長度的報文。

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創建的速度

原文連接：
https://www.cnblogs.com/123hll/p/6923043.html

---

​

識別圖中二維碼,歡迎關注python寶典