手机App应用内容分发系统存在的问题及对策解决方案

流媒体分发

在流媒体分发中，通常对flv的支持会更好。原因是flv根据文件偏移量执行快进和快退。 mp4编码会随着时间的推移而快进和快退。一些CDN供应商可能不正确支持mp4，或者可能根本不支持mp4。但是，flv通常可以直接应用。实际上，flv格式是由播放器计算的，这降低了分发服务器的技术要求。这里的困难主要是由作为上述来源的返回模块的复杂性引起的。如果需要进一步处理索引，则程序级别将变得更加复杂。

另外，如果分布式流媒体的容量相对较大，建议主动拆分文件（小于100MB）。这样，您可以对某些配置错误的服务器进行一些优化。例如，在没有阵列或阵列卡损坏的系统上，避免将大文件放在单个磁盘上，以便最大程度地从多个磁盘读取文件，从而有效地提高了吞吐量。

前端SDK应该能够收集数据，例如启动客户端IP，连接到服务器IP，解析服务器IP时间开销。连接到服务器IP的时间成本，第一个数据包的时间成本以及数据中断率。服务器返回状态值，数据传输时间等。因为整个网络中都有一些“代理服务器”，所以某些请求永远不会到达服务器，或者该请求已被修改。将日志放在前端和后端一起可以使分析更好，更清晰，从而可以改进方法并改善用户体验。数据是系统演进的重要组成部分。

必须考虑反延伸链的设计。在不严重影响客户端和服务器端性能的情况下，打破热链规则的难度应尽可能高。引荐来源网址很容易伪造，但可以用作过滤请求的第一道防线。它通过复杂的规则增加了热链接的成本。分析前端和后端日志以了解流量消耗，并根据需要定期修改防盗链算法。

应用程序分布

当前正在部署许多移动应用程序，并且许多应用程序面临链接劫持的问题。如果您面临DNS劫持，则基本上只能使用HttpDns之类的第三方解决方案。如前所述，如果您的http层由“代理服务器”缓存，则可以通过构造动态URL来配置缓存。对于http劫持，您可以参考参考信息中的链接。原则上，了解问题的性质后，您会发现某些方法更具针对性，但有些方法不容易解决。发现问题后，您可以尽快提出投诉。因此，每个人都可以通过查看我稍后提供的参考链接来学习如何找到各种千斤顶。4.3在Linux上优化Nginx的性能

与CDN系统相比，服务器程序主要使用系统的网络IO和磁盘IO。对于较小的请求（从几千字节到几十千字节），所测量的关键指标将更多地关注于每秒可以响应的请求数。由于请求的文件很小，因此nginx对小文件进行了很多优化。例如，sendfile函数可以避免将文件读取到内存中（由系统缓存到用户内存中，然后传递给系统以用于网络接口），并使操作系统内核直接发送文件。当然，此功能也有其缺点。换句话说，如果文件太大，则带宽将被请求占用，因此nginx具有内部限制来防止这种情况。相对较大的请求通常更加关注磁盘IO和内存优化。对于大请求，nginx使用固定长度的缓冲区来减少用于每个请求的网络和磁盘IO。这样，您可以更公平地将有限的IO分配给多个请求，并且浪费不均。

Nginx本身由事件模型驱动，并且在多个进程中，在正常情况下，每个进程只有一个线程。但是，使用事件模型，即使是一个线程也可以响应数千个请求。

当nginx在Linux机器上运行时，服务文件的存储空间远远大于机器内存，并且如果这些文件是热文件，则连接到nginx服务器可能会导致连接超时或慢速链接设置问题。

必须从两个方面解决这个问题。 Linux文件访问操作分为两类。

一种使用操作系统的虚拟存储来缓存热文件，这可以加快磁盘访问速度。接口的另一种类型称为直接访问模式，绕过操作系统缓存并将文件直接加载到用户进程存储空间中。 Linux上的第一类访问模式不支持“异步操作”，即不兼容的事件模式。第二种访问模式与“异步操作”兼容，但是该接口不友好，因为没有用于磁盘缓存的操作系统。第二种类型主要是没有高速缓存管理，这会大大降低系统性能。在Linux上，nginx始终将第一种访问模式投入运行。 Nginx的设计目标是为多个流程提供更好的稳定性，并减少流程之间的交互。使用第二种模式会增加复杂性，并会导致进程之间的交互受到更多的阻止（考虑到对数据缓存机制的支持）。这意味着，如果无法将请求的资源放入系统的内存中，则事件模型将被文件操作中止，并且无法正常响应连接。在nginx 1.7.12及更高版本1.8中，nginx引入了线程池来缓解上述问题。当主线程决定启动文件系统操作时，它将创建一个特殊作业并删除工作队列中的作业。线程池中的线程继续在队列中执行文件操作，然后将执行的结果放入返回队列中，主线程继续进行后续操作。通过此操作，主线程不再被阻塞，因此连接建立不会中断。

