http原理概述.docx
- 文档编号:23013402
- 上传时间:2023-04-30
- 格式:DOCX
- 页数:24
- 大小:59.38KB
http原理概述.docx
《http原理概述.docx》由会员分享,可在线阅读,更多相关《http原理概述.docx(24页珍藏版)》请在冰豆网上搜索。
http原理概述
HTTP协议的概念和工作原理
一、HTTP协议是什么
我们在浏览器的地址栏里输入的网站地址叫做URL(UniformResourceLocator,统一资源定位符)。
就像每家每户都有一个门牌地址一样,每个网页也都有一个Internet地址。
当你在浏览器的地址框中输入一个URL或是单击一个超级链接时,URL就确定了要浏览的地址。
浏览器通过超文本传输协议(HTTP),将Web服务器上站点的网页代码提取出来,并翻译成漂亮的网页。
因此,在我们认识HTTP之前,有必要先弄清楚URL的组成,例如:
1.http:
//:
代表超文本传输协议,通知服务器显示Web页,通常不用输入;
2.www:
代表一个Web(万维网)服务器;
3.M
4.China/:
为该服务器上的子目录,就好像我们的文件夹;
5.Index.htm:
index.htm是文件夹中的一个HTML文件(网页)。
我们知道,Internet的基本协议是TCP/IP协议,然而在TCP/IP模型最上层的是应用层(Applicationlayer),它包含所有高层的协议。
高层协议有:
文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和HTTP协议等。
HTTP协议(HypertextTransferProtocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。
它可以使浏览器更加高效,使网络传输减少。
它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。
这就是你为什么在浏览器中看到的网页地址都是以“http:
//”开头的原因。
自WWW诞生以来,一个多姿多彩的资讯和虚拟的世界便出现在我们眼前,可是我们怎么能够更加容易地找到我们需要的资讯呢?
当决定使用超文本作为WWW文档的标准格式后,于是在1990年,科学家们立即制定了能够快速查找这些超文本文档的协议,即HTTP协议。
经过几年的使用与发展,得到不断的完善和扩展,目前在WWW中使用的是HTTP/1.0的第六版。
二、HTTP是怎样工作的
既然我们明白了URL的构成,那么HTTP是怎么工作呢?
我们接下来就要讨论这个问题。
由于HTTP协议是基于请求/响应范式的(相当于客户机/服务器)。
一个客户机与服务器建立连接后,发送一个请求给服务器,请求方式的格式为:
统一资源标识符(URL)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
服务器接到请求后,给予相应的响应信息,其格式为一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。
许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。
最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。
在Internet上,HTTP通讯通常发生在TCP/IP连接之上。
缺省端口是TCP80,但其它的端口也是可用的。
但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。
HTTP只预示着一个可靠的传输。
这个过程就好像我们打电话订货一样,我们可以打电话给商家,告诉他我们需要什么规格的商品,然后商家再告诉我们什么商品有货,什么商品缺货。
这些,我们是通过电话线用电话联系(HTTP是通过TCP/IP),当然我们也可以通过传真,只要商家那边也有传真。
以上简要介绍了HTTP协议的宏观运作方式,下面介绍一下HTTP协议的内部操作过程。
在WWW中,“客户”与“服务器”是一个相对的概念,只存在于一个特定的连接期间,即在某个连接中的客户在另一个连接中可能作为服务器。
基于HTTP协议的客户/服务器模式的信息交换过程,它分四个过程:
建立连接、发送请求信息、发送响应信息、关闭连接。
这就好像上面的例子,我们电话订货的全过程。
其实简单说就是任何服务器除了包括HTML文件以外,还有一个HTTP驻留程序,用于响应用户请求。
你的浏览器是HTTP客户,向服务器发送请求,当浏览器中输入了一个开始文件或点击了一个超级链接时,浏览器就向服务器发送了HTTP请求,此请求被送往由IP地址指定的URL。
驻留程序接收到请求,在进行必要的操作后回送所要求的文件。
在这一过程中,在网络上发送和接收的数据已经被分成一个或多个数据包(packet),每个数据包包括:
要传送的数据;控制信息,即告诉网络怎样处理数据包。
TCP/IP决定了每个数据包的格式。
如果事先不告诉你,你可能不会知道信息被分成用于传输和再重新组合起来的许多小块。
也就是说商家除了拥有商品之外,它也有一个职员在接听你的电话,当你打电话的时候,你的声音转换成各种复杂的数据,通过电话线传输到对方的电话机,对方的电话机又把各种复杂的数据转换成声音,使得对方商家的职员能够明白你的请求。
这个过程你不需要明白声音是怎么转换成复杂的数据的。
了解WWW服务与HTTP协议
在前一篇文章里,我们介绍了网络应用和网络协议的一些基础知识,现在,让我们来了解一下WWW服务应用和HTTP网络协议。
历史上,先后问世了多个具有重大社会影响的电子通信技术。
第一个这样的技术是19世纪70年代发明的电话。
电话使得不在同一物理位置的两人得以实时地口头交流。
它对社会有重大的影响——有好的也有坏的。
下一个电子通信技术是20世纪20年代及30年代问世的广播收音机/电视机。
广播收音机/电视机使得人们能收听收视大量的音频和视频信息。
它对社会同样有重大的影响——有好的也有坏的。
改变了人们的生活与工作方式的第三个重大通信技术是web。
web最吸引用户的也许是它的随选(ondemand)操作性。
用户只在想要时收到所要的东西。
这一点不同于广播收音机/电视机。
广播收音机/电视机的用户是在其内容供应商播出内容期间被迫收听收视。
除了随选操作性,Web还有许多大家喜爱的其他精彩特性。
任何个人都可以极其容易地在Web上公布任何信息;任何人都可能以极低的成本成为发行人。
超链接和搜索引擎帮助我们在Web站点的海洋中导航。
图形和动画刺激着我们的感官。
表单、Java小应用程序、Activex控件以及其他许多设备使得我们能与Web页面和站点交互。
Web还越来越普遍地提供存放在因特网中的、可随选访问(即点播)的大量音频和视频材料的菜单接口。
HTTP概貌
Web的应用层协议HTTP是Web的核心。
HTTP在Web的客户程序和服务器程序中得以实现。
运行在不同端系统上的客户程序和服务器程序通过交换HTTP消息彼此交流。
HTTP定义这些消息的结构以及客户和服务器如何交换这些消息。
在详细解释HTTP之前,我们先来回顾一些web中的术语。
Web页面(webpage,也称为文档)由多个对象构成。
对象(object)仅仅是可由单个URL寻址的文件,例如HTML文件、JPG图像、GIF图像、JAVA小应用程序、语音片段等。
大多数Web页面由单个基本HIML文件和若干个所引用的对象构成。
例如,如果一个Web页面包含HTML文本和5个JPEG图像,那么它由6个对象构成,即基本H1ML文件加5个图像。
基本HTML文件使用相应的URL来引用本页面的其他对象。
每个URL由存放该对象的服务器主机名和该对象的路径名两部分构成。
例如,在如下的URL中:
是一个主机名,/urlpath/picture.qif是一个路径名。
浏览器是web的用户代理,它显示所请求的Web页面,并提供大量的导航与配置特性。
Web浏览器还实现HTTP的客户端,因此在web上下文中,我们会从进程意义上互换使用“浏览器”和“客户”两词。
流行的Web浏览器有NetscapeCommunicator,firefox和微软的IE等。
Web服务器存放可由URL寻址的Web对象。
web服务器还实现HTTP的服务器端。
流行的Web服务器有Apache、微软的IIS以及NetscapeEnterpriseServer。
Netcraft提供了web服务器的概要剖析[Netcrft2000]。
HTTP定义Web客户(即浏览器)如何从web服务器请求Web页面,以及服务器如何把Web页面传送给客户。
下图展示了这种请求—响应行为。
当用户请求一个Web页面(譬如说点击某个超链接)时,浏览器把请求该页面中各个对象的HTTP请求消息发送给服务器。
服务器收到请求后,以运送含有这些对象HTTP响应消息作为响应。
到1997年底,基本上所有的浏览器和Web服务器软件都实现了在RFC1945中定义的HTTP/1.0版本。
1998年初,一些Web服务器软件和浏览器软件开始实现在RFC2616中定义的HTTP/1.1版本。
H1TP/1.1与HTTP/1.0后向兼容;运行1.1版本的web服务器可以与运行1.0版本的浏览器“对话”,运行1.1版本的浏览器也可以与运行1.0版本的Web服务器“对话”。
图1HTTP请求与响应行为
HTTP/1.0和HTTP/1.1都把TCP作为底层的传输协议。
HTTP客户首先发起建立与服务器TCP连接。
一旦建立连接,浏览器进程和服务器进程就可以通过各自的套接字来访问TCP。
如前所述,客户端套接字是客户进程和TCP连接之间的“门”,服务器端套接字是服务器进程和同一TCP连接之间的“门”。
客户往自己的套接字发送HTTP请求消息,也从自己的套接字接收HTTP响应消息。
类似地,服务器从自己的套接字接收HTTP请求消息,也往自己的套接字发送HTTP响应消息。
客户或服务器一旦把某个消息送入各自的套接字,这个消息就完全落入TCP的控制之中。
TCP给HTTP提供一个可靠的数据传输服务;这意味着由客户发出的每个HTTP请求消息最终将无损地到达服务器,由服务器发出的每个HTTP响应消息最终也将无损地到达客户。
我们可从中看到分层网络体系结构的一个明显优势——HTTP不必担心数据会丢失,也无需关心TCP如何从数据的丢失和错序中恢复出来的细节。
这些是TCP和协议栈中更低协议层的任务。
TCP还使用一个拥塞控制机制。
该机制迫使每个新的TCP连接一开始以相对缓慢的速率传输数据,然而只要网络不拥塞,每个连接可以迅速上升到相对较高的速率。
这个慢速传输的初始阶段称为缓启动(slowstart)。
需要注意的是,在向客户发送所请求文件的同时,服务器并没有存储关于该客户的任何状态信息。
即便某个客户在几秒钟内再次请求同一个对象,服务器也不会响应说:
自己刚刚给它发送了这个对象。
相反,服务器重新发送这个对象,因为它已经彻底忘记早先做过什么。
既然HTTP服务器不维护客户的状态信息,我们于是说HTTP是一个无状态的协议(statelessprotocol)。
非持久连接和持久连接
HTTP既可以使用非持久连接(nonpersistentconnection),也可以使用持久连接(persistentconnection)。
HTTP/1.0使用非持久连接,HTTP/1.1默认使用持久连接。
非持久连接
让我们查看一下非持久连接情况下从服务器到客户传送一个Web页面的步骤。
假设该贝面由1个基本HTML文件和10个JPEG图像构成,而且所有这些对象都存放在同一台服务器主机中。
再假设该基本HTML文件的URL为:
下面是具体步骡:
1.HTTP客户初始化一个与服务器主机中的HTTP服务器的TCP连接。
HTTP服务器使用默认端口号80监听来自HTTP客户的连接建立请求。
2.HTTP客户经由与TCP连接相关联的本地套接字发出—个HTTP请求消息。
这个消息中包含路径名/somepath/index.html。
3.HTTP服务器经由与TCP连接相关联的本地套接字接收这个请求消息,再从服务器主机的内存或硬盘中取出对象/somepath/index.html,经由同一个套接字发出包含该对象的响应消息。
4.HTTP服务器告知TCP关闭这个TCP连接(不过TCP要到客户收到刚才这个响应消息之后才会真正终止这个连接)。
5.HTTP客户经由同一个套接字接收这个响应消息。
TCP连接随后终止。
该消息标明所封装的对象是一个HTML文件。
客户从中取出这个文件,加以分析后发现其中有10个JPEG对象的引用。
6.给每一个引用到的JPEG对象重复步骡1-4。
浏览器在接收web页面的同时把它显示给用户。
不同的浏览器可能会以略有不同的方式解释(也就是向用户显示)同一个web页面。
HTTP与客户如何解释Web页面没有任何关系,其规范([RFC1945]和[RFC2616I)仅仅定义HTTP客户程序和服务器程序之间的通信协议。
上述步骤之所以称为使用非持久连接,原因是每次服务器发出一个对象后,相应的TCP连接就被关闭,也就是说每个连接都没有持续到可用于传送其他对象。
每个TCP连接只用于传输一个请求消息和一个响应消息。
就上述例子而言,用户每请求一次那个web页面,就产生11个TCP连接。
在上述步骡中,我们有意不说清客户是通过10个串行的TCP连接先后取得所有JPEG对象,还是通过并行的TCP连接同时取得其中某些JPEG对象。
实际上,现今的浏览器允许用户通过配置来控制并行连接的程度。
大多数浏览器默认可以打开5到10个并行的TCP连接,每个连接处理一个请求—响应事务。
用户要是喜欢,可以把最大并行连接数设为l,那样的话这10个连接是串行地建立的。
我们将在第3章看到,使用并行连接可以缩短响应时间。
继续介绍之前,先估算一下从客户请求基本HTML文件到它收到该文件所经历的时间。
为此我们定义往返时间(roundtriptime,简称RTT),它是一个小分组从客户主机游动到服务器主机再返回客户主机所花的时间。
RTT包括分组传播延迟、在中间路由器和交换机土的分组排队延迟以及分组处理延迟。
下面考虑用户点击某个超链接时会发生什么。
用户的点击导致浏览器发起建立一个与Web服务器的TCP连接;这里涉及·—次“三次握手”过程——首先是客户向服务器发送一个小的冗余消息,接着是服务器向客户确认并响应以一个小的TCP消息,最后是客户向服务器回确认。
三次握手过程的前两次结束时,流逝的时间为1个RTT。
此时客户把HTTP请求消息发送到TCP连接中,客户接着把三次握手过程最后一次中的确认捎带在包含这个消息的数据分节中发送以去。
服务器收到来自TCP连接的请求消息后,把相应的HTML文件发送到TCP连接中,服务器接着把对早先收到的客户请求的确认捎带在包含该HTML文件的数据分节中发送出去。
这个HTTP请求顺应交互也花去1个RTT时间。
因此,总的响应时间粗略地算是2个RTT加上服务器发送这个HTMI文件的时间。
持久连接
非持久连接有些缺点。
首先,客户得为每个待请求的对象建立并维护一个新的连接。
对于每个这样的连接,TCP得在客户端和服务器端分配TCP缓冲区,并维持TCP变量。
对于有可能同时为来自数百个不同客户的请求提供服务的web服务器来说,这会严重增加其负担。
其次,如前所述,每个对象都有2个RTT的响应延长——一个RTT用于建立TCP连接,另—个RTT用于请求和接收对象。
最后,每个对象都遭受TCP缓启动,因为每个TCP连接都起始于缓启动阶段。
不过并行TCP连接的使用能够部分减轻RTT延迟和缓启动延迟的影响。
在持久连接情况下,服务器在发出响应后让TCP连接继续打开着。
同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。
整个Web页面(上例中为包含一个基本HTMLL文件和10个图像的页面)自不用说可以通过单个持久TCP连接发送:
甚至存放在同一个服务器中的多个web页面也可以通过单个持久TCP连接发送。
通常,HTTP服务器在某个连接闲置一段特定时间后关闭它,而这段时间通常是可以配置的。
持久连接分为不带流水线(withoutpipelining)和带流水线(withpipelining)两个版本。
如果是不带流水线的版本,那么客户只在收到前一个请求的响应后才发出新的请求。
这种情况下,web页面所引用的每个对象(上例中的10个图像)都经历1个RTT的延迟,用于请求和接收该对象。
与非持久连接2个RTT的延迟相比,不带流水线的持久连接已有所改善,不过带流水线的持久连接还能进一步降低响应延迟。
不带流水线版本的另一个缺点是,服务器送出一个对象后开始等待下一个请求,而这个新请求却不能马上到达。
这段时间服务器资源便闲置了。
HTTP/1.1的默认模式使用带流水线的持久连接。
这种情况下,HTTP客户每碰到一个引用就立即发出一个请求,因而HTTP客户可以一个接一个紧挨着发出各个引用对象的请求。
服务器收到这些请求后,也可以一个接一个紧挨着发出各个对象。
如果所有的请求和响应都是紧挨着发送的,那么所有引用到的对象一共只经历1个RTT的延迟(而不是像不带流水线的版本那样,每个引用到的对象都各有1个RTT的延迟)。
另外,带流水线的持久连接中服务器空等请求的时间比较少。
与非持久连接相比,持久连接(不论是否带流水线)除降低了1个RTT的响应延迟外,缓启动延迟也比较小。
其原因在于既然各个对象使用同一个TCP连接,服务器发出第一个对象后就不必再以一开始的缓慢速率发送后续对象。
相反,服务器可以按照第一个对象发送完毕时的速率开始发送下一个对象。
HTTP消息格式
HTTP规范1.0[RPcl945]和1.1[RFC2616]定义了HTTP消息的格式。
HTTP消息分为请求消息和响应稍息两类。
下面我们分别进行介绍。
HTTP请求消息
下面是一个典型的HTTP请求消息:
GET/somedir/page.htmlH7TP/1.1
Host:
Connection:
close
User-agent:
Mozilla/4.0
Accept-language:
zh-cn
(额外的回车符和换行符)
仔细检查这个简单的请求消息,我们可从中学到不少东西。
首先,这个消息是用普通的ASCII文本书写的。
其次,这个消息共有5行(每行以一个回车符和一个换行符结束),最后一行后面还有额外的一个回车特和换行符。
当然,一个请求消息可以不止这么多行,也可以仅仅只有一行。
该请求消息的第一行称为请求行(requestline),后续各行都称为头部行(header)。
请求行有3个宁段:
方法字段、URL字段、HTTP版本宇段。
方法字段有若干个值可供选择,包括GET、POST和HEAD。
HTTP请求消息绝大多数使用GET方法,这是浏览器用来请求对象的方法,所请求的对象就在URL字段中标识。
本例表明浏览器在请求对象/somedir/page.html。
版本字段是不言自明的;本例中浏览器实现的是HTTP/1.1版本。
现在看一下本例中的各个头部行。
头部行Host:
定存放所请求对象的主机。
请求消息中包含头部Connection:
close是在告知服务器本浏览器不想使用持久连接;服务器发出所请求的对象后应关闭连接。
尽管产生这个请求消息的浏览器实现的是HTTP/1.1版本,它还是不想使用持久连接。
User-agent头部行指定用户代理,也就是产生当前请求的浏览器的类型。
本例的用户代理是Mozilla/4.0,它是Nelscape浏览器的一个版本。
这个头部行很有用,因为服务器实际上可以给不同类型的用户代理发送同一个对象的不同版本(这些不同版本位用同一个URL寻址)。
最后,Accept-languag:
头部行指出要是所请求对象有简体中文版本,那么用户宁愿接收这个版本;如果没有这个语言版本,那么服务器应该发送其默认版本。
Accept-languag:
仅仅是HTTP的众多内容协商头部之一。
我们接着看一下下图所示的请求消息的一般格式。
图2:
HTTP请求格式
上面的请求消息例子符合这个格式,不过一般格式中还有一个位于各个头部(及额外的回车符和换行符)之后的“附属体”(毗叮body)。
附属体不在GET方法中使用,而是在POST方法中使用。
POST方法适用于需由用户填写表单的场合,如往google搜索引擎中填入待搜索的词。
用户提交表单后,浏览器就像用户点击了超链接那样仍然从服务器请求一个Web页面,不过该页面的具体内容却取决于用户填写在表单各个字段中的值。
如果浏览器使用POST方法提出该请求,那么请求消息附属体中包含的是用户填写在表单各个字段中的值。
与GET方法类似的是HEAD方法,两者的差别只是服务器在对HEAD方法的响应消息中去掉了所请求的对象,其他内容则与对GET方法的响应消息一样。
HEAD方法通常用于HTTP服务器软件开发人员进行调试。
HTTP响应消息
下面是一个典型的HTTP响应消息:
HTTP/1.12000K
Connectlon:
close
Date:
Thu,13Oct200503:
17:
33GMT
Server:
Apache/2.0.54(Unix)
Last—Nodified:
Mon,22Jun199809;23;24GMT
Content—Length:
682l
Content—Type:
text/html
(数据数据数据数据数据…………)
这个响应消息分为3部分:
1个起始的状态行(statusline),6个头部行、1个包含所请求对象本身的附属体。
状态行有3个字段:
协议版本字段、状态码字段、原因短语字段。
本例的状态行表明,服务器使用HTTP/1.1版本,响应过程完全正常(也就是说服务器找到了所请求的对象,并正在发送)。
现在看一下本例中的各个头部行。
服务器使用Connectlon:
close头部行告知客户自己将在发送完本消息后关闭TCP连接。
Date:
头部行指出服务器创建并发送本响应消息的日期和时间。
注意,这并不是对象本身的创建时间或最后修改时间,而是服务器把该对象从其文件系统中取出,插入响应消息中发送出去的时间。
Server:
头部行指出本消息是由Apache服务器产生的;它与HTTP请求消息中的User-agent:
头部行类似。
Last—Nodified:
头部行指出对象本身的创建或最后修改日期或时间。
Last—Nodified:
头部对于对象的高速缓存至关重要,且不论这种高速缓存是发生在本地客户主机上还是发生在网络高速缓存服务器主机(也就是代理服务器主机)上。
Content—Length:
头部行指出所发送对象的字节数。
Content—Type:
头部行指出包含在附属体中的对象是HTML文本。
对象的类型是由Content—Type:
头部而不是由文件扩展名正式指出的。
注意,如果服务器收到一个HTTP/1.0的请求,那么它即使是一个HTTP/1.1服务器,也不会使用持久连接。
相反,这样的HTTP/1.1服务器会在发出所请求的对象后关闭TCP连接。
这么做是必要的,因为HTTP/1.0客户期待服务器马上关闭连接。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- http 原理 概述
![提示](https://static.bdocx.com/images/bang_tan.gif)