direktori cari
Guides Access control CORS Authentication Browser detection using the user agent Caching Caching FAQ Compression Conditional requests Connection management in HTTP 1.x Content negotiation Content negotiation: List of default Accept values Cookies CSP Messages Overview Protocol upgrade mechanism Proxy servers and tunneling Proxy servers and tunneling: Proxy Auto-Configuration (PAC) file Public Key Pinning Range requests Redirections Resources and specifications Resources and URIs Response codes Server-Side Access Control Session Guides: Basics Basics of HTTP Choosing between www and non-www URLs Data URIs Evolution of HTTP Identifying resources on the Web MIME Types MIME types: Complete list of MIME types CSP Content-Security-Policy Content-Security-Policy-Report-Only CSP: base-uri CSP: block-all-mixed-content CSP: child-src CSP: connect-src CSP: default-src CSP: font-src CSP: form-action CSP: frame-ancestors CSP: frame-src CSP: img-src CSP: manifest-src CSP: media-src CSP: object-src CSP: plugin-types CSP: referrer CSP: report-uri CSP: require-sri-for CSP: sandbox CSP: script-src CSP: style-src CSP: upgrade-insecure-requests CSP: worker-src Headers Accept Accept-Charset Accept-Encoding Accept-Language Accept-Ranges Access-Control-Allow-Credentials Access-Control-Allow-Headers Access-Control-Allow-Methods Access-Control-Allow-Origin Access-Control-Expose-Headers Access-Control-Max-Age Access-Control-Request-Headers Access-Control-Request-Method Age Allow Authorization Cache-Control Connection Content-Disposition Content-Encoding Content-Language Content-Length Content-Location Content-Range Content-Type Cookie Cookie2 Date DNT ETag Expect Expires Forwarded From Headers Host If-Match If-Modified-Since If-None-Match If-Range If-Unmodified-Since Keep-Alive Large-Allocation Last-Modified Location Origin Pragma Proxy-Authenticate Proxy-Authorization Public-Key-Pins Public-Key-Pins-Report-Only Range Referer Referrer-Policy Retry-After Server Set-Cookie Set-Cookie2 SourceMap Strict-Transport-Security TE Tk Trailer Transfer-Encoding Upgrade-Insecure-Requests User-Agent User-Agent: Firefox Vary Via Warning WWW-Authenticate X-Content-Type-Options X-DNS-Prefetch-Control X-Forwarded-For X-Forwarded-Host X-Forwarded-Proto X-Frame-Options X-XSS-Protection Methods CONNECT DELETE GET HEAD Methods OPTIONS PATCH POST PUT Status 100 Continue 101 Switching Protocols 200 OK 201 Created 202 Accepted 203 Non-Authoritative Information 204 No Content 205 Reset Content 206 Partial Content 300 Multiple Choices 301 Moved Permanently 302 Found 303 See Other 304 Not Modified 307 Temporary Redirect 308 Permanent Redirect 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone 411 Length Required 412 Precondition Failed 413 Payload Too Large 414 URI Too Long 415 Unsupported Media Type 416 Range Not Satisfiable 417 Expectation Failed 426 Upgrade Required 428 Precondition Required 429 Too Many Requests 431 Request Header Fields Too Large 451 Unavailable For Legal Reasons 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported 511 Network Authentication Required Status
watak

HTTP 是万维网的底层协议。由 Tim Berners-Lee 在1989  -  1991年发明的,HTTP 已经看到了许多变化,保持了大部分简单性并进一步塑造了其灵活性。HTTP 已经从早期的协议演变到在半可信的实验室环境中交换文件,到现在的互联网迷宫,现在它们携带图像,高分辨率和3D视频。

万维网的发明

1989年,当他在欧洲核子研究中心工作时,蒂姆伯纳斯李写了一个建议,建立一个通过互联网的超文本系统。最初称它为Mesh,后来在1990年实施时重新命名为万维网。它建立在现有的TCP和IP协议上,由4个构建块组成:

  • 表示超文本文件的文本格式,即超文本标记语言(HTML)。

  • 一个简单的协议来交换这些文件,HypertText传输协议(HTTP)。

  • 一个客户端显示(和意外编辑)这些文件,第一个Web浏览器称为WorldWideWeb

  • 提供访问文档的服务器,httpd的早期版本。

这四个构件块在1990年底完成,第一批服务器已在1991年初在欧洲核子研究中心外运行。1991年8月6日,Tim Berners-Lee 在公共超文本新闻组的帖子现在被认为是正式开始作为一个公共项目的万维网。

这些早期阶段使用的HTTP协议非常简单,后来被称为HTTP/0.9,有时也被称为单线协议。

HTTP/0.9 – The one-line protocol

HTTP的初始版本没有版本号; 它后来被称为0.9来区分它和更高版本。HTTP / 0.9非常简单:请求由一行代码组成,并从唯一可能的方法开始,GET然后是资源路径(不是URL,因为连接到服务器后不需要协议,服务器和端口)。

