英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料
一个未来家庭无线网络的openwrt解决方案
Claudio E.Palazzi, Matteo Brunati, Marco Roccetti.
摘要
未来大多数家庭和办公用户的数字设备都会利用互联网和无线方式的结来配置和传输，然而，配置常规接入点和协议将影响异构应用程序流的有效共存。事实上，拥有不同性能要求的实时应用和弹性应用正在（或将会）被不同的协议和特性所支持。对于前者要求每一个数据包的低延时，对于后者要求高吞吐率。在这个工作中，我们提出正在进行中的对于一个新的AP原型的评估。这种新接入点原型能够保证实时数据流的快速和流畅传送，同时保持基于TCP协议的应用的高吞吐率。我们的方法是在openwrt操作系统上对接入点代码一个用户空间的修改，以此达到适当的改变网络流量的通过。初步的实验结果证实，我们的解决方案将成为未来无线室内场景为中心的最理想的候选者。
关键词：openwrt 智能接入点 测试平台 无线协议
1、简介
很容易预见在不久的将来，家庭和SOHO将会拓展无线连接的使用去支持更加广泛大量的设备。例如：个人电脑、控制器、电视机和其他设备，文件下载和共享，浏览网络、视频、音频流，网络电话和在线游戏。这只是一小部分，即使是基于连接的多媒体应用的代表性样品也将被用户同时的运行。
不幸的是，当前的TCP/IP网络协议已经发展了数十年，并且在嵌入到无线异构场景时显现出了一些问题。首先，我们要牢记的是实时服务通常基于UDP传输协议，然而弹性应用利用TCP协议（TCP执行流量控制功能）。不幸的是，异构应用不会以一个友好的方式共存，TCP和UDP也是如此。事实上，TCP的拥塞控制机制被设计成为了得到更多的带宽不断的探测信道知道饱和通道和缓冲区的瓶颈为止。在拥塞控制阶段以相同探测模式从新开始之前，一些数据包丢失并且传输速度会减半，由于这个特性会产生等待队列（在瓶颈缓冲区）会对实时应用产生不利影响，从而增加了每个数据包的传送滞后时间，而这对于实时交互应用是一个主要的性能指标。
尽管是可预测的，但是由于广泛的认为TCP比UDP更友好，这个结果仍然相当令人惊讶，由于仅仅是TCP有拥塞控制功能，事实上，一本网络课程广泛采纳的教科书之一上说：“尽管现在通过UDP运行多媒体应用是普遍的策略，但说这是最后的办法也是有争议的.......由于UDP缺少拥塞控制，这会导致发送端和接受端之间高的数据丢失率，并且排挤TCP会话——这是一个严重的潜在问题”
即使是在可获得带宽很少的情况下这个陈述仍然是正确的，现在（和未来）提供的越来越大的宽带连接可能会使这种情况逆转，这样一来如果一个用户和在线互动游戏保持连接同时另一个共享同一瓶颈的用户在下载一个大型文件，前者就会经常发现接收游戏更新和执行游戏中动作时缺少响应，由于用户不能在公平的方式下竞争，这个游戏就会缺少乐趣[2,10,11,12]。
相反，无线连接应该公平的支持任何种类的应用，同时提供高下载吞吐率和每个数据包的低延迟，这分别是弹性和实时应用的主要性能指标。为了这个目标，我们提出一个解决方案，他利用增强型的AP，标准的协议功能和对正在进行的流量信息的获取。详细点说，我们的解决方案是基于openwrt操作系统并且使AP运行中动态修改每个传输的TCP的ACK数据包的通知窗口。通过这种方法，TCP数据流的转发速率就被限制不会超过可获得带宽。
事实上，通过适当的限制每个流量的最大传输速率，下载型应用产生更平稳的数据流量，这可以有效的利用可获得信道而不用承担因拥塞而导致降低他们性能的损失。并且在此同时在AP中不会产生可能增加实时应用每个数据包延迟的排队队列。
为了证明我们的论述，我们已经对我们的解决方案实现了一个原型，并进行了初步的评估，展现在这张纸上的从文档和报告中收集的结果是非常令人鼓舞的，并且需要更进一步的调查。
其余部分按照如下的方式展开：在第二部分，我们讨论我们所建议的解决方案。测试平台的评估呈现在第三部分。实验结果展示在第四部分。最后，第五部分总结这个报告同时预测这一工作未来的方向。
2、建议的解决方案
我们致力于寻找最好的解决方案去平衡存在于TCP吞吐率和实时应用的延迟之间的关系，我们利用规定的存在于所有TCP确认数据包中的通知窗口部分去限制TCP流所利用的带宽。事实上，真正的TCP流的发送率取决于它当前的拥塞窗口和由接收器所决定的通知窗口。发送窗口由这两个中最小的一个决定。由此，显而易见通知窗口是如何TCP发送率的自然上界。我们的贡献是在AP中加入智能模块，以此来使得它能够适当的修改通过的所传输的TCP确认包的通知窗口文件，所有产生自置于屋内和发向置于屋内的无线节点的流量都必须通过该AP。这使得他成为最适合执行我们的解决方案的地方，由于它的属性，这个解决方案被称为“低通知窗口的智能接入点（SAP-LAW）”。
关于利用常规TCP，限制发送窗口能够确保有同样甚至有更高的吞吐率，事实上，在稳定状态适当的限制通知窗口能够产生更稳定的传输速率。这与TCP vega 的发送窗口的特性更相似，而不是传统TCP版本的锯齿形的发送窗口。同时排队延迟将被避免，因此对时间敏感数据流将带来有有利影响，例如那些实时应用产生的数据流。
SAP-LAW一个重要的组成无疑是由计算每个基于TCP的数据流的通知窗口即最大传输速率的方案所实现的。毫无疑问，由于一个确定点可能有不同个数的基于UDP的数据流和不同数量的基于TCP的连接，一个静态数值就不能表达不同的网络配置。因此，每个传输的ACK的通知窗口的值就要考虑好几个因素来进行动态计算。
- MaxTCPrate=(C-UDPTraffic(t)) / numberTCPflows(t)
- MaxTCPratei(t)=(C-UDPtraffic(t))*RTTi / （sum;RTTi/avg_RTT）
通常连接的瓶颈是在最后一英里的连接，这是已经在科学文献中被证实了的，这条连接的带宽能够简单的理解为与用户所支付的连接相一致；或者说，像capProbe类似的软件可能会被安装。利用这个信息，公式（1）和公式（2）是对处于一个确定时间t内用于计算各种不同的基于TCP的数据流的合适窗口的可行公式。在（1）和（2）中，C是瓶颈能力，第一个公式并没有考虑TCP流的RTT不公平问题，并且简单的把最大TCP速率定为时间t来作为UDP流剩余空闲瓶颈能力和同时存在的TCP流数量之间的比例。因此，所有TCP流将会受同样被限制的通知窗口所影响。
相反，公式（2）计算不同的地最大TCP速率值：一个值对应于一个TCP流i ，由他的实际RTT(RTTi)所决定。本质上，被计算的通知窗口与各自的RTTs成反比以建立一个公平共享可用的带宽（即相同的最终吞吐率）。这可以通过监视每个不同的共存的TCP流的RTTs和计算他们的平均值为代价来实现。
SAP-LAW解决办法同样与其他文献中可获得的建议相一致，例如第十八个参考文献，然而尽管第十八个参考文献要求同时修改AP和接收端，我们的体系却只是利用了一个增强型的AP。
在接下来的子部分我们更多的与我们的解决方案相关的实施问题方面的细节，这些细节同时包含硬件和软件的角度。
2.1 实施细节
对于硬件部分，我们需要一个可以被没有过多负担的修改并且代表一种现成的产品的接入点，因此我们选则的是NETGEAR 的WGT634U。此外我们做了一些基本的测试和可能的备选方案，比如说Fonera （Fonera 2201版）。
我们的目标是一种可在运行着大量AP和嵌入式硬件的家庭和小型办公室实施的解决方案。因此，为了可以使大量的AP使用我们的解决方案，我们需要一个适用于嵌入式体系结构的基于Linux的操作系统，这个选则使我们可以在我们PC的Linux环境下工作，并且当软件完成之后在移植到真实的AP上。对应于我们目标最好的选择就是openwrt：一个基于Linux内核的针对嵌入式解决方案的操作系统，该操作系统主要面向网络支持。
针对软件部分，应该说解决方案越接近硬件，执行的就越快。另一方面，实施高度硬件依赖的解决方案不容易对具有不同网络接口的嵌入式平台进行移植，因此我们评估了不同可行的解决方案。例如修改网络驱动，修改已经存在内核模块和加入新的内核模块。为了获得最大的可移植性，之后我们决定使用一个用户空间解决方案，同时一个基于内核的解决方案保留为以后的工作。然而，我们不得不说对于一个现实的家庭无线网络场景，正如我们在实验中考虑的那个，我们的用户空间解决方案从执行速度方面来考虑没有任何的问题。
更多的细节是：被采纳的解决方案是基于Netfilter架构，这是Linux内核网络框架。Netfilter允许将自己注册到内核来写模块，然后通过描述怎样处理网络流数据包的特定表，启用内核来利用这些模块。甚至，Netfilter提供了API接口给开发者来从用户空间连接内核；另一方面，在未来没有什么会妨碍将编译好的用户空间模块移植到内核。
至于现在，我们的解决方案已经被设计成对于用户空间的SAP-LAW版本，我们把它称作SAP-LAW-US或者简称为SLUS，我们的原型显然是一个概念验证，我们用它来创建一个能够证明其基本功能和可以实现好处的测试平台。
更多的细节是：SLUS的实施有两个重要组成部分组成：第一部分是iptables规则的定义，用来将特定的TCP的ACK数据包转发到特定的用户空间队列，实施的第二部分是由一个C语言写的应用程序组成，他通过libnetfilter队列从上述的队列中读出数据（netfilter的读和修改数据包的API在用户空间层），第二部分专门负责拦截和修改通过的TCP的ACK数据包的通知窗口字段，在我们现在的SLUS AP原型版本中，TCP的ACK数据包的通知窗口能以一个固定的值或者通过公式（1）来修改，我们现在也正在研究通过公式（2）来实施修改。
3、测试平台评估
为了学习在同时具有UDP和TCP流的真实网络中的SLUS，我们已经试过重建一个真实场景，该场景具有数十毫秒的RTTs。我们为证实SLUS的效率配置的测试平台在图片1中展示，值得一提的是，该平台是多么容易被扩展到所有需要互联客户端和服务端接入点的实验测试案例。
正如预期，对于无线网络我们使用NETGEAR WGT634U AP 的openwrt系统（包括我们的SLUS解决方案）。相反，为了模拟互联网的实时和弹性服务，我们使用了两台笔记本电脑，一台PC是通信的服务器，用来产生UDP和TCP数据流，另一台PC作为客户机，用来接收产生于服务器的数据，并且收集所有的流统计信息用来绘制展现在第四部分中的图形。客户端连接到AP，在这两者之间，互联网通过Dummynet模拟器来进行模拟。客户端（一个客户端运行一个应用程序）通过不加密的IEEE 802.11g协议连接到AP，瓶颈定位于Dummynet和AP之间，与4Mbit/s相一致。
我们用了各种软件去配置和分析该实验，特别的，Dummynet被用来模拟网络的互联网连接；D-ITG提供产生基于UDP和基于TCP流的网络流量的模拟；Tcpdump和Tcptrace被用来收集TCP数据信息，该信息用来制作后期加工图。
在表格1中描述的是我们通过D-ITG套件中的ITGSend程序为我们的测试生成的数据流，在每个实验中，我们都有三个基于UDP的实时流和一个基于TCP的弹性流，这四个流开始于不同的时间，TCP流是最晚开始的，经过135s的模拟。第一道流是一个简单的连续不断的比特率流，它每秒发送1KB，分成200个包。第二道流对应于CS在线游戏的网络活动部分，每40ms从服务器发送200B游戏包到客户机。第三道流参考基于RTP协议带有G.711.1编解码器的VoIP电话。逐渐的，这三个基于UDP的流消耗了大量的网络带宽，这大概在1.7Mbit/s左右摆动。使得剩余可获得带宽约为2.3Mbit/s。最后，第四道流即基于TCP的那个。对应于一个长FTP下载会话，该会话每个数据包都有1KB的负载，这个FTP流消耗的带宽越接近2.3Mbit/s，他的效率就越高。
4、实验和结论
要验证SLUS实施并证明其适用于现实世界，我们使用了先前部分所描述过的实验平台：不同的测试平台配置参数都被尝试过。为了简明起见，我们仅仅将一个有意义的案例结果呈现在这里，该案例考虑了60ms的RTT。尽管如此，其他与呈现在这里的这个相一致的配置的结果和图表能够在项目网站上找到[23]。
特别的，图片2和图片3分别显示了常规配置和应用SLUS时生成FTP的比特率。配置了SLUS，通知窗口设置为一个适当的值用来消耗所有可获得带宽而不会产生队列，这个值对应于公式（1）的结果。然而，由于在这个配置中仅仅有一个基于TCP的流，公式（1）和（2）实际上可能会产生同样的结果，正如可以从两张图中所得到的一样。SLUS允许一个平稳的比特率，该比特率不会显著影响最后的平均吞吐率（2.183Mbit/s对比2.164Mbit/s）。在这两个例子中，关于可用的（大概为2.3Mbit/s）带宽利用率是很高的。
由于我们已经证明了所采用的SLUS配置确实不会影响弹性流的吞吐率，我们现在要评估它是否能完成它所承诺的确保实时流的低数据包延迟。因此我们监视了同时发生的在线游戏流的数据包间隔到达时间，所利用的CS游戏模拟器定期在服务端每40ms生成一个游戏数据包
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[152639]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
