网络游戏的数据传输处理和防火墙穿透

51testing

一般来说，client和server之间的数据交换，分为几个优先级，大部分情况下是下面3种：
1. 不可以丢失，但是不要求速度。
2. 不可以丢失，但是要求速度,确并不是非常严格。
3. 可以丢失，但是要求速度    对于1来说，最直接的例子就是聊天信息，动态的地图信息。这些数据不是time-critical的，所以应该使用TCP连接。 在大多数情况下，有专门的  voice/chat server和map server,client到每个server有个TCP连接。一个client有多少个连接根据需要决定。同时有2-3个连接并没有多大开销。当然，如果开销很大，就是程序设计的问题了。其实你想想开BT的时候同时有4,50个连接，你用其他程序的速度并没有慢多少。
    对于2来说，比较显著的例子是战斗信息，动作序列。 比如一个人玩游戏，用鼠标点了下地图上的一个坐标，那么些人物向这个坐标前进。这个信息从server转发到其他的client,当然越快越好，如果client没收到，就要重发，否则client就看不到这个动作。如果你玩过wow的盗贼，就会发现在网络卡的时候，经常先偷袭，按下键盘以后要等一会才看到攻击动作，就是这个原理。当然这里数据需要经过server的处理，每次打包多个client的动作，和顺序，然后发送。需要复杂的server端逻辑处理。这种应该使用UDP，同时对所有的UDP包编号（用来防止2次处理），使用slide window类似的协议进行重传。
    对于3来说，就是位置信息。 位置信息可以丢失，但是由于这种信息更新的最频繁，所以即使丢失其中一个，也可以根据 dead reckoning 算法进行位置预测和修正。 dead reckoning算法有很多变种，适合多类情况。 比如你见过wow里，如果一个人掉线，但是一直往前不停的跑，那多半就是算法进行的预测。偶尔你会发现网络卡的时候，刚刚走到一个地方就退回到原来的位置，就是因为你的动作数据包(2里的)没发送出去，导致update world position的时候，算法进行位置修正的结果。这类数据应该使用UDP.
    需要说明的是 UDP和TCP无明显分界。 TCP相比UDP，只有3个缺点，1是slow start, 2是 throughput jitter, 3是insistence on reliability(相对的，不时绝对缺点). 在数据传诵量比较小,网络状况比较稳定的情况下，使用TCP和UDP无大分别。

    对于防火墙穿透，如果你是做client的，不需要关心这个问题，因为你往Server发数据，建立连接，都不会受到放火墙的影响。不过server端对于放火墙可以有几种实现方式：
1. 最差的方式是client发送SYN包给服务器，在防火墙或网关上建立NAT地址，然后 Server之需要取得这个NAT地址，把所有的数据包都封装成SYN-ACK包，发给client就行拉。这样做比较省事。但是无法穿透 stateful firewall
2. 是比较好的方式。 不过需要先建立TCP连接，然后对server发送正常的UDP包。大部分的NAT网关会为UDP专门建立个NAT地址，那么通过这个地址，server就可以发UDP包了。但是并不是所有的firewall都会为UDP建立单独的NAT地址。
3.  是最好的方式，由于防火墙不会阻止内部网发起的TCP连接，所以TCP进行数据传输没有任何问题。对于Server/Client来说，只要使用 Raw Socket模拟TCP协议，但是这个模拟的TCP协议使用UDP的本质，没有slide window, 没有 congestion control, 没有flow control等等，这种实现最麻烦，但是几乎能处理所有的防火墙。
4. 其实没有4，不过实在想提下这种最强技术. 就是所有的Server到Client的数据包都可以是ICMP echo reply message. 由于种种原因，firewall不太可能禁止ICMP echo,所以这类消息也是很容易传送到client,但是。。。。。。。。Client如果有 IDS system,很容易把你的sever归类到入侵扫描的范围。所以不用最好。
    如果你们不是采用第3种方式，并且你只写client,那么防火墙跟你就没有什么关系。都是server的事。