第7章 传输层协议——TCP与UDP 任课教师 卢豫开.

Presentation on theme: "第7章 传输层协议——TCP与UDP 任课教师 卢豫开."— Presentation transcript:

1 第7章 传输层协议——TCP与UDP 任课教师 卢豫开

2 传输层协议——TCP与UDP 传输层提供了面向连接的传输控制协议（Transmission Control Protocol ,TCP）和无连接的用户数据报协议（User Datagram Protocol ,UDP），将任意数据通过网络从发送方传输到接收方。 TCP提供可靠的、可控的传输服务；UDP提供的服务轻便但不可靠。

3 第7章 传输层协议——TCP与UDP 学 习 要 点

4 7.1 传输层协议概述（P138） 传输层介于网络层与应用层之间。 TCP和UDP协议位于传输层，在TCP/IP协议栈中的位置如图：

5 传输层协议概述 传输层协议的基本功能： 创建进程到进程的通信。进程之间通过传输层进行通信。
提供控制机制，如流量控制（Flow Control）、差错控制。定义端到端用户之间的流量控制。 提供连接机制。在数据传输开始，通信双方需要建立连接；在传输过程中，双方需要继续通过协议进行通信，并验证数据是否被正确接收；数据传输完成后，任一方可以关闭连接。

6 7.1.1 TCP协议（P139） RFC793“TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION”是TCP协议的正式规范文件。 1. TCP协议的特性 面向连接。它向应用程序提供面向连接的服务，两个需要通过TCP进行数据传输的进程之间首先必须建立一个TCP连接，并且在数据传输完成后释放连接。 全双工。只要建立了TCP连接，就能在两个进程之间进行双向的数据传输服务，但是这种传输只是端到端的传输，不支持广播和多播。 可靠。TCP提供流量控制，解决了接收方不能及时处理数据的问题；提供拥塞控制，解决因网络拥堵带来的数据丢失问题；提供差错控制解决数据被破坏、重复、失序和丢失的问题，从而保证数据传输的可靠性。

7 TCP协议 基于字节流。提供面向字节流的服务，两个建立了TCP连接的应用进程之间交换的是字节流。发送进程以字节流形式发送数据，接收进程也把数据作为字节流来接收。在传输层上数据被当做没有信息的字节序列来对待。 2. TCP协议的功能 TCP安全、稳定，但是效率不高，占用资源较多。 TCP的作用是在计算机之间可靠地传输数据。 目前大多数Internet信息交付服务都使用TCP协议，这样便于开发人员专注于服务本身，而不是处理可靠性和数据交付问题。

8 7.1.2 UDP协议（P139） RFC768“User Datagram Protocol”是UDP协议的正式规范文件。
不需要建立连接，因此不存在连接建立的时延。 传输数据不需要维护连接状态，包括收发状态等，这样一台服务器可同时向多个客户端传输相同的数据，可以多播。 UDP数据报首部很短，只有8字节，相对于TCP的20字节首部的开销要小很多。 吞吐量不受流量控制算法的调节，只受应用软件生成数据的速率、传输带宽、信源和信宿主机性能的限制。

9 2. UDP协议的功能 只需要简单数据交换的应用，例如DNS服务，它不需要复杂的可靠性保证机制，这样，利用UDP来传输数据既可以节省系统开销又提高了网络的传输效率。 不需要关心数据的差错控制和流量控制的应用。 实时性要求较高但可承受一定的数据错误的应用，如实时语音传输、视频通信等。 实现一对多数据发送的应用，例如广播和多播。 UDP的可靠性由用户的应用程序来决定。

10 TCP与UDP的区别（P140） TCP UDP 面向连接 无连接 可靠性高 效率高 一次传输大量报文 一次传输少量报文 复杂 简单

11 7.1.3 进程之间的通信（P140） 进程之间通信与主机之间通信 1. 进程标识
为保证数据能够正确地到达指定的目的进程，必须显式地给出全局惟一的目的进程标识符 要全局惟一地标识一个进程，必须采用一个三元组（协议，主机地址，端口号） 两个进程之间的关联用一个五元组（协议，本地主机地址，远程主机地址，本地端口号，远程端口号）

