《计算机网络-自顶向下》02. 应用层
文章目录
-
- 应用层协议原理
-
- 应用程序体系结构
- 进程通信
-
- 客户和服务器进程
- 进程与计算网络之间的接口
- 进程寻址
- 可供应用使用的运输层服务
-
- 可靠数据传输
- 吞吐量
- 定时
- 安全性
- 因特网提供的运输服务
-
- TCP
- 安全的 TCP
- UDP
- 因特网运输协议所不提供的服务
- 一些因特网应用所使用的运输层协议
- 网络应用 —— Web 和 HTTP 协议
-
- Web
- HTTP
-
- 概况
- 执行流程
- 持久和非持久 HTTP 连接
- 往回时间 RTT
- HTTP 报文格式
-
- 请求报文
- 响应报文
- HTTP Status
- Cookie 和 Session
-
- Cookie
- Session
- Web 缓存
- 网络应用 —— 电子邮件
-
- SMTP
- SMTP 的报文格式
- SMTP 和 HTTP 的区别
- 邮件访问协议
-
- POP3
- IMAP
- 基于 Web 的电子邮件
- 网络应用 —— DNS：因特网的目录服务
-
- DNS 所提供的的服务
- DNS 工作基本原理概述以及最简单的 DNS 实现方式
- DNS 是一个分布式数据库、层次数据库
-
- 根 DNS 服务器
- 顶级域 DNS 服务器
- 权威 DNS 服务器
- 本地 DNS 服务器
- DNS 的查询方式，递归？迭代？
- DNS 缓存
- DNS 记录和报文
-
- 资源记录
- DNS 报文
- 在 DNS 数据库中插入记录
- 网络应用 —— P2P
-
- 文件分发时间
-
- 客户端-服务器方式
- P2P 方式
- BitTorrent
-
- 洪流与跟踪器
- 当一个用户加入洪流时，会发生的情况
- tit-for-tat
- 种子
- 网络应用 —— 视频流和内容分发
-
- 因特网视频
- HTTP 流和 DASH
- 内容分发网
-
- 部署策略
- CDN 访问流程
- 集群选择策略
应用层协议原理
网络应用的核心：能够运行在不同的端系统，以及可以通过网络彼此之间通信。
应用程序能够通过 C、Java、Python 等编程语言来实现。我们的网络应用程序是运行在应用层上的，我们并不需要去编写运行在网络核心设备（如路由器、链路层交换机）上的软件，即便要编写，那也做不到。网络核心设备并不在应用层起作用，只在较低层起作用，特别是网络层以及下面的层次。这种基本设计，将应用软件限制在端系统上的方法，促进了大量的网络应用程序的迅速研发和部署。
应用程序体系结构
在编写软件之前，需要选择一个体系结构（应用程序的体系结构不同于网络的系统结构，即于五层因特网系统结构不同）。
现代网络应用程序主流的体系结构：
- 客户端-服务端体系结构（C/S, Client/Server）。
- 对等体系结构，即 P2P（Peer to Peer）。
- C/S 和 P2P 的混合体。
进程通信
在相同端系统上，使用进程间通信机制来互相通信。进程通信的规则由端系统上的操作系统决定。
在不同端系统上，通过交换报文来通信。
- 发送进程生成报文并向网络中发送报文。
- 接收进程接收这些报文并可能通过回送报文进行响应。
客户和服务器进程
- 客户端：发起通信、发送数据的进程。
- 服务端：等待联系的进程。
进程与计算网络之间的接口
多数应用程序是由通信进程对组成，每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过网络。进程通过套接字（Socket）的软件接口向网络发送报文和从网络中接收报文。
套接字是同一台主机内应用层与运输层之间的接口。由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口。
应用程序开发者可以控制套接字在应用层上的一切，但套接字在运输层上的控制仅限于：
- 选择运输层协议。
- 允许设置少量的运输层参数，例如最大缓存、最大报文段长度等。
一旦应用开发者选择了一个运输层协议，则应用程序就建立在由该协议提供的运输层服务之上。
Socket 也分为 TCP Socket 和 UDP Socket。
应用层通过 Socket 套接字向传输层传输信息，根据连接类型具体如下：
- TCP Socket，应用层向运输层发送
(源IP，源port，目标IP，目标port)。 - UDP Socket，应用层向运输层发送
(目标IP，源port)。
进程寻址
从一个主机发送分组给另一台主机，需要如下信息：
- 对方主机的地址。
- 应用程序的端口号。
可供应用使用的运输层服务
可靠数据传输
可靠数据传输：不丢包。
- 有些应用需要可靠的数据传输，例如银行。
- 有些应用可以容忍包丢失，例如音频。
吞吐量
吞吐率：运输层可以提供最低的速率给应用程序。
需要保底吞吐率的应用有：因特网电话
如果运输层无法提供最低的编码速率给因特网电话，可能会造成语音质量的下降，甚至是语音通话的中断。这是因为因特网电话使用实时传输协议（Real-time Transport Protocol，简称RTP）来传输音频流，RTP要求传输速率至少为G.711编码速率（64 kbps），否则会导致语音数据的丢失和延迟，从而影响语音质量和通话稳定性。因此，在设计和部署因特网电话网络时，需要考虑网络带宽、网络拥塞情况等因素，以保证语音通话的稳定和高质量。
需要最低限度的吞吐率，从而使得应用程序能够有效运转，这种应用称为带宽敏感性应用。
不需要最低限度的吞吐率的应用称为：弹性应用。
例如：电子邮件、文件传输、Web 传输等。
定时
定时：可以保证数据在限定的时间内完成传输。
对时间严格的应用： Internet 电话、交互式游戏（点击一个技能，结果服务器一分钟后才响应，导致的结果就是你凉了）。
对时间不严格的应用： 电子邮件、文件传输、Web 传输等。
安全性
运输协议能够加密由发送方传输的所有数据，在接收主机中，运输层协议能够将数据交付给接收进程之前将这些数据解密。这便是机密性。
其它的优点有：完整性、端点鉴别。（都是后面章节的内容）
因特网提供的运输服务
TCP
- 可靠的传输服务（接收方一定会收到）
- 流量控制：发送方不会淹没接收方。
- 拥塞控制：当网络出现拥塞时，能抑制发送方的发送速率。
- 不能提供的服务：时间保障、最低限度吞吐率和安全性。
- 面向连接：端间通信之前，必须要先建立连接。
安全的 TCP
TCP 和 UDP 都不具备安全性，即都是明文传输。
SSL 是对 TCP 的一种加强，这种强化是在应用层上实现的。
当一个应用使用 SSL 时，发送进程向 SSL 套接字传递明文数据，在发送方主机中的 SSL 则加密该数据并将加密后的数据传递给 TCP 套接字。
SSL 提供了包含加密、数据完整性、端点鉴别的安全性服务。
UDP
- 不可靠传输（接收方不一定会收到）
因特网运输协议所不提供的服务
吞吐量和定时保证，这些服务目前因特网运输层协议并没有提供。但这并不意味这因特网电话这种时间敏感性应用不能运行在今天的因特网上，因为在因特网上运行时间敏感应用以及多年了。
记住：今天的因特网能为时间敏感性应用提供满意的服务，但不可以提供定时或吞吐量的保证。
一些因特网应用所使用的运输层协议
网络应用 —— Web 和 HTTP 协议
Web
- 应用程序体系结构：客户端-服务器模式。
HTTP
概况
- HTTP 是 Web 的应用层协议，是 Web 的核心，全称 HyperText Transfer Protocol, 超文本传输协议，简称 HTTP。
- HTTP 定义了 Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送 Web 页面的方式。
- HTTP 使用 TCP 作为它的支撑运算协议。
- HTTP 是无状态协议。
执行流程
- Web 客户端向 Web 服务器发起一个 TCP 连接请求。
- Web 服务器接收并且回应客户端的请求，此时连接完成建立。
- 在客户端发送一个 Web 页面的 HTTP 请求。
- 服务器响应该请求。
- 服务器关闭 TCP 连接。
3-4 是端之间交换 HTTP 报文。
持久和非持久 HTTP 连接
非持久 HTTP：
- 最多只允许一个对象在 TCP 连接上发送。
- 下载多个对象需要多个 TCP 连接。
- HTTP/1.0 使用非持久连接。
- 每个对象需要两个 RTT。
- 操作系统必须为每个 TCP 连接分配资源。
- 浏览器通常打开并行 TCP 连接，以获取引用对象。
持久 HTTP：
- 允许多个对象可以在同一个 TCP 连接上传输。
- 服务器在发送响应后，仍然保持 TCP 连接，若经过一定时间（可配置的时间间隔）未有新的请求，则关闭该连接。
- HTTP/1.1 默认使用持久连接。
非流水线方式的持久 HTTP：
- 客户端只能在收到前一个响应后才能发出新的请求。
- 每个引用对象（即每个 HTTP 请求）花费一个 RTT。
流水线方式的持久 HTTP：
- 客户端遇到一个引用对象就立即产生一个请求。
- 所有的引用对象（前提是小对象）只花费一个 RTT 是可能的。
- HTTP/1.1 的默认模式。
往回时间 RTT
往返时间 RTT（Round-Trip Time）：一个小的分组从客户端到服务器，在回到客户端的时间（传输时间忽略），包括发送时间、传输时间、处理时间和返回时间。在计算机网络中，RTT通常被用于测量网络延迟（latency），也是TCP协议中的一个重要指标，它可以用来评估网络的性能和质量。
HTTP 报文格式
请求报文
一个典型的 HTTP 请求报文：
GET /somedir/page.html HTTP/1.1
Host: www.someshcool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
HTTP 请求报文的通用格式：
HTTP Request Header：
| Header | 解释 | 示例 |
|---|---|---|
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
| Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
| Authorization | HTTP授权的授权证书 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） | Connection: close |
| Cookie | HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
| Content-Length | 请求的内容长度 | Content-Length: 348 |
| Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 请求的特定的服务器行为 | Expect: 100-continue |
| From | 发出请求的用户的Email | From: [email protected] |
| Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
| If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
| Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只请求实体的一部分，指定范围 | Range: bytes=500-999 |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
| TE | 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向服务器指定某种传输协议以便服务器进行转换（如果支持） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中间网关或代理服务器地址，通信协议 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
响应报文
一个典型的响应报文：
HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2023 21:01:08 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2023 20:59:00 GMT
Content-Length: 6821
Content-Type: text/html
(data data data ...)
一个 HTTP 响应报文的通用格式：
HTTP Response Header：
| Header | 解释 | 示例 |
|---|---|---|
| Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
| Age | 从原始服务器到代理缓存形成的估算时间（以秒计，非负） | Age: 12 |
| Allow | 对某网络资源的有效的请求行为，不允许则返回405 | Allow: GET, HEAD |
| Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
| Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
| Content-Language | 响应体的语言 | Content-Language: en,zh |
| Content-Length | 响应体的长度 | Content-Length: 348 |
| Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回资源的MD5校验值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
| Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.zcmhi.com/archives/94.html |
| Pragma | 包括实现特定的指令，它可应用到响应链上的任何接收方 | Pragma: no-cache |
| Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | Proxy-Authenticate: Basic |
| refresh | 应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持） | Refresh: 5; url=http://www.zcmhi.com/archives/94.html |
| Retry-After | 如果实体暂时不可取，通知客户端在指定时间之后再次尝试 | Retry-After: 120 |
| Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Set-Cookie | 设置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
| Trailer | 指出头域在分块传输编码的尾部存在 | Trailer: Max-Forwards |
| Transfer-Encoding | 文件传输编码 | Transfer-Encoding:chunked |
| Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 | Vary: * |
| Via | 告知代理客户端响应是通过哪里发送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 警告实体可能存在的问题 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 | WWW-Authenticate: Basic |
HTTP Status
常见的有：
- 1xx（信息性状态码）：表示请求已接收，正在处理。
- 2xx（成功状态码）：表示请求已成功处理。
- 200 OK：表示请求已成功处理，服务器返回了请求的资源。
- 201 Created：表示请求已成功处理，服务器创建了新的资源。
- 204 No Content：表示请求已成功处理，但没有返回任何内容。
- 3xx（重定向状态码）：表示需要客户端进一步操作才能完成请求。
- 301 Moved Permanently：表示请求的资源已永久移动到新的位置。
- 302 Found：表示请求的资源已暂时移动到新的位置。
- 304 Not Modified：表示请求的资源未被修改，可以使用缓存的版本。
- 4xx（客户端错误状态码）：表示客户端请求有错误。
- 400 Bad Request：表示客户端请求有错误，服务器无法处理。
- 401 Unauthorized：表示请求需要身份验证，但未提供有效的身份凭证。
- 403 Forbidden：表示服务器拒绝请求。
- 404 Not Found：表示请求的资源不存在。
- 5xx（服务器错误状态码）：表示服务器处理请求时出错。
- 500 Internal Server Error：表示服务器出错，无法完成请求。
- 502 Bad Gateway：表示服务器作为网关或代理时收到无效的响应。
- 503 Service Unavailable：表示服务器暂时无法处理请求，通常是由于维护或过载造成的。
Cookie 和 Session
由于 HTTP 是无状态的，但服务器由于业务的需求，需要“认得”用户。例如电商平台的购物车就是一个例子，服务器是如何知道客户选了什么产品的呢？便是靠 Cookie 或 SESSION 来实现用户的标识。
Cookie
在客户端跟踪用户通常通过在客户端存储 Cookie 来实现。当用户访问一个网站时，网站服务器可以在响应中设置一个包含用户信息的 Cookie，浏览器会将 Cookie 存储在客户端（通常是本地磁盘）上，以便以后的请求中携带该 Cookie。当浏览器向该网站发出请求时，会自动携带之前存储的 Cookie，网站服务器可以根据 Cookie 中的信息识别用户，从而提供个性化的服务。
服务器可以在响应头中设置 Set-Cookie 字段来设置一个包含用户信息的 Cookie，具体步骤如下：
-
服务器在响应头中设置
Set-Cookie字段Set-Cookie: name=value; expires=Sun, 27 Jun 2023 11:59:59 GMT; path=/; domain=.example.com; secure; HttpOnly- name=value 是 Cookie 的名称和值
- expires 指定了 Cookie 的过期时间
- path 指定了 Cookie 的作用范围
- domain 指定了 Cookie 的作用域
- secure 指定了 Cookie 是否只能通过 HTTPS 连接发送
- HttpOnly 指定了 Cookie 是否只能通过 HTTP 或 HTTPS 协议访问，不能通过 JavaScript 访问
-
浏览器接收到响应后，会将
Set-Cookie中的信息存储到本地磁盘上，并在今后的请求中自动发送该 Cookie。
Session
SESSION 是在服务器端进行跟踪用户的机制，它的基本原理是在服务器端为每个用户创建一个唯一的会话标识符（session ID），并将该标识符与用户相关联。当用户向服务器发送请求时，服务器会根据请求中包含的 session ID 找到与之相关联的用户信息，从而保持跟踪用户的状态。
具体来说，当用户首次访问服务器时，服务器会为其生成一个唯一的 session ID，并将其存储在服务器端的内存中或者持久化到数据库中。随后，服务器会将 session ID 通过 Cookie 或者 URL 参数的方式发送给客户端。客户端在随后的请求中会携带该 session ID，服务器端就可以根据该 session ID 找到对应的用户信息，从而保持会话状态。
如果A同学知道B同学的SESSION-ID是否可以登录B账户？
如果A同学知道B同学的SESSION-ID，A同学可以在一定程度上模拟B同学的身份登录B同学的账户。但是，这需要A同学在登录之前知道B同学的SESSION-ID，并且能够在SESSION过期之前使用该SESSION-ID进行登录，这通常是比较困难的。此外，如果B同学在登录时设置了额外的安全措施，例如双因素身份验证或IP地址绑定等，A同学也无法轻易登录B同学的账户。因此，保护SESSION-ID的安全性是非常重要的。
Web 缓存
略略略
条件 GET：允许缓存器证实它的对象是否为最新。
网络应用 —— 电子邮件
主要组成部分：
- 用户代理：端系统中的邮箱软件
- 邮件服务器：维护客户的邮件和客户要发送的邮件
- 简单邮件传输协议：SMTP
SMTP
- SMTP 是因特网电子邮件的核心。
- SMTP 基于 TCP 协议，依赖于 TCP 提供的可靠数据传输无差错地将邮件投递到接收服务器。
- SMTP 端口为 25。
- SMTP 采用直接连接，即两台主机采用 TCP 直接连接，不经过中间服务器。
- 若要发送邮件给对方，若对方的主机没有开机，则要发送的邮件将保存在自己的邮件服务器上，并等待进行新的尝试，这意味着邮件并不在中间某个邮件服务器存留。
- 报文必须为 7 位 ASCII 码。
邮件发送过程演示：
当用户 A 想要给用户 B 发送电子邮件时（20世纪90年代早期）：
- 用户 A 打开自己的邮件客户端软件（如Eudora，Outlook等）并填写电子邮件内容，包括收件人地址 B 和邮件主题等信息。
- 邮件客户端软件会将邮件内容发送给用户 A 所在的邮件服务器，这个过程中会用到 SMTP 协议。
- 用户 A 所在的邮件服务器使用 DNS 来查找接收方 B 所在的邮件服务器的IP地址。
- 一旦用户A所在的邮件服务器找到了接收方 B 所在的邮件服务器的 IP 地址，就会使用 SMTP 协议将邮件内容发送给接收方 B 所在的邮件服务器。
- 接收方 B 使用自己的邮件客户端软件（如Eudora，Outlook等）来检查邮件服务器上的新邮件。这个过程可以使用 POP3 或 IMAP 协议来完成。
- 接收方 B 的邮件客户端软件下载并显示邮件内容，B 就可以查看 A 发送的邮件了。
现代电子邮件的大致流程：
- 用户使用邮件客户端（如Outlook、Gmail、Apple Mail等）编写邮件，并填写收件人地址。
- 邮件客户端使用 SMTP 协议将邮件发送到用户所在的邮件服务器。
- 邮件服务器检查发件人地址和收件人地址，并根据 DNS 记录查找目标邮件服务器的 IP 地址。
- 发送邮件服务器使用 SMTP 协议将邮件发送到目标邮件服务器。
- 目标邮件服务器将邮件存储在自己的邮件队列中，并等待收件人访问。
- 收件人使用邮件客户端连接到目标邮件服务器，使用 POP3、IMAP 等协议检索邮件。
- 邮件客户端从邮件服务器下载邮件，并将其存储在本地计算机上的邮箱中。
- 收件人可以使用邮件客户端阅读、回复或转发邮件。
20世纪90年代早期和现代的区别：
-
安全性
前者：使用简单邮件传输协议（SMTP）和邮件访问协议（POP3）
后者：安全且高效的传输层安全协议（TLS/SSL） 和 身份验证方式（OAuth、两步认证等）
-
体验感
前者：需要手动输入命令和参数，需要有点邮件协议的基础知识才能正常的发送和接收邮件。
后者：提供了友好的操作界面。
-
数据存储和维护
前者：需要用户保留自己的邮件服务器。
后者：云端服务。
前者：复杂、不安全、需要自行维护邮件服务器。
后者：方便、安全性高、不需要自己维护邮件服务器，有云服务。
SMTP 的报文格式
From: [email protected]
To: [email protected]
Subject: Interview Jay about play game.
(text text text...)
- From：发送方邮箱地址
- To：接收方邮箱地址
- Subject：主题
- 接着一个空行（即回车换行）
- 紧接着就是具体的正文信息
SMTP 和 HTTP 的区别
略略略
邮件访问协议
POP3
IMAP
基于 Web 的电子邮件
网络应用 —— DNS：因特网的目录服务
DNS 所提供的的服务
主机名到IP地址的转换：域名到IP地址的转换。
主机别名：一台主机可以有一个或多个别名。
例如：主机名为 admin.xiaoling.com，可能存在两个别名为 xiaoling.com 和 www.xiaoling.com。
这种情况下，admin.xiaoling.com 称为规范主机名。
邮件服务器别名：允许为同一台主机创建多个别名。
负载均衡：DNS 也用于在冗余的服务器之间进行负载分配。
DNS 工作基本原理概述以及最简单的 DNS 实现方式
从主机名到IP地址转换的过程：
- 某些应用程序需要用到 DNS 转换服务时，例如浏览器输入一个 www.xiaoling.com。
- 这些应用将调用 DNS 的客户端，并指明需要转换的主机名。
- 用户主机上的 DNS 客户端接收到后，向网络中发送一个 DNS 查询报文。
- 经过若干秒后，用户主机上的 DNS 接收到一个响应报文。
- 用户主机上的 DNS 将这个响应报文传递给应用程序。
所有 DNS 请求和响应报文都是使用 UDP 数据报经过端口 53 发送。
DNS 服务器的一种简单实现就是使用一个 DNS 服务器，该服务器包含所有的映射。
这种集中式的缺点：
- 单点故障
- 通信容量
- 远距离的集中式服务
- 维护
DNS 是一个分布式数据库、层次数据库
根 DNS 服务器
根DNS服务器是DNS层次结构中的顶级服务器，它存储了整个DNS系统的顶级域名服务器的地址，负责处理来自下一级DNS服务器的请求，并将请求重定向到相应的顶级域名服务器。根DNS服务器的IP地址是固定的，并且由互联网领域的几个管理机构管理。
根DNS服务器实际上由多个服务器组成，并且它们分布在全球各地。目前有13组根DNS服务器，它们被分配了不同的IP地址，并由不同的组织或公司管理。每个根DNS服务器都有一个唯一的名称，如"A.root-servers.net"、"B.root-servers.net"等。在进行DNS解析时，本地DNS服务器将首先查询其中一台根DNS服务器，然后再查询其他级别的DNS服务器，直到找到所需的IP地址。
顶级域 DNS 服务器
顶级域DNS服务器（Top-Level Domain Name Server）是DNS层次结构中的一级域名服务器，负责管理顶级域名（如.com、.org、.net等）下的所有子域名。顶级域DNS服务器的作用是将查询请求路由到相应的下一级DNS服务器，使得域名解析能够成功完成。
这些服务器由不同的组织或公司运营和管理，它们相互之间独立，但都遵循DNS协议，使得域名解析能够协调进行。
权威 DNS 服务器
权威DNS服务器（Authoritative DNS Server）是存储特定域名的DNS记录的服务器，也是对该域名进行查询的最终答案来源。它负责管理特定域名下所有的DNS记录，比如A记录、MX记录、CNAME记录等等，以及响应特定域名的DNS查询请求。通常，权威DNS服务器是由域名所有者或者DNS记录管理者所管理的，可以自己搭建也可以由DNS服务提供商来提供。
本地 DNS 服务器
本地DNS服务器是指位于本地网络中的一台DNS服务器，用于解析网络中的域名。通常，本地DNS服务器由网络服务提供商或组织内部管理人员提供。当用户在浏览器或其他网络应用中输入一个URL或域名时，本地DNS服务器会负责将该域名转换成IP地址，以便网络应用可以通过IP地址连接到对应的服务器。本地DNS服务器通常会缓存解析的域名和IP地址，以提高后续查询的速度和效率。
DNS 的查询方式，递归？迭代？
1-8 递归，其它为迭代，虽然从形式上来看确实是这样的，日后还需要做实验来验证。
查询 gaia.cs.umass.edu 过程：
- 请求主机向本地 DNS 服务器发送一个 DNS 请求。
- 本地找不到
gaia.cs.umass.edu记录，那就中转根 DNS 服务器。 - 根 DNS 服务器观察发现 .edu，返回给本地 DNS 服务器一个 “.edu 顶级域” 的 IP 地址。
- 本地 DNS 服务器接收到 “.edu 顶级域” 的 IP 后，去向该顶级域发送一个 DNS 请求。
- 顶级域观察发现
umass.edu，在本服务器中找到umass.edu的记录信息，得到umass.edu的权威服务器 DNS，名为dns.umass.edu。 - 向该权威服务器
dns.umass.edu发送一个 DNS 请求。 - 权威服务器观察发现
gaia.cs.umass.edu，返回该域名真实 IP。 - 本地 DNS 服务器得到后返回给请求主机。
上面的例子假设了 TLD 知道主机的权威 DNS 服务的 IP 地址。一般的，TLD 服务器只是知道中间的某个 DNS 服务器，该中间 DNS 服务器依次才能知道用于该主机的权威 DNS 服务器。
假设 dns.umass.edu 是马萨诸塞大学的一台 DNS 服务器，每个院系的 DNS 服务器是本系所有主机的权威服务器，例如 dns.cs.umass.edu。
在这种情况下，当中间 DNS 服务器 dns.umass.edu 收到了对某主机的请求时，假设请求 cs.umass.edu。
dns.umass.edu返回给dns.nyu.edu一个dns.cs.umass.edu的 IP 地址。- 后者
dns.cs.umass.edu是cs.umass.edu的一个权威 DNS 服务器。 - 接着本地 DNS 服务器
dns.nyu.edu向权威 DNS 服务器发送 DNS 请求，该权威 DNS 服务器会返回一个cs.umass.edu的 IP 地址。
DNS 缓存
根DNS服务器、顶级域DNS服务器、权威DNS服务器和本地DNS服务器都有缓存。缓存的目的是减少对上层DNS服务器的查询次数，提高DNS查询效率。缓存的过期时间根据DNS记录中的TTL(Time To Live)字段进行设置。一般情况下，缓存时间比较短，以确保DNS信息的及时更新。具体缓存策略可以根据实际情况进行配置。
DNS 记录和报文
资源记录
DNS 分布式数据库的所有 DNS 服务器都存储了资源记录（Resource Record, RR），RR 提供了主机名到IP地址的映射。
每个 DNS 回答报文包含了一条或多条资源记录。这些记录全都存储在了各个 DNS 服务器上，当有请求的时候会返回对应的记录信息。
资源记录的格式是个 4 元组：(Name, Value, Type, TTL)
- TTL：该记录的生存时间。
Name 和 Value 的值取决于 Type：
| Type | Name | Value | 例子 |
|---|---|---|---|
| A | 主机名 | 该主机名对于的IP地址 | (www.xiaolingya.com, 10.2.3.4, A) |
| NS | 域 | 该域 IP 所对应的权威 DNS 服务器的主机名 | (foo.com, dns.foo.com, NS) |
| CNAME | 别名 | 别名为 Name 的主机所对应的规范主机名 | (foo.com, relay1.bar.foo.com, CNAME) |
| MX | 邮箱别名 | 邮箱别名的邮件服务器的规范主机名 | (foo.com, mail.bar.foo.com, MX) |
DNS 报文
| 字段名称 | 字段长度 | 字段描述 |
|---|---|---|
| 事务ID（ID） | 16 bits | 该查询的唯一标识符，由DNS服务器返回响应时也会包含此字段 |
| 标志（Flags） | 16 bits | 分为QR、OPCODE、AA、TC、RD、RA、Z、RCODE八个位段 |
| 问题数（QDCOUNT） | 16 bits | DNS请求中的问题数 |
| 回答数（ANCOUNT） | 16 bits | DNS响应中回答的记录数 |
| 授权回答数（NSCOUNT） | 16 bits | DNS响应中权威服务器记录数 |
| 额外记录数（ARCOUNT） | 16 bits | DNS响应中附加的记录数 |
| 问题区域（Question Section） | 0或多个记录 | 通常包含一个查询的域名和类型字段 |
| 回答区域（Answer Section） | 0或多个记录 | 包含DNS服务器响应的资源记录 |
| 授权区域（Authority Section） | 0或多个记录 | 通常包含一个指向权威DNS服务器的资源记录 |
| 附加区域（Additional Section） | 0或多个记录 | 包含有关查询的其他信息的资源记录 |
**其中标志字段的位段描述如下： **
| 位段 | 长度 | 描述 |
|---|---|---|
| QR | 1 bit | 指定消息是查询还是响应 |
| OPCODE | 4 bits | 指定查询的类型，如标准查询、反向查询等 |
| AA | 1 bit | 指示响应的权威性，1表示响应来自权威DNS服务器 |
| TC | 1 bit | 指示响应是否太大，无法适合单个UDP数据报 |
| RD | 1 bit | 指示是否需要递归解析 |
| RA | 1 bit | 指示DNS服务器是否支持递归查询 |
| Z | 3 bits | 保留字段 |
| RCODE | 4 bits | 指示响应的状态，如无法解析域名等 |
在 DNS 数据库中插入记录
当一个新的域名需要被添加到 DNS 服务器上时，通常需要经历以下步骤：
-
向注册局注册域名并提供域名服务器信息：域名的所有者需要通过向域名注册局注册域名的方式将域名添加到 DNS 服务器上。在注册时，所有者需要提供域名服务器的信息，以便 DNS 查询能够顺利地进行。
-
在顶级域 DNS 服务器上添加 NS 记录：在注册局接受域名注册并将域名的信息发送给顶级域 DNS 服务器之后，顶级域 DNS 服务器需要将 NS（Name Server）记录添加到其 DNS 数据库中。这个 NS 记录指向提供该域名的权威 DNS 服务器的地址。例如，如果新的域名是 example.com，则需要在 .com 的 DNS 服务器上添加一个 NS 记录，它指向 example.com 域名的权威 DNS 服务器。
(example.com, dns1.example.com, NS) -
在权威 DNS 服务器上添加 DNS 记录：在顶级域 DNS 服务器将 NS 记录添加到其 DNS 数据库之后，权威 DNS 服务器需要添加域名的其他 DNS 记录，例如 A、MX、CNAME 等记录。这些记录是根据用户的需求和网络拓扑来添加的。例如，如果要将域名 example.com 映射到 IP 地址 203.0.113.1，则需要在权威 DNS 服务器上添加一个 A 记录。
(dns1.example.com, 203.0.113.1, A) -
最后，本地 DNS 服务器缓存记录：当 DNS 查询到达本地 DNS 服务器时，它会尝试查找所需的记录。如果找到了，则 DNS 服务器将缓存该记录以供以后使用，以避免重复查询。
需要注意的是，DNS 记录的添加过程可能需要一些时间来传播到全球 DNS 服务器中。这是因为 DNS 记录的复制是异步的，并且每个 DNS 服务器都有自己的 TTL（Time To Live）时间，它决定了该记录可以被缓存的时间。因此，在修改 DNS 记录时，可能需要一些时间才能在全球范围内看到结果。
域名注册机构：
域名的注册登录机构是指被ICANN（互联网名称与数字地址分配机构）授权管理注册和管理顶级域名的机构。这些机构被称为注册机构（Registrar），它们提供域名注册服务，并与顶级域名服务器（TLD）合作，确保域名系统（DNS）的稳定运行。注册机构需要遵守ICANN的规定，并支付注册费用，同时也可以向客户提供其他增值服务，如DNS托管、Whois隐私保护、SSL证书等。常见的注册机构包括GoDaddy、Namecheap、域名.com等。
网络应用 —— P2P
文件分发时间
客户端-服务器方式
服务器的工作：必须向每个对等方发送该文件的一个副本，即 N 个客户就要上载（发送） N 个副本。
客户端的工作：每个客户端必须下载一个文件的副本。
假设服务器只发送一个文件副本： F U S \frac{F}{U_S} USF
假设服务器要发送多个文件副本： N F U S \frac{NF}{U_S} USNF
结论：将一个 F 大小的文件分发给 N 个客户端耗时为：
D c s ≥ { N F u s , F d m i n } D_{cs} \ge \begin{Bmatrix} \frac{NF}{u_s}, \frac{F}{d_{min}} \end{Bmatrix} Dcs≥{usNF,dminF}
P2P 方式
服务器的工作：至少需要上载一份文件副本。
客户端的工作：每个客户端必须下载一个文件副本。
BitTorrent
BitTorrent 算术一种用于文件分发的点对点（P2P）文件共享协议。
BitTorrent 可以让一个文件被分割为多个块，每个块都可以从不同的对等方下载。这样还可以从其它正在下载该文件的用户那里下载该文件的不同部分。
洪流与跟踪器
**洪流：**参与一个特定文件的分发的所有对等方的集合。
**跟踪器（Tracker）：**洪流的基础设施节点。
- 当一个对等方加入洪流时，它向跟踪器注册自己。
- 对等方以周期性地通知追踪器它仍在该洪流中。
- 主要作用是维护和跟踪所有客户端的信息，包括当前下载和上传的对等方列表、文件分块情况等。
- 对等方定期向 Tracker Server 发送请求并报告他们的下载和上传情况，Tracker Server 会回复一个可下载的对等方列表，对等方从列表中选择一个或多个对等方来下载文件分块。
当一个用户加入洪流时，会发生的情况
当一个用户加入一个 BitTorrent 洪流时，会发生以下几个步骤：
- 客户端启动：用户启动 BitTorrent 客户端，并加载种子文件，从而获得要下载的文件的信息和 Tracker Server 的地址。
- 连接 Tracker Server：客户端向 Tracker Server 发送 HTTP GET 请求，请求 Tracker Server 向其返回种子文件所列出的所有对等方的 IP 地址和端口号。Tracker Server 在返回响应时，会返回一个列表，其中包含了所有可用对等方的信息。
- 连接对等方：客户端根据 Tracker Server 返回的对等方列表，建立与一些对等方的连接。客户端会尝试连接所有可用的对等方，但可能会因为某些原因连接失败。如果连接成功，客户端会向对等方发送握手消息，协商连接和文件的相关信息。
- 交换数据：一旦连接建立，对等方之间就可以开始交换数据了。客户端会请求缺少的数据块，并将自己拥有的数据块发送给对等方。这种交换是基于 tit-for-tat 的原则进行的，即一个对等方只会将数据块发送给另一个对等方，如果后者同样可以将一些数据块发送给前者。这种交换方式有助于平衡上传和下载速度，从而提高整个洪流的效率。
- 下载完成：当一个对等方下载完整个文件时，它会成为一个 seed（种子）。此时，其他对等方可以从它那里获取完整的文件。当所有的对等方都成为 seed 后，该洪流就会被关闭。
tit-for-tat
tit-for-tat 是 BitTorrent 协议中用来促进对等方之间资源共享的一种策略。其基本思想是对于与其进行文件交换的对等方，它会优先将文件块发送给那些曾经发送过文件块的对等方，同时也会惩罚那些拒绝发送文件块的对等方，从而鼓励所有对等方积极参与文件共享。
具体而言，tit-for-tat 策略分为两个阶段：
-
合作阶段
在这个阶段中，对等方会主动向其他对等方发送文件块，以达成资源共享的目的。同时，它会记录每个对等方曾经发送的文件块，并给予积极的反馈。这样，对于那些愿意分享资源的对等方，tit-for-tat 会优先将文件块发送给它们，从而加快文件下载的速度。
-
惩罚阶段
在这个阶段中，如果对等方拒绝发送文件块，tit-for-tat 会对其进行惩罚。具体而言，tit-for-tat 会停止向该对等方发送文件块，同时还会将其从优先列表中删除。这样一来，该对等方将无法获得其他对等方的文件块，从而导致其下载速度变慢。
（列表中被删除了后，就不会与对方分享文件块，因为它道德败坏，若表现良好，则有机会重新加入列表）
tit-for-tat 策略的本质是通过合作与惩罚来促进资源共享，从而达到加快文件下载速度的目的。该策略已被证明在 BitTorrent 协议中是非常有效的，因为它能够充分利用对等方之间的合作，同时也能够防止一些恶意对等方破坏资源共享的稳定性。
种子
BitTorrent 使用了一种称为种子（Torrent）的文件格式，其中包含了共享文件的元数据（例如文件名、文件大小、文件块哈希值、种子文件创建者等）以及跟踪器（Tracker）的 URL。
每个文件都有一个唯一的文件块哈希值，便于验证所下载文件的完整性和正确性。
网络应用 —— 视频流和内容分发
因特网视频
-
视频是一系列图片，通常以一种恒定速率来展现。
-
图像是由像素阵列组成，其中每个像素都是由一些比特编码来表示的颜色和亮度。
-
视频的特征：能被压缩，因此可以用比特率来权衡视频的质量。
比特率越高，图像质量越好。
-
流式视频最重要的性能度量是平均端到端的吞吐量。
-
视频能使用压缩算法生成相同视频但不同质量的多个版本。例如：300kbps、1Mbps、3Mbps。
用户可以根据带宽自行选择看哪个版本。
HTTP 流和 DASH
HTTP流和DASH都是用于在Web上实现视频流传输的技术。
HTTP流是基于HTTP协议的一种流媒体传输技术，它将视频数据分割成若干个小的数据块，并通过HTTP协议分段传输，每个数据块可以独立请求和传输，用户可以在数据传输的同时观看视频。HTTP流技术采用自适应码率技术，可以根据网络带宽和设备性能调整视频的码率和质量，从而提供更好的观看体验。但是，由于HTTP流是基于HTTP协议的，因此它具有延迟高、带宽低、卡顿现象等问题。
HTTP动态适应性流（HTTP Dynamic Adaptive Streaming，简称DASH），是一种基于HTTP的视频流传输技术，它可以在不同的设备和网络条件下提供一致的观看体验。DASH技术将视频分割成多个小片段，每个小片段有不同的码率和质量，服务器根据客户端的带宽和性能，动态调整传输的视频质量和码率。DASH技术可以使用MP4、WebM、MPEG-DASH等多种格式，其中MPEG-DASH是最流行的格式之一。相比于HTTP流，DASH技术具有更低的延迟、更好的自适应性和更高的效率，因此在Web视频传输中得到了广泛应用。
内容分发网
为什么要使用 CDN，没有 CDN 时会…
- 网络延迟高：用户请求访问网站时，由于用户可能与服务器的距离较远，网络延迟高，因此用户可能需要等待较长的时间才能加载网页内容。
- 服务器负载高：用户请求直接发送到源服务器，源服务器需要承担全部流量和负载，可能导致服务器过载、崩溃等问题。
- 地域覆盖不全：网站的服务范围受限于源服务器的位置，可能无法覆盖全球范围内的用户，导致用户体验不佳。
- 安全风险：源服务器容易成为攻击目标，可能会暴露服务器的安全漏洞，造成数据泄漏和其他安全问题。
使用CDN可以提高网站的访问速度、可靠性和稳定性，降低带宽费用，支持高并发和大流量，提高全球访问速度。
部署策略
深入：
通过遍及全球的接入 ISP 中部署服务器集群来深入到 ISP 的接入网中。其目的是靠近端用户，减少端用户和 CDN 集群之间链路和路由器的数量，即跳转次数变少了，从而改善了时延和吞吐量，同时缺点是维护和管理集群非常麻烦。
邀请做客：
采取的策略是将服务器集群放置到 IXP 附近，便于与 ISP 建立互联互通关系，从而提高数据的可及性和可靠性。降低维护和管理开销，代价是端用户的较高时延和较低吞吐量。
CDN 集群：
一旦 CDN 集群准备就绪，就可以跨集群复制内容。
你可以选择把所有视频在集群中全部存一份副本，也可以只选择存储常用的。
事实上，我们可以使用一种简单的拉策略：若客户向一个未存储该视频的集群请求某视频，则该集群检索该视频（从某个中心仓库或从另一个集群），向客户流式传输视频的同时也在本地（指的集群）存储一个副本。当某集群容量满时，它将删除不经常请求的视频。
CDN 访问流程
假设内容提供商 NetCinema 雇佣了第三方 CDN 公司 KingCDN 来向客户分发视频。
- 用户访问了位于 NetCinema 的 Web 首页。
- 用户点击了链接 http://video.netcinema.com/1.mp4，向本地 DNS 服务器发送一个 DNS 请求。
- 本地 DNS 服务器没有记录，那就(先查根 DNS -> .com 顶级域 DNS) 最后到达 netcinema.com 的权威 DNS 服务器。（括号括起来的是图省略了）
NetCinema 权威 DNS 服务器观察到有个子域 video，得到了 KingCDN 的主机名 a1105.kingcdn.com。 - 本地 DNS 服务器收到 a1105.kingcdn.com 后，查询 LDNS 是否有该记录，没有，那就(查询根 DNS -> .com 顶级域 DNS)，最终到达 a1105.kingcdn.com 的权威服务器，该权威服务器的 DNS 系统最终向 LDNS 返回 KingCDN 内容服务器的 IP 地址。（此时，在 KingCDN 的 DNS 系统中，指定了 CDN 服务器，客户将能够从这台服务器接收它的内容）
- LDNS 响应回用户机一个 CDN 节点的 IP 地址。
- 一旦客户收到 KingCDN 内容服务器的 IP 地址，与该 IP 建立 TCP 链接，并发出对该视频的 HTTP 请求。
集群选择策略
略…