【用户数据报服务只是在IP所提供的服务基础上增加了多路复用和解复用，没有增加更多的服务。】
UDP：User Datagram Protocol [RFC 768]（用户数据报协议）
- “no frills,” “bare bones” Internet传输协议
- “尽力而为”的服务，报文段可能【UDP能够提供进程到进程的，IP只能提供主机到主机的服务，除此之外，UDP没有在IP基础之上增加额外的服务品质。所以UDP向上层提供的服务像IP一样，也是尽力而为的】
- 丢失
- 送到应用进程的报文段乱序【先传的延时比较大，后传的延时比较小，后传的就先到了，也有可能是乱序】
- 无连接：
- UDP发送端和接收端之间没有握手【一个socket和本地的IP和UDP端口相捆绑，不知道跟谁要通信、也不知道是谁发给我的；因为没有握手，所以跟谁要通信，是上层告诉UDP的，告诉了socket、要发的内容、还有对方的IP和port（&cad）】
- 每个UDP报文段都被独立地处理
- UDP被用于
- 流媒体（丢失不敏感，速度敏感、应用可控制传输速率）【特别是实时流媒体的应用；第二种是事务性的应用，一次往返搞定的】
- DNS
- SNMP
- 在UDP上可行可靠传输：
- 在应用层增加可靠性
- 应用特定的差错恢复
UDP：用户数据报协议【为什么叫数据报，因为他是无连接的，每一个UDP的协议数据单元都是独立发送的。IP也叫数据报，所以讲到数据报这个词可能要结合上下文来看是UDP的数据报还是IP的数据报】
【8个字节的头部，然后是载荷部分，载荷是应用进程交给UDP，让他传的报文的内容，是UDP的SDU（服务数据单元）】
【8个字节的头部包括源端口号（2个字节）、目标端口号（2个字节）、长度（以字节为单位，包括头部的整个的长度，代表多长的UDP报文）、校验和（EDC：属于差错检验码；携带的数据部分、当然还包括头部的一些信息，跟校验和之间是符合约定的、差错控制编码的一些关系；在源端做校验和的计算，到目标端再判断一下校验的范围、和校验和本身是不是还符合约定的差错控制编码的关系，如果符合的话就认为他不出错，如果不符合就认为他出错。所以校验和的主要目的是判断UDP的数据报，包括头部、载荷，在传输的过程有没有出错，如果出错、没有通过校验就会被丢掉。所以最终出错的表现是UDP数据报被扔掉，应用进程收不到message，所以错就是表现为丢失）】
为什么要有UDP？
- 不建立连接（建立连接会增加延时）
- 简单：在发送端和接收端没有连接状态【服务器不维护客户端的状态，客户端也不需要维护我有没有和哪个远端的应用程序在通信的状态】
- 报文段的头部很小（开销小）【效率高】【而TCP头部是20个字节】
- 无拥塞控制和流量控制：UDP可以尽可能快的发送报文段
- 应用->传输的速率 = 主机->网络的速率【这种特性对某些原因非常有用，如实时多媒体应用】
【要在UDP上做但又希望应用要可靠要怎么办？在UDP上去跑应用，但是在应用进程自己内部实现可靠性。为什么没有第三个协议？因为UDP和TCP这两种类型的协议能够支撑85%以上的应用。整个协议栈不再安排第三个协议，因为再在安排第三个协议他们的协议栈比较复杂，他们之间的协调存在很大的问题】
UDP校验和
目标：检测在被传输报文段中的差错（如比特反转）
发送方：
- 将报文段的内容视为16比特的整数
- 校验和：报文段的加法和（1的补运算）
- 发送方将校验和放在UDP的检验和字段
【在发送方做校验，使得校验范围和校验和，EDC部分符合某种约定的差错控制编码的关系，这个差错控制编码的关系具体到这里就是和的关系】
接收方：
- 计算接收到的报文段的校验和
- 检查计算出的校验和与校验和字段的内容是否相等：
- 不相等——检测到差错
- 相等——没有检测到差错，但也许还是有差错
- 残存错误
【同样计算校验和，然后我计算的校验和和携带过来的校验和是否一样，一样的话就通过校验，不一样就一定错】
【没有通过校验一定错，通过了校验不一定对】
【在传输的过程当中，保护的范围如果出了任何一个比特的错误他都有可能检查出来，那么EDC主要作用就是差错检测的作用】
Internet校验和的例子
发送端：
把报文段分为一个个16比特，不足的补0，把每个16比特加起来，加起来求得的和叫check sum（检验和）
求和的细节：
进位回滚——16比特和16比特相加出现进位的情况就把他拉到最低位再加
真正的EDC是所有16比特加起来的和的反码（0变成1，1变成0）
接收端：
把报文段分为一个个16比特，不足的补0，把每个16比特和EDC加起来，进位回滚，最后得的和是16位全1，那么就判定通过了校验，在传输过程没有出错。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
