传输层综合练习题

解题思路：

把传输层的功能归成五类：交付给应用什么、如何寻址、如何在应用间共享介质、对错误做什么、对速率做什么。

详细步骤：

传输层的主要功能包括：

1. 端到端进程通信：

   • 为应用层进程提供通信服务
   • 在源主机和目标主机之间建立逻辑连接
   • 将数据从源进程传递到目标进程

2. 传输层寻址：

   • 使用端口号标识主机内的进程
   • 实现进程间的通信
   • 支持多路复用

3. 复用与分用：

   • 多个应用层进程共享传输层服务
   • 将接收到的数据分发给相应的应用层进程
   • 实现多路复用

4. 差错检测与可靠性：

   • 检测数据传输过程中的错误
   • 确保数据完整、有序、无重复传输
   • 提供重传机制

5. 流量控制：

   • 防止发送方过快导致接收方缓冲区溢出
   • 控制数据传输速率
   • 保证网络稳定性

最终答案：

传输层负责进程间寻址与复用解复用、可靠有序传输以及流量控制。

解题思路：

先说明端口号的几种作用，再按所属的 IANA 区间列出值得记忆的端口。

详细步骤：

端口号的作用：

1. 进程标识：唯一标识主机内的进程
2. 服务区分：区分不同的网络服务
3. 连接标识：在 TCP 中标识连接
4. 数据分发：将数据分发给正确的应用进程

常见端口举例：

熟知端口（0-1023）：

• 20/21：FTP（文件传输协议）
• 22：SSH（安全外壳协议）
• 23：Telnet（远程登录）
• 25：SMTP（简单邮件传输协议）
• 53：DNS（域名系统）
• 80：HTTP（超文本传输协议）
• 110：POP3（邮局协议）
• 143：IMAP（互联网消息访问协议）
• 443：HTTPS（安全超文本传输协议）

注册端口（1024-49151）：

• 1433：Microsoft SQL Server
• 1521：Oracle 数据库
• 3306：MySQL 数据库
• 5432：PostgreSQL 数据库
• 6379：Redis
• 8080：HTTP 代理

最终答案：

端口号既标识进程又区分协议类型，需记住的知名端口有 20/21、22、23、25、53、80、110、143、443 等。

解题思路：

在真正会改变应用行为的维度上对比两种协议，再说明各自服务的场景。

详细步骤：

主要区别：

1. 连接方式：

   • UDP：无连接，不需要预先建立连接
   • TCP：面向连接，需要先建立连接

2. 可靠性：

   • UDP：不可靠，不保证数据包到达
   • TCP：可靠，保证数据完整传输

3. 流量控制：

   • UDP：无流量控制
   • TCP：有流量控制，防止接收方过载

4. 拥塞控制：

   • UDP：无拥塞控制
   • TCP：有拥塞控制，适应网络状况

5. 传输效率：

   • UDP：效率高，协议开销小
   • TCP：效率较低，协议开销大

6. 延迟：

   • UDP：延迟低，适合实时应用
   • TCP：延迟较高，适合可靠传输

7. 适用场景：

   • UDP：实时应用、简单查询
   • TCP：文件传输、Web 浏览

最终答案：

TCP 可靠有序但开销大、时延高，UDP 高效低时延；文件传输与 Web 浏览选 TCP，实时与简单查询选 UDP。

解题思路：

按「让 UDP 成为正确选择的那个属性」给场景分组，并逐组说明理由。

详细步骤：

UDP 适用于以下应用场景：

1. 实时应用：

   • 语音传输：对延迟敏感，允许少量丢包
   • 视频传输：实时性要求高，允许部分丢包
   • 在线游戏：实时交互，低延迟要求

2. 简单查询服务：

   • DNS 查询：简单快速，一次请求一次响应
   • DHCP：自动分配 IP 地址，广播通信
   • SNMP：网络管理，简单监控

3. 广播/组播应用：

   • 网络广播：一对多通信
   • 组播应用：视频会议、直播
   • 网络发现：设备发现服务

