1. 媒体类型(MIME)Multipurpose Internet Mail Extension 多用途因特网邮件扩展
2.URI (Uniform Resource Identifier) 统一资源标识符,在世界范围内唯一标识并定位信息资源。
3.URL 统一资源定位符, 大部分 URL 都遵循一种标准格式,这种格式包含三个部分。(现在,几乎所有的 URI 都是 URL)
3.1 URL 的第一部分被称为 • 方案(scheme),说明了访问资源所使用的协议类型。这 部分通常就是 HTTP 协议(http://)。
3.2 第二部分给出了服务器的因特网地址(比如,www.joes-hardware.com)。
3.3 其余部分指定了 web 服务器上的某个资源(比如,/specials/saw-blade.gif)
4.URN 统一资源名
URN 是作为特定内容的唯一名称使用 的,与目前的资源所在地无关。使用这些与位置无关的 URN,就可以将资源四处搬 移。通过 URN,还可以用同一个名字通过多种网络访问协议来访问资源。
5. 报文
HTTP 报文是由一行一行的简单字符串组成的。HTTP 报文都是纯文本,不是二进 制代码,所以人们可以很方便地对其进行读写。HTTP 报文包括以下三个部分
- 1.起始行
- 报文的第一行就是起始行,在请求报文中用来说明要做些什么,在响应报文中说 明出现了什么情况。
- 2.首部字段
- 起始行后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值,为 了便于解析,两者之间用冒号(:)来分隔。
- 首部以一个空行结束。添加一个首 部字段和添加新行一样简单。
- 3. 主体
- 空行之后就是可选的报文主体了,其中包含了所有类型的数据。请求主体中包括 了要发送给 Web 服务器的数据;
- 响应主体中装载了要返回给客户端的数据。起 始行和首部都是文本形式且都是结构化的,而主体则不同,主体中可以包含任意 的二进制数据(比如图片、视频、音轨、软件程序)。当然,主体中也可以包含 文本。
6. 连接
6.1 TCP/IP
HTTP 是个应用层协议。HTTP 无需操心网络通信的具体细节;它把联网的细节都 交给了通用、可靠的因特网传输协议 TCP/IP。
- TCP提供了:
- 1.无差错的数据传输;
- 2.按序传输(数据总是会按照发送的顺序到达);
- 3.未分段的数据流(可以在任意时刻以任意尺寸将数据发送出去)。
- 只要建立了 TCP 连接,客户端和服务器之间的报文交换就不会丢失、不会被破坏, 也不会在接收时出现错序了,HTTP 协议位于 TCP 的上层。HTTP 使用 TCP 来传输其报文数 据
6.2 连接、IP 地址及端口号
- (a) 浏览器从 URL 中解析出服务器的主机名;
- (b) 浏览器将服务器的主机名转换成服务器的 IP 地址;
- (c) 浏览器将端口号(如果有的话)从 URL 中解析出来;
- (d) 浏览器建立一条与 Web 服务器的 TCP 连接;
- (e) 浏览器向服务器发送一条 HTTP 请求报文;
- (f) 服务器向浏览器回送一条 HTTP 响应报文;
- (g) 关闭连接,浏览器显示文档
7. Web 的结构组件
- 代理•
- 位于客户端和服务器之间的 HTTP 中间实体。
- 缓存•
- HTTP 的仓库,使常用页面的副本可以保存在离客户端更近的地方。
- 网关•
- 连接其他应用程序的特殊 Web 服务器。
- 隧道•
- 对 HTTP 通信报文进行盲转发的特殊代理。
- Agent 代理•
- 发起自动 HTTP 请求的半智能 Web 客户端
7.1 代理
代理位于客户端和服务器之间,接收所有客户端的 HTTP 请求,并 将这些请求转发给服务器(可能会对请求进行修改之后转发)。对用户来说,这些应 用程序就是一个代理,代表用户访问服务器。
7.2 缓存
Web 缓存(Web cache)或代理缓存(proxy cache)是一种特殊的 HTTP 代理服务 器,可以将经过代理传送的常用文档复制保存起来。客户端从附近的缓存下载文档会比从远程 Web 服务器下载快得多。
HTTP 定义了很 多功能,使得缓存更加高效,并规范了文档的新鲜度和缓存内容的隐私性
7.3 网关
网关(gateway)是一种特殊的服务器,作为其他服务器的中间实体使用。通常用于 将 HTTP 流量转换成其他的协议。网关接受请求时就好像自己是资源的源端服务器 一样。
客户端可能并不知道自己正在与一个网关进行通信。
7.4 隧道
隧道(tunnel)是建立起来之后,就会在两条连接之间对原始数据进行盲转发的 HTTP 应用程序。HTTP 隧道通常用来在一条或多条 HTTP 连接上转发非 HTTP 数 据,转发时不会窥探数据
HTTP 隧道的一种常见用途是通过 HTTP 连接承载加密的安全套接字层(SSL, Secure Sockets Layer)流量,这样 SSL 流量就可以穿过只允许 Web 流量通过的防 火墙了
7.5Agent 代理
用户 Agent 代理(或者简称为 Agent 代理)是代表用户发起 HTTP 请求的客户端程 序。所有发布 Web 请求的应用程序都是 HTTP Agent 代理。到目前为止,我们只提 到过一种 HTTP Agent 代理:Web 浏览器,但用户 Agent 代理还有很多其他类型。
有些自己会在 Web 上闲逛的自动用户 Agent 代理,可以在无人监视的情况下 发布 HTTP 事务并获取内容。这些自动代理的名字通常都很生动,比如 "网络蜘蛛" (spiders)或者 "Web 机器人"(Web robots)
1. 字符限制
1. 状态码
1.1 100~199:信息状态码
1,2 200~299:成功状态码
1.3 300~399:重定向状态码
1.4 400~499:客户端错误状态码
1.5 500~599:服务器错误代码
1. TCP 连接
世界上几乎所有的 HTTP 通信都是由 TCP/IP 承载的,TCP/IP 是全球计算机及网络 设备都在使用的一种常用的分组交换网络分层协议集。客户端应用程序可以打开一 条 TCP/IP 连接,连接到可能运行在世界任何地方的服务器应用程序。一旦连接建 立起来了,在客户端和服务器的计算机之间交换的报文就永远不会丢失、受损或 失序。
1.1 TCP 为 HTTP 提供了一条可靠的比特传输管道。从 TCP 连接一端填入的字节会从另 一端以原有的顺序、正确地传送出来
1.2 TCP 流是分段的、由 IP 分组传送
TCP 的数据是通过名为 IP 分组(或 IP 数据报)的小数据块来发送的。HTTP 就是 "HTTP over TCP over IP" 这个 "协议栈" 中的最顶层 了。其安全版本 HTTPS 就是在 HTTP 和 TCP 之间插入了一个(称为 TLS 或 SSL 的)密码加密层
HTTP 要传送一条报文时,会以流的形式将报文数据的内容通过一条打开的 TCP 连 接按序传输。TCP 收到数据流之后,会将数据流砍成被称作段的小数据块,并将段 封装在 IP 分组中,通过因特网进行传输
每个 TCP 段都是由 IP 分组承载,从一个 IP 地址发送到另一个 IP 地址的。每个 IP 分组中都包括:
一个 IP 分组首部(通常为 20 字节)
一个 TCP 段首部(通常为 20 字节)
一个 TCP 数据块(0 个或多个字节)
IP 首部包含了源和目的 IP 地址、长度和其他一些标记。TCP 段的首部包含了 TCP 端口号、TCP 控制标记,以及用于数据排序和完整性检查的一些数字值。
1.3 保持 TCP 连接的正确运行
在任意时刻计算机都可以有几条 TCP 连接处于打开状态。TCP 是通过端口号来保持 所有这些连接的正确运行的。TCP 连接是通过 4 个值来识别的
<源 IP 地址、源端口号、目的 IP 地址、目的端口号>
这 4 个值一起唯一地定义了一条连接。两条不同的 TCP 连接不能拥有 4 个完全相同 的地址组件值(但不同连接的部分组件可以拥有相同的值)。
1.4 HTTP 事务的时延
与建立 TCP 连接,以及传输请求和响应报文的时间相比,事务处理时间可能 是很短的。除非客户端或服务器超载,或正在处理复杂的动态资源,否则 HTTP 时 延就是由 TCP 网络时延构成的。
HTTP 事务的时延有以下几种主要原因
1. 客户端首先需要根据 URI 确定 Web 服务器的 IP 地址和端口号。如果最近没有对 URI 中的主机名进行访问,通过 DNS 解析系统将 URI 中的主机名转换成一个 IP 地址可能要花费数十秒的时间 3
2. 接下来,客户端会向服务器发送一条 TCP 连接请求,并等待服务器回送一个请 求接受应答。每条新的 TCP 连接都会有连接建立时延。这个值通常最多只有一 两秒钟,但如果有数百个 HTTP 事务的话,这个值会快速地叠加上去。
3. 一旦连接建立起来了,客户端就会通过新建立的 TCP 管道来发送 HTTP 请求。 数据到达时,Web 服务器会从 TCP 连接中读取请求报文,并对请求进行处理。因特网传输请求报文,以及服务器处理请求报文都需要时间
4. 然后,Web 服务器会回送 HTTP 响应,这也需要花费时间。
1.5 TCP 连接的握手时延
TCP 连接握手需要经过以下几个步骤
1. 请求新的 TCP 连接时,客户端要向服务器发送一个小的 TCP 分组(通常是 40 ~ 60 个字节)。这个分组中设置了一个特殊的 SYN 标记,说明这是一个连接请求。
2. 如果服务器接受了连接,就会对一些连接参数进行计算,并向客户端回送一个 TCP 分组,这个分组中的 SYN 和 ACK 标记都被置位,说明连接请求已被接受
3. 最后,客户端向服务器回送一条确认信息,通知它连接已成功建立
2. HTTP 连接的处理
2.1 串行事务处理时延
如果每个事务都需要(串行地建 立)一条新的连接,那么连接时延和慢启动时延就会叠加起来
串行加载的另一个缺点是,有些浏览器在对象加载完毕之前无法获知对象的尺寸, 而且它们可能需要尺寸信息来决定将对象放在屏幕的什么位置上,所以在加载了足 够多的对象之前,无法在屏幕上显示任何内容。在这种情况下,可能浏览器串行装 载对象的进度很正常,但用户面对的却是一个空白的屏幕,对装载的进度一无所知
2.2 并行连接 (通过多条 TCP 连接发起并发的 HTTP 请求)
HTTP 允许客户端打开多条连接,并行地执行多个 HTTP 事务。在 这个例子中,并行加载了四幅嵌入式图片,每个事务都有自己的 TCP 连接:
即使并行连接的速度可能会更快,但并不一定总是更快。客户端的网络带宽不足 (比如,浏览器是通过一个 28.8kbps 的 Modem 连接到因特网上去的)时,大部分 的时间可能都是用来传送数据的。在这种情况下,一个连接到速度较快服务器上的 HTTP 事务就会很容易地耗尽所有可用的 Modem 带宽。如果并行加载多个对象,每 个对象都会去竞争这有限的带宽,每个对象都会以较慢的速度按比例加载,这样带 来的性能提升就很小,甚至没什么提升
而且,打开大量连接会消耗很多内存资源,从而引发自身的性能问题。复杂的 Web 页面可能会有数十或数百个内嵌对象。客户端可能可以打开数百个连接,但 Web 服 务器通常要同时处理很多其他用户的请求,所以很少有 Web 服务器希望出现这样的 情况。一百个用户同时发出申请,每个用户打开 100 个连接,服务器就要负责处理 10 000 个连接。这会造成服务器性能的严重下降。对高负荷的代理来说也同样如此
2.3 持久连接 (重用 TCP 连接,以消除连接及关闭时延)
1.HTTP/1.0+keep-alive 连接
实现 HTTP/1.0 keep-alive 连接的客户端可以通过包含 Connection:Keep-Alive 手部请求讲一条连接保持在打开状态
为避免哑代理问题发生,现代的代理都不能转发 Connection 首部和所有名字出现在 Connection 值中的首部,因此,如果一个代理收到了一个 Connection: Keep-Alive 首部,是不应该
转发 Connection 首部,或所有名为 Keep-Alive 的首部的。另外还有几个不能作为 Connection 首部值列出,也不能被代理转发或作为缓存响应使用的首部。其中包括 Proxy-Authenticate,
Proxy-Connection,Transfer-Encoding 和 Upgrade (盲中继:很多代理只是简单的将字节从一个连接转发到另一个连接中区,不对 Connection 首部进行特殊处理。)
Netscape 通过向代理发送非标准的 Proxy-Connection 扩展首部,而不是官方的 Connection 首部来解决这个问题。如果代理是盲中继,它会将无意义的 Proxy-Connection 首部发给 Web 服务器
服务器会忽略此首部。但如果代理能够理解持久连接的握手动作,就用一个 Connection 首部取代无意义的 Proxy-Connection 首部,然后将其发送给服务器,以收到预期效果。
但是,对有多层次代理的情况 Proxy-Connection 任然无法解决问题
HTTP/1.1 持久连接:HTTP/1.1 逐渐停止了对 keep-alive 连接的支持,用一种明晚持久连接的改进型设计取代了它。与 HTTP/1.0 的 keep-alive 不同,HTTP/1.1 持久连接在默认情况下是激活的。
要在事务处理结束之后将连接关闭,HTTP/1.1 应用程序必须向报文中显示地添加一个 Connection:close 首部。在以前版本中,keep-alive 连接要么是可选的要么根本就不支持。
2.3.1 持久连接的限制和规则
1. 发送了 Connection:close 请求首部之后,客户端就无法在那条连接上发送更多的请求了
2. 如果客户端不想在连接上发送其他请求了,就应该在最后一条请求中发送 Connection:close
3. 只有连接上所以报文都有正确的,自定义报文长度时,也就是,实体主体部分的长度都和相应的 Content-Length 一致,或者是用分块传输编码方式编码的,才能持久保持
4.HTTP/1.1 的代理必须能够分别管理与客户端和服务器的持久连接,每个持久连接都只适用于一跳传输。
5. 由于较老的代理会转发 Connection 首部,所以 HTTP/1.1 的代理服务器不应该与 HTTP/1.0 客户端简历连接
6. 不管 Connection 首部取了什么值,HTTP/1.1 设备都可以在任意时刻关闭连接
7.HTTP/1.1 应用程序必须能够从异步的关闭中恢复出来,只要不存在可能会累积起来的副作用,客户端都应该重试这条请求
8. 除非重复发起请求会产生副作用,否则如果客户端收到整条响应之前连接关闭了,客户端就必须要重新发起请求
9. 一个客户端对任何服务器或代理最多只能维护两条持久连接,以防服务器过载。代理可能需要更多到服务器的连接来支持并发用户的通信,所以如果
有 N 个用户试图访问服务器的话,代理最多要维持 2N 条到任意服务器或父代理的连接
2.4 管道化连接 (通过共享的 TCP 连接发起并发的 HTTP 请求)
HTTP/1.1 允许在持久连接上可选地使用请求管道。这是在 keep-alive 连接上的进一步性能优化。在响应到达之前,可以将多条请求放入队列。当第一条请求通过网络流向另一端的服务器
时,第二条和第三条请求也可以开始发送了。在高时延网络条件下,这样做可以降低网络的环回时间,提高性能。
限制:
1. 如果 HTTP 客户端无法确认连接是持久的,就不应该使用管道
2. 必须按照与请求相同的顺序会送 HTTP 响应。HTTP 报文中没有序列号标签,因此如果收到的响应失序了,就无法与请求匹配
3.HTTP 客户端必须做好连接会在任意时刻关闭的准备,还要准备好重发所有未完成的管道化请求。
4.HTTP 客户端不应该用管道化的方式发送会产生副作用的请求,如 POST。出错的时候管道化方式会阻碍客户端连接服务器执行的是一系列管道化请求中的哪一些。
由于无法安全地重试 POST 这样的非幂等请求,所以出错时,就存在某些方法永远不会被执行的风险
来源: http://www.qdfuns.com/notes/13600/e1699c6fc65b9ed7557ed5171aae5aa6.html