C++后端开发——POSIX网络API解析

Dear 丶 2023-09-24 21:48 38阅读 0赞

## 网络中进程之间如何通信？ ##

本地的进程间通信（IPC）有很多种方式，但可以总结为下面4类：

1.  消息传递（管道、FIFO、消息队列）
2.  同步（互斥量、条件变量、读写锁、文件和写记录锁、信号量）
3.  共享内存（匿名的和具名的）
4.  远程过程调用（Solaris门和Sun RPC）

> 但这些都不是本文的主题！我们要讨论的是网络中进程之间如何通信？首要解决的问题是如何唯一标识一个进程，否则通信无从谈起！在本地可以通过进程PID来唯一标识一个进程，但是在网络中这是行不通的。其实TCP/IP协议族已经帮我们解决了这个问题，网络层的“ip地址”可以唯一标识网络中的主机，而传输层的“协议+端口”可以唯一标识主机中的应用程序（进程）。这样利用三元组（ip地址，协议，端口）就可以标识网络的进程了，网络中的进程通信就可以利用这个标志与其它进程进行交互。  
> 使用TCP/IP协议的应用程序通常采用应用编程接口：UNIX BSD的套接字（socket）和UNIX System V的TLI（已经被淘汰），来实现网络进程之间的通信。就目前而言，几乎所有的应用程序都是采用socket，而现在又是网络时代，网络中进程通信是无处 不在，这就是我为什么说“一切皆socket”。

## POSIX介绍 ##

POSIX表示可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为 POSIX ），POSIX标准定义了操作系统应该为应用程序提供的接口标准。

POSIX标准意在期望获得源代码级别的软件可移植性。换句话说，为一个POSIX兼容的操作系统编写的程序，应该可以在任何其它的POSIX操作系统（即使是来自另一个厂商）上编译执行。

简单总结：

完成同一功能，不同内核提供的系统调用（也就是一个函数）是不同的，例如创建进程，linux下是fork函数，windows下是creatprocess函数。好，我现在在linux下写一个程序，用到fork函数，那么这个程序该怎么往windows上移植？我需要把源代码里的fork通通改成creatprocess，然后重新编译…

posix标准的出现就是为了解决这个问题。linux和windows都要实现基本的posix标准，linux把fork函数封装成posix\_fork（随便说的），windows把creatprocess函数也封装成posix\_fork，都声明在unistd.h里。这样，程序员编写普通应用时候，只用包含unistd.h，调用posix\_fork函数，程序就在源代码级别可移植了。

### 1 POSIX网络API ###

网络编程常用的API：

![ffee04f3da90f727db2307b153112543.jpeg][]

## 2 函数与内部过程分析 ##

### 2.1 Socket ###

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

调用socket()会创建一个套接字（socket）对象。套接字由两部分组成，文件描述符（fd）和TCP Control Block（tcb）。

socket作为网络编程的第一个函数，主要作用是用于创建句柄和对应的TCB控制块；建立起文件描述符和内部控制块的对应关系，类似与插座和槽的关系。TCB主要包括关系信息有网络的五元组（remote IP，remote PORT， local IP， local PORT， protocol）确定一个具体的网络连接

socket函数对应于普通文件的打开操作。普通文件的打开操作返回一个文件描述字，而socket()用于创建一个socket描述符（socket descriptor），它唯一标识一个socket。这个socket描述字跟文件描述字一样，后续的操作都有用到它，把它作为参数，通过它来进行一些读写操作。

正如可以给fopen的传入不同参数值，以打开不同的文件。创建socket的时候，也可以指定不同的参数创建不同的socket描述符，socket函数的三个参数分别为：

