# Web 服务器与游戏服务器
桌游电子化项目中，我第一次在完整的项目背景下尝试 WebSocket 的使用，架构的结果不太令人满意，涉及 WebSocket 通信的操作我都不敢点得太快，生怕出错。
那些 FPS 游戏的服务器是怎么做到处理成吨的操作还能稳定运行的呢？是 WebSocket 不行吗？是 C++ 的游戏服务器比 Java 的 Web 服务器牛哔吗？带着这些疑问，我踏上了寻找答案之路。
通过查阅大量资料，观点归纳如下：
Web 服务器关注高吞吐量，游戏服务器关注低延迟。
很好理解，就像上面提到的 FPS 游戏，对于用户的射击操作，游戏服务器必须快速反应并与客户端同步，如果你打完子弹出现一个 loading 动画，几秒后对面的人才倒下，你一定把这个游戏制作者的祖宗三代都骂完了；Web 服务器方面，我们想象淘宝，同一时间买家们可能查看大量不同的商品信息，从图片到文字描述，数据量相对来讲大了很多，但买家可以接受 loading 三秒再看到完整的商品信息。
Web 服务器是无状态的，游戏服务器是有状态的。
这也是因为关注点的不同。游戏服务器关注低延迟，所以数据直接保存在内存中，以便频繁读写；而 Web 服务器为了吞吐量考虑，服务端通常会做分层，数据也是持久化存储在数据库里，这样一来，延迟就被加大再加大。非常典型的一个例子是：Web 服务器修改数据一般是提交一个事务，如果产生冲突将会回滚，而回滚在游戏服务器是完全不能接受的，总不能让刚才那个被你打死的对手再站起来吧（x
Web 服务器通过 HTTP 协议建立短连接，游戏服务器通过 Socket 建立长连接。
传统意义上，Web 服务器只从客户端发送请求、从服务端接收响应，可以根据请求地址的不同访问不同的服务端点；而游戏客户端和服务器通过 Socket 连接后，两端都会有一个连接对象，地位基本平等，可以互发消息，且连接只允许与这一个服务器通信。
Web 服务器和游戏服务器都是服务器，本质上没有区别。
虽然上面罗列了很多 Web 服务器与游戏服务器的不同，但要注意，这些都只是 传统 意义上的理解。
然而，时至今日，我们或许应该将它们理解为服务器两种不同的客户端交流方式。Web 应用中，也会有服务器推送的需求，也会有即时性的场景（这也是 WebSocket 出现的原因）；而一些弱联机游戏，比如不需要快速响应的卡牌类游戏，Web 服务器也能够满足其需要。
而作为服务器，它们都有高并发处理的需要——淘宝双十一零点要面对上千万的购买请求，MMO 游戏要处理同屏上千人的移动攻击……它们也都可以进行分布式的架构。
# 总结
总而言之，现在我们似乎更应该把 Web 和游戏看作服务器与客户端交互方式的两种典型代表。客户端会同时出现这两种需要，服务端也应该可以兼容这两种方式的处理。
至于我的 WebSocket 为什么那么烂……多线程并发啥的咱都不懂，也没有网络框架的辅助，能不烂嘛！