当前位置：首页 > news >正文

Linux网络socket套接字(上)(2)

news 2025/8/2 20:50:54

文章目录

前言
一、预备知识
- 理解源IP地址和目的IP地址
- 理解源MAC地址和目的MAC地址
- 理解源端口号和目的端口号
- PORT VS PID
- 认识TCP协议和UDP协议
- 网络字节序
二、socket套接字
- socket 常见API
- sockaddr 结构体
三、简单的UDP网络程序
- 服务端创建套接字
- 服务端绑定
- 字符串IP VS 整数IP
- 运行服务器
总结

前言

难死了，难死了，这篇真的是
我靠，我感觉 Linux 比 Cpp 还难！

一、预备知识

在正式讲解套接字之前，我们不妨先来看看一些预备知识来酝酿一下

理解源IP地址和目的IP地址

因特网上的每台计算机都有一个唯一的IP地址，如果一台主机上的数据要传输到另一台主机，那么对端主机的IP地址就应该作为该数据传输时的目的IP地址。但仅仅知道目的IP地址是不够的，当对端主机收到该数据后，对端主机还需要对该主机做出响应，因此对端主机也需要发送数据给该主机，此时对端主机就必须知道该主机的IP地址。因此一个传输的数据当中应该涵盖其源IP地址和目的IP地址，目的IP地址表明该数据传输的目的地，源IP地址作为对端主机响应时的目的IP地址。

在数据进行传输之前，会先自顶向下贯穿网络协议栈完成数据的封装，其中在网络层封装的IP报头当中就涵盖了源IP地址和目的IP地址。而除了源IP地址和目的IP地址之外，还有源MAC地址和目的MAC地址的概念。

理解源MAC地址和目的MAC地址

大部分数据的传输都是跨局域网的，数据在传输过程中会经过若干个路由器，最终才能到达对端主机。

在这里插入图片描述
源MAC地址和目的MAC地址是包含在链路层的报头当中的，而MAC地址实际只在当前局域网内有效，因此当数据跨网络到达另一个局域网时，其源MAC地址和目的MAC地址就需要发生变化，因此当数据达到路由器时，路由器会将该数据当中链路层的报头去掉，然后再重新封装一个报头，此时该数据的源MAC地址和目的MAC地址就发生了变化。

例如，在图中主机１向主机２发送数据的过程中，数据的源MAC地址和目的MAC地址的变化过程如下：

时间轴	源MAC地址	目的MAC地址
刚开始	主机1的MAC地址	路由器A的MAC地址
经过路由器A之后	路由器A的MAC地址	路由器B的MAC地址
经过路由器B之后	路由器B的MAC地址	路由器C的MAC地址
经过路由器C之后	路由器C的MAC地址	路由器D的MAC地址
经过路由器D之后	路由器D的MAC地址	主机2的MAC地址

因此数据在传输的过程中是有两套地址：

一套是源IP地址和目的IP地址，这两个地址在数据传输过程中基本是不会发生变化的（存在一些特殊情况，比如在数据传输过程中使用NET技术，其源IP地址会发生变化，但至少目的IP地址是不会变化的）。
另一套就是源MAC地址和目的MAC地址，这两个地址是一直在发生变化的，因为在数据传输的过程中路由器不断在进行解包和重新封装。

理解源端口号和目的端口号

首先我们需要明确的是，两台主机之间通信的目的不仅仅是为了将数据发送给对端主机，而是为了访问对端主机上的某个服务。比如我们在用百度搜索引擎进行搜索时，不仅仅是想将我们的请求发送给对端服务器，而是想访问对端服务器上部署的百度相关的搜索服务。

socket通信的本质

现在通过IP地址和MAC地址已经能够将数据发送到对端主机了，但实际我们是想将数据发送给对端主机上的某个服务进程，此外，数据的发送者也不是主机，而是主机上的某个进程，比如当我们用浏览器访问数据时，实际就是浏览器进程向对端服务进程发起的请求。

在这里插入图片描述
也就是说，socket通信本质上就是两个进程之间在进行通信，只不过这里是跨网络的进程间通信。比如逛淘宝和刷抖音的动作，实际就是手机上的淘宝进程和抖音进程在和对端服务器主机上的淘宝服务进程和抖音服务进程之间在进行通信。

因此进程间通信的方式除了管道、消息队列、信号量、共享内存等方式外，还有套接字，只不过前者是不跨网络的，而后者是跨网络的。

端口号

实际在两台主机上，可能会同时存在多个正在进行跨网络通信的进程，因此当数据到达对端主机后，必须要通过某种方法找到该主机上对应的服务进程，然后将数据交给该进程处理。而当该进程处理完数据后还要对发送端进行响应，因此对端主机也需要知道，是发送端上的哪一个进程向它发送的数据请求。

端口号（port）的作用实际就是标识一台主机上的一个进程。

端口号是传输层协议的内容。
端口号是一个2字节16位的整数。
端口号用来标识一个进程，告诉操作系统，当前的这个数据要交给哪一个进程来处理。
一个端口号只能被一个进程占用。

由于IP地址能够唯一标识公网内的一台主机，而端口号能够唯一标识一台主机上的一个进程，因此用IP地址+端口号就能够唯一标识网络上的某一台主机的某一个进程。

当数据在传输层进行封装时，就会添加上对应源端口号和目的端口号的信息。这时通过源IP地址+源端口号就能够在网络上唯一标识发送数据的进程，通过目的IP地址+目的端口号就能够在网络上唯一标识接收数据的进程，此时就实现了跨网络的进程间通信。

注意：因为端口号是隶属于某台主机的，所以端口号可以在两台不同的主机当中重复，但是在同一台主机上进行网络通信的进程的端口号不能重复。此外，一个进程可以绑定多个端口号，但是一个端口号不能被多个进程同时绑定。

理解socket这个名字

socket在英文上有“插座”的意思，插座上有不同规格的插孔，我们将插头插入到对应的插孔当中就能够实现电流的传输。

在进行网络通信时，客户端就相当于插头，服务端就相当于一个插座，但服务端上可能会有多个不同的服务进程（多个插孔），因此当我们在访问服务时需要指明服务进程的端口号（对应规格的插孔），才能享受对应服务进程的服务。

PORT VS PID

端口号（port）的作用唯一标识一台主机上的某个进程，进程ID（PID）的作用也是唯一标识一台主机上的某个进程，那在进行网络通信时为什么不直接用PID来代替port呢？

进程ID（PID）是用来标识系统内所有进程的唯一性的，它是属于系统级的概念；而端口号（port）是用来标识需要对外进行网络数据请求的进程的唯一性的，它是属于网络的概念。

一台机器上可能会有大量的进程，但并不是所有的进程都要进行网络通信，可能有很大一部分的进程是不需要进行网络通信的本地进程，此时PID虽然也可以标识这些网络进程的唯一性，但在该场景下就不太合适了。

比如每个人都有自己的身份证号，身份证号已经可以标识我们的唯一性了，但是当我们到了学校还是会有学号，到了公司还是会有工号。这是为什么呢？为什么不直接用身份证号来代替学号和工号呢？

因为身份证号是国家用于行政管理时用的编号，而学号是学校用于管理学生时用的编号，工号是公司用于管理员工时用的编号。但并不是全中国人都在某所学校或某家公司，因此在学校或公司当中，没必要用身份证号来标识每个人的唯一性。此时就出现了学号和工号，在学号和工号当中还可以包含一些便于管理的信息，比如入学（入职）年份、性别等信息。

也就是说，在不同的场景下可能需要不同的编号来标识某种事物的唯一性，因为这些编号更适合用于该场景。

底层如何通过port找到对应进程的？

实际底层采用哈希的方式建立了端口号和进程PID或PCB之间的映射关系，当底层拿到端口号时就可以直接执行对应的哈希算法，然后就能够找到该端口号对应的进程。

认识TCP协议和UDP协议

网络协议栈是贯穿整个体系结构的，在应用层、操作系统层和驱动层各有一部分。当我们使用系统调用接口实现网络数据通信时，不得不面对的协议层就是传输层，而传输层最典型的两种协议就是 TCP协议和 UDP协议。

TCP协议

