搜索
目录A、http缓存B、CDN缓存C、基于不同内容承载类型的cdn缓存方式Ahttp缓存1、缓存有关的HTTP消息报头1）Expires与Cache-Control2）Last-Modified和ETag3）Last-Modified与If-Modified-Since4）ETag与If-None-MatchAhttp缓存2、浏览器缓存请求流程浏览器再次请求，情况就不一样了。首先会读取缓存，然后判断缓存是否过期，如果不过期，就直接读取缓存。否则，判断浏览器返回的头部信息是否存在Etag,如果存在，浏览器会像服务器发送带有If-None-Match的请求头，来和服务器返回的Etag做对比，如果if-None-Match和Etag相等。说明缓存没有更新，服务器返回304，浏览器继续从缓存读取相应的内容。如果if-None-Match和Etag不等，则服务器返回200，浏览器重新需要从服务器获取内容。如果服务器的返回信息里面没有Etag，则判断浏览器的返回信息里是否有Last-Modified。如果有，浏览器会像服务器发送一个if-Modified-Since的请求头。然后if-Modified-Since的值会和Last-Modified的值做对比，如果if-Modified-Since的值大于等于Last-Modified，则服务器返回304，文件没有更新，直接读取缓存即可。如果if-Modified-Since的值小于Last-Modified。则说明浏览器的缓存不是最新的，需要从服务器重新读取。如果服务器返回的头部信息既没有Etag，又没有Last-Modified,则缓存已经失效了，重新服务器抓取。Ahttp缓存3、用户操作行为与缓存当用户在按F5进行刷新的时候，会忽略Expires/Cache-Control的设置，会再次向服务器发送请求，而Last-Modified/Etag还是有效的，服务器会根据情况判断返回304还是200；而当用户使用Ctrl+F5进行强制刷新的时候，所有的缓存机制都将失效，重新从服务器获取资源。4、不能被缓存的情况1）Cache-Control:no-cache，pragma:no-cache，或Cache-Control:max-age=02）POST、PUT请求无法被缓存3）HTTP响应头中不包含Last-Modified/Etag，也不包含Cache-Control/Expires的请求BCDN缓存1、CDN缓存机制CDN边缘节点缓存策略因服务商不同而不同，但一般都会遵循http标准协议，通过http响应头中的Cache-control:max-age的字段来设置CDN边缘节点数据缓存时间。当客户端向CDN节点请求数据时，CDN节点会判断缓存数据是否过期，若缓存数据并没有过期，则直接将缓存数据返回给客户端；否则，CDN节点就会向源站发出回源请求，从源站拉取最新数据，更新本地缓存，并将最新数据返回给客户端。所以，如果我们修改了内容，最好加个版本号，来容CDN重新获取资源，从而减少不必要的麻烦，比如:app.js?v=20160717或者tyle.css?v=2016071701CDN服务商一般会提供基于文件后缀、目录多个维度来指定CDN缓存时间，为用户提供更精细化的缓存管理。CDN缓存时间会对“回源率”产生直接的影响。若CDN缓存时间较短，CDN边缘节点上的数据会经常失效，导致频繁回源，增加了源站的负载，同时也增大的访问延时；若CDN缓存时间太长，会带来数据更新时间慢的问题。开发者需要增对特定的业务，来做特定的数据缓存时间管理。缓存的设置建议：1、对于不经常更新的静态文件，建议将缓存时间设置为1个月以上（eg：图片类型，应用下载类型）。2、对于需要更新并且更新很频繁的静态文件，可以将缓存时间设置短些（eg：js,css等）。3、对于动态文件（eg：php|jsp|asp），建议设置缓存时间为0s，即不缓存（eg：php|jsp|asp）。4、建议源站的内容不要使用同名更新，以版本号的方式方步，即采用img-v1.0.jpg、img-v2.1.jpg的命名方式。BCDN缓存2、阿里云CDN缓存机制C基于不同内容承载类型的cdn缓存方式1、网页加速适用小文件的场景，如网页上有各种元素，HTML、CSS、JavaScript、图片等，这些网页元素的平均大小基本都在1M以下，有些可能只有几KB,几十KB。C基于不同内容承载类型的cdn缓存方式2、大文件下载加速适用大型文件的场景，如安桌的APK应用包，iOS的IPA应用包，网络游戏的安装包，下载的gz,zip,tar等文件。因为文件比较大，有些文件的大小可能是几百Ｍ，几Ｇ时或更大，传输的时间相对会比较长，极难在一次请求中完成下载。如果中途断开了，将前功尽弃，又要重新传输,重试的成本高。相比小文件，大文件的传输有很大的稳定性问题。这时可以将文件按照一定的大小，分成若干个数据块，CDN节点分成多次请求回源，按顺序每次下载固定大小的数据块，并立即返回给客户端。如果中途断开了也能从某个失败的数据块开始继续下载。当文件大于几百Ｍ，几Ｇ时，如果为每个数据包的传送创建一个连接，就会有大量的建立/释放连接的开销，而长连接方式则可以让一个大文件分片传送时只创建一个连接，每传完一个分片就重置keepalive_timout，重新计时，这样更高效，性能更高。C基于不同内容承载类型的cdn缓存方式3、音视频在线使用的音视频文件采用的是流式传输方式，将整个A/V及3D等多媒体文件经过特殊的压缩方式分成一个个压缩包，由视频服务器向用户计算机连续、实时传送。用户不必采用像下载方式那样等到整个文件全部下载完毕才能观看，而只需经过几秒或几十秒的启动延时即可在用户的计算机上利用解压设备对压缩的A/V、3D等多媒体文件解压后进行播放和观看。虽然音视频文件也是大文件，但其文件结构和应用形态写安装包之类完全不同，如果使用网页加速的方式会出现卡画面现象，如果使用下载加速，顺序播放通宵没有问题，一旦拖拽进度条则可能会卡顿，等待。为了解决拖拽播放需求，需要解析进度条时刻对应的数据块，单独的，有序的重新下载。在观看视频时可以看到进度条分三种颜色，分别表示已加载的，已缓存的，未缓存加载的。原视频文件以内容类别、版本等为索引按片段存放在服务器上，用户端加载的第一个包里保存的是元数据，视频每25帧会有一个关键帧，元数据里包含这些视频帧序列，时间长度、码率、采样频率等信息。在观看时并不需要等到视频全部加载完，当需要跳着看视频时，即使前面的内容还未加载完，也可以从新起点进行加载，通过视频帧的索引信息找到该视频帧，先加载新起，会点前后的视频帧，因为视频帧非常少，所以跳着看也不会卡。C基于不同内容承载类型的cdn缓存方式4、动态资源某些页面，如论坛，邮箱应用等，需要动态生成（访问数据库+页面渲染），每次请求的数据都不一样，通常无法将结果缓存下来。如一个论坛的帖子，这次请求可能盖了10层楼，下次请示可能就是20层楼了。因为每次的内容都不一样，要与后端的数据库做交互，不能在CDN缓存节点取到相应的数据，只能将请求发送到从源站获取。针对这种数据，CDN节点会将每次请求穿透回源站上，此时应用的是链路加速，将请求通过最短的链路发送到服务器站，从而提高访问速度。C基于不同内容承载类型的cdn缓存方式5、流媒体直播直播处理的是流媒体数据，而不是成形的，单独的，可反复访问的单一文件，故没必要缓存所有数据。通宵而言，CDN节点使用长连接，不停从源站拉取最新画面帧数据，并缓存一小段（3-5秒），超时过后即删除过期数据，同时缓存新数据。直播客户端获取到的，并不是一个完整的数据流，有头没尾，不可以快进/回退，缓存的数据消费了就删除。在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。直播的分段策略基本上推荐是10秒一个分片，为了缓存等方面的原因，在索引文件中会保留最新的三个分片地址，以类似“滑动窗口”的形式，进行更新。m3u8，是直播的索引文件。包含第一个TS分片的序列号，每个分片TS的最大的时长，m3u8文件结束符，分片TS的信息，如时长，带宽等。C基于不同内容承载类型的cdn缓存方式5、链路加速用户和网站服务器中间通过全国各大城市的多路（电信、联通、移动、教育）骨干网络内部连接、骨干网间互联和骨干网与互联网互联互通,它们之间的通信需要经过重重的路由转发和处理，网络延误不可避免。有别于传统的互联网性能改善方案(如增加接入带宽、升级软硬件和建立多个镜像站点)，CDN是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，从而解决Internet网络拥挤的状况，提高用户访问网站的响应速度。当Web用户点击一个可以内容分发的URL,内容分发网络实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等信息,将用户请求重定向到离用户最近的内容服务器。CDN节点解决了跨运营商和跨地域访问的问题，访问延时大大降低。