03网络协议第三讲

传输层协议分析第三讲第10章UDP：用户数据报第11章TCP：数据结构和输入处理第12章TCP：有限状态机的实现第13章TCP：输出处理第14章TCP：定时器管理22020/2/12第10章UDP：用户数据报32020/2/1210.1引言用户数据报协议提供应用程序之间的无连接通信。它允许某个机器上的一个程序向其他机器上的一个或多个程序发送数据报并接收响应信息。本章讨论UDP的实现过程，主要集中讲述UDP如何利用协议端口号来识别通信的端点。它讨论了两种解决协议端口号绑定问题的方法，并给出其中一种方法的实现细节。最后，本章描述了UDP伪首部，并详述了计算UDP校验和的过程是如何使用伪首部的。42020/2/1210.2UDP端口和多路分解处理理论上，使用UDP的通信非常简单。协议标准规定应用程序使用一个称为协议端口号的抽象模型来识别通信的端点。当机器A中的应用程序与机器B中的一个应用程序通信时，这两个应用程序都必须从自己的本地操作系统中获取一个UDP端口号。两端在通信时都必须使用协议端口号。使用协议端口号(而不是系统提供的标识符，如进程、任务或作业标识符)的优点是保持了协议与特定系统之间的独立性，并允许不同类型的计算机系统应用程序之间互相通信。虽然UDP协议端口号的设计思想看起来直截了当，但在实现时有两种基本的方法。两种方法都与协议标准一致，但它们为应用程序提供的接口稍有不同。下一节将描述客户和服务器如何使用UDP，并说明了两种方法是如何互相兼容的。52020/2/1210.2.1成对通信使用的端口如图所示，有些应用程序使用UDP来进行成对通信。要做到这一点，两个应用程序各自从本地操作系统中获取UDP端口号，并且他们利用这对端口号交换UDP报文。在这种情况下，应用程序和协议软件之间的理想的接口，是将具体的地址操作从发送和接收数据报的操作中分离出来。这样，接口允许一个应用程序一次性指定本地的和远程的协议端口号，然后多次发送和接收数据报。当然，在指定另一个机器上的协议端口号时，应用程序必须同时指定该机器的IP地址。一旦协议端口号被指定，应用程序就能发送和接收任意多的数据报。62020/2/1210.2.2多对一通信使用的端口绝大多数应用程序使用客户—服务器模式的交互形式，如图所示。单一的服务器应用程序接收来自多个客户的UDP报文。当服务器启动时，它不会指定另一个机器上的一个IP地址或UDP端口，因为它必须允许任意一个机器向其发送报文。事实上，它仅仅指定一个本地UDP端口号。由客户送往服务器的每个报文必须给出客户的UDP端口号及服务器的UDP端口号。服务器从输入的UDP数据报中提取源端口号，并在它发送应答报文时将该端口号作为目的端口号。当然服务器还必须在UDP数据报到达时获取客户的IP地址，这样在发送应答报文时，它也能够指定IP地址。72020/2/1210.2.2多对一通信使用的端口因为服务器与多个客户通信，所以不能设置一个永久的IP目的地址或永久的UDP协议端口号。事实上，用于多对一通信的接口必须允许服务器在每次发送数据报时给出有关目的站的信息。这样，与成对通信使用的理想型接口不同，服务器使用的理想型接口并没有将地址标识和数据报的传送分开。82020/2/1210.2.3操作模式为了与成对通信和多对一通信方式都兼容，大多数UDP接口利用参数来控制交互的模式。一种典型的采用成对交互作用的模式是客户。它允许应用程序一次性指定本地和对方的协议端口号，然后发送及接收UDP数据报，并且无需每次都给出端口号。另一种模式包含了服务器。它允许服务器仅仅指定本地端口，然后就可接收来自任意客户的数据报。这种系统可能要求一个应用程序明确地说明交互模式，也可能从应用程序给出的端口绑定中推断出其模式。92020/2/1210.2.4多路分解处理中的细节问题除了要考虑交互模式之外，UDP实现方案还要提供对协议端口多路分解处理的解释。这里有两种可能性：●多路分解时仅使用目的站的协议端口号。●多路分解时同时使用源站和目的站的协议端口号。不同的选择会对应用程序与协议软件之间的交互作用产生微妙的影响。要理解其中详情，考虑如图所示的两种多路分解形式。102020/2/1210.2.4多路分解处理中的细节问题112020/2/1210.2.4多路分解处理中的细节问题122020/2/1210.2.4多路分解处理中的细节问题在第一种多路分解方式下，系统将发向特定目的站协议端口的所有数据报都送到同一队列中。在第二种多路分解方式下，系统在为数据报多路分解时要利用源地址(源站协议端口号和源IP地址)。因此在第二种方式下，每个队列中的所有数据报都来自特定的某个源站。这两种方式各有利弊。例如，在第一种方式下，服务器发挥的作用很小，因为应用程序接收了所有发往给定协议端口号的数据报，与它们的生成源无关。然而，由于系统对多个源站不加区分，所以系统不能过滤掉有地址错误的数据报。只要是一个以该端口为目的站的数据报到达，程序就会接收，哪怕它被错误地发送了。在第二种方式下，客户发挥的作用小，因为一个给定的应用程序有权选择接收另一应用程序发送来的数据报。然而，如果一个应用程序需要与两个远程应用程序同时通信，它就必须分配两个队列，每个远程应用程序对应一个队列。再者，系统可能需要提供附加的机制，以允许一个程序在两个队列上等待I/O端口的事件。132020/2/1210.2.4多路分解处理中的细节问题虽然看起来困难，但还是有可能同时使用两种方式的多路分解处理，以同时适用于客户和服务器。在第一种方式下，仅与一个远程应用程序通信的客户必须选择一个未被其他任何本地程序使用的本地协议端口号。在第二种方式下，服务器必须使用一个通配符，如图10.2所示。被标志为ANY的源站代表一个与任意源匹配的通配符(任意源IP地址的源协议端口号)。在某一特定时刻，系统最多允许为某个目的端口使用一个通配符：当数据报到达时，该实现方案在检查通配符之前，先查看其源站和目的站是否与给出的源站—目的站对相匹配。因此，在例子中，如果一个目的端口号为200，源端口号为397，而源IP地址为192.5.48.3的数据报到达，系统将其放入应用程序1对应的队列中。类似地，系统将目的端口号为200，源端口号为40，而源IP地址为128.10.2.26的数据报放入应用程序2对应的队列中。系统使用通配符机制与其他目的端口号为200的数据报相匹配，并将它们放入应用程序4对应的队列中。142020/2/1210.3UDP的输入处理我们的范例程序使用的多路分解方式是为仅有目的协议端口号的输入数据报选择一个队列。我们选用这种方式是因为它既能有效地进行多路分解处理，又允许应用程序与多个远程站点同时通信。在介绍了UDP使用的数据结构的定义之后，我们将叙述软件如何处理输入的数据报，以及如何发送外发数据报。10.3.1UDP数据结构的说明在文件udp.h中说明的结构udp定义了UDP数据报的格式。除了16位的源站和目的站协议端口号外，UDP首部还包含了16位的数据报长度字段和16位的校验和。除UDP数据报格式的说明之外，udp.h中还包含了一些符号常量，用于为最常用的UDP协议端口号赋值。例如，TFTP服务器总是在第69号端口上操作、而RIP使用的端口号为520。152020/2/1210.3.2传入数据报队列的说明UDP软件将存储传入数据报的数据结构划分为两部分：第一部分由传入数据报的队列组成，而第二部分包含了UDP用来选择队列的映像信息。前者是UDP和用于提取传入数据报的应用程序之间接口的一部分。后者是操作系统的一部分——UDP软件利用它来选择一个队列，但应用程序不能访问此队列。文件dgram.h中包含了对应用程序使用的队列的定义。虽然这个文件中包含的许多细节超过了本章讲述的范围，但有两个定义与我们此刻探讨的内容密切相关。用来存储传入数据报的基本数据结构由一个数组dgtab组成，数组中的元素的类型是dgblk。可以把dgtab看作是一组队列，在dgtab中每个正在使用中的本地UDP协议端口对应一个活动的表项。字段dg_lport指定本地UDP协议端口号，而字段dg_xport定义了以该端口为目的站的数据报所对应的队列。字段dg_state说明了该表项是正在使用中(DGS_INUSE)还是未分配(DGS—FREE)的。162020/2/1210.3.2传入数据报队列的说明除了为多路分解处理定义的结构之外，dgram.h还定义了在应用程序和UDP协议软件之间传输的数据报的格式。范例软件没有将UDP数据报传送给应用程序，而是在结构xgram里定义了一个新格式。回想一下使用的多路分解处理方式，应用程序打开一个给定的协议端口号，并接收发往该端口的所有数据报。系统以xgram格式向应用程序传送数据报，这样应用程序就能够同时确定发送者的IP地址和协议端口号。172020/2/1210.3.3UDP端口号与队列的映射UDP利用传入数据报中的目的端口号来选取dgtab中正确的表项。它在数组upqs中查找映射地址。数组upqs在文件udp.h中说明。过程udp_in(在10.3.6节给出)将目的站协议端口号与upqs数组的每个表项中的up_port字段相比较，直到它找到一个匹配表项为止。然后它利用字段up_xport来决定是否与用来将数据报置入队列的unix端口一致。将upqs中的端口映射从dgtab中的队列中分离出去似乎有些多余，因为当前的实现方案在端口映射时使用的是线性查找。然而线性查找对只有少量活动UDP端口的系统来说是有效的。具有大量端口的系统应使用更有效的查找策略，如散列表。将端口映射时使用的数据结构与数据报队列使用的数据结构分开，就有可能在改变映射算法时不用改变应用程序接口的数据结构。它们两者的分离还使操作系统有可能直接使用UDP，而无需依赖于应用程序这样的接口。182020/2/1210.3.4分配空闲队列因为我们的范例代码对upqs数组采用了线性查找法，所以分配一个表项是十分简单明了的，过程upalloc在数组中搜索，直到它找到一个当前未被使用的表项，然后它填写表项中的各个字段，创建一个用来传入数据报队列的Xinu端口,并向调用者返回此表项在数组中的索引值。192020/2/1210.3.5网络字节顺序与本机字节顺序之间的相互转换有两个实用程序用于处理UDP首部字段在网络字节顺序和本机字节顺序之间的转换。过程udpnet2h为输入数据报处理向本机字节顺序的转换，程序代码自身有清楚的说明。202020/2/1210.3.6处理一个己到达的数据报当有一个以本机为目的站的UDP数据报到达后，伪网络接口中的一个过程就调用过程udp_in，它以参数的形式传递含有输入分组的缓冲区地址以及网络接口索引，分组通过该网络接口到达。udp_in首先查看发送方是否支持校验和选项。如果有校验和存在，udp_in调用udpcksum来验证该校验和。如果分组包含的校验和正确，调用返回0。如果校验和项不为0，但又不正确，udp_in不再做进一步处理，直接丢弃该UDP数据报。udp_in还调用udpnet2h将所有首部字段转换为本机字节顺序。在转换了首部之后，udp_in将数据报多路分解，并搜索一组数据报队列(数组upqs)，直到它为传入数据报的目的UDP端口找到一个对应的队列。如果端口未满，udp_in调用psend将数据报置入队列，然后调用send向任何正在等待该数据报的进程发送一个报文。如果队列已满，udp_in记录溢出错误并丢弃该数据报。如果udp_in搜索了全部数据报队列，却没有找到一个为传入数据报中的目的端口而保留的队列。则意味着没有任何应用程序同意接收此端口上的数据报。udp_in必须调用icmp向生成数据报的源站返回一个ICMP“目的站不可达”报文。212020/2/1210.3.7UDP校验和的计算过程udpcksum为一个UDP数据报计算其校验和。与以前描述的过程cksum类似，该过程可用来生成一个校验和(通过将校验和的首部字段置0)，或验证一个现有的校验和。然而