Skip to content

Commit b59f2cc

Browse files
committed
[docs fix]修复&完善部分内容
1 parent 4d09f56 commit b59f2cc

File tree

5 files changed

+18
-14
lines changed

5 files changed

+18
-14
lines changed

docs/cs-basics/network/http&https.md

+6-10
Original file line numberDiff line numberDiff line change
@@ -109,7 +109,7 @@ SSL/TLS 介绍到这里,了解信息安全的朋友又会想到一个安全隐
109109

110110
#### 数字签名
111111

112-
好,到这一小节,已经是 SSL/TLS 的尾声了。上一小节提到了数字签名,数字签名要解决的问题,是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖,就是靠数字签名技术
112+
好,到这一小节,已经是 SSL/TLS 的尾声了。上一小节提到了数字签名,数字签名要解决的问题,是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖,就是 **靠数字签名技术**
113113

114114
数字签名,是 CA 在给服务器颁发证书时,使用散列+加密的组合技术,在证书上盖个章,以此来提供验伪的功能。具体行为如下:
115115

@@ -121,24 +121,20 @@ SSL/TLS 介绍到这里,了解信息安全的朋友又会想到一个安全隐
121121
122122
![](./images/http&https/digital-signature.png)
123123

124-
注意,验证身份的证书一定是由 CA 的公钥进行签名,而不能由发送者自己来签名。这是为了抵抗以下的攻击场景:
125-
126-
> 攻击者使用某种手段,欺骗了客户端,将服务器的公钥替换为攻击者的诱饵公钥。
127-
>
128-
> 假使证书的签名使用的是服务器的私钥,那么客户端在解码的时候,将会使用假的服务器公钥(实则为诱饵公钥)。那么,如果该证书实则由攻击者(使用自己的私钥签名)发出,那么客户端就会成功验证(攻击者的)身份为真,从而信赖了证书中的公钥。
129-
>
130-
> 如果使用 CA 的私钥和公钥来对签名处理,则不会出现上述问题。
131-
132124
总结来说,带有证书的公钥传输机制如下:
133125

134126
1. 设有服务器 S,客户端 C,和第三方信赖机构 CA。
135127
2. S 信任 CA,CA 是知道 S 公钥的,CA 向 S 颁发证书。并附上 CA 私钥对消息摘要的加密签名。
136128
3. S 获得 CA 颁发的证书,将该证书传递给 C。
137-
4. C 获得 S 的证书,信任 CA 并知晓 CA 公钥,使用 CA 公钥对 S 证书山的签名解密,同时对消息进行散列处理,得到摘要。比较摘要,验证 S 证书的真实性。
129+
4. C 获得 S 的证书,信任 CA 并知晓 CA 公钥,使用 CA 公钥对 S 证书上的签名解密,同时对消息进行散列处理,得到摘要。比较摘要,验证 S 证书的真实性。
138130
5. 如果 C 验证 S 证书是真实的,则信任 S 的公钥(在 S 证书中)。
139131

140132
![](./images/http&https/public-key-transmission.png)
141133

