技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 网络系统 --> 简明HTTP协议

简明HTTP协议

浏览:3744次  出处信息

注:公司同事分享,在此仅作交流

1 HTTP协议的概念和历史

1.1 什么是HTTP协议

    HTTP协议是超文本传送协议(HyperText Transfer Protocol)的缩写,它是万维网(World Wide Web,www,也简称为Web)的基础。HTTP协议设计之初就是为了实现Web的想法。HTTP协议位于TCP/IP协议栈的应用层。

    我们在浏览器的地址栏里输入的网站地址叫做URL(UniformResourceLocator,统一资源定位符)。就像每家每户都有一个门牌地址一样,每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时,URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP),将Web服务器上站点的网页代码提取出来,并呈现出客户端需要的网页。

    HTTP协议使用的默认端口是80,同时也支持自定义端口。

1.2 HTTP协议的历史

    HTTP协议到现在为止总共经历了3个版本的演化,第一个HTTP协议诞生于1989年3月。当时Berners-Lee向 CERN?onseil Europeen pour la Recherche Nucleaire,欧洲核能研究所)提交了一篇名为《信息管理的一个提议》的文章。文章中提出了www网络的构想,不过仅仅在很多方面都只关注了概念,而没涉及到细节。

    第一个HTTP协议的版本是HTTP 0.9,它的组成极其简单,因为它只允许客户端发送GET这一种请求,它不包含协议头,每个请求只有一句话,例如:

    GET /index.html

    由于没有协议头,造成了HTTP 0.9协议只支持一种内容,即纯文本。不过网页仍然支持用HTML语言格式化,同时无法插入图片。所以HTTP 0.9能够支持的应用实在太有限了。一次HTTP 0.9的传输首先要建立一个由客户端到Web服务器的TCP连接,由客户端发起一个请求,然后由Web服务器返回页面内容,然后连接会关闭。如果请求的页面不存在,也不会返回任何错误码。

    HTTP 0.9的缺点是显著的,但至少实现了第一代的Web。

    HTTP协议的第二个版本是HTTP 1.0,直到HTTP 1.0成为最重要的面向事务的应用层协议。该协议对每一次请求/响应,同样是建立并关闭一次连接。其特点是简单、易于管理,所以它符合了大家的需要,得到了广泛的应用。

    并且HTTP 1.0最显著的变化之一是开始支持客户端通过POST方法向Web服务器提交数据。从此客户端与Web服务器之间不再只能单向地获取数据,而可以实现交互,因此CGI?ommon Gate Interface,通用网关接口)开始流行起来,Web上开始出现留言板、论坛等丰富的应用。

    HTTP 1.0还有个显著的变化是通过HTTP协议头可以支持各种媒体类型。从此Web上不再仅仅是纯文本的页面,比如图像通过的HTML标记开始出现。

    除了以上几个新特性,HTTP 1.0支持长连接(但默认还是使用短连接),缓存机制,以及身份认证。

    虽说HTTP协议的设计是向前兼容的,但目前很多浏览器和Web服务器都强制要求HTTP协议版本至少是1.0。

    HTTP协议的第三个版本是HTTP 1.1,它就是目前使用最广泛的协议版本。这个版本的HTTP协议已经稳定了,跟HTTP 1.0相比,它新增了很多引人注目的新特性,比如Host协议头,一个HTTP请求的头中可以包含一句例如:

    Host: vimer.cn

    从此一个Web服务器可以支持挂载多个域名了,无需每个域名都使用独立IP,每个网站可以使用虚拟主机。

    另一个HTTP 1.1的新特性是支持部分内容请求/响应,这意味着当客户端请求的数据量很大时,可以分多次发起请求,每次请求只要求获取整块数据的一部分。Web服务器也可以分多次响应,每次只返回整块数据的一部分。这使得流媒体得以实现。

    从HTTP 1.1开始,客户端默认与Web 服务器建立长连接,这种连接适合Web上数据量较大的丰富应用,使得资源消耗更少。

    QzHTTP就是一个支持HTTP 1.1协议的Web Server。

    2.HTTP协议内容介绍

2.1 URI

    HTTP协议通过URI(Uniform Resource Identifiers,统一资源定位符)来访问资源。根据RFC 1808的官方定义,一个完整URI的组成如下:

    http://myname:mypass@www.vimer.cn:80/mydir/myfile.html?myvar=myvalue#myfrag

URI字段

表 2.1

URI部分

意义

http

协议名称

myname

用户名(可选)

mypass

密码(可选)

www.vimer.cn

主机网络地址

80

端口号(可选)

/mydir/myfile.html

资源路径

myvar=myvalue

查询字符串(可选)

myfrag

锚点(可选)

    可见协议名称用“://”结束,用户名和密码以“:”分隔,以“@”结束,端口号与主机网络地址以“:”分隔,资源路径与查询字符串以“?”分隔,锚点以#开头。

    并且,只有协议名称、主机网络地址和资源路径是必须包含在URI里的。

    一个更常见的例子如下:

    http://www.vimer.cn/

    在这里面,http是协议,www.vimer.cn是主机网络地址,注意末尾的/就是资源路径,这是必须的。当我们平时使用Web浏览器访问时,只需要输入www.vimer.cn就可以访问,这是由于Web浏览器替我们自动补齐了前面的http://和最后的/,Web浏览器发起请求时使用的URI还是完整的,Web浏览器并不强制用户输入格式规范的URI。

2.2 HTTP请求与响应

    HTTP协议的交互主要由请求和响应组成,请求是指客户端发起向Web服务器请求资源的消息,而响应是Web服务器根据客户端的请求回送给客户端的资源消息。

    发出的请求信息(Request Message)包括以下几部分:

    l 请求行,例如GET /images/logo.gif HTTP/1.1,表示从/images 目录下请求logo.gif 这个文件。

    l (请求)头,例如Accept-Language: en

    l 空行

    l 可选的消息体

    请求行和标题必须以 作为结尾(也就是,回车然后换行)。空行内必须只有而无其他空格。在HTTP/1.1 协议中,所有的请求头,除Host外,都是可选的。

    请求方法(Request Method)

    HTTP/1.1协议中共定义了八种方法(有时也叫“动作”)来表明Request-URI指定的资源的不同操作方式:

    l OPTIONS

    返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送\'*\'的请求来测试服务器的功能性。

    l HEAD

    向服务器索要与GET请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息。

    l GET

    向特定的资源发出请求。注意:GET方法不应当被用于产生“副作用”的操作中,例如在Web 应用程序中。其中一个原因是GET可能会被网络蜘蛛等随意访问。

    l POST

    向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。

    l PUT

    向指定资源位置上传其最新内容。

    l DELETE

    删除指定资源。

    l TRACE

    回显服务器收到的请求。

    l CONNECT

    HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

    方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候,服务器应当返回状态码405(Method Not Allowed);当服务器不认识或者不支持对应的请求方法的时候,应当返回状态码501(Not Implemented)。

    HTTP服务器至少应该实现GET和HEAD方法,其他方法都是可选的,可选方法中还有一个重要的方法是POST。当然,所有的方法支持的实现都应当符合下述的方法各自的语义定义。此外,除了上述方法,特定的HTTP服务器还能够扩展自定义的方法。

    一个GET请求的示例如图2.3所示:

untitled

图2.3 HTTP请求

    GET 代表方法名,后面的/代表资源路径,HTTP/1.1表示协议版本。下面都是协议头部分,常见的头字段如表2.2所示。

HTTP协议头字段

表2.2

头字段

定义

Accept

客户端可以处理的媒体类型(MIME-Type),按优先级排序;在一个以逗号为分隔的列表中,可以定义多种类型和使用通配符

Accept-Language

客户端支持的自然语言列表

Accept-Encoding

客户端支持的编码列表

User-Agent

客户端环境类型

Host

服务器端的主机地址

Connection

连接类型,默认为Keep-Alive

    HTTP协议是Web内容的容器。一个示例HTTP响应如图2.4所示:

untitled2

图2.4 HTTP响应

    每个响应由HTTP协议头和Web内容构成。Web服务器收到一个请求,就会立刻解释请求中所用到的方法,并开始处理应答。服务器的响应消息也包含头字段形式的协议头。响应的格式在RFC2616中定义如下:

    Status-Line*

    (( general-header)| response-header | entity-header)CRLF)

    CRLF

    [ message-body ]

    响应消息的第一行是状态行(Stauts-Line),由协议版本以及数字状态码和相关的文本短语组成,各部分间用空格符隔开,除了最后的回车或换行外,中间不允许有回车换行。

    Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

    状态码是试图理解和满足请求的三位数字的整数码, 原因短语(Reason-Phrase)是为了给出的关于状态码的文本描述。状态码用于控制条件,而原因短语(Reason-Phrase)是让用户便于阅读。客户端不需要检查和显示原因短语。

    状态码的第一位数字定义响应类型。后两位数字没有任何分类角色。第一位数字有五种值,如表2.3所示。

