计算点：

  • Web 缓存服务器带来的性能提升。
  • P2P 模型下文件分发时间的计算。

    应用层服务模型

    应用层服务模型有两种主流服务模型： C/S 模型和 P2P 模型。

C/S 模型

适用范围：基础设施密集型应用。
client-server 模型，一直打开的主机称为服务器，等待客户端访问。
服务器特点：

  • 服务器永不关机。
  • 服务器的 IP 地址一般是不变的、周知的。
  • 服务器位于数据中心，服务器集群满足伸缩性要求。

客户端特点：

  • 客户端的访问具有间歇性；
  • 客户端可能的 IP 地址可能动态变化。
  • 客户端之间不互相通信。

著名应用程序：Web，FTP，电子邮件等等。

P2P 模型

适用范围：流量密集型应用。
Point to Point 模型，基本不依赖于数据中心的服务器，每个客户端的主机互为服务器，这些主机称为对等方，对等方之间互相通信传递数据。

  • 没有永不关机的服务器；
  • 对等方之间互相收发数据；
  • 自扩展性：新的对等方加入体系既增加需求，也增加服务能力。
  • 对等方之间间歇性连接且具有动态变化的 IP 地址。

进程通信

计算机网络关注不同主机之间的进程间通信，此时需要通过 socket 套接字进行通信。

socket 套接字

socket 是一台主机内应用层与运输层之间的接口。
假设主机 1 的进程与主机 2 的进程通过 socket 通信。

  • 发送方只需要在应用层把数据推入 socket 接口即可，剩下的交给其他层处理；接受方在应用层查看 socket 接口是否有数据到来。
  • socket 对传输层基本没有控制权，最多选一选运输层协议（TCP 或 UDP），设置几个运输层参数。

进程寻址

一台主机会运行许多进程，为了标识数据应该被哪个进程接收，需要两样信息：

  • 目的主机 IP 地址；
  • 目的主机接收进程的端口号。

小贴士：哪个主机的哪个进程接收数据。

应用层所需传输层的服务

  1. 可靠传输。应用层希望应用程序发送的数据能够被接收方完整接收。
  2. 吞吐量。应用层希望应用程序能够以一定大小的带宽发送的数据（但有些应用也没有这样的要求）。
  3. 定时。应用层希望应用程序发送的数据能够在限定时间内到达接收方。
  4. 安全。应用层希望应用程序发送的数据除了接收方不能被其他人识别。

传输层提供的服务

TCP 服务

提供面向连接的、可靠的、具有流量控制的、拥塞控制的传输服务。

UDP 服务

提供不可靠的传输服务。
不可靠不代表不能用，不可靠的意思是不能保证数据被正确接收，但是还是有很大可能被正确接收的，有些应用没有这么严格的要求，允许有容错率，比如流媒体应用。

安全性

TCP 和 UDP 没有加密机制，以明文传输，都不安全。
只能依靠 SSL 或 TLS 保证安全。

典型应用层协议采用的传输层协议

image.png

HTTP 协议

HyperText Transfer Protocol，HTTP，超文本传输协议，是 Web 的核心。
关于 HTTP 的发展史详见：HTTP 与 HTTPS

传输模型

C/S 模型：
image.png
Web 服务器的端口号是 80.

传输对象

Web 页面：由 Web 对象组成。
Web 对象：一个对象是一个文件，通过 URL 寻址，如 HTML 文件、图片、视频等等。
一个 Web 页面通常包含一个 HTML 文件和多个其他 Web 对象。

无状态协议

HTTP 协议是一个无状态协议，它不保存录用户的信息，这会给很多应用场景带来麻烦，比如浏览购物网站在首页登录后点击商品跳转又要登录。
因此保存状态是有必要的，关于弥补 HTTP 无状态的缺陷方法详见：HTTP 状态维持 （若链接失效，请联系我）

采用的传输层协议

HTTP 采用 TCP 协议来保证数据的可靠传输。

连接的持续性

因为采用 TCP 协议来传输数据，因此需要建立 TCP 连接：非持续连接和持续连接。

非持续连接

一个 TCP 连接只用来传输一个 Web 对象。