134+
对于数字签名,我这里讲的比较简单,如果你没有搞清楚的话,强烈推荐你看看[数字签名及数字证书原理](https://www.bilibili.com/video/BV18N411X7ty/)这个视频,这是我看过最清晰的讲解。
135+
136+
![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/image-20220321121814946.png)
137+
142138
## 总结
143139

144140
- **端口号** :HTTP 默认是 80,HTTPS 默认是 443。

docs/cs-basics/operating-system/operating-system-basic-questions-01.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -136,7 +136,7 @@ tag:
136136

137137
👨‍💻**面试官****你知道什么是死锁吗?**
138138

139-
🙋 ****多个进程可以竞争有限数量的资源。当一个进程申请资源时,如果这时没有可用资源,那么这个进程进入等待状态。有时,如果所申请的资源被其他等待进程占有,那么该等待进程有可能再也无法改变状态。这种情况称为 **死锁**
139+
🙋 ****死锁描述的是这样一种情况:多个进程/线程同时被阻塞,它们中的一个或者全部都在等待某个资源被释放。由于进程/线程被无限期地阻塞,因此程序不可能正常终止
140140

141141
### 2.7 死锁的四个条件
142142

docs/database/basis.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -117,7 +117,7 @@ tag:
117117

118118
* drop(丢弃数据): `drop table 表名` ,直接将表都删除掉,在删除表的时候使用。
119119
* truncate (清空数据) : `truncate table 表名` ,只删除表中的数据,再插入数据的时候自增长 id 又从 1 开始,在清空表中数据的时候使用。
120-
* delete(删除数据) : `delete from 表名 where 列名=值`删除某一列的数据,如果不加 where 子句和`truncate table 表名`作用类似。
120+
* delete(删除数据) : `delete from 表名 where 列名=值`删除某一行的数据,如果不加 where 子句和`truncate table 表名`作用类似。
121121

122122
truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据,但是 **truncate 和 delete 只删除数据不删除表的结构(定义),执行 drop 语句,此表的结构也会删除,也就是执行 drop 之后对应的表不复存在。**
123123

docs/distributed-system/theorem&algorithm&protocol/paxos-algorithm.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -46,7 +46,7 @@ Paxos是第一个被证明完备的共识算法(前提是不存在拜占庭将
4646

4747
针对存在恶意节点的情况,一般使用的是工作量证明(POW,Proof-of-Work)、权益证明(PoS,Proof-of-Stake )等共识算法。这类共识算法最典型的应用就是区块链,就比如说前段时间以太坊官方宣布其共识机制正在从工作量证明(PoW)转变为权益证明(PoS)。
4848

49-
区块链系统使用的共识算法需要解决的核心问题是 **拜占庭将军问题**这和和我们日常接触到的 ZooKeeper、Etcd、Consul 等分布式中间件不太一样。
49+
区块链系统使用的共识算法需要解决的核心问题是 **拜占庭将军问题**这和我们日常接触到的 ZooKeeper、Etcd、Consul 等分布式中间件不太一样。
5050

5151
下面我们来对 Paxos 算法的定义做一个总结:
5252

docs/java/basis/java-basic-questions-02.md

+9-1
Original file line numberDiff line numberDiff line change
@@ -266,7 +266,15 @@ public final class String implements java.io.Serializable, Comparable<String>, C
266266
>
267267
> 相关阅读:[如何理解 String 类型值的不可变? - 知乎提问](https://www.zhihu.com/question/20618891/answer/114125846)
268268
>
269-
> 补充(来自[issue 675](https://github.com/Snailclimb/JavaGuide/issues/675)):在 Java 9 之后,`String``StringBuilder``StringBuffer` 的实现改用 byte 数组存储字符串。
269+
> 补充(来自[issue 675](https://github.com/Snailclimb/JavaGuide/issues/675)):在 Java 9 之后,`String``StringBuilder``StringBuffer` 的实现改用 `byte` 数组存储字符串。
270+
>
271+
> **Java 9 为何要将 `String` 的底层实现由 `char[]` 改成了 `byte[]` ?**
272+
>
273+
> 新版的 String 其实支持两个编码方案: Latin-1 和 UTF-16。如果字符串中包含的汉字没有超过 Latin-1 可表示范围内的字符,那就会使用 Latin-1 作为编码方案。Latin-1 编码方案下,`byte` 占一个字节(8位),`char` 占用2个字节(16),`byte` 相较 `char` 节省一半的内存空间。
274+
>
275+
> 如果字符串中包含的汉字超过 Latin-1 可表示范围内的字符,`byte``char` 所占用的空间是一样的。
276+
>
277+
> 这是官方的介绍:https://openjdk.java.net/jeps/254
270278
271279
`StringBuilder``StringBuffer` 都继承自 `AbstractStringBuilder` 类,在 `AbstractStringBuilder` 中也是使用字符数组保存字符串,不过没有使用 `final``private` 关键字修饰,最关键的是这个 `AbstractStringBuilder` 类还提供了很多修改字符串的方法比如 `append` 方法。
272280

0 commit comments

Comments
 (0)