By

我们假定读者掌握了：

  1. Linux环境下C/C++的系统编程和基本的socket编程方法
  2. 操作系统基本概念以及Linux的基本概念和原理
  3. Linux进程和线程的内存地址空间布局和资源关系

我们谈什么，不谈什么：

  1. Linux下的网络程序设计所遵循的规范
  2. Linux网络程序的工作模型和原理
  3. 一般性质上的网络协议设计方法和原则
  4. 基本上只针对Linux，基本不涉及Windows
  5. 只涉及TCP协议的通信，不谈UDP

可以先行阅读的参考资料：
进程眼中的线性地址空间
线程眼中的线性地址空间
Linux线程的前世今生
聊聊内存管理
Linux系统调用
goroutine背后的系统知识

从基本socket函数开始

留意一些socket函数与众不同的参数细节

1
2
3
4
5
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

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

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

TCP三次握手在socket接口的位置

强调TIME_WAIT状态
MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间，每个具体的TCP实现都必须选择一个确定的MSL值。RFC1122建议是2分钟。
TIME_WAIT 状态最大保持时间是2 * MSL，也就是1-4分钟。

1
int listen(int sockfd, int backlog);

Linux内核协议栈

TCP 的发送

TCP的接收

协议栈完整的收发流程

关于socket接口与内核协议栈的挂接

请参考：socket接口与内核协议栈的挂接

TCP相关参数的设置方法


套接字设置

1
2
3
4
5
6
7
#include <sys/types.h>
#include <sys/socket.h>

int getsockopt(int sockfd, int level, int optname,
                      void *optval, socklen_t *optlen);
int setsockopt(int sockfd, int level, int optname,
                      const void *optval, socklen_t optlen);

SO_REUSEADDR
当有一个有相同本地地址和端口的socket1处于TIME_WAIT状态时，而你启动的程序的socket2要占用该地址和端口，你的程序就要用到该选项。这个选项允许同一port上启动同一服务器的多个实例(多个进程)。但每个实例绑定的IP地址是不能相同的。（多块网卡的应用场合）

SO_RECVBUF / SO_SNDBUF
发送和接收缓冲区大小，不详述。

TCP_NODELAY / TCP_CHORK
是否采用Nagle算法把较小的包组装为更大的帧。HTTP服务器经常使用TCP_NODELAY关闭该算法。相关的还有TCP_CORK。

TCP_DEFER_ACCEPT
推迟accept，实际上是当接收到第一个数据之后，才会创建连接。（对于像HTTP等非交互式的服务器，这个很有意义，可以用来防御空连接攻击。）

TCP_KEEPCNT / TCP_KEEPIDLE / TCP_KEEPINTVL
如果一方已经关闭或异常终止连接，而另一方却不知道，我们将这样的TCP连接称为半打开的。TCP通过保活定时器(KeepAlive)来检测半打开连接。设置SO_KEEPALIVE选项来开启KEEPALIVE，然后通过TCP_KEEPIDLE、TCP_KEEPINTVL和TCP_KEEPCNT设置keepalive的开始时间、间隔、次数等参数。

保活时间：keepalive_time = TCP_KEEPIDLE + TCP_KEEPINTVL * TCP_KEEPCNT

从TCP_KEEPIDLE 时间开始，向对端发送一个探测信息，然后每过TCP_KEEPINTVL 发送一次探测信息。如果在保活时间内，就算检测不到对端了，仍然保持连接。超过这个保活时间，如果检测不到对端，服务器就会断开连接，如果能够检测到对方，那么连接一直持续。


内核全局设置

内核的TCP/IP调优参数都位于/proc/sys/net/目录，可以直接写入数值或者采用sysctl命令或者系统调用。

1
2
3
4
#include <unistd.h>
#include <linux/sysctl.h>

int _sysctl(struct __sysctl_args *args);

详细请参考：提高 Linux 上 socket 性能

常见的协议格式设计

记住，TCP是一种流协议

语出《Effective TCP/IP Programming》。意思是，TCP的数据是以字节流的方式由发送者传递给接收者，没有固有的“报文”或者“报文边界”的概念。简单说，TCP不理解应用层通信的协议，不知道应用层协议格式和边界。所以，所谓的“粘包和断包”是个伪概念。TCP压根就没有包边界的概念，何谈粘与断。

OSI模型定义的7层结构网络中，TCP协议所在的传输层和应用层之间还有会话层和表示层，原本协议包分界和加密等等操作是在这两层完成的。TCP/IP协议在设计的时候，并没有会话层和表示层。那如果用户需要这两层提供的服务怎么办？比如包的分界？答案是，用户自行在应用层代码中实现吧。

示例：

发送者发送三次

