TCP使用三次握手协议来建立连接.ppt_第1页
TCP使用三次握手协议来建立连接.ppt_第2页
TCP使用三次握手协议来建立连接.ppt_第3页
TCP使用三次握手协议来建立连接.ppt_第4页
TCP使用三次握手协议来建立连接.ppt_第5页
已阅读5页,还剩21页未读 继续免费阅读

下载本文档

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

文档简介

第5章传输层 TCP使用三次握手协议来建立连接 设甲乙双方发送报文的初始序号分别为X和Y 甲方发送 SYN 1 SEQ X 的报文交给乙方 乙方接收报文后发送 SYN 1 SEQ Y ACKX 1 的报文给甲方 然后甲方发送一个确认报文给乙方方便建立了连接 TCP是一个面向连接的协议 它提供连接的功能是 全双工 的 采用 超时重传和确认 技术来实现可靠数据流的传送 为了提高效率 又引入了滑动窗口协议 协议规定重传 未被确认 的分组 这种分组的数量最多可以 等于滑动窗口的大小 TCP协议采用滑动窗口协议解决了 端到端的流量控制 在一次TCP连接中 如果某方要关闭连接 则应该发出 FIN 这时应答方则应该在收到该报文后 在对该报文进行肯定确认后 应该收到应用程序通知后再发送关闭连接报文 TCP和UDP都是传输层协议 其服务访问点是 1 通常用数字来表示 1 而为了使得通用网络应用的服务访问点兼容 为其提供了一系列保留端口 对于其范围的表述正确的是 2 1 A MAC地址B IP地址C 端口地址D 进程号 2 A 1 255B 1 1023C 1 1024D 1 65535 由于IP地址通常是针对一台主机而言的 而在网络应用中 一台主机通常会有多个应用程序在使用 因此为了区分不同的应用程序 就引入了 端口 的概念 端口是传输层的服务访问点 而在TCP UDP 合法的端口地址的范围是 1 65535 下面是关于源端口地址和目标端口地址的描述中 正确的是 A 在TCP UDP报文中 源端口地址和目标端口地址是不能相同的B 在TCP UDP报文中 源端口地址和目标端口地址是可以相同的 用来表示发回自己的数据C 在TCP UDP报文中 源端口地址和目标端口地址是可以相同的 因为虽然端口地址一样 但其所在的主机是不同的D 以上描述均不正确 TCP协议中使用的流量控制机制称为 1 协议规定重传丢失的分组 这种分组的数量最多可以是 2 1 A 固定大小的滑动窗口协议B 可变大小的滑动窗口协议C 后退N帧的ARQ协议D 选择重发ARQ协议 2 A 是任意的B 1个C 大于滑动窗口的大小D 等于滑动窗口的大小 在建立TCP连接时 首先由发起方发出 1 序号 X 当应答方接收到这个报文之后 就将回应 2 1 A SYN 1B SYN 0C FIN 1D FIN 0 2 A 序号 Y ACKXB 序号 Y ACKX 1C SYN 1 序号 Y ACKX 1D SYN 0 序号 Y ACKX 1 经过TCP的三次握手后 而TCP的状态应该是 1 而在关闭了一个连接之后就将进入 2 状态 并当停留时间达到最长报文段寿命的两倍时 将删除这个连接的记录 1 A CLOSEDB LISTENC ESTABLISHEDD SYNSENT 2 A CLOSEDB FINWAIT 1C FINWAIT 2D TIME WAIT TCP协议发送窗口 接收端口和拥塞窗口三者之间的关系是 B A 发送窗口上限值 MAX 接收窗口 拥塞窗口 B 发送窗口上限值 MIN 接收窗口 拥塞窗口 C 接收端窗口上限值 MAX 发送窗口 拥塞窗口 D 接收端窗口上限值 MIN 发送窗口 拥塞窗口 在TCP IP协议簇中 UDP协议工作在 B A 应用层B 传输层C 网络互联层D 网络接口层 为保证数据传输的可靠性 TCP协议采用了对 C 确认的机制 报文段B 分组C 字节D 比特 下列关于TCP和UDP的描述正确的是 C TCP和UDP均是面向连接的 TCP和UDP均是无连接的C TCP是面向连接的 UDP是无连接的D UDP是面向连接的 TCP是无连接的 TCP是一个 1A 协议 为了确保连接的建立和终止都是可靠的 TCP使用了 2C 的方式交换信息 1 A 面向连接的B 面向无连接的 面向服务的D 面向接口的 2 分组交换B 报文交换C 三次握手D N次握手 在TCP协议中 为了使通信不致发生混乱 引入了所谓套接字的概念 这里 套接字由 A 和IP地址两部分组成 A 端口号B 域名C 接口D 物理地址 1 设TCP的ssthresh的初始值是8 单位为报文段 当拥塞窗口上升到12时网络发生了超时 TCP使用慢启动和拥塞避免 试分别求出第1次到第15次传输的各拥塞窗口的大小 拥塞控制实现的具体过程为 1 TCP连接初始化 将拥塞窗口cwnd值置1 2 执行慢启动算法 cwnd按指数规律增长 直到cwnd ssthresh 开始执行拥塞避免算法 cwnd开始按线性规律增长 3 当网络发生拥塞 把ssthresh值更新为拥塞前ssthresh值的一半 cwnd重新设置为1 按步骤 2 执行 依据上述原理 首先拥塞窗口初始值为1 接下来窗口值按指数规律增长 因此随后窗口大小分别为2 4 8 当拥塞窗口cwnd ssthresh时 进入拥塞避免阶段 其窗口大小依次是9 10 11 12 直至上升到12为止发生拥塞 然后 cwnd重新设置为1 ssthresh更新为6 慢启动窗口的大小依次是1 2 4 6 接着进入拥塞避免阶段 窗口大小依次是7 8 9 第1次到第15次传输的各拥塞窗口大小依次为1 2 4 8 9 10 11 12 1 2 4 6 7 8 9 2 试用具体例子说明为什么在运输连接建立时要使用三次握手 说明如果不这样做可能会出现什么情况 我们知道三次握手完成两个重要的功能 既要双方做好发送数据的准备工作 也要允许双方就初始序列号进行协商 这个序列号在握手过程中被发送和确认 现在把3次握手改成只需要2次握手 是有可能发生死锁的 例如 考虑计算机A和B之间的通信 假定B给A发送一个连接请求分组 A收到了这个分组 并发送了确认应答分组 按照2次握手的协定 A认为连接已经成功建立了 可以开始发送数据分组 可是 B在A的应答分组在传输中被丢失的情况下 将不知道A是否已准备好 不知道A建议什么样的序列号 B甚至怀疑A是否收到自己的连接请求分组 在这种情况下 B认为连接还未建立成功 将忽略A发来的任何数据分组 只等待连接确认应答分组 而A在发出的分组超时后 就会重新发送同样的分组 这样就形成了死锁 3 网络允许的最大报文段长度为128字节 序号用8bit表示 报文段在网络中的生存时间为30秒 试求每一条TCP连接所能达到的最高速率 具有相同编号的TCP报文段不应该同时在网络中传输 必须保证 当序列号循环回来重复使用的时候 具有相同序列号的TCP报文段已经从网络中消失 现在存活时间是30秒 那么在30秒的时间内发送的TCP报文段的数目不能多于255个 这样255 128 8 30 8704b s 所以每条TCP连接所能达到的最高速率是8 704kb s 4 给出Nagle算法用于严重拥塞网络潜在的缺点 Nagle算法建议 当数据一次一个字节的来到发送方时 只发送第一个字节 并且缓冲所有其他内容 直到所发出的字节被确认为止 然后在一个TCP报文段中发送所有缓冲的字符 接着又开始缓冲 直到前一个报文段中的所有字节被确认 这样 如果用户输入的速度足够快 而网络又比较慢的话 那么在每个报文段中都可以有相当数量的字符 该算法还允许输入足够的数据以填满半个窗口或一个最大的报文段的情况下发送一个新的分组 在这种运行方式下 尽管用户是以均匀的速度的输入的 而字符却是以突发的方式回显 用户可能敲击了好几个键 而屏幕上什么都没有显示 然后突然地在屏幕上显示出所有已输入的字符 人们可能对此感到恼火 TCP IP协议簇中的TCP和IP协议可对应OSI参考模型中的哪一层 其中TCP协议为了确保连接的建立和终止都是可靠的采用了什么样的信息交换方式 绘制一个简单的示意图说明TCP建立连接的过程 1 由于TCP协议属于传输层协议 所以TCP对应OSI参考模型的传输层 而IP协议属于网络层协议 所以IP协议对应OSI参考模型的网络层 2 为了确保连接的建立和终止都是可靠的 TCP使用三次握手方式 即交换三次消息 SYN消息用来进行创建连接 FIN消息用来关闭一个连接 试述UDP和TCP协议的主要特点及它们的使用场合 UDP是一个简单的面向数据报的传输层协议 应用进程的每个输出操作都产生一个UDP数据报 并组装成一份待发送的IP数据报中发送 UDP提供不可靠 无连接的数据报服务 它把应用程序传给IP层的数据发送出去 但是并不保证它们能到达目的地 因此 UDP通常用于不要求可靠传输的场合 另外也常用于客户机 服务器模式中 TCP协议被用来在一个不可靠的互联网中为应用程序提供可靠的端点间的字节流服务 所有TCP连接都是全双工和点对点的 因而TCP不支持广播和组播的功能 TCP实体间以 段 为单位进

温馨提示

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

评论

0/150

提交评论