TCP/IP|TCP/IP UDP:用户数据报协议 (11) TCP

TCP 是面向数据流的协议，而UDP是面向数据报的协议；

UDP 是一个简单的面向数据报的传输层协议；（进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发送的IP数据报)

与面向流字符(数据流)的协议不同；（eg：TCP，应用程序产生的全体数据与真正发送的单个数据报可能没有什么联系。）

UDP提供不可靠性；把应用程序传给IP的数据发送出去，但是并不能够保证它们能够到达目的地。【由于缺乏可靠性，我们似乎避免使用UDP而使用TCP】

???
应用程序必须关心IP数据报的长度，如果它超过网络的MTU，那么就要对IP数据报进行分片。如果需要，源端到目的端之间的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做。 —— 这个分片和应用程序有什么关系？ ——>ip 的分片机制。

也就是不管UDP传输下来的数据报是多大的，都进行了IP的封装， ——> 造成了需要进行分片各个内容；—— 因为数据报过大，所以，我们在IP要将数据传输，就需要对IP数据报进行分片。 TCP会选择适当的大小， MSS（最大传输单元）, 如果觉得小了， IP层会将好几个数据组装成为一个大的数据，给你一个tcp头部发走。 TCP会不会有时候觉得也是大的？分成很多小的数据进行发走。传输层的数据报文传到IP层，进行数据传输，没有本质的联系的；没有边界，有点像流水一样，进行转发的的，两层没有关系的； TCP如果觉得大了，就会组装成小的，如小了，就组装成为大的； TCP有自己的判断。 UDP就不管，

【TCP/IP|TCP/IP UDP:用户数据报协议 (11)】UDP 的三大应用：（特点：快）

查询类：DNS
— 没有TCP三次握手过程，快
— 多个DNS同事查询

数据传输：TFTP 【这个可以不用管】
— 停止等待协议，慢(需运用层确认数据)
— 适合于无盘工作站
3）语音视频流
—支持广播和组播
—支持丢包，保障效率

文章图片
UDP 格式

文章图片

1)端口号表示发送进程和接收进程
2)TCP 和UDP端口是相互独立的。（有些服务为了方便使用，提供了相同的端口）
3)UDP长度指的是UDP首部和UDP数据的字节长度。改字段的最小值为8byte。

4)UDP 校验和
1> UDP 校验和覆盖UDP首部和UDP数据，而IP首部的校验和只覆盖IP的首部。？？这样会不会出现没有校验的地方，因为IP + UDP/ICMP... ，这些IP内部的内容有校验和了，所以，ip的校验和只是校验首部就可以的，IP校验和 + 内容协议的校验和 = 所有的内容都有校验到了。
2> UDP 的校验和是可选的，而TCP的校验和是必须的。？？为什么UDP校验和是可选的？
3> UDP数据报的长度可以为奇数字节，但是校验和算法是把若干个16bit相加。解决方法是：在最后填充字节0。【这个只是为了校验和计算，可能增加的填充字段不被传送】
4> UDP数据报和TCP段包含一个12字节长的伪首部，它是为了计算校验和而设置的。伪首部包含IP首部一些字段。其目的是让UDP两次检查数据是否已经正确到达目的地。【这个有个问题，UDP是在什么时候将伪首部加进去的？传输层知道IP地址的么？如果知道，那就还好，如果不知道，就小在IP层传，按道理来说，是可以知道的，因为DNS也是一个程序获取到了IP地址】【eg: IP没有接受地址不是本主机的数据报，以及IP没有吧应传给另一高层的数据包传给UDP】【Nat的一个例子，nat改变了伪首部的IP地址，这样的校验是通不过的，所以伪首部也反防止Nat转换】

文章图片
11.3.1 tcpdump输出

文章图片

可以看到，三个系统中有两个打开了UDP检验和选项。【为0不检验，不为0，需要检验】【UDP校验和是简单的16bit和（TCP/IP协议族中所有的校验和），检测不出来交换两个16bit的差错】
——————
11.5 IP分片

