《图解 HTTP》 摘要一

Posted 2021-02-20 believe-oneself

• 学习过程对书本的内容的摘要以及总结，逐步完善，带有个人理解成分。

---

Web 及网络基础

使用 HTTP 协议访问 Web

• 客户端：通过获取请求获取服务资源的 Web 浏览器等
• HTTP 全称：HtyperText Transfer Protocol
• WWW 全称：Wrold Wide Web
• SGML 标准通用标记语言 全称：Standard Generalized Markup Language

网络基础 TCP/IP

• TCP/IP 协议族，或指TCP、IP
• 协议族常见协议：TCP、UDP、IP、PPPoE、DNS、SNMP、ICMP 等

TCP/IP 的分层管理

分为四层：应用层、传输层、网络层、数据链路层

应用层

• 决定了向用户提供应用服务时通信的活动
• 预存了各类通用的应用服务。如：DNS、FTP
• HTTP 协议也在该层

传输层

• 对上层应用层，提供处于网络连接中的两台计算机之间的数据传输协议
• TCP、UDP在其中

网络层（网络互连层）

• 处理网络上的流动数据包。
• 数据包：网络传输的最小单位。
• 规定了通过了怎样的传输路径（传输路线）到达对方的计算机，并把数据包给对方。

链路层（数据链路层、网络接口层）

• 处理连接网络的硬件部分。
• 例如：控制操作系统、硬件的设备驱动、光纤等，硬件范围。

TCP/IP 通信传输流

• 发送端：应用层往下走。接受端相反
• 发送端：层与层之间传输数据的时候会把对应的首部信息打上。反之消去首部。
• 把数据包装起来的做法叫封装。

与 HTTP 密切相关的协议：IP、TCP 和 DNS

负责传输的 IP 协议

• IP：Internet Protocol 位于网络层的网际协议。
• 把各自数据包传送给对方。
• 要保证确实传输到对方那里，需要满足各类条件。其中两个重要的是：IP 地址和 MAC 地址（Media Access Control Address）。IP 地址指明了节点被分配的地址，MAC 地址是指网卡所属的固定地址。
• IP 地址可和 MAC 地址相互匹配，IP 地址可变换， MAC 地址基本上不会更改。

使用ARP协议（Address Resolution Protrocol）协议

• 是一种用以解析地址的协议。
• 根据通信方的IP地址就可以反查出对应的 MAC 地址。

确保可靠性的 TCP 协议

• 位于传输层，提供可靠的字节流服务。

• 字节流服务：为方便传输，将大块的数据分割成报文段（segment）为单位的数据包进行管理。（为了传输大数据才将数据进行分割）

• 可靠的服务：把数据准确的传输给对方。

• 确保能到达目标。

• • 采用三次握手策略（three-way handshaking）策略。
  • 使用了 TCP 标志：(flag)—SYN(synchronize) 和 ACK(ackonwledgement)

负责域名解析的 DNS 服务

• DNS（Domain Name System）是位于应用层的协议。同 HTTP 一样。
• 提供域名到 IP 地址之间的解析服务。可逆向查询。
• 计算机可被赋予 IP 地址，也可被赋予 主机名和域名。通常用主机名或域名，因为符合人类记忆习惯。

各种服务与 HTTP 协议的关系

• 想想想想

URI 和 URL

• URI：Uniform Resource Identifier 统一资源标识符。
• • Uniform 规定统一的格式，方便处理多种不同类型的资源。
  • Resource 资源的定义是“可标识的任何东西”。除文档文件、图形或服务等能够区别与其他的，全部可做资源。资源不仅可单一，也可以是多数的集合体。
  • Identifier 表示可标识的对象。也称标识符。
  • 就是由某个协议方案表示的资源定位符。协议方案是指访问资源时使用的协议的类型名称。例如：采用 HTTP 协议的时候，协议方案就是 http。除此之外，还有ftp、file等30多种。

URI 用字符串标识着某一互联网资源，URL 表示资源的地点。

可见，URL 是 URI 的子集。

• URL：Uniform Resource Locator 统一资源定位符。

URI 格式

• 表示指定的 URL ，要使用涵盖全部必要信息的 绝对 URL 、绝对 URL 以及相对 URL 以及相对 URL 。相对 URL ，是指从浏览器中基本 URL 处指定的 URL，形如 /image/logo.gif

绝对 URL 的格式：

http:// user:pass @ www. exanple.jp: 80 / dir/index.htm ? uid=1 # ch1

• http:// 协议方案名。不区分大小写。
• user:pass 登录信息（认证）。可选信息。
• www. exanple.jp: 服务器地址。
• • 使用绝对的URL必须指定待访问的服务器地址。
  • 地址可以是类似 hackr.jp 这种DNS 可解析的名称，也可以是 192.168.1.1 这种类似 IPv4 地址名，还可以是 [0:0:0:0:0:0:0:1]这种方括号括起来的 IPv6 地址名。
• 80 服务器端口号。可选项。省略则使用默认的端口号。
• dir/index.htm 带层次的文件路径。与 UNIX 系统的文件目录结构类似。
• uid=1 查询字符串。针对已指定的文件路径内的资源。可选。
• ch1 片段标识符。通常可标记出已获取资源的子资源。可选。 RFC 中没有规定其使用方法。

RFC（Request for COmments）征求修正意见书

制定 HTTP 协议技术标准的文档。

简单的 HTTP 协议

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

• 必定是一端担任客户端角色，另一端担任服务器角色。

通过请求和响应的交换达成通信

• 请求必定由客户端发出，服务端回复

实例：

客户端发给某个服务器的请求报文中的内容。

---

GET /index.htm HTTP/1.1

Host : hacker.jp

---

• GET 请求访问服务器的类型，称为方法(method)。
• /index.htm 指明了访问的资源对象。称为 请求URI(request-URI)。
• HTTP/1.1 是 HTTP 的版本号。

意思是：请求访问某台 HTTP 服务器上的 /index/htm 页面资源

---

// 服务器
HTTP/1.1 200 OK
Date: Tue, 1 Jan 2020 08:00:01 GMT
Content-Length: 362
Content-Type: text/html

...

---

请求报文是由请求方法、请求URL、协议版本、可选的请求首部字段和内容实体构成。

• HTTP/1.1 表示服务对应的 HTTP 版本。
• 200 OK 表示请求的处理结果的状态码(status code)和原因短语(reason-phrase)。
• 下一行显示响应的时间，是首部字段(header field)内的一个属性。
• 接下来，空一行 分隔，之后的内容称为资源实体的主体(enntity field)
• GMT 是响应首部字段。

HTTP 是不保存状态的协议

• 无状态协议(stateless)
• HTTP 这个级别，协议对于发送请求或响应都不做持久化处理。
• 每当有新的请求，即产生新的响应，不保存之前的响应报文信息。
• 为了保持状态，引入 Cookie 技术。

请求 URL 定位资源

• 类型很多种。。。

如果不是访问特定的资源，而是对服务器本身发起请求，可以用一个 * 来代替请求URI。例如：

OPTIONS * HTTP/1.1

告知服务器意图的 HTTP 方法

GET ：获取资源

• GET 方法用来请求访问已被 URI 识别的资源。
• 指定的资源经服务端解析后返回响应内容。如果请求资源是文本，那就保持原样返回；如果是像 CGI(Common Gateway Interface) 通用网关接口那样的程序，则返回经过执行后的输出结果。

例子：

请求	Get /index.html http/1.1
响应	返回 index.html 的页面资源

请求	Get /index.html http/1.1 Host: www.hackr. jp if-modified-since: thu, 1 jan 2020 08:20:01 gmt
响应	仅返回2020年1月1日8点20分以后更新过的index页面资源。

POST：传输实体主体

• 用来传输实体的主体。

例子：

请求	post /submit.cgi http/1.1 Host: www.hackr. jp content-length:1560（1560字节的数据）
响应	返回 submit.cgi 接收数据的处理结果

PUT：传输文件

• 传输文件，像 FTP 一样。
• 要求在请求报文主体中包含文件内容，然后保存到请求 URI 制定的位置。
• HTTP/1.1 自身不带验证机制。存在安全问题，一般不用。
• 若配合 Web 应用程序的验证机制，或采用 REST(REpresentational State Transfer，表征状态转移) 标准的同类 Web 网站，可能会使用。

