计算机网络-自顶向下—第二章应用层-重点复习笔记
全部章节都有哦，具体看此博客
计算机网络-自顶向下期末复习一篇就够了——重点复习笔记整理-CSDN博客
未出现的章节一般考点较少，可以根据自己需求复习
目录
2.1应用层原理
2.2Web和HTTP
2.3电子邮件协议（SMTP）
三大组件：
SMTP 工作流程（RFC 2821）：
2.4DNS
DNS的作用
DNS简介
2.5 P2P（点到点应用）
示例场景：
客户端-服务器 vs P2P 架构的比较
2.1应用层原理
应用层协议及其底层传输协议与原因（如 Telnet、HTTP、SMTP、POP3、FTP、DNS、DHCP）
1. Telnet（远程登录）
- 传输协议：TCP
- 原因：
-
- 需要可靠的字节流传输，确保远程登录时命令和数据无差错、按序到达。
- 交互性强（如键盘输入响应），TCP 的确认机制和流量控制能保证实时性和稳定性。
2. HTTP（超文本传输协议）
- 传输协议：TCP
- 原因：
-
- 网页内容（文本、图片等）传输需高可靠性，不允许数据丢失或乱序。
- HTTP 依赖 TCP 的持久连接（HTTP/1.1），减少多次建立连接的开销，提升网页加载效率。
3. SMTP（简单邮件传输协议）
- 传输协议：TCP
- 原因：
-
- 邮件内容（文本、附件）的传输必须可靠且完整，避免因丢包导致邮件损坏或丢失。
- SMTP 的通信模型（客户端与服务器间的交互式对话）依赖 TCP 的连接稳定性。
4. POP3（邮局协议版本 3）
- 传输协议：TCP
- 原因：
-
- 从邮件服务器下载邮件时需确保数据完整，TCP 的可靠传输机制能保证邮件内容正确无误。
- 与 SMTP 一致，POP3 的命令响应模式依赖 TCP 的有序性和连接导向特性。
5. FTP（文件传输协议）
- 传输协议：TCP
- 原因：
-
- 文件传输（尤其是大文件）对完整性和准确性要求极高，TCP 的差错校验和重传机制可避免数据损坏。
- FTP 使用 “控制连接 + 数据连接” 的双连接模式，TCP 的多路复用能力支持这种复杂交互。
6. DNS（域名系统）
- 传输协议：UDP（默认）/TCP（特殊场景）
- 原因：
-
- 常规查询使用 UDP：
-
-
- 查询请求 / 响应数据量小（通常 < 512 字节），UDP 的无连接特性可降低延迟，提升解析速度。
- 短连接场景下，UDP 的轻量级优势显著（无需建立连接的三次握手）。
-
-
- 区域传输（如主从服务器同步）使用 TCP：
-
-
- 数据量大且需可靠传输，避免因丢包导致域名记录同步失败。
-
7. DHCP（动态主机配置协议）
- 传输协议：UDP
- 原因：
-
- 主机初始化时需快速获取 IP 地址等配置信息，UDP 的无连接特性适合 “请求 - 响应” 的简单交互。
- DHCP 报文通常较小（如 Discover、Offer 报文），UDP 的开销更低，适合广播或组播场景（如客户端首次启动时无 IP 地址，需广播发现服务器）。
不同的网络架构的区别，以及其适用的典型网络应用
- 客户端-服务器架构
- 对等（P2P）架构
- 混合架构（客户端-服务器 + P2P）
客户端-服务器架构
服务器端：
- 永远在线的主机
- 拥有固定 IP 地址
- 采用服务器集群（Server Farm）提升扩展能力
客户端：
- 向服务器发起通信
- 可能是间歇性在线
- IP 地址可能动态变化
- 客户端之间不直接通信
纯P2P架构
- 无永远在线的服务器
- 任意终端系统之间直接通信
- 节点间歇性连接，IP地址会变动
- 例子：BitTorrent、Skype
- 高度可扩展，但难以管理
混合架构示例：
Skype（VoIP应用）：
- 使用集中式服务器寻找对方地址
- 建立端到端的直连通信
即时通讯：
- 用户之间聊天是P2P
- 中央服务器用于用户在线状态检测和地址定位
用户进程和服务进程的区别
| 比维度 | 客户端进程（Client） | 服务器进程（Server） |
| 功能角色 | 主动发起请求，消费服务（如浏览器访问网页） | 被动提供服务，等待客户端连接（如 Web 服务器） |
| 启动方式 | 由用户主动启动（如双击应用程序） | 通常随系统启动后长期运行（如后台守护进程） |
| IP 地址与端口 | - 源 IP：动态分配（如 DHCP 获取） | - 目的 IP：固定（如服务器公网 IP） |
| 并发处理 | 一般无需处理多请求（单次连接对应单个服务） | 需支持多客户端并发连接（通过多线程、多进程或 I/O 多路复用） |
| 网络连接特性 | 主动建立连接（发起 TCP 三次握手或 UDP 请求） | 监听端口，被动接受连接（TCP 中通过 和 ） |
| 示例 | 浏览器、FTP 客户端、邮件客户端（Outlook） | Web 服务器（Nginx/Apache）、FTP 服务器、DNS 服务器 |
| 资源占用 | 通常占用资源较少（短期运行） | 长期占用 CPU、内存、网络带宽等资源（需高稳定性） |
| 防火墙规则 | 通常允许客户端主动访问外部端口（出站规则较宽松） | 需开放特定端口（如 80、443）供客户端访问（入站规则严格） |
2.2Web和HTTP
1.HTTP请求报文和应答报文的特点
HTTP 请求消息格式
两种消息类型：
- 请求（Request）
- 响应（Response）
请求示例（纯 ASCII）：
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language: fr- 请求行：GET、POST、HEAD 等
- 首部行：携带参数与元信息
表单数据上传方式
POST 上传资源方法：
- 页面包含表单输入
- 输入数据随请求体（entity body）上传
GET 获取资源方法：
- 将输入数据编码进 URL 的请求行中
示例：
www.somesite.com/animalsearch?monkeys&bananaHTTP 方法类型
HTTP/1.0 支持：
- GET：获取资源
- POST：上传资源
- HEAD：仅请求首部，不返回正文
HTTP/1.1 新增：
- PUT：上传文件至 URL 指定位置
- DELETE：删除 URL 指定的文件
HTTP 响应消息
示例：
HTTP/1.1 200 OK
Connection: close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …
Content-Length: 6821
Content-Type: text/html
[数据部分]- 状态行：协议版本 + 状态码 + 描述短语
- 首部行：说明信息
- 数据：实际返回的对象
常见状态码
200 OK：请求成功301 Moved Permanently：对象已永久转移400 Bad Request：请求格式错误404 Not Found：找不到请求对象505 HTTP Version Not Supported：不支持的协议版本
持久性链接以及非持久性连接（HTTP1.0以及HTTP1.1）
HTTP 连接类型
非持久连接（Nonpersistent HTTP）：
- 每个 TCP 连接仅传输一个对象
- HTTP/1.0 默认使用这种模式
持久连接（Persistent HTTP）：
- 一个 TCP 连接可以传输多个对象
- HTTP/1.1 默认启用持久连接
非持久 HTTP 请求过程示例：
用户访问 www.someSchool.edu/someDepartment/home.index：
- 浏览器发起 TCP 连接请求到主机端口 80
- 发送请求消息，请求页面对象
- 服务器接收请求，响应包含该对象
- 传输完毕后关闭 TCP 连接
- 浏览器解析 HTML，发现有10个 JPEG 图片引用
- 为每个图片重复上述过程
非持久 HTTP 响应时间
RTT（往返时延）：从客户端发送小包至服务器并返回的总时间
完整响应时间 =
- 1 次 RTT：建立 TCP 连接
- 1 次 RTT：发送请求并开始接收响应
-
- 文件传输时间
即总时间 ≈ 2 × RTT + 文件传输时间
持久 HTTP
非持久 HTTP 存在问题：
- 每个对象需 2 RTT
- 每个 TCP 连接带来系统开销
- 浏览器通常并行建立多个 TCP 连接
持久 HTTP 的优势：
- 服务器在发送响应后保持连接开启
- 客户端后续请求复用该连接
无流水线模式（Without Pipelining）：
- 每次收到响应后才发送下一个请求 → 每对象仍需 1 RTT
有流水线模式（With Pipelining）：
- HTTP/1.1 默认启用
- 浏览器遇到引用对象立即发送多个不同请求 → 提升效率
3.Web缓存（代理的作用）以及应用场景
基本概念
- 浏览器设置：配置为通过缓存访问 Web。
- 工作流程：
-
- 浏览器发送 HTTP 请求到缓存服务器。
- 缓存命中（Hit）：若对象在缓存中，立即返回。
- 缓存未命中（Miss）：从源服务器获取对象，存入缓存并返回给用户。
- 目标：减少对源服务器的访问，提高响应速度。
缓存示例分析
假设条件
| 参数 | 值 |
| 平均对象大小 | 1 Mb（兆比特） |
| 机构浏览器请求率 | 15 次/秒 |
| 本地路由器到源服务器的 RTT | 2 秒 |
| 局域网带宽 | 100 Mbps |
| 接入链路带宽 | 15 Mbps |
原始情况（无缓存）
- 局域网利用率：100Mbps15×1Mb=0.15=15%
- 接入链路利用率（15 Mbps）：15Mbps15×1Mb=1=100%（严重拥塞）
- 总平均时延：Internet delay+Access delay+LAN delay=2s+分钟级+毫秒级
安装缓存后（命中率 40%）
- 40% 请求：由缓存直接响应（延迟≈几毫秒）。
- 60% 请求：仍需访问源服务器（延迟≈2.01 s）。
- 接入链路利用率下降： 0.6 \times 15\,\text{Mbps} = 9\,\text{Mbps} \quad \text{（利用率降至 60%）}
- 总平均延迟优化：0.6×(2s+0.01s)+0.4×0.001s≈1.4s
缓存带来的改进
| 指标 | 无缓存 | 有缓存（40% 命中率） | 改进效果 |
| 接入链路利用率 | 100% | 60% | 减少拥塞 |
| 平均延迟 | ≥2 s | ≈1.4 s | 降低 30% |
| 源服务器负载 | 15 次/秒 | 9 次/秒 | 减少 40% |
2.3电子邮件协议（SMTP）
三大组件：
- 用户代理（UA, Mail Reader）
-
- 编写、读取邮件
- 示例：Outlook、Thunderbird、Eudora
- 本地存储发送/接收邮件
- 邮件服务器(Mail Servers)
-
- 存储收件箱
- 维护待发送邮件队列
- SMTP（Simple Mail Transfer Protocol）
-
- 用于邮件服务器间传输邮件
- 使用 TCP（端口 25）
SMTP 工作流程（RFC 2821）：
- 使用 TCP，直接在发送方与接收方服务器之间通信
- 分三步：
-
- 握手
- 邮件传输
- 连接关闭
- 命令响应交互采用 ASCII 文本
- 邮件必须是 7-bit ASCII 格式
示例：Alice 向 Bob 发邮件
- Alice 使用邮件客户端编写邮件，目标地址：bob@someschool.edu
- 客户端将邮件发送至本地邮件服务器，存入发件队列
- SMTP 客户端建立 TCP 连接到 Bob 的邮件服务器
- 通过 TCP 连接发送邮件内容
- 邮件投递至 Bob 的邮箱
- Bob 使用邮件客户端读取邮件
SMTP 示例对话：
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr
C: MAIL FROM: <alice@crepes.fr>
S: 250 OK
C: RCPT TO: <bob@hamburger.edu>
S: 250 OK
C: DATA
S: 354 Start mail input
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted
C: QUIT
S: 221 Closing connectionSMTP vs HTTP 比较：
| 特征 | SMTP | HTTP |
| 模式 | 推（push） | 拉（pull） |
| 内容结构 | 多对象合并传输（multipart） | 每个对象单独响应 |
| 连接方式 | 持久连接（persistent） | 默认无状态连接 |
| 编码格式 | 7-bit ASCII | 支持各种类型（如HTML、JSON） |
邮件格式（RFC 822）：
- 头部：
-
To:收件人From:发件人Subject:主题
- 正文：ASCII 文本（邮件主体）
- 空行分隔头部与正文
邮件访问协议
- SMTP：用于投递（客户端 → 服务器）
- POP3（Post Office Protocol）用于接收：
-
- 授权后下载邮件
- 支持“下载后删除”或“下载后保留”
- 会话间不保留状态
- IMAP （Internet Mail Access Protocol）用于接收：
-
- 所有邮件保存在服务器
- 支持文件夹、状态同步
- 会话间保持用户状态（如文件夹结构）
- HTTP(gmail, Hotmail, Yahoo! Mail, etc.)
2.4DNS
DNS的作用
人类使用“名称”访问网站（如：www.yahoo.com），而互联网使用的是IP地址（如：128.35.4.2）。
问题： 如何将域名映射为IP地址？
DNS简介
DNS 是一种分布式数据库系统，采用层次结构，由多个名称服务器构成。
- 应用层协议，用于主机、路由器和服务器之间进行名称解析
- 是互联网的核心功能之一
为什么不能集中管理 DNS？
- 单点故障风险大
- 流量过载
- 地理分布太广
- 更新维护困难
结论： 不可扩展！
DNS 提供的服务
- 主机名 → IP地址 转换
- 主机别名 → 主机名
-
- 例如：www.ibm.com 是 servereast.backup2.ibm.com 的别名
- 邮件服务器别名
- 负载分担
-
- 多个Web服务器拥有同一域名，对应不同 IP
DNS层级结构示意
一个典型的查询过程如下：
- 用户请求 www.amazon.com 的IP地址
- 本地DNS服务器向根服务器查询 com 服务器（顶级域名服务器）
- 顶级域名服务器根据本地域名服务器的请求返回全文域名服务器地址
- com 服务器回应 amazon.com 的权威DNS服务器
- 然后再由 amazon.com 的服务器返回最终的IP地址
根域名服务器（Root DNS Servers）
- 全球约有13个“逻辑”根服务器，标记为 A 到 M
- 实际上每个“根服务器”由一组物理服务器构成（冗余部署）
顶级域名服务器（TLD Servers）
- 管理 .com、.org、.edu 等域，以及国家顶级域名（如 .cn、.uk）
- Network Solutions 负责 .com
- Educause 负责 .edu
权威 DNS 服务器（Authoritative DNS Servers）：
- 由组织自身维护，为其服务器（如Web、邮件）提供权威解析
本地 DNS 服务器（Local DNS Server）
- 每个ISP或单位通常配置一个本地 DNS
- 又称“默认 DNS”
- 当主机发起查询时，首先发送给本地 DNS
- 本地 DNS 会代为查询完整的解析路径
名称解析方式：递归与迭代
迭代查询（iterated query）：
- 被查询的服务器返回“我不知道答案，但你可以问某某服务器”
递归查询（recursive query）：
- 本地 DNS 负责“到底查到为止”，将最终结果返回给主机
DNS缓存与更新
- DNS服务器会缓存其曾解析的结果
- 缓存信息会在设定时间后失效（TTL机制）
- 顶级域名服务器往往被长期缓存
动态更新机制：
- 正在设计中，见 RFC 2136
DNS 记录（Resource Record，RR）
DNS数据库包含以下类型的记录：
| 类型 | 含义 |
| A | 主机名与IP地址对应关系 |
| NS | 某域名的权威DNS服务器名称 |
| CNAME | 别名与真实主机名的对应 |
| MX | 邮件服务器信息 |
RR 格式： (name, value, type, TTL)
DNS 协议与报文结构
DNS 使用相同格式的查询与响应报文，包含以下字段：
- 标识符：16位编号，请求与响应使用相同编号
- 标志位：
-
- 是查询还是响应
- 是否允许递归
- 响应是否为权威信息
向 DNS 系统插入记录（注册新域名）
以“Network Utopia”为例：
- 注册域名
networkutopia.com（如通过 Network Solutions） - 提供权威 DNS 的主/备地址
- 注册机构将以下RR插入 .com TLD 服务器中：
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)- 创建 A记录 和 MX记录，供用户查找 Web/IP 和邮箱服务器
2.5 P2P（点到点应用）
示例场景：
- Alice 使用笔记本运行 P2P 客户端
- 她不时上网，每次连接都会获得新 IP
- 她搜索歌曲 “Hey Jude”
- 系统返回多个持有该歌曲的节点（例如 Bob）
Alice 选择 Bob，文件从 Bob 的电脑复制到她的笔记本。
同时：
- 其他用户也可以从 Alice 下载该文件
P2P 特性： 所有节点既是客户端也是服务器 → 高可扩展性！
客户端-服务器 vs P2P 架构的比较
问题： 将大小为 F 的文件从一个服务器分发给 N 个客户端，需要多长时间？
- 客户端-服务器模型：
-
- 服务器串行发送 N 份 → 时间约为
NF/us - 某客户端下载需
F/di时间 - 总耗时
dCS = max {NF/us, F/min(di)}
- 服务器串行发送 N 份 → 时间约为
- P2P 模型：
-
- 每客户端既可下载又可上传
- 所有节点共同完成上传任务
- 理想状态下总耗时：
dP2P = max {F/us, F/min(di), NF/(us + ∑ui)}