HTTP协议（http://www.w3.org/Protocols/）是“一次性单向”协议。
服务端不能主动连接客户端，只能被动等待并答复客户端请求。客户端连接服务端，发出一个HTTP Request，服务端处理请求，并且返回一个HTTP Response给客户端，本次HTTP Request-Response Cycle结束。
我们看到，HTTP协议本身并不能支持服务端保存客户端的状态信息。于是，Web Server中引入了session的概念，用来保存客户端的状态信息。
这里用一个形象的比喻来解释session的工作方式。假设Web Server是一个商场的存包处，HTTP Request是一个顾客，第一次来到存包处，管理员把顾客的物品存放在某一个柜子里面（这个柜子就相当于Session），然后把一个号码牌交给这个顾客，作为取包凭证（这个号码牌就是Session ID）。顾客（HTTP Request）下一次来的时候，就要把号码牌（Session ID）交给存包处（Web Server）的管理员。管理员根据号码牌（Session ID）找到相应的柜子（Session），根据顾客（HTTP Request）的请求，Web Server可以取出、更换、添加柜子（Session）中的物品，Web Server也可以让顾客（HTTP Request）的号码牌和号码牌对应的柜子（Session）失效。顾客（HTTP Request）的忘性很大，管理员在顾客回去的时候（HTTP Response）都要重新提醒顾客记住自己的号码牌（Session ID）。这样，顾客（HTTP Request）下次来的时候，就又带着号码牌回来了。
我们可以看到，Session ID实际上是在客户端和服务端之间通过HTTP Request和HTTP Response传来传去的。

我们看到，号码牌（Session ID）必须包含在HTTP Request里面。关于HTTP Request的具体格式，请参见HTTP协议（http://www.w3.org/Protocols/）。这里只做一个简单的介绍。
在Java Web Server（即Servlet/JSP Server）中，Session ID用jsessionid表示（请参见Servlet规范）。
HTTP Request一般由3部分组成：
（1）Request Line
这一行由HTTP Method（如GET或POST）、URL、和HTTP版本号组成。
例如，GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET http://www.google.com/search?q=Tomcat HTTP/1.1
POST http://www.google.com/search HTTP/1.1
GET http://www.somsite.com/menu.do;jsessionid=1001 HTTP/1.1

（2）Request Headers
这部分定义了一些重要的头部信息，如，浏览器的种类，语言，类型。Request Headers中还可以包括Cookie的定义。例如：
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Accept-Language: en-us
Cookie: jsessionid=1001

（3）Message Body
如果HTTP Method是GET，那么Message Body为空。
如果HTTP Method是POST，说明这个HTTP Request是submit一个HTML Form的结果，
那么Message Body为HTML Form里面定义的Input属性。例如，
user=guest
password=guest
jsessionid=1001
主意，如果把HTML Form元素的Method属性改为GET。那么，Message Body为空，所有的Input属性都会加在URL的后面。你在浏览器的URL地址栏中会看到这些属性，类似于
http://www.somesite/login.do?user=guest&password=guest&jsessionid=1001

从理论上来说，这3个部分（Request URL，Cookie Header, Message Body）都可以用来存放Session ID。由于Message Body方法必须需要一个包含Session ID的HTML Form，所以这种方法不通用。
一般用来实现Session的方法有两种：
（1）URL重写。
Web Server在返回Response的时候，检查页面中所有的URL，包括所有的连接，和HTML Form的Action属性，在这些URL后面加上“;jsessionid=XXX”。
下一次，用户访问这个页面中的URL。jsessionid就会传回到Web Server。
（2）Cookie。
如果客户端支持Cookie，Web Server在返回Response的时候，在Response的Header部分，加入一个“set-cookie: jsessionid=XXXX”header属性，把jsessionid放在Cookie里传到客户端。
客户端会把Cookie存放在本地文件里，下一次访问Web Server的时候，再把Cookie的信息放到HTTP Request的“Cookie”header属性里面，这样jsessionid就随着HTTP Request返回给Web Server。

我们来看Tomcat5的源代码如何支持jsessionid。
org.apache.coyote.tomcat5.CoyoteResponse类的toEncoded()方法支持URL重写。
String toEncoded(String url, String sessionId) {
…
StringBuffer sb = new StringBuffer(path);
if( sb.length() > 0 ) { // jsessionid can't be first.
sb.append(";jsessionid=");
sb.append(sessionId);
}
sb.append(anchor);
sb.append(query);
return (sb.toString());
}