TCP协议叫做传输控制协议（Transmission Control Protocol），TCP协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP协议是面向连接的，如果两台主机之间想要进行数据传输，那么必须要先建立连接，当连接建立成功后才能进行数据传输。其次，TCP协议是保证可靠的协议，数据在传输过程中如果出现了丢包、乱序等情况，TCP协议都有对应的解决方法。

UDP协议

UDP协议叫做用户数据报协议（User Datagram Protocol），UDP协议是一种无需建立连接的、不可靠的、面向数据报的传输层通信协议。

使用UDP协议进行通信时无需建立连接，如果两台主机之间想要进行数据传输，那么直接将数据发送给对端主机就行了，但这也就意味着UDP协议是不可靠的，数据在传输过程中如果出现了丢包、乱序等情况，UDP协议本身是不知道的。

既然UDP协议是不可靠的，那为什么还要有UDP协议的存在？

TCP协议是一种可靠的传输协议，使用TCP协议能够在一定程度上保证数据传输时的可靠性，而UDP协议是一种不可靠的传输协议，UDP协议的存在有什么意义？

首先，可靠是需要我们做更多的工作的，TCP协议虽然是一种可靠的传输协议，但这一定意味着TCP协议在底层需要做更多的工作，因此TCP协议底层的实现是比较复杂的，我们不能只看到TCP协议面向连接可靠这一个特点，我们也要能看到TCP协议对应的缺点。

同样的，UDP协议虽然是一种不可靠的传输协议，但这一定意味着UDP协议在底层不需要做过多的工作，因此UDP协议底层的实现一定比TCP协议要简单，UDP协议虽然不可靠，但是它能够快速的将数据发送给对方，虽然在数据在传输的过程中可能会出错。

编写网络通信代码时具体采用TCP协议还是UDP协议，完全取决于上层的应用场景。如果应用场景严格要求数据在传输过程中的可靠性，此时我们就必须采用TCP协议，如果应用场景允许数据在传输出现少量丢包，那么我们肯定优先选择UDP协议，因为UDP协议足够简单。

注意：一些优秀的网站在设计网络通信算法时，会同时采用TCP协议和UDP协议，当网络流畅时就使用UDP协议进行数据传输，而当网速不好时就使用TCP协议进行数据传输，此时就可以动态的调整后台数据通信的算法。

网络字节序

数据拥有高权值位和低权值位，比如在 32 位操作系统中，十六进制数 0x11223344，其中的 11 称为最高权值位，44 称为最低权值位
内存有高地址和低地址之分

如果将数据的高权值存放在内存的低地址处，低权值存放在高地址处，此时就称为 大端字节序，反之则称为小端字节序，这两种字节序没有好坏之分，只是系统设计者的使用习惯问题，比如我当前的电脑在存储数据时，采用的就是 小端字节序 方案

在这里插入图片描述

通过内存单元可以看到，使用小端字节序时数据是倒着放的，大端字节序就是正着存放了

在网络出现之前，使用大端或小端存储都没有问题，网络出现之后，就需要考虑使用同一种存储方案了，因为网络通信时，两台主机存储方案可能不同，会出现无法解读对方数据的问题

如果你是网络标准的设计者，你会如何解决？

解决方案1：数据发送前，给报文中添加大小端的标记字段，待数据递达后，对端在根据标志位进行解读，再进行转换。这个方案实现起来不太方便，并且给每一个报文都添加标记字段这个行为比较浪费
解决方案2：书同文，车同轨，直接统一标准。这种解决方案就很彻底了，直接从根源上解决问题，也更方便

顶层设计者采用了解决方案2，TCP/IP 协议规定：网络中传输的数据，统一采用大端存储方案，也就是网络字节序，现在大端/小端称为主机字节序

发送数据时，将主机字节序转化为网络字节序，接收到数据后，再转回主机字节序就好了，完美解决不同机器中的大小端差异，可以用下面这批库函数进行转换，在发送 / 接收时，调用库函数进行转换即可

#include <arpa/inet.h>// 主机字节序转网络字节序
uint32_t htonl(uint32_t hostlong); 	// l 表示32位长整数
uint16_t htons(uint16_t hostshort);	// s 表示16位短整数// 网络字节序转主机字节序
uint32_t ntohl(uint32_t netlong); 	// l 表示32位长整数
uint16_t ntohs(uint16_t netshort);	// s 表示16位短整数

