图解HTTP-1.web和网络基础

目录

1. 3 项 WWW 构建技术

2. TCP/IP 是互联网相关的各类协议族的总称

协议（protocol）

TCP/IP分层管理

TCP/IP通信传输流

封装（encapsulate）

3. 与 HTTP 关系密切的协议 : IP、 TCP 和DNS

3.1负责传输的IP协议（网络层）

路由选择（routing）

3.2 确保可靠性的 TCP 协议（传输层）

字节流服务（Byte Stream Service）

三次握手（three-way handshaking）

3.3 负责域名解析的 DNS 服务

3.4 总结：各种协议与 HTTP 协议的关系

4. URI 和 URL

4.1 统一资源标识符 Uniform Resource Identifier

4.2 URI 格式

---

1. 3 项 WWW 构建技术

• SGML（Standard Generalized Markup Language， 标准通用标记语言） 作为页面的文本标记语言的 HTML（HyperText Markup Language， 超文本标记语言） ；
• 作为文档传递协议的 HTTP ；
• 指定文档所在地址的 URL（Uniform Resource Locator， 统一资源定位符）

---

2. TCP/IP 是互联网相关的各类协议族的总称

协议（protocol）

计算机与网络设备要相互通信， 双方就必须基于相同的方法。 比如，如何探测到通信目标、 由哪一边先发起通信、 使用哪种语言进行通信、 怎样结束通信等规则都需要事先确定。 不同的硬件、 操作系统之间的通信， 所有的这一切都需要一种规则。 而我们就把这种规则称为协议（protocol） 。

---

TCP/IP分层管理

---

TCP/IP通信传输流

利用 TCP/IP 协议族进行网络通信时， 会通过分层顺序与对方进行通信。 发送端从应用层往下走， 接收端则往应用层往上走。

1. 我们用 HTTP 举例来说明， 首先作为发送端的客户端在应用层（HTTP 协议） 发出一个想看某个 Web 页面的 HTTP 请求。
2. 在传输层（TCP 协议） 把从应用层处收到的数据（HTTP 请求报文） 进行分割， 并在各个报文上打上标记序号及端口号后转发给网络层。
3. 在网络层（IP 协议） ， 增加作为通信目的地的 MAC 地址后转发给链路层。 这样一来， 发往网络的通信请求就准备齐全了。
4. 接收端的服务器在链路层接收到数据， 按序往上层发送， 一直到应用层。 当传输到应用层， 才能算真正接收到由客户端发送过来的 HTTP请求。

封装（encapsulate）

这种把数据信息包装起来的做法称为封装（encapsulate）。

---

3. 与 HTTP 关系密切的协议 : IP、 TCP 和DNS

3.1负责传输的IP协议（网络层）

使用 ARP 协议凭借 MAC 地址进行通信IP 间的通信依赖 MAC 地址。 在网络上， 通信的双方在同一局域网（LAN） 内的情况是很少的， 通常是经过多台计算机和网络设备中转才能连接到对方。 而在进行中转时， 会利用下一站中转设备的 MAC地址来搜索下一个中转目标。 这时， 会采用 ARP 协议（Address Resolution Protocol）。ARP 是一种用以解析地址的协议， 根据通信方的 IP 地址就可以反查出对应的 MAC 地址。

路由选择（routing）

没有人能够全面掌握互联网中的传输状况。

在到达通信目标前的中转过程中， 那些计算机和路由器等网络设备只能获悉很粗略的传输路线。就像发快递。

---

3.2 确保可靠性的 TCP 协议（传输层）

字节流服务（Byte Stream Service）

为了方便传输， 将大块数据分割成以报文段（segment） 为单位的数据包进行管理。 而可靠的传输服务是指， 能够把数据准确可靠地传给对方。 一言以蔽之，TCP 协议为了更容易传送大数据才把数据分割， 而且 TCP 协议能够确认数据最终是否送达到对方。

---

三次握手（three-way handshaking）

1. 发送端首先发送一个带 SYN 标志的数据包给对方。
2. 接收端收到后，回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。
3. 最后， 发送端再回传一个带 ACK 标志的数据包， 代表“握手”结束。

若在握手过程中某个阶段莫名中断， TCP 协议会再次以相同的顺序发送相同的数据包。

---

3.3 负责域名解析的 DNS 服务

DNS 协议提供通过域名查找 IP 地址， 或逆向从 IP 地址反查域名的服务。

---

3.4 总结：各种协议与 HTTP 协议的关系

---

4. URI 和 URL

4.1 统一资源标识符 Uniform Resource Identifier

URI（统一资源标识符） 相比， 我们更熟悉 URL（Uniform Resource Locator， 统一资源定位符） 。

RFC2396 分别对这 3 个单词进行了如下定义。

• Uniform：规定统一的格式可方便处理多种不同类型的资源， 而不用根据上下文环境来识别资源指定的访问方式。 另外， 加入新增的协议方案（如http: 或 ftp:） 也更容易。
• Resource：资源的定义是“可标识的任何东西”。 除了文档文件、 图像或服务（例如当天的天气预报） 等能够区别于其他类型的， 全都可作为资源。 另外， 资源不仅可以是单一的， 也可以是多数的集合体。
• Identifier：表示可标识的对象。 也称为标识符。

URI 就是由某个协议方案表示的资源的定位标识符。 协议方案是指访问资源所使用的协议类型名称。

URI 用字符串标识某一互联网资源， 而 URL 表示资源的地点（互联网上所处的位置） 。 可见 URL 是 URI 的子集。

“RFC3986： 统一资源标识符（URI） 通用语法”中列举了几种 URI 例子， 如下所示。

ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:John.Doe@example.com
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2

---

4.2 URI 格式

表示指定的 URI， 要使用涵盖全部必要信息的绝对 URI、 绝对 URL 以及相对 URL。

相对 URL， 是指从浏览器中基本 URI 处指定的 URL，形如 /image/logo.gif。

让我们先来了解一下绝对 URI 的格式

• 使用 http: 或 https: 等协议方案名获取访问资源时要指定协议类型。 不区分字母大小写， 最后附一个冒号（:） 。
• 也可使用 data: 或 javascript: 这类指定数据或脚本程序的方案名。登录信息（认证）指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证） 。 此项是可选项。
• 服务器地址：使用绝对 URI 必须指定待访问的服务器地址。 地址可以是类似hackr.jp 这种 DNS 可解析的名称， 或是 192.168.1.1 这类 IPv4 地址名， 还可以是 [0:0:0:0:0:0:0:1] 这样用方括号括起来的 IPv6 地址名。
• 服务器端口号：指定服务器连接的网络端口号。 此项也是可选项， 若用户省略则自动使用默认端口号。
• 带层次的文件路径：指定服务器上的文件路径来定位特指的资源。 这与 UNIX 系统的文件目录结构相似。
• 查询字符串：针对已指定的文件路径内的资源， 可以使用查询字符串传入任意参数。 此项可选。
• 片段标识符：使用片段标识符通常可标记出已获取资源中的子资源（文档内的某个位置） 。 但在 RFC 中并没有明确规定其使用方法。 该项也为可选项。

---