传输层提供的服务
传输层的复用与分用
复用: 发送方多个不同的应用进程可以使用同一个{传输层协议}传送数据
分用: 接收方能够把数据正确交付到多个不同{应用进程}
Q: 传输层要对收到的报文段的哪些部分进行差错检测?
A: 伪首部+首部 (去除 FCS 字段)+数据部分
Q: TCP 和 UDP 计算校验和的时候, 都需要添上伪首部吗?
A: 需要
Q: 为什么传输层要对收到的报文段的首部和数据部分都要检测?
A: 传输层需要向上提供可靠服务
数据部分的差错检测, 是可靠服务的必要条件
传输层
TCP 协议, 从逻辑上看, 是一条{c1: 可靠}的{c1: 全双工}(单工/半双工/全双工) 信道
UDP 协议, 从逻辑上看, 是一条{c2: 不可靠}信道
Q: 套接字 (Socket) 是由什么组成的?
A: IP 地址: 端口号
Q: TCP 与 UDP 都可以进行复用与分用吗?
A: 是的
两个协议都可以进行复用与分用
协议
Q: UDP 与 TCP 首部长度可变吗?
A: UDP 不可变, TCP 可变
TCP 存在一个最大大小为 40B 的可选字段
UDP 可以支持一对一, 一对多, 多对一和多对多的交互通信.
TCP 每一条 TCP 连接只能是一对一的.
Q: UDP 与 TCP 有拥塞控制机制吗?
A: - UDP: 没有
UDP 可以接受部分报文段被丢弃, 但是不能接受拥塞控制带来的延迟
例如 FPS 中, 对于丢包的容忍度是比延迟的容忍度要高的
- TCP: 有的
TCP 供可靠交付的服务, 保证传送的数据无差错, 不丢失, 不重复且有序
为了避免拥塞导致的丢失, 一定要有拥塞控制机制
UDP
Q: UDP 首部字段组成
A: 
每个字段的长度都是 2B
- 源端口号
- 目的端口
- 长度: UDP 报文段的长度 (包括首部和数据), 其最小值是 8 (仅有首部)
- 检验和: 检测 UDP 报文段在传输中是否有错. 该字段是可选的, 当源主机不想计算检验和时, 则直接令该字段为全 0
Q: UDP 报文段对哪些部分计算检验和
A: 12B 伪首部+首部+数据项
UDP 报文最短长度为{8}B
TCP
Q: TCP 两端都需要设置发射缓冲与接受缓冲吗?
A: 需要
TCP 在逻辑上是一个全双工的信道
允许通信双方的应用进程在任何时候都能发送数据
为实现全双工, 需要在 TCP 连接的两端都设置发送缓存和接收缓存, 用来临时存放双向通信的数据
TCP 首部最短长度为{c1:20B}, 最长长度为{c1:60B}, 长度为{c2:4B}的整数倍
Q: TCP 报文段对哪些部分计算检验和
A: 12B 伪首部+首部+数据项
三次握手与四次挥手
Q: TCP 是在什么之间建立的连接?
A: 每一条 TCP 连接建立在两个端点 (即两个套接字) 之间
TCP 连接中 seq 与 ack 的含义
Seq (Sequence Number，序列号):{c1: 己方发送报文段第一字节的序号}
Ack (Acknowledgment Number，确认号):{c1: 期待对方发送的下一报文段第一字节的序号}
Q: TCP 三次握手, 交换的报文信息为
A: 1. 客户机到服务器: SYN=1, seq=x
2. 服务器到客户机: SYN=1, ACK=1, seq=y, ack=x+1
3. 客户机到服务器: ACK=1, seq=x+1, ack=y+1
Q: TCP 三次握手, 对于序号的消耗情况如何?
A: 第一次握手与第二次握手一定是消耗序号的
第三次握手消耗序号与否, 取决于是否携带了数据
如果携带数据, 则消耗序号
否则, 不消耗序号
Q: TCP 四次挥手, 交换的报文信息为:
A: 1. 客户机到服务器: FIN=1, seq=u
2. 服务器到客户机: ACK=1, seq=v, ack=u+1
3. 服务器到客户机: FIN=1, ACK=1,seq=w, ack=u+1
4. 客户机到服务器: ACK=1, seq=u+1, ack=w+1
Q: TCP 四次挥手中, 主动方→被动方: FIN=1, SEQ=u 后, 主动方还能够发送数据或接受数据吗?
A: 不能够发送数据, 但是能够接受来自被动方的数据
Q: TCP 四次挥手中, 客户机最后发送确认帧之后, 为什么还要等待 2MSL 时间, 才能够释放 TCP 连接?
A: 确保确认帧能够送达服务器
客户机在发送完最后一个 ACK 后, 进入 TIME-WAIT 状态, 并等待 2MSL.
这段时间足以让丢失的 ACK 所对应的 FIN 报文被服务器重传, 并再次到达客户机.
处于 TIME-WAIT 状态的客户机如果再次收到了 FIN, 它就知道自己之前发送的 ACK 可能丢失了, 于是会重新发送一次 ACK, 并重置 2MSL 计时器.
这样, 服务器最终能够收到确认, 从而正常关闭连接.
Q: TCP 三次握手, 画图
A: 
Q: TCP 四次挥手, 画图
A: 
TCP 可靠传输
TCP 把数据视为一个无结构但有序的{字节流}, 而不是报文段
TCP 使用{c1: 累计}确认方式
Q: 什么是累计确认方式
A: 接收方在发送确认 (ACK) 时, 不仅确认最后一个正确接收的数据包, 还隐式确认了之前所有已成功接收的数据包
Q: 哪两种事件会导致 TCP 对报文段进行重传?
A: 超时和冗余 ACK
TCP 流量控制与拥塞控制
拥塞控制与流量控制的区别:
拥塞控制: 发送方与{所有接收方}, 确保网络能够承受负荷, 涉及所有主机, 路由器及降低性能的因素, 目标是避免{整个网络过载}
流量控制: 发送方与{单个接收方}, 接收方控制发送方的发送速率, 确保接收方能够及时处理数据, 目标是避免{接收方过载}
Q: TCP 如何通过控制接收窗口大小实现流量控制?
A: TCP 会在确认帧中增加关于接受窗口大小的信息 rwnd=n
当发送方收到 rwnd 的大小后, 会动态调整发送窗口的大小, 使其不超过接受窗口的大小
发送窗口的上限值={c1:
TCP 进行拥塞控制的四大算法慢开始, 拥塞避免, 快重传和快恢复.
TCP 还要求发送方维持一个拥塞窗口 (cwnd),
其大小取决于网络的拥塞程度, 并且动态地变化. 发送方控制拥塞窗口的原则: 只要网络未出现
拥塞, 拥塞窗口就再增大一些, 以便把更多的分组发送出去, 以提高网络的利用率. 但只要网络
出现拥塞, 拥塞窗口就减小一些, 以减少注入到网络的分组数, 以缓解网络出现的拥塞.
Q: TCP 拥塞控制的慢开始, 具体内容
A: 初始拥塞窗口 cwnd=1, 每经过一个 RTT (每接收到一个确认 ACK), 就将拥塞窗口大小加倍, 指数增长
Q: TCP 拥塞控制的拥塞避免, 具体内容
A: 每经过一个 RTT (每收到一个确认 ACK), cwnd 就线性增长 1
Q: TCP 拥塞控制的拥塞处理, 具体内容
A: 将慢开始门限 ssthresh 设置为, 出现拥塞时的 cwnd 的一半, 再把 cwnd 设置为 1, 重新执行慢开始算法
Q: 什么情况下执行 TCP 拥塞控制的拥塞避免?
A: 拥塞窗口经过慢开始过程, 到达慢开始门限之后
Q: 什么情况下执行 TCP 拥塞控制的拥塞处理?
A: 未按时收到确认
Q: 什么情况下执行 TCP 拥塞控制的慢开始?
A: 拥塞窗口大小为 1
TCP 连接刚刚建立或拥塞处理结束之后
Q: TCP 进行拥塞控制的拥塞处理与快重传, 各自的触发条件
A: - 拥塞处理: 在发送方确认计时器超时之后
- 快重传: 在发送方连续收到三个相同的 ACK, 并且确认计时器并未超时
Q: TCP 发送方连续收到三个相同的 ACK, 并且确认计时器并没有超时的情况下, 会做出什么操作?
A: 1. 执行快重传: 立即重传与 ACK 内容相应的报文段
2. 执行快恢复:
将 ssthresh 与 cwnd 调整为当前 cwnd 的一半
执行拥塞避免算法