Web 服务器和游戏服务器有什么区别？
我想构建一款回合制多人 iPhone 游戏，需要在某个地方有一个游戏服务器来连接玩家并分发世界状态数据。我试图了解游戏服务器如何工作，以便我可以开始设计和构建它。到目前为止，我只有构建 Web 应用程序的经验，所以很自然地我想将游戏服务器设计为以与 Web 服务器类似的方式工作，但是可以吗？
我过去使用的 ASP.NET MVC Web 服务器的工作原理是，客户端向服务器发送对某些网页数据的请求，服务器生成 HTML、XML 或 JSON，并以 HTTP 数据包将其返回给客户端。对于多人游戏来说，这个过程听起来完全一样，只是客户端可能不会请求 HTML，但请求 XML 或 JSON 数据是有意义的，对吗？
所以我的问题是...
- 可以使用 ASP.NET MVC 编写游戏服务器，并使用我设计的 RESTful API 与 Web 服务器一样工作吗？
- 有没有比使用包含 XML 或 JSON 数据的 HTTP 数据包更好的方法来请求和接收游戏数据？从游戏服务器返回的数据会很小。
- 使用 RESTful API 从 Web 服务器访问数据很有意义，但使用 RESTful API 从游戏服务器请求游戏数据没有意义，事实上，听起来可能会导致安全问题，您的想法是什么？
- 最后，有人可以推荐一些好的游戏书籍，其中展示了如何构建一个像样的游戏服务器的示例吗？
预先非常感谢您的帮助！
I'd like to build a turn-based, multiplayer iPhone game that will require a game server somewhere to connect the players and dish out the world state data. I'm trying to understand how the game server will work so I can begin designing and building it. Up until now, I only have experience with building web applications and so naturally my mind wants to design the game server to work in a similar fashion as a web server, but can it?
The ASP.NET MVC web servers I've used in the past work by the client sending a request for some web page data to the server and the server generates the HTML or XML or JSON and returns it to the client in an HTTP packet. This process sounds exactly the same for a multiplayer game, except the client probably won't be requesting HTML, but it would make sense to request XML or JSON data, right?
So my questions are...
- Can a game server be written using ASP.NET MVC and work the same as a web server using a RESTful API designed by me?
- Is there a better approach to requesting and receiving game data than using HTTP packets with XML or JSON data packed into them? The data being returned from the game server will be small.
- Using a RESTful API to access data from a web server makes good sense, but using a RESTful API to request game data from a game server doesn't make sense and, in fact, sounds like it could cause security issues, your thoughts?
- Lastly, can anyone recommend any good game books that show examples on how to build a decent game server?
Thanks so much in advance for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
主要区别在于 Web 服务器使用（相对）很少或不使用状态信息来生成大量相对静态的内容。即使使用状态，它通常也特定于会话或用户。读取比写入频繁得多，因此缓存有助于提高吞吐量。您还可以信任 Web 浏览器以（相对）可靠的方式传递一些状态数据和 cookie。
相反，游戏服务器大多数时间处理来自客户端的更新，保留大量全局状态（所有游戏、玩家、状态状态），并在客户端请求时向客户端发送状态更新。缓存是不可能的，而且您不能相信您的客户会告诉您一天中的时间 - 您必须假设他们会尝试以任何方式进行欺骗。
使用 REST API 不是一个问题，因为您可以使用已经使用的标准身份验证机制。
《美丽的建筑》一书的第 3 章描述了 Darkstar 的建筑（现在RedDwarf) 项目，一个用于在线游戏和虚拟世界的可扩展应用服务器。虽然 RedDwarf 的规模比您想要的大得多，但这本书确实描述了创建游戏服务器时需要解决的问题。
The main difference is that a web server generates a lot of relatively static content using (relatively) little or no state information. Even when state is used, it is usually specific to the session or user. Reads are a lot more frequent than writes, so caching can help increase throughput. You can also trust web browsers to pass some state data and cookies in a (relatively) reliable way.
A game server on the contrary most of the time handles updates from clients, keeps a large amount of global state (all game, player, status state) and sends status updates to clients when they request them. Caching is impossible and you can't trust your clients to tell you the time of day - you have to assume they will try to cheat in whatever way they can.
Using a REST API is not such a problem, as you can use the standard authentication mechanisms you use already.
Chapter 3 of the book "Beautiful Architecture" describes the architecture of the Darkstar (now RedDwarf) project, a scalable application server for online games and virtual worlds. While the scale of RedDwarf is MUCH bigger than what you want, the book does describe what you need to address when creating a game server.
网络服务器缺少一个重要组件...
IE。他们是无国籍的。整个网络平台（以及一般的 HTTP 服务器）基于无状态模式，这意味着当您从一个页面切换到另一个页面时，它们不会保留数据。
有一些方法可以绕过这个限制。在客户端：您可以在浏览器打开时使用会话来保存数据；或 cookie 来长期存储数据。在服务器端：数据库通常用于长期存储状态。所以...
是的，但是根据您想要存储游戏会话状态的数量和时间，您可能会发现单独运行游戏服务器/引擎（而不是作为网络服务器）会给您带来未来有更多的扩展/增长空间。
是的，也不是……XML/JSON 几乎是在互联网上传递对象状态的方法，因为它简单且独立于平台。由于您可能/不编写自己的服务器后端，我建议您考虑使用 XML -RPC，然后再考虑从头开始推出自己的解决方案。
我不知道你为什么对安全如此偏执。如果您对可接受的请求/响应周期实施相当严格的访问策略，那么就不应该有任何问题。正如我之前所说，研究一下 XML-RPC。关键是，不要让用户访问超出其需要的游戏服务器数据。
不，主要是因为我不写游戏。尽管如此，我确实有编写客户端/服务器架构应用程序的经验，而且这并不是火箭手术。我建议您考虑加入即将进入测试版的游戏开发 Stack Exchange 常见问题解答网站。
Webservers are missing one important component...
IE. They're stateless. The whole platform of the web (and HTTP servers in general) is based on the pattern that they're stateless meaning they don't hold on to data when you switch from page-to-page.
There are ways around the limitation. On the client-side: you can use a session to hold data while the browser is open; or cookies to store data over a longer term. On the server-side: databases are usually used to store state long-term. So...
Yes, but depending on how much and how long you want to store the state of a game session, you might find that running the game server/engine separately (and not as a webserver) will give you a lot more room to scale/grow in the future.
Yes, and no... XML/JSON is pretty much the way to pass object state around the internet because it's simple and platform-independent. Since you may/not be writing your own server backend I'd suggest you take a look into using XML-RPC before you consider rolling your own solution from scratch.
I'm not sure why you're paranoid about security. If you implement a pretty strict access policy for what an acceptable request/response cycle is there shouldn't be any issues. Like I stated before, look into XML-RPC. The key is, don't give the user access to any more of the game server data than they need.
Nope, mostly because I don't write games. Although, I do have experience writing client/server architecture apps and it's not rocket surgery. I suggest you take a look into joining the Game Development Stack Exchange FAQ site that's about to hit beta.