招银网络科技电话面试

最新推荐文章于 2022-08-27 05:26:10 发布

jing_nnn

最新推荐文章于 2022-08-27 05:26:10 发布

阅读量7.3k

点赞数

分类专栏：面试准备

本文链接：https://blog.youkuaiyun.com/jing_nnn/article/details/107015753

版权

面试准备专栏收录该内容

32 篇文章

订阅专栏

本文主要讨论了在招银网络科技电话面试中的技术问题，涉及TCP长连接的选择、MRUDP的策略及其数据流程。内容涵盖TCP长连接的优缺点，心跳保活机制，以及MRUDP的数据发送、接收、重传和循环校验过程。同时，还提及了C++的继承、聚合和多态实现内存的相关知识点。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 关于项目的负责内容

还是非常有必要熟悉应急–天基的基础传输模块的，基本面试中都会觉得只界面模块很单薄
应急—基础传输模块、无人机网络协议、速率控制模块、界面模块
天基—基础传输模块、 MRUDP、界面模块

2. TCP长连接

问：如何在TCP长连接和UDP改进之间进行取舍？
首先暴露出来，我对socket连接的常见面试问题非常不了解，腾讯也曾问过长连接的问题，首先解决长连接与MRUDP 的理解问题，然后对socket常见的面试问题做了解记录。

TCP长连接与短链接，项目中是使用的什么？
TCP长连接博客
所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持（不发生RST包和四次挥手）。
连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接（一个TCP连接通道多个读写通信）；
这就要求长连接在没有数据通信时，定时发送数据包(心跳)，以维持连接状态；
短连接：
短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接（管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段）；
连接→数据传输→关闭连接；
区别于适用场景
长连接
1.多用于操作频繁，点对点的通讯，而且连接数不能太多的场景
2.每个TCP连接都需要三次握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，再次处理时直接发送数据包就OK了，不用建立TCP连接。
例如：微信开放平台网站应用的扫码登陆，聊天室等。
短连接
1.用户无需频繁操作，不需要一直获取服务端反馈情况下需用短连接就好。
WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源
长连接保活
判断长连接双端是否都还在线。
操作系统实现：
TCP的KeepAlive机制（此机制并不是TCP协议规范中的内容，由操作系统去实现）KeepAlive机制开启后，在一定时间内（一般时间为7200s，参数tcp_keepalive_time）在链路上没有数据传送的情况下，TCP层将发送相应的KeepAlive探针以确定连接可用性，探测失败后重试10（参数tcp_keepalive_probes）次，每次间隔时间75s（参数tcp_keepalive_intvl），所有探测失败后，才认为当前连接已经不可用。这些参数是机器级别，可以调整。KeepAlive的保活机制只在链路空闲的情况下才会起到作用。
一个可靠的系统，长连接的保活肯定是要依赖应用层的心跳来保证的。
应用层实现：
如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。
如果一个给定的连接在两小时内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态：
客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位。
客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。
客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。
心跳包使用
方案一
最简单的策略当然是客户端定时n秒发送心跳包，服务端收到心跳包后，回复客户端的心跳，如果客户端连续m秒没有收到心跳包，则主动断开连接，然后重连，将正常的业务请求暂时不发送的该台服务器上。
方案二
这样传送一些无效的数据包有点多，可以做些优化。因为心跳就是一种探测请求，业务上的正常请求除了做业务处理外，还可以用作探测的功能，比如此时有请求需要发送到服务端，这个请求就可以当作是一次心跳，服务端收到请求，处理后回复，只要服务端有回复，就表明链路还是通的，如果客户端请求比较空闲的时候，服务端一直没有数据回复，就使用心跳进行探测，这样就有效利用了正常的请求来作为心跳的功能，减少无效的数据传输。
MRUDP的策略，优势

3. MRUDP的策略

全称（Muti-RUDP)多个R包括：real-time、reliable
实时UDP信息可靠传输模块（MRUDP 模块）需要达到如下目标：

建立端到端实时有序可靠传输的逻辑实体。
在现有底层基础设施下，达到 300Mbps 的端到端实时有序可靠传输速率

要达到实时可靠可靠有序传输，MRUDP的核心组件为固定窗口组件，上层模块接口和下层模块接口分别与MRUDP模块的上下层模块进行数据交互。固定窗口组件类似于TCP的滑动窗口的作用，但是与真正的 TCP 滑动窗口不同，这一组件模仿的是固定缓冲区元素个数的循环“滑动窗口”，而且实际数据并未存储在固定窗口组件中，而是借由数据缓存组件存储在文件、数据库或者内存中。数据缓存组件针对数据存取提供了一个一致性接口。
实时 UDP 信息可靠传输模块（MRUDP）主要包括两个组件：窗口组件和数据缓存组件。其中窗口组件的职能如下：

管理端到端数据发送、接收循环队列。
处理接收到的数据和 FACK。
利用数据缓存组件缓存数据内容。
数据缓存组件的职能是提供随机数据存取服务。
MRUDP在控制实时可靠有序主要有以下几个过程：数据发送、数据接收、数据重传

3.1 数据发送流程

MRUDP 与其上层模块之间的数据交互类似“透传”。上层模块将待传输数据字节序列交付给 MRUDP 模块中的上层模块接口，上层模块接口并不解析这些数据字节序列，而是直接将其编码为 MRUDP 模块的内部消息实例，并将此内部消息实例交付给固定窗口组件。固定窗口组件通过检查并更新数据发送窗口的状态来对此内部消息实例进行加工，之后调用数据缓存组件将此消息实例的再编码字节序列缓存，并将再编码字节序列交付给下层模块接口以待完成数据发送流程。具体的数据发送流程如图 1.2 所示。
在这里插入图片描述

3.2 数据接收流程

反之，MRUDP 模块的下层模块接口从下层模块接收到数据后将其解码为
MRUDP 的内部消息实例，继而将此内部消息实例交付给固定窗口组件。由固定
窗口组件判定该实例是否有效，并更新数据接收窗口。具体的数据接收流程如
图 1.4 所示
在这里插入图片描述

3.3 数据重传FACK响应流程

下层模块借助 MRUDP 的下层模块接口向 MRUDP 模块传递与 FACK 对应的数据字节序列，下层模块接口将其解码为 FACK 实例并将 FACK 实例交付给固定窗口组件。固定窗口组件在接收到 FACK 实例后根据数据发送窗口状态检查FACK 是否有效，并进一步更新数据缓存组件，随后根据 FACK 内容重传相应数据包。这些需要重传的数据包就是数据缓存组件所缓存的一个个字节序列。具体的 FACK 响应流程如图 1.3 所示。
在这里插入图片描述

3.4 数据循环校验流程

与上面工作流交错的还有数据循环检验流程（数据流如图 1.5 所示），这一流程保证了实时 UDP 信息的有序可靠传输。这一流程可被视为一个定时线程，周期性地检查固定窗口组件中已被标记为成功接收的内部消息实例，并将其按序交付给上层接口模块，并进一步按序交付给上层模块。同时此流程还会更新固定窗口组件的数据接收窗口，生成 FACK 并将FACK 交付给下层模块接口，下层模块接口将 FACK 编码后交付给下层模块并最终发送到对端。
在这里插入图片描述