ttz.pw

Windows端口未被占用，但是无法使用的问题解决方式

Wed, 11 Feb 2026 09:16:40 +0800

1. 问题描述

最近发现Windows系统中存在一种特殊问题：明明端口未被任何应用程序占用，但却无法使用该端口。例如：Docker Desktop容器已经正常启动，但外部无法访问；通过Docker Desktop界面查看端口占用情况，发现容器端口未正常对外暴露；之前一直正常运行的程序，今天启动时突然报错"端口已被占用"。

2. 问题分析

通常遇到端口占用问题，我们会选择结束占用该端口的应用程序。但在特殊情况下，当你确认没有应用程序占用该端口时，仍然会收到"端口已被占用"的错误提示。这种情况往往是系统级别的端口占用所致。

2.1 常规端口占用排查

步骤1：查看端口占用情况

使用以下命令查看特定端口的占用情况（以8080端口为例），若查询不到结果，尝试以管理员权限重新运行：

1netstat -ano | findstr 8080

步骤2：结束占用端口的进程

如果查询到占用端口的进程，可以通过以下命令强制结束该进程：

1taskkill /F /PID 1234

其中，1234 是占用端口的进程ID。

步骤3：重置网络设置

如果查询不到占用端口的进程，可以尝试重启计算机，或者使用以下命令重置网络设置：

1netsh int ip reset

2.2 特殊情况：Windows系统保留端口

如果以上常规方法都无法解决问题，可能是遇到了Windows系统保留端口的问题。Windows会自动保留一些端口范围用于系统服务，这些端口即使没有被任何应用程序占用，也无法被用户应用使用。

检查Windows保留端口范围

使用以下命令查看Windows系统保留的端口范围：

 1# 以管理员身份运行PowerShell
 2netsh int ipv4 show excludedportrange protocol=tcp
 3
 4协议 tcp 端口排除范围
 5
 6开始端口    结束端口
 7----------    --------
 8      4309        4408
 9      5985        5985
10      7630        7729
11      7730        7829
12      7830        7929
13      7930        8029
14      8030        8129
15      8130        8229
16      8230        8329
17      9081        9180
18     10089       10188
19     47001       47001
20     50000       50059     *
21
22* - 管理的端口排除。
23# 查看动态端口范围
24netsh int ipv4 show dynamicport tcp
25
26协议 tcp 动态端口范围
27---------------------------------
28启动端口        : 49152
29端口数          : 16384

通过以上命令可以查看：

Windows系统自动保留的TCP端口排除范围（即无法被用户应用使用的端口）
Windows动态端口范围（系统用于临时分配的端口）

如果你的应用程序使用的端口正好在系统保留的端口范围内，即使没有任何应用程序占用该端口，也会收到"端口已被占用"的错误。

实际案例：我启动的应用程序使用端口8000，但一直报错"端口已被占用"。通过查看系统保留端口范围，发现8000端口正好位于7930-8029的保留范围内，因此无法使用。

3. 解决方法

3.1 临时解决方案（无需重启）

如果急需启动服务，可以采用以下临时方法释放端口（无需重启电脑）：

1net stop winnat
2# 立即启动你的应用服务（如Spring Boot、Redis、Docker容器等）
3net start winnat

说明：此方法通过临时停止并重启Windows网络地址转换服务（WinNAT）来释放系统保留的端口。停止WinNAT服务后，请立即启动你的应用程序，以抢占该端口。

3.2 根本解决方案（推荐）

调整Windows动态端口范围，避免与常用开发端口冲突。将动态端口的起始点从默认值调整为标准的49152（IANA标准动态端口范围）：

1# 必须以管理员身份运行PowerShell或命令提示符
2netsh int ipv4 set dynamicport tcp start=49152 num=16384
3netsh int ipv4 set dynamicport udp start=49152 num=16384

说明：

执行上述命令后，需要重启电脑使设置生效
重启后，系统将仅在49152–65535范围内分配动态端口
这将避免系统保留端口与常用开发端口（如8080、8000、3000等）产生冲突
此方法是一劳永逸的解决方案

Redis Lua Script 溢出漏洞（CVE-2024-31449）

Fri, 28 Nov 2025 08:33:45 +0800

1. 漏洞描述

Redis是一个开源的基于内存亦可持久化的Key-Value数据库。2024年10月，官方披露 CVE-2024-31449 Redis Lua Script 溢出漏洞，经过身份验证的用户可以使用特制的Lua脚本来触发堆栈缓冲区溢出，并可能会导致远程代码执行。官方已发布更新修复，建议升级至最新版本。

目前受影响的Redis版本：

2.6 ≤ Redis < 6.2.16
7.0.0 ≤ Redis < 7.2.6
7.4.0 ≤ Redis < 7.4.1

安全版本

6.2.16
7.2.6
7.4.1

解决建议

Redis 官方已发布更新修复，建议升级至最新版本。
利用安全组设置Redis仅对可信地址开放。
应用漏洞暂只支持获取 Redis 自身版本，若确定已为各发行版本安全修复版本，可予忽略。

2. 升级前信息收集

2.1. 查看旧redis版本信息

1# /usr/local/redis/bin/redis-server --version
2Redis server v=2.8.22 sha=00000000:0 malloc=jemalloc-3.6.0 bits=64 build=4c2b76a2ddab816

2.2. 查看目前redis的key

 1# 登录redis客户端
 2# /usr/local/redis/bin/redis-cli 
 3127.0.0.1:6379> AUTH  xxx
 4OK
 5127.0.0.1:6379> dbsize
 6(integer) 19
 7127.0.0.1:6379> keys *
 8 1) "sys_dict:sys_yes_no"
 9 2) "sys_config:sys.account.captchaEnabled"
10 3) "sys_dict:sys_job_group"
11 4) "sys_config:sys.index.skinName"
12 5) "sys_dict:sys_show_hide"
13 6) "sys_dict:sys_common_status"
14 7) "sys_dict:sys_job_status"
15 8) "sys_dict:cl_url_status"
16 9) "sys_dict:cl_school_type"
1710) "sys_config:sys.user.initPassword"
1811) "sys_config:sys.index.sideTheme"
1912) "sys_dict:cl_school_status"
2013) "sys_dict:sys_notice_type"
2114) "sys_dict:sys_normal_disable"
2215) "sys_config:sys.login.blackIPList"
2316) "sys_dict:sys_oper_type"
2417) "sys_dict:sys_user_sex"
2518) "sys_dict:sys_notice_status"
2619) "sys_config:sys.account.registerUser"

2.3. 备份数据

1# 备份命令
2127.0.0.1:6379> SAVE
3OK
4
5或
6BGSAVE

2.4. 查看备份文件地址

1# 通过命令找到备份的数据文件
2127.0.0.1:6379> config get dir
31) "dir"
42) "/data"
5127.0.0.1:6379> config get dbfilename
61) "dbfilename"
72) "dump.rdb"

2.5. 将旧Redis安装目录备份

1备份旧目录
2cp /usr/local/redis /usr/local/redisbak -r

3. 安装新版本Redis

3.1. 下载redis安装包

下载地址

这里本人下载的 6.2.21 版本

3.2. 安装redis

1# 下载
2wget https://download.redis.io/releases/redis-6.2.21.tar.gz
3# 解压
4tar -zxf redis-6.2.16.tar.gz
5# 切换到解压后的目录
6cd redis-6.2.21
7# 编译安装
8make PREFIX=/usr/local/redis install

配置文件修改为和旧版本一致，主要是数据存放目录和日志目录等

 1配置文件
 2bind * -::*
 3protected-mode no
 4port 6379
 5tcp-backlog 511
 6timeout 0
 7tcp-keepalive 300
 8daemonize no
 9pidfile /var/run/redis_6379.pid
10loglevel notice
11logfile /logs/redis.log
12databases 16
13always-show-logo yes
14set-proc-title yes
15proc-title-template "{title} {listen-addr} {server-mode}"
16locale-collate ""
17save 3600 1 300 100 60 10000
18stop-writes-on-bgsave-error yes
19rdbcompression yes
20rdbchecksum yes
21dbfilename dump.rdb
22rdb-del-sync-files no
23dir /data
24replica-serve-stale-data yes
25replica-read-only yes
26repl-diskless-sync yes
27repl-diskless-sync-delay 5
28repl-diskless-sync-max-replicas 0
29repl-diskless-load disabled
30repl-disable-tcp-nodelay no
31replica-priority 100
32acllog-max-len 128
33aclfile /etc/redis/users.acl
34lazyfree-lazy-eviction no
35lazyfree-lazy-expire no
36lazyfree-lazy-server-del no
37replica-lazy-flush no
38lazyfree-lazy-user-del no
39lazyfree-lazy-user-flush no
40oom-score-adj no
41oom-score-adj-values 0 200 800
42disable-thp yes
43appendonly yes
44appendfilename "appendonly.aof"
45appenddirname appendonly
46appendfsync everysec
47no-appendfsync-on-rewrite no
48auto-aof-rewrite-percentage 100
49auto-aof-rewrite-min-size 64mb
50aof-load-truncated yes
51aof-use-rdb-preamble yes
52aof-timestamp-enabled no
53slowlog-log-slower-than 10000
54slowlog-max-len 128
55latency-monitor-threshold 0
56notify-keyspace-events ""
57hash-max-listpack-entries 512
58hash-max-listpack-value 64
59list-max-listpack-size -2
60list-compress-depth 0
61set-max-intset-entries 512
62set-max-listpack-entries 128
63set-max-listpack-value 64
64zset-max-listpack-entries 128
65zset-max-listpack-value 64
66hll-sparse-max-bytes 3000
67stream-node-max-bytes 4096
68stream-node-max-entries 100
69activerehashing yes
70client-output-buffer-limit normal 0 0 0
71client-output-buffer-limit replica 256mb 64mb 60
72client-output-buffer-limit pubsub 32mb 8mb 60
73hz 10
74dynamic-hz yes
75aof-rewrite-incremental-fsync yes
76rdb-save-incremental-fsync yes
77jemalloc-bg-thread yes

3.3. 启动新的redis

1redis-server /usr/local/redis/etc/redis.conf

3.4. 验证

3.4.1. 查看新安装的redis版本

1redis-server --version
2Redis server v=6.2.21 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=12b91a981b4a57b016 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=12b91a981b4a57b0

3.4.2. 查看数据是否恢复

 1# 登录redis客户端
 2# /usr/local/redis/bin/redis-cli 
 3127.0.0.1:6379> AUTH  xxx
 4OK
 5127.0.0.1:6379> dbsize
 6(integer) 19
 7127.0.0.1:6379> keys *
 8 1) "sys_dict:sys_yes_no"
 9 2) "sys_config:sys.account.captchaEnabled"
10 3) "sys_dict:sys_job_group"
11 4) "sys_config:sys.index.skinName"
12 5) "sys_dict:sys_show_hide"
13 6) "sys_dict:sys_common_status"
14 7) "sys_dict:sys_job_status"
15 8) "sys_dict:cl_url_status"
16 9) "sys_dict:cl_school_type"
1710) "sys_config:sys.user.initPassword"
1811) "sys_config:sys.index.sideTheme"
1912) "sys_dict:cl_school_status"
2013) "sys_dict:sys_notice_type"

从数据可知数据和旧数据一致，说明数据恢复了

Springboot Actuator未授权访问漏洞复现

Wed, 17 Sep 2025 11:24:48 +0800

说明

Actuator 是 SpringBoot 提供的用来对应用系统进行自省和监控的功能模块，借助于 Actuator 开发者可以很方便地对应用系统某些监控指标进行查看、统计等。

1. 漏洞介绍

Spring Boot Actuator 模块提供了生产级别的功能，比如健康检查，审计，指标收集，HTTP 跟踪等，帮助监控和管理Spring Boot 应用。这个模块是一个采集应用内部信息暴露给外部的模块，上述的功能都可以通过HTTP 和 JMX 访问。

Actuator是Spring Boot提供的应用系统监控的开源框架。在攻防场景里经常会遇到Actuator配置不当的情况，攻击者可以直接下载heapdump堆转储文件，然后通过一些工具来分析heapdump文件，从而可进一步获取敏感信息。

2. 漏洞环境搭建

搭建环境：windows10 + java1.8 可以直接按照命令进行操作，但是在环境搭建中，可能会遇到一定的问题：

1git clone https://github.com/callicoder/spring-boot-actuator-demo.git
2cd spring-boot-actuator-demo-master
3mvn package
4java -jar target/actuator-demo-0.0.1-SNAPSHOT.jar

mvn的安装，可以百度下，比较容易。执行mvn package

然后启动环境：

1java -jar target/actuator-demo-0.0.1-SNAPSHOT.jar

访问当前的ip信息：http://127.0.0.1:8080/

时环境搭建完成。

3. 漏洞利用

3.1. 漏洞发现

一般来说，这种可以通过扫描工具发现漏洞，在这里可以用fscan来试试：

1./fscan_darwin -h 127.0.0.1

在这里可以发现漏洞：

1[3.7s] [+] 目标: http://127.0.0.1:8080
2  漏洞类型: poc-yaml-springboot-env-unauth
3  漏洞名称: spring2
4  详细信息:
5        参考链接:https://github.com/LandGrey/SpringBootVulExploit

3.2. 利用方法

1.x版本

 1/configprops # 显示所有@ConfigurationProperties
 2/env # 公开 Spring 的ConfigurableEnvironment
 3/health # 显示应用程序运行状况信息
 4/httptrace # 显示 HTTP 跟踪信息
 5/metrics # 显示当前应用程序的监控指标信息。
 6/mappings # 显示所有@RequestMapping路径的整理列表
 7/threaddump # 线程转储
 8
 9/heapdump # 堆转储
10/jolokia # JMX-HTTP桥,它提供了一种访问JMX beans的替代方法

2.x版本

1/actuator/configprops # 显示所有@ConfigurationProperties
2/actuator/env # 公开 Spring 的ConfigurableEnvironment
3/actuator/health # 显示应用程序运行状况信息
4/actuator/httptrace # 显示 HTTP 跟踪信息
5/actuator/metrics # 显示当前应用程序的监控指标信息。
6/actuator/mappings # 显示所有@RequestMapping路径的整理列表
7/actuator/threaddump # 线程转储
8/actuator/heapdump # 堆转储
9/actuator/jolokia # JMX-HTTP桥,它提供了一种访问JMX beans的替代方法

3.3. springboot-env-unauth

公开 Spring 的ConfigurableEnvironment

1http://127.0.0.1:8080/actuator/env

1http://127.0.0.1:8080/actuator/configprops

3.4. spring-actuator-heapdump

其实在实战中，最重要的就是heapdump文件，在这里文件里面理论上可以发现很多敏感的数据库之类的信息。

1http://127.0.0.1:8080/actuator/heapdump

该文件可以直接下载到本地来，使用专业工具进行解密；

专业工具地址：

1https://github.com/wyzxxz/heapdump_tool

使用方法：java -jar heapdump_tool.jar heapdump

当然，在这个环境中，暂时没有发现什么敏感信息，但是在实战里面，有概率是可以发现敏感数据的：

4. 解决方案都有哪些

4.1. 关闭端口(大多数是不会采取这种方案)

在配置文件中添加配置

1management:
2  endpoints:
3    enabled-by-default: false
4# 版本低的配置
5# management:
6#   endpoints: 
7#     enabled: false

虽然 management.endpoints.web.exposure.enabled=false 已经足够安全，但如果您想彻底地、一劳永逸地禁用所有与 Actuator 相关的 Web 功能（包括那个空的 /actuator 发现页面），可以采用以下更严格的方案：

1# 彻底禁用 Actuator 的 Web 功能
2management.endpoints.web.exposure.enabled=false
3# 同时，确保没有端点被包含在内（双重保险）
4management.endpoints.web.exposure.exclude=*
5# 并且，禁用发现页面的响应，这样 /actuator 也会返回 404
6management.endpoints.web.discovery.enabled=false

大多数是不会采取这种方案，但也不排除生产上感觉actuator没什么实质作用的同学，可以选择关闭暴露端点但毕竟使用actuator是主观意向，主要是为了配合 SpringAdmin 或 Prometheus 来监控的，很多人都会需求其他的解决方案

4.2. 网关限制（最简单粗暴）

如果使用nginx作为网关控制，直接屏蔽掉相关接口即可

4.2.1. nginx 配置文件

1
2location ~ .*actuator.* {
3   deny all;
4}

4.2.2. k8s-ingress 配置文件

屏蔽actuator路径

1metadata:
2annotations:
3nginx.ingress.kubernetes.io/configuration-snippet: |
4      location ~ .*actuator.* {
5        deny all;
6      }

4.3. Actuator 开启认证授权（存在代码污染风险）

主要是借助 spring security 来实现的，如果当前项目有使用security，需要自己解决一下合并问题

4.3.1. 引入Maven包坐标

1<dependency>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-starter-security</artifactId>
4</dependency>

4.3.2. 增加Java 权限控制代码

 1import org.springframework.context.annotation.Bean;
 2import org.springframework.context.annotation.Configuration;
 3import org.springframework.security.config.annotation.web.builders.HttpSecurity;
 4import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
 5import org.springframework.security.web.firewall.HttpFirewall;
 6import org.springframework.security.web.firewall.StrictHttpFirewall;
 7/**
 8 * Actuator 监控端点权限
 9 *
10 * @author Parker
11 */
12@Configuration
13public class ActuatorSecurityConfig extends WebSecurityConfigurerAdapter {
14@Override
15protected void configure(HttpSecurity http) throws Exception {
16        http.httpBasic().and()
17                .authorizeRequests()
18                    .antMatchers("/actuator/**")
19                        .authenticated()
20                    .anyRequest()
21                        .permitAll();
22        http
23// 关闭csrf token认证不需要csrf防护
24            .csrf().disable()
25// 关闭Session会话管理器 JWT 不需要
26            .sessionManagement().disable()
27// 关闭记住我功能 JWT 不需要
28            .rememberMe().disable();
29    }
30/**
31     * 配置地址栏不能识别 // 的情况
32     * @return
33     */
34@Bean
35public HttpFirewall allowUrlEncodedSlashHttpFirewall() {
36        StrictHttpFirewall firewall = new StrictHttpFirewall();
37//此处可添加别的规则,目前只设置 允许双 //
38        firewall.setAllowUrlEncodedDoubleSlash(true);
39return firewall;
40    }
41}

4.3.3. Spirngboot 工程增加配置

 1# 开启SpringBoot Admin的监控
 2management:
 3endpoints:
 4web:
 5exposure:
 6include: '*'
 7endpoint:
 8health:
 9show-details: always
10spring:
11# 自身权限校验账号密码
12security:
13user:
14name:
15password:
16# 上报账号密码    
17boot:
18admin:
19client:
20url: Admin URL
21username:
22password:
23instance:
24metadata:
25user.name: ${spring.security.user.name}
26user.password: ${spring.security.user.password}

5. 总结

关于其他的工具来获取明文信息的，可以参考以下链接： https://mp.weixin.qq.com/s/JKq4WxFKwh7IDIAqTKcTHw

软件测试测试设计

Tue, 04 Mar 2025 16:20:49 +0800

1. 测试设计的定义

1.1. 定义

测试设计包括测试分析和测试用例，是前期测试需求分析的功能点和测试点通过功能测试设计方法（黑盒测试设计方法）产出测试用例的过程。具体来说，测试分析是确定目标的过程（中间过程）；测试设计是得出具体的测试实例（用例）以达到完成这个测试目标的过程。

2. 测试用例设计方法

2.1. 黑盒测试

黑盒测试(功能测试)：这种方法把被测软件看成黑盒，在不考虑软件内部结构和特性的情况下测试软件的外部特性。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。

2.1.1. 等价类划分法

定义：把所有可能输入的数据分为若干个区域，然后从每个区域中取少量具有代表性的数据进行测试即可。

2.1.1.1. 等价类划分原则

划分为有效等价类和无效等价类
根据取值范围或值的个数、值的集合
根据需要遵守的规则一条用例尽可能多的满足有效等价类
一条用例覆盖一条无效等价类

2.1.1.2. 等价类划分步骤

a. 分析需求，确定输入数据类型

b. 使用规则划分有效和无效等价类

c. 设计用例覆盖有效等价类

d. 设计用例覆盖无效等价类

2.1.1.3. 等价类划分举例

需求：

QQ账号6-10位自然数，第一位不能为0。

等价类划分：

测试用例设计：

2.1.2. 边界值分析法

定义：边界是指对于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。通常边界值分析法是作为对等价类划分法的补充，长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

2.1.2.1. 边界值分析原则

上点：是指边界上的点，无论此时的域是开区间还是闭区间，开区间的话，上点就是在域外，闭区间的话，上点就是在域内。
离点：是指离上点最近的点，这里就跟是闭区间还是开区间就有关系了，如果是开区间，那么离点就在域内，如果是闭区间，那么离点就在域外。(开内闭外) 遵循的原则：开内闭外，开区间往中间找，闭区间往外找。
内点：域内的任意点都是内点。

2.1.2.2. 边界值分析步骤

a. 分析需求，确定输入数据类型

b. 使用规则划分有效/无效等价类

c. 确认上点、离点、内点

d. 设计测试用例覆盖有效等价类

e. 设计测试用例覆盖无效等价类

2.1.2.3. 边界值案例

需求：

一个文本框的输入长度为 6-10 个字符。

等价类划分、边界值确认：

测试用例设计：

2.1.3. 判定表法

定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具，适用于多条件的内容组合与结果分析。

2.1.3.1. 判定表法原则

判定表的组成：(使用条件：所有的条件桩在表中的位置和顺序互不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同)

条件桩：列出了问题的所有条件
动作桩：列出了问题规定可能采取的操作
条件项：列出条件项中的各种情况下的真假值
动作项：列出在条件项中的各种取值情况下应该采取的动作

2.1.3.2. 判定表法步骤

a. 分析需求，确定原因和动作，列出所有的条件桩和动作桩

b. 分析条件的组合数量，即条件项（全组合：若有n个条件，每个条件有m种情况，则最后一共有m^n个条件项）

c. 填写动作项，合并、简化相似规则或者相同动作，排除一些不可能的情况

d. 简化判定表，输出测试用例

2.1.3.3. 判定表案例

需求：

如果金额大于500元，又未过期，则发出批准单和提货单。
如果金额大于500元，但过期了，则不发批准单和提货单。
如果金额小于等于500元，则不论是否过期都发出批准单和提货单。
在过期的情况下不论金额大小还需发出通知单。

列出判定表：

简化判定表，输出用例（一个规则对应一条测试用例）：

2.1.4. 场景法

定义：场景法是通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法，适用于解决业务流程清晰的系统或者功能。

2.1.4.1. 场景法原则

基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流只有一个起点和一个终点。
备选流：除了基本功能流程之外的各支流，包含多种不同情况。

场景1:基本流;

场景2:基本流,备选流1;

场景3:基本流,备选流1,备选流2;

场景4:基本流,备选流1,备选流4;

场景5:基本流,备选流3;

场景6:基本流,备选流3,备选流1;

场景7:基本流,备选流3,备选流1,备选流2;

场景8:基本流,备选流4;

场景9:基本流,备选流3,备选流4。

2.1.4.2. 场景法步骤

a. 分析需求，描述出程序的基本流及各项备选流。

b. 根据基本流和各项备选流生成不同的场景。

c. 对每一个场景生成相应的测试用例。

2.1.4.3. 场景法案例

需求：

取款机银行卡取款

分析基本流（正常流程）：

①插入银行卡：客户将银行卡插入ATM机的读卡器；

②验证银行卡：ATM机从银行卡的磁条中读取账户代码，并检查它是否属于可以接受的银行卡；

③输入密码：ATM机要求客户输入密码；

④验证密码：确定该密码是否正确；

⑤进入ATM主界面：ATM显示在本机中可用的各种选项；

⑥取款并选择金额：客户选择“取款”，并选择取款金额；

⑦ATM机验证：ATM机进行验证账户余额是否满足以及总取款金额是否满足要求，验证ATM机内现金是否够用；

⑧更新账户余额、出钞：验证成功，更新账户余额，输出现金，提示用户收取现金；

⑨返回主界面。

分析备选流：

①银行卡无效：提示错误并退卡；

②密码错误：提示错误，并判断是否3次错误；

③密码3次错误：提示错误，吞卡；

④账户余额不足：提示错误并退卡；

⑤总取款金额超出当日可取限额：提示错误并退卡；

⑥ATM机余额不足：提示错误并退卡。列出所有场景：

列出所有场景：

为每一个场景设计测试用例：

2.1.5. 功能图法

定义

功能图方法是用功能图形象的描述程序的功能说明，并机械的生成功能图的测试用例；功能图由状态迁移图和逻辑功能模型构成。这种方法是一种黑盒白盒测试方法相结合的设计方法，具体来说就是在从功能图导出测试用例时需要用到白盒测试方法中的路径覆盖和逻辑覆盖的测试用例设计方法。

2.1.5.1、功能图法原则

状态迁移图和逻辑功能模型的相关描述如下：

状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。

逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型仅用于描述静态说明，输出数据仅由输入数据决定。测试用例则是由测试中经过一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。

2.1.5.2、功能图法步骤

a. 明确状态节点。分析被测对象的测试特性及需求规格说明书，明确被测对象的状态节点数量及相互迁移关系。

b. 绘制状态迁移图。利用圆圈表示状态节点，有向箭头表示状态间的迁移关系，根据需要在箭头旁边标识迁移条件。可以利用绘图软件绘制状态迁移图。

c.绘制状态迁移树。根据状态迁移图，按照广度优先和深度优先搜索绘制状态迁移树。首先确定起始节点和终止节点，在绘制时，当路径上遇到终止节点时，不再扩展，遇到已经出现的节点也停止扩展。

抽取测试路径设计用例。根据绘制好的状态迁移树，提取测试路径，从左到右，横向抽取，每条路径构成一条测试规则，然后再利用等价类和边界值等测试用例设计方法设计具体的测试用例。

2.1.5.3、功能图法案例

需求：一个编辑文本的软件中有可以改变字体颜色的功能，其中可选的颜色共有黑、红、蓝三种颜色。

分析需求：功能共有三种状态，假设红色为起始状态，那么可以得到如下的状态迁移图：根据上述的状态迁移图，绘制出如下的状态迁移树：