12 进程之间的通信 2. 端口号 端口号是16位（bit）的标识符，因此取值范围是0～65535
端口分配有两种方式，一种是全局端口分配，采用集中控制方式，由权威管理机构针对特定应用程序统一分配；另一种是本地端口分配，由本地操作系统根据请求动态分配。 通常小于1024的端口号用作公认(wellknown)端口号，按全局方式分配，又称为注册端口或保留端口。服务器必须使用公认端口号。 端口范围称为自由端口或动态端口，以本地方式分配，可以临时申请使用。客户端一般采用临时端口号。

13 进程之间的通信 3. 套接字（Socket） 将传输层协议（TCP/UDP）、目的IP地址和端口号3个参数结合起来称为套接字（Socket）。分为面向连接的流式套接字和无连接的数据报套接字。 套接字之间连接过程的三步骤： （1）服务器监听。服务器端套接字处于等待连接的状态，实时监控网络状态。 （2）客户端请求。客户端套接字提出连接请求，要连接的目标是服务器端的套接字。 （3）连接确认。服务器监听到客户端请求，响应，把服务器套接字发送给客户端，客户端确认，连接完成。

14 7.2 TCP段格式（P142） 传输层的TCP数据分组称为报文段。 TCP将来自应用层的数据分块并封装成TCP段进行发送。
TCP段封装在IP数据报中，然后再封装成数据链路层中的帧。 TCP段封装

15 TCP段格式

16 7.1.2 TCP首部格式（P142） TCP组成字段 源端口（Source Port）和目的端口（Destination Port）
序列号（Sequence Number）32bit 确认号（Acknowledgment Number）32bit 首部长度（Header length）4bit，以4为单位，可以在5(5x4=20)到15(15x4=60)之间。回顾P82的IP报的首部长度。 标志（Flags）6bit,定义6种控制或标志，用在TCP的流量控制、连接建立和终止等。 窗口大小（Window size）16bit，指明TCP接收方的缓冲区长度。最大65535字节，当0时发送方应停止发送。 校验和（Checksum）UDP校验和可选，TCP校验和是强制性的。 紧急指针（Urgent Pointer），16bit，指向缓冲区一个偏移量，所指向的一段数据不必等待缓冲区数据积累，直接发送。 选项（Options），最大40字节。

17 TCP标志（P143） 标志 含义 URG 表示紧急指针是否有效。值为1时表示紧急指针有效，有高优先级的信息需要传输 ACK
表示确认号是否合法。值为1表示合法，值为0时表示段中不包含确认信息，确认号被忽略 PSH 推送数据，一旦接收到PSH值为1（带有Push标志位）的报文段，接收方必须不缓存数据，将数据直接传递给应用层协议，而不必等到缓冲区满时才传送 RST 对连接进行复位，用于复位因某种原因引起出现的错误连接（完全关闭），也用于拒绝非法数据和请求。值为1时表示请求重新连接，通常是发生了某些错误 SYN 在连接建立时对序列号进行同步。当建立一个新的连接时，SYN值变为1。在连接请求（Connection Request）中，SYN=1，ACK=0；连接响应（Connection Accepted）时，SYN=1，ACK= 1 FIN 终止连接（当然它本身并不终止连接），值为1时表示释放连接，表明发送方已经没有数据发送了

18 7.22 选项（P144） 1. 选项列表结束（EOP） 在选项列表末尾，只能用一次，表示首部已经没有更多的选项，这个选项之后就是有效载荷(来自应用层的数据) 2.无操作（NOP） 用作选项之间的填充。

19 选项 3.最大段长度（Maximum Segment Size，MSS）
定义接收方可以接收的TCP数据的最大长度，而不是报文最大长度。MSS值在0到65535字节，默认值为536字节。 注意： 不要混淆MSS和MTU。MTU是数据链路层能够放在以太帧中的数据长度，Ethernet II的MTU是1500字节（见P32　Ethernet II帧格式和P88 MTU）。MSS是能够放在TCP首部后面的数据长度，对于Ethernet II是 =1460字节。

