[OT] 在学校出口做静态内容缓存是不是一个好主意

106 views

Skip to first unread message

Bojie Li

unread,

Nov 11, 2012, 2:09:38 PM11/11/12

to USTC_LUG

网络流量的很大部分是一些热门静态资源，例如各大门户的图片、js、css等，比如双11期间电商网站的很多资源都被大量重复访问，给这些网站的CDN带来很大压力。HTTP头中有指定Cache-Control和Expires，据此可以判断资源是否静态及其有效期。但目前HTTP头只是对浏览器有效，学校一侧网络上并没有cache，流量全部被导到骨干网上了。我突发奇想，如果在学校出口上做个静态资源cache，就可以节省学校的出口流量。如果每个这种流量规模的网络区域都做个cache，就能降低骨干网的拥塞程度，节约网站的带宽。

技术上如果大流量不方便阻塞处理的话，我觉得可以用类似GFW的方法，将内网请求分光到一台cache服务器，如果命中就伪装成外网IP向内网IP返回cache内容，并向外网IP发TCP的RST。由于内网延迟很低，几乎可以保证cache的返回先于外网服务器。这里存在几个问题：1、TCP三次握手的前两次没有有效载荷，到外网服务器的连接还是要建立。2、cache命中后发送RST，连接就断了，TCP建立连接是挺费资源的，keep-alive机制受影响；如果不发RST，后续的TCP序列号就乱了。

这是不是一个好主意？是否可以起到显著降低骨干网流量的效果？

Zhang Cheng

unread,

Nov 11, 2012, 8:40:02 PM11/11/12

to USTC LUG

你这个想法正是很多二级运营商小区宽带的做法。但是，所有二级运营商做cache，并不是为了减轻主干网压力，而是为了减少小区出口的带宽，降低自己的成本。国内的主干网的流量足够大，没那么容易就饱和。不过，小区宽带缓存的那套设备成本很高，据jameszhang说要上百万。说那套缓存的东西也向许多学校推荐过，但没有一个学校愿意买，太贵了。

缓存原理，关键字 dpi。缓存的原理与GFW基本一样。在网关处劫持流量，分光（复制）出去，到缓存服务器，如果发现命中，缓存服务器伪造真实服务器返回一个302到缓存服务器的真实url，并向真实服务器发出中止信号（rst）。你考虑的1、2两个问题都不是问题，在网关上想伪造真实服务器跟你通信太容易了，这是非常成熟的技术。难点在于如何缓存文件。

1) 缓存服务器与CDN节点不同，数据pass by缓存服务器，pass through CDN节点。CDN服务器在收到一个miss请求时，会回源，并根据cache-control或者人为设定的规则（如根据url后缀）来缓存，而缓存服务器，由于是pass by，缓存服务器除非自己下一遍，否则不知道文件的cache-control。

2) 大量的文件请求都是没有control-control的，CDN节点除了根据cache-control缓存外，还可以人为的配置很多规则，而更重要的，CDN提供cache invalidate的接口。而这种缓存则是十分不可控的。

3) 大量的http请求可能都是bytes-range请求，还有更多的请求是动态内容（即php、aspx等这类由服务器动态产生的内容）。bytes-range的请求更难缓存，动态内容则不应该缓存。

另外，小区宽带缓存时，一般只会缓存flv、mp4、exe、rar等这种（十分可能是）大文件的请求，而不会缓存图片、js、css。图片、js、css一般网站会经常更新，同时因为比较小，所以一般都会让浏览器缓存。浏览器对于这些文件每次都会请求一下，服务器返回一个304就可一了，消耗的流量非常小。一般小区宽带重点缓存的是两种类型的文件：

* 下载型的（exe、rar等后缀）

* 多媒体型的（flv、mp4）各大视频网站的视频一般都会被缓存

小区缓存通常不参考cache-control，一般都是同名文件永久缓存。

小区的缓存很多时候有许多问题。例如我碰到的几个例子。

