安装

安装 pcre

1
2
3
4

下载
解压
./configure
make && make install

更新依赖

1

sudo yum install make zlib zlib-devel gcc-c++ libtool openssl openssl-devel

安装 nginx

1
2
3
4

下载
解压
./configure
make && make install

CentOS7 的默认防火墙改成了 firewall，不再使用 iptables 为默认防火墙了

安装好 nginx 后需要打开 80 端口

1
2
3
4
5

firewall-cmd --list-all #查看开发的端口号
firewall-cmd --zone=public --add-port=80/tcp --permanent # 开发 80 端口 tcp 协议
# --zone #作用域
# --add-port=80/tcp #添加端口，格式：端口/通讯协议
# --permanent #永久生效，没有此参数重启后失效

firewall 相关命令

1
2
3
4

systemctl stop firewalld.service # 停止
systemctl start firewalld.service # 启动
systemctl status Firewalld.service # 状态
systemctl restart firewalld.service # 重启

相关命令

查看版本号：

1
2

[root@centos-7 sbin]# ./nginx -v
nginx version: nginx/1.19.1

停止：

1
2
3

[root@centos-7 sbin]# ./nginx -s stop
[root@centos-7 sbin]# ps aux | grep nginx
root     16465  0.0  0.0 112824   980 pts/0    S+   21:31   0:00 grep --color=auto nginx

启动：

1
2
3
4
5

[root@centos-7 sbin]# ./nginx
[root@centos-7 sbin]# ps aux | grep nginx
root     16475  0.0  0.0  20568   620 ?        Ss   21:32   0:00 nginx: master process ./nginx
nobody   16476  0.0  0.0  23092  1380 ?        S    21:32   0:00 nginx: worker process
root     16478  0.0  0.0 112824   976 pts/0    S+   21:32   0:00 grep --color=auto nginx

重加载：

1
2
3
4

[root@centos-7 sbin]# ./nginx -s reload
[root@centos-7 sbin]# ps aux | grep nginx
root     16475  0.0  0.0  20708  1344 ?        Ss   21:32   0:00 nginx: master process ./nginx
nobody   16480  0.0  0.0  23208  1492 ?        S    21:33   0:00 nginx: worker process

配置文件

一般在/usr/local/nginx/conf下。

注意：如果在 nginx 安装过程中指定了--prefix=/path/的情况下，这个目录就在指定的 path 下。

注意：yum 安装的可能不在这个目录下。

配置文件分为 3 个部分：

• 全局块（对应下文中配置文件的 1-10 行）

  从配置文件开始到 events 块之间的内容，主要会设置一些影响 nginx 服务器整体运行的配置指令。

  主要包括配置运行 nginx 服务器的用户(组)、允许生成的 worker process 数，进程 PID 存放路径、日志存放路径和类型、配置文件的引入等。

  比如：worker_processes 1;是 nginx 服务器并发处理服务的关键配置，值越大，可以支持的并发处理量也越多，但是会受到硬件、软件等设备的制约。（和 CPU 核心数量一致比较合理？）

• events 块

  主要影响 nginx 服务器与用户的网络连接。

  比如：worker_connections 1024; 支持的最大连接数。

• http 块

  配置中最频繁的步伐，代理、缓存、日志定义绝大多数功能和第三方模块的配置都在这里

  注意：http 块也可以包括 http 全局块、server 块。

• • http 全局块（下文中 17-33 行）
  • 包括文件引入、mime-type 定义、日志自定义、连接超时时间、单链接请求数上限等。

• • server 块

  • 和虚拟主机有密切关系，虚拟主机从用户角度看，和一台独立的硬件主机是完全一样的，该技术的产生是为了节省互联网服务器硬件成本。

  • 每个 http 块可以包括多个 server 块，每个 server 块就相当于一个虚拟主机。

  • 每个 server 块也分为全局 server 块以及可以同时包含多个 location 块。

  • 全局 server 块（下文 35-41 行）最常见的就是配置本虚拟主机的监听配置和本虚拟主机的名称或 IP 配置。

  • location 块，一个 server 块可以包含多个 location 块，主要是基于 nginx 服务器接收到的请求字符串(例如 server_name/uri-string)，对虚拟主机名称（也可以是IP别名）之外的字符串（例如前面的/uri-string）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有许多第三方模块的配置也在这里进行。

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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}

}

NGINX 原理

master & worker

1
2
3

[root@centos-7 keepalived]# ps aux | grep nginx
root     11262  0.0  0.0  20612  1424 ?        Ss   14:14   0:00 nginx: master process ./nginx
nobody   18694  0.0  0.0  23124  1664 ?        S    16:27   0:00 nginx: worker process

worker 是如何工作的？

争抢。

一个 master 和多个 worker 的好处？

1、可以使用 nginx -s reload 热部署

当使用了热部署后，之前有 client 请求的 worker 还是按照之前的规则进行处理请求，空闲的 worker 就可以根据新的配置来进行处理 client 的请求。

2、对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查找时，也会方便很多。

3、采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快启动新的worker进程。

当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。

设置多少个 worker 合适？

Nginx同redis类似都采用了io多路复用机制，每个worker都是一个独立的进程，但每个进程里只有一个主线程，通过异步非阻塞的方式来处理请求，即使是 千上万个请求也不在话下。

每个worker的线程可以把一个cpu的性能发挥到极致。所以worker数和服务器的cpu数相等是最为适宜的。设少了会浪费cpu，设多了会造成cpu频繁切换上下文带来的损耗。

1
2
3
4
5
6
7
8

# 设置worker数量
worker_processes 4

# work绑定cpu(4work绑定4cpu)
worker_cpu_affinity 0001 0010 0100 1000

# work绑定cpu (4work绑定8cpu中的4个)
worker_cpu_affinity 0000001 00000010 00000100 00001000

连接数 worker_connection

这个值是表示每个worker进程所能建立连接的最大值。

所以，一个nginx 能建立的最大连接数，应该是worker.connections * worker processes。

当然，这里说的是最大连接数，对于HTTP 请求本地资源来说，能够支持的最大并发数量是worker.connections * worker processes。

如果是支持http1.1的浏览器每次访问要占两个连接，所以普通的静态访问最大并发数是worker.connections * worker.processes / 2。

而如果是HTTP作为反向代理来说，最大并发数量应该是worker.connections * worker_proceses/4。

因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。

发送请求，占用了woker的几个连接数?

2 个或者 4 个。

比如请求的是静态资源，一来一回是两个连接数。

如果访问别的资源比如说是 tomcat，则 worker 和 tomcat 也有一来一回两个连接，所以是 4 个连接数。

nginx有一个master,有四个woker,每个woker支持最大的连接数1024,支持的最大并发数是多少?

普通的静态访问最大并发数是: worker connections * worker processes/2

而如果是HTTP作为反向代理来说，最大并发数量应该是worker connections * worker processes/4

EOF

6、伸缩性-永无止境