20 选项 4.窗口扩大因子（Window Scale）
TCP的窗口大小（ Window size ）定义了滑动窗口值，范围是0~65535字节。当通信双方需要扩大窗口，在连接开始时就可以使用这个窗口扩大因子来定义更大的窗口。 新的窗口大小=首部定义的窗口大小x2窗口扩大因子 TCP/IP所容许的窗口扩大因子最大值是14，这就表示滑动窗口的最大窗口值可以是216x214=230

21 选项 5.时间戳（Timestamp） 时间戳（Timestamp）和时间戳回送应答（Timestamp Echo Reply）
时间戳的一个功能是测量往返时间。发送端填写时间戳，接收端在发送确认报文时将收到的时间戳COPY到时间戳应答字段，原发送端收到这个确认后就可以计算出往返时间。 时间戳另一个功能是防止序列号绕回。因为序列号只有32位，在高速连接中可能发生绕回而造成重复同一个值，因此用时间戳和序列号的组合来标识一个报文段。

22 7.2.3 验证分析TCP段格式（P145）

23

24 7.3 TCP连接（P146） IP是无连接协议，而TCP是面向连接的协议。
TCP用IP的服务把单个的报文段交付给接收方，但是TCP控制这个连接，在源节点到目的节点之间建立一条虚通道，属于同一个报文的所有TCP段都从这个虚通道传送。 发送数据之前，必须在双方之间建立一条连接。 　　通常是建立一条客户端到服务器的TCP连接,连接建立后，双方通过连接通道进行数据传输。

25 7.3.1　TCP连接建立（P146） 1. 三次握手建立连接 为了避免重复连接，在建立TCP连接时采用三次握手（Three-way Handshak），整个连接过程分为3步。 ACK=0 SYN=1 SYN=1 SYN=0

26 TCP连接建立 （1）客户端（源主机）向服务器（目的主机）发送TCP连接请求(SYN段)，标志ACK=0, SYN=1；序列号是客户端初始序列号。目的端口号是服务器端口号。 （2）服务器在指定端口等待连接，收到TCP连接请求后，回应1个TCP连接应答(SYC/ACK段)，标志ACK=1, SYN=1；序列号是服务器初始序列号；确认序列号是客户端初始序列号加1。目的端口号是客户端源端口号。 （3）客户端收到服务器的应答，再向服务器发送1个TCP连接确认(ACK段)，标志ACK=1，SYN=0；序列号是客户端初始序列号加1,；确认序列号是服务器初始序列号加1。 经过以上三次握手后，TCP连接正式建立，双方交换并确认了对方的初始序列号，可以通过连接相互传输数据了。

27 TCP连接建立 2. 验证分析三次握手建立连接 以1个客户端浏览器访问Web服务器为例，抓取TCP连接建立三次握手过程中的3个数据包。

28 验证分析三次握手建立连接 TCP连接建立第1次握手过程中的数据包分析

29 验证分析三次握手建立连接 TCP连接建立第2次握手过程中的数据包分析

30 验证分析三次握手建立连接 TCP连接建立第3次握手过程中的数据包分析

31 三次握手第1次

32 三次握手第2次

33 三次握手第3次

34 TCP段格式 0 0 0 0 0 0 三次握手第1次 ACK=0 SYN=1 第48字节是0x02 HLEN的值单位为4 包头长=HLEN
的值×4 三次握手第2次 ACK=1 SYN=1 第48字节是0x12 三次握手第3次 ACK=1 SYN=0 第48字节是0x10

35 TCP连接建立 3. 半开连接 P149 服务器收到SYN请求后，在发送SYN/ACK给客户端之前，服务器要分配一个数据区以服务于这个即将形成的TCP连接。 一般将收到SYN而还未收到客户端的ACK时的连接状态称为半开连接（Half-open Connection）或半打开连接 半开连接通信序列按以下顺序发生： 客户端 SYN>>>>> 服务器 客户端 <<<<<ACK SYN 服务器 …… 可能是客户端出现故障，服务器不断发送SYN/ACK，试图完成握手过程，大量消耗服务器资源。

