一、传输层

主要负责数据能够从发送端传输接收端

二、再谈端口号

端口号属于传输层
前面的文章中我提到过IP+端口号:表示某个主机对应的服务进程在全网中是唯一性，所以即使多个服务被部署到同一主机上，由于他们的端口号不同，当数据向上交付给应用层的时候，能够找到对应的服务

在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信
在这里插入图片描述

2.1 端口号划分

0 - 1023: 知名端口号, HTTP(80), FTP(21), SSH(22)等这些广为使用的应用层协议, 他们的端口号都是固定的，不能被bind
1024-65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的

三、查看网络状态—netstat

netstat是一个用来查看网络状态的重要工具.
语法： netstat [选项]
功能：查看网络状态
常用选项：
n 拒绝显示别名，能显示数字的全部转化成数字
l 仅列出有在 Listen (监听) 的服务状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项，默认不显示LISTEN相关

四、查看服务器进程ID—pidof

在查看服务器的进程id时非常方便.
语法： pidof [进程名]
功能：通过进程名, 查看进程id
如：pidof tcpserver
pidof tcpserver | xargs kill -9将pidof返回的id拼接在-9后面终止此进程

五、UDP协议端格式

在这里插入图片描述

解包：UDP协议采用固定长度的方式将报头和有效载荷分离
分用：根据分离出来的报头中的目的端口号，将有效载荷交付给上层服务进程/协议
UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)；如果我们需要传输的数据超过64K（字节）, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装

5.1 理解报头

Linux内核使用c语言写的，UDP属于OS,所以报头的本质是一个结构化数据对象(结构体或位段)

扫描二维码关注公众号，回复： 15181844 查看本文章

struct udp_hdr{
    
    
	uint16_t src_port;
	uint16_t dsc_port;
	uint16_t length;
	uint16_t check;
}

或
struct udp_hdr{
    
    
	unsigned int src_port:16;
	unsigned int dsc_port:16;
	unsigned int length:16;
	unsigned int check:16;
}

在这里插入图片描述

添加报头的实质是，将上层数据拷贝到缓冲区里，在缓冲区的前面填写上报头的字段，就形成一个报文继续向下交付。

接收方收到此报文会用一个指针指向该报文的头部，然后强转成struct udp_hdr类型提取报头中的字段，这期间不需要像应用层一样反序列化，OS会帮我们解决此问题。

六、UDP的特点

UDP传输过程类似寄信

无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
不可靠: 数据在传输过程中会发生丢包问题，UDP没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
面向数据报: 不能够灵活的控制读写数据的次数和数量

何为面向数据报？
应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并

例如：发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节

在UDP通信中，不需要考虑怎么完整读到一个数据，只需要关心结构化的数据序列化与反序列化

七、UDP的缓冲区问题

UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致（有序是可靠性的一种）; 如果缓冲区满了, 再到达的UDP数据就会被丢弃
UDP的一端可读可写，它也是全双工的

八、常见基于UDP的应用层协议

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

Linux【网络编程】之深入理解UDP协议