[轉]微軟msn服務器設計思想初步理解
來源不明
由于工作需要，我用了近2個月的時間去了解msn的協議，通過長時間的抓包和試圖實現，我將我了解了的msn的服務器端的部分設計思想總結如下。
作為服務器設計，比較重要的幾個問題是：(不妥之處，希望大家修正）
1.安全性
2.并發服務能力
3.性能的可線性提高
一、安全性
服務器的安全性包括兩部分，一是服務器本身軟硬件配置上的安全性，比如防止系統漏洞；二是服務器和客戶端通訊協議的安全性設計，防止通過協議本身導致密碼泄露、服務器被非法攻擊等。
在協議上，msn的密碼是通過ssl傳送到服務器的；我對ssl的內部細節不是很了解，但是顯然，密碼經過ssl傳輸過程到服務器端后，是被明文解出的， 因此安全性依賴于ssl本身提供。在這方面，我傾向于yahoo的設計，密碼不通過自身的明文或者任何本身的加密后密文傳輸，而是同服務器返回的 session和password結合，進行混合的不可反向解密的md5密文進行傳輸。這樣的加密結果被任何第三方截獲都是沒有意義的；因為不可能從這樣 的密文中分析出原來的密碼。
我認為，傳輸協議中，密碼必須和服務器端協商的一個隨機seesion結合，通過不可恢復的加密方式進行加密，傳送到服務器，服務器端也是按照session和passowrd進行同樣方式的加密，比較加密結果，驗證用戶的合法性。
就軟硬件系統本身的安全性而言，我認為盡量把系統中不需要的軟件和其它模塊去除，保留服務器系統運行需要的最小內核；同時一臺服務器應該只提供該服務器需 要提供的服務，不開多余的網絡端口，對telnet方式禁止，而使用更安全的ssh進行遠程管理。
二、并發服務能力
服務器的并發服務能力是服務器程序設計的一個重要內容。
1、在單臺服務器上，服務器軟件的性能設計應考慮以下問題：
數據拷貝
內存管理
線程間的鎖控制
數據拷貝：
通常來說，避免數據拷貝是個非常頭疼的問題。我在平時的工作中，盡量把緩沖區的指針使用范圍限定在一定的作用域內，如果需要在作用域外使用，我通常會通過 數據拷貝的方式進行，這樣可以避免令人頭疼的內存泄露問題，一塊內存一旦在多個作用域使用或者在分配該內存的作用域之外使用時，很容易搞不清楚何時該釋放 該內存。
一個比較好的辦法是利用在COM里使用的引用計數技術，把該內存的釋放時機交給內存自己管理；也就是說把內存封裝進一個結構體或者類里，本身對自己被使用進行管理，一旦發現自己沒有人使用了，就釋放自己。
內存管理：
內存的處理也是很需要注意的一部分，頻繁的new /delete內存會讓內存出現大量碎片，對服務器軟件的性能也是有不小的影響的；通常的做法我們可以一開始申請一個比較大的內存區域，然后自己負責管 理，把這塊內存劃分成很多小塊（64B/ 128B/ 256B)，然后按照申請內存的需要，分配合適的內存區域。這樣可以不用每次都到系統申請內存，也把內存泄露的可能性限制在很小的范圍內（內存泄露應該被 解決）。
另外，對于一些對象，在我們使用完后，可以暫時不把它真正的從內存里釋放掉，而是把它掛到一個list上去，下次對于通用的對象，完全可以重用這快內存。這也是減少內存分配次數的一個辦法。但是這可能會導致使用很耗的加解鎖。
線程間的鎖控制：
涉及到鎖控制的，主要是因為共享問題。共享分為兩種：一是代碼共享部分；一是數據共享部分。其中做主要的還是數據共享部分。但是沒有什么好的解決辦法，唯一的辦法就是檢查這個共享是不是真正必要的，這些數據可不可以分成兩部分以形成不是共享的。
當然，這部分為軟老大做了什么我不清楚。
三、性能的可線性提高
這主要指服務器群組的服務能力可以通過增加服務器的方式線性提高性能。這就要求服務器的服務能力分擔是均衡的，即實現良好的負載平衡。新加入的服務器能均衡的被負載平衡服務器分配服務。
當然，這也設計到服務器集群、數據庫服務器的集群，我想找個時間專門研究這些問題。
在這方面，微軟的設計思想很好的體現了這個原則，能夠把負載均衡的交給新服務器。
msn 的認證服務器、聊天服務器分開的。即每次聊天時，都需要向認證服務器申請一個聊天服務器地址，然后在通過認證服務器邀請對方加入到這個聊天服務器，這就 保證了聊天的人會在同一臺服務器上，不用再到數據庫服務器查找對方的地址，也避免了頭疼的服務器數據同步問題。
如果新加入一個服務器，那么這太服務器只要在負載平衡服務器注冊，就可以和其他服務器不相干的為客戶端提供可靠的服務，當然群組的服務能力就線性提升了。
寫文專為與朋友們交流，對于內容中不妥之處，請多多指教：）