1、此前有至少三个人跟我反应过用mirrors.ustc更新ubuntu时报hashsum mismatch，经查都是小区缓存的问题，小区缓存缓存了一个文件，没有及时更新。（这个文件是没有cache-control头的）

2、我在北京这边小区里下载itunes，由于itunes使用同名更新，导致我在小区里怎么下都是旧的版本，不得不用外面的服务器中转一下。

3、风云直播的一个播放器（后缀flv）被缓存了，而播放器会用自己url的相对路径来加载另外两个组件，而由于被小区缓存（302）了，另两个组件没有被缓存，导致其他组件加载失败，最终无法播放。后来风云直播使用的解决方法是，将flv的后缀改成php，来骗过小区缓存不要cache。

许多页游（网页游戏），据说加载成功率最高的也才90%，而大多数的开发者都不知道为何加载失败，我猜测跟小区缓存有关。

公网上的流量，我估计http的流量不到30%（我没有查过统计数据，凭感觉猜的），甚至更少，而http的流量里面，不能缓存的内容可能占多数，还有许多可以缓存的内容，网站开发者需要自己去控制缓存。

其实总结的说，这种小区缓存就是无量奸商用来降低成本的，有百害而只有一利（在小区看优酷、搜狐的热门视频确实快）。

PS，说个有意思的事情，我们有一些统计服务器，客户端会不定期的报数据，HTTP POST，返回一个200即可，返回的东西只有HTTP头，没有内容。相关的几个机房带宽快用满了，于是我尝试去优化，我发现返回的HTTP头比较大，有许多东西都用不着，于是我优化了一下返回的头，只留下了200这一行，省了50个字节左右，仅从返回头减少的体积看，出带宽应该能降低一半左右，但实际上发现几乎没有减少。然后发现，tcp三次握手所消耗的带宽（近200字节），比一次http的请求消耗的更多。

2012/11/12 Bojie Li <boj...@gmail.com>

网络流量的很大部分是一些热门静态资源，例如各大门户的图片、js、css等，比如双11期间电商网站的很多资源都被大量重复访问，给这些网站的CDN带来很大压力。HTTP头中有指定Cache-Control和Expires，据此可以判断资源是否静态及其有效期。但目前HTTP头只是对浏览器有效，学校一侧网络上并没有cache，流量全部被导到骨干网上了。我突发奇想，如果在学校出口上做个静态资源cache，就可以节省学校的出口流量。如果每个这种流量规模的网络区域都做个cache，就能降低骨干网的拥塞程度，节约网站的带宽。

技术上如果大流量不方便阻塞处理的话，我觉得可以用类似GFW的方法，将内网请求分光到一台cache服务器，如果命中就伪装成外网IP向内网IP返回cache内容，并向外网IP发TCP的RST。由于内网延迟很低，几乎可以保证cache的返回先于外网服务器。这里存在几个问题：1、TCP三次握手的前两次没有有效载荷，到外网服务器的连接还是要建立。2、cache命中后发送RST，连接就断了，TCP建立连接是挺费资源的，keep-alive机制受影响；如果不发RST，后续的TCP序列号就乱了。

这是不是一个好主意？是否可以起到显著降低骨干网流量的效果？

Cheng,

Best Regards

Bojie Li

unread,

Nov 12, 2012, 12:18:36 AM11/12/12

to USTC_LUG

2012/11/12 Zhang Cheng <steph...@gmail.com>:
> 国内的主干网的流量足够大，没那么容易就饱和。

有的网站比较快，大多数小网站都比较慢，如果不是主干网的问题，是网站服务器带宽不足的问题吗？单个小网站所需带宽应该也不大，难道是机房的总带宽太小？

> 缓存原理，关键字
> dpi。缓存的原理与GFW基本一样。在网关处劫持流量，分光（复制）出去，到缓存服务器，如果发现命中，缓存服务器伪造真实服务器返回一个302到缓存服务器的真实url，并向真实服务器发出中止信号（rst）。你考虑的1、2两个问题都不是问题，在网关上想伪造真实服务器跟你通信太容易了，这是非常成熟的技术。难点在于如何缓存文件。

