您的位置: 首页  >  文章  >  图解HTTP笔记

图解HTTP笔记

分类: 文章 • 2024-07-17 22:32:16

uint01

URI 统一资源标识符 P16

  • URI就是某个协议方案表示的资源的定位标识符 协议方案是指访问资源时所使用的协议类型名称
  • URI用字符串表示某一互联网资源 而URL表示资源的地点(互联网上的位置) 可见URL是URI的子集
  • 表示指定的URI要使用涵盖全部必要信息的绝对URI-绝对URL-相对URL(是指从浏览器基本URI处指定的URL)
    图解HTTP笔记

unit02

HTTP是不保存状态(stateless)的协议可以利用cookie管理状态

  • get 获取资源
  • post 传输实体主体 虽然get也可以传递实体的主题但是一般不这么做
  • put 传输文件
  • head 与get类似但是不返回报文主题部分 可以用来查询URL有效性和更新日期等其他信息
  • delete 删除文件
  • option 询问支持的方法
  • trace 追踪路径
  • connect 要求用隧道协议连接代理 要求与代理服务器通信时建立隧道主要使用SSl和TLS

持久连接

  • 初始的http每进行一次http通信就断开一次tcp连接
  • 持久连接 任意一端没有明确提出断开连接 则保持tcp连接
    • 可以减少tcp的连接和断开的开销
    • 持久连接可以使请求以管线化方式(pipelining)发送成为可能 从前发送请求后需要等待收到响应后才能发送下一个请求 管线化技术可以不需要等待就可以直接发送下一个请求

使用cookie可以管理状态

unit03

HTTP报文由报文首部和报文主体两块组成 由第一个换行(CR+LF)来划分

请求报文首部
- 请求行
- 请求首部字段
- 通用首部字段
- 实体首部字段
- 其他

响应报文首部
- 响应行
- 响应首部字段
- 通用首部字段
- 实体首部字段
- 其他

分块传输编码(Chunked Transfer Coding)

  • 在传输大量数据时 通过把数据分割成多块 可以让浏览器逐步显示页面

内容协商返回最合适的内容(比如语言等)

  • 服务器驱动协商 服务器根据请求首部的字段自动处理
  • 客户端驱动协商 客户端自己从选项列表中手动选择 比如显示是PC页面还是手机页面
  • 透明协商 上面两者结合

unit04

关于返回码说明

  • 1xx 信息状态码(接受的请求正在处理)
  • 2xx 成功状态码(请求正常处理完毕)
  • 3xx 重定向状态码(需要进行附加操作完成请求)
  • 4xx 客户端错误状态码(服务器无法处理请求)
  • 5xx 服务器错误状态码(服务器处理请求出错)

unit05

通信数据转发程序

  • 代理
    • 缓存代理
    • 透明代理(不对报文做任何加工 反之称为非透明代理)
  • 网关
    • 与代理十分类似但是网关可以提供非HTTP协议服务
  • 隧道
    • 可以使用SSL等加密手段

unit06

http首部字段自行翻阅书籍

unit07

HTTP主要不足

  • 通信使用明文不加密 可能会被窃听
    • tcp是可能被窃听的网络 通信内容在所有的通信线路上都可能被窃取
    • 就算是经过加密的报文信息 也只能是可能无法被** 而经过加密的报文本身也是可见的
    • 加密处理防止被窃听
      • 通信加密 SSL TLS
      • 内容加密(仍有篡改风险)
  • 不验证通信方的身份 可以遭遇伪装
    • 任何人可以发起请求
    • 查明对手的证书
  • 无法验证报文的完整性 可能遭到篡改
    • 接收到的内容可能有误
    • 如何防止篡改
      • MD5 SHA-1 PGP 等方法
      • 但是这些验证方法也没有办法百分百确认结果正确 因为PGP和MD5本身也可能被改写

HTTPS=HTTP+加密+认证+完整性保护 HTTPS是披着SSL的HTTP 通常HTTP直接和TCP通信 使用SSL时则 HTTP与SSL通信 SSL与TCP通信 SSL是独立的协议 SMTP 和 Talent 等协议均可以配合 SSL 协议使用 SSL可以说是广泛应用的网络安全技术

  • 共享**
    • 加密和解密用同一个**的方式称为共享**加密
    • 问题在于如何将**发送给对方
  • 使用两把**的公开**加密
    • 公开**加密使用一对非对称的** 一个私有**一把公开**
    • 发送方使用公开**进行加密 接收方使用私有**进行解密
    • 问题在于无法证明公开**本身就是货真价实的公开** ------ 使用数字证书认证机构解决这个问题
      • 服务器运营人员向数字证书认证机构提出公开**的申请
      • 数字证书认证机构验证申请者的身份之后 对申请的公开**进做数字签名 然后分配这个已签名的公开** 并将开公开**放入公钥证书后绑在在一起
      • 总结1 数字证书认证机构将公开**放入公钥证书然后与该公开**的数字签名绑定在一起
      • 然后服务器将这个公钥证书发送给客户端
      • 接收证书的客户端可以使用数字证书认证机构的公开**对那张证书上的数字签名进行验证 验证通过既OK
      • 总结2客户端收到证书后向数字证书认证机构进行验证
      • 问题如何将证书发送给客户端 如果使用通信那么是同样的问题 安全转交很困难 因此大多数浏览器事先在内部会植入常用认证机关的公开**

HTTPS采用混合加密机制

  1. 使用公开**安全的交换后面需要的共享**
  2. 用第一步的共享**进行加密通信

用以确认客户端的客户端证书
以客户端证书进行客户端确认 证明服务器正在通信的对方始终是预料之内的客户端 其作用和服务器证书如出一辙

  • 问题
  • 证书的获取和发布 户端证书一般需要用户自行安装 并且客户端证书大多需要付费 比如网银哈哈
  • 证书只能证明客户端实际存在 不能证明用户本人的真是有效

认证机构一旦被黑客黑进去 gg

使用OpenSSL可以构建一套属于自己的认证机构从而可以自己给自己颁发服务器证书 P159
HTTPS的安全通信机制 P161

后面的不写拉拉

相关推荐