例如当请求一个 Web 页面包含 10 个 Web 对象时，需要建立是 11 个 TCP 连接，算上三次握手过程，传输第一个 Web 对象 HTML 文件就需要 2 个 RTT，得到 HTML 文件后发现还有 10 个其他 Web 对象，重复上述过程获取需要 20 个 RTT，因此总共需要 22 个 RTT，反复建立和断开连接开销巨大。
可以采取并行 TCP 连接减少 RTT，但是浏览器通常限制 5-10 个并行 TCP 连接。
小贴士：在计算机网络：自顶向下方法中，RTT 定义为一个短分组从客户端到服务器再返回客户端所需的时间。

持续连接

一个 TCP 连接只用来传输多个 Web 对象。

还是上面的例子，传输完 HTML 文件后，不关闭 TCP 连接而是继续用它发送请求和接收响应，因此只需要 2 + 10 = 12 个 RTT。

小结

持续连接比非持续链接胜在没有多余的握手开销。

HTTP 报文结构

请求报文

image.png

  1. // 一个典型的 HTTP 请求报文
  2. GET /somedir/page.html HTTP/1.1
  3. Host: www.sorneschool.edu
  4. Connection: close
  5. User-agent: Mozilla/5.0
  6. Accept-language: fr

请求行

包含方法、URL 和 HTTP 版本三个部分。
在 HTTP/1.0 只有 GET, POST, HEAD 三个方法，HTTP/1.1 增加了 PUT 和 DELETE 方法。
HEAD 与 GET 的区别：使用 HEAD 发起请求时，服务器使用一个 HTTP 报文响应而不返回请求对象。

  • 应用程序开发者常用其于调试跟踪
  • 当客户端需要请求一个文件时，会先通过 HEAD 获取文件的大小再决定是否要获取文件。

PUT 和 DELETE 分别用于通过 URL 往服务器上传文件和删除服务器中的文件。

首部行

常见首部字段的作用如下：

首部字段 取值 作用
Connection keep-alvie / close 持续连接 或 非持续连接
User-agent Mozilla/5.0 等 浏览器类型。服务器可以根据浏览器的类型发送相同对象的不同版本
Accept-language fr 客户端想得到的对象的语法版本

请求实体

使用 GET 方法时，请求实体为空；使用 POST 方法提交表单时，表单内容以键值对的形式出现在请求实体中。

当然提交表单不一定要用 POST 方法，也可以通过 GET 方法在 URL 里输入表单数据，如 www.yuque.com/login?user=zwjason&password=123456

小结

HTTP 请求报文包括请求行、首部行和请求实体。其中请求行包含了请求方法、URL 和 HTTP 协议的版本；首部行里以键值对的形式定义了一系列规则；请求实体在 GET 方法时为空，在 POST 方法时是键值对形式的表单内容。

响应报文

image.png

  1. HTTP/1.1 200 OK
  2. Connection : close
  3. Date : Tue, 18 Aug 2015 15:44:04 GMT
  4. Server: Apache /2.2.3 (CentOS)
  5. Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
  6. Content-Length: 6821
  7. Content-Type : text/html
  8. (data data data data data ...)

状态行

HTTP 状态码如下

1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误

常见状态码：200 表示成功；301 表示资源已经被永久移除，新定义的 URL 在首部行的 Location 字段中；400 表示请求有语法错误等问题，服务器无法解析请求；404 表示请求的资源不存在；505 表示服务器不支持该版本的 HTTP。

首部行

很多首部字段都是见名知意，几个特别的如下：

  • Connection：如请求中的作用那样，表示是否请求报文中的 TCP 连接方式。

响应实体

存放响应内容的地方。

小结

HTTP 响应报文包括状态行、首部行和响应实体。状态行显示了本次请求成功与否，包括 HTTP 版本、状态码和状态码对应的短语；首部行以键值对的形式显示了一系列规则；若请求成功，响应实体是 HTPP 请求所需要的内容，否则为空或一些其他信息。

cookie 交互

使用 cookie 弥补 HTTP 协议无状态的缺点，交互过程如下：
image.png
注意点：

  1. 在 HTTP 响应报文中加入 cookie 头；
  2. 下次 HTTP 请求时带上 cookie；
  3. cookie 保存在浏览器；
  4. 后端数据库保存一个表项用于验证 cookie。

