月度归档:2011年02月

情人节快乐

rose和老公一起过了3个情人节了。一大早到得公司,公司微博上到处都是情人节的祝福和收到礼物的同事晒的幸福。老公怕我不高兴,给我解释了两次今年没有鲜花。看在老公平日送鲜花的频率上,就不为难你了吧。

幸福不一定需要鲜花,同事在微博里面发了几个帖子,让我觉得很幸福:

一个人说看到女朋友全身上下没有一个饰品,答应 09 年买个大家伙给女朋友。 但是到过节的时候囊中羞涩,灵机一动,买了个游泳圈,就那年,教会了女朋友游泳。

有同事说上班的路上看到买菜的老头老太太,聊着今天是情人节,同事还调侃说老头可以送老太太一颗西兰花。 有同事想好了下班后给女朋友洗头发。

我给公公和婆婆发短信,提醒公公要送婆婆礼物,公公说会送给婆婆一个吻,哈哈,好年轻前卫的公公~

 

晚上和老公一起去吃饭,下班了看到到处都是捧着鲜花拦车的人们,公交车挤不上去,和老公步行回家找了一家店子吃饭。老公还是买了玫瑰花,哈哈,意料之外~

要为老公做的,一直没有告诉老公。到了晚上,老公说还有礼物要送,把我拉到房间坐下,让我猜是什么,心里想着会不会和我想的一样哦,就啪啦把鞋子甩一边,果然一样—老公要给我洗脚。哈哈, 怕痒的老公被我挠了好久的脚趾丫和脚板心~~

老公,不管你买不买礼物,只要你有心,我都会很开心的。我们约定平时的时候支持你的工作,你的学习和你的朋友;过节的时候我最大~

HTTP协议的过期模型和由过期时间想到的

HTTP为提高性能,减少网络传输的信息量,从而使用了缓存。
HTTP协议缓存的目标是去除许多情况下对于发送请求的的需求和去除许多情况下发送完整请求的需求。
在http协议中使用截止模型和证实模型来实现缓存。
【截止模型】
目的:减少操作的大量网络来回奔波,或者说减少http的请求数。
避免请求的主要机制是服务器提供明确的在将来截止的时间,表示响应可满足后续请求,即可以在不联系服务器而返回更新的响应。
在服务器指定了截止时间,在截止时间之前实体不会改变,此时需要慎重考虑截止时间。
实现方式:服务器可以使用Expires头部,也可以使用Cache-Control头部的max-age指令来指定明确的截止时间。
其中max-age指令的优先级高于Expires
【证实模型】
目的:减少网络带宽的损耗
这里的证实是指在在请求与应答中存在一些缓存的条目,这些条目在请求与应答中传递,判断是否过期,从而判断是否重传内容。
与截止模型相关,这里还有一次请求,只是如果缓存有效,则不会重传内容。
实现方式:Last-Modified实体头部域经常用于证实模型,如果实体在Last-Modified值以来没有修改过,则可以认为此缓存有效。
ETag头部域提供“不透明”的证实。
【由过期时间想到的】
近来看协议,看源码,过期时间或者超时总会频繁出现。
思考,为什么在这种大型的架构中,过期时间这样一个限制是如此频繁的出现。又或者我们在cookie或session中所看到的expire,缓存中的时间限制等等。这些都是我们经常可以遇到的。
如果我们把这些东西赋予生命,那么我们所设置的这些都是他们的生命终止的时候。
为了保证程序或信息流的生命的完整性,我们希望他们在出生后,只能存活这样一段时间,在我们可以控制的范围内自然的消散?
那对于内存的分配和新的垃圾收集机制,PHP中使用了引用计数,如果使用过期时间,在某个特定的时间内有效,又或者我们无法控制用户所定义的变量的生命周期,所以我们无法以过期时间来实现?
前面提到了session,PHP的session存储方案中,以文件存储为例,设置了过期时间。以文件的最后修改时间为准。
一次http请求,如果缓存 在客户端的内容还没有过期,则直接使用客户端的内容,这是http协议的一种过期模型。这是一个纯粹的以过期时间缓存的模型。不存在再次的交互。
在应用中提到过期,也许我们会看到缓存这个东西。缓存,以一种更快的介质或更短的距离取代较慢的介质或较长的传输距离的优化方式。
如果一个生命没有了完结的时候,它永生了,又当如何?守护进程,我们希望他会一直运行,那如何我们需要时时的中断这样的守护进程,如何管理?我们在做设计的时候如何处理?对于一个永不过期的缓存,如果我们需要将其清除掉,如何处理?清除这一个?以相同 的key重新设置?
以上的http协议的过期模型来自 RFC2616
后面是乱想的…
从年前开始,一直在和朋友一起写TIPI系统文章,而blog的更新也就放在一旁了。这里说明一下。