4. 对实时性要求高的应用：

   • 网络游戏：实时交互
   • 流媒体：音频视频传输
   • 网络监控：设备状态监控

5. 简单高效的应用：

   • 简单协议：自定义协议
   • 轻量级服务：简单查询
   • 临时通信：临时数据传输

最终答案：

UDP 适合可容忍丢包的实时业务、一对多的广播组播，以及自定义的简单轻量服务。

解题思路：

按这些机制作用于报文段的先后顺序来列：编号、确认、重传、窗口，最后是两个保护接收方与网络的控制回路。

详细步骤：

TCP 通过以下机制实现可靠传输：

1. 序号机制：

   • 每个字节都有唯一序号
   • 用于标识数据段顺序
   • 支持乱序重组

2. 确认机制：

   • 累积确认：确认号表示期望收到的下一个字节
   • 延迟确认：减少网络开销
   • 选择性确认：确认特定数据段

3. 超时重传：

   • 动态调整超时时间
   • 指数退避算法
   • 快速重传机制

4. 滑动窗口：

   • 发送窗口控制发送速率
   • 接收窗口控制接收能力
   • 动态调整窗口大小

5. 流量控制：

   • 防止发送方过快
   • 匹配发送和接收速率
   • 避免接收方缓冲区溢出

6. 拥塞控制：

   • 慢启动算法
   • 拥塞避免算法
   • 快重传和快恢复

最终答案：

TCP 依靠序号、确认重传和滑动窗口实现可靠有序传输，并用流量控制与拥塞控制调节发送速率。

解题思路：

把两者当成受控对象不同的两个控制回路：流量控制保护接收方，拥塞控制保护网络。

详细步骤：

主要区别：

1. 控制目标：

   • 流量控制：防止接收方缓冲区溢出
   • 拥塞控制：防止网络拥塞

2. 控制对象：

   • 流量控制：端到端控制
   • 拥塞控制：网络整体控制

3. 控制机制：

   • 流量控制：基于接收窗口大小
   • 拥塞控制：基于网络拥塞状况

4. 控制参数：

   • 流量控制：接收方通告的窗口大小
   • 拥塞控制：拥塞窗口大小

5. 控制算法：

   • 流量控制：滑动窗口机制
   • 拥塞控制：慢启动、拥塞避免等算法

6. 影响范围：

   • 流量控制：影响单个连接
   • 拥塞控制：影响整个网络

7. 触发条件：

   • 流量控制：接收方缓冲区满
   • 拥塞控制：网络拥塞、丢包等

最终答案：

流量控制保护接收方、影响单个连接，拥塞控制保护整个网络、在丢包与拥塞时触发。

解题思路：

把握手和挥手都写成报文段的交互，每一步之后标出各端进入的状态。

详细步骤：

TCP 连接建立（三次握手）：

1. 第一次握手：

   • 客户端发送 SYN=1, seq=x
   • 客户端进入 SYN_SENT 状态
   • 服务器收到后进入 SYN_RCVD 状态

2. 第二次握手：

   • 服务器发送 SYN=1, ACK=1, seq=y, ack=x+1
   • 服务器确认客户端的连接请求
   • 客户端收到后进入 ESTABLISHED 状态

3. 第三次握手：

   • 客户端发送 ACK=1, seq=x+1, ack=y+1
   • 客户端确认服务器的连接确认
   • 服务器收到后进入 ESTABLISHED 状态

TCP 连接释放（四次挥手）：

1. 第一次挥手：

   • 客户端发送 FIN=1, seq=u
   • 客户端进入 FIN_WAIT_1 状态
   • 服务器收到后进入 CLOSE_WAIT 状态

2. 第二次挥手：

   • 服务器发送 ACK=1, ack=u+1
   • 服务器确认客户端的结束请求
   • 客户端收到后进入 FIN_WAIT_2 状态

3. 第三次挥手：

   • 服务器发送 FIN=1, seq=v
   • 服务器进入 LAST_ACK 状态
   • 客户端收到后进入 TIME_WAIT 状态