二、socket套接字

socket 常见API

socket 套接字提供了下面这一批常用接口，用于实现网络通信

#include <sys/types.h>
#include <sys/socket.h>					// 创建socket文件描述符（TCP/UDP    服务器/客户端）
int socket(int domain, int type, int protocol);// 绑定端口号（TCP/UDP    服务器）
int bind(int socket, const struct sockaddr* address, socklen_t address_len);// 开始监听socket (TCP	服务器)
int listen(int socket, int backlog);// 接收连接请求 (TCP	服务器)
int accept(int socket, struct sockaddr* address, socklen_t* address_len);// 建立连接 (TCP	客户端)
int connect(int sockfd, const struct sockaddr* addr, socklen_t addrlen);

可以看到在这一批 API 中，频繁出现了一个结构体类型 sockaddr，该结构体支持网络通信，也支持本地通信

socket 套接字就是用于描述 sockaddr 结构体的字段，复用了文件描述符的解决方案

sockaddr 结构体

socket 这套网络通信标准隶属于 POSIX 通信标准，该标准的设计初衷就是为了实现可移植性，程序可以直接在使用该标准的不同机器中运行，但有的机器使用的是网络通信，有的则是使用本地通信，socket 套接字为了能同时兼顾这两种通信方式，提供了 sockaddr 结构体

由 sockaddr 结构体衍生出了两个不同的结构体：sockaddr_in 网络套接字、sockaddr_un 域间套接字，前者用于网络通信，后者用于本地通信

可以根据 16 位地址类型，判断是网络通信，还是本地通信
在进行网络通信时，需要提供 IP 地址、端口号等网络通信必备项，本地通信只需要提供一个路径名，通过文件读写的方式进行通信（类似于命名管道）

在这里插入图片描述
socket 提供的接口参数为 sockaddr*，我们既可以传入 &sockaddr_in 进行网络通信，也可以传入 &sockaddr_un 进行本地通信，传参时将参数进行强制类型转换即可，这是使用 C语言实现多态的典型做法，确保该标准的通用性 > 为什么不将参数设置为 void* ？ > 因为在该标准设计时，C语言还不支持 void* 这种类型，为了确保向前兼容性，即便后续支持后也不能进行修改了

三、简单的UDP网络程序

服务端创建套接字

我们把服务器封装成一个类，当我们定义出一个服务器对象后需要马上初始化服务器，而初始化服务器需要做的第一件事就是创建套接字。

socket函数

创建套接字的函数叫做socket，该函数的函数原型如下：

int socket(int domain, int type, int protocol);

参数说明：

domain：创建套接字的域或者叫做协议家族，也就是创建套接字的类型。该参数就相当于 struct sockaddr 结构的前16个位。如果是本地通信就设置为AF_UNIX，如果是网络通信就设置为 AF_INET（IPv4）或 AF_INET6（IPv6）。
type：创建套接字时所需的服务类型。其中最常见的服务类型是 SOCK_STREAM 和 SOCK_DGRAM ，如果是基于UDP的网络通信，我们采用的就是SOCK_DGRAM，叫做用户数据报服务，如果是基于TCP的网络通信，我们采用的就是 SOCK_STREAM ，叫做流式套接字，提供的是流式服务。
protocol：创建套接字的协议类别。你可以指明为 TCP 或 UDP ，但该字段一般直接设置为0就可以了，设置为0表示的就是默认，此时会根据传入的前两个参数自动推导出你最终需要使用的是哪种协议。

返回值说明：

套接字创建成功返回一个文件描述符，创建失败返回-1，同时错误码会被设置。

我相信你一定和我一样好奇这个 socket函数底层到底做了什么？

socket函数是被进程所调用的，而每一个进程在系统层面上都有一个进程地址空间PCB（task_struct）、文件描述符表（files_struct）以及对应打开的各种文件。而文件描述符表里面包含了一个数组fd_array，其中数组中的0、1、2下标依次对应的就是标准输入、标准输出以及标准错误。

