1 / 68

第九章 传输控制协议 (TCP)

第九章 传输控制协议 (TCP). Application layer. Transport layer. TCP. UDP. Network layer. §9-1 引言. TCP. Transmission Control Protocol TCP 叫做 面向连接的 、 可靠的 传输协议。 它给服务增加了面向连接和可靠性的特点。. 进程 ( 运行的应用程序 ). 进程 ( 运行的应用程序 ). Internet. IP 协议的作用范围.

cullen-tanner
Download Presentation

第九章 传输控制协议 (TCP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 第九章 传输控制协议(TCP)

  2. Application layer Transport layer TCP UDP Network layer §9-1 引言 TCP • Transmission Control Protocol • TCP叫做面向连接的、可靠的传输协议。 • 它给服务增加了面向连接和可靠性的特点。

  3. 进程 (运行的应用程序) 进程 (运行的应用程序) Internet IP 协议的作用范围 TCP协议的作用范围 进程到进程的通信

  4. TELNET 客户 TELNET 服务器 64295 23 TCP TCP 端口号 与UDP一样，TCP也是服务器使用熟知端口号，客户程序使用短暂端口号。

  5. 80 16250 Port: 80 202.115.12.6 202.115.12.34 Endpoint: (202.115.12.6, 80) Connection: (202.115.12.6, 80) and (202.115.12.34, 16250) 端口、端点、连接

  6. TCP使用的熟知端口号

  7. IP 地址 端口号 200.23.56.8 69 69 200.23.56.8 Socket 地址 Socket 地址 • TCP 需要两个标识符：IP地址和端口号。它们各用在一端以建立一条连接。 • 一个IP地址与一个端口号合起来就叫做Socket地址。 • 要使用TCP的服务，我们需要一对Socket地址：客户Socket地址和服务器Socket地址。

  8. §9-2 TCP的服务 流式数据服务 TCP 服务 全双工服务 可靠服务

  9. 流式数据服务 • 流式服务: • 发送TCP从发送应用程序接收到字符流，从这个流中提取适当的长度创建为叫做报文段的分组，然后将它们发送到网络上。 • 接收TCP则接收报文段，从中提取数据，若它们没有按序到达还要将它们排序，并将它们作为字符流交付给接收应用程序。

  10. 全双工服务 数据 确认 数据可在同一时间双向流动 捎带：确认可随数据一起发送

  11. 20~60 bytes §9-3 TCP报文段

  12. 对各字段的说明： • 源端口地址：是一个16位字段。定义了在主机中发送该报文段的应用程序的端口号。 • 目的端口地址：是一个16位字段。定义了在主机中接收该报文段的应用程序的端口号。 • 序号：是一个32位字段。它定义了一个数，指派给本报文段数据的第一个字节。为了保证连通性，要发送的每一个字节都要编上号。序号告诉目的地，这个序列中的哪一个字节是报文段中的第一个字节。 • 确认号：是一个32位字段。定义了源进程期望从对方接收的报文段的序号。确认可捎带和数据一起发送。 • 首部长度：是一个4位字段。指出TCP首部共有多少个4字节字。 • 保留：是一个6位字段。保留为今后使用。

  13. URG:紧急指针（urgent pointer）有效 ACK:确认序号有效。 PSH:接收方应该尽快将这个报文段交给应用层。 RST:重建连接。 SYN:同步序号用来发起一个连接。FIN:发端完成发送任务。 URG ACK PSH RST SYN FIN 控制：是一个6位字段。定义了6种不同的控制位或标志。 这些比特用在TCP的流控制、连接建立和中止以及数据传送的方式等方面。

  14. 对各字段的说明（续）： • 窗口大小：是一个16位字段。定义对方必须维持的窗口大小（以字节为单位）。最大长度为65535字节。 • 检验和：是一个16位字段。 • 紧急指针：是一个16位字段。只有当紧急标志置位时，这个字段才有效。这时的报文段包括紧急数据。 • 选项：在TCP首部中可以有多达40字节的可选信息。

  15. Data stream Sending Receiving Incising Sending buffer Receiving buffer Recovering Segment 流、分组和序号： 分组的序号是这样一个数，它指派给本报文段数据的第一个字节。

  16. 无操作 选项结束 单字节 多字节 选 项 最大报文段长度 窗口扩大因子 时间戳 §9-4 选项 TCP首部可以有多达40个字节的可选信息。它们用来将附加信息传递给目的站，或用来将其他选项对齐。

  17. 选项 选项结束 数据 选项说明： • 无操作：是一个一字节选项。用作选项之间的填充。 • 选项结束：也是一个1字节选项，用于选项字段结束时的填充。但它只能用作最后一个选项。在此选项之后，接收器就寻找有效载荷数据。

  18. 代码：2 长度：4 最大报文段长度 1字节 1字节 2字节 选项说明（续）： • 最大报文段长度：这个选项定义可以被目的站接收的TCP报文段的最长数据块（即数据的最大长度）。 • 最大数据长度是在连接建立阶段确立的，这个大小是由报文段的目的站而不是源站确定的。 • 这个选项仅在进行连接的报文段中使用。它不能用于数据传送中的报文段。 • 下图为这个选项的格式：

  19. 代码：3 长度：3 扩大因子 1字节 1字节 1字节 选项说明（续）： • 窗口扩大因子：这个选项定义了滑动窗口的大小。为了增大窗口大小，就要使用窗口扩大因子。 • 新的窗口大小可以这样求出，即先计算2的n次方，这里n是窗口扩大因子，再将得出的结果乘以首部中的窗口大小： 新的窗口大小=首部中定义的窗口大小×2窗口扩大因子 • 窗口扩大因子只能在连接建立阶段确定。在数据传送阶段，窗口大小可以改变，但它必须乘以同样的扩大因子。 • 下图为这个选项的格式：

  20. 代码：8 长度:10 时间戳值 时间戳回送回答 选项说明（续）： • 时间戳：这是一个10字节字段。该字段由报文段离开的源站填入。目的站接收报文段并存储该时间戳。 • 当目的站发送对该报文段的字节的确认时，就输入前面在回送回答字段中存储的值。 • 当源站收到确认时，就将当前时间与该数值进行检查，差值就是往返时间。 • 下图为这个选项的格式：

  21. 伪首部 32位源IP地址 32位目的IP地址 全0 协议 (6) 总长度 源端口地址 目的端口地址 首 部 序号 确认序号 首部长度 保留 控制 窗口大小 检验和 紧急指针 数据和选项 （必须进行填充使数据是16位的倍数） §9-5 检验和

  22. TCP需要解决的一些问题： • 传输时延长； • 丢失，重复，失序或受到损伤； • 无法预知的传输时延； • 网络拥塞； Flow control Error control Connection control Congestion control

  23. Sender Receiver How fast could I send my data to ensure not to overwhelm him? §9-6 流控制 流控制 定义了在收到从目的站发来的确认之前源站可以发送的数据量。 滑动窗口 是TCP使用的流控制解决办法。

  24. transmission Data Idle time acknowledgment Idle time 停止等待协议 上图中的简单停止等待协议是一个非常缓慢的过程。 若数据要走很长的距离，源站就要在等待确认时一直处在空闲状态。

  25. Sliding window Sliding window 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Before sliding After sliding 滑动窗口 • 这是一个流控制协议； • 两个主机为每一个连接各使用一个窗口； • 窗口覆盖了缓存的一部分，这部分就是主机可以发送而不必考虑从另一个主机发来的确认； • 这个窗口叫滑动窗口，因为当接收端对安全、完整地接收到的字节发送确认时，这个窗口能够在缓存上滑动。

  26. 已被发送的字节 滑动窗口 不能发送的字节 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 已确认的字节 可以发送的字节 指针 带指针的滑动窗口 TCP 使用可变大小的窗口。窗口可增大也可减小，取决于目的站的通知。

  27. 发送端窗口 • 窗口大小与确认号有关。 • 高层协议可以一次发送一个或多个字节到TCP。 • Sent but not acknowledged:等待确认或重传。 Can not be sent now Acknowledged Data waiting for sending Sent but not acknowledged

  28. 接收端窗口 • 由序号确定要再排列的接收数据流。 • 高层协议可以一次从TCP接收一个或多个字节。 Fragmentary Submitted Rearranged but not submitted Unused buffer

  29. 可变大小窗口 • 发送端窗口大小能够动态的改变 • 接收端宣布现在能使用的接收端缓存大小. • 发送端调整窗口大小以适应这个值. • 最小的报文段大小为:1字节. • 接收端宣布:我的缓存大小为0 • 发送端停止发送数据. • 以下情况开始重新发送: • 宣布的缓存大小大于0 • 实验发送:防止死锁 • 带外数据

  30. 确认表示对此序号以前的数据都确认 确认累积 x x+7 x+23 确认与重传 规则: • 发送序号是发送数据流的第一个字节。 • 确认序号指出了接收方期望收到的下一个字节的序号。 • 数据没有得到确认时，若超时了就必须重传。

  31. Sender Receiver Segment 1 Buffer Seq: 1001, 4000B 4000 Ack: 5001, Win: 0 1000 3000 Ack: 5001, Win: 1000 Segment 2 Seq: 5001, 1000B 窗口管理 由接收端宣布的窗口大小通常就是接收端的缓存剩下的空间。

  32. 对滑动窗口的几点说明： • 使用滑动窗口可使传输更加有效，同时也可以控制数据流，使得目的站不致因数据来的过多而瘫痪。 • TCP的滑动窗口是面向字节的。 • 源站不一定要发送出整个窗口大小的数据。 • 窗口大小可由目的站将其增大或减小。 • 目的站可在任何时候发送确认。

  33. 糊涂窗口综合症 什么是糊涂窗口综合症？ 如何导致的？ 怎么解决？ 网络上有很多短报文段 发送应用程序产生数据很慢，或者接收应用程序吸收数据很慢，或者两者都有。

  34. 时间过长： 会产生太大的延迟 不够长：又会继续产生短报文 等待： （一）发送端解决办法 发送端的TCP可能产生糊涂窗口综合症，如果它为产生数据很慢的应用程序服务。 Nagle算法： • 发送端的TCP将它从发送应用程序收到的第一块数据发送出去，哪怕只有一个字节。 • 发送第一个报文段后，发送端的TCP就在输出缓存中积累数据并等待：或者收到接收端的TCP发送出一个确认，或者数据已累积到可以装成一个最大的报文段，就将其发送。

  35. （二）接收端解决办法 接受端的TCP可能产生糊涂窗口综合症，如果它为消耗数据很慢的应用程序服务。 ① Clark解决方法： • 只要有数据到达就发送确认； • 但宣布的窗口大小为零，直到缓存空间已能放入具有最大长度的报文段，或者缓存空间的一半已经空了。

  36. （二）接收端解决办法（续） ② 推迟确认： • 这是另一种解决接收端产生糊涂窗口综合症的方法。 • 当一个报文段到达时，并不立即发送确认。 • 接收端在确认收到的报文段之前一直等待，直到输入缓存有足够的空间为止。 • 接收端不需要确认每一个报文段。这样可以减少通信量。 • 缺点是：延迟的确认可能迫使发送端重传其未被确认的报文段。 • 目前规定确认的延迟不能超过500毫秒。

  37. 一个应用程序依靠TCP进行可靠的传输 差错控制 可靠性 按序的、没有差错的、没有丢失和重复的 差错检测、差错纠正 受到损伤的、丢失的、失序的、重复的报文段 §9-7 差错控制

  38. 三种简单工具： • 检验和 • 确认 • 超时 差错检测和纠正 在TCP中不使用否认 若一个报文段在超时截止期之前未被确认，则被认为是受到损伤或已丢失，需要进行重传。

  39. Sender Receiver Segment 1 Seq: 1201, 200bytes Segment 2 Seq: 1401, 200bytes Segment 3 Ack: 1601 Seq: 1601, 200bytes 报文段3受损伤 OK OK Segment 3, retransmitted 超时 Seq: 1601, 200bytes Ack: 1801 OK Time Time 受损伤的报文段

  40. Sender Receiver Segment 1 Seq: 1201, 200bytes Segment 2 Seq: 1401, 200bytes Segment 3 Ack: 1601 Seq: 1601, 200bytes OK OK 报文段 3 丢失 Segment 3, retransmitted 超时 Seq: 1601, 200bytes Ack: 1801 OK Time Time 丢失的报文段

  41. 重复的报文段 产生原因： 可由源TCP产生：当超时截止期到而确认还没有收到。 解决办法： • 目的TCP期望收到连续的字节流 • 当含有同样序号的分组作为另一个收到的报文段到达时，目的TCP只要丢弃这个分组就可。

  42. 失序的报文段 产生原因： TCP 使用IP的服务，而IP是一个不可靠的无连接的网络层协议。 解决办法： • TCP 对失序的报文段不确认，直到收到所有它以前的报文段为止。 • 若确认晚到了，源TCP的失序的报文段的计时器会到期而重新发送该报文段。 • 而目的TCP就丢弃重复的报文段。

  43. Sender Receiver Segment 1 Seq: 1201, 200bytes Segment 2 Seq: 1401, 200bytes Segment 3 Ack: 1601 Seq: 1601, 200bytes Ack: 1801 OK OK OK 确认丢失 Time Time 丢失的确认

  44. 计时器 重 传 时间等待 坚 持 保 活 §9-8 TCP的计时器

  45. （一）重传计时器 为了控制丢失的或丢弃的报文段，TCP使用处理重传时间（即对报文段的确认的等待时间）的重传计时器。 当TCP发送报文段时，它就创建该特定报文段的重传计时器： 若在计时器截止时间到之前收到了对此特定报文段的确认 撤销此计时器 若在收到了对此特定报文段的确认之前计时器截止期到 重传此报文，并将计时器复位。

  46. 不同的连接，重传时间是不同的 固定时间： 同一个连接，重传时间也不是固定的。 对每一个连接动态更改 动态算法： 动态估算往返时间 (RTT) 关键：如何精确估算RTT 重传时间的计算： 重传时间= 2×RTT

  47. RTT的计算： RTT:往返时间 • 使用时间戳选项； • 发送一个报文段，启动计时器，然后等待其确认。 当前的RTT = 收到确认的时间 – 发送报文段的时间 用在计算重传时间的RTT值是RTT的更新值： RTT = α ×前面的RTT+ (1- α) ×当前的RTT α通常取90%

  48. 是从原始报文段发送的时间开始算？ 具有二义性： 还是从重传的报文段的发送时间开始算？ 估算 RTT 时的问题： 假设： 一个报文段在重传期间未被确认—— • 这个报文段又被重传； • 当发送端TCP收到对此报文段的确认时，它无法知道该确认是对原来的报文段的确认，还是对重传的报文段的确认。 考虑： 在这种情况下，该如何估算 RTT?

  49. Karn算法： • 在计算新的RTT时，不考虑重传报文段的RTT； • 不要更新 RTT， 除非你发送了一个报文段并在不需要重传时收到了确认。 Karn算法要求发送方使用定时器补偿策略把超时重传的影响估计在内。

  50. 发送确认并 宣布一个非零的窗口 丢失 （二）坚持计时器 为了对付零窗口大小通知，TCP需要另一个计时器：坚持计时器。 Deadlock! Sender Receiver Window: 0 等待接收方发送确认来通知窗口的大小。 等待发送端的TCP发送更多的报文段。 要打开这个死锁，TCP为每个连接使用一个坚持计时器。

More Related