GET /mypage.html

答案也非常简单:它只包含文件本身。

<HTML>A very simple HTML page</HTML>

与随后的演变不同,没有HTTP标头,这意味着只能传输HTML文件,而不能传输其他类型的文件。没有状态或错误代码:在发生问题的情况下,发送特定的HTML文件并将其中包含的问题描述供人类使用。

HTTP/1.0  - 构建可扩展性

HTTP/0.9非常有限,浏览器和服务器很快将其扩展到更多功能:

  • 版本信息现在在每个请求中发送(HTTP/1.0附加到GET行中)

  • 状态码行也在响应开始时发送,允许浏览器自己了解请求的成功或失败并调整其行为(如以特定方式更新或使用本地缓存)

  • 已经引入了HTTP标头的概念,包括请求和响应,允许传输元数据并使协议非常灵活和可扩展。

  • 在新的HTTP标题的帮助下,增加了传输其他文档而不是纯HTML文件的功能(感谢Content-Type标题)。

一个典型的要求是这样的:

GET /mypage.html HTTP/1.0User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17Content-Type: text/html<HTML> A page with an image  <IMG SRC="/myimage.gif"></HTML>

接下来是第二个连接并请求获取图像:

GET /myimage.gif HTTP/1.0User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17Content-Type: text/gif(image content)

这些新奇事物并没有作为协同努力被引入,而是作为1991  -  1995年期间的一种尝试和看见的方法:服务器和浏览器增加了一个功能,并且看到它是否得到了牵引。许多互操作性问题很常见。在1996年11月,为了解决这些烦恼,RFC 1945发布了描述通用实践的信息文件。这是HTTP/1.0的定义,值得注意的是,从狭义上讲,它不是官方的标准。

HTTP/1.1  - 标准化协议

与HTTP/1.0的各种实现的有些混乱的使用并行,并且从1995年开始,在明年发布HTTP/1.0文档之前,正在进行适当的标准化。HTTP/1.1的第一个标准化版本于1997年初发布,仅在HTTP/1.0之后几个月发布。

HTTP/1.1澄清了含糊之处并引入了许多改进:

  • 连接可以重复使用,节省重新打开多次的时间,以显示嵌入到检索到的单个原始文档中的资源。

  • 流水线已添加,允许在第一个请求的答案完全传输之前发送第二个请求,从而降低通信延迟。

  • 分块响应现在也支持。

  • 额外的缓存控制机制已经被引入。

  • 内容协商(包括语言,编码或类型)已经引入,并允许客户和服务器就最适合交换的内容达成一致。

  • 多亏了Host标题,现在可以在同一个IP地址上托管不同的域,从而允许服务器搭配。

一个典型的请求流,通过一个单一的连接现在看起来像这样:

GET /en-US/docs/Glossary/Simple_header HTTP/1.1Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)


GET /static/img/header-background.png HTTP/1.1
Host: developer.cdn.mozilla.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header200 OK
Age: 9578461Cache-Control: public, max-age=315360000Connection: keep-alive
Content-Length: 3077Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache(image content of 3077 bytes)

HTTP/1.1于1997年1月首次发布为RFC 2068。

超过15年的延期

由于其可扩展性 - 很容易创建新的头文件或方法 - 即使HTTP/1.1协议经过两次修订(1999年6月发布的RFC 2616和2014年6月发布的RFC 7230 - RFC 7235系列)HTTP / 2的发布,这个协议在超过15年的时间里非常稳定。

使用HTTP进行安全传输

发生在HTTP上的最大变化早在1994年底完成。Netscape Communication不是通过基本的TCP / IP堆栈发送HTTP,而是在其上创建了一个额外的加密传输层:SSL。SSL 1.0从未在公司以外发布过,但SSL 2.0及其后继者SSL 3.0和SSL 3.1允许通过加密和保证服务器和客户端之间交换消息的真实性来创建电子商务网站。SSL被放在标准轨道上,最终成为TLS,1.0,1.1和1.2版成功出现在关闭漏洞的地方。TLS 1.3目前正在制作中。

同时,对加密传输层的需求也在增加:Web留下了大多数学术网络的相对可信度,到了广告客户,随机个人或罪犯竞相获取关于人们的私人信息的丛林,试图模仿他们甚至可以取代由改变的数据传输的数据。随着通过HTTP构建的应用程序变得越来越强大,访问越来越多的私人信息(如地址簿,电子邮件或用户的地理位置),即使在电子商务使用之外,也需要使TLS变得无处不在案件。

将HTTP用于复杂的应用程序

