又菜又爱玩oh
获得徽章 1
#青训营笔记创作活动#
2月5日 Day25
今日学习：多级缓存的珠联璧合
尝到了集中式缓存的甜头之后，暖心的程序员们想到要彻底为数据库减压，将所有业务中需要频繁使用的数据全部同步存储到Redis中，然后业务使用的时候直接从Redis中获取相关数据，大大地减少了数据库的请求频次。但是改完上线之后，发现有些处理流程中并没有太大的性能提升。缘何如此？只因为对集中式缓存的过分滥用！分析发现这些流程的处理需要涉及大量的交互与数据整合逻辑，一个流程需要访问近乎30次Redis！虽然Redis的单次请求处理性能极高，甚至可以达到微秒级别的响应速度，但是每个流程里面几十次的网络IO交互，导致频繁的IO请求，以及线程的阻塞与唤醒切换交替，使得系统在线程上下文切换层面浪费巨大。
那么，要想破局，最常规的手段便是尝试降低对集中式缓存（如Redis）的请求数量，降低网络IO交互次数。而如何来降低呢？ —— 又回到了本地缓存！集中式缓存并非是分布式系统中提升性能的银弹，但我们可以将本地缓存与集中式缓存结合起来使用，取长补短，实现效果最大化
2月5日 Day25
今日学习：多级缓存的珠联璧合
尝到了集中式缓存的甜头之后，暖心的程序员们想到要彻底为数据库减压，将所有业务中需要频繁使用的数据全部同步存储到Redis中，然后业务使用的时候直接从Redis中获取相关数据，大大地减少了数据库的请求频次。但是改完上线之后，发现有些处理流程中并没有太大的性能提升。缘何如此？只因为对集中式缓存的过分滥用！分析发现这些流程的处理需要涉及大量的交互与数据整合逻辑，一个流程需要访问近乎30次Redis！虽然Redis的单次请求处理性能极高，甚至可以达到微秒级别的响应速度，但是每个流程里面几十次的网络IO交互，导致频繁的IO请求，以及线程的阻塞与唤醒切换交替，使得系统在线程上下文切换层面浪费巨大。
那么，要想破局，最常规的手段便是尝试降低对集中式缓存（如Redis）的请求数量，降低网络IO交互次数。而如何来降低呢？ —— 又回到了本地缓存！集中式缓存并非是分布式系统中提升性能的银弹，但我们可以将本地缓存与集中式缓存结合起来使用，取长补短，实现效果最大化
展开
评论
点赞
#青训营笔记创作活动#
2月4日 Day24
今日学习：设计秒杀系统需要注意的9个细节。
瞬时高并发
页面静态化
秒杀按钮
读多写少
缓存问题
库存问题
分布式锁
mq异步处理
如何限流？
详细内容都在一下链接文章中，文章讲的很好内容丰富，也很细节，提到了很多知识，会让我们对高并发设计秒杀系统有了更多理解
2月4日 Day24
今日学习：设计秒杀系统需要注意的9个细节。
瞬时高并发
页面静态化
秒杀按钮
读多写少
缓存问题
库存问题
分布式锁
mq异步处理
如何限流？
详细内容都在一下链接文章中，文章讲的很好内容丰富，也很细节，提到了很多知识，会让我们对高并发设计秒杀系统有了更多理解
展开
评论
点赞
#青训营笔记创作活动#
2月3日 Day23
今日学习： 能用公匙加密，却不能用公匙解密
大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定情况下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。
HTTPS相当于HTTP+TLS，目前主流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。
TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。
TLS四次握手背起来会挺难受的，建议关注三个随机数的流向，以此作为基础去理解，大概就能记下来了。
2月3日 Day23
今日学习： 能用公匙加密，却不能用公匙解密
大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定情况下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。
HTTPS相当于HTTP+TLS，目前主流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。
TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。
TLS四次握手背起来会挺难受的，建议关注三个随机数的流向，以此作为基础去理解，大概就能记下来了。
展开
评论
点赞
#青训营笔记创作活动#
2月2日 Day22
今日学习：redis中string的使用
Redis 底层实现了简单动态字符串的类型（Simple Dynamic String，SDS）来表示 String 类型。没有直接使用C语言定义的字符串类型。
SDS 实现相对于C语言String方式的提升
避免缓冲区移除。对字符修改时，可以根据 len 属性检查空间是否满足要求
获取字符串长度的复杂度较低
减少内存分配次数
兼容C字符串函数，可以重用C语言库的一部分函数
2月2日 Day22
今日学习：redis中string的使用
Redis 底层实现了简单动态字符串的类型（Simple Dynamic String，SDS）来表示 String 类型。没有直接使用C语言定义的字符串类型。
SDS 实现相对于C语言String方式的提升
避免缓冲区移除。对字符修改时，可以根据 len 属性检查空间是否满足要求
获取字符串长度的复杂度较低
减少内存分配次数
兼容C字符串函数，可以重用C语言库的一部分函数
展开
评论
点赞
#青训营笔记创作活动#
2月1日 Day21
今日学习：MySQL索引的创建方式
MySQL索引的创建方式
①使用CREATE语句创建
CREATE INDEX indexName ON tableName (columnName(length) [ASC|DESC]);
这种创建方式可以给一张已存在的表结构添加索引，其中需要指定几个值：
indexName：当前创建的索引，创建成功后叫啥名字。
tableName：要在哪张表上创建一个索引，这里指定表名。
columnName：要为表中的哪个字段创建索引，这里指定字段名。
length：如果字段存储的值过长，选用值的前多少个字符创建索引。
ASC|DESC：指定索引的排序方式，ASC是升序，DESC是降序，默认ASC。
当然，上述语句中的INDEX也可更改为KEY，作用都是创建一个普通索引，而对于其他的索引类型，这点在后续的索引分类中再聊。
②使用ALTER语句创建
ALTER TABLE tableName ADD INDEX indexName(columnName(length) [ASC|DESC]);
这里的参数都相同，所以不再重复赘述。
③建表时DDL语句中创建
CREATE TABLE tableName(
columnName1 INT(8) NOT NULL,
columnName2 ....,
.....,
INDEX [indexName] (columnName(length))
);
这种方式就比较适合在库表设计时，已经确定了索引项的情况下建立。
2月1日 Day21
今日学习：MySQL索引的创建方式
MySQL索引的创建方式
①使用CREATE语句创建
CREATE INDEX indexName ON tableName (columnName(length) [ASC|DESC]);
这种创建方式可以给一张已存在的表结构添加索引，其中需要指定几个值：
indexName：当前创建的索引，创建成功后叫啥名字。
tableName：要在哪张表上创建一个索引，这里指定表名。
columnName：要为表中的哪个字段创建索引，这里指定字段名。
length：如果字段存储的值过长，选用值的前多少个字符创建索引。
ASC|DESC：指定索引的排序方式，ASC是升序，DESC是降序，默认ASC。
当然，上述语句中的INDEX也可更改为KEY，作用都是创建一个普通索引，而对于其他的索引类型，这点在后续的索引分类中再聊。
②使用ALTER语句创建
ALTER TABLE tableName ADD INDEX indexName(columnName(length) [ASC|DESC]);
这里的参数都相同，所以不再重复赘述。
③建表时DDL语句中创建
CREATE TABLE tableName(
columnName1 INT(8) NOT NULL,
columnName2 ....,
.....,
INDEX [indexName] (columnName(length))
);
这种方式就比较适合在库表设计时，已经确定了索引项的情况下建立。
展开
评论
点赞
#青训营笔记创作活动#
1月31日 Day20
今日学习：引入索引机制后，能够给数据库带来的优势
引入索引机制后，能够给数据库带来的优势很明显：
①整个数据库中，数据表的查询速度直线提升，数据量越大时效果越明显。
②通过创建唯一索引，可以确保数据表中的数据唯一性，无需额外建立唯一约束。
③在使用分组和排序时，同样可以显著减少SQL查询的分组和排序的时间。
④连表查询时，基于主外键字段上建立索引，可以带来十分明显的性能提升。
⑤索引默认是B+Tree有序结构，基于索引字段做范围查询时，效率会明显提高。
⑥从MySQL整体架构而言，减少了查询SQL的执行时间，提高了数据库整体吞吐量。
。
1月31日 Day20
今日学习：引入索引机制后，能够给数据库带来的优势
引入索引机制后，能够给数据库带来的优势很明显：
①整个数据库中，数据表的查询速度直线提升，数据量越大时效果越明显。
②通过创建唯一索引，可以确保数据表中的数据唯一性，无需额外建立唯一约束。
③在使用分组和排序时，同样可以显著减少SQL查询的分组和排序的时间。
④连表查询时，基于主外键字段上建立索引，可以带来十分明显的性能提升。
⑤索引默认是B+Tree有序结构，基于索引字段做范围查询时，效率会明显提高。
⑥从MySQL整体架构而言，减少了查询SQL的执行时间，提高了数据库整体吞吐量。
。
展开
评论
点赞
#青训营笔记创作活动#
1月30日 Day19
今日学习:可视化平台搭建
先学习一下Bytebase
Bytebase是一款面向开发者的数据库变更管理工具，目前在Github上已有3.6K+Star。
它的主要特性如下：
SQL审核：具有一站式SQL审核面板，可以直观地看到数据库所有变更记录。
SQL建议：能自动检查SQL语句规范，额外提供GitHub Action和API接入方式。
SQL编辑器：可以在线管理及查看数据库表，支持语法的自动提示。
GitOps工作流：支持集成GitHub和GitLab，使用GitOps工作流进行数据库变更。
备份恢复：支持自动备份数据库及恢复数据。
然后根据以下链接，按粗周操作搭建出可视化平台，确实很方便
1月30日 Day19
今日学习:可视化平台搭建
先学习一下Bytebase
Bytebase是一款面向开发者的数据库变更管理工具，目前在Github上已有3.6K+Star。
它的主要特性如下：
SQL审核：具有一站式SQL审核面板，可以直观地看到数据库所有变更记录。
SQL建议：能自动检查SQL语句规范，额外提供GitHub Action和API接入方式。
SQL编辑器：可以在线管理及查看数据库表，支持语法的自动提示。
GitOps工作流：支持集成GitHub和GitLab，使用GitOps工作流进行数据库变更。
备份恢复：支持自动备份数据库及恢复数据。
然后根据以下链接，按粗周操作搭建出可视化平台，确实很方便
展开
评论
点赞
#青训营笔记创作活动#
1月29日 Day18
今日学习：临时表排序
临时表的排序是怎样的呢？
就是把需要排序的字段，放到sort buffer，排完就返回。在这里注意一点哈，排序分全字段排序和rowid排序
如果是全字段排序，需要查询返回的字段，都放入sort buffer，根据排序字段排完，直接返回
如果是rowid排序，只是需要排序的字段放入sort buffer，然后多一次回表操作，再返回。
2.9.2 group by可能会慢在哪里？
group by使用不当，很容易就会产生慢SQL问题。因为它既用到临时表，又默认用到排序。有时候还可能用到磁盘临时表。
如果执行过程中，会发现内存临时表大小到达了上限（控制这个上限的参数就是tmp_table_size），会把内存临时表转成磁盘临时表。
如果数据量很大，很可能这个查询需要的磁盘临时表，就会占用大量的磁盘空间。
1月29日 Day18
今日学习：临时表排序
临时表的排序是怎样的呢？
就是把需要排序的字段，放到sort buffer，排完就返回。在这里注意一点哈，排序分全字段排序和rowid排序
如果是全字段排序，需要查询返回的字段，都放入sort buffer，根据排序字段排完，直接返回
如果是rowid排序，只是需要排序的字段放入sort buffer，然后多一次回表操作，再返回。
2.9.2 group by可能会慢在哪里？
group by使用不当，很容易就会产生慢SQL问题。因为它既用到临时表，又默认用到排序。有时候还可能用到磁盘临时表。
如果执行过程中，会发现内存临时表大小到达了上限（控制这个上限的参数就是tmp_table_size），会把内存临时表转成磁盘临时表。
如果数据量很大，很可能这个查询需要的磁盘临时表，就会占用大量的磁盘空间。
展开
评论
点赞
#青训营笔记创作活动#
1月28日 Day17
今日学习：Mysql优化准则
SQL语句的执行过程，实际上也就是MySQL的架构中一层层对其进行处理，慢慢掌握知识，一步一步走远
MySQL优化器的一些优化准则如下：
❶多条件查询时，重排条件先后顺序，将效率更好的字段条件放在前面。
❷当表中存在多个索引时，选择效率最高的索引作为本次查询的目标索引。
❸使用分页Limit关键字时，查询到对应的数据条数后终止扫表。
❹多表join联查时，对查询表的顺序重新定义，同样以效率为准。
❺对于SQL中使用函数时，如count()、max()、min()...，根据情况选择最优方案。
max()函数：走B+树最右侧的节点查询（大的在右，小的在左）。
min()函数：走B+树最左侧的节点查询。
count()函数：如果是MyISAM引擎，直接获取引擎统计的总行数。
......
❻对于group by分组排序，会先查询所有数据后再统一排序，而不是一开始就排序。
❼......
1月28日 Day17
今日学习：Mysql优化准则
SQL语句的执行过程，实际上也就是MySQL的架构中一层层对其进行处理，慢慢掌握知识，一步一步走远
MySQL优化器的一些优化准则如下：
❶多条件查询时，重排条件先后顺序，将效率更好的字段条件放在前面。
❷当表中存在多个索引时，选择效率最高的索引作为本次查询的目标索引。
❸使用分页Limit关键字时，查询到对应的数据条数后终止扫表。
❹多表join联查时，对查询表的顺序重新定义，同样以效率为准。
❺对于SQL中使用函数时，如count()、max()、min()...，根据情况选择最优方案。
max()函数：走B+树最右侧的节点查询（大的在右，小的在左）。
min()函数：走B+树最左侧的节点查询。
count()函数：如果是MyISAM引擎，直接获取引擎统计的总行数。
......
❻对于group by分组排序，会先查询所有数据后再统一排序，而不是一开始就排序。
❼......
展开
评论
点赞
#青训营笔记创作活动#
1月27日 Day16
今日学习：502错误怎么办
HTTP状态码用来表示响应结果的状态，其中200是正常响应，4xx是客户端错误，5xx是服务端错误。
客户端和服务端之间加入nginx，可以起到反向代理和负载均衡的作用，客户端只管向nginx请求数据，并不关心这个请求具体由哪个服务器来处理。
后端服务端应用如果发生崩溃，nginx在访问服务端时会收到服务端返回的RST报文，然后给客户端返回502报错。502并不是服务端应用发出的，而是nginx发出的。因此发生502时，后端服务端很可能没有没有相关的502日志，需要在nginx侧才能看到这条502日志。
如果发现502，优先通过监控排查服务端应用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他原因导致进程主动退出。如果进程也没崩溃过，去排查下nginx的日志，看下是否将请求打到了某个不知名IP端口上。
1月27日 Day16
今日学习：502错误怎么办
HTTP状态码用来表示响应结果的状态，其中200是正常响应，4xx是客户端错误，5xx是服务端错误。
客户端和服务端之间加入nginx，可以起到反向代理和负载均衡的作用，客户端只管向nginx请求数据，并不关心这个请求具体由哪个服务器来处理。
后端服务端应用如果发生崩溃，nginx在访问服务端时会收到服务端返回的RST报文，然后给客户端返回502报错。502并不是服务端应用发出的，而是nginx发出的。因此发生502时，后端服务端很可能没有没有相关的502日志，需要在nginx侧才能看到这条502日志。
如果发现502，优先通过监控排查服务端应用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他原因导致进程主动退出。如果进程也没崩溃过，去排查下nginx的日志，看下是否将请求打到了某个不知名IP端口上。
展开
评论
点赞
#青训营笔记创作活动#
1月26日 Day15
今日学习： 后端开发好习惯
注释尽可能全面,写有意义的方法注释
.项目拆分合理的目录结构
不在循环里远程调用、或者数据库操作，优先考虑批量进行
封装方法形参
封装通用模板
封装复杂的逻辑判断条件
保持优化性能的嗅觉
可变参数的配置化处理
会总结并使用工具类
控制方法函数复杂度
在finally块中对资源进行释放
把日志打印好
考虑异常，处理好异常
考虑系统、接口的兼容性
代码采取措施避免运行时错误
以上是内容的大体总结，更多详细内容都在下方链接文章中，我们在这里可以学到更多知识，博主准备的很细节，很充分，
1月26日 Day15
今日学习： 后端开发好习惯
注释尽可能全面,写有意义的方法注释
.项目拆分合理的目录结构
不在循环里远程调用、或者数据库操作，优先考虑批量进行
封装方法形参
封装通用模板
封装复杂的逻辑判断条件
保持优化性能的嗅觉
可变参数的配置化处理
会总结并使用工具类
控制方法函数复杂度
在finally块中对资源进行释放
把日志打印好
考虑异常，处理好异常
考虑系统、接口的兼容性
代码采取措施避免运行时错误
以上是内容的大体总结，更多详细内容都在下方链接文章中，我们在这里可以学到更多知识，博主准备的很细节，很充分，
展开
评论
点赞
#青训营笔记创作活动#
1月25日 Day14
今日学习：网络原理学习
从单机到互联：本质是通信问题
数据传输方式：电路交换、报文交换、分组交换
结点&链路（node）： 从计算机、集线器，交换机、路由器
网络的边界：个人区域网、局域网、城域网、广域网、互联网
慢慢的学习更多基础知识，更有利于我们对未来编程的理解，更能帮助我们成长，博主用到的方法非常好，网络原理倒着看，更能帮助我们理解其实的知识！
1月25日 Day14
今日学习：网络原理学习
从单机到互联：本质是通信问题
数据传输方式：电路交换、报文交换、分组交换
结点&链路（node）： 从计算机、集线器，交换机、路由器
网络的边界：个人区域网、局域网、城域网、广域网、互联网
慢慢的学习更多基础知识，更有利于我们对未来编程的理解，更能帮助我们成长，博主用到的方法非常好，网络原理倒着看，更能帮助我们理解其实的知识！
展开
评论
点赞
赞了这篇文章
#青训营笔记创作活动#
1月24日 Day13
今日学习: Mysql
MySQL的这个架构往下走。
连接层：主要是指数据库连接池，会负责处理所有客户端接入的工作。
服务层：主要包含SQL接口、解析器、优化器以及缓存缓冲区四块区域。
存储引擎层：这里是指MySQL支持的各大存储引擎，如InnoDB、MyISAM等。
文件系统层：涵盖了所有的日志，以及数据、索引文件，位于系统硬盘上。
SQL接口组件，这个名词听上去似乎不太容易理解，其实主要作用就是负责处理客户端的SQL语句，当客户端连接建立成功之后，会接收客户端的SQL命令，比如DML、DDL语句以及存储过程、触发器等，当收到SQL语句时，SQL接口会将其分发给其他组件，然后等待接收执行结果的返回，最后会将其返回给客户端。
解析器
客户端连接发送的SQL语句，经过SQL接口后会被分发到解析器，解析器这东西其实在所有语言中都存在，Java、C、Go...等其他语言都有，解析器的作用主要是做词法分析、语义分析、语法树生成...这类工作的，如果对于这个具体过程感兴趣，可以参考之前的《JVM-执行引擎子系统-Javac编译过程》，Java源码在编写后，会经历这个过程，SQL语言同样类似。
1月24日 Day13
今日学习: Mysql
MySQL的这个架构往下走。
连接层：主要是指数据库连接池，会负责处理所有客户端接入的工作。
服务层：主要包含SQL接口、解析器、优化器以及缓存缓冲区四块区域。
存储引擎层：这里是指MySQL支持的各大存储引擎，如InnoDB、MyISAM等。
文件系统层：涵盖了所有的日志，以及数据、索引文件，位于系统硬盘上。
SQL接口组件，这个名词听上去似乎不太容易理解，其实主要作用就是负责处理客户端的SQL语句，当客户端连接建立成功之后，会接收客户端的SQL命令，比如DML、DDL语句以及存储过程、触发器等，当收到SQL语句时，SQL接口会将其分发给其他组件，然后等待接收执行结果的返回，最后会将其返回给客户端。
解析器
客户端连接发送的SQL语句，经过SQL接口后会被分发到解析器，解析器这东西其实在所有语言中都存在，Java、C、Go...等其他语言都有，解析器的作用主要是做词法分析、语义分析、语法树生成...这类工作的，如果对于这个具体过程感兴趣，可以参考之前的《JVM-执行引擎子系统-Javac编译过程》，Java源码在编写后，会经历这个过程，SQL语言同样类似。
展开
评论
1
#青训营笔记创作活动#
1月22日 Day12
今日学习：TLS四次握手
TLS四次握手
第一次握手：
Client Hello：是客户端告诉服务端，它支持什么样的加密协议版本，比如 TLS1.2，使用什么样的加密套件，比如最常见的RSA，同时还给出一个客户端随机数。
第二次握手：
Server Hello：服务端告诉客户端，服务器随机数 + 服务器证书 + 确定的加密协议版本（比如就是TLS1.2）。
第三次握手：
Client Key Exchange: 此时客户端再生成一个随机数，叫 pre_master_key 。从第二次握手的服务器证书里取出服务器公钥，用公钥加密 pre_master_key，发给服务器。
Change Cipher Spec: 客户端这边已经拥有三个随机数： 客户端随机数，服务器随机数和pre_master_key，用这三个随机数进行计算得到一个"会话秘钥"。此时客户端通知服务端，后面会用这个会话秘钥进行对称机密通信。
Encrypted Handshake Message：客户端会把迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给服务器做校验，此时客户端这边的握手流程就结束了，因此也叫Finished报文。
第四次握手：
Change Cipher Spec：服务端此时拿到客户端传来的 pre_master_key（虽然被服务器公钥加密过，但服务器有私钥，能解密获得原文），集齐三个随机数，跟客户端一样，用这三个随机数通过同样的算法获得一个"会话秘钥"。此时服务器告诉客户端，后面会用这个"会话秘钥"进行加密通信。
Encrypted Handshake Message：跟客户端的操作一样，将迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给客户端做校验，到这里，服务端的握手流程也结束了，因此这也叫Finished报文。
1月22日 Day12
今日学习：TLS四次握手
TLS四次握手
第一次握手：
Client Hello：是客户端告诉服务端，它支持什么样的加密协议版本，比如 TLS1.2，使用什么样的加密套件，比如最常见的RSA，同时还给出一个客户端随机数。
第二次握手：
Server Hello：服务端告诉客户端，服务器随机数 + 服务器证书 + 确定的加密协议版本（比如就是TLS1.2）。
第三次握手：
Client Key Exchange: 此时客户端再生成一个随机数，叫 pre_master_key 。从第二次握手的服务器证书里取出服务器公钥，用公钥加密 pre_master_key，发给服务器。
Change Cipher Spec: 客户端这边已经拥有三个随机数： 客户端随机数，服务器随机数和pre_master_key，用这三个随机数进行计算得到一个"会话秘钥"。此时客户端通知服务端，后面会用这个会话秘钥进行对称机密通信。
Encrypted Handshake Message：客户端会把迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给服务器做校验，此时客户端这边的握手流程就结束了，因此也叫Finished报文。
第四次握手：
Change Cipher Spec：服务端此时拿到客户端传来的 pre_master_key（虽然被服务器公钥加密过，但服务器有私钥，能解密获得原文），集齐三个随机数，跟客户端一样，用这三个随机数通过同样的算法获得一个"会话秘钥"。此时服务器告诉客户端，后面会用这个"会话秘钥"进行加密通信。
Encrypted Handshake Message：跟客户端的操作一样，将迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给客户端做校验，到这里，服务端的握手流程也结束了，因此这也叫Finished报文。
展开
评论
点赞
#青训营笔记创作活动#
1月21日，Day11
今日学习：如何写出优质代码
看了up辛苦整理的的文章。我意识到，写好代码并不简单，要写出漂亮规范的代码更有许多许多细节要去注意，注释，格式，等等，所以，要想写出真正好的代码，还是要静下心来认真学习
1月21日，Day11
今日学习：如何写出优质代码
看了up辛苦整理的的文章。我意识到，写好代码并不简单，要写出漂亮规范的代码更有许多许多细节要去注意，注释，格式，等等，所以，要想写出真正好的代码，还是要静下心来认真学习
展开
评论
点赞
赞了这篇文章