DevOps文化 & SRE实战分享平台

0%

DotNet Windows and Docker SSL TLS证书问题分析排障


文章声明:此文基于木子实操撰写。
生产环境:Windows Server 2008 R2 Datacenter,runtime:3.1-alpine Docker
论证耗时:2h
撰文耗时:1h
校文耗时:30m
问题关键字:未能创建 SSL/TLS 安全通道,HandShake Failure,The SSL connection could not be established


问题说明

前几天运维同事反馈开发同事代码在Windows 2008 R2 Datacenter服务器上运行DotNet Framework程序出现无法正常建立SSL/TLS连接的情况,在自己的电脑上运行是OK的,代码也没有改过。于是我问他改了服务器上什么配置没有,他说改了注册表也不行。接过这个坑,心里万马奔腾,没事改注册表,这还能够回滚吗?这坑还可以越得过去吗?连忙问了一下,改注册表有记录吗?他说还在服务器桌面上,松了一口气,还可以回滚(后来回滚操作的时候发现他是直接从网上COPY的别人写的注册表文件,COPY过来的是乱码的,所以实际导入的都是错的……)。先根据对应注册表修改文件改回了注册表配置,重启服务器。

再通过DotNet Framework代码测试接口出现以下错误:

1
2
3
4
5
时间:2020-03-23 12:07:44 执行开始。。。
时间:2020-03-23 12:07:44 接口出现异常WebException:
Response报文:请求被中止: 未能创建 SSL/TLS 安全通道。
时间:2020-03-23 12:07:44 执行结束。。。
时间:2020-03-23 12:07:44 总耗时:428毫秒

排查错误

于是写了一个Python脚本测试了一把是正常的,又通过Chrome浏览器访问接口也可以正常响应(DotNet走的是IE浏览器相同的证书等级,即本身Windows系统支持的,而Chrome走的是自己的一套),但使用DotNet Framework写的代码就是不行。于是Google了一下,希望能够尽快解决问题,回复基本上都是修改DotNet代码,添加对于4.0对TLS1.2的支持,还有就是改注册表,开启TLS1.2的支持。前者我觉得是有可能的,根据微软官方信息显示DotNet Framework 4.0需要手动配置TLS1.2的支持才能够响应TLS1.2。
于是加了以下代码:

1
ServicePointManager.SecurityProtocol = (SecurityProtocolType)192 |(SecurityProtocolType)768 | (SecurityProtocolType)3072;

测试OK,OK问题解决了?找了另一台服务器一测试,还是不行。怎么可能一台服务器可以,另一台不行了?没有道理啊。本以为这个问题就这么简单就解决了,但实际结果并非如此,查看日志还是一样的报错Response报文:请求被中止: 未能创建 SSL/TLS 安全通道。看来只能够通过抓包解决问题了,于是分别在行与不行的服务器上安装了Wireshark,进行抓包对比分析。
先在正常服务器上抓包,从下图可以看到,是很正常的。

而在非正常的服务器上抓包,报错(因为在测试过程中,没有保存抓包数据,只记录了报错关键字):

1
Level: Fatal, Description: HandShake Failure

