游戏协议
是否有任何可以用来制作游戏的标准协议（例如http、ftp），因为当我在随机端口（1024-65300）上测试连接时遇到问题（我必须在路由器上转发端口，它只一次与一台计算机一起工作）。
应该有，即时通讯程序使用某些东西，并且无需设置任何端口...
您知道我可以使用什么吗？ 我使用 C
++ 我对类似于 http 的东西感兴趣，有人发送请求，另一人发送响应。 我在 html 中看到你必须发送到 ip/index.html 或类似的东西，我不太明白如何使用......
Are there any standard protocols with witch you could make games with (like http, ftp), as i had problems when I tested a connection on a random port (1024-65300) out (I had to forward ports on my router and it only works with one computer at a time).
There should be, im programs use something and there is no need to set up any ports...
Do you have any idea what I could use? i use c++
p.s. I would be interested in something similar to http, someone sends a request and the other sends response. I saw in html you have to send to ip/index.html or something like that which I don't really understand how to use...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
IM 程序不需要任何开放端口，因为它们是客户端程序。 作为一般规则（注意出站防火墙），所有端口都对客户端上的传出连接开放。 为了实际接受连接，端口必须允许传入流量。 例如，大多数服务器可以接受所有端口上的传入流量。 网络通信和协议的设计考虑到了这一点：客户端（您的浏览器）始终发起与服务器（网站）的连接，而不是相反。
至于协议，您应该使用 TCP/IP 或 UDP，具体取决于您需要执行的操作。 如果您打算让您的客户端通过使用近似值来获取游戏帐户丢失的信息（大多数 FPS 游戏都这样做，以及几乎任何需要非常快速反应的游戏），那么 UDP 就很棒，而 TCP/IP 更简单，将大大减少传输错误，并且更容易出现滞后。 两者之间的主要区别在于 UDP 是“即发即忘”，这意味着它不会费心检查消息是否确实到达目的地。
至于最重要的协议，你提到了http和ftp。 我强烈建议两者都不使用。 当您在自定义端口上使用直接套接字通信时，您可以自由地制定自己的协议以供游戏使用。 只要它通过来回发送数据包来完成其工作，其他所有事情都完全取决于您，而且应该如此。 毕竟，游戏协议需要快，除非您确实需要，否则您不希望来自 http 的所有这些额外标头垃圾堵塞您的网络传输。
请记住：网络连接需要两个部分：客户端和服务器。 这意味着您要么为游戏设置了中央服务器，要么让一名玩家“托管”游戏（作为服务器，他需要打开端口）。 其他玩家（中央服务器设置中的所有玩家）连接到中央人员，并通过他传递通信。 这意味着您的游戏协议需要两个部分，服务器端和客户端。 大多数游戏中的客户端都是盲目运行的，因为它会发送有关用户的玩家信息，然后依靠服务器更新来告诉它游戏中其他所有内容的位置。 服务器应该负责从所有客户端收集玩家信息，然后将该信息分发给其他人。 这可以包括验证（大多数这样做）以防止游戏中发生“非法”事情，但这取决于您。
IM Programs don't require any open ports because they are client programs. As a general rule (watch out for outbound firewalls) all ports are open for outgoing connections on a client. In order to actually accept connections, the port has to allow incoming traffic. Most servers, for example, can accept incoming traffic on all ports. Network communications and protocols are designed with this in mind: the client (your browser) always initiates the connection to the server (the website), not the other way around.
As for a protocol, you should use either TCP/IP or UDP, depending on what you need to do. UDP is great if you plan to have your client for the game account for missing information by using approximation (most FPS games do this, as well as just about any game that requires very quick reflexes) where TCP/IP is simpler, will greatly reduce errors in transmission, and be more prone to lag. The main difference between the two is that UDP is "fire and forget," meaning that it doesn't bother to check to see if the message actually arrived at its destination.
As for the protocol on top of that, you mentioned http and ftp. I would greatly advice using neither. When you're using direct socket communication on a custom port, you have all the freedom of crafting your own protocol for the game to use. So long as it gets its job done by sending packets back and forth, everything else about it is completely up to you, and should be. After all, a game protocol needs to be fast, you don't want all this extra header garbage from http clogging up your network transmissions unless you really need it.
Just remember: network connections require two parts, a client and a server. This means that you either have a central server set up for the game, or you have one player "host" the game (acting as a server, he will need his ports open). The other players (all players, in a central server setup) connect to the central guy, and pass communication through him. This means that your game protocol needs two parts, a server end and a client end. The client in most games sort of runs blind, in that it sends off player information about the user, and then relies on server updates to tell it where everything else in the game is. The server should be in charge of collecting player information from all clients, and then distributing that information to everyone else. This can include validation (most do) to prevent "illegal" things from happening within the game, but that's up to you.
这个问题比仅仅使用特定端口或协议通过 NAT 稍微复杂一些。 您可以在此处获取更多信息。
The problem is a little more complex than just using a specific port or protocol to get through a NAT. You can get more information here.
某些路由器可以处理 UPnP 请求以打开端口。
Some routers can handle UPnP requests to open ports.
大多数多人游戏都使用 UDP，并且端口各不相同，有些需要比其他端口更多的端口。 服务器端往往需要转发开放端口。
为了做到这一点，您显然需要深入研究套接字编程。
玩得开心 ：）
Most multiplayer games use UDP and the ports vary, some need more than others. The server side tends to require the open ports being forwarded.
You'll obviously be delving deeply into sockets programming in order to do this.
Have fun :)
UDP 的另一个优点和防火墙技巧是，对于大多数防火墙来说，如果内部客户端发送 UDP 数据包，防火墙会在外部打开一个 UDP 端口，该端口可以接受外部数据包并将其转发回源。
因此，如果所有客户端都将 UDP 发送到中央服务器，则该服务器可以收集所有 UDP 端口信息并将其发送回每个客户端（再次通过 UDP）。 然后每个客户端向其他客户端发送 UDP 数据包以打开防火墙端口。 这使得每个客户端可以直接与其他客户端通信，而不是通过服务器。 它仍然需要一个服务器，每个客户端都可以将其用作会面点。
Skype 和其他 IM 协议以及一些需要 P2P 访问才能良好运行的 BitTorrent 客户端都使用此技巧。
它的一个问题是所有流量都是 UDP，这使得连接不可靠，因此如果需要可靠性，您需要在其上实现自己的 TCP 版本。 我相信有一些图书馆可以做到这一点。 或者你可以运行 OpenVPN 之类的东西，尽管这对于游戏来说似乎有点大材小用。
Another UDP advantage and firewall trick is that for most firewalls, if an internal client sends a UDP packet, the firewall opens a UDP port on the outside that can accept and forward outside packets back to the source.
So if all of your clients send UDP to a central server, that server can collect all the UDP port information and send it back to each client (again through UDP). Then each client sends a UDP packet to each other client to open the firewall ports. This lets each client talk to each other client directly instead of through a server. It does still need a server out there that each client can use as a meeting point.
This trick is used by Skype and other IM protocols and some BitTorrent clients that need P2P access to perform well.
One problem with it is that all the traffic is UDP which makes the connections unreliable, so you need to implement your own version of TCP over it if you need reliability. I believe that there are some libraries to do that. Or you can run something like OpenVPN although that seems like overkill for a game.