Tim Berners-Lee对于Web的最初设想不是只读媒体。他设想了一个Web,人们可以在其中远程添加和移动文档,这是一种分布式文件系统。大约在1996年,HTTP已经扩展到允许创作,并且创建了一个名为WebDAV的标准。它已被进一步扩展用于特定应用程序,如CardDAV处理地址簿条目和CalDAV以处理日历。但所有这些* DAV扩展都有一个缺陷:它们必须由要使用的服务器来实现,这非常复杂。他们在Web领域的使用保持保密。

在2000年,设计了一种使用HTTP的新模式:表示状态转移(或REST)。API引发的操作不再通过新的HTTP方法传达,而仅通过使用基本的HTTP/1.1方法访问特定的URI。这允许任何Web应用程序提供API以允许检索和修改其数据,而不必更新浏览器或服务器:所有需要的内容都通过标准的HTTP/1.1嵌入到网站提供的文件中。REST模型的缺点在于每个网站都定义了自己的非标准RESTful API并对其进行了全面控制; 与客户端和服务器可互操作的* DAV扩展不同。REST风格的API在2010年变得非常普遍。

自2005年以来,Web页面可用的一组API大大增加,其中一些API为特定目的而创建了HTTP协议的扩展(主要是新的特定HTTP标头):

  • 服务器发送的事件,服务器可以将偶然消息推送到浏览器。

  • WebSocket,一种可以通过升级现有HTTP连接来建立的新协议。

放宽Web的安全模型

HTTP独立于Web的安全模型,即同源策略。实际上,当前的Web安全模型是在创建HTTP之后开发的!多年来,通过允许在某些限制条件下取消对这项政策的某些限制,能够变得更加宽容,证明是有用的。服务器使用一堆新的HTTP标头将这些限制解除多少以及何时传送给客户端。这些定义在跨源资源共享(CORS)或内容安全策略(CSP)等规范中。

除了这些大的扩展之外,还添加了许多其他的头文件,有时仅用于实验。值得注意的标题是Do Not Track(DNT)标题来控制隐私X-Frame-Options,或者Upgrade-Insecure-Requests更多的存在。

HTTP/2  - 更高性能的协议

多年来,网页变得越来越复杂,甚至成为应用程序本身。显示的可视媒体数量,增加交互性的脚本的体积和大小也有所增加:通过显着更多的HTTP请求传输更多的数据。HTTP/1.1连接需要以正确的顺序发送请求。理论上,可以使用几个并行连接(通常在5到8之间),带来相当大的开销和复杂性。例如,HTTP流水线已成为Web开发中的资源负担。

在2010年上半年,Google通过实施SPDY实验协议,演示了在客户端和服务器之间交换数据的另一种方式。这引起了在浏览器和服务器上工作的开发人员的兴趣。SPDY定义了响应性的增加,并解决了传输数据重复的问题,成为HTTP/2协议的基础。

HTTP/2协议与HTTP/1.1版本有几个主要区别:

  • 这是一个二进制协议,而不是文本。尽管有这个障碍,但不能再手动读取和创建,现在可以实施改进的优化技术。

  • 它是一个多路复用协议。并行请求可以通过同一个连接处理,消除HTTP/1.x协议的顺序和阻塞约束。

  • 它压缩标题。由于这些请求在一组请求中经常相似,这消除了传输数据的重复和开销。

  • 它允许服务器在需要之前通过称为服务器推送的机制将数据填充到客户端缓存中。

2015年5月正式标准化后,HTTP/2取得了很大的成功。到2016年7月,所有网站有8.7%已经使用它,占所有请求的68%以上。高流量的网站显示了最快的采用率,大大节省了数据传输开销和后续预算。

这种快速采用率很可能是因为HTTP/2不需要适应网站和应用程序:使用HTTP/1.1或HTTP/2对他们来说是透明的。使用最新的服务器与最近的浏览器进行通信足以支持其使用:只需要有限的一组组即可触发采用,并且随着旧版浏览器和服务器版本的更新,使用量自然会增加,而无需其他Web开发者努力。

Post-HTTP/2 evolution

HTTP在HTTP / 2发布后并没有停止发展。与之前的HTTP / 1.x一样,HTTP的可扩展性仍然用于添加新功能。值得注意的是,我们可以引用2016年出现的HTTP协议的新扩展:

  • 支持Alt-Svc允许标识和给定资源的位置分离,允许更智能的CDN缓存机制。

  • 引入Client-Hints允许浏览器或客户端主动将有关其需求或硬件约束的信息传达给服务器。

  • Cookie头文件中引入与安全有关的前缀,现在有助于保证cookie的安全性没有被改变。

HTTP的这种演变证明了它的可扩展性和简单性,解放了许多应用程序的创建并强制采用该协议。现在使用HTTP的环境与20世纪90年代初期的情况完全不同。HTTP的原创设计被证明是一个杰作,它允许Web在四分之一世纪内发展,而不需要哗变。通过修复漏洞,并保持使HTTP获得如此成功的灵活性和可扩展性,采用HTTP / 2为协议提供了光明的未来。

Artikel sebelumnya: Artikel seterusnya: