《图解 HTTP》 摘要一

技术分享4年前 (2020)更新 技术分享
1,813 0 0
  • 学习过程对书本的内容的摘要以及总结,逐步完善,带有个人理解成分。

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

© 版权声明

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...