Web and http
一些术语
- Web页:由一些对象组成
- 对象可以是HTML文件、JPEG图像,JAVA小程序,声音剪辑文件等
- Web页含有一个基本的HTML文件,该基本HTML文件又包含若干对象的引用(链接)
- 通过URL对每个对象进行引用
- 访问协议:用户名、口令字、端口等
- URL格式:
Port://user:psw@www.someSchool.edu/someDept/pic.gif:port
路径元素 | 含义 |
---|---|
Port | 协议名 |
user | 用户 |
psw | 口令 |
www.somSchool.edu | 主机名 |
someDept/pic.gif | 路径名 |
port | 端口 |
用户口令可以不提供,即匿名访问
端口不填可以是默认的:http-80,ftp-21
HTTP概况
HTTP:超文本传输协议
- Web的应用层协议
- 用户/服务器模式
- 客户:请求、接收和显示Web对象的浏览器
- 服务器:对请求进行响应,发送对象的Web服务器
- HTTP 1.0: RFC 1945
- HTTP 1.1: RFC 2068
使用TCP
- 客户发起一个与服务器的TCP连接(建立套接字),端口号为80
- 服务器接受客户的TCP连接
- 在浏览器(HTTP客户端)与Web服务器(HTTP服务器server)交换HTTP报文(应用层协议报文)
- TCP连接关闭
HTTP是无状态的
- 服务器并不维护关于客户的任何信息
维护状态的协议很复杂
- 必须维护历史信息(状态)
- 如果服务器/客户端死机,他们的状态可能不一致,二者的信息必须一致
- 无状态的服务器能够支持更多的客户端
HTTP连接
非持久HTTP
- 最多只有一个对象在TCP连接上发送
- 下载多个对象需要多个TCP连接
- HTTP/1.0使用非持久连接
持久HTTP
- 多个对象可以在一个(在客户端和服务器之间的)TCP连接上传输
- HTTP/1.1默认使用持久连接
非持久HTTP连接
响应时间模型
往返时间RTT:一个小的分组从客户端到服务器,在回到客户端的时间(传输时间忽略)
响应时间
- 一个RTT用来发起TCP连接
- 一个RTT用来HTTP请求并等待HTTP响应
- 文件传输时间
共:2RTT + 传输时间
持久HTTP
非持久HTTP的缺点
- 每个对象要 2 个RTT
- 操作系统必须为每个TCP连接分配资源
- 但浏览器通常打开并行TCP连接,以获取引用对象
持久HTTP
- 服务器在发送响应后,仍保持TCP连接
- 在相同客户端和服务器之后的后续请求和响应报文通过相连的连接进行传送
- 客户端在遇到一个引用对象的时候,就可以尽快发送该对象的请求
非流水方式的持久HTTP
- 客户端只能在收到前一个响应后才能发出新的请求
- 每个引用对象花费一个RTT
流水方式的持久HTTP
- HTTP/1.1的默认模式
- 客户端遇到一个引用对象就立即产生一个请求
- 所有引用(小)对象只花费一个RTT是可能的
HTTP请求报文
- 两种类型的HTTP报文:请求、响应
HTTP请求报文
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
A***ept-language:fr
解析报文如下:
部分 | 举例 | 说明 |
---|---|---|
请求行 | GET /somedir/page.html HTTP/1.1 | 命令: GET:获取数据;POST:上载数据;HEAD:仅仅获取相应头部,搜索引擎使用改命令得到头部之后建立索引资源路径:/somedir/page.html 协议/协议版本:HTTP/1.1
|
首部行 | Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close A***ept-language:fr | |
实体 |
HTTP请求报文:通用格式
sp是space空格
cr是回车
if是有可能有,有可能没有
提交表单输入
Post方式
- 网页通常包括表单输入
- 包含在实体主体中的输入被提交到服务器
URL方式
- 方法:GET
- 输入通过字段请求行的URL字段上载
方法类型
HTTP 1.0
- GET
- POST
-
HEAD
- 要求服务器咋响应报文中不包含请求对象 -> 故障跟踪
HTTP 1.1
- GET、POST、HEAD
-
PUT
- 将实体主体中的文件上载到URL字段限定的路径
-
DELETE
- 删除URL字段限定的文件
HTTP响应报文
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
解析:
部分 | 举例 | 说明 |
---|---|---|
状态行 | HTTP/1.1 200 OK | HTTP/1.1是协议及版本,200是状态码,OK是状态码相应状态信息 |
首部行 | Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …… Content-Length: 6821 Content-Type: text/html | |
数据 | data data data data data … |
HTTP响应状态码
位于服务器 -> 客户端的响应报文中的首行
一些状态码的例子
状态码 | 状态信息 | 说明 |
---|---|---|
200 | OK | 请求成功,请求对象包含在响应报文的后续部分 |
301 | Moved Permanently | 请求的对象己经被永久转移了;新的URL在响应报文的Location:首部行中指定;客户端软件自动用新的URL去获取对象 |
400 | Bad Request | 一个通用的差错代码,表示该请求不能被服务器解读 |
404 | Not Found | 请求的文档在该服务上没有找到 |
505 | HTTP version Not supported | 版本不支持 |
用户-服务器状态:cookies
大多数主要的门户网站使用cookies
4个组成部分
- 在HTTP响应报文中有一个cookie的首部行
- 在HTTP请求报文含有一个cookie的首部行
- 在用户端系统中保留有一个cookie文件,由用户的浏览器管理
- 在Web站点有一个后端数据库
Cookies:维护状态
Cookies能带来什么
- 用户验证
- 购物车
- 推荐
- 用户状态
如何维持状态
- 协议端节点:在多个事务上,发送端和接收端维持状态
- cookies:http报文携带状态信息
Cookies与隐私
- Cookies允许站点知道许多关于用户的信息
- 可能将他知道的东西卖给第三方
- 使用重定向和cookie的搜索引擎还可能知道用户的更多信息
- 广告公司从站点获得信息
Web缓存(代理服务器)
目标:不访问原始服务器,就满足客户的请求
- 用户设置浏览器:通过缓存访问Web
- 浏览器将所有的HTTP请求发送给缓存:
- 在缓存中的对象:缓存直接返回对象
- 如对象不在缓存:缓存请求原始服务器,然后再将对象返回给客户端
Web缓存
- 缓存既是客户端又是服务器
- 通常缓存是由ISP安装
为什么要使用Web缓存
- 降低客户端的请求响应时间
- 可以大大减少一个机构内部网络与Inter***接入链路上的流量
- 互连网大量采用了缓存:可以使较弱的ICP也能够有效提供内容
缓存示例
条件
- 平均对象大小 = 100kb(也就是请求的文件的平均大小是100kb)
- 机构内浏览器对原始服务器的 平均请求率为 = 15请求/s
- 平均到浏览器的速率:1.5Mbps(100kb * 15请求/s)
- 接入链路带宽:1.54Mbps
相关数据计算:
-
各种延时计算(Inter***延时、接入延时、LAN延时)
-
延时如下:
- Inter***延时:公共网(public Inter***)路由器到原始服务器 再返回到路由器的的延时 ( Inter*** 延时)= 2s;这个也是网络核心的延时吧
- 接入延时:不确定,不过有公式:接入延时(主要还是排队延时) d q u e u e d_{queue} dqueue = I(1-I) * L / R = 2min
- LAN延时:客户端到LAN路由器再返回客户端的时间,为10ms
-
流量强度和排队延时计算:
- 流量强度 I = 平均到达浏览器的速率 / 接入链路宽带
- 排队延时 = t q u e u e t_{queue} tqueue = I(1-I) * L / R
- L/R:一个分组的传输时间
-
结果:
- LAN的流量强度 = 15%
- 接入链路上的流量强度 = 99% (排队延迟会非常大,排队延迟会随着分组的流量强度越接近于1趋近于无穷,此时排队延迟会非常大)
- 总延时= LAN延时+ 接入延时+ Inter*** 延时 = ms + 分+ 2s
流量强度 = 平均到达浏览器的速率 / 接入链路宽带 = 1.5 / 1.54 = 0.99
优化方式
-
提高接入链路带宽
- 假设:
- 平均对象大小 = 100kb
- 机构内浏览器对原始服务器的 平均请求率为 = 15请求/s
- 平均到浏览器的速率:1.5Mbps
- 接入链路带宽:1.54Mbps——> 154Mbps(带宽提升)
- 延时:
- Inter***延时机构内部路由器到原始服务器 再返回到路由器的的延时 = 2s
- LAN延时:客户端到LAN路由器再返回客户端的时间,为10ms
- 结果:
- LAN的流量强度 = 15%
- 接入链路上的流量强度 = 9.9%(可以看到强度降低了很多,排队延时也会下降)
- 总延时 = LAN延时 + 接入延时 + Inter*** 延时 = ms + 分 + 2s
- 代价: 增加了接入链路带宽(非常昂贵!)
- 假设:
-
安装本地缓存
- 假设:
- 平均对象大小 = 100kb
- 机构内浏览器对原始服务器的平均 请求率为 = 15请求/s
- 平均到浏览器的速率:1.5Mbps
- 机构内部路由器到原始服务器再返回到路由器的的延时 (Inter*** 延 时)= 2s
- 接入链路带宽:1.54Mbps
- 结果:
- LAN 利用率: 15%
- 接入网络利用率: ?
- 总体延迟= ? 代价: web缓存(廉价!)
- 假设:
计算链路利用率,有缓存的延迟:
- 假设:
- 缓存命中率0.4:40%请求在缓存中被满足,其他60%的请求 需要被原始服务器满足
- 接入链路利用率: 60%的请求采用接入链路
- 进过接入链路到达浏览器的数据速 率 = 0.6*1.50 Mbps = 0.9 Mbps
- 利用率= 0.9/1.54 = 0.58
- 总体延迟 = 0.6 * (从原始服务器获取对象的 延迟,也就是接入延时 + Inter***延时) +0.4 * (从缓存获取对象的延迟,也就是LAN延时) = 0.6 * (2s) + 0.4 * (msecs,这个很小,所以几乎不看了) = 1.2 secs
- 比安装154Mbps链路还来得小 (而且 比较便宜!)
条件GET方法
- 目标:如果缓存器中的对 象拷贝是最新的,就不要发送对象
- 缓存器: 在HTTP请求中指 定缓存拷贝的日期
If-modified-since:<date>
- 服务器: 如果缓存拷贝陈 旧,则响应报文没包含对象:
HTTP/1.0 304 Not Modified