接收者可能收到这样：

避免分片的效率损失

数据链路层Maximum Transmission Unit（MTU, 最大传输单元）。

以太网通常在1500字节上下。所以单次发送的协议包数据最好小于这个值，从而避免IP层分片带来的效率损失。

扩展阅读：Linux TCP/IP协议栈关于IP分片重组的实现

常见的协议格式

这个很简单，和文件一样，无非是纯文本格式或者二进制格式。

便于解包的协议设计方法

一般而言，应用层协议设计有四种常见方法：

  1. 每个发送的包长度固定
  2. 包每行均采取特殊结束标记用以区分（例如HTTP使用的\r\n）
  3. 包前添加长度信息（所谓的TLV模式，即type、length、value）
  4. 利用包本身的格式解析（如XML、JSON等）

以上1和3通常是二进制格式，2和4是文本格式。

有没有通用的二进制通信协议？推荐谷歌的ProtoBuf或者Apache Swift.

Protocol Buffers

Google Protocol Buffer的使用和原理

protobuf-c的学习总结

使用Protocol Buffers代替JSON的五个原因

Apache Thrift

Need a demo？

#### 包长度固定

很简单的思路，我们可以定义服务端和客户端均采用同一个结构体进行数据传输，这样的话很容易根据结构体大小来进行分隔收到的数据。这个不用写吧…

#### 包每行均采取特殊结束标记用以区分

这个也很简单理解，采用纯ASCII发送信息的时候，完全可以采用这种方式。比如一个包中，每行采用\r\n进行分隔，包结束采用\r\n\r\n进行分隔等等。
如果在包的数据中出现了结束标记怎么办？转义呗～

#### 包前添加长度信息（所谓的TLV模式，即type、length、value）

这个理解起来也不困难，以结构体为例，即便是服务端和客户端采用多种结构体进行通信，只需要加上一个类型字段和长度字段，这样不就解决了么。

不过这里的type、length以及value只是指导思想，大家完全可以自行去实现自己的格式。

不要觉得这个貌似很搓的样子，看看QQ早些时候的定义：

沈昭萌学长博客：TLV-简单的数据传输协议

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// 包类型
typedef
enum {
    control_start,
    control_end,
    heart_data
} package_t;

// 协议包
typedef
struct _protocol_t {
    uint32_t length_;
    package_t type_;
    uint32_t crc_;
    uint8_t data_[DATA_LENGTH];
} __attribute__((packed)) protocol_t;

// 解包过程：
while (1) {
    uint32_t length = sizeof(uint32_t);
    // 读取 length 值
    if (rio_readn(conn_fd, conn_buff->buff, length) == length) {
        length = *(uint32_t *)conn_buff->buff;
        if (rio_readn(conn_fd, conn_buff->buff+sizeof(uint32_t), length) == length) {
            if (analyse_protocol(conn_buff) < 0) {
                break;
            }
        } else {
            server_print_info(LOG_INFO, "Read Data Error! Close User Link!");
        }
    } else {
        server_print_info(LOG_INFO, "Read Data Length Error! Close User Link!");
        break;
    }
}

rio_readn 函数的实现如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
size_t rio_readn(int fd, void *usrbuf, size_t n)
{
    size_t nleft = n;
    size_t nread = 0;
    char   *bufp = usrbuf;

    while (nleft > 0) {
        if ((nread = read(fd, bufp, nleft)) == -1) {
            if (errno == EINTR) {     // Interrupted by sig handler return
                nread = 0;     // and call read() again
            } else {
                return -1;     // errno set by read()
            }
        } else if (nread == 0) {
            break;         // EOF
        }
        nleft -= nread;
        bufp += nread;
    }

    return (n - nleft);     // return >= 0
}

analyse_protocol 是解析函数，简单的实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 协议解析程序
static int analyse_protocol(server_buffer_t *buff)
{
    protocol_t *proto = (protocol_t *)buff->buff;

    switch (proto->type_) {
    case heart_data:
        if (write(data_fd, buff->buff, DATA_LENGTH) != DATA_LENGTH) {
            perror("write file error");
            exit(EXIT_FAILURE);
        }
        break;
    default:
        server_print_info(LOG_ERR, "未知的包类型，解析错误");
        return -1;
    }

    return 0;
}

利用包本身的格式解析（如XML、JSON等）

这种方式也不难，我们可以通过Xml，Json本身的格式来匹配每一个具体的包。下面给出一个简单的XML接收和解析的简单例子和Qt下使用QtXml的解析方法。

