" config.ini 配置中的 chain 配置说明可以参考 FISCO 官网
1. chain
我们可以看到在 chain 这个配置中有三个配置项 id, sm_crypto , sm_crypto_channel ，官网上也对这三个配置项做了说明。下面我们依次来讲解这三个配置项的作用
1.1 id
这个配置项很简单，实际应用中我们也不会涉及到修改这个配置项，保持默认即可
1.2 sm_crypto
这个配置项表示节点是否以国密方式启动。关于国密和非国密，这里不做过多解释，有兴趣的可以自行百度。
这个值是使用 build_chain.sh ( 这里以 build_chain.sh 为例 ) 生成节点的时候，指定是否生成国密节点来确定的，默认值是 false ，表示的是以非国密方式启动，那么如果我们希望以国密方式启动呢，只能重新生成新的链，无法通过直接修改来变更运行方式，可以参考 FISCO 官网 查看如何生成国密链。同时各位读者可以参考我的另一个文章 “FISCO BCOS 实战教程（三） build_chain.sh 搭链“ 了解使用 build_chain.sh 时，各个参数的使用说明。
1.3 sm_crypto_channel
这里假设各位读者已经根据 FISCO 官网 生成链一条国密链。这里我们使用 bash build_chain.sh -l 127.0.0.1:4 -p 30300,20200,8545 -g -G 生成链，然后并启动。
进入 fisco/nodes/127.0.0.1/node0 目录，查看 config.ini 文件。这里我们看到 sm_crypto_channel 为 true，表示 channel 连接方式为国密方式。 sm_crypto_channel 具体影响到客户端连接节点时使用的证书。下面我们来验证一下。
参考 FISCO 官网 配置下载 console 后，进行配置文件和证书配置。这里需要注意的是，官网中复制证书时，使用的命令是 "cp -r nodes/127.0.0.1/sdk/* console/conf/" ， 这里官网假设你是使用 "bash build_chain.sh -l 127.0.0.1:4 -p 30300,20200,8545 -g" 生成的节点，但实际上，我们上面用的命令是 "bash build_chain.sh -l 127.0.0.1:4 -p 30300,20200,8545 -g -G " ，这里多来一个 -G 。所以，复制证书的时候，我们不能直接使用官网上的命令，需要稍微修改下。
使用如下命令, 在 console/conf 目录下，创建 gm 目录，然后复制证书到 gm 目录下。至于为什么要创建 gm 目录，大家可以查看 console/conf/config.toml 这个文件。我们看到， gm 默认的证书路径为 conf/gm ，所以方便起见，这里我们就创建默认的 conf/gm 目录。
## 创建gm 目录
mkdir console/conf/gm
## 复制证书
cp sdk/gm/* console/conf/gm/
然后进入到 console 目录下，执行 ./start.sh 启动 console
如果启动失败，则需要 ps -ef|grep -i fisco 查看 fisco 进程是否启动。如果没有启动，进入到 nodes/127.0.0.1 目录，使用 ./start_all.sh 启动节点后，在次尝试启动 console。
好了，这里我们启动 console 成功，表示成功连接到节点了，下面我们来修改 sm_crypto_channel 参数，看看具体的效果。
进入 nodes/127.0.0.1/node0 目录，修改 config.ini 文件中 sm_crypto_channel=false。
然后重启 node0，看到 success 字样表示重启成功。
再次进入到 console/conf 目录，修改 peers=["127.0.0.1:20200"] 。这里说明下，默认的配置是 peers=["127.0.0.1:20200"，"127.0.0.1:20201"] ， 表示 console 会去尝试连接 node0 和 node1 ( 具体的连接说明可以查看我的 "FISCO BCOS 实战教程（四）config.ini 配置详解之 channel & rpc" ）。 但因为刚才我们只修改 node0 的配置，所以为了看到实验效果，这里配置 console 只连接 node0。
之后我们尝试启动 console, 连接失败了。这里我们看到，虽然我们在 console/conf/gm 目录下防止了证书，但却依然连接失败。让我们继续实验
使用如下命令，复制 sdk目录下的非国密证书到 console/conf 目录。
cp nodes/127.0.0.1/sdk/* console/conf
然后再次进入 console 目录，尝试启动 console。我们看到 console 启动成功了。这里不知道大家有没有注意到，我们在 console 目录下同时放置了国密和非国密的证书，那么 console 怎么知道用那个证书去连接节点呢？ 答案是，按个尝试去连接。console 首先会使用 conf 目录下的非国密证书去连接节点，如果成功，则连接成功，console 返回 "Welcome" 信息；如果连接失败，则继续使用 conf/gm 目录下的国密证书去尝试连接节点，如果连接成功，则返回 “Welcome" 信息； 如果两次尝试都失败，哦，console 就提示连接失败，返回连接失败的错误信息。
同时，我们可以注意到，我们只修改来 node0 的 sm_crypto_channel 的配置，node1/node2/node3 的配置并没有修改，这说明这个配置项对于每个节点是独立的，每个节点中的这个配置项是可以为不相同的。
另外，可能有人会问，如果我生成的是非国密的链，即节点中 sm_crypto 和 sm_cryto_channel 都是 false, 那么我可以修改节点的 sm_cryto_channel 为 true 吗？ 呵呵，如果你生的非国密的链，那么你的 sdk 目录中是没有 gm 这个目录的，所以就算你修改 sm_cryto_channel=true , 你也找不都国密的证书。
1.4 还原配置
做完实验来，记得还原 node0 中 config.ini 的 sm_crypto_channe=true , 然后重启 node0
2. compatibility
现在让我来继续看下一个配置。compatibility 配置项中只有一个 supported_version 配置项，这个配置项的作用是用于兼容升级的。以下图为例，现在配置为 2.7.2 ，表示我的 fisco-bcos 二进制版本为 2.7.2 , 那么后续如果 FISCO 官方继续开发了新版本的FISCO BCOS ，比如 2.9.0。如果 2.9.0 中对性能有很大提升，你也想用这个新版本，那么你就可以直接拿 2.9.0 的 fisco-bcos 二进制，替换当前节点上的 fisco-bcos 二进制，然后只需要重启节点，不用做任何修改，你的节点可以继续运行，当然 2.9.0 中所包含的新功能因为这个 supported_version 这个参数的原因是关闭的，你无法使用。如果你修改 supported_version 为 2.9.0 那么，会造成各种异常和不兼容，因为你的数据和配置文件还是 2.7.2 的。
所以，总结来说，这个配置项是对后续版本的 fisco-bcos 二进制来说的，已经运行的节点不能修改这个配置项，否则会出现各种异常。
3. log
这个配置项就很简单了，一眼就能明白作用，这里不做过多解释
4. flow_control
这个配置下面有两个配置项，limit_req 和 outgoing_bandwidth_limit。
4.1 outgoing_bandwidth_limit
outgoing_bandwidth_limit 这个配置项参考官网的说明进行理解。不容易进行模拟，这里就不进行演示，并且实际使用中，这个参数使用较少。
4.2 limit_req
比较有意思的参数是这个 limit_req, 用于限制节点接受的 QPS 。
首先，下载 java-sdk-demo （ 我们将使用这个工具发送 QPS ）
git clone https://github.com/FISCO-BCOS/java-sdk-demo.git
# 如果 git 访问很慢，可以访问 gitee
git clone https://gitee.com/FISCO-BCOS/java-sdk-demo
进入到 java-sdk-demo 目录，进行编译
进行文件配置， 这里的配置和 console 的配置一样，大家一样画葫芦就好了
cp java-sdk-demo/dist/config-example.toml config.toml
mkdir java-sdk-demo/dist/conf/gm
cp nodes/127.0.0.1/sdk/gm/* java-sdk-demo/dist/conf/gm
当然，这了 config.toml 文件我们需要修改下，配置 peers=["127.0.0.1:20200"] ， 只连接 node0
好了，准备工作就绪，我们来实验一下。进入 java-sdk-demo/dist 目录，执行如下命令
#调用格式：java -cp 'conf/:lib/*:apps/*' org.fisco.bcos.sdk.demo.perf.ParallelOkPerf parallelok [groupid] add [用户量] [QPS] [用户文件名]#调用样例java -cp 'conf/:lib/*:apps/*' org.fisco.bcos.sdk.demo.perf.ParallelOkPerf parallelok 1 add 5000 1000 user1
执行成功，我们看到这里最后输出 TPS 为 888 ，执行结果可能有细微差别，这里结果想近即可 。 TPS 和 QPS 的区别，大家可以百度下，因为这里我们是在本地执行，所以可以认为 QPS = TPS.
下面，进入 nodes/127.0.0.1/node0 ，修改 config.ini 为如下。打开 limit_req, 并设置为 100
然后重启 node0
再次进入 java-sdk-demo/dist 目录，执行如下命令
#调用格式： java -cp 'conf/:lib/*:apps/*' org.fisco.bcos.sdk.demo.perf.ParallelOkPerf parallelok [groupid] add [用户量] [QPS] [用户文件名] #调用样例 java -cp 'conf/:lib/*:apps/*' org.fisco.bcos.sdk.demo.perf.ParallelOkPerf parallelok 1 add 5000 1000 user1
这里我们查看最后的输出，注意到 “include error requests“ 结果为 950 ，接近 1000, 也就是我们发送的 QPS 速率。然后 “exclude error requests“ 为 129 , ， 就是我们设置的 node0 的 limit_req 值。那么总结下，就可以发现，当我们发送的 QPS 值超过节点设置的 limit_req 值时，多余的 QPS 消息，节点会返回拒绝，即处理失败。
这个值的使用场景是，当节点机器性能较差，当业务请求量较多（ 即 QPS ） 时，通过设置这个值，可以限制节点的处理速率。
4.3 还原配置
最后，记得还原 node0 的配置哦