cookie 的优点

  1. 授权
  2. 对于购物等需要维持状态的交互式场景提供方便；服务器可以根据 cookie 进行个性推荐。

cookie 的缺点：

  1. 包含太多隐私信息。
  2. 可能被卖给第三方。

Web 代理（缓存）

用于提高 Web 应用的性能。
image.png
有关引入 Web 缓存是如何降低的时延的例子请看书，还挺重要，涉及计算，可能要考。

条件 GET

Web 缓存的内容可能过时，使用条件 GET 方法更新。
在首部行里加入 If-Modified-Since 字段，表示自从这个时间点之后是否仍有修改。

FTP 协议

该协议采用 C/S 模型实现，使用 TCP 协议。
image.png

  1. FTP 服务器的控制连接端口号是 21，数据传输端口号是 20；
  2. 客户端授权连接；
  3. 使用 TCP 协议三次握手建立连接后传输，一个 TCP 连接传一个文件，传完就关闭连接；
  4. FTP 服务器维持状态：当前目录，早期授权。

电子邮件系统

电子邮件系统参与对象包括：

  • user agent 用户代理：微软的 Outlook 和 Apple Mail 等等
  • mail server 邮件服务器： 维护一个邮件报文队列。
  • Simple Mail Transfer Protocol，SMTP 简单邮件传输协议：使用 TCP 协议。

SMTP 协议

特点：

  • 使用 TCP 协议
  • 邮件服务器的端口号是 25
  • 邮件报文所有部分必须是 7 比特 ASCII 字符

交互过程：A 发 B 收

  1. A 调用用户代理程序并提供 B 的邮箱地址发送报文。
  2. A 的用户代理把该报文放到 A 的邮件服务器上。
  3. A 的邮件服务器的 SMTP 程序发现该报文，与 B 的邮件服务器建立 TCP 连接。
  4. 三次握手建立连接后发送该报文。
  5. B 的邮件服务器上的 SMTP 程序接受该报文并放入 B 的邮件服务器。
  6. B 调用用户代理查看该报文。

image.png

与 HTTP 比较

  1. 都是用 TCP 协议，但 SMTP 一定使用持续链接，HTTP 不一定。
  2. SMTP 是推协议，HTTP 是拉协议。
  3. 都使用 ASCII 编码，但 SMTP 的邮件报文所有部分必须是 7 比特 ASCII 字符，HTTP 无限制。
  4. HTTP 把每个对象封装到 HTTP 响应报文中；SMTP 把所有报文对象封装到一个报文中。

邮件报文格式

image.png

POP3 协议

Post Office Protocol 3，第三版邮局协议。
SMTP 是推协议只发邮件不能接受，POP3 则是一个拉协议只收邮件不能发。
其他的邮件接收协议还有：IMAP（Internet Mail Access Protocol）
POP3 是一个极其简单的协议，它的一些信息如下：

  • 提供下载并删除 或 下载并保留两种方式

IMAP 的一些信息如下：

  • 把所有邮件都放在服务器，允许用户使用文件夹管理。

小结

电子邮件系统由 4 部分组成，用户代理、邮件服务器、邮件传输协议、邮件访问协议。用户代理是用户与邮件服务器的中间人，用户通过用户代理接收邮件或向其他用户发送邮件；发送邮件使用邮件传输协议如 SMTP，接收邮件使用邮件访问协议如 POP3, IMAP

DNS 协议

简介

主机名：标识主机，主要是便于人类记忆，如 www.baidu.com，一个主机可以有多个主机名。
IP 地址：标识主机，具有唯一性，接入因特网的设备都会被分配一个 IP 地址，如 127.0.0.1 表示本地主机。

人类喜欢主机名，便于记忆，而路由器更喜欢具有定长的、有层次结构的 IP 地址，因此 DNS 协议主要就是提供一个主机名到 IP 地址转换的目录服务，所以 DNS 协议经常被 HTTP, SMTP, FTP 等协议使用。

Domain Name System，DNS，域名系统。

  • 一个运行于 UDP 协议之上的应用层协议，使用 53 号端口。
  • 本质是一个由分层的 DNS 服务器实现的分布式数据库。

