TopDownV3-3

null第3章 运输层 Transport Layer 第3章 运输层 Transport Layer 计算机网络：自顶向下方法 (原 书 关于书的成语关于读书的排比句社区图书漂流公约怎么写关于读书的小报汉书pdf 第三版) 陈鸣译，机械工业出版社，2005年 Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. 第3章:运输层第3章:运输层我们的目的: 理解运输层服务依据的原理: 复用/分解 可靠数据传输 流量控制 拥塞控制 学习因特网中的运输层 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 ： UDP: 无连接传输 TCP: 面向连接传输 TCP 拥塞控制 第3章 要点第3章 要点3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型运输服务和协议运输服务和协议在运行不同主机上应用进程之间提供逻辑通信 运输协议运行在端系统中 发送方：将应用报文划分为段，传向网络层 接收方：将段重新装配为报文，传向应用层 应用可供使用的运输协议不止一个 因特网：TCP和UDP运输层 vs. 网络层运输层 vs. 网络层网络层: 主机间的逻辑通信 运输层: 进程间的逻辑通信 依赖、强化网络层服务家庭类比: 12个孩子向12个孩子发信 进程 = 孩子 应用报文= 信封中的信 主机 = 家庭 运输协议 = Ann和Bill 网络层协议= 邮政服务 因特网运输层协议因特网运输层协议可靠的、按序的交付 (TCP) 拥塞控制 流量控制 连接建立 不可靠、不按序交付: UDP “尽力而为”IP的不提供不必要服务的扩展 不可用的服务: 时延保证 带宽保证第3章 要点第3章 要点3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型Internet 层的复用与分解Internet 层的复用与分解复用/分解复用/分解= 进程= 套接字将接收到的段交付给正确的套接字从多个套接字收集数据，用首部封装数据(以后用于分解 )分解工作过程分解工作过程主机接收IP数据报 每个数据报有源无连接, 目的地无连接 每个数据报承载1个运输层段 每个段具有源、目的端口号 (回想: 对特定应用程序的周知端口号) 主机使用IP地址 &端口号将段定向到适当的套接字源端口 #目的端口 #32 bits应用数据 (报文)其他首部字段TCP/UDP 段格式无连接分解无连接分解生成具有端口号的套接字: DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); UDP套接字由二元组标识 : (目的地IP地址, 目的地端口号)当主机接收UDP段时: 在段中检查目的地端口号 将UDP段定向到具有该端口号的套接字 具有不同源IP地址和/或源端口号的IP数据报 定向到相同的套接字无连接分解(续)无连接分解(续)DatagramSocket serverSocket = new DatagramSocket(6428); SP提供了“返回地址”面向连接分解面向连接分解TCP套接字由四元组标识: 源IP地址 源端口号 目的IP地址 目的端口号 接收主机使用这四个值来将段定向到适当的套接字服务器主机可能支持许多并行的TCP套接字： 每个套接字由其自己的四元组标识 Web服务器对每个连接的客户机具有不同的套接字 非持久HTTP将为每个请求具有不同的套接字面向连接分解 (续)面向连接分解 (续)客户机 IP:B服务器 IP: CSP: 9157DP: 80D-IP:CS-IP: AD-IP:CS-IP: BD-IP:CS-IP: B面向连接分解: 多线程Web服务器面向连接分解: 多线程Web服务器客户机 IP:B服务器IP: CSP: 9157DP: 80P4D-IP:CS-IP: AD-IP:CS-IP: BD-IP:CS-IP: B第3章 要点第3章 要点3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型UDP: 用户数据报协议 [RFC 768]UDP: 用户数据报协议 [RFC 768]“没有不必要的,” “基本要素” 互联网传输协议 “尽力而为”服务，UDP段可能： 丢包 对应用程序交付失序 无连接: 在UDP发送方和接收方之间无握手 每个UDP段的处理独立于其他段为何要有 UDP协议? 无连接创建(它将增加时延) 简单：在发送方、接收方无连接状态 段首部小 无拥塞控制: UDP能够尽可能快地传输UDP: 其他UDP: 其他常用于流式多媒体应用 丢包容忍 速率敏感 其他UDP应用 DNS SNMP 经UDP的可靠传输 : 在应用层增加可靠性 应用程序特定的差错恢复！源端口#目的端口#32 bits应用数据 (报文)UDP 段格式长度检查和UDP段的长度，包括首部，以字节计UDP检查和UDP检查和发送方: 将段内容处理为16比特整数序列 检查和: 段内容的加法(反码和) 发送方将检查和放入UDP检查和字段 接收方: 计算接收的段的检查和 核对计算的检查和是否等于检查和字段的值: NO – 检测到差错 YES – 无差错检测到。虽然如此，还可能有差错吗？详情见后……目的: 在传输的段中检测“差错” (如比特翻转) 互联网检查和例子互联网检查和例子注意 当数字作加法时，最高位进比特位的进位需要加到结果中 例子: 两个16-bit整数相加1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1回卷 和检查和第3章 要点第3章 要点3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型可靠数据传输的原则可靠数据传输的原则在应用层、运输层、数据链路层的重要性 重要的网络主题中的最重要的10个之一! 不可靠信道的特点决定了可靠数据传输 协议 (rdt) 的复杂性可靠数据传输: 基本概念可靠数据传输: 基本概念发送侧接收侧可靠数据传输: 基本概念可靠数据传输: 基本概念我们将: 增强研发发送方，可靠数据传输协议 (rdt) 的接收方侧 仅考虑单向数据传输 但控制信息将在两个方向流动！ 使用有限状态机 (FSM)来定义发送方和接收方引起状态变迁的事件状态变迁所采取的行动状态: 当位于这个“状态时”，下个状态惟一地由下个事件决定第3章 要点第3章 要点3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型Rdt1.0: 经可靠信道的可靠传输Rdt1.0: 经可靠信道的可靠传输底层信道非常可靠 无比特差错 无分组丢失 装发送方、接收方的单独FSM: 发送方将数据发向底层信道 接收方从底层信道读取数据Wait for call from abovepacket = make_pkt(data) udt_send(packet)rdt_send(data)extract (packet,data) deliver_data(data)Wait for call from belowrdt_rcv(packet)发送方接收方第3章 要点第3章 要点3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型Rdt2.0: 具有比特差错的信道Rdt2.0: 具有比特差错的信道underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection receiver feedback: control msgs (ACK,NAK) rcvr->senderrdt2.0: FSM规格参数rdt2.0: FSM规格参数 等待来自上面的调用snkpkt = make_pkt(data, checksum) udt_send(sndpkt)extract(rcvpkt,data) deliver_data(data) udt_send(ACK)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)rdt_rcv(rcvpkt) && isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) && isNAK(rcvpkt)发送方接收方rdt_send(data)Lrdt2.0: 无差错时的操作rdt2.0: 无差错时的操作 等待来自上面的调用snkpkt = make_pkt(data, checksum) udt_send(sndpkt)extract(rcvpkt,data) deliver_data(data) udt_send(ACK)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)rdt_rcv(rcvpkt) && isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) && isNAK(rcvpkt) 等待来自下面的调用rdt_send(data)Lrdt2.0: 有差错时的情况rdt2.0: 有差错时的情况 等待来自上面的调用snkpkt = make_pkt(data, checksum) udt_send(sndpkt)extract(rcvpkt,data) deliver_data(data) udt_send(ACK)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)rdt_rcv(rcvpkt) && isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) && isNAK(rcvpkt) 等待来自下面的调用rdt_send(data)Lrdt2.0有重大的缺陷!rdt2.0有重大的缺陷!如果ACK/NAK受损，将会出现何种情况？ 发送方不知道在接收方会发生什么情况！ 不能只是重传：可能导致冗余 处理冗余: 发送方对每个分组增加序列号 如果ACK/NAK受损，发送方重传当前的分组 接收方丢弃(不再向上交付)冗余分组发送方发送一个分组，然后等待接收方响应rdt2.1: 发送方, 处理受损的ACK/NAKrdt2.1: 发送方, 处理受损的ACK/NAK等待来自上面的调用0sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt)rdt_send(data)udt_send(sndpkt)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) )sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)rdt_send(data)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) )rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) LLrdt2.1: 接收方,处理受损的ACK/NAKrdt2.1: 接收方,处理受损的ACK/NAKsndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)rdt_rcv(rcvpkt) && (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)rdt2.1: 讨论rdt2.1: 讨论发送方: 序号seq # 加入分组中 两个序号seq. #’s (0,1) 将够用. ( 为什么?) 必须检查是否收到的ACK/NAK受损 状态增加一倍 状态必须“记住”是否“当前的”分组具有0或1序号接收方: 必须检查是否接收到的分组是冗余的 状态指示是否0或1是所期待的分组序号seq # 注意: 接收方不能知道是否它的最后的ACK/NAK在发送方已经接收OK rdt2.2: 一种无NAK的协议rdt2.2: 一种无NAK的协议与rdt2.1一样的功能，仅使用ACK 代替NAK,接收方对最后正确接收的分组发送ACK 接收方必须明确地包括被确认分组的序号 在发送方冗余的ACK导致如同NAK相同的动作：重传当前分组rdt2.2: 发送方, 接收方片段rdt2.2: 发送方, 接收方片段sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt)rdt_send(data)udt_send(sndpkt)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) 发送方FSM 片段rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt))udt_send(sndpkt)接收方FSM 片段L第3章 要点第3章 要点3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型rdt3.0: 具有差错和丢包的信道rdt3.0: 具有差错和丢包的信道新假设: 下面的信道也能丢失分组(数据或ACK) 检查和、序号、重传将是有帮助的，但不充分方法: 发送方等待ACK一段“合理的”时间 如在这段时间没有收到ACK则重传 如果分组(或ACK)只是延迟(没有丢失)： 重传将是冗余的，但序号的使用已经处理了该情况 接收方必须定义被确认的分组序号 需要倒计时定时器rdt3.0发送方rdt3.0发送方sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timerrdt_send(data)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timerrdt_send(data)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timerstop_timerudt_send(sndpkt) start_timertimeoutudt_send(sndpkt) start_timertimeoutrdt_rcv(rcvpkt)Lrdt_rcv(rcvpkt)LLLrdt3.0 运行情况rdt3.0 运行情况无丢包时的运行 分组丢失发送方发送方接收方接收方rdt3.0运行情况rdt3.0运行情况ACK丢失 过早超时 发送方发送方接收方接收方rdt3.0的性能rdt3.0的性能rdt3.0能够工作，但性能不太好 例子: 1 Gbps链路, 15 ms端到端传播时延, 1KB分组: Ttransmit=8kb/pkt10**9 b/sec= 8 microsecU sender: 利用率 – 发送方用于发送时间的比率 每30 msec 1KB 分组 -> 经1 Gbps 链路有33kB/sec 吞吐量 网络协议限制了物理资源的使用!L (packet length in bits)R (transmission rate, bps)=rdt3.0: 停等协议的运行rdt3.0: 停等协议的运行传输分组的第一个比特, t = 0发送方接收方RTT 传输分组的最后一个比特, t = L / R分组第一个比特到达传输最后一个比特到达,发送ACKACK 到达，发送下一个分组, t = RTT + L / R第3章 要点第3章 要点3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型流水线协议流水线协议流水线: 发送方允许发送多个、“传输中的”,还没有应答的报文段 序号的范围必须增加 发送方和/或接收方设有缓冲流水线协议的两种形式: 回退N帧法（go-Back-N）, 选择性重传（S-R）, 流水线协议: 增加利用率流水线协议: 增加利用率传输第一个分组比特, t = 0发送者接收者RTT 传输最后一个比特, t = L / R第一个分组比特到达分组最后一个比特到达,发送 ACKACK 到达, 发送下一个分组, t = RTT + L / R第二个分组最后比特到达,发送ACK第三个分组最后比特到达,发送ACK利用率增加3倍!Go-Back-NGo-Back-N发送方: 在分组首部需要K比特序号，2k=N “窗口”最大为N, 允许N个连续的没有应答分组ACK(n): 确认所有的（包括序号n）的分组 - “累计ACK” 可能收到重复的ACKs (见接收方) 对每个传输中的分组的用同一个计时器 timeout(n):若超时，重传窗口中的分组n及所有更高序号的分组GBN: 发送方扩展的 FSMGBN: 发送方扩展的 FSMstart_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) 超时 rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data)base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timerrdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt) LGBN: 接收方扩展 FSMGBN: 接收方扩展 FSM只有ACK: 对发送正确接收的分组总是发送具有最高按序序号的ACK 可能产生冗余的ACKs 仅仅需要记住期望的序号值（expectedseqnum） 对失序的分组: 丢弃 (不缓存) -> 没有接收缓冲区! 重新确认具有按序的分组Waitudt_send(sndpkt)default rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) L等待GBN 操作GBN 操作发送方接收方选择性重传（Selective Repeat）选择性重传（Selective Repeat）GBN改善了信道效率，但仍然有不必要重传问题 接收方分别确认所有正确接收的报文段 需要缓存分组, 以便最后按序交付给给上层 发送方只需要重传没有收到ACK的分组 发送方定时器对每个没有确认的分组计时 发送窗口 N个连续的序号 也需要限制已发送但尚未应答分组的序号选择性重传: 发送方, 接收方窗口选择性重传: 发送方, 接收方窗口a. 发送方看到的序号b. 接收方看到的序号已经确认 可用，还未发送发送，还未确认不可用可接受（窗口内） 失序(已缓存)但未被确认 可接受（窗口内）期待，还未收到 不可用 窗口长度N 窗口长度N 选择性重传选择性重传上层传来数据 : 如果窗口中下一个序号可用, 发送报文段 timeout(n): 重传分组n, 重启其计时器 ACK(n) 在[sendbase,sendbase+N]: 标记分组 n 已经收到 如果n 是最小未收到应答的分组，向前滑动窗口base指针到下一个未确认序号分组n在 [rcvbase, rcvbase+N-1] 发送 ACK(n) 失序: 缓存 按序: 交付 (也交付所有缓存的按序分组),向前滑动窗口到下一个未收到报文段的序号 分组n在[rcvbase-N,rcvbase-1] ACK(n) 其他: 忽略 选择重传的操作选择重传的操作选择重传: 困难的问题选择重传: 困难的问题例子: 序号: 0, 1, 2, 3 窗口长度 = 3 接收方：在(a)和(b)两种情况下接收方没有发现差别! 在 (a)中不正确地将新的冗余的当为新的，而在(b)中不正确地将新的当作冗余的 问题: 序号长度与窗口长度有什么关系? 回答：窗口长度小于等于序号空间的一半可靠数据传输机制及用途 总结 初级经济法重点总结下载党员个人总结TXt高中句型全总结.doc高中句型全总结.doc理论力学知识点总结pdf 可靠数据传输机制及用途总结第3章 要点第3章 要点3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议TCP概述 RFCs: 793, 1122, 1323, 2018, 2581TCP概述 RFCs: 793, 1122, 1323, 2018, 2581全双工数据: 同一连接上的双向数据流 MSS: 最大报文段长度 MTU:最大传输单元 面向连接: 在进行数据交换前，初始化发送方与接收方状态，进行握手(交换控制信息), 流量控制: 发送方不能淹没接收方 拥塞控制: 抑止发送方速率来防止过分占用网络资源点到点: 一个发送方, 一个接收方 连接状态与端系统有关，不为路由器所知 可靠、有序的字节流: 没有 “报文边界” 流水线: TCP拥塞和流量控制设置滑动窗口协议 发送和接收缓冲区 TCP 报文段结构TCP 报文段结构URG: 紧急数据 (一般不用)ACK: ACK 序号 有效PSH: 立即提交数据 (一般不用)RST, SYN, FIN: 连接建立(建立和拆连)接收方允许 的字节数对数据字节计数(并非对报文段计数!)因特网检查和 (同 UDP一样)TCP序号和确认号TCP序号和确认号序号: 报文段中第1个数据字节在字节流中的位置编号 确认号: 期望从对方收到下一个字节的序号 累计应答 问题：接收方如何处理失序报文段？ 回答：TCP规范没有说明， 由实现者自行选择实现: 抛弃/缓存 主机 A主机 BSeq=42, ACK=79, data = ‘C’Seq=79, ACK=43, data = ‘C’Seq=43, ACK=80用户键入 ‘C’主机对接收 到的‘C’回 显给出确认主机对收到 的‘C’给出确认, 回显 ‘C’简单的telnet情况捎带确认TCP往返时延(RTT)的估计与超时TCP往返时延(RTT)的估计与超时问题: 如何设置TCP 超时值? 应大于RTT 但RTT是变化的 太短: 过早超时 不必要的重传 太长: 对报文段的丢失响应太慢问题: 如何估计RTT? SampleRTT: 从发送报文段到接收到ACK的测量时间 忽略重传 SampleRTT会变化,希望估计的RTT“较平滑” 平均最近的测量值,并不仅仅是当前SampleRTTTCP往返时延估计与超时 (续)TCP往返时延估计与超时 (续)EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT指数加权移动平均(Exponential weighted moving average) 过去的样本指数级衰减来产生影响 典型值:  = 0.125RTT估计的例子RTT估计的例子TCP往返时延估计与超时 (续)TCP往返时延估计与超时 (续)设置超时间隔 EstimtedRTT 加 “安全余量” EstimatedRTT大变化-> 更大的安全余量 首先估算EstimatedRTT与SampleRTT之间差值有多大 : TimeoutInterval = EstimatedRTT + 4*DevRTTDevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (典型地,  = 0.25) 然后估算超时值:第3章 要点第3章 要点3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议TCP 可靠数据传输TCP 可靠数据传输TCP在IP不可靠服务的基础上创建可靠数据传输服务 流水线发送报文段 累计确认 TCP使用单个重传计时器 重传被下列事件触发: 超时事件 重复ACK 先考虑简化的TCP发送方: 忽略重复ACK 忽略流量控制，拥塞控制TCP 发送方事件TCP 发送方事件1.从应用层接收数据: 根据序号创建报文段 序号是报文段中第一个数据字节的数据流编号 如果未启动，启动计时器 (考虑计时器用于最早的没有确认的报文段) 超时间隔: TimeOutInterval= EstimatedRTT + 4*DevRTT2.超时: 重传导致超时的报文段 重新启动计时器 3.收到确认： 如果确认了先前未被确认的报文段 更新被确认的报文段序号 如果还有未被确认的报文段，重新启动计时器TCP 发送方 (简化的)TCP 发送方 (简化的) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number y start timer event: ACK received, with ACK field value of y if (y > SendBase) { /* 累计确认到Y */ SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ 注释: SendBase-1: 上次 累计的已确认字节 例如: SendBase-1 = 71; y= 73, 因此接收方期待73+ ; y > SendBase, 因此新数据被确认TCP: 重传的情况TCP: 重传的情况主机 ASeq=100, 20 bytes dataACK=100过早超时的情况主机 BSeq=92, 8 bytes dataACK=120Seq=92, 8 bytes dataACK=120Seq=92 超时SendBase = 100SendBase = 120SendBase = 120Sendbase = 100TCP 重传情况(续)TCP 重传情况(续)主机 ASeq=92, 8 bytes dataACK=100丢包超时累计确认情况主机 BXSeq=100, 20 bytes dataACK=120时间SendBase = 120TCP ACK 产生 [RFC 1122, RFC 2581]TCP ACK 产生 [RFC 1122, RFC 2581]接收方事件 所期望序号的报文段按序到达。所有在期望序号及以前的数据都已经被确认 有期望序号的报文段按序到达。另一个按序报文段等待发送ACK 比期望序号大的失序报文段到达，检测出数据流中的间隔。 部分或者完全填充已接收到 数据间隔的报文段到达 TCP 接收方行为 延迟的ACK。对另一个按序报文段的到达最多等待500 ms。如果下一个按序报文段在这个时间间隔内没有到达，则发送一个ACK 立即发送单个累积ACK，以确认两个按序报文段 立即发送冗余ACK，指明下一个期待字节的序号（也就是间隔的低端字节序号） 倘若该报文段起始于间隔的低端，则立即发送ACK 快速重传快速重传超时间隔常常相对较长: 重传丢失报文段以前有长时延 通过冗余ACK，检测丢失的报文段 发送方经常一个接一个的发送报文段 如果报文段丢失，将会收到很多重复ACK 如果对相同数据，发送方收到3个ACK, 假定被确认的报文段以后的报文段丢失了: 快速重传: 在定时器超时之前重传快速重传算法:快速重传算法: 事件: 收到ACK, ACK 域的值为 y if (y > SendBase) { SendBase = y if (当前还有没有确认的报文段) 启动定时器 } else { 值为 y的重复确认的次数加1 if (值为 y的重复确认的计数= 3) { 重传序号位y的报文段 } 对已经确认的报文段 收到一个重复ACK快速重传第3章 要点第3章 要点3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议TCP 流量控制TCP 流量控制TCP连接的接收方有1个接收缓冲区:匹配速度服务: 发送速率需要匹配接收方应用程序的提取速率应用进程可能从接收缓冲区读数据缓慢TCP流控: 工作原理TCP流控: 工作原理(假设 TCP 接收方丢弃失序的报文段) 缓冲区的剩余空间 = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]接收方在报文段接收窗口字段中通告其接收缓冲区的剩余空间 发送方要限制未确认的数据不超过RcvWindow LastByteSent-LastByteAcked <或= RcvWindow 保证接收缓冲区不溢出第3章 要点第3章 要点3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议TCP 连接管理TCP 连接管理回想: TCP 发送方与接收方 在交换报文段前要先建连接 初始化 TCP 变量: 序号 缓冲区和流控信息 (如RcvWindow) 客户机: 连接的发起方 Socket clientSocket = new Socket("hostname","port number"); 服务器: 接受客户请求 Socket connectionSocket = welcomeSocket.accept();TCP 连接管理TCP 连接管理三次握手: 步骤 1: 客户机向服务器发送 TCP SYN报文段 指定初始序号 没有数据 步骤 2: 服务器收到SYN报文段, 用SYNACK报文段回复 服务器为该连接分配缓冲区和变量 指定服务器初始序号 步骤 3: 客户机接收到 SYNACK, 用ACK报文段回复,可能包含数据SYN, SEQ = xSYN, SEQ = y, ACK = x + 1SYN, SEQ = x+1,ACK = y + 1客户机服务器TCP 连接管理 (续)TCP 连接管理 (续)关闭连接: 客户关闭套接字: clientSocket.close(); 步骤 1: 客户机向服务器发送TCP FIN控制报文段 步骤 2: 服务器收到FIN，用ACK回答。关闭连接，发送FINTCP 连接管理 (续)TCP 连接管理 (续)步骤 3: 客户机收到FIN, 用ACK回答 进入 “超时等待” – 将对接收到的FIN进行确认 步骤 4: 服务器接收ACK，连接关闭 注意: 少许修改, 可以处理并发的FINTCP 连接管理 (续)TCP 连接管理 (续)TCP 客户 生命周期TCP 服务器 生命周期第3章 要点第3章 要点3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议拥塞控制原理拥塞控制原理拥塞: 非正式地: “太多的源发送太多太快的数据，使网络来不及处理” 不同于流量控制! 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 现: 丢包 (路由器缓冲区溢出) 长时延 (路由器缓冲区中排队) 网络中的前10大问题之一! 拥塞的原因与开销: 情况1 拥塞的原因与开销: 情况1 两个发送方, 两个接收方 一个路由器, 无限缓冲区 不重传 拥塞时时延增大 可达到最大吞吐量无限的共享式输出链路缓冲主机Alin : 原始数据主机Blout拥塞的原因与开销 : 情况2 拥塞的原因与开销 : 情况2 一个路由器，有限缓冲区 发送方重传丢失的数据分组 有限的共享式输出链路缓存主机 Alin : 原始数据主机 Bloutl‘in : 原始数据 ＋重传数据拥塞的原因与开销: 情况2 (续) 拥塞的原因与开销: 情况2 (续) 通常: (吞吐量) 仅当丢失丢包时，需要“完美的” 重传 : 迟延的分组（而不是丢失）的重传使得 比(同完美情况相比) 更大 拥塞的“代价”: 比额定的“吞吐量”做更多的工作 (重传) 不必要重传: 链路承载分组的多个拷贝拥塞的原因与开销: 情况3 拥塞的原因与开销: 情况3 四个发送者 多跳路径 超时/重传 问题: 随着 和 的 增加将发生什么情况 ?有限的共享式输出链路缓存 lin 原始数据loutl‘in : 原始数据, ＋重传数据拥塞的原因与开销: 情况3 (续) 拥塞的原因与开销: 情况3 (续) 另一个拥塞的“开销”: 当分组丢失时, 任何用于传输该分组的上游传输能力都被浪费!lout拥塞控制方法拥塞控制方法端到端的拥塞控制: 不能从网络得到明确的反馈 从端系统根据观察到的时延和丢失现象推断出拥塞 这是TCP所采用的方法网络辅助的拥塞控制: 路由器为端系统提供反馈 一个bit指示一条链路出现拥塞(SNA,DECnet,TCP/IP ECN, ATM) 指示发送方按照一定速率发送控制拥塞的两类方法: 案例 全员育人导师制案例信息技术应用案例心得信息技术教学案例综合实践活动案例我余额宝案例 研究: ATM ABR 拥塞控制案例研究: ATM ABR 拥塞控制ABR: 可用比特率: “弹性服务” 如果发送方的路径 “欠载”: 发送方应该使用可用的带宽 如果发送方的路径拥塞: 发送方被抑制到最小的保证速率RM (资源管理) 信元: 发送方发送RM 信元, 散布在数据信元中 由交换机设置 RM 信元中的特定比特(“网络辅助”) NI bit: 速率无增长 (轻度拥塞) CI bit: 拥塞指示 接收方向发送方返回RM 信元案例研究: ATM ABR拥塞控制案例研究: ATM ABR拥塞控制RM信元中的两字节 ER (明确速率)字段 拥塞的交换机会降低RM信元中的ER 值为 发送方以路径上所有交换机的最小支持速率发送 数据信元中的EFCI bit : 被拥塞的交换机设置为1 如果比RM信元先到达的数据信元的EFCI位为1，接收方将在返回的RM信元的CI位置1第3章 要点第3章 要点3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议TCP 拥塞控制TCP 拥塞控制端到端控制 (没有网络辅助) 发送方限制传输: LastByteSent-LastByteAcked  CongWin 粗略地, 拥塞窗口是动态的, 具有感知到的网络拥塞的函数发送方如何感知网络拥塞? 丢失事件 = 超时或者 3个重复ACK 发生丢失事件后，TCP发送方降低速率(拥塞窗口) 三个机制: AIMD（加增倍减算法） 慢启动 超时事件后的保守机制TCP加增倍减 AIMDTCP加增倍减 AIMD乘性减: 丢包事件后，拥塞窗口值减半加性增: 如没有检测到丢包事件，每个RTT时间拥塞窗口值增加一个MSS (最大报文段长度)长生命周期TCP连接TCP慢启动TCP慢启动在连接开始时, 拥塞窗口值 = 1 MSS 例如: MSS= 500 bytes & RTT = 200 msec 初始化速率 = 20 kbps 可获得带宽可能 >> MSS/RTT 希望尽快达到期待的速率 当连接开始，以指数快地增加速率，直到第一个丢失事件发生TCP 慢启动(续)TCP 慢启动(续)当连接开始的时候，速率呈指数式上升，直到第1次报文丢失事件发生为止: 每RTT倍增拥塞窗口值 每收到ACK，增加拥塞窗口 总结: 初始速率很低，但以指数快地增加改进改进收到3个冗余确认后: CongWin减半 窗口再线性增加 但是超时事件以后: CongWin值设置为1 MSS 窗口再指数增长 到达一个阈值 (Threshold) 后，再线性增长 3个冗余ACK指示网络还具有某些传送报文段的能力 3个冗余ACK以前的超时,则更为 “严重” 基本思想:改进 (续)改进 (续)问题: 什么时候从指数增长转变为线性增长? 回答: CongWin达到它超时以前1/2的时候.实现方法: 设置一个变的阈值－Threshold 在丢包事件发生时，阈值Threshold设置为发生丢包以前的CongWin的一半TCP 拥塞控制：小结TCP 拥塞控制：小结当CongWin < Threshold时，发送者处于慢启动阶段, CongWin指数增长 当CongWin > Threshold时，发送者处于拥塞避免阶段, CongWin线性增长 当出现3个冗余确认时, 阈值Threshold设置为CongWin/2，且CongWin设置为Threshold 当超时发生时，阈值Threshold设置为CongWin/2，并且CongWin设置为1 MSS. TCP 发送方拥塞控制TCP 发送方拥塞控制第3章 要点第3章 要点3.5 面向连接的传输: TCP 报文段结构 可靠数据传输 流量控制 连接管理 3.6 拥塞控制的原则 3.7 TCP拥塞控制 机制 TCP吞吐量 TCP公平性 时延模型3.1 运输层服务 3.2 复用与分解 3.3 无连接传输: UDP 3.4 可靠数据传输的原则 rdt1 rdt2 rdt3 流水线协议TCP 吞吐量TCP 吞吐量作为窗口长度和RTT的函数，TCP的平均吞吐量是什么？ 忽略慢启动 设当丢包发生时窗口长度是W 如果窗口为 W，吞吐量是 W/RTT 当丢包发生后，窗口降为 W/2，吞吐量为 W/2RTT. 一个连接的平均吞吐量为0 .75 W/RTTTCP 未来TCP 未来举例: 1500 字节的报文段, 100ms RTT, 要达到10 Gbps 的吞吐量 要求窗口长度 W = 83,333