传输控制协议(TCP).ppt

上传人:xt****7 文档编号:5183449 上传时间:2020-01-22 格式:PPT 页数:68 大小:748.81KB
返回 下载 相关 举报
传输控制协议(TCP).ppt_第1页
第1页 / 共68页
传输控制协议(TCP).ppt_第2页
第2页 / 共68页
传输控制协议(TCP).ppt_第3页
第3页 / 共68页
点击查看更多>>
资源描述
第九章传输控制协议 TCP 2 9 1引言 TCP TransmissionControlProtocolTCP叫做面向连接的 可靠的传输协议 它给服务增加了面向连接和可靠性的特点 3 进程到进程的通信 4 端口号 与UDP一样 TCP也是服务器使用熟知端口号 客户程序使用短暂端口号 5 端口 端点 连接 6 TCP使用的熟知端口号 7 Socket地址 TCP需要两个标识符 IP地址和端口号 它们各用在一端以建立一条连接 要使用TCP的服务 我们需要一对Socket地址 客户Socket地址和服务器Socket地址 一个IP地址与一个端口号合起来就叫做Socket地址 8 9 2TCP的服务 TCP服务 流式数据服务 全双工服务 可靠服务 9 流式数据服务 流式服务 发送TCP从发送应用程序接收到字符流 从这个流中提取适当的长度创建为叫做报文段的分组 然后将它们发送到网络上 接收TCP则接收报文段 从中提取数据 若它们没有按序到达还要将它们排序 并将它们作为字符流交付给接收应用程序 10 全双工服务 数据可在同一时间双向流动 数据 确认 捎带 确认可随数据一起发送 11 9 3TCP报文段 12 对各字段的说明 源端口地址 是一个16位字段 定义了在主机中发送该报文段的应用程序的端口号 目的端口地址 是一个16位字段 定义了在主机中接收该报文段的应用程序的端口号 序号 是一个32位字段 它定义了一个数 指派给本报文段数据的第一个字节 为了保证连通性 要发送的每一个字节都要编上号 序号告诉目的地 这个序列中的哪一个字节是报文段中的第一个字节 确认号 是一个32位字段 定义了源进程期望从对方接收的报文段的序号 确认可捎带和数据一起发送 首部长度 是一个4位字段 指出TCP首部共有多少个4字节字 保留 是一个6位字段 保留为今后使用 13 控制 是一个6位字段 定义了6种不同的控制位或标志 这些比特用在TCP的流控制 连接建立和中止以及数据传送的方式等方面 14 对各字段的说明 续 窗口大小 是一个16位字段 定义对方必须维持的窗口大小 以字节为单位 最大长度为65535字节 检验和 是一个16位字段 紧急指针 是一个16位字段 只有当紧急标志置位时 这个字段才有效 这时的报文段包括紧急数据 选项 在TCP首部中可以有多达40字节的可选信息 15 流 分组和序号 分组的序号是这样一个数 它指派给本报文段数据的第一个字节 16 9 4选项 TCP首部可以有多达40个字节的可选信息 它们用来将附加信息传递给目的站 或用来将其他选项对齐 17 选项说明 无操作 是一个一字节选项 用作选项之间的填充 选项结束 也是一个1字节选项 用于选项字段结束时的填充 但它只能用作最后一个选项 在此选项之后 接收器就寻找有效载荷数据 18 选项说明 续 最大报文段长度 这个选项定义可以被目的站接收的TCP报文段的最长数据块 即数据的最大长度 最大数据长度是在连接建立阶段确立的 这个大小是由报文段的目的站而不是源站确定的 这个选项仅在进行连接的报文段中使用 它不能用于数据传送中的报文段 下图为这个选项的格式 19 选项说明 续 窗口扩大因子 这个选项定义了滑动窗口的大小 为了增大窗口大小 就要使用窗口扩大因子 新的窗口大小可以这样求出 即先计算2的n次方 这里n是窗口扩大因子 再将得出的结果乘以首部中的窗口大小 新的窗口大小 首部中定义的窗口大小 2窗口扩大因子窗口扩大因子只能在连接建立阶段确定 在数据传送阶段 窗口大小可以改变 但它必须乘以同样的扩大因子 下图为这个选项的格式 20 选项说明 续 时间戳 这是一个10字节字段 该字段由报文段离开的源站填入 目的站接收报文段并存储该时间戳 当目的站发送对该报文段的字节的确认时 就输入前面在回送回答字段中存储的值 当源站收到确认时 就将当前时间与该数值进行检查 差值就是往返时间 下图为这个选项的格式 21 9 5检验和 22 TCP需要解决的一些问题 传输时延长 丢失 重复 失序或受到损伤 无法预知的传输时延 网络拥塞 Flowcontrol Errorcontrol Connectioncontrol Congestioncontrol 23 9 6流控制 流控制定义了在收到从目的站发来的确认之前源站可以发送的数据量 滑动窗口是TCP使用的流控制解决办法 24 停止等待协议 上图中的简单停止等待协议是一个非常缓慢的过程 若数据要走很长的距离 源站就要在等待确认时一直处在空闲状态 25 滑动窗口 这是一个流控制协议 两个主机为每一个连接各使用一个窗口 窗口覆盖了缓存的一部分 这部分就是主机可以发送而不必考虑从另一个主机发来的确认 这个窗口叫滑动窗口 因为当接收端对安全 完整地接收到的字节发送确认时 这个窗口能够在缓存上滑动 26 带指针的滑动窗口 TCP使用可变大小的窗口 窗口可增大也可减小 取决于目的站的通知 27 发送端窗口 窗口大小与确认号有关 高层协议可以一次发送一个或多个字节到TCP Sentbutnotacknowledged 等待确认或重传 Sentbutnotacknowledged Datawaitingforsending Acknowledged Cannotbesentnow 28 接收端窗口 Rearrangedbutnotsubmitted Unusedbuffer Submitted Fragmentary 由序号确定要再排列的接收数据流 高层协议可以一次从TCP接收一个或多个字节 29 可变大小窗口 发送端窗口大小能够动态的改变接收端宣布现在能使用的接收端缓存大小 发送端调整窗口大小以适应这个值 最小的报文段大小为 1字节 接收端宣布 我的缓存大小为0发送端停止发送数据 以下情况开始重新发送 宣布的缓存大小大于0实验发送 防止死锁带外数据 30 确认与重传 规则 发送序号是发送数据流的第一个字节 确认序号指出了接收方期望收到的下一个字节的序号 数据没有得到确认时 若超时了就必须重传 31 窗口管理 由接收端宣布的窗口大小通常就是接收端的缓存剩下的空间 32 对滑动窗口的几点说明 使用滑动窗口可使传输更加有效 同时也可以控制数据流 使得目的站不致因数据来的过多而瘫痪 TCP的滑动窗口是面向字节的 源站不一定要发送出整个窗口大小的数据 窗口大小可由目的站将其增大或减小 目的站可在任何时候发送确认 33 糊涂窗口综合症 什么是糊涂窗口综合症 如何导致的 怎么解决 网络上有很多短报文段 发送应用程序产生数据很慢 或者接收应用程序吸收数据很慢 或者两者都有 34 一 发送端解决办法 发送端的TCP可能产生糊涂窗口综合症 如果它为产生数据很慢的应用程序服务 Nagle算法 发送端的TCP将它从发送应用程序收到的第一块数据发送出去 哪怕只有一个字节 发送第一个报文段后 发送端的TCP就在输出缓存中积累数据并等待 或者收到接收端的TCP发送出一个确认 或者数据已累积到可以装成一个最大的报文段 就将其发送 35 二 接收端解决办法 接受端的TCP可能产生糊涂窗口综合症 如果它为消耗数据很慢的应用程序服务 Clark解决方法 只要有数据到达就发送确认 但宣布的窗口大小为零 直到缓存空间已能放入具有最大长度的报文段 或者缓存空间的一半已经空了 36 二 接收端解决办法 续 推迟确认 这是另一种解决接收端产生糊涂窗口综合症的方法 当一个报文段到达时 并不立即发送确认 接收端在确认收到的报文段之前一直等待 直到输入缓存有足够的空间为止 接收端不需要确认每一个报文段 这样可以减少通信量 缺点是 延迟的确认可能迫使发送端重传其未被确认的报文段 目前规定确认的延迟不能超过500毫秒 37 9 7差错控制 38 差错检测和纠正 在TCP中不使用否认若一个报文段在超时截止期之前未被确认 则被认为是受到损伤或已丢失 需要进行重传 39 受损伤的报文段 40 丢失的报文段 41 重复的报文段 产生原因 可由源TCP产生 当超时截止期到而确认还没有收到 解决办法 目的TCP期望收到连续的字节流当含有同样序号的分组作为另一个收到的报文段到达时 目的TCP只要丢弃这个分组就可 42 失序的报文段 产生原因 TCP使用IP的服务 而IP是一个不可靠的无连接的网络层协议 解决办法 TCP对失序的报文段不确认 直到收到所有它以前的报文段为止 若确认晚到了 源TCP的失序的报文段的计时器会到期而重新发送该报文段 而目的TCP就丢弃重复的报文段 43 丢失的确认 44 9 8TCP的计时器 45 一 重传计时器 为了控制丢失的或丢弃的报文段 TCP使用处理重传时间 即对报文段的确认的等待时间 的重传计时器 撤销此计时器 若在计时器截止时间到之前收到了对此特定报文段的确认 重传此报文 并将计时器复位 若在收到了对此特定报文段的确认之前计时器截止期到 当TCP发送报文段时 它就创建该特定报文段的重传计时器 46 重传时间的计算 重传时间 2 RTT 47 RTT的计算 RTT 往返时间 使用时间戳选项 发送一个报文段 启动计时器 然后等待其确认 用在计算重传时间的RTT值是RTT的更新值 RTT 前面的RTT 1 当前的RTT 通常取90 当前的RTT 收到确认的时间 发送报文段的时间 48 估算RTT时的问题 假设 一个报文段在重传期间未被确认 这个报文段又被重传 当发送端TCP收到对此报文段的确认时 它无法知道该确认是对原来的报文段的确认 还是对重传的报文段的确认 考虑 在这种情况下 该如何估算RTT 49 Karn算法 在计算新的RTT时 不考虑重传报文段的RTT 不要更新RTT 除非你发送了一个报文段并在不需要重传时收到了确认 Karn算法要求发送方使用定时器补偿策略把超时重传的影响估计在内 50 二 坚持计时器 为了对付零窗口大小通知 TCP需要另一个计时器 坚持计时器 Sender Receiver Window 0 等待发送端的TCP发送更多的报文段 等待接收方发送确认来通知窗口的大小 Deadlock 要打开这个死锁 TCP为每个连接使用一个坚持计时器 51 坚持计时器的用法 当发送端的TCP收到一个窗口大小为零的确认时 就启动坚持计时器 当坚持计时器期限到时 发送端的TCP就发送一个特殊的报文段 称为探测报文段 用来提醒接收端的TCP 确认已丢失 必须重传 坚持计时器的值设置为重传时间的数值 若没有收到从接收端来的响应 则需发送另一个探测报文段 并将坚持计时器的值加倍和复位 发送端继续发送探测报文段 将坚持计时器的值加倍和复位 直到这个值增大到门限值 通常是60秒 为止 在这以后 发送端每隔60秒就发送一个探测报文段 直到窗口重新打开 52 三 保活计时器 保活计时器的用法 用来防止在两个TCP之间的连接处理长时间空闲 每当服务器收到客户的信息 就将计时器复位 超时通常设置为2小时 若服务器过了2小时还没收到客户的信息 它就发送探测报文段 若发送了10个探测报文段 每一个相隔75秒 还没有响应 就假定客户出了故障 因而就终止该连接 53 四 时间等待计时器 时间等待计时器的用法 用在连接终止期间 当TCP关闭一个连接时 它并不认为这个连接马上就真正关闭了 在时间等待期间中 连接还处于一种中间过渡状态 这就可使重复的FIN报文段 如果有的话 可以到达目的站因而可将其丢弃 这个计时器的值通常设置为一个报文段的寿命期待值的两倍 54 9 9连接 Source Destination 面向连接的协议在源站和目的站之间建立一条虚路径 面向连接的传输是通过两个过程来完成的 连接建立连接终止 属于一个报文的所有报文段都沿着这条虚路径发送 55 初始序号 初始序号 ISNs 在三次握手过程中要传输并获得确认 ISN被用来分辨字节在传输的流中的位置 ISN是每个机器随机选择的 TCP不能用1作为每次连接建立时的序号 双方要对各自的初始序号进行协商 56 连接建立 双方在传送数据前 须完成如下工作 主机A发送报文段宣布他愿意建立连接 报文段包括关于从A到B的通信量的初始化信息 主机B发送报文段确认A的请求 主机B发送报文段包括关于从B到A的通信量的初始化信息 主机A发送报文段确认B的请求 步骤2和3可以同时进行 57 连接建立 续 被动打开 三次握手过程从服务器开始 服务器程序告诉它的TCP 它已准备好接收一个连接 但它自己并不能完成这个连接 主动打开 客户程序发出请求 打算与服务器进行连接的客户告诉它的TCP它需要连接到特定的服务器 58 三次握手 59 两军队问题 Bluearmy 1 Bluearmy 2 Whitearmy Thebluesarmieswanttocommunicatethroughanunreliablechanneltosynchronizetheirattacks Doesaprotocolexistthatallowsthebluearmiestowin Attackat0 00onMay23 Howaboutit Noproblem 60 连接终止 要在两个方向都关闭连接需要如下过程 主机A发送报文段 宣布它愿意终止连接 主机B发送报文段对A的请求加以确认 在此之后 一个方向的连接就关闭了 但另一个方向的并没有关闭 当主机B发完其数据后 就发送报文段 表示它愿意关闭此连接 主机A确认B的请求 61 四次握手 62 连接复位 TCP可以请求将一条连接复位 这里的复位表示当前的连接已经被破坏了 在某一端的TCP请求了一条到并不存在的端口的连接 在另一端的TCP就可以发送报文段 其RST比特置为1以取消该请求 由于出现了异常情况 某一端的TCP可能愿意将连接异常终止 某一端的TCP可能发现在另一端的TCP已经空闲了很长的时间 以下情况后发生复位 63 9 10状态转换图 64 状态转换图 65 9 11拥塞控制 从发送站发出的分组要经过许多的路由器才能到达最终的目的站 若路由器接受分组过快 超过它的处理能力 就可能出现拥塞 会使一些分组被丢弃 拥塞会导致更严重的状态 更多的重传和更多的分组被丢弃 因而产生更严重的拥塞 最后导致整个系统崩溃 现在的TCP协议包括了这个功能 发送端的窗口大小不仅决定于接收端 而且取决于网络的拥塞状况 真正的窗口大小 minimum 接收端通知的窗口大小 拥塞窗口大小 66 窗口大小增大的策略 Congestionwindowsizeincreasesexponentiallyuntilthethreshold Afterthethresholditisincreasedonesegmentforeachacknowledgment 67 发送窗口大小变化 68 练习题 1 TCP在5 30 20发送了一个报文段 它在5 30 25收到确认 若以前的RTT值是4秒 问新的RTT值是多少 重传时间为多少 2 一TCP连接使用10000字节的窗口大小 而上一次的确认号是22001 它收到了一个报文段 确认了字节24001 并将窗口大小改变为11000 试用图说明在这之前与之后的窗口情况
展开阅读全文
相关资源
相关搜索

当前位置:首页 > 图纸专区 > 课件教案


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!