TCP协议和UDP协议

传输层

两个主要协议：

• TCP,传输控制协议
• UDP，用户数据报协议

UDP协议（数据格式、校验和）

• UDP是无连接的，减少了建立和释放连接的开销
• UDP尽最大能力交付，不保证可靠交付
• 因此不需要维护一些复杂的参数，首部只要8个字节（TCP首部至少20个字节）

UDP-校验和（checksum）

• 校验和的计算内容：伪首部（含源IP、目标IP）+首部+数据
  • 伪首部：仅在计算校验和时起作用，不会传递给网络层

TCP协议

• 几个要点
  • 可靠传输
  • 流量控制
  • 阻塞控制
  • 连接管理（建立连接、释放连接）

• TCP首部长度为20字节~60字节
• 数据偏移
  • 占4位，取值范围（5~15）
  • 首部长度= 数据偏移*4

UDP首部中有个16位字段记录了UDP报文段的长度（首部+数据）

TCP只记录了TCP首部的长度

• 分析
• UDP首部中占16位的长度字段完全是冗余的，纯粹为了保证首部是32bit对齐
• TCP\UDP的数据长度，其实完全可以由IP数据包的首部推断出

TCP-校验和

• 同UDP一样，TCP的校验和的计算内容：伪首部+首部+数据

TCP标志位（Flags）URG ACK PSH RST SYN FIN

URG(Urgent)

• 当 URG = 1 时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送

ACK

• 当 ACK = 1 时，确认号字段才有效

RST(Reset)

• 当 RST = 1 时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接

SYN**（Synchronization）**

• 当 SYN = 1、ACK = 0 时，表明这是一个建立连接的请求
• 若对方同意建立连接，则回复 SYN = 1、ACK = 1

FIN(Finish)

• 当 FIN = 1 时，表明数据已经发送完毕，要求释放连接

TCP-序号、确认号、窗口

序号（Seq）

• 在传输过程的每一个字节都会有一个编号
• 在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号

确认号（Ack）

• 在建立连接后，确认号代表：期望对方下一次传过来的TCP数据部分的第一个字节的编号

窗口

• 该字段由流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）

TCP-【可靠传输】

可靠传输的目的：为了保证包的完整性，当有丢包、收到三次重复确认等情况，就会重新发包。

实现方式一：停止等待ARQ协议

ARQ（Automatic Repeat Request），自动重传请求

重传次数

若有个包重传了N次还是失败，会一直持续重传到成功为止吗？

• 这个取决于系统的设置，有些系统，重传5次还未成功就会发送reset(RST)报文断开TCP连接
  *

实现方式二：连续ARQ协议+滑动窗口协议

问题：

如果接收窗口最多接收4个包，但发送方只发了2个包，接收方如何确定后面还有没有2个包？

• 等待一定时间后没有第3个包，就会返回确认收到2个包返回给发送方

• 假设每一组数据是100个字节，代表一个数据段的数据
• 每一组给一个编号

SACK(选择性确认)

产生原因：

1. 在TCP通信过程中，如果发送序列中间某个数据包丢失（比如1、2、3、4、5中3丢失了）
2. TCP会通过重传最后确认的分组后续的分组（最后确认的是2，会重传3、4、5）
3. 这样原先已经正确传输的分组也可能重复发送（比如4、5），降低了TCP性能

解决：SACK（Selective acknowledgment，选择性确认）技术

1. 告诉发送方哪些数据丢失，哪些数据已经提前收到 （参照上图）
2. 使TCP只重新发送丢失的包（7），不用发送后续所有的分组（8）

SACK信息会放在TCP首部的选项部分

• Kind：占1字节。值为5代表这是SACK选项
• Length：占1字节。表明SACK选项一共占用多少字节
• Left Edge：占4字节，左边界
• Right Edge：占4字节，右边界

思考

为什么选择在传输层将数据分为多个段，而不是等到网络层再分片传递给数据链路层？

• 为了提高重传的性能
• 需要明确的是:可靠传输是再传输层进行控制
• 如果在传输层不分段,一旦出现数据丢失,整个传输层的数据都得重传
• 如果在传输层分了段,一旦出现数据丢失,只需要重传丢失的那些段即可

TCP-[流量控制]

流量控制是点对点 ,端对端两台设备之间

为什么需要流量控制?

如果接收方的缓存区满了,发送方还在疯狂着发送数据

• 接收方只能把收到的数据包丢掉,大量的丢包会极大地浪费网络资源
• 所以要进行流量控制

什么是流量控制?

• 让发送方的速率不要太快,让接收放来得及接收处理

原理

• 通过确认报文中**窗口字段(win)**来控制发送方的发送速率
• 发送放的发送窗口大小不能超过接收方的接收窗口大小
• 当发送方收到接收窗口的大小为0时,发送方就会停止发送数据

[流量控制]特殊情况

1. 一开始,接收方给发送方发送了0窗口的报文段
2. 后面,接收方又有了一些存储空间,然而在给发送方发送的非0窗口的报文段丢失了
3. 发送方的发送窗口会一直为0,双方陷入僵局

解决方案:

• 当发送放收到0窗口通知时,这时发送方停止发送报文
• 并且同时开启一个定时器,隔一段时间就发个测试报文去询问接收方最新的窗口大小
• 如果接收的窗口大小还是为0,则发送方再次刷新启动定时器

TCP-[拥塞控制]

何为拥塞控制?

• 防止过多的数据注入到网络中
• 避免网络中的路由器或链路过载

拥塞控制是一个全局性的过程

• 涉及到所有的路由器和主机
• 涉及降低网络传输有关的所有因素
• 是大家努力的结果

TCP-解决拥塞控制方法

• 慢开始
• 拥塞避免
• 快重传
• 快恢复

几个概念

• MSS(Maximum Segment Size):每个段最大的数据部分大小(在建立连接时确定)
• cwnd(congestion window):拥塞窗口
• rwnd:接收窗口
• swnd=min(rwnd,cwnd) 发送窗口

TCP-[拥塞控制]慢开始

cwnd的初始值比较小,然后随着数据包被接受方确认(收到一个ACK)

cwnd然后就成倍增长(指数级)

TCP-[拥塞控制]拥塞避免

ssthresh(slow start threshold):慢开始阈值,cwnd达到阈值,开始拥塞避免(加法增大)

拥塞避免(加法增大):拥塞窗口cwnd缓慢增大,防止网络过早出现拥塞

乘法减小:只要出现网络拥塞,把sshresh减为拥塞峰值的一半,同时执行慢开始算法(cwnd又恢复到初始值)

• 当出现频繁拥塞时,sshresh值下降的很快
• 拥塞峰值:拥塞避免(加法增大)出现丢包的cwnd的临界值

TCP-[拥塞控制]快重传,快恢复

• 快重传

• 快恢复:
  • 当发送放连续收到三个重复确认,说明网络出现拥塞(丢包了)
    • 就执行"乘法减小"算法,把 慢开始阈值(sshresh)减为拥塞峰值的一般
  • 与慢开始不同之处,是不执行慢开始算法,即cwnd现在不恢复到初始值
    • 而是把cwnd值设置为新的sshresh值(减小后的值)
    • 然后开始执行拥塞避免算法(“加法增大”),是cwnd线性增大

快重传+快恢复

发送窗口的最大值swnd = min(接收窗口cwnd, 堵塞窗口rwnd)

• 当 rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值
• 当 cwnd < rwnd 时，则是网络的拥塞限制发送窗口的最大值