为什么要返回302跳转，而不是直接返回文件内容？302跳转就改变了文件的路径，我记得你也说过Flash相对路径加载失败的问题。直接返回文件内容对用户是透明的，会有什么问题？

> 1) 缓存服务器与CDN节点不同，数据pass by缓存服务器，pass through
> CDN节点。CDN服务器在收到一个miss请求时，会回源，并根据cache-control或者人为设定的规则（如根据url后缀）来缓存，而缓存服务器，由于是pass
> by，缓存服务器除非自己下一遍，否则不知道文件的cache-control。

尽管是pass by，缓存服务器也要对HTTP协议进行解析吧，不然如何分出URL和文件内容？既然能解析HTTP协议，为什么不能把服务器返回的HTTP头中的Cache-Control和Expires记录进缓存信息？

> 2)
> 大量的文件请求都是没有control-control的，CDN节点除了根据cache-control缓存外，还可以人为的配置很多规则，而更重要的，CDN提供cache
> invalidate的接口。而这种缓存则是十分不可控的。
>
> 3)
> 大量的http请求可能都是bytes-range请求，还有更多的请求是动态内容（即php、aspx等这类由服务器动态产生的内容）。bytes-range的请求更难缓存，动态内容则不应该缓存。

小区宽带是如何缓存bytes-range请求的？分析HTTP头，然后把不同range的文件片段拼接起来？

>
> 另外，小区宽带缓存时，一般只会缓存flv、mp4、exe、rar等这种（十分可能是）大文件的请求，而不会缓存图片、js、css。图片、js、css一般网站会经常更新，同时因为比较小，所以一般都会让浏览器缓存。浏览器对于这些文件每次都会请求一下，服务器返回一个304就可一了，消耗的流量非常小。一般小区宽带重点缓存的是两种类型的文件：
> * 下载型的（exe、rar等后缀）
> * 多媒体型的（flv、mp4）各大视频网站的视频一般都会被缓存
> 小区缓存通常不参考cache-control，一般都是同名文件永久缓存。

考虑到TCP连接建立的带宽成本，这种旁路cache的方法确实不适合js、css、图片这些小文件啊。不过为什么不采用阻塞方式，即类似nginx
reverse proxy的方式：向外网服务器的连接首先建立到cache服务器上，如果发现所要获取的URL已被缓存就直接返回内容，外网服务器一个数据包都收不到；如果发现URL未被缓存就假冒成内网IP向外网服务器发起连接，收到内容，然后再把内容返回给内网IP（之所以要新建一个连接，是考虑到服务器返回的TCP序列号可能不同）。可能会增加几毫秒的延迟，不过这个应该无所谓吧。相当于在reverse
proxy上增加了IP伪装功能。是不是这种方式对缓存服务器的资源消耗太大？

>
> 小区的缓存很多时候有许多问题。例如我碰到的几个例子。
> 1、此前有至少三个人跟我反应过用mirrors.ustc更新ubuntu时报hashsum
> mismatch，经查都是小区缓存的问题，小区缓存缓存了一个文件，没有及时更新。（这个文件是没有cache-control头的）
> 2、我在北京这边小区里下载itunes，由于itunes使用同名更新，导致我在小区里怎么下都是旧的版本，不得不用外面的服务器中转一下。
> 3、风云直播的一个播放器（后缀flv）被缓存了，而播放器会用自己url的相对路径来加载另外两个组件，而由于被小区缓存（302）了，另两个组件没有被缓存，导致其他组件加载失败，最终无法播放。后来风云直播使用的解决方法是，将flv的后缀改成php，来骗过小区缓存不要cache。
> 许多页游（网页游戏），据说加载成功率最高的也才90%，而大多数的开发者都不知道为何加载失败，我猜测跟小区缓存有关。
>
> 公网上的流量，我估计http的流量不到30%（我没有查过统计数据，凭感觉猜的），甚至更少，而http的流量里面，不能缓存的内容可能占多数，还有许多可以缓存的内容，网站开发者需要自己去控制缓存。

