Ai.Haibara
Ai.Haibara codes
HomeProjectsTalksBlogs

《图解Http》 阅读记录

1. TCP/IP 协议族

不同的硬件、操作系统之间的通信, 所有的一切都需要一种规则. 而我们就将这种规则称为协议( protocol ). 协议中存在着各种各样的内容, 像这样把互联网相关的协议集合统称为 TCP/IP.

TCP/IP 的分层管理

  1. 应用层 决定了向用户提供应用服务时的通信的活动. http 协议处于该层.

  2. 传输层 为上层应用层提供了处于网络连接中的两台计算机之前的数据传输. TCP 协议以及 UDP 协议.

  3. 网络层 处理在网络上流动的数据包. 改成规定了通过怎样的路径(传输路线)到达对方计算机, 并将数据包传输给对方.

  4. 链路层 硬件相关, 例如设备驱动、网卡、光纤等.

TCP/IP 通信传输流

alt

与 Http 密切相关的协议: IP、TCP 以及 DNS

alt

URI 和 URL

URI 用字符串标识某一互联网资源, URL 表示资源的地点. URL 属于 URI 的子集.

URI 格式:

ftp://user:pass@127.0.0.1:8181/URI/test.txt
http://www.exapmle.com:80/dir/index.html?uid=1#ch=1

具体每项信息如下图:

alt

2. 简单的 Http 协议

HTTP 协议用于客户端和服务端之间的通信

http 协议规定, 请求从客户端发出, 最后服务端响应该请求并返回. 换句话说, 肯定是先从客户端开始建立通信, 服务端在没有接收到请求之前不会发送响应.

举个栗子:

alt

下面是从客户端发送给某个 HTTP 服务端的请求报文内容.

Get /index.html HTTP/1.1

其表示为 请求访问某台 HTTP 服务器上的 /index.html 页面资源. 请求报文是由请求方法(GET), 请求 URI (/index.html) 、协议版本(HTTP/1.1)、可选的请求首部字段和内容实体构成的.

alt

HTTP 是一种无状态协议

HTTP 协议自身不对请求和响应之间的通信状态进行保存. 使用 HTTP 协议时, 每当有新的请求发送时, 就会有对应的新响应产生, 协议本身并不会保留之前一切的请求或响应报文的信息. 这是为了更快的处理大量事务, 确保协议的可伸缩性.

随着 Web 的不断发展, 因无状态而导致业务处理变得棘手的情况增多了, 例如保存用户的登录状态. 为了实现期望的保持状态功能, 于是引入了 Cookie 技术. 有了 Cookie 后便可以管理状态了.

Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态.

Cookie 会根据从服务端发送的响应报文内的一个名为 Set-Cookie 的首部字段信息, 通知客户端保存 Cookie. 当下次客户端再往该服务发送请求时, 客户端会自动在请求报文中加入 Cookie 值后发送出去. 服务端发现客户端发送过来的 Cookie 后, 回去检查究竟是从哪一个客户端发来的连接请求, 然后对比服务器上的记录, 最后得到之前的状态信息.

alt

  • 请求报文(没有 Cookie 信息的状态)
Get /reader/ HTTP/1.1
Host: localhost:3000
  • 响应报文(服务端生成 Cookie 信息)
HTTP/1.1 200 OK
Date: Thu, 12 Jul 2022 07:12:20 GMT
Server: Apache
<Set-Cookie: sid=18872608917; path=/; expires=Web, =>
10-Oct-12 07:12:20 GMT>
Content-Type: text/plain; charset=UTF-8
  • 请求报文(自动发送保存着的 Cookie 信息)
Get /image/ HTTP/1.1
Host: localhost:3000
Cookie: sid=18872608917

HTTP 的持久连接

HTTP 协议的初始版本中, 每进行一次 HTTP 通信后都需要断开一次 TCP 连接. 当传输的容量很小时, 这样设计也不会有太大的问题. 可随着 HTTP 的普及, 文档中包含大量图片的情况多了起来. 这样每次的请求都会造成无谓的 TCP 连接建立和断开, 增加通信量的开销.

alt

持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销, 减轻了服务端的负载. 另外, 减少开销的那部分时间, 使 HTTP 请求和响应能够更早的结束, 这样 Web 页面的现实速度也就相应的提高了. 在 HTTP/1.1 中, 所有的连接默认都是持久连接.

持久连接使得多数请求以管线化(pipelining)方式发送成为可能. 从前发送请求后需等待并收到响应, 才能发送下一个请求. 管线化技术出现后, 不用等待响应亦可直接发送下一个请求.

HTTP 报文内的 HTTP 信息

HTTP 报文

用于 HTTP 协议交互的信息被称为 HTTP 报文. 请求端(客户端)的 HTTP 报文叫做请求报文, 响应端(服务端)的叫做响应报文. HTTP 报文本身是由多行数据构成的字符串文本.

请求报文以及响应报文的结构

alt

alt

请求报文和响应报文的首部内容由以下数据组成.

  • 请求行: 包含用于请求的方法, 请求 URI 和 HTTP 版本.
  • 状态行: 包含表明响应结果的状态码, 原因短语和 HTTP 版本.
  • 首部字段: 包含表示请求和响应的各种条件和属性的各类首部

编码提升传输速率

HTTP 在传输数据时可以按照数据原貌直接传输, 但也可以在传输过程中通过编码提升传输速率. 通过在传输时便吗, 能有效地处理大量的访问请求. 但是, 编码的操作需要计算机来完成, 因此会消耗更多的 CPU 等资源.

  1. 压缩传输的内容编码

  2. 分割发送的分块传输编码

发送多种数据的多部分对象集合

HTTP 协议中采纳了多部分对象集合, 发送的一份报文主体哪颗含有多类型实体. 通常是在图片或文本文件等上传时使用.

  • multipart/form-data: 在 Web 表单文件上传时使用
  • multipart/byteranges: 状态码 206(Partial Content, 部分内容)响应报文包含了多个范围的内容时使用

返回结果的 HTTP 状态码

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status

与 HTTP 协作的 Web 服务器

一台 Web 服务器可搭建多个独立域名的 Web 网站, 也可作为通信路径上的中转服务器提升传输效率.

单台虚拟主机实现多个域名

HTTP/1.1 规范允许一台 HTTP 服务器搭建多个 Web 站点. 即使物理层面只有一台服务器, 但只要使用虚拟主机的功能, 则可以假象已具有多台服务器.

客户端使用 HTTP 协议访问服务器时, 会经常采用类似 www.hackkr.jp 这样的主机名和域名.

在互联网上, 域名通过 DNS 服务映射到 IP 地址(域名解析)之后访问目标网站. 可见, 当请求发送到服务器时, 已经是以 IP 地址形式访问了.

所以, 如果一台服务器内托管了 www.tricorder.jp 和 www.hackr.jp 这两个域名, 当收到请求时就需要弄清楚究竟要访问哪个域名.

alt

在相同的 IP 地址下, 由于虚拟主机可以寄存多个不同主机名和域名的 Web 网站, 因此在发送 HTTP 请求时, 必须在 Host 首部内完整指定主机名或域名的 URI.

通信数据转发程序: 代理、网关、隧道

HTTP 通信时, 除客户端和服务器以外, 还有一些用于通信数据转发的应用程序, 例如代理、网关和隧道. 他们可以配合服务器工作.

代理

代理是一种有转发功能的应用程序, 它扮演了位于服务器和客户端 “中间人” 的角色, 接收由客户端发送的请求并转发给服务器, 同时也接收服务器返回的响应并转发给客户端.

alt

代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器. 代理不改变请求 URI, 会直接发送给前方持有资源的目标服务器. 持有资源实体的服务器被称为源服务器. 从源服务器返回的响应经过代理服务器后再传给客户端.

使用代理服务器的理由: 利用缓存技术减少网络带宽的流量, 组织内部针对特定网站的访问控制, 以获取访问日志为主要目的等等.

代理有多种使用方法, 按两种基准分类

  1. 缓存代理

    代理转发响应时, 缓存代理(Catching Proxy)会预先将资源的副本缓存在代理服务器上. 当代理再次接收到对相同资源的请求时, 就可以不从源服务器那里获取资源, 而是将之前缓存的资源作为响应返回.

  2. 透明代理

    转发请求或响应时, 不对报文做任何加工的代理类型被称为透明代理(Transparent Proxy). 反之, 对报文内容进行加工的代理被称为非透明代理.

网关

网关是转发其他服务器通信数据的服务器, 接收从客户端发送来的请求时, 它就像自己拥有资源的源服务器一样对请求进行处理. 有时可能客户端都不会察觉, 自己的通信目标是一个网关.

alt

网关的工作机制和代理十分相似. 而网关能使通信线路上的服务器提供非 HTTP 协议服务. 利用网关能提高通信的安全性, 因为可以在客户端与网关之间的通信路上加密以确保连接的安全. 比如, 网关可以连接数据库, 使用 SQL 语句查询数据.

隧道

隧道实在相隔甚远的客户端和服务器两者之前进行中转, 并保持双方通信连接的应用程序.

alt

隧道可按要求建立起一条与其他服务器的通信线路, 届时使用 SSL 等加密手段进行通信. 隧道的目的是确保客户端能与服务器进行安全的通信. 隧道本身不会去解析 HTTP 请求. 也就是说, 请求保持原样中转给之后的服务器. 隧道会在通信双方断开连接时结束.

保存资源的缓存

缓存是指代理服务器或客户端本地磁盘内保存的资源副本. 利用缓存可减少对源服务器的访问, 因此也就节省了通信流量和通信时间.

缓存服务器是代理服务器的一种, 并归类在缓存代理类型中. 换句话说, 当代理转发从服务器返回的响应时, 代理服务器将会保存一份资源的副本.

alt

