udp和arp之间的交互作用

udp和arp之间的交互作用

arp -a验证arp告诉缓存是空的

sock -u -i -nl -w8192 svr4 discard

1.在第一个arp应答返回以前，总共产生了6个arp请求。

2.在接收到第一个arp应答时（第7行），只发送最后一个数据报片（第9行）

3.在大多数的现实中，在等待一个arp应答时，只将最后一个报文发送给特定目标的主机。

4.另一个无法解释的不正常的现象是,svr4发回7个，而不是6个arp应答

5.这里我们没看到icmp消息的原因有两个，首先，大多数从berkeley派生的实现从不产生该差错，这些实现会设置定时器，也会在定时器溢出时将数据报片丢弃，但是不生成icmp差错。

6.第二，并未接受到包含udp首部的偏移量为0的第一个数据报片（这是arp所丢弃的5个报文的第1个）。除非接受到第一个数据报片，否则并不要求任何实现产生icmp差错。

最大udp数据报长度

ip数据报的最大长度是65535字节，这是由ip首部(图3-1）16比特总长度字段所限制的。

我们将遇到两个限制因素，第一，应用程序可能会受到其他程序接口的限制，socket api提供了一个可供应程序调用的函数，以设置接收和发送缓存的长度，对于udp socket,这个长度与应用程序可以读写的最大udp数据报的长度直接相关，现在的大部分系统都默认提供了可读写大于8192字节的udp数据报（使用这个默认值是因为8192是nfs读写用户数据数的默认值）

第二个限制来自于tcp/ip的内核实现，可能存在一些实现特性（或差错），使ip数据报长度小于65535字节。

在sunof.4.1.3下使用换回接口的最大ip数据报长度是32767字节。比空大的值都会发生差错，但是从bsd/386到os4.1.3的情况下，sun所能接收到最大ip数据报长度为32786字节（即32758字节的用户数据）。在solaris 2.2下使用换回接口，最大可首发ip数据报长度为65535字节，从solaris 2.2到aix 3.2.2，发送的最大ip数据报长度可以是65535字节，很显然，这是限制于源端和目的端的实现有关。

我们在3.2节中提过，要求主机必须能够接收最短为5 7 6字节的ip数据报，在许多udp应用程序的设计中，其应用程序数据被限制成512字节或更小，因此比这个限制值小。

数据报截断

由于ip能够发送或接收特定长度的数据报并不意味着接收应用程序可以读取该长度的数据，因此，udp变成接口允许应用程序制定每次返回的最大字节数，如果接受哦到的数据报长度大于应用程序所能处理的长度，那么会发生什么情况呢，

不幸的是，该问题的答案取决于变成接口和实现。

典型的berkeley版socket api对数据报进行阶段，并丢弃任何多余的数据，应用程序何时能够知道，则与潘奔有关（4.3bsd reno及其后的版本可以通过应用程序数据报被截断）。

svr4下的socket api(包括solaris 2x)并不阶段数据报，超出部分数据在后面的读取中返回，它也不通知应用程序从单个udp数据报中多次进行读取操作。

tliapi不丢弃数据，相反，它返回一个标志标明可以获得更多的数据，而应用程序后面的读操作将返回数据包的其余部分。

在讨论tcp时，我们发现它为应用程序提供连续的字节流，而没有任何信息边界。tcp以应用程序读操作时所要求的长度传送数据，因此，在这个接口下，不会发生数据丢弃。

icmp源站抑制差错（续）

但是新的router requirements rfc提出路由器不应该产生源站抑制差错报文，由于源站抑制要消费网络带宽 ，且对于拥塞来说是一种无效而不公平的调整，因此现在人品对源站抑制差错的状态时不支持的。

还需要指出是，sock程序要么没有接收到源站抑制差错报文，要么接收到却将他们忽略了，结果是如果采用udp协议，那么bsd实现通常忽略其接收到的源站抑制报文（正如我们在21.10节所讨论的那样，tcp接受源站抑制差错报文，并将放慢在该链接上的数据传输速度）。其部分原因在于，在接收到源站抑制差错报文时，导致源站抑制的进程可能已经中止了。

udp输入队列

我们还可以看到，服务器的-e选项使其可以知道每个数据报的目的ip地址。如果需要，它可以选择如何处理其接收到的第一个数据报，这个数据报的地址是广播地址。

我们可以从本例中看到以下几个特点，首先，应用程序并不知道其输入队列何时溢出，之水由udp对超出数据报进行丢弃处理。同时，从tcpdump输出结果，我们看到，没有发回任何信息高速客户其数据报被丢弃，这里不存在像icmp源站抑制这样发回发送端的消息，最后，看来udp输出队列是fifo(先进先出的）的，而我们在11.9节中所看到的arp输入确实lifo(后进先出）的。

2.广播与多播

三种ip地址：单播地址、广播地址和多播地址。

广播和多播仅用于udp,他们对需将报文同时传往多个接受者的应用来说十分重要。

tcp是一个面向连接的协议，它意味着分别运行于两个主机（由于ip地址确定）内的两个进程（由端口号确定）间存在一条连接。

有时一个主机要向网上的所有其他主机发送帧，这就是广播，通过arp和rarp可以看到这一过程。

多播(multicast)处于单播和广播之间，帧仅传送给属于多播的多个主机。

数据帧过滤过程

广播

受限的广播255.255.255.255

指向网络的广播10.255.255.255 192.168.1.255

指向子网的广播10.1.1.255 10.1.255.255

指向所有子网的广播10.255.255.255

主机处理的地址192.168.255.255（cisco路由器支持）

路由器支持255.255.255.255，主机不支持（当主机处理）

ip directed-broadcast直接广播

多播

多播组地址包括1110的最高4bit和多播组号，他们通常可表示为点分十进制数，范围从224.0.0.0到239.255.255.255

ip多播相对应的以太网地址方位01:00:5e:00:00:00到01:00:5e:7f:ff:ff.

多播地址224.128.64.32（十六进制e0.80.40.20)和224.0.64.32(十六进制e0.00.40.20)都映射为同一个以太网地址01:00:5e:00:40:20.

既然地址映射是不唯一的，那么设备驱动程序或ip层就必须对数据报进行过滤，因为网卡可能接收到主机不想接收的多播数据帧。

3.dns

域名系统(dns)是一种用于tcp/ip应用程序的分布式数据库，它提供主机名字和ip地址之间的转换及有关电子邮件的选路信息。

这里提到的分布式是指在internet上的单个站点不能拥有所有的信息。

dns提供了允许服务器和客户程序相互通信的协议。

对dns的访问是通过一个地址解析器(resolver)来完成的。

解析器通常是应用程序的一部分，解析器并不像tcp/ip协议那样是操作系统的内核。

从操作系统内核中的tcp/ip协议族对于dns一点都不知道

dns基础

dns的名字空间和unix的文件系统相思，也具有层次结构。

命名标识中一律不区分大写和小谢。

命名树上任何一个节点的域名就是将从该节点到最高层的域名串连起来，中间使用.分割这些域名

月明树中间的每个结点必须有一个唯一的域名，但域名树中的不同节点可以相同的标示。

以点.结尾的域名称为i而绝对域名或完全合格的域名fqdn(full qualified domain name)，如果sun.tuc.noao.edu.如果一个月明不以点结尾，则认为该域名是不完全的。

dns系统特性

nic负责分配顶级域和委托其他指定地区域的授权机构。

一个独立管理的dns子树称为一个区域(zone).一个常见的区域是一个二级域，如noao.edu.

一旦一个区域授权机构被委派后，由它服务则想该区域提供多个名字服务器。当一个新系统加入到一个区域中时，该区域的dns管理者为该新系统申请一个域名和一个ip地址，并将他们加到名字服务器的数据库中，这就是授权机构存在的必要性。

一个区域的管理者必须为该区域提供一个主名字服务器和至少一个辅助名字服务器。

主、辅名字服务器的主要区别在于主名字服务器从磁盘文件中调入该区域的所有信息，而辅名字服务器则从主服务器调入所哟偶信息。我们将辅名字服务器那个主服务器调入信息称为区域传送。

当一个名字服务器没有请求的信息时，它将如何处理？它必须与其他的名字服务器联系

并不是每个名字服务器都知道如何同其他名字服务器联系，相反，每个名字服务器必须知道如何同根的名字服务器联系。

这样一个反复的过程：正在处理请求的名字服务器与根服务器联系，根服务器告诉它与另一个名字服务器联系。

dns的一个基本特性是使用超高速缓存

dns的报文格式

这个报文由12字节唱的首部和4个长度可变的字段组成。

3字段由客户程序设置并由服务器返回结果。客户程序通过它来确定相应与查询是否匹配。

16bit的标志字段被划分为若干子字段。

qr是1bit字段：0表示查询报文，1表示相应报文。

opcode是一个4bit字段：普通值为0（标准查询），其他值为1（反向查询呢）和2（服务器状态请求）。

aa是1bit标志，表示授权回答(authoriative answer)

tc是1bit字段，表示,可截断的(truncated)

rd是1bit字段标示期望递归(recursion desired)

ra是1bit字段，标示可用递归

rcode是一个4bit的返回码字段。通常值为0(没有差错）和3（名字差错）

随后的4个16bit字段说明最后4个变长字段中包含的条目数，对于查询报文，问题（question)数通常是1，而其他3项则均为0.类似地，对于应答报文，回答数至少是1，剩下的两项可以是0或非0.

用udp还是tcp

注意到dns名字服务器使用的熟知端口号无论对udp还是tcp都是53。这意味着dns均支持udp和tcp访问。

当名字解析器发出一个查询请求，并且返回相应中的tc(删减标志）比特被设置为1时，它就意味着相应的长度超过了512个字节，而仅返回前512个字节。在遇到这种情况时，名字解析器通常使用tcp重发原来的查询请求，它将允许返回的相应超过512个字节（回想在11.10节讨论的udp数据报的最大长度）。既然tcp能将用户的数据流分为一些报文端，它就能用多个报文段来传输任意长度的用户数据。

区域传输将使用tcp,因为这里传输的数据远比一个查询或相应多得多。

4.tftp

tftp(trivial file transfer protocol)即简单文件传输协议，最初打算用于引导无盘系统(通常是工作站或x终端）。

和使用tcp的文件传输协议（ftp)不同，为了保持简单和短小，tftp将使用udp.

tftp的代码（和它所需要的udp、ip和设备驱动程序)都能适合只读存储器。

协议

tftp报文的头两个字节标示操作码，对于读请求和写请求（wrq),文件名字段说明客户要读或写的位于服务器上的文件，这个文件字段以0字节作为结束（见图15-1）。模式字段是一个ascii码串netascii或octet(可大小写任意组合），同样以0字节结束。

每个数据分组包含一个块编号字段，它以后要在确认分组中使用。

除了最后一个数据分组可含有不足512字节的数据，其他每个数据分组均含有512字节的数据。当tftp客户收到一个不足512字节的数据分组，就知道它收到最后一个数据分组。

在写请求的情况下，tftp客户发送wrq指明文件名和模式，如果该文件被该客户写，tftp服务器就返回块编号为0的ack包，该客户就将文件的头512字节以块编号为1发出。服务器则返回块编号为1的ack.

这种类型的数据传输称为停止等待协议。

和许多udp应用程序一样，tftp报文中没有检验和，它假定任何数据差错都将被udp的检验和检验到

安全性

于tftp是设计用于系统引导进程，它不可能提供用户名和口令。

tftp的这一特性被许多解密高手用于获取unix口令文件的复制，然后来猜测用户口令。

为防止这种类型的访问，目前大多数tftp服务器提供了一个选项来限制只能访问特定目录下的文件（unix系统通常是/tftpboot).这个目录中只包含无盘系统进行系统引导时所需的文件

对其他的安全性，unix系统下的tftp服务器通常将它的用户id和组ip设置为不会赋给任何真正用户的值。这只允许访问具有读或写属性的文件。