架构的伸缩性设计

不同功能进行物理分离实现伸缩

纵向分离（分层后分离）
横向分离（业务分割后分离）

单一功能通过集群规模实现伸缩

当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车。

应用服务器集群的伸缩性设计

HTTP 重定向负载均衡

根据请求，计算一个服务器地址，利用 HTTP 302 重定向到服务器地址。
优点：
比较简单。
缺点：
浏览器需要两次请求服务器才能完成一次访问，性能较差；
重定向服务器自身的处理能力可能成为性能瓶颈；
302 重定向可能被搜索引擎判断为 SEO 作弊，降低搜索排名。

DNS 域名解析负载均衡

在 DNS 服务器中配置多个 A 记录，如： www.xxx.com IN A 114.100.80.1 和 www.xxx.com IN A 114.100.80.2。每次域名解析请求都会根据负载均衡算法计算一个不同的 IP 地址返回。
优点：
负载均衡工作转交给 DNS，省去了一些工作内容。
DNS 还支持基于地理位置的域名解析。
缺点：
DNS 多级解析，每一级 DNS 都可能缓存 A 记录，当某台服务器下线后，即使修改了 A 记录，也得等一会才能生效。

可以部分使用 DNS 域名解析，解析作为第一级负载均衡手段，即解析得到的一组服务器并不是真正提供 Web 服务的物理服务器，而是同样提供负载均衡的内部服务器。

反向代理负载均衡

反向代理服务器转发请求在 HTTP 协议层面，因此也称为 应用层负载均衡。
优点：
和反向代理服务器功能集成在一起，部署简单。
缺点：
反向代理服务器是所有请求和响应的中转站，性能可能会成为瓶颈。

IP 负载均衡

SNAT 源地址转换！
优点：
IP 负载均衡在内核进程中完成数据分发，比反向代理负载均衡（在应用层分发）有更好的性能；
缺点：
所有请求和响应都要经过负载均衡服务器，集群最大相应数据屯独立受制于负载均衡服务器网卡带宽；

数据链路负载均衡

在通信协议的数据链路层修改 mac 地址进行负载均衡。
这种负载均衡方式又称作直接路由方式（DR）。
也称为三角模式。
在 Linux 上比较好的开源产品是 LVS（Linux Virtual Server）

负载均衡算法

负载均衡服务器的实现可以分为 2 个部分：
1、根据负载均衡算法和 Web 服务器列表得到集群中一台 Web 服务器的地址。
2、将请求数据发送到该地址对应的 Web 服务器上。

轮询（Round Robin，RR）

适用于所有服务器硬件都相同的场景。

加权轮询（Weighted Round Robin，WRR）

根据硬件性能，高性能服务器能分配更多请求。

随机（Random）

简单实用，随机数本身就很均衡。
也可以改一改成为加权随机法。

最少连接（Least Connections）

记录每个服务器正在处理的连接数（请求数），新请求发给连接数最少的那个。
同样可以实现个加权最少连接。

源地址散列（Source Hashing）

一个 IP 地址进行 Hash 得到应用服务器地址，这样来自同一个 IP 地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内复用，从而实现会话粘滞。

分布式缓存集群的伸缩性设计

Memcached 分布式缓存集群的访问模型

set(key, data)、get(key)
路由根据 key 计算对应应该从哪台服务器写缓存，从哪台服务器读缓存。

Memcached 分布式缓存集群的伸缩性挑战

对于集群的管理，路由算法至关重要，决定着究竟该访问集群中的哪台服务器。
简单的路由算法就是余数 Hash。
对于余数 Hash，当集群需要扩容的时候，事情就比较糟糕了。
假设 3 台缓存服务器需要扩容到 4 台，更改服务器列表，依然使用余数 Hash，用 4/key 的 Hash 值大约有 75%(3/4) 不能正确命中，随着服务器集群规模的增大，这个比例直线上升！
当 100 台集群中增加一台，不能命中的概率是 99%( n/(n+1) )。

大部分的业务数据读操作请求事实上是通过缓存获取的，只有少量的操作请求会访问数据库。
当大量的缓存出现不能命中时，对于数据库的压力就很大了，甚至宕机。

一种解决方法就是在网站访问了最少的时候进行缓存服务器集群扩容，然后通过模拟请求的方法来预热缓存。
另一种方法就是通过下面的算法了！

分布式缓存的一致性 Hash 算法

一致性 Hash 算法通过一个叫做一致性 Hash 环的数据结构实现 KEY 到缓存服务器的 Hash 映射。
具体算法过程为：
先构造一个长度为 2^32 的整数环，这个环被称为一致性 Hash 环。
根据节点名称的 Hash 值（其分布范围为[0, 2^32-1]）将缓存服务器节点放置在这个 Hash 环上。
然后根据需要缓存的数据 KEY 的值计算得到其 Hash 值（分布范围同上）。
然后在 Hash 环上顺时针找举例这个 KEY 的 Hash 值最近的缓存服务器节点，完成 KEY 服务器的 Hash 映射查找。

当缓存服务器集群需要扩容的时候，只需要将新加入的节点名称（NODE3）的 Hash 值放入一致性 Hash 环中，由于 KEY 是顺时针查找举例其最近的节点，因此新加入的节点只影响整个环中的一小段。
3台 -> 4台扩容时候的命中率是 75%，远高于余数 Hash 的 25%。

在具体应用中，这个长度为 2^32 的一致性 Hash 环通常使用二叉查找树实现，Hash 查找过程实际上是在二叉查找树中查找不小于查找数的最小数值，这个数的最左叶子节点和最右叶子节点连接构成环。

但是！这个过程还存在一些小问题！

新加入的节点 NODE3 只影响了原来的节点 NODE1，也就是说一部分原来需要访问 NODE1 的缓存数据现在需要访问 NODE3（概率上市 50%）。
但是原来的节点 NODE0 和 NODE2 不受影响，这就意味着 NODE0 和 NODE2 缓存数据量和负载压力是 NODE1 和 NODE3 的两倍。
如果这 4 台机器性能是一样的，那么这种结果不是想要的。

怎么办？

计算机的任何问题都可以通过增加一个虚拟层来解决！
计算机硬件、计算机网络、计算机软件都莫过于此。
计算机网络7层，每一层可以看做是下一层的虚拟层；计算机操作系统可以看做是硬件的虚拟层；JVM 可以看作是操作系统的虚拟层；分层软件架构事实上也是如此。

将每台物理缓存服务器虚拟为一组虚拟缓存服务器，将虚拟服务器的 Hash 值放置在 Hash 环上，KEY 在环上先找到虚拟服务器节点，再得到物理服务器信息。

这样在新加入物理服务器节点时，是将一组虚拟节点加入环中，如果虚拟节点的树木足够多，这组虚拟节点将会影响同样多树木的已经在换上存在的虚拟节点，这些已经存在的虚拟节点又对应不同的物理节点。
最终结果是：新加入一台缓存服务器，将会较为均匀的影响原来及群众已经存在的所有服务器，也就是说分摊原有缓存服务器集群中所有服务器的一小部分负载。

