英语翻译大作业

一、英译汉

Tcp_ip illustrated volume 1第十一章

11.1这样的UDP数据报长度为总长度减去的IP报头长度

用户数据包协议（UDP），是一个简单的，面向数据报的，传输层的协议。每个输出操作的过程中都会产生一个UDP数据报，并使一个IP数据报发送。这是一个不同于面向信息流的协议，如TCP 。TCP通过应用程序写入的数据量可能实际上会与单个的IP数据报发送的内容的关系不大。

UDP数据报封装为IP数据报。

UDP不提供可靠性：它发送应用程序写入IP层的数据包，但是不能保证他们会到到达目的地。鉴于这种可靠性的缺乏，我们倾向于认为我们应该避免UDP，而一直使用一个可靠的协议，如TCP。在我们描述了TCP在17章，我们会回到这个话题，看什么类型的应用程序可以使用UDP。应用程序需要担心产生的IP数据报的大小。如果它超过网络的最大传输单元 ( MTU )（2.8节），IP数据报会产生碎片。这适用于数据包传输时从源到目的地每个网络，不仅是第一个连接发送主机的网络。我们将会在11.5节中检查IP碎片。

11.2

端口号确认发送过程和接收过程。TCP和UDP使用目的端口号从IP多路复用传进来的数据。由于IP已经解复用IP数据报的传入的TCP或UDP（基于IP报头中的协议价值），这意味着TCP端口号都看的TCP，UDP的则看UDP。TCP端口号都是独立于UDP端口号的。

尽管存在这种独立性，如果一个知名的服务是通过TCP和UDP提供的。对于这两个传输层，端口号通常被选择为相同的。这纯粹是为了方便，而不是协议的需要。

UDP长度字段代表的是UDP报头加上UDP数据的字节长度。该字段的最小值是8字节。（发送一个0字节的UDP数据包是可行的）这UDP长度是多余的。IP数据报中包含总的字节长度，所以UDP数据报长度为总长度减去的IP报头长度。

11.3

UDP校验和包括UDP报头和UDP数据。回想一下，在IP报头校验只包括IP报头不包括在IP数据报的任何数据。UDP和TCP有校验在它们的标题来掩盖他们的头和他们的数据。UDP校验和是可选的，而TCP是强制性的。

虽然计算UDP校验和基本类似于我们在3.2节中描述的IP报头校验（的补充和16位字），有差异。首先，对UDP数据报的长度可以是奇数字节，而校验算法增加了16位的字。解决方法是添加一个0瓦字节到最后，如果必要的话，只是用于校验和计算。（这是可能的，这不是垫

字节传输。）

接下来，UDP和TCP包括一个12字节的伪头与UDP数据报（或TCP段）只是用于校验和计算。这个伪报头包括从IP标头的某些领域。目的是让UDP双重检查数据到达正确的目的地（即，IP 数据报，没有接受，不给这个主机的IP，没有给予UDP数据报，是另一种上层）。

在图中我们明确地显示一个奇数长度的数据包，需要一个校验和计算垫字节。注意，UDP数据报长度校验和计算中出现两次。

如果计算校验码是0，它存储为一位（65535），这是在的补码运算等效。如果发送的校验和是0，这表明发件人没有计算校验和。

如果发件人并计算校验和接收器检测校验和错误，UDP数据报是默默丢弃。没有产生错误消息。（这是如果检测到IP是IP报头校验错误。发生什么）

这是一个端到端的UDP校验和校验。它是由发送方计算，并通过接收器。它的目的是捕捉任何修饰的UDP标题或数据的发送者和接收者之间的任何地方。