从状态迁移树中，导出以下规则：

根据规则输出测试用例：

2.1.6、正交实验法

定义：正交实验法是一种测试组合的方法。把影响实验指标的条件称为因子，而影响实验因子的条件叫因子的状态。利用正交实验设计方法来设计测试用例时，首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素，把他们当作因子；而把各个因子的取值当作状态。

2.1.6.1、正交实验法原则

正交表的构成：

行数：正交表中的行的个数，即试验的次数，也是我们通过正交实验法设计的测试用例的个数。
因素数：正交表中列的个数，即我们要测试的功能点。
水平数：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到“水平数-1”或从1到“水平数” 。即要测试功能点的输入条件。
正交表的形式：L行数(水平数因素数) 如：L8(27)如下图
与判定表法的区别是：判定表法是人工对全排列进行组合，正交试验法是借助数学工具从全排列组合中选出组合组成正交表，测试的时候查看正交表编写测试用例。下图是四因子三状态的正交表：

可以使用正交试验法的情形：单个功能测试：输入是因子，输出是状态功能组合测试：功能是因子，是否包含功能是状态配置测试：配置项是因子，每个配置项的值是状态

2.1.6.2、正交实验法步骤

分析需求，获取因子和水平；根据因子和水平查正交表；替换正交表中的因子与水平；根据正交表获取测试用例。

2.1.6.3、正交实验法案例

需求：

某银行交易系统的卡号查询功能界面如图所示：

分析需求，获取因子和水平：

因子（功能点）：卡号、卡号所属地区、卡状态、用户姓名、开户年月

水平（条件）：输入、不输入

综上为5因子2水平（一般通过工具生成正交表）查正交表（取7因子2水平，要取最接近且结果大于所需数量）：

替换因子与水平：

根据正交表的每一行编写测试用例：略

（以上正交实验法的部分知识来源于CSDN博主rm group，若侵权可联系我及时删除。）

2.1.7、因果图法

定义：因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。适用于输入条件比较多，输入存在复杂（相互制约或者相互依赖）关系的情况。测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

2.1.7.1、因果图法原则

因果图基本符号（a）恒等若原因出现，则结果出现；若原因不出现，则结果也不出现；（b）非 ~ 若原因出现，则结果不出现；若原因不出现，则结果出现；若结果存在，则不提示错误，若结果不存在，则提示错误。（c）或 ∨ 若几个原因中出现一个，则结果出现；若几个原因都不出现，则结果不出现；（d）与 ∧ 若几个原因都出现，则结果出现；若其中的一个原因不出现，则结果不出现；

因果图约束条件

（1）互斥：最多有一个可能成立（2）包含：至少有一个成立（3）屏蔽：a成立时，b不成立；a不成立时，b的值不一定（4）唯一：三个或多个原因中有且只有一个成立（5）要求：一个出现，另一个一定出现

2.1.7.2、因果图法步骤

分析软件规格说明的描述中哪些是原因，哪些是结果。原因是输入或输入条件的等价类，结果是输出条件。给每个原因和结果赋予一个标识符，根据这些关系，画出因果图。因果图上用一些记号表明约束条件或限制条件。对需求加以分析并把它们表示为因果图之间的关系图。把因果图转换成判定表。将判定表的每一列作为依据，设计测试用例。

2.1.7.3、因果图法案例

需求：某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。

分析需求，明确输入和输出：原因： 1——第一列字符是A； 2——第一列字符是B； 3——第二列字符是一数字。结果： 21——修改文件； 22 ——给出信息L； 23——给出信息M。根据原因结果画出因果图：

（说明：11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。）根据因果图建立判定表：

（说明：表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。）

输出测试用例：略（和前面判定表一样)

2.1.8、错误推测法

定义：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。还有输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行，这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

2.2、

白盒测试

白盒测试(结构测试)：这种方法把被测软件看成白盒，根据程序的内部结构和逻辑设计来设计测试实例，对程序的路径和过程进行测试。

2.2.1、桌面检查

桌面检查是一种人工检查程序的方法，通过对源程序代码的分析、检验来发现程序中的错误。桌面检查关注的是变量的值和程序逻辑，所以执行桌面检查要求严格按照程序中的逻辑顺序。桌面检查可以由程序作者本人执行，但是效率很低。最好是两个程序员互相检查。桌面检查不如审查或者走查有效。但是比什么都不做好。

2.2.2、代码审查

正式的代码评审过程。由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。

2.2.3、代码走查

非正式的代码评审过程。代码走查就是，项目开发人员在一起，对代码进行讨论。项目开发人员可以向大家阐述代码的逻辑和写代码的思路，在向别人阐述的时候，会发现做自己写的代码出现的一些问题。

2.2.4、代码扫描工具

代码质量的重要性不言而喻，代码质量水平决定了软件的可靠性、可维护性、执行效率、安全性等软件质量水平。而大规模的软件系统的代码庞大而复杂，必须借助自动化手段辅助完成代码审查。 Sonar（SonarQube）是一个开源平台，用于管理源代码的质量。Sonar 不只是一个质量数据报告工具，更是代码质量管理平台。支持的语言包括：Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。Sonar是一个Web系统，展现了静态代码扫描的结果，结果是可以自定义的，支持多种语言的原理是它的扩展性。 Sonar作用：对源代码执行静态分析；可以静态分析编译代码，比如Java的Class文件、C#的dll文件等；对应特定语言，Sonar能够执行动态分析，比如Java、C#的单元测试。

2.2.5、语句覆盖

定义：

设计测试用例，使得程序中每条语句至少被执行一次语句覆盖率 = 至少被执行一次的语句数量 /可执行的语句总数尽可能使得语句覆盖率达成100% 局限性：不能准确判断运算中的逻辑关系错误

2.2.5.1、语句覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

2.2.6、判定覆盖

定义：

也叫分支覆盖，设计测试用例，使得程序中的每个判断的“真”和“假”都至少被执行一次；即程序中的每个分支至少执行一次判定覆盖率 = 每个判定的真假值至少出现一次 / 判定结果的总数满足判定覆盖一定满足语句覆盖局限性：判定覆盖会忽略条件中取或的情况

2.2.6.1、判定覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

if(x>0 && y>0)判定：记为P1
if(m<0)判定：记为P2

2.2.7、条件覆盖

定义：

设计测试用例，使得判定中的每个条件至少有一次取真值，有一次取假值条件覆盖率 = 每个条件真假值至少出现一次/条件结果的总数局限性：条件覆盖不能保证判定覆盖

2.2.7.1、判定覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

if(x>0 && y>0)判定：记为P1
if(m<0)判定：记为P2
x>0：记为C1
y>0：记为C2
m<0：记为C3 需要满足C1、C2、C3均取真、取假

2.2.8、判定条件覆盖

定义：

设计测试用例，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值（真假）也至少被满足一次，即同时满足100%判定覆盖和100%的条件覆盖的标准

判定条件覆盖率 = 每个判定真假值和条件真假值至少出现一次 / (判定结果的总数+条件结果的总数) 满足判定条件覆盖一定满足判定覆盖、条件覆盖、语句覆盖局限性：判定覆盖会忽略条件中取或的情况

2.2.8.1、判定条件覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

if(x>0 && y>0)判定：记为P1
if(m<0)判定：记为P2
x>0：记为C1
y>0：记为C2
m<0：记为C3 需要满足C1、C2、C3均取真、取假

2.2.9、条件组合覆盖

定义:

设计测试用例，使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次条件组合覆盖率=条件组合至少出现一次的数量/条件组合的总数条件组合覆盖满足判定覆盖、条件覆盖、判定-条件覆盖、语句覆盖局限性：不能保证所有路径被执行

例：假设代码中有判定2个，条件3个（判定1有2个条件，判定2有1个条件），则判定1 的条件组合为4个，判定2的条件组合为2个，设计测试用例执行5个条件组合，则条件覆盖率=5/(4+2) = 83%

2.2.9.1、条件组合覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

if(x>0 && y>0)判定：记为P1
if(m<0)判定：记为P2
x>0：记为C1
y>0：记为C2
m<0：记为C3 需要满足C1、C2、C3均取真、取假

2.2.10、路径覆盖

定义：

设计测试用例，覆盖程序中所有可能的路径路径覆盖率 = 至少被执行过一次的路径数/总的路径数局限性：不适合包含路径过多的程序

2.2.10.1、路径覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

if(x>0 && y>0)判定：记为P1
if(m<0)判定：记为P2
x>0：记为C1
y>0：记为C2
m<0：记为C3 需要满足C1、C2、C3均取真、取假

2.2.11、基本路径测试法

定义：基本路径测试法又称独立路径测试，是在程序控制流图的基础上，通过分析控制结构的环路复杂性，导出基本可执行路径集合，从而设计出相应的测试用例的方法。设计出的测试用例要保证在测试中程序的语句覆盖100%，条件覆盖100%。

PART 03 什么是测试用例

3.1、定义

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。（来自百度百科）

测试用例主要包含（不限于）四个内容：用例标题，前置条件，测试步骤和预期结果。用例标题主要描述测试某项功能；前置条件是指用例标题需要满足该条件；测试步骤主要描述用例的操作步骤；预期结果指的是符合预期（开发规格书、需求文档、用户需求等）需求。

3.2、测试用例的作用

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路。

3.3、测试用例八要素

用例编号
测试项目
测试标题
重要级别
预置条件
测试输入
操作步骤
预期结果

3.4、测试用例需具备的特性

易读、可执行性：测试用例可被其他测试人员易于理解和执行
有效性：测试用例能够被使用，且被不同人员使用测试结果一致
可重复性：良好的测试用例具有重复使用的功能。(回归测试)
易组织性：好的测试用例会分门别类地提供给测试人员参考和使用(功能、性能、易用分类编号)
清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的的针对性，不应出现一些无用的操作步骤。
可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用例符合相应测试要求。

3.5、如何写出漂亮的测试用例

测试用例名称要是一个完整的句子，例：在怎样的条件下，谁做了怎样的事情，得到什么结果。
划分好用例的优先级
明确测试步骤和预期结果的对应关系
测试步骤不宜过多，不要多余7步，不要少于2步
不要在测试用例中引用测试用例
避免在测试步骤中使用笼统的词，简洁易懂

……

PART 04 测试分析与测试用例的区别

测试分析：主要是对测试点进行细化，明确测试设计方法，通过思维导图的方式列出每一个测试点的所有测试项和优先级，并写明使用的测试方法，测试分析不包含测试步骤和测试数据。测试分析是测试设计的中间产物，一般不作为产出物（无需拿到项目组进行评审）。

测试用例：是对测试分析具体的实现，需要将测试分析的所有测试项转换为用例，通过表格文档进行呈现，需要详细写明测试步骤和测试数据。测试用例是测试设计的最终产物，需要将产出的测试用例拿到测试内部（内部评审）和项目组（外部评审）进行评审，评审后需要根据评审结果建议进行修改，并最终达成一致。

PART 05 测试数据的准备

1、测试过程中通常会设计到两类数据：

基础数据：在对某个业务进行测试之前，数据库已存在的数据，一般提测包会包含（例如下拉框等默认数据，字典表）
业务数据：在测试过程中使用的数据，是测试需要提前准备的数据（例如某可视化大屏展示的数据，提前了解数据流构造数据）

2、数据准备遵守的原则：

全面性：包含所有类型数据
无约束性：不能存在相互依赖的现象
正确性：保证业务被执行
数据量充足：性能测试
无敏感数据：安全测试

……

运维人员常用脚本

Tue, 04 Mar 2025 15:23:39 +0800

1. 日志分析工具

1.1. 提取日志中错误信息

 1def extract_errors(log_file, output_file):
 2    with open(log_file, 'r') as f:
 3        lines = f.readlines()
 4    
 5    errors = [line for line in lines if "ERROR" in line]
 6    
 7    with open(output_file, 'w') as f:
 8        f.writelines(errors)
 9
10# 使用示例
11extract_errors("app.log", "errors.log")

1.2. 统计日志中关键词出现次数

 1from collections import defaultdict
 2
 3def count_keywords(log_file, keywords):
 4    keyword_count = defaultdict(int)
 5    
 6    with open(log_file, 'r') as f:
 7        for line in f:
 8            for keyword in keywords:
 9                if keyword in line:
10                    keyword_count[keyword] += 1
11    
12    return keyword_count
13
14# 使用示例
15keywords = ["ERROR", "WARNING", "INFO"]
16result = count_keywords("app.log", keywords)
17print(result)

1.3. 按时间范围过滤日志

 1from datetime import datetime
 2
 3def filter_logs_by_time(log_file, start_time, end_time, output_file):
 4    start = datetime.strptime(start_time, "%Y-%m-%d %H:%M:%S")
 5    end = datetime.strptime(end_time, "%Y-%m-%d %H:%M:%S")
 6    
 7    withopen(log_file, 'r') as f:
 8        logs = f.readlines()
 9    
10    filtered_logs = []
11    forloginlogs:
12        log_time_str = log.split()[0] + " " + log.split()[1] # 假设时间戳在日志的前两部分
13        log_time = datetime.strptime(log_time_str, "%Y-%m-%d %H:%M:%S")
14        ifstart <= log_time <= end:
15            filtered_logs.append(log)
16    
17    withopen(output_file, 'w') as f:
18        f.writelines(filtered_logs)
19
20# 使用示例
21filter_logs_by_time("app.log", "2025-02-26 12:00:00", "2025-02-06 14:00:00", "filtered_logs.log")

1.4. 统计日志中高频错误

 1from collections import Counter
 2import re
 3
 4def top_n_errors(log_file, n=5):
 5    error_pattern = re.compile(r"ERROR: (.+)")
 6    errors = []
 7    
 8    with open(log_file, 'r') as f:
 9        for line in f:
10            match = error_pattern.search(line)
11            if match:
12                errors.append(match.group(1))
13    
14    return Counter(errors).most_common(n)
15
16# 使用示例
17top_errors = top_n_errors("app.log", n=3)
18print(top_errors)

1.5. 日志文件合并

1def merge_log_files(log_files, output_file):
2    with open(output_file, 'w') as outfile:
3        for log_file in log_files:
4            with open(log_file, 'r') as infile:
5                outfile.write(infile.read())
6
7# 使用示例
8merge_log_files(["log1.log", "log2.log", "log3.log"], "merged_logs.log")

1.6. 日志文件实时监控

 1import time
 2
 3def tail_log_file(log_file):
 4    with open(log_file, 'r') as f:
 5        f.seek(0, 2) # 移动到文件末尾
 6        while True:
 7            line = f.readline()
 8            if line:
 9                print(line.strip())
10            else:
11                time.sleep(0.1)
12
13# 使用示例
14tail_log_file("app.log")

2. 性能监控工具

2.1. 监控cpu和内存使用情况

 1import psutil
 2import time
 3
 4def monitor_system(interval=1):
 5    while True:
 6        cpu_usage = psutil.cpu_percent(interval=interval)
 7        memory_usage = psutil.virtual_memory().percent
 8        print(f"CPU Usage: {cpu_usage}% | Memory Usage: {memory_usage}%")
 9        time.sleep(interval)
10
11# 使用示例
12monitor_system(interval=2)

2.2. 监控GPU使用情况

 1import pynvml
 2
 3def monitor_gpu_usage():
 4    pynvml.nvmlInit()
 5    device_count = pynvml.nvmlDeviceGetCount()
 6    
 7    for i in range(device_count):
 8        handle = pynvml.nvmlDeviceGetHandleByIndex(i)
 9        util = pynvml.nvmlDeviceGetUtilizationRates(handle)
10        memory_info = pynvml.nvmlDeviceGetMemoryInfo(handle)
11        print(f"GPU {i}: Usage={util.gpu}%, Memory Used={memory_info.used / 1024 ** 2} MB")
12
13# 使用示例
14monitor_gpu_usage()

2.3. 监控网络带宽

 1import psutil
 2import time
 3
 4def monitor_network_usage(interval=1):
 5    old_value = psutil.net_io_counters().bytes_sent + psutil.net_io_counters().bytes_recv
 6    
 7    whileTrue:
 8        new_value = psutil.net_io_counters().bytes_sent + psutil.net_io_counters().bytes_recv
 9        bandwidth = (new_value - old_value) / interval # 计算带宽（字节/秒）
10        print(f"Network Bandwidth: {bandwidth} B/s")
11        
12        old_value = new_value
13        time.sleep(interval)
14
15# 使用示例
16monitor_network_usage(interval=2)

2.4. 监控磁盘IO

 1import psutil
 2import time
 3
 4def monitor_disk_io(interval=1):
 5    old_read = psutil.disk_io_counters().read_bytes
 6    old_write = psutil.disk_io_counters().write_bytes
 7    
 8    whileTrue:
 9        new_read = psutil.disk_io_counters().read_bytes
10        new_write = psutil.disk_io_counters().write_bytes
11        
12        read_speed = (new_read - old_read) / interval
13        write_speed = (new_write - old_write) / interval
14        
15        print(f"Read Speed: {read_speed / 1024} KB/s | Write Speed: {write_speed / 1024} KB/s")
16        
17        old_read = new_read
18        old_write = new_write
19        time.sleep(interval)
20
21# 使用示例
22monitor_disk_io(interval=2)

2.5. 监控进程资源占用

 1import psutil
 2
 3def monitor_process(pid):
 4    process = psutil.Process(pid)
 5    
 6    while True:
 7        cpu_usage = process.cpu_percent(interval=1)
 8        memory_usage = process.memory_info().rss / 1024 ** 2  # 转换为MB
 9        print(f"PID {pid}: CPU={cpu_usage}%, Memory={memory_usage} MB")
10
11# 使用示例
12monitor_process(1234) # 替换为目标进程的PID

2.6. 监控系统温度

 1import psutil
 2
 3def monitor_temperature():
 4    temps = psutil.sensors_temperatures()
 5    for name, entries in temps.items():
 6        for entry in entries:
 7            print(f"{name}: {entry.label} = {entry.current}°C")
 8
 9# 使用示例
10monitor_temperature()

3. 数据处理工具

3.1. 数据清洗

 1import pandas as pd
 2
 3def clean_data(input_file, output_file):
 4    df = pd.read_csv(input_file)
 5    df.dropna(inplace=True) # 删除空值
 6    df.drop_duplicates(inplace=True) # 删除重复值
 7    df.to_csv(output_file, index=False)
 8
 9# 使用示例
10clean_data("data.csv", "cleaned_data.csv")

3.2. 数据对比

 1import pandas as pd
 2
 3def compare_data(file1, file2):
 4    df1 = pd.read_csv(file1)
 5    df2 = pd.read_csv(file2)
 6    diff = df1.compare(df2)
 7    return diff
 8
 9# 使用示例
10result = compare_data("file1.csv", "file2.csv")
11print(result)

4. 文件处理工具

4.1. 批量重命名文件

1import os
2
3def batch_rename(directory, prefix):
4    for count, filename in enumerate(os.listdir(directory)):
5        new_name = f"{prefix}_{count}.txt"
6        os.rename(os.path.join(directory, filename), os.path.join(directory, new_name))
7
8# 使用示例
9batch_rename("/path/to/files", "file")

4.2. 查找大文件

 1import os
 2
 3def find_large_files(directory, size_limit_mb):
 4    size_limit = size_limit_mb * 1024 * 1024# 转换为字节
 5    large_files = []
 6    
 7    for root, dirs, files in os.walk(directory):
 8        for file in files:
 9            file_path = os.path.join(root, file)
10            if os.path.getsize(file_path) > size_limit:
11                large_files.append(file_path)
12    
13    return large_files
14
15# 使用示例
16large_files = find_large_files("/path/to/directory", 100) # 查找大于100MB的文件
17print(large_files)

5. 网络检测工具

5.1. 检测端口是否开放

 1import socket
 2
 3def check_port(host, port):
 4    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 5    result = sock.connect_ex((host, port))
 6    sock.close()
 7    return result == 0
 8
 9# 使用示例
10if check_port("example.com", 80):
11    print("Port 80 is open")
12else:
13    print("Port 80 is closed")

5.2. 批量ping测试

 1import os
 2
 3def ping_hosts(hosts):
 4    for host in hosts:
 5        response = os.system(f"ping -c 1 {host}")
 6        if response == 0:
 7            print(f"{host} is up")
 8        else:
 9            print(f"{host} is down")
10
11# 使用示例
12hosts = ["google.com", "example.com", "localhost"]
13ping_hosts(hosts)

6. 定时任务工具

6.1. 定时执行任务

 1import time
 2from datetime import datetime
 3
 4def scheduled_task(interval):
 5    while True:
 6        print(f"Task executed at {datetime.now()}")
 7        time.sleep(interval)
 8
 9# 使用示例
10scheduled_task(60) # 每60秒执行一次

Python 调用 QML 的两种方式

Sat, 12 Oct 2024 11:12:59 +0800

在 PySide6 和 QML 中，有两种主要的方式来创建和管理 QML UI：使用 QQuickView 和 QQmlApplicationEngine。

1. QQuickView

QQuickView 是一个可视化窗口，用于显示和管理 QML UI。您可以将 QQuickView 视为一个独立的窗口，它可以加载和显示 QML 文件。

使用 QQuickView 或 QQmlApplicationEngine 类可以创建一个 QML 视图对象，它是一个高级界面容器，可以显示 QML 内容。
QML 视图可以加载和显示 QML 文件，而不需要额外的代码。
可以使用 rootObject() 方法获取根 QML 对象，然后通过该对象访问 QML 中的属性和方法。
QML 视图对象通常用于简单的界面应用程序，而不需要太多的自定义逻辑。

QML 视图对象通常用于简单的界面应用程序，而不需要太多的自定义逻辑。

1from PySide6.QtCore import QUrl
2from PySide6.QtGui import QGuiApplication
3from PySide6.QtQuick import QQuickView
4
5app = QGuiApplication([])
6view = QQuickView()
7view.setSource(QUrl.fromLocalFile("main.qml"))
8view.show()
9app.exec()

在上述示例中，我们创建了一个 QQuickView 对象，并使用 setSource 方法加载了一个 QML 文件。然后，使用 show 方法显示了窗口，最后通过 app.exec 进入 Qt 事件循环。

2. QQmlApplicationEngine

QQmlApplicationEngine 是一个 QML 引擎，它可以加载和执行 QML 文件，并将其嵌入到现有的 Qt 应用程序中。

使用 QmlEngine 类可以创建一个 QML 引擎对象，它负责加载和管理 QML 内容。
可以将 QML 文件加载到引擎中，并通过引擎对象与 Python 代码进行交互。
引擎对象可以设置全局属性、注册自定义类型和提供信号与槽机制。
可以通过 rootObjects() 方法获取根 QML 对象，然后通过该对象访问 QML 中的属性和方法。

1from PySide6.QtCore import QUrl
2from PySide6.QtGui import QGuiApplication
3from PySide6.QtQml import QQmlApplicationEngine
4
5app = QGuiApplication([])
6engine = QQmlApplicationEngine()
7engine.load(QUrl.fromLocalFile("main.qml"))
8app.exec()

在上述示例中，我们创建了一个 QQmlApplicationEngine 对象，并使用 load 方法加载了一个 QML 文件。然后，通过 app.exec 进入 Qt 事件循环。

3. 主要区别

QQuickView 是一个可视化窗口，可以作为独立的应用程序窗口来使用，可以使用窗口管理功能，例如调整大小、最小化等。
QQmlApplicationEngine 是一个 QML 引擎，主要用于将 QML 嵌入到现有的 Qt 应用程序中，没有独立的窗口管理功能。

4. 总结

使用 QML 引擎（QML Engine）可以手动加载 QML 文件并进行更多的自定义操作，适用于需要更复杂交互和逻辑的场景。
使用 QML 视图（QML View）是一种简化的方式，适用于简单的界面应用程序，无需太多自定义操作。
如果您只需要一个独立的 QML 窗口，可以使用 QQuickView。如果您希望将 QML 嵌入到现有的 Qt 应用程序中，可以选择 QQmlApplicationEngine。

大文件并发分片下载

Thu, 26 Sep 2024 14:55:01 +0800

程序的主要功能是通过多线程的方式下载一个文件，并将下载进度条显示给用户。下面是对其各部分功能的详细总结：

1. 主要功能：

1.1. 并行分段下载文件

使用 requests 库的 Range 请求头，通过多个线程并行下载不同的文件片段，将这些片段组合起来完成整个文件的下载。
下载过程中使用 ThreadPoolExecutor 来管理线程，并行化下载以提高下载效率。

1.2. 显示下载进度

通过 tqdm 库为每个线程显示一个进度条，追踪每个线程下载的文件片段大小，并在主进度条中汇总所有线程的下载进度。

1.3. 断点续传

使用 .fetch 文件来追踪下载进度，如果文件已经部分下载，再次运行程序时可以从断点续传，而不必重新下载整个文件。

2. 关键模块与功能解释：

2.1. 文件的分段请求 (fetch_one)

根据文件的总大小，将下载任务分成多个段，每个段交给不同的线程处理。
使用 Range 头部请求文件的特定字节范围，确保每个线程下载对应的文件片段。

2.2. 多线程下载 (insert_data)

使用 ThreadPoolExecutor 来创建多个线程，进行并发的文件片段下载。
每个线程负责从指定的开始位置下载到结束位置，并将下载的数据写入文件的相应部分。

2.3. 显示下载进度 (tqdm)

对每个线程使用单独的 tqdm 进度条来显示下载进度，并汇总显示整个文件的总进度。下载过程中通过 pbar_thread.update() 来更新进度条的显示，便于用户了解下载的实时进度。

2.4. 断点续传

当下载中断时，通过保存文件进度在 .fetch 文件中，可以在下次运行时从中断的位置继续下载。

2.5. 错误处理

通过 try-except 捕获异常，并使用 loguru 记录错误信息。当下载失败时，程序不会崩溃，可以记录错误以便后续分析和处理。

3. 总体流程：

获取文件大小：首先通过 get_file_length() 获取文件的总大小。
创建文件占位：如果目标文件还未存在，则预先创建一个与下载文件大小一致的文件（填充空字节），以便可以使用 seek 精确写入下载的文件片段。
分段下载：使用 ThreadPoolExecutor 将下载任务分配给多个线程，线程根据 Range 头部请求文件片段，写入相应部分。
显示进度：通过 tqdm 显示下载的进度。
下载完成：下载结束后，删除 .fetch 文件并提示下载成功。