如上图，加入 NODE3 对应的一组虚拟节点为 V30 V32 V32，加入到一致性 Hash 环上后，影响 V01 V12 V22
这三个被影响的虚拟节点对应 NODE0 NODE1 NODE2 三个物理节点。
最终加入一个节点，影响三个物理节点，理想情况下，每个物理节点收到影响的缓存数据量是 1/4 (x/ (x+n))，N 为原物理节点数，X 为新加入物理节点数。也就是及群众已经被缓存的数据有 75% 可以被命中。

理论上虚拟节点数越多，物理节点之间的负载就越均衡。
但是太多影响性能，太少负载不均衡，一般来说经验是 150，根据集群规模和均衡的精度需求，具体对待。

数据存储服务器集群的伸缩性设计

关系数据库集群的伸缩性设计

分库分表，质数。

NoSQL 数据库的伸缩性设计

NoSQL 更关注高可用性和可伸缩性。
舍弃了以关系代数为基础的结构化查询语言（SQL）和事务一致性保证（ACID）。

EOF！

高可用-万无一失

廉价的服务器硬件故障是常态，网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够访问。
实现上述高可用方案的主要数据和服务的手段是冗余备份和失效转移。


应用层：应对高并发，负载均衡，心跳检测监控，不可用时候剔除。
服务层：通过集群方式实现高可用，被应用层通过分布式调用框架访问，分布式调用框架会在客户端程序中实现软件负载均衡、心跳检测。
数据层：同步复制，冗余备份。

高可用的应用

健身房小姐姐填表单的栗子。
无状态性！！！


可以直接通过负载均衡实现无状态服务的负载均衡。


应用服务器集群的 Session 管理
事实上，业务总是有状态的，在交易类的电商网站需要有购物车记录的购买信息，用户每次购买请求都是向购物车中增加商品；在社交类网站中，需要记录用户的当前登录状态、最新发布的消息和好友列表等，每次刷新页面都需要更新这些信息。

1. Session 复制

应用服务器开启 Web 容器的 Session 复制功能，在集群中的几台服务器之间同步 Session 对象，每台服务器保存所有用户的 Session 信息。
当集群规模较大时候，大量的 Session 复制通信占用服务器的网络资源较大，甚至有内存不够存 Session 情况。

2. Session 绑定

Session 绑定可以利用负载均衡的源地址 Hash 算法实现，总是将同一个 IP 的请求分发到同一台服务器上，也可以根据 Cookie 信息将同一个用户的请求分发到同一台服务器上。这个负载均衡服务器必须工作在 HTTP 协议层上。这样就能保证这个用户的请求都在同一台服务器上，这种方法又被成为会话粘滞。
但是 Session 绑定的方案不符合高可用程序，某台服务器宕机后一些依赖此服务器的用户的服务就不可用了。

3. 利用 Cookie 记录 Session
   1. Cookie 大小限制，记录信息有限
   2. 每次响应都要传输 Cookie，影响性能
   3. 如果用户关闭 Cookie 功能，访问就会不正常
4. Session 分离

独立的 Session 服务器或者集群，基础服务平台。

高可用的服务

可复用的服务和应用一样，也是无状态的服务，此可以使用类似负载均衡的失效转移策略实现高可用服务。

1. 分级管理
   1. 核心应用和服务优先使用更好的硬件，运维响应时间也要迅速
2. 超时设置
   1. 超时后继续重试或者将请求失效转移到提供相同服务的其他服务器上
3. 异步调用
   1. 消息队列等异步调用的方式
4. 服务降级
   1. 拒绝服务？关闭服务？
   2. 拒绝服务：拒绝优先级低的应用调用，减少服务器的并发数，保证核心功能正常调用；或者随机拒绝部分请求调用，节约资源。
   3. 关闭服务：关闭不中哟的部分服务，或者服务内部关闭部分不重要的功能。
5. 幂等性设计
   1. 服务重复调用是无法避免的，应用层也不需要关心服务是否真的失效，只要没有得到调用成功的响应，就可以认为调用失效，并充实服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

高可用的数据

数据备份和失效转移机制。


为了保证数据的高可用，网站通常会牺牲另一个很重要的指标：数据一致性。
**
CAP 原理
数据持久性
数据可访问性
数据一致性

1. 数据强一致
2. 数据用户一致
3. 数据最终一致

数据备份

异步热备份、同步热备份

失效确认

访问转移

转移到存储的数据完全一样的服务器上（对等服务器）
如果服务不对等，就需要重新计算路由，选择存储服务器。

数据恢复

。。。

软件质量保证

网站发布

飞行中给飞机换个引擎。

自动化测试

全面的回归测试。

预发布验证

预发布机器。

代码控制

主干发布，分支开发。
主干开发，分支发布。
~~

自动化发布

灰度发布

第一天发布 0999 服务器，遇到故障回滚。
第二天发布 10001999 服务器，遇到故障回滚。
。。。

网站运行监控

不允许没有监控的系统上线。

监控数据采集

1. 用户行为日志收集
   1. 服务端日志手机
   2. 客户端浏览器日志收集
2. 服务器性能监控
3. 运行数据报告

监控管理

1. 系统报警
2. 失效转移
3. 自动优雅降级

EOF！

高性能-瞬时响应

检查请求各个环节的诶之，分析哪个环节响应时间不合理、超出预期；
检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是 CPU，是代码问题还是架构设计不合理，或者系统资源确实不足。

性能测试指标

响应时间、并发数、吞吐量、性能计数器等。

响应时间

每个响应时间比较短不好测试，常用方法是重复请求很多次，求平均时间。

并发数

系统能够同时处理请求的数目，对于网站而言，指同时提交请求的用户数目。


测试程序通过多线程/协成模拟并发用户的办法来测试系统的并发处理能力，为了真实的模拟用户行为，测试程序并不是启动多线程后不停地发送请求，而是再两次请求中间加入一个随机等待时间，被称为思考时间。

吞吐量

TPS（每秒事务数）
HPS（每秒HTTP请求数）
QPS（每秒查询数）

性能计数器

System Load、对象与县城数、内存使用、CPU 使用、磁盘与网络 I/O 等指标。
系统监控、报警。


System Load（系统负载），指当前正在被 CPU 执行和等待被执行的进程数目总和，是反应系统忙闲程度的重要指标。
Load 理想值是 CPU 数目，Load 高于 CPU 数目的时候表示系统资源不足，影响程序的执行性能。

top 命令查看，3 个浮点数，表示最近 1min、5min、15min 运行队列平均进程数。

性能优化

前端性能优化

减少 HTTP 请求

合并 CSS 文件、合并 JS 文件、合并图片、懒加载等。

使用浏览器缓存