但是，如果IO严重不足，则请求时间可能仍然很长，或者客户端请求可能会超时。在这种情况下，您可以执行其他优化，例如磁盘调度算法，文件存储结构优化和存储升级。上一篇文章说，nginx使用线程池性能提高了9倍，这实际上是Linux上的性能问题。这个问题在FreeBSD系统上不存在，因为FreeBSD系统上的异步IO支持使用内存作为文件缓存。

不支持Linux的原因是因为社区辩论。而不是系统本身的功能。

如何降低成本

CDN的价格不是特别透明，知名制造商通常会与销售商协商。而且，根据流量的不同会有一些折扣。但是，CDN在市场上的价格基本上可以考虑如下：

文件的价格小于流媒体的价格，大于下载的价格。

直播价格也将高于点播流媒体价格。

如果签订的价格合同基于标准峰值带宽+ 95计费方法，那么降低峰值通常是常用的方法。但是，根据您的特定使用情况，您需要执行峰去除。例如，以下情况可能不适用或可能属于峰去除。我们紧急发布一个修复严重错误或安全漏洞的版本。这时，可能会提示用户尽快升级。很高的山峰。开展新业务时，您的旧流量并没有发生明显变化，并且在一些热门时期创造了新的高峰。大规模的黑客攻击创造了额外的流量并带来了新的高峰。峰值消除方法是交错请求以避免同时请求。以下方案更适合去除峰。我们将发布非关键升级，并期望用户逐步过渡。要减少最大值，可以限制通知升级用户的数量。针对不健康流量的自动日志分析具有自动应变计划，例如自动拒绝某些请求。

包含SDK对客户的影响

实际上，类似于HttpDns或p2p，此处的sdks是代码安全性问题，由于大小，稳定性问题，集成额外成本（小型客户没有人力或能力），需求等导致的CDN成本增加。您将面对此事。它是否真的存在（小客户可能没有能力考虑它）。这也是SDK解决方案通常难以推广的问题。开源SDK可以大大减少客户对代码安全性的担忧，但是成本和集成成本并不容易解决。5. P2P穿墙打孔

让我们从Internet添加临时补充内容。帮助所有人简要了解P2P的核心技术并突破壁垒。

通常，P2P是多对多传输，但实际上可以分为:控制部分和传输部分，P2P网络需要一些服务来交换信息并协调钻孔。当然，这些服务通常还具有查询资源位置和相关的能力。与传输部分相关的对象分为两类：可直接访问的对象和隐藏在NAT后面的对象。只要一个或多个参与方可以直接访问，控制部分就可以用来建立传输通道，而无需钻孔。如果两个实体都隐藏在NAT之后，则会发生打孔问题。

所谓的打孔实际上是指当NAT的内部服务器连接到外部实体时，隐藏在NAT服务器中的“临时”映射关系。这样，NAT服务器可以将数据包从外部网络正确发送到内部实体。

在P2P钻孔过程中，每个实体必须主动连接到P2P网络中的服务器，并向服务器报告其自己的外部网络IP和钻探的“临时”端口。这样，服务器可以将实体的资源信息和网络信息存储在一起，并为后续的连接请求提供输入参数。

当实体A准备好连接到实体B时，您要做的就是通过P2P网络上的服务器获取连接信息并直接连接。这是因为先前已设置了“临时”孔。

实际上，还有一些其他要求。

每个实体都必须像P2P网络服务器一样定期发送心跳。心跳是为了确保打孔的“临时”端口不会被擦除。

NAT服务器是圆锥型服务器。这意味着从外部主机发送到该端口的任何信息都可以传递到打孔主机。这种类型的NAT服务器在大多数情况下都可以解决。

如果NAT打孔失败，最好放弃或切换到服务器转发模式。

上面是一个相对简单的UDP打孔，TCP也可以在墙上打孔，但是比较复杂。美区制造商有很多在墙上钻孔的专家，简单的算法无法解决复杂的家庭Internet环境中的许多详细问题。 “高速通道”中的P2P传输效果非常好，因为这些制造商已经在该领域工作了很长时间。