4. 优化点：

错误处理：可以进一步优化每个线程的错误处理，避免某个线程的失败导致整体下载失败。断点续传功能扩展：目前 .fetch 文件的实现较为简单，后续可以将每个片段的下载状态保存到 .fetch 文件中，保证下载中断时能更智能地恢复下载。

This is a tip

一个技巧横幅

或者

This is a tip

一个技巧横幅

 1import requests
 2from concurrent.futures import ThreadPoolExecutor
 3import os
 4from pathlib import Path
 5from loguru import logger
 6import traceback
 7from tqdm import tqdm
 8from threading import Lock
 9from functools import partial
10
11# url = "https://scontent.xx.fbcdn.net/m1/v/t6/An_YmP5OIPXun-vu3hkckAZZ2s4lPYoVkiyvCcWiVY21mu1Ng5_1HeCa2CWiSTsskj8HQ8bN013HxNpYDdSC_7jWQq_svcg.tar?ccb=10-5&oh=00_AfBn8XrMhiHu6w1KuS1X8rkuLzzZJnRs8B9jFMvVRfQnfg&oe=64659C28&_nc_sid=fb0754"
12#
13# tar_path = Path("/Users/chennan/Desktop/sa_000020.tar")
14# fetching_path = Path(f"{tar_path.as_posix()}.fetch")
15lock = Lock()
16downloaded = 0
17url = "https://images.pexels.com/photos/15983035/pexels-photo-15983035.jpeg"
18tar_path = Path("/Users/chennan/Desktop/pexels-photo-15983035.jpeg")
19fetching_path = Path(f"{tar_path.as_posix()}.fetch")
20pbar_threads = []
21
22def insert_data(info):
23    headers, start, end = info
24    pbar_thread = tqdm(total=end - start)
25    pbar_threads.append(pbar_thread)
26    with requests.get(url, stream=True, headers=headers) as response:
27        with tar_path.open('rb+') as f:  # path 文件保存路径
28            # 从文件的start位置开始写入
29            f.seek(start)
30            for chunk in response.iter_content(chunk_size=1024):
31                if chunk:
32                    f.write(chunk)
33                # pbar.update(len(chunk))
34                pbar_thread.update(len(chunk))
35            pbar_thread.close()
36
37
38def get_file_length():
39    # 改为requests.head可能更高效，待测试。
40    req = requests.get(url, stream=True)
41    return int(req.headers['content-Length'])
42
43
44def fetch_one(content_length):
45    all_thread = 64  # 线程数量
46    part = content_length // all_thread  # 每个线程请求的大小
47    for i in range(all_thread):
48        # 每个线程开始， 结束爬取的位置
49        start = part * i
50        if i == all_thread - 1:
51            end = content_length
52        else:
53            end = start + part
54        if i > 0:
55            start += 1
56        # 设置从网站请求开始和结束的位置
57        headers = {
58            'Range': f'bytes={start}-{end}',
59        }
60        yield headers, start, end
61
62
63if __name__ == '__main__':
64    content_length = get_file_length()
65    if not tar_path.exists():
66        with tar_path.open('wb') as f:
67            f.seek(content_length - 1)
68            f.write(b'\0')
69    if not fetching_path.exists():
70        with fetching_path.open("wb") as fs:
71            fs.write(b"\0")
72
73    try:
74        with ThreadPoolExecutor(max_workers=16) as pool:
75            pool.map(insert_data, fetch_one(content_length))
76        with tqdm(total=content_length) as pbar:
77            progress = sum(pbar_thread.n for pbar_thread in pbar_threads)
78            pbar.update(progress)
79        fetching_path.unlink()
80        logger.info("下载完成")
81    except Exception:
82        logger.error(f"{traceback.format_exc()}")

Telegram消息通过企业微信机器人发送警告通知的功能

Thu, 26 Sep 2024 14:28:22 +0800

程序的主要功能是从 Telegram 频道中抓取消息数据，并将其保存到 MongoDB 数据库中，同时通过 Redis 来存储和管理消息的偏移数据，用于跟踪消息的处理进度。它还包含将消息通过企业微信机器人发送警告通知的功能。

1. 具体功能总结：

1.1. MongoDB 数据库连接与更新

程序使用 pymongo 连接 MongoDB 数据库，提供了 update 方法来将抓取到的 Telegram 消息数据保存到 MongoDB 中，采用 upsert 模式（如果消息已存在则更新，否则插入）。

1.2. Redis 用于存储偏移信息

通过 Redis 来记录处理的 Telegram 消息的偏移量，确保从上次处理过的消息开始获取历史记录，避免重复处理消息。

1.3. Telegram 客户端配置与消息抓取

使用 telethon 的 TelegramClient 来连接 Telegram API，并通过异步的 iter_messages 方法抓取指定频道的消息。通过 format_message 方法将消息格式化为需要的结构化数据（包括消息文本、发送者信息、群组信息等），并返回一个字典格式的数据。抓取的消息按照消息 ID 或者日期进行排序，以获取指定的历史记录。

1.4. 消息保存与处理

消息经过格式化后，会通过 mongo_cli.update() 保存到 MongoDB 中。同时，使用 redis_cli.set 将当前处理的消息 ID 存入 Redis，以便下次继续处理新的消息。

1.5. 通过企业微信机器人发送通知

robot_warning 函数用于通过企业微信机器人发送通知。在某些场景下，抓取到的消息数据会被发送到企业微信中，作为系统的警告通知功能。

1.6. 定时任务调度

使用 apscheduler 的 AsyncIOScheduler 设置一个每隔 5 分钟运行一次的任务，调用 load_history_to_save 函数来抓取新的消息并进行处理。使用 next_run_time=datetime.datetime.now() 来立即启动第一个任务执行。

1.7. 异步加载 Telegram 历史消息

load_history_to_save 函数会遍历所有对话（群组或频道），通过异步的方式抓取历史消息并存储到 MongoDB 中，间隔 10 秒处理每个群组。使用 iter_dialogs 方法获取所有对话，依次处理每个群组的历史消息。

2. 总结：

该程序主要用于从 Telegram 群组或频道中抓取历史消息，并通过 MongoDB 和 Redis 进行数据存储与管理，结合定时调度任务自动获取最新的消息。同时，提供了一个企业微信通知机制来发送消息抓取的结果。

  1import asyncio
  2import datetime
  3import json
  4
  5import pymongo
  6import requests
  7from apscheduler.schedulers.asyncio import AsyncIOScheduler
  8from redis import Redis
  9from telethon import TelegramClient
 10# https://my.telegram.org/apps
 11from telethon.utils import get_display_name
 12
 13# 数据库基本信息
 14db_configs = {
 15    'type': 'mongo',
 16    'host': '127.0.0.1',
 17    'port': '27017',
 18    "user": "",
 19    "password": "",
 20    'db_name': 'new_spider'
 21}
 22
 23
 24class Mongo():
 25    def __init__(self):
 26        self.db_name = db_configs.get("db_name")
 27        self.host = db_configs.get("host")
 28        self.port = db_configs.get("port")
 29        self.client = pymongo.MongoClient(f'mongodb://{self.host}:{self.port}', connect=False, maxPoolSize=10)
 30        self.username = db_configs.get("user")
 31        self.password = db_configs.get("passwd")
 32        if self.username and self.password:
 33            self.db = self.client[self.db_name].authenticate(self.username, self.password)
 34        self.db = self.client[self.db_name]
 35
 36    def update(self, item, col="tg_spider"):
 37        if not isinstance(item, list):
 38            item = [item]
 39
 40        for each_item in item:
 41            coll = self.db[col]
 42            coll.update_one({"message_id": each_item["message_id"]}, {'$set': each_item}, upsert=True)
 43
 44
 45redis_cli = Redis.from_url("redis://@localhost:6379")
 46last_offset_date = datetime.datetime.strptime("2022-10-01", "%Y-%m-%d")  # 设置开始时间
 47api_id = xxxx
 48
 49api_hash = xxxxxx
 50
 51channel_dict = {}
 52
 53client = TelegramClient('ztelegrm', api_id, api_hash, connection_retries=15, retry_delay=3)
 54robot_url = xxxxx
 55
 56mongo_cli = Mongo()
 57
 58
 59def robot_warning(text, url):
 60    """
 61    企业微信机器人
 62    text: 文本
 63    url: 链接
 64
 65    """
 66    if isinstance(text, dict) or isinstance(text, list):
 67        text = json.dumps(text, ensure_ascii=False)
 68    headers = {
 69        "Content-Type": "application/json"
 70    }
 71    data = {
 72        "msgtype": "text",
 73        "text": {
 74            "content": text,
 75        }
 76    }
 77    return requests.post(url, headers=headers, data=json.dumps(data))
 78
 79
 80async def format_message(message, chat_id):
 81    if not message.text or message.media:
 82        return None
 83
 84    chat = await message.get_chat()
 85
 86    chat_display_name = get_display_name(chat)
 87    sender_user = await message.get_sender()
 88
 89    content = message.text
 90    talker = chat_id
 91    tg_id = getattr(sender_user, 'username', '')
 92    create_time = message.date.strftime("%s")
 93    group_name = chat_display_name
 94    first_name = getattr(sender_user, 'first_name', '')
 95    last_name = getattr(sender_user, 'last_name', '')
 96    if tg_id is None:
 97        tg_id = "未知"
 98    if last_name is None and first_name is None:
 99        user_name = "未知"
100    else:
101        user_name = f"{first_name}_{last_name}"
102    send_data = f"{content}|$#$#|{talker}|$#$#|{tg_id}|$#$#|{create_time}|$#$#|{group_name}|$#$#|{user_name}"
103    redis_cli.set(f"tg_cache_id_{chat_id}", message.id)
104    # return send_data
105
106    doc_data = {
107        "timestamp": message.date.strftime("%s"),
108        "sender": {
109            "username": getattr(sender_user, 'username', ''),
110            "firstName": getattr(sender_user, 'first_name', ''),
111            "lastName": getattr(sender_user, 'last_name', '')
112        },
113        "channel": chat_display_name,
114        "channel_id": chat_id,
115        "text": message.text,
116        "message_id": message.id
117    }
118    return doc_data
119
120
121async def get_channel_dict():
122    async for d in client.iter_dialogs():
123        channelId = d.entity.id
124        channelName = d.name
125        # channel_dict[channelId] = channelName
126        yield channelId, channelName
127
128
129async def load_history_to_save():
130    channel_dict = get_channel_dict()
131    async for channel_info in channel_dict:
132        channel_id = channel_info[0]
133        min_id = redis_cli.get(f"tg_cache_id_{channel_id}")
134        if min_id is None:
135            min_id = 0
136        print(channel_id, channel_info[1])
137        entity = await client.get_entity(channel_id)
138        await asyncio.sleep(10)
139        message_list = []
140        # 每次查50条，limit=50
141        if min_id == 0:
142            # 这个地方含义是获取2022-10-01这天的数据,从旧数据到新数据的顺序，这样message id逐渐增大。
143            async for message in client.iter_messages(entity, reverse=True, offset_date=last_offset_date, limit=50):
144                doc_data = await format_message(message, channel_id)
145                if doc_data:
146                    message_list.append(doc_data)
147        else:
148            # 根据message id获取数据，id逐渐增大。
149            async for message in client.iter_messages(entity, reverse=True, min_id=int(min_id),
150                                                      limit=50):
151                doc_data = await format_message(message, channel_id)
152                if doc_data:
153                    message_list.append(doc_data)
154        # robot_warning(message_list, robot_url)
155        mongo_cli.update(message_list)
156
157        print("发送完成")
158
159
160def start():
161    with client:
162        scheduler = AsyncIOScheduler()
163        scheduler.add_job(load_history_to_save, 'interval', minutes=5, max_instances=1,
164                          next_run_time=datetime.datetime.now())
165        scheduler.start()
166        client.loop.run_forever()
167
168
169if __name__ == '__main__':
170    start()

下载 YouTube 视频和音频

Thu, 26 Sep 2024 14:18:09 +0800

1. 安装

我的使用环境是 macOS，使用 pip 安装。

1pip3 install yt-dlp

之后查看版本

1yt-dlp --version
22024.08.06

在我开启系统代理的情况下，我可以直接使用它，它会自动走代理。

如果把代理关掉，再来使用它，自然连接不上。会出现这样的警告。

1WARNING: [youtube] Unable to download webpage: (<urllib3.connection.HTTPSConnection object at 0x10788cb10>, 'Connection to www.youtube.com timed out. (connect timeout=20.0)')

2. 使用

获取视频的结构（就是看它有哪些分辨率，哪些音频），使用大写的 F

1yt-dlp -F https://www.youtube.com/xxxxxxxxxxxxxxxxx

不加任何参数（也就是上面的命令去掉 -F），会自动下载质量最高的视频和音频，然后将它们合并起来。

1yt-dlp https://www.youtube.com/xxxxxxxxxxxxxxxxx

当然我们也可以自由选择，例如我们不需要那么高分辨率的视频，我只要 720P 就够了之类的。那么可以序号相加的方式，例如

1yt-dlp -f 251+614 https://www.youtube.com/xxxxxxxxxxxxxxxxx

3. 下载音频

我个人有这样的需要，想要下载视频的音频部分。所以我了解到有这样的参数，-x 参数，可以用来提取音频。

不过我发现这样是把完整的视频下载之后，再从视频中把音频提取出来。然后再删除掉视频……

感觉不环保，我明明不需要视频部分，它下载之后只保留音频，再删掉视频……

当然也有只下载音频的方法，先用 -F 查询信息，然后选择想要的音频 id 就行，例如

1yt-dlp -f 251 https://www.youtube.com/xxxxxxxxxxxxxxxxx

但是这样也比较麻烦，得先查询嘛。于是继续了解，发现可以使用 -f ba ，也就是 best audio 的首字母缩写，只下载质量最好的音频。

不过这样有时候下载的音频是 webm 格式的。

我观察了一个视频

1233 mp4   audio only        │                  m3u8  │ audio only          unknown             Default
2234 mp4   audio only        │                  m3u8  │ audio only          unknown             Default
3599 m4a   audio only      2 │    2.50MiB   31k https │ audio only          mp4a.40.5   31k 22k ultralow, m4a_dash
4600 webm  audio only      2 │    2.70MiB   33k https │ audio only          opus        33k 48k ultralow, webm_dash
5139 m4a   audio only      2 │    3.96MiB   49k https │ audio only          mp4a.40.5   49k 22k low, m4a_dash
6249 webm  audio only      2 │    3.99MiB   49k https │ audio only          opus        49k 48k low, webm_dash
7250 webm  audio only      2 │    5.31MiB   65k https │ audio only          opus        65k 48k low, webm_dash
8140 m4a   audio only      2 │   10.51MiB  129k https │ audio only          mp4a.40.2  129k 44k medium, m4a_dash
9251 webm  audio only      2 │    9.83MiB  121k https │ audio only          opus       121k 48k medium, webm_dash

只看它音频部分，其实质量最高的应该是 140 m4a audio only 2 │ 10.51MiB 129k 这个才对，不管是文件体积还是码率，它都是最大的。

但实际上使用 ba 参数，下载的是最高一项 webm 这个。难道是因为它是 48K 而上面的 m4a 是 44k 的？

那么我添加一个限制，排除掉 webm

1yt-dlp -f 'bestaudio/best' --format 'bestaudio[ext!=webm]'

这样后面再加上视频链接即可。

然后我再写一个 alias，之后我只需要「ya 视频链接」，就能下载一个视频的音频了。

1alias ya="yt-dlp -f 'bestaudio/best' --format 'bestaudio[ext!=webm]'"

Acme.sh申请免费ssl证书

Thu, 04 Jul 2024 09:03:10 +0800

acme.sh 实现了 acme 协议, 可以从 letsencrypt 生成免费的证书.

主要步骤:

安装 acme.sh
生成证书
copy 证书到 nginx/apache 或者其他服务
更新证书
更新 acme.sh
出错怎么办, 如何调试

下面详细介绍.

1. 安装 acme.sh

安装很简单, 一个命令:

curl https://get.acme.sh | sh -s email=my@example.com

普通用户和 root 用户都可以安装使用. 安装过程进行了以下几步:

把 acme.sh 安装到你的 home 目录下:

~/.acme.sh/

并创建一个 shell 的 alias, 例如 .bashrc，方便你的使用: alias acme.sh=~/.acme.sh/acme.sh

自动为你创建 cronjob, 每天 0:00 点自动检测所有的证书, 如果快过期了, 需要更新, 则会自动更新证书.

更高级的安装选项请参考: https://github.com/Neilpang/acme.sh/wiki/How-to-install

安装过程不会污染已有的系统任何功能和文件, 所有的修改都限制在安装目录中: ~/.acme.sh/

2. 生成证书

acme.sh 实现了 acme 协议支持的所有验证协议. 一般有两种方式验证: http 和 dns 验证.

2.0.1. http 方式

需要在你的网站根目录下放置一个文件, 来验证你的域名所有权,完成验证. 然后就可以生成证书了.

acme.sh --issue -d mydomain.com -d www.mydomain.com --webroot /home/wwwroot/mydomain.com/

只需要指定域名, 并指定域名所在的网站根目录. acme.sh 会全自动的生成验证文件, 并放到网站的根目录, 然后自动完成验证. 最后会聪明的删除验证文件. 整个过程没有任何副作用.

如果你用的 apache服务器, acme.sh 还可以智能的从 apache的配置中自动完成验证, 你不需要指定网站根目录:

acme.sh --issue -d mydomain.com --apache

如果你用的 nginx服务器, 或者反代, acme.sh 还可以智能的从 nginx的配置中自动完成验证, 你不需要指定网站根目录:

acme.sh --issue -d mydomain.com --nginx

注意, 无论是 apache 还是 nginx 模式, acme.sh在完成验证之后, 会恢复到之前的状态, 都不会私自更改你本身的配置. 好处是你不用担心配置被搞坏, 也有一个缺点, 你需要自己配置 ssl 的配置, 否则只能成功生成证书, 你的网站还是无法访问https. 但是为了安全, 你还是自己手动改配置吧.

如果你还没有运行任何 web 服务, 80 端口是空闲的, 那么 acme.sh 还能假装自己是一个webserver, 临时听在80 端口, 完成验证:

acme.sh --issue -d mydomain.com --standalone

acme.sh脚本默认ca服务器是zerossl，经常出错，会导致获取证书的时候一直出现：Pending, The CA is processing your order, please just wait.

只需要把ca服务器改成letsencrypt 即可，虽然更改以后还是有概率出现pending，但基本2-3次即可成功

acme.sh --set-default-ca --server letsencrypt

更高级的用法请参考: https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert

2.0.2. 手动 dns 方式

手动在域名上添加一条 txt 解析记录, 验证域名所有权.

这种方式的好处是, 你不需要任何服务器, 不需要任何公网 ip, 只需要 dns 的解析记录即可完成验证. 坏处是，如果不同时配置 Automatic DNS API，使用这种方式 acme.sh 将无法自动更新证书，每次都需要手动再次重新解析验证域名所有权。

acme.sh --issue --dns -d mydomain.com \
 --yes-I-know-dns-manual-mode-enough-go-ahead-please

然后, acme.sh 会生成相应的解析记录显示出来, 你只需要在你的域名管理面板中添加这条 txt 记录即可.

等待解析完成之后, 重新生成证书:

acme.sh --renew -d mydomain.com \
  --yes-I-know-dns-manual-mode-enough-go-ahead-please

注意第二次这里用的是 --renew

dns 方式的真正强大之处在于可以使用域名解析商提供的 api 自动添加 txt 记录完成验证.

acme.sh 目前支持 cloudflare, dnspod, cloudxns, godaddy 以及 ovh 等数十种解析商的自动集成.

以 dnspod 为例, 你需要先登录到 dnspod 账号, 生成你的 api id 和 api key, 都是免费的. 然后:

export DP_Id="1234"

export DP_Key="sADDsdasdgdsf"

acme.sh --issue --dns dns_dp -d aa.com -d www.aa.com

证书就会自动生成了. 这里给出的 api id 和 api key 会被自动记录下来, 将来你在使用 dnspod api 的时候, 就不需要再次指定了. 直接生成就好了:

acme.sh --issue -d mydomain2.com --dns  dns_dp

更详细的 api 用法: https://github.com/Neilpang/acme.sh/blob/master/dnsapi/README.md

3. copy/安装证书

前面证书生成以后, 接下来需要把证书 copy 到真正需要用它的地方.

注意, 默认生成的证书都放在安装目录下: ~/.acme.sh/, 请不要直接使用此目录下的文件, 例如: 不要直接让 nginx/apache 的配置文件使用这下面的文件. 这里面的文件都是内部使用, 而且目录结构可能会变化.

正确的使用方法是使用 --install-cert 命令,并指定目标位置, 然后证书文件会被copy到相应的位置, 例如:

3.1. Apache example:

acme.sh --install-cert -d example.com \
--cert-file      /path/to/certfile/in/apache/cert.pem  \
--key-file       /path/to/keyfile/in/apache/key.pem  \
--fullchain-file /path/to/fullchain/certfile/apache/fullchain.pem \
--reloadcmd     "service apache2 force-reload"

3.2. Nginx example:

acme.sh --install-cert -d example.com \
--key-file       /path/to/keyfile/in/nginx/key.pem  \
--fullchain-file /path/to/fullchain/nginx/cert.pem \
--reloadcmd     "service nginx force-reload"

(一个小提醒, 这里用的是 service nginx force-reload, 不是 service nginx reload, 据测试, reload 并不会重新加载证书, 所以用的 force-reload)

Nginx 的配置 ssl_certificate 使用 /etc/nginx/ssl/fullchain.cer ，而非 /etc/nginx/ssl/<domain>.cer ，否则 SSL Labs 的测试会报 Chain issues Incomplete 错误。

--install-cert命令可以携带很多参数, 来指定目标文件. 并且可以指定 reloadcmd, 当证书更新以后, reloadcmd会被自动调用,让服务器生效.

详细参数请参考: https://github.com/Neilpang/acme.sh#3-install-the-issued-cert-to-apachenginx-etc

值得注意的是, 这里指定的所有参数都会被自动记录下来, 并在将来证书自动更新以后, 被再次自动调用.

4. 查看已安装证书信息

acme.sh --info -d example.com
# 会输出如下内容：
DOMAIN_CONF=/root/.acme.sh/example.com/example.com.conf
Le_Domain=example.com
Le_Alt=no
Le_Webroot=dns_ali
Le_PreHook=
Le_PostHook=
Le_RenewHook=
Le_API=https://acme-v02.api.letsencrypt.org/directory
Le_Keylength=
Le_OrderFinalize=https://acme-v02.api.letsencrypt.org/acme/finalize/23xxxx150/781xxxx4310
Le_LinkOrder=https://acme-v02.api.letsencrypt.org/acme/order/233xxx150/781xxxx4310
Le_LinkCert=https://acme-v02.api.letsencrypt.org/acme/cert/04cbd28xxxxxx349ecaea8d07
Le_CertCreateTime=1649358725
Le_CertCreateTimeStr=Thu Apr  7 19:12:05 UTC 2022
Le_NextRenewTimeStr=Mon Jun  6 19:12:05 UTC 2022
Le_NextRenewTime=1654456325
Le_RealCertPath=
Le_RealCACertPath=
Le_RealKeyPath=/etc/acme/example.com/privkey.pem
Le_ReloadCmd=service nginx force-reload
Le_RealFullChainPath=/etc/acme/example.com/chain.pem

5. 更新证书

目前证书在 60 天以后会自动更新, 你无需任何操作. 今后有可能会缩短这个时间, 不过都是自动的, 你不用关心.

请确保 cronjob 正确安装, 看起来是类似这样的:

crontab  -l

56 * * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null

6. 关于修改ReloadCmd

目前修改ReloadCmd没有专门的命令，可以通过重新安装证书来实现修改reloadCmd的目的。此外，安装证书后，相关信息是保存在~/.acme.sh/example.com/example.conf文件下的，内容就是acme.sh --info -d example.com输出的信息，不过ReloadCmd在文件中使用了Base64编码。理论上可以通过直接修改该文件来修改ReloadCmd，且修改时，无需Base64编码，直接写命令原文acme.sh也可以识别。不过，example.conf文件的位置和内容格式以后可能会改变！example.conf一直都是内部使用, 后面有可能会改为用 sqlite 或者mysql 格式存储. 所以一般不建议自己修改。

7. 更新 acme.sh

目前由于 acme 协议和 letsencrypt CA 都在频繁的更新, 因此 acme.sh 也经常更新以保持同步.

升级 acme.sh 到最新版 :

acme.sh --upgrade

如果你不想手动升级, 可以开启自动升级:

acme.sh --upgrade --auto-upgrade

之后, acme.sh 就会自动保持更新了.

你也可以随时关闭自动更新:

acme.sh --upgrade --auto-upgrade  0

8. 出错怎么办：

请使用 --debug 参数输出详细的调试信息。

例如：

1acme.sh --issue  ......... --debug

要输出更详细的信息：

1acme.sh --issue  .......... --debug 2

常见问题的根本原因：

端口 80 被阻塞如果你的ISP（互联网服务提供商）阻止了端口 80，任何基于 webroot 的认证都将失败。你可以通过从你本地网络外部运行以下命令来测试这一点：
```
1curl -IkL -m20 http://[binanceearn.org]
```

使用 DNS API 的常见错误：

错误1：笨拙的操作 - ~/.acme.sh/account.conf 文件中有换行符如果在输入 API 密钥或私钥时意外地输入了换行符或拼写错误，请检查并确保 ~/.acme.sh/account.conf 文件中的密钥看起来正确。

我仍然看到旧的密钥（从 letsencrypt bot 切换到 .acme.sh 时）必要步骤 - 将 nginx 配置指向基于 acme 的新密钥如果在最终使 DNS 基础认证工作后仍然看到使用旧密钥的情况，您可能需要注释掉 letsencrypt bot 中的旧密钥，并指向新的文件夹：

1# RSA 证书
2
3#ssl_certificate /etc/letsencrypt/live/[binanceearn.org]/fullchain.pem; # 由 Certbot 管理
4
5#ssl_certificate_key /etc/letsencrypt/live/[binanceearn.org]/privkey.pem; # 由 Certbot 管理
6
7ssl_certificate [您的主目录]/.acme.sh/[binanceearn.org]/fullchain.cer;
8
9ssl_certificate_key [您的主目录]/.acme.sh/<binanceearn.org>/[您的域名].key;

我是否需要为 DNS 包含 webroot -w [您的 webroot] ？不需要！如果你的问题是端口 80 访问你的 webroot 文件夹失败，那么你最终会回到这个问题。

以上是关于使用 --debug 参数输出详细调试信息的翻译和解释。

在DNS验证模式下如果debug中出现诸如"timed out"等字样可能是因为GFW拦截了相应请求，需要添加http(s) proxy环境变量。（请按照自己实际设定修改）

export http_proxy="socks5h://localhost:1081" && export https_proxy="socks5h://localhost:1081"

如果是使用docker则完整示例配置如下：

docker run --rm  -it  \
  -v "/etc/acme":/acme.sh  \
  -e "CF_Token=[填入自己的信息]" \
  -e "CF_Account_ID=[填入自己的信息]" \
  -e "CF_Zone_ID=[填入自己的信息]" \
  -e http_proxy="socks5h://[代理A]:1234" \
  -e https_proxy="socks5h://[代理A]:1234" \
  --network container:[代理A]\
  neilpang/acme.sh \
  --issue -d example.com --dns dns_cf --debug

上述例子中使用cloudflare的DNS来签发证书，并通过把acme.sh链接到容器[代理A]，来转发curl请求（请按照自己实际设定修改）

最后, 本文并非完全的使用说明, 还有很多高级的功能, 更高级的用法请参看其他 wiki 页面.

https://github.com/Neilpang/acme.sh/wiki

吞吐量(TPS)、QPS、并发数、响应时间(RT)的概念与QPS计算公式

Tue, 02 Jul 2024 08:37:09 +0800

1. 响应时间(RT)

　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。

　　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

2. 吞吐量(Throughput)

　　吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。

　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

3. 并发用户数

　　并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

4. QPS每秒查询率(Query Per Second)

　　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。（看来是类似于TPS，只是应用于特定场景的吞吐量）. Qps 基本类似于 Tps，但是不同的是，对于一个页面的一次访问，形成一个 Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。

例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个“T”，产生三个“Q”。

5. PV（page view）

　　即页面浏览量，通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。用户每一次对网站中的每个页面访问均被记录 1 次。用户对同一页面的多次刷新，访问量累计。根据这个特性，刷网站的 PV 就很好刷了。与 PV 相关的还有 RV，即重复访问者数量（repeat visitors）。

6. UV 访问数（Unique Visitor）

　　指独立访客访问数，统计 1 天内访问某站点的用户数(以 cookie 为依据)，一台电脑终端为一个访客。可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的 cookies 实现的。如果更换了 IP 后但不清除 cookies，再访问相同网站，该网站的统计中 UV 数是不变的。如果用户不保存 cookies 访问、清除了 cookies 或者更换设备访问，计数会加 1。00:00-24:00 内相同的客户端多次访问只计为 1 个访客。根据这个特性，如果有人让你刷 UV，也很好的刷！

7. IP（Internet Protocol）独立 IP 数

　　是指 1 天内多少个独立的 IP 浏览了页面，即统计不同的 IP 浏览用户数量。同一 IP 不管访问了几个页面，独立 IP 数均为 1；不同的 IP 浏览页面，计数会加 1。IP 是基于用户广域网 IP 地址来区分不同的访问者的，所以，多个用户（多个局域网 IP）在同一个路由器（同一个广域网 IP）内上网，可能被记录为一个独立 IP 访问者。如果用户不断更换 IP，则有可能被多次统计。

8. GVM

　　所谓的 GMV，是 Gross Merchandise Volume 的简称。只要是订单，不管消费者是否付款、卖家是否发货、是否退货，都可放进 GMV 这个“大箩筐”里。电商是很在意 GMV 的，拼多多的优惠券事故，估计就能产生不少 GMV。根据 GMV 的统计方法，如果有人让你帮忙刷 GMV，你就可以一直下单，然后一直退款。

9. QPS 计算规则:

原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器。

假设每天500w PV 的在单台机器上，这台机器需要多少QPS？

( 5000000 * 0.8 ) / (86400 * 0.2 ) = 232 (QPS)。

一般需要达到232QPS，因为是峰值。

如果一台机器的QPS是60，需要几台机器来支持？ 232 / 80 = 2.9 = 3

9.1. 聚合报告各项性能指标1. 响应时间(RT)

9.2. 接口性能测试指标一般通过标准：

计算机性能衡量指标TPC、TPCC、TPMC

Mon, 01 Jul 2024 16:28:58 +0800

1. 什么是TPC和tpmC?

1.1. TPC

TPC(Transaction Processing Performance Council，事务处理性能委员会)是由数10家会员公司创建的非盈利组织，总部设在美国。该组织对全世界开放，但迄今为止，绝大多数会员都是美、日、西欧的大公司。TPC的成员主要是计算机软硬件厂家，而非计算机用户，它的功能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量，并管理测试结果的发布。

TPC的出版物是开放的，可以通过网络获取(http://www.tpc.org)。TPC不给出基准程序的代码，而只给出基准程序的标准规范(Standard Specification)。任何厂家或其它测试者都可以根据规范，最优地构造出自己的系统(测试平台和测试程序)。为保证测试结果的客观性，被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report)，包括被测系统的详细配置、分类价格和包含五年维护费用在内的总价格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。现在全球只有几个审核员，全部在美国。

TPC已经推出了四套基准程序，被称为TPC－A、TPC－B、TPC－C和TPC－D。其中A和B已经过时，不再使用了。TPC－C是在线事务处理(OLTP)的基准程序，TPC－D是决策支持(Decision Support) 的基准程序。TPC即将推TPC－E，作为大型企业(Enterprise)信息服务的基准程序。

1.2. tpmC

tpmC值在国内外被广泛用于衡量计算机系统的事务处理能力。但究竟什么是tpmC值呢?作者曾向一些用户、推销人员乃至某些国外大公司的技术人员问过这个问题，但回答的精确度与tpmC值的流行程度远非相称。tpmC这一度量也常被误写为TPM或TPMC。

TPC-C模拟一个批发商的货物管理环境。该批发公司有N个仓库，每个仓库供应10个地区，其中每个地区为3000名顾客服务。在每个仓库中有10个终端，每一个终端用于一个地区。在运行时，10×N个终端操作员向公司的数据库发出5类请求。由于一个仓库中不可能存储公司所有的货物，有一些请求必须发往其它仓库，因此，数据库在逻辑上是分布的。N是一个可变参数，测试者可以随意改变N，以获得最佳测试效果。

TPC-C使用三种性能和价格度量，其中性能由TPC-C吞吐率衡量，单位是tpmC。tpm是transactions per minute的简称；C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。要注意的是，在处理新订单的同时，系统还要按表1的要求处理其它4类事务请求。从表1可以看出，新订单请求不可能超出全部事务请求的45％，因此，当一个系统的性能为1000tpmC时，它每分钟实际处理的请求数是2000多个。价格是指系统的总价格，单位是美元，而价格性能比则定义为总价格÷性能，单位是＄/tpmC。

tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。

（吞吐量测试结果以比特/秒或字节/秒表示。）

2. TPCC

2.1. 基准测试

TPCC值被广泛用于衡量C/S环境下,由服务器和客户端构筑的整体系统的性能,它由事物处理性能委员会（TPC，Transaction Processing Corp）制定,TPC为非赢利性国际组织。

TPCC值可以反映出系统的性能价格比。TPCC测试系统每分钟处理的任务数,单位为tpm,(transactions per minute)。系统的总体价格(单位为美元)除以TPCC值,就可以衡量出系统的性价比,系统的性价比值越大,系统的性价比越好。

需要注意的是,TPC-C值描述的是C/S整体系统的性能,它与系统的服务器和客户机的性能都有关系,也就是说,同样的服务器配置不同的客户端将会影响TPCC值,任何厂商和测试者都可以根据TPC提供的测试规范构造出自己最优的系统,当然测试的结果要经过TPC审核。

2.2. 性能测试指标介绍

TPC-C

作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。

相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。

TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。

TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。

2.3. TPC-C规范概要

TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。

TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。

该系统需要处理的交易为以下几种：

New-Order：客户输入一笔新的订货交易；
Payment:更新客户账户余额以反映其支付状况;
Delivery:发货(模拟批处理交易);
Order-Status:查询客户最近交易的状态；
Stock-Level:查询仓库库存状况，以便能够及时补货。

对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。

2.4. 评测指标

TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。

TPC-C的测试结果主要有两个指标：

2.4.1. ①流量指标(Throughput，简称tpmC)

按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。

流量指标值越大越好！

2.4.2. ②性价比(Price/Performance，简称Price/tpmC)

即测试系统价格（指在美国的报价）与流量指标的比值。

性价比越大越好！

3. （TPCC）如何衡量计算机系统的性能和价格

在系统选型时，我们一定不要忘记我们是为特定用户环境中的特定应用选择系统。切忌为了“与国际接轨”而盲目套用“国际通用”的东西。在性能评价领域，越是通用的度量常常越是不准确的。据我所知，美国的一些大用户从不相信任何“国际通用”的度量，而是花相当精力，比如预算的5％，使用自己的应用来测试系统，决定选型。在使用任何一种性能和价格度量时，一定要弄明白该度量的定义，以及它是在什么系统配置和运行环境下得到的，如何解释它的意义等。下面我们由好到差讨论三种方式。

3.1. 在真实环境中运行实际应用

最理想的方式是搞一个试点，要求制造商或系统集成商配合将系统(含平台、软件和操作流程)在一个实际用户点真正试运行一段时间。这样，用户不仅能看到实际性能，也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否足够、全部价格是否合理。如果一个部门需要购买一批同类的系统，这种方式应列为首选，因为它不仅最精确、稳妥，也常常最有效率，用户还可先租一套系统作为试点。用这种方式得到的度量值常常具有很明确和实际的含义。

3.2. 使用用户定义的基准程序

如果由于某种原因第一种方式不可行，用户可以定义一组含有自己实际应用环境特征的应用基准程序。我举两个例子：近年来，由于R/3软件是应用层软件，SAP公司的基准程序获得了越来越多国外企业的认可；中国税务总局最近也开发了自己的基准程序，以帮助税务系统进行计算机选型。这种方式在中国尤其重要，因为中国的信息系统有其特殊性。

3.3. 使用通用基准程序

如果第1种和第2种方式都不行，则使用如TPC-C之类的通用基准程序，这是不得已的一种近似方法。因此，tpmC值只能用作参考。我们应当注意以下几点：

3.3.1. ①实际应用是否与基准程序相符

绝大多数基准程序都是在美国制订的，而中国的企事业单位与美国的运作方式常常不一样(恐怕也不应该或不可能一样)。在使用TPC－C时，我们应该清楚地知道：我的应用是否符合批发商模式?事务请求是否与表1近似?对响应时间的要求是否满足表1?如果都不是，则tpmC值的参考价值就不太大了。

3.3.2. ②TPC度量的解释

TPC基准程序是用来测系统而不是测主机的，厂家肯定要充分优化他们的被测系统。此处的“系统”包括主机、外设(如硬盘或RAID)、主机端操作系统、数据库软件、客户端计算机及其操作系统、数据库软件和网络连接等。在很多厂家的TPC测试系统中，主机的价格只是系统总价格的1/4或更小，而硬盘的价格有可能占到总价格的1/3以上，因为TPC－C要求被测系统必须保存180天的事务记录。如果同样的主机被用到用户的环境中，厂家报的tpmC值就意义不大，因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时，tpmC值可能有相当大的变化，现在很多用户还没有意识到这一点。

我举一个例子。假设用户希望购买一批同类系统，每一系统至少需要1GB的内存和50GB的硬盘。厂家A、B、C 各报了三个价格相当的系统，tpmC值分别为3000、2800、2600。用户是否应该选厂家A的产品呢?答案是：不一定。厂家用于测试tpmC值的系统与实际提供给用户的系统配置大不一样。tpmC最低的厂家C提供给用户的系统反而有可能性能最好，不论是以实际系统的tpmC值还是以用户的实际应用性能来衡量。

3.3.3. ③TPC测试的成本

TPC－C和TPC－D都是很复杂的基准程序，做一个严格的测试是很消耗资源的，厂家当然不会说出他们花费了多少钱和时间。但据国外知情人士透露，一个厂家做第一个TPC－C测试需要几十万到上百万美元的资金和半年左右的时间投入。因此，很多TPC的度量值都是估计的。由于计算机系统换代频繁，如果用户一定要用通过审核的度量值，就必须多等待半年时间，因此而不能用最先进的系统。中国的厂家通过审核的时间则更长。

综上所述，我们对中国用户(尤其是大用户)在计算机系统的选型方面有如下建议：

最好建立一个真实的试点，因为实际应用环境是检验计算机系统的最好标准。

中国的行业应该建立符合自己实际应用的基准程序和测试标准。中国税务总局的做法值得提倡。国家有关部门应该建立独立的测试中心，制定跨行业、符合中国企事业运作模式的性能测试标准。

“国际通用”的度量可以作为参考值，而不应作为必要条件。尤其是一定要弄清这些流行度量有什么含义，是在什么样的系统环境中测得的，以及基准程序是否符合企业真实的业务流程和运作模式。

4. TPCC计算原则

4.1. 建议

不管是TPC-C还是SPECjbb2000，计算结果都只能作为一个横向比较的参考。在实际应用中，决定系统性能的因素除了硬件、系统软件外，与应用软件的设计也是有很大关系的，此外，基于系统可扩展性的考虑，更多时候也倾向于一次性的采购。

从长远考虑，以政府信息化主管部门的角度考虑，建立一套评估机制是非常有用的，这其中包括：

1、通过对各单位业务系统运行情况的调查，进行历史数据的收集分析，按分类建立基准指标库。收集的信息包括：服务器的配置、并发用户数（每天业务量）、CPU负荷等；

2、由厂商定期提供基准值，更新基准指标库；

有了基准指标库的信息参照，不仅可以用于评估项目建设方案中服务器选型，也可以对各部门进行系统架构设计的优化提供指导。如以下是一些指导原则：

1、数据库服务器选型：采购两台相同配置的小型机，进行虚拟分区和并行处理，以提高系统资源的利用率；日后扩容时采取垂直扩展的方式进行升级；

2、应用服务器：采用负载均衡的方式提高并发处理能力，一般可配置2台以上，每台的硬件配置完全可以不同，应首先考虑使用旧的数据库服务器（利旧），如需采购新的服务器，应采用水平扩展的方式逐步升级；

3、 WEB服务器，可以考虑采用刀片服务器，提高扩展性和可管理性。

5. 参考：某项目计算实例

5.1. 参考1

为了方便计算数据库服务器的造型，我们约定：" 系统同时在线用户数为1500人（U1）；" 平均每个用户每分钟发出2次业务请求（N1）；" 系统发出的业务请求中，更新、查询、统计各占1/3；" 平均每次更新业务产生3个事务（T1）；" 平均每次查询业务产生8个事务（T2）；" 平均每次统计业务产生13个事务（T3）；" 一天内忙时的处理量为平均值的5倍；“经验系数为1.6；(实际工程经验) " 考虑服务器保留30％的冗余；

服务器需要的处理能力为：

**TPC-C=U1N1（T1+T2+T3）/33经验系数/冗余系数 **

则应用服务器的处理性能估算为：

TPC-C= 15002（3+8+13）/351.6/0.7= 274,285 tpmC

数据库服务器关系到整个系统的稳定运行，考虑到高可靠性和高可用性，并注重设备的可扩展性和性价比，系统将配置两台TPC-C值不小于28万的高性能数据库服务器。

5.2. 参考2

以单台服务器性能进行计算，即确保单台服务器工作的时候可以满足系统正常运行的需要；

假设每天有1万人次来窗口办理业务，每人次办理一项业务。即以每日1万笔前台交易为例进行综合系数的推导：

1. 假设每月前台交易数（未来5年内的设计指标）为220,000 （有些业务在月初、月末的处理量比较高，按月统计可以平衡此项差异）;

2. 每日前台交易数=220000/22=10,000 ，即每日 1万笔；3. 忙时处理能力：每日交易的80%在4个小时内完成，即1000080%/4=2000（笔/小时）4. 峰值处理能力：20002=4000（笔/小时），即峰值处理能力为每小时4000笔，或 67笔/分，假设业务人员同时在线为100人，即每人每分钟处理0.7笔）5. 假设每笔交易对应数据库事务数=20，基准TPC指标值对应的比例=8，cpu保留30%的处理能力冗余，计算值与公布值（最优值）的偏差经验值为4 （这几个参数估算的依据不足，更多的是经验值）

则 tpmC值为：

tpmC= 672084/(1-30%)= 61257[颠峰处理能力时（笔/分）每笔交易对应数据库事务数基准TPC指标值对应的比例计算值与公布值（最优值）的偏差经验值/（1- cpu保留30%的处理能力冗余）

倒算出综合系数 = 61257/10000=6.1即数据库服务器tpmC= 每日前台交易数 * 6.1 （实际计算值应不高于该值）

应用服务器的 tpmC = 数据库服务器 tpmC *50% （一般）

应用服务器的 tpmC = 数据库服务器 tpmC *70% （涉及大量计算的，如社保、税务）

5.3. 参考3

当前电信业已进入群雄并起、竞争极端激烈的战国时代,在话音、数据和各种增值服务等领域国内各电信运营商，在高端和低端的不同层次上，展开了大规模的中原逐鹿。在如此复杂的局面下，在众多繁复的业务种类竞争中，如何保证一个电信企业的良好运作，建立一个顺畅的收入现金流至为重要。这也就是为什么电信企业在计费系统上进行了不遗余力的投资。但是，正是业务种类层出不穷的推出、通信模式和接入技术快速进步，使电信计费系统存在着难以满足需要的局面，往往制约了电信的运营和业务的开展。如何建立一套能够满足当前乃至今后一定时间的业务开展，又能够保证安全稳定易管理的电信综合计费系统，是各电信运营商和电信科研单位极为重视的一个课题。下面结合中国网通的计费系统建设经验，为即将建设的计费系统的服务器选型方面提供一些建议和参考。

电信计费系统通常有如下种类的服务器:

接口服务器
认证服务器
计费服务器
采集服务器
数据库服务器
管理工作站等

其中，核心服务器为计费服务器、认证服务器和数据库服务器。在一些小型的计费系统中，接口服务器可以与采集服务器合一，计费服务器可以与认证服务器，甚至与数据库服务器合一,管理工作站也可以不设置专用工作站，而用 WEB 管理方式。

对于这些服务器，用途不同，在不同规模的计费系统方案中的组合也不同，业务规模也对服务器的处理性能、存储性能、开放等性能需求不同。选择适当的服务器，不仅能够充分满足业务开展所雲，而且能够提供为未来业务发展所需的系统扩展能力，这样既保障了运营，又能够节省投资。下面对计费系统的服务器选型、处理性能换算方法提出一些参考建议。

服务器处理性能计算方法

按照电信计费系统的统计经验值，一般每1万用户配置5个终端，通常同时访问数据库的终端数目概率为 20%，每次访问请求需处理1秒，其中平均要完成5个交易，由此需要的服务器处理性能为:

用户数x5x206x5x60/(10000x1)(TpmC)

5.3.1. 选型参考建议

标准化原则

符合 ISO 和 ANSI 标准，符合 SVRV4 标准，符合中国的有关计算机技术标准，选择当今业界较为流行的主要产品

高性能原则

保证所选购的服务器,不仅能够满足运营系统的运行和业务处理的需要,而且能够满足一定时期的业务量增长的需要。采用上面公式，计算出所需的服务器 TpmC 值，比较 IDC 公布的权威测算的厂商服务器 TpmC 值，选择相应的机型。同时，用服务器的市场价/报价除上计算出来的TpmC 值得出单位 TpmC 值的价格，从而选择高性能价格比的服务器。

可靠性原则

可靠性原则是所有选择设备和系统中要考虑的，尤其是在大型的、有大量处理要求的、需要长期运行的系统。

考虑服务器系统的可靠性，不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关辅助系统之间连接的整体可靠性，如:网络系统、安全系统、远程打印系统等。在必要时，还应考虑对关键服务器采用集群技术，如:双机热备份或集群并行访问的N+n技术，甚至采用可能的完全容错机。

保证系统(硬件和操作系统)在 99.98%的时间内都能够正常运作(包括维修时间),则故障停机时间六个月不得超过 0.5 个小时。服务器需 7x24 小时连续运行，因而要求其具有很高的安全可靠性。系统整机平均无故障时间(MTBF)不低于 80000 小时。

服务器如出现 CPU 损坏或其它机械故障,都能在 20 分钟内由备用的 CPU 和机器自动代替工作，无须人员操作，保证数据完整。

可扩展性原则

保证所选购的服务器具有优秀的可扩展性原则。因为服务器是所有系统处理的核心，要求具有大数据吞吐速率，包括:I/0 速率和网络通讯速率，而且服务器需要能够处理一定时期的业务发展所带来的数据量，需要服务器能够在相应时间对其自身根据业务发展的需要进行相应的升级，如:CPU 型号升级、内存扩大、硬盘扩大、更换网卡、增加终端数目、挂接磁盘阵列或与其他服务器组成对集中数据的并发访问的集群系统等。这都需要所选购的服务器在整体上具有一个良好的可扩充余地。

一般数据库和计费应用服务器在大型计费系统的设计中就会采用集群方式来增加可靠性,其中挂接的磁盘存储系统，根据数据量和投资考虑，可以采用 DAS、NAS 或 SAN 等实现技术。对于 Redius Server 可以依靠 Redius 协议采用双机互备，但不需要专门购买的集群软件。

安全性原则

服务器处理的大都是相关系统的核心数据,其上存放和运行着关键的交易和重要的数据。这些交易和数据对于拥有者来说是一笔重要的资产，他们的安全性就非常敏感服务器的安全性与系统的整体安全性密不可分，如:网络系统的安全、数据加密、密码体制等。服务器需要在其自身，包括软硬件，都应该从安全的角度上设计考虑，在借助于外界的安全设施保障下，更要保证本身的高安全性。

如图中所示的认证服务器(Redius Server)和 AAA Server，保障用户访问的合法性，防火墙和服务器的口令甚至一次性口令系统等则保障着系统和数据的安全,有的系统还采用了数据加密和线路加密等手段。

可管理性原则

服务器既是核心又是系统整体中的一个节点部分,就像网络系统需要进行管理维护一样，也需要对服务器进行有效的管理。这需要服务器的软硬件对标准的管理系统支持,尤其是其上的操作系统，也包括一些重要的系统部件。如 Management Station，它既可以是基于 B/S 结构的专用管理软件系统，也可以是基于SNMP 或 WEB 的通用管理方式的软件系统。

5.3.2. 如何规划和选择数据库服务器?

举例说明，使用 TPC-C进行数据库服务器评估

下面针对 XYZ 行的网上银行业务的需求，我们进行数据库服务器的选型分析。

由于目前 XYZ 行只有 17 个分行开通了网上银行业务，据我们估计，按照目前的客户数量全部分行都开通网上银行业务后，总的客户数量可以达到10万。考虑INTERNET 在我国的迅猛发展,客户数量的年增长率按照 50%计算,那么,3年后的客户数量将达到 10万x(1+50%)3≈34万。

这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高我们按平均每个企业客户每天做 1.5 笔交易计算:个人客户常用的交易是査询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易;那么，每天的交易量就是:

34万x50%x1.5+34万x50%x(4+30) ≈28万笔

假设网上银行的交易复杂度达到 15，那么，每天的数据库操作数达到:

28 万x15=420 万次

5.3.2.1. 高法诉讼费缴费:

由于诉讼费的增长量不大，我们按年递增率 5%计算。根据 XYZ 总行的统计，全国共 37 家分行，缴费量比较大的分行可以达到 25000 笔每月，占分行总数的 20%:缴费量中等的省可达到15000 笔每月，占分行总数的 30%;缴费量小的省可达到 7000 笔每月，占分行总数的 50%;按个月 20 个工作日计算。这样，三年后每天的交易数量可以达到:

(25000x20%+15000x30%+7000x50%)x37-20x(1+5%)3≈28740笔

我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到:

28740*13=373620 次

5.3.2.2. 整体性能要求:

总的数据库操作次数是:4200000+373620=4573620

假设每天的交易的 80%集中在4小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为:4573620x80%÷(4x60)≈15250

要为将来陆续加入的应用预留 40%的处理能力;另外,考虑到 CPU 的繁忙时间低于 70%时,系统的性能较好，我们把这个比例定在 65%。所以系统的 TPC-C 值应达到:15250-(1-40%)-65%≈39000

5.3.2.3. 内存容量需求分析

首先根据数据库容量算出所需的数据库缓存大小,再估计出操作系统、系统软件等所需内存,合计即是所需的内存容量

5.3.2.4. 网银数据量分析:

XYZ 总行网上银行系统的数据库由 CIF 信息，交易日志、交易流水三部分组成。

其中:CIF 信息包括企业客户和个人客户信息，企业客户信息平均大小为 20K 左右，个人客户信息平均大小为 5K 左右;每一笔交易都要记交易日志,日志的平均大小为 4K 左右;每一笔转帐交易都要记交易流水，交易流水的大小为2K左右。

这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做 1.5 笔交易计算:个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易;那么，每天的交易量就是:

所有的交易日志和交易流水都要保留三个月。由于个人客户的转帐交易非常少，可以忽略不计;假定企业客户的转帐交易占总交易量的 70%。我们就可以计算网上银行对存储系统容量的要求:

CIF 信息容量=20Kx(34万x50%)+5Kx(34万x50%)=3.25GB+421MB≈4GB

交易日志容量=[34万x50%x1.5+34万x50%x(4÷30)]x4Kx30x3 =277667x4Kx30x3~95GB

交易流水容量=(34万x50%x1.5)x70%x2Kx30x3 ≈30GB

XYZ 网上银行总体数据容量要求:=4GB+95GB+30GB=129GB

5.3.2.5. 高法诉讼费数据量分析:

高法的交易数据按要求要保留三年，每笔交易记录的大小为512字节，总体容量为:(25000x20%+15000x30%+7000x50%)x37x12x3x0.5K≈8.2GB

因此，数据库的总数据量为:129GB+8.2GB=137.2GB

数据库系统在缓存容量达到数据库总容量的5%时性能较好，因此，数据库缓存大小为:6.86GB。

5.3.2.6. 从而计算出系统内存需求为:

AIX操作系统所占的内存 128MB
数据库管理系统所占的内存 256MB
双机热备等系统软件所占的内存 128MB
应用程序所占的内存 256MB
数据库缓存 6.86GB
合理的内存利用率 75% 总计 10GB

5.3.2.7. 存储容量需求分析

除了上述的 XYZ 网上银行系统和高法诉讼费缴费系统的存储容量要求之外，还有异步查询下载服务的存储要求。

异步查询下载服务每隔1小时生成一个下载数据包，每个数据包的大小为 3MB，需要下载的数据包是上午十点生成的数据包，这个数据包需要保存2年，其它数据包只要保存3个月。因此，存储容量为:

23x3Mx30x3+1x3Mx365*2=6GB+2GB=8GB

为避免存储系统成为系统性能的瓶颈，系统存储系统的使用率应小于40%，建议采用镜像方式存储数据，因此总的存储容量为: (137.2GB+8GB)+40%x2=766GB HP 银行参考 TPC-C 测算参考以下吧!!

日峰值交易量，即每天业务高峰时的交易量，根据经验以在2小时内完成日均交易量的 80%为计算依据。

日峰值交易量=日均交易量x80%/2=104000(笔/小时)

月峰值日集中系数，即在每月的最忙日最忙时，其峰值交易量要高于根据上式计算出的平均日峰值交易量,为了使主机能够从容处理每月中的最高峰值交易量,在平均日峰值交易量的基础上考虑一个月峰值日集中系数，根据业务繁忙程度取值 1.5~3，根据###的具体情况，在这里取值1.5 。则:

104000x1.5÷3600 =43(笔/秒)

根据软件的测试结果，软件软件交易处理能力与计算机厂商公布的TPmC值之间的比例关系为1:4。由此，可得出###需主机系统的 TPmC 值:主机系统的处理能力为:43 x4x60=10320TPmC综合以上数值，####系统所需最大处理能力约为 10320TPmC

nightcat 兄，谢了?我也得到一个数据如下:跟据 xx银行提供的数据，目前的业务量为:日均5万笔日均交易量为5万笔。设 M 为每日实际交易量，则M=50,000

设T为每日实际交易时间或实际统计值，我们假设高峰期每日交易量在每天的2小时即 120 分钟内完成:T=120 标准交易指标值TPC-C对应于实际交易值比例为:MO=15:1应保证 50%(M1)的主机 CPU 处理余量，用于系统、数据库、工具软件、监控软件或其它应用系统的使用因此，对应计算得标准 TPC-C 估计值为:

TPC=M x MO/(T xM1)=50000x15/(120x50%)=12500

还应考虑系统业务未来三年的发展，每年增长率按 30%计算，得出的 TPC 值为:

TPC=12500x 1.3 x1.3x1.3=27462.5

5.4. 参考4

服务器系统作为劳动和社会保障各级数据中心的核心设备，提供计算处理服务、网络应用服务、劳动保障业务应用服务和其他服务。根据部省市局域网的逻辑构成，劳动保障信息系统的服务器设备包括数据库服务器、应用服务器、WEB 服务器、DNS 服务器等。服务器的配置应根据各级各类应用的不同规模和特点，并结合处理速度、存储容量、可靠性、系统开放性、性能价格比等因素来进行选择。

数据层服务器作为业务系统的核心，具有业务量大、存储量大等特点。它承担着业务数据的存储和处理任务,因此关键数据库服务器的选择就显得尤为重要。服务器的可靠性和可用性是首要的需求，其次是数据处理能力和安全性，然后是可扩展性和可管理性。为保证劳动保障信息系统持续稳定高效地运行，须保证服务器数据存储系统较高的可靠性、扩展性和灾难恢复能力。

基于RISC 系统的高中端服务器系统是适用于数据库服务器的选择，可根据具体业务需求和投资情况选择双机集群和单服务器系统，应用层服务器承担着业务系统的各类应用服务，主要强调其强大的计算能力，能够处理大量的并发连接处理，并能在用户数增加的情况下保持良好的性能平衡。

除此之外，能够提供连续可用的可靠性，能够适应各种网络环境的扩展能力也是需要考虑的因素。基于 RISC 系统的中低端服务器系统或高中端 PC服务器系统是适合于应用层服务器的选择,可根据具体业务需求和投资情况选择双机集群和单服务器方案。

其他服务器，如WEB 服务器、DNS 服务器等，要根据具体应用和投资要求在可靠性和处理能力等方面综合考虑。可采用中低端PC服务器系统。

下面以省级数据中心交换区数据层服务器为例，详细阐述服务器选型的方法。

省级数据中心交换区数据层服务器中作为社会保险关系异地转移、离退休人员异地数据交换和异地就医数据交换的数据库服务器，支持在职人员社会保险关系跨市转移的信息交换，以及异地领取养老金相关信息(如人员的基本状况、支付标准、生存状况等)的交换，同时保存死亡信息和公共服务信息、临时缓存宏观决策上报数据和基金监管信息。

考虑其作为中央、省、市三级数据中心信息交换的枢纽，所支撑应用的关键性，应采用基于 RISC 系统的高端服务器系统，具体配置要求如下:

5.4.1. 服务器处理能力

为支持本省的异地转移、异地就医和异地领取养老金等业务，需要较高的交易数据处理能力。

TPC 计算如下:

设: 全省参保总人数 C=980 万

交易日平均交易人数比例 a1=1%

每笔交易对应数据库事务数 a2=5

则:每日实际交易量 M= Cxa1xa2

交易日集中交易时间 T=120 分钟

交易日集中期内交易量比例 Ct=80%基准 TPC 指标值对应实际交易值的比例 MO=6:1CPU 处理能力余量 M1=30%-45%，取 35%

3年内每年处理能力增长率 P=30%

根据经验公式TPC=(MxM0xCt/(Tx(1-M1))x(1+30%)3=89,435

服务器选型考虑采用 TPC 值不低于 100,000 的高端服务器系统配置。

内存容量根据经验和类似业务量和环境，内存容量应为 1G/CPUxCPU数，从目前主流硬件厂商的指标来看，TPC 值要达到 100，000，一般需要配置8个CPU，因此内存建议配置 8GB.
总线带宽在高 CPU、大容量内存的配置下，必须要求主机系统总线带宽、/0 总线带宽都达到很高,否则,系统性能将形成瓶颈。
存储容量交换区平均数据量为 164.8GB，峰值数据量为 164.8GBx1.5，考虑 0.2倍的数据库索引和系统占用空间;作 RAID 保护后 60%存储利用率;以后数据增长，需提供 30%的数据扩充能力等因素，总存储容量约为:164.8x1.5x1.2160%170%=706GB，采用 SAN 中的光纤通道阵列作为数据存储.
可靠性、扩展性等

由于作为生产型数据库服务器，支持异地经办业务，属于实时性服务，该服务器系统在可靠性方面要求较高，可靠性必须达到 99.99%以上，提供全年 7x24 的可用性，配置为双机集群方式。系统采用多部件的冗余结构设计，具有高速差错校验和纠错的存储器，并有监控和诊断功能..

综上所述，对于在金保工程建设中服务器的选型，首先需对其业务系统的业务类型、业务复杂度等方面做系统的需求分析，其后根据需求在数据容量、数据处理的强度等方面进行估算，并兼顾服务器的可靠性、扩展性、安全性、可管理性等方面综合考虑，完成最终的产品选型。

5.5. 参考5

本工程合肥节点新建的处理能力以及用户容量规模如表1-1所示:

表1-1 本期工程 MMSC 处理规模

节点名称	用户容量	软件许可要求(MM/s)	软件许可要求(MM/s)	备注备注
合肥	200万	30	80	备注

5.5.1. 主要服务器处理能力

5.5.1.1. MMSC、数据库服务器和计费服务器

通常采用TPC-C指标衡量服务器的在线事务处理能力。TPC-C包括五种不同类型的即时处理或队列处理的并行交易混合，以分钟为单位计算。TPC-C的性能取决于计算机硬件、操作系统、数据库等多种因素。

目前MMS业务允许的消息大小为100KBytes，比短消息大3个数量级，其磁盘I/O，数据库访问所需要的服务器在线事务处理能力需求较高,华为公司经过测试得出不同的基本消息业务流程所需要的处理能力，如下表1-2所示:

单位:tpcC

表1-2 不同消息所需要的处理能力(单位:tpcC)

消息类型	MO	MT	EO	ET	AO	AT	FO	FT	系统保留(tpmC)
MMSC	6.3	7.8	8.6	9.8	8.5	8.2	8.2	8.3	1600
计费服务器	0.5	0.5	0.5	0.5	0.5	0.5	0.5	0.5	400
数据库服务器	0.5	0.5	0.5	0.5	0.5	0.5	0.5	0.5	400

考虑到基本格式转换需求，在EO/MT和MO/MT流程中进行字符集转换，进行字符集转换时相对于基本处理流程系统增加5%的处理能力开销。按本期工程要求，按照所有业务量的25%需要进行字符集转换配置系统。

在应用相关流程中，MMSC将业务请求传送给DSMP进行用户状态/订购信息的鉴权、认证以及批价操作，MMSC业务节点和计费服务器相对于基本业务流程需要增加相应的处理能力开销。

根据华为在广州进行DSMP功能测试的情况，与DSMP互联时增加的开销在13%左右，考虑到在现网业务情况相对复杂，与DSMP互联时业务节点和计费服务器相对于基本业务流程所需增加相应的处理能力开销取为15%。

根据本期工程需求，MMSC与DSMP进行互联时,接口处理能力按照不低于系统标称处理能力的15%业务量作为梦网业务进行考虑。

本期工程新增彩信计数器需求，根据华为公司相关产品的经验进行估计，进行计数器实时采集时，整个系统相对于基本业务流程需要增加5%的处理开销。

综合上述因素，消耗系统处理资源最大的业务流程为AO/FT业务流程，其处理能力要求为:(8.5+8.3)x(1+15%x15%)x(1+5%)=18.04 tpcC，华为MMSC设备选型即以此流程作为配置选型依据:

MMSC服务器

TPMC=每秒消息处理能力x60xTMs=80x60x18.04=86592(tpmC)

计费服务器

TPMC=每秒消息处理能力x60 xTi費x(1+DSMP增加的处理能力)-80x60x1x(1+15%x15%)=4908(tpmC)

Oracle数据库服务器

TPMC=每秒消息处理能力x60-80x60x1=4800(tpmC)

所需要的MMSC业务主机数=TPMC:(单机处理能力一系统保留处理能力)由上面的计算公式可得不同设备的处理能力如表1-3所示。

表1-3 不同设备的处理能力要求(单位:tpmC)

设备	处理能力	考虑 70%的系统利用率
MMSC	85592	122274
计费服务器	4908	7011
数据库服务器	4800	6857
合计	95300	136143
合计(计费和数据库，考虑 30%的冗余)	9708	13869

5.5.2. 配置建议

5.5.2.1. MMSC 业务主机

综合考虑MMSC业务特点，本工程建议选用V440和V490作为MMSC服务节点需要V440(4*1.28GHz)的单机数量计算如下:

86592÷(54612x0.7-1600)=2.36(台)

考虑冗余节点，及MMSC相互之间互备，实际配置4台V440(4*1.28GHz)的小型机，组成2套双机，相互之间互备每台主机所需要的内存为:

9.16÷4-2(系统保留)=4.29(G)

综上，本工程需要选用4CPU、8G的V440四台(2套双机，其中1台单机冗余)，作为4个MMSC业务集群节点，相互之间两两互备。

你会正确估算服务器处理能力吗？

Mon, 01 Jul 2024 16:22:13 +0800

1. 引题

但凡写过技术方案的都知道，在技术方案最终落实到工程实施部署时，必须编制出当前解决方案需要部署的IT设备及环境，包括：需要的网络环境、端口、带宽、组网方式、网络安全保障措施；需配置的服务器设备性能、数量；需配置的存储数据存储设备、容量、存储速率；甚至还需考虑整个系统的备份设备容量、备份I/O数、速率、备份策略等。

严格说来，无论是系统厂商、集成公司、还是研究院、设计公司，在最终提供方案的硬件配置时，都应该以业务需求为依据、适当考虑客户业务的发展趋势和系统冗余，详细估算：当前业务需求对网络带宽、对处理能力、对数据存储容量的指标。因此，本文以自己的项目案例和经验为基础，简述计算机处理能力如何正确估算，供大家参考。

2. 性能评测标准

众所周知，事务处理性能委员会的TPC-C标准，是测算和衡量计算机硬件设备性能的行业标准。随着B/S技术架构的大行其道，SPEC组织专门推出了针对Web服务器响应客户端Web访问请求的性能测算标准，即SPEC web系列。因此，如果是传统的基于事务处理模式的服务器，仍采用TPC-C的方式进行测算；如果是Web服务器，则需要采用SPEC web系列的标准进行测算。然而，很遗憾的看到，很多人在测算服务器性能时完全忽视这两种差别。

2.1. TPC-C标准

TPC-C基准是事务处理委员会建立的一个专门演示在线事务处理性能（OLTP）的性能基准，它的测量方法是为了使客户能够评估不同的在线事务处理系统的性能，这些事务进程于一个可控制的状态下在一个标准的数据库中运行。

TPC-C的事务处理是在一个9个表的数据库上实现的事务处理过程包括：更新、插入、删除、终止，以及对主和次级键的访问，每种事务处理95%的响应时间应小于或等于5秒，其中，库存水平的响应时间可以在60秒以内。TPC-C值表示每分钟处理的标准事务量，单位是tpmC。

2.2. SPEC web标准

SPEC web99，WEB 服务器可以支持的并发接入数。SPEC web99 检测程序模拟客户通过慢Internet 连接，向Web 服务器发送HTTP 工作量请求。

SPEC Web2005，作为SPECweb99的继承者，SPEC web2005延续了SPEC的传统测试的原理，通过多台客户机向服务器发出Http Get请求，请求调用Web服务器上的网页文件，这些文件从数千字节到数兆字节不等。在相同的时间里，服务器回答的请求越多，就表明服务器对客户端的处理能力越强，系统的Web性能就越好。

3. 性能估算公式

3.1. 常见的错误估算方法

在技术方案评审和招投标评标过程中，我常常看到这样的评估服务器处理能力的表格：

示例一： Web 服务器处理能力估算

序号	评估项	性能需求
1	最大并发用户数	500
2	每个连接每小时事务数	600
3	经验系数	1.5
4	应用类型指数	2
5	冗余系数(系统保证 30%冗余)	0.3
6	TPCC	21429

示例二： Web 服务器处理能力估算

序号	评估项	性能需求
1	最大并发用户数	500
2	每个连接每小时事务数	600
3	经验系数	1.5
4	应用类型指数	2
5	冗余系数(系统保证 30%冗余)	0.3
6	TPCC	21429

不知道这种评估方法是从那里开始的，在技术方案文档中，曾多次看到这样的评估模型和表格。即不全是TPC-C的评估方法，又不全是SPEC Web体系的评估方法。

3.2. TPC-C估算公式

TPC-C是用计算机设备在每分钟内所能处理的标准事务的数量来衡量其处理能力的多少；因此，估算一个应用场景对处理能力的需求，本质上就是估算出每类业务处理事务对应的标准tpc-c事务量，然后在适当考虑冗余量。TPC-C的测算结果是每分钟的事务数，单位是tpmc。

TPC-C的通用估算公式如下：

TPC-C = ∑(每分钟业务事务量 * 标准事务量比率)/ (1 — 冗余率)。

例如：某业务系统有2类业务处理事务操作，业务事务1每分钟30000个，每个业务事务1操作相当于0.5个标准tpc-c事务；务事务2每分钟20000个，每个业务事务2操作相当于2个标准tpc-c事务；考虑30%的系统冗余。则该业务应用需要的处理能力为：

服务器处理能力(tpmc) = ((30000 X0.5) + (20000 X 2)) / (1 – 30%) = 78581。

3.3. SPEC Web估算公式

SPEC Web2005标准的衡量结果是一台Web服务器能够有效响应客户端的Web请求的最大极限个数。因此，测算的结果应该是一个Web请求数字，单位是个。

在评估应用服务器的SPEC Web2005值时，通常的方法是通过系统的在线用户，结合其在线率估算出并发用户数，在参照日常业务使用场景中可能发起的http请求来进行估算。

SPEC Web2005的参考估算公式如下：(注意：公式仅供参考，需根据项目的具体情况自行设计估算模型)

Web访问响应能力(SPEC Web2005) = (在线用户数 * 在线率 * 在线用户平均发起http请求数)/ (1 — 冗余率)。

例如：某业务系统的在线用户数为2000，在线率10%，每在线用户平均发起的http请求数为3，考虑30%的系统响应能力冗余。则负责该业务请求的Web服务器的响应能力为：

[Web访问响应能力(个) = 2000 * 10% * 3 / (1 – 30%) = 857]

4. 应用实例

下面以一个实际工程项目的应用服务器(部署Web Service中间件)的性能估算为例进行示范。

应用服务器上运行中间件产品，承担系统的各类业务逻辑组件运行计算，收敛系统用户对数据库服务器的访问请求，集中对外提供应用服务。通过分析，应用服务器性能需求在于：提供Web应用服务、业务逻辑处理。

Web应用服务方面，根据的业务预测数据，应用服务器平均在线并发用户按120估算，并发在线率20%，每用户平均发起3个http链接，考虑30%系统响应冗余能力，参照SPECweb99的评测标准，Web应用服务性能需求：

[Web服务器最大并发连接数=(120×20%×3)/(1 - 30%)= 103]

业务逻辑处理性能方面，主要的应用服务组件性能需求在于：集团数据监测分析、省数据监测分析、业务数据查询。据调研统计，集团数据为每分钟3585 条，省数据平均为每分钟51667条，业务信息查询请求平均为每分钟2151次；集团数据监测分析，每次业务操作约需3个标准tpcc事务，省数据监测分析，每次业务操作约需2个tpcc事务，业务信息查询，每次业务操作约需2个tpcc事务；则系统主机的处理能力需求TPCC值计算如下：

分类	数据项	估算公式	估算结果
集团数据监测分析	每分钟服务过程记录	A1	3585
集团数据监测分析	每次控制器作标准TPCC	A2	5
集团数据监测分析	结果	A3 = A1 * A2	17925
省公司数据监测分析	每分钟分析记录数	B1	51667
省公司数据监测分析	每次控制器作标准TPCC	B2	2
省公司数据监测分析	结果	B2 = B1 * B2	103334
业务信息查询	每分钟服务数据查询请求	C1	2151
业务信息查询	每次操人生标准TPCC	C2	3
业务信息查询	结果	C3 = C1 * C2	6453
汇总	系统软件占用开锁	D0	10000
汇总	结果		137712
汇总	主机CPU处理冗余度	D2	30.00%
汇总	处理能力需求	D3 = D1/(1-D2)196731

自备

Wed, 26 Jun 2024 09:04:41 +0800

需要解锁后查看内容.

我是输入密码后可以看到的内容。

加密与安全：动态令牌 OTP、HOTP、TOTP 原理解析

Mon, 17 Jun 2024 13:51:34 +0800

1. OTP、HOTP、TOTP 简介

1.1. OTP

One-Time Password 简写，表示一次性密码。

1.2. HOTP

HMAC-based One-Time Password 简写，表示基于 HMAC 算法加密的一次性密码。是事件同步，通过某一特定的事件次序及相同的种子值作为输入，通过 HASH 算法运算出一致的密码。

1.3. TOTP

Time-based One-Time Password 简写，表示基于时间戳算法的一次性密码。

时间同步，基于客户端的动态口令和动态口令验证服务器的时间比对，一般每 60 秒产生一个新口令，要求客户端和服务器能够十分精确的保持正确的时钟，客户端和服务端基于时间计算的动态口令才能一致。　　

2. TOTP 弱点和漏洞编辑

TOTP 代码可以像密码一样被钓鱼，但它们需要网络钓鱼者实时代理凭证，而不是及时收集它们，不限制登录尝试的实现容易受到强制执行代码的攻击。

窃取共享密钥的攻击者可以随意生成新的有效 TOTP 代码。如果攻击者破坏了大型身份验证数据库，这可能是一个特殊问题。

由于 TOTP 设备的电池电量不足，时钟可以解除同步，并且由于软件版本在用户可能丢失或被盗的手机上，因此所有实际实施都有绕过保护的方法（例如：打印的代码，电子邮件 - 重置等），这可能给大型用户群带来相当大的支持负担，并且还为欺诈用户提供额外的利用向量。

TOTP 代码的有效期超过它们在屏幕上显示的时间（通常是两倍或更多倍）。这是一个让步，认证和认证方的时钟可以大幅度扭曲。所有一次性基于密码的身份验证方案（包括 TOTP 和 HOTP 等）仍然容易受到会话劫持，即在用户登录后占用用户的会话。

3. 原理介绍

3.1. OTP 基本原理

计算 OTP 串的公式：

1OTP(K,C) = Truncate(HMAC-SHA-1(K,C))

其中，

K 表示秘钥串；
C 是一个数字，表示随机数；
HMAC-SHA-1 表示使用 SHA-1 做 HMAC；
Truncate 是一个函数，就是怎么截取加密后的串，并取加密后串的哪些字段组成一个数字。

对 HMAC-SHA-1 方式加密来说，Truncate 实现如下：

HMAC-SHA-1 加密后的长度得到一个 20 字节的密串；
取这个 20 字节的密串的最后一个字节，取这字节的低 4 位，作为截取加密串的下标偏移量；
按照下标偏移量开始，获取4个字节，按照大端方式组成一个整数；
截取这个整数的后 6 位或者 8 位转成字符串返回。

示例：

 1public static String generateOTP(String K,
 2                                     String C,
 3                                     String returnDigits,
 4                                     String crypto){
 5       int codeDigits = Integer.decode(returnDigits).intValue();
 6       String result = null;
 7 
 8       // K是密码
 9       // C是产生的随机数
10       // crypto是加密算法 HMAC-SHA-1
11       byte[] hash = hmac_sha(crypto, K, C);
12       // hash为20字节的字符串
13 
14       // put selected bytes into result int
15       // 获取hash最后一个字节的低4位，作为选择结果的开始下标偏移
16       int offset = hash[hash.length - 1] & 0xf;
17 
18       // 获取4个字节组成一个整数，其中第一个字节最高位为符号位，不获取，使用0x7f
19       int binary =
20               ((hash[offset] & 0x7f) << 24) |
21               ((hash[offset + 1] & 0xff) << 16) |
22               ((hash[offset + 2] & 0xff) << 8) |
23               (hash[offset + 3] & 0xff);
24       // 获取这个整数的后6位（可以根据需要取后8位）
25       int otp = binary % 1000000;
26       // 将数字转成字符串，不够6位前面补0
27       result = Integer.toString(otp);
28       while (result.length() < codeDigits) {
29           result = "0" + result;
30       }
31       return result;
32   }

返回的结果就是看到一个数字的动态密码。

3.2. HOTP 基本原理

知道了 OTP 的基本原理，HOTP 只是将其中的参数 C 变成了随机数。

1HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))

HOTP：

Generates the OTP for the given count

C 作为一个参数，获取动态密码。

示例：

HOTP 的 python 代码片段：

1class HOTP(OTP):
2    def at(self, count):
3        """
4        Generates the OTP for the given count
5        @param [Integer] count counter
6        @returns [Integer] OTP
7        """
8        return self.generate_otp(count)

一般规定 HOTP 的散列函数使用 SHA2，即：基于 SHA-256 or SHA-512 [SHA2] 的散列函数做事件同步验证；

3.3. TOTP 基本原理

TOTP 只是将其中的参数 C 变成了由时间戳产生的数字。

1TOTP(K,C) = HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))

不同点是 TOTP 中的 C是时间戳计算得出。

1C = (T - T0) / X;

T 表示当前 Unix 时间戳：

T0 一般取值为 0，也就是 1970 年 1 月 1 日。

因此上式可以简化为：

1C = T / X;

X 表示时间步数，也就是说多长时间产生一个动态密码，这个时间间隔就是时间步数 X，系统默认是 30 秒；

例如:

1T0 = 0;
2 
3X = 30;

简化为：C = T / 30

1）T = 30 ~ 59

1C = 1;
2表示 30 ~ 59 这  30  秒内的动态密码一致。

2）T = 60 ~ 89

1C = 2; 
2
3表示 30 ~ 59 这 30 秒内的动态密码一致。

不同厂家使用的时间步数不同：

1阿里巴巴的身份宝使用的时间步数是 60 秒；
2 
3宁盾令牌使用的时间步数是 60 秒；
4 
5Google 的身份验证器的时间步数是 30 秒；
6 
7腾讯的 Token 时间步数是 60 秒；

TOTP 的 python 代码片段：

 1class TOTP(OTP):
 2    def __init__(self, *args, **kwargs):
 3        """
 4        @option options [Integer] interval (30) the time interval in seconds
 5            for OTP This defaults to 30 which is standard.
 6        """
 7        self.interval = kwargs.pop('interval', 30)
 8        super(TOTP, self).__init__(*args, **kwargs)
 9    def now(self):
10        """
11        Generate the current time OTP
12        @return [Integer] the OTP as an integer
13        """
14        return self.generate_otp(self.timecode(datetime.datetime.now()))
15 
16    def timecode(self, for_time):
17        i = time.mktime(for_time.timetuple())
18        return int(i / self.interval)

self.interval 是时间步数 X；
datetime.datetime.now() 为当前的 Unix 时间戳；
timecode 表示 (T - T0) / X，即获取获取动态密码计算的随机数。
TOTP 的实现可以使用 HMAC-SHA-256 或者 HMAC-SHA-512 散列函数；

TOTP 的要求：