缓存 CSS、JS、Logo、图表等静态资源。
通过设置 HTTP 头中的 Cache-Control 和 Expires 属性，控制浏览器的缓存。

有时候静态资源变化需要及时应用到浏览器，可以通过修改文件名实现，即更新 JS 文件并不更新 JS 文件内容。

逐渐更新：一次更新一部分图标文件等等。

启用压缩

文本文件的压缩可达 80% 以上，因此 HTML、CSS、JS 通过启用 GZip 压缩可以达到好的效果，但是压缩对服务器和浏览器会产生一定的压力，在网络状况好的情况下要权衡考虑。

CSS 放在页面最上面，JS 放在页面最下面

浏览器会在下载完全部的 CSS 后才对网页进行渲染。
浏览器在加载 JS 后立即执行，有可能阻塞整个页面。

减少 Cookie 传输

减少 Cookie 次数。Cookie 会包含在每次的请求和响应中，太大的 cookie 会影像数据传输。
静态资源的传输，有时候带上 Cookie 没有意义，有的时候有意义（比如图片验证码）。

CDN 加速

emmm 类似于缓存

反向代理

emmm 类似于缓存

服务端性能优化

网站性能优化第一定律：优先考虑缓存优化性能。

分布式缓存

注意要合理使用缓存。缓存穿透、雪崩、击穿！！！
频繁修改的数据！
没有热点的访问！
数据不一致和脏读！
缓存可用性！


缓存预热！

异步操作

消息队列等。
消息队列（削峰作用）。

使用集群

配置负载均衡。

代码优化

多线程、协成。
资源使用统一管理（池，进程池、线程池、连接池、对象池、单例）

数据结构

哈希？

垃圾回收

。。。

存储性能优化

机械硬盘、固态硬盘。

B+树、LSM 树。

传统的关系数据库使用的是 B+ 树，层次最多三层。
现在很多 NoSQL 数据库使用 LSM 树。

存储阵列

RAID0、RAID1、RAID10、RAID5、RAID6。
HDFS 中，系统在整个存储集群的多态服务器上进行数据并发读写备份，可以看做在服务器集群规模上上线了类似 RAID 的功能，因此不需要磁盘 RAID。
MapReduce 并发访问，迁移计算而不是不迁移数据。


HDFS 中两个重要的服务器角色：NameNode（名字服务器节点）和 DataNode（数据存储节点）。
NameNode 在 HDFS 中只部署一个实例，提供元数据服务，相当于操作系统中的文件分配表 FAT，管理文件名 Block 的分配，维护整个文件系统的结构。
DataNode 则部署在 HDFS 集群中其他所有服务器上，提供真正的数据存储服务。

大型网站核心架构要素

性能

浏览器端：浏览器缓存、页面压缩、合理页面布局、减少 Cookie 传出、CDN。
应用服务器端：本地缓存、分布式缓存、异步操作、服务器集群。
代码层面：多线程、改善内存管理等。
数据库端：索引、缓存、SQL 优化等性能优化手段、NoSQL 优化数据模型、存储结构、伸缩性。

可用性

假设系统中任何一台或多台服务器宕机时，以及出现各种不可预期的问题时，系统整体依然保持可用。
提高网站可用性的主要手段是冗余。
1、对于应用服务器，多台服务器负载均衡，前提是应用服务器上不能保存请求的回话信息（小姐姐小哥哥游泳健身表单）。
2、对于存储服务器，实时热备份。
3、开发过程质量保证，预发布验证、自动化测试、自动化发布、灰度发布，减少将故障引入线上环境。

伸缩性

所谓伸缩性是指通过不断向及群众加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。

1、对于应用服务器集群，只要服务器上不保存数据，所有服务器都是对等的，通过合适的负载均衡设备就可以向进群中不断添加服务器。
2、对于缓存服务器集群，加入新的服务器可能会导致缓存路由失败，进而导致及群众大部分缓存数据无法访问。虽然缓存的数据可以通过数据库重新加载，但是如果应用已经严重依赖缓存，可能会导致整个网站崩溃，需要改进缓存路由算法保证缓存数据的可访问性。
3、数据库虽然支持数据复制，主从热备等机制，但是很难做到大规模集群的可伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。

至于 NoSQL 数据库，天生就是为海量数据而生，伸缩性通常都非常好。

扩展性

增加新的业务产品时，是否可以实现对现有产品透明吴映香，不需要任何改动或者很少的搞懂现有业务功能就可以上线新的产品。不同产品之间的少耦合。
网站可扩展架构的主要手段是事件驱动和分布式服务。

事件驱动架构在网站通常利用消息队列来实现，分布式服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。

安全性

现存和潜在的攻击和窃密手段，是否有可靠的应对策略。

EOF

大型网站架构模式

每一个模式描述了一个在我们周围不断重复大声的问题以及问题解决方案的核心。

分层

将系统横向切分。
分层结构在计算机中无处不在，网络的 ISO 7层分层，计算机硬件、操作系统、应用软件也是一种分层。
网站系统中：应用层、服务层、数据层。
分层架构的挑战：合理规划层次边界和接口。
进制跨层次的调用（应用层直接调用数据层）和逆向调用（数据层调用服务层，或者服务层调用应用层）。

分割

将系统纵向切分。
将每一层按模块进行分割，每个模块由不同的团队负责。

分布式

分布式应用和服务、分布式静态资源、分布式数据和存储、分布式计算（Hadoop 的 MapReduce 分布式计算框架，移动计算而不是移动数据）。

集群

使用分布式已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块（比如网站首页），还需要将独立部署的服务器集群化，即多态服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

缓存

CDN、反向代理、本地缓存、分布式缓存。
使用缓存有两个条件：
1、数据访问热点不均衡，某些数据会被更频繁的访问；
2、数据再某个时间段内有效，不会很快过期，否则缓存的数据会因已经失效而产生脏读，影响正确性。

异步

单一服武器内部可以通过多线程共享内存队列的方式实现异步，业务线程将输出写入队列，处理线程从队列读取进行处理；
分布式系统中，多个服务器集群通过分布式消息队列实现异步（内存队列的分布式部署）。
异步架构是典型的生产者消费者模型，两者不存在直接调用，只需要保持数据结构不变，彼此功能实现可以随意变化而不相互影响，这对网站拓展新功能非常便利。

使用异步队列还有如下特性：
1、提供系统可用性，消费者服务器故障，数据再消息队列中堆积，生产者继续处理就可以了。
2、加快网站响应速度，业务端将请求写入消息队里，不需要等待消费者处理就可以返回。
3、消除并发访问高峰，消息队列将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次处理。

冗余

定期备份，冷备份。
主从热备份。
容灾数据中心。
去中心化。

自动化

发布过程自动化、自动化代码管理、自动化测试、自动化安全监测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级（网站遇到高峰超出处理能力，为了保证整个网站安全可用，关闭一些不用的服务或者拒绝部分请求）、自动化分配资源。

安全

加密、安全校验、风险控制。

