妈耶哭瞎
仔细复习了几天的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.youkuaiyun.com/Xingaaaxing/article/details/50829794