客户端和服务器必须能够彼此知道或者推算出对方的 Unix Time；
客户端和服务器端必须共享一个密钥；
算法必须使用 HOTP 作为其关键实现环节；
客户端和服务器端必须使用相同的步长 X；
每一个客户端必须拥有不同的密钥；
密钥的生成必须足够随机；
密钥必须储存在防篡改的设备上，而且不能在不安全的情况下被访问或使用；
对该算法中 T 的实现必须大于 int32，因为它在 2038 年将超出上限；
T0 和 X 的协商必须在之前的步骤中就已经做好了。

4. 参考

4.1. python 的 otp 实现

1https://pypi.python.org/pypi/pyotp
2https://github.com/pyotp/pyotp

4.2. 基于 pyotp 的简单应用

1>>> import base64
2>>> base64.b32encode('This is my secret key')
3'KRUGS4ZANFZSA3LZEBZWKY3SMV2CA23FPE======'
4>>> secretKey = base64.b32encode('This is my secret key')
5>>> import pyotp
6>>> totp = pyotp.TOTP(secretKey)
7>>> totp.now()
8423779

简单说明：

加载base64的模块，将我的秘钥做一下base32的加密，加载pyotp模块，otp使用base32加密后的秘钥传作为种子，生成随机数字验证的。
可以使用pyotp和expect一起实现基于google authenticator的自动登录（免去每次双认证，输入密码和动态密码）。

4.3、pyotp 的 TOTP 的使用说明

1totp = pyotp.TOTP('base32secret3232')
2totp.now() # => 492039
3 
4# OTP verified for current time
5totp.verify(492039) # => True
6time.sleep(30)
7totp.verify(492039) # => False

4.3. pyotp 的 HOTP 的使用说明

1hotp = pyotp.HOTP('base32secret3232')
2hotp.at(0) # => 260182
3hotp.at(1) # => 55283
4hotp.at(1401) # => 316439
5 
6# OTP verified with a counter
7hotp.verify(316439, 1401) # => True
8hotp.verify(316439, 1402) # => False

4.4. 使用场景

服务器登录动态密码验证（如阿里云ECS登录，腾讯机房服务器登录等）；
公司VPN登录双因素验证；
网络接入radius动态密码；
银行转账动态密码；
网银、网络游戏的实体动态口令牌；
等动态密码验证的应用场景。

4.5. 市面上基于 HOTP 的产品

宁盾令牌
阿里巴巴的身份宝
Google 的身份验证器（google-authenticator）

4.6. Google 基于 TOTP 的开源实现

https://github.com/google/google-authenticator

RFC6238中TOTP基于java代码的实现。

4.7. golang 的一个 otp 实现

https://github.com/gitchs/gootp

4.8. RFC 参考

RFC 4226 One-Time Password and HMAC-based One-Time Password.

RFC 6238 Time-based One-Time Password.

RFC 2104 HMAC Keyed-Hashing for Message Authentication.

5. refer：

https://www.cnblogs.com/voipman/p/6216328.html

http://www.bubuko.com/infodetail-1884978.html

蓝队巨献！告警IP全自动封禁平台

Tue, 11 Jun 2024 13:39:35 +0800

1. 作为蓝队成员，你是否在防守过程中常常为以下问题所困扰？

尽管明确指定了防守资产，但封堵人员还是频繁误封生产环境。
安全设备匹配到DNS服务器请求的IOC域名告警时，封堵人员胡乱封禁DNS，导致邮件等需要外联的生产系统崩溃。
封堵人员甚至对127.0.0.1进行封禁，显现出严重的专业知识缺乏。
监测人员每时每刻都需要根据安全设备告警填写封禁IP协同表格，封禁人员也无法实时封禁攻击IP，效率低下。
重复性的工作需要大量人员参与，还必须进行24小时轮班，增加了人力成本和管理复杂度。
防守单位的防火墙等封禁设备性能低下，添加规则既繁琐又易导致系统崩溃。
误封IP后，解禁时需要在多个设备上反复排查搜索，耗费了大量时间和精力。
临时添加白名单IP后，无法有效同步给所有工作组成员。
总是重复封禁相同IP，封禁设备的规则库又容易空间不足，无法满足封禁需求。
封禁设备陈旧，无法支持封禁一定时间后自动解除。
安全厂商自家设备只能和自家设备进行联动，无法也不给适配全部设备，限制了整体防护效果。

2. 解决方案

针对以上问题，我们特此研发了全自动封禁平台（https://github.com/sec-report/SecAutoBan），从此防守不再困难，平台具备以下优势：

智能化防护：自动封禁威胁，减少人为错误，降低人力成本。
高效协同：封禁信息实时同步，确保所有工作组成员及时了解动态。
精确管理：支持对封禁规则进行细粒度控制，自动解除过期封禁，提升封禁设备性能。
兼容性强：能够与不同厂商的安全设备进行联动，构建全面的防护体系。
简化操作：用户友好的界面设计，简化操作流程，降低学习成本。

服务采用分布式设计，由三大模块组成，分别为：告警日志解析处理模块、核心处理模块、IP封禁/解禁模块，每个模块单独运行。

告警模块：负责处理所有来自安全设备的告警信息，并提取其中的IP地址。
核心模块：接收到告警模块传入的IP地址后，进行去重和过滤等处理，以确保只有有效的IP被处理。
封禁模块：接收来自核心模块处理后的IP地址，并进行相应的封禁操作。

具体思维导图如下：

整体封禁流程如下：

3. 安装使用

3.1. 安装核心模块

核心模块采用docker-compose方案一键安装，运行脚本前请先安装docker：

1mkdir SecAutoBan && cd SecAutoBan
2wget https://raw.githubusercontent.com/sec-report/SecAutoBan/main/docker-compose.yml
3wget https://raw.githubusercontent.com/sec-report/SecAutoBan/main/run.sh
4chmod +x run.sh
5./run.sh

Docker全部运行后访问http://127.0.0.1/访问管理后台，初始化管理员账号。

3.2. 新建告警/封禁设备

首先在管理后台添加设备：

添加设备后，复制设备连接Key。（注意：设备连接Key仅显示一次，请妥善保存）

3.3. 配置并运行告警/封禁模块

安装加密依赖，回连平台数据包需要加密：

1pip3 install pycryptodome

模块具体使用方法请跳转至项目文档：https://github.com/sec-report/SecAutoBan

（目前项目中只有python版样例，后续会上新golang等语言样例），根据项目文档配置好模块后，使用python运行即可。

运行告警分析模块：

运行封禁/解封模块：

运行成功后，平台将显示设备已连接：

模块全部运行后，就会有源源不断的报警推送到核心模块中，核心模块处理后会再推送给所有连接平台的封禁模块进行处置。

使用Web端实时查看封禁处置流水：

至此整个系统就全部运行起来了，享受全自动封禁带来的高效和便捷吧～

Linux 笔记整理

Wed, 05 Jun 2024 10:21:49 +0800

1. Linux 常见目录

目录	用途
/	根目录，通常不储存文件
/bin	二进制目录，存放用户级 GNU 工具
/boot	启动目录，存放启动文件
/dev	设备目录
/etc	系统配置文件目录
/home	主目录，Linux 在这里创建用户目录
/lib	库目录，存放系统和应用程序的库文件
/media	媒体目录，可移动媒体设备的常用挂载点
/mnt	挂在目录，另一个常用挂载点
/opt	可选目录，常用于存放第三方软件包和数据文件
/root	root 用户的主目录
/sbin	系统二进制目录，存放 GNU 管理员级工具
/run	运行目录，存放系统运作时的运行时数据
/proc	进程目录，存放现有硬件和当前进程的相关信息
/srv	服务目录，存放本地服务的相关文件
/sys	系统目录，存放系统硬件信息的相关文件
/tmp	临时目录，可以在该目录中创建删除临时工作文件
/usr	用户二进制目录
/var	可变目录

2. 常用命令

pwd：显示 shell 会话当前目录。. 表示当前目录，.. 表示当前文件目录的父目录。
man：查看手册。
cd destination：切换目录。
ls：显示当前目录下的文件和目录。
- -F：区分文件和目录，目录文件名后会添加/。
- -a：将隐藏文件和普通文件及目录一起显示出来。
- -R：递归选项。列出当前目录下包含的子目录中的文件。
- -l：产生长列表格式的输出，包含了目录中每个文件的相关信息：文件类型，权限，硬链接总数，属主的用户名，组名，大小，上次修改时间，文件名或目录名。
- -i：查看文件或目录的 inode 编号。
- --time=atime：显示访问时间。
文件扩展匹配：使用通配符。
- ?：代表一个字符。
- *：代表零个或多个字符。
- []：表示一个字符位置并给出多个可能的选择，也可以指定范围。
- !：将不需要的内容排除。
touch：创建空文件，或改变文件修改时间。
- -a：改变访问时间。
cp source destination：复制文件。
- -i：强制 shell 询问是否需要覆盖已有文件。
- -R：递归地复制整个目录的内容。
ln -s：创建符号链接。
- ln：创建硬链接。
- 符号链接是一个实实在在的文件，它指向存放在虚拟目录结构中某个地方的另一个文件。这两个通过符号链接在一起的文件，彼此的内容并不相同。
- 硬链接会创建独立的虚拟文件，其中包含了原始文件的信息和位置。但是它们从根本上而言是同一个文件。引用硬链接等同于引用了源文件。
mv：移动或重命名文件和目录。重命名、移动不改变 inode 编号和时间戳。
- -i：命令试图覆盖已有文件时得到提示。
rm：删除。
- -i：确认提示。
- -f：强制删除。
- -r：向下进入目录。
mkdir：创建目录。
- -p：同时创建多个目录和子目录。
- rmdir：只删除空目录。
file：查看目录、文件类型和字符编码。
cat：显示文本文件中所有数据。
- -n：给所有行加上行号。
- -b：给有文本的行加上行号。
- -T:用 ^I 替换文中制表符。
more：显示文本文件中的内容，但会在显示每页数据之后停下来。
- less：more 的升级。
tail：显示文件最后几行内容。默认显示文件的末尾 10 行。
- -n：修改所显示的行数。
- -f：在其他进程使用该文件时查看文件的内容，这是实时监测系统日志的绝妙方式。
head：显示文件开头内容，默认显示前 10 行。
- -n：修改所显示的行数。
ps：默认显示运行在当前控制台下的属于当前用户的进程。
top：实时显示进程信息。
kill PID：结束进程，必须为进程的属主或为 root 用户，只支持 PID。
- killall：支持进程名。
mount -t type device directory：挂载媒体设备。
- 默认输出当前系统上挂在的设备列表。
- umount：卸载设备。
df：查看所有挂载磁盘使用情况。
- -h：按用户易读的形式显示。
du：显示某个特定目录（默认情况是当前目录）的磁盘使用情况。
- -c：显示所有已列出文件总的大小。
- -h：按用户易读的形式显示。
sort：按会话指定的默认语言的排序规则对文本文件中的数据进行排序。
- -n：把数字识别成数字而不是字符，并且按值排序。
- -M：按月排序。
- -t：指定字段分隔符。
- -k：指定排序的字段。
- -r：将结构按降序输出。
grep [options] pattern [file]：搜索数据。
- -v：反向搜索，输出不匹配该模式的行。
- -n：显示匹配模式的行所在的行号。
- -c：显示有多少行含有匹配的模式。
- -e：指定多个匹配模式。
gzip：压缩文件
- gzcat：查看压缩过的文本文件的内容。
- gunzip：解压文件。
tar function [option] object：归档数据。
- -cvf：创建一个归档文件。
- -tf：列出内容。
- -xvf：提取内容。
- tar -zxvf filename.tgz：解压 .tgz
jobs：显示出当前运行在后台模式中的所有用户的进程。
- -l：显示命令的 PID。
history：查看最近使用过的命令列表。
- -a：将命令历史记录强制写入 .bash_history 文件。
alias -p：查看一些常用命令的别名。
env / printenv 查看全局变量，printenv 也可以查看个别环境变量。
useradd：添加新用户
- -D：查看默认值。
- -m：创建 HOME目录。
userdel：删除用户信息，不删除文件。
- -r：删除用户的 HOME目录以及邮件目录。
usermod：修改用户帐户的字段。
- -l：修改用户账户的登录名。
- -L：锁定账户。
- -p：修改账户的密码。
- -U：解除锁定。
passwd：修改密码。
- -e：强制用户下次登录时修改密码。

3. 文件权限

3.1. 文件权限符

举例说明：

1-rwxrwxr-x 1 rich rich 4882 2010-09-18 13:58 myprog
2
3# 登录名为 rich 的用户可以读取、写入以及执行这个文件。
4# rich 组的成员也可以读取、写入和执行这个文件。
5# 不属于 rich 组的其他用户只能读取和执行这个文件。

输出的第一个字段是描述文件和目录权限的编码。第一个字符代表对象的类型：

- 代表文件
d 代表目录
l 代表链接
c 代表字符型设备
b 代表块设备
n 代表网络设备

之后有 3 组三字符的编码，每组定义了 3 种访问权限：

r 代表对象是可读的。
w 代表对象是可写的。
x 代表对象是可执行的。

若没有某种权限，则该权限位会出现破折线。

3 组权限对应对象的 3 个安全级别：

对象的属主
对象的属组
系统的其他用户

3.2. Linux 文件权限码

权限	二进制值	八进制值	描述
—	000	0	没有任何权限
–x	001	1	只有执行权限
-w-	010	2	只有写入权限
-wx	011	3	有写入和执行权限
r–	100	4	只有读取权限
r-x	101	5	有读取和执行权限
rw-	110	6	有读取和写入权限
rwx	111	7	有全部权限

3.3. 默认文件权限

umask：设置所创建文件和目录的默认权限。系统默认的八进制的 umask 值是 0022。

1$ umask
20022

第一位代表了一项特别的安全特性。叫做粘着位。

要把 umask 值从对象的全权限值中减掉。对文件来说，全权限值是 666（所有用户都有读和写的权限），而对目录来说，则是 777（所有用户都有读、写、执行权限）。

3.4. 改变权限

chmod options mode file：改变文件和目录的安全性设置，可以使用八进制模式或符号模式进行设置。
- -R：让权限的改变递归地作用到文件和子目录。

3.4.1. 八进制模式

1$ chmod 760 newfile
2$ ls -l newfile
3-rwxrw---- 1 rich   rich   0  Sep 20 19:16 newfile

3.4.2. 符号模式

[ugoa...][+-=][rwxXstugo...]

[ugoa...]

u 代表用户
g 代表组
o 代表其他
a 代表上述所有

[+-=]

+：在现有权限基础上增加权限
-：在现有权限基础上移除权限
=：将权限设置成后面的值

[rwxXstugo...]

X：如果对象是目录或者它已有执行权限，赋予执行权限
s：运行时重新设置 UID 或GID。
t：保留文件或目录。
u：将权限设置为跟属主一样。
g：将权限设置为跟属组一样。
o：将权限设置为跟其他用户一样。

1# 移除属主已有的执行权限
2$ chmod u-x newfile
3$ ls -l newfile
4-rw-rw-r--   1 rich   rich   0  Sep 20 19:16 newfile

3.5. 改变所属关系

chown options owner[.group] file：改变文件的属主，也支持同时改变文件的属主和属组。
- -R：递归地改变子目录和文件的所属关系。
- -h：改变该文件的所有符号链接文件的所属关系。
chgrp：更改文件或目录的默认属组。

4. Vim 编辑器

vim <file_name>：启动 vim 编辑器。
vim + <file_name> : 打开文件并把光标移动到最后一行行首。
vim +<num> file_name : 打开文件并把光标移动到第 num 行的行首。
vim +<word> file_name : 打开文件并把光标移动到 word 第一次出现的位置行的行首，按 n 移动。

4.1. 普通模式

h：左移一个字符。
j：下移一行（文本中的下一行）。
k：上移一行（文本中的上一行）。
l：右移一个字符。
PageDown（Ctrl + F）：下翻一屏。
PageUp（Ctrl + B）：上翻一屏。
G：移到缓冲区的最后一行。
num G：移动到缓冲区中的第 num 行。
gg：移到缓冲区的第一行。

4.1.1. vim 编辑命令

命令	描述
x	删除当前光标所在位置的字符
dd	删除当前光标所在行
dw	删除当前光标所在位置的单词
d$	删除当前光标所在位置至行尾的内容
J	删除当前光标所在行行尾的换行符（拼接行）
u	撤销前一编辑命令
a	在当前光标后追加数据
A	在当前光标所在行行尾追加数据
r char	用 char 替换当前光标所在位置的单个字符
R text	用 text 覆盖当前光标所在位置的数据。直到按下 ESC 键

vim 在删除数据时，实际上会将数据保存在单独的一个寄存器中。可以用 p 命令取回数据。

vim 中复制命令是 y ，可以在 y 后面使用和 d 命令相同的第二字符（yw 表示复制一个单词，y$ 表示复制到行尾。）。在复制文本后，把光标移动刀你想放置文本的地方，输入 p 命令，复制的文本就会出现在该位置。

要输入一个查找字符串，按下斜线（/）键。

4.2. 命令行模式

q：如果未修改缓冲区数据，推出。
q!：取消所有对缓冲区数据的修改并退出。
w filename：将文件保存到另一个文件中。
wq：将缓冲区数据保存到文件中并退出。
替换命令：:s/old/new/
- :s/old/new/g：一行命令替换所有 old。
- :n,ms/old/new/g：替换行号 n 和 m 之间所有 old。
- :%s/old/new/g：替换整个文件中的所有 old。
- :%s/old/new/gc：替换整个文件中的所有 old，但在每次出现时提示。

5. 杂项

访问 Linux 虚拟控制台：Ctrl + Alt + F1 ~ F7
tty : 电传打字机（ teletypewriter ）
/etc/passwd：所有系统用户账户列表以及每个用户的基本配置信息。
只能对处于同一存储媒体的文件创建硬链接。不同储存媒体的文件之间创建链接，只能使用符号链接。
在一行中指定要依次运行一系列命令，只要在命令间加入 ； 号，即通过命令列表实现。
将命令置入后台模式，可以在命令行末尾加上字符 &。
/etc/profile 是系统默认的 bash shell 的主启动文件。
etc/passwd 文件的字段包含如下信息：登陆用户名，用户密码，用户账户的 UID ，用户账户的组 ID 。用户账户的文本描述，用户 HOME 目录的位置，用户的默认 shell。
本地连接虚拟机中的 Ubuntu 时，若出现 ssh: connect to host localhost port 22: Connection refused ，原因是 Ubuntu 没有默认提供 ssh 服务，首先安装 ssh apt-get install openssh-server ，如果安装完后该服务没有自动启动，则手工启动 sudo /etc/init.d/ssh start 。

6. 附

6.1. CentOS 7 使用 yum 更换 epel 仓库

6.1.1. 常规

安装：yum -y install epel-release
卸载：yum -y remove epel-release
查看：yum repolist

6.1.2. 手动安装

针对系统架构选择相应的类型，选择相应的包。

1rpm -vih https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-11.noarch.rpm

或

1cd ~ && wget https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-11.noarch.rpm  <br>rpm -vih epel-release-7-6.noarch.rpm

6.1.3. 查看并更新源

查看：ls -l /etc/yum.repos.d/
两个 epel 的 repo 文件：epel.repo 和 epel-testing.repo
更新：yum clean all && yum makecache

6.2. FirewallD 常用命令

6.2.1. 基本使用

启动： systemctl start firewalld
查看状态： systemctl status firewalld
停止： systemctl disable firewalld
禁用： systemctl stop firewalld

6.2.2. 配置

查看版本： firewall-cmd --version
查看帮助： firewall-cmd --help
显示状态： firewall-cmd --state
查看所有打开的端口： firewall-cmd --zone=public --list-ports
更新防火墙规则： firewall-cmd --reload
查看区域信息: firewall-cmd --get-active-zones
查看指定接口所属区域： firewall-cmd --get-zone-of-interface=eth0
拒绝所有包：firewall-cmd --panic-on
取消拒绝状态： firewall-cmd --panic-off
查看是否拒绝： firewall-cmd --query-panic
禁止被 ping：firewall-cmd --permanent --add-rich-rule='rule protocol value=icmp drop'

6.2.3. 添加删除端口

添加：firewall-cmd --zone=public --add-port=80/tcp --permanent（--permanent 永久生效，没有此参数重启后失效）
重新载入：firewall-cmd --reload
查看：firewall-cmd --zone= public --query-port=80/tcp
删除：firewall-cmd --zone= public --remove-port=80/tcp —permanent

不要开启tcp_tw_recycle

Tue, 04 Jun 2024 16:55:03 +0800

不要开启net/ipv4/tcp_tw_recycle

1. 问题描述

我们把Greenplum搬到了kubernetes上面。Greenplum主控分为master和standby两个容器，分别跑在2个物理机器上，容器网络为NAT(flannel)；为了方便用户访问，我们为每个租户分配了一个virtual ip(物理机器网段)，该地址由keepalived管理，具体实现上我们使用了kube-keepalived-vip，它也以容器的方式跑在kubernetes上，宿主机网络(因为要向宿主机下发virtual ip)，对keepalived本身做了封装：通过configmap传递virtual ip和real server(即master容器的ip地址，rmt50-vip-svc的endpoint)，并生成keepalived的配置文件，然后启动keepalived。keepalived会向内核下发lvs规则，将到virtual ip + 5432(192.168.128.5 5432)的报文走NAT转发给master容器(10.244.3.27 5432)。 configmap:

1apiVersion: v1
2data:
3  192.168.128.5: default/rmt50-vip-svc
4kind: ConfigMap

具体keepalived.conf:

 1vrrp_instance vips {
 2  state BACKUP
 3  interface eno16780032
 4  virtual_router_id 28
 5  priority 100
 6  nopreempt
 7  advert_int 1
 8
 9  track_interface {
10    eno16780032
11  }
12
13  virtual_ipaddress { 
14    192.168.128.5
15  }
16}
17
18# Service: default/rmt50-vip
19virtual_server 192.168.128.5 5432 {
20  delay_loop 5
21  lvs_sched wlc
22  lvs_method NAT
23  persistence_timeout 1800
24  protocol TCP
25  
26  real_server 10.244.3.27 5432 {
27    weight 1
28    TCP_CHECK {
29      connect_port 5432
30      connect_timeout 3
31      retry 1
32      delay_before_retry 3
33    }
34  }
35}

该租户各个容器的地址如下。其中rmt50-master为master容器,rmt50-standby是standby容器，rmt50-vip为vip容器。

1kubectl get pods -o wide|grep rmt50
2rmt50-master              1/1       Running    0          2d        10.244.3.27       s2.adb.g1.com
3rmt50-standby             1/1       Running    0          2d        10.244.1.250      m2.adb.g1.com
4rmt50-vip                 1/1       Running    5          2d        192.168.128.149   s2.adb.g1.com

但实际使用时，发现psql连接virtual ip(192.168.128.5)有一定概率会失败，服务器反馈端口不可达；查看kube-keepalived-vip容器(下面简称vip容器)的日志，发现是TCP_CHECK检测real_server超时后，将real_server从内核lvs表项中删除了(通过ipvsadm -l查看)。

一开始我以为是网络抖动，所以把connection_timeout, retry都调大了一点(retry 1确实有点太严苛了)，之后的确有所改善，但问题并没有根除，如果从另一物理机器(m1)和vip容器上同时去频繁psql连接virtual ip，基本上几分钟就可以复现出来。

2. 定位过程

2.1. 怀疑点1：网络

出现问题时，docker exec进入vip容器，发现ping master容器正常，说明从vip容器到master容器的网络是正常的。由于vip容器和master容器都在同一个物理机器上(s1)，只是vip容器在宿主机网络上，而master容器在flannel网络内；由于宿主机网络有所有的路由，因此从vip容器出来的报文，直接走cni0转发即可，源地址使用cni0的地址，一般来说不太会出问题。

2.2. 怀疑点2：postgre进程故障

在master容器上tcpdump抓包，可以看到vip 容器发过来的syn报文，但是master容器并没有应答，导致syn报文一直重传。如果postgre进程跑飞了会不会造成这个现象呢？在出问题的时候，我strace -p pid了下postgre进程，看到一直在select，说明内核没有上报新socket事件。

其实，根本就不应该怀疑postgre进程。从抓包看到只有收到syn没有应答syn+ack，就可以肯定跟用户态的postgre进程无关了：tcp三次握手完全是内核完成的，只有3次握手结束，内核才会给用户态进程上报事件；用户态最多就是不响应该事件，但不会造成不应答syn+ack。

2.3. 怀疑点3：内核丢包

只有这种可能了。linux内核调试起来比较麻烦，不过可以通过proc来看一些统计信息。

1cat /proc/net/netstat 
2TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps ArpFilter TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab DelayedACKs DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops TCPPrequeued TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue TCPPrequeueDropped TCPHPHits TCPHPHitsToUser TCPPureAcks TCPHPAcks TCPRenoRecovery TCPSackRecovery TCPSACKReneging TCPFACKReorder TCPSACKReorder TCPRenoReorder TCPTSReorder TCPFullUndo TCPPartialUndo TCPDSACKUndo TCPLossUndo TCPLostRetransmit TCPRenoFailures TCPSackFailures TCPLossFailures TCPFastRetrans TCPForwardRetrans TCPSlowStartRetrans TCPTimeouts TCPLossProbes TCPLossProbeRecovery TCPRenoRecoveryFail TCPSackRecoveryFail TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent TCPDSACKOfoSent TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnData TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger TCPAbortFailed TCPMemoryPressures TCPSACKDiscard TCPDSACKIgnoredOld TCPDSACKIgnoredNoUndo TCPSpuriousRTOs TCPMD5NotFound TCPMD5Unexpected TCPSackShifted TCPSackMerged TCPSackShiftFallback TCPBacklogDrop TCPMinTTLDrop TCPDeferAcceptDrop IPReversePathFilter TCPTimeWaitOverflow TCPReqQFullDoCookies TCPReqQFullDrop TCPRetransFail TCPRcvCoalesce TCPOFOQueue TCPOFODrop TCPOFOMerge TCPChallengeACK TCPSYNChallenge TCPFastOpenActive TCPFastOpenActiveFail TCPFastOpenPassive TCPFastOpenPassiveFail TCPFastOpenListenOverflow TCPFastOpenCookieReqd TCPSpuriousRtxHostQueues BusyPollRxPackets TCPAutoCorking TCPFromZeroWindowAdv TCPToZeroWindowAdv TCPWantZeroWindowAdv TCPSynRetrans TCPOrigDataSent TCPHystartTrainDetect TCPHystartTrainCwnd TCPHystartDelayDetect TCPHystartDelayCwnd TCPACKSkippedSynRecv TCPACKSkippedPAWS TCPACKSkippedSeq TCPACKSkippedFinWait2 TCPACKSkippedTimeWait TCPACKSkippedChallenge
3TcpExt: 0 0 118 0 0 0 0 0 1 0 94979 0 960494 0 0 906 343087 1119 5435 0 0 432477 9530 21215128 0 7057137 7 2736264 2582522 0 4 0 1 2 0 0 0 0 6 317 0 0 5 0 92 0 23 1992 1464 713 0 0 4 0 5450 62 1557 0 293509 80 0 12 0 0 0 0 0 782 49 0 0 0 0 171 0 0 0 0 0 0 0 2 1743889 11075 0 69 7 3 0 0 0 0 0 0 174 0 303158 542 542 3641 3021 21292349 27 749 0 0 0 0 0 0 0 0
4IpExt: InNoRoutes InTruncatedPkts InMcastPkts OutMcastPkts InBcastPkts OutBcastPkts InOctets OutOctets InMcastOctets OutMcastOctets InBcastOctets OutBcastOctets InCsumErrors InNoECTPkts InECT1Pkts InECT0Pkts InCEPkts
5IpExt: 3 0 4802567 1188058 6661 0 57132122839 92642737581 189351200 38019672 2189009 0 0 85932763 0 0 0