EOF

大型网站架构演化

网站架构设计的目标

高可用、高性能、易扩展、可伸缩、安全。

网站的价值在于它能为用户提供什么价值，在于网站能做什么，不在于网站怎么做的。
不是所有的问题都可以通过技术来解决。
有的时候调整业务也是很好的一种方式。
技术是用来解决业务问题的，业务的问题也可以尝试通过业务的手段去解决。

网站架构演化发展历程

初始阶段

应用服务和数据服务分离

一台服务器逐渐不能满足需求，越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。
将存储和应用服务器分开。

缓存

80% 的业务访问集中在 20% 的数据上。
缓存又可以有两种方案：

1. 缓存在应用服务器的本地缓存；
   1. 访问速度较快，但是收到内存限制。
2. 专门的分布式缓存服务器；
   1. 理论上不受内存容量限制。

应用服务器集群

使用集群是网站解决高并发、海量数据问题的常用手段。

数据库读写分离

网站使用缓存后，绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
大部分主流数据库提供主从热备功能，配置主从关系，将数据同步，利用这一功能进行读写分离，改善数据库负载压力。

反向代理和 CDN 加速

CDN 和 反向代理的基本原理都是缓存。
CDN 部署在网络提供商的机房，用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；
反向代理部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

分布式文件系统和分布式数据库

文件服务器正常，文件太多放不下了。
分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常大的时候才使用。
不到不得已时，网站常用的数据库拆分手段是业务分库，不同业务使用不同数据库部署在不同的机器上。

NoSQL 和搜索引擎

网站业务愈加复杂，对数据存储和检索的需求也越来越复杂，网站需要使用一些菲关系数据库技术如 NoSQL 和非数据库查询技术如搜索引擎。

业务拆分

纵向拆分。

服务拆分

横向拆分。
提供一些统一的常用的相同的业务操作。
业务部门、基础服务器部门、数据部门等等。

EOF

缓存雪崩、缓存击穿、缓存穿透的概念和解决方案。

布隆过滤器的简单原理和应用。

缓存雪崩

就是缓存层里的数据同一个时间点失效，那么这些数据就会集中打向 MySQL。

缓存击穿

缓存里有一条数据，一条数据失效后也是穿过了 redis 打到了 MySQL。

缓存击穿、缓存雪崩属于缓存穿透的一种特殊表现形式。

缓存穿透

描述

当找 redis 找不到数据时候，就会出现缓存穿透。

低频率的缓存穿透不可怕，正常现象。

当高频率的穿透就影响大了。

黑客攻击的场景，模拟很多客户端发送 id = -1 的请求。

id = -1 在 redis 中找不到，穿过 redis 找到数据库，数据处理不过来就崩了（拒绝服务攻击DDOS）。

解决方案

• 通过 MySQL 中找不到的值缓存在 redis 中。（黑客太菜了）

  当然第一次查询 id = -1 的时候可能没找到穿透了，但是这次我把 id = -1 放在了 redis 中。

  id = -2 再查询我再放。。。。也是大量的访问数据库。（UUID 黑盒 每次生成一个不一样的 ID）

  这个方案适得其反，redis 一定的数据淘汰策略（LRU、LFU…）如果每次都是 UUID，那么真正需要缓存的数据就被淘汰了，redis 里是一些垃圾数据。

• 过滤器（redis），这个过滤器把 MySQL 里面的所有 id 号，放在 redis 和 MySQL 的中间（不行），不一定是通过 id 查询或者 id 过多，这样就会导致过滤器的效率太低，内存紧张，导致整个链路都很慢。

  解决过滤器中数据过多的场景。布隆过滤器，通过一定的错误率降低内存的占用。

  比如 id = 100，传给 hash 函数，来一个 bin(二进制, size=10) 数组，保证哈希结果在 0-9 之间。。。。。。

  拿到 id = 100，计算出的 hash 相同，就会告诉客户端你要的数据是有的。

  错误发生在计算哈希上，如果布隆过滤器告诉你数据存在，那么数据不一定存在。如果布隆过滤器告诉你数据不存在，那么这个数据一定不存在。

  宁可错杀 3k 不放过一个。发生哈希碰撞就有可能是一次错误，数组的长度影响错误率。

  和哈希函数的个数也有关系。布隆过滤器的简单实现是 3 个 hash 函数计算的三个位置标示一个数据是否存在。哈希函数个数多了反而错误率升高。数组长度很长会增加内存占用。

  【人生中最重要的一个字“度”】，通过算法计算合适的 hash 函数个数和数组长度。通常的布隆过滤器会要求提供允许的错误率 fpp 和存储的数据量 n。然后通过公式计算出数组大小 m 和 hash 函数的个数 k。

  m = - ( n*ln(fpp) ) / ( ln(2) ^2 )

  k = m/n * ln(2)

  遇到删除数据的情况？如果 id = 100 和 id = 10 的 hash 结果相同，我删除了 id = 10 的数据，那么布隆过滤器的这个 hash 结果的位置不能设为 0，因为还有数据对应。

  如果场景中有频繁的数据删除情况，建议搞一个二维的数组，第二维的数组用来计数。（长度 100亿占用 1GB 左右）

  面试题：文件 A 存了 100 亿个URL，B 文件也是 100 亿个 URL。只给一个 4GB 内存文件，快速找出 AB 的交集。

  模糊算法

  通过布隆过滤器来计算 A 中的，B 中的 URL，然后找到对应的交集。只需要一次的磁盘 IO 即可。

  精准算法

  A、B 两个大文件拆分 1000 个放一个文件，分块计算 hash 值然后对 1000 取余。然后对A、B的小文件一一比较。拆分成小文件是为了可以加载入内存中。

  相同 URL 的 hash 值相同，取摸后也相同。所以会出现在 1-1 对应的小文件中。

EOF

基础知识

UDP 输出 TCP/IP 协议分层中的传输层。
UDP 是一个不可靠的通信协议，没有重传和确认，没有有序控制，也没有拥塞控制。
UDP 不保证报文的有效传递，不保证报文的有序，也就是说使用 UDP 的时候，我们需要做好丢包、重传、报文组装等工作。
UDP 比较简单，适合的场景还是比较多的，我们常见的 DNS 服务，SNMP 服务都是基于 UDP 协议的，这些场景对时延、丢包都不是特别敏感。另外多人通信的场景，如聊天室、多人游戏等，也都会使用到 UDP 协议。

报文格式

UDP 报头长 8 字节，分别是源端口、目的端口、UDP 报文长度、校验和。
因为 UDP 报文长度只用 2 个字节记录，所以包含报头长度的报文最大长度为 65535 字节。

用UDP协议发送时，用sendto函数最大能发送数据的长度为：65535- IP头(20) - UDP头(8)＝65507字节。用sendto函数发送数据时，如果发送数据长度大于该值，则函数会返回错误。
由于IP有最大MTU，因此，
UDP 包的大小应该是 1500 - IP头(20) - UDP头(8) = 1472(Bytes)

