有了初级教程的基础，相信大家已经能够做不少事情了。在本章，我们来深入一下，看看如何提高性能和网络传输效率。首先，需要介绍一下http 1.1（RFC2616）的基础知识。当然，如果你已经很熟悉了，可以跳过第一节。
一、HTTP 1.1的简要介绍 [TOP] HTTP 1.1是一个基于文本的互联网实体信息交互主流协议，这里的实体可以是WAP兼容浏览器之类的用户终端，可以是WAP网关之类的代理服务器，也可以是Java servlet之类的源服务器程序。它们之间的交互信息就是两大类：客户端对服务器端的请求（request）和服务器端对客户端的响应（response）。一次完整的交互包括一个请求和对它的响应。 所有的请求和响应都采用[RFC822]中定义的标准互联网消息格式，框架如下： * 消息定义 * 没有或多个消息头 * CRLF（空行回车） * 可选的消息本体 其中消息定义不分指定了发送消息的类型。请求和响应都可以包含多个消息头，用来进一步或者重新定义用户终端和服务器之间的交互。CRLF仅仅用来将信息定义和消息本体分开。 1、 请求 [TOP] 在消息定义部分可以这样定义请求： 请求类型 URL HTTP/1.1 其中请求类型可以是下面的一种： ①. OPTION：返回请求者和相应者之间可以使用的通信选项，主要用来检测服务器处理能力； ②. GET：获得以URL标示的文件内容或者程序执行结果。服务器根据文件名后缀判断服务内容，比如该URL是静态文本还是一个程序； ③. HEAD：除了不返回响应的信息本体以外，得到的是跟GET一样的信息。一般用来测试链接的有效性、可达性和近期修改； ④. POST：把消息本体中的消息发送到一个URL或者其他类似的服务器端定义行为。通常用来提交一个HTML表单或者一些数据操作活动； ⑤. PUT：把消息本体中的消息发送到一个URL，跟POST类似，但不常用； ⑥. DELETE：删除URL指定的资源； ⑦. TRACE：调用一个远程应用层请求消息回路。发出这个消息的用户终端除了收到原来的消息内容以外，还得到消息在Internet上的传送路径。 最常用的请求类型--也是我们在处理WAP应用时最关心的--是GET和POST。假设有一个WML文档，我们用UP的浏览器去浏览的话，就会向服务器发出如下GET请求： GET www.wap86.com/index.wml HTTP/1.1 accept-charset: UTF-8 accept-language: ch accept: text/vnd.wap.wml, */*, image/bmp, text/html user-agent: UP.Browser/3.1-UPG1 UP.Link/3.2 host: www.wap86.net …… 其中粗体的部分是HTTP消息头，这里我们忽略了一些与我们关系不大的消息头。 accept-charset: 用户终端支持的字符集 accept-language: 用户终端目前使用的语言 accept: 用户终端可以接受的MIME文件类型 user-agent: 用户终端供应商提供的终端描述信息 host: 请求信息发送到的域名 2、 响应 [TOP] 响应的消息定义部分一般是这样的：HTTP/1.1 状态码 状态描述 在[RFC2616]中定义了近40种不同的状态码（分成5组）。其中最常见的是3个： 200 OK 401 Unauthorized 404 Not Found 继续上面那个例子，如果该URL合法的话，服务器的响应会是这样的： HTTP/1.1 200 OK Server: www/5.0 Date: Fri, 26 Oct 2000 12:15:23 GMT Connection: Keep-Alive Content-Length: 1211 Content_Type: text/vnd.wap.wml Last-Modified: Mon, 22 Oct 2000 18:19:24 GMT <?xml version=”1.0”> <!<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” “http://www.wapforum.org/DTD/wml_1.1.xml”> …… 其它内容 …… 这个响应信息里包括了响应的数字代码和文本描述，然后是一组消息头。在一个换行符以后就是消息本体，在这里，消息本体就是www.wap86.net/index.wml的源代码。 Server: 发出响应的服务器 Date: 响应发出的时间 Connection: 指示用户终端保持连接 Content-Length: 响应信息的长度，从DECK的第一个"<"字符开始计算 Content_Type: 响应的MIME类型 Last-Modified: 响应中DECK的最后修改时间 当用户终端接收到响应以后，会对其状态信息和消息头进行解码，然后决定对响应做出什么样的动作。如果收到OK响应，一般会把消息本体里的内容显示在屏幕上。对于桌面终端，通常是HTML，对于WAP浏览器，则是WML。 HTTP是一种很罗嗦的协议。即使是简单没有任何数据的请求和响应都要产生数百字节的消息。WAP通过WAP网关来解决这个问题。WAP网关一个很重要的功能就是把所有的HTTP1.1消息转换成无线任务协议（Wireless Session Protocol, WSP）的消息格式。这种格式是压缩的二进制协议，兼容HTTP1.1。它能解析所有的请求和响应消息，并转换成最精简的BIT序列。 到这里我们已经介绍了HTTP1.1的主要内容。当然HTTP1.1还有很多复杂的内容，但是在这里并不打算多讲，如果你有兴趣，可以去相关网站查找它的资料。作者只想大家知道一点：用户终端和服务器之间还有比GET和POST请求更多的互动消息，它们一样有请求和响应消息头，并且可以包含一些信号来影响WAP应用程序的执行和性能。这正是提高WAP运行效率的秘密所在。 二、缓存（Caching） [TOP] 根据[RFC2616]的定义，缓存是："程序中响应消息的本地储存区以及控制这些消息储存、重新获取和删除的子系统。缓存保存可以缓存的响应消息以便降低将来的响应时间和网络带宽消耗，同样也适用于请求消息。" 由于WAP信道带宽的限制，我们在编写WAP应用的时候都希望最大限度地减少消息的传送量。要做到这一点，就要尽量地使用缓存，经常地从缓存中获得以前的消息。幸运的是目前大多数WAP设备都有一定级别的缓存，在默认情况下，会尝试最大化的缓存。几乎所有指向URL的响应都会被缓存下来。 当WAP用户终端缓存一个响应的时候，会保存几乎所有的信息：URL、响应文本、消息头以及其他可以验证响应的内容（参看下一节"验证和历史堆栈"）。每个被缓存的项目都可以根据它的URL组成部分（域名、路径、协议、参数、端口等等）唯一的识别。 有两种HTTP消息头可以让你控制WML的DECK缓存，对我们最重要的是Cache-Control消息头。它能够直接通过请求/响应链来控制所有的缓存实体。所有的缓存机制都必须遵守这些消息头的定义。Cach-Control消息头通常用来屏蔽一个设备的默认缓存行为。他们在消息链中传递时必须直接穿过所有的代理服务器和网关而不被改变。 * Cache-Control: no-cache。设定这个选项的URL不能被缓存，包括用户终端和所有处于内容服务器和用户终端之间的其他服务器； * Cache-Control: max-age=<second> * Expired:<date> 在写一个WAP应用的时候，你要先假设用户终端会尽量最大化缓存以便使向内容服务器获取信息的动作减少到最少。下面做些解释： 1、 永久缓存URL [TOP] 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的缓存时间 [TOP] 通常的情况是对一个URL你只需要缓存一段时间。比如股票报价系统，网页可能需要5分钟更新一次，那么你只要在DECK的HEAD部分指定Cache-Control: max-age=300就行了。 如果用户在5分钟以内再次检索该页面，看到的还是缓存里的网页。如果在5分钟以后，就会到服务器上获取最新的数据。 另外一种控制缓存时间的方法是使用前面提到过的Expires，不过这种方法只能告诉用户终端：只要过了指定时间，无论什么时候访问页面都要刷新。如果你下次要控制时间，只能改变Expires里的时间值。 3、 禁止对URL的缓存 [TOP] 对于快速变化的内容，一般都会希望每次都得到最新的数据。所以这个时候要完全禁止对相关网页的缓存。方法有三种： * 设定Cache-Control: no-cache； * 设定最大缓存时间为0，Cache-Control: max-age=0； * 设定缓存到期日为一个早就过去的日期，Expires: Mon, 1 Jan 1990 00:00:00 GMT。 实际上，后两种不是最好的选择。首先这样会多占用终端的处理时间，因为当碰到这个DECK时，终端需要计算一下过期时间。其次，这样会多占用一些字节，而且在表达上也不够清楚。 三、验证（validation）和历史堆栈（History Stack） [TOP] 在HTTP1.1中对缓存进一步提出了验证的概念。验证的目的就是检验缓存项目是否在有效期内。由于历史堆栈的存在，WAP终端上的验证过程变得有点复杂。 WAP标准规定所有的WAP设备都至少要有可以容纳10-个项目的历史堆栈。当用户按下由<go> 一般情况下，所有的前行链接都会被验证，而后退链接则不会，因为它已经在cache里了。可是我们有时候还是希望当用户按下后退键时依然能够得到最新的数据。如果终端总是不予验证的话，那用户只好找到主菜单再重新进入那个页面。 幸运的是，我们用Cache-Control：must-revalidate就可以强迫用户终端在用户按back时对URL进行验证。当然，进行验证并不是说该页面会立刻重新读取，而是根据他是否过期来决定。如果没有过期，验证的结果仍然是显示缓存中的页面。 如果你需要每次back都重新读取页面，用Cache-Control：must-revalidate, no-cache可以实现。另外，把 no-cache换成max-age=300就可以在back时对已缓存了300秒的页面进行刷新。 四、HTTP头与meta元素 [TOP] 到这里，大家已经知道HTTP消息头的在WAP页面的作用了。不过要在WML文档里设置这些消息头，就要用到meta元素，它只能出现在WML文档<head>段里。下面是几个消息头和它们的表示形式： Expires: Mon, 10 Jan 2000 00:00:00 GMT Cache-Control: max-age=300 Cache-Control: no-cache <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"/> 当网关在WML文档中扫描到元素时，就会把它们转换成WSP等效的HTTP消息头，然后用户终端就可以据此对缓存进行控制了。 |
||||||||||||||||||