*  **domain：** 即协议域，又称为协议族（family）。常用的协议族有，AF\_INET、AF\_INET6、AF\_LOCAL（或称AF\_UNIX，Unix域socket）、AF\_ROUTE等等。协议族决定了socket的地址类型，在通信中必须采用对应的地址，如AF\_INET决定了要用ipv4地址（32位的）与端口号（16位的）的组合、AF\_UNIX决定了要用一个绝对路径名作为地址。
 *  **type：** 指定socket类型。常用的socket类型有，SOCK\_STREAM、SOCK\_DGRAM、SOCK\_RAW、SOCK\_PACKET、SOCK\_SEQPACKET等等（socket的类型有哪些？）。
 *  **protocol：** 故名思意，就是指定协议。常用的协议有，IPPROTO\_TCP、IPPTOTO\_UDP、IPPROTO\_SCTP、IPPROTO\_TIPC等，它们分别对应TCP传输协议、UDP传输协议、STCP传输协议、TIPC传输协议（这个协议我将会单独开篇讨论！）。  
    注意：并不是上面的type和protocol可以随意组合的，如SOCK\_STREAM不可以跟IPPROTO\_UDP组合。当protocol为0时，会自动选择type类型对应的默认协议。

当我们调用socket创建一个socket时，返回的socket描述字它存在于协议族（address family，AF\_XXX）空间中，但没有一个具体的地址。如果想要给它赋值一个地址，就必须调用bind()函数，否则就当调用connect()、listen()时系统会自动随机分配一个端口。

### 2.2 bind ###

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

正如上面所说bind()函数把一个地址族中的特定地址赋给socket。例如对应AF\_INET、AF\_INET6就是把一个ipv4或ipv6地址和端口号组合赋给socket。

函数的三个参数分别为：

*  **sockfd**：即socket描述字，它是通过socket()函数创建了，唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。
 *  **addr**：一个const struct sockaddr \*指针，指向要绑定给sockfd的协议地址。这个地址结构根据地址创建socket时的地址协议族的不同而不同，如ipv4对应的是：

struct sockaddr_in {
        
        sa_family_t    sin_family; /* address family: AF_INET */
        in_port_t      sin_port;   /* port in network byte order */
        struct in_addr sin_addr;   /* internet address */
    };
    
    /* Internet address. */
    struct in_addr {
        
        uint32_t       s_addr;     /* address in network byte order */
    };

ipv6对应的是：

struct sockaddr_in6 {
         
        sa_family_t     sin6_family;   /* AF_INET6 */ 
        in_port_t       sin6_port;     /* port number */ 
        uint32_t        sin6_flowinfo; /* IPv6 flow information */ 
        struct in6_addr sin6_addr;     /* IPv6 address */ 
        uint32_t        sin6_scope_id; /* Scope ID (new in 2.4) */ 
    };
    
    struct in6_addr {
         
        unsigned char   s6_addr[16];   /* IPv6 address */ 
    };

Unix域对应的是：

#define UNIX_PATH_MAX    108
    
    struct sockaddr_un {
         
        sa_family_t sun_family;               /* AF_UNIX */ 
        char        sun_path[UNIX_PATH_MAX];  /* pathname */ 
    };

*  addrlen：对应的是地址的长度。

通常服务器在启动的时候都会绑定一个众所周知的地址（如ip地址+端口号），用于提供服务，客户就可以通过它来接连服务器；而客户端就不用指定，有系统自动分配一个端口号和自身的ip地址组合。这就是为什么通常服务器端在listen之前会调用bind()，而客户端就不会调用，而是在connect()时由系统随机生成一个。

> 网络字节序与主机字节序  
> 主机字节序就是我们平常说的大端和小端模式：不同的CPU有不同的字节序类型，这些字节序是指整数在内存中保存的顺序，这个叫做主机序。引用标准的Big-Endian和Little-Endian的定义如下：  
> a) Little-Endian就是低位字节排放在内存的低地址端，高位字节排放在内存的高地址端。  
> b) Big-Endian就是高位字节排放在内存的低地址端，低位字节排放在内存的高地址端。  
> 网络字节序：4个字节的32 bit值以下面的次序传输：首先是0～7bit，其次8～15bit，然后16～23bit，最后是24~31bit。这种传输次序称作大端字节序。由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序。字节序，顾名思义字节的顺序，就是大于一个字节类型的数据在内存中的存放顺序，一个字节的数据没有顺序的问题了。

所以： 在将一个地址绑定到socket的时候，请先将主机字节序转换成为网络字节序，而不要假定主机字节序跟网络字节序一样使用的是Big-Endian。由于 这个问题曾引发过血案！公司项目代码中由于存在这个问题，导致了很多莫名其妙的问题，所以请谨记对主机字节序不要做任何假定，务必将其转化为网络字节序再 赋给socket。

## 2.3 listen/connect/accept ##

### 2.3.1 listend（） ###

服务端调用listen()后，开始监听网络上发送给socket的连接请求。

listen(fd,size)，fd是socket的文件描述符，size在Linux是指全连接队列的长度，即一次最多能保存size个连接请求。

### 2.3.2 connect（） ###

客户端调用connect()函数，向指定服务端发起连接请求。

### 2.3.3 accept（） ###

accept()函数只做两件事，将连接请求从全连接队列中取出，给该连接分配一个fd并返回。

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

TCP服务器端依次调用socket()、bind()、listen()之后，就会监听指定的socket地址了。TCP客户端依次调用socket()、connect()之后就想TCP服务器发送了一个连接请求。TCP服务器监听到这个请求之后，就会调用accept()函数取接收请求，这样连接就建立好了。之后就可以开始网络I/O操作了，即类同于普通文件的读写I/O操作。

accept函数的第一个参数为服务器的socket描述字，第二个参数为指向struct sockaddr \*的指针，用于返回客户端的协议地址，第三个参数为协议地址的长度。如果accpet成功，那么其返回值是由内核自动生成的一个全新的描述字，代表与返回客户的TCP连接。

> 注意：accept的第一个参数为服务器的socket描述字，是服务器开始调用socket()函数生成的，称为监听socket描述字；而accept函数返回的是已连接的socket描述字。一个服务器通常通常仅仅只创建一个监听socket描述字，它在该服务器的生命周期内一直存在。内核为每个由服务器进程接受的客户连接创建了一个已连接socket描述字，当服务器完成了对某个客户的服务，相应的已连接socket描述字就被关闭。

### 2.3.4 过程分析 ###

listen/connect/accept三个函数和三次握手有关，这里放到一起进行描述。当客户端调用connet函数时表示开始进入三次握手，当服务端收到syn包后，listen函数会在内核协议栈为新的客户端创建一个TCB块同时将其**加入到半连接队列**。客户端收到对方的ACK和Syn包后会回复一个ACK这时候客户端就会认为整个连接已经建立；服务端收到ACK后会将半连接队列的TCB数据**移动到全连接队列**；当服务端**调用accept会在全连接队列有数据时被触发**，同时返回客户端的文件句柄和对方的ip端口；这时候TCB一个完整的五元组被构建好，服务端和客户端连接成功。具体如下图所示：

![4f90f14de3d17768dc01a263e5989417.jpeg][]

### 2.3.5 注意点 ###

1.  三次握手为啥是三次?  
    一个完整的TCP连接需要双方都得到确认，客户端发送请求和收到确认需要两次；服务端发送请求和收到确认需要两次，当中**服务回复确认和发送请求合并为一次**总共需要3次；才能保证双向通道是通的。
2.  百万连接是如何做到的?  
    一个服务器的端口数是65535，为何能做到一百万的连接，主要是因为一条连接是由五元组所组成，所以一个服务器的连接数是**五个成员数的乘积**。例如：客户端ip：100，客户端port：100，服务端ip：10，服务端port：100，协议：tcp。总的连接数可以达到：10000000连接数。
3.  DOS攻击怎么解决?  
    DOS攻击就是利用三次握手的原理，模拟客户端只向服务器发送syn包，然后耗尽被攻击对象的资源。比较多的做法是**利用防火墙，做一些过滤规则**。

## 2.4 send/recv等函数 ##

万事具备只欠东风，至此服务器与客户已经建立好连接了。可以调用网络I/O进行读写操作了，即实现了网络中不同进程之间的通信！网络I/O操作有下面几组：

*  read()/write()
 *  recv()/send()
 *  readv()/writev()
 *  recvmsg()/sendmsg()
 *  recvfrom()/sendto()  
    我推荐使用recvmsg()/sendmsg()函数，这两个函数是最通用的I/O函数，实际上可以把上面的其它函数都替换成这两个函数。它们的声明如下：

