目录
可靠数据传输原理
停等传输下的情况
1. 经过完全可靠信道的可靠数据传输
2. 经具有比特差错信道的可靠数据传输
3. 经具有比特差错的丢包信道的可靠数据传输
流水线传输
1. 回退 N 步 (Go-Back-N,GBN) 协议
2. 选择重传(Selective Repeat,SR)
TCP 解析
TCP 报文段结构
往返时间(Round-Trip Time,RTT)
TCP 可靠数据传输
流量控制(区别于拥塞控制)
TCP 连接管理:
三次握手(客户发起)
四次挥手(双方都可发起)
SYN 洪泛攻击的应对
TCP 拥塞控制
TCP 吞吐量
AIMD 算法公平吗
可靠数据传输原理
如何在一条不可靠的信道上得到可靠的传输?
不可靠的原因: 可能出现比特差错, 丢包
停等传输下的情况
从简单到难的情况一步步分析:
1. 经过完全可靠信道的可靠数据传输
这时只需要一发一收, 值得注意的是: 发送端的发送动作是由上层 (应用层) 触发, 接收端的接收动作是由下层 (网络层) 触发
2. 经具有比特差错信道的可靠数据传输
既然可能出现比特差错, 那首先要能检测出比特差错, 这可以用校验和的方法
当接收端检测到比特差错, 应该向发送端反馈出错了(NAK), 发送端再重新发送直到没有错误(即使无错误也要反馈接受无误(ACK)), 注意反馈时也要用到校验和
这里又出现了问题, 没有办法保证发送端反馈的信息无差错传输(反馈信息也可能出现错误, 表现为校验和错误, 不过错误背后的信息即可能是 NAK 也可能是 ACK), 因此发送端为了保证万无一失, 只要收到的反馈有错误, 就重新发送该分组
然然然而, 数据运输是许多个分组, 一个接着一个, 然后想到如果是 ACK 分组受损, 发送端重传分组, 会导致接收端错把重传分组当成新分组, 所以必须区分一前一后两个分组, 这可以通过在分组前增加 0/1 来解决(0/1 对应一前一后)
3. 经具有比特差错的丢包信道的可靠数据传输
先考虑丢包的后果, 丢包会导致接收端无回应, 因此发送端可以选定一个时长, 当发送分组在经过此时长后就判定发生丢包, 随后重传分组, 具体操作是设定一个定时器
流水线传输
上面讨论的传输都是停等传输, 即发送端收到一个确定, 发送一个分组, 要想提高效率, 可以允许发送端发送多个分组而无需等待确认, 一回合发送多个分组后必须要做的工作有: 增加序号范围, 缓存多个分组, 此外对于如何处理丢失, 损坏和超时, 有两种方法:
1. 回退 N 步 (Go-Back-N,GBN) 协议
发送端: 维护一个发送窗口,[Send Base,SendBase+N-1], 窗口已满时拒绝上层调用, 累计确认 ACK(序号 n), 定时器
接收端: 按序接受, 累计确认, 丢弃乱序包并反馈
丢弃一个正确接受的分组的缺点是最后对该分组的重传也许会丢失或出错, 因此需要更多的重传
2. 选择重传(Selective Repeat,SR)
发送端: 每个分组一个单独一个定时器, 采用单个确认
接收端: 维护一个接收窗口,[rcv_base,rcv_base+N-1], 用来缓存失序的分组
收到序号在小于现在 一个窗口大小范围内 的分组, 必须产生一个 ACK
发送端和接收端的窗口并不总是一致, 最大错位一个窗口, 所以序号范围有限时, 为了避免对一个序号的含义混淆(重传 / 新分组), 窗口长度必须小于或等于序号空间大小的一半
TCP 解析
特点: 面向连接的(connection-oriented), 全双工服务, 点对点的
TCP 报文段结构
首部一般 20 字节: 源端口号 (16bits), 目的端口号(16bits), 检验和字段(16bits), 序号(32bits), 确认号(32bits), 接收窗口(16bits), 首部长度(4bits, 以 32bits 的字为单位), 选项(可变长), 标志(ACK 确认,(RST,SYN,FIN) 连接建立与拆除,(CWR,ECE)拥塞报告, PSH(表明应立即将数据交给上层),URG(紧急报文)), 紧急数据指针(16bits, 配合 URG 标志使用)
序号和确认号: 序号对数据流中的字节编号, 确认号表示下一次接收时期望的序号
往返时间(Round-Trip Time,RTT)
往返时间的估计: 某个时刻的值 SampleRTT, 其均值为 EstimateRTT
计算公式: EstimateRTT=(1-α)EstimateRTT+αSampleRTT,α的推荐值为 0.125
(指数加权移动平均)
偏差的估计: DevRTT=(1-β)DevRTT+β|SampleRTT-EstimateRTT|
设置和管理重传时间间隔: 重传超时间隔 TimeoutInterval=EstimateRTT+4*DevRTT, 初始值为 1s
TCP 可靠数据传输
这里指出上节可靠数据传输技术的缺点: 定时器的管理需要相当大的开销
拥塞控制的简单方法: 超时间隔加倍, 初始 0.75s
快速重传: 3 个冗余 ACK--->重传
累计确认, 缓存失序分组
流量控制(区别于拥塞控制)
为了消除发送方发送太快, 使接收方缓存溢出的可能性
方法: 维护一个接收窗口变量, 表明接收方还有多少可用的缓存空间
TCP 连接管理:
三次握手(客户发起)
1. 客户主机随机生成序号, SYN 标志置为 1, 发送连接请求
2. 服务器随机生成序号, SYN 标志置为 1, 确认号置为客户序号 + 1, 允许连接
3. 客户回复序号 + 1,SYN 置为 0, 确认号为服务器序号 + 1, 连接建立
四次挥手(双方都可发起)
1. 一方将 FIN 标志置为 1, 请求关闭连接, 这一方进入 FIN_WAIT_1 状态
2. 另一方回复 ACK, 进入 CLOSE_WAIT,(发起方收到 ACK, 进入 FIN_WAIT_2)
3. 并接着回复 FIN=1, 进入 LAST_ACK
4. 初始方收到 FIN, 回复 ACK, 进入 TIME_WAIT, 定时 (30s/1min/2min) 关闭,(另一方收到 ACK, 进入 CLOSED)
SYN 洪泛攻击的应对
服务器以请求连接方的 IP 和 Port 为参数使用一个私密的散列函数计算出一个值, 使其作为服务器初始序号, 并发送 SYNACK 给请求方, 这时并不建立半开连接
如果用户回复 ACK, 且 ACK-1=f(IP,Port), 那么说明用户合法, 允许建立连接
如果回复的 ACK 错误, 说明此用户并没有较早的 SYN 请求, 是非法的
如果没有回复, 也不会产生危害, 因为服务器并没有给它分配资源
TCP 拥塞控制
加性增, 乘性减(Additive-Increase,Multiplicative-Decrease,AIMD)
TCP 吞吐量
一条连接的平均吞吐量 = 0.75W/RTT,W 为丢包发生时的窗口长度
经高带宽路径的平均吞吐量 = 1.22MSS/(RTT * 根号 L),L 为丢包率
AIMD 算法公平吗
公平, 因为拥塞发生时, 原本占带宽大的减少较多的窗口长度, 原本占带宽少的减少较少的窗口长度, 拥塞避免状态又是以同样速度增加窗口长度, 数次拥塞发生后, 各连接的窗口长度接近相等, 带宽占用趋于平均
来源: https://www.cnblogs.com/wangxinwen/p/10802318.html