Web前端开发培训第一讲：Http协议讲义完整版

Web前端培训第一讲：HTTP协议讲义完整版

目录

0. 预备知识 (1)

0.1 OSI层次模型与TCP/IP协议栈 (1)

0.2 IP地址 (2)

0.3 TCP/IP通信方式 (2)

1. HTTP协议通信过程 (2)

1.1 URL自动解析 (2)

1.2 获取IP，建立TCP连接 (3)

1.3客户端浏览器向服务器发出HTTP请求 (3)

1.4 Web服务器应答，并向浏览器发送数据 (3)

1.5 Web服务器关闭TCP连接 (3)

2. HTTP协议之URL (4)

2.1 HTTP协议概述 (4)

2.2 HTTP之URL (4)

2.3 URL编码 (5)

3. HTTP协议之请求 (8)

3.1 HTTP请求的结构 (8)

4. HTTP协议之响应 (9)

5. HTTP协议之消息报头 (10)

5.1 普通报头 (10)

5.2 请求报头 (11)

5.3 响应报头 (12)

5.4 实体报头 (13)

6. 需要提前了解的工具HttpAnalyzer (14)

7. 核心参考资料 (14)

0.预备知识

0.1OSI层次模型与TCP/IP协议栈

CCNA视频教程：https://www.360docs.net/doc/5c14016081.html,/playlist_show/id_767428.html

重点学习第二讲OSI层次参考模型与第三讲TCP/IP协议栈。

0.2IP地址

Windows Server 2003从入门到精通系列之：TCP/IP协议基础。

0.3 TCP/IP通信方式

●按Client和Server的连接数量分类

1)一个Client方连接一个Server方，或称点对点(peer to peer)。

2)多个Client方连接一个Server方，这也是通常的并发服务器方式。

3)一个Client方连接多个Server方，这种方式很少见。

●按连接方式分类

1)长连接

Client方与Server方先建立通讯连接，然后再进行报文发送和接收，在通信过程中连接不断开。

2)短连接

Client方与Server每进行一次报文收发交易时才进行通讯连接，通讯完毕后立即断开连接。

●按发送接收方式分类

1)异步

报文发送和接收是分开的，相互独立的，互不影响。这种方式又分两种情况：

(1)异步双工：接收和发送在同一个程序中，有两个不同的子进程分别负责发送和接收

(2)异步单工：接收和发送是用两个不同的程序来完成。

2)同步

报文发送和接收是同步进行，既报文发送后等待接收返回报文。

1.HTTP协议通信过程

当我们在浏览器的地址栏输入“https://www.360docs.net/doc/5c14016081.html,”然后按回车，这之后发生了什么事，我们直接看到的是打开了对应的网页，那么内部客户端和服务端是如何通信的呢？

1.1 URL自动解析

HTTP URL包含了用于查找某个资源的足够信息，基本格式如下：HTTP://host[“:”port][abs_path]，其中HTTP表示桶盖HTTP协议来定位网络资源；host表示合法的主机域名或IP地址，port指定一个端口号，缺省80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

例如：输入https://www.360docs.net/doc/5c14016081.html,;浏览器会自动转换成：https://www.360docs.net/doc/5c14016081.html,/

1.2 获取IP，建立TCP连接

浏览器地址栏中输入"https://www.360docs.net/doc/5c14016081.html,/"并提交之后，首先它会在DNS本地缓存表中查找注1，如果有则直接告诉IP地址。如果没有则要求网关DNS进行查找，如此下去，找到对应的IP后，则返回会给浏览器。

当获取IP之后，就开始与所请求的Tcp建立三次握手连接，连接建立后，就向服务器发出HTTP请求。

注1：在Windows操作系统环境下，解析域名的过程有很多步骤，详细内容可以参Windows Server 2003从入门到精通系列之：DNS协议基础。

1.3客户端浏览器向服务器发出HTTP请求

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令，接着以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

1.4 Web服务器应答，并向浏览器发送数据

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

HTTP/1.1 200 OK

应答的第一部分是协议的版本号和应答状态码，正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

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

1.5 Web服务器关闭TCP连接

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

Connection:keep-alive

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

注2：关闭连接也可以由客户端来要求。

