面试：杂记（二）

    前段时间面试了某大厂游戏部门，这里记录下其中的两个问题。

1. 在中国，MTU设置为多少合适？

    遇到这个问题的时候是懵逼的，就知道MTU最大为1500。后面和同事探讨了下，才知道国际通用576，因为目前最老的路由器超过576就会分包，而我们公司UDP包内容限定为480应该就是这个考量。对于TCP分包并没有影响，因为TCP协议会自己整合在一起，但是如果UDP报文如果分包了，就应用层自己做分包的处理了。

2. 我当前游戏项目为什么game server要分开用TCP传指令，UDP传帧数据。

     以前上网搜到的就是UDP比较快，但不知道为什么慢。自己想了下就说TCP由于是有滑动窗口和拥塞控制等的会慢，并且TCP是可靠连接的。面试官问我为什么UDP快，自己有没有测试过？然后我又懵逼了，说白了还是自己遇到的问题比较少，也没怎么主动去思考。

     后面和同事探讨了下，才了解到网络好的情况下，UDP和TCP的速度其实是差不多的，但在网络差的情况下UDP的表现更好，实时性也更好。因为这个时候TCP会出现重传以及流量控制等操作，导致发包变慢以及发包变小，导致这种情况下TCP实时性比UDP要差很多。所以对于帧数据这种实时性要求比较高的，肯定是不能用TCP来传输了。而对于指令这种不管多久都要保证通知发送端对端接收到的（双向），避免重复发送的内容，用TCP显然更好。

     由于客户端实际是根据服务器收集的所有帧数据来重新演算这一帧的操作的，所以即使网络问题导致客户端发送的UDP数据没有被服务器收到，所有客户端的表现结果都还是一样的。对于帧数据，对实时性要求更高。

     对于指令数据，对于可靠性要求更高。

 

2019.10.12补充：

3. 实现一个ID号获取的进程，适用于高并发的情况，ID号为一个整数，全局唯一。

     我自己的思路使用多线程实现，每个线程自己拥有一个范围的数据段。每次通过这个线程提供ID号时则从这个范围段内拿一个，实际上这个线程只需要记录这个范围段的起始与结束范围然后逐渐递增ID号就可以了。负载均衡在进程选择线程处理获取请求的时候做。

    面试官让我分析这个方法每秒能产生多少个ID号，不过自己没有这方面的经验，所以直接回答不知道怎么计算了。

    面试官接着问我如果一台机器不足以支撑，该怎么实现。这里就是用多台服务器，每个服务器都跑上面的进程，但是这里我加了一个范围段获取的中心，每个线程在范围段用完后可以直接向这个中心请求新的范围段。如果线程检测到自己出问题了，也可以将未用完的数据段回收给中心，中心与线程之间存在一定的交互。负载均衡在域名解析选择指定进程处理获取请求的时候做。

    感觉这个方案还算是可以的，中心的也不存在太大的压力，当然需要记录ID的使用情况（如哪些已经被使用），通过这种方式，服务器上也基本只需要记录一个范围就可以了，由于对中心的请求不会太频繁，对数据库的读写也不会很频繁。不过后面想到每个进程可以用一个队列来存储请求，当然这个要根据实际情况处理。

    打算自己实现下这个方案。如果这个方案存在问题，也希望大家可以提出来。毕竟我还是相当缺乏高并发的知识与经验。