提供的服务

  1. 主机名到 IP 地址转换的目录服务。
  2. 主机别名。一台主机的规范名可能很长，如 relay1.west-coast.enterprise.com，不好记忆，DNS 可以让主机拥有多个别名，方便记忆，如 www.enterprise.com.
  3. 邮件服务器别名。提供便于记忆的邮件地址别名，如 123456@qq.com.
  4. 负载分配。DNS 缓存着多台 Web 服务器的 IP 地址（这些 Web 服务器具有相同的主机别名，但 IP 地址不同），当请求到来时，根据压力情况，把请求转向其中一台 Web 服务器。

DNS 结构

1. 单一 DNS 服务器

用一台 DNS 服务器存储所有映射，这是不现实的。
缺点：

  1. 单点故障。如果该 DNS 服务器崩溃，整个因特网随之瘫痪。
  2. 通信容量。单个 DNS 服务器难以承担世界上所有 DNS 查询。
  3. 远距离的集中式数据库。对于距离较远的客户，时延非常高。
  4. 维护。难以维持频繁更新的需求。

因此单台服务器不具有伸缩性。

2. 分布式 DNS 服务器

应用层 - 图10

  • 根 DNS 服务器：全球 400 多个，由不同组织管理。
  • 顶级域 DNS 服务器：各大公司维护。
  • 权威 DNS 服务器：DNS 服务提供商，一些组织机构维护。

DNS 查询

1. DNS 缓存

在实践中，通常会引入一个层次结构之外的本地 DNS 服务器，用作缓存。
目的是改善时延性能，减少因特网上 DNS 报文的数量。
本地 DNS 服务器会自动定时丢弃缓存信息。

2. 递归查询

应用层 - 图11
根 DNS 服务器要等待底层 DNS 返回结果。

3. 迭代查询

应用层 - 图12
请求主机和本地 DNS 服务器之间还是递归查询，本地 DNS 服务器与其他 DNS 服务器之间是迭代查询。
根 DNS 服务器不用等待底层 DNS 返回结果。
实践中也采用了这样 递归查询 + 迭代查询 的方式。

DNS 记录和报文

记录类型

资源记录，Resource Record，RR，提供了主机名到 IP 地址的映射。
每个 DNS 回答报文都包含一条或多条 RR。
RR 结构：一个四元组，(Name, Value, Type, TTL)，请求 TTL 是生存时间。
RR 共分 4 类：忽略 TTL，Name 和 Value 取决于 Type

  1. Type = A，标准的主机名到 IP 地址映射。Name 是主机名，Value 是 IP 地址，如 (www.baidu.com, 183.232.231.174, A, TTL).
  2. Type = NS，域到权威 DNS 服务器的主机名映射。Name 是个域，Value 是一个知道如何获得该域中主机 IP 地址的权威 DNS 服务器的主机名，如 (foo.com, dns.foo.com, NS, TTL).
  3. Type = CNAME，别名到规范名的映射。Name 是别名，Value 是对应的规范名，如 (foo.com, relay1.bar.foo.com, CNAME, TTL).
  4. Type = MX，别名到规范名的映射（邮件）。Name 是别名，Value 是对应的规范名，如 (foo.com, mail.bar.foo.com, CNAME, TTL).

插入记录

向注册登录机构提供你的辅助权威 DNS 服务器的主机名和 IP 地址。
注册登记机构插入一条 NS 和一条 A 类型的记录到顶级域 DNS 服务器。
在自己的权威 DNS 服务器插入 A 和 MX 类型的记录。

报文结构

DNS 只有查询报文和回答报文，具有相同格式。
应用层 - 图13

nslookup 程序

使用 nslookup 程序可以直接发送一个 DNS 查询报文到 DNS 服务器。
使用方法：nslookup + 主机名（一次性）或直接输入 nslookup 启动程序后，直接输入主机名。

DNS 安全

1. DDoS 攻击

Distributed Denial of Service，分布式拒绝服务攻击，攻击者通过控制大量主机同时向服务器发送大量分组，使得合法分组无法得到处理。

以根 DNS 服务器为攻击对象