将IP数据报长度和MTU长度作比较，如果大于，就进行分片

分片可以发生在原始发送端主机上，也可以发生在中间的路由器上。

把一份IP数据报分片以后，只有到达目的地才进行重新组装(FR fragment)

重新组装由目的端的IP层来完成，其目的是使分片和重新组装过程对传输层(TCP/UDP) 是透明的。

已经分片过的数据报有可能会再一次进行分片(可能不止一次)

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

尽管IP分片过程看起来是透明的，但有一点让人不想使用它：即使只丢失一篇数据也要重传整个数据报。

IP层本身没有超时重传的机制 —— 由更高层来负责超时和重传(TCP有超时和重传机制，但是UDP没有)。当来自TCP报文段的某一篇丢失后，TCP在超时后会重新发真个tcp报文段，改报文段对应一份IP数据报。没有办法只重传数据报中的一个数据报片

如果对数据报分片的是中间路由器，而不是起始端系统，那么起始端系统无法知道数据报是如何被分片的。就这个原因，经常哟啊避免分片。

[图片上传失败...(image-f67209-1620301520106)]](https://upload-images.jianshu.io/upload_images/1205674-35840f382e9c76ec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

分片的内容，主要和第二行的内容有关。

文章图片

文章图片
分片例子——输入

文章图片
分片例子——输出 11.6 ICMP不可达差错(需要分片)

发生ICMP不可达差错的另一种情况是：当路由器收到一份需要分片的数据报，而在IP首部又设置了不分片的标志比特(DF=1)。如果某个程序需要帕努单目的端的路途中最小的MTU是多少——称作路径MTU发现机制，那么这个差错就可以被该程序使用。
这个格式的第二个32bit的16~31bit可以提供下一站的MTU，而不再是0。如果路由器没有提供这种新的ICMP差错报文格式，那么下一站的MTU就设为0。

文章图片

例子：

文章图片

在点到点的链路汇总，不要求两个方向的MTU为相同的值

主机上sun上运行tcpdump ，观察SLIP链路，看什么时候分片，知道数据长度从500增加到600字节。可以看到接收到的回显请求，但不见回显应答。

第1行：显示的回显请求通过路由器netb到达sun主机，没有进行分片，并设置了DF比特，因此我们知道了还没有达到netb的SLIP MTU 。

第2行主机DF被赋值到回显应答的报文中，所以，回显应答的DF=1。回显应答和回显请求的报文长度相同，超过了552，所以，会被丢弃掉。

第3行和第6行中，mtu=0表示主机sun没有在icmp不可达报文中返回出口MTU值。【后面25.9中，将重新回到这个问题，用SNMP判断netb上的slip接口MTU值为1500？？？？】

11.7 用Traceroute确定路径MTU

尽管大多数的系统不支持路径MTU发现功能，但可以容易地修改traceroute程序，用它确定路径MTU。

文章图片
设置为路径MTU中最小的一个

怎么发现路径的MTU?
设置DF=1 ，然后发送不同的包，

文章图片
通过MTU的值不断减小尝试【因为没有MTU值返回】，如果有MTU值返回，就用这个MTU值吃到尝试 11.8 采用UDP的路径MTU发现

文章图片

文章图片
执行返回的结果

将采用它作为源站发送一份 6 5 0 字节数据报经 s l i p 。由于 s l i p 主机位于 M T U 为 2 9 6 的 S L I P 链路后，因此，任何长于 2 6 8 字节( 2 9 6- 2 0 - 8 ) 且 “ 不分片 ” 比特置为 1 的 U D P 数据都会使 b s d i 路由器产生 I C M P “不能分片”差错报文。

1~4行： DF=1 ，都会回ICMP差错，所以可以判断要设置DF=0
5行：发往目的地址的数据包不能够将DF=1 ，因此， IP进而将数据报在源站主机上进行分片。由于ICMP 不能分片报文并没有指出下一跳的MTU，因此，看来IP猜测MTU为576就行了。
第一份片：包含544字节的UDP数据，8字节UDP首部以及20的IP首部；因此总IP数据报长度是572字节，
6行：第二次分片包含剩余的106byteUDP数据和20字节IP首部。
7行：DF=1 ， bsdi 丢弃并返回ICMP差错，发生了IP定时器超时，通过IP查看是不是因为路径MTU增大而在此将DF=1，可以从19行和20行看出结果， IP在30秒就将DF=1，查看MTU是否增增大。
如果发送， ICMP有对应的MTU返回，下一次使用MTU返回的值进行传输就可以了；
11.9 UDP和ARP之间的交互作用

文章图片

在第一个ARP应答返回之前，总共产生了6个ARP请求

在接收到第一个ARP应答时(7行)，只发送最后一个数据报片(9行)

在大多数实现中，在等待一个ARP应答时，只将最后一个保温发送给特定目的主机

另一个无法解释的不正常的现象是， svr4 发挥7个，而不是6个ARP应答

没有看大搜ICMP消息的原因有两个《1》大多数的berkeley派生的实现从不产生差错，这些实现会设置定时器，也会在定时器溢出时候将数据片丢弃，，但是不生成ICMP差错《2》并未受到包含UDP首部的偏移量为0的第一个数据报片（这是被ARP锁丢弃的5个报文的第1个）。除非接收到第一个数据报片，否则并不要求任何实现产生ICMP差错。

11.10 最大UDP数据报长度

IP 数据报最大长度是65535byte，由IP首部长度字段限制的
遇到两个限制因素：《1》应用程序可能受到其他程序接口的限制。（socket api 提供了应用程序调用的函数，可以设置接收、发送缓存的长度）对于UDP socket，大部分系统提供了一个大于8192字节的UDP数据报《2》 TCP/IP 的内核实现，可能存在一些实现特性，使IP数据报长度小于65535字节。
与源端和目的端的实现有关

数据报截断

由于IP能够发送或接收特定长度的数据报并不意味着接收应用程序可以读取该长度的数据。 —— UDP编程接口允许应用程序制定每次返回的最大字节数。

接收到超过的长度 —— 数据报截断
Berkeley 版的socket API 对数据报进行截断，将多余的丢弃掉
SVR4 并没有截断数据报，超出部分数据在后面的读取中返回。它也不通知应用程序从单个UDP数据报中多次进行读取操作
TLI API 不丢弃数据，它返回一个标志标明可以获得更多的数据，，而应用程序后面的读操作将返回数据报其余部分。
11.11 ICMP源站抑制差错

文章图片

也可以使用UDP产生ICMP “源站抑制(source queench)”差错。当一个系统(路由器、主机)接收数据报的速度比其处理速度快时，可能产生着差错。[即使一个系统已经没有缓存并丢弃数据报，也不要求它一定要发送源站抑制报文。]

结果是如果采用UDP协议，那么BSD实现通常忽略其接收到的源站抑制报文【TCP接收源站抑制差错报文，并将放慢在该链接上的数据传输速度】。其部分原因在于，在接收到源站抑制差错报文时，导致源站抑制的进程可能已经中止了。

UDP 服务器的内容，暂时略过【这个地方，以后开发服务器，，再进行设置这个内容】
小结》》》》
U D P 是一个简单协议。它的正式规范是 R F C 7 6 8 [ P o s t e l 1 9 8 0 ] ，只包含三页内容。它向用户进程提供的服务位于 I P 层之上，包括端口号和可选的检验和。我们用 U D P 来检查检验和，并观察分片是如何进行的。
接着，我们讨论了 I C M P 不可达差错，它是新的路径 M T U发现功能中的一部分( 2 . 9 节)。用 Tr a c e r o u t e 和 U D P 来观察路径 M T U 发现过程。还查看了 U D P 和 A R P 之间的接口，大多数的 A R P 实现在等待 A R P 应答时只保留最近传送给目的端的数据报。
当系统接收 I P 数据报的速率超过这些数据报被处理的速率时，系统可能发送 I C M P 源站抑制差错报文。使用 U D P 时很容易产生这样的 I C M P 差错。