7.4.2 UDP TCP
用户数据报协议 UDP （User Datagram Protocol）
- 不需要建立连接
- 无拥塞控制
常用于流媒体数据传输
- 低负载
- 速率敏感
报文格式
- 源端口
- 目的端口
- 报文长度：指示数据报总长度，包括报头及数据区总长度
- 校验和：为0表示未选校验和，全1表示校验和位0
- 伪报头：位于UDP报头之前，用于验证UDP数据报是否被送到正确的目的节点
传输控制协议 TCP Transmission Control Protocol
用于提供可靠的面向连接的数据传输服务
TCP数据报长度要求小于64字节
TCP协议是面向字节流的，为每一个字节分配序号
TCP报头格式
- 源端口和目的端口：各16位
- 序号和确认号：以字节为单位编号，各32位
每次发送的报文段的首部中的序号字段数值表示该报文段第一个字节的序号
确认号表示接收端期望下一次收到的数据中的第一个数据字节的序号 - TCP头的长度：4位，长度单位为32字节
- 6位的保留域
- 6位的标识位：置1：有效
URG：和紧急指针配合使用，发送紧急数据
ACK：确认号是否有效
PSH：只是发送方和接收方将数据不做缓存，立刻发送或接收
RST：由于不可恢复的错误重置连接
SYN：用于连接建立指示
FIN：用于连接释放提示 - 窗口大小：基于可变滑动窗口的流控，指示发送方从确认号开始可以在发送窗口大小的字节流
- 校验和：为增加可靠性，对TCP头，数据和伪头计算校验和
- 可选项域
TCP连接管理
两军问题
三次握手建立连接
确认号：下次期望接收到的序号
为什么三次握手而不是两次？防止已经失效的连接请求报文段突然又传送到的目标节点，因而产生失误。
A向B发起握手请求，第一个请求由于网络问题阻塞在路上，超时。A再次发送握手请求，成功握手，并且A,B结束会话后，关闭了连接。此时第一个阻塞的请求到达B，B认为是正常连接请求（不知道是延迟到达的），此时如果B会正常回复A，若不等待A的第二次确认B就建立连接，则会产生一次不需要的连接请求，浪费资源。
四次挥手
TCP的传输策略
- TCP窗口管理机制
基于确认和可变窗口大小
窗口大小为0时，正常情况下，发送方不能再发TCP段；但是，1.紧急数据可以发送 2.为防止死锁，发送方可以发送1字节的TCP段，以便让接收方重新声明确认号和窗口大小 - 改进传输层性能
1.发送方缓存应用程序数据，等形成较大段再发出。
2.在没有可能进行“捎带”的情况下，接收方延迟发送确认段 - 使用Nagle算法
当应用程序每次向传输实体发出一个字节时，传输实体发出第一个字节并缓存所有其后的字节直至收到对第一个字节的确认
使用数据发送速度快，而网速较慢的情况 - 使用Clark算法解决傻窗口症状
傻窗口症状：当应用程序一次从传输层实体读出一个字节时，传输层实体会产生一个一字节的窗口更新段，使得发送方只能发送一个字节
解决办法：限制收方只有在具备一半的空缓存或最大段长的空缓存时，才产生一个窗口更新段
TCP拥塞控制
出现拥塞的两种情况
- 快网络小缓存接收者：来不及接收
- 慢网络大缓存接收者
导致网络拥塞的两个潜在原因：
- 网络能力
- 接收能力
处理快网络小缓存
- 建立连接时声明最大可接受段长度
- 利用可变滑动窗口协议防止出现拥塞
处理慢网络大缓存
- 发送方维护两个窗口：接收方的拥塞窗口，发送方窗口取两个窗口的最小值发送
- 拥塞窗口依照慢启动算法和拥塞避免算法变化
接收窗口rwnd（receiver window）
- 接收端根据其目前的接收缓存大小所许诺的最新的窗口值，是来自接收端的流量控制
- 接收端将此窗口值放在TCP报文的首部中的窗口字段，传送给发送端
拥塞窗口cwnd（congestion window）
- 发送端根据自己估计的网络拥塞程度而设置的窗口值，是来自发送端的流量控制
慢启动（slow start）算法
- 连接建立时拥塞窗口初始值为该连接允许的最大段长，不超过64K
- 发出一个最大段长的TCP段，若正确确认，拥塞窗口变为两个最大段长
- 发出（拥塞窗口/最大段长）个最大长度的TCP段，若都的到确认，则拥塞窗口加倍
- 重复上一步，直至发生丢包超时事件，或拥塞窗口大于阈值
拥塞避免（congestion avoidance）算法
- 若拥塞窗口大于阈值（预设值，如24 个最大段长24 * 64 K），从此时开始，拥塞窗口线性增长，一个RTT周期增加一个最大段长，直至发生丢包超时事件
- 当超时事件发生后，阈值设置为当前拥塞窗口大小的一半，拥塞窗口重新设置为一个最大段长；
- 执行慢启动算法