#include <unistd.h>
    
    ssize_t read(int fd, void *buf, size_t count);
    ssize_t write(int fd, const void *buf, size_t count);
    
    #include <sys/types.h>
    #include <sys/socket.h>
    
    ssize_t send(int sockfd, const void *buf, size_t len, int flags);
    ssize_t recv(int sockfd, void *buf, size_t len, int flags);
    
    ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,
                   const struct sockaddr *dest_addr, socklen_t addrlen);
    ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags,
                     struct sockaddr *src_addr, socklen_t *addrlen);
    
    ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);
    ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);

send和recv在连接生命周期中占用的时常最长，主要负责数据的收发。send函数负责将数据拷贝到内核，内核协议栈主要是利用TCB中的发送缓冲区进行数据缓存，然后根据内核自己的策略决定何时将数据发送。接收端数据也是先到达TCB的接收缓冲区，然后才是通过recv拷贝到用户空间。

*  recv（）  
    接收数据函数，此函数将数据从内核态的接收缓冲区拷贝到用户空间。
 *  send（）  
    发送函数，此函数将数据从用户态拷贝到内核态的发送缓冲区，具体发送由协议控制。

### 2.4.1 过程分析 ###

send和recv在连接生命周期中占用的时常最长，主要负责数据的收发。send函数负责**将数据拷贝到内核**，内核协议栈主要是利用TCB中的发送缓冲区进行数据缓存，然后根据内核自己的策略决定何时将数据发送。接收端数据也是先到达TCB的接收缓冲区，然后才是通过**recv拷贝到用户空间**。

![7fe29a753ee7a6b88ba7be7fadd6faaf.jpeg][]

### 2.4.2 注意事项 ###

1.  接收数据的黏包问题如何解决？  
    一种是利用**包头上添加一个数据包长度**的字段，用于数据的划分；  
    另一种是在包的尾部添加**分隔符**，用于数据的划分；
2.  如何保证接收数据的顺序到达？  
    顺序到达是由于TCP的**延迟ACK**的机制来保证的，TCP接收到数据并不是立即回复而是经过一个延迟时间，回复接收到**连续包的最大序列号加1**。如果丢包之后的包都需要重传。在弱网情况下这里就会有实时性问题和带宽占用的问题；
3.  UDP优势？  
    UDP在实时性要求高的场景和弱网情况下较TCP更具有优势。目前竞技类游戏实时性要求高的行业，音视频通话及小数据量交互等场景下UDP使用得比较多。

## 2.5 close ##

#include <unistd.h>
    int close(int fd);

在服务器与客户端建立连接之后，会进行一些读写操作，完成了读写操作就要关闭相应的socket描述字，好比操作完打开的文件要调用fclose关闭打开的文件。

close一个TCP socket的缺省行为时把该socket标记为以关闭，然后立即返回到调用进程。该描述字不能再由调用进程使用，也就是说不能再作为read或write的第一个参数。

注意：close操作只是使相应socket描述字的引用计数-1，只有当引用计数为0的时候，才会触发TCP客户端向服务器发送终止连接请求。

### 2.5.1 过程分析 ###

close函数是最简单的一个函数，但是断开连接也是状态机也是最为复杂的。close过程涉及到四次挥手的全过程。首先是客户端调用close，内核开始进入四次挥手阶段，首先是发送fin包，自己先进入fin\_wait\_1状态，然后对方回复ack，进入close\_wait状态；这时主动方进入fin\_wait\_2阶段，等待对方发送fin信息，被动方发送fin后自己进入last\_ack状态，主动方发送ack进入time\_wait状态。整个过程比较复杂。

1.  正常情况下一方调用close情况如下图：

![f1663978fc2c54b26e98c08d6ad31c39.jpeg][]

2.当双方同时调用close，如下图:

![c5dd62a0c15b83a93bf7b6f1507ec578.jpeg][]

### 2.5.2 注意事项 ###

1.  Fin\_wait\_1作用？  
    等待对方回复，超时自动重发fin。
2.  Fin\_wait\_2作用？  
    等待对方业务逻辑处理后，发送fin包。这里有可能出现死等待的情况服务器如果出现大量的Fin\_wait\_2可能需要考虑是不是没有close，或者close之前做了耗时操作。
3.  time\_wait 作用？  
    防止最后一个ACK没有顺利到达对方，超时重新发送ack。time\_wait时常一般是120s可以修改。
