- 1、本文档共58页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
第09章TCP协议资料
第九章 TCP协议 协议概述 报文段格式 差错控制 流控和拥塞控制 TCP连接管理 TCP软件设计 引言 高层应用的需求 传输大量的数据,要求可靠的通信服务 自身的可靠性机制弱 底层网络和IP网络是不可靠、无连接投递 TCP 提供通用的、可靠的通信服务 提供统一的数据流投递服务接口 两种通信方式 报文流 Datagram stream 投递单位:报文 可靠性:报文按序接收 连续报文流,报文边界 接收的报文:大小和顺序严格与发送方相同 发送:报文,前后报文不能合并 接收:报文 数据流 Data stream 投递单位:byte 可靠性:byte按序接收 连续字节流、无边界 接收的字节:顺序严格与发送方发送顺序相同 发送:数据块或逐字节,前后可合并 接收:数据块或逐字节 9.1 协议概述 Transmission Control Protocol,TCP RFC 793,传输控制协议 可靠投递服务特点 面向数据流的传输 无结构字节流:没有边界,内容任意 虚电路连接 尽管IP网络是无连接的,但在TCP的端点上,却可看作是面向连接的通信 —— 端到端连接 可靠投递服务特点(续) 有缓冲的传送 —— 提高传输效率 应用进程:使用自己认为适宜的任何大小的数据片(最小1字节) TCP协议软件:根据网络情况选择适当的收发缓冲区(合并/分割) Push:强制滞留数据的发送 全双工服务 TCP可靠性保证 采用面向连接的通信方式 滑动窗口协议,以提高通信性能 捎带确认方式 未使用显示确认,减少报文种类 TCP只有一种报文格式,完成 建立、拆除连接 数据传输 确认、流控、窗口滑动 TCP端口、端点、连接 端口、端点概念与方式与UDP完全一样 连接:TCP上通信双方抽象的虚电路连接 9.2 报文段格式 9.2.1 控制字段 报文类型、流控、连接建立和拆除 9.2.2 数据流、报文段、序号 序号 依据数据流中的字节序号(流序号) 报文序号为报文段中第一个字节的流序号 如:流序号=X,长度=L的报文段 则:报文的序号为X,下一报文序号为X+L 特点 报文的顺序关系 数据流的位置,更便于流的复原 需较大的序号空间(32bit,4Gbyte) 序号不连续,n1n2n3… 9.2.3 紧急指针与带外数据 带外数据(out-of-band data,urgent data) 位于数据字段的开始,例如:ctrl-c 不在数据流中排队,直接递交上层 提供快速传递数据的功能 紧急指针 指向带外数据的最后一个字节 9.2.4 选项 最大报文段长度(MSS,RFC 879) MSS影响网络传输性能 太小:降低网络利用率(报文开销) 太大:降低网络性能(分片降低成功传输概率) 最佳MSS 理论:尽可能长而不分片 实际:不存在 通常:发送端按发送接口的MTU来确定MSS 通信双方用MSS选项进行MSS值的协商 接收方不能处理较长的报文时(如资源有限等) 窗口比例因子 针对高吞吐量和高时延传输介质上的数据传输,增大窗口大小 新窗口大小 = 首部中定义的窗口大小 * 2 比例因子 比例因子的最大值是16 最大窗口大小 = 216 * 216 = 232 窗口大小可在数据传输阶段改变,窗口比例因子只能在连接建立阶段确定 时间戳 用来测量往返时间,动态定义超时时间 9.3 差错控制 TCP的可靠性 按序 无差错 不丢失、不重复 差错控制 检测:校验和、确认、超时 纠正:重传 TCP的确认机制 确认机制 —— 带重传的肯定确认,Positive acknowledgement with retransmission 接收方收到正确的数据后,向源站回送ACK报文 发送方重传错误数据(受损报文、丢失报文) 累计确认 ACK number是接收方希望接收的下一个字节 对ACK number以前的所有字节的确认 超时重传机制 发送方发送数据时启动一个定时器 定时期间,发送方收到确认后,再发送后续数据 定时期满,发送方重传未确认数据 未确认数据 受损或丢失的数据 确认丢失的数据 受损报文的超时重传 丢失报文的超时重传 丢失确认 问题:重复报文段 原因 重传定时器 报文往返时间(Round Trip Time) 解决 接收方根据报文段的序号,丢弃重复报文段 重传定时器 = RTT ? 自适应超时重传算法 不同的连接传输路径“远近”差异,时延随网络流量变化的差异 —— 固定超时时限只能使TCP性能更糟 超时重传报文时,后续的重传报文“再多等一会儿”,这当中也许就收到了确认(考虑时延的不确定性) 关键:精确估计当前的RTT 问题:失序报文段 原因 封装TCP报文段的IP数据报的独立选路,不按序到达 解决 接收方对失序报文段不确认,直到收到所有它以前的报文段为止 若确认晚到,发送方重发失
文档评论(0)