标注：看《HTTP权威指南》所记的笔记，用于防止自己看过又忘记
用户识别机制
- 承载用户身份信息的HTTP首部
- From/User-Agent/Referer
- 客户端IP地址跟踪
- 缺点
- 客户端IP地址描述的是机器不是用户，多个用户共享同一台机器就无法区分
- 用户登录时IP地址是动态分配的
- 用户通过网络地址转换防火墙浏览内容的，隐藏了实际客户端IP地址
- 服务器看到的地址有可能是代理的IP
- 缺点
- 用户登录，用认证方式识别用户
- www-Authenticate 响应首部/Authorization请求首部
- 胖URL(在URL中嵌入识别信息的技术)
- 缺点
- 丑陋的URL
- 无法共享的URL
- 破坏缓存
- 额外的服务器负荷
- 逃逸口
- 在会话期间是非持久的
- 缺点
- cookie
- 识别用户，实现持久会话的最好方式
- 类型
- 会话cookie
- 临时cookie，用户退出浏览器的时候就被删除了
- 设置了Discard参数或者没设置Expires或Max-Age参数
- 持久cookie
- 存储在硬盘。退出重启仍然存在
- 唯一区别是过期时间
- 会话cookie
- Set-Cookie响应首部、Cookie请求首部
认证
- 质询、响应框架的认证协议
- www-Authenticate 响应首部:如何及在哪里认证
- Authorization请求首部:密码和认证参数
- Authentication-Info : 与授权会话相关的附加信息
- 安全域: 不同的资源使用不同权限访问
- 官方认证协议
- 基本认证
- 流程
- 1.客户端请求
- 2.服务器质询
- 响应401和www-Authenticate首部(要求对请求的域进行认证)
- 3.客户端响应
- 用户输入用户名和密码后客户端编码放在Authorization首部返回)
- 4.服务器响应
- 对用户名和密码解码并验证，响应200 OK及客户端请求的报文
- 不会用到Authentication-Info 首部
- 代理认证
- 通过代理服务器对某组织内部资源的统一访问控制
- 优点
- 简单便捷
- 可阻止非恶意用户的无意间访问
- 配合SSL加密技术使用
- 缺陷
- 不安全
- 通过网络发送用户名和密码，很容易解码
- 第三方可以捕获用户名密码重放给原始服务器，获得访问权
- 用户使用习惯使得认证很危险(银行网站和邮件有同样的密码)
- 没有提供对代理和中间节点的防护措施，可以修改报文内容
- 假冒服务器很容易骗过基本认证
- 不安全
- 流程
- 摘要认证
- 改进
- 不会以明文方式发送密码
- 可放在恶意用户捕获并重放认证的握手过程
- 有选择的防止对报文内容的修改
- 防范其他几种常见的攻击方式
- 工作原理
- 1.客户端请求
- 2.服务器质询
- 3.客户端传递密码摘要
- 单向摘要(MD5)
- 计算摘要的时候附加随机数，防止重放攻击(随机数从www-Authenticate首部获取)
- 4.服务器验证并响应请求内容
- 服务器知道所有密码，可以将客户端提供的摘要与自己计算出的摘要进行比较验证
- 核心
- 对公共信息，保密信息和有时限的随机值这个组合的单向摘要
- 几种预授权方式
- 服务器预先在Authentication-Info(这个首部是认证成功才发送)成功首部中发送下一个随机数
- 允许一段时间内使用同一个随机数
- 客户端和服务器使用同步的可预测的随机数生成算法
- 改进
- 基本认证
安全HTTP
- HTTPS
- 在HTTP下面提供了一个传输级的密码安全层(SSL和TLS)，HTTPs将报文发送给TCP之前，先发送给安全层进行加密。
- 所有的HTTP请求和响应在发送到网络之前都要进行加密
- 数字签名
- 加了密的校验和(附加在报文上的特殊加密校验码)
- 好处
- 证明是作者编写了这条报文
- 只有私有密钥才可以计算出校验和
- 防止报文被篡改
- 证明是作者编写了这条报文
- 通常用非对称公开密钥技术产生的
- 数字证书
- 包含了由某个受信任组织担保的用户或公司的先信息
实体和编码
- Content-Length
- 区分报文结束还是报文截尾
- 缓存代理服务器通常不会为没有显式Content-Length首部的http主体做缓存，减小缓存已截尾报文的风险
- 对于持久链接必不可少，因为不能通过连接关闭来判断报文结束
- 分块编码的情况下，可以没有该首部，数据是分一系列块发送，每块都有大小说明。
- 如果实体编码就是编码后的长度
- 没有首部可以说明原始未编码主体长度，客户端难以验证解码过程完整性。
- Content-MD5
- 对实体主体运行MD5算法的结果
- Content-Type
- 说明的是原始主体的媒体类型
- 内容编码
- 和内容的具体格式细节紧密相关
- 过程
- 网站服务器生成原始响应报文，包含原始的Content-Length和Content-Type首部
- 内容编码服务器创建编码后的报文，编码后的报文有同样的Content-Type. 但Content-Length可能不同，编码后的报文增加Content-Encoding首部，接受的应用程序就可以解码
- 接收程序得到编码后的报文，进行解码，获得原始报文
- 客户端用Accept-Encoding告诉服务器自己支持的内容编码方式。如果没有包含该首部，服务器就可以假设客户端接受任何编码方式
- 传输编码
- 与内容格式无关，为了改变报文中的数据在网络上传输的方式
- Transfer-Encoding
- 告知接收方为了可靠传输报文，对其进行何种编码
- TE
- 用在请求首部，告知服务器可以使用哪些传输编码扩展
- 分块编码
- 长度和分块的数据
- 长度值为0表示主体结束
- Trailer
- 列出了跟在分块报文之后的首部列表
- 除了Transfer-Encoding，Trailer，Content-Length首部之外，其他首部都可以作为拖挂发送。
- 规则
- 传输编码集合中必须包括"分块"
- 使用分块传输编码时，它必须是最后一个作用到报文主体上的
- 分块传输编码不能多次作用到一个报文主体上
- 这些规则使得接收方可以确定报文传输长度
- 无法理解经过传输编码的报文，响应501
- 内容编码只是对报文的实体部分进行编码，传输编码作用在整个报文上，报文自身的结构发生了变化
- 有条件的请求
- 避免资源没有改变的情况下发送相同副本浪费网络带宽。
- 仅当资源改变时才请求副本
- 通过以If-开头的有条件的首部实现
- 验证码
- 弱验证码 W/
- 强验证码
- 举例，最后修改时间是弱验证码，Etag是强验证码
- 范围请求
- 允许客户端只请求文档的一部分或者某个范围
- Range:bytes=4000-
- 在点对点文件共享客户端软件广泛应用，他们从不同的对等实体同时下载多媒体文件的不同部分
- Accept-Range：bytes 向客户端说明可以接受的范围请求，首部的值是计算范围的单位
- 范围请求仅当客户端和服务器拥有文档的同一个版本时才会有意义
- 差异编码
- 通过交换对象的改变的部分而不是完整的对象来优化传输性能
- A-IM首部
- 客户端告诉服务器愿意接受该页面的差异
- 可以接受的一些实例操控的类型
- 服务器响应
- 226 状态码
- 告诉客户端发送的是所请求对象的实例操控，不是完整的对象
- IM: 说明使用的何种实例操控
- 新的Etag和Delta-Base说明用于计算差异的基线文档的Etag
- 226 状态码
内容协商
- 客户端驱动的协商
- 客户端来选择哪个页面最适合客户端
- 服务器驱动的协商
- 服务器自动判定
- 内容协商首部集
- 内容协商首部中的质量值
- 透明协商
- 中间代理来选
- Vary首部
- 服务器在响应中发送Vary首部以告知中间点需要使用哪些请求首部进行内容协商
转码
- 服务器没有能满足客户端需求的文档时，可以把现存的文档转换成某种客户端可用的文档
- 格式转换
- 信息综合
- 内容注入
- 转码与静态预生成对比
- 静态预生成会导致某个页面中的任何小改动都牵扯到很多页面，需要很多空间存储不同版本
- 使页面编目和web服务器编程变得更加困难
- 有些转码不能静态实现，比如定向广告插入
Web主机托管
- 对内容资源的存储，协调以及管理的职责统称为web主机托管
- 虚拟主机托管（共享主机托管）
- 专用托管
- 虚拟主机托管正常工作的四种技术
- 通过url路径进行虚拟主机托管
- 路径多余
- 通过端口号进行主机托管
- 用户会不乐意在url指定非标准端口号
- 通过ip地址进行主机托管
- 在计算机系统能绑定的虚拟ip地址有限
- Ip地址是稀缺资源
- 托管者通过复制服务器来增加容量时，ip地址短缺的问题更严重了
- 通过Host首部进行主机托管
- 把主机名（和端口号）放在所有请求的Host首部中传送
- 通过url路径进行虚拟主机托管
- Host首部
- 如果首部不包含端口，使用地址方案中默认的端口
- 如果URL包含IP地址，首部就应当包含同样地址
- 如果URL包含主机名
- 首部必须包含同样名字
- 首部不应当包含url主机名对应的ip地址，因为会扰乱虚拟主机托管服务的工作
- 首部不应当包含主机名的别名
- 如果客户端显式使用代理服务器，客户端必须把原始服务器而不是代理服务器的名字和端口放在Host首部
- 客户端必须在所有请求报文中包含Host首部
- Web代理必须在转发请求报文之前添加Host首部
- 必须用400状态码响应所有缺少Host首部字段的请求报文
- 解释Host首部
- 对于没有进行虚拟主机托管而且不允许资源随请求主机的不同而变化的 原始服务器，可以忽略Host首部字段的值
- 对于资源会随主机名的不同而变化的原始服务器，必须在一条HTTP/1.1请求判断其所请求的资源时使用如下规则
- 如果请求报文中的URL是绝对的（包含方案和主机部分），就忽略Host首部值
- 如果请求报文中的url没有主机部分，而该请求带有Host首部，则主机端口就从首部取
- 如果都无法获取有效主机响应400
重定向
- 大多数重定向部署都包含了某些形式的负载均衡，任意形式的负载均衡都包含了重定向
- 通用的重定向方法
- 将报文重定向到服务器的方法
- HTTP重定向
- 优点
- 知道客户端ip地址
- 缺点
- 需要原始服务器进行大量处理来判断重定向到哪台服务器，有时发布重定向的处理量和提供页面本身所需的处理量几乎一样
- 增加用户时延，因为要两次往返
- 重定向服务器故障站点就会瘫痪
- 优点
- DNS重定向
- DNS轮询
- 负载均衡算法
- 邻接路由算法
- 故障屏蔽算法
- 任播寻址
- IP MAC转发
- MAC地址转发只是点对点，所以服务器或代理只能位于离交换机一跳远的地方
- IP地址转发
- 完全NAT
- 半NAT
- 代理的重定向方法
- 将报文重定向到代理服务器的重定向方法
- 显示浏览器配置
- 缺点
- 配置为使用代理的服务器，即使在代理无法响应的情况下也不会联系原始服务器
- 如果服务提供商要添加更多代理或者使一些退出服务，用户都要修改配置
- 缺点
- 代理自动配置（PAC）
- 浏览器获取一个PAC文件，这个文件说明了每个URL关联的代理
- 必须要对浏览器进行配置，以知道从哪个服务器取PAC文件
- Web Proxy代理自动发现协议(WPAD)
- 在不要求终端用户手工配置代理设置，而且不依赖透明流量拦截的情况下，为浏览器提供一种发现并使用附近代理的方式
- 步骤
- 用WPAD找到PAC文件的CURL
- WPAD算法
- DHCP(动态主机配置协议),
- WPAD客户端向DHCP服务器发送查询获取CURL
- SLP(服务定位协议)
- DNS知名主机名,DNS SRV记录,DNS TXT记录中提供的服务URL
- WPAD客户端会按照顺序用上面的机制发送一系列发现请求，客户端只会尝试它支持的机制，成功则构建CURL，如果获取到PAC文件过程结束，否则从它预定义的资源请求系列里中断的地方恢复，若尝试了所有机制都没有获取到PAC文件，WAPD协议就失败了，客户端会配置成不使用代理服务器
- 基于DNS的机制中会循环多次
- DHCP(动态主机配置协议),
- WPAD算法
- 根据CURL获取PAC文件
- 执行PAC文件确定代理服务器
- 向PAC文件返回的代理服务器发送HTTP请求
- 用WPAD找到PAC文件的CURL
- 显示浏览器配置
- 将报文重定向到代理服务器的重定向方法
- 缓存的重定向方法
- Web缓存协调协议（WCCP）
- 启动包含了一些支持WCCP的路由器和缓存的网络(路由器和缓存之间可相互通信)
- WCCP服务组(一组路由器及目标缓存构成)，服务组的配置说明将何种流量发往何处，如何发送及如何在服务组的缓存之间负载均衡
- 若服务组配置重定向HTTP流量，服务组的路由器就会将HTTP请求发送到服务组的缓存
- HTTP请求到达服务组的路由器时，路由器会选择服务组的某个缓存为请求提供服务
- 路由器向缓存发送分组，可以用IP地址或者IP MAC转发封装分组
- 如果缓存无法提供服务，就将分组返回给路由器进行普通转发
- 服务组的成员会互相交换心跳报文，不断验证对方可用性
- 因特网缓存协议（ICP）
- 允许缓存在其兄弟缓存中查找命中内容(如果自己没有)
- squid支持ICP
- 缓存分组路由协议（CARP）
- 与ICP对比
- CARP协议允许将一组代理服务器看成单个的集群缓存，ICP是一组相互合作又相互独立的缓存服务器
- CARP确定请求解析路径会在一跳之内找到某个特定的Web对象的家，降低ICP在一组代理服务器中查找web对象时产生的代理间流量
- CARP避免在不同的代理服务器上存储Web对象多个副本的问题, 使缓存系统集群的Web对象存储容量较大，但是任意一个代理故障都要改写现存代理的部分缓存内容
- 与ICP对比
- 超文本缓存协议（HTCP）
- 允许兄弟缓存之间通过所有URL和所有的请求及相应首部来相互查询文档是否存在，以降低错误命中的可能，而且HTCP允许兄弟缓存监视或请求在对方的缓存中添加删除所选中的文档，并修改对方已缓存文档的缓存策略
- Web缓存协调协议（WCCP）
2843
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