尽管UDP校验和是可选的，他们应该启用。在20世纪80年代，一些电脑厂商关闭UDP校验和默认情况下，加快其Sun的网络文件系统（NFS）的实现，使用UDP。虽然这可能在一个单一的局域网是可以接受的，在循环冗余校验数据链路上的框架（例如，以太网或令牌环帧）可以检测框架最腐败，当数据包通过路由器，所有的赌注都关闭。相信它或没有，有软件和硬件错误，修改位在数据包被路由的路由器。这些错误被检测不到在UDP数据报如果端到端的UDP 校验和残疾。也意识到一些数据链路协议（例如，滑）没有任何形式的数据链路校验和。主机需求RFC要求是默认启用UDP校验和。它还指出，实施必须验证接收到的校验和，如果发送方计算（即，接收的校验和是非零）。许多实施违反本，然而，只有验证接收到的校验和如果即将离任的校验和启用。

检测出是否一个特定的系统已经启用UDP校验和是很难的。一个应用程序在接收的UDP报头获得校验和字段通常是不可能的。为了解决这个问题，作者对tcpdump程序，打印接收的UDP 校验和添加另一个选项。如果打印的值是0，这意味着发送主机不计算校验和。

图11.4显示输出和来自三个不同的系统，在我们的测试网络（见封面图）。我们把袜子程序（附录C），用9个字节的数据到标准的回声服务器发送一个UDP数据报。

11.10

从理论上讲，一个IP数据报的最大大小为65535字节，由16位总长度字段在IP报头强加的（图3.1）。与一个20字节的IP报头和一个8字节的UDP报头，这使得最大为65507字节的UDP数据报的用户数据。大多数的实现，然而，提供小于这个最大的。

有两个限制，我们会遇到。首先，应用程序可以通过编程接口有限公司。套接字API（第1.15节）提供了一个函数，应用程序可以调用设置接收缓冲区和发送缓冲区的大小。一个UDP套接字，这个尺寸是最大规模的UDP数据包的应用程序可以读取或写入直接相关。今天，大多数系统提供一个默认的刚刚超过8192字节的UDP数据报可以读取或写入的最大尺寸。（这是因为8192是默认的用户数据量，NFS读取和写入默认情况下。）

未来的限制来自于TCP／IP核的实现。有可能实现的功能（或错误），一个IP数据报的限制到小于65535字节的大小。

作者试验了各种各样的UDP数据包大小，使用的袜子程序。使用环回接口在SunOS 4.1.3，IP 数据报的最大大小为32767字节。所有值较高的失败。但在以太网从BSD / 386到SunOS 4.1.3，IP数据报的最大大小的太阳能接受32786（即，32758字节的用户数据）。使用环回接口在Solaris 2.2，最大65535字节的IP数据包可以发送和接收。从Solaris 2.2 AIX 3.2.2，最大65535字节的IP数据报可以转移。显然这个极限取决于源和目标的实现。

我们3.2节中提到，一个主机必须至少有一个576字节的IP数据报接收。许多的UDP应用程序的设计限制了它们的应用数据为512字节或更少，低于此限制。我们看到这在10.4节中，例如，在路由信息协议总是差小于512字节的数据，每个数据报。我们会遇到同样的限制与其他UDP的应用：的DNS（14章），TFTP（15章），BOOTP（16章），和简单网络管理协议（25章）。

数据截断

因为IP能够发送和接收数据报的大小并不意味着接收应用程序编写的读取，大小。UDP编程接口允许应用程序指定要返回的最大字节数的每一次。如果接收到的数据包超过大小的应用是准备以应付发生了什么？

不幸的是，答案取决于编程接口和实现。

插座的传统伯克利版API截断数据包，丢弃任何多余的数据。应用程序是否通知取决于版本。（4.3BSD雷诺和以后可以通知数据包被截断。应用）

API在SVR4插座（包括Solaris 2。x）不截断数据报。任何多余的数据返回在随后的读取。应用程序没有通知多个读取是从一个单一的UDP数据报实现。

TLI API不丢弃数据。相反，一个标志还表明更多的数据是可用的，和随后的读取由应用程序返回的数据报的休息。

当我们讨论TCP我们会看到它的应用程序提供了一个连续的字节流，没有任何消息边界。TCP 将数据传递到任何大小的应用程序读取应用程序要求是没有任何数据丢失在这个界面。