非常友好的统计信息！

回头还是用go写个小工具format下netstat，这个真的太难看了。我用atom把netstat竖排了下，发现有个ListenDrops计数在出现问题的时候会有变大。呵呵呵，坏人抓到了。

这里可以用我写的netproc来观察net计数的变化，还是比较友好的！

来看内核的这个计数是干啥的。

ListenDrops计数对应内核的LINUX_MIB_LISTENDROPS，走读下代码，可以看到有很多情况该计数会增加，为了区分不同情况，内核会在增加LINUX_MIB_LISTENDROPS的同时增加其他的计数。不慌，我们再看下netstat的信息，有没有发现PAWSPassive的计数跟ListenDrops是一致的？是不是巧合呢？没关系，我们再重复一把，看看netstat的变化。

果然还是一致的。

两次netstat的信息：

1PAWSPassive 3565   3858
2ListenDrops 3565   3858

PAWSPassive对应内核的LINUX_MIB_PAWSPASSIVEREJECTED，它只有一种情况下会出现：

tcp_ipv4.c/tcp_v4_conn_request:

 1int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 2		/* VJ's idea. We save last timestamp seen
 3		 * from the destination in peer table, when entering
 4		 * state TIME-WAIT, and check against it before
 5		 * accepting new connection request.
 6		 *
 7		 * If "isn" is not zero, this request hit alive
 8		 * timewait bucket, so that all the necessary checks
 9		 * are made in the function processing timewait state.
10		 */
11		if (tmp_opt.saw_tstamp &&
12		    tcp_death_row.sysctl_tw_recycle &&
13		    (dst = inet_csk_route_req(sk, &fl4, req)) != NULL &&
14		    fl4.daddr == saddr) {
15			if (!tcp_peer_is_proven(req, dst, true)) {
16				NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
17				goto drop_and_release;
18			}
19		}
20drop_and_release:
21	dst_release(dst);
22drop_and_free:
23	reqsk_free(req);
24drop:
25	NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
26	return 0;

net/ipv4/tcp_metrics.c:

 1bool tcp_peer_is_proven(struct request_sock *req, struct dst_entry *dst, bool paws_check)
 2{
 3	struct tcp_metrics_block *tm;
 4	bool ret;
 5
 6	if (!dst)
 7		return false;
 8
 9	rcu_read_lock();
10	tm = __tcp_get_metrics_req(req, dst);
11	if (paws_check) {
12		if (tm &&
13		    (u32)get_seconds() - tm->tcpm_ts_stamp < TCP_PAWS_MSL &&
14		    (s32)(tm->tcpm_ts - req->ts_recent) > TCP_PAWS_WINDOW)
15			ret = false;
16		else
17			ret = true;
18	}

内核版本为3.10。

简单来说，当开启了tcp_tw_recycle时，kernel会记录每个peer的最后一个报文的时戳，如果记录的该时戳仍然有效(距离当前时间小于TCP_PAWS_MSL)，并且新收到的syn报文的时戳，比kernel记录的该peer的时戳还要小(换句话说，时光倒流了)，那么就认为新收到的syn报文是有问题的(比如是某个在网络上兜兜转转了很久才到目的地址的syn)，从而drop之。

所以我们看到的现象就是，内核收到了新的syn报文，但只是默默drop了(没什么好处理方法，回RST可能误伤)，所以造成了psql连接超时。

3. 解决方法

只要将net.ipv4.tcp_tw_recycle恢复为默认值0即可。

4. 深入理解

4.1. TIME_WAIT是干啥的

先祭出tcp状态机迁移图。做协议栈的都要能默写啊！只有主动关闭连接的一方，才会转移到TIME_WAIT。

TIME_WAIT的主要目的有2个：

避免误收延迟到达的报文

如下图，由于TIME_WAIT的时间被缩短了，造成新建的连接收到了之前延迟到达的报文(5元组是匹配的)。

保证对端已经关闭了连接

如下图，由于TIME_WAIT的时间被缩短了，对端还处于LAST_ACK状态，本端发送的syn报文被直接RST掉了。

4.2. 为什么Greenplum会开启tcp_tw_recycle

为什么内核会开启net.ipv4.tcp_tw_recycle=1呢？网络上有很多资料建议繁忙的服务器开启这个sysctl，Greenplum也在其官网的资料Linux System Settings里提到，linux的/etc/sysctl.conf中应设置net.ipv4.tcp_tw_recycle=1。

开启tcp_tw_recycle的目的是为了减少TIME_WAIT状态的socket连接，从而减少内存、cpu的使用，因为TIME_WAIT状态的socket会快速释放；也可以提高并发连接的规格，因为客户端可以使用的端口号更多了。对比下没有开启recycle的情况，若服务端先关闭连接，socket会停留在TIME_WAIT状态的时间是1个TCP_PAWS_MSL(在linux上是1分钟)，在此时间内，客户端不能再使用刚刚用过的源端口号，否则服务端会直接RST之。

看上去很美好。

4.3. 为什么不要开启tcp_tw_recycle

但人算不如天算，当网络中存在NAT的情况下，开启tcp_tw_recycle会引起上述syn报文被丢弃的问题。我们来看下为什么。

从前面问题定位的过程可以发现，tcp_tw_recycle能够运转，其基础是tcp报文中需要带TIMESTAMP时戳选项。要了解tcp_tw_recycle，必然要先了解下tcp时戳选项。TCP timestamp这篇文章中详细的讲解了时戳，建议先跳转过去看看。

简单来说，TCP协议中有一个很重要的概念：RTO(Retransmission TimeOut)，重传超时时间，RTO是根据RTT(Round Trip Time)来动态调整的。但如何测量RTT呢？

一个办法是计算报文发送时间和对端ack确认的时间差，作为RTT。但由于报文重传、SACK等原因，这样计算出来的RTO可能会偏大，因此一般会选择没有重传的报文来计算。

另一个办法就是使用TIMESTAMP选项。

发送方在发送数据时，将一个timestamp(表示发送时间)放在包里面
接收方在收到数据包后，在对应的ACK包中将收到的timestamp返回给发送方(echo back)
发送发收到ACK包后，用当前时刻now - ACK包中的timestamp就能得到准确的RTT

时戳的值，在linux上是这样定义的：

include/net/tcp.h

1/* TCP timestamps are only 32-bits, this causes a slight
2 * complication on 64-bit systems since we store a snapshot
3 * of jiffies in the buffer control blocks below.  We decided
4 * to use only the low 32-bits of jiffies and hide the ugly
5 * casts with the following macro.
6 */
7#define tcp_time_stamp		((__u32)(jiffies))

jiffies即系统从开机到现在的时钟中断次数。

回到tcp_tw_recycle上来。我们来看下tcp_peer_is_proven这个函数中是怎么判断是否应该丢弃该syn报文的。

1if (tm &&
2		    (u32)get_seconds() - tm->tcpm_ts_stamp < TCP_PAWS_MSL &&
3		    (s32)(tm->tcpm_ts - req->ts_recent) > TCP_PAWS_WINDOW)    //here
4			ret = false;
5		else
6			ret = true;

只要新包的时戳比上次看到的时戳小，就判断报文有问题。可见，同一个peer的时戳，必须要线性增长，否则判断会出错。显然，一般情况下对于同一个客户端，”时戳线性增长”这个前提是满足的，但如果客户端在NAT之后呢？

我们在家里访问外部服务器的时候，家里可能有多台终端，其地址可能是192.168.1.100, 192.168.1.101，但在从家庭路由器出去的时候，会做一次SNAT，将报文的源地址替换为运营商给我们分配的公网地址。对于服务器来说，只能看到该公网地址。但由于2台终端开机的时间不一样，其报文中的TIMESTAMP选项值也不一样。因此，如果192.168.1.100的开机时间比192.168.1.101早，可能会出现192.168.1.100的连接关闭以后，192.168.1.101无法立即建立连接，因为后收到的syn报文的TIME_STAMP的值更小。在服务端来看，时间不可能倒流，那么新来的syn报文可能是个迟到的家伙，因此必然会被drop，192.168.1.101只能等一会才能建立连接(TCP_PAWS_MSL之后)。

如果192.168.1.100在频繁的连接建立、断开，192.168.1.101可能很久都无法连接的上。

4.4. 特殊国情

但我们的环境中，并不符合上述客户端在NAT里面的情况，而是反过来：master容器在NAT里面。

客户端访问virtual ip时，内核会做一次DNAT，将报文目的地址virtual ip转为master的ip，源地址不变。如果之后报文直接走cni0进入master容器，其实不会出现上面的问题：报文源地址是不同的。但由于kubernetes的缘故，报文在POSTROUTING阶段，还是会做一次SNAT(此处应该给生哥掌声)：

1Chain POSTROUTING (policy ACCEPT 6 packets, 360 bytes)
2 pkts bytes target     prot opt in     out     source               destination
36351K  563M KUBE-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes postrouting rules */
4    0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
52601K  177M RETURN     all  --  *      *       10.244.0.0/16        10.244.0.0/16
6 102K 6466K MASQUERADE  all  --  *      *       10.244.0.0/16       !224.0.0.0/4
71248K   86M MASQUERADE  all  --  *      *      !10.244.0.0/16        10.244.0.0/16

即：若报文的源地址和目的地址一个是10.244.0.0/16网段，一个不是，则走MASQUERADE，即做一次SNAT。MASQUERADE表示源地址不静态指定，而是动态选择。

因此，从m1上发出的psql请求，在经过lvs的一次DNAT和POSTROUTING阶段的一次SNAT之后，报文的源地址和目的地址，从192.168.128.158->192.168.128.5，变为了10.244.3.1->10.244.3.27；而从vip容器发出的psql请求，其源地址和目的地址就是10.244.3.1->10.244.3.27。

悲剧就发生了。

由于vip容器所在的机器启动时间要晚一点，因此受害者总是它，也就是我们一开始所描述的vip容器去psql连接master容器超时，但从m1上访问总是没问题的现象。

btw:上面的lvs+iptables实现了FULLNAT的效果，可以不给内核打阿里的补丁。

5. 总结

tcp_tw_recycle这个选项在内核的文档里说明的比较含糊，但是有一句警告：

1Enable fast recycling TIME-WAIT sockets. Default value is 0. It should not be changed without advice/request of technical experts.

意思就是：特殊勤务，请勿靠近。

不过man 7 tcp里倒是挺干脆的提示:

1Enable fast recycling of TIME_WAIT sockets. Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation).

ref:

Coping with the TCP TIME-WAIT state on busy Linux servers

一个NAT问题引起的思考

TCP timestamp

Docker Gitea

Tue, 04 Jun 2024 09:04:11 +0800

1. 准备工作

首先创建一个 gitea 工作目录，后续工作都在这个目录下完成。

1mkdir ~/gitea && cd ~/gitea

1.1. 添加密钥

1.在系统中添加 Docker 的官方 GPG 密钥

1sudo mkdir -p /etc/apt/keyrings && curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

2.以腾讯云为例，添加 Docker Repository 软件包镜像加速

1echo \
2  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://mirrors.cloud.tencent.com/docker-ce/linux/ubuntu \
3  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

1.2. 安装Docker

1sudo apt update && sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

2. 启动 Gitea

使用现有的 Docker Compose 模板启动 Gitea

2.1. 创建 `docker-compose.yml`

使用此模板创建 docker-compose.yml

 1docker-compose.yml
 2version: "3"
 3
 4networks:
 5  gitea:
 6    external: false
 7
 8services:
 9  server:
10    image: gitea/gitea:latest
11    container_name: gitea
12    environment:
13      - USER_UID=1000
14      - USER_GID=1000
15    restart: always
16    networks:
17      - gitea
18    volumes:
19      - ./gitea:/data
20      - /etc/timezone:/etc/timezone:ro
21      - /etc/localtime:/etc/localtime:ro
22    ports:
23      - "3000:3000"
24      - "3022:22"

Win下按ctrl + s，Mac下按command + s保存。

2.2. 启动 Gitea 实例

使用 Docker Compose 命令拉去镜像启动 Gitea 实例

1sudo docker compose up -d

3. 开始体验

3.1. 进入 Gitea 开始体验

Gitea 已经启动成功，点击访问当前实验环境的公网地址，完成初始化 Gitea 后即可开始体验应用。

点击安装Gitea，完成初始化 Gitea 后即可开始体验应用。管理员默认为第一个注册的用户。

OpenSSL 实践

Mon, 03 Jun 2024 16:30:56 +0800

1. 简介

数字证书（digital certificate）是公钥基础设施（public key infrastructure, PKI）的一个重要组成部分。证书包括公用钥匙和标的物识别名称（distinguished name, DN）以及其他内容。DN 是证书所携带的公用钥匙的实体的标识符。这个实体可以是任何需要加密服务的实体，如个人、组织或计算机程序。证书签发者（certificate issuer）使用其私人密钥签署证书。证书拥有者将他的证书提供给他人，以便他人可以安全地与他/她通信。证书中没有任何秘密，因此可以使用任何传递方式。但是，证书接受者在使用所附的公钥之前，必须验证证书的真实性。要做到这一点，就要获得证书颁发者的公钥，并用它来验证证书的签名。发证者的公钥也是通过证书获得的。该证书必须由链中更高一级的另一个发证者验证，或者出于特定的原因信任其真实性。

认证机构（certification authority, CA）是一个人，或者更可能是一个组织，它得到许多用户的信任。由于商业或实用性的原因，CA 可以按等级组织起来。最底层的是最终用户，他们要求中间 CA（如区域 CA）签署他们的证书。中间 CA 的证书由更高一级的 CA（如国家 CA）签署。最终，达到最高级别的 CA。这个 CA 被称为根 CA，其证书称为根证书。根证书是由根 CA 自签的，因为没有更高一级的 CA 可以证明根 CA 的身份。完整的证书验证意味着从根证书以下的级别到终端用户级别的所有证书都得到验证。不这样做是一个严重的安全风险。根证书不能以同样的方式进行验证。相反，它们是通过声誉来信任的，并且通常包含在运给用户的产品中（例如，在 Web 浏览器或嵌入式设备中）。

CA 有两类：public 和 private 。

公共 CA（如 Verisign）在公众中建立了信任，因为它们在为个人和组织提供认证服务方面有经济利益。如果公众知道签发的证书是假的（无论是故意还是错误），就会对 CA 所享有的信任产生灾难性影响，从而对 CA 从认证服务中获得的利润产生灾难性影响。

私人 CA 负责在一个组织内签发证书，比如在企业内部。在这种情况下，信任来源于雇主和雇员的关系。一个理性的雇主非常希望维护数字资源的安全访问。因此，实施适当的安全程序，例如为员工管理数字证书，是符合他们的最佳利益的。来自私人 CA 的证书可以保护内网网站的安全，或允许客户端对服务器进行认证。由于私人 CA 在其组织之外不受信任，因此除了组织成员外，其他人不能安全地使用其证书。

数字证书的事实上的标准格式是 X.509。这一标准的最初版本由国际电联于 1988 年发布。1995 年，IETF 成立了 Public-Key Infrastructure x.509 Working Group（PKIX-WG），以规范互联网上的 PKI 使用，其中包括如何使用 X.509 的指南（记录在 RFC 42101 中）。X.509 的初始版本有许多缺陷，并导致了后续版本的发布，X.509v3 是最新版本。

X.509v3 最显著的变化是对扩展的支持，它们允许证书包含 X.509v1 中定义以外的附加字段。一些扩展在 X.509v3 中因其有用性而被标准化，但非标准的扩展也是可能的。

扩展名由一个名称（字段名称）、一个分配给字段的值和一个表示该扩展名是否关键的布尔标志组成。如果任何关键扩展不被识别，那么处理具有关键扩展的证书的应用程序必须拒绝证书的有效性。不被应用程序识别的非关键扩展可以被忽略。

2. 实践指南

OpenSSL 是一个免费的开源加密库，它提供了处理数字证书的命令行工具。其中一些工具可以用来充当证书颁发机构。

最佳做法是创建一个根 CA 和一个或多个中间 CA。根 CA 的私钥由组织中一位值得信赖的（通常是既得利益者）成员离线保存。该成员可以将签发证书的责任委托给组织中的其他成员，这些成员将充当中间 CA。受信任的员工除了是根 CA 之外，还可以扮演中间 CA 的角色。为每个中间 CA 创建密钥对和证书。中间 CA 的证书用根 CA 的私钥签署。

如果怀疑中间 CA 的私钥被泄露，那么根 CA 可以撤销中间 CA 的证书。这就有效地破坏了证书链，并间接地使所有由泄露的CA签署的证书无效。当代理中间 CA 的个人离开组织时，可以采用同样的撤销程序。这将确保此人无法再代表组织签署任何证书。

3. 环境

系统：Ubuntu 18.04

创建主目录用于存放根证书：

1$ mkdir root_ca
2$ cd root_ca/
3$ mkdir certs crl newcerts private
4$ chmod 700 private/
5$ touch index.txt
6$ echo 1000 > serial
7$ pwd
8/home/root_ca

我们创建了四个子目录。当一个证书由根 CA 签发时，它会自动作为一个文件放在 newcerts 目录下。文件名是所发证书的序列号。这并不总是那么实用 —— 例如，有时你想通过所有者的名字来查找证书。因此，我们在 certs 目录下存储了每个由根 CA 发行的证书的副本。crl 目录下将包含有废止证书的列表。最后，私钥存储在私有目录下。私钥在任何时候都必须是保密的。这就是为什么我们设置了目录的权限位，只允许目录的所有者访问它的内容。

OpenSSL 将使用 index.txt 文件来跟踪所有签发的证书。每个证书必须有一个唯一的值，这个值是从序列文件中获得的。OpenSSL 为每一个创建的证书递增这个文件中的值。在第 6 行，我们提供了初始值。OpenSSL 将该文件的内容解释为十六进制值，所以 1000 实际上是 0x1000，也就是十进制的 4096 。

接着复制默认的配置文件到目录下：

1cp /etc/ssl/openssl.cnf /home/root_ca/

4. 修改用于创建根证书的配置文件

这里需要修改拷贝过来的配置文件 openssl.cnf 。

编辑 [ CA_default ] ，修改几个变量：

修改路径

1dir         = /home/root_ca

修改保存的名称，`<name><type><format>`

1certificate = $dir/certs/root.cert.pem
2crl         = $dir/crl/root.crl.pem
3private_key = $dir/private/root.key.pem

找到 `default_md` 并确保设置成 `sha256` ，默认的 `sha1` 已经被放弃使用。

1default_md  = sha256

找到并注释 `x509_extensions` 变量。因为用于特定目的的扩展都集中在一个共同的部分中。我们将在命令行中选择所需的扩展部分。

编辑 [ req ] 部分，主要在创建证书或证书签署请求时使用。

添加变量

1default_md  = sha256

编辑 [ req_distinguished_name ] 部分，本节定义了建立区分名称（distinguished name, DN）所需的元素，区分名称是唯一识别证书所有者的方法。

1countryName_default = CN
2stateOrProvince_default = Beijing
3localityName_default = Chaoyang
40.organizationName_default = the masses

编辑 [ v3_ca ] 部分，本节主要在创建根证书时使用。

取消注释 keyUsage 变量，并增加值

1keyUsage = critical, digitalSignature, cRLSign, keyCertSign

新增 [ v3_intermediate_ca ] 部分

1[ v3_intermediate_ca ]
2subjectKeyIdentifier = hash
3authorityKeyIdentifier = keyid:always,issuer
4basicConstraints = critical, CA:true, pathlen:0
5keyUsage = critical, digitalSignature, cRLSign, keyCertSign

`pathlen:0` 确保中间 CA 下面不能再有其他证书机构。

编辑 [ usr_cert ] 部分，该部分被用来签发客户证书。

取消注释并修改两个变量

1keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
2extendedKeyUsage = clientAuth, emailProtection

新增 [ server_cert ] 部分，主要用于签发服务器证书。

1[ server_cert ]
2basicConstraints = CA:FALSE
3subjectKeyIdentifier = hash
4authorityKeyIdentifier = keyid,issuer:always
5keyUsage = critical, digitalSignature, keyEncipherment
6extendedKeyUsage = serverAuth

5. 修改用于创建中间人证书的配置文件

为方便起见，在根证书目录下创建中间人证书目录：

1mkdir inter_ca
2cd inter_ca/
3mkdir certs crl newcerts private csr
4chmod 700 private/
5touch index.txt
6echo 2000 > serial
7echo 2000 > crlnumber
8cp ../openssl.cnf .

我们创建一个 csr 目录来存储所有传入的证书签名请求（certificate signature requests, CSR）。创建文件 crlnumber 用于跟踪 CRLs 。

如同上文一样，我们需要修改 openssl.cnf 中的路径，文件名等。

启用 x509_extensions 并设置成 usr_cert ，同时设置 policy 的值为 policy_anything 。

6. 为 root 和中间人创建密钥和证书

使 PKI 正常运行的下一步是分别为 root 和中间人生成密钥对和相应的证书。

6.1. 为 root 创建密钥

1$ cd root_ca/
2$ openssl genrsa -aes256 -out private/root.key.pem 4096
3Generating RSA private key, 4096 bit long modulus
4.......................................................................................................................................................................++
5............................................................................................++
6e is 65537 (0x010001)
7Enter pass phrase for private/root.key.pem: root # 仅作为示例使用，请勿模仿！
8Verifying - Enter pass phrase for private/root.key.pem: root
9$ chmod 400 private/root.key.pem

如果想要获得公钥，可以使用如下命令：

1openssl rsa -in private/root.key.pem -pubout -out root.pub.pem

这里我们不这么直接使用，因为公钥将在被嵌入证书后间接使用。

6.2. 为 root 生成自签名证书

 1$ openssl req -config openssl.cnf -key private/root.key.pem -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/root.cert.pem
 2Enter pass phrase for private/root.key.pem:
 3You are about to be asked to enter information that will be incorporated
 4into your certificate request.
 5What you are about to enter is what is called a Distinguished Name or a DN.
 6There are quite a few fields but you can leave some blank
 7For some fields there will be a default value,
 8If you enter '.', the field will be left blank.
 9-----
10Country Name (2 letter code) [CN]:
11State or Province Name (full name) [Beijing]:
12Locality Name (eg, city) [Chaoyang]:
13Organization Name (eg, company) [the masses]:
14Organizational Unit Name (eg, section) []:
15Common Name (e.g. server FQDN or YOUR name) []: cyqz_Root
16Email Address []:
17$ chmod 444 certs/root.cert.pem

6.3. 验证根证书

 1$ openssl x509 -noout -text -in certs/root.cert.pem
 2Certificate:
 3    Data:
 4        Version: 3 (0x2)
 5        Serial Number:
 6            8f:4f:94:a4:7d:21:49:d0
 7    Signature Algorithm: sha256WithRSAEncryption
 8        Issuer: C = CN, ST = Beijing, L = Chaoyang, O = the masses, CN = " cyqz_Root"
 9        Validity
10            Not Before: Dec 22 08:48:28 2020 GMT
11            Not After : Dec 17 08:48:28 2040 GMT
12        Subject: C = CN, ST = Beijing, L = Chaoyang, O = the masses, CN = " cyqz_Root"
13        Subject Public Key Info:
14            Public Key Algorithm: rsaEncryption
15                Public-Key: (4096 bit)
16                Modulus:
17                    00:c9:37:6b:a7:b0:b4:a5:2f:83:5e:65:ec:47:aa:
18                    92:9d:a5:20:f3:3a:c1:22:08:b9:a8:1e:eb:2b:49:
19                    2c:89:b5:a0:00:ae:f0:1b:48:2c:b0:24:83:10:fb:
20                    72:82:3b:af:38:c8:7d:46:48:90:17:76:64:ff:ca:
21                                        ...
22                    5d:fb:6f:4c:fb:65:b8:af:72:98:e8:84:e6:f0:fb:
23                    4b:c7:5e:13:23:7c:5d:10:ff:fb:92:19:d8:09:19:
24                    94:15:da:cb:b7:82:f1:0f:16:f8:45:2a:8b:43:b0:
25                    65:7e:53
26                Exponent: 65537 (0x10001)
27        X509v3 extensions:
28            X509v3 Subject Key Identifier:
29                CE:45:6D:DA:CB:11:46:F4:79:0A:D9:70:22:0A:95:92:49:FB:D1:37
30            X509v3 Authority Key Identifier:
31                keyid:CE:45:6D:DA:CB:11:46:F4:79:0A:D9:70:22:0A:95:92:49:FB:D1:37
32
33            X509v3 Basic Constraints: critical
34                CA:TRUE
35            X509v3 Key Usage: critical
36                Digital Signature, Certificate Sign, CRL Sign
37    Signature Algorithm: sha256WithRSAEncryption
38         77:5f:fe:43:c8:e3:37:51:68:1a:f8:e7:bd:43:bc:db:97:41:
39         a3:14:6e:92:7f:e6:90:a1:42:aa:f0:d4:e0:a2:d4:ab:ea:83:
40         94:5d:00:3b:d9:aa:9b:1d:f7:3b:7a:ae:30:08:1d:12:c0:ec:
41         d0:3b:af:1d:0d:47:45:d5:58:ed:b5:68:02:7d:db:2b:84:49:
42                                    ...
43         16:67:9d:53:d5:88:23:7b:4e:d0:34:b2:38:2e:9a:2f:20:ed:
44         64:97:ab:79:98:4f:fb:f4:a5:ef:e4:fb:98:66:26:9c:8f:ab:
45         74:f6:4d:eb:21:e5:6c:89