36 7.3.2 TCP数据传输（P149） TCP建立连接后，双向的数据传输就可以进行了。 1.数据传输过程 客户端向服务器发送数据报文
服务器收到后会回复一个带有ACK的确认报文 客户端收到确认报文后知道数据已经成功发送，否则会重发。 客户端与服务器都可以在两个方向上进行数据传输与确认。 TCP并不是每发送1段报文就确认1次，通常是连续发送几段，然后等待回应；再发送几段，再等待回应。每次发送多少段，由双方协调。

37 TCP数据传输 数据传输过程 TCP数据传输过程中数据包列表

38 服务器发送几段报文客户端响应1次

39 TCP数据传输----数据传输过程 数据可以双向传输，在同一个报文段中可以携带确认，即确认是由数据捎带上的。 TCP数据传输过程示意图

40 TCP数据传输 2. 推送数据 通常TCP向应用程序延迟传送和延迟交付数据以提高效率。
希望对方立即收到就不能采用这种延迟方式，而需要发送方应用程序请求推送（PUSH）操作。 发送方TCP设置推送标志（PSH）以告诉接收方TCP该报文段所包括的数据必须尽快地交付给接收应用程序，而不要等待更多的数据的到来。 TCP可以选择是否使用推送操作。

41 TCP数据传输 3. 紧急数据传输 某些情况下应用程序需要发送紧急数据，希望接收应用程序不按顺序依次读出，这可发送带有URG标志的报文来实现。 方法是发送应用程序通知发送方TCP某些数据需要紧急发送。 发送方TCP创建报文段，并将紧急数据放在报文段的开头，其余部分可以是来自缓冲区的正常数据。 TCP首部中的紧急指针字段定义了紧急数据的结束和正常数据的开始位置。 当接收方TCP收到URG置位的报文段时，它就利用紧急指针的值从报文段中提取出紧急数据，优先交付给接收应用程序。

42 建立TCP连接之后，可以保持连接以避免每次发送数据都需要重复执行握手过程。这样，即使没有数据在TCP链路上传输，仍旧能够维持连接。
7.3.3 TCP连接保持（P151） 建立TCP连接之后，可以保持连接以避免每次发送数据都需要重复执行握手过程。这样，即使没有数据在TCP链路上传输，仍旧能够维持连接。 通常应用层可以实现连接保持，如FTP或telnet。 如果应用程序不能保持连接，则可以由服务器进程发起TCP保持连接。 默认情况下，Windows操作系统关闭了TCP连接保持功能。

43 7.3.4 TCP连接关闭（P151） 1. 四次握手关闭连接 终止1个连接需要经过4次握手。这是由TCP的半关闭造成的。
由于1个TCP连接是全双工的，因此每个方向要单独关闭。当一方完成数据发送任务就可发送1个FIN段（应用层关闭连接要求TCP发送FIN）来终止这个方向的连接。 当一方收到1个FIN段，就告知应用层，对方已经终止，此时它自己仍能向对方发送数据。 首先关闭的一方执行主动关闭，另一方执行被动关闭。

44 TCP连接关闭 TCP四次握手关闭连接 P151 Flags=00010001 Flags=00010000 Flags=00010001
客户端 服务器 主 动 关 闭 第1次握手: 序列号＝m, 确认号＝n, ACK=1, FIN=1 Flags= 第2次握手: 序列号＝n, 确认号＝m+1, ACK=1, FIN=0 Flags= 被 动 关 闭 Flags= 第3次握手: 序列号＝n, 确认号＝m+1, ACK=1, FIN=1 Flags= 第4次握手: 序列号＝m+1, 确认号＝n+1, ACK=1, FIN=0

45 TCP连接关闭 2. 验证分析四次握手关闭连接 TCP连接关闭四次握手过程中的数据包（telnet）

46 TCP连接关闭 验证分析四次握手关闭连接 TCP连接关闭第1次握手过程中的数据包分析

