主机A发送报文段-Read.ppt

第九章 传输控制协议(TCP) §9-1 引言 进程到进程的通信 端口号 端口、端点、连接 TCP使用的熟知端口号 Socket 地址 §9-2 TCP的服务 流式数据服务 全双工服务 §9-3 TCP报文段 对各字段的说明： 控制：是一个6位字段。定义了6种不同的控制位或标志。 对各字段的说明（续）： 流、分组和序号： §9-4 选项 选项说明： 选项说明（续）： 选项说明（续）： 选项说明（续）： §9-5 检验和 TCP需要解决的一些问题： §9-6 流控制 停止等待协议 滑动窗口 带指针的滑动窗口 发送端窗口 接收端窗口 可变大小窗口 确认与重传 窗口管理 对滑动窗口的几点说明： 糊涂窗口综合症 （一）发送端解决办法 （二）接收端解决办法 （二）接收端解决办法（续） §9-7 差错控制 差错检测和纠正 受损伤的报文段 丢失的报文段 重复的报文段 失序的报文段 丢失的确认 §9-8 TCP的计时器 （一）重传计时器 重传时间的计算： RTT的计算： 估算 RTT 时的问题： Karn算法： （二）坚持计时器 坚持计时器的用法： （三）保活计时器 （四）时间等待计时器 §9-9 连接 初始序号 连接建立 连接建立（续） 三次握手 两军队问题： 连接终止 四次握手 连接复位 §9-10 状态转换图 状态转换图 §9-11 拥塞控制 窗口大小增大的策略 发送窗口大小变化 练习题： 服务器等待最后一个确认 LAST-ACK 服务器等待应用程序关闭连接 CLOSE-WAIT 等待已经重传的报文段消失 TIME-WAIT 两端都已决定同时关闭连接 CLOSING 另一端已接受关闭该连接 FIN-WAIT-2 应用程序已请求关闭该连接 FIN-WAIT-1 连接已建立 ESTABLISHED 连接请求已收到 SYN-RCVD 连接请求已发送，等待确认 SYN-SENT 服务器等待从客户来的呼叫 LISTEN 没有连接 CLOSED Description State Segment 1 Seq: 1001, 4000B Seq: 5001, 1000B Ack: 5001, Win: 0 Ack: 5001, Win: 1000 4000 1000 3000 Buffer Sender Receiver Segment 2 由接收端宣布的窗口大小通常就是接收端的缓存剩下的空间。 使用滑动窗口可使传输更加有效，同时也可以控制数据流，使得目的站不致因数据来的过多而瘫痪。 TCP的滑动窗口是面向字节的。 源站不一定要发送出整个窗口大小的数据。 窗口大小可由目的站将其增大或减小。 目的站可在任何时候发送确认。 什么是糊涂窗口综合症？ 如何导致的？ 怎么解决？ 网络上有很多短报文段 发送应用程序产生数据很慢，或者接收应用程序吸收数据很慢，或者两者都有。 发送端的TCP可能产生糊涂窗口综合症，如果它为产生数据很慢的应用程序服务。 Nagle算法： 发送端的TCP将它从发送应用程序收到的第一块数据发送出去，哪怕只有一个字节。 发送第一个报文段后，发送端的TCP就在输出缓存中积累数据并等待：或者收到接收端的TCP发送出一个确认，或者数据已累积到可以装成一个最大的报文段，就将其发送。 时间过长： 会产生太大的延迟 不够长：又会继续产生短报文 等待： 接受端的TCP可能产生糊涂窗口综合症，如果它为消耗数据很慢的应用程序服务。 ① Clark解决方法： 只要有数据到达就发送确认； 但宣布的窗口大小为零，直到缓存空间已能放入具有最大长度的报文段，或者缓存空间的一半已经空了。 ② 推迟确认： 这是另一种解决接收端产生糊涂窗口综合症的方法。 当一个报文段到达时，并不立即发送确认。 接收端在确认收到的报文段之前一直等待，直到输入缓存有足够的空间为止。 接收端不需要确认每一个报文段。这样可以减少通信量。 缺点是：延迟的确认可能迫使发送端重传其未被确认的报文段。 目前规定确认的延迟不能超过500毫秒。 可靠性 按序的、没有差错的、没有丢失和重复的 差错控制 差错检测、差错纠正 受到损伤的、丢失的、失序的、重复的报文段 一个应用程序依靠TCP进行可靠的传输 在TCP中不使用否认 若一个报文段在超时截止期之前未被确认，则被认为是受到损伤或已丢失，需要进行重传。 三种简单工具： 检验和 确认 超时 OK Segment 1 Seq: 1201, 200bytes Ack: 1601 Sender Receiver Segment 2 Seq: 1401, 200bytes Segment 3 Seq: 1601, 200bytes Segment 3, retransmitted Seq: 1601, 200bytes A