折叠 编辑本段 发展简史
折叠 理论提出
超文本传输协议的前身是世外桃源(Xanadu)项目,超文本的概念是泰德˙纳尔森(Ted Nel题所兴句我创证son)在1960年代提出的。进入哈佛大学后,纳尔森一直致力于超文本协议和该项目的研究,但他从未公开发表过资料。
折叠 程序开发
1989年,蒂姆˙伯纳斯˙李来自(Tim Berners Lee)在CERN(欧洲原子核研究委员会 = European Organization for Nucle余酒候唱识游下其激ar Research)担任软件360百科咨询师的时候,开发节理子罗古面双众还许了一套程序,奠定了万维网的基础。1990年12月,超文本在CERN首次上线。1991年夏天,继Telnet等协议之后,超文本转移协议成为互联网诸多协议的一分金序绝能先飞抗级字子。
折叠 发展状况
折叠 编辑本段 工作过程
超文本传输协议,是我们浏览网页、看在线视频、听在线音乐等必须遵循的规则。正是在这样的规则下,浏览器(万维网客户)才能向万维网服务器发送万维网文档请求,然后服务器会将请求的文档发送回浏览器。在浏览器和服务器之间的请求和响应的交互,必须着具尔谈希当按照规定的格式和规则,这些格式和规则就构成了超文本传输协议。
从上面的例子我们可以看到万维网的大致工作过程如图。
图 万维网的工作过程
计算机系统中有一个专门为HTTP开放的80端口,主要用于万维网传输信息的协议。每个万维网网点(可以是计算机)都有一个服务器进程来监听TCP的80端口,一旦发现浏览器向它发出连接建立请求,继而建立TCP连接,浏览器就向万维网服务器发出浏览某个网页的请求,服务器就接着返回所请措曾海拿压求的页面作为响应。最后,TCP连接被释放。
需要说明的是,HTTP协议是无状态的,也就是说同一个客户第二次访问同一个服务器上面的页面时,服务器的响应与第一次访问时的相同。服务器并不知燃均能道曾经访问过此客户,更不会记得此客户曾经被服务过多少次了。但是,在实际工作医执口刚成阻言几奏强中一些万维网站点还是希望能够识别用户的。比如,你在某个购物网站上将某个产品加入购物车后,希望继续浏览并选购其它商品,这时服务器就需要记住用户的身份以便所有的商品可以一起结账。
HTTP中的Cookie提供了这种功能。Cookie是这样工作的:当用户(代号为Use明神电r)访问某个使用Cookie的网站时,该网站就会为User产生一个唯一的识别码并以此作为索引在服务器的后端数据库中产句太确画来型活全聚绿生一个项目。接着在给初达渐几孩具User的HTTP响应济宗降武实压志超劳多报文(关于HTTP的报文结构附录会有介绍,困读者可以先看那部分内田措章损容)中添加Set-cook食祖校展根ie的首部行。这象若希湖导特钱里的"首部字段名"为"Set-cookie",后面的"值"就是赋予该用户的"识别码岩组密只书解当察"。例如这个首部行为:Set-cookie:09876543。
当User收到这个响应时,其浏览器就在它管理的特定Cookie文件中添加一行,其中包括这个服务器的主机名和Set-cookie后面给出的识别码。当User继续浏览这个网站时,每发送一个HTTP请求报文,其浏览器就会从其Cookie文件中取出这个网站的识别码并放到HTTP请求报文的Cookie首部行中:Cookie:09876543。于是这个网站就能够跟踪User在这个网站的活动,也就能够实现购买的商品一起付费了。服务器和用户的交集仅仅在于这个识别码,服务器不知道User的其它任何信息。[1]
折叠 编辑本段 协议
折叠 释义
H香液TTP是Hyper Text Transfer Protocol(超文本传输协议)的缩写。它的发展是万维网协会(World Wide Web Consortium)和Internet工作小组IETF(Internet Engineering Task Force)合样调没属作的结果,(他们)最终发布了一系列的RFC,RFC 1945定义了HTTP/1.0版本。其中最著名的就是RFC 2始卷引河志于宁供秋616。RFC 2616定义了今天普遍使用的一个版本--HTTP 1.1。为纪念Tim Berners-Lee提出HTTP后对互联网发展的贡献,万维网协会保留有他最原始提交的版本。[2]
HTTP协议(HyperText Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可著异地开半销热画风江以使浏览器更加高效,使网络传输减少。它不仅保证船计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图影曲小带超形)等。
HTTP是一个应用层协议,由请求和响应构成,是一个标准的穿据组客户端服务器模型。HTTP是一个无状态的协议。
折叠 特点
HTTP协议的主要特点可概括如下:
1、支呢武采由是少观汉似景刻持客户/服务器模式。支持基本认证和安全认证(见后文《安全协议》)。
2、 简单快速:客户向服务器请求服务时,只需系约布探医合素令基八集传送请求方法和路径垂女罪体消包口多包。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
3、灵着调末限年范活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4、HTTP 0.9和1.0使用非持续连接:限制每次连接只处理一个请求,服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
HTTP 1.1使用持续连接:不必为每个web对象创建扬亮子象冷善要助呢夫一个新的连接,一个连接可以传送多个对象。
5、无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。
另一方面,在服务器不需要先前信息时它的应答就较快。
折叠 请求信息
发出的请求信息包括以下几个:
●请求行,例如GET /images/logo.gif HTTP/1.1,表示从/images目录下请求logo.gif这个文指件。
●(请求)头,例如Accept-Language: en
●空行
●可选的消息体 请求行和标题必须以<CR><LF>作为结尾(也就是,回车然后换行)。空行内必须只有<CR><LF>而无其他空格。在HTTP/1.1协议中,所有的请求头,除host外,都是施升可选的。
折叠 请求方法
HTTP/1.1协议中共定义了八种物绝纪德愿织简方法(有时也叫"动作")来表明Request-URI指定的资源的不同操作方式:
OPTIONS - 返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
HEAD- 向服务器索要与GET请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息。
GET - 向特定的于温课如讨清套资源发出请求。注意:GET方法不应当被用于产生"副作用"的操作中,例如在web app送书证.中。其中一个原因是GET可能会被网络蜘蛛等随意访问。
POST - 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。PO生衣庆括校功有协另课金ST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT - 向指定资源位置上传其最新内容。
DELETE - 请求服务效红器删除Request-URI所标识的资源。
TRACE- 回显服务器收到的请求,主要用于测试或诊断。
CONNECT - HTTP/训湖1.1协议中预留给能够将连接改为管道方式的代理服务器。
PATCH - 用来将局部修药州项兴制念时镇参端改应用于某一资源,添加于规范RFC5789。
方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候,服务器应当返回状态码405(Method Not Allowed);当服那右独又务器不认识或者不支持对应的请求方法的时候,应当返回状态码501(Not I章木草入mplemented)。
HTT护交P服务器至少应该实现G办金准食真ET和POST方法,其他方法达都是可选的。当然,所有的方法支持的实现都应当符合下述的方法各自的语义定义。此外,除了上述方法,特定的HTTP服务器还能够扩展自定义的方法。
折叠 响应头
客户端向服务器发送一个请求,服务器以职前研服检敌意错口一个状态行作为响应,响应的工色她银岩十到生内容包括:消息协议的版本、成功或者错误编码、服务器信息、实体元信息以及必要的实体内容。根据响应类别的类别,服务器响应里可以含实体内容,但不是所有的响应都有实体内容。本节仅简述响应头。
响应头第一行
响应头第一行也称为状态行,格式如下:
HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF
HTTP- Version表示HTTP版本,例如为HTTP/1.1。Status- Code是结果代码,用三个数字表示。Reason-Phrase是个简单的文本描述,解释Status-Code的具体原因。Status-Code用于机器自动识别,Reason-Phrase用于人工理解。Status-Code的第一个数字代表响应类别,可能取5个不同的值。后续两位描述在该类响应下发生的具体状况,具体请参见:HTTP状态码 。
响应头域
服务器需要传递许多附加信息,这些信息不能全放在状态行里。因此,需要另行定义响应头域,用来描述这些附加信息。响应头域主要描述服务器的信息和Request-URI的信息。响应头举例、实体头以及实体请参见: 服务器头文件响应
折叠 安全
安全超文本转移协议(Secure Hypertext Transfer Protocol, S-HTTP)是一种结合HTTP而设计的消息的安全通信协议。S-HTTP协议为HTTP客户机和服务器提供了多种安全机制,这些安全服务选项是适用于Web上各类用户的。还为客户机和服务器提供了对称能力(及时处理请求和恢复,及两者的参数选择)同时维持HTTP的通信模型和实施特征。
S-HTTP不需要客户方的公用密钥证明,但它支持对称密钥的操作模式。这意味着在没有要求用户个人建立公用密钥的情况下,会自发地发生私人交易。它支持端对端安全传输,客户机可能首先启动安全传输(使用报头的信息),用来支持加密技术。
在语法上,S-HTTP报文与HTTP相同,由请求行或状态行组成,后面是信息头和主体。请求报文的格式由请求行、通用信息头、请求头、实体头、信息主体组成。响应报文由响应行、通用信息头、响应头、实体头、信息主体组成。
目前有两种方法来建立连接:HTTPSURI方案(RFC 2818)和HTTP 1.1请求头(由RFC2817引入)。由于浏览器对后者的几乎没有任何支持,因此HTTPS URI方案仍是建立安全超文本协议连接的主要手段。安全超文本连接协议使用https://代替http://
折叠 编辑本段 报文结构
HTTP有两类报文:请求报文和响应报文。请求报文是从客户向服务器发送的请求报文(如图),响应报文是从服务器到客户的回答(如图)。
图 HTTP请求报文结构
图 HTTP响应报文结构
HTTP请求报文和响应报文都是由三部分组成,可以看出,这两种报文格式的区别就在于开始行不同。
1 开始行,用于区别是请求报文还是响应报文。在请求报文中的开始行叫做请求行,在响应报文中的开始行叫做状态行。在开始行的三个字段之间都以空格分隔开,最后的"CR"和"LF"分别代表"回车"和"换行"。
特别注意的是,请求报文中的第一行只有三个内容,即方法,请求资源的URL,以及HTTP的版本。这里的名词"方法"就是对所请求的对象进行的操作,这些方法其实也就是一些命令。因此请求报文的类型是由它采用的方法决定的。
2 首部行,用来说明浏览器、服务器或者报文主体的一些信息。首部可以有若干行,也可以没有。
3 实体主体,在请求报文中一般无此字段,在响应报文中也可以没有此字段。
折叠 编辑本段 HTTP函数
折叠 释义
在 PHP 中,HTTP 函数允许您在其他输出被发送之前,对由 Web 服务器发送到浏览器的信息进行操作。
折叠 安装
HTTP 函数是 PHP 核心的组成部分。无需安装即可使用这些函数。
折叠 列表
PHP:指示支持该函数的最早的 PHP 版本。
函数 | 描述 | PHP |
---|---|---|
header() | 向客户端发送原始的 HTTP 报头。 | 3 |
headers_list() | 返回已发送的(或待发送的)响应头部的一个列表。 | 5 |
headers_sent() | 检查 HTTP 报头是否发送/已发送到何处。 | 3 |
setcookie() | 向客户端发送一个 HTTP cookie。 | 3 |
setrawcookie() | 不对 cookie 值进行 URL 编码,发送一个 HTTP cookie。 | 5 |
折叠 状态码
HTTP状态码列表:
状态码 | 状态码英文名称 | 中文描述 |
---|---|---|
100 | Continue | 继续。客户端应继续其请求 |
101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议 |
200 | OK | 请求成功。一般用于GET与POST请求 |
201 | Created | 已创建。成功请求并创建了新的资源 |
202 | Accepted | 已接受。已经接受请求,但未处理完成 |
203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本 |
204 | No Content | 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档 |
205 | Reset Content | 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域 |
206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
300 | Multiple Choices | 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择 |
301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URL,返回信息会包括新的URL,浏览器会自动定向到新URL。今后任何新的请求都应使用新的URL代替 |
302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URL |
303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
304 | Not Modified | 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
306 | Unused | 已经被废弃的HTTP状态码 |
307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
400 | Bad Request | 客户端请求的语法错误,服务器无法理解 |
401 | Unauthorized | 请求要求用户的身份认证 |
402 | Payment Required | 保留,将来使用 |
403 | Forbidden | 服务器理解请求客户端的请求,但是拒绝执行此请求 |
404 | Not Found | 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
405 | Method Not Allowed | 客户端请求中的方法被禁止 |
406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
407 | Proxy Authentication Required | 请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权 |
408 | Request Time-out | 服务器等待客户端发送的请求时间过长,超时 |
409 | Conflict | 服务器完成客户端的PUT请求时可能返回此代码,服务器处理请求时发生了冲突 |
410 | Gone | 客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置 |
411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
412 | Precondition Failed | 客户端请求信息的先决条件错误 |
413 | Request Entity Too Large | 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息 |
414 | Request-URLToo Large | 请求的URL过长(URL通常为网址),服务器无法处理 |
415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
416 | Requested range not satisfiable | 客户端请求的范围无效 |
417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
500 | Internal Server Error | 服务器内部错误,无法完成请求 |
501 | Not Implemented | 服务器不支持请求的功能,无法完成请求 |
502 | Bad Gateway | 充当网关或代理的服务器,从远端服务器接收到了一个无效的请求 |
503 | Service Unavailable | 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
504 | Gateway Time-out | 充当网关或代理的服务器,未及时从远端服务器获取请求 |
505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本,无法完成处理 |