在这里插入图片描述
当我们调用 socket函数创建套接字时，实际相当于我们打开了一个“网络文件”，打开后在内核层面上就形成了一个对应的struct file结构体，同时该结构体被连入到了该进程对应的文件双链表，并将该结构体的首地址填入到了fd_array数组当中下标为3的位置，此时fd_array数组中下标为3的指针就指向了这个打开的“网络文件”，最后3号文件描述符作为socket函数的返回值返回给了用户。

在这里插入图片描述
其中每一个 struct file 结构体中包含的就是对应打开文件各种信息，比如文件的属性信息、操作方法以及文件缓冲区等。其中文件对应的属性在内核当中是由 struct inode 结构体来维护的，而文件对应的操作方法实际就是一堆的函数指针（比如 read* 和 write* ）在内核当中就是由 struct file_operations 结构体来维护的。而文件缓冲区对于打开的普通文件来说对应的一般是磁盘，但对于现在打开的 “网络文件” 来说，这里的文件缓冲区对应的就是网卡。

在这里插入图片描述
对于一般的普通文件来说，当用户通过文件描述符将数据写到文件缓冲区，然后再把数据刷到磁盘上就完成了数据的写入操作。而对于现在 socket函数打开的“网络文件”来说，当用户将数据写到文件缓冲区后，操作系统会定期将数据刷到网卡里面，而网卡则是负责数据发送的，因此数据最终就发送到了网络当中。

服务端创建套接字

当我们在进行初始化服务器创建套接字时，就是调用 socket函数创建套接字，创建套接字时我们需要填入的协议家族就是 AF_INET ，因为我们要进行的是网络通信，而我们需要的服务类型就是 SOCK_DGRAM ，因为我们现在编写的 UDP服务器是面向数据报的，而第三个参数之间设置为0即可。

