Download
1 / 145
1.45k likes | 1.6k Vues
第三部分 传输层协议. 传输层概述. 网络层的任务是提供主机到主机的通信，而传输层的任务是提供进程到进程的通信 。. 进程与端口号. 在 TCP/IP 协议中，使用端口号（ 0~65535 ）来定义进程，端口号只具有本地意义。 TCP/IP 采用客户 - 服务器模式实现进程到进程的通信： 运行在本地主机上的程序称为客户，运行在远程主机上提供服务的程序称为服务器。 客户的端口号通常随机选取，而服务器的端口号一般是由 IANA 指派的熟知端口号。 服务器在熟知端口上等待客户的服务请求，客户向服务器主机上的熟知端口发送服务请求，并得到响应。. 客户 - 服务器模式示意.
E N D
传输层概述 • 网络层的任务是提供主机到主机的通信，而传输层的任务是提供进程到进程的通信。
进程与端口号 • 在TCP/IP协议中，使用端口号（0~65535）来定义进程，端口号只具有本地意义。 • TCP/IP采用客户-服务器模式实现进程到进程的通信： • 运行在本地主机上的程序称为客户，运行在远程主机上提供服务的程序称为服务器。 • 客户的端口号通常随机选取，而服务器的端口号一般是由IANA指派的熟知端口号。 • 服务器在熟知端口上等待客户的服务请求，客户向服务器主机上的熟知端口发送服务请求，并得到响应。
端口号分配 • 熟知端口：0~1023，由IANA指派和控制。 • 注册端口：1024~49151，IANA不指派也不控制，但需要在IANA注册以防止重复。 • 动态端口：49152~65535，不需要向IANA注册，可以由任何进程使用，也称短暂端口。
套接字地址 • 一个IP地址与一个端口号合起来称为套接字地址（socket address）。 • 一个套接字地址唯一标识了一个通信端点： • 客户套接字地址唯一定义了客户进程 • 服务器套接字地址唯一定义了服务器进程
为什么需要传输层 • 设置传输层的两个原因： • 为端系统上运行的多个进程提供复用和分用的功能（用端口号实现） • 为应用进程提供所需的数据传输服务 • TCP和UDP为应用进程提供不同的数据传输服务 • TCP：提供可靠的面向连接的服务（完美的服务） • UDP：提供不可靠的无连接服务（最简单的服务）
11.1 用户数据报格式 • UDP报文称为用户数据报，它包括一个8字节的固定头部和数据部分。
检查和计算 • 计算UDP检查和包括伪头、UDP头和数据三个部分。 • 检查和的使用是可选的，若不计算检查和，该字段填入0。
11.2 UDP服务的要点 • UDP发送的每一个用户数据报都是独立的，因而用户数据报没有编号，这意味着只有发送短报文的进程才能使用UDP。 • UDP不负责流量控制。 • 除了可选的检查和之外，UDP没有差错控制机制。
11.3 UDP的封装和拆装 • 封装： • 发送端进程将报文、报文长度及一对套接字地址传递给UDP，UDP在报文前面加上UDP头，然后将用户数据报及源/目的IP地址传递给IP软件。 • 拆装： • 接收端UDP使用检查和检错后，取出其中的数据部分连同发送端的套接字地址一起传递给接收进程。
封装和拆装示意 一对套接字地址 + 一对IP地址+ 一对MAC地址+
11.4 端口的实现 • 端口用队列实现： • 客户进程启动时，从操作系统请求一个端口号，创建一个相关联的入队列和一个出队列；服务器进程启动时，使用熟知端口号创建入队列和出队列。 • 发送进程将报文发送到相应的出队列，UDP从出队列中取出报文，加上UDP头后交给IP层。 • 接收端UDP收到用户数据报后，检查与目的端口号相关联的入队列是否存在，若存在将报文加入队列末尾，若不存在丢弃报文，并请求ICMP发送端口不可达报文。 • 接收进程从入队列中接收报文。
11.5 复用和分用 • 复用：发送端多个进程调用UDP发送报文 • 分用：接收端UDP为多个进程接收报文，并根据端口号交付到适当的进程。
11.7 UDP的应用 • 适用于只要求简单的请求-响应通信的进程，如DNS。 • 适用于具有内部流量控制和差错控制的进程，如TFTP。 • 多播和广播应用，多播和广播能力已经内置于UDP软件中。 • 管理进程，如SNMP。 • 某些路由选择协议，如RIP。
11.8 UDP软件包示例 控制块表：记录进程、端口和队列的关系 控制块模块：维护控制块表 输入队列：接收UDP交付的报文 输入模块：从IP接收UDP报文，放入相应的队列 输出模块：创建和发送UDP报文
UDP软件包功能模块 • 假想的UDP软件包由控制块表、输入队列、控制块模块、输入模块、输出模块组成。 • 控制块表：记录已打开的端口，每个表项记录进程ID、端口号和队列号的对应关系。 • 输入队列：用来接收由UDP交付的报文。 • 控制块模块：维护控制块表。 • 输入模块：从IP接收用户数据报，查找控制块表，将用户数据报放入相应的队列。 • 输出模块：负责创建和发送用户数据报。
练习 • 28，33，43
第12章 传输控制协议TCP • TCP服务模型 • TCP段格式 • TCP的连接机制 • TCP的传输策略 • TCP的差错控制 • TCP的定时器 • TCP的拥塞控制
12.1 TCP服务模型 • TCP提供可靠的、有序的字节流服务 • TCP使用连接进行通信，因而数据传输是有序的 • TCP使用确认机制保证数据的正确接收，因而是可靠的 • 一条TCP连接就是一个字节流，每个字节都有一个编号，它不保留报文的边界
字节流交付 • TCP使得进程与进程之间如同由“管道”连接一般。 • 发送方TCP实体将应用程序的输出分为不超过64k字节（实际通常为1500字节）的数据片段，每个数据片段封装在一个IP分组中发送。 • 接收方TCP实体根据字节序号将接收到的各个数据片段组装成连续的字节流交给应用程序。
TCP服务模型（续） • 每条TCP连接有两个端点（套接字），一对套接字唯一标识一条TCP连接： • 由于TCP使用两个端点来识别连接，因此一个套接口可以同时用于多个连接。 • 每条连接只能有两个端点， 因此TCP连接是点到点的，它不支持多播或广播。 • TCP连接是全双工的，数据可以在两个方向上同时传输。 • TCP支持紧急数据传输。
TCP段头结构 • TCP段中的每个数据字节都有一个32比特的序号，TCP段的序号即为第一个数据字节的序号。 • 确认序号：是对另一个方向上收到的数据的累计确认，表示预期接收的下一个字节的序号，同时表示这之前的数据字节已经全部正确收到。 • 窗口值：指出接收端为TCP连接预留的缓存空间大小，用于流量控制。 • 检查和：计算方法同UDP的检查和，包括伪头、TCP段头和数据三个部分。
重要的TCP选项 • 最大段长度 • 由接收端指明自己可以接收的最大数据长度（不包括段头），默认值为536字节。 • 窗口扩大因子 • 用于增大窗口值。若窗口扩大因子为n，则新的窗口值=段头中的窗口值×2n。
12.3 TCP的连接机制 • 从概念上说，建立连接是指在两个通信端点之间建立一条虚路径，在这两个通信端点之间传输的所有数据均沿着这条虚路径走，从而保证传输的顺序以及方便数据丢失的检测及恢复。 • 从实现上说，建立TCP连接就是要记录和维护通信的状态，如每个方向上数据传输的序号和确认序号。 • TCP使用三向握手过程建立连接，交换两个方向上数据传输的起始序号并协商相关的参数： • 客户->服务器：SYN（seq=x） • 服务器->客户：SYN+ACK（seq=y, ack=x+1） • 客户->服务器：ACK（seq=x or x+1, ack=y+1）（取决于该报文段中是否携带数据） • 在以上过程中，可以使用选项协商相关参数。
终止连接 • TCP连接是全双工连接，当一个方向的连接被终止时，另一个方向的连接仍然可以通信。因此，终止一条TCP连接必须在两个方向上都关闭连接。 • TCP使用四向握手过程终止连接 • 主机A->主机B：FIN（seq=x） • 主机B->主机A：ACK（ack=x+1） • 主机B->主机A：FIN（seq=z） • 主机A->主机B：ACK（ack=z+1） • 如果B收到A的终止请求时，数据也发送完了，则第2、3步可以合并。 • 当某一端的TCP发现连接异常时，可以使用RST置1的报文段复位连接。
12.4 字节流服务 • 发送缓存：缓存应用进程要发送的数据，以及已发送但尚未被确认的数据。当发送的数据被确认后，从发送缓存中清除这部分数据。 • 接收缓存：缓存已正确接收但尚未交付给应用进程的数据。当数据交付给应用进程后，从接收缓存中清除这部分数据。
12.5 TCP的流量控制 • 流量控制： • 用来限制源节点在收到从目的节点发来的确认之前可以发送的数据量，防止接收端被淹没。 • 滑动窗口机制： • 接收窗口：接收端从被确认的序号开始，可以接收的数据字节。接收窗口大小在TCP段的window size中通知。 • 发送窗口：发送端已发送但尚未被确认的数据字节，以及允许发送的数据字节。
发送窗口和接收窗口 • 图
可变长度滑动窗口 • 例：下图中发送窗口=9，序号为200~202的字节已发送，但尚未收到确认，允许发送序号从203~208的6个字节。
举例（续） • 接上面的例子，发送端收到一个报文段，其中的确认序号=202，接收窗口=9，拥塞窗口不变，且在此期间主机又发送了序号为203~205的字节，则其发送窗口如下：
举例（续） • 接上面的例子，发送端收到报文段，其中的确认序号=206，接收窗口=12，在此期间主机未发送，则其发送窗口如下：
举例（续） • 接上面的例子，发送端收到报文段，其中的确认序号=210，接收窗口=5，拥塞窗口未变，在此期间主机发送了序号为206~209的字节，则其发送窗口如下： • 大多数实现不允许这种情况。
当窗口为0时，发送端一般必须停止发送，但以下两种情况例外：当窗口为0时，发送端一般必须停止发送，但以下两种情况例外： • 可以发送紧急数据，例如终止在远端计算机上的运行进程。 • 可以发送一个1字节的段，以触发一个包含接收窗口大小的响应。
12.6 糊涂窗口综合症 • 发送方不断发送小数据分组，导致大量带宽浪费，此现象称为糊涂窗口综合症。 • 糊涂窗口综合症的产生原因 • 发送应用程序产生数据很慢，致使发送端TCP产生只包括少量字节的TCP段 • 接收缓存空间满且接收应用程序消耗数据很慢，致使接收端TCP发送具有微小增量窗口的通告 • 现行的TCP标准使用启发式方法来防止糊涂窗口综合症。
发送端策略 • 发送端TCP在发送报文段之前必须等待，以积累足够多的数据量，防止发送短的报文段。 • 问题：发送方TCP应该等待多长时间？ • Nagle算法： • 发送端TCP将收到的第一块数据发送出去，哪怕只有1个字节； • 发送端TCP在输出缓存中积累数据并等待，直到收到接收端的确认或者积累的数据足以填满一个最大长度的段，发送一个段； • 重复该过程 • Nagle算法简单，且可以适应不同的网络延时、不同的最大段长度和不同应用程序速度的组合情况，而且在常规情况下不会降低网络的吞吐量。
接收端策略 • Clark的解决方法： • 仅当窗口大小显著增加之后才发送非零窗口通告，所谓显著增加是指窗口大小达到缓冲区空间的一半或者一个最大段长度（取两者的最小值）。 • TCP标准推荐采用延迟确认的方法，即当缓存空间不够时推迟发送确认： • 优点：减少了通信量，不需要确认每一个报文段。 • 缺点：当确认延迟太大时会导致不必要的重传，也会给TCP估计往返时间带来混乱。 • TCP标准规定推迟确认不能超过500ms，而且接收方至少每隔一个报文段使用正常方式对报文段进行确认，以便准确估计往返时间。
12.7 TCP的差错控制 • TCP使用检查和、确认和重传来检测和纠正传输错误。 • 正确接收： • 接收端使用确认来报告数据的正确接收。可以采用推迟确认和捎带应答。 • 报文段出错及丢失： • 接收端丢弃出错的报文段，早期实现不做任何响应；现在的实现会发送一个重复的确认。 • 对于失序的报文段，早期的TCP实现将其丢弃，现在的TCP实现将其缓存起来，并发送一个重复的确认。 • 发送端使用超时检测数据丢失，一旦发现超时，重传未被确认的数据。 • 快速重传： • 当定时器超时或收到三个重复的确认时，发送端重传未被确认的数据。 • 对于ACK段，不设置重传定时器，也不重传。