少院机房网关上的流量，似乎UDP是TCP的几倍。是不是P2P下载的流量要超过HTTP上网、看视频等的流量？

>
> 其实总结的说，这种小区缓存就是无量奸商用来降低成本的，有百害而只有一利（在小区看优酷、搜狐的热门视频确实快）。

如果HTTP流量不到30%的话，做个缓存能降低多少成本？既然设备很贵，如果只能降低5%带宽值得做吗？

>
> PS，说个有意思的事情，我们有一些统计服务器，客户端会不定期的报数据，HTTP
> POST，返回一个200即可，返回的东西只有HTTP头，没有内容。相关的几个机房带宽快用满了，于是我尝试去优化，我发现返回的HTTP头比较大，有许多东西都用不着，于是我优化了一下返回的头，只留下了200这一行，省了50个字节左右，仅从返回头减少的体积看，出带宽应该能降低一半左右，但实际上发现几乎没有减少。然后发现，tcp三次握手所消耗的带宽（近200字节），比一次http的请求消耗的更多。

这就是我提的两个问题
1、TCP三次握手的前两次没有有效载荷，到外网服务器的连接还是要建立。2、cache命中后发送RST，连接就断了，TCP建立连接是挺费资源的，keep-alive机制受影响。
也就是说如果文件比较小的话，三次握手的带宽比文件本身还大，而且不管是用302还是直接返回内容，到服务器的原有连接肯定是要断开的（不然TCP序列号都不对）。而浏览器到服务器的连接一般是keep-alive的，被缓存服务器一搞，就必须每发出一个HTTP请求就建立一次TCP连接，可能反而增加成本。

Zhang Cheng

unread,

Nov 12, 2012, 1:10:04 AM11/12/12

to USTC LUG

2012/11/12 Bojie Li <boj...@gmail.com>

有的网站比较快，大多数小网站都比较慢，如果不是主干网的问题，是网站服务器带宽不足的问题吗？单个小网站所需带宽应该也不大，难道是机房的总带宽太小？

很多时候慢的原因是跨ISP访问。

为什么要返回302跳转，而不是直接返回文件内容？302跳转就改变了文件的路径，我记得你也说过Flash相对路径加载失败的问题。直接返回文件内容对用户是透明的，会有什么问题？

返回302可以使得程序变得简单。全程伪造通信成本太高，用GFW这种规模的处理能力，估计也只能承担一个小城市的量。

尽管是pass by，缓存服务器也要对HTTP协议进行解析吧，不然如何分出URL和文件内容？既然能解析HTTP协议，为什么不能把服务器返回的HTTP头中的Cache-Control和Expires记录进缓存信息？

cache-control本来就只是一个建议，但这不能根本的解决问题。而且大多数http的内容都是没有cache-control的，比如mirrors.ustc。

如果要根据cache-control来缓存，那还需要一个东西专门来管理缓存的内容，要定期的清理过期的内容，这个成本也非常高。

小区宽带是如何缓存bytes-range请求的？分析HTTP头，然后把不同range的文件片段拼接起来？

先不说小区宽带，先说说CDN。CDN一般分为两种（或者更多）平台，小文件和大文件。对于小文件（js/css这种量级），第一个用户来请求时，服务器先去upstream获取整个文件，此间客户端是被hang在那里的，新来的客户端也一样被放到一个等待队列里，当upstream返回完整的文件之后，服务器再向所有的客户端分发。对于大文件，一般都是先手动将要分发的文件放到CDN节点上，然后CDN节点其实就是一个普通的http服务器。小文件的这种方式不适合大文件，因为客户端被hang住的时间太久，latency太长，并且可能超时。而CDN一般不会proxy bytes-range，如果有bytes range的请求，CDN会到upstream获取完整的文件，然后自己来处理bytes range。

小区宽带其实是第二种，先把整个文件都拿过来，然后自己是http服务器。

