Netty中，耗時的業(yè)務(wù)邏輯代碼應(yīng)該寫在哪

netty是個網(wǎng)絡(luò)編程的框架，按照正常高并發(fā)系統(tǒng)的分層原則，這一層都不應(yīng)該有耗時的程序，因為這一層的阻塞代表著所有客戶端無法和服務(wù)器建立連接。

當(dāng)你的系統(tǒng)并發(fā)量上來時，這一層必須快速處理連接建立及收發(fā)包，這一層的cpu都是給io用的，你如果分出來幾個線程處理耗時邏輯，一旦阻塞，cpu就扛不住了。

android中netty使用udp連接能發(fā)送數(shù)據(jù)

我的也是,不知道怎么回事,在普通java工程中去連接就沒問題,在android中就是連接超時

WebSocket是什么原理為什么可以實現(xiàn)持久連接

首先需要明白：基于TCP的應(yīng)用層協(xié)議，只要設(shè)計者愿意，都是可以實現(xiàn)持久連接的。

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

http協(xié)議是請求應(yīng)答式的文本協(xié)議，協(xié)議設(shè)計就是Client-Server模式，出發(fā)點是服務(wù)端為客戶端提供資源。http服務(wù)端只能監(jiān)聽和響應(yīng)來自客戶端的請求，http客戶端只能發(fā)起請求接受響應(yīng)，這個是HTTP協(xié)議本身的設(shè)計，雙向通信不在設(shè)計的考慮之內(nèi)。

關(guān)于Http協(xié)議，額外說點：

HTTP1.0/0.9

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

HTTP1.1

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

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

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

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

HTTP2.0

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

HTTP相關(guān)知識推薦《HTTP權(quán)威指南》以及相關(guān)的RFC文檔，盡量少去看博客上面支離破碎的小知識，體系化的認(rèn)知結(jié)構(gòu)對你幫助更大。

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

現(xiàn)代的Web場景，服務(wù)端推送的需求非常大，這個發(fā)展過程中使用的Ajax輪詢，Comet等都只是臨時解決方案，從設(shè)計上看，只為滿足需求，一點都不優(yōu)雅。

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

websocket協(xié)議實現(xiàn)獨占一條tcp通道，它負(fù)責(zé)從tcp流確定消息邊界，解析出每個獨立的消息包?？蛇M(jìn)行全雙工的雙向通信。題主所謂的WebSocket可以實現(xiàn)持久連接，只是的一個服務(wù)端WebSocket會話和對應(yīng)的客戶端WebSocket會話在使用一個固定的保持連接的TCP通信而已。一般需要將服務(wù)端WebSocket會話和某位用戶關(guān)聯(lián)起來（客戶單連接后，可以再單獨發(fā)送憑證驗證），實現(xiàn)給某個用戶推送消息，只需根據(jù)關(guān)聯(lián)找到對應(yīng)的WebSocket會話調(diào)用發(fā)送API即可。

使用單獨實現(xiàn)websocket協(xié)議的服務(wù)\客戶端組件，可以更加輕松地實現(xiàn)自定義協(xié)議：在websocket的二進(jìn)制或者文本消息體內(nèi)或者直接使用websocket的自協(xié)議定義機(jī)制封裝自己定義的協(xié)議。

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

如果你要用websocket實現(xiàn)請求應(yīng)答式的子協(xié)議，要點是你要設(shè)計唯一的請求標(biāo)志，響應(yīng)也將請求標(biāo)志帶回來，然后你就可以從客戶端的請求隊列中查找響應(yīng)對應(yīng)的請求將響應(yīng)交給上層處理！

特別注意：

關(guān)于webcket持久連接，本質(zhì)上是下層tcp連接的保持，核心問題同樣是如何保活。需要考慮Nat失效（基站最突出，一般有效期只有3分鐘）或者其它網(wǎng)絡(luò)原因?qū)е麓罅堪脒B接存在。解決方案就是合理的心跳時間，一般我設(shè)置為2分50秒的樣子。

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

和網(wǎng)絡(luò)IO密切相關(guān)的就是線程，要設(shè)計高可用的TCP服務(wù)器，必須要熟悉多線程。網(wǎng)絡(luò)IO和多線程是我認(rèn)為最重要的兩個核心知識點。

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

如果時間允許，有標(biāo)準(zhǔn)的協(xié)議最好看看RFC文檔，現(xiàn)在Chrome的翻譯已經(jīng)很好了，如果英文不太好，問題也不大。

《計算機(jī)網(wǎng)絡(luò)：自頂向下方法》和謝希仁的《計算機(jī)網(wǎng)絡(luò)》都是不錯的入門書籍。

《TCP/IP詳解》是經(jīng)典，雖然出版已久，內(nèi)容是沒過時的。

網(wǎng)絡(luò)應(yīng)用脫離不了操作系統(tǒng)，所以可以再看看操作系統(tǒng)關(guān)于網(wǎng)絡(luò)IO這一塊的設(shè)計。

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

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

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

如何實現(xiàn)單服務(wù)器300萬個長連接的

1.事件驅(qū)動，這個只是為了IO和CPU異步，讓CPU從IO等待中解放出來，這樣就能在CPU循環(huán)中往死里accept連接了，nginx就靠這個把apache玩死的，nodejs的快不僅僅因為這個，語言層的magic就扯遠(yuǎn)了。

2.利用雙核，2個核就2個進(jìn)程，一個進(jìn)程一個事件驅(qū)動核（epoll，select啥的），增加鏈接吞吐。

3.參數(shù)調(diào)優(yōu)，這才是最重要的一步，一個Socket連接默認(rèn)是有內(nèi)存消耗的，我不記得Python的Socket占用是4M還是多少來著了，當(dāng)然這個也可以調(diào)優(yōu)，eurasia的作者沈大俠說過可以搞到2M來著？當(dāng)然這對于一個24G的服務(wù)器來說300w還是搞不定的，但是就送TCP本身來分析的話，tcp_rmem/tcp_wmem，這2個系統(tǒng)tcp讀寫緩存默認(rèn)都很高，拉低到4k，然后把tcp_mem也得改下，這個說起來太麻煩，man一下就有了，總的來說就是得拉高High值

4.網(wǎng)卡要給力，端口給足，句柄加高。