最近遇到一个需求，即一个配置文件，由于这个文件的访问量非常大（8000次/秒），并且配置文件本身也比较大，所以需要
1.发布之后在5分钟之内生效
2.要能够cache，并尽量减少请求量和流量
对于以上的需求进行分析，首先否定掉放到CDN上，因为虽然第二点满足，但是第一点没法满足。
那么只能通过cgi读取配置文件返回内容来实现，具体方法如下：
1.发布之后5分钟生效
使用Etag，在这里即为配置文件的md5值，当来的请求的Etag值和服务器上的版本不一致时，才返回数据，并设置新的Etag；否则，返回304
2.能够cache
使用Cache-Control，来设定cache的时间
从而，使用Etag减少了流量，使用cache减少了请求量，并且同时兼顾了数据的更新时间可控。
示例代码如下：
返回304：
void CAppBaseConf::PrintHttp304()
{
std::string v = "HTTP/1.1 304 Not Modified\r\nServer: qzhttp\r\n";
printf("%s",v.c_str());
CCGIEx:: OutputHttpHeader();
return;
}
返回正常数据并设置Etag：
int CAppBaseConf::SetEtag(std::string &etag)
{
if(etag.size() <= 0)
return 0;
printf("Etag: %s\r\n",etag.c_str());
return 0;
}
服务器抓包截图如下：
304返回：
HTTP/1.1 304 Not Modified
Server: qzhttp
Content-Type: text/html; charset=utf-8
Connection: keep-alive
正常返回：
HTTP/1.1 200 OK
Server: QZHTTP-2.12
Date: Thu, 22 Jul 2010 10:24:15 GMT
UUID: 2872113653
Content-Length: 35
Etag: 2
Cache-Control: max-age=1800
Content-Type: text/html; charset=utf-8
Connection: keep-alive
_Callback(
{"ret":0,
"flag":"2"});
可以看出，确实是生效了。
夜弓 on #
你说到Etag是配置文件的md5值，其实不然，应该是HTTP消息的内容的md5值。区别在于后者对于gzip, deflate应该要算出一个不同的md5来。
Reply
Dante on #
这个，应该不是吧？
我是要保证客户端的配置和服务器上的一致即可，无需知道其http消息是怎样组合的～
Reply
夜弓 on #
呃，如果只是让它在www环境中工作，你这样就可以了，但是考虑兼容性其实不够。
比如说有人HEAD请求到了ETag没变就直接把本地的cache应用上了，但是两次的response是不一样的(走了gz和没走)。显然他这样处理是完全符合rfc，但他得到了错误的结果。
Reply
夜弓 on #
你可以看看wiki的说法，里面提到了有strong和weak两种
http://en.wikipedia.org/wiki/HTTP_ETag
Reply
Dante on #
哦哦，还有这样的问题，我仔细研究一下～～～多谢～～
Reply
iMadPer on #
发现最近的文章我都看不懂了....我还是踏踏实实的打我的酱油好了~
Reply
Dante on #
呵呵，因为工作性质，所以总会出现些和工作挂钩太严重的东西～
Reply
雨碎江南 on #
我还是抽时间学学C++吧...
Reply
Dante on #
呵呵，其实也不一定非得是C++，用php，python，只要是CGI都是可以这样模拟一下
Reply
想找兼职的设计师 on #
仔细看了看你的博客，觉得，还不错。如果有机会在外包领域合作。我很期待。
Reply
jim on #
Server: QZHTTP-2.12
楼主在tx工作？
Reply
Dante on #
哈，正是，既然知道qz，莫非兄台也在tx？
Reply