TCP协议.ppt

2020 1 27 1 Chapter9TCP OverviewTCPservicesWindowbasedcontrolProtocolFlowcontrolErrorcontrolTCPtimersCongestioncontrolSegmentConnectionTCPoperationTCPpackage 要求 1 掌握TCP的可靠性机制 确认 重传 序号 2 掌握TCP的流控和提高传输效率策略 滑动窗口机制 3 掌握TCP连接的建立与关闭协议 三次握手 4 掌握TCP的报文段格式 5 掌握TCP的拥塞控制技术 6 掌握TCP避免糊涂窗口综合症的技术 7 了解紧急数据发送和强迫数据发送 2020 1 27 3 TransportLayerProtocol ResponsibilitiesTocreateaprocess to processcommunication使用两个端点地址 IP 端口号 通信Toprovideaflow controlanderror controlmechanismatthetransportlayerErrorcontrol ARQ WindowbasedcontrolAcknowledgementpacketTime outRetransmissionFlowcontrol slidingwindowprotocol Windowbasedcontrol 2020 1 27 4 TransportLayerProtocol ToprovideacongestioncontrolToprovideaconnectionmechanismfortheprocessesTCP aconnection oriented reliabletransportprotocol 2020 1 27 5 理解TCP的责任 提供process to processcommunication在IP层上建立起 可靠的 顺序的 reliable sequential 分组传输服务面向连接的通信Error control 2020 1 27 6 理解TCP的责任 源端到目的端的流量控制 flow control TopreventafastsourceofpacketsfromoverwhelmingaslowsinkAdaptivebandwidthsharinginthenetwork congestioncontrol 2020 1 27 7 Introduction 高层应用的需求 reliability传输大量的数据 要求可靠的通信服务自身的可靠性机制弱底层网络和IP网络是不可靠 无连接投递TCPProcess to processcomm samewithUDPToaddconnection orientedandreliabilityfeaturestotheservicesofIP 2020 1 27 8 Overview TransmissionControlProtocol TCPRFC793 传输控制协议 IP LANs MANs WANs ICMP IGMP ARP RARP NetworkLayer NetworkAccessLayer ApplicationLayer TCP UDP TransportLayer 2020 1 27 9 Process to processCommunication 端口 端点概念与方式与UDP完全一样连接 TCP上通信双方抽象的虚电路连接 202 115 12 6 80 Port 80 Endpoint 202 115 12 6 80 202 115 12 34 16250 Connection 202 115 12 6 80 and 202 115 12 34 16250 2020 1 27 10 ChapterTCP OverviewTCPservicesWindowbasedcontrolProtocolFlowcontrolErrorcontrolTCPtimersCongestioncontrolSegmentConnectionTCPoperationTCPpackage 2020 1 27 11 TCPServices Streamdeliveryservice 流交付服务 Full duplexservice 全双工服务 Connection orientedserviceReliableservice 2020 1 27 12 TCPServices Streamdeliveryservice 流交付服务 流 指的是流入到进程或从进程流出的字节序列 面向字节流 虽然应用程序和TCP的交互是一次一个数据块 大小可能不等 但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流 2020 1 27 13 理解 StreamDelivery 与UDP交付区别 进程把预先定义好边界的一组报文 用户数据报 发送给UDPUDP对这些报文中的每一个添加首部 传递给IP传输UDP和IP都不认为这些数据报之间有任何关系 独立处理每一个数据报 2020 1 27 14 TCPServices StreamDeliveryService Streamdeliveryservicerequires SendingprocesscandeliverdataasastreamofbytesReceivingprocesscanobtaindataasastreamofbytesstreamofbytes 进程间使用自己认为适宜的任何大小的数据片进行发送或接收 最小1字节 TCP 发送进程 接收进程 TCP Streamofbyte TCPcreatesaenvironmentinwhichthetwoprocessesseemtobeconnectedbyan tube thatcarrierstheirdataacrosstheInternet 2020 1 27 15 Sendingandreceivingbuffers TCP为什么需要buffer 原因 TCP要为进程构建 tube 可靠传输 差错控制流量控制发送进程与接收进程产生和消耗数据的速率不一致 2020 1 27 16 TCPsegments TCP是如何发送 字节流 的 按报文段 segment 传输报文段 若干字节构成IP是按分组 Package 处理的 而非字节流 1个segment就封装在1个Package字节流按照报文段传输的后果 接收方TCP收到报文段可能失序 损伤 重复 或者丢失 2020 1 27 17 TCPServices Streamdeliveryservice 流交付服务 Full duplexservice 全双工服务 Connection orientedserviceReliableservice 2020 1 27 18 TCPServices Full DuplexService 全双工 数据可以在同一时间双向流动每一个TCP都有发送缓存和接收缓存在发送时 应用程序在把数据传送给TCP缓存之后就可以去做自己的事情 而TCP在合适的时候把数据发送出去 在接受时 TCP把收到的数据放入缓存 上层的应用进程在合适的时候读取缓存中的数据 2020 1 27 19 TCPServices Full DuplexService Data ACK Piggybacking捎带 Datacanflowinbothdirectionatthesametime 2020 1 27 20 TCPServices Streamdeliveryservice 流交付服务 Full duplexservice 全双工服务 Connection orientedserviceReliableservice 2020 1 27 21 TCPServices Connection OrientedService 建立的是虚连接 virtualconnection 而非物理连接 physicalconnection 封装成IP分组的TCP报文段可能走不同的路径到达目的地接收到的TCP报文段可能 乱序 丢失 损坏 重复而TCP需要向上层按顺序交付数据 2020 1 27 22 TCPServices Streamdeliveryservice 流交付服务 Full duplexservice 全双工服务 Connection orientedserviceReliableservice 2020 1 27 23 TCPServices ReliableService ReliabilitySequential withouterror andwithoutanypartlostorduplicated如何实现可靠传输 ARQ AutomaticRepeatreQuest 自动重传请求基本思路 接收方 mustcontinuouslyreturnacknowledgments ACK forsuccessfullyreceiveddata发送方 每一个发送的数据都需要接收方的确认 ACK 发送每一个数据都需要缓存 并启动定时器 超时重传 可靠传输的工作原理 IP层只能提供尽最大努力的交付 TCP必须采用适当的措施才能保证通信的可靠性 理想的传输条件有两个特点 1 传输信道不产生差错 2 不管发送方以多快的速度发送数据 接收方总是能够及时接受并进行处理 a 无差错情况 A 发送M1 确认M1 B 发送M2 发送M3 确认M2 确认M3 A 发送M1 B 超时重传M1 发送M2 确认M1 丢弃有差错的报文 b 超时重传 t t t t 请注意 在发送完一个分组后 必须暂时保留已发送的分组的副本 分组和确认分组都必须进行编号 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些 确认丢失和确认迟到 A 发送M1 B 超时重传M1 发送M2 丢弃重复的M1重传确认M1 a 确认丢失 确认M1 A 发送M1 B 超时重传M1 发送M2 丢弃重复的M1重传确认M1 b 确认迟到 确认M1 收下迟到的确认但什么也不做 t t t t 可靠通信的实现 使用上述的确认和重传机制 我们就可以在不可靠的传输网络上实现可靠的通信 这种可靠传输协议常称为自动重传请求ARQ AutomaticRepeatreQuest ARQ表明重传的请求是自动进行的 流水线传输 发送方可连续发送多个分组 不必每发完一个分组就停顿下来等待对方的确认 由于信道上一直有数据不间断地传送 这种传输方式可获得很高的信道利用率 B 分组 t t A ACK 连续ARQ协议 1 2 3 4 5 6 7 8 9 10 11 12 a 发送方维持发送窗口 发送窗口是5 发送窗口 发送窗口 位于发送窗口内的5个分组都可以连续发送出去 而不需要等待对方确认 优点 提高的信道的利用率 连续ARQ协议 连续ARQ协议规定 发送方每收到一个确认 就把发送窗口向前滑动一个分组的位置 对于接受方来说 一般都采用累积确认的方式 累积确认 累积确认 即接收方不必对收到的分组逐个发送确认 而是对按序到达的最后一个分组发送确认 这样就表示 到这个分组为止的所有分组都已正确收到了 累积确认有的优点是 容易实现 即使确认丢失也不必重传 缺点是 不能向发送方反映出接收方已经正确收到的所有分组的信息 发送方发送了前5个分组 中间的第3个分组丢失了 4和5都正确到达了 这时接收方只能对前两个分组发出确认 如果下一个时刻分组3正确到达了 这时就可以一次发出确认信息ACK 6 TCP可靠通信的具体实现 TCP连接的每一端都必须设有两个窗口 一个发送窗口和一个接收窗口 TCP的可靠传输机制用字节的序号进行控制 TCP所有的确认都是基于序号而不是基于报文段 TCP两端的窗口经常处于动态变化之中 TCP连接的往返时间RTT也不是固定不变的 需要使用特定的算法估算较为合理的重传时间 提供可靠性1 防丢失 带重传的肯定确认技术 接收方收到数据后向源站发确认 ACK 设置定时器 源站在限定时间内未收到ACK 则重发 接收确认 防止重复和乱序 引入带重传的肯定确认技术后出现的问题 造成报文段的重复 原因 超时没有收到确认的报文 确认丢失或者确认信息超时到达 为了解决报文的重传问题 方法 TCP给每一个报文段都指定一个唯一的序号并要求接收方记住报文段的序号以检测重复 这种方法同时也解决了报文段乱序的问题 在建立TCP连接时 通信双方会协商初始序号ISN 这是第一个报文段的序号 之后的报文段序号的编号方法 第n 1个报文段的序号 第n个报文段的序号 第n个报文段的长度 TCP确认机制的特点 TCP的确认方法具有以下特点 TCP的确认指明的是期望接收的下一个报文段的序号 而不是已经收到的报文段的序号累计确认捎带确认接收方通常并不设置专门的报文段反馈确认信息 而是把对上一个报文段的确认信息放到自己发给发送方的数据报中捎带回去 超时重传定时器的设置 由于TCP的下层是一个互联网环境 IP数据报所选择的路由变化很大 因而运输层的往返时间的变化也会很大 那么如何设定超时重传的定时器呢 大点好还是小点好 超时定时器的设置对TCP的性能的影响很大 设置的偏小 会进行不必要的重传 设置的偏大 会影响通信效率 设置成固定的值 不适应网络环境的变化 最好的方法 根据网络的性能动态调整定时时限 性能比较好的时候 报文段和确认传输得都比较快 超时时间间隔应该设置的短一点 相反 超时时间间隔应该设置的长一点 如何衡量网络性能的好坏 反向思考 报文段的传输速度比较快的话 从报文段发出到收到确认的时间间隔也会比较短 往返时间 可以判断出网络性能比较好 定义从报文段发出到收到确认的时间间隔 称为RTT RoundTripTime 有了RTT就可以动态调整超时定时器的设置 自适应重传算法 自适应重传算法 监视每个连接的性能 由此推算出合适的定时时限 当连接的性能变化时 随时修改定时时限 根据RTT的变化动态的调整定时时限 重传定时时限的计算方法 早期的方法TCP对每个报文段都记录下发送时间和确认到达的时间 由此计算出所经历的时间并作为往返时间样本 毎得到新的样本 TCP就修改这个连接的平均往返时间 TCP软件把估算的RTT存储起来作为一个加权平均值 再使用新的往返样本来修改这个平均值 改进的方法考虑 差值 主要是为了适应RTT变化比较大的情况 在实现协议时既考虑往返时延 也估计偏差 Karn算法和定时器补偿涉及超时重传时间的选择问题 加权平均往返时间 TCP保留了RTT的一个加权平均往返时间RTTS 这又称为平滑的往返时间 第一次测量到RTT样本时 RTTS值就取为所测量到的RTT样本值 以后每测量到一个新的RTT样本 就按下式重新计算一次RTTS 新的RTTS 1 旧的RTTS 新的RTT样本 式中 0 1 若 很接近于零 表示RTT值更新较慢 若选择 接近于1 则表示RTT值更新较快 RFC2988推荐的 值为1 8 即0 125 超时重传时间RTO RetransmissionTime Out RTO应略大于上面得出的加权平均往返时间RTTS RFC2988建议使用下式计算RTO RTO RTTS 4 RTTDRTTD是RTT的偏差的加权平均值 RFC2988建议这样计算RTTD 第一次测量时 RTTD值取为测量到的RTT样本值的一半 在以后的测量中 则使用下式计算加权平均的RTTD 新的RTTD 1 旧的RTTD RTTS 新的RTT样本 是个小于1的系数 其推荐值是1 4 即0 25 计算时限 RT0 RTT 早期取2 后改为4 缺陷 在RTT变化较大的场合 说明网络某处处于拥塞状态 但上述方法对此反映不敏感 从而造成不必要的重传 进一步加重网络负担 2 改进的方法R RTT的估计值M 本次测量的RTT值Diff 差值Diff M RR R DiffDev 平均偏差的估计值Dev Dev Diff Dev 2 改进的方法RT0 定时时限RT0 R Dev 在0 1之间 通常取 1 23 1 22 23 往返时间的测量相当复杂 从理论上讲 计算RTT时 只用收到确认的时间减去发送报文的时间 但TCP采用的是累积确认 并且是丢失重传 这就会导致确认的二义性 TCP生成一个报文段 封装到IP数据包中发送出去了 但当定时器到时后也没有收到确认 于是重传刚才的报文 由于两个数据包含了同样的信息 发送方收到确认后无法分辨出是针对哪个报文段的确认 往返时间RTT TCP报文段1没有收到确认 重传 即报文段2 后 收到了确认报文段ACK 如何判定此确认报文段是对原来的报文段1的确认 还是对重传的报文段2的确认 发送一个TCP报文段 超时重传TCP报文段 收到ACK 时间 1 2 往返时间RTT 是对哪一个报文段的确认 如果是对原先的那次传输的确认 会使RTT无限增长下去 如果是对最近的传输的确认 会使RTT值变得更小 最终将稳定为一个恒定的值 解决方法Karn算法 Karn算法 在计算平均往返时间RTT时 只要报文段发生超时和重传了 就不采用其往返时间样本 这样得出的加权平均平均往返时间RTTS和超时重传时间RTO就较准确 新的问题 超时重传时间无法得到更新 报文段每重传一次 就把RTO增大一些 新的RTO 旧的RTO 系数 的典型值是2 当不再发生报文段的重传时 才根据报文段的往返时延更新平均往返时延RTT和超时重传时间RTO的数值 实践证明 这种策略较为合理 修正的Karn算法 2020 1 27 55 Chapter9TCP OverviewTCPservicesWindowbasedcontrolProtocolFlowcontrolErrorcontrolTCPtimersCongestioncontrolSegmentConnectionTCPoperationTCPpackage 2020 1 27 56 WindowbasedcontrolProtocol 基本协议技术 序号 Sequencenumber 确认 Acknowledgment 超时重传机制窗口滑动 sliding 扩展 expanding 缩回 shrinking 关闭 closing 2020 1 27 57 NumberingBytes 给字节编号 TCP是面向连接的按字节流进行数据传输的 在一个TCP连接中传送的字节流中的每一个字节都是按序进行编号的 Tonumberalldatabytestransmittedinaconnection 字节号 而不是给每个报文段分配编号某个TCP连接上的某个报文段的序号 sequencenumber 报文段中第一个数据字节的字节号 2020 1 27 58 NumberingBytes 给字节编号 整个要传送的字节流的起始序号必须在连接建立时设置 首部中的序号字段值指的是本报文段所发送的数据的第一个字节的序号 Numberingisindependentineachdirection 例如 一个报文段的序号字段值是101 而携带的数据共有200字节表明 本报文段的数据的第一个字节的序号是101 最后一个字节的序号是300 显然 下一个报文段的数据序号应从301开始 也就是说下一个报文段的序号字段值应为301 2020 1 27 60 TCP NumberingBytes 给字节编号 Thenumberingstartsrandomly NOTfrom0选取范围 0 232 1 TCP Sending Sendingbuffer Receivingbuffer Receiving Datestream Segment Data 2020 1 27 61 练习 ImagineaTCPconnectionistransferringafileof6000bytes Thefirstbyteisnumbered10010 Whatarethesequencenumbersforeachsegmentifdataissentinfivesegmentswiththefirstfoursegmentscarrying1 000bytesandthelastsegmentcarrying2 000bytes Thefollowingshowsthesequencenumberforeachsegment Segment1 10 010 10 010to11 009 Segment2 11 010 11 010to12 009 Segment3 12 010 12 010to13 009 Segment4 13 010 13 010to14 009 Segment5 14 010 14 010to16 009 13010 14010 10010 11010 12010 1 IP欺骗 核心 ISN估计 H冒充B攻击AH冒充B向A发送SYN报文A向B回应SYN ACK报文B发现错误 向A发RSTA发现错误 假设B关机 攻击步骤 1 H冒充B向A发送SYN报文 ISNh 2 A向B回应SYN ACK ACKISNh 1 SYNISNA 白发 3 H假冒B回应ACK到A ACKISNa 1 问题 ISNa 难点 解决 掌握ISN增长的规律 2020 1 27 63 WindowbasedcontrolProtocol 基本协议技术 序号 Sequencenumber 确认 Acknowledgment 超时重传机制窗口滑动 sliding 扩展 expanding 缩回 shrinking 关闭 closing 2020 1 27 64 Acknowledgment 确认 ACK Acknowledgmentnumber 确认号 对已经收到的字节表示确认表示的是期望收到对方下一个报文段的第一个数据字节的序号 PositiveACK 肯定确认 ThenumberofthenextdatabyteapartyexpectstoreceiveCumulativeACK 累计确认 例如TCP报文段中的确认号是 1234 意味着 已经收到了字节号 1234的以前的所有字节希望收到了下一个TCP报文段的序号 1234 2020 1 27 65 Discussion 例1 asegmentwithSeq X DataLen LThentheSeq ofthenextsegment 例2 asegmentwithAck XThismeansallbytesfromthebeginninguptoX 1hasbeenreceivedFeatures 确认的特点 报文的顺序关系数据流的位置 更便于流的复原需较大的序号空间 32bit 232 4Gbyte 序号不连续 n1 n2 n3 X L 2020 1 27 66 WindowbasedcontrolProtocol 基本协议技术 序号 Sequencenumber 确认 Acknowledgment 超时重传机制窗口滑动 sliding 扩展 expanding 缩回 shrinking 关闭 closing 2020 1 27 67 超时重传机制 发送方每发送一个报文段 Segment 就启动一个定时器 如果在定时内 没有收到对该报文段的确认 ACK 重传该报文段发送方必须缓存已经发送但未收到确认的报文段发送方在定时内没有收到确认 ACK 发送方判断 该报文段损坏或者该报文段丢失或者ACK丢失 2020 1 27 68 WindowbasedcontrolProtocol 基本协议技术 序号 Sequencenumber 确认 Acknowledgment 超时重传机制窗口滑动 sliding 扩展 expanding 缩回 shrinking 关闭 closing 2020 1 27 69 滑动窗口 发送窗口与接收窗口 窗口 缓存中一组字节号 或者报文序号 的集合落在发送窗口 sendingwindow 字节号两部分 发方已发送但还未收到确认的字节号 或者报文号 集合发方可以立即发送的字节号 或者报文号 集合发送窗口大小Ws 一次性连续发送的最大字节数落在接收窗口 receivingwindow 的序号 收方希望接收的字节号 或者报文号 集合接收窗口大小Wr 允许一次性接收的最大字节数 字节号不在发送窗口的数据不能发送 2020 1 27 70 TCP中的滑动窗口 TCP允许随时改变滑动窗口的大小 滑动 sliding 扩展 expanding 缩回 shrinking 关闭 closing 既实现高效的可靠传输 又提供了流量控制高效可靠传输 发方在等待确认之前 可以发送多个分组流量控制 端到端 接收方控制发送窗口的大小 控制发送速率拥塞控制 路由器超载 拥塞 TCP减小发送窗口 控制发送速率 2020 1 27 71 Chapter9TCP OverviewTCPservicesWindowbasedcontrolProtocolFlowcontrolErrorcontrolTCPtimersCongestioncontrolSegmentConnectionTCPoperationTCPpackage 2020 1 27 72 FlowControl 流量控制 TCP采用的流控方法 控制发送窗口的大小发送方根据接收方反馈的信息控制发送窗口的操作关键 发送窗口大小 WS 接收方宣告窗口 advertisementwindow 的大小 rwnd rwnd 接收方允许发送方连续发送的数据量 也就等于接收方空闲缓存的大小 2020 1 27 73 SenderBuffer SenderWindow 2020 1 27 74 ReceiverWindow ReceiverbufferTostoreTCPsegmentsinorder 缓存乱序到达的报文段 向上层提供顺序数据 接收方宣告窗口的大小 rwnd Wr 已占用的缓存字节数 Consider Howtoprocessanout of orderTCPsegment acceptornot RFC1122 section4 2 2 20and4 2 2 21 2020 1 27 75 ReceiverWindow TostoreTCPsegmentsinorder 6 7 8 Receiver 9 10 11 12 13 14 15 16 6 7 8 2020 1 27 76 0 1 2 3 4 5 6 7 8 SlidingtheSenderWindow 发送窗口的滑动 Thesourcedoesnothavetosendafullsenderwindow sworthofdataThesenderwindowcanslideoverthesenderbufferasanacknowledgmentisreceivedfromthereceiverThedestinationcansendanacknowledgmentatanytime sender receiver 0 9 10 11 12 13 14 15 16 Ws 5 1 2 3 4 5 6 7 8 ACK1 ACK4 2020 1 27 77 Expandingthesenderwindow 发送窗口的扩展 Thereceivingprocessconsumesdatafasterthanitreceives rwnd 将rwnd通知发送方 反馈 发送方扩展Ws Ws rwnd 0 1 2 3 4 5 6 7 8 Sender 0 9 10 11 12 13 14 15 16 1 2 3 4 5 6 7 8 Ws 4 4 5 6 7 8 Receiver 2 3 4 5 Wr 10 rwnd 4 rwnd 8 ACK6 rwnd 8 0 1 Ws 8 2020 1 27 78 Shrinkingthesenderwindow 发送窗口的缩小 Thereceivingprocessconsumesdataslowerthanitreceives rwnd 将rwnd通知发送方 反馈 发送方收缩为Ws rwnd 0 1 2 3 4 5 6 7 8 Sender 0 9 10 11 12 13 14 15 16 1 2 3 4 5 6 7 8 Ws 4 4 5 6 7 8 Receiver 2 3 4 5 Wr 10 rwnd 4 rwnd 3 ACK7 rwnd 3 0 1 Ws 3 6 2020 1 27 79 Closingthesenderwindow 发送窗口的关闭 Thereceiverbufferistotallyfull rwnd 0 将rwnd通知发送方 反馈 发送方关闭窗口 窗口左边 右边 停止数据的发送 Q Whentostartsending 2020 1 27 80 WindowManagement 4000 1000 3000 Buffer Sender Receiver 2020 1 27 81 Discussion SenderSenderbufferSenderwindowHowmuchtosend Whentosend ReceiverReceiverbufferReceiverwindowHowmuchtoreceive Whentoack Problem网络的缓冲 窗口的流控机制不会立即起作用网络中间的拥塞 确认丢失 滑动 窗口通告丢失 窗口大小 2020 1 27 82 TCP的糊涂窗口综合症 SillyWindowSyndrome SWS 糊涂窗口综合症 RFC813什么是SWS 接收方的小窗口通告造成发送方发送一系列小的报文段 严重浪费网络带宽 SymptomTosenddatainverysmallsegments whichreducestheefficiencyoftheoperationExample 1byteofdata 40bytesofTCPandIPheaders 2020 1 27 83 接收方SWS解决方案 接收方SWS 原因 接收进程数据消耗缓慢现象 发端TCP逐个字节地发送TCP报文段解决思路 1 避免小窗口通告 在零窗口通告之后 只在可用缓冲区显著增加 缓冲区空间的一半或一个MSS 后才发送新的窗口通告 2 推迟确认 最多500ms 窗口大小不到避免SWS策略所需的尺寸时 推迟发送确认 优缺点 2020 1 27 84 发送方SWS解决方案 发送方SWS 原因 发送进程数据产生缓慢现象 发端TCP逐个字节地发送TCP报文段解决思路 发送方延迟发送 收集应用程序的发送数据 聚集合理的数据量关键问题 延迟时间如何确定延迟长 通信延迟增加延迟短 产生短的TCP报文段延迟策略 Nagle salgorithm发送方TCP发送第一块从应用进程收到的数据发送方等待ACK 并且累积数据 发送方发送条件 数据累积到可以封装成最大长度的报文段或者收到上一报文段的ACK Nagle算法 自适应推迟传输以便将数据组块 1 连接建立后 最初的数据会立即发送 2 当缓冲区中数据不足一个报文段 则推迟发送 等到一个确认来到 确认触发 时 发送缓冲区中的小报文段 问题 可能出现死锁 确认丢失 说明 Nagle算法的两个优点 自适应 确认到达得越快 数据也就发送得越快 计算简单 不需要定时器 可关闭Nagle算法 应用程序接口一般提供选项TCP NODELAY来关闭Nagle算法 2020 1 27 86 Chapter9TCP OverviewTCPservicesWindowbasedcontrolProtocolFlowcontrolErrorcontrolTCPtimersCongestioncontrolSegmentConnectionTCPoperationTCPpackage 2020 1 27 87 ErrorControl 目标 接收应用程序从TCP收到的数据流是按序的 无差错的 无丢失 无重复的差错控制分两步 DetectingandcorrectingLostsegmentsOut of ordersegmentsDuplicatedsegmentsTCP中实现差错控制的三种工具Checksum 用来检查受损报文Acknowledgment positiveandcumulativeTime out retransmission 2020 1 27 88 确认 ACK报文段不消耗序号 也不被确认什么时候产生ACK报文段捎带确认 发送数据报文段时 减少ACK报文段推迟确认 接收端无数据发送 按序收到数据 且前一个报文段已确认 减少ACK报文段立即确认 接收端无数据发送 按序收到数据 且前一个报文段未确认 避免不必要的重传当收到失序报文段当丢失的报文段到达重复报文段到达 2020 1 27 89 重传 什么时候重传 重传定时器超时发送端连续收到3个重复的ACK重传定时器超时发送方就认为 对应报文段受损或者丢失收到3个重复的ACK发送方就认为 某个报文丢失 或收方收到大量乱序报文快速重传 2020 1 27 90 CorruptedSegment 报文段受损 Sender Receiver Time Time Segment3corrupted 2020 1 27 91 LostSegment Sender Receiver Time Time 2020 1 27 92 LostAcknowledgment Sender Receiver Time Time Acknowledgmentlost 2020 1 27 93 DuplicateSegment 重复报文段 CauseWhentheacknowledgmentdoesnotarrivebeforethetime out关键 重传定时器的长短如何确定 重传定时器 RTT RoundTripTime 报文往返时间 一种简单解决方案 thedestinationTCP 接收方TCP 检测出重复报文段SequencenumberSimplydiscardthepacket 6 7 8 Receiver 124 524 924 假设 TCP报文段定长为400Byte 2020 1 27 94 Out of OrderSegment 失序报文段 CauseTCPusestheservicesofIP anunreliable connectionlessnetworklayerservice解决方案 thedestinationTCP 接收方TCP 检测出失序的报文段 sequencenumberCorrectingTCPdoesNOTacknowledgeanout of ordersegmentuntilitreceivesallofthesegmentsthatprecedeit 6 7 8 Receiver 9 10 11 12 13 14 15 16 6 7 8 2020 1 27 95 ChapterTCP OverviewTCPservicesWindowbasedcontrolProtocolFlowcontrolErrorcontrolTCPtimersCongestioncontrolSegmentConnectionTCPoperationTCPpackage 2020 1 27 96 TCPTimer Retransmissiontimer 重传定时器 ThewaitingtimeforanackofasegmentTocontrolalostordiscardedsegmentPersistencetimer 坚持定时器 Todealwiththezerowindow sizeadvertisementThewaitingtimeforanackwithanon zerowindowsizeKeepalivetimer 保活定时器 TopreventalongidleconnectionbetweentwoTCPThewaitingtimeforsomedatafromaclientTime waitedtimer 时间等待定时器 Tobeusedduringconnectiontermination 2020 1 27 97 RetransmissionTimer 功能 处理重传超时发送方可以重传报文段 某些报文段在传输过程中可能丢失或者被丢弃 lostordiscarded ThewaitingtimeforanackofasegmentUsage 如何使用重传定时器 WhenTCPsendsasegment itcreatesaretransmissiontimerforthatsegmentIfanackisreceivedforthatsegmentbeforetime out thetimerisdestroyedOtherwisethesegmentisretransmittedandthetimerisreset关键问题 重传超时时间 RTO 如何确定 2020 1 27 98 重传超时时间 RTT Round TripTime 报文段传输的往返时延从发送一个报文到收到这个报文的时间重传超时时间取值一般是基于RTT的例如 一种简单算法 Retransmissiontimer 2xRTTInternet的上的RTT不同TCP连接具有各自不同的路径长度 时延差异大同一个TCP连接 发送方从发送报文段到收到确认的时间随网络的拥塞状况而改变分组经过路由器 路由器产生的时延取决于通信量结论 分组的传输时延无法预先确定 重传超时时间无法实现预测 是动态变化的 2020 1 27 99 Internet上的100个Packet的往返传输时间图 2020 1 27 100 PersistenceTimer 坚持定时器 功能 Todealwiththelossofnon zerowindowsizeadvertisement当发送方窗口关闭后 直到收方发送一个确认来宣告非零窗口值如果该确认丢失 双方将陷入死锁UsageWhenthesendingTCPreceivesanackwithawindowsizeofzero itstartsapersistencetimerIfanackwithanon zerowindowsizeisnotreceivedfromthereceiverbeforetime out thensendaprobesegment 发送探测报文段 探测报文段有序号 但不需要确认ThevalueofthetimerissettothevalueoftheretransmissiontimerThesendercontinuessendingtheprobesegmentanddoublingandresettingthevalueofthetimeruntilthevaluereachesathreshold usually60s TCP中 不对ACK确认 2020 1 27 101 KeepaliveTimer 保活定时器 功能 TopreventalongidleconnectionbetweentwoTCPUsageEachtimetheserverhearsfromaclient itresetsthistimerThetime outisusually2hoursIftheserverdoesnothearfromtheclientafter2hours itsendsaprobesegmentIfthereisnoresponseafter10probe eachofwhichis75sapart thentheserverassumesthattheclientisdownandterminatestheconnection 2020 1 27 102 Time waitedTimer UsageWhenTCPclosesaconnection itdoesnotconsidertheconnectionreallyclosed Theconnectionisheldinlimbo 过渡期 foratime waitedperiodThevalueforthistimerisusually2timestheexpectedlifetimeofasegment MaximumSegmentLifetime MSL 2minutes anengineeringchoice 2020 1 27 103 Chapter9TCP OverviewTCPservicesWindowbasedcontrolProtocolFlowcontrolErrorcontrolTCPtimersCongestioncontrolSegmentConnectionTCPoperationTCPpackage 2020 1 27 104 CongestionControl 拥塞控制 Congestion 网络中 路由器接收过多的分组 超过其处理能力时 发生拥塞 分组被丢弃Somepacketscouldbedroppedbytherouter noackissentfromthedestination TCP发送端重传定时器会超时 thesenderretransmitsthelostpacketTocreatemorecongestionandmoredropping moreretransmissionandmorecongestionFinally thewholesystemcollapses结论 拥塞引起的重传 会使情况更糟 2020 1 27 105 CongestionControl 端点 主机 上的TCP是无法准确知道网络因何原因或者在何处发生拥塞TCP本身没有提供拥塞控制拥塞对于端点而言 表现为 TCP传输延迟增加 导致超时重传TCP应该在网络出现拥塞时 必须减慢发送速率 或停止传输 拥塞控制问题 TCP如何发现网络的拥塞呢 Inflowcontrol 发送窗口由接收方直接控制Senderwindow Receiverwindow网络中拥塞 发送窗口还要取决于网络的拥塞情况TCPassumes 关键假设 Thecauseofalostsegmentisduetocongestioninthenetwork 2020 1 27 106 CongestionWindow 拥塞窗口 Senderwindow Min rwnd cwnd rwnd receiver sadvertisedwindow 接收方通告窗口 areceiver sidelimit 流量控制cwnd congestionwindow 拥塞窗口 asender sidelimit 反映了网络的拥塞状况 拥塞控制 2020 1 27 107 TCP中的几个窗口 接收方通告窗口 rwnd 接收方通过反馈告诉发送方的允许传输的数据量 单位 可以是字节 也可以是报文段 拥塞窗口 cwnd 发送方为了进行拥塞控制而限制自己传输的数据量实际发送窗口的大小