1. TCP 的可靠传输

1.1 停止等待 ARQ 协议

主机采用 TCP 发出信息时会设置一个定时器, 若超出定时器所设定的时间还没有响应过来, 则主机会认为发出去的消息没有传达到目的主机, 故而将信息重新发送


当主机重传一定次数后仍然没有接收到对该消息的响应, 主机会判断网络有问题, 从而发送 RST 报文断开 TCP 连接

1.2 滑动窗口协议

对于停止等待协议, 其有一个很大的缺点: 每发送一份数据, 都需要收到来自目的主机的响应信息后才会发送下一份数据

而基于滑动窗口协议, 主机可以将一个滑动窗口内的所有数据包一次性都发出去而不用等待目的主机的响应


目的主机还是需要对每个数据包做出响应, 当发送端接收到响应后, 其窗口会向后移动相应的位置

1.2.1 滑动窗口协议的数据丢失问题

1.2.2 高速重发机制(快重传)

只要连续收到三个重复确认(总共4个相同的确认), 发送端就会立即重传对方尚未收到的数据包

2. 流量控制

目的主机在对每一个数据包的响应中告诉发送方自己接收数据的缓存大小还有多少, 而发送方则会根据该信息对发送窗口的大小进行调节

3. 拥塞控制

发送窗口(swnd), 拥塞窗口(cwnd), 接收窗口(rwnd)
swnd = min(cwnd, rwnd)

  • cwnd > rwnd: 网络状况限制了发送窗口的最大值
  • cwnd < rwnd: 接收方的接受能力限制了发送窗口的最大值

3.1 Tahoe

3.1.1 慢开始

拥塞窗口(cwnd)一开始被设置的比较小(cwnd = 1MSS), 而随着接收方返回的响应, cwnd 指数级增加(每有一次响应, cwnd 会变为以前的 2 倍)

但是这样的指数级增加也是有限制的: 当 cwnd 超过设定的慢启动阈值(slow start thresh)时, cwnd 就只能线性增大了(即进入了拥塞避免阶段)

注: 在 TCP 通信开始时默认并不会设置 ssthresh, 而是当出现了超时重发的情况后, 才有 \(ssthresh = cwnd \div 2\). (每当出现超时重发的情况, ssthresh 都会被重新更新一次)

3.1.2 拥塞避免

3.1.3 超时重传和快重传

Tahoe 算法允许超时重传和快重传两种重传机制

当使用快重传来代替超时重传机制时, 可以想象: 目的主机没有成功接收 A 数据, 但是却接收了 A 数据后面的三个连续的数据(因为需要发送端接收到三个连续的 ACK 才会触发快重传), 说明目前网络的状况并不算太差. 在这样的情况下, 令 cwnd = 1 MSS 的惩罚力度太大了(可能有发送给目的主机的信息还在路上, 而 swnd = 1 MSS 会导致发送端在短时间内只能发送少量的信息)

3.2 Reno

3.2.1 慢开始

TCP 通信开始时或者触发了超时重传机制时, 进入慢开始
cwnd = 1 MSS, 每经过一个 RTT, cwnd 翻倍. 当 cwnd >= ssthresh 时, 进入拥塞避免阶段

3.2.2 拥塞避免

当 cwnd > ssthresh 时, 每经过一个 RTT, cwnd += 1MSS

3.2.3 快重传

当快重传被触发时, 进入快恢复阶段

3.2.4 快恢复

当快恢复被触发时, 令\(ssthresh = cwnd \div 2\), \(cwnd = ssthresh\)
在快恢复阶段: 当发送端在此阶段中接收到新的 ACK 信息(触发快重传以外的 ACK 信息), \(cwnd = cwnd + 3 MSS\), 并进入拥塞避免阶段

原文地址:http://www.cnblogs.com/suzukaze/p/TCP-feature.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性