47 TCP连接关闭 验证分析四次握手关闭连接 TCP连接关闭第2次握手过程中的数据包分析

48 TCP连接关闭 验证分析四次握手关闭连接 TCP连接关闭第3次握手过程中的数据包分析

49 TCP连接关闭 验证分析四次握手关闭连接 TCP连接关闭第4次握手过程中的数据包分析

50 TCP连接关闭四次握手过程中的数据包（FTP）

51 TCP连接关闭四次握手（FTP）----第1次握手

52 TCP连接关闭四次握手（FTP）----第2次握手

53 TCP连接关闭四次握手（FTP）----第3次握手

54 TCP连接关闭四次握手（FTP）----第4次握手

55 TCP连接关闭 3. 半关闭 （P153） TCP连接的一方结束发送后还能接收另一方的数据，这就是半关闭。
关闭通常由客户端发起，发出FIN半关闭这个连接，服务器发出ACK段接受这个半关闭，但是此时服务器仍能够发送数据给客户端，且客户端虽然不能发送数据却仍能够回应ACK。 待服务器把所有处理的数据都发送完，就发出FIN段，关闭余下的半个连接，客户端回应ACK后最终完全关闭连接。

56 TCP连接关闭 TCP连接半关闭的过程 客户端 服务器 序列号＝m, 确认号＝n, ACK=1, FIN=1 主 动 关 闭
序列号＝n, 确认号＝m+1, ACK=1, FIN=0 数据 对数据的确认 被 动 关 闭 序列号＝x, 确认号＝m+1, ACK=1, FIN=1 序列号＝m+1, 确认号＝x+1, ACK=1, FIN=1

57 可以使用RST标志来非正常关闭连接。TCP首部中的RST是用于复位的，主要用于快速结束连接。
7.3.5 TCP连接复位（P154） 可以使用RST标志来非正常关闭连接。TCP首部中的RST是用于复位的，主要用于快速结束连接。 TCP连接复位有以下几种几种情形 1. 拒绝连接请求 当一方TCP向另一方发出连接请求，而接收方的端口没打开或没有监听，接收方可以发送RST段来取消这个请求。 2. 异常关闭连接 关闭连接的正常方式是发送FIN段，当出现异常情况，一方可发送RST段来关闭这个连接。

58 TCP连接复位 3. 终止空闲的连接 一方TCP发现另一方TCP已经空闲很长时间，就可以发送RST段来撤销这个连接。与异常关闭连接一样。

59 7.3.6 传输控制块（TCB）（P155） 为了控制连接，TCP使用一种称为传输控制块（Transmission Control Block，TCB）的结构来保持每一条连接的有关信息。 任何时候都可能有好几个连接，TCP就以表的形式存储TCB数组。 每一个TCB都包括许多字段。例如“状态”字段指定连接状态；“进程”字段定义在主机上使用这个连接的进程（作为客户端或服务器）；常用的字段还有本地IP地址、本地端口、远程IP地址、远程端口、接口、本地窗口、远程窗口、发送序列号、接收序列号、发送确认号、往返时间、超时值、缓冲区大小、缓冲区指针等。

60 7.3.7 TCP状态转换图（P155） 1. TCP状态 CLOSED：无连接状态。 LISTEN：侦听状态，等待连接请求SYN。
SYN-SENT：已发送连接请求SYN状态，等待确认ACK。 SYN-RCVD：已收到连接请求SYN状态。 ESTABLISHED：已建立连接状态。 FIN-WAIT-1：应用程序要求关闭连接，断开请求FIN已经发出状态。 FIN-WAIT-2：已关闭半连接状态，等待对方关闭另一个半连接。 CLOSING：双方同时决定关闭连接状态。 TIME-WAIT：等待超时状态。 CLSOE-WAIT：等待关闭连接状态，等待来自应用程序的关闭要求。 LAST-ACK：等待关闭确认状态。

61 2. 状态转换图（P156）

62 3. TCP连接全过程 状态转换分析 客户端主动打开请求 连接，服务器被动打 开，经过三次握手， 建立连接。 然后交换数据。
最后经过四次握手断 开连接。