4. 第四次挥手：

   • 客户端发送 ACK=1, ack=v+1
   • 客户端等待 2MSL 后进入 CLOSED 状态
   • 服务器收到后进入 CLOSED 状态

最终答案：

连接建立需三次握手、关闭需四次挥手，正确性来自各端状态机的迁移而非标志位本身。

解题思路：

用「每个报文段排除了哪种故障」来作答，再补上历史连接与资源两方面的理由。

详细步骤：

TCP 连接建立需要三次握手的原因：

1. 确保双向通信：

   • 第一次握手：客户端 → 服务器，确认客户端发送能力
   • 第二次握手：服务器 → 客户端，确认服务器收发能力
   • 第三次握手：客户端 → 服务器，确认客户端接收能力

2. 防止历史连接干扰：

   • 如果只有两次握手，历史连接可能被误认为新连接
   • 三次握手确保连接的唯一性
   • 避免数据混乱

3. 同步序号：

   • 客户端和服务器都需要知道对方的初始序号
   • 确保数据的有序传输
   • 为可靠传输做准备

4. 资源分配：

   • 服务器在收到第三次握手后才分配资源
   • 避免资源浪费
   • 防止 SYN 攻击

5. 状态确认：

   • 双方都确认连接已建立
   • 可以开始数据传输
   • 状态机正确转换

最终答案：

三次握手是为了防止失效的连接请求浪费服务器资源、同步双方初始序号并让服务器在第三次握手后才分配资源。

解题思路：

从需求出发而不是从协议出发，先列出把选择推向 UDP 的需求，再列出推向 TCP 的需求。

详细步骤：

选择 UDP 的情况：

1. 实时性要求高：

   • 语音、视频传输
   • 在线游戏
   • 实时监控

2. 允许少量数据丢失：

   • 实时应用可以容忍少量丢包
   • 数据可以快速重传
   • 对完整性要求不高

3. 简单查询服务：

   • DNS 查询
   • DHCP 服务
   • 简单状态查询

4. 广播/组播应用：

   • 网络广播
   • 视频会议
   • 网络发现

选择 TCP 的情况：

1. 可靠性要求高：

   • 文件传输
   • 邮件传输
   • 数据库连接

2. 数据完整性重要：

   • 不允许数据丢失
   • 需要保证数据顺序
   • 对准确性要求高

3. 大数据量传输：

   • 文件下载
   • 数据库备份
   • 系统镜像传输

4. 交互式应用：

   • Web 浏览
   • 远程登录
   • 在线支付

最终答案：

实时性优先或可容忍丢包选 UDP，要求可靠有序或大数据量传输选 TCP。

解题思路：

按每种算法如何增长窗口来描述，再归纳各自优化的目标，最后列出算法作用的四个参数。

详细步骤：

TCP 的拥塞控制算法包括：

1. 慢启动（Slow Start）：

   • 初始 cwnd=1 个 MSS
   • 每收到一个 ACK，cwnd 翻倍
   • 指数增长，快速探测网络容量
   • 直到达到 ssthresh

2. 拥塞避免（Congestion Avoidance）：

   • cwnd 达到 ssthresh 后线性增长
   • 每 RTT 增加 1 个 MSS
   • 谨慎增长，避免拥塞
   • 直到发生拥塞

3. 快重传（Fast Retransmit）：

   • 收到 3 个重复 ACK 立即重传
   • 不等待超时
   • 快速恢复，减少延迟
   • 提高传输效率

4. 快恢复（Fast Recovery）：

   • 重传后进入拥塞避免状态
   • 不进入慢启动状态
   • 保持较高的传输速率
   • 提高网络利用率

算法特点：

• 慢启动：快速探测，但可能造成拥塞
• 拥塞避免：谨慎增长，避免拥塞
• 快重传：快速响应，减少延迟
• 快恢复：保持效率，避免效率下降

参数说明：

• cwnd：拥塞窗口大小
• ssthresh：慢启动阈值
• RTT：往返时间
• MSS：最大段大小

最终答案：

慢启动、拥塞避免、快重传和快恢复共同调节拥塞窗口，作用参数是 cwnd、ssthresh、RTT 和 MSS。