一般来说,这种错误是因为加密套件不匹配造成的,所以开始比较两台服务器之间加密套件的区别。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#因为没有截图保存,只导出了Cipher Suites进行比较,发现正常的服务器支持28种Cipher Suites,而非正常的服务器只支持21种Cipher Suites,相差7种Cipher Suites。
#非正常服务器
Cipher Suites (21 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
#正常服务器
Cipher Suites (28 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

再仔细查看了一下正常响应的服务器,在发送Server Hello时使用的加密套件(Cipher Suite)是:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

而非正常的服务器响应的是:TLS 1.2 Alert(Level: Fatal, Description:Handshake failure),从这里就可以很清楚的看到原因了,是因为客户端不支持Cipher Suite:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384造成的,所以HTTPS请求连接建立才会失败。

解决问题

找到问题,解决问题就简单了,Windows IIS Cipher Suites问题,我们可以通过IIS Crypto工具进行解决。下载工具IIS Crypto,然后查看当前服务器的加密套件:

我们会发现在这里面并没有证书支持的加密套件,于是我手动添加了证书所支持的加密套件,重启服务器。

实际上除了可以通过IIS Crypto工具可以添加加密套件外,还可以通过修改注册表进行操作,打开:计算机\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Functions 这里面的[数据]值,即当前系统添加的加密套件,默认排在最前的即为推荐的。

再请求对接接口,现在可以正常获取数据了。

1
2
3
4
5
6
7
8
9
时间:2020-03-23 14:55:30 执行开始。。。
时间:2020-03-23 14:55:45 {
"current_page": 1,
"data": [
{
"id": xxx,
"PID": "xxxx",
"totalCount": "0"
},

正常响应抓包:

扩展思考

怎么知道对应域名支持哪些加密套件了?

需要明确的一点是本身域名证书支持哪些加密套件是与对应服务端配置的Web服务器(Nginx、IIS、Tomcat…)的配置有关的。我们可以通过这个工具的Site Scanner,输入对应URL,然后点击[Scan],这时候会打开ssllabs,进行网站证书检测,我们可以拉到最后面,有一个[Cipher Suites]就可以看到对应的TLS 1.2加密套件支持。

这里我们可以看到此证书是支持5种加密套件的,而我们的服务器完美的错过了这5种加密套件,但也并非所有的服务器都错过了,所以出现有些服务器可以正常访问接口,有些服务器不正常。

还有一种方法,就是我们通过Chrome,按F12,选择Security,也可以查看到对应的安全连接设置。

或者通过nmap命令查看:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
~ » nmap -p 443 --script ssl-enum-ciphers www.oubayun.com
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-23 17:23 CST
Nmap scan report for www.oubayun.com (xxx.xxx.xxx.xxx)
Host is up (0.065s latency).

PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Key exchange (dh 2048) of lower strength than certificate key
| Key exchange (secp256r1) of lower strength than certificate key
|_ least strength: A

Nmap done: 1 IP address (1 host up) scanned in 18.84 seconds

另外还可以通过sslScan命令查看其它推荐的加密套件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
b~ » sslscan www.oubayun.com
Version: 1.11.13-static
OpenSSL 1.0.2f 28 Jan 2016

Connected to xxx.xxx.xxx.xxx

Testing SSL server www.oubayun.com on port 443 using SNI name www.oubayun.com

TLS Fallback SCSV:
Server supports TLS Fallback SCSV

TLS renegotiation:
Session renegotiation not supported

TLS Compression:
Compression disabled

Heartbleed:
TLS 1.2 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.0 not vulnerable to heartbleed

Supported Server Cipher(s):
#这里我们可以看到首选的是: ECDHE-RSA-AES256-GCM-SHA384
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 2048 bits

SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 4096

Subject: www.oubayun.com
Altnames: DNS:www.oubayun.com
Issuer: Let's Encrypt Authority X3

Not valid before: Feb 29 09:35:16 2020 GMT
Not valid after: May 29 09:35:16 2020 GMT

当然查看Cipher Suites的方法不仅仅只有这些,还有很多其它的方法。

怎么开启TLS 1.2支持?

这是我们也可以通过这个工具,点击Schannel,然后勾选TLS 1.2,选择Apply,再重启服务器即可。

TLS 1.2支持37种加密套件,但建议使用以下种类:

1
2
3
4
#Nginx设置
AESGCM+ECDH
ARIAGCM+ECDH
CHACHA20+ECDH

问题补充

2020年4月7日新增错误情况:
Alpine DotNet Runtime3.1 Docker 运行偶尔出现以下错误,请求对方API有时候可以请求成功,有时候报以下错误。

1
The SSL connection could not be established, see inner exception. Authentication failed because the remote party has closed the transport stream.!

解决方法:
本质原因还是因为生产环境对于证书的支持不全,当开发同事将SecurityProtocol设置成如下所示时,会发现在请求、响应采用Tls1.2的时候正常,采用Tls1.1或Tls1.0的时候就报上面的错误,解决方法即强制使用Tls1.2即可。

1
2
3
4
#原有配置
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
#修正后配置
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

2020年5月5日新增错误情况:
今天同事再报有部份Windows Server 2008 R2 Datacenter出现和上次同样的问题,本能反应木子查询对应域名支持的加密套件并添加至服务器,本想问题解决的,但实际并非那么回事。Scan对应域名,证书等级很高A+级。


在这里可以看到这个域名只支持TLS1.2,且支持的加密套件只有三个,如下所示:

1
2
3
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

回到上面的问题,为什么添加了加密套件还是不行了,其实是因为Windows Server 2008 R2 Datacenter本身不支持这三种加密套件(体质决定的),而这三种加密套件在Windows Server 2012 R2默认也是不支持的,需要更新系统补丁才能够支持。那回过头来问,Windows系统支持的加密套件,在哪里可以查询到了?我们可以通过以下链接查询:https://docs.microsoft.com/zh-cn/windows/win32/secauthn/cipher-suites-in-schannel
过程回放
我们来回放一下整个事件的过程,在添加了加密套件以后,再来进行抓包,我们可以看到客户端发起了一个Client Hello,并将自己支持的加密套件带过去了,总共28种,而这里面并没有我们添加的那三种。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Cipher Suites (28 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

Windows Server 2008 R2发送的:

这时候我们看Nginx服务器端的回复,如前面所述:HandShake Failure

实际上在整个ssllabs检测过程报告输出时,我们在[Handshake Simulation]模拟握手的过程中IE 11/Win 7、IE 11/Win 8.1是全军覆没的,而Win7对应Windows Server 2008 R2,而Win8.1对应的是Windows Server 2012 R2,所以这也是我们前面为什么说Windows Server 2012 R2也不支持的一个原因。

解决方法:
原因知道了,那解决这个问题的方法有两种:

  • 降级Nginx配置,满足Windows Server 2008 R2加密套件的支持需求。
  • 升级Windows Server 2008 R2至Windows Server 2012 R2及以上版本,建议支持Windows Server 2016起。

因为木子这里的API接口是从Kubernetes放出来的,本身来说我们是没有升级对应证书安全等级的,大概率是阿里云后台进行了安全级级别提升,这就需要我们自己去调整Kubernetes的nginx配置了。在对应命名空间kube-systemconfigmap中找到nginx-configuration,添加对应支持的加密套件与加密协议支持,详细如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: v1
data:
allow-backend-server-header: 'true'
enable-underscores-in-headers: 'true'
generate-request-id: 'true'
ignore-invalid-headers: 'true'
max-worker-connections: '65536'
proxy-body-size: 20m
proxy-connect-timeout: '10'
reuse-port: 'true'
server-tokens: 'false'
#加密套件支持
ssl-ciphers: >-
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
#加密协议支持
ssl-protocols: TLSv1 TLSv1.1 TLSv1.2
ssl-redirect: 'false'
worker-cpu-affinity: auto
kind: ConfigMap
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: >
{"apiVersion":"v1","data":{"allow-backend-server-header":"true","enable-underscores-in-headers":"true","generate-request-id":"true","ignore-invalid-headers":"true","max-worker-connections":"65536","proxy-body-size":"20m","proxy-connect-timeout":"10","reuse-port":"true","server-tokens":"false","ssl-redirect":"false","worker-cpu-affinity":"auto"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app":"ingress-nginx"},"name":"nginx-configuration","namespace":"kube-system"}}
creationTimestamp: '2019-04-27T07:37:55Z'
labels:
app: ingress-nginx
name: nginx-configuration
namespace: kube-system
resourceVersion: '4052397464'
selfLink: /api/v1/namespaces/kube-system/configmaps/nginx-configuration
uid: 5f3dd5c3-68bf-11e9-94e7-228aa24a1bc3

正常来说变更配置以后1分钟内生效,这时候我们再检测对应的证书安全等级及模拟握手支持,就会发现已经支持IE 11/Win7和IE 11/Win8.1了。

只是安全等级变更了B。

话说回来,目前国外的一些电商平台已经开始使用TLS 1.3,如:api.allegro.pl,虽然我们这里看到TLS1.1是支持的,但是我们会发现是黄色的,是因为在TLS1.1支持的加密套件中没有一个是被推荐的,也就是说安全等级是比较低的。所以升级我们的操作系统及DotNet Framework是有必要的。

坚持原创技术分享,您的支持与鼓励,是我持续创作的动力!