TCP 序列号和确认码.PPT

传输控制协议 TCP – Transport Control Protocol TCP TCP Overview Connection-oriented Reliable data transfer Byte-stream app writes bytes TCP sends segments app reads bytes TCP TCP Segment Structure TCP 序列号和确认码 (I) TCP Seq. #’s and ACKs (II) TCP 伪头部 TCP 选项域 TCP 选项域 TCP TCP连接管理 Connection Establishment 两军问题 结论 这样无限循环下去，两边的蓝军都始终无法确定自己最后发出的电文对方是否已经收到。 没有一种协议能够蓝军能 100% 获胜。 三次握手 TCP Connection Termination 正常的TCP生命周期 TCP State Diagram: Connection Setup State Diagram: Connection Tear-down 复位TCP连接 TCP 交互式与海量数据 交互式数据传输的问题 延迟确认 Nagle算法 TCP 海量数据传输 ? 交互式数据传输 (rlogin, telnet) 主要指不定期的、少量的数据传输. ? 问题1: – 为了少量的数据发送很多的确认. – 解决方法: 延迟确认（尽可能采用捎带应答） ? 问题2: – 传输的报文分段太短, 效率低（报头长（至少20字节），数据短） – 解决方法: Nagle’s 算法（发送方尽量不发送数据含量小的数据段，而是缓存应用层的数据，等到形成一个比较大的段再发送。） ? 可以把确认延迟到 200ms ? 但是: – 连续两个分段到达时，必须发送一个确认 – 收到副本应立即发送确认 ? 延迟确认的理由:一般情况下，200ms 时延内会有用户要发送的数据准备好，这样可以通过数据分段捎带应答。 ? 只在下列情况下发送一个新的数据段： – 数据填满了最大数据段, – 或，数据填满了接收方缓冲区的一半, – 或，所有已传输的数据段都得到了确认 ? 这样，Nagle’规则减少了小段的数量。 ? 实现: 发送一字节，并缓存所有后续字节直到收到确认，然后在一个报文段中发送所有缓冲字节. ? 有时候，算法可能失效。 * 概述 报文格式 连接管理 TCP中的数据传输 流控与阻塞控制 错误控制 (Timer) Full duplex Flow control: keep sender from overrunning receiver Congestion control: keep sender from overrunning network 概述 报文格式 连接管理 TCP中的数据传输 流控与阻塞控制 错误控制 (Timer) √ TCP 首部 20 字节的 固定首部 目 的 端 口 数据 偏移 检 验 和 选 项 （长 度 可 变） 源 端 口 序 号 紧 急 指 针 窗 口 确 认 号 保 留 F I N 32 bit S Y N R S T P S H A C K U R G 比特 0 8 16 24 31 填 充 TCP 数据部分 TCP 首部 TCP 报文段 IP 数据部分 IP 首部 发送在前 source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F S R P A U head len not used Options (variable length) URG: urgent data (generally not used) PSH: push data now (generally not used) RST, SYN, FIN: connection management (reset, setupteardown commands) # bytes rcvr willing to accept ACK: ACK # valid counting by bytes o