协议分析 第3章-1.ppt_第1页
协议分析 第3章-1.ppt_第2页
协议分析 第3章-1.ppt_第3页
协议分析 第3章-1.ppt_第4页
协议分析 第3章-1.ppt_第5页
已阅读5页,还剩131页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

计算机网络协议分析与测试 第三章 1TCP协议 第三章 1主要内容 传输层概述进程间通信TCP段格式TCP连接的建立和拆除TCP流量控制TCP拥塞控制TCP差错控制TCP状态转换图 传输层概述 传输层在TCP IP协议中非常重要 网络层用数据报统一了MAC层的帧 用IP地址统一了MAC地址 但对服务没有统一 通信子网主要有运营商建立 维护并对外提供服务 用户无法控制通信子网 不同的通信子网在服务和服务质量QOS方面存在较大差异 用户只有通过传输层对通信子网的服务进行加强 屏蔽其差异性 向上层提供一个标准的 完善的服务界面 传输层概述 传输层的目的 弥补和加强通信子网服务弥补 针对服务类型而言 传输层提供端到端进程间的通信 而通信子网网络层提供的是点到点主机的通信 加强 针对QOS而言 主要是提高服务的可靠性 传输层概述 传输层的高可靠性的代价 较大的开销传输层提供多种不同类型的服务 用户根据需要进行选择 TCP 面向连接的传输控制协议 适用于可靠性较差的底层网络 比如 广域网 UDP 无连接的用户数据报协议 适用于可靠性较高的底层网络 比如 局域网 传输层概述 传输层以下各层只提供相邻机器的点对点传输 而传输层提供了端到端的数据传输 端到端 不仅仅是源主机到目的主机的端到端通信 而且指源进程到目的进程的端到端通信 第一节进程间通信 3 1进程间通信 由于在一台计算机中同时存在多个进程 要进行进程间的通信 首先要解决进程的标识问题 TCP和UDP采用协议端口来标识某一主机上的通信进程 必须给出全局惟一的信宿端的进程标识符 主机可以用IP地址进行标识 IP地址是全局惟一的 再给主机上的进程赋予一个本地惟一的标识符 端口号 二者加起来 便形成了进程的全局惟一标识符 端口 传输层服务访问点TSAP TransportServiceAccessPoint 从内部实现看 端口是一种抽象的软件结构 数据结构和I O缓冲区 从通信对方看 端口是通信进程的标识 应用进程通过系统调用与端口建立关联后 传输层传给该端口的数据都会被相应的应用进程所接收 从本地应用进程看 端口是进程访问传输服务的入口点 每个端口拥有一个端口号 portnumber 端口号是16比特的标识符 因此 端口号的取值范围是从0到65535 端口分配有两种基本的方式 全局端口分配和本地端口分配 端口分配方式 全局端口分配 本地端口分配 全局端口分配 集中式控制 权威管理机构根据用户需要统一进行分配 并将结果对外公开 特点 特定应用程序对应的端口是众所周知的 方便对进程的寻址 不足 需求无限增长 全局分配不能适应 本地端口分配 进程需要访问传输服务时 向本地操作系统提出动态申请 系统返回一个本地唯一的端口号 进程通过系统调用将自己和相应端口号关联起来 特点 灵活方便不足 其他主机难以得知分配结果 TCP和UDP都是提供进程通信能力的传输层协议 各有一套端口号 都是从0到65535 同一个端口在TCP和UDP中可能对应于不同类型的应用进程 也可能对应于相同类型的应用进程 为了区别TCP和UDP的进程 除了给出主机IP地址和端口号之外 还要指明协议 不同协议的端口之间不会互相干扰 没有任何联系 因特网中要全局惟一地标识一个进程必须采用一个三元组 协议 主机地址 端口号 网络通信是两个进程之间的通信 两个通信的进程构成一个关联 这个关联应该包含两个三元组 由于通信双方采用的协议必须是相同的 可用一个五元组描述两个进程的关联 协议 本地主机地址 本地端口号 远地主机地址 远地端口号 因特网通信进程间的相互作用模式 客户 服务器模型 客户 服务器模型相互作用的过程是 客户向服务器发出服务请求 服务器完成客户所要求的操作 然后给出响应 服务器一般先于客户端启动 为了让客户能够找到服务器 服务器必须使用一个客户熟知的地址 客户可以根据此地址向服务器提出服务请求 熟知 wellknown 地址的含义 协议是双方约定的协议 主机IP地址是固定且公开的 端口号是大家所熟知的 每一个标准的服务器都拥有一个熟知的端口号 不同主机上相同服务器的端口号是相同的 e g21 20 23 80 25 110 客户进程一般采用临时端口号 ephemeralhumber 而不采用熟知的端口号 临时端口是使用时向操作系统申请 由操作系统分配 使用完后再交由操作系统管理的端口 因此 不管有多少应用程序 只要同一时间同一主机上的应用进程数量不超过可分配的临时端口数量 就能保证系统的正常运行 熟知端口所占端口号不多 以全局方式进行分配 TCP和UDP规定 小于1024的端口号用作熟知端口 又称为保留端口 从1024到65535编号的端口为临时端口 临时端口又称为自由端口 临时端口占全部端口的绝大部分 以本地方式进行分配 当进程要与远地进程通信时 首先申请一个临时端口 然后根据全局分配的熟知端口号与远地服务器建立联系传输数据 注册端口 registeredports 从1024到49151 它们松散地绑定于一些服务 也就是说有许多服务绑定于这些端口 这些端口同样用于许多其它目的 例如 许多系统处理动态端口从1024左右开始 动态和 或私有端口 dynamicand orprivateports 从49152到65535 理论上 不应为服务分配这些端口 实际上 机器通常从1024起分配动态端口 但也有例外 sun的rpc端口从32768开始 TCP IP结合了两种端口分配方式 既保证了灵活性 又方便了建立通信进程间的联系 Socket套接字 系统提供的进程通信编程界面 支持C S模型 Socket地址提供进程通信的端点 一个完整的关联 五元组 可以描述一个Socket连接 TCP是面向流的协议 发送方以字节流发送数据 接收方以字节流接受数据 数据在建立的连接之上按顺序发送 并且按顺序到达信宿机 因为IP层以数据分组的形式传输数据 所以TCP要将数据分为分组 TCP所采用的分组称为TCP段 TCP段不定长 被封装在IP数据报中传输 IP数据报不能保证数据的按序到达 还可能造成数据的丢失或毁坏 这些问题经过TCP协议的处理后 对上层提供的是可靠的无差错的服务 TCP为应用进程提供可靠的 端到端的 面向连接的字节流通信的协议 由RFC793正式定义 TCP特点 1 提供面向连接的服务 但不提供广播或多播服务 2 提供可靠的服务 使用确认机制来检查数据是否安全 完整地到达 3 面向字节流 4 提供全双工通信 TCP流交付服务在UDP中 应用程序把预先定义好边界的报文发送给UDP进行交付 UDP对这些报文的每一个添加自己的首部 传递给IP协议传输 在TCP中 则允许进程以字节流的形式传递数据 依靠缓存来实现 TCP面向流的概念 发送TCP报文段 发送方 接收方 把字节写入发送缓存 从接收缓存读取字节 应用进程 应用进程 18 17 16 15 14 H 加上TCP首部构成TCP报文段 TCP TCP 字节流 字节流 H 表示TCP报文段的首部 x 表示序号为x的数据字节 TCP连接 报文段TCP把若干个字节构成一个分组 叫做报文段 注意 IP层作为TCP服务提供者 发送数据以分组为单位 而非数据流 第二节TCP段格式 3 2TCP段格式 TCP将应用层的数据分块并封装成TCP段进行发送 TCP段 段首部 数据段首部 20到60字节 定长部分 变长部分定长部分长度 20字节变长部分 选项 填充 长度 0到40字节之间 TCP首部 20字节的固定首部 目的端口 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN 32位 SYN RST PSH ACK URG 位08162431 填充 TCP数据部分 TCP首部 TCP报文段 IP数据部分 IP首部 发送在前 首部长度 TCP首部 20字节的固定首部 DestinationPort HLEN Checksum Options Lengthvariable SourcePort SequenceNumber UrgentPointer Windows Reserved FIN 32位 SYN RST PSH ACK URG 位08162431 Packing TCP数据部分 TCP首部 TCP报文段 IP数据部分 IP首部 发送在前 AcknowledgmentNumber TCP首部 20字节固定首部 目的端口 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 源端口和目的端口字段 各占2字节 端口是传输层与应用层的服务接口 传输层的复用和分用功能都要通过端口才能实现 首部长度 TCP首部 20字节固定首部 目的端口 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 序号字段 占4字节 TCP连接中传送的数据流中的每一个字节都编上一个序号 序号字段的值则指的是本报文段所发送的数据的第一个字节的序号 首部长度 TCP首部 20字节固定首部 目的端口 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 填充 确认号字段 占4字节 是期望收到对方的下一个报文段的数据的第一个字节的序号 该序号之前的数据已被正确接收 PiggyBack技术 在发送的数据段中捎带对对方数据的确认 大大减少传输的报文数 首部长度 编号系统1 字节号TCP把连接中发送的所有数据字节都编上号 每一个方向的编号都是独立的 1 接收应用层数据 存入缓存 2 产生一个随机数作为第一个字节的编号 如 随机数为1057 数据总共有6000字节 则编号从1057 7056 2 序号当字节编上号以后 就给每一个报文段指派一个序号 序号是在这个报文字段中的第一个字节数据的编号 3 确认号TCP通信是全双工的 连接建立后 每一方都以不同的开始字节号对字节编号 序号表示报文段携带的第一个字节数据的编号 确认号定义了这一方期望接收的下一个字节的编号 把正确收到的最后一个字节的编号 1作为确认号 例如 一个TCP连接要传送6000字节的文件 第一个字节的编号是10001 若数据用5个报文段来发送 前4个报文段各携带1000字节的数据 最后一个报文段携带2000字节的数据 问每个报文段的序号 例如 一个TCP连接要传送6000字节的文件 第一个字节的编号是10001 若数据用5个报文段来发送 前4个报文段各携带1000字节的数据 最后一个报文段携带2000字节的数据 问每个报文段的序号 报文内字节编号范围报文序号10001 110001000111001 120001100112001 130001200113001 140001300114001 1600014001 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 填充 首部长度 占4位 指出TCP首部共有多少个4字节 32bit 的首部长度 首部长度在20 60字节之间 所以 该字段值在5 15之间 填充和选项不能超过10个单位常度 40字节 TCP首部 20字节固定首部 目的端口 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 填充 保留字段 占6位 保留为今后使用 但目前应置为0 首部长度 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 紧急URG 当URG 1时 表明紧急指针字段有效 它告诉系统此报文段中有紧急数据 应尽快传送 相当于高优先级的数据 而不是按原次序发送 紧急指针指出本报文段中紧急数据的最后1个字节的序号 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 确认ACK 和确认号字段配合使用 只有当ACK 1时确认号字段才有效 当ACK 0时 确认号无效 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 推送PSH PuSH 发送方将立即发送缓冲区中的数据 而不等待后续数据构成一个更大的段 接收TCP收到PSH 1的报文段 就尽快地将缓冲区数据交付接收应用进程 而不再等到后续数据的到达 PSH 0时 要等缓存都填满后再向上交付 PSH位与URG位的差异PSH在Telnet中使用较多 往往用户输入字符 希望立即能发给服务器 因此设置PSH 1 此时 发送方TCP不必等到更多数据以构成特定大小的段 接收方同样也根据该位 立即将缓冲区数据提交给应用程序 但数据的发送和提交仍是按照数据的先后次序进行处理 URG属于紧急操作 要求优先发送紧急数据 并在接收方优先提交 如Ctrl x Ctrl c等终止操作命令 紧急数据被插入当前段的最前面 所以指针指向的是紧急数据的最后一个字节 进行发送 接收方根据紧急指针将紧急数据抽取出来立即提交给应用程序 而不必排队等待处理 即 紧急数据不排队 直接优先处理 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 复位RST ReSeT 当RST 1时 表明TCP连接中出现严重差错 如由于主机崩溃或其他原因 必须释放连接 然后再重新建立传输连接 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 同步SYN 同步SYN 1表示这是一个连接请求或连接接受报文 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 终止FIN FINis 用来释放一个连接 FIN 1表明此报文段的发送端的数据已发送完毕 并请求释放传输连接 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 窗口字段 占2字节 16bit 向对方通告当前本机的接收缓冲区的大小 用来让对方设置发送窗口的依据 单位为字节 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 检验和 占2字节 16bit 检验和字段检验的范围包括首部和数据这两部分 在计算检验和时 要在TCP报文段的前面加上12字节的伪首部 计算方法和IP数据报首部校验和的计算方法相同 TCP伪首部的信息来自IP数据报的首部 协议字段指明当前协议为TCP 6 TCP段的发送端和接收端在计算校验和时都会加上伪首部信息 若接收端验证校验和是正确的 则说明数据到达了正确主机上正确协议的正确端口 为什么要引入TCP的伪首部 为了验证TCP段数据段是否传送到了正确的信宿 由于TCP数据段本身只含有目的端口号 不能构成一个完整的信宿端应用进程的标识 所以要通过伪首部来补充其他信息 引入伪首部后进行的TCP校验和计算是TCP IP协议栈中保证数据正确性的唯一手段 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 紧急指针字段 占16位 指出在本报文段中紧急数据共有多少个字节 即紧急指针指出本报文段中紧急数据的最后一个字节的序号 紧急数据放在本报文段数据的最前面 TCP首部 20字节固定首部 目的端口 首部长度 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 位08162431 填充 填充字段 这是为了使整个首部长度是4字节的整数倍 TCP首部 20字节固定首部 目的端口 数据偏移 检验和 选项 长度可变 源端口 序号 紧急指针 窗口 确认号 保留 FIN SYN RST PSH ACK URG 比特08162431 填充 选项字段 长度可变 TCP最初只规定了一种选项 即最大报文段长度MSS MSS告诉对方TCP 我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节 MSS MaximumSegmentSize 是TCP报文段中的数据字段的最大长度 数据字段加上TCP首部才等于整个的TCP报文段 TCP选项是变长字段 当前TCP使用的选项 选项结束标志为单字节选项 代码为0 用于表示选项结束 无操作选项为单字节选项 代码为1 用于选项的填充 实现32位对齐 TCP选项是变长字段 当前TCP使用的选项 最大段大小 MSS 选项为多字节选项 代码为2 长度为4字节 最后两个字节用于标识本机能够接收的段 数据字段 的最大字节数 该值范围为0到65535 默认值为536 TCP选项是变长字段 当前TCP使用的选项 窗口规模因子 扩大选项 选项为多字节选项 代码为3 长度为3字节 其中有一个字节表示规模因子 移位值S 新的窗口值等于TCP首部中的窗口位数增大到 16 S 相当于把窗口值向左移动S位后获得实际的窗口大小 窗口规模因子 在TCP段的首部存在16比特的窗口大小字段 但在高吞吐和低延迟的网络中 65535字节的窗口仍然嫌小 通过在选项中采用窗口规模因子 可以增加窗口的大小 扩展后的窗口大小为 Wn Wo 2fWn为新的窗口大小 Wo为TCP首部窗口大小字段的值 f为窗口规模因子 TCP选项是变长字段 当前TCP使用的选项 时间戳选项为多字节选项 代码为8 长度为10字节 其中最主要的字段时间戳值字段 4字节 和时间戳回送回答字段 4字节 时间戳值字段由源端在发送数据段时填写信宿端收到后 在确认数据段中将收到的时间戳值填入时间戳回显应答字段信源端根据该时间戳值和当前时间戳可以计算出数据段的往返时间 代码为8长度为10字节 第三节TCP连接的建立和拆除 TCP的连接管理 面向连接的传输需要3个阶段 连接建立数据传输连接终止TCP连接的管理就是使传输连接的建立和释放都能正常地进行 3 3TCP连接的建立和拆除 3 3 1TCP连接的建立为了实现数据的可靠传输 TCP要在应用进程间建立传输连接 从理论上讲 建立传输连接只需要一个请求和一个响应就可以了 但是由于通信子网的问题 请求有可能丢失 为了解决请求的丢失问题 常用的办法是超时重传 客户发出连接请求时 启动一个定时器 一旦定时器超时 客户将被迫再次发起连接请求 会导致重复连接 解决重复连接的办法 三次握手方法 Three wayHandshake TCP连接的建立三次握手过程 采用客户 服务器方式 服务器告诉自己的TCP已经准备好接受连接 称为被动打开请求 被动等待连接建立 客户程序发出请求叫做主动打开 主动发起连接的建立 解决重复连接的办法 三次握手方法 Three wayHandshake 三次握手方法要求对所有报文进行编号 TCP采用的方法是给每个字节一个32比特的序号 每次建立连接时都产生一个新的初始序号 序号字段位数定长 序号循环使用 序号字段位数较长 当序号循环一周回来时 使用同一序号的旧报文段早已传输完 这样 保证网络中不会同时出现来自同一源主机的相同序号的两个不同报文段 建立连接前 服务器端首先被动打开其熟知的端口 对端口进行监听 当客户端要和服务器建立连接时 发起一个主动打开端口的请求 临时端口 然后进入三次握手过程 1 第一次握手 由要建立连接的客户向服务器发出连接请求段 该段首部的同步标志 SYN被置为1 并在首部中填入本次连接的客户端的初始段序号SEQ 例如 SEQ 26500 2 第二次握手 服务器收到请求后 发回连接确认 SYN ACK 该段首部中的同步标志 SYN被置为1 表示认可连接 首部中的确认标志 ACK被置为1 表示对所接收的段的确认 与ACK标志相配合的是准备接收的下一序号 ACK26501 该段还给出了自己的初始序号 例如 SEQ 29010 对请求段的确认完成了一个方向上连接 第三次握手 客户向服务器发出的确认段 段首部中的确认标志ACK被置为1 表示对所接收的段的确认 与ACK标志相配合的准备接收的下一序号被设置为收到的段序号加1 ACK29011 TCP连接 连接建立 连接建立过程中要解决以下三个问题 要使每一方能够确知对方的存在 要允许双方协商一些参数 如最大报文段长度 最大窗口大小 服务质量等 能够对传输实体资源 如缓存大小 连接表中的项目等 进行分配 用三次握手建立TCP连接 CLOSED CLOSED A B 客户 服务器 A的TCP向B发出连接请求报文段 其首部中的同步位SYN 1 并选择序号seq x 表明传送数据时的第一个数据字节的序号是x 用三次握手建立TCP连接 CLOSED CLOSED A B 客户 服务器 B的TCP收到连接请求报文段后 如同意 则发回确认 B在确认报文段中应使SYN 1 使ACK 1 其确认号ack x 1 自己选择的序号seq y CLOSED CLOSED A B 客户 服务器 A收到此报文段后向B给出确认 其ACK 1 确认号ack y 1 A的TCP通知上层应用进程 连接已经建立 CLOSED CLOSED A B 客户 服务器 B的TCP收到主机A的确认后 也通知其上层应用进程 TCP连接已经建立 用三次握手建立TCP连接的各状态 CLOSED CLOSED A B 客户 服务器 携带窗口信息 SYN ACKACK 推送数据PSH位将PSH位置为1表示发送端TCP不需要等待窗口被填满 每创建一个报文段就立即发送 紧急数据发送程序希望某一块数据不按字节流顺序读出 如ctrl c命令 紧急指针 定义了紧急数据的结束和正常数据的开始 TCP数据传送 3 3 2TCP连接的拆除连接双方都可以发起拆除连接操作 简单地拆除连接可能会造成数据丢失 例如 A B两主机已建立连接并传输报文 A主机在B主机没有准备的情况下 单方面发出断开连接请求 并停止接收该连接上的数据 但断开连接请求的传输要有一段时间 而在B主机未收到断开连接请求之前 随时可能向A主机发送数据 会有丢失数据的可能性 解决 TCP采用和三次握手类似的方法 四次握手方法 这里可以将断开连接操作视为在两个方向上分别断开连接操作构成 一方发出断开连接请求后并不马上拆除连接 而是等待对方的确认 对方收到断开连接请求后 发送确认报文 这时拆除的只是单方向上连接 半连接 对方发送完数据后 再通过发送断开连接请求来断开另一个方向上的半连接 三次握手过程1 主动关闭端发送一个FIN报文段 FIN seq x ack y F 2 服务器端发送一个FIN ACK报文段 FIN ACK seq y ack x 1 A F 3 发送一个ACK报文段 ACK seq x ack y 1 A 四次握手过程半关闭连接 TCP的连接释放 CLOSED 数据传送 ESTAB LISHED ESTAB LISHED A B 客户 服务器 CLOSED 数据传输结束后 通信的双方都可释放连接 现在A的应用进程先向其TCP发出连接释放报文段 并停止再发送数据 主动关闭TCP连接 A把连接释放报文段首部的FIN 1 其序号seq u 等待B的确认 TCP的连接释放 数据传送 通知应用进程 ESTAB LISHED ESTAB LISHED A B 客户 服务器 B发出确认 确认号ack u 1 而这个报文段自己的序号seq v TCP服务器进程通知高层应用进程 从A到B这个方向的连接就释放了 TCP连接处于半关闭状态 B若发送数据 A仍要接收 TCP的连接释放 数据传送 ESTAB LISHED ESTAB LISHED A B 客户 服务器 数据传送 若B已经没有要向A发送的数据 其应用进程就通知TCP释放连接 TCP的连接释放 数据传送 ESTAB LISHED ESTAB LISHED A B 客户 服务器 数据传送 A收到连接释放报文段后 必须发出确认 TCP的连接释放 数据传送 ESTAB LISHED ESTAB LISHED A B 客户 服务器 数据传送 在确认报文段中ACK 1 确认号ack w 1 自己的序号seq u ACK 1 seq u ack w 1 TCP的连接释放 ACK 1 seq u ack w 1 FIN 1 ACK 1 seq w ack u 1 FIN WAIT 1 CLOSE WAIT FIN WAIT 2 LAST ACK 被动关闭 数据传送 ESTAB LISHED ESTAB LISHED A B 客户 服务器 数据传送 CLOSED 5 9 2TCP的连接释放 TCP连接必须经过时间2MSL后才真正释放掉 最大生存时间MSL 一个报文段在被丢弃前在因特网中能够生存的最大时间 30 60s 第四节TCP流量控制 3 4TCP流量控制 TCP除了提供进程通信能力外 主要特点是具有高可靠性 TCP在发送端与接收端之间建立一条连接 报文需要得到接收端的确认 TCP传输的是一个无报文丢失 重复和失序的正确的数据流 TCP采用的最基本的可靠性技术 流量控制拥塞控制差错控制 问题 在面向连接的传输过程中 发送方与接收方在发送报文的速率方面要协调一致 若发送方一味地向网络注入数据 则可能造成网络拥塞或因接收方来不及处理而丢失数据 若发送方每发出一个报文都等待对方的确认 势必造成效率低下 解决 滑动窗口协议 采用滑动窗口协议既能够保证可靠性 又可以充分利用网络的传输能力 这种方案允许连续传输多个报文而不必等待各个报文的确认 能够连续发送的报文数受到窗口大小的限制 滑动窗口协议通过发送方窗口和接收方窗口的配合来完成传输控制 发送缓存中是一组顺序编号的字节数据 这些数据的一部分在发送窗口中 另一部分在发送窗口外 图中发送缓存左端和右端空白处表示可以填入数据的空闲缓存 实际上可以将缓存视为左端和右端相连的环 窗口前面是已经发送而且收到确认的数据 因此 缓存被释放 在发送窗口中 左边是已经发送但尚未得到确认的数据 右边是尚未发送但可以连续发送的数据 窗口外的数据是暂不能发送的数据 一旦窗口内的部分数据得到确认 窗口便向右滑动 将已确认的数据移到窗口的外面 这些数据所对应的缓冲单元成为空闲单元 窗口右边沿的移动使新的数据又落入到窗口中 成为可以被连续发送的数据的一部分 接收方的窗口反映当前能够接收的数据的数量 图给出了接收方缓存与窗口的示意 接收端窗口的大小 W对应接收端缓存可以继续接收的数据量 它等于接收缓存大小 M减去缓存中尚未提交的数据字节数 N 即W M N 接收方窗口的大小取决于接收方处理数据的速度和发送方发送数据的速度 当从缓存取走数据的速度低于数据进入缓存的速度时 接收窗口逐渐缩小 反之则逐渐扩大 接收方将当前窗口大小通告给发送方 利用TCP段首部的窗口大小字段 发送方根据接收窗口调整其发送窗口 使发送方窗口始终小于或等于接收方窗口的大小 通过使用滑动窗口协议限制发送方一次可以发送的数据量 就可以实现流量控制的目的 这里的关键是要保证发送方窗口小于或等于接收方窗口的大小 当发送方窗口大小为1时 每发送一个字节的数据都要等待对方的确认 这便是简单停等协议 流量控制可以在网络协议的不同层次上实现 TCP的流量控制是在传输层上实现的端到端的流量控制 TCP流量控制 一般说来 我们总是希望数据传输得更快一些 但如果发送方把数据发送得过快 接收方就可能来不及接收 这就会造成数据的丢失 流量控制 就是让发送方的发送速率不要太快 既要让接收方来得及接收 也不要使网络发生拥塞 折中方法 滑动窗口协议两个主机在缓存上各使用一个窗口 由该窗口决定可以发送而不必考虑确认的数据量 窗口有左沿和右沿 都可以滑动 展开 不允许发送 已发送并收到确认 A的发送窗口 20 允许发送的序号 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 B期望收到的序号 前沿 后沿 合拢 缩回 根据B给出的窗口值A构造出自己的发送窗口 TCP标准强烈不赞成发送窗口前沿向后缩回 TCP流量控制 不允许发送 已发送并收到确认 A的发送窗口位置不变 允许发送但尚未发送 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 已发送但未收到确认 56 P1 P2 P3 不允许接收 已发送确认并交付主机 B的接收窗口 允许接收 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 未按序收到 可用窗口 A发送了11个字节的数据 P3 P1 A的发送窗口 又称为通知窗口 P2 P1 已发送但尚未收到确认的字节数P3 P2 允许发送但尚未发送的字节数 又称为可用窗口 允许发送但尚未发送 A的发送窗口向前滑动 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 已发送并收到确认 不允许发送 已发送但未收到确认 56 P1 P2 P3 允许接收 B的接收窗口向前滑动 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 已发送确认并交付主机 不允许接收 56 未按序收到 A收到新的确认号 发送窗口向前滑动 先存下 等待缺少的数据的到达 不允许发送 已发送并收到确认 A的发送窗口已满 有效窗口为零 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 已发送但未收到确认 56 P1 P2 P3 A的发送窗口内的序号都已用完 但还没有再收到确认 必须停止发送 窗口大小取决于2个数中的较小一个 接收窗口 rwnd 由对方发送的包含确认的报文段中所给出的值 拥塞窗口 cwnd 由网络为避免拥塞而确定的值 滑动窗口举例 如果接收端主机B的缓存大小为5000字节 其中1000字节用于存放收到而未处理的数据 试问主机A的接收窗口值rwnd是多少 主机B在溢出之前只能接收4000字节数据 所以A的rwnd为4000字节 服务器收到一个分组 其确认号为202而rwnd为9 主机已发送出203 204 205字节 cwnd值为20 试画出服务器的窗口 需要强调三点 A的发送窗口并不总是和B的接收窗口一样大 因为有一定的时间滞后 TCP标准没有规定对不按序到达的数据应如何处理 通常是先临时存放在接收窗口中 等到字节流中所缺少的字节收到后 再按序交付上层的应用进程 TCP要求避免缩回窗口 窗口关闭 接收端可以发送rwnd为0的报文段来暂时关闭窗口 源点并非必须要发送整个窗口的大小 糊涂窗口综合症 糊涂窗口症状 非常低效率地使用网络的容量 发送应用程序产生数据很慢 接收应用程序消耗数据很慢 导致发送的报文段很小 引起操作效率的降低 解决方法 发送端产生的症状 Nagle算法 1 立即发送第1块数据 哪怕只有1个字节 2 在输出端 累计并等待 直到收到TCP确认或积累到足够数据 3 重复步骤2 特点 简单 综合考虑应用程序产生数据的速率 以及网络运输数据的速率 糊涂窗口综合症 接收端产生的症状 假设接收端缓存为4000字节 发送端发出第1个4000字节收 接收端会发送窗口值为0来关闭窗口 若接收应用程序消耗数据很慢 一次仅1个字节 则会产生糊涂窗口症状 解决方法 1 Clark解决方法 只要有数据到达就发送确认 但宣布的窗口大小为零 直到或者缓存空间已能放入具有最大长度的报文段 或者缓存空间的一半已经空了 2 推迟确认 推迟发送确认报文段 直到缓存有足够的空间为止 优点 减少通信量 不需要对每个报文段进行确认 缺点 可能迫使发送端重传它未被确认的报文段 推迟确认不超过500ms 第五节TCP拥塞控制 3 5TCP拥塞控制 流量控制是由于接收端不能及时处理数据而引发的控制机制 拥塞是由于网络中的路由器超载而引起的严重延迟现象 拥塞的发生会造成数据的丢失 数据的丢失会引起超时重传 而超时重传的数据又会进一步加剧拥塞 如果不加以控制 最终将会导致系统的崩溃 拥塞造成的数据丢失 仅仅靠超时重传是无法解决的 因此 TCP提供了拥塞控制机制 TCP的拥塞控制 仍然是利用发送方的窗口来控制注入网络的数据流的速度 减缓注入网络的数据流后 拥塞就会被解除 引入拥塞控制后 发送窗口的大小取决于两个方面的因素 接收方的处理能力 确认报文所通告的窗口大小 即可用的接收缓存的大小 来表示 网络的处理能力 发送方所设置的变量 拥塞窗口来表示 发送窗口的大小取通告窗口和拥塞窗口中小的一个 发送窗口大小 min 接收方通告窗口大小 拥塞窗口大小 和接收窗口一样 拥塞窗口也处于不断的调整中 一旦发现拥塞 TCP将减小拥塞窗口 为了避免和消除拥塞 TCP周而复始地采用三种策略来控制拥塞窗口的大小 首先是使用慢启动策略 在建立连接时拥塞窗口被设置为一个最大段大小MSS 对于每一个段的确认都会使拥塞窗口增加一个MSS 实际上这种增加方式是指数级的增加 例如 开始时只能发送一个数据段 当收到该段的确认后拥塞窗口加大到两个MSS 发送方接着发送两个段 收到这两个段的确认后 拥塞窗口加大到4个MSS 接下来发送4个段 拥塞窗口加大到8个MSS 当拥塞窗口加大到门限值 拥塞发生时拥塞窗口的一半 时 进入拥塞避免阶段 在这一阶段 使用的策略是 每收到一个确认 拥塞窗口加大1个MSS 即使确认是针对多个段的 拥塞窗口也只加大1个MSS 这在一定程度上减缓了拥塞窗口的增长 但在此阶段 拥塞窗口仍在增长 最终可能导致拥塞 拥塞使重传定时器超时 发送方进入拥塞解决阶段 发送方在进行重传的同时 将门限值调整为拥塞窗口的一半 并将拥塞窗口恢复成一个MSS 然后进入新一轮的循环 7 3 1网络拥塞 网络上的负载 发送到网络的分组数 大于网络的容量 网络能处理的分组数 则可能会发生拥塞 拥塞控制是一种机制和技术 使网络负载低于网络容量 分组丢失原因 1 线路噪声2 拥塞TCP假设分组传输超时是由拥塞造成 且以监控定时器超时作为出现问题的信号 拥塞的原因 在任何包含等待的系统中都会产生拥塞 网络产生拥塞 是因为R orSW 有队列 处理分组之前或之后存放分组的缓存 R到达 R处理 输入队列 R离开 R处理 输出队列 分组到达路由器的一个接口 需要3个步骤才能离开路由器 1 分组放在输入队列的末尾 等待检查2 一旦该分组到了输入队列最前端 路由器处理模块将其取走 根据路由表和目的地址找到路由 3 分组被放到适当的输出队列中 等候发送 拥塞控制涉及的因素 判断网络性能的两个因素 延时 吞吐量延时 传播延时 处理延时吞吐量 单位时间内通过网络的分组数 拥塞控制涉及的因素 分组延时和网络负载的关系负载容量时 延迟无穷大 队列 源点收不到确认 重传 使延时 拥塞控制涉及的因素 吞吐量和网络负载的关系负载容量时 吞吐量下降 队列没空位 路由器丢弃分组 丢弃并不会减少网络中的分组数 分组不到终点 源点将其按超时机制重传 拥塞控制技术 拥塞控制 技术或机制在拥塞发生之前防止其发生 在拥塞发生之后消除拥塞 TCP中有机结合慢启动 拥塞避免 快速重传 快速恢复来实现拥塞控制 拥塞窗口 cwnd 拥塞控制的关键参数 控制源端在拥塞情况下一次最多能发送多少数据包 接收窗口 rwnd 接收端对源端发送窗口大小所做的限制 在建立连接时由接收方通过ACK确认带给源端慢启动门限值 ssthresh 拥塞控制中用来限制发送窗口大小的门限值 它是慢启动阶段与拥塞避免阶段的分界点 初始值设为65535bytes或cwnd的大小 回路响应时间 RTT 数据包从源发到接收端直至源收到接收端的该数据包确认信息所经历的时间间隔 超时重传计数器 RTO 描述数据包从发送到失效的时间间隔 是源端用来判断数据报是否丢失和网络拥塞的重要参数 发送端的发送窗口的上限值应当取为接收端窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个 即应按以下公式确定 发送窗口的上限值 Min rwnd cwnd 当rwnd cwnd时 是接收端的接收能力限制发送窗口的最大值 当cwnd rwnd时 则是网络的拥塞限制发送窗口的最大值 TCP拥塞控制的四个阶段 慢启动阶段拥塞避免阶段快速重传阶段快速恢复阶段 1慢启动阶段 当连接刚建立或超时时 进入慢启动阶段 当新建TCP连接时 拥塞窗口 cwnd 被初始化为一个数据包大小 缺省为512或536bytes 实际发送窗口win取拥塞窗口与接收方提供的通告窗口的较小值 即win min cwnd awnd 每收到一个ACK确认 就增加一个数据包发送量 这样慢启动阶段cwnd随RTT呈指数级增长 1个 2个 4个 8个 慢启动指数增长 慢启动 到ssthresh门限时 停止 大多数情况下ssthresh 65535 优点 慢启动采用逐渐增大cwnd的方法 可以防止TCP在启动一个连接时向网络发送过多的数据包而造成不必要的数据丢失和网络拥塞 为了防止cwnd的无限制增长引起网络拥塞 引入一个状态变量 慢启动门限值ssthresh当cwndssthresh时 使用拥塞避免算法 减缓cwnd的增长速度 2拥塞避免阶段 当TCP源端发现超时或收到3个相同的ACK确认帧时 即认为网络将发生拥塞 此时进入拥塞避免阶段 在拥塞避免阶段 慢启动域值ssthresh将被设置为当前cwnd的一半 当发生超时时 cwnd被置为初始值1 如果cwnd ssthresh 则执行拥塞避免算法 即cwnd在每收到一个ACK确认时只增加1个报文段 拥塞避免阶段cwnd随RTT呈线性增长 拥塞避免加法增大 慢启动 到ssthresh门限时 停止 然后开始拥塞避免 每次确认后加1 拥塞检测乘法减小 拥塞发生 cwnd必须减小 发方能猜到拥塞发生的唯一方法 重传报文重传发生在两个情况 RTO超时or收到3个Ack则ssthresh门限值 1 2当前窗口RTO超时 则cwnd 1 慢启动 可能已拥塞 3个ACK 则cwnd ssthresh 拥塞避免 未拥塞 在拥塞避免阶段 当数据包超时时 cwnd被置为1 重新进入慢启动阶段 这会导致过大地减小发送窗口尺寸 降低TCP连接的吞吐量 因此 引入了快速重传和快速恢复机制 3快速重传阶段 当网络发生拥塞时 如果源端等待超时之后再进行拥塞控制 那么从出现拥塞到实施控制有一定的时延 除了超时之外 源端还可以使用重复ACK作为拥塞信号 源端在接收到重复ACK时并不能确定是由于分组丢失还是分组乱序产生的 通常假定如果是分组乱序 在目的端处理之前源端只可能收到一个或两个重复的ACK 如果源端连续接收到三个或更多的重复ACK 表明一个报文段丢失了 这时 源端不等到重传定时器超时就重发这个可能丢失的分组 这就是快速重传算法 在快速重传阶段 当源端收到3个或3个以上重复的ACK时 就判定数据包丢失 同时ssthresh设置为当前cwnd的一半 并重传丢失的包 进入快速恢复阶段 4快速恢复阶段 当快速重传算法重传了可能丢失的分组之后 如果TCP重新进入慢启动阶段 将会使拥塞窗口减为1 重新开始探测网络带宽 从而严重影响网络吞吐量 因此快速恢复算法在快速重传之后转去执行拥塞避免算法 避免了过大地减小发送窗口而导致的网络性能下降 在快速恢复阶段 每收到重复的ACK 则cwnd加1 收到非重复ACK时 置cwnd ssthresh 转入拥塞避免阶段 如果发生超时重传 则置ssthresh为当前cwnd的一半 cwnd 1 重新进入慢启动阶段 TCP拥塞策略小结 拥塞例子 第六节TCP差错控制 3 6TCP差错控制 差错控制是TCP保证可靠性的手段之一 TCP的差错控制包括差错检测和纠正 TCP处理的差错有数据被破坏 重复 失序和丢失 数据被破坏可以通过TCP的校验和检测出来 接收方丢弃出错的数据 而且不给出确认 发送方定时器超时后 重发该数据 重复数据段一般是由超时重传造成的 接收方可以根据序号判断是否是重复数据段 对于重复数据段只需要简单地丢弃即可 数据失序是由于TCP下面的IP协议是无连接的数据报协议 不能保证数据报的按序到达 TCP对于提前到达 前面的数据还未到达 的数据 暂不确认 直到前面的数据到达后再一起确认 数据丢失错误也是通过超时重传来进行恢复 但是确认报文段的丢失一般不会造成任何影响 因为TCP采用的是累计确认 TCP确认针对流中的字节序号 而不是段号 一般情况下 接收方确认已正确收到的 连续的流前部 对于接下去的数据段的确认也就包含了对前面数据的确认 若下一个确认未能在重传定时器超时之前到达发送方 则会出现重复报文段 重复数据会被接收方鉴别出来 根据序号 并被丢弃 超时重传最关键的因素是重传定时器的定时时间片的大小 由于在因特网这种大型网络中传输延迟变化范围很大 从发出数据到收到确认所需的往返时间 RoundTriptTime RTT 动态变化 很难确定 为了适应传输延迟的动态

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论