http://friping.iteye.com/blog/531061
博客原文
HTTP是Web协议集中的重要协议,它是从客户机/服务器模型发展起来的。客户机/服务器是运行一对相互通信的程序,客户与服务器连接时,首先,向服务器提出请求,服务器根据客户的请求,完成处理并给出响应。浏览器就是与Web服务器产生连接的客户端程序,它的端口为TCP的80端口。举一个大家都很常见的例子,浏览器与Web服务器之间所遵循的协议就是HTTP。
Web的应用层协议HTTP是Web的核心。HTTP在Web的客户程序和服务器程序中得以实现。运行在不同端系统上的客户程序和服务器程序通过交换HTTP消息彼此交流。HTTP定义这些消息的结构以及客户和服务器如何交换这些消息。HTTP定义Web客户(即浏览器)如何从web服务器请求Web页面,以及服务器如何把Web页面传送给客户。
HTTP协议的优点就是可以解决传输数据的准确性、安全性较高、而且有处理网络拥塞的能力。这主要的原因就是HTTP协议传输数据的时候,是由HTTP都把TCP作为底层的传输协议。HTTP客户首先发起建立与服务器TCP连接。一旦建立连接,浏览器进程和服务器进程就可以通过各自的套接字来访问TCP。如前所述,客户端套接字是客户进程和TCP连接之间的“门”,服务器端套接字是服务器进程和同一TCP连接之间的门。客户往自己的套接字发送HTTP请求消息,也从自己的套接字接收HTTP响应消息。类似的,服务器从自己的套接字接收HTTP请求消息,也往自己的套接字发送HTTP响应消息。客户或服务器一旦把某个消息送入各自的套接字,这个消息就完全落入TCP的控制之中。
TCP给HTTP提供一个可靠的数据传输服务;这意味着由客户发出的每个HTTP请求消息最终将无损地到达服务器,由服务器发出的每个HTTP响应消息最终也将无损地到达客户。我们可从中看到分层网络体系结构的一个明显优势——HTTP不必担心数据会丢失,也无需关心TCP如何从数据的丢失和错序中恢复出来的细节。HTTP/1.1服务器端处理请求时按照收到的顺序进行,这就保证了传输的正确性。当然,服务器端在发生连接中断时,会自动的重传请求,保证数据的完整性。
值得注意的是HTTP协议的建立连接方式也非常特别,在早先的HTTP/1.0版本中使用的是非持久连接,而到了HTTP/1.1时非持久连接和持久连接都被支持,但默认使用持久连接。在此要说明非持久连接大概的过程是,举一个浏览网页的例子。首先客户由与TCP连接相关联的本地套接字发出—个HTTP请求消息;其次,服务器接受请求并且经由同一个套接字发送响应消息;然后HTTP服务器告知TCP关闭这个TCP连接(不过TCP要到客户收到刚才这个响应消息之后才会真正终止这个连接);这时HTTP客户经由同一个套接字接收这个响应消息后,TCP连接随后终止。该消息明确标明所封装的对象是一个什么样的文件。客户从中取出这个文件,加以分析后发现其中的真正内容的引用。然后再对这些内容申请连接,最后浏览器就可以显示出网页的内容了,假如网页的内容是由5幅图片组成的那么完成对网页的浏览就需要有6次TCP的连接,这是HTTP/1.0版本的做法。
在HTTP/1.1中,在持久连接情况下,服务器在发出响应后让TCP连接继续打开着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。整个Web页面(上例中为包含一个基本HTML文件和5个图像的页面)可以通过单个持久TCP连接发送,甚至存放在同一个服务器中的多个web页面也可以通过单个持久TCP连接发送。通常,HTTP服务器在某个连接闲置一段特定时间后关闭它,而这段时间通常是可以配置的。持久连接分为不带流水线(without pipelining)和带流水线(with pipelining)两个版本。如果是不带流水线的版本,那么客户只在收到前一个请求的响应后才发出新的请求。这种情况下,web页面所引用的每个对象(上例中的5个图像)都经历1个RTT的延迟,用于请求和接收该对象。与非持久连接2个RTT的延迟相比,不带流水线的持久连接已有所改善,不过带流水线的持久连接还能进一步降低响应延迟。不带流水线版本的另一个缺点是,服务器送出一个对象后开始等待下一个请求,而这个新请求却不能马上到达。这段时间服务器资源便闲置了。HTTP/1.1的默认模式使用带流水线的持久连接。这种情况下,HTTP客户每碰到一个引用就立即发出一个请求,因而HTTP客户可以一个接一个紧挨着发出各个引用对象的请求。服务器收到这些请求后,也可以一个接一个紧挨着发出各个对象。如果所有的请求和响应都是紧挨着发送的,那么所有引用到的对象一共只经历1个RTT的延迟(而不是像不带流水线的版本那样,每个引用到的对象都各有1个RTT的延迟)。另外,带流水线的持久连接中服务器空等请求的时间比较少。与非持久连接相比,持久连接(不论是否带流水线)除降低了1个RTT的响应延迟外,缓启动延迟也比较小。其原因在于既然各个对象使用同一个TCP连接,服务器发出第一个对象后就不必再以一开始的缓慢速率发送后续对象。相反,服务器可以按照第一个对象发送完毕时的速率开始发送下一个对象。
从上面的例子不难看出,非持久连接中用户的点击导致浏览器发起建立一个与Web服务器的TCP连接,这里涉及一个三次握手的过程:首先是客户向服务器发送一个小的冗余消息,接着是服务器向客户确认并响应一个小的TCP消息,最后是客户向服务器回确认。三次握手过程的前两次结束时,流逝的时间为1个RTT。此时客户把HTTP请求消息发送到TCP连接中,客户接着把三次握手过程最后一次中的确认捎带,在包含这个消息的数据分节中发送出去。服务器收到来自TCP连接的请求消息后,把相应的HTML文件发送到TCP连接中,服务器接着把对早先收到的客户请求的确认捎带在包含该HTML文件的数据分节中发送出去。这个HTTP请求顺应交互也花去1个RTT时间。很容易就能看出持久连接在时间损耗上的优势了。
另外一个非常重要的地方就是HTTP协议的请求头以及响应头的格式。如果不清楚请求头的格式就无法向服务器端准确地发送下载请求;同时响应头的获得信息,对下载工具下一步的处理也至关重要。下面列出HTTP请求消息:
GET/somedir/page.htmlHTTP/1.1
Host:www.hhit.edu.cn
Connection:close
User-agent:Mozilla/4.0
Accept-language:zh-cn
(额外的回车符和换行符)
首先,这个消息是用普通的ASCII文本书写的。其次,这个消息共有5行(每行以一个回车符和一个换行符结束),最后一行后面还有额外的一个回车和换行符。当然,一个请求消息可以不止这么多行,也可以仅仅只有一行。该请求消息的第一行称为请求行(request line),后续各行都称为头部行(header)。请求行有3个字段:方法字段、URL字段、HTTP版本字段。方法字段有若干个值可供选择,包括GET、POST和HEAD。HTTP请求消息绝大多数使用GET方法,这是浏览器用来请求对象的方法,所请求的对象就在URL字段中标识。本例中浏览器实现的是HTTP/1.1版本。
上面例子中的请求消息有四行他们的意思分别是:
头部行Host:www.hhit.edu.cn存放所请求对象的主机。
请求消息中包含头部Connection:close是在告知服务器本浏览器不想使用持久连接;服务器发出所请求的对象后应关闭连接。尽管产生这个请求消息的浏览器实现的是HTTP/1.1版本,它还是不想使用持久连接。
User-agent头部行指定用户代理,也就是产生当前请求的浏览器的类型。本例的用户代理是Mozilla/4.0,它是Nelscape浏览器的一个版本。这个头部行很有用,因为服务器实际上可以给不同类型的用户代理发送同一个对象的不同版本(这些不同版本位用同一个URL寻址)。
最后,Accept-languag:头部行指出要是所请求对象有简体中文版本,那么用户宁愿接收这个版本;如果没有这个语言版本,那么服务器应该发送其默认版本。Accept-languag:仅仅是HTTP的众多内容协商头部之一。
HTTP协议请求消息的一般格式如图:
图 HTTP协议的请求信息格式
值得注意的是在请求消息的最后是附属体,在我们给出的例子中并没有这一项。是因为,附属体不在GET方法中使用,而是在POST方法中使用。POST方法适用于需由用户填写表单的场合,如往google搜索引擎中填入待搜索的词。用户提交表单后,浏览器就像用户点击了超链接那样仍然从服务器请求一个Web页面,不过该页面的具体内容却取决于用户填写在表单各个字段中的值。如果浏览器使用POST方法提出该请求,那么请求消息附属体中包含的是用户填写在表单各个字段中的值。
HTTP协议的响应消息和请求消息有所不同,下面是一个典型的响应消息:
HTTP/1.1 200 OK
Connection:close
Date:Thu,13Oct200503:17:33GMT
Server:Apache/2.0.54(Unix)
Last-Modified:Mon,22Jun199809;23;24GMT
Content-Length:682l
Content-Type:text/html
(数据数据数据数据数据…………)
这个响应消息分为3部分:1个起始的状态行(Status Line),6个头部行、1个包含所请求对象本身的附属体。状态行有3个字段:协议版本字段、状态码字段、原因短语字段。本例的状态行表明,服务器使用HTTP/1.1版本,状态码(Status Codes)200表示响应过程完全正常(也就是说服务器找到了所请求的对象,并正在发送)。
在上面的响应消息中头部行的意思分别是:
服务器使用Connection:close头部行告知客户自己将在发送完本消息后关闭TCP连接。
Date头部行:指出服务器创建并发送本响应消息的日期和时间。注意,这并不是对象本身的创建时间或最后修改时间,而是服务器把该对象从其文件系统中取出,插入响应消息中发送出去的时间。
Server头部行:指出本消息是由Apache服务器产生的;它与HTTP请求消息中的User-agent头部行类似。
Last-Modified头部行:指出对象本身的创建或最后修改日期或时间。Last-Modified头部对于对象的高速缓存至关重要,且不论这种高速缓存是发生在本地客户主机上还是发生在网络高速缓存服务器主机(也就是代理服务器主机)上。
Content-Length头部行:指出所发送对象的字节数。
Content-Type头部行:指出包含在附属体中的对象是HTML文本。对象的类型是由Content—Type头部而不是由文件扩展名正式指出的。
HTTP响应消息格式如图:
图 HTTP协议的响应信息格式
图 完整的HTTP请求响应内容
在响应消息中的状态行明显多出了明显多出了状态码(Status Codes)和原因短语,是因为在请求的信息可能存在着很多情况需要区分开,这样也便于用户能够清楚地知道请求的情况以及出错的原因,响应消息中的状态码和原因短语指示相应请求的处理结果。当服务器响应时,其状态行的信息为HTTP的版本号,状态码,及解释状态码的简单说明。现将5类状态码详细列出:
1XX客户方错误
100 继续
101 交换协议
2XX成功
200 OK
201 已创建
202 接收
203 非认证信息
204 无内容
205 重置内容
206 部分内容
3XX重定向
300 多路选择
301 永久转移
302 暂时转移
303 参见其它
304 未修改(Not Modified)
305 使用代理
4XX客户方错误
400 错误请求(Bad Request)
401 未认证
402 需要付费
403 禁止(Forbidden)
404 未找到(Not Found)
405 方法不允许
406 不接受
407 需要代理认证
408 请求超时
409 冲突
410 失败
411 需要长度
412 条件失败
413 请求实体太大
414 请求URL太长
415 不支持媒体类型
5XX服务器错误
500 服务器内部错误
501 未实现(Not Implemented)
502 网关失败
504 网关超时
505 HTTP版本不支持
分享到:
相关推荐
### HDMI 传输原理解析 #### 一、HDMI传输原理概述 HDMI(High Definition Multimedia Interface,高清多媒体接口)是一种未压缩的高清音视频数据传输接口标准,它能够同时传输高质量的音频与视频信号。HDMI之所以...
### HDMI的基本传输原理详解 #### 一、HDMI概述 HDMI(High-Definition Multimedia Interface,高清晰度多媒体接口)是一种先进的数字接口技术,旨在通过单一的线缆传输未经压缩的全数字高清视频、多声道音频以及...
《数字图像传输原理教程》是一份综合性的学习资料,涵盖了图像传输领域的核心概念和技术。这份教程通过PPT和WORD文档的形式,深入浅出地讲解了图像在通信和网络中的传输方式,旨在帮助学习者理解并掌握这一关键领域...
CAN 总线传输原理 CAN 总线是一种控制器局域网(Controller Area Network),其发展始于 20 世纪 80 年代末的汽车工业中,由德国 BOSCH 公司最先提出。1991 年 9 月 PHILIPS Semiconductors 制定并发布了 CAN 技术...
RTC6701无线模拟视频传输模块原理图PADS格式,是安防,无线视频的低成本方案。
### 图像格式转换算法原理 #### 一、引言 图像作为多媒体技术中不可或缺的信息媒介,在数字通信、网络传输及各类应用软件中扮演着至关重要的角色。然而,图像的多种存储格式及其庞大的数据量给多媒体技术的发展...
无线视频音频传输同步原理主要涉及的是...总结来说,无线视频音频传输同步原理涉及网络带宽、MPEG编码与容器格式、同步机制和流量控制等多个方面。随着技术的不断进步,未来我们将看到更加高效、流畅的无线多媒体体验。
首先,我们要理解数据传输的基本原理。数据传输是指通过通信网络将信息从一个地方传送到另一个地方的过程。这个过程涉及编码、调制、解调、信道选择和错误控制等步骤。编码是将原始信息转化为适合在通信媒介上传输的...
**广播电视数字微波传输原理及设备分析** 广播电视数字微波传输是现代电视传输的重要方式,它基于同步数字体系(SDH)技术,能够高效、稳定地传输大量的电视节目和数据服务。SDH是一种国际标准,适用于光纤和微波...
### FTP文件传输协议原理 #### 1.1 什么是FTP: 文件传输协议原理 FTP(File Transfer Protocol)是一种用于在互联网或局域网上进行文件传输的标准协议。它最初由Abhay Bhushan在1971年提出,并在1985年通过RFC 959...
CAN总线传输原理的组成包括一个控制器、一个收发器、两个数据传输终端及两条数据传输线。除数据传输线外,其他元件都置于控制单元内部。CAN控制器是用来接收控制单元中微电脑传输的信息,并将其转换为CAN总线上的...
本资源包括六个讲座部分和一个关于官方的RTSP协议简介,能快速了解流媒体的原理,系统,格式应用,不可多得的好东西。
它将各种不同速率的数字信号复用成统一的同步传输格式,提供高效的数据、语音和视频传输服务。SDH的主要特点包括: 1. **标准化**:SDH定义了一套统一的帧结构和复用层次,使得不同厂家的设备可以无缝对接。 2. **...
在提供的“LoRa无线图像和视频传输原理图及程序”压缩包中,应包含LoRa通信的硬件连接图、HuskyLens的配置代码、LoRa传输的协议栈实现以及可能的示例应用代码。这些资源可以帮助开发者快速理解和实现基于LoRa的无线...
BSC到BTS的传输原理 本课件主要讲解BSC到BTS的传输原理,涵盖了传输媒体、E1和T1标准、信道映射、A接口和A-bis接口等内容。下面是相关知识点的详细解释: 1. 传输媒体(Transport Media) 传输媒体是指在BSC到BTS...
首先,我们要理解无线传输的基本原理。无线传输主要基于电磁波理论,通过无线电频率或者光频段将信息编码为电磁波信号,然后在空气中传播。这些信号可以穿越空气,甚至穿透建筑物,到达接收设备,然后由接收设备解码...
综上所述,HTTP协议及其传输参数是理解Web工作原理的关键,无论是对于前端开发者还是后端工程师,深入掌握HTTP协议的细节都是十分必要的。通过本文的介绍,相信读者对HTTP格式有了更深刻的理解。
文档中的内容似乎是一份关于冶金传输原理中动量传输部分的习题解答,涉及了一些基本概念、公式推导和问题解决。尽管具体内容由于格式限制并未完全显示,但从给出的部分可以看到,习题涵盖了一些基础的物理和工程计算...
MP3,全称为MPEG Audio Layer 3,是音频压缩技术的一种,因其高效的数据压缩能力,使得音频文件能够在保持相对高质量的同时,体积大大减小,从而成为流行音乐格式的首选。MP3是ISO/MPEG标准的一部分,这个标准不仅...