我们来看org.apache.coyote.tomcat5.CoyoteRequest的两个方法configureSessionCookie()
doGetSession()用Cookie支持jsessionid.

/**
* Configures the given JSESSIONID cookie.
*
* @param cookie The JSESSIONID cookie to be configured
*/
protected void configureSessionCookie(Cookie cookie) {
…
}

HttpSession doGetSession(boolean create){
…
// Creating a new session cookie based on that session
if ((session != null) && (getContext() != null)
&& getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
session.getId());
configureSessionCookie(cookie);
((HttpServletResponse) response).addCookie(cookie);
}
…
}

Session的典型应用是存放用户的Login信息，如用户名，密码，权限角色等信息，应用程序（如Email服务、网上银行等系统）根据这些信息进行身份验证和权限验证

2、POST是被设计用来向上放东西的，而GET是被设计用来从服务器取东西的，GET也能够向服务器传送较少的数据，而Get之所以也能传送数据,只是用来设计告诉服务器,你到底需要什么样的数据.POST的信息作为HTTP 请求的内容，而GET是在HTTP 头部传输的；

3、POST与GET在HTTP 中传送的方式不同，GET的参数是在HTTP 的头部传送的，而Post的数据则是在HTTP 请求的内容里传送;

4、POST传输数据时，不需要在URL中显示出来，而GET方法要在URL中显示；

5、GET方法由于受到URL长度的限制,只能传递大约1024字节；POST传输的数据量大，可以达到2M，而根据微软方面的说法，微软对用 Request.Form() 可接收的最大数据有限制，IIS 4 中为 80 KB 字节，IIS 5 中为 100 KB 字节；

6、SOAP是依赖于HTTP POST模式实现的；

例子：

HTTP GET

发送

GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow.com

回复

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
  <Success>boolean</Success>
  <ErrorDescription>string</ErrorDescription>
  <ErrorNumber>int</ErrorNumber>
  <CustomerOrderReference>long</CustomerOrderReference>
  <OrderConfirmation>string</OrderConfirmation>
  <CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>

HTTP POST

发送

POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1
Host: api.efxnow.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length

UserID=string&PWD=string&OrderConfirmation=string

回复

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
  <Success>boolean</Success>
  <ErrorDescription>string</ErrorDescription>
  <ErrorNumber>int</ErrorNumber>
  <CustomerOrderReference>long</CustomerOrderReference>
  <OrderConfirmation>string</OrderConfirmation>
  <CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>

SOAP 1.2

发送

POST /DEMOWebServices2.8/Service.asmx HTTP/1.1
Host: api.efxnow.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <CancelOrder xmlns="https://api.efxnow.com/webservices2.3">
      <UserID>string</UserID>
      <PWD>string</PWD>
      <OrderConfirmation>string</OrderConfirmation>
    </CancelOrder>
  </soap12:Body>
</soap12:Envelope>

回复

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <CancelOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
      <CancelOrderResult>
        <Success>boolean</Success>
        <ErrorDescription>string</ErrorDescription>
        <ErrorNumber>int</ErrorNumber>
        <CustomerOrderReference>long</CustomerOrderReference>
        <OrderConfirmation>string</OrderConfirmation>
        <CustomerDealRef>string</CustomerDealRef>
      </CancelOrderResult>
    </CancelOrderResponse>
  </soap12:Body>
</soap12:Envelope>

HTTP请求包括三部分：请求行(Request Line)，头部（Headers）和数据体（Body)。其中，请求行由请求方法(method)，请求网址Request-URI和协议 (Protocol)构成，而请求头包括多个属性，数据体则可以被认为是附加在请求之后的文本或二进制文件。

下面这个例子显示了一个HTTP请求的Header内容，这些数据是真正以网络HTTP协议从IE浏览器传递到Apache服务器上的。

GET /icwork/? search=product HTTP/1.1

Accept:image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,application/vnd.ms-powerpoint,application/vnd.ms-excel,application/msword,*.*

Accept-Language:en-us

Accept-Encoding:gzip,deflate

User-Agent:Mozilla/4.0(compatible;MSIE 5.01;Windows NT 5.0;DigExt)

Host:www.icconcept.com:8080

Referer:http://www.yoursite.com/header.html

Connection:Keep-Alive

这段程序使用了6个Header，还有一些Header没有出现。我们参考这个例子具体解释HTTP请求格式。

1.HTTP请求行：请求行格式为Method Request-URI Protocol。在上面这个例子里，“GET /icwork/? search=pruduct HTTP/1.1”是请求行。

