wap开发中如何有效的利用缓存减少消息的传送量
更新时间：2010年06月25日 17:43:30 作者：
由于WAP信道带宽的限制，我们在编写WAP应用的时候都希望最大限度地减少消息的传送量。
要做到这一点，就要尽量地使用缓存，经常地从缓存中获得以前的消息。幸运的是目前大多数WAP设备都有一定级别的缓存，在默认情况下，会尝试最大化的缓存。几乎所有指向URL的响应都会被缓存下来。
根据[RFC2616]的定义，缓存是："程序中响应消息的本地储存区以及控制这些消息储存、重新获取和删除的子系统。缓存保存可以缓存的响应消息以便降低将来的响应时间和网络带宽消耗，同样也适用于请求消息。"
当WAP用户终端缓存一个响应的时候，会保存几乎所有的信息：URL、响应文本、消息头以及其他可以验证响应的内容（参看下一节"验证和历史堆栈"）。每个被缓存的项目都可以根据它的URL组成部分（域名、路径、协议、参数、端口等等）唯一的识别。
有两种HTTP消息头可以让你控制WML的DECK缓存，对我们最重要的是Cache-Control消息头。它能够直接通过请求/响应链来控制所有的缓存实体。所有的缓存机制都必须遵守这些消息头的定义。Cach-Control消息头通常用来屏蔽一个设备的默认缓存行为。他们在消息链中传递时必须直接穿过所有的代理服务器和网关而不被改变。
<meta http-equive="Expires" content=" Mon, 10 Jan 2000 00:00:00 GMT"/>
<meta http-equive="Cache-Control" content="max-age=300"/>
<meta http-equive="Cache-Control" content="no-cache"/>
* Cache-Control: no-cache。设定这个选项的URL不能被缓存，包括用户终端和所有处于内容服务器和用户终端之间的其他服务器；
* Cache-Control: max-age=<second>。定义URL保存在设备缓存中的最长时间。时间到了以后，这个实体会从缓存中清除；
* Expired:<date> 。指定URL在缓存中存放的最后日期期限。[RFC1123]定义了日期的格式，通常是这样的：Expires: Sun, 29 October 2000 17:30:47 GMT
在写一个WAP应用的时候，你要先假设用户终端会尽量最大化缓存以便使向内容服务器获取信息的动作减少到最少。下面做些解释：
1、 永久缓存URL
WAP用户终端通常会尽量长地在它的缓存中保存存取过的URL，这个"尽量长"在Phone.com浏览器中的定义是大约30天。不过，也许你会想把一个URL的缓存时间尽量延长，比如你公司的LOGO，这样每次打开页面的时间就会减少。用下面两种方法能够很简单地实现：
* 指定一个离现在很远的过期日，比如：Expires: Tue, 01 Jan 2002 00:00:00 GMT；
* 指定一个很大的缓存时间，如：Cache-Control: max-age=3153600。这个例子可以让URL缓存一年。用户终端允许的最大整数是2,147,483,647，所以你可以让一个URL保存超过68年之久。当然，到那个时候，你的手机早就那报废了。
2、 指定对URL的缓存时间
通常的情况是对一个URL你只需要缓存一段时间。比如股票报价系统，网页可能需要5分钟更新一次，那么你只要在DECK的HEAD部分指定Cache-Control: max-age=300就行了。 如果用户在5分钟以内再次检索该页面，看到的还是缓存里的网页。如果在5分钟以后，就会到服务器上获取最新的数据。
另外一种控制缓存时间的方法是使用前面提到过的Expires，不过这种方法只能告诉用户终端：只要过了指定时间，无论什么时候访问页面都要刷新。如果你下次要控制时间，只能改变Expires里的时间值。
3、 禁止对URL的缓存
对于快速变化的内容，一般都会希望每次都得到最新的数据。所以这个时候要完全禁止对相关网页的缓存。方法有三种：
* 设定Cache-Control: no-cache；
* 设定最大缓存时间为0，Cache-Control: max-age=0；
* 设定缓存到期日为一个早就过去的日期，Expires: Mon, 1 Jan 1990 00:00:00 GMT。
实际上，后两种不是最好的选择。首先这样会多占用终端的处理时间，因为当碰到这个DECK时，终端需要计算一下过期时间。其次，这样会多占用一些字节，而且在表达上也不够清楚。
WAP标准规定所有的WAP设备都至少要有可以容纳10-个项目的历史堆栈。当用户按下由<go>或其他转向指令的定义的前行（forward）链接时，URL被推（push）入堆栈。如果按下由<prev>定义的后退（backward）链接，URL被弹（pop）出。
一般情况下，所有的前行链接都会被验证，而后退链接则不会，因为它已经在cache里了。可是我们有时候还是希望当用户按下后退键时依然能够得到最新的数据。如果终端总是不予验证的话，那用户只好找到主菜单再重新进入那个页面。
幸运的是，我们用Cache-Control：must-revalidate就可以强迫用户终端在用户按back时对URL进行验证。当然，进行验证并不是说该页面会立刻重新读取，而是根据他是否过期来决定。如果没有过期，验证的结果仍然是显示缓存中的页面。
如果你需要每次back都重新读取页面，用Cache-Control：must-revalidate, no-cache可以实现。另外，把 no-cache换成max-age=300就可以在back时对已缓存了300秒的页面进行刷新。
根据[RFC2616]的定义，缓存是："程序中响应消息的本地储存区以及控制这些消息储存、重新获取和删除的子系统。缓存保存可以缓存的响应消息以便降低将来的响应时间和网络带宽消耗，同样也适用于请求消息。"
当WAP用户终端缓存一个响应的时候，会保存几乎所有的信息：URL、响应文本、消息头以及其他可以验证响应的内容（参看下一节"验证和历史堆栈"）。每个被缓存的项目都可以根据它的URL组成部分（域名、路径、协议、参数、端口等等）唯一的识别。
有两种HTTP消息头可以让你控制WML的DECK缓存，对我们最重要的是Cache-Control消息头。它能够直接通过请求/响应链来控制所有的缓存实体。所有的缓存机制都必须遵守这些消息头的定义。Cach-Control消息头通常用来屏蔽一个设备的默认缓存行为。他们在消息链中传递时必须直接穿过所有的代理服务器和网关而不被改变。
<meta http-equive="Expires" content=" Mon, 10 Jan 2000 00:00:00 GMT"/>
<meta http-equive="Cache-Control" content="max-age=300"/>
<meta http-equive="Cache-Control" content="no-cache"/>
* Cache-Control: no-cache。设定这个选项的URL不能被缓存，包括用户终端和所有处于内容服务器和用户终端之间的其他服务器；
* Cache-Control: max-age=<second>。定义URL保存在设备缓存中的最长时间。时间到了以后，这个实体会从缓存中清除；
* Expired:<date> 。指定URL在缓存中存放的最后日期期限。[RFC1123]定义了日期的格式，通常是这样的：Expires: Sun, 29 October 2000 17:30:47 GMT
在写一个WAP应用的时候，你要先假设用户终端会尽量最大化缓存以便使向内容服务器获取信息的动作减少到最少。下面做些解释：
1、 永久缓存URL
WAP用户终端通常会尽量长地在它的缓存中保存存取过的URL，这个"尽量长"在Phone.com浏览器中的定义是大约30天。不过，也许你会想把一个URL的缓存时间尽量延长，比如你公司的LOGO，这样每次打开页面的时间就会减少。用下面两种方法能够很简单地实现：
* 指定一个离现在很远的过期日，比如：Expires: Tue, 01 Jan 2002 00:00:00 GMT；
* 指定一个很大的缓存时间，如：Cache-Control: max-age=3153600。这个例子可以让URL缓存一年。用户终端允许的最大整数是2,147,483,647，所以你可以让一个URL保存超过68年之久。当然，到那个时候，你的手机早就那报废了。
2、 指定对URL的缓存时间
通常的情况是对一个URL你只需要缓存一段时间。比如股票报价系统，网页可能需要5分钟更新一次，那么你只要在DECK的HEAD部分指定Cache-Control: max-age=300就行了。 如果用户在5分钟以内再次检索该页面，看到的还是缓存里的网页。如果在5分钟以后，就会到服务器上获取最新的数据。
另外一种控制缓存时间的方法是使用前面提到过的Expires，不过这种方法只能告诉用户终端：只要过了指定时间，无论什么时候访问页面都要刷新。如果你下次要控制时间，只能改变Expires里的时间值。
3、 禁止对URL的缓存
对于快速变化的内容，一般都会希望每次都得到最新的数据。所以这个时候要完全禁止对相关网页的缓存。方法有三种：
* 设定Cache-Control: no-cache；
* 设定最大缓存时间为0，Cache-Control: max-age=0；
* 设定缓存到期日为一个早就过去的日期，Expires: Mon, 1 Jan 1990 00:00:00 GMT。
实际上，后两种不是最好的选择。首先这样会多占用终端的处理时间，因为当碰到这个DECK时，终端需要计算一下过期时间。其次，这样会多占用一些字节，而且在表达上也不够清楚。
WAP标准规定所有的WAP设备都至少要有可以容纳10-个项目的历史堆栈。当用户按下由<go>或其他转向指令的定义的前行（forward）链接时，URL被推（push）入堆栈。如果按下由<prev>定义的后退（backward）链接，URL被弹（pop）出。
一般情况下，所有的前行链接都会被验证，而后退链接则不会，因为它已经在cache里了。可是我们有时候还是希望当用户按下后退键时依然能够得到最新的数据。如果终端总是不予验证的话，那用户只好找到主菜单再重新进入那个页面。
幸运的是，我们用Cache-Control：must-revalidate就可以强迫用户终端在用户按back时对URL进行验证。当然，进行验证并不是说该页面会立刻重新读取，而是根据他是否过期来决定。如果没有过期，验证的结果仍然是显示缓存中的页面。
如果你需要每次back都重新读取页面，用Cache-Control：must-revalidate, no-cache可以实现。另外，把 no-cache换成max-age=300就可以在back时对已缓存了300秒的页面进行刷新。
相关文章
油猴脚本（Tampermonkey）是一个非常流行的浏览器扩展，它可以运行由广大社区编写的扩展脚本，来实现各式各样的功能，常见的去广告、修改样式文件、甚至是下载视频，今天给大家介绍油猴脚本编写教程，感兴趣的朋友一起看看吧2020-02-02
chatGPT使用及注册过程中常见的一些错误解决方法(所有报错汇总)
这篇文章主要介绍了chatGPT注册报错及使用过程中报错汇总及解决方法,本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下2023-02-02
这篇文章主要介绍了git通过内网代理，访问外网的相关配置,配置git代理以http代理为例，给大家详细讲解，需要的朋友可以参考下2023-05-05
这篇文章主要为大家介绍了防止删库跑路及高级代码投毒技巧详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2022-07-07
这篇文章主要介绍了git基本操作和指令的相关知识，本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友参考下吧2020-11-11
这篇文章主要介绍了idea git拉取代码特别慢的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2024-07-07
这篇文章主要介绍了关于HTTPS的加密流程详解,http是为了解决http存在的问题而在http基础上加入了SSL/TSL，在HTTP/2中TCP三次握手后会进入SSL/TSL握手，当SSL/TSL建立链接后，才会进行报文的传输,需要的朋友可以参考下2023-07-07
这篇文章主要为大家介绍了怎样写commit log记录以及及如何提交有哪些约定，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2022-06-06
这篇文章主要为大家介绍了基于角色的权限控制模型RBAC的图文教程，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步早日升职加薪2022-03-03
越是复杂的东西越能体现我们码农的核心竞争力,既然要学习图，得要遵守一下图的游戏规则2013-11-11
最新评论