2.HTTP协议之URL

2.1 HTTP协议概述

http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

关键词：请求与相应模式、无状态的、常基于TCP的应用程协议、持续连接的机制。

请求与相应模式：客户端发出一个请求，服务器给出一个应答。

无状态的：指http协议本身不会在多次请求间保持状态。

常基于TCP的应用程协议：TCP/IP是事实上的网络通信工业标准，但并不是唯一，因此是“常”。

持续连接的机制注3：指的是Http1.1版本，通信方式已经可以为“长连接”。

注3：http协议中规定了一个特殊规则：浏览器对一个服务器不能同时打开两个以上的连接(IP+Port)。这个规则应该是为了保护服务器不会很容易被洪水攻击。主流浏览器包括IE都实现了这个规则。

DEMO:用IE下载一个网站的文件，只能同时打开2个，第三个就需要等待。

附注：这个规定是对IE而言是精确到域名而不是IP。

相关内容的详细说明：

HTTP协议1.1中文版：

https://www.360docs.net/doc/5c14016081.html,/Class/HTTP/0772522080738754597.html

请查看8.1.4节最后的说明。

其中节选：

另外：Iframe与DIV+ajax实现方式效果差别。

我们知道ERP和桌面部件大多数都是使用IFrame加载的。那么它的缺陷非常的明显，因为iframe指定src的方式，默认是使用“同步长连接”。因此当iframe的数量多了之后，连接数就会超过2，因此后面的请求必须等待。如果加载的iframe服务端处理时间过长，则整个客户端的浏览器一直被阻塞住。

而DIV+ajax的方式则不同。Ajax发出的请求最后都由ajax Engine发出，即连接由ajaxEngine 管理（发送和接收数据）。因此，DIV+ajax异步请求不会出现IE页面阻塞现象。

2.2 HTTP之URL

HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：http://host[":"port][abs_path]

http表示要通过HTTP协议来定位网络资源；

●host表示合法的Internet主机域名或者IP地址；

●port指定一个端口号，为空则使用缺省端口80；

●abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI

时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

DEMO：输入：https://www.360docs.net/doc/5c14016081.html,，浏览器自动转换成：https://www.360docs.net/doc/5c14016081.html, /

2.3URL编码

foo://https://www.360docs.net/doc/5c14016081.html,:8042/over/there?name=ferret#nose

\_/ \______________/ \________/\_________/ \__/

| | | | |

scheme authority path query fragment

URI是统一资源标识的意思，通常我们所说的Url只是URI的一种。典型Url的格式如上面所示。Url编码，实际上指的是URI编码。

2.3.1 为什么需要Url编码

通常如果一样东西需要编码，说明这样东西并不适合传输。对于Url来说，之所以要进行编码，是因为Url中有些字符会引起歧义。

DEMO:Url参数字符串中使用key=value键值对这样的形式来传参，键值对之间以&符号分隔，如/s?q=abc&ie=utf-8。如果你的value字符串中包含了=或者&，那么势必会造成接收Url的服务器解析错误，因此必须将引起歧义的&和=符号进行转义，也就是对其进行编码。

Url编码的原则就是使用安全的字符（没有特殊用途或者特殊意义的可打印字符）去表示那些不安全的字符。

2.3.2哪些字符需要编码

RFC3986文档规定，Url中只允许包含英文字母（a-zA-Z）、数字（0-9）、-_.~4个特殊字符以及所有保留字符。

RFC3986文档对Url的编解码问题做出了详细的建议，指出了哪些字符需要被编码才不会引起Url语义的转变，以及对为什么这些字符需要编码做出了相应的解释。

2.3.3 US-ASCII字符集中没有对应的可打印字符

Url中只允许使用可打印字符。US-ASCII码中的10-7F字节全都表示控制字符，这些字符都不能直接出现在Url中。同时，对于80-FF字节（ISO-8859-1），由于已经超出了US-ACII 定义的字节范围，因此也不可以放在Url中。

2.3.4 保留字符

Url可以划分成若干个组件，协议、主机、路径等。有一些字符（:/?#[]@）是用作分隔不同组件的。