上面是同步的，下面来个异步的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
void MainWindow::clientDataReceived()
{
    while (clientSocket->bytesAvailable()) {
        QByteArray recvMsg = clientSocket->readAll();
        recvBuffer.append(recvMsg);

        QString strProtoTag("</wiidroid>");
        int tagLen = strProtoTag.size();

        int pos = recvBuffer.indexOf(strProtoTag);
        while ((pos = recvBuffer.indexOf(strProtoTag)) != -1) {
            QByteArray recvPacket(recvBuffer.data(), pos+tagLen);
            recvBuffer.remove(0, recvPacket.size());
            if (recvBuffer.at(0) == '\n') {
                recvBuffer.remove(0, 1);
            } else if (recvBuffer.at(0) == '\r' && recvBuffer.at(1) == '\n') {
                recvBuffer.remove(0, 2);
            }
            parseProtoPackage(recvPacket);
        }
    }
}

void MainWindow::parseProtoPackage(QByteArray &recvPacket)
{
    KeyPressInfo keyPressInfo;
    ASpeedInfo aSpeedInfo;
    GyroscopeInfo gyroscopeInfo;

    switch (ProtocolXml::getXmlInfoType(recvPacket)) {
        // 客户端控制（键盘消息）
        case PROTO_CONTROL_KEY:
            ProtocolXml::parseKeyInfo(recvPacket, keyPressInfo);
            qDebug() << "客户端控制（键盘消息）: \n Key: " << keyPressInfo.key
                << " isPress: " << keyPressInfo.isPress << "\n";
            break;
            // 客户端控制（加速度传感器）
        case PROTO_CONTROL_ASPEED:
            ProtocolXml::parseASpeedInfo(recvPacket, aSpeedInfo);
            qDebug() << "客户端控制（加速度传感器）\n x: " << aSpeedInfo.x
                << " y: " << aSpeedInfo.y << " z: " << aSpeedInfo.z << "\n";
            break;
            // 客户端控制（陀螺仪）
        case PROTO_CONTROL_GYROSCOPE:
            ProtocolXml::parseGyroscopeInfo(recvPacket, gyroscopeInfo);
            qDebug() << "客户端控制（陀螺仪）\n x: " << gyroscopeInfo.x
                << " y: " << gyroscopeInfo.y << " z: " << gyroscopeInfo.z << "\n";
            break;
        case -1:
            qDebug() << "Error Package Format!\n";
    }
}

/*
<?xml version="1.0" encoding="utf-8" ?>
    <wiidroid type="11">           // 消息类型 11
        <coord-x>x</coord-x>       // x, y, z 三轴数据
        <coord-y>y</coord-y>
        <coord-z>z</coord-z>
     </wiidroid>
 */
void ProtocolXml::parseASpeedInfo(QByteArray &recvPacket, ASpeedInfo &aSpeedInfo)
{
    QXmlStreamReader reader(recvPacket);

    while (!reader.atEnd()) {
        QXmlStreamReader::TokenType type = reader.readNext();

        if (type == QXmlStreamReader::StartElement) {
            if (reader.name() == "coord-x") {
                aSpeedInfo.x = reader.readElementText(QXmlStreamReader::SkipChildElements)
                .toDouble();
            } else if (reader.name() == "coord-y") {
                aSpeedInfo.y = reader.readElementText(QXmlStreamReader::SkipChildElements)
                .toDouble();
            } else if (reader.name() == "coord-z") {
                aSpeedInfo.z = reader.readElementText(QXmlStreamReader::SkipChildElements)
                .toDouble();
            }
        }
    }

    if (reader.hasError()) {
        qDebug() << "XML Format Error:" << reader.errorString() << "\r\n";
    }
}

常见的通信模型

研究server模型的目的

适应特定的硬件体系与OS特点
比如说相同的server模型在SMP体系下与NUMA下的表现就可能不尽相同，又如在linux下表现尚可的进程模型在windows下面就非常吃力。好的server 模型应该从硬件和OS的进步发展中，得到最大化的好处。

实现维护成本与性能的平衡
好的模型会在编程难度与性能之间做比较好的平衡，并且会很容易地在特定场景下做重心偏移。

基本模型


多进程模型与原理

Unix/Linux特有模型，不必多说，可参考**子进程自父进程继承什么或未继承什么。**

最典型的应用当数传统CGI了。什么语言能写CGI？只要写出来的东东能运行，就能当CGI。c/c++、php、python、perl、甚至shell等等。

优化下就是prefork模型，传说中的进程池。

进程数的经验值可以这样估计: n=current * delay
Current 是并发量，delay 是平均任务时延。
当delay 为2，并发量current 为100 时，进程数至少要为200。

缺点：用进程数来抗并发用户数，因一台机器可启动的进程数是有限的，还没见到过进程能开到K级别，并且当进程太多时OS调度和切换开销往往也大于业务本身了。