2.Accept:指浏览器或其他客户可以接爱的MIME文件格式。Servlet可以根据它判断并返回适当的文件格式。

3.Accept-Charset：指出浏览器可以接受的字符编码。英文浏览器的默认值是ISO-8859-1.

4.Accept-Language：指出浏览器可以接受的语言种类，如en或en-us，指英语。

5.Accept-Encoding：指出浏览器可以接受的编码方式。编码方式不同于文件格式，它是为了压缩文件并加速文件传递速度。浏览器在接收到Web响应之后先解码，然后再检查文件格式。

6.Authorization：当使用密码机制时用来标识浏览器。

7.Cache-Control：设置关于请求被代理服务器存储的相关选项。一般servlet用不到。

8.Connection：用来告诉服务器是否可以维持固定的HTTP连接。HTTP/1.1使用Keep-Alive为默认值，这样，当浏览器需要多个文件时(比如一个HTML文件和相关的图形文件)，不需要每次都建立连接。

9.Content-Type：用来表名request的内容类型。可以用HttpServletRequest的getContentType()方法取得。

10.Cookie：浏览器用这个属性向服务器发送Cookie。Cookie是在浏览器中寄存的小型数据体，它可以记载和服务器相关的用户信息，也可以用来实现会话功能。

11.Expect：表时客户预期的响应状态。

12.From：给出客户端HTTP请求负责人的email地址。

13.Host：对应网址URL中的Web名称和端口号。

14.If-Match：供PUT方法使用。

15.If-Modified-Since：客户使用这个属性表明它只需要在指定日期之后更改过的网页。因为浏览器可以使用其存储的文件而不必从服务器请求，这样节省了Web资源。由于Servlet是动态生成的网页，一般不需要使用这个属性。

16.If-None-Match：和If-Match相反的操作，供PUT方法使用。

17.If-Unmodified-Since：和If-Match-Since相反。

18.Pragma：这个属性只有一种值，即Pragma：no-cache,表明如果servlet充当代理服务器，即使其有已经存储的网页，也要将请求传递给目的服务器。

19.Proxy-Authorization：代理服务器使用这个属性，Servlet一般用不到。

20.Range：如果客户有部分网页，这个属性可以请求剩余部分。

21.Referer：表明产生请求的网页URL。如比从网页/icconcept/index.jsp中点击一个链接到网页/icwork/search，在向服务器发送的GET/icwork/search中的请求中，Referer是http://hostname:8080/icconcept/index.php。这个属性可以用来跟踪Web请求是从什么网站来的。

22.Upgrage：客户通过这个属性设定可以使用与HTTP/1.1不同的协议。

23.User-Agent：是客户浏览器名称。

24.Via：用来记录Web请求经过的代理服务器或Web通道。

25.Warning：用来由客户声明传递或存储(cache)错误。

HTTP(HyperText Transfer Protocol)是一套计算机通过网络进行通信的规则。计算机专家设计出HTTP，使HTTP客户（如Web浏览器）能够从HTTP服务器(Web服务器)请求信息和服务，HTTP目前协议的版本是1.1.HTTP是一种无状态的协议，无状态是指Web浏览器和Web服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后Web服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息.HTTP遵循请求(Request)/应答(Response)模型。Web浏览器向Web服务器发送请求，Web服务器处理请求并返回适当的应答。所有HTTP连接都被构造成一套请求和应答。

HTTP使用内容类型，是指Web服务器向Web浏览器返回的文件都有与之相关的类型。所有这些类型在MIME　Internet邮件协议上模型化，即Web服务器告诉Web浏览器该文件所具有的种类，是HTML文档、GIF格式图像、声音文件还是独立的应用程序。大多数Web浏览器都拥有一系列的可配置的辅助应用程序，它们告诉浏览器应该如何处理Web服务器发送过来的各种内容类型。

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：

（1）    建立TCP连接

在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80

（2）    Web浏览器向Web服务器发送请求命令

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令

例如：GET/sample/hello.jsp HTTP/1.1

（3）    Web浏览器发送请求头信息

浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

（4）    Web服务器应答

客户机向服务器发出请求后，服务器会客户机回送应答，

HTTP/1.1 200 OK

应答的第一部分是协议的版本号和应答状态码

（5）    Web服务器发送应答头信息

正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

（6）    Web服务器向浏览器发送数据

Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据

（7）    Web服务器关闭TCP连接

一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码

Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