63 7.3.8 TCP连接同时打开与同时关闭（P157） 1. 同时打开TCP连接
双方的应用程序同一时刻都主动打开TCP连接。双方同时向对方发送SYN，但是仅建立一条TCP连接而不是两条。双方既是客户端又是服务器，通信双方对等。

64 2. 同时关闭TCP连接 TCP双方都执行主动关闭。当应用层发出关闭命令，两端均从ESTAELISHED变为FIN-WAIT-1。双方各发送一个FIN段。双方收到FIN后，从FIN-WAIT-1变迁到CLOSING，并发送最后的ACK。

65 7.3.9 序列号与确认号机制（P158） TCP协议使用序列号和确认号来确保传输的可靠性。
序列号和确认号确保了数据适当排序，并防止报文段丢失。 要发送的确认号 = 已收到的序列号 + 已收到数据的字节数

66 在Wireshark抓包结果中禁用相对序列号
在wireshark中点击Edit->Preferences->Protocol->TCP，清除“Relative sequence numbers”

67 服务器开始传输一个报文段 下一个序列号=当前序列号+要传输的数据长度 下一个序列号1519826911=1519825451+1460
确认号为上次对方的序列号加上收到数据的长度

68 服务器传输下一个报文段 下一个序列号=当前序列号+要传输的数据长度 下一个序列号 1519828371=1519826911+1460
连续发送确认号不变

69 客户端发送确认报文段 确认号为收到的对方序列号加上收到的数据长度 序列号为对方的确认号1466272879
确认号为上次对方序列号加上收到数据的长度 =

70 服务器继续发送数据 下一个序列号=当前序列号+要传输的数据长度；确认号为对方的序列号加上收到的数据长度。
序列号为对方确认号 下一个序列号 = 确认号为上次对方序列号加上收到的数据长度

71 客户端发往服务器的确认报文段 TCP段长度0字节，序列号Seq= ， 确认号Ack= 。

72 服务器开始传输一个报文段 下一个序列号=当前序列号+要传输的数据长度 下一个序列号3261539649=3261538209+1440
确认号为上次对方的序列号加上收到数据的长度

73 服务器传输下一个报文段 下一个序列号=当前序列号+要传输的数据长度 下一个序列号 3261541089=3261539649+1440
连续发送确认号不变

74 客户端发送确认报文段 确认号为收到的对方序列号加上收到的数据长度 序列号430935114，是上一个从服务器发给客户端的TCP段的确认号。
确认号为上次对方序列号加上收到数据的长度 = 序列号为对方的确认号

75 服务器继续发送数据 下一个序列号=当前序列号+要传输的数据长度；确认号为对方的序列号加上收到的数据长度。
序列号为对方确认号 下一个序列号 ＝ ＋1440 确认号为上次对方序列号加收到的数据长度 =

76 Relative sequence number

77 清除“Relative sequence number”复选框

78 要发送的确认号＝已收到的序列号+已收到数据的字节数
ACK确认报文不消耗序列号。 连续发送的TCP序列报文段的确认号不变。

79 7.3.10 SYN洪泛攻击及其防范（P161） 1. 直接攻击 攻击者使用未经伪装的IP地址快速地发送SYN包。
这种攻击要想得逞，攻击者还必须阻止其系统响应SYN/ACK。 攻击者可以通过设置防火墙规则阻止一切要到达服务器的数据包（除了SYN），或者阻止一切传入的包来使SYN-ACK包在到达本地TCP处理程序之前就被丢弃了。 非常容易抵御，用一个简单的防火墙规则阻止带有攻击者IP地址的数据包。

80 2. 欺骗式攻击 攻击者用有效的IP和TCP首部去替换和重新生成原始IP报文，并让位于伪装IP地址上的主机必须不能响应任何发送给它们的SYN/ACK包。 攻击者有两种方法欺骗，一种是仅伪装一个源IP地址，另一种是伪装许多源地址，让伪装地址上的主机不会响应SYN-ACK包。 最好的防御方法就是尽可能地阻塞源地址相近的欺骗数据包。

