layout: post
title: 计算机网络（二）Linux网络编程
description: 计算机网络（二）Linux网络编程
tag: 计算机网络

文章目录

资源共享
POSIX
- 概念
- POSIX网络相关API
- - socket()
  - bind()
  - - 网络字节序与主机字节序（大小端设备）
  - listen/connect/accept
  - - listend()
    - connect()
    - accept()
    - 连接过程：三次握手
    - 注意点
  - send/recv
  - - 注意事项
  - close
  - - 关闭过程：四次挥手
    - 注意事项
网络IO管理
- 五种IO网络模型
- - 阻塞IO
  - 非阻塞 IO（基于循环recv）
  - 多路复用/事件驱动IO
  - 异步IO（Asynchronous I/O）
  - 信号驱动IO（signal driven I/O SIGIO）
服务器模型Reactor与Proactor
- Reactor模型
- Proactor模型

资源共享

POSIX

概念

POSIX表示可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为 POSIX ），POSIX标准定义了Unix操作系统应该为应用程序提供的接口标准，Linux也遵循了这一接口标准，Windows也兼容了POSIX标准。

POSIX网络相关API

根据C/S模型，主要接口函数如下：
服务端包括：Socket（套接字）、Bind（绑定）、Listen（监听）、Accept（接待）、Recv（接收）、Send（发送）、Close（关闭）。
客户端包括：Socket（套接字）、Connect（连接）、Recv（接收）、Send（发送）、Close（关闭）。
在这里插入图片描述

socket()

Socket既是数据报的载体，又包含有数据报的控制模板

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

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

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

创建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()时系统会自动随机分配一个端口。

bind()

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

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

bind()函数的三个参数分别为：

sockfd：即socket描述字，它是通过socket()函数创建了，唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。
addr：一个const struct sockaddr *指针，指向要绑定给sockfd的协议地址。
addrlen：对应的是地址的长度。

参数中的地址结构根据地址创建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    108struct sockaddr_un { sa_family_t sun_family;               /* AF_UNIX */ char        sun_path[UNIX_PATH_MAX];  /* pathname */ 
};

网络字节序与主机字节序（大小端设备）

主机字节序就是我们平常说的大端和小端模式：不同的CPU有不同的字节序类型，这些字节序是指整数在内存中保存的顺序，这个叫做主机序。小端/大端的区别是指低位数据存储在内存低位还是高位的区别。其中小端机器指：数据低位存储在内存地址低位，高位数据则在内存地址高位；大端机器正好相反。
当前绝大部分机器都是小端机器，就是比较符合人们逻辑思维的数据存储方式，数据从左至右排列，数据低位在内存地址低位(右边)，数据高位在内存地址的高位(左边)
网络字节序：4个字节的32 bit值以下面的次序传输：首先是0～7bit，其次8～15bit，然后16～23bit，最后是24~31bit。这种传输次序称作大端字节序。由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序。字节序，顾名思义字节的顺序，就是大于一个字节类型的数据在内存中的存放顺序，一个字节的数据没有顺序的问题了。

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

listen/connect/accept

listend()

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

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

connect()

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

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连接。

连接过程：三次握手

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

注意点

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

send/recv

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

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

经过上边的操作，服务器与客户已经建立好连接了。可以调用网络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);

注意事项

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

close

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

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

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

关闭过程：四次挥手

close函数是最简单的一个函数，但是断开连接也是状态机也是最为复杂的。close过程涉及到四次挥手的全过程。首先是客户端调用close，内核开始进入四次挥手阶段，首先是发送fin包，自己先进入fin_wait_1状态，然后对方回复ack，进入close_wait状态；这时主动方进入fin_wait_2阶段，等待对方发送fin信息，被动方发送fin后自己进入last_ack状态，主动方发送ack进入time_wait状态。整个过程比较复杂。
在这里插入图片描述
其实用下面这个图更加清晰，客户端发送fin包后，服务端收到，回复ack，此时服务端通知进程关闭TCP应用进程，等待服务端TCP应用进程关闭后，服务端发送fin包，客户端收到后回复ack，当服务端收到ack后，close完成，客户端等待2MSL后完成close。等待2MSL时长后再关闭是为了防止客户端的最后确认ack报文发生丢失，导致服务端一直处于最后确认，无法关闭。
在这里插入图片描述

注意事项

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

网络IO管理

五种IO网络模型

阻塞IO