例子：

请求	put /example.html http/1.1 host: www.hackr .jp content-type: text/html content-length: 1560 (1560字节的数据)
响应	响应返回状态码 204 Not Content （比如：该 html 已存在于服务器上）

HEAD：获得报文首部

• HEAD 方法和 GET 方法一样，不返回报文主体部分。
• 用于确认 URL 的有效性及资源更新的日期时间等。

例子：

请求	head /index.html http/1.1 host: www.hackr .jsp
响应	返回 index.html有关的响应首部

DELETE：删除文件

• 用来删除文件，是与 PUT 相反的方法。
• 但是和 HTTP/1.1 一样，不带验证机制，所以一般的 Web 网站也不使用 DELETE 方法。
• 当配合 Web 应用程序的验证机制，或遵循 REST 标准时还是有可能会开放使用。

例子：

请求	DELETE /example.html HTTP/1.1
响应	响应返回状态码 204 No Content （比如：该 html 已从该服务器上删除）

OPTIONS：询问支持的方法

例子：

请求	OPTIONS * HTTP/1.1 Host:www.hackr .jp
响应	HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS（返回服务器支持的方法）

TRACE：追踪路径

• 让 Web 服务器端将之前的请求通过通信回环给客户端的方法。
• 在 Max-Forwards 首部字段中填入数值，每经过一个服务器就将该数字减1，当数字减到 0 时，就返回状态码 200 OK 的响应。
• 客户端通过 TRACE 方法查询发送出去的请求是怎样被加工修改/篡改的。因为请求连接到源目标服务器可能会通过代理中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。
• 不常用。易引发 XST（Cross-Site Tracing，跨站追踪）攻击。

例子：

请求	TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards:2
响应	HTTP/1.1 200 OK Content-Type: message/http TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards:2 （返回响应包含的请求内容）

CONNECT：要求要用隧道协议连接代理

• 要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。
• 主要使用 SSL (Secure Sockets Layer，安全套接层) 和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
• 语法格式：CONNECT 代理服务名：端口号 HTTP版本

例子：

请求	CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp
响应	HTTP/1.1 200 OK（之后进入网络隧道）

使用方法下达命令

• 向请求 URI 制定的资源发送请求报文时，采用成为方法的命令。
• 方法的作用在于，可以指定请求的资源按期望产生某种行为。方法中有 GET、POST 和 HEAD 等。

支持的方法

方法	说明	支持的 HTTP 协议版本
GET	获取资源	1.0、1.1
POST	传输实体主体	1.0、1.1
PUT	传输文件	1.0、1.1
HEAD	获取报文首部	1.0、1.1
DELETE	删除文件	1.0、1.1
OPTIONS	询问支持的方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的联系	1.0
UNLINE	断开连接关系	1.0

持久连接节省通信量

• 之前的情况：每进行一次 HTTP 通信就要断开一次 TCP 连接。

持久连接

• 持久连接（HTTP Persistent Connections）,也称为 HTTP keep-alive 或 HTTP connection reuse。
• 特点：只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
• 在 HTTP/1.1 中所有的连接默认都是持久连接。

管线化

• 使用管线化技术，不用等待响应即可直接发送下一个请求

使用 Cookie 的状态管理

• HTTP 协议，无协议也有好处，简单才会被更多的应用。

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

Cookie 会根据从服务器端发送的响应报文内的一个叫 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。

下次再客户端再往该服务器发送请求时，客户端会自动再请求报文中加入 Cookie 值后发送出去。

• HTTP 请求报文和响应报文内容如下：

1.请求报文（没有 Cookie 信息的状态）

---

GET /reader/ HTTP/1.1

Host: hackr.jp

• 首部字段内没有 Cookie 的相关信息

---

2.响应报文（服务器端生成 Cookie 信息)

---

HTTP /1.1 200 OK

Date: Tue, 1 Jan 2020 08:10:01 GMT

Sever: Apache

<Set-Cookie:sid=13420770140226734; pa+10-jan-11 08:10:01 GMT>

content-Type: text/plain; charaset=UTF-8

---

3.请求报文

---

GET /image/ HTTP/1.1

Host: hackr.jp

Cookie: sid=1342077140226724