TCP-IP详解卷1：协议读书笔记_11

UDP是一个简单的面向数据报的传输层协议:进程的每个输出 *** 作都正好产生一个UDP数据报，并组装成一份待发送的IP数据报。这与面向流字符的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系。

UDP数据报封装成一份IP数据报的格式如下图:

UTP不提供可靠性:它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地。

应用程序必须注意IP数据报的长度。如果它超过网络MTU(最大传输单元)，那么就要对IP数据报进行分片。如果需要源端到目的端的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做。

首部结构如下图:

端口号表示发送进程和接受进程，由于IP层已经把IP数据报分配给TCP或UDP（根据IP首部中协议字段值），因此TCP端口号由TCP来查看，而UDP端口号由UDP来查看。TCP端口号与UDP端口号是相互独立的。

UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为8字节(发送一份0字节的UDP数据报是OK的)。这个UDP长度是有冗余的，IP数据报长度指的是数据报全长，因此UDP数据报长度等于IP数据报长度减去IP首部的长度。

UDP校验和覆盖UDP首部和UDP数据。回想IP首部的校验和，它只覆盖IP的首部----并不覆盖IP数据报的任何数据。

UDP和TCP在首部都有覆盖它们首部和数据的校验和。UDP校验和是可选的，而TCP的校验和是必需的。

尽管U D P检验和的基本计算方法与我们之前第三节中描述的IP首部检验和计算方法相类似（16bit字的二进制反码和），但是它们之间存在不同的地方。首先，UDP数据报的长度可以为奇数字节，但是检验和算法是把若干个16bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算（也就是说，可能增加的填充字节不被传送）。

如果发送端没有计算检验和而接收端检测到检验和有差错，那么UDP数据报就要被悄悄地丢弃。不产生任何差错报文（当IP层检测到IP首部检验和有差错时也这样做）。

UDP检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。

物理网络层一般要限制每次发送数据帧的最大长度。任何时候IP层接收到一份要发送的IP数据报时，它要判断向本地哪个接口发送数据(选路)，并查询该接口获得其MTU。IP把MTU与数据报长度进行比较，如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发生在中间路由器上。

把一份IP数据报进行分片以后，只有到达目的地才进行重新组装(这里的重新组装与其他网络协议不同，它们要求在下一站就进行重新组装，而不是在最终目的地)。重新组装由目的端的IP层来完成，其目的是使分片和重新组装过程对传输层(TCP和UDP)是透明的。已经分片过得数据报可能会再次进行分片，IP首部中包含的数据为分片和重新组装提供了足够的信息。

对于发送端发送的每份IP数据报来说，其标识字段都包含一个唯一值。该值在数据报分片时被复制到每个片中。标志字段其中一个比特来表示"更多的片"。除了最后一片外，其他每个组成数据报的片都要把比特置1。片偏移字段指的是该片偏移原始数据报开始处的位置。另外，当数据报被分片后，每个片的总长度值要改为该片的长度值。

最后，标志字段中有一个比特称作“不分片”位。如果将这一比特置1，IP将不对数据报进行分片。相反把数据报丢弃并发送一个ICMP差错报（“需要进行分片但设置了不分片比特”）给起始端。

当IP数据报被分片后，每一片都成为一个分组，具有自己的IP首部，并在选择路由时与其他分组独立。这样，当数据报的这些片到达目的端时可能会失序，但是在IP首部中有足够的信息让接收端能正确组装这些数据报片。

IP分片有一个问题:丢失掉一片数据也要重新传输整个数据报。

原因:IP层没有超时重传机制---由更高层负责超时和重传。当来自TCP报文段的某一片丢失后，TCP超时会重发整个TCP报文段，该报文段对应于一份IP数据报。没有办法重传数据报中的一个数据报片。

使用UDP很容易导致IP分片。下图是UDP分片示例:

发现ICMP不可达差错的另一种情况是，当路由器收到一份需要分片的数据报，而在IP首部又设置了不分片(DF)的标志比特。如果某个程序需要判断到达目的端的路途中最小MTU是多少----称作路径MTU发现机制，那么这个差错就可以被该程序使用。

这个情况下ICMP不可达差错报文格式如下图：

如果路由器没有提供这种新的ICMP差错报文格式，那么下一站的MTU就为0。

理论上，IP数据报的最大长度是65535字节，这是由IP首部16比特总长度字段所限制的。去除20字节的IP首部和8个字节的UDP首部，UDP数据报中用户数据的最长长度为65507字节。但是，大多数实现所提供的长度比这个最大值小。

其中有两个限制因素:

1应用程序可能会受到其程序接口的限制。socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于UDP socket，这个长度与应用程序可以读写的最大UDP数据报的长度直接相关。

2第二个限制来自于TCP/IP的内核实现。可能存在一些实现特性(或差错)，是IP数据报长度小于65535字节。

我们同样可以使用UDP缠上ICMP"源站抑制"差错。当一个系统(路由器或主机)接受数据报的速度比其处理速度快时，可能产生这个差错。

当在以太网传播的数据需要经过SLIP链路时，可能产生该差错报文。因为SLIP链路的速度大约只有以太网的千分之一，所以，很容易使其缓存用完。

在本例中，应用程序要么没有接收到源站抑制差错信号，要么接收到却将其忽略了。结果是如果采用UDP协议，那么BSD实现通常忽略其接收到的源站抑制报文。其部分原因在于，在接收到源站抑制差错报文时，导致源站抑制的进程可能已经中止了。

不处理ICMP源站抑制差错，说明了UDP是一个非可靠的协议，它只控制端到端的流量控制。除非在应用程序中建立一些应答机制，否则发送端并不知道接收端是否收到了这些数据。

来自客户的是UDP数据报。IP首部包含源端和目的端IP地址，UDP首部包含了源端和目的端的UDP端口号。当一个应用程序接收到UDP数据报时， *** 作系统必须告诉它是谁发送了这份消息，即源IP地址和端口号。

这个特性允许一个交互UDP服务器对多个客户进行处理。给每个发送请求的客户发回应答。

一些应用程序需要知道数据报是发给谁的，即目的地址。这要求 *** 作系统从接收到的UDP数据报中将目的IP地址交给应用程序。

大多数UDP服务器是交互服务器，单个服务器进程对单个UDP端口上的所有客户请求进行处理。

通常程序所使用的每个UDP端口都与一个有限大小的输入队列向联系。这意味着，来自不同客户的差不多同时到达的请求将有UDP自动排队。接收到UDP数据报以其接收顺序交给应用程序。

因此，由于队列溢出导致的UDP数据报的丢失不可避免。应用程序不知道其输入队列什么时候会溢出，只能有UDP对超出数据报进行丢弃处理。同时，不会发挥任何消息告诉客户其数据报被丢弃。

大多数UDP服务器在创建UDP端点时都使其本地IP地址具有通配符的特点。这表明进入的UFP数据报如果其目的地为服务端端口，那么任何本地接口均可接收到它。

大多数系统允许UDP端点对远端地址进行限制。

下面是UDP服务器本身可以创建的三类地址绑定:

在所有情况下，lport指的是服务器有名端口号，localIP必须是本地接口的IP地址。表中这三行的排序是UDP模块在判断用哪个端点接收数据报时所采用的顺序。最为确定的地址（第一行）首先被匹配，最不确定的地址（最后一行IP地址带有两个星号）最后进行匹配。

当UDP数据报到达的目的IP地址为广播地址或多播地址，而且在目的IP地址和端口号处有多个端点时，就向每个端点传送一份数据报的复制（端点的本地IP地址可以含有星号，它可匹配任何目的IP地址）。但是，如果UDP数据报到达的是一个单播地址，那么只向其中一个端点传送一份数据报的复制。选择哪个端点传送数据取决于各个不同的系统实现。

UDP是一个简单协议。它想用户进程提供的服务位于IP层之上，包括端口号和可选的校验和，我们用UDP老检查校验和并观察分片是如何进行的。

当系统接收IP数据报的速率超过这些数据报被处理的速率时，系统可能发送ICMP源站抑制差错报文。使用UDP时很容易产生这样的ICMP差错。

mtu 最大传输单元（Maximum Transmission Unit，MTU）是指一种通信协议的某一层上面所能通过的最大数据报大小（以字节为单位）。最大传输单元这个参数通常与通信接口有关（网络接口卡、串口等）。

因特网协议允许IP分片，这样就可以将数据报分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。这一分片过程发生在IP层（OSI模型的第三层，即网络层），它使用的是将分组发送到链路上的网络接口的最大传输单元的值。原始分组的分片都被加上了标记，这样目的主机的IP层就能将分组重组成原始的数据报了。

在因特网协议中，一条因特网传输路径的“路径最大传输单元”被定义为从源地址到目的地址所经过“路径”上的所有IP跳的最大传输单元的最小值。或者从另外一个角度来看，就是无需进一步分片就能穿过这条“路径”的最大传输单元的最大值。