HTTP请求格式

当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息，HTTP请求信息由3部分组成：

l   请求方法URI协议/版本

l   请求头(Request Header)

l   请求正文

下面是一个HTTP请求的例子：

GET/sample.jspHTTP/1.1

Accept:image/gif.image/jpeg,*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)

Accept-Encoding:gzip,deflate

username=jinqiao&password=1234

（1）       请求方法URI协议/版本

请求的第一行是“方法URL议/版本”：GET/sample.jsp HTTP/1.1

以上代码中“GET”代表请求方法，“/sample.jsp”表示URI，“HTTP/1.1代表协议和协议的版本。

根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1支持7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet应用中，最常用的方法是GET和POST。

URL完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本声明了通信过程中使用HTTP的版本。

（2）　请求头(Request Header)

请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。

Accept:image/gif.image/jpeg.*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)

Accept-Encoding:gzip,deflate.

（3）　请求正文

请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息：

username=jinqiao&password=1234

在以上的例子的HTTP请求中，请求的正文只有一行内容。当然，在实际应用中，HTTP请求正文可以包含更多的内容。

HTTP请求方法我这里只讨论GET方法与POST方法

GET方法

GET方法是默认的HTTP请求方法，我们日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向Web服务器发送，因此，如果使用GET方法来提交表单数据就存在着安全隐患上。例如

Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB

从上面的URL请求中，很容易就可以辩认出表单提交的内容。（？之后的内容）另外由于GET方法提交的数据是作为URL请求的一部分所以提交的数据量不能太大

POST方法

POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。POST方法克服了GET方法的一些缺点。通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。

从编程的角度来讲，如果用户通过GET方法提交数据，则数据存放在QUERY＿STRING环境变量中，而POST方法提交的数据则可以从标准输入流中获取。

HTTP应答与HTTP请求相似，HTTP响应也由3个部分构成，分别是：

l 　协议状态版本代码描述

l 　响应头(Response Header)

l 　响应正文

下面是一个HTTP响应的例子：

HTTP/1.1 200 OK

Server:Apache Tomcat/5.0.12

Date:Mon,6Oct2003 13:23:42 GMT

Content-Length:112

<html>
<head>

<title>HTTP响应示例<title>

</head>

<body>

Hello HTTP!

</body>

</html>

协议状态代码描述HTTP响应的第一行类似于HTTP请求的第一行，它表示通信所用的协议是HTTP1.1服务器已经成功的处理了客户端发出的请求（200表示成功）:

HTTP/1.1 200 OK
响应头(Response Header)响应头也和请求头一样包含许多有用的信息，例如服务器类型、日期时间、内容类型和长度等：

Server:Apache Tomcat/5.0.12

Date:Mon,6Oct2003 13:13:33 GMT

Content-Type:text/html

Last-Moified:Mon,6 Oct 2003 13:23:42 GMT

Content-Length:112

响应正文响应正文就是服务器返回的HTML页面：

<html>
<head>

<title>HTTP响应示例<title>

</head>

<body>

Hello HTTP!

</body>

</html>

响应头和正文之间也必须用空行分隔。　　

HTTP应答码

HTTP应答码也称为状态码，它反映了Web服务器处理HTTP请求状态。HTTP应答码由3位数字构成，其中首位数字定义了应答码的类型：

1XX－信息类(Information),表示收到Web浏览器请求，正在进一步的处理中

2XX－成功类（Successful）,表示用户请求被正确接收，理解和处理例如：200 OK

3XX-重定向类(Redirection),表示请求没有成功，客户必须采取进一步的动作。

4XX-客户端错误(Client Error)，表示客户端提交的请求有错误 例如：404 NOT  Found，意味着请求中所引用的文档不存在。

5XX-服务器错误(Server Error)表示服务器不能完成对请求的处理：如 500

对于我们Web开发人员来说掌握HTTP应答码有助于提高Web应用程序调试的效率和准确性。

安全连接

Web应用最常见的用途之一是电子商务，可以利用Web服务器端程序使人们能够网络购物，需要指出一点是，缺省情况下，通过Internet发送信息是不安全的，如果某人碰巧截获了你发给朋友的一则消息，他就能打开它，假想在里面有你的信用卡号码，这会有多么糟糕，幸运的是，很多Web服务器以及Web浏览器都有创立安全连接的能力，这样它们就可以安全的通信了。

通过Internet提供安全连接最常见的标准是安全套接层(Secure Sockets layer,SSl)协议。SSL协议是一个应用层协议(和HTTP一样)，用于安全方式在Web上交换数据，SSL使用公开密钥编码系统。从本质讲，这意味着业务中每一方都拥有一个公开的和一个私有的密钥。当一方使用另一方公开密钥进行编码时，只有拥有匹配密钥的人才能对其解码。简单来讲，公开密钥编码提供了一种用于在两方之间交换数据的安全方法，SSL连接建立之后，客户和服务器都交换公开密钥，并在进行业务联系之前进行验证，一旦双方的密钥都通过验证，就可以安全地交换数据。

一、介绍（introduction）

1. 目的——HTTP/0.9-〉HTTP/1.0-〉HTTP/1.1

2. 要求——MUST、REQUIRED、SHOULD

3. 术语——连接(Connection)、消息(Message)、请求(Request)、应答(Response)、资源(Resource)、实体(Entity)、表示方法(Representation)、内容协商(Content Negotiation)、变量（Variant)、客户机（Client）、用户代理(User agent)、服务器(Server)、原服务器（Origin server)、代理服务器（ Proxy）、网关（gateway）、高速缓存（Cache）、可缓存（Cacheable）、直接（first-hand）、明确终止时间（explicit expiration time）、探索终止时间（heuristic expiration time）、年龄（Age）、保鲜寿命（Freshness lifetime）、保鲜（Fresh）、陈旧（Stale）、语义透明（semantically transparent）、有效性判别器（Validator）、实体标记（entity tag）或最终更改时间（Last-Modified time))、上游/下游（upstream/downstream）、向内/向外（inbound/outbound）

4. 总体操作——请求/应答、中介

二、符号惯例与一般语法（notational conversions and generic grammar）

1. 扩充BNF——name = definition,"literal",rule1 | rule2,(rule1 rule2),*rule,[rule],N rule, #rule,; comment, implied *LWS

2. 基本规则——OCTET,CHAR,UPALPHA,LOALPHA,ALPHA,DIGIT,CTL,CR,LF,SP,HT,<">

三、协议参数（protocol parameters）

1. HTTP版本——HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

2. 统一资源标示符（URI）——统一资源定位器(URL)和统一资源名称(URN)的结合，http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

3. 日期/时间格式——Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123，
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036，
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

4. 字符集——本文档中的术语"字符集"指一种用一个或更多表格将一个八字节序列转换成一个字符序列的方法，
charset=token
失踪字符集

5. 内容编码——内容编码主要用来允许文档压缩（信源编码）
content-coding= token
注册表包含下列标记：gzip，compress，deflate，identity

6. 传输编码——目的是能够确保通过网络安全传输（信道编码）
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )，
成块传输代码

7. 媒体类型——media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
规范化和原文缺省
多部分类型

8. 产品标记——product = token ["/" product-version]
product-version = token

9. 质量值——qvalue = ( "0" [ "." 0*3DIGIT ] )| ( "1" [ "." 0*3("0") ] )

10. 语言标记——language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA

11. 实体标记——entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string

12. 范围单位——range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token

四、 HTTP消息（HTTP message）

1. 消息类型——HTTP-message = Request | Response ; HTTP/1.1 messages
generic-message = start-line *(message-header CRLF) CRLF [ message-body ]
start-line = Request-Line | Status-Line

2. 消息头——HTTP头域包括常规头,请求头,应答头和实体头域
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string>

3. 消息体——message-body = entity-body| <entity-body encoded as per Transfer-Encoding>

4. 消息的长度——决定因素

5. 常规头域——general-header = Cache-Control| Connection| Date| Pragma| Transfer-Encoding

五、 请求（request）

首行包括利用资源的方式,区分资源的标识,以及协议的版本号
Request = Request-Line * (( general-header| request-header| entity-header ) CRLF) CRLF [ message-body ]

1. 请求行——Request-Line = Method SP Request-URI SP HTTP-Version CRLF
方法——方法标记指的是在请求URI所指定的资源上所实现的方式
Method = "OPTIONS"| "GET"| "POST"| "PUT"| "DELETE"| "TRACE"| "CONNECT"| extension-method
extension-method = token
请求URL——请求URL是一种全球统一的应用于资源请求的资源标识符
Request-URI = "*" | absoluteURI | abs_path | authority
请求行举例：GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

2. 请求定义的资源——一个INTERNET请求所定义的精确资源由请求URL和主机报头域所决定