81 3. 分布式攻击 攻击者运用在网络中主机数量上的优势而发动的分布式SYN洪泛攻击将更加难以被阻止。主机群可以用直接攻击，也可以更进一步让每台主机都运用欺骗攻击。 要阻止这类攻击目前还是一个挑战。

82 7.4 TCP可靠性（P161） TCP采用的可靠性技术主要包括差错控制、流量控制和拥塞控制。 7.4.1 TCP差错控制
2. 确认----TCP采用确认来证实收到了报文段。ACK的确认机制最常用的规则有以下几种： (1)ACK报文段不需要确认，也不消耗序列号。 (2)发送数据时捎带确认，给出对方所期望接收的下一个序列号，以减少通信量。 (3)当收到的序列号比期望的序列号大，立即发送ACK报文段，让对方快速重传丢失的报文段。

83 TCP差错控制 (4)当收到丢失的报文段，立即发送ACK报文段，告知对方已经收到了丢失的报文段。
3. 重传----当1个报文段损坏、丢失或被延迟了，就要重传。(1)超时重传：为每一个发送的TCP报文段设置1个超时重传（Retransmission Time Out, RTO）计时器，计时器时间一到，就可认为该报文段损坏或丢失，需要重传。 　(2)快重传：当1个报文段丢失，会造成很多失序报文到达接收方。接收方以ACK通知发送方，发送方收到3个重复的ACK后立即重传这个丢失的报文段。

84 TCP差错控制 4. 失序报文段的处置 不丢弃那些失序的报文段，而是暂时存储下来，并把它们标志为失序报文段，直到丢失的报文段到达。注意失序的报文段并不交付到进程。TCP保证数据必须按序交付到进程。 5. 重复报文段的处置 接收方根据序列号判断是否是重复报文段，重复报文段只需简单地丢弃即可。 6. 选择确认（SACK） 在一些新的TCP实现中支持选择确认，报告时序和重复报文段，将其作为首部选项的一部分。SACK并不是代替ACK而是向发送方报告附加的信息。

85 7.4.2 TCP流量控制（P163） 1. 滑动窗口机制 发送方窗口。发送方整个缓冲区是左端与右端相连的环。
发送窗口左侧是已经发送并被接收方确认的数据，对应的缓冲区已经释放。 发送窗口中靠左的部分是已经发送但未确认的数据，靠右部分是可以立即发送的数据（当前可用窗口）。 发送窗口右侧是暂时不能发送的数据，一旦发送窗口内的部分数据得到确认，窗口便向右滑动，将已经确认的数据移到窗口左侧，而右边新的数据进入窗口成为可以立即发送的数据。

86 TCP流量控制----滑动窗口机制 接收方窗口。反映当前能够接收的数据的流量，窗口大小取决于接收方处理数据的速度和发送方发送数据的速度。当缓冲区取出数据的速度低于数据进入的速度，接收窗口逐渐缩小，反之逐渐扩大。 接收方将当前窗口大小通告给发送方（用TCP报文段首部中的窗口大小字段），发送方根据接收窗口调整其发送窗口，使发送窗口始终小于或等于接收窗口的大小。 只有在接收窗口滑动时（同时发送确认），发送窗口才有可能滑动。 收发双方的窗口按以上规律不断的向前滑动，这种协议又称为滑动窗口协议。

87 TCP流量控制----滑动窗口机制 TCP的窗口以字节为单位进行调整，以适应接收方的处理能力，处理过程如下： （1）TCP连接阶段，双方协商窗口大小，同时接收方预留数据缓存区； （2）发送方根据协商的结果，发送符合窗口大小的数据字节流，并等待对方的确认； （3）发送方根据确认信息，改变窗口大小，增加或者减少发送未得到确认的字节流中的字节数。如果出现发送拥塞，发送窗口缩小为原来的一半，同时将超时重传的时间间隔扩大一倍。

