游戏网络通信的流程则是服务端先开启监听，等待客户端的连接，然后交互操作，最后断开。
套接字
每个Socket都包含网络连接中一端的信息。每个客户端需要一个Socket结构，服务端则需要N+1个Socket结构，其中N为客户端的连接数，另外一个是服务端打开监听的套接字。
单线程事件模型(Reactor模型)
单线”指的是单线程，“事件”指的是事件触发，即当新连接、断开连接、收到数据这些事件到来时会触发某段代码。
一致性问题是分布式系统的一大难题
可能会出现很多异常情况：重复执行等，需要保持一致性；
操作系统
单个程序中可能会存在一些阻塞语句让CPU空闲，开启多个程序可以填补CPU的空闲时间。比如：
readFileSync
var server = net.createServer(function(socket){
//新连接
var data = fs.readFileSync('save.txt');
//...
//断开连接
socket.on('close',function(){
fs.writeFileSync('save.txt', data)
});
});
如果程序中不包含阻塞语句，且运行在单核CPU下，同台物理机下部署多个程序是不能提升性能的。不过当代大多是多核CPU，可以同时执行多个程序，因此在非阻塞程序中，开启与CPU核心数相当的进程可以充分利用CPU。
阻塞为什么不占用CPU
常见的一些阻塞函数:等待客户端连接的accept函数，接收数据的recv函数等。那阻塞为什么不会占用CPU资源呢：
操作系统会分时执行各个运行状态的进程，由于速度很快，看上去就像是在同时执行多个任务。
阻塞了会到等待队列，等到条件成立（比如等待一段时间）操作系统会重新将进程A放入工作队列中，继续执行。
切换线程
CPU切换线程需要做很多工作，它执行一条语句大概需要几纳秒，完成一次线程切换大概需要几微秒，花销较大。开启的线程数越多，CPU就需要做更多的切换工作，这会使响应变慢。
网络模块的底层实现有两种方式：
1）每当有新的客户端连接时，开启新线程处理该客户端。
2）使用多路复用技术，所谓“多路”，指的是服务端可以阻塞（如使用epoll_wait）等待多个客户端的连接，有任何一个收到数据即返回。
Web服务器可以用这两种方法，但游戏服务端大多只会用第2种方法。这是因为Web服务器都是短连接，发送消息后即断开，同时在线的客户端很少；游戏服务端大多是长连接，同时在线的玩家很多，方法1只能支持数百名玩家。
难以分割的业务
实现分布式程序的前提是游戏逻辑能够分割。如果游戏规则复杂，各个功能紧密相连，则不容易找到分割的方案。
actor
合理分割功能是分布式模型的一大难点，我们需要寻找一种模式，它既能符合游戏逻辑的表达，又能让计算机高效执行。传统的多进程方式很多场景不能满足游戏逻辑的表达；
每个Actor都会包含自身状态（HP、Coin），以及一个信箱（消息队列），Actor通过给其他Actor“寄信”来实现通信。至于收到信件后的反应，取决于收信的Actor。
由于各个Actor相互独立，计算机很容易让它们并行工作。
对游戏服务端而言，Actor并发模型给游戏业务的分割提供了灵活性。
Skynet的强项在于单个节点内的并行运算
启动流程
skynet.socket模块
socket.read中所谓的阻塞模式和skynet.call一样，都利用了Lua的协程机制。调用socket.read，服务有可能被挂起，直到接收到数据，才会往下执行。
skynet协程
Skynet服务在收到消息时，会创建一个协程，在协程中会运行消息处理方法（即用skynet.dispatch设置的回调方法）。这意味着，如果在消息处理方法中调用阻塞API（如skynet.call skynet.sleep、socket.read），服务不会被卡住（仅仅是处理消息的协程被卡住），执行效率得以提高，但程序的执行时序将得不到保证。