HTTP响应状态码

表 2.3

状态码

定义

1xx 报告

接收到请求,继续进程

2xx 成功

步骤成功接收,被理解,并被接受

3xx 重定向

为了完成请求,必须采取进一步措施

4xx 客户端出错

请求包括错的顺序或不能完成

5xx 服务器出错

服务器无法完成显然有效的请求

    下面列举了为HTTP/1.1定义的状态码值,和对应的原因短语(Reason-Phrase)的例子。

    l 客户端错误

    "100" : Continue 继续

    "101" : witching Protocols 交换协议

    l 成功

    "200" : OK

    "201" : Created 已创建

    "202" : Accepted 接收

    "203" : Non-Authoritative Information 非认证信息

    "204" : No Content 无内容

    "205" : Reset Content 重置内容

    "206" : Partial Content 部分内容

    l 重定向

    "300" : Multiple Choices 多路选择

    "301" : Moved Permanently 永久转移

    "302" : Found 暂时转移

    "303" : See Other 参见其它

    "304" : Not Modified 未修改

    "305" : Use Proxy 使用代理

    "307" : Temporary Redirect

    l 客户方错误

    "400" : Bad Request 错误请求

    "401" : Unauthorized 未认证

    "402" : Payment Required 需要付费

    "403" : Forbidden 禁止

    "404" : Not Found 未找到

    "405" : Method Not Allowed 方法不允许

    "406" : Not Acceptable 不接受

    "407" : Proxy Authentication Required 需要代理认证

    "408" : Request Time-out 请求超时

    "409" : Conflict 冲突

    "410" : Gone 失败

    "411" : Length Required 需要长度

    "412" : Precondition Failed 条件失败

    "413" : Request Entity Too Large 请求实体太大

    "414" : Request-URI Too Large 请求URI太长

    "415" : Unsupported Media Type 不支持媒体类型

    "416" : Requested range not satisfiable

    "417" : Expectation Failed

    l 服务器错误

    "500" : Internal Server Error 服务器内部错误

    "501" : Not Implemented 未实现

    "502" : Bad Gateway 网关失败

    "503" : Service Unavailable

    "504" : Gateway Time-out 网关超时

    "505" : HTTP Version not supported HTTP版本不支持

    HTTP状态码是可扩展的。HTTP应用程序不需要理解所有已注册状态码的含义,尽管那样的理解显而易见是很合算的。但是,应用程序必须了解由第一位数字指定的状态码的类型,任何未被识别的响应应被看作是该类型的x00状态,有一个例外就是未被识别的响应不能缓存。例如,如果客户端收到一个未被识别的状态码431,则可以安全的假定请求有错,并且它会对待此响应就像它接收了一个状态码是400的响应。在这种情况下,用户代理(user agent)应当把实体和响应一起提交给用户,因为实体很可能包括人可读的关于解释不正常状态的信息。报文最后是实体信息,即客户请求得到的HTTP服务器上的资源内容。

    点击这里下载原版pdf

建议继续学习:

  1. HTTPS, SPDY和 HTTP/2性能的简单对比    (阅读:15878)
  2. 浅析http协议、cookies和session机制、浏览器缓存    (阅读:15760)
  3. 从输入 URL 到页面加载完成的过程中都发生了什么事情?    (阅读:14461)
  4. HTTP协议Keep-Alive模式详解    (阅读:10587)
  5. 介绍几个QQ开源项目及协议下载    (阅读:8861)
  6. 各种浏览器审查、监听http头工具介绍    (阅读:6215)
  7. nginx中对http请求处理的各个阶段分析    (阅读:6029)
  8. nginx上,http状态200响应,PHP空白返回的问题    (阅读:5483)
  9. websocket 通信协议    (阅读:5384)
  10. 你不知道的 HTTP    (阅读:5342)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1