編號項按層從下到上。
網路
1.native api:socket, select, iocp, epoll訊息&序列化2.網路庫:ace, boost.asio, libevent
有些方案是序列化和rpc一起提供的，比如fb的thrift。
3.訊息中介軟體（以下為不同方案，非分層。）:rpc：（調研還不是很仔細）本地呼叫遠端函式的方式，而非發訊息了。每個rpc本質上還是乙個訊息，所以個人感覺可以基於mq實現，也就是可以在mq層之上。但是mqnewer 把rpc和mq做為兩種並列的訊息中介軟體。訊息：一般來說都是非同步的。
直接發訊息：不是用中介軟體，接收訊息的只做乙個訊息快取佇列。自己解析訊息，呼叫對應的函式。返回值也通過發乙個訊息給客戶端實現。
訊息佇列
：使用通用的mq協議如amqp，或庫如zeromq。個人感覺mq的很多特性遊戲用不到：確保資訊傳輸並且是一次且僅一次(once-and-only-once)的傳遞，這個是指消費者掛了重啟後還可以從mq中讀取訊息，但是遊戲的各個服是有狀態的（各種玩家資訊），掛了重啟後這些資訊沒了，有訊息也沒用，這個特性只有無狀態的或能儲存狀態的消費者才有用。mq還可以加一層介面卡，目前只了解到stomp，還不知道有何用以及在mq之上還是之下。
傳統的mq如rabbitmq、activemq等都有訊息中介軟體，啟動第三方服務程序。而zmq就應用程式端點扮演了這個服務角色，原理和其它幾種差別太大了。其實和上面的直接發訊息也差不了多少，只是提供更多模式選擇。
同步rpc：初接觸的rpc都是這種，效率低，遊戲服務端應該不會用的。4.序列化: protobuf, amf 這個算不上分層，最上的應用是將傳送的包先經過序列化後才放入mq中。不需要返回值的非同步rpc：就等於直接發訊息了。
非同步rpc：配合coroutin可以實現非同步rpc，這種應該是最完美的。
網路協議簡述
英文名稱 hyper text transport protocol 中文名稱 超文字傳輸協議 ftp 英文名稱 file transfer protocol 中文名稱 檔案傳輸協議 功能介紹 該協議是從internet上獲取檔案的方法之一，它是用來讓使用者與檔案伺服器之間進行相互傳輸檔案而用的，通...
簡述網路協議
這張圖表明了協議之間的關係.以下內容均來自csdn 和 chinaunix 傳送協議的主機從上自下將資料按照協議封裝，而接收資料的主機則按照協議從得到的資料報解開，最後拿到需要的資料。這種結構非常有棧的味道，所以某些文章也把tcp ip協議族稱為tcp ip協議棧 互連網早期的時候，主機間的互連使用...
網路知識（簡述）
三次握手，四次揮手，為什麼要四次揮手 確保資料能夠完整傳輸,主動方和被動方 tcp連線建立 使用三次握手建立連線 1 客戶端傳送請求 定址請求 syn 2 伺服器端收到報文請求，回應客戶端 確認請求 syn ack 3 客戶端收到服務端的報文進行回應。連線請求 三次握手完成，tcp客戶端和服務端成功...