协议说明名目1. 了解 4.1.1 简介 4.1.2. 1.0 的会话方式41.4. 恳求消息 5.1.5. 响应消息 5.1.6. 消息 5.1.7. 消息头 6.2. 具体说明 7.2.1. URL72.2. 协议之恳求方法72.3. 协议之响应状态82.4. 协议之消息报头91. 了解 1.1 简介 用于定义 web 扫瞄器与 web 效劳器之间交换数据的过程以及数据本身的格式。 协议的版本： 1.0、1.1。 是一个属于应用层的面对对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于 1990 年提出，经过几年的使用与进展，得到不断地完善和扩展。目前在 WWW 中使用的是 /1.0 的 第六版， /1.1 的标准化工作正在进展之中，而且 -NG(Next Generation of )的建议已经提出。 协议的主要特点可概括如下：1. 支持客户/效劳器模式。2. 简洁快速：客户向效劳器恳求效劳时，只需传送恳求方法和路径。恳求方法常用的有 GET、HEAD、POST。每种方法规定了客户与效劳器联系的类型不同。由于 协议简洁，使得 效劳器的程序规模小，因而通信速度很快。3. 机敏： 允许传输任意类型的数据对象。正在传输的类型由Content-Type 加以标记。4. 无连接：无连接的含义是限制每次连接只处理一个恳求。效劳器处理完客户的恳求，并收到客户的应答后，即断开连接。承受这种方式可以节约传输时间。5. 无状态： 协议是无状态协议。无状态是指协议对于事务处理没有记忆力量。缺少状态意味着假设后续处理需要前面的信息，那么它必需重传，这样可能导致每次连接传送的数据量增大。另一方面，在效劳器不需要从前信息时它的应答就较快。1.2. 1.0 的会话方式扫瞄器和 WEB 效劳器的四个步骤：建立连接-发出恳求信息-回送响应信息-关闭连接扫瞄器和 WEB 效劳器的连接过程是短暂的:每次连接只处理一个恳求和响应，对每一个页面的访问，扫瞄器与web 效劳器都要建立一次单独的连接。全部通讯都是完全独立分开的恳求和响应对。支持代理:代理效劳器会存储缓存扫瞄器访问多图网页的过程。1.3. 1.1 与 1.0 的比较在一个 TCP 连接上可以传送多个 恳求和响应。多个恳求和响应过程可以重叠进展。增加了更多的恳求头和响应头。1.4. 恳求消息恳求消息的构造：一个恳求行，假设干消息头，以及实体内容，其中消息头和实体内容都是可选的，消息头和实体内容之家你要用空行隔开。举例：GET /books/java.html /1.1恳求行Accept:*/*消息头Accept-language:en-us消息头Connection:Keep-Alive消息头Host:localhost消息头Referer: :/localhost/links.asp消息头User-Agent:Mozilla/4.0消息头Accept-Encoding:gzip,deflate消息头空行GET 方式的实体行为空，只有 POST 等方法才有实体行1.5. 响应消息就是效劳器回送给扫瞄器的消息，响应消息的构造：与恳求消息一样，包括一个状态行，假设干消息行，以及实体内容。举例： /1.1 200 OK状态行Server：Microsoft-IIS、5.0消息行Date:Thu, 13 Jul 2000 05:46:53 GMT消息行Content-Length:2291消息行Content-Type:text/html消息行Cache-control:private消息行空行实体行实体行1.6. 消息 响应消息的实体内容就是网页文件的内容，也就是在扫瞄器中使用查看源文件的但凡看到的内容 一个使用 GET 方式的恳求消息中不能包含实体内容，只有使用 POST、PUT 和 DELETE 方式的恳求消息中才可以包含实体内容。 对于 1.1 来说，假设 消息中包含实体内容，且没有承受 chunked 传输编码方式，那么消息头局部必需包含内容长度的字段，否那么，客户和效劳程序就无法知道实体内容何时完毕。 在 协议中，还可以使用简洁的恳求消息和响应消息，他们都没有消息头局部。简洁的恳求消息中能用于 GET 方式，且恳求行中不用指定 版本号。对于简洁的恳求消息，效劳器返回简洁的响应消息，简洁的响应消息中只返回实体内容。1.7. 消息头 使用消息头，可以实现 客户机与效劳器之间的条件恳求和应答。消息头相当于效劳器与扫瞄器之间的一些暗号指令。 每个消息头包含一个头字段名称，然后依次是冒号、空格、值、回车和换行符。举例：Accept-Language: en-us 消息头字段名是不区分大小写的，但习惯上将每个单词的第一个字母大写。 消息头又可以分为通用消息头、恳求头、响应头、实体头等四类。 很多恳求头字段都允许客户端在值局部指定多个可承受的选项，多个项之间以逗号分隔。举例：Accept-Encoding：gzip, compress 有些头字段可以消灭屡次，例如：响应消息中可以包含有多个“Warning”头字段。2. 具体说明2.1URL 超文本传输协议是一个基于恳求与响应模式的、无状态的、应用层的协议，常基于 TCP 的连接方式， 1.1 版本中给出一种持续连接的机制，绝大多数的 Web 开发，都是构建在 协议之上的 Web 应用。 URL (URL 是一种特别类型的 URI，包含了用于查找某个资源的足够的信息)的格式如下： :/host“:“portabs_path 表示要通过 协议来定位网络资源；host 表示合法的 Internet 主机域名或者 IP 地址；port指定一个端口号，为空那么使用缺省端口 80；abs_path 指定恳求资源的 URI；假设 URL 中没有给出abs_path，那么当它作为恳求 URI 时，必需以“/”的形式给出，通常这个工作扫瞄器自动帮我们完成。例如:1、输入： 扫瞄器自动转换成： :/ 2、 :192.168.0.116:8080/index.jsp2.2. 协议之恳求方法 恳求由三局部组成，分别是：恳求行、消息报头、恳求正文。1、恳求行以一个方法符号开头，以空格分开，后面跟着恳求的URI 和协议的版本，格式如下：Method Request-URI -Version CRLF其中 Method 表示恳求方法；Request-URI 是一个统一资源标识符； -Version 表示恳求的 协议版本；CRLF 表示回车和换行除了作为结尾的CRLF 外，不允许消灭单独的 CR 或 LF 字符。恳求方法全部方法全为大写有多种，各个方法的解释如下：GET恳求猎取Request-URI 所标识的资源POST在 Request-URI 所标识的资源后附加新的数据HEAD恳求猎取由Request-URI 所标识的资源的响应消息报头PUT恳求效劳器存储一个资源，并用Request-URI 作为其标识DELETE 恳求效劳器删除Request-URI 所标识的资源TRACE恳求效劳器回送收到的恳求信息，主要用于测试或诊断CONNECT 保存将来使用OPTIONS 恳求查询效劳器的性能，或者查询与资源相关的选项和需求应用举例：GET 方法：在扫瞄器的地址栏中输入网址的方式访问网页时，扫瞄器承受GET 方法向效劳器猎取资源，例如:GET /form.html /1.1 (CRLF)POST 方法：要求被恳求效劳器承受附在恳求后面的数据，常用于提交表单。例如：POST /reg.jsp / (CRLF)Accept:image/gif,image/x-xbit,. (CRLF).HOST: (CRLF) Content-Length:22 (CRLF) Connection:Keep-Alive (CRLF) Cache-Control:no-cache (CRLF)(CRLF)/该 CRLF 表示消息报头已经完毕，在此之前为消息报头user=jeffrey&pwd=1234 /此行以下为提交的数据HEAD 方法与 GET 方法几乎是一样的，对于HEAD 恳求的回应局部来说，它的 头部中包含的信息与通过GET 恳求所得到的信息是一样的。利用这个方法，不必传输整个资源内容，就可以得到 Request-URI 所标识的资源的信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。2.3. 协议之响应状态在接收和解释恳求消息后，效劳器返回一个 响应消息。 响应也是由三个局部组成，分别是：状态行、消息报头、响应正文状态行格式如下： -Version Status-Code Reason-Phrase CRLF其中， -Version 表示效劳器 协议的版本； Status-Code 表示效劳器发回的响应状态代码； Reason-Phrase 表示状态代码的文本描述。状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：1xx：指示信息-表示恳求已接收，连续处理2xx：成功-表示恳求已被成功接收、理解、承受3xx：重定向-要完成恳求必需进展更进一步的操作4xx：客户端错误-恳求有语法错误或恳求无法实现5xx：效劳器端错误-效劳器未能实现合法的恳求常见状态代码、状态描述、说明：200 OK/客户端恳求成功400 Bad Request /客户端恳求有语法错误，不能被效劳器所理解401 Unauthorized /恳求未经授权，这个状态代码必需和WWW-Authenticate 报头域一起使用403Forbidden/效劳器收到恳求，但是拒绝供给效劳404Not Found/恳求资源不存在，eg：输入了错误的URL500 Internal Server Error /效劳器发生不行预期的错误503 Server Unavailable /效劳器当前不能处理客户端的恳求，一段时间后可能恢复正常例如： /1.1 200 OK CRLF2.4. 协议之消息报头 消息由客户端到效劳器的恳求和效劳器到客户端的响应组成。恳求消息和响应消息都是由开头行对于恳求消息，开头行就是恳求行，对于响应消