输成及应用层.pptVIP

* TCP 连接管理 (续) Step 3: 客户端 收到 FIN, 用 ACK进行应答. 随着对接收到的FIN发送ACK-同时进入 “timed wait（计时等待）” Step 4: 服务器, 接收 ACK. 连接关闭. 注意: 稍加修改,即可管理同时发生的多个FINs. client FIN server ACK ACK FIN closing closing closed timed wait closed * TCP 连接管理 (续) TCP 客户端实例的生命周期 TCP 服务进程的生命周期 * 拥塞控制原理 拥塞: 非正式的说法: “过多信源以过快的速率发送了过多的数据、导致网络穷于应付” 不同于流量控制! 后果: 丢失数据分组 (路由器缓存溢出) 长时间的延迟 (在路由器的缓存中排队) 在网络发展的技术中的a top-10 problem! * 缘由/代价-拥塞问题:场景1 两个发送端, 两个接收端 一个路由器, 有限缓存 无重传机制 发生拥塞时的延迟 可达到的最大吞吐量 * 缘由/代价-拥塞问题: 场景 2 四个发送端 多步跳路径 超时/重传 l in Q: 当 和 增加时发生了什么? l in * 缘由/代价-拥塞问题 : 场景 2 拥塞的“代价”: 当分组被丢弃时, 所有“上游”信道为该分组所作的工作统统被浪费了! * 拥塞问题的解决方案 端对端的拥塞控制: 没有来自网络的反馈信息 对拥塞问题的了解来自于对数据丢失和延迟的推断 由 TCP来解决 网络辅助的拥塞控制: 路由器向端系统提供反馈 用一比特位说明 (SNA, DECNet, TCP/IP ECN, ATM) 显式告知发送方所应采用的数据速率 两大类拥塞控制的办法: * 案例研究: ATM ABR 拥塞控制 ABR: available bit rate（可用数据速率）: “弹性服务” 如果发送方的路径“欠负载” 发送端应该把带宽用足 如果发送端路径拥塞: 发送端将其数据速率约束到最小承诺速率 RM (resource management) cells（资源管理信元）: 由发送端发送, 掺和在数据信元一起 在 RM 信元中的数据位由交换机设定 (“网络辅助”) NI bit: 不得增加发送速率 (轻微拥塞) CI bit: 拥塞指示 RM信元由接收端返回给发送端, 所有数据位保持原样 * 案例研究: ATM ABR 拥塞控制 在RM信元中有2字节的 ER (explicit rate) 字段 处于拥塞的交换机可降低信元中的ER 值 发送端的发送速率可以在路径上得到最低程度的支持 数据信元的EFCI 位: 在拥塞的交换机中被设成 1 如果在RM信元之前的数据信元的EFCI置1, 发送端将在返回的 RM的RM信元中将CI置1 * TCP 拥塞控制 端到端的控制 (无需网络协助) 传输速率限制由建立在数据段之上的拥塞窗口尺寸Congwin决定: w=数据段数量, 每个具有 MSS字节,在一个 RTT周期内发送: 吞吐量 = w * MSS RTT Bytes/sec Congwin * TCP 拥塞控制: 两个 “阶段” slow start（慢启动） congestion avoidance（拥塞避免） 重要变量: Congwin threshold: 定义两个慢启动之间，拥塞控制阶段的门限值 “刺探” 可用带宽: 理想情况: 全速传输 (Congwin 越大越好) 没有数据丢失 增加 Congwin 直到出现数据丢失 (拥塞) 数据丢失: 减小 Congwin, 然后重新开始进行刺探(增加Congwin) * TCP Slowstart（慢启动） 窗口尺寸按指数递增 (每隔 RTT) (不算太慢!) 丢失事件: 超时(Tahoe TCP) 和/或三次重复 ACKs (Reno TCP) initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin threshold) Slowstart 算法 Host A one segment RTT Host B time two segments four segments * TCP 拥塞避免 /* slowstart is over */ /* Congwin threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin