标签:图像 信息 das 英语 大量 判断 编码 代理商 属性
目前的内容协商技术主要有3种——客户端驱动协商、服务器驱动协商和透明协商(也就是中间代理商进行选择和判断)。
这三类大致归纳如下:
该种协商技术的基本原理和过程就是:客户端发起请求的时候,先请求一次服务器可以提供服务的列表,然后客户端选择一个最合适自己的版本进行请求。这种协商方式,服务器实现简单,而且客户端也能够寻找到最适合自己的版本,但是缺点也是显而易见。每次为了获取一份内容都需要发送两次请求。这样会给用户感觉请求速度很慢。
其中具体的实现原理上:
服务器有两种选择,
缺点:
除了添加时延并且对每个页面都要进行繁琐的多次请求之外,致命缺点:它需要多个URL---公共页面要一个,其他每种特殊页面也都要一个
这种协商技术,服务器需要依赖于客户端在请求中提供足够多的信息以便让服务器知道该返回什么版本的内容给客户端。这种协商技术相较于客户端驱动的协商,只需要一次请求即可,可以大大降低用户等待时间。但是主要技术点就在于客户端怎么给服务器提供足够多的可用于判断返回版本的信息。
Accept首部集
实体首部集像运输标签-----描述了把报文从服务器传输给给客户端的过程中必须的各种报文主体属性
内容协商首部集-----是由客户端发送给服务器用于交换偏好信息的
这种协商技术虽然减少了用户等待时间,提交了效率。但是有个需要解决的问题是:返回的版本不一定是客户端最适合的版本。比如:服务器端只有英文、中文两种语言的内容。但是客户端给到的Accept-Language中却是需要西班牙语,这个时候服务器可能就不知道应该返回哪个版本了。也行用户在中文和英文中对英文更加熟悉,那他就可能希望返回英文版本,也有可能对中文更加熟悉呢。这个时候服务器就需要客户端提供更多的信息,用于匹配更加合适的版本。在HTTP中提供了一个质量值用于描述偏好信息,如:
Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0
这里我们为每一种语言定义了一个q值。用于表示我们的偏好信息。其中q的取值范围为(0~1),数值越大,代表优先级越高,同时该值的对排列顺序并没有要求。比如上述例子中,nl优先级就要高于en。
透明协商的机制利用中间代理实现。假定代理了解了客户端的需要,可以代表客户端与服务器进行协商,并将协商后的内容进行缓存。下次客户端在获取的时候,就能直接提供需要的内容。但是在服务器这端,为了支持该特性,需要告知代理服务器需要进行哪些请求首部的检查,以便达到和客户端进行最佳匹配的目的。
HTTP/1.1规范中没有定义任何透明协商机制,但定义了Vary首部,服务器在响应中发送Vary首部,以告知中间节点需要使用哪些请求首部进行内容协商。如:
Vary: User-Agent, Cookie
这里的Vary字段说明,需要根据User-Agent和Cookie两个首部进行内容筛选匹配,最终确定出一份最合适的文档。
中间代理缓存为了实现上面的功能,就必须对同一份内容的不同形式进行缓存。比如同一份文档存在英语和法语两种语言,中间缓存的代理就需要更加客户端的需求缓存两份文档,以便满足不同客户端的需求。如果筛选标准在多一些,从不同的纬度进行判断,如上述的列子。这个时候缓存代理就需要缓存成倍的内容。所以这个也会消耗掉大量测存储空间。
我们前面讨论的都是假设服务器存在满足客户端需求的文档。然而,如果服务器没有能满足客户端需求的文档会怎么样呢?服务器可以给出一个错误响应。但理论上,服务器可以把现存的文档转换成某种客户端可用的文档。这种选项称为转码。常见的3种转码类型如下:
a)、格式转换
格式转换是指将数据从一种格式转换成另一种格式,使之可以被客户端查看。通过 HTML 到 WML 的转换,无线设备就可以访问通常供桌面客户端查看的文档了。通过慢速连接访问 Web 页面的客户端并不需要接收高分辨率图像,如果通过格式转换降低图像分辨率和颜色来减小图像文件大小的话,这类客户端就能更容易地查看图像比较丰富的页面了。
注:内容转换或转码-------可使访问设备能够查看内容
内容编码或传输编码------用于高效或安全地传输内容
b)、信息综合
从文档中提取关键的信息片段称为信息综合(information synthesis),这是一种有用的转码操作。这种操作的例子包括根据小节标题生成文档的大纲,或者从页面中删除广告和商标。
c)、内容注入
前面描述的两类转码通常会减少 Web 文档的内容,但还有另一类转换会增加文档的内容,即内容注入转码。内容注入转码的例子有自动广告生成器和用户追踪系统。
现在大多数的Web服务器,也是通过动态注入生成不同的页面,从而替代以前的单独保存各种不同版本的静态资源。
标签:图像 信息 das 英语 大量 判断 编码 代理商 属性
原文地址:https://www.cnblogs.com/liuzhiyun/p/11518684.html