首先需要明白：基于TCP的應用層協議，只要設計者愿意，都是可以實現持久連接的。

你問的方式，大概是在和HTTP做比較。

HTTP

http協議是請求應答式的文本協議，協議設計就是Client-Server模式，出發點是服務端為客戶端提供資源。http服務端只能監聽和響應來自客戶端的請求，http客戶端只能發起請求接受響應，這個是HTTP協議本身的設計，雙向通信不在設計的考慮之內。

關于Http協議，額外說點：

HTTP1.0/0.9

不支持keep-alive，要完成一次HTTP請求，需要建立一個新的TCP連接，然后發送http請求，待接收響應后關閉連接。

HTTP1.1

默認使用keep-alive，一次HTTP請求完成后不會關閉TCP連接，會繼續為下一個HTTP請求服務（可以類比數據庫連接池和線程池的設計），減小建立和關閉TCP連接的開銷（三次握手四次揮手）。當然閑置超時后也會關閉。并非樓下所說的“把多個HTTP請求合并為一個”。

HTTP協議的設計無法實現對TCP通道的分用和復用。因為HTTP協議沒有請求的唯一標記（僅僅是URL是不行的，原因大家想）用來從同一TCP通道分離不同的HTTP消息，所以一個完整的HTTP請求在發送請求到響應回來之間是獨占一個TCP通道的！是不是覺得HTTP對TCP的利用率太低了？而關于pipeline模式，不管在服務端還是客戶端排隊，HTTP響應依然要通過進入服務端隊列的順序返回，這樣才能和客戶端HTTP請求隊列用順序做對應！所以pipeline模式某個請求被服務端因為某些原因阻塞了的情況下，后續請求都會阻塞，會引起很大的問題，實際上很少用。

瀏覽器或者一般HTTP客戶端組件為某一個服務器端點（域名+端口）保留4-6條活躍TCP連接。你可以F12觀察瀏覽器，看看同時是幾個請求阻塞了就知道你的瀏覽器設置的多少。比較大的門戶網站，比如京東，首頁請求非常多，但是大量都需要排隊等TCP空閑。限制客戶端的連接數量的出發點主要是性能，否則會占用服務器太多Socket資源（考慮socket預留的讀寫緩沖區，windows的內核對象或者linux的文件句柄）或者變相地造成DoS攻擊。

Tips：HTTP客戶端組件一般會提供諸如ConnectionLimit的選項讓你控制最大TCP連接數。如果你是桌面客戶端，或者請求遠程服務，不宜設置過大。如果你是內部服務之間調用，可以根據需求合理設置以增加并發性能。

HTTP2.0

針對以上的問題（主要是性能）做了很多改進，這個也會提高很多人在后端不同服務器之間做通信時選擇HTTP（我在HTTP2.0出來之前就是自己設計RPC方案）。詳細的HTTP2.0的東西，這里不展開了，詳細參考官方文檔。

HTTP相關知識推薦《HTTP權威指南》以及相關的RFC文檔，盡量少去看博客上面支離破碎的小知識，體系化的認知結構對你幫助更大。

WebSocket

WebSocket的出現，就是為了解決http協議不支持雙向通信的缺口。所以WebSocket的握手協議就是使用的HTTP消息來Upgrade。

現代的Web場景，服務端推送的需求非常大，這個發展過程中使用的Ajax輪詢，Comet等都只是臨時解決方案，從設計上看，只為滿足需求，一點都不優雅。

Html5規范將WebSocket納入后，得到了現代幾乎所有瀏覽器的支持，當然IE（10+才支持）仍然是一個巨坑，在乎用戶覆蓋面的產品依然要通過瀏覽器是否支持ws來做出降級處理（輪詢、長連接）。

websocket協議實現獨占一條tcp通道，它負責從tcp流確定消息邊界，解析出每個獨立的消息包。可進行全雙工的雙向通信。題主所謂的WebSocket可以實現持久連接，只是的一個服務端WebSocket會話和對應的客戶端WebSocket會話在使用一個固定的保持連接的TCP通信而已。一般需要將服務端WebSocket會話和某位用戶關聯起來（客戶單連接后，可以再單獨發送憑證驗證），實現給某個用戶推送消息，只需根據關聯找到對應的WebSocket會話調用發送API即可。

應用

使用單獨實現websocket協議的服務\客戶端組件，可以更加輕松地實現自定義協議：在websocket的二進制或者文本消息體內或者直接使用websocket的自協議定義機制封裝自己定義的協議。

推薦大家如果有些需要自建IM服務器，推送服務器的場合嘗試先用WebSocket來實現。負載高（協議頭消耗小），協議簡潔，幾乎所有客戶端（減少了大量的工作）都有對應的開源項目可用，同時還是唯一可以在瀏覽器上用的雙向通信協議（flash和silverlight等插件方式除外）。

如果你要用websocket實現請求應答式的子協議，要點是你要設計唯一的請求標志，響應也將請求標志帶回來，然后你就可以從客戶端的請求隊列中查找響應對應的請求將響應交給上層處理！

特別注意：

關于webcket持久連接，本質上是下層tcp連接的保持，核心問題同樣是如何保活。需要考慮Nat失效（基站最突出，一般有效期只有3分鐘）或者其它網絡原因導致大量半連接存在。解決方案就是合理的心跳時間，一般我設置為2分50秒的樣子。

其它

不論是否從事網絡編程，都應該花時間學習下TCP/IP協議簇方面的知識，著重理解分層原理，各層的功能和為上層提供了哪些功能。就像這個問題，如果不對TCP有所了解，回答的內容就沒多大意義了。閱讀一個你比較熟悉的語言的的一種協議（比如http）實現項目的源碼，幫助應該很大。

和網絡IO密切相關的就是線程，要設計高可用的TCP服務器，必須要熟悉多線程。網絡IO和多線程是我認為最重要的兩個核心知識點。

關于協議的設計，你可以多學習其他優秀的基于TCP實現的應用層協議，簡單的就有Redis的通信協議，里面有阻塞式的消費者隊列，那個就需要一條單獨的tcp通道。協議設計是很有意思的一件事情，就是mysql和mongodb的通信協議我也不會放過，去看看，會給自己設計協議帶來不少的參考價值。

如果時間允許，有標準的協議最好看看RFC文檔，現在Chrome的翻譯已經很好了，如果英文不太好，問題也不大。

關于TCP/IP相關的書籍

《計算機網絡：自頂向下方法》和謝希仁的《計算機網絡》都是不錯的入門書籍。

《TCP/IP詳解》是經典，雖然出版已久，內容是沒過時的。

網絡應用脫離不了操作系統，所以可以再看看操作系統關于網絡IO這一塊的設計。

實際開發更多和Socket以及多線程打交道，Windows下面可以看看《Windows核心編程》。

其它的就是開源項目：Nginx，netty等大量優秀的項目都在等你。

還是要感謝大家對我寫的東西有那么一點感興趣，能對大家有所幫助就更好了。