妈耶我需要好好补一下计算机网络的知识了QAQ

妈耶哭瞎
仔细复习了几天的C++还有游戏架构、游戏引擎等知识
今天突然接到了某面试，前面都答出来了
结果问了好多计算机网络的题目，暴风哭泣QAQ
我上班不怎么遇到都快忘光了

不要放弃，再来恶补一下网络方面的知识！！！！！

我先把问题写了，等研究透了再把答案写上去，不能坑别个啊QAQ

1.TCP和UDP的区别？

(1)TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
(2)TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
(3)UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
(4)每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
(5)TCP对系统资源要求较多，UDP对系统资源要求较少。

2.如何保证UDP的可靠，可靠的UDP（RUDP）？

这个靠我自己研发一个可靠的UDP有点难为我了，先记一下RUDP相关的方法和技术吧：

2.1重传

重传有多种方法，这里介绍三种：定时重传，请求重传和FEC选择重传
（1）定时重传
这个最简单，就是发送方发送一个数据包之后一段时间内（RTO）不收到该数据包的ACK消息，那么就重传这个数据包。
该方法存在的问题：
①对方收到了数据包，但是ACK发送途中丢失了 ②ACK在途中，但是发送端的时间已经超过了一个RTO
适合的场景：
如果你的场景是一个对延迟敏感但对流量成本要求不高的场景，就可以将RTO的计算设计比较小，这样能尽最大可能保证你的延时足够小。例如：实时操作类网游、教育领域的书写同步，是典型的用expense换latency和Quality的场景，适合用于小带宽低延迟传输。对于对带宽消耗很大的网络，则推荐使用请求重传。

（2）请求重传
请求重传就是接收端在发送ACK的时候携带自己丢失报文的信息反馈，发送端接收到ACK信息时根据丢包反馈进行报文重传。比如接收到了1号和4号包，然后判断出应该接收不到2、3号了，那么返回的ACK就要告诉发送端2、3没接到。
如何判断？
接收端在通信的过程中要评估网络的jitter time，也就是rtt_var（RTT方差值），当发现丢包的时候记录一个时刻t1,当t1 + rtt_var < curr_t(当前时刻)，我们就认为它丢失了，这个时候后续的ACK就需要携带这个丢包信息并更新丢包时刻t2,后续持续扫描丢包队列，如果他t2 + RTO

适合的场景：

这种方式是由丢包请求引起的重发，如果网络很不好，接收端会不断发起重传请求，造成发送端不停的重传，引起网络风暴，通信质量会下降，所以我们在发送端设计一个拥塞控制模块来限流，这个后面我们重点分析。除了网络风暴以外，整个请求重传机制也依赖于jitter time和RTO这个两个时间参数，评估和调整这两个参数和对应的传输场景也息息相关。请求重传这种方式比定时重传方式的延迟会大，一般适合于带宽较大的传输场景，例如：视频、文件传输、数据同步等。

（3）FEC选择重传

FEC（Forward Error Correction）是一种前向纠错技术的意思，一般是通过XOR类似的算法来实现，也有多层的EC算法和raptor涌泉码技术，其实是一个解方程的过程。一般情景是这样的：发送方先发送了包1和包2，然后发送了一个FEC包。此时接收方发现包2没得了，就使用包1和FEC包计算出了包2，这样就不用请求重传。要是FEC包也救不了，那就只好再请求重传了。

3.在某个支付流程中，用户有可能因为网络不好连点两次，如何分辨确实是网络不好，还是故意连点两次？

这个我还没想好客户端主要可以做什么，如果是我，就禁止两次间距过短的支付操作好了。。。。但是这么回答肯定得不到面试官的青睐的。

先看看这篇文章好了，服务器为主的：
弱网络下的游戏服务器设计：
https://blog.csdn.net/Xingaaaxing/article/details/50829794

4.窗口与拥塞控制？