HTTP为提高性能,减少网络传输的信息量,从而使用了缓存。

HTTP协议缓存的目标是去除许多情况下对于发送请求的的需求和去除许多情况下发送完整请求的需求。

在http协议中使用截止模型和证实模型来实现缓存。

【截止模型】

目的:减少操作的大量网络来回奔波,或者说减少http的请求数。

避免请求的主要机制是服务器提供明确的在将来截止的时间,表示响应可满足后续请求,即可以在不联系服务器而返回更新的响应。

在服务器指定了截止时间,在截止时间之前实体不会改变,此时需要慎重考虑截止时间。

实现方式:服务器可以使用Expires头部,也可以使用Cache-Control头部的max-age指令来指定明确的截止时间。

其中max-age指令的优先级高于Expires

【证实模型】

目的:减少网络带宽的损耗

这里的证实是指在在请求与应答中存在一些缓存的条目,这些条目在请求与应答中传递,判断是否过期,从而判断是否重传内容。

与截止模型相关,这里还有一次请求,只是如果缓存有效,则不会重传内容。

实现方式:Last-Modified实体头部域经常用于证实模型,如果实体在Last-Modified值以来没有修改过,则可以认为此缓存有效。

ETag头部域提供“不透明”的证实。

【由过期时间想到的】

近来看协议,看源码,过期时间或者超时总会频繁出现。

思考,为什么在这种大型的架构中,过期时间这样一个限制是如此频繁的出现。又或者我们在cookie或session中所看到的expire,缓存中的时间限制等等。这些都是我们经常可以遇到的。

如果我们把这些东西赋予生命,那么我们所设置的这些都是他们的生命终止的时候。

为了保证程序或信息流的生命的完整性,我们希望他们在出生后,只能存活这样一段时间,在我们可以控制的范围内自然的消散?

那对于内存的分配和新的垃圾收集机制,PHP中使用了引用计数,如果使用过期时间,在某个特定的时间内有效,又或者我们无法控制用户所定义的变量的生命周期,所以我们无法以过期时间来实现?

前面提到了session,PHP的session存储方案中,以文件存储为例,设置了过期时间。以文件的最后修改时间为准。

一次http请求,如果缓存 在客户端的内容还没有过期,则直接使用客户端的内容,这是http协议的一种过期模型。这是一个纯粹的以过期时间缓存的模型。不存在再次的交互。

在应用中提到过期,也许我们会看到缓存这个东西。缓存,以一种更快的介质或更短的距离取代较慢的介质或较长的传输距离的优化方式。

如果一个生命没有了完结的时候,它永生了,又当如何?守护进程,我们希望他会一直运行,那如何我们需要时时的中断这样的守护进程,如何管理?我们在做设计的时候如何处理?对于一个永不过期的缓存,如果我们需要将其清除掉,如何处理?清除这一个?以相同 的key重新设置?

以上的http协议的过期模型来自 RFC2616

后面是乱想的…

从年前开始,一直在和朋友一起写TIPI系统文章…