• UDP协议


    本篇介绍

    再谈端口号,并补充信息

    介绍netsta&pidof两个新指令


    UDP协议

    UDP协议格式

    理解报头是什么


    UDP特点介绍

    那些应用层协议基于UDP

    全双工概率补充

    在前面已经完成了应用层的基本内容,现在进入传输层

    传输层

    负责数据能够从发送端传输接收端.解决通信问题
     

    端口号

    补充1:再谈端口号
     

    端口号(Port)标识了一个主机上进行通信的不同的应用程序;
     

    在TCP/IP协议中, 用 "源IP", "源端口号", "目的IP", "目的端口号", "协议号" 这样一个五元组来标识一个通信(可以通过netstat -n查看)
     

            这里的通过端口号来标识不同的通信体现在:当你访问同一个网站,开两个窗口,这时候服务器无法通过源IP来区别,但是它可以通过源端口号(在进行网络通信的时候需要绑定源端口号,这一点在定制简单的网络服务器讲过)来区别,上图中的6指的是协议号,后续再介绍

    补充2:端口号范围划分
     

    端口号在传输层

    0 - 1023: 知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的.


    1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的

    这一点体现在我们在绑定端口号的时候,会发现有些端口号是无法被绑定的

    补充3:认识知名端口号(Well-Know Port Number)
     

            有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号:

    ssh服务器, 使用22端口
    ftp服务器, 使用21端口
    telnet服务器, 使用23端口
    http服务器, 使用80端口
    https服务器, 使用443

    执行下面的命令, 可以看到知名端口号
    cat /etc/services

    我们自己写一个程序使用端口号时, 要避开这些知名端口号
     

    两个问题
     

    1. 一个进程是否可以bind多个端口号?
    2. 一个端口号是否可以被多个进程bind?

    新指令

    netsta

    netstat是一个用来查看网络状态的重要工具
    语法: netstat [选项]
    功能:查看网络状态

    常用选项:
    n 拒绝显示别名,能显示数字的全部转化成数字
    l 仅列出有在 Listen (监听) 的服务状态
    p 显示建立相关链接的程序名
    t (tcp)仅显示tcp相关选项
    u (udp)仅显示udp相关选项
    a (all)显示所有选项,默认不显示LISTEN相关

    Recv-Q Send-Q 接收与发送了多少报文,不过这里通常立马就被处理了,所以这里看不到

    local Address 本地地址

    Foreign Address 对方地址

    pidof
     

    在查看服务器的进程id时非常方便.
    语法: pidof [进程名]
    功能:通过进程名, 查看进程id
     

    UDP协议
     

    无论学习网络协议中的哪一层协议,都需要回答这两个问题 

    UDP协议端格式
     

    为什么都是16位:因为操作系统的内核是16位,这是在进行统一

    16位UDP长度:表示整个数据报(UDP首部+UDP数据)的最大长度;


    检验和:如果校验和出错, 就会直接丢弃

            这里的数据指的就是从应用层传过来的数据,在传输层添加了上述的报头,这就是传输层对应用层数据进行的封装操作

    理解报头是什么东西

    位段就是这样的,两者都是一样的

    UDP的特点

    UDP传输的过程类似于寄信(直接发送,不需要考虑对方状态).


    无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
    不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息,不做任何防止传输错误的行为,只需要把数据发送到下层协议它的工作就完成了;
    面向数据报: 不能够灵活的控制读写数据的次数和数量,它发送几个对方就会收到几个数据报(不考虑丢包),发送几次,对面就要接收几次,对方要么不读,一旦读取就一定是一个完整的独立的数据报;

    面向数据报
     

    应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;


    用UDP传输100个字节的数据:
    如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;

     

    UDP的缓冲区
     

    UDP没有真正意义上的发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;


    UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;
    UDP的socket既能读, 也能写, 这个概念叫做
    全双工

    UDP使用注意事项
     

    我们注意到, UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部).
    然而64K在当今的互联网环境下, 是一个非常小的数字.
    如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装,也就是说需要手动去分割,再发送;

     

    基于UDP的应用层协议

    NFS: 网络文件系统
    TFTP: 简单文件传输协议
    DHCP: 动态主机配置协议
    BOOTP: 启动协议(用于无盘设备启动)
    DNS: 域名解析协议

    DNS:


    当然, 也包括你自己写UDP程序时自定义的应用层协议;
     

    补充4:全双工

    UDP协议完了!其实主要是UDP并没有很多的处理行为,后续的TCP协议才是重头戏

    下文预告:TCP协议​​​​​​​

  • 相关阅读:
    vscode在windows系统上进行C/C++环境配置
    解决方案 | 法大大电子签赋能电力交易全流程电子化
    Vite打包优化插件
    Python之函数进阶-柯里化
    npm publish包报404,is not in the npm registry错误
    Linux CentOS7 vim多文件与多窗口操作
    【数据结构与算法】之深入解析“两个有序数组的第K小乘积”的求解思路与算法示例
    759页14万字智慧大楼弱电智能化规划设计方案
    Linux地址映射那些事,堪称初学者的噩梦!
    使用Optional和直接返回null,哪个更好?
  • 原文地址:https://blog.csdn.net/weixin_67595436/article/details/132846123