今天有乙個哥們在群裡問關於手機即時通訊開發的事情，然後我們就開始聊上了,對此我也發表了一些自己的看法。
大家都知道在iphone端做及時通訊很好做，因為蘋果已經封裝好了系統推送的介面，所有推送都是通過蘋果伺服器建立的那個唯一的socket連線。
但是放在android終端就有一些困難了，首先android在2.2才推出了c2dm服務，不過這個東西在中國這個地方似乎不怎麼試用，首先手機的版本問題難以解決，然後就是定製化太嚴重。
所以對於android及時通訊而言只能自己架設伺服器完成這個事情了。
說道自己構建伺服器就無可避免的談到伺服器負載,效能的一些問題,我首先想到的是p2p技術,這樣伺服器只負責打洞，可以大大的減少伺服器壓力。不過這一套似乎在移動終端很難實現,首先是移動終端的不穩定性,其次就是運營商對p2p做了限制,總之這條路在移動領域很難走通了。
後來有考慮用一些第三方的框架，比如android的第三方的androidpn，這些似乎伺服器要求很高，一台64的linux伺服器只能承載4w使用者，即時最大優化也只能承載5w，那如果使用者有100w不是需要20臺伺服器？這樣對於很多公司而言都是一筆很大的成本。
然後我又思考了一下到底什麼才是瓶頸，如果建立tcp長連線的話無疑是非常浪費伺服器資源的，既然如此我就想到了另外的一種模式，那就是udp負責保持連線，tcp負責傳送訊息的模式。
大家都知道，udp不是面向連線的，所以理論上來講一台伺服器可以開無限個udp，而且udp消耗相對於tcp小，至於如何報錯udp的不穩定性？我們可以把協議擴充一些比如時間戳，接收回執，失敗重發,傳送報文減小到乙個包裡面，等等.反正只作為通知用，報文不需要太大。
基於上面的理論，我假設有兩台伺服器一台負責udp保持連線，一台用於tcp傳送訊息。我們不需要tcp保持長時間連線，每次傳送完成之後斷開連線即可，我們甚至可以用http伺服器作為訊息傳送容器。而udp伺服器主要是用於心跳響應和通知終端去伺服器取訊息。
這樣我們只需要測試tcp伺服器最大的負載能力以及udp保持的最大連線數即可。如果是http伺服器測試就更加方便了。至於伺服器集群之類的我就不說了，老身長談。
以上只是我個人的拙見，我也不是專門搞這一塊的，也沒有經過測試，只是我一時突發奇想，如果有什麼不對的地方也請大家不要建議，也希望大家能夠多多討論。
還有一些人問我，那不如直接全部用udp不是更簡單，針對這一點我想說的是，udp是不確定內容完整性的。及時通訊一般傳輸的都是字元流，我們很難確保發出去的包都能收到，而且接收的順序不確定性（當然也有一些擴充套件協議能夠補充這一點），所以傳送訊息不如直接用tcp協議，這樣可以確保伺服器能夠收到而且也省了很多麻煩。
當然這個想法應該不是我第乙個想到的，也許已經有一些公司嘗試過了，或者已經有成熟的產品在運用，還是請大家多多拍磚 呵呵。
即時通訊系統
企業擁有一套理想的即時通訊系統，正如找到了一位得心應手的商務秘書。然而，縱觀當前企業即時通訊市場，同質化的即時通訊軟體比比皆是，而能夠讓企業真正根據自身需要來按需定製 人性化開發的即時通訊系統卻少之又少。傳統開發理念讓企業被動使用即時通訊。目前，大多數的軟體提供商還在用傳統的開發理念來開發企業即時通...
即時通訊系統IM
背景 即時通訊 instant messaging 是目前internet上最為流行的通訊方式，各種各樣的即時通訊軟體也層出不窮 服務提供商也提供了越來越豐富的通訊服務功能。不容置疑，internet已經成為真正的資訊高速公路。從實際工程應用角度出發,以計算機網路原理為指導,結合當前網路中的一些常用...
即時通訊系統架構
先看狀態訊息系統 connd client接入伺服器，可以支援udp，也可以支援tcp，一般建議優先選擇tcp。connd可以布置多台，client接入時，可以用簡單的dns輪詢的方式實現負載均衡。connd功能是維護連線和 訊息包。pconnd proxy connd,接入伺服器，是connd的擴...