一个进程可以绑定多个端口一个端口只能被一个进程绑定如果校验和出错udp直接丢弃报文发送方不知道所以无连接不可靠UDP使用用户数据报协议不存在数据粘包问题UDP协议报头本质是结构体协议栈传输层往下属于OS部分OS是C语言写的客户端和服务端可以直接传结构体变量封装的本质是对结构体变量的拷贝封装完传输层后下面对于网络层的报头封装也是类似的如何理解报文OS系统内可能会有很多报文要进行管理先描述再组织应用层发送数据传输层构建struct sk_buff结构体对象开辟缓冲区拷贝应用层数据到缓冲区接收方数据链路层把报文交给网络层网络层拿到之后创建sk_buff开辟缓冲区把拿到的数据拷贝到缓冲区报文sk_buff缓冲区也就是描述报文的内核结构体变量存储报文的缓冲区OS内对报文的管理-对链表的增删查改报文贯穿协议栈封装和解包最核心的是移动指针快报文不变data指针在上/下移协议栈就是软件层交给上层就是回调交给下层就是调用下层函数传递sk_buff结构体变量指针本质都是调用函数C语言面向过程函数调用传参做协议栈级别的流动当收到报文如何利用文件原理把底层的报文读到应用层进程角度如何把sk_buff读上来但其实底层创建的不是struct sock而是struct inet_sock有一些类似基类struct socket里的sk指针指向udp_sock或者tcp_sock来使用不同的协议也就是多态udp是无连接的在应用层通信之前是不需要建立连接的不可靠网络路由器/接收方把报文丢弃发送方不知道不关心不重传但不排除上层用户维护可靠性UDP面向数据报把100B数据交给UDP就发送100B接收也只能接收100B不能分多次接收内核层面上解决了报文之间边界的问题UDP协议不可靠为什么还要有呢UDP不可靠不是数据传不过去而是丢包了不关心当代网络环境UDP丢包概率不高网络状况好不会丢包只有网络状况极致差才会丢包也即UDP不可靠不代表不可用可靠性可要做更多的工作知道丢包超时重传tcp面向连接连接建立好为了增加可靠性UDP本身不可靠少做了很多工作简单内核角度报文只有4个字段应用层面编码方面没有复杂的获取链接、管理连接可能相对快一些但是tcp也有很多保证快的设定在对于丢包数据不敏感的场景中快速使用UDP做内容的分发不可靠是UDP的特点而不是缺点应用层自己做可靠性TCP支持全双工本质是TCP内部维护接收和发送缓冲区用户层发数据把数据拷贝到发送缓冲区拷贝到对方的接收缓冲区UDP也是全双工没有真正意义上的发送缓冲区因为不需要缓冲数据暂时保存数据到内核为了支持可靠性数据报丢了要重传但从发送到丢有一段时间发送到网络里之后在TCP上不能直接删因为万一丢了要重传所以UDP不需要发送缓冲区直接把数据交给网络层UDP有接收缓冲区不保证收到报文的顺序和发送顺序一致乱序不可靠因为报文从A主机发送到B主机跨网络传输可能选择路径不同如果接收缓冲区满了那收到的sk_buff就丢弃而报文长度是16bits最大长度是2^1664KB在当前网络环境其实比较小就在应用层进行分包发送接收方进行拼接电脑没有联网其实是没有IP的连上路由器自动分配IP地址动态获取IP地址的方式是DHCP协议属于应用层协议底层用的是UDP局域网通信丢包的概率低 不用复杂的建立连接过程把IP地址快速给用户DNS域名解析协议域名解析要访问域名解析服务器通信用的是DNS底层是UDP应用场景直播内容分发录播信息不在服务器端而是购买了网络服务类似图床用户请求客户端包了浏览器去CDN服务器请求视频块在本地拼接看到视频直播/录播CDN为了快速分发用的是UDP协议TCP的话网络服务要和那么多用户建立TCP连接太慢/重网络电视直播游戏直播实时音视频传输UDP用户量10w几百万用户的直播间建立连接成本高UDP简单multiplayer游戏传感器互联网实时性要求高用户量比较大局域网通信