多线程模型与原理

也不必多说了吧？对其进行简单的优化就是线程池模型了。

线程池代码: 头文件 实现

上面代码看看思想就好，99.99%的可能会有bug。

你会发现，C写的线程池把互斥锁、条件变量、队列和代码逻辑混合在一起很难理解。我们引入C++和RAII技术：RAII就是资源获取即初始化。简单说就是由相关的类来拥有和处理资源，在构造函数里进行资源的获取，在析构函数里对资源进行释放。由语言天生的作用域来控制资源，极大的解放了生产力和程序员思想包袱。

pthread_mutex的 例子

怎么用？戳这里的 无界阻塞队列

封装之后的代码：线程池

从同步到异步


阻塞、非阻塞、同步、异步

非阻塞+IO复用

推荐方式，非阻塞必然和IO复用联合起来~（不然你要一直在用户态做轮询吗？）

这是异步IO？

啥是异步IO？看POSIX.1对同步I/O和异步I/O的定义：

  • 同步I/O操作导致发出请求的进程被阻塞直到I/O操作完成。
  • 异步I/O操作在I/O操作期间不导致发出请求的进程被阻塞。

根据这个定义，阻塞，非阻塞，多路复用，信号驱动均属于同步I/O(尽管信号驱动由于习惯原因，在以前被成为异步I/O)


Linux目前实现的两套异步IO方法

Pthread实现的AIO和Linxu内核实现的Native AIO。

缺点？Pthread的是在用线程模拟！完全不可用！内核的倒是异步，但是目前的实现没法利用IO缓存！不过在一些场合还是不错的。

可以参考：Linux AIO（异步IO）那点事儿

好吧，不明觉厉的同学暂时还是老老实实的用EventLoop+IO线程池吧~

吐槽下，windows很早以前的的IOCP就是纯异步了…迅雷很早以前都在用…


Reactor模型与Proactor模型

重头戏，先看看 【翻译】两种高性能I/O设计模式(Reactor/Proactor)的比较，到时候我们现场重点聊聊Reactor这个。这里就不描述了，细节太多，问题太多。我希望这里作为大家讨论的重点，而不是现在用文字完全描述。

其次，单个EventLoop循环如果跑在了单个进程/线程中，对于多核服务器来说，是个浪费。多线程和多进程需要注意的一些点还有false sharing等现象和cache的利用以及上下的切换。前者看SMP架构多线程程序的一种性能衰退现象—False Sharing，后者看cpu绑定和cpu亲和性。最后不要忘记了函数重入性与线程安全。

什么，你要代码示例？看这里.

内核级别的优化，来自最近火起来的新浪的FastOS计划内的FastSocket.

Linux服务器程序规范

  1. 一般以后台守进程形式运行，没有控制终端不接受用户输入。
  2. 通常有一套日志系统，至少能输出到文件。
  3. 一般以非root的特殊用户身份运行。
  4. 通常是可配置的，文件放在/etc下。
  5. 通常需要在启动的时候生成一个PID文件并存入/var/run目录中，记录该后台进程的PID 。

标准库与第三方库

C/C++相关

太多了，数不胜数，典型的有libev、libevent、libuv、boost asio、cpp-netlib、POCO

太多了，还有各种特殊用途的，比如SSL，DNS异步解析，HTTP相关操作的curl等，不详细说了。

国外程序员整理的 C++ 资源大全

C/C++网络库比较

libev库的用法

Libev轻网络库 源码浅析

UVBook中文版

Java相关

标准库就是socket和nio了。

第三方库很多，比如mina、netty等，推荐后者，应用的比较多且比前者效率好些。

Python相关

大名鼎鼎的 Twisted.

我看到的最棒的Twisted入门教程

如果时间允许，我们还要：
剖析一个流行的开源服务器模型，比如nginx的框架和实现，顺道看看阿里核心系统团队怎么对nginx的数据结构和算法进行的优化～

下一站，分布式系统设计与实现

啥是分布式？别被名字吓到了，分布式的定义如下：

组件分布在联网的计算机上，组件之间通过传递消息进行通信和动作协调的系统。

特性：组件的并发性、缺乏全局时钟、组件故障的独立性
动机：资源共享
挑战：组件异构性、开放性、安全性、可伸缩性、故障处理、并发性、透明性、服务质量。

怎么学？哈哈，我还不会，跟着大牛们摸索，不过分布式两大基础协议之一的一致性哈希算法我介绍过的，这个必须会。

一致性hash算法

服务器端程序设计就这么一点内容吗？
No, we are too young, too simple.
路很长，现在还远远不是终点，我们欠缺的还有很多！共勉！

赏杯咖啡鼓励下~