Linux中，默认情况下所有的socket都是阻塞型的，所谓阻塞型接口是指系统调用（一般是IO 接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。
在这里插入图片描述
实际上，除非特别指定，几乎所有的IO 接口 ( 包括socket 接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。

一个简单的改进方案是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。
在这里插入图片描述
在上述的线程 / 时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。很多初学者可能不明白为何一个socket 可以accept 多次。实际上socket 的设计者可能特意为多客户机的情况留下了伏笔，让accept()能够返回一个新的socket。下面是
accept 接口的原型：

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

输入参数s 是从socket()，bind()和listen()中沿用下来的socket 句柄值。执行完bind()和listen()后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用accept()接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与s 同类的新的socket 返回句柄。新的socket 句柄即是后续read()和recv()的输入参数。如果请求队列当前没有请求，则accept() 将进入阻塞状态直到有请求进入队列。

上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。

非阻塞 IO（基于循环recv）

Linux下，还可以设置socket为非阻塞型。在非阻塞式 IO 中，用户进程其实是需要不断的主动询问 kernel数据准备好了没有。
在非阻塞状态下， recv() 接口在被调用后立即返回，返回值代表了不同的含义。如本例中，

recv()返回值大于 0，表示接受数据完毕，返回值即是接受到的字节数；
recv()返回 0，表示连接已经正常断开
recv() 返回 -1，且 errno 等于 EAGAINEAGAIN，表示 recv 操作还没执行完成；
recv()返回 -1，且 errno 不等于 EAGAINEAGAIN，表示 recv 操作遇到系统错误 errno ；

非阻塞的接口相比于阻塞型接口的显著差异在于，在被调用之后立即返回。使用如下的函数可以将某句柄 fd设为非阻塞状态。
fcntl (fd, F_SETFL, O_NONBLOCK);
在这里插入图片描述
服务器线程可以通过循环调用recv()接口，可以在单个线程内实现对所有连接的数据接收工作。但是上述模型绝不被推荐。因为，循环调用recv()将大幅度推高CPU占用率；

此外，在这个方案中recv()更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如select()多路复用模式，可以一次检测多个连接是否活跃。

多路复用/事件驱动IO

基本原理就是select/epoll 这个function会不断的轮询所负责的所有socket，当某个socket 有数据到达了，就通知用户进程。
在多路复用模型中，对于每一个socket ，一般都设置成为 non blocking ，但是，整个用户的 process 其实是一直被 block 的。只不过 process 是被 select 这个函数 block ，而不是被 socket IO 给 block 。因此 select() 与非阻塞 IO 类似。

大部分 Unix/Linux 都支持 select 函数，该函数用于轮询探测多个文件句柄的状态变化。
select 接口的原型：

FD_ZERO( int fd, fd_set* fds)
FD_SET( int fd, fd_set* fds)
FD_ ISSET( int fd, fd_set* fds)
FD_CLR( int fd, fd_set* fds)
int select (int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout)

其中：fd_set类型可理解为按bit位标记句柄的队列，例如在某fd_set中标记一个值为16的句柄，则该fd_set的第16个bit位被标记为1。具体的置位、验证可使用 FD_SET 、 FD_ISSET 等宏实现。在 select() 函数中， readfds 、 writefds 和exceptfds 同时作为输入参数和输出参数。如果输入的readfds标记了16号句柄，则select()将检测16号句柄是否可读。号句柄是否可读。在 select() 返回后，可以通过检查 readfds 有否标记 16 号句柄，来判断该可读事件是否发生。另外，用户可以设置 timeout 时间。
在这里插入图片描述
相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU ，同时能够为多客户端提供服务。
但这个模型依旧有着很多问题。首先select() 接口并不是实现事件驱动的最好选择。因为当需要探测的句柄值较大时， select() 接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如 linux 提供了 epoll BSD 提供了 kqueue Solaris提供了 /dev/poll 。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。

幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有libevent 库，还有作为 libevent 替代者的 libev 库。

异步IO（Asynchronous I/O）

异步 IO 是真正非阻塞的，它不会对请求进程产生任何的阻塞，因此对高并发的网络服务器实现至关重要。用户进程发起read 操作之后，它会立刻返回，用户进程就可以开始去做其它的事。kernel 会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后， kernel 会给用户进程发送一个 signal ，告诉它 read 操作完成了。

信号驱动IO（signal driven I/O SIGIO）

socket还可进行信号驱动 I/O, 安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。当数据报准备好读取时，内核就为该进程产生一个 SIGIO 信号。我们随后既可以在信号处理函数中调用 read 读取数据报，并通知主循环数据已准备好待处理，也可以立即通知主循环，让它来读取数据报。无论如何处理 SIGIO 信号，这种模型的优势在于等待数据报到达第一阶段期间，进程可以继续执行，不被阻塞，当有活跃套接字时，由注册的 handler处理。

服务器模型Reactor与Proactor

Reactor模型

首先来回想一下普通函数调用的机制：程序调用某函数，函数执行，程序等待，函数将结果和控制权返回给程序，程序继续处理。
Reactor 释义为“反应堆”，是一种事件驱动机制。和普通函数调用的不同之处在于：应用程序不是主动的调用某个 API 完成处理，而是恰恰相反， Reactor 逆置了事件处理流程，应用程序需要提供相应的接口并注册到 Reactor 上，如果相应的事件发生， Reactor 将主动调用应用程序注册的接口，这些接口又称为回调函数。

Reactor模式是处理并发 I/O 比较常见的一种模式，用于同步 I/O ，中心思想是将所有要处理的 I/O 事件注册到一个中心 I/O 多路复用器上，同时主线程进程阻塞在多路复用器上；一旦有 I/O 事件到来或是准备就绪文件描述符或 socket 可读、写 )，多路复用器返回并将事先注册的相应 I/O 事件分发到对应的处理器中。
Reactor 模型有三个重要的组件：