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

Presentation on theme: "第九章 传输控制协议 (TCP)."— Presentation transcript:

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

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

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

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

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

6 TCP使用的熟知端口号 Port Protocol Description 7 Echo 将收到的数据报回送到发送器 9 Discard
丢弃任何收到的数据报 11 Users 活跃的用户 13 Daytime 返回日期和时间 17 Quote 返回日期的引用 19 Chargen 返回字符串 20 FTP, Data 文件传送协议（数据连接） 21 FTP, Control 文件传送协议（控制连接） 23 TELNET 终端网络 25 SMTP 简单邮件传送协议 53 DNS 域名服务器 67 BOOTP 引导程序协议 79 Finger 80 HTTP 超文本传送协议 111 RPC 远程过程调用

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

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

9 流式数据服务 流式服务: 发送TCP从发送应用程序接收到字符流，从这个流中提取适当的长度创建为叫做报文段的分组，然后将它们发送到网络上。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

41 重复的报文段 产生原因： 可由源TCP产生：当超时截止期到而确认还没有收到。 解决办法： 目的TCP期望收到连续的字节流

42 失序的报文段 产生原因： 解决办法： TCP 使用IP的服务，而IP是一个不可靠的无连接的网络层协议。

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

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

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

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

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

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

49 Karn算法： 在计算新的RTT时，不考虑重传报文段的RTT； 不要更新 RTT， 除非你发送了一个报文段并在不需要重传时收到了确认。

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

51 坚持计时器的用法： 当发送端的TCP收到一个窗口大小为零的确认时，就启动坚持计时器。
当坚持计时器期限到时，发送端的TCP就发送一个特殊的报文段，称为探测报文段。用来提醒接收端的TCP：确认已丢失，必须重传。 坚持计时器的值设置为重传时间的数值。 若没有收到从接收端来的响应，则需发送另一个探测报文段，并将坚持计时器的值加倍和复位。 发送端继续发送探测报文段，将坚持计时器的值加倍和复位，直到这个值增大到门限值（通常是60秒）为止。 在这以后，发送端每隔60秒就发送一个探测报文段，直到窗口重新打开。

52 （三）保活计时器 保活计时器的用法： 用来防止在两个TCP之间的连接处理长时间空闲。
每当服务器收到客户的信息，就将计时器复位。超时通常设置为2小时。 若服务器过了2小时还没收到客户的信息，它就发送探测报文段。 若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。

53 （四）时间等待计时器 时间等待计时器的用法： 用在连接终止期间。
当TCP关闭一个连接时，它并不认为这个连接马上就真正关闭了。在时间等待期间中，连接还处于一种中间过渡状态。 这就可使重复的FIN报文段（如果有的话）可以到达目的站因而可将其丢弃。 这个计时器的值通常设置为一个报文段的寿命期待值的两倍。

54 面向连接的协议在源站和目的站之间建立一条虚路径。
§9-9 连接 Source Destination 面向连接的协议在源站和目的站之间建立一条虚路径。 属于一个报文的所有报文段都沿着这条虚路径发送。 面向连接的传输是通过两个过程来完成的： 连接建立 连接终止

55 初始序号 初始序号 (ISNs) 在三次握手过程中要传输并获得确认。 ISN 被用来分辨字节在传输的流中的位置。
TCP 不能用1作为每次连接建立时的序号。双方要对各自的初始序号进行协商。

56 连接建立 步骤2和3可以同时进行。 A B 双方在传送数据前，须完成如下工作：
主机A发送报文段宣布他愿意建立连接，报文段包括关于从A到B的通信量的初始化信息。 主机B发送报文段确认A的请求。 主机B发送报文段包括关于从B到A的通信量的初始化信息。 主机A发送报文段确认B的请求。 步骤2和3可以同时进行。

57 连接建立（续） 被动打开：三次握手过程从服务器开始。服务器程序告诉它的TCP，它已准备好接收一个连接。但它自己并不能完成这个连接。

58 三次握手 Client Server Time Data can be sent with the 3rd packet
Segment 1: SYN Seq: 1200, ack: -- Client Server Time Segment 2: SYN+ACK Seq: 4800, ack: 1201 Segment 3: ACK Seq: 1201, ack: 4801 Server waits for a passive open Client requests for an active open Client’s wish to make a connection Server’s ack. and own request Client’s ack. to server’s request Data can be sent with the 3rd packet Procedure starts with server