考虑到TCP连接建立的带宽成本，这种旁路cache的方法确实不适合js、css、图片这些小文件啊。不过为什么不采用阻塞方式，即类似nginx
reverse proxy的方式：向外网服务器的连接首先建立到cache服务器上，如果发现所要获取的URL已被缓存就直接返回内容，外网服务器一个数据包都收不到；如果发现URL未被缓存就假冒成内网IP向外网服务器发起连接，收到内容，然后再把内容返回给内网IP（之所以要新建一个连接，是考虑到服务器返回的TCP序列号可能不同）。可能会增加几毫秒的延迟，不过这个应该无所谓吧。相当于在reverse
proxy上增加了IP伪装功能。是不是这种方式对缓存服务器的资源消耗太大？

“可能会增加几毫秒的延迟”，这往往是不能接受的，尤其对于小文件。打开一个网页，往往需要加载上百个资源文件，延迟太大会严重影响用户体验。

另外还是那个原因，伪装的成本太大。

少院机房网关上的流量，似乎UDP是TCP的几倍。是不是P2P下载的流量要超过HTTP上网、看视频等的流量？

UDP的使用似乎是要比TCP大很多的，其实TCP就是对UDP的封装，增加了握手而已（当然，这是在协议层面做的），许多应用不喜欢TCP，会用UDP，自己来处理可靠性问题。比如openvpn over udp就是一个很容易理解的例子。

如果HTTP流量不到30%的话，做个缓存能降低多少成本？既然设备很贵，如果只能降低5%带宽值得做吗？

HTTP的流量中，一大半可能都是不能缓存的。只降低5%带宽显然不值得，还不如买带宽。从实施上来说，铺设光缆的成本低多了。国内带宽普遍很小不是因为成本太高运营商不铺，而是因为垄断。

这就是我提的两个问题
1、TCP三次握手的前两次没有有效载荷，到外网服务器的连接还是要建立。2、cache命中后发送RST，连接就断了，TCP建立连接是挺费资源的，keep-alive机制受影响。
也就是说如果文件比较小的话，三次握手的带宽比文件本身还大，而且不管是用302还是直接返回内容，到服务器的原有连接肯定是要断开的（不然TCP序列号都不对）。而浏览器到服务器的连接一般是keep-alive的，被缓存服务器一搞，就必须每发出一个HTTP请求就建立一次TCP连接，可能反而增加成本。

所以小区宽带只缓存大文件。当然，它比较笨，所以一般简单的根据后缀来判断哪些文件该缓存，js/css等通常是不会缓存的，节省不了多少带宽。keep alive不都是好事，我在有些服务器上是把keep alive关掉的，在mirrors.ustc上，我设置的keep alive只有3s。按我的理解，服务大文件时没必要用keep alive，短时间内对同一个客户端服务大量小文件才有意义。

Cheng,

Best Regards

Bojie Li

unread,

Nov 12, 2012, 1:41:28 AM11/12/12

to USTC_LUG

2012/11/12 Zhang Cheng <steph...@gmail.com>:

> “可能会增加几毫秒的延迟”，这往往是不能接受的，尤其对于小文件。打开一个网页，往往需要加载上百个资源文件，延迟太大会严重影响用户体验。

几毫秒都不能接受，那么到Google上百毫秒的延迟让我们情何以堪？

> HTTP的流量中，一大半可能都是不能缓存的。只降低5%带宽显然不值得，还不如买带宽。从实施上来说，铺设光缆的成本低多了。国内带宽普遍很小不是因为成本太高运营商不铺，而是因为垄断。

既然不值得，小区宽带为什么还要做缓存？

> 所以小区宽带只缓存大文件。当然，它比较笨，所以一般简单的根据后缀来判断哪些文件该缓存，js/css等通常是不会缓存的，节省不了多少带宽。keep
> alive不都是好事，我在有些服务器上是把keep alive关掉的，在mirrors.ustc上，我设置的keep alive只有3s。
> 按我的理解，服务大文件时没必要用keep alive，短时间内对同一个客户端服务大量小文件才有意义。

