首先谈谈遇到的问题:
一个Nginx架在一个后端服务的前面，Nginx proxy_pass到它并开启proxy_cache,假设这个后端服务总是会吐Etag响应头。
在应用中，我们发现当nginx 的proxy_cache成功将后端的页面cache住时,浏览器多次对该页面发起请求，会命中nginx的cache,但即使浏览器请求带了If-None-Match请求头，nginx却不会响应304，而是响应200.
这样带来的问题是，即使nginx的cache将请求阻挡在后端应用之外，但是:
（1）命中后每次响应200导致我们nginx所在的服务器和客户浏览器双方都有流量损耗
（2）更重要的是增长了我们的服务响应时间。因为，如果是304的话，nginx不需要向浏览器吐数据，只用告诉浏览器用本地的缓存就好了。
我们知道,Linux提供了多种进程间传递消息的方式，比如共享内存、套接字、管道、消息队列、信号等，每种方式都各有特点，各有优缺点。其中Nginx主要使用了其中的三种方式:
本文主要结合代码讲一下前两种方式，匿名套接字对和共享内存在Nginx中的使用。
首先简单的说一下Nginx中channel通信的机制。
Nginx中的channel通信，本质上是多个进程之间,利用匿名套接字(socketpair)对来进行通信。
我们知道,socketpair可以创建出一对套接字,在这两个套接字的任何一个上面进行写操作,在另一个套接字上就可以相应的进行读操作,而且这个管道是全双工的。
首先，必须声明，“进程间传递文件描述符”这个说法是错误的。
在处理文件时，内核空间和用户空间使用的主要对象是不同的。对用户程序来说，一个文件由一个文件描述符标识。该描述符是一个整数，在所有有关文件的操作中用作标识文件的参数。文件描述符是在打开文件时由内核分配，只在一个进程内部有效。两个不同进程可以使用同样的文件描述符，但二者并不指向同一个文件。基于同一个描述符来共享文件是不可能的。
《深入理解Linux内核架构》
这里说的“进程间传递文件描述符”是指，A进程打开文件fileA,获得文件描述符为fdA,现在A进程要通过某种方法，根据fdA,使得另一个进程B,获得一个新的文件描述符fdB,这个fdB在进程B中的作用，跟fdA在进程A中的作用一样。即在fdB上的操作,即是对fileA的操作。
3月15号上午8点开赛，现在是3月18号，想想还是写一篇文章记录一下吧，免得再拖就拖没了。
总体上说，比赛本身很顺利，一方面我不是很在乎具体成绩，能在关门前跑完就行；另一方面，我虽然报的是半马，但在平时的训练中，从来没有一次超过12km的，在这种情况下，能跑完且不受伤，就算是很顺利了。
但整个赛期安排略有坑爹。一方面，是清远首次举办马拉松比赛，经验不足，另一方面是我首次参加马拉松比赛，经验也不足。这一大一小两个菜鸟一碰撞，受苦的当然就是我这个小菜鸟了。
走的弯路主要有以下几点：
1)3月14号就到了清远，3月15号6点起床从住处往起点赶。因为马上要封路，路上并没有多少车往起点的方向去，我们心想这些完了，要走一个马拉松半程的距离了，时间恐怕不够了。不过幸运的是，半路上碰到一个出租车司机，他正好载着他的夫人和儿子往起点赶，于是愉快的坐了一趟顺风车。谢谢这位热情好客，助人为乐的清远的哥。
2)这次比赛从一开始到结束，雨就一直没停过。参赛前，觉得清远本来就是个山清水秀的地方，边跑步边欣赏美景是件很惬意的事情。可是由于天气的原因，全程能见度都只有几百米，跑的时候，有人说，这简直是在玩寂静岭啊。而且，由于下雨，开始大家都穿着雨衣跑。雨衣虽然能防水，但随着跑步的进行，体内的热气散发不出去，感觉又闷又燥，最后，跑到8千米的时候，我只好双手一把将雨衣潇洒的撕开，冒雨前进了。
我想百分之九十的可能，我是被髂胫束综合症给缠上了。
具体表现就是跑步距离过长时，膝盖外侧疼痛，当爬楼梯时尤其疼痛难忍。但在跑步过程中，很容易受到忽视，不就是有点疼吗，坚持坚持就行了，然后才发现这种疼痛是越来越剧烈的。
不过自从决定将跑步作为一项终身运动后，心里就已经做好了与伤病共舞的准备了。还记得去年冬天去北京出差，那天刚好是广州马拉松比赛，在飞机上，我旁边坐着一位刚跑完全程的北京小伙，虽然年轻，但已经跑过很多次全马了。一路上，他与另一位中年大叔交谈，那位大叔因为脚伤中途退赛了。我记得那小伙子安慰大叔的话，“对于我们跑者来说，受伤未尝不是一个好事，因为它让我们更加了解自己的身体。”
无论如何，是不会因为这个髂胫束综合症就放弃跑步的，因为自从去年秋天开始跑步以来，收获的东西太多了。