CDN小文件的原理

以下为个人所知道的,可能不全,甚至有错误,但希望各位大牛帮忙改正

1.开始,客户机要访问网页,首先要把域名解析为ip地址,客户机要发送一个DNS查询包请求包,在数据包到达ISP路由器之前,有可能会做分光\镜像(个人感觉分光主要是对光纤采用分光,而普通的网线应该采用镜像),也有可能在数据包到达ISP的路由器后通过Forward把数据包复制一份给DPI(重定向服务器)。

2.DPI(重定向服务器)接收到DNS查询包后,检查DNS是允许合法的,如果合法,则定位到服务缓存器,并把一个确定的缓存服务器的ip返回给客户机(如果缓存服务器中已有缓存,则返回有缓存的服务器的IP地址),如果不合法,则丢弃查询包,而客户机按照正常的流程访问网页。(注意DNS查找其实正常DNS查询过程也是在执行的,只不过CDN返回的DNS查询结果比正常的查询结果快,代替了正常的结果)(猜测,因为按照正常的TCP流程,DPI返回的DNS查询结果客户机应该是不会接收的,所以本人猜测可能DPI在返回DNS查询请求的时候,把返回数据包的源地址改为了客户机真正的DNS地址)

3.客户接收到DPI返回的DNS数据包后,向缓存服务器发送请求,如果缓存服务器中已经存在缓存,则返回缓存的数据。如果缓存的数据不存在,那么缓存服务器向真实的服务器请求,然后把请求结果返回给客户,并缓存。

总体来说缓存服务器使用的squid或者nginx。把网页缓存下来,和我在学校做的反向代理差不多,不过中间插入了重定向,以及一些其他的功能。

CDN小文件的流程大概就这样了,希望各位大牛指出我文章中不足的地方,也好修改学习一下,谢谢!

CDN小文件的原理

时间: 2024-10-08 12:01:17

CDN小文件的原理的相关文章

Hadoop对小文件的解决方案

小文件指的是那些size比HDFS的block size(默认64M)小的多的文件.任何一个文件,目录和block,在HDFS中都会被表示为一个object存储在namenode的内存中, 每一个object占用150 bytes的内存空间.所以,如果有10million个文件, 每一个文件对应一个block,那么就将要消耗namenode 3G的内存来保存这些block的信息.如果规模再大一些,那么将会超出现阶段计算机硬件所能满足的极限. 控制小文件的方法有: 1.应用程序自己控制 2.arc

LOSF 海量小文件问题综述

1.LOSF问题概述 在互联网(尤其是移动互联网).物联网.云计算.大数据等高速发展的大背景下,数据呈现爆炸式地增长.根据IDC的预测,到2020年产生的数据量 将达到40ZB,而之前2011年6月的预测是35ZB.然而,社会化网络.移动通信.网络视频音频.电子商务.传感器网络.科学实验等各种应用产生的数 据,不仅存储容量巨大,而且还具有数据类型繁多.数据大小变化大.流动快等显著特点,往往能够产生千万级.亿级甚至十亿.百亿级的海量小文件,而且更多地 是海量大小文件混合存储.由于在元数据管理.访问

ATS写小文件

与读缓存类似,写缓存也有大文件小文件的区分,这里讨论写小文件.整个流程如下: Cache::open_write: 根据key生成一个新key作为earliest_key,不过小文件的话貌似earlist_key没用.根据CacheV->first_key计算的到vol.执行Vol::open_write,在Vol::open_write中进行了简单的aggregation buf的错误检查就执行了OpenDir::open_write.最后将CacheVC::openWriteMain设置为回

FastDFS分布式文件系统设计原理

转载自http://blog.chinaunix.net/uid-20196318-id-4058561.html FastDFS是一个开源的轻量级分布式文件系统,由跟踪服务器(tracker server).存储服务器(storage server)和客户端(client)三个部分组成,主要解决了海量数据存储问题,特别适合以中小文件(建议范围:4KB < file_size <500MB)为载体的在线服务. Storage server Storage server(后简称storage)以

httplib模块,测试cdn节点文件同步

httplib模块是一个专门用于http的模块,urllib和urllib2也都是基于对它进行了更上层次的封装 我记得刚开始的时候,公司用的cdn有段时间抽风,全球40多个节点总是有那么几个节点不同步,导致玩家加载的是老的活动图片,玩家在论坛抱怨,国外的玩家抱怨,那可不像国内的(客服MM万篇一律:您的情况我已经收到,已经在处理了请稍后).国外的要是不立马赶紧马上处理好,玩家会直接撤款,搞不好还告你..论坛一旦接到这样的情况马上就得打电话给我们,管尼码半夜几点.(运维的悲哀)刚开始时候只能写hos

海量小文件存储与Ceph实践

海量小文件存储(简称LOSF,lots of small files)出现后,就一直是业界的难题,众多博文(如[1])对此问题进行了阐述与分析,许多互联网公司也针对自己的具体场景研发了自己的存储方案(如taobao开源的TFS,facebook自主研发的Haystack),还有一些公司在现有开源项目(如hbase,fastdfs,mfs等)基础上做针对性改造优化以满足业务存储需求: 一. 通过对若干分布式存储系统的调研.测试与使用,与其它分布式系统相比,海量小文件存储更侧重于解决两个问题: 1.

海量小文件存储最优解决方案,杉岩数据MOS完美解决

面对千亿量级的小文件,存储系统压力山大 所谓小文件,指的是存储占用空间相对较小的文件,一般来说低于64MB的文件就可以被认定为小文件,而大量的小文件大小则在几KB到几十KB之间.在云计算.大数据业务中,文本.图片.音乐等是典型的小文件应用场景. 随着数字化创新的加速,组织内部的数据呈现出指数级增长的趋势,特别是小文件更是随着业务增长到一个巨大的量级.与大文件的存储不同的是,大量磁盘在小文件存储场景中的性能极低,单块企业级SATA磁盘如果全部存储4KB左右的小文件,带宽只有520KB/s,远远小于

JVM理解(上):classloader加载class文件的原理和机制

转自:https://www.jianshu.com/p/52c38cf2e3d4 JVM理解(上):classloader加载class文件的原理和机制 安东尼_Anthony关注 12018.11.10 10:16:40字数 4,361阅读 3,731 1 JVM架构整体架构 在进入classloader分析之前,先了解一下jvm整体架构: JVM架构 JVM被分为三个主要的子系统 (1)类加载器子系统(2)运行时数据区(3)执行引擎 1. 类加载器子系统 Java的动态类加载功能是由类加载

关于hadoop处理大量小文件情况的解决方法

小文件是指那些size比HDFS的block size(默认64m)小的多的文件.任何一个文件,目录和bolck,在HDFS中都会被表示为一个object存储在namenode的内存中,每一个object占用150bytes的内存空间.所以,如果有10milion个文件,每一个文件对应一个block,那么就会消耗namenode 3G来保存这些block的信息.如果规模再大一点,那么将会超出现阶段计算机硬件所能满足的极限. 控制小文件的方法有: 1应用程序自己控制 2archieve 第一种是我