3. 请求报头域——request-header = Accept| Accept-Charset| Accept-Encoding| Accept-Language| Authorization| Expect| From| Host| If-Match| If-Modified-Since| If-None-Match| If-Range| If-Unmodified-Since| Max-Forwards| Proxy-Authorization| Range| Referer| TE| User-Agent

六、 应答（response）

接收和翻译一个请求信息后，服务器发出一个HTTP应答信息
Response = Status-Line*(( general-header| response-header| entity-header ) CRLF) CRLF [ message-body ]

1. 状态行——Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状态码——状态码是试图理解和满足请求的三位数字的整数码，1xx,2xx,3xx,4xx,5xx，100-〉505-〉扩展码

2. 应答报头域——response-header = Accept-Ranges| Age| Location| Proxy-Authenticate| Retry-After| Server| Vary| WWW-Authenticate

七、 实体（entity）

在未经特别规定的情况下，请求与应答的消息也可以传送实体。 实体包括实体报头域与实体正文，而有些应答只包括实体报头。

1. 实体报头域——entity-header = Allow | Content-Encoding| Content-Language| Content-Length | Content-Location| Content-MD5| Content-Range| Content-Type| Expires| Last-Modified| extension-header
extension-header = message-header

2. 实体正文——entity-body = *OCTET
entity-body := Content-Encoding( Content-Type( data ) )

八、 连接（connection）

1. 持续连接——优点
持续连接是任何HTTP连接的缺省方式，支持持续连接的客户机可以以流水线方式发送请求
代理服务器

2. 消息传递要求——持续连接与流量控制
监视连接中出错状态的消息
100号状态的用途
服务器过早关闭连接时客户机的动作

九、 方法定义（method definitions）

1. 安全和等幂方法
安全方法——GET和HEAD方法除了补救外不应该有别的采取措施的含义
等幂方法——没有副作用的序列是等幂的

2. OPTIONS——OPTIONS方法代表在请求URI确定的请求/应答过程中通信条件是否可行的信息

3. GET——GET方法说明了重建信息的内容由请求URI来确定

4. HEAD——除了应答中禁止返回消息正文外,HEAD方法与GET方法一样

5. POST——POST方法实现的实际功能取决于服务器

6. PUT——PUT方法要求所附实体存储在提供的请求URI下

7. DELETE——DELELE方法要求原服务器释放请求URI指向的资源

8. TRACE——TRACE方法用于调用远程的应用层循环请求消息

9. CONNECT——CONNECT方法用于能动态建立起隧道的代理服务器

十、 状态码定义（status code definitions）

1. 信息1XX——
100继续
101转换协议

2. 成功2XX——
200请求成功
201创建
202接受
203非权威信息
204无内容
205重置内容
206局部内容

3. 重新定向3XX——
300多样选择
301永久移动
302创立
303观察别的部分
304只读
306(没有用的)
307临时重发

4. 客户错误4xx——
400坏请求
401未授权的
402必需的支付
403禁用
404没有找到
405不被允许的方法
406不接受
407代理服务器认证所必需
408请求超时
409冲突
410停止
411必需的长度
412预处理失败
413请求实体太大
414请求的URI过长
415不被支持的媒体类型
416请求范围不满足
417期望失败

5. 服务器错误5xx——
500服务器内部错误
501不能实现
502坏网关
503难以获得的服务
504网关超时
505 HTTP版本不支持

十一、 访问验证（access authentication）——可选择

十二、 内容谈判（content negotiation）

HTTP为了"内容谈判"提供了一些机制，即当有很多种可能的表示时如何选择对于一个请求的最佳的表示。

1. 服务器驱动谈判——一个请求的最佳表示的选择由服务器提供的运算法则来完成

2. 代理驱动谈判——对于一个应答的最佳表示法的选择是在代理从原服务器端收到最初的应答后实现的

3. 透明谈判——透明的判断是服务器驱动和代理驱动谈判的结合体

十三、 HTTP中的缓存（caching in HTTP）

HTTP典型应用于能通过采用缓存技术而提高性能的分布式信息系统

1. 缓存——
缓存正确性
警告信息
缓存控制机制
直接的用户代理警告
规则和警告的例外情况
由客户控制的行为

2. 过期模型——
服务器指定模型
启发式过期
年龄计算
过期计算
澄清过期值
澄清多重响应

3. 确认模型——当缓存器想要用一个失时效的条目来相应客户的请求,他首先必须向源服务器检验这一缓存条目是否仍然可用
最后修改日期
标签缓存确认器
强弱控制器
关于何时使用实体标签和最后修改时间的规则
不确认条件

