主要有两种比较重要的机制，在这里总结一下： 

一， 连接机制;

HTTP/1.1支持两种连接机制，一种是非持久连接，第二种是持久连接。基本上默认是使用持久连接，因为这样能够减少建立连接时候的网络延时与CPU消耗。其中服务器与客户端都会假定连接没有关闭，除非对方传来的头文件包含" Connection:close"，不然连接将继续保持。客户端，服务器与代理都可以随时结束连接，而他们也应该有一套机制去重新搭建起连接，并保持正确性。每个客户端也只能与一个服务器保持两条连接。代理也只能保持2N条连接，N 为代理的活跃用户数。对于连接的时候，由用户向服务器端发送一个带有"Expect"的信息到服务器端，服务器端如果连接正常则返回一个100 ( continue )的信息到客户端，提示客户端可以继续发送。

HTTP对于传输道路上的元素也有一定的要求。也规定了不透明代理可以改变哪些字段，而不能改变哪些字段。

二．缓存机制;

 HTTP中使用缓存主要有两个作用，一个是在很多情况下可以减少发送包，减少网络IO，使用“过期”机制来处理；第二个是可以减少发送整包的操作，减少带宽需求，使用“验证”机制来处理。

(1)“过期”机制(Expiration Model)，用于服务器端制定一个“过期时间”，主要有两种计算方式，按优先级顺序，第一种是年龄(Age)，第二种是过期时间(Expiration)。对于第一种，服务器会提供一个年龄字段（Age)与一个有效年龄(max-age)，而年龄的计算，则是采用服务器生成时的初始年龄再加上从服务器生成至缓存的时间。如果有Age 这个字段的存在，则说明这个消息不是第一手的，中间有缓存的存在。而要计算一个消息是否过期，则需要采用以下的方法：

if( max_age_value )

     Freshness_lifetime = max_age_value ;

Else

     Freshness_lifetime = expires_value - date_value ;

Response_is_fresh = ( freshness_lifetime > current_age ) ;

总体计算方法都比较直观与简单，而如果需要更新缓存的话，则可以加入以下字段：

Cache-Control : max-age = 0 ; OR Cache-Control : no-cache ;

(2)验证机制(Validation Model ) ,采用这种机制的时候，缓存先向服务器验证当前的缓存条目是否最新的，则收到304的提示表示 Not Modified，条目是最新的。否则则会收到服务器返回的新缓存条目。而进行验证的时候，可以使用两个标准，一个是使用服务器在原条目上的"Last-Modified"，使用条件GET(If-Modified-Since OR If-Not-Modified-Since)去查询。第二个是使用服务器为每个条目生成的"Entity Tag"，这个Tag如何生成完成由服务器去决定，因此也衍生出两种验证策略，一种是强验证，即如果一个条目发生了改变之后"Entity Tag"也马上变化的，第二种是使用弱验证，即条目变化了"Entity Tag"仍然保持不变，相对验证条件更弱。而对于是使用强验证还是弱验证则是取决于服务器端了。

This document lists all the message headers defined in the HTTP/1.1 protocol, with short descriptions. In the list, the name of the header is a link to its definition in the protocol itself. Note that some of the headers are also used in Internet E-mail and in Usenet; see Quick reference to Internet message headers.

The kind of the header is indicated as follows:

[Entity

Specifies which Internet media types are acceptable for the response and to assign preferences to them.

Accept-Charset [Request]

Specifies which character encodings (confusingly called "charsets") are acceptable for the response and to assign preferences to them.

Accept-Encoding [Request]

Specifies which data format tranformations, confusingly called content (en)codings, such as compression mechanisms, are acceptable for the response and to assign preferences to them.

Accept-Language [Request]

Specifies which natural languages are acceptable for the response and to assign preferences to them. Useful for language negotation.

Accept-Ranges [Response]

Indicates the server's acceptance of range requests for a resource.

Age [Response]

Gives the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server.

Allow [Entity]

Lists the set of methods supported by the resource identified by the Request-URI. The purpose is to inform the recipient of valid methods associated with the resource.

Authorization [Request]

Consists of credentials containing the authentication information of the client for the realm of the resource being requested

Cache-Control [General]

Specifies directives that must be obeyed by all caching mechanisms along the request/response chain.

Connection [General]

Specifies options that are desired for the particular connection and must not be communicated by proxies over further connections.

Content-Encoding [Entity]

Used as a modifier to the media-type, to indicate what additional data format transformations such as compression have been applied to the entity-body.

Content-Language [Entity]

Specifies the natural language(s) of the intended audience for the enclosed entity. But according to RFC 3282, specifies the language(s) of the entity.

Content-Length [Entity]

Indicates the size (in octets) of the entity-body that is sent or that would have been sent if it has reen requested.

Content-Location [Entity]

Supplies the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI.

Content-MD5 [Entity]

An MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.

Content-Range [Entity]

Sent with a partial entity-body to specify where in the full entity-body the partial body should be applied.

Content-Type [Entity]

Specifies the Internet media type of the entity-body that is sent or would have been sent if requested. Often includes a charset parameter specifying the character encoding.

Date [General]

Date and time at which the message was originated.

ETag [Response]

Provides the current value of the entity tag for the requested variant, forcaching purposes.

Expect [Request]

Indicates that particular server behaviors are required by the client.

Expires [Entity]

Gives the date/time after which the response is considered stale, forcaching purposes.

From [Request]

The Internet e-mail address for the human user who controls the requesting browser or other client.

Host [Request]

Specifies the Internet host and port number of the resource being requested. Obligatory in all HTTP/1.1 requests.

If-Match [Request]

Used with a method to make it conditional: a client that has previously obtained entities can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field.

If-Modified-Since [Request]

Used with a method to make it conditional: if the requested variant has not been modified since the time specified in this field, the server will not return the entity but information about this fact.

If-None-Match [Request]

Used with a method to make it conditional: a client that has previously obtained entities can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Matchheader field.

If-Range [Request]

Used together with Range to say: "if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity".

If-Unmodified-Since [Request]

Used with a method to make it conditional: if the requested variant has been modified since the time specified in this field, the server will not perform the requested operation but information about this fact.

Last-Modified [Entity]

Indicates the date and time at which the origin server believes the variant was last modified.

Location [Response]

Redirects the recipient to a location other than the Request-URI for completion of the request or identification of a new resource.

Max-Forwards [Request]

Provides a mechanism with the TRACE and OPTIONS methods to limit the number of proxies or gateways that can forward the request to the next inbound server.

Pragma [General]

Used to include implementation-specific directives that might (optionally) apply to any recipient along the request/response chain.

Proxy-Authenticate [Response]

Included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.

Proxy-Authorization [Request]

Used by a client to identify itself (or its user) to a proxy which requires authentication.

Range [Request]

Restricts the request to some part(s), specified as range(s) of octets, in the resource.

Referer [Request]

Used by a client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained.

Retry-After [Response]

Indicates how long the service is expected to be unavailable to the requesting client.

Server [Response]

Contains information about the software used by the origin server to handle the request.

TE [Request]

Indicates what extension transfer-codings the client is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding.

Trailer [General]

Indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding.

Transfer-Encoding [General]

Indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the Content-Encoding in that the transfer-coding is a property of the message, not of the entity.

Upgrade [General]

Used by a client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The server uses the Upgrade header to indicate which protocol(s) are being switched.

User-Agent [Request]

Contains information about the user agent (client) originating the request

Vary [Response]

Indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation.

Via [General]

Used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses.

Warning [General]

Carries additional information about the status or transformation of a message which might not be reflected in the message.

WWW-Authenticate [Response]

Used in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.下载本文