缓存服务器的优势在于利用缓存可避免多次从源服务器转发资源. 因此客户端可就近从缓存服务器上获取资源, 而源服务器也不必多次处理相同的请求了.

缓存的有效期限

即便缓存服务器内有缓存, 也不能保证每次都会返回对同资源的请求. 因为这关系到被缓存的有效性问题. 当遇上源服务器上的资源更新时, 如果还是使用不便的缓存, 那就会演变成返回更新前的旧的资源. 即使存在缓存, 也会因为客户端的要求、缓存的有效期限等因素, 向源服务器确认资源的有效性. 若判断缓存失效, 缓存服务器将会再次从源服务器上获取新的资源.

alt

客户端的缓存

缓存不仅可以存于缓存服务器内, 还可以存在客户端浏览器中. 客户端缓存一般被称为 临时网络文件(Temporary Internet File).

浏览器缓存如果有效, 就不必再向服务器请求相同的资源了, 可以直接从本地磁盘累读取. 另外, 和缓存服务器相同的一点是, 当判定缓存过期后, 会向源服务器确认资源的有效性. 若判断浏览器缓存失效, 浏览器会再次请求新资源.

alt

HTTP 首部

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers

确保 Web 安全的 HTTPS

在 HTTP 协议中可能存在信息窃听或身份伪装等安全问题. 使用 HTTPS 通信机制可以有效的防止这些问题.

HTTP 的缺点

  • 通信使用明文(未加密), 内容可能遭到窃听
  • 不验证通信方的身份, 因此可能遭遇伪装
  • 无法证明报文的完整性, 所有有可能已遭篡改

通信使用明文可能会被窃听

由于 HTTP 本身不具备加密的功能, 所以也无法做到对通信整体进行加密. 即 HTTP 报文使用明文的方式发送.

TCP/IP 是可能被窃听的网络

为什么通信时不加密是一个缺点? 这是因为按 TPC/IP 协议族的工作机制, 通信内容在所有的通信路线上都有可能遭到窥视.

即使已经过加密处理的通信, 也会被窥视到通信内容, 这点和未加密的通信是相同的. 只是说如果通信经过加密, 就有可能让人无法破解报文信息的含义, 当加密处理后的报文信息本身还是会被看到.

alt

窃听相同段上的通信并非难事. 只需要收集在互联网上流动的数据包(帧)即可. 对于收集来的数据包的解析工作, 可交给抓包(Packet Capture) 或嗅探器(Sniffer) 工具.

加密处理防止被窃听

  1. 通信加密

    HTTP 协议中没有加密机制, 但可以通过 SSL(Secure Socket Layer, 安全套接层)或 TLS(Transport Layer Security, 安全层传输协议)的组合使用, 加密 HTTP 的通信内容. 用 SSL 建立安全通信路线之后, 就可以在这条线路上进行 HTTP 通信了. 与 SSL 组合使用的 HTTP 被称为 HTTPS(HTTP Secure, 超文本传输安全协议) 或 HTTP over SSL.

  2. 内容加密

    对 HTTP 协议传输的内容本身加密, 即将 HTTP 报文里包含的内容进行加密处理(对报文主机进行加密, 报文首部信息未加密处理). 为了做到有效的内容加密, 前提是要求客户端和服务器同时具备加密和解密机制. 主要应用在 Web 服务中. 由于该方式不同于 SSL 或 TLS 将整个通信路线加密处理, 所以内容仍有被篡改的风险.

不验证通信方的身份可能遭遇伪装

HTTP 协议中的请求和响应不会对通信方进行确认. 也就是说存在 “服务器是否就是发送请求中 URI 真正指定的主机, 返回的响应是否真的返回到实际提出请求的客户端” 等问题.

  1. 任何人都可以发起请求

    服务器只要接收到请求, 不管对方是谁都会返回一个响应(但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下), 因此会存在以下隐患

    • 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器. 有可能是已伪装 Web 服务器.
    • 无法确定响应返回到的客户端是否是按真实意图接收响应的客户端. 有可能是已伪装的客户端.
    • 无法确定正在通信的对方是否具备访问权限. 因为某些 Web 服务器上保存着重要信息, 只想发给特定用户通信的权限.
    • 无法判定请求时来自何方、出自谁手.
    • 即使是无意义的请求也会照单全手, 无法阻止海量请求下的 Dos 攻击(Denial of Service, 拒绝服务攻击).

  2. 查明对手的证书

    虽然使用 HTTP 协议无法确定通信方, 但如果使用 SSL 则可以. SSL 不仅提供加密信息, 而且还使用了一种被称为证书的手段, 可用于确定对方身份. 证书由值的信任的第三方机构颁发, 用以证明服务器和客户端是实际存在的. 另外, 伪造证书从技术角度来说是一场困难的一件事情.

    alt

无法证明报文完整性

所谓完整性是指信息的准确度. 若无法证明其完整性, 通常也就意味着无法判断信息是否准确. 仅靠 HTTP 确保完整性是非常苦难的, 因此通过和其他协议组合来实现防止第三方的篡改.