UDP 编程

服务器：
1、创建 socket。
2、绑定要监听的 ip 和 port。
3、循环：
3.1、调用 recvfrom 读取接收到的报文，如果没有报文则阻塞在这里。
3.2、收到报文处理完后调用 sendto 将相应发给客户端。

客户端：
1、创建 socket。
2、循环：
2.1、调用 sendto 发送请求。
2.2、调用 recvfrom 接收相应。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <sys/socket.h>
// 返回值：收到数据的字节数
// 参数：
// 		sockfd：socket描述符
// 		buff：本地缓存
// 		nbytes：缓存最大接收字节数
// 		flags：I/O 相关的参数，一般使用 0 即可
// 		from：发送端的 ip 和 port 等信息
// 		addrlen：from 的大小
ssize_t 
recvfrom(int sockfd, void *buff, size_t nbytes, int flags, 
　　　　　　　　　　struct sockaddr *from, socklen_t *addrlen); 
　　　　
// 返回值：发送了多少字节
// 参数：和上面的 recvfrom 类似　　　　　　
ssize_t
sendto(int sockfd, const void *buff, size_t nbytes, int flags,
                const struct sockaddr *to, socklen_t addrlen); 

代码参考我之前的文章：UDP 回显程序https://blog.csdn.net/Hanoi_ahoj/article/details/105358383

UDP 报文的“无连接”的特点，可以在 UDP 服务器重启之后，继续进行报文的发送，这就是 UDP 报文“无上下文”的最好说明。

有连接的 UDP

通过上文，在 UDP 中是不需要类似于 TCP 编程中的 connect 建立连接的。
其实 UDP 也可以是 “有连接” 的。

下面通过一个程序来测试一下：
客户端： 需要注意的是在创建完 socket 后进行了 connect，绑定了服务器的 ip 和 port。

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

// UDP connect 测试客户端

#include <stdio.h>
#include <string.h>
#include <strings.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>

int main() {
  int socket_fd = socket(AF_INET, SOCK_DGRAM, 0);
  if (socket_fd < 0) {
    perror("socket");
    return -1;
  }

  struct sockaddr_in server_addr;
  bzero(&server_addr, sizeof(server_addr));
  server_addr.sin_family = AF_INET;
  server_addr.sin_port = htons(9090);
  server_addr.sin_addr.s_addr = inet_addr("127.0.0.1");

  int ret = connect(socket_fd, (struct sockaddr*)&server_addr, sizeof(server_addr));
  if (ret < 0) {
    perror("connect");
    return -1;
  }

  while (1) {
    char buf[1024] = {0};
    printf("input>");
    scanf("%s", buf);
    ssize_t n = sendto(socket_fd, buf, strlen(buf), 0, (struct sockaddr*)&server_addr, sizeof(server_addr));
    if (n < 0) {
      perror("sendto");
      continue;
    }

    printf("%zd bytes sent to [%s:%d]\n", n, inet_ntoa(server_addr.sin_addr), ntohs(server_addr.sin_port));

    bzero(buf, sizeof(buf));
    n = recvfrom(socket_fd, buf, sizeof(buf), 0, NULL, NULL);
    if (n < 0) {
      perror("recvfrom");
      return -1;
    }
    printf("resp: %s\n", buf);
  }

  close(socket_fd);
  return 0;
}

服务器： 就是正常的服务器，收到请求原封不动返回。

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

#include <stdio.h>
#include <string.h>
#include <strings.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>

int main() {
  int socket_fd = socket(AF_INET, SOCK_DGRAM, 0);
  if (socket_fd < 0) {
    perror("socket");
    return -1;
  }

  struct sockaddr_in server_addr;
  bzero(&server_addr, sizeof(server_addr));
  server_addr.sin_family = AF_INET;
  server_addr.sin_addr.s_addr = inet_addr("0.0.0.0");
  server_addr.sin_port = htons(9090);
  int ret = bind(socket_fd, (struct sockaddr*)&server_addr, sizeof(server_addr));
  if (ret < 0) {
    perror("bind");
    return -1;
  }

  // 一般服务器不进行 connect 操作
  while (1) {
    char buf[1024] = {0};
    struct sockaddr_in client_addr;
    bzero(&client_addr, sizeof(client_addr));
    socklen_t client_addr_len = sizeof(client_addr);
    ssize_t n = recvfrom(socket_fd, buf, sizeof(buf) - 1, 0,
        (struct sockaddr*)&client_addr, &client_addr_len);
    if (n < 0) {
      perror("recvfrom");
      continue;
    }
    buf[n] = '\0';

    printf("req->[%s:%d] %s\n", inet_ntoa(client_addr.sin_addr),
        ntohs(client_addr.sin_port), buf);

    n = sendto(socket_fd, buf, strlen(buf), 0, (struct sockaddr*)&client_addr, client_addr_len);
    if (n < 0) {
      perror("sendto");
      continue;
    }
  }

  close(socket_fd);
  return 0;
}

1
2

gcc client.c -o client
gcc server.c -o server

测试：
1、不运行 server，只运行 client。
可以看到，在调用 sendto 的时候发送了，但是当走到 recvfrom 的时候出错 Connection refused。

2、运行 server 和 client。
正常的接收请求、处理请求过程。

UDP connect 的作用

不用 connect 的话，不开启 server，运行 client，程序会阻塞在 recvfrom 上。直到服务器重启或者超时。
通常 UDP 的服务器是不需要进行 connect 的，因为 connect 以后这个服务器就只能对这个客户端进行服务器了。

==connect 的作用就是让程序尽早收到错误信息返回：==

通过对 UDP 套接字进行 connect 操作，将 UDP 套接字建立了“上下文”，该套接字和服务器端的地址和端口产生了联系，正是这种绑定关系给了操作系统内核必要的信息，能够将操作系统内核收到的信息和对应的套接字进行关联。

调用 sendto 或者 send 操作函数时，应用程序报文被发送，我们的应用程序返回，操作系统内核接管了该报文，之后操作系统开始尝试往对应的地址和端口发送，因为对应的地址和端口不可达，一个 ICMP 报文会返回给操作系统内核，该 ICMP 报文含有目的地址和端口等信息。

进行了 connect 操作，帮助操作系统内核从容建立了（UDP 套接字——目的地址 + 端口）之间的映射关系，当收到一个 ICMP 不可达报文时，操作系统内核可以从映射表中找出是哪个 UDP 套接字拥有该目的地址和端口，别忘了套接字在操作系统内部是全局唯一的，当我们在该套接字上再次调用 recvfrom 或 recv 方法时，就可以收到操作系统内核返回的“Connection Refused”的信息。

在对 UDP 进行 connect 之后，关于收发函数的使用，很多书籍是这样推荐的：
使用 send 或 write 函数来发送，如果使用 sendto 需要把相关的 to 地址信息置零；
使用 recv 或 read 函数来接收，如果使用 recvfrom 需要把对应的 from 地址信息置零。
其实不同的 UNIX 实现对此表现出来的行为不尽相同。

