《传输控制协议》PPT课件.ppt

第7章传输控制协议TCP 要求 1 掌握TCP的可靠性机制 确认 重传 序号 2 掌握TCP的流控和提高传输效率策略 滑动窗口机制 3 掌握TCP连接的建立与关闭协议 三次握手 4 掌握TCP的报文段格式 5 掌握TCP的拥塞控制技术 6 掌握TCP避免糊涂窗口综合症的技术 7 了解紧急数据发送和强迫数据发送 问题 IP协议的特点是什么 无连接不保证可靠性尽最大努力传输应用程序如果要得到高可靠性服务 有哪些途径 在IP层上增加一层功能模块由应用程序自身完成可靠性功能UDP能否满足应用程序的需求 7 1概述 1 可靠性 防丢失 确认与重传 防重复 报文段序号 2 传输效率 流量控制 滑动窗口机制 3 拥塞控制 加速递减与慢启动技术 4 建立连接 三次握手协议 5 关闭连接 改进的三次握手协议 要实现可靠的数据流传输服务 必须解决哪几个问题 面向数据流 虚电路连接 有缓冲的传输 无结构的数据流 全双工连接 可靠传输服务有哪些特点 7 2TCP的特点 7 3TCP连接1 建立连接 三次握手 功能 1 同意连接协商 做好传输数据的准备 2 协商各自报文段ISN 初始序列号 不能为 1 3 协商MSS 只有SYN报文段能协商MSS 说明 SYN报文段占用初始序号 发送数据的第一字节序号为ISN 1 接收ACK 关于ISN和MSS ISN不能取1 为什么 ISN的设置方法是有一定规律的 MSS为什么要选择MSS 如果连接的两端在同一个物理网络中 TCP协议软件能计算出合适的MSS 如果连接的两端不在同一个物理网络中 则把路径上最小的MTU除去首部后的数据大小作为MSS 选择合适的MSS非常困难 太小 网络利用率低 太大 会降低网络性能 2 关闭连接 改进的三次握手 说明 FIN报文段占用一个序号 单纯的ACK报文段不占用序号 TCP提供了半关闭能力 连接的一端在结束它的发送后还能接收来自另一端数据 有些编程接口提供close来关闭TCP连接 提供shutdown加特殊参数来实现半关闭 接收ACK 接收ACK 3 TCP连接异常关闭异常关闭 出现异常情况使得应用程序或网络软件中断连接 连接复位 RST 发起端发RST报文段 双方立即停止传输 并退出连接 4 端口 端点和连接 1 端口 21 23 25 53 79 80 88 139 161 2 端点一对整数 hostIP port 标识通信一方的一个应用程序 3 连接一对端点 表示通信双方应用程序间的一条虚电路 主动打开 去请求 被动打开 等待来 4 说明 一台机器上的一个TCP端口可被多个连接共享 TCP UDP可用相同的端口号 但不会冲突 一个DOS命令 NetstatActiveConnectionsProtoLocalAddressForeignAddressStateTCPkoukou 1056202 196 56 240 httpsESTABLISHEDNetstat o 列出与每个端口相关的进程Netstat r 显示路由表 7 4提供可靠性1 防丢失 带重传的肯定确认技术 接收方收到数据后向源站发确认 ACK 设置定时器 源站在限定时间内未收到ACK 则重发 接收确认 两个问题 如何识别和处理重复的数据 序号抛弃定时器时限设置多长 2 防重复和乱序 报文段重复产生的原因 假 丢失 确认丢失或确认延迟 超时 到达 致使发送方重传造成的 解决方法 为每一分组赋予一个序号 用以检测重复 序号同时保证了分组间的正确顺序 确认时通过确认号指明哪些分组已经收到 累计确认 序号与确认号 序号 seq seq1 ISNseqn 1 seqn 第n个报文段的长度 以字节计 确认号 ACK 确认号 期望接收的下一个报文段的序号 可提高效率的捎带累计确认技术 什么是累计确认 只确认前面连续收到的报文什么是捎带确认 把对上一个报文的确认信息放到发给发送方的数据报文中捎带回去 3 RTT与重传定时器 对于超时重传的情况 如何设置重传定时器的时限 时限设置的过大过小会出现什么问题 网络性能不断变化 定时时限应动态调整两个概念 RTT 往返时间 报文段发出到收到确认信息间的时间段 自适应重传算法 监视每个连接的性能 由此推算出合适的定时时限 当连接的性能变化时 随时修改定时时限 重传定时时限的计算方法 重传定时时限的计算方法 早期的方法 改进的方法 Karn算法和定时器补偿 1 早期的方法R RTT的估计值 之前RTT的加权平均值 M 本次测量的RTT值RTO 定时时限修改估计值 R R 1 M 0 1 通常取 0 9 计算时限 RTO R 早期取2 后改为4 缺陷 在RTT变化较大的场合 说明网络某处处于拥塞状态 但上述方法对此反映不敏感 从而造成不必要的重传 进一步加重网络负担 2 改进的方法R RTT的估计值M 本次测量的RTT值RTO 定时时限Diff 本次测量结果与上次RTT估计值的偏差Dev 平均偏差的估计值Diff M RR R DiffDev Dev Diff Dev Dev的估计值 RTO R Dev 在0 1之间 通常取 1 8 1 4 8 3 Karn算法和定时器补偿确认二义性 对于重传的报文段 收到确认后是对哪一次传输的确认无法确定 结果 RTT样本值无法使用 Karn算法 思想 当超时重传发生时 不再更新RTT估计值 忽略重传样本 定时器补偿 超时重传发生 加大定时时限 RTO RTO 通常取2 即指数避退 对重传分组的后续分组 定时时限不变 直到获得一个新的有效样本时再更改时限值 7 5传输效率和流量控制 滑动窗口机制停 等机制 等前一个报文的确认到来后才能发送下一个报文 效率太低 1 一般的滑动窗口机制思想 允许发送方不必等确认到来就可继续发送下面的分组 但规定一个上限 若多个分组的确认未到时 则暂停发送 TCP的滑动窗口按字节操作而不是按报文段或分组操作 TCP窗口大小为字节数 最大为65535字节 发送方为每个连接设置3个指针 定义了滑动窗口三要素 1 左边界指针 区分已发送字节流中已确认部分与未确认部分 2 右边界指针 序列中未得到确认情况下可以发送的最高字节的序号 3 已发与未发边界指针 窗口中已发送和未发送字节的界限 2 TCP的滑动窗口技术 12 100101102 410041014102 分组流 WindowSize 4000 右边界指针 左边界指针 已发与未发边界指针 通信双方都设有发送和接收缓冲区 相当于发送窗口和接收窗口 默认大小各系统有差异 如4096 8192 16384等 发送缓冲区大小为默认窗口大小 TCP连接两端各有两个窗口 发送窗口和接收窗口 3 TCP端到端流量控制 窗口大小可变技术时机 目的主机缓冲区变小而不能接收源主机更多的数据时 就要进行流量控制 TCP技术 可随时改变窗口大小 目的主机在确认时 向源主机告知目的主机接收缓冲区的大小 说明 接收方使用0窗口通告来停止所有的传输 此时 除了紧急数据和窗口试探报文外 不发其它数据 101 200201 320321 399 如何防止死锁 当接收方缓存有了空间时 如何让对方继续发送数据给自己 如果窗口变为非0时 则接收方会向发送方发非0窗口的通告 但是 若该确认丢失 则会造成死锁 如何防止死锁 坚持定时器 发送方接收到0窗口通告时进行设置 用于周期性地向对方询问窗口大小 窗口试探报文 在坚持定时器时间到 但仍没收到接收方非0窗口的通知时发送 防止非0窗口通告丢失造成死锁 发送端要发送900字节长的数据 划分为9个100字节长的报文段 而发送窗口确定为500字节 发送端只要收到了对方的确认 发送窗口就可前移 发送TCP要维护一个指针 每发送一个报文段 指针就向前移动一个报文段的距离 举例 发送端已发送了400字节的数据 但只收到对前200字节数据的确认 同时窗口大小不变 现在发送端还可发送300字节 发送端收到了对方对前400字节数据的确认 但对方通知发送端必须把窗口减小到400字节 现在发送端最多还可发送400字节的数据 主机A 主机B 允许A再发送300字节 A还能发送200字节 A还能发送200字节 A还能发送300字节 A还能发送100字节 A超时重发 但不能发送序号500以后的数据 允许A再发送200字节 序号501至700 A还能发送100字节 序号601至700 不允许A再发送 到序号600的数据都已收到 利用可变窗口大小进行流量控制双方确定的窗口值是400 1 什么是SWS 接收方的小窗口通告造成发送方发送一系列小的报文段 严重浪费网络带宽 2 启发式的避免策略 接收方 1 避免小窗口通告 在零窗口通告之后 只在可用缓冲区显著增加 缓冲区空间的一半或一个MSS 后才发送新的窗口通告 2 推迟确认 最多500ms 窗口大小不到避免SWS策略所需的尺寸时 不确认 为了使发送方正确估计RTT 至少每隔一个报文段要进行正常的确认 4 糊涂窗口综合症SWS 发送方 避免小报文段发送Nagle算法 自适应推迟传输以便将数据组块 1 连接建立后 最初的数据会立即发送 2 当缓冲区中数据不足一个报文段 则推迟发送 等到一个确认来到 确认触发 时 发送缓冲区中的小报文段 3 说明 Nagle算法的两个优点 自适应 确认到达得越快 数据也就发送得越快 计算简单 不需要定时器 可关闭Nagle算法 应用程序接口一般提供选项TCP NODELAY来关闭Nagle算法 拥塞 交换节点 如路由器 数据报负载过重的现象 回顾 IP层的拥塞控制技术 ICMP源站抑制报文 是一种被动机制 TCP拥塞控制的必要性 在TCP层 拥塞造成时延增加 这又会造成超时重传 控制不当会进一步加重拥塞 7 6TCP拥塞控制技术 TCP控制拥塞的两个变量 每一个TCP连接需要有以下两个状态变量 接收端窗口 receiverwindow 又称为通知窗口 advertisedwindow 接收端根据其目前的接收缓存大小向发送方所许诺的最新的窗口值来自接收端的流量控制拥塞窗口 congestionwindow 发送端根据自己估计的网络拥塞程度而设置的窗口值它对一个发送方能向网络中发送流量的速率进行限制来自发送端的流量控制 发送窗口的上限值 发送窗口的上限值取决于接收端窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个 即应按以下公式确定 发送窗口的上限值 min rwnd cwnd 慢启动门限 慢启动门限 ssthresh 用于确定是采用慢启动还是拥塞避免算法来控制数据传送 当cwndssthresh时 使用拥塞避免算法 当cwnd ssthresh时 既可以使用慢启动算法 也可以使用拥塞避免算法 拥塞窗口cwnd每个连接都有一个拥塞窗口 该窗口大小以字节为单位 但是增加和减少以MSS为单位 初始大小 1个MSS 慢启动算法思想 新连接开始或拥塞解除后 都仅以一个最大报文段长度作为拥塞窗口cwnd的初始值 此后 每收到一个确认 cwnd增加一个MSS 拥塞避免算法当cwnd增加到ssthresh的一半时 进入 拥塞避免 状态 思想 窗口中的所有报文段都被确认后 才将cnwd增加一个MSS 加速递减技术指数级递减 出现超时重传时 将ssthresh值设为当前拥塞窗口的1 2 拥塞窗口恢复为1个MSS大小 指数退避 对保留在发送窗口中的报文段 将重传时限加倍 TCP拥塞控制技术 慢开始和拥塞避免算法的实现举例 1 当TCP连接进行初始化时 将拥塞窗口置为1 图中的窗口单位不使用字节而使用报文段 慢开始门限的初始值设置为16个报文段 即ssthresh 16 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 拥塞避免 更新后的ssthresh 12 发送端的发送窗口不能超过拥塞窗口和接收端窗口中的最小值 我们假定接收端窗口足够大 因此现在发送窗口的数值等于拥塞窗口的数值 慢开始和拥塞避免算法的实现举例 2 在执行慢开始算法时 拥塞窗口的初始值为1 发送第一个报文段M0 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 拥塞避免 更新后的ssthresh 12 慢开始和拥塞避免算法的实现举例 3 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 拥塞避免 更新后的ssthresh 12 发送端收到ACK1 确认M0 期望收到M1 后 将拥塞窗口从1增大到2 于是发送端可以接着发送M1和M2两个报文段 慢开始和拥塞避免算法的实现举例 4 接收端发回ACK2和ACK3 发送端每收到一个对新报文段的确认ACK 就把发送端的拥塞窗口加1 现在发送端的拥塞窗口从2增大到4 并可发送M4 M6共4个报文段 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 拥塞避免 更新后的ssthresh 12 慢开始和拥塞避免算法的实现举例 5 发送端每收到一个对新报文段的确认ACK 就把发送端的拥塞窗口加1 因此拥塞窗口随着传输次数按指数规律增长 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 拥塞避免 更新后的ssthresh 12 慢开始和拥塞避免算法的实现举例 6 当拥塞窗口增长到慢开始门限值ssthresh时 即当CongWin 16时 就改为执行拥塞避免算法 拥塞窗口按线性规律增长 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 更新后的ssthresh 12 慢开始和拥塞避免算法的实现举例 7 假定拥塞窗口的数值增长到24时 网络出现超时 表明网络拥塞了 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 拥塞避免 更新后的ssthresh 12 慢开始和拥塞避免算法的实现举例 8 更新后的ssthresh值变为12 即发送窗口数值24的一半 拥塞窗口再重新设置为1 并执行慢开始算法 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 拥塞避免 更新后的ssthresh 12 慢开始和拥塞避免算法的实现举例 9 当CongWin 12时改为执行拥塞避免算法 拥塞窗口按线性规律增长 每经过一个往返时延就增加一个MSS的大小 2 4 6 8 10 12 14 16 18 20 22 0 0 4 8 12 16 20 24 传输次数 拥塞窗口 ssthresh 16 慢开始 慢开始 拥塞避免 拥塞避免 更新后的ssthresh 12 7 7TCP报文 1 报文段和序号 报文段是TCP软件间传输数据的基本单元 每个报文段都有一个序号 1 选取初始序号 2 第n 1段的序号 第n段序号 第n段数据区字节数 相当于每个字节都有一个序号 首部长度 4字节计数 最大15 TCP首部长度20 60序号 当前报文的序号确认号 希望接收的对方下一报文段序号 已成功接收到的数据字节序 1 说明 1 序号和确认序号在一起使得确认可捎带进行 2 TCP采用累计确认策略 3 TCP采用经受时延的确认 时延一般为200ms 缺点 发送方无法收到所有成功传输的报文段的确认信息 对往返时间样本的精确测量带来影响 窗口 通告对等端缓冲区大小 使发送方修改窗口的大小 以便进行收发双方的流量控制 问题 初始窗口大小如何确定 默认值 在建立连接时互相通告 校验和计算 加入伪首部 必须 UDP可选 码元比特 标识报文段的目的与内容 选项 第一版TCP 定义了选项表结束 无操作 MSS 最大报文段长度 MSS过小 效率低MSS过大 考虑分片 丢失可能性增大MSS接近路径MTU时为最佳 由于路径改变 很难 说明 只有SYN报文能协商MSS 默认536字节 选项 第二版TCP rfc1323 增加了窗口扩大因子和时间戳 功能 将TCP窗口定义从16bit扩大到32bit 移位数 R 窗口大小 65535 2R说明 只能出现在一个SYN报文段中 主动建立连接的一方发送这个选项 被动方收到该选项后才能发此选项 每个方向上的扩大因子可以不同 时间戳选项 时间戳 发送方填时间戳回显应答 接收方确认复制发回功能 更好地估算RTT防止回绕的序号问题 如果接收方发送了一个对两个报文段的确认 那么应该复制哪一个报文的时间戳字段呢 解决 TCP为每个连接保留一个时间戳数值 1 TCP设置两个变量 1 tsrecent 每个连接的时间戳数值 2 lastack 最后发送的ACK的确认序号 2 当包含lastack的报文段到达时 其中的时间戳被保存至tsrecent 3 无论何时发送确认 tsrecent将被写入时间戳回显应答字段 确认序号则被保存到lastack 分析 1 若ACK被接收方延迟 则回显的是第一个报文段 例 若包含1 1024和1025 2048字节的两个报文段到达 则 lastack为1025 回显时间戳为1 1024的时戳 原因 发送方在进行重传超时时间的计算时 必须将延迟的ACK也考虑在内 2 若收到的报文失序 则丢失的报文段到达时 它的时间戳被回显 例 收到报文的顺序为1 1024 2049 4072 1025 2048 则处理情况如下 1 确认号为1025 回显时间戳为1 1024的时戳 2 确认号为1025 回显时间戳为1 1024的时戳 3 确认号为4073 回显时间戳为1025 2048的时戳 结果 造成RTT估计过高 比过低好 7 8紧急数据和强迫数据发送 1 紧急数据发送和带外数据带外数据 源站不能按字节流的顺序而需要立即发给接收方并及时处理的数据 普通数据流中的紧急数据 接收方收到URG报文段 立即把紧急数据交应用程序处理 然后再处理普通数据流 通常 紧急数据从数据区最前端开始 但有些系统只传送1字节紧急数据 可位于数据区任意地方 2 强迫数据发送应用背景 通常 TCP为提高网络利用率 在缓冲区中积累够一个最大报文段容量的数据后才发送 在交互环境或实时性要求高的场合 每条命令 甚至每个字符 希望及时传送 TCP提供推 PUSH 操作 以强迫发送当前数据流中的数据而不必等待缓冲区满 应用方式 发送方将PSH置 1 以通知接收方尽快把该报文段数据交应用程序 1 重传定时器 设定丢失重传的时间间隔 2 坚持定时器在接收方发出 0 窗口通告后 发送方为了防止死锁发生 用一个坚持定时器周期性地向接收方发送窗口探察报文 防止 0 窗口通告后窗口恢复通告丢失后造成死锁 3 保活定时器 间隔 2小时 在服务器端检测半开放的连接 如果一个给定的连接在两个小时内没有任何动作 则服务器会向客户端发送一个探察报文段 根据响应情况进行处理 7 9TCP的定时器 客户机可能的四种状态 客户机正常工作 并从服务器可达 2小时后保活定时器复位 若期间有通信 通信后2小时再复位 客户机崩溃 服务器连续发10个探察报文 回应超时时间间隔设置为75秒 若始终没有回应 则终止连接 客户机崩溃后重新启动 服务器收到RST回应报文 终止连接 客户机正常工作 但从服务器不可达 同状态2 1 IP欺骗 核心 ISN估计 7 11TCP攻击实例 H冒充B攻击AH冒充B向A发送SYN报文A向B回应SYN ACK报文B发现错误 向A发RSTA发现错误 假设A死 攻击步骤 1 H冒充B向A发送SYN报文 ISNh 2 A向B回应SYN ACK ACKISNh 1 SYNISNA 白发 3 H假冒B回应ACK到A ACKISNa 1 问题 ISNa 难点 解决 掌握ISN增长的规律 RFC793 ISN是32比特的计数器 每4ms 1ISN 系统初始化时不能设置为 1 4 4BSD和多数Berkeley实现版中ISN初始化为 1 每0 5秒增加64000 每隔9 5小时归 0 对应每8ms 1 每建立一个连接增加64000问题 Windows如何实现 2 TCP端口扫描TCP实现的基本规则 若SYN或者FIN数据包到达一个关闭的端口 TCP丢弃数据包同时发送一个RST数据包 全连接扫描扫描主机用三次握手与目的机指定端口建立正规连接 实现方式 connect 函数调用 若端口打开则连接成功 否则失败 优点 实现简单缺点 很容易被发现 目前通常被禁止 半开扫描 SYN扫描 1 发SYN报文到目的主机的目标端口 2 若目标返回SYN ACK 则端口开放 否则回RST 3 若端口开放 则发送RST给目标 从而终止连接半开的含义 全连接尚未建立缺点 不能用socket编程实现 优点 不容易被发现 Fin扫描 1 发送FIN报文到目标主机的目标端口 2 若返回RST 则端口关闭 否则端口打开缺点 不能用socket编程实现 优点 不容易被发现 1 TCP服务器的设计并发特性 可处理多个呼入连接请求 每到达一个请求 调用一个进程处理 Berkeley的服务器TCP实现规则 设置长度固定的连接队列 其中的连接已被TCP接受 但没有被应用接受 TCP接受连接是将其写入该队列 应用层接受该连接是将其从队列中移出 应用层指明队列的最大长度 连接请求 SYN 到达时 若队列中还有空间 则接收这个连接并确认 若无空间 不理会该请求 也不作回应 3 SYNFlood DoS DDoS 2 SYNFlood的原理发送大量伪造的TCP请求 填满呼入请求队列 则服务器无法响应正常的连接请求 并且CPU和内存资源最终被耗尽