keep alive对浏览器访问大量同源小文件来说也不是好事？是服务器的并发连接数太多的问题？

Zhang Cheng

unread,

Nov 12, 2012, 1:52:52 AM11/12/12

to USTC LUG

2012/11/12 Bojie Li <boj...@gmail.com>

2012/11/12 Zhang Cheng <steph...@gmail.com>:

> “可能会增加几毫秒的延迟”，这往往是不能接受的，尤其对于小文件。打开一个网页，往往需要加载上百个资源文件，延迟太大会严重影响用户体验。

几毫秒都不能接受，那么到Google上百毫秒的延迟让我们情何以堪？

这就是为什么要有http keep alive。有些网站甚至会想办法合并请求，例如taobao nginx，可以将两个文件用同一个http请求返回。淘宝的CDN的响应延迟都很低。响应延迟和下载带宽是不同的指标，在不同的场合需求也不一样大。例如下载大文件，响应时间慢点无所谓，甚至BT这样的满启动都可以。而请求小文件时，响应延迟就是一个难以忍受的问题了。这个问题不仅网络上有，操作系统里所有跟存取数据有关的地方都有，细到从CPU开始的一级级cache，粗到系统的readahead，都要考虑响应延迟和带宽哪个更重要。

> HTTP的流量中，一大半可能都是不能缓存的。只降低5%带宽显然不值得，还不如买带宽。从实施上来说，铺设光缆的成本低多了。国内带宽普遍很小不是因为成本太高运营商不铺，而是因为垄断。

既然不值得，小区宽带为什么还要做缓存？

缓存大文件还是能节省不少带宽的。例如优酷、sohu的视频都可以缓存。因为当带宽实在不够用时，在网关上是可以丢UDP的包的，需要的话丢多少都行。而TCP包就尽量不能丢，那么这就可以节省流量了。

> 所以小区宽带只缓存大文件。当然，它比较笨，所以一般简单的根据后缀来判断哪些文件该缓存，js/css等通常是不会缓存的，节省不了多少带宽。keep
> alive不都是好事，我在有些服务器上是把keep alive关掉的，在mirrors.ustc上，我设置的keep alive只有3s。
> 按我的理解，服务大文件时没必要用keep alive，短时间内对同一个客户端服务大量小文件才有意义。

keep alive对浏览器访问大量同源小文件来说也不是好事？是服务器的并发连接数太多的问题？

访问大量小文件是好事，但也需要浏览器的支持。例如你apt-get时，可能每个文件都是启动一个新的wget进程，那就不支持keep alive了。（没验证过，不知道apt-get是否用了keep alive，我只是随口举个例子，我只知道apt-get用了一个简化的wget，但不知道如何实现的。）

Cheng,

Best Regards

Bojie Li

unread,

Nov 27, 2012, 7:38:13 AM11/27/12

to USTC_LUG

你们学校是纯软件实现还是硬件实现的？大文件的过期时间是多长？如何判断“高频”的？

2012/11/27 Qijiang Fan <fqj...@gmail.com>:
> 我们学校做了这个事情。不过不做小文件的。只做高频（其实也不高）的大文件（至少几十兆字节的文件）。
>
> 在 2012年11月12日星期一UTC+8上午3时09分39秒，Bojie Li写道：

>>
>>
>> 网络流量的很大部分是一些热门静态资源，例如各大门户的图片、js、css等，比如双11期间电商网站的很多资源都被大量重复访问，给这些网站的CDN带来很大压力。HTTP头中有指定Cache-Control和Expires，据此可以判断资源是否静态及其有效期。但目前HTTP头只是对浏览器有效，学校一侧网络上并没有cache，流量全部被导到骨干网上了。我突发奇想，如果在学校出口上做个静态资源cache，就可以节省学校的出口流量。如果每个这种流量规模的网络区域都做个cache，就能降低骨干网的拥塞程度，节约网站的带宽。
>>
>>
>> 技术上如果大流量不方便阻塞处理的话，我觉得可以用类似GFW的方法，将内网请求分光到一台cache服务器，如果命中就伪装成外网IP向内网IP返回cache内容，并向外网IP发TCP的RST。由于内网延迟很低，几乎可以保证cache的返回先于外网服务器。这里存在几个问题：1、TCP三次握手的前两次没有有效载荷，到外网服务器的连接还是要建立。2、cache命中后发送RST，连接就断了，TCP建立连接是挺费资源的，keep-alive机制受影响；如果不发RST，后续的TCP序列号就乱了。
>>
>> 这是不是一个好主意？是否可以起到显著降低骨干网流量的效果？
>

> --
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
>
>
>

Qijiang Fan

unread,

Dec 8, 2012, 3:45:23 AM12/8/12

to ustc_lug

找到地址了
http://115.156.191.66/download/153835/158710/3/gz/5/147/1340793383429_403/latest_specs.4.8.gz
有谁可以试一试看能不能发现他用什么做的。
不过太奇葩了，rubygems的latest_specs.4.8.gz这种高频率变动的东西都被缓存了，但是各种发行版的iso却没有被缓存。

$ wget http://rubygems.org/latest_specs.4.8.gz
--2012-12-08 16:45:02-- http://rubygems.org/latest_specs.4.8.gz
Resolving rubygems.org (rubygems.org)... 204.232.149.25, 204.232.149.26
Connecting to rubygems.org (rubygems.org)|204.232.149.25|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://115.156.191.66/download/153835/158710/3/gz/5/147/1340793383429_403/latest_specs.4.8.gz
[following]
--2012-12-08 16:45:02--
http://115.156.191.66/download/153835/158710/3/gz/5/147/1340793383429_403/latest_specs.4.8.gz
Connecting to 115.156.191.66:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 343146 (335K) [application/octet-stream]
Saving to: `latest_specs.4.8.gz.1'

100%[====================================================================================>]
343,146 --.-K/s in 0.03s

2012-12-08 16:45:02 (10.0 MB/s) - `latest_specs.4.8.gz.1' saved [343146/343146]

在 2012年11月27日下午9:15，Qijiang Fan <fqj...@gmail.com> 写道：
> 不知道。我不是做这个的。我也不知道发生了什么，以前肯定会被重定向的文件现在没有了。。。。
>
>
> 在 2012年11月27日星期二UTC+8下午8时38分14秒，Bojie Li写道：

--
喵～～

Zhang Cheng

unread,

Dec 10, 2012, 4:42:40 AM12/10/12

to USTC LUG

这个从重定向的方式来看，跟小区宽带的缓存一样，劫持请求，给出302跳转。

2012/12/8 Qijiang Fan <fqj...@gmail.com>

找到地址了
http://115.156.191.66/download/153835/158710/3/gz/5/147/1340793383429_403/latest_specs.4.8.gz
有谁可以试一试看能不能发现他用什么做的。
不过太奇葩了，rubygems的latest_specs.4.8.gz这种高频率变动的东西都被缓存了，但是各种发行版的iso却没有被缓存。

$ wget http://rubygems.org/latest_specs.4.8.gz
--2012-12-08 16:45:02-- http://rubygems.org/latest_specs.4.8.gz
Resolving rubygems.org (rubygems.org)... 204.232.149.25, 204.232.149.26
Connecting to rubygems.org (rubygems.org)|204.232.149.25|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://115.156.191.66/download/153835/158710/3/gz/5/147/1340793383429_403/latest_specs.4.8.gz
[following]
--2012-12-08 16:45:02--
http://115.156.191.66/download/153835/158710/3/gz/5/147/1340793383429_403/latest_specs.4.8.gz
Connecting to 115.156.191.66:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 343146 (335K) [application/octet-stream]
Saving to: `latest_specs.4.8.gz.1'

100%[====================================================================================>]
343,146 --.-K/s in 0.03s

2012-12-08 16:45:02 (10.0 MB/s) - `latest_specs.4.8.gz.1' saved [343146/343146]

Cheng,

Best Regards

Reply all

Reply to author

Forward

0 new messages