|
|
|
|
移动端

8.1.3 HTTP协议简介(1)

《Linux服务器配置全程实录》第8章配置Web服务器,在本章中将介绍通过Apache配置HTTP、HTTPS、WebDAV、反向代理、安全配置、多种用户认证方式、虚拟主机,JSP环境搭建,LAMP环境搭建以及使用Lighttpd实现HTTP、HTTPS、虚拟主机等的相关内容。本节为HTTP协议简介。

作者:张勤/杨章明来源:人民邮电出版社|2011-08-10 21:42

有奖调研 | 1TB硬盘等你拿 AI+区块链的发展趋势及应用调研


8.1.3  HTTP协议简介(1)

HTTP(HyperText Transfer Protocol,超文本传输协议)是Internet上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

HTTP的发展是万维网协会(World Wide Web Consortium)和Internet工作小组(Internet Engineering Task Force)合作的结果,他们最终发布了一系列的RFC,其中最著名的就是RFC 2616。RFC 2616定义了HTTP协议的普遍使用的一个版本HTTP 1.1。

HTTP是一个客户端和服务器端请求和应答的标准(HTTP使用TCP而不是UDP的原因在于一个网页必须传送很多数据,而TCP协议提供传输控制,按顺序组织数据,并进行错误纠正)。客户端是终端用户,服务器端是网站。通过使用Web浏览器或其他的工具,由HTTP客户端使用URL发起一个请求,建立一个到服务器指定端口(默认是80端口)的TCP连接。HTTP服务器则在那个端口侦听客户端发送过来的请求。一旦收到请求,服务器向客户端发回一个状态码,比如"HTTP/1.1 200 OK"和响应的消息,响应的消息体可能是请求的文件、错误消息或其他一些信息。在HTTP客户端和HTTP服务器中间可能存在多个中间层(比如代理、网关、隧道等)。尽管TCP/IP协议是互联网上最流行的应用,HTTP协议并没有规定必须使用它和基于它支持的层。事实上HTTP可以在任何其他互联网协议上,或者在其他网络上实现。HTTP只假定其下层协议提供可靠的传输,任何能够提供这种保证的协议都可以被其使用。

提示:URL(Uniform /Universal Resource Locator,统一资源定位符)是Internet上标准的资源地址。URL最初是由蒂姆·伯纳斯·李发明用来作为万维网的地址。现在它已经被万维网联盟编制为因特网标准RFC1738了。在Internet的历史上统一资源定位符的发明是一个非常基础的步骤。统一资源定位符的语法是可扩展的,它使用ASCII代码的一部分来表示因特网的地址。统一资源定位符的开始,一般会标志着一个计算机网络所使用的网络协议。

HTTP/1.1协议中共定义了8种动作(方法)来表明Request-URI指定的资源的不同操作方式。

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

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

(3)GET:向特定的资源发出请求。

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

(5)PUT:向指定资源位置上传其最新内容。

(6)DELETE:删除指定资源。

(7)TRACE:回显服务器收到的请求。

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

HTTP/1.1协议中的动作名称是区分大小写的,当某个请求所针对的资源不支持对应的请求方法的时候,服务器应当返回状态码405,当服务器不认识或不支持对应的请求方法的时候,应当返回状态行501。HTTP服务器至少应该实现GET和HEAD方法,其他方法都不是必需的。HTTP服务器回应客户端状态码主要有以下几个。

1.1xx消息

这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送1xx响应。

(1)100 Continue:客户端应当继续发送请求。这个临时响应用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。

(2)101 Switching Protocols:服务器已经理解了客户端的请求,并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后,服务器将会切换到在Upgrade消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似措施。比如切换到新的HTTP版本比旧版本更有优势,或者切换到一个实时且同步的协议以传送利用此类特性的资源。

(3)102 Processing:由WebDAV扩展的状态码,代表处理将被继续执行。

2.2xx成功

这一类型的状态码,代表请求已成功被服务器接收、理解并接受。

(1)200 OK:请求已成功,请求所希望的响应头或数据体将随此响应返回。

(2)201 Created:请求已经被实现,而且有一个新的资源已经依据请求的需要而建立,且其URI已经随Location头信息返回。假如需要的资源无法及时建立的话,应当返回"202 Accepted"。

(3)202 Accepted:服务器已接受请求,但尚未处理。正如它可能被拒绝一样,最终该请求可能会也可能不会被执行。在异步操作的场合下,没有比发送这个状态码更方便的做法了。返回202状态码的响应的目的是允许服务器接受其他过程的请求(比如某个每天只执行一次的基于批处理的操作),而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息,以及指向处理状态监视器或状态预测的指针,以便用户能够估计操作是否已经完成。

(4)203 Non-Authoritative Information:服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合,而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。比如包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的,而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。

(5)204 No Content:服务器成功处理了请求,但不需要返回任何实体内容,并且希望返回更新了的元信息。响应可能通过实体头部的形式,返回新的或更新后的元信息。如果存在这些头部信息,则应当与所请求的变量相呼应。如果客户端是浏览器的话,那么用户浏览器应保留发送了该请求的页面,而不产生任何文档视图上的变化,即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。由于204响应被禁止包含任何消息体,因此它始终以消息头后的第一个空行结尾。

(6)205 Reset Content:服务器成功处理了请求,且没有返回任何内容。但是与204响应不同,返回此状态码的响应要求请求者重置文档视图。该响应主要用于接受用户输入后,立即重置表单,以便用户能够轻松地开始另一次输入。与204响应一样,该响应也被禁止包含任何消息体,且以消息头后的第一个空行结束。

(7)206 Partial Content:服务器已经成功处理了部分GET请求。类似于FlashGet或迅雷这类的HTTP下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。该请求必须包含Range头信息来指示客户端希望得到的内容范围,并且可能包含If-Range来作为请求条件。任何不支持 Range 以及 Content-Range 头的缓存都禁止缓存206响应返回的内容。

(8)207 Multi-Status:由WebDAV扩展的状态码,代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码。


【责任编辑:云霞 TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

精通Spring 2.x——企业应用开发详解

本书深刻揭示了Spring的技术内幕,对IoC、AOP、事务管理等根基性的技术进行了深度的挖掘。读者阅读本书后,不但可以熟练使用Spring的各项功...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