课程报告：4G网络不同场景的性能测试及协议分析

4G网络不同场景的性能测试及协议分析 陆豪锋 156001026摘 要:*本文通过使用linux下的拥塞控制系统以及iperf测量工具在不同场景下对4G信号传输性能进行测试分析。并且由此通过分析相关支持4G信号传输的协议。其中进行测量比较的包括Reno，CUBIC和Verus。本文中，我们采用了不同的测量地点，对空旷下和拥挤两种环境下的传输性能进行测试对比，来得出能够支持我们的数据。研究表明，在拥挤处的传输速率大大降低，相对于三种算法来说，当网络条件极其恶劣的时候，Verus协议的性能反而可能大大降低。 *关键词:*4G 传输协议 拥塞控制*Authors InformationAbstract: This paper tests and analyzes the 4G signal transmission performance in different scenarios by using the linux under the congestion control system and iperf measurement tools. And thus by analyzing related protocols supporting 4G signal transmission. Among the measurement comparisons included Reno, CUBIC and Verus. In this article, we used different measurement locations to compare the transmission performance under both airborne and congested environments to obtain data that can support us. Studies have shown that the transmission rate in the crowded place is greatly reduced. Compared to the three algorithms, when the network conditions are extremely harsh, the Verus protocol performance may be greatly reduced.Key words: 4G Transfer Protocol Congestion control1 引言4G网络已经融入了我们的生活中，蜂窝网络无处不在。移动网络通信都是高度可变的，以及用户对网络速度需求的可变性加之无线网络资源的稀缺使得通道难以预测。TCP协议以及它的附属协议在解决移动网络的拥塞问题上已经不能满足要求了。所以我决定通过简单的对蜂窝网络的测试，来分析一些协议之间的差别与优劣。蜂窝网络信道变化很大，由于无线资源稀少，用户在短时间内经常会出现无线链路速率波动，使得这些信道很难预测。众所周知，TCP及其变体在蜂窝网络中性能差，这是由于高容量的可变性，自身造成的排队延迟，与拥塞无关的随机分组丢失以及带宽延迟。三个具体特征直接影响到蜂窝频道的不可预测性。首先，移动设备和基站之间的蜂窝信道的状态经历了几个复杂的状态转换，在短时间尺度上影响信道可用性15。这引入了底层渠道的变化。其次，蜂窝网络中使用的帧调度算法在蜂窝信道中引起突发。基于真实的细胞测量，我们观察到接收机的典型业务特性是突发性的（即使对于平滑的发送模式），具有可变的突发大小和突发的到达间期。第三，虽然之前工作只考虑了自己造成的排队延迟，这是造成高延迟的原因33，我们发现竞争的流量确实会影响端到端的延迟特性，特别是在高争用或蜂窝频道接近饱和时。最后，设备的移动性有一个对信道特性的实质性影响进一步加剧了这些挑战。缺乏渠道可预测性对设计有重要的影响新的拥塞控制协议。本文中，我对一些简单的协议进行了相关测试与分析。2 相关工作这项测试，我预备了两套方案。方案1：用Android Studio修改运行程序（/jiangxianliang/HSRNetTest），用此软件进行数据监测和分析。方案2：若上述程序使用失败，则采用备用方案，使用iperf软件，通过4G热点来进行数据测试，此测试方法较上述方法1，可能存在一定误差。此外，对于此次试验，我还准备了一些理论支持，具体如下。遗留拥塞控制协议拥塞控制是一个广泛研究的主题，有许多TCP变体。 TCP Reno ，TCP Tahoe 和TCP NewReno 是早期流行的基于丢失的变体，TCP Vegas 是最早的基于延迟的控制协议之一。大多数当前的操作系统利用TCP Cubic 或者Compound TCP 。虽然TCP Cubic在传统的基于AIMD的窗口控制中对递增函数进行了特定的修改，但是复合TCP维护两个拥塞窗口以适应其发送窗口。还有其他一些TCP口味，比如LEDBAT ，TCP Nice ，基于方程的速率控制和二项式拥塞控制。这些传统的拥塞控制协议都不能直接适用于基础信道在短时间内发生变化的蜂窝网络条件，以及链路具有固定容量的基本假设不成立。另外，这些TCP变种没有一个可以区分作为蜂窝环境的一部分的随机损失与拥塞造成的损失。我们旨在将来自传统的基于丢失控制的思想与基于延迟的控制相结合，从TCP Vegas这样的协议中吸取灵感。Reno算法：Reno是目前应用最广泛且较为成熟的算法。该算法所包含的慢启动、拥塞避免和快速重传、快速恢复机制，是现有的众多算法的基础。目前使用最广泛的TCP Reno拥塞控制主要分为4个阶段：1）慢启动阶段： cwnd呈现指数增长趋势2）拥塞避免阶段：cwmdssthresh 呈现线性增长趋势3）快重传阶段：发送方只要一连接收到三个重复确认就应该立即重传对方尚未的报文段，而不必等到重传计时器超时后发送。由3个重复应答判断有包丢失，重新发送丢包的信息。4）快速恢复阶段：主要决定于收到的重复应答数据的初始门限值（一般为3）与慢启动不同，Reno的发送方用额外到达的应答为后续包定时。发送方窗口的上限值=min（接收方窗口，拥塞窗口）CUBIC算法：传统TCP协议，例如TCP-Reno等，每过一个RTT，窗口增加一个单位，这使得TCP的数据传输速度缓慢，远不能充分利用网络带宽。而之前提出的BIC-TCP拥塞控制策略基于二分搜索的思想，通过调整拥塞窗口的大小有效地解决了网络拥塞。但是在窗口调整算法上复杂性较高，并且在小链路贷款时延情况下抢占性较高，为了解决这些问题同时保证协议的稳定性和公平性，CUBIC算法诞生了。CUBIC算法由BIC算法改进而来，它改进了BIC-TCP的窗口调整算范，以一个三次函数代替了BIC-TCP中的凹函数和凸函数。CUBIC的窗口增长只依赖于连续两次拥塞时间之间的时间，这使得窗口增长独立于RTT，从而使得CUBIC能够在多条共享瓶颈链路的TCP连接之间保持良好的RTT公平性。Verus协议：Verus借用传统TCP变体的许多特性，例如慢速启动和乘法减少，但改变了它维护发送窗口的方式。传统TCP使用加性增加并将拥塞窗口（CWMD）的大小增加1 / CWND，即，当拥塞窗口成功收到一个完整的窗口。这个过程可能会很慢。相反，Verus每增加/减少发送窗口在每个“ms”时间，并且在信道条件允许更多分组时，通过快速增加发送窗口来适应改变的蜂窝信道。类似地，Verus寻求在丢包之前减少发送窗口而TCP只能在丢失后通过积极的乘法减少来减少拥塞窗口。Verus的主要目标是通过在等于估计的网络往返时间（RTT）的时间段上维持适当的（滑动）发送窗W来避免拥塞。 Verus通过用一系列小的“步骤”来替代增加的增加来快速适应信道波动，Verus在发送窗口中估计需要发送多少分组以避免在较小的“ms历元”上发生拥塞或分组丢失。3 研究动机4G网络作为现在信息发展的主流体系，一直以来受到广泛的关注，借着这个课题的机会，我想来探究一下4G网络中的奥秘。4G网有着很大的流动性，在不同的地点测量4G网络的传输性能，其结果是大不相同的。在空旷的地方，4G网络的传输性能相对较好，也不会发生拥塞的问题。而到了拥挤的市场，人流量相对较大，干扰因素变多，竞争也相继产生，再加上4G网络本身的特点所带来的问题，在拥挤的地方，4G的传输性能会出现巨大的变化。而到了高速运行的高铁上，情况又不一样了，在我的预想中，高铁上的网速应该较空旷处的慢，因为它要不断地进行基站的连接与断开，因此影响了传输性能。而这些猜想也会在接下来的实验中进行试探。通过对不同场景下4G信号的不同的传输性能的分析，我们可以通过linux系统或者是其他的手机软件，来进行具体数据的测试，来分析每一种传输协议对4G传输性能的影响。在这里我选取的是Reno，CUBIC以及Verus。具体的传输性能的测试，我们可以通过流量分析软件来进行。此处首先选用的是Android Studio编译的程序。因为它的程序可以生成KPI并且在安卓机上运行，便于直接测量4G信号的传输过程。然而由于对Android Studio的掌握并非太过熟练，我还选择了备用方案，用linux系统来进行拥塞控制的测试。4 具体方案在实验的最初，我通过使用Android Studio来运行已有的流量监测软件，并对它的代码进行简单的修改，来达到我所需要的效果。以下是开源的APP的下载地址：/jiangxianliang/HSRNetTest在安装Android Studio的过程中，并没有遇到太大的问题。安装完成后，在Android Studio中打开我们下载好的源代码。在运行之前，我们需要下载好所需要的环境以及所缺少的gradle，在运行了程序以后，我发现我需要的是gradle4.1.4，此处建议自行从网上下载，而不是直接在程序中进行下载，因为直接下载会遇到VPN的问题，所以可以直接从网上搜索所需要的gradle进行下载，然后放到指定的目录下。如图1.1所示图1.1 Android Studio 工作列表接着运行程序，选择安装所需要的虚拟机 如图1.2和图1.3所示图1.2 选择虚拟机的版本图1.3 进行相关资源的下载安装于是便得到了如下的虚拟机的界面 如图1.4所示图1.4 虚拟机模拟器然而在运行过程中一直出现下列问题，如图1.5所示图 1.5 APP崩溃而我本身的Android Studio水平有限，于是我放弃了使用Android Studio。于是我采用了我的备用方案，使用了linux虚拟机以及编译好的拥塞控制内核再加上iperf测试工具。首先在linux中使用编译好的拥塞控制算法的内核，然后在linux中安装使用iperf。需要注意的是，这里需要两台PC机，分别作为服务器和接收端。此处，为了测4G的传输速率。于是我采用了手机热点，来给两台PC机提供流量，并进行相关协议的测试。首先，这样测量肯定存在一定的误差，但是也能相应的反应出大致的一个走向。我刚开始在寝室里进行测量，对不同的传输协议分别统计测试数据。寝室里的网络情况较好，所测得的数据也较高。其次，我找到了一个人流量较大的教学楼，选择了其中的一间教室进行测量，同样的，带着两台PC机以及一个提供网络的手机，然后对不同的协议进行测量记录，然后再把两个地方的数据进行综合对比。5 实验结果在寝室中，我测得3组数据，但是在数据上数值偏大，目前未寻找出错误原因： 图1 空旷处的Reno 图2 空旷处的CUBIC 图3 空旷处的Verus以及在网络状况较差的环境中测出来的数据： 图4 拥挤场所下的reno 图5 拥挤场所下的CUBIC 图6 拥挤下的Verus通过上述数据，我们可以看出，首先在拥挤的情况下，传输状况明显差于网络状况好的场所。其次，在网络较差的环境中，Verus协议下的传输速率明显慢于其他两个协议，此处我猜测与协议本身有关，正因为Verus协议的原理，在极差的网络环境下，反而成了它的弊端。但是Reno和CUBIC协议在此次实验中并没有看出明显的不同。6 结论展望此处可以看出，还是有一些不足，Reno和CUBIC协议并不能看出明显差距。也许是测试方法并不够严谨。在闲暇后，我会钻研一下Andr