由于存在分组过滤器和本地 DNS 服务器，这种方式至今未成功。

  • 分组过滤器有效地过滤一些恶意报文，如 ICMP ping 报文。
  • 本地 DNS 服务器缓存了顶级域名的 DNS 服务器的 IP 地址，使得分组绕过了根 DNS 服务器。

以顶级域 DNS 服务器为攻击对象

通过本地 DNS 服务器可以缓解这样的攻击。

2. 重定向攻击

中间人攻击

攻击者拦截请求，伪造回答发回给用户，导致用户得到错误 IP 地址。

DNS 毒害攻击

攻击者拦截请求，伪造回答发回给服务器，导致服务器缓存了错误的记录。

都难以实现，因为拦截分组和扼制服务器很难。

小结

DNS 协议提供主机名到 IP 地址的映射服务，运行在 UDP 协议上，DNS 系统本质上是一个分布式数据库。从分层角度来说，DNS 系统自顶向下共 3 层：根服务器、顶级域服务器、权威服务器。DNS 查询有两种方式：递归查询和迭代查询，递归查询给根服务器带来巨大压力，实践中使用迭代查询。DNS 系统比较健壮，安全可靠。

P2P 的应用

P2P 模型的扩展性

基于 P2P 模型的应用程序具有自扩展性，原因是新的对等方加入体系既增加需求，也增加服务能力。
关于扩展性的计算详见课本，重要。

文件分发

BitTorrent 是流行的 P2P 协议，用于文件分发。
image.png
几个概念：

  • 洪流 torrent：参与一个特定文件分发的所有对等方集合称为洪流。
  • 文件块 chunk ：整个文件等分出的块，典型大小为 256 KB
  • 追踪器 tracker：记录洪流中所有对等方的信息包括 IP 地址等，新对等方加入需要向追踪器注册，并周期性地通知追踪器自己仍在洪流中。

一个新的对等方加入洪流接收文件的流程：

  • 向追踪器注册自己，并获取一份所有对等方的 IP 地址列表。
  • 尝试与所有对等方建立 TCP 连接，成功的成为邻近对等方，邻近对等方是疏通的，其他对等方是阻塞的。
  • 采用最稀缺优先技术决定接下来从它的邻居请求哪个文件块：对于他自己没有的所有块，哪个在邻居中的副本最少，那么就请求它。
  • 采用対换算法决定向哪个邻居发送文件块：邻居里谁给我发送数据的速率最快，那么他就拥有最高优先权，先给他传文件块，但是每隔 30 秒也要随机选取一个对等方传送文件块。

如果一个自私的对等方只收不传，只要他在洪流中待的时间足够长，也是可以收到整个文件的。

分布式哈希表

DHT，Distributed Hash Table，是一种数据库，数据库记录分布在一个 P2P 系统的多个对等方上。

记录的形式

一般 key 是文件名，value 是文件所在对等方的 IP 地址，但是通过其他哈希函数可以把 key 转为数字，形成 ID 空间。

记录的分配

把记录分给具有最近 ID 的对等方。
假设 ID 空间为 [0, 1, 2, …, 63] ，有 8 个对等方：1, 12, 13, 25, 32, 40, 48, 60

  • 若 key = 51，则分配给对等方 60.
  • 若 key = 61，则分配给对等方 1.

距离一样近时，考虑其他因素？

循环 DHT

循环 DHT 中规定：任何一个对等方只知道直接前驱和直接后继的信息。
image.png
若按顺时针方向为正，则 60 的直接前驱是 48，直接后继是 1.

查询解析

image.png
对于一个查询平均需要 O(n) 时间，n 是对等方的数量。

带捷径的 DHT

image.png
为 O(log n) 个邻居设计捷径，查询的平均时间缩短为 O(log n)。

DHT 变动

image.png
问题：若 4 只保存直接后继 5 的信息，当 5 离开后，4将失去后继信息。
解决：每个对等方保存两个后继的信息，通过周期性 ping 它们检查它们是否仍然存在。若直接后继离开了，则选择下一个后继为新的直接后继，并让通过新的直接后继得知第二个后继的信息。
如 5 离开了，4 选择 8 成为新的直接后继，然后从 8 得知它的直接后继是 10， 所以 4 的第二后继也是 10.