RFC 1191描述了“路径最大传输单元发现方法”，这是一种确定两个IP主机之间路径最大传输单元的技术，其目的是为了避免IP分片。在这项技术中，源地址将数据报的DF（Don't Fragment，不要分片）位置位，再逐渐增大发送的数据报的大小——路径上任何需要将分组进行分片的设备都会将这种数据报丢弃并返回一个“数据报过大”的ICMP响应到源地址——这样，源主机就“学习”到了不用进行分片就能通过这条路径的最大的最大传输单元了。

不幸的是，越来越多的网络封杀了ICMP的传输（譬如说为了防范DDOS攻击）——这使得路径最大传输单元发现方法不能正常工作，其常见表现就是一个连接在低数据流量的情况下可以正常工作，但一旦有大量数据同时发送，就会立即挂起（例如在使用IRC的时候，客户会发现在发送了一个禁止IP欺骗的ping之后就得不到任何响应了，这是因为该连接被大量的欢迎消息堵塞了）。而且，在一个使用因特网协议的网络中，从源地址到目的地址的“路径”常常会为了响应各种各样的事件（负载均衡、拥塞、断电等等）而被动态地修改——这可能导致路径最大传输单元在传输过程中发生改变——有时甚至是反复的改变。其结果是，在主机寻找新的可以安全工作的最大传输单元的同时，更多的分组被丢失掉了。

对于时下大多数使用以太网的局域网来说，最大传输单元的值是1500字节。但是像PPPoE这样的系统会减小这个数值，这就使得在使用最大传输单元发现方法时可能会产生这样的结果：一些处于配置不当的防火墙之后的站点变得不可达了。对于这种情况，还是可能找到变通的方法的，但这取决于你控制的是网络的哪一部分。这些方法包括改变用来在防火墙一端建立TCP连接的第一个分组的MSS（Maximum Segment Size，最大分段大小）。

对于一些支持老版本以太网协议的IBM系统（例如XSeries），可能只有在把最大传输单元设为1492之后才能在当下常见的局域网上进行运作。

[编辑本段]如何检测网关的MTU

在本机打开dos窗口，执行： ping -f -l 1472 19216801 其中19216801是网关IP地址，1472是数据包的长度。请注意，上面的参数是“-l”（小写的L），而不是“-1”。 如果能ping通，表示数据包不需要拆包，可以通过网关发送出去。 如果出现： Packet needs to be fragmented but DF set 表示数据包需要拆开来发送。此时，减少数据包长度，再执行上面的ping命令。从1400到1472之间多试几次，就能找到合适的数据包长度了。把数据包长度加上数据包头28字节，就得到MTU的值。 如果检测到网关的MTU值是1500，不需要修改。 如果网关有防火墙ping不通，可以试试直接把MTU设为1400。

[编辑本段]如何修改本机的MTU

修改方法如下：

（1）、运行regedit （2）、浏览到： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

（3）、Interfaces下有多个子项，每个子项对应一个网卡。请按如下方法选择网卡： （a）确定本机用来连接Internet的网卡或拨号连接的IP，如192168019； （b）用鼠标点击Interfaces上的子项，查看键值列表中的IPAddress项； （c）如果IPAddress的键值与（a）中的IP相同，即192168019，则该子项就是要找的网卡。 （4）、进入该子项，在右边的窗口里按鼠标右键，选择“新建”->“双字节值”，输入名称“MTU”，按回车。再用鼠标双击“MTU”，d出修改窗口： 如图3： 填入MTU的值。填写前请先把基数设为十进制。 设置好后，需要重启机器才能生效。

Linux下可使用如下命令修改 需要root权限

ifconfig 网卡 MTU值

如 ifconfig eth0 mtu 1460

MaxMTU是最大的TCP/IP传输单元，在TCP/IP协议中，将要传输的数据分成较小的组进行传输，每个组的大小为576字节。Windows默认的字节为1500，这是以太网的分组标准。ADSL使用的 PPPoE略小于这个数值，一般为1492。而某些网站采用的MaxMTU大于1492，所以，可能导致某些网页不能访问。修改Windows默认的MaxMTU可以解决这个问题。不论是 PC机上安装的PPPoE软件或者是内置在Modem的 PPPoE软件，在使用中都有可能遇到这个问题。 如果使用路由器出现此种情况, 请在 防火墙配置 => 基本设定 里, 将MTU改为手工, 设置为 1492 即可 那如何确定路由器从ISP获得的 MTU 为 1500, 请见附件圈出的位置

以上就是关于TCP-IP详解卷1：协议读书笔记_11全部的内容，包括:TCP-IP详解卷1：协议读书笔记_11、交换机的MTU是什么、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！