《TCP与UDP协议PPT课件.ppt》由会员分享，可在线阅读，更多相关《TCP与UDP协议PPT课件.ppt（25页珍藏版）》请在金锄头文库上搜索。
1、TCP与UDP TCP IP传输层有两个并列的协议 TCP和UDP 其中 TCP TransportControlProtocol 传输控制协议 是面向连接的 相当于OSI的TP4 而且两者确实有许多相似之处 UDP UserDatagramProtocol 用户数据报协议 是无连接的 相当于OSI的TP0 一般情况下 TCP和UDP共存于一个网间网中 前者提供高可靠服务 后者提供高效率服务 高可靠性的TCP用于一次传输大量报文的情形 如文件传输 远程登录等 高效率的UDP用于一次传输少量报文 尤其是交易型应用 的场合 其可靠性由应用程序提供 TCP要解决各种可靠性问题 因而比较复杂 UDP几
2、乎直接建立在IP协议之上 相对简单得多 TCP和UDP共存于一个网间网中的事实告诉我们 在计算机网络中 可靠性并不比效率更重要 只有可靠性而无效率的协议在某些应用场合下是根本没有用的 对二者的选择取决于应用的环境和需要 1 TCP与UDP IP数据报采用无连接的数据报机制 对数据只是尽力传送 至于传输是否正确 有序 不采取任何措施 因此 TCP IP的可靠性体现在传输层 传输层有两个协议 其中UDP协议是无连接的 因此传输层向它的上层协议提供的服务质量主要依靠TCP协议来保证 因为TCP提供面向连接的服务 称为端到端可靠性 2 传输层连接管理 传输层连接管理 包括连接端点的标识 建立传输连接的
3、模型 建立连接与撤除连接这样几个问题 1 连接端点的标识在建立连接的时候 必须显式地给出全局唯一的信宿端的地址 一个全局的传输服务用户应该用以下四个域来标识 TSAP NSAP 主机地址 网络号 当网络层是无连接的 IP协议就是 NSAP便可以忽略 TCP IP把TSAP叫做端口 port 一个端口拥有一个本地唯一的端口号 作为一种逻辑结构 TCP IP端口可以随机分配 但有一部分保留下来供系统专用 前者称为自由端口 后者称为保留端口 保留端口只占很小一部分 以全局方式进行分配 就是后面我们要提到的服务器进程 每一个标准的服务器都拥有一个全局公认的端口号 不同机器上同样的服务器 其端口号相同
4、自由端口占全部端口的绝大部分 以本地方式进行分配 TCP IP传输层的两个协议 TCP与UDP 3 传输层连接管理 他们各有自己的保留端口与自由端口 且保留端口号的范围都是0 255 不同协议的端口之间没有任何联系 不会互相干扰 同一个保留端口在TCP和UDP中可能对应于不同类型的应用进程 也可能对应于相同类型的应用进程 我们进一步来分析一下端口号 在同一台计算机上 当一个应用程序运行的时候 就分配给它一个端口 这里有三个问题 第一 什么时候 哪一个应用程序运行 是随机的 第二 同一个应用程序在不同时刻运行所分配的端口号一般不会相同 也就是说 一个应用程序并不拥有固定的端口号 第三 同一台主机
5、上拥有的应用程序是有限的 不可能你需要什么程序就有什么程序 2 建立传输连接的模型传输连接必须面向进程 必须用到对方的端点地址TSAP 问题是 发起连接的一方如何知道对方哪个应用程序正在运行 即使正在运行 分配给它的端口号又是多少呢 4 传输层连接管理 广泛使用的客户 服务器模型巧妙地解决了这个问题 客户 发起连接的一方 发出连接请求 服务器 接受连接的一方 中有一个特殊的后台进程 叫进程服务器 进程服务器随系统一起启动并常驻内存 它拥有一个全局公认的TSAP 客户根据对方的主机地址和进程服务器TSAP向对方进程服务器发起连接请求 在请求报文中同时给出自己的TSAP及所在的主机地址 进程服务器
6、监听其公认TSAP 一旦收到连接请求 便建立一条临时连接 客户通过临时连接向进程服务器发送一个报文 告诉它希望得到的服务 进程服务器便选择一个自由TSAP 并fok一个运行具体服务程序的新进程 将新TSAP传给新进程 进程服务器再向客户发回新TSAP 并终止临时连接 继续监听公认TSAP 客户再与具体服务器之间通过新TSAP建立新连接 并在新连接上开始正式通信 5 传输层连接管理 以上建立传输连接的模型是由ARPANET首先提出来的 称ARPANET初始连接协议 显而易见的缺点是 客户怎么能知道某台服务器上正好能提供它所需要的服务呢 即是否存在相应的应用程序 一种改进的模型是取消进程服务器 对
7、每一具体服务器均分配一个公认TSAP 再提供一个名字服务器 它也占用一个公认TSAP 根据服务名字 可以从名字服务器中查出对应的公认TSAP 客户先从名字服务器中查出具体服务器的公认TSAP 再直接与具体服务器建立连接 即可获得所需服务 3 建立连接在理想的情况下 一个成功的建立传输连接的过程如图8 45所示 图中 T CONNECT表示传输层连接类原语 request indication response和confirm分别是连接请求 指示 响应与确认原语 比如T CONNECTrequest表示层连接请求原语 建立连接时 客户发送一个请求报文 服务 6 传输层连接管理 器若愿意接收请求
8、则发回一个响应报文 这样连接就建立起来 这是一个合情合理的过程 很容易理解 7 传输层连接管理 然而问题并没有那么简单 因为子网不是理想的 不是所有子网都能保证分组能正确及时地传到信宿端 因为分组可能在传送过程中丢失 解决分组丢失的常用方法是使用超时重传 最难解决的问题是 请求根本没有丢失 而是在子网中存储起来 过一段时间后 又突然出现在服务器端 在无连接数据报子网中 尤其可能出现这种情况 这就是所谓延迟重复问题 消除重复连接有三种方法 消除重复连接本身 消除重复连接请求 三次握手建立连接 1 消除重复连接 遵循消除重复连接的思路 有两种具体方法可以考虑 即利用过时连接表和非重复TSAP地址
9、2 消除重复连接请求 消除重复连接请求总的想法是删除在网络中滞留的陈旧分组 方法是给每一分组赋予一个 8 传输层连接管理 生存时间 TimeToLive 简称TTL 分组一进入网络 立刻开始生存时间计数 到时候尚未到达信宿机者 一律被抛弃 从网间网中被清除 3 三次握手建立连接 即便是有了TTL这样的机制 也难保没有重复请求报文出现 最后的解决办法是在建立连接的机制上做文章 三次握手 three wayhandshaking 方法就是一种很常用的机制 三次握手方法首先要求对本次连接的所有报文进行编号 常用的方法是取当前时钟的最低n位作为初始序号 由于序号域具有足够的长度 可以绝对保证序号循环一
10、周回来时 使用同一序号的旧报文早已传输完毕 这样网络中不会出现关于同一连接 同一序号的两个不同报文 三次握手解决的问题是 假设A机向B机发出连接请求 但请求报文丢失 而一个延迟的重复的旧请求报文到达B 如果B接受此请求 连接就会错误地建立起来 9 传输层连接管理 面向连接的传输要求A机和B机以同步方式进行报文传输 双方发出的第一个报文均给出一个本地独立的初始序号 在双方一来一回的报文交换过程中 回报文要对收到的上一个来报文加以确认 在三次握手法的第一次中 A机向B机发出连接请求 简称CR 其中包含A机端的初始报文序号 比如X 第二次 B机收到CR后 发回连接确认 CC 其中 包含B机端的初始报
11、文序号 比如Y 以及B机对A机初始序号X的确认 第三次 A机向B机发送X序号数据 其中包含对B机初始Y的确认 三次握手法的操作过程如图8 46所示 由于A机在本端对报文进行编号 它知道哪些序号是过时的 假如B收到一个过时连接请求CR 初始序号 X1 并确认之 A机判断出CC 确认 X1 是过时的 将发送一个拒绝报文REJ 确认 Y 表示对来自B机的CC 初始序号 Y 确认 X1 的拒绝 于是便不会在旧的重复连接请求上建立错误连接了 10 传输层连接管理 图8 46三次握手示意 11 传输层连接管理 4 撤除连接撤除连接比建立连简单 但也可能造成数据丢失 因为连接的双方都可以发起撤除连接操作 假
12、设A B两机建立连接并传输报文 在A机毫无准备的情况下 B机单方面发出断连请求 并立刻终止接收该连接上数据 在A机未收到断连请求之前 随时可能向B机发送数据 于是便有了数据丢失的可能性 为了解决此问题 要再次使用三次握手法 一方发出断连请求后并不立即撤除连接 而要等待对方确认 对方收到请求后 发送确认报文 并撤除连接 发起方收到确认后最后撤除连接 12 传输层的其他问题 传输层的其他几个问题包括滑动窗口协议 传输层多路复用以及崩溃恢复 下面分别叙述 1 滑动窗口协议 滑动窗口协议的作用有二 其一是保证数据传输的可靠性 其二是实现流量控制 网关和接收端可以通过某种方式通知发送方改变其窗口大小 以
13、限制发方报文注入网络的速度 达到流控之目的 2 传输层多路复用 TCP IP的网络层不提供连接 所以不存在向下多路复用问题 向上多路复用指多个传输连接使用一个网络连接 其目的在于充分利用虚电路带宽 降低传输开销 TCP IP就属此种类型 3 崩溃恢复 这是传输层最难解决的问题之一 有两种情况 一是网络连接崩溃 一是主机崩溃 不管是那种崩溃 主机都会丢失未确认的数据或关于传输状态的信息 为了恢复崩溃 发送端向所有主机广播一个查询报文 宣告自己已经崩溃 希望得知其它主机所有打开连接的状态 以此为依据进行恢复 13 用户数据报协议UDP 用户数据报协议UDP UserDatagramProtocol
14、 建立在IP协议之上 提供无连接的数据报传送 相对于IP协议 它唯一增加的能力是提供协议端口 以保证进程通信 基于UDP的应用程序在不可靠子网上必须自己解决可靠性 如报文丢失 重复 失序 流控等 UDP虽然不可靠而TCP IP依然还要采用它的理由是UDP的高效率 一条UDP报文就叫一条用户数据报 分为头标和数据区 如图UDP报文格式所示 各字段的意义如下 信源端口 SOURCEPORT 发送端UDP端口 当不需要返回数据时 该域置0 信宿端口 DESTINATIONPORT 接收端UDP端口 长度 LENGTH 以字节计的整个报文长度 最小值为8 头标长 14 用户数据报协议UDP 校验和 C
15、HECKSUM 这是一个可选域 置0时表示未选 全1 负0的反码 表示校验和为0 UDP建立在IP之上 意味着整个UDP报文封装在IP数据报中传送 如图UDP报文封装所示 所谓封装实际上是发送端UDP软件将UDP报文交给IP软件后 IP软件在前面加一个头标 构成IP数据报 这一过程相当于将UDP报文装入IP数据报数据区 值得注意的是 UDP数据报中不指定信源主机和信宿主机地址 因为这没有必要 传输层只需识别端口 而不用识别主机 识别主机的工作由互联网层 IP软件 完成 UDP校验和是一个可选域 这是其效率的又一体现 因为计算校验和是很花费时间的 如果应用程序对效率的兴趣远远高于对可靠性的兴趣
16、就可以不选此域 UDP校验和还有一个与众不同的特点 除UDP数据报本身外 它还覆盖一个附加头标 该头标并非UDP数据报的有效成分 称为伪头标 pseudoheader 其格式如图UDP伪头标所示 15 图8 47UDP报文格式 用户数据报协议UDP 0151631 头标 数据区 16 用户数据报协议UDP 其中填充域的目的在于使伪头标为16比特的整数倍 协议域 PROTO 含协议类型码 17代表UDP UDP长度 UDPLENGTH 域含UDP数据报 不包括伪头标 长度 使用伪头标是为了验证UDP数据报是否传到正确的信宿端 UDP数据报信宿端地址包括两部分 信宿主机地址和信宿端口号 UDP数据报本身只包含信宿端口号 由伪头标补充信宿主机地址部分 UDP数据报发送 接收端计算校验和时 均加上伪头标信息 假如接收端发现校验和正确 则在一定程度上说明UDP数据报到达了正确主机上的正确端口 UDP伪头标来自于IP头标 因此在计算UDP校验和之前 UDP首先必须从IP层获取有关信息 换言之 UDP与IP层之间存在一定程度的交互作用 这是对分层原则的违背 但这种违背是出于实际的需要 在原有的分层