==效率因素：==

因为如果不使用 connect 方式，每次发送报文都会需要这样的过程：
连接套接字→发送报文→断开套接字→连接套接字→发送报文→断开套接字 →………

而如果使用 connect 方式，就会变成下面这样：
连接套接字→发送报文→发送报文→……→最后断开套接字

我们知道，连接套接字是需要一定开销的，比如需要查找路由表信息。所以，UDP 客户端程序通过 connect 可以获得一定的性能提升。

参考：极客时间 - 网络编程实战(https://time.geekbang.org/column/article/129807)

EOF

基础铺垫

首先来简单说几个问题。

1、程序双击后发生了什么？
程序双击后，程序会被操作系统装载入内存，包括程序的代码、数据等信息。然后从程序的入口开始执行。

2、本机的不同程序间可以相互对话(通信)吗？
当然是可以的，召唤师们经常用的 WeGame 和 LOL 是两个程序，当你在 WeGame 登录后点击启动 LOL，通常情况下再不用在 LOL 输入账号密码了，说明你再 WeGame 登录的账号信息也给了 LOL 的程序。至于是如何给的？
举个实现的例子：当你登录 WeGame 后，你会获得一个 ticket，这个 ticket 代表你的小票，这个小票就有着你的身份信息，你可以凭着这个小票进入召唤师峡谷。这个还得看程序员的具体的实现。

这个就属于进程间通信。

3、如何实现不同主机间的不同进程的对话(通信)？
当然可以，你电脑上的 QQ 和室友电脑上的 QQ，双击后会被载入自己的内存，那么你发的话是如何被室友收到的呢？这个就是不同主机间不同进程的通信，利用网络通信！

4、那问题 3 中的两个 QQ 进程是如何找到对方的呢？
举个栗子：假设你有个女朋友，你的女朋友在北京上大学，你在西安上大学，你的女朋友给你准备了一份礼物，她要把这个礼物寄给你，她会填写快递信息如：
【中国陕西省西安市xxx区，西安xxx大学，xxx收，手机号xxx】
快递小哥可以根据这个地址和手机号唯一的定位到你，然后把快递送到你手里。

在计算机中也是有唯一标识的，这个东西就是 ==IP== 地址，IP 地址标识了网络上的一台主机。
IP 地址就相当于【中国陕西省西安市xxx区，西安xxx大学】。
但是你的电脑上正在运行着很多程序，QQ、LOL、WeGame 等等，对方怎么知道这个包裹发给哪个程序呢？这个就需要另一个东西叫==端口号==。这个端口号就唯一的标识了你电脑上的一个程序。
端口号就相当于【xxx收，手机号xxx】。

这样就可以唯一的标识一个网络上一个主机的一个进程了。

5、什么是协议？
协议就是一种约定，用 4 中的栗子来说，你的女朋友给你寄的是特产烤鸭，她打电话给你说让你拿到后热一下再吃，这就是一种协议。
当然你也可以拿到后不热直接吃。（别吃坏肚子了）
当然她使用中文填写的快递地址信息也是和快递小哥的一种协议(约定)。

6、计算机有大端和小端之分，那数据在网络上传输的时候是按照什么方式传输呢？
规定网络传输的数据都以大端序传输，即先发出的数据是低地址，后发出的数据是高地址。
发送主机通常将发送缓冲区中的数据按内存地址从低到高的顺序发出；
接收主机把从网络上接到的字节依次保存在接收缓冲区中,也是按内存地址从低到高的顺序保存；
TCP/IP协议规定，网络数据流应采用大端字节序，即低地址高字节；
不管这台主机是大端机还是小端机，都会按照这个 TCP/IP 规定的网络字节序来发送/接收数据；
如果当前发送主机是小端，就需要先将数据转成大端；否则就忽略，直接发送即可。

为使网络程序具有可移植性，使同样的C代码在大端和小端计算机上编译后都能正常运行，下文的代码实现均会做网络字节序和主机字节序的转换。
转换需要用到的函数：

1
2
3
4
5

#include <arpa/inet.h>
uint32_t htonl(uint32_t hostlong);  // host to network long
uint16_t htons(uint16_t hostshort);  // host to network short
uint32_t ntohl(uint32_t netlong);  // network to host long
uint16_t ntohs(uint16_t netshort);  // network to host short

好了铺垫就到这里，来说说 UDP 协议。

UDP 协议

UDP 协议就是一种约定，约定了“快递小哥”拿到包裹后根据什么找到你。

UDP 协议格式如下：

其中需要注意的是：
1、2 个字节的 UDP 长度，是这整个 UDP 协议的长度，也就是说上面这张图的数据部分最多放 65535 - 64 字节的数据。资料：TCP、UDP数据包大小的限制
2、校验和，如果校验和出错（和实际收到的数据校验和对不上），这个包裹就被丢弃了。

UDP 网络回显程序

实现如下功能：
客户端 — hello —> 服务器
客户端 <— hello — 服务器

服务端实现

1. 创建一个 socket；
2. 服务器需要绑定一个固定的 IP 和端口号方便客户端找到他；
3. 服务器启动并监听这个端口号；
4. 循环处理：收到请求、处理请求、返回响应。

1

gcc echo_server.c -o echo_server

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

// echo_server.c
// UDP 回显服务器

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main() {
    // 创建 socket
    int fd = socket(AF_INET, SOCK_DGRAM, 0);
    if (fd < 0) {
        perror("socket");
        return 1;
    }
    // 绑定 IP 和 port
    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = inet_addr("0.0.0.0");
    addr.sin_port = htons(8080);
    int ret = bind(fd, (struct sockaddr*)&addr, sizeof(addr));
    if (ret < 0) {
        perror("bind");
        return 1;
    }
    printf("server start!\n");

    // 循环处理收到的请求、返回响应
    while (1) {
        // 读取请求
        char buf[1024] = {0};
        struct sockaddr_in client_addr;  // 客户端 ip 和 port
        socklen_t len = sizeof(client_addr);

        ssize_t n = recvfrom(fd, buf, sizeof(buf) - 1, 0, (struct sockaddr*)&client_addr, &len);
        if (n < 0) {
            perror("recvfrom");
            continue;  // 当一次读取失败，服务器不退出
        }
        buf[n] = '\0';

        // 处理请求
        // 因为是回显服务器，原封不动返回给客户端

        // 返回响应
        n = sendto(fd, buf, strlen(buf), 0, (struct sockaddr*)&client_addr, len);
        if (n < 0) {
            perror("sendto");
            continue;
        }

        printf("[%s:%d] buf: %s\n", inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port), buf);
    }

    close(fd);
    return 0;
}

客户端实现

1. 创建 socket；
2. 配置要连接服务器的 ip 和 port；
3. 循环处理：获取输入、发送给服务器、获取响应结果。