DEMO：冒号用于分隔协议和主机，/用于分隔主机和路径，?用于分隔路径和查询参数，等等。还有一些字符（!$&'()*+,;=）用于在每个组件中起到分隔作用的，如=用于表示查询参数中的键值对，&符号用于分隔查询多个键值对。当组件中的普通数据包含这些特殊字符时，需要对其进行编码。

RFC3986中指定了以下字符为保留字符：

2.3.5 不安全字符

还有一些字符，当他们直接放在Url中的时候，可能会引起解析程序的歧义。这些字符被视为不安全字符，原因有很多。

●空格：Url在传输的过程，或者用户在排版的过程，或者文本处理程序在处理Url的过

程，都有可能引入无关紧要的空格，或者将那些有意义的空格给去掉

●引号以及<>：引号和尖括号通常用于在普通文本中起到分隔Url的作用

●# ：通常用于表示书签或者锚点

●% ：百分号本身用作对不安全字符进行编码时使用的特殊字符，因此本身需要编码

●{}|\^[]`~：某一些网关或者传输代理会篡改这些字符

需要注意的是，对于Url中的合法字符，编码和不编码是等价的，但是对于上面提到的这些字符，如果不经过编码，那么它们有可能会造成Url语义的不同。因此对于Url而言，只有普通英文字符和数字，特殊字符$-_.+!*'()还有保留字符，才能出现在未经编码的Url之中。其他字符均需要经过编码之后才能出现在Url中。

但是由于历史原因，目前尚存在一些不标准的编码实现。例如对于~符号，虽然RFC3986文档规定，对于波浪符号~，不需要进行Url编码，但是还是有很多老的网关或者传输代理会

2.3.6 如何对Url中的非法字符进行编码

Url编码通常也被称为百分号编码（Url Encoding，also known as percent-encoding），是因为它的编码方式非常简单，使用%百分号加上两位的字符——0123456789ABCDEF——代表一个字节的十六进制形式。Url编码默认使用的字符集是US-ASCII。例如a在US-ASCII码中对应的字节是0x61，那么Url编码之后得到的就是%61，我们在地址栏上输入https://www.360docs.net/doc/5c14016081.html,/search?q=%61%62%63，实际上就等同于在google上搜索abc了。又如@符号在ASCII字符集中对应的字节为0x40，经过Url编码之后得到的是%40。

常见字符的

1)对于非ASCII字符，需要使用ASCII字符集的超集进行编码得到相应的字节，然后对每

个字节执行百分号编码。对于Unicode字符，RFC文档建议使用utf-8对其进行编码得到相应的字节，然后对每个字节执行百分号编码。如“中文”使用UTF-8字符集得到的字节为0xE4 0xB8 0xAD 0xE6 0x96 0x87，经过Url编码之后得到“%E4%B8%AD%E6%96%87”。

2)如果某个字节对应着ASCII字符集中的某个非保留字符，则此字节无需使用百分号表示。

例如“Url编码”，使用UTF-8编码得到的字节是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81，由于前三个字节对应着ASCII中的非保留字符“Url”，因此这三个字节可以用非保留字符“Url”表示。最终的Url编码可以简化成“Url%E7%BC%96%E7%A0%81”，当然，如果你用"%55%72%6C%E7%BC%96%E7%A0%81”也是可以的。

由于历史的原因，有一些Url编码实现并不完全遵循这样的原则，下面会提到。

2.3.7 JS中escape,encodeURI和encodeURIComponent的区别

Javascript中提供了3对函数用来对Url编码以得到合法的Url，它们分别是escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。由于解码和编码的过程是可逆的，因此这里只解释编码的过程。

这三个编码的函数——escape，encodeURI，encodeURIComponent——都是用于将不安全不合法的Url字符转换为合法的Url字符表示，它们有以下几个不同点。

●安全字符不同

下面的表格列出了这三个函数的安全字符（即函数不会对这些字符进行编码）

安全字符

escape（69个）*/@+-._0-9a-zA-Z

encodeURI（82个）!#$&'()*+,/:;=?@-._~0-9a-zA-Z

encodeURIComponent（71个）!'()*-._~0-9a-zA-Z

●兼容性不同

escape函数是从Javascript1.0的时候就存在了，其他两个函数是在Javascript1.5才引入的。但是由于Javascript1.5已经非常普及了，所以实际上使用encodeURI和encodeURIComponent 并不会有什么兼容性问题。

●对Unicode字符的编码方式不同

这三个函数对于ASCII字符的编码方式相同，均是使用百分号+两位十六进制字符来表示。但是对于Unicode字符，escape的编码方式是%uxxxx，其中的xxxx是用来表示unicode 字符的4位十六进制字符。这种方式已经被W3C废弃了。但是在ECMA-262标准中仍然保留着escape的这种编码语法。encodeURI和encodeURIComponent则使用UTF-8对非ASCII 字符进行编码，然后再进行百分号编码。这是RFC推荐的。因此建议尽可能的使用这两个函数替代escape进行编码。

●适用场合不同

encodeURI被用作对一个完整的URI进行编码，而encodeURIComponent被用作对URI 的一个组件进行编码。

从上面提到的安全字符范围表格来看，我们会发现，encodeURIComponent编码的字符范围要比encodeURI的大。我们上面提到过，保留字符一般是用来分隔URI组件（一个URI 可以被切割成多个组件，参考预备知识一节）或者子组件（如URI中查询参数的分隔符），如:号用于分隔scheme和主机，?号用于分隔主机和路径。由于encodeURI操纵的对象是一个完整的的URI，这些字符在URI中本来就有特殊用途，因此这些保留字符不会被encodeURI 编码，否则意义就变了。

组件内部有自己的数据表示格式，但是这些数据内部不能包含有分隔组件的保留字符，否则就会导致整个URI中组件的分隔混乱。因此对于单个组件使用encodeURIComponent，需要编码的字符就更多了。

3.HTTP协议之请求

3.1 HTTP请求的结构

http请求由三部分组成，分别是：请求行、消息报头、请求正文。

●请求行

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：

Method Request-URI HTTP-Version CRLF

其中Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

应用举例：

GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源。

eg:GET /form.html HTTP/1.1 (CRLF)

POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。

eg：POST /reg.jsp HTTP/ (CRLF)

Accept:image/gif,image/x-xbit,... (CRLF)

...

HOST:https://www.360docs.net/doc/5c14016081.html, (CRLF)

Content-Length:22 (CRLF)

Connection:Keep-Alive (CRLF)

Cache-Control:no-cache (CRLF)

(CRLF) //该CRLF表示消息报头已经结束，在此之前为消息报头，后面为请求正文user=jeffrey&pwd=1234 //此行以下为提交的数据

HEAD方法与GET方法几乎是一样的，对于HEAD请求的回应部分来说，它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。利用这个方法，不必传输整个资源内容，就可以得到Request-URI所标识的资源的信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。

●请求报头后述

●请求正文

请求正文：user=jeffrey&pwd=1234 //此行以下为提交的数据

4.HTTP协议之响应

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

1、状态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx：指示信息--表示请求已接收，继续处理

2xx：成功--表示请求已被成功接收、理解、接受

3xx：重定向--要完成请求必须进行更进一步的操作

4xx：客户端错误--请求有语法错误或请求无法实现

5xx：服务器端错误--服务器未能实现合法的请求

常见状态代码、状态描述、说明：

200 OK //客户端请求成功

400 Bad Request //客户端请求有语法错误，不能被服务器所理解

401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用（这里可以演示一个例子，IIS，windows集成身份验证。总的来说，这个交互过程还是非常复杂的）

403 Forbidden //服务器收到请求，但是拒绝提供服务

404 Not Found //请求资源不存在，eg：输入了错误的URL

500 Internal Server Error //服务器发生不可预期的错误

503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后，可能恢复正常

eg：HTTP/1.1 200 OK （CRLF）

2、响应报头后述

3、响应正文就是服务器返回的资源的内容

5.HTTP协议之消息报头

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。

HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。

每一个报头域都是由名字+“：”+空格+值组成，消息报头域的名字是大小写无关的。

5.1 普通报头

在普通报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。

Cache-Control

Cache-Control用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。

请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached;

响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、

proxy-revalidate、max-age、s-maxage.

eg：为了指示IE浏览器（客户端）不要缓存页面，服务器端的JSP程序可以编写如下：

https://www.360docs.net/doc/5c14016081.html,代码

Response.AddHeader("Cache-Control","no-cache");

//Response.AddHeader("Pragma","no-cache");作用相当于上述代码，通常两者合用

Response.AddHeader("Cache-Control","no-cache"); //response.setHeader("Pragma","no-cache");作用相当于上述代码，通常两者合用

这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache

Date

Date普通报头域表示消息产生的日期和时间

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

(发送方向)

HTTP1.0要求不能生成第三种asctime格式的date/time stamp；

HTTP1.1则要求只生成RFC 1123(第一种)格式的date/time stamp。

Connection

Connection普通报头域允许发送指定连接的选项。例如指定连接是连续，或者指定“close”选项，通知服务器，在响应完成后，关闭连接

注意：某些杀毒软件可能会在特定的情况下阻止ajax的调用。当Connection为keep-Alive 时，对其他的header会有要求。

5.2 请求报头

请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。

常用的请求报头

Accept

Accept请求报头域用于指定客户端接受哪些类型的信息。eg：Accept：image/gif，表明客户端希望接受GIF图象格式的资源；Accept：text/html，表明客户端希望接受html文本。

Accept-Charset

Accept-Charset请求报头域用于指定客户端接受的字符集。

eg：Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。

Accept-Encoding

Accept-Encoding请求报头域类似于Accept，但是它是用于指定可接受的内容编码。

eg：Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。

Accept-Language

Accept-Language请求报头域类似于Accept，但是它是用于指定一种自然语言。

eg：Accept-Language:zh-cn.如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。

Authorization

Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。

Host（发送请求时，该报头域是必需的）

Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，

eg：我们在浏览器中输入：https://www.360docs.net/doc/5c14016081.html,/index.html

浏览器发送的请求消息中，就会包含Host请求报头域，如下：

Host：https://www.360docs.net/doc/5c14016081.html,

此处使用缺省端口号80，若指定了端口号，则变成：Host：https://www.360docs.net/doc/5c14016081.html,:指定端口号

User-Agent

我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的浏览器的名称和版本，这往往让很多人感到很神奇，实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不过，这个报头域不是必需的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息了。

请求报头举例：

GET /form.html HTTP/1.1 (CRLF)

Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms -excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)

Accept-Language:zh-cn (CRLF)

Accept-Encoding:gzip,deflate (CRLF)

If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)

If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)

User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)

Host:https://www.360docs.net/doc/5c14016081.html, (CRLF)

Connection:Keep-Alive (CRLF)

(CRLF)

5.3 响应报头

响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对

Request-URI所标识的资源进行下一步访问的信息。

常用的响应报头

Location

Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。

Server

Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是Server响应报头域的一个例子：

Server：Apache-Coyote/1.1

WWW-Authenticate

WWW-Authenticate响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。

eg：WWW-Authenticate:Basic realm="Basic Auth Test!"

//可以看出服务器对请求资源采用的是基本验证机制。

5.4 实体报头

请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。

常用的实体报头

Content-Encoding

Content- Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，

eg：Content- Encoding：gzip

Content-Language

Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读

者。eg：Content-Language:da

Content-Length

Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。

Content-Type

Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg：

Content-Type:text/html;charset=ISO-8859-1

Content-Type:text/html;charset=GB2312

Last-Modified

Last-Modified实体报头域用于指示资源的最后修改日期和时间。

Expires

Expires 实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和降低服务器负载)的页面，我们可以使用Expires实体报头域指定页面过期的时间。

eg：Expires：Thu，15 Sep 2006 16:23:12 GMT

HTTP1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。

eg：为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置为0，https://www.360docs.net/doc/5c14016081.html,中程序如下：Response.AddHeader("Expires","0");

6.需要提前了解的工具HttpAnalyzer

了解一款http协议抓包工具：Http watch,fiddler ,HttpAnalyzer。。。。。。

7.核心参考资料

1>http协议详解（孙鑫）

2>URL编码：

https://www.360docs.net/doc/5c14016081.html,/2009/08/%e8%af%a6%e8%a7%a3javascript%e4%b8%ad%e7% 9a%84url%e7%bc%96%e8%a7%a3%e7%a0%81.html

3>http协议中文版(RFC2612)