88 TCP流量控制 2. 发送方产生的糊涂窗口综合症（P164） 如果发送方TCP为生产数据很慢的应用程序服务，就可能产生糊涂窗口综合症。
解决的方法是防止发送方TCP逐个字节地发送数据，强迫发送方TCP等待，凑成大块数据再发送。 为了使TCP等待的时间更为合理，采用了Nagle算法： 1）发送方将来自应用程序的第1块数据发送出去 2）发送方在输出缓冲区积累并等待，直到接到接收方的确认，或已经积累到足够的数据。 3）剩下的数据重复步骤2。

89 TCP流量控制 3. 接收方产生的糊涂窗口综合症 如果接收方TCP为消耗数据很慢的应用程序服务，就可能产生糊涂窗口综合症。 有两种解决方法。
（1）延迟通告（Delayed Advertisement），在缓冲区已经有足够大的空间之前一直宣布窗口值为0。 （2）推迟确认（Delayed Acknowledgement），报文到达时不立即发送确认，直到缓冲区有足够的空间为止。

90 7.4.3 TCP拥塞控制（P165） 拥塞的发生会造成数据丢失，数据丢失又造成超时重传，超时重传进一步加剧拥塞，如果不加以控制，最终会导致系统崩溃。 在拥塞控制机制中，发送方能够发送的数量不仅要接受接收方的控制，还要由网络拥塞程度来决定 RFC2581为TCP定义了4种拥塞控制机制 慢启动（Slow Start） 拥塞避免（Congestion Avoidance） 快重传（Fast Retransmit） 快恢复（Fast Recovery）

91 TCP拥塞控制 1. 拥塞窗口 如果网络上的负载大于网络的容量，也即发送的数据包数大于网络能够处理的数据包数，在网络中就可能发生拥塞。
发送窗口的大小取决于两个因素：1）接收窗口----接收方的缓冲区 2）拥塞窗口----网络的处理能力。 接收窗口和拥塞窗口都在动态的调整。 发送窗口的大小取决于接收窗口和拥塞窗口中较小的一个。

92 TCP拥塞控制 2. 拥塞策略（P166） (1)慢启动（Slow Start），开始很慢，但按指数规律成倍增长，到达慢启动阈值（拥塞门限）后转入拥塞避免。 (2)拥塞避免（Congestion Avoidance），按线性规律增长，直到出现拥塞。 (3)拥塞检测（Congestion Detection），当检测到拥塞已发生，拥塞窗口快速减小（乘法减小），将慢启动阈值调整为当前拥塞值的一半（新拥塞门限） 。 (4)重新开始慢启动。

93 TCP拥塞控制

94 7.5 UDP协议（P166） UDP同IP协议一样提供无连接数据报传输，它在IP协议上增加了进程通信能力。
由于UDP本身不具备可靠通信能力，所以UDP的运行环境应该是高可靠性、低延迟的通信线路。 如果运行在不可靠的通信线路上，UDP的上层的应用层程序应该能解决报文的损坏、丢失、重复、失序以及流量控制等问题。 UDP是一个非常简单的协议，其最吸引人的地方在于它的高效率，不需要建立连接，开销很小。

95 7.5.1 数据报格式（P167） UDP数据报格式 UDP首部字段
源端口（Source Port）和目的端口（Destination Port）各占2字节。 长度（Length）2字节，标示整个UDP数据报的长度（包括报头），最小值为8（无数据）。 校验和（Checksum）2字节，校验整个数据报（包括报头和数据）

96 7.5.2 UDP伪首部与校验和计算（P167） 1. UDP伪首部格式
伪首部不是UDP的有效成分，而是IP数据报的一部分，只是用于验证UDP数据报是否正确到达目的地的。 UDP收发双方在计算校验和时都加上伪首部。 协议字段指明当前协议为UDP,协议值为17。

97 UDP伪首部与校验和计算 2. 校验和计算 UDP校验和是一个端到端的校验和。
UDP校验和的基本计算方法与IP首部校验和计算方法相类似，都是16位字的二进制反码和。

98 7.5.3 验证分析UDP数据报格式（P169） 抓取DNS查询的数据包，展开其中的UDP数据报。

99 UDP数据报