4.  服务器掉线重启出现端口被占用怎么办？  
    其实主要是由于**还处于time\_wait状态**，**端口并没有真正释放**。这时候可以设置SO\_REUSEADDR属性，保证掉线能马上重连。

## 3 总结 ##

![27f83bdb767583903c1d8924382b5c9d.jpeg][]

![9fd6af832384517b6a771881d8d60194.jpeg][]

转载自：[https://blog.csdn.net/weixin\_43687811/article/details/122657720?spm=1001.2101.3001.6650.16&utm\_medium=distribute.pc\_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-16-122657720-blog-121686590.pc\_relevant\_multi\_platform\_featuressortv2dupreplace&depth\_1-utm\_source=distribute.pc\_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-16-122657720-blog-121686590.pc\_relevant\_multi\_platform\_featuressortv2dupreplace&utm\_relevant\_index=27][https_blog.csdn.net_weixin_43687811_article_details_122657720_spm_1001.2101.3001.6650.16_utm_medium_distribute.pc_relevant.none-task-blog-2_7Edefault_7EBlogCommendFromBaidu_7ERate-16-122657720-blog-121686590.pc_relevant_multi_platform_featuressortv2dupreplace_depth_1-utm_source_distribute.pc_relevant.none-task-blog-2_7Edefault_7EBlogCommendFromBaidu_7ERate-16-122657720-blog-121686590.pc_relevant_multi_platform_featuressortv2dupreplace_utm_relevant_index_27]

[ffee04f3da90f727db2307b153112543.jpeg]: https://img-blog.csdnimg.cn/img_convert/ffee04f3da90f727db2307b153112543.jpeg
[4f90f14de3d17768dc01a263e5989417.jpeg]: https://img-blog.csdnimg.cn/img_convert/4f90f14de3d17768dc01a263e5989417.jpeg
[7fe29a753ee7a6b88ba7be7fadd6faaf.jpeg]: https://img-blog.csdnimg.cn/img_convert/7fe29a753ee7a6b88ba7be7fadd6faaf.jpeg
[f1663978fc2c54b26e98c08d6ad31c39.jpeg]: https://img-blog.csdnimg.cn/img_convert/f1663978fc2c54b26e98c08d6ad31c39.jpeg
[c5dd62a0c15b83a93bf7b6f1507ec578.jpeg]: https://img-blog.csdnimg.cn/img_convert/c5dd62a0c15b83a93bf7b6f1507ec578.jpeg
[27f83bdb767583903c1d8924382b5c9d.jpeg]: https://img-blog.csdnimg.cn/img_convert/27f83bdb767583903c1d8924382b5c9d.jpeg
[9fd6af832384517b6a771881d8d60194.jpeg]: https://img-blog.csdnimg.cn/img_convert/9fd6af832384517b6a771881d8d60194.jpeg
[https_blog.csdn.net_weixin_43687811_article_details_122657720_spm_1001.2101.3001.6650.16_utm_medium_distribute.pc_relevant.none-task-blog-2_7Edefault_7EBlogCommendFromBaidu_7ERate-16-122657720-blog-121686590.pc_relevant_multi_platform_featuressortv2dupreplace_depth_1-utm_source_distribute.pc_relevant.none-task-blog-2_7Edefault_7EBlogCommendFromBaidu_7ERate-16-122657720-blog-121686590.pc_relevant_multi_platform_featuressortv2dupreplace_utm_relevant_index_27]: https://link.zhihu.com/?target=https%3A//blog.csdn.net/weixin_43687811/article/details/122657720%3Fspm%3D1001.2101.3001.6650.16%26utm_medium%3Ddistribute.pc_relevant.none-task-blog-2%257Edefault%257EBlogCommendFromBaidu%257ERate-16-122657720-blog-121686590.pc_relevant_multi_platform_featuressortv2dupreplace%26depth_1-utm_source%3Ddistribute.pc_relevant.none-task-blog-2%257Edefault%257EBlogCommendFromBaidu%257ERate-16-122657720-blog-121686590.pc_relevant_multi_platform_featuressortv2dupreplace%26utm_relevant_index%3D27