一、再谈端口号

1.1 理解端口号

网络中两台主机进行通信的本质是主机的进程间进行通信，端口号标识了主机进行通信的不同的应用程序。

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

1.2 端口号划分

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

1.3 知名端口号

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

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

当我们自己写程序绑定端口号时要避开这些知名端口号

问题一： 一个进程是否可以 bind 多个端口号?

可以。这个问题可以理解为一个进程是否可以创建多个网络套接字,每个socket都可以独立地绑定到一个不同的端口号上。在Linux等操作系统中，每个socket都是一个独立的文件描述符，而每个文件描述符都可以与一个特定的端口号相关联。

问题二：一个端口号是否可以被多个进程绑定？

不可以，因为端口号要标识进程的唯一性。因为网络通信中的端口号是一个用于标识目标应用程序或服务的唯一数字，多个进程绑定到同一端口号通常会引发冲突和混乱。当一个进程已经绑定到一个端口号时，操作系统通常会阻止其他进程尝试绑定到相同的端口号，这是为了确保数据包能够正确地路由到正确的应用程序，避免混淆。

二、UDP协议

2.1 UDP协议格式

• 16 位 UDP 长度, 表示整个数据报(UDP 首部+UDP 数据)的最大长度;
•  如果校验和出错, 就会直接丢弃;
• 我们自己写程序时将端口号定义为uint_16的类型的原因是因为协议就是这样规定的，我们在应用层发送数据并不是直接发送给对方的应用层，而是首先转发给我们的传输层

2.2 UDP的特点

UDP 传输的过程类似于寄信.

• 无连接: 知道对端的 IP 和端口号就直接进行传输, 不需要建立连接;
• 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP 协议层也不会给应用层返回任何错误信息;
• 面向数据报: 不能够灵活的控制读写数据的次数和数量，应用层交给 UDP 多长的报文, UDP 原样发送, 既不会拆分, 也不会合并，如果发送端调用一次 sendto, 发送 100 个字节, 那么接收端也必须调用对应的 一次 recvfrom, 接收 100 个字节; 而不能循环调用 10 次 recvfrom, 每次接收 10 个字节;

2.3 UDP 的缓冲区

TCP支持全双工的原因是tcp套接字内部存在两个缓冲区，发送缓冲区和接收缓冲区。而UDP支持全双工的原因也是源于他的缓冲区：

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

2.4 UDP 使用注意事项

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

2.5 深入理解报头和有效载荷

1. 如何将报头和有效载荷分离？

UDP的报头是固定长度的，分为四部分，每部分16位一共8个字节，数据报前8个字节就是报头，而数据报的总长度我们是知道的，剩下的就是有效载荷的长度

2. 如何将有效载荷进行分用？

当主机收到对应的报文，报头中存在目的端口号，而这个端口号标识的就是本主机的某一个进程，只需要反向查表就可以知道要将有效载荷的数据发送给哪一个进程了

3. 如何理解报文

udp报头实际就是一个结构化数据

struct udp_hdr
{
    uint16_t src_port;// 源端口
    uint16_t dsc_port;// 目的端口
    uint16_t length;// UDP长度
    uint16_t check;// 校验和
};

UDP存在缓冲区的意义是他可以保存一些报文，除了上层正在处理的报文外，OS可能还会不断地从硬件读取报文，所以有的报文可能正在被处理，有的报文可能需要放到缓冲区中，并且有的报文需要向上交付，有的需要向下交付，总之OS内部可能同时存在许多的报文，那OS就需要管理这些报文，那如何管理呢？先描述在组织，OS内部存在一个struct sk_buff 的结构体用于描述报文，这个结构体内部存在两个指针（不仅只有两个）char* head和char* data，当应用层向传输层发送数据时，传输层首先会开辟一段缓冲区，head和data刚开始会指向这个缓冲区中间的部分，可以将应用层发送的数据放到data所指的区域，这样有效载荷就放好了

然后head-=（struct udp_header）向前移动传输层报头大小字节的单位，将指针强转为struct udp_header*的类型，通过->就可以添加报头信息，这就是报头添加的过程。在向下叫付时报头添加的方式类似，head指针向前移动就可以添加报头，向移动就可以解析报头。

OS内部可能存在许多这样的结构体，在内核中他们用双链表联系起来，这样对报文的管理就变为了对链表结点的管理，交付时只需要将对应节点交付即可