class UdpServer								
{
public:bool InitServer(){// 创建套接字_sockfd = socket(AF_INET, SOCK_DGRAM, 0);if (_sockfd < 0){ // 创建套接字失败std::cerr << "socket error" << std::endl;return false;}std::cout << "socket create success, sockfd: " << _sockfd << std::endl;return true;}~UdpServer(){if (_sockfd >= 0){close(_sockfd);}};private:int _sockfd; //文件描述符
};

注意：当析构服务器时，我们可以将 sockfd 对应的文件进行关闭，但实际上不进行该操作也行，因为一般服务器运行后是就不会停下来的。

这里我们可以做一个简单的测试，看看套接字是否创建成功。

int main()
{UdpServer* svr = new UdpServer();svr->InitServer();return 0;
}

运行程序后可以看到套接字是创建成功的，对应获取到的文件描述符就是3，这也很好理解，因为0、1、2默认被标准输入流、标准输出流和标准错误流占用了，此时最小的、未被利用的文件描述符就是3。

在这里插入图片描述

服务端绑定

现在套接字已经创建成功了，但作为一款服务器来讲，如果只是把套接字创建好了，那我们也只是在系统层面上打开了一个文件，操作系统将来并不知道是要将数据写入到磁盘还是刷到网卡，此时该文件还没有与网络关联起来。

在这里插入图片描述
由于现在编写的是不面向连接的UDP服务器，所以初始化服务器要做的第二件事就是绑定。

bind函数

绑定的函数叫做bind，该函数的函数原型如下：

int bind(int sockfd, const struct sockaddr* addr, socklen_t addrlen);

参数说明：

sockfd：绑定的文件的文件描述符。也就是我们创建套接字时获取到的文件描述符。
addr：网络相关的属性信息，包括协议家族、IP地址、端口号等。
addrlen：传入的addr结构体的长度。

返回值说明：

绑定成功返回0，绑定失败返回-1，同时错误码会被设置。

struct sockaddr_in 结构体

在绑定时需要将网络相关的属性信息填充到一个结构体当中，然后将该结构体作为bind函数的第二个参数进行传入，这实际就是 struct sockaddr_in 结构体。

我们可以用 grep 命令在 /usr/include 目录下查找该结构，此时就可以找到定义该结构的文件。
在这里插入图片描述
在该文件中就可以找到 struct sockaddr_in 结构的定义，需要注意的是，struct sockaddr_in 属于系统级的概念，不同的平台接口设计可能会有点差别。

在这里插入图片描述
可以看到，struct sockaddr_in当中的成员如下：

sin_family：表示协议家族。
sin_port：表示端口号，是一个16位的整数。
sin_addr：表示IP地址，是一个32位的整数。

剩下的字段一般不做处理，当然你也可以进行初始化。

其中sin_addr的类型是struct in_addr，实际该结构体当中就只有一个成员，该成员就是一个32位的整数，IP地址实际就是存储在这个整数当中的。

在这里插入图片描述

如何理解绑定

在进行绑定的时候需要将IP地址和端口号告诉对应的网络文件，此时就可以改变网络文件当中文件操作函数的指向，将对应的操作函数改为对应网卡的操作方法，此时读数据和写数据对应的操作对象就是网卡了，所以绑定实际上就是将文件和网络关联起来。

增加IP地址和端口号

由于绑定时需要用到IP地址和端口号，因此我们需要在服务器类当中引入IP地址和端口号，在创建服务器对象时需要传入对应的IP地址和端口号，此时我们就可以根据传入的IP地址和端口号对对应的成员进行初始化。

class UdpServer
{
public:UdpServer(std::string ip, int port):_sockfd(-1),_port(port),_ip(ip){};~UdpServer(){if (_sockfd >= 0){close(_sockfd);}};private:int _sockfd; //文件描述符int _port; //端口号std::string _ip; //IP地址
};

注意：虽然这里端口号定义为整型，但由于端口号是16位的，因此我们实际只会用到它的低16位。

服务端绑定

套接字创建完毕后我们就需要进行绑定了，但在绑定之前我们需要先定义一个 struct sockaddr_in 结构，将对应的网络属性信息填充到该结构当中。由于该结构体当中还有部分选填字段，因此我们最好在填充之前对该结构体变量里面的内容进行清空，然后再将协议家族、端口号、IP地址等信息填充到该结构体变量当中。

需要注意的是，在发送到网络之前需要将端口号设置为网络序列，由于端口号是16位的，因此我们需要使用前面说到的 htons 函数将端口号转为网络序列。此外，由于网络当中传输的是整数IP，我们需要调用inet_addr函数将字符串IP转换成整数IP，然后再将转换后的整数IP进行设置。

当网络属性信息填充完毕后，由于 bind函数提供的是通用参数类型，因此在传入结构体地址时还需要将 struct sockaddr_in* 强转为 struct sockaddr* 类型后再进行传入。

class UdpServer
{
public:UdpServer(std::string ip, int port):_sockfd(-1),_port(port),_ip(ip){};bool InitServer()						{//创建套接字_sockfd = socket(AF_INET, SOCK_DGRAM, 0);if (_sockfd < 0){ //创建套接字失败std::cerr << "socket error" << std::endl;return false;}std::cout << "socket create success, sockfd: " << _sockfd << std::endl;//填充网络通信相关信息struct sockaddr_in local;memset(&local, '\0', sizeof(local));local.sin_family = AF_INET;local.sin_port = htons(_port);local.sin_addr.s_addr = inet_addr(_ip.c_str());                                                                                                                                                                                                                                                                                                                                                                                                        //绑定if (bind(_sockfd, (struct sockaddr*)&local, sizeof(sockaddr)) < 0){ //绑定失败std::cerr << "bind error" << std::endl;return false;}std::cout << "bind success" << std::endl;return true;}~UdpServer(){if (_sockfd >= 0){close(_sockfd);}};private:int _sockfd; 		//文件描述符int _port; 			//端口号std::string _ip; 	//IP地址
};

字符串IP VS 整数IP

IP地址的表现形式有两种：

字符串IP：类似于192.168.233.123这种字符串形式的IP地址，叫做基于字符串的点分十进制IP地址。
整数IP：IP地址在进行网络传输时所用的形式，用一个32位的整数来表示IP地址。

整数IP存在的意义

网络传输数据时是寸土寸金的，如果我们在网络传输时直接以基于字符串的点分十进制IP的形式进行IP地址的传送，那么此时一个IP地址至少就需要15个字节，但实际并不需要耗费这么多字节。

IP地址实际可以划分为四个区域，其中每一个区域的取值都是0~255，而这个范围的数字只需要用8个比特位就能表示，因此我们实际只需要32个比特位就能够表示一个IP地址。其中这个32位的整数的每一个字节对应的就是IP地址中的某个区域，我们将IP地址的这种表示方法称之为整数IP，此时表示一个IP地址只需要4个字节。

在这里插入图片描述
因为采用整数IP的方案表示一个IP地址只需要4个字节，并且在网络通信也能表示同样的含义，因此在网络通信时就没有用字符串IP而用的是整数IP，因为这样能够减少网络通信时数据的传送。

字符串IP和整数IP相互转换的方式

转换的方式有很多，比如我们可以定义一个位段A，位段A当中有四个成员，每个成员的大小都是8个比特位，这四个成员就依次表示IP地址的四个区域，一共32个比特位。

然后我们再定义一个联合体IP，该联合体当中有两个成员，其中一个是32位的整数，其代表的就是整数IP，还有一个就是位段A类型的成员，其代表的就是字符串IP。

在这里插入图片描述
由于联合体的空间是成员共享的，因此我们设置IP和读取IP的方式如下：

当我们想以整数IP的形式设置IP时，直接将其赋值给联合体的第一个成员就行了。
当我们想以字符串IP的形式设置IP时，先将字符串分成对应的四部分，然后将每部分转换成对应的二进制序列依次设置到联合体中第二个成员当中的p1、p2、p3和p4就行了。
当我们想取出整数IP时，直接读取联合体的第一个成员就行了。
当我们想取出字符串IP时，依次获取联合体中第二个成员当中的p1、p2、p3和p4，然后将每一部分转换成字符串后拼接到一起就行了。

注意：在操作系统内部实际用的就是位段和枚举，来完成字符串IP和整数IP之间的相互转换的。

inet_addr函数

实际在进行字符串IP和整数IP的转换时，我们不需要自己编写转换逻辑，系统已经为我们提供了相应的转换函数，我们直接调用即可。

将字符串IP转换成整数IP的函数叫做inet_addr，该函数的函数原型如下：

in_addr_t inet_addr(const char *cp);

该函数使用起来非常简单，我们只需传入待转换的字符串IP，该函数返回的就是转换后的整数IP。除此之外，inet_aton函数也可以将字符串IP转换成整数IP，不过该函数使用起来没有inet_addr简单。

inet_ntoa函数

将整数IP转换成字符串IP的函数叫做inet_ntoa，该函数的函数原型如下：

char *inet_ntoa(struct in_addr in);

需要注意的是，传入inet_ntoa函数的参数类型是in_addr，因此我们在传参时不需要选中in_addr结构当中的32位的成员传入，直接传入in_addr结构体即可。

运行服务器

UDP服务器的初始化就只需要创建套接字和绑定就行了，当服务器初始化完毕后我们就可以启动服务器了。

服务器实际上就是在周而复始的为我们提供某种服务，服务器之所以称为服务器，是因为服务器运行起来后就永远不会退出，因此服务器实际执行的是一个死循环代码。由于UDP服务器是不面向连接的，因此只要UDP服务器启动后，就可以直接读取客户端发来的数据。

recvfrom函数

UDP服务器读取数据的函数叫做recvfrom，该函数的函数原型如下：

ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen);

参数说明：

sockfd：对应操作的文件描述符。表示从该文件描述符索引的文件当中读取数据。
buf：读取数据的存放位置。
len：期望读取数据的字节数。
flags：读取的方式。一般设置为0，表示阻塞读取。
src_addr：对端网络相关的属性信息，包括协议家族、IP地址、端口号等。
addrlen：调用时传入期望读取的src_addr结构体的长度，返回时代表实际读取到的src_addr结构体的长度，这是一个输入输出型参数。

返回值说明：

读取成功返回实际读取到的字节数，读取失败返回-1，同时错误码会被设置。

注意：

由于UDP是不面向连接的，因此我们除了获取到数据以外还需要获取到对端网络相关的属性信息，包括IP地址和端口号等。
在调用 recvfrom 读取数据时，必须将 addrlen 设置为你要读取的结构体对应的大小。
由于 recvfrom 函数提供的参数也是 struct sockaddr* 类型的，因此我们在传入结构体地址时需要将 struct sockaddr_in* 类型进行强转。

启动服务器函数

现在服务端通过 recvfrom函数 读取客户端数据，我们可以先将读取到的数据当作字符串看待，将读取到的数据的最后一个位置设置为’\0’，此时我们就可以将读取到的数据进行输出，同时我们也可以将获取到的客户端的IP地址和端口号也一并进行输出。

需要注意的是，我们获取到的客户端的端口号此时是网络序列，我们需要调用 ntohs 函数将其转为主机序列再进行打印输出。同时，我们获取到的客户端的IP地址是整数IP，我们需要通过调用 inet_ntoa 函数将其转为字符串IP再进行打印输出。

class UdpServer
{
public:void Start(){#define SIZE 128char buffer[SIZE];for (;;){struct sockaddr_in peer;socklen_t len = sizeof(peer);ssize_t size = recvfrom(_sockfd, buffer, sizeof(buffer) - 1, 0, (struct sockaddr*)&peer, &len);if (size > 0){buffer[size] = '\0';int port = ntohs(peer.sin_port);std::string ip = inet_ntoa(peer.sin_addr);std::cout << ip << ":" << port << "# " << buffer << std::endl;}else{std::cerr << "recvfrom error" << std::endl;}}}private:int _sockfd; 		//文件描述符int _port; 			//端口号std::string _ip; 	//IP地址
};

注意：如果调用recvfrom函数读取数据失败，我们可以打印一条提示信息，但是不要让服务器退出，服务器不能因为读取某一个客户端的数据失败就退出。

引入命令行参数

鉴于构造服务器时需要传入IP地址和端口号，我们这里可以引入命令行参数。此时当我们运行服务器时在后面跟上对应的IP地址和端口号即可。

由于云服务器的原因，后面实际不需要传入IP地址，因此在运行服务器的时候我们只需要传入端口号即可，目前我们就手动将IP地址设置为127.0.0.1。IP地址为127.0.0.1实际上等价于localhost表示本地主机，我们将它称之为本地环回，相当于我们一会先在本地测试一下能否正常通信，然后再进行网络通信的测试。

int main(int argc, char* argv[])
{if (argc != 2){std::cerr << "Usage: " << argv[0] << " port" << std::endl;return 1;}std::string ip = "127.0.0.1"; //本地环回int port = atoi(argv[1]);UdpServer* svr = new UdpServer(ip, port);svr->InitServer();svr->Start();return 0;
}

需要注意的是，agrv数组里面存储的是字符串，而端口号是一个整数，因此需要使用atoi函数将字符串转换成整数。然后我们就可以用这个IP地址和端口号来构造服务器了，服务器构造完成并初始化后就可以调用Start函数启动服务器了。

此时带上端口号运行程序就可以看到套接字创建成功、绑定成功，现在服务器就在等待客户端向它发送数据。

在这里插入图片描述
虽然现在客户端代码还没有编写，但是我们可以通过netstat命令来查看当前网络的状态，这里我们可以选择携带nlup 选项。

netstat常用选项说明：

-n：直接使用IP地址，而不通过域名服务器。
-l：显示监控中的服务器的Socket。
-t：显示TCP传输协议的连线状况。
-u：显示UDP传输协议的连线状况。
-p：显示正在使用Socket的程序识别码和程序名称。

此时你就能查看到对应网络相关的信息，在这些信息中程序名称为 ./main 的那一行显示的就是我们运行的 UDP服务器的网络信息。

在这里插入图片描述
你可以尝试去掉 -n 选项再查看，此时原本显示IP地址的地方就变成了对应的域名服务器。

在这里插入图片描述
其中 netstat 命令显示的信息中，Proto表示协议的类型，Recv-Q表示网络接收队列，Send-Q表示网络发送队列，Local Address表示本地地址，Foreign Address表示外部地址，State表示当前的状态，PID表示该进程的进程ID，Program name表示该进程的程序名称。