认识知名端口号，执行cat /ect/services 可以查看。我们在自己写程序使用端口号时，要避开这些知名端口号
我们再来学习udp协议
面向数据报的协议---不灵活地控制数据的读写次数和数量。读写字节个数是一致的，边界明显（俄国：写信 收信）
http/网络版本计算器都会序列化成为字节流
udp协议需要分离与分用？我们来重点理解分离与分用
分离？
udp是八字节定长报头，数据报除去定长报头后剩下的就是有效载荷。报头和有效载荷分离，有效载荷分离后将自己的有效载荷交给上层的哪个协议
分用？
有目的端口号。系统根据目的端口号查询这个表，找到对应的应用进程，再把 "分离" 后得到的有效载荷，准确交付给该进程内核协议是16位的，使用端口号也是16位的
本质是结构体
协议的报头部分有着固定的格式和字段，很适合用结构体这种数据类型定义和解析
struct udphdr{
__be16 source; // 源端口号
__be16 dest; // 目的端口号
__be16 len; // UDP数据报长度（包括报头和数据部分）
__be16 check; // 校验和
};
报文和报文之间都是有边界的，os之间，直接传递结构体对象
直接交换二进制流
报文:
数据，每个长度交付上层，都是固定的
缓冲区的问题
没有真正意义上的发送缓冲区。因为udp传输不能保证可靠性，把udp的数据缓存起来没有意义
具有接收缓冲区，上层忙的时候可以有自己的缓存。但不能保证收到的和发送的udp报的顺序一致，缓冲区满了，后面的数据就会被丢弃
++udp：传输层的一个协议，给上层提供最简单的面向数据报的通信服务++
报文的理解
在OS内部，一定可能会同时存在大量的报文，os就必须管理这些报文
数据链路层存在套接字缓冲区sk_buff，os将sk_buff上交给网络层
应用层正在进行报文的解析，处理，不会影响os从网络中读取数据
报文=报头+有效载荷
所谓的封装和解包，本质上是移动套接字缓冲区内的data指针在缓冲区中的指向