1

gcc echo_client.c -o echo_client

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

// echo_client.c
// UDP 回显客户端

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main() {
    // 创建 socket
    int fd = socket(AF_INET6, SOCK_DGRAM, 0);
    if (fd < 0) {
        perror("socket");
        return 1;
    }

    // 配置要连接服务器的 ip 和 port
    struct sockaddr_in server_addr;
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = inet_addr("127.0.0.1");
    server_addr.sin_port = htons(8080);

    while (1) {
        // 获取输入
        printf("input> ");
        char input[1024] = {0};
        scanf("%s", &input);
        
        // 将输入发送给服务器
        sendto(fd, input, sizeof(input), 0, (struct sockaddr*)&server_addr, sizeof(server_addr));
        printf("req: %s\n", input);
        
        // 接收响应
        char resp[1024] = {0};
        recvfrom(fd, resp, sizeof(resp), 0, (struct sockaddr*)&server_addr, sizeof(server_addr));
        printf("resp: %s\n", resp);
    }

    close(fd);

    return 0;
}

实现说明

1、socket()

socket 函数用来创建一个建立网络通信的端点。

1
2
3

#include <sys/types.h>
#include <sys/socket.h>
int socket(int domain, int type, int protocol);

参数：
domain，在上面的代码中使用 AF_NET，即 IPv4，当然还有其他的选项：

1
2
3
4
5
6
7
8
9
10
11

Name                Purpose                          Man page
AF_UNIX, AF_LOCAL   Local communication              unix(7)
AF_INET             IPv4 Internet protocols          ip(7)
AF_INET6            IPv6 Internet protocols          ipv6(7)
AF_IPX              IPX - Novell protocols
AF_NETLINK          Kernel user interface device     netlink(7)
AF_X25              ITU-T X.25 / ISO-8208 protocol   x25(7)
AF_AX25             Amateur radio AX.25 protocol
AF_ATMPVC           Access to raw ATM PVCs
AF_APPLETALK        Appletalk                        ddp(7)
AF_PACKET           Low level packet interface       packet(7)

type，套接字具有指定的类型，该类型指定通信语义。即代表协议，上述代码中使用 SOCK_DGRAM 代表 UDP。

1
2

SOCK_STREAM 	TCP协议使用这个
SOCK_DGRAM 		UDP协议

protocol，用来指定 socket 所使用的传输协议编号，通常为0。

返回值：
失败返回 -1，成功返回对应的文件描述符。

2、bind()
当使用 socket() 来创建一个 socket 时候，它存在于名称空间(地址族)中，但没有分配给它地址。
bind 用来给 socket 绑定 ip 和 端口。

1

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

返回值：
成功返回 0，失败返回 -1。
参数：
sockfd，创建的 socket 文件描述符。
addr，这个结构体存储协议族、ip、port等信息。
addr_len，addr 的大小。

1
2
3
4

struct sockaddr {
	sa_family_t sa_family;
	char        sa_data[14];
}

socket API 可以都用 struct sockaddr * 类型表示, 在使用的时候需要强制转化成 sockaddr_in；
这样的好处是程序的通用性，可以接收IPv4、IPv6, 以及UNIX Domain Socket 各种类型的sockaddr结构体指针做为参数;

3、sendto()

1
2

ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,
                        const struct sockaddr *dest_addr, socklen_t addrlen);

发送 buf 中的数据 len 个给 dest_addr。

4、recvfrom()

1
2

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

接收到一个数据，src_addr 是输出型参数，代表谁发给我的。

封装 UDP socket

可以看到，上面服务端、客户端实现时候，有一些同样的操作要做，那为了后面使用方便，封装一个 UDP 的 socket 类来实现这些共同的操作。

来分析一下需求：
客户端程序需要：

• 创建 socket
• 关闭 socket
• 接收数据
• 发送数据

服务端程序需要：

• 创建 socket
• 关闭 socket
• 接收数据
• 发送数据
• 绑定端口号

实现

udp_socket.hpp

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

#ifndef __UDP_SOCKET__
#define __UDP_SOCKET__

#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#include <string>

class UdpSocket {
public:
	UdpSocket() : m_fd(-1) {}
    ~UdpSocket() {
        Close();
    }

    // 创建一个 UDP socket
    // 成功返回 true，失败返回 false
	bool Create() {
        m_fd = socket(AF_INET, SOCK_DGRAM, 0);
        return m_fd == -1 ? false : true;
    }
    // 关闭 socket
    // 成功返回 true，失败返回 false
    bool Close() {
        return close(m_fd) == -1 ? false : true;
    }
    // 绑定 ip 和 port
    bool Bind(const std::string& ip, const std::uint16_t& port) {
        sockaddr_in addr;
        addr.sin_family = AF_INET;
        addr.sin_addr.s_addr = inet_addr(ip.c_str());
        addr.sin_port = htons(port);
        return bind(m_fd, (sockaddr*)&addr, sizeof(addr)) == -1 ? false : true;
    }
    // 接收数据
    bool RecvFrom(std::string* msg, std::string* ip=nullptr, std::uint16_t* port=nullptr) {
        char buf[1024] = { 0 };
        sockaddr_in peer;
        socklen_t peer_len = sizeof(peer);
        ssize_t n = recvfrom(m_fd, buf, sizeof(buf) - 1, 0, (sockaddr*)&peer, &peer_len);
        if (n < 0) {
            return false;
        }
        *msg = buf;
        if (ip != nullptr) {
            *ip = inet_ntoa(peer.sin_addr);
        }
        if (port != nullptr) {
            *port = ntohs(peer.sin_port);
        }
        return true;
    }
    // 发送数据
    bool SendTo(const std::string& msg, const std::string& ip, const std::uint16_t& port) {
        sockaddr_in addr;
        addr.sin_family = AF_INET;
        addr.sin_addr.s_addr = inet_addr(ip.c_str());
        addr.sin_port = htons(port);
        ssize_t n = sendto(m_fd, msg.c_str(), msg.size(), 0, (sockaddr*)&addr, sizeof(addr));
        return n == -1 ? false : true;
    }

private:
	int m_fd;
};

#endif // __UDP_SOCKET__

测试

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

// 回显客户端
#include <iostream>

#include "udp_socket.hpp"

int main() {
    UdpSocket socket;
    bool ret = socket.Create();
    if (!ret) {
        perror("Socket::Create()");
        return -1;
    }
    
    while (true) {
        std::string input;
        std::cout << "input> ";
        std::cin >> input;

        ret = socket.SendTo(input, "127.0.0.1", 8080);
        if (!ret) {
            perror("Socket::SendTo()");
            continue;
        }
        
        std::string resp;
        ret = socket.RecvFrom(&resp);
        if (!ret) {
            perror("Socket::RecvFrom()");
            continue;
        }
    }

    socket.Close();
    return 0;
}

测试结果：OK

EOF