超文本传输协议

超文本传输 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 --HTTP/1.1（RFC2616中文版）中13HTTP中的缓存HTTP典型应用于能通过采用缓存技术而提高性能的分布式信息系统。HTTP/1.1协议包括的许多使缓存尽可能的工作的元素。因为这些元素与协议的其他方面有着千丝万缕的联系，而且他们相互作用、影响，因此有必要单独的来介绍基本的缓存 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 。如果缓存不能改善性能，他将一无用处。HTTP/1.1中缓存的目的是为了在很多情况下减少发送请求,同时在许多情况下可以不需要发送完整响应。前者减少了网络回路（译注：一个请求会返回一个响应，请求响应这个过程就是一个回路）的数量；我们利用一个“过期（expiration）”机制来为此目的（见13.2节）。后者减少了网络应用的带宽；我们用“验证（validation）”机制来为此目的。对行为，可行性，和关闭的操作的要求放松了语义透明性的目的。HTTP/1.1协议允许服务器，缓存，和客户端能显示地降低透明性当在必要的时候。然而，因为不透明的操作能混淆非专业的用户，同时可能和某个服务器应用程序不兼容（例如订购商品），因此此协议透明性在下面情况下才能被放松要求：--只有在一个显示的协议层的请求时，透明性才能被客户端或源服务器放松--当出现一个对终端用户的显示的警告时，透明性才能被缓存或被客户端放松因此，HTTP/1.1协议提供这些重要的元素：1．提供完整语义透明的协议特征，当这些特征被通信的所有方需要时允许源服务器或用户代理显示的请求和控制不透明操作的协议特征允许缓存给这样的响应绑定警告信息的协议特征，这些响应不能保留请求的语义透明的近似一个基本的原则是客户端必须能够发现语义透明性的潜在的放松。注意：服务器，缓存，或者客户端的实现者可能会面对设计上的判断，而这些判断没有显示地在此规范里讨论。如果一个判断可能会影响语义透明性，那么实现者应该能维持语义透明性，除非一个仔细的完整的 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 能说明打破透明性的好处。缓存正确性（CacheCorrectness）一个正确的缓存必须能用最新的响应来响应请求，此响应当在下面的条件满足时才适合此请求（见13.2.5，13.2.6，和13.12）此缓存响应已被检测与假设通过源服务器重验证后源服务器返回的响应相等价。此缓存响应是足够保鲜（fresh）的（见13.2节）。缺省的情况下，这意味着此响应必须满足客户端，源服务器，和缓存的最严格的保鲜要求（见14.9节）；如果源服务器指定了保鲜寿命，这说明它是源服务器自己的保鲜要求。由于客户端和源服务器的最严格的保鲜要求，如果一个缓存的响应不是足够保鲜的，那么在仔细考虑的情况下，缓存可能仍然返回此缓存的响应通过合适的Warning头域（见13.1.5和14.46节），除非此响应被阻止（例如：通过”no-store”cache-directive，或者通过一个”no-cache”cache-request-directive；见14.9节）。此缓存响应是一个304（没有被改变），305（代理重定向），或错误（4xx或者5xx）响应消息。如果缓存不能同源服务器通信，那么一个正确的缓存应该用它缓存的响应去响应请求，如果此缓存的响应能正确的服务于请求；如果不能服务器于此请求，那么缓存必须能返回一个错误或警告指示存在通信失败。如果缓存从服务器端接收到一个响应（或者是一个完整的响应，或者一个304（没有被改变）的响应），此响应应该是正常情况下要发送到请求的客户端的，并且此响应并不是新鲜的，那么此缓存应该把此响应转发给请求客户端不需要添加一个新的Warning头域（但是没有移去已经存在的Warning头域）。缓存并不是简单的因为传输中响应变得陈旧而尝试去重验证响应；这可能会导致一个无限的循环。用户代理接收一个陈旧的没有Warning头域的响应应该提示用户一个警告信息。警告信息（Warnings）无论何时，缓存返回一个响应，此响应既不是第一手的（first-hand）也不是足够保鲜（在13.1.1节的条件2），那么缓存必须利用一个Warning常用头域来警告产生的效果。Warning头域和当前定义的警告在14.46节里描述。这些警告允许客户端去采取合适的动作。警告可能被用于其他的目的，和缓存相关的目的和其他的目的。警告和错误状态码的区别在于是否是真正的失败。警告被赋予三位数字warn-codes。第一个数字指明：警告是否必须或不必须从缓存项里删除，在一个成功的重验证之后。1xx警告描述了响应的保鲜或重验证状态信息，并且这些信息应该在一个成功的重验证之后删除。1XX警告码可能是由缓存产生的，当缓存验证一个缓存项时。此警告码不能被客户端产生。2xx警告描述了实体主体或实体头域的某些方面的信息，这些信息不能被重验证修改，并且这些信息不能在一个成功重验证之后被删除。见14.46节关于警告码的定义。HTTP/1.0缓存将缓存所有响应中的警告，并且不会删除第一类警告。穿过HTTP/1.0缓存响应中的警告会携带一个额外的warning-date域，这是为了防止将来的HTTP/1.1接收端信任一个错误的缓存警告。警告同样携带一个警告文本。此文本可能是任何合适的自然语义（可能基于客户端请求的Accept头域），同时包含一个可选择的关于何种字符集被使用的声明。多个警告可能会绑定一个响应（或者被源服务器或者被一个缓存发送的），这包括多个警告可以共用一个警告码。例如，服务器可能会以英语和法语提供相同的警告。当多个警告绑定一个响应时，有时候不可能把所有的警告都展示给客户。HTTP版本不能指定一个严格的优先值去决定警告的优先和顺序显示，但是可以探索一些方法。缓存控制机制（Cache-controlMechanism）HTTP/1.1基本的缓存机制（服务器指定过期时间和验证器）对缓存是隐含的指令。某些情况下，服务器或客户端可能需要给HTTP缓存提供显示的指令。我们利用Cache-ControI头域为此目的。Cache-ControI头域允许客户端或服务器在请求或响应里传输多个指令。这些指令常常覆盖缺省的缓存算法。作为一个常用规则，如果头域值中存在一个明显的冲突，那么最具严格解释的头域值会被应用（也就是说，能保留语义透明性的值）。然而，一些情况下，cache-controI指令被显示地指定用来削弱语义透明性的相似性（例如，”max-stale”或者“public”）。Cache-controI指令在14.9节被描述。显示的用户代理警告（ExplicitUserAgentWarnings）很多用户代理允许用户覆盖基本缓存机制。例如，用户代理可能允许用户指定缓存实体（即使实体明显是陈旧的）从来不要被验证。或者，用户代理可能习惯于给任何请求加上“Cache-Control:max-stale=3600”。用户代理不能缺省的执行不透明行为，或者不能缺省的执行导致非正常的无效率的缓存行为，但是可能被显示地设置去这样做通过一个显示的用户动作。如果用户已经覆盖基本的缓存机制，那么用户代理应该给用户指示何时显示不能满足服务器透明要求的信息（特别地，如果显示的实体被认为是陈旧的）。因为此协议通常允许用户代理去判定响应是否是陈旧或不是陈旧的，所以此指示只需要当实际发生时显示。此指示不必是对话框；它应该是一个图标（例如，一个正在腐烂的鱼）或者一些其他的指示器。如果用户以一种方式已经覆盖了缓存机制，这种方式可能不正常地减少缓存效率，那么用户代理应该继续指示用户的状态（例如，通过一个图片显示）以便用户不能不注意地消费过度的资源或者忍受过度的延迟。规则和警告的例外情况在某些情况下，缓存的操作者应该设置缓存返回陈旧的响应，即使此响应没有被客户端请求。这个判定本来不应该轻易决定，但是由于某些原因可能会这样做，特别是当缓存和源服务器连接不好时。无能何时当缓存会返回一个陈旧的响应时，缓存必须给此响应做个标记(利用Warning头域)，因为这样能使客户端提示用户响应是陈旧的。用户代理照样能采取步骤去获得第一手的或保鲜的响应。由于这个原因，如果客户端显示地请求第一手的或保鲜的响应，缓存就不能返回一个陈旧的响应，除非由于技术或策略方面的原因。由客户控制的行为(Client-controlledBehavior)当源服务器是过期信息得主要来源时，有时候客户端可能需要控制缓存去判定是否返回一个缓存响应而不需要缓存通过服务器验证它。客户端通过利用一些Cache-Control头域来达到此目的。客户端的请求可能会指定自己愿意接受一个没有验证的响应的最大的年龄(age)；指定0值会强迫缓存重验证所有的响应。客户端照样会指定在响应过期前的最小保持时间。这些选项增加了对缓存行为的限制，同时这样做并不能进一步地放松缓存语义透明的近似。客户端可能照样会指定它会接受陈旧响应直到陈旧数达到最大数量。这放松了对缓存的限制，同时这可能违反了源服务器指定对语义透明性的限制，但是这可能支持无连接的操作或者高获得性当连接不好时。13.2过期模型(ExpirationModel)13.2.1服务器指定模型(Server-SpecifiedExpiratiion)HTTP缓存会工作的很好，这是因为缓存能完全地避免客户端对源服务器的请求。避免对源服务器请求的主要机制是服务器将来会提供一个显示过期时间(explicitexpirationtime)此显示过期时间用来指示响应可能会满足后续的请求。也就是说，客户端请求响应时，缓存能返回一个保鲜(fresh)的响应而不需要从源服务器那里获得。我们希望服务器给响应设置显示过期时间(explicitexpirationtime)，服务器相信在过期时间之前实体不会改变。这能保持语义透明性(译注：语义透明性情况1.3节里关于“语义透明”的解释)，只要服务器对过期时间仔细选择。过期机制只能应用于能从缓存获得的响应，不能应用于客户端请求的第一手(first-hand，见1.3节术语)的响应。如果源服务器希望强制一个语义透明缓存去验证每个请求，它会使显示过期时间(explicitexpirationtime)设为过去。这就是说响应总是陈旧的，所以此缓存应该验证此响应当缓存利用此响应去服务于后续的请求时。见14.9.4节，有更多强迫重验证的方法如果源服务器希望强迫任何HTTP/1.1缓存(不管此缓存是怎样设置的)去验证每一个请求，源服务器应该在Cache-Control头域里指定“must-revalidate”缓存控制指令(见14.9节)。源服务器利用Expires头域或在Cache-Control头域里通过max-age缓存控制指令，来指定显示过期时间(explicitexpirationtime)。过期时间不能被用于强制客户代理去重新刷新它的显示或重载资源；过期的语义只能应用于