6.4. 为中间人创建密钥

1$ openssl genrsa -aes256 -out inter_ca/private/inter.key.pem 4096
2Generating RSA private key, 4096 bit long modulus
3...............................................................................++
4.......................................................................................................................................................................................................................................................................................................................................................++
5e is 65537 (0x010001)
6Enter pass phrase for inter_ca/private/inter.key.pem: inter # 仅作为示例使用，请勿模仿！
7Verifying - Enter pass phrase for inter_ca/private/inter.key.pem: inter
8$ chmod 400 inter_ca/private/inter.key.pem

6.5. 创建 CSR

 1$ openssl req -config inter_ca/openssl.cnf -new -sha256 -key inter_ca/private/inter.key.pem -out inter_ca/csr/inter.csr.pem
 2Enter pass phrase for inter_ca/private/inter.key.pem:
 3You are about to be asked to enter information that will be incorporated
 4into your certificate request.
 5What you are about to enter is what is called a Distinguished Name or a DN.
 6There are quite a few fields but you can leave some blank
 7For some fields there will be a default value,
 8If you enter '.', the field will be left blank.
 9-----
10Country Name (2 letter code) [CN]:
11State or Province Name (full name) [Beijing]:
12Locality Name (eg, city) [Chaoyang]:
13Organization Name (eg, company) [the masses]:
14Organizational Unit Name (eg, section) []:
15Common Name (e.g. server FQDN or YOUR name) []:cyqz_Inter
16Email Address []:
17
18Please enter the following 'extra' attributes
19to be sent with your certificate request
20A challenge password []:
21An optional company name []:

6.6. 验证 CSR

 1$ openssl req -text -noout -verify -in inter_ca/csr/inter.csr.pem
 2verify OK
 3Certificate Request:
 4    Data:
 5        Version: 1 (0x0)
 6        Subject: C = CN, ST = Beijing, L = Chaoyang, O = the masses, CN = cyqz_Inter
 7        Subject Public Key Info:
 8            Public Key Algorithm: rsaEncryption
 9                Public-Key: (4096 bit)
10                Modulus:
11                    00:b2:80:b6:b8:c5:d6:6a:37:56:da:40:c1:86:80:
12                    6d:cb:b4:01:a3:8d:9d:3e:1d:81:59:74:4c:e4:dd:
13                    39:10:94:f6:e9:f8:8e:fc:96:2b:18:fd:6a:54:23:
14                    70:80:8f:20:f3:f7:ce:c5:a1:58:43:de:af:80:36:
15                                        ...
16                    a1:fa:e2:fb:cf:30:04:69:88:a5:3a:63:5d:65:bd:
17                    03:ba:c8:54:8b:12:f6:3e:6f:36:fe:e8:e7:e3:6a:
18                    a8:8d:b6:74:ea:2c:47:9f:5b:2e:19:8a:1b:7f:22:
19                    83:c5:3d
20                Exponent: 65537 (0x10001)
21        Attributes:
22            a0:00
23    Signature Algorithm: sha256WithRSAEncryption
24         23:31:74:a6:3e:a4:87:82:c3:4e:7f:2d:50:bd:44:e3:1f:b7:
25         ae:2c:02:58:c8:b5:73:e3:0c:6e:c1:06:89:90:c2:42:42:2a:
26         f5:61:9c:7f:bf:6e:58:1b:4b:02:37:2c:ce:ac:e1:36:a4:09:
27         c8:47:43:ed:1f:81:04:e5:63:da:64:35:2a:20:0d:24:fa:48:
28                              ...
29         83:b5:53:93:0f:97:27:bf:69:e8:9a:2d:92:6e:9e:d5:5b:99:
30         ab:d7:d9:e6:57:77:9b:ba:3f:ae:c0:df:02:11:b2:00:50:1d:
31         8e:49:9f:5b:c6:b4:83:f4:84:b8:9b:c8:64:18:8f:02:06:84:
32         98:4c:8d:c9:4b:d1:0a:61

6.7. 创建中间人证书

 1$ openssl ca -config openssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in inter_ca/csr/inter.csr.pem -out inter_ca/certs/inter.cert.pem
 2Using configuration from openssl.cnf
 3Enter pass phrase for /root_ca/private/root.key.pem:
 4Check that the request matches the signature
 5Signature ok
 6Certificate Details:
 7        Serial Number: 4096 (0x1000)
 8        Validity
 9            Not Before: Dec 22 11:49:10 2020 GMT
10            Not After : Dec 20 11:49:10 2030 GMT
11        Subject:
12            countryName               = CN
13            stateOrProvinceName       = Beijing
14            organizationName          = the masses
15            commonName                = cyqz_Inter
16        X509v3 extensions:
17            X509v3 Subject Key Identifier:
18                4E:ED:71:D7:0E:F5:67:42:78:57:6B:77:DB:D1:0F:69:65:81:E2:40
19            X509v3 Authority Key Identifier:
20                keyid:CE:45:6D:DA:CB:11:46:F4:79:0A:D9:70:22:0A:95:92:49:FB:D1:37
21
22            X509v3 Basic Constraints: critical
23                CA:TRUE, pathlen:0
24            X509v3 Key Usage: critical
25                Digital Signature, Certificate Sign, CRL Sign
26Certificate is to be certified until Dec 20 11:49:10 2030 GMT (3650 days)
27Sign the certificate? [y/n]:y
28
29
301 out of 1 certificate requests certified, commit? [y/n]y
31Write out database with 1 new entries
32Data Base Updated
33$ chmod 444 inter_ca/certs/inter.cert.pem

6.8. 验证中间人证书

验证证书细节。

 1$ openssl x509 -noout -text -in inter_ca/certs/inter.cert.pem
 2Certificate:
 3    Data:
 4        Version: 3 (0x2)
 5        Serial Number: 4096 (0x1000)
 6    Signature Algorithm: sha256WithRSAEncryption
 7        Issuer: C = CN, ST = Beijing, L = Chaoyang, O = the masses, CN = " cyqz_Root"
 8        Validity
 9            Not Before: Dec 22 11:49:10 2020 GMT
10            Not After : Dec 20 11:49:10 2030 GMT
11        Subject: C = CN, ST = Beijing, O = the masses, CN = cyqz_Inter
12        Subject Public Key Info:
13            Public Key Algorithm: rsaEncryption
14                Public-Key: (4096 bit)
15                Modulus:
16                    00:b2:80:b6:b8:c5:d6:6a:37:56:da:40:c1:86:80:
17                    6d:cb:b4:01:a3:8d:9d:3e:1d:81:59:74:4c:e4:dd:
18                    39:10:94:f6:e9:f8:8e:fc:96:2b:18:fd:6a:54:23:
19                    70:80:8f:20:f3:f7:ce:c5:a1:58:43:de:af:80:36:
20                                       ...
21                    11:b4:43:5d:da:30:b0:b9:47:2f:8d:cf:d3:7e:f6:
22                    a1:fa:e2:fb:cf:30:04:69:88:a5:3a:63:5d:65:bd:
23                    03:ba:c8:54:8b:12:f6:3e:6f:36:fe:e8:e7:e3:6a:
24                    a8:8d:b6:74:ea:2c:47:9f:5b:2e:19:8a:1b:7f:22:
25                    83:c5:3d
26                Exponent: 65537 (0x10001)
27        X509v3 extensions:
28            X509v3 Subject Key Identifier:
29                4E:ED:71:D7:0E:F5:67:42:78:57:6B:77:DB:D1:0F:69:65:81:E2:40
30            X509v3 Authority Key Identifier:
31                keyid:CE:45:6D:DA:CB:11:46:F4:79:0A:D9:70:22:0A:95:92:49:FB:D1:37
32
33            X509v3 Basic Constraints: critical
34                CA:TRUE, pathlen:0
35            X509v3 Key Usage: critical
36                Digital Signature, Certificate Sign, CRL Sign
37    Signature Algorithm: sha256WithRSAEncryption
38         9d:6d:32:00:ab:1f:cd:b0:df:5d:fd:43:80:b4:0c:83:91:66:
39         7b:b7:f2:af:da:9a:b5:f7:3a:40:f0:ea:1c:b6:f1:05:a0:c9:
40         fa:29:57:75:d0:cb:fe:c3:e3:00:30:e5:bd:3c:da:c6:e0:09:
41         03:90:ed:d3:79:ee:86:bd:7c:7e:c0:b5:98:13:40:2e:d9:92:
42                                      ...
43         f6:fd:a1:e5:da:11:53:e0:e5:14:ba:95:15:a8:3a:e1:6d:ec:
44         37:1c:94:ae:7d:97:e4:52:56:40:23:cf:cb:36:89:24:56:29:
45         f3:2e:be:5a:0d:6b:64:ea:64:f0:3a:de:3e:cb:f4:96:fd:ce:
46         a8:ce:02:24:b6:b3:64:90:e3:57:5a:47:a2:59:3b:da:59:31:
47         a4:1e:be:26:d4:c7:c6:f5

将中间证书与根证书进行核对。

1$ openssl verify -CAfile certs/root.cert.pem inter_ca/certs/inter.cert.pem
2inter_ca/certs/inter.cert.pem: OK

6.9. 创建证书链

当应用程序（例如 Web 浏览器）尝试验证由中间 CA 签名的证书时，它还必须对照根证书验证中间证书。要完成信任链，请创建一个 CA 证书链以呈现给应用程序。

1cat inter_ca/certs/inter.cert.pem certs/root.cert.pem > inter_ca/certs/ca-chain.cert.pem
2chmod 444 inter_ca/certs/ca-chain.cert.pem

7. 创建服务器证书

使用中间 CA 来为服务器签署证书。

7.1. 创建私钥

如果你正在创建一个用于 Web 服务器的加密对（例如，Apache），你需要在每次重新启动 Web 服务器时输入这个密码。你可能想省略 -aes256 选项来创建一个没有密码的密钥，虽然这样会导致安全性降低。

1$ openssl genrsa -out inter_ca/private/server.key.pem 2048
2Generating RSA private key, 2048 bit long modulus
3.......................................................................................+++
4....................................................................+++
5e is 65537 (0x010001)

7.2. 创建 CSR

 1$ openssl req -config inter_ca/openssl.cnf -key inter_ca/private/server.key.pem -new -sha256 -out inter_ca/csr/server.csr.pem
 2You are about to be asked to enter information that will be incorporated
 3into your certificate request.
 4What you are about to enter is what is called a Distinguished Name or a DN.
 5There are quite a few fields but you can leave some blank
 6For some fields there will be a default value,
 7If you enter '.', the field will be left blank.
 8-----
 9Country Name (2 letter code) [CN]:
10State or Province Name (full name) [Beijing]:
11Locality Name (eg, city) [Chaoyang]:
12Organization Name (eg, company) [the masses]:
13Organizational Unit Name (eg, section) []:
14Common Name (e.g. server FQDN or YOUR name) []:localhost
15Email Address []:
16
17Please enter the following 'extra' attributes
18to be sent with your certificate request
19A challenge password []:
20An optional company name []:

7.3. 验证 CSR

 1$ openssl req -text -noout -verify -in inter_ca/csr/server.csr.pem
 2verify OK
 3Certificate Request:
 4    Data:
 5        Version: 1 (0x0)
 6        Subject: C = CN, ST = Beijing, L = Chaoyang, O = the masses, CN = localhost
 7        Subject Public Key Info:
 8            Public Key Algorithm: rsaEncryption
 9                Public-Key: (2048 bit)
10                Modulus:
11                    00:bc:da:6d:7b:73:e1:bf:1a:8e:b2:32:d2:39:7f:
12                    e4:67:9e:a3:3c:f8:38:d9:45:13:75:26:22:c5:54:
13                    ae:9e:76:7a:f7:1a:91:c3:01:49:bc:8a:b3:8a:d6:
14                    6f:9c:f4:b7:0a:65:ac:cf:fa:f9:8d:07:2b:18:e4:
15                                        ...
16                    a0:cd:70:48:3e:11:e9:26:14:11:91:4c:36:5a:c6:
17                    ed:e4:19:14:77:32:e5:1b:64:a7:dc:8b:3f:3b:94:
18                    5f:ed:db:50:32:c8:2d:25:6b:bc:67:af:37:2e:80:
19                    80:77:df:04:66:e1:f6:8a:19:a1:94:37:ab:73:a1:
20                    57:73
21                Exponent: 65537 (0x10001)
22        Attributes:
23            a0:00
24    Signature Algorithm: sha256WithRSAEncryption
25         b9:12:34:af:a6:46:38:e7:2b:3f:01:79:d6:8c:20:3b:77:b8:
26         76:d2:1f:d3:5c:6b:b6:c0:15:f0:2d:90:30:80:46:a6:ae:69:
27         f8:21:f1:20:a8:c7:b7:52:73:22:0e:b3:cf:52:ba:2e:a5:02:
28         f6:72:e0:58:cc:28:36:ff:cf:9b:7e:49:6c:8d:06:da:90:05:
29                                   ...
30         a6:d4:4c:74:2b:8a:67:19:f0:8e:bc:b8:3d:3a:4b:75:00:36:
31         48:cd:9e:c1:a6:70:1e:b1:ec:b7:d1:bf:79:8a:88:fa:79:a3:
32         58:cd:9e:91

7.4. 创建证书

 1$ openssl ca -config inter_ca/openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in inter_ca/csr/server.csr.pem -out inter_ca/certs/server.cert.pem
 2Using configuration from inter_ca/openssl.cnf
 3Enter pass phrase for /home/root_ca/inter_ca/private/inter.key.pem:
 4Check that the request matches the signature
 5Signature ok
 6Certificate Details:
 7        Serial Number: 8192 (0x2000)
 8        Validity
 9            Not Before: Dec 22 12:17:44 2020 GMT
10            Not After : Jan  1 12:17:44 2022 GMT
11        Subject:
12            countryName               = CN
13            stateOrProvinceName       = Beijing
14            localityName              = Chaoyang
15            organizationName          = the masses
16            commonName                = localhost
17        X509v3 extensions:
18            X509v3 Basic Constraints:
19                CA:FALSE
20            X509v3 Subject Key Identifier:
21                6B:F6:40:0A:6D:93:7C:A2:23:19:E3:6A:7B:DF:DF:6D:5F:63:49:EF
22            X509v3 Authority Key Identifier:
23                keyid:4E:ED:71:D7:0E:F5:67:42:78:57:6B:77:DB:D1:0F:69:65:81:E2:40
24                DirName:/C=CN/ST=Beijing/L=Chaoyang/O=the masses/CN= cyqz_Root
25                serial:10:00
26
27            X509v3 Key Usage: critical
28                Digital Signature, Key Encipherment
29            X509v3 Extended Key Usage:
30                TLS Web Server Authentication
31Certificate is to be certified until Jan  1 12:17:44 2022 GMT (375 days)
32Sign the certificate? [y/n]:y
33
34
351 out of 1 certificate requests certified, commit? [y/n]y
36Write out database with 1 new entries
37Data Base Updated

7.5. 验证证书

 1$ openssl x509 -noout -text -in inter_ca/certs/server.cert.pem
 2Certificate:
 3    Data:
 4        Version: 3 (0x2)
 5        Serial Number: 8192 (0x2000)
 6    Signature Algorithm: sha256WithRSAEncryption
 7        Issuer: C = CN, ST = Beijing, O = the masses, CN = cyqz_Inter
 8        Validity
 9            Not Before: Dec 22 12:17:44 2020 GMT
10            Not After : Jan  1 12:17:44 2022 GMT
11        Subject: C = CN, ST = Beijing, L = Chaoyang, O = the masses, CN = localhost
12        Subject Public Key Info:
13            Public Key Algorithm: rsaEncryption
14                Public-Key: (2048 bit)
15                Modulus:
16                    00:bc:da:6d:7b:73:e1:bf:1a:8e:b2:32:d2:39:7f:
17                    e4:67:9e:a3:3c:f8:38:d9:45:13:75:26:22:c5:54:
18                    ae:9e:76:7a:f7:1a:91:c3:01:49:bc:8a:b3:8a:d6:
19                    6f:9c:f4:b7:0a:65:ac:cf:fa:f9:8d:07:2b:18:e4:
20                                      ...
21                    ed:e4:19:14:77:32:e5:1b:64:a7:dc:8b:3f:3b:94:
22                    5f:ed:db:50:32:c8:2d:25:6b:bc:67:af:37:2e:80:
23                    80:77:df:04:66:e1:f6:8a:19:a1:94:37:ab:73:a1:
24                    57:73
25                Exponent: 65537 (0x10001)
26        X509v3 extensions:
27            X509v3 Basic Constraints:
28                CA:FALSE
29            X509v3 Subject Key Identifier:
30                6B:F6:40:0A:6D:93:7C:A2:23:19:E3:6A:7B:DF:DF:6D:5F:63:49:EF
31            X509v3 Authority Key Identifier:
32                keyid:4E:ED:71:D7:0E:F5:67:42:78:57:6B:77:DB:D1:0F:69:65:81:E2:40
33                DirName:/C=CN/ST=Beijing/L=Chaoyang/O=the masses/CN= cyqz_Root
34                serial:10:00
35
36            X509v3 Key Usage: critical
37                Digital Signature, Key Encipherment
38            X509v3 Extended Key Usage:
39                TLS Web Server Authentication
40    Signature Algorithm: sha256WithRSAEncryption
41         1c:4b:7b:16:c5:32:79:8c:f1:c4:1c:68:8d:17:02:7d:b6:f9:
42         ba:22:ca:f9:17:40:2d:3a:82:c7:ae:74:96:12:5b:9c:f8:0d:
43         03:c5:e7:fc:55:46:6c:92:f4:3f:91:24:66:ad:be:fb:73:d7:
44         d4:dc:fa:35:c5:d3:4d:97:7c:bb:45:94:24:d5:62:de:46:c4:
45         29:dd:9d:7b:90:ac:5b:29:ef:00:b8:58:e2:2e:fa:e8:27:d8:
46                              ...
47         70:56:96:fe:b3:6d:4b:2d:d6:6c:23:76:b4:fa:1b:7d:aa:e3:
48         41:15:91:cc:0c:f1:d0:05:39:11:ee:c7:f3:70:fc:91:35:1f:
49         97:bb:2d:59:2a:68:45:13:12:9a:a3:ce:01:f1:66:dc:f3:f6:
50         c2:2d:2b:cc:fd:5c:88:04:f1:ac:f3:07:52:09:55:d6:ac:f3:
51         e2:d1:33:d0:26:3f:40:7d

1$ openssl verify -CAfile inter_ca/certs/ca-chain.cert.pem inter_ca/certs/server.cert.pem
2inter_ca/certs/server.cert.pem: OK

8. 使用 CRL 吊销证书

编辑 /root_ca/inter_ca/openssl.cnf ，并在 server_cert 部分添加：

1crlDistributionPoints = URI:https://localhost/inter.crl.pem

8.1. 创建 CRL

1$ openssl ca -config inter_ca/openssl.cnf -gencrl -out inter_ca/crl/inter.crl.pem
2Using configuration from inter_ca/openssl.cnf
3Enter pass phrase for /home/root_ca/inter_ca/private/inter.key.pem:

检查内容：

 1$ openssl crl -in inter_ca/crl/inter.crl.pem -noout -text
 2Certificate Revocation List (CRL):
 3        Version 2 (0x1)
 4    Signature Algorithm: sha256WithRSAEncryption
 5        Issuer: /C=CN/ST=Beijing/O=the masses/CN=cyqz_Inter
 6        Last Update: Dec 22 12:37:35 2020 GMT
 7        Next Update: Jan 21 12:37:35 2021 GMT
 8        CRL extensions:
 9            X509v3 CRL Number:
10                8192
11No Revoked Certificates.
12    Signature Algorithm: sha256WithRSAEncryption
13         55:78:44:16:c4:a6:15:f4:71:ad:e9:0b:9f:9f:72:a0:2a:8f:
14         96:67:8a:c2:7e:f4:49:ab:9f:34:73:b7:13:04:e0:b4:b0:60:
15         50:07:16:e3:d5:d9:61:cc:70:2f:6f:3d:91:fa:52:9b:96:96:
16         2d:93:7b:85:f4:4c:a0:b1:16:e1:a9:02:67:1d:0c:de:eb:44:
17                               ...
18         35:4a:3b:a7:2a:59:c6:78:99:5e:f3:54:9f:8a:af:2b:da:38:
19         a1:5a:3f:2c:65:86:56:02:3c:5e:f9:c1:f8:12:8d:41:d0:d8:
20         a3:2b:52:af:00:f2:52:93

此时还没有证书被吊销，接下来就创建一个证书并吊销它。

8.2. 吊销证书

8.2.1. 创建私钥

1$ openssl genrsa -out private/jack@jack.com.key.pem 2048
2Generating RSA private key, 2048 bit long modulus
3........................................................+++
4.....................................+++
5e is 65537 (0x010001)

8.2.2. 创建 CSR

 1$ mkdir csr
 2$ openssl req -config inter_ca/openssl.cnf -key private/jack@jack.com.key.pem -new -sha256 -out csr/jack@jack.com.csr.pem
 3You are about to be asked to enter information that will be incorporated
 4into your certificate request.
 5What you are about to enter is what is called a Distinguished Name or a DN.
 6There are quite a few fields but you can leave some blank
 7For some fields there will be a default value,
 8If you enter '.', the field will be left blank.
 9-----
10Country Name (2 letter code) [CN]:
11State or Province Name (full name) [Beijing]:
12Locality Name (eg, city) [Chaoyang]:
13Organization Name (eg, company) [the masses]:
14Organizational Unit Name (eg, section) []:
15Common Name (e.g. server FQDN or YOUR name) []:jack@jack.com
16Email Address []:
17
18Please enter the following 'extra' attributes
19to be sent with your certificate request
20A challenge password []:
21An optional company name []:

8.2.3. 创建证书

 1$ openssl ca -config inter_ca/openssl.cnf -extensions usr_cert -days 375 -notext -md sha256 -in csr/jack@jack.com.csr.pem -out certs/jack@jack.com.cert.pem
 2Using configuration from inter_ca/openssl.cnf
 3Enter pass phrase for /home/root_ca/inter_ca/private/inter.key.pem:
 4Check that the request matches the signature
 5Signature ok
 6Certificate Details:
 7        Serial Number: 8193 (0x2001)
 8        Validity
 9            Not Before: Dec 22 12:49:47 2020 GMT
10            Not After : Jan  1 12:49:47 2022 GMT
11        Subject:
12            countryName               = CN
13            stateOrProvinceName       = Beijing
14            localityName              = Chaoyang
15            organizationName          = the masses
16            commonName                = jack@jack.com
17        X509v3 extensions:
18            X509v3 Basic Constraints:
19                CA:FALSE
20            X509v3 Key Usage: critical
21                Digital Signature, Non Repudiation, Key Encipherment
22            Netscape Comment:
23                OpenSSL Generated Certificate
24            X509v3 Subject Key Identifier:
25                F9:43:1B:77:29:B4:5D:E3:69:C8:7F:09:71:94:CE:C8:91:24:6F:F9
26            X509v3 Authority Key Identifier:
27                keyid:4E:ED:71:D7:0E:F5:67:42:78:57:6B:77:DB:D1:0F:69:65:81:E2:40
28
29            X509v3 Extended Key Usage:
30                TLS Web Client Authentication, E-mail Protection
31Certificate is to be certified until Jan  1 12:49:47 2022 GMT (375 days)
32Sign the certificate? [y/n]:y
33
34
351 out of 1 certificate requests certified, commit? [y/n]y
36Write out database with 1 new entries
37Data Base Updated

8.2.4. 验证证书

1$ openssl verify -CAfile inter_ca/certs/ca-chain.cert.pem certs/jack@jack.com.cert.pem
2certs/jack@jack.com.cert.pem: OK

8.2.5. 查看 `index.txt`

1$ cat inter_ca/index.txt
2V   220101121744Z       2000    unknown /C=CN/ST=Beijing/L=Chaoyang/O=the masses/CN=localhost
3V   220101124947Z       2001    unknown /C=CN/ST=Beijing/L=Chaoyang/O=the masses/CN=jack@jack.com

8.2.6. 吊销证书

1$ openssl ca -config inter_ca/openssl.cnf -revoke certs/jack@jack.com.cert.pem
2Using configuration from inter_ca/openssl.cnf
3Enter pass phrase for /home/root_ca/inter_ca/private/inter.key.pem:
4Revoking Certificate 2001.
5Data Base Updated

8.2.7. 再次查看 `index.txt`

1$ openssl ca -config inter_ca/openssl.cnf -revoke certs/jack@jack.com.cert.pem
2Using configuration from inter_ca/openssl.cnf
3Enter pass phrase for /home/root_ca/inter_ca/private/inter.key.pem:
4Revoking Certificate 2001.
5Data Base Updated

此时证书已经被吊销

8.3. 重新创建 CRL

1$ openssl ca -config inter_ca/openssl.cnf -gencrl -out inter_ca/crl/inter.crl.pem
2Using configuration from inter_ca/openssl.cnf
3Enter pass phrase for /home/root_ca/inter_ca/private/inter.key.pem:

查看内容：

1$ cat inter_ca/index.txt
2V   220101121744Z      2000 unknown /C=CN/ST=Beijing/L=Chaoyang/O=the masses/CN=localhost
3R   220101124947Z   201222125325Z   2001    unknown /C=CN/ST=Beijing/L=Chaoyang/O=the masses/CN=jack@jack.com

吊销的证书会出现说明。