59 Attack at 0:00 on May 23. How about it?
两军队问题： Attack at 0:00 on May 23. How about it? No problem! Blue army #1 Blue army #2 White army The blues armies want to communicate through an unreliable channel to synchronize their attacks. Does a protocol exist that allows the blue armies to win?

60 One connection : Two directions
连接终止 A B One connection : Two directions 要在两个方向都关闭连接需要如下过程： 主机A发送报文段，宣布它愿意终止连接。 主机B发送报文段对A的请求加以确认。在此之后，一个方向的连接就关闭了，但另一个方向的并没有关闭。 当主机B发完其数据后，就发送报文段，表示它愿意关闭此连接。 主机A确认B的请求。

61 四次握手 Client Server Time Procedure starts with client Segment 1: FIN
Seq: 2500, ack: -- Client Server Time Segment 2: ACK Seq: 7000, ack: 2501 Segment 4: ACK Seq: 2501, ack: 7002 Procedure starts with client Segment 3: FIN Seq: 7001, ack: 2501 Client’s wish to close the connection Server’s ack. to client’s request Client’s ack. to server’s request Server’s wish to close the connection

62 连接复位 以下情况后发生复位： TCP可以请求将一条连接复位。这里的复位表示当前的连接已经被破坏了。
在某一端的TCP请求了一条到并不存在的端口的连接。在另一端的TCP就可以发送报文段，其RST比特置为1以取消该请求。 由于出现了异常情况，某一端的TCP可能愿意将连接异常终止。 某一端的TCP可能发现在另一端的TCP已经空闲了很长的时间。

63 §9-10 状态转换图 State Description CLOSED 没有连接 LISTEN 服务器等待从客户来的呼叫 SYN-SENT
§9-10 状态转换图 State Description CLOSED 没有连接 LISTEN 服务器等待从客户来的呼叫 SYN-SENT 连接请求已发送，等待确认 SYN-RCVD 连接请求已收到 ESTABLISHED 连接已建立 FIN-WAIT-1 应用程序已请求关闭该连接 FIN-WAIT-2 另一端已接受关闭该连接 CLOSING 两端都已决定同时关闭连接 TIME-WAIT 等待已经重传的报文段消失 CLOSE-WAIT 服务器等待应用程序关闭连接 LAST-ACK 服务器等待最后一个确认

64 状态转换图 CLOSED LISTEN ESTABLISHED SYN-RCVD SYN-SENT FIN WAIT-1
CLOSING TIME-WAIT CLOSE WAIT LAST ACK FIN/ACK ACK/-- Close/FIN FIN+ACK/ACK SYN/SYN+ACK (simultaneous open) RST/-- Send/SYN Close/-- Active open/SYN Passive open/-- (Time-out) Time-out/RST Close or time-out/--

65 §9-11 拥塞控制 从发送站发出的分组要经过许多的路由器才能到达最终的目的站。
§9-11 拥塞控制 从发送站发出的分组要经过许多的路由器才能到达最终的目的站。 若路由器接受分组过快，超过它的处理能力，就可能出现拥塞，会使一些分组被丢弃。 拥塞会导致更严重的状态：更多的重传和更多的分组被丢弃，因而产生更严重的拥塞，最后导致整个系统崩溃。 现在的TCP协议包括了这个功能：发送端的窗口大小不仅决定于接收端，而且取决于网络的拥塞状况。 真正的窗口大小 = minimum (接收端通知的窗口大小，拥塞窗口大小)

66 Congestion window size increases exponentially until the threshold
窗口大小增大的策略 After the threshold it is increased one segment for each acknowledgment Congestion window size increases exponentially until the threshold

67 Variation of Sending Window
发送窗口大小变化 发送窗口变化 10 20 30 40 50 60 2 4 6 8 12 14 16 18 22 time 发送窗口 Variation of Sending Window Sending Window Time

68 练习题： 1、TCP在5:30:20发送了一个报文段，它在5:30:25收到确认。若以前的RTT值是4秒，问新的RTT值是多少？重传时间为多少？ 2、一TCP连接使用10000字节的窗口大小，而上一次的确认号是22001。它收到了一个报文段，确认了字节24001，并将窗口大小改变为11000。试用图说明在这之前与之后的窗口情况。