4. 响应的缓存能力——除非被明确限制,缓存系统可以将一成功的响应作为缓存实体一直存储

5. 从缓存构造响应——
端到端和Hop-by-hop报头
不可更改报头
联合报头
联合字节范围

6. 缓存谈判响应

7. 共享与非共享缓存

8. 错误和不完全响应缓存行为

9. GET和 HEAD的副作用

10. 刷新或删除后的无效性

11. 强制写通过

12. 缓存替换

13. 历史纪录

十四、 报头域定义（header field definitions）

1. Accept——Accept = "Accept" ":" #( media-range [ accept-params ] )
media-range = ( "*/*"| ( type "/" "*" )| ( type "/" subtype )) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
例1：Accept: audio/*; q=0.2, audio/basic
例2：Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

2. Accept-Charset——Accept-Charset = "Accept-Charset" ":" 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
例：Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

3. Accept-Encoding——Accept-Encoding = "Accept-Encoding" ":" 1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
例：Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

4. Accept-Language——Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
例：Accept-Language: da, en-gb;q=0.8, en;q=0.7

5. Accept-Range——Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
例：Accept-Ranges: bytes

6. Age——Age = "Age" ":" age-value
age-value = delta-seconds

7. Allow——Allow = "Allow" ":" #Method
例：Allow: GET, HEAD, PUT

8. Authorization——Authorization = "Authorization" ":" credentials

9. Cache-Control——Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive| cache-response-directive
cache-request-directive ="no-cache"| "no-store"| "max-age" "=" delta-seconds| "max-stale" [ "=" delta-seconds ]| "min-fresh" "=" delta-seconds| "no-transform"| "only-if-cached"| cache-extension
cache-response-directive ="public"| "private" [ "=" <"> 1#field-name <"> ]| "no-cache" [ "=" <"> 1#field-name <"> ]| "no-store"| "no-transform"| "must-revalidate"| "proxy-revalidate"| "max-age" "=" delta-seconds| "s-maxage" "=" delta-seconds| cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
什么是可缓存的
哪些可能被缓存保存
对基本过期失效机制的改进
缓存重新确认有效和重载控制
不得转换的指令
缓存控制扩展

10. Connection——Connection = "Connection" ":" 1#(connection-token)
connection-token = token
例：Connection: close

11. Content-Encoding——Content-Encoding = "Content-Encoding" ":" 1#content-coding
例：Content-Encoding: gzip

12. Content-Language——Content-Language = "Content-Language" ":" 1#language-tag
例：Content-Language: mi, en

13. Content-Length——Content-Length = "Content-Length" ":" 1*DIGIT
Content-Length: 3495

14. Content-Location——Content-Location = "Content-Location" ":"( absoluteURI | relativeURI )

15. Content-MD5——Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>

16. Content-Range——Content-Range = "Content-Range" ":" content-range-spec
content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/"( instance-length | "*" )
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | "*"
instance-length = 1*DIGIT
例：The first 500 bytes:bytes 0-499/1234

17. Content-Type——Content-Type = "Content-Type" ":" media-type
例：Content-Type: text/html; charset=ISO-8859-4

18. Date——Date = "Date" ":" HTTP-date
例：Date: Tue, 15 Nov 1994 08:12:31 GMT
没有时钟的原服务器的运作

19. Etag——ETag = "ETag" ":" entity-tag
例：ETag: W/"xyzzy"

20. Expect——Expect = "Expect" ":" 1#expectation
expectation = "100-continue" | expectation-extension
expectation-extension = token [ "=" ( token | quoted-string )*expect-params ]
expect-params = ";" token [ "=" ( token | quoted-string ) ]

21. Expires——Expires = "Expires" ":" HTTP-date
例：Expires: Thu, 01 Dec 1994 16:00:00 GMT

22. From——From = "From" ":" mailbox
例：From: webmaster@w3.org

23. Host——Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

24. If-Match——If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
例：If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"

25. If-Modified-Since——If-Modified-Since = "If-Modified-Since" ":" HTTP-date
例：If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

26. If-None-Match ——If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
例：If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"

27. If-Range ——If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

28. If-Unmodified-Since ——If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
例：If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

29. Last-Modified ——Last-Modified = "Last-Modified" ":" HTTP-date
例：Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

30. Location ——Location = "Location" ":" absoluteURI
Location: http://www.w3.org/pub/WWW/People.html

31. Max-Forwards ——Max-Forwards = "Max-Forwards" ":" 1*DIGIT

32. Pragma ——Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]

33. Proxy-Authenticate ——Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge

34. Proxy-Authorization ——Proxy-Authorization = "Proxy-Authorization" ":" credentials

35. Range——字节范围
范围检索请求
Range = "Range" ":" ranges-specifier

36. Referer——Referer = "Referer" ":" ( absoluteURI | relativeURI )

37. Retry-After ——Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )

38. Server ——Server = "Server" ":" 1*( product | comment )

39. TE ——TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
例：TE: trailers, deflate;q=0.5

40. Trailer ——Trailer = "Trailer" ":" 1#field-name

41. Transfer-Encoding ——Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
例：Transfer-Encoding: chunked

42. Upgrade——Upgrade = "Upgrade" ":" 1#product
例：Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

43. User-Agent ——User-Agent = "User-Agent" ":" 1*( product | comment )
例：User-Agent: CERN-LineMode/2.15 libwww/2.17b3

44. Vary ——Vary = "Vary" ":" ( "*" | 1#field-name )

45. Via ——Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
例：Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

46. Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text [SP warn-date]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
warn-text = quoted-string
warn-date = <"> HTTP-date <">

47. WWW-Authenticate ——WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

十五、 安全考虑（security considerations）

一些建议，但是并不包括最终解决方案

1. 个人信息
服务器日志信息的滥用
敏感信息的传输
URI中敏感信息的编码
连接到Accept报头的机要问题

2. 基于文件和路径名称的攻击

3. DNS欺骗

4. Location（位置）报头和欺骗

5. 内容倾向问题

6. 鉴定证书和空闲的客户机

7. 代理服务器和高速缓存
对代理服务器的拒绝服务攻击

十六、 感谢

十七、 参考文献

十八、 作者地址

十九、 附录

　　2、代理服务器负载均衡 使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。

　　3、地址转换网关负载均衡 支持负载均衡的地址转换网关，可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。

　　4、协议内部支持负载均衡 除了这三种负载均衡方式之外，有的协议内部支持与负载均衡相关的功能，例如HTTP协议中的重定向能力等，HTTP运行于TCP连接的最高层。

　　5、NAT负载均衡 NAT（Network Address Translation 网络地址转换）简单地说就是将一个IP地址转换为另一个IP地址，一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。

　　此种负载均衡是当前多WAN口路由器的带宽汇聚技术基础，以欣向路由器为例：

　　欣向的多WAN路由器实现的是业界先进的动态负载平衡机制，我们独立研发的多WAN口动态负载平衡技术，使得在使用多条线路的情况下动态分配内网的数据流量，动态的实现带宽汇聚的功能，采用特有的三种负载平衡机制：

　　a．Session：所有启用的WAN口，采用均分session的方式工作。

　　如第一个连接session通过WAN1口流出，则下一个session自动选择WAN2流出，第三个session选择WAN3口流出（假设所有WAN口都启用）

这种方式适用于多条相同带宽的线路捆绑时使用。

b．Round robin：同样是根据session数目调整负载，但比例可调。

　　如将比例设为1：2：3：4，则按如下规则处理：

　　第1个session选择WAN1口（session数=1）；

　　第2，3个 session选择WAN2口（session数=2）；

　　第4 ~ 6个 session 选择WAN3口（session数=3）；

　　第7 ~ 10个session选择WAN4口（session数=4）；

这种方式适用于多条不同带宽的线路能够更好的协同工作。例如：WAN1口接一条512K的ADSL，WAN2口接2M的光纤，这种情况下我们就可以把比例设为1：4，这样能够充分利用两条线路的带宽。

c．Traffic：按数据流量分配负载，系统自动选择流量最小的WAN口作为出口。

　　此种方式适用于线路不稳定时的多条线路混用的情况。在某一条线路暂时不通或者线路不稳定的情况下会把流量自动分配到另一条稳定的线路上。但在多条线路稳定的情况下不建议使用这种方式。

　　有了这三种负载平衡使得路由器可以灵活的应对多种线路混用的复杂情况，支持多种线路混接，支持多种协议，能够满足多种复杂应用。

　　6、反向代理负载均衡 普通代理方式是代理内部网络用户访问internet上服务器的连接请求，客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。

　　7、混合型负载均衡 在有些大型网络，由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异，我们可以考虑给每个服务器群采用最合适的负载均衡方式，然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务（即把这多个服务器群当做一个新的服务器群），从而达到最佳的性能。我们将这种方式称之为混合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。