mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-16 18:10:13 +08:00
[docs fix]修复&完善部分内容
This commit is contained in:
parent
4d09f56304
commit
b59f2cc30a
@ -109,7 +109,7 @@ SSL/TLS 介绍到这里,了解信息安全的朋友又会想到一个安全隐
|
||||
|
||||
#### 数字签名
|
||||
|
||||
好,到这一小节,已经是 SSL/TLS 的尾声了。上一小节提到了数字签名,数字签名要解决的问题,是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖,就是靠数字签名技术。
|
||||
好,到这一小节,已经是 SSL/TLS 的尾声了。上一小节提到了数字签名,数字签名要解决的问题,是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖,就是 **靠数字签名技术** 。
|
||||
|
||||
数字签名,是 CA 在给服务器颁发证书时,使用散列+加密的组合技术,在证书上盖个章,以此来提供验伪的功能。具体行为如下:
|
||||
|
||||
@ -121,24 +121,20 @@ SSL/TLS 介绍到这里,了解信息安全的朋友又会想到一个安全隐
|
||||
|
||||

|
||||
|
||||
注意,验证身份的证书一定是由 CA 的公钥进行签名,而不能由发送者自己来签名。这是为了抵抗以下的攻击场景:
|
||||
|
||||
> 攻击者使用某种手段,欺骗了客户端,将服务器的公钥替换为攻击者的诱饵公钥。
|
||||
>
|
||||
> 假使证书的签名使用的是服务器的私钥,那么客户端在解码的时候,将会使用假的服务器公钥(实则为诱饵公钥)。那么,如果该证书实则由攻击者(使用自己的私钥签名)发出,那么客户端就会成功验证(攻击者的)身份为真,从而信赖了证书中的公钥。
|
||||
>
|
||||
> 如果使用 CA 的私钥和公钥来对签名处理,则不会出现上述问题。
|
||||
|
||||
总结来说,带有证书的公钥传输机制如下:
|
||||
|
||||
1. 设有服务器 S,客户端 C,和第三方信赖机构 CA。
|
||||
2. S 信任 CA,CA 是知道 S 公钥的,CA 向 S 颁发证书。并附上 CA 私钥对消息摘要的加密签名。
|
||||
3. S 获得 CA 颁发的证书,将该证书传递给 C。
|
||||
4. C 获得 S 的证书,信任 CA 并知晓 CA 公钥,使用 CA 公钥对 S 证书山的签名解密,同时对消息进行散列处理,得到摘要。比较摘要,验证 S 证书的真实性。
|
||||
4. C 获得 S 的证书,信任 CA 并知晓 CA 公钥,使用 CA 公钥对 S 证书上的签名解密,同时对消息进行散列处理,得到摘要。比较摘要,验证 S 证书的真实性。
|
||||
5. 如果 C 验证 S 证书是真实的,则信任 S 的公钥(在 S 证书中)。
|
||||
|
||||

|
||||
|
||||
对于数字签名,我这里讲的比较简单,如果你没有搞清楚的话,强烈推荐你看看[数字签名及数字证书原理](https://www.bilibili.com/video/BV18N411X7ty/)这个视频,这是我看过最清晰的讲解。
|
||||
|
||||

|
||||
|
||||
## 总结
|
||||
|
||||
- **端口号** :HTTP 默认是 80,HTTPS 默认是 443。
|
||||
|
@ -136,7 +136,7 @@ tag:
|
||||
|
||||
👨💻**面试官** :**你知道什么是死锁吗?**
|
||||
|
||||
🙋 **我** :多个进程可以竞争有限数量的资源。当一个进程申请资源时,如果这时没有可用资源,那么这个进程进入等待状态。有时,如果所申请的资源被其他等待进程占有,那么该等待进程有可能再也无法改变状态。这种情况称为 **死锁**。
|
||||
🙋 **我** :死锁描述的是这样一种情况:多个进程/线程同时被阻塞,它们中的一个或者全部都在等待某个资源被释放。由于进程/线程被无限期地阻塞,因此程序不可能正常终止。
|
||||
|
||||
### 2.7 死锁的四个条件
|
||||
|
||||
|
@ -117,7 +117,7 @@ tag:
|
||||
|
||||
* drop(丢弃数据): `drop table 表名` ,直接将表都删除掉,在删除表的时候使用。
|
||||
* truncate (清空数据) : `truncate table 表名` ,只删除表中的数据,再插入数据的时候自增长 id 又从 1 开始,在清空表中数据的时候使用。
|
||||
* delete(删除数据) : `delete from 表名 where 列名=值`,删除某一列的数据,如果不加 where 子句和`truncate table 表名`作用类似。
|
||||
* delete(删除数据) : `delete from 表名 where 列名=值`,删除某一行的数据,如果不加 where 子句和`truncate table 表名`作用类似。
|
||||
|
||||
truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据,但是 **truncate 和 delete 只删除数据不删除表的结构(定义),执行 drop 语句,此表的结构也会删除,也就是执行 drop 之后对应的表不复存在。**
|
||||
|
||||
|
@ -46,7 +46,7 @@ Paxos是第一个被证明完备的共识算法(前提是不存在拜占庭将
|
||||
|
||||
针对存在恶意节点的情况,一般使用的是工作量证明(POW,Proof-of-Work)、权益证明(PoS,Proof-of-Stake )等共识算法。这类共识算法最典型的应用就是区块链,就比如说前段时间以太坊官方宣布其共识机制正在从工作量证明(PoW)转变为权益证明(PoS)。
|
||||
|
||||
区块链系统使用的共识算法需要解决的核心问题是 **拜占庭将军问题** ,这和和我们日常接触到的 ZooKeeper、Etcd、Consul 等分布式中间件不太一样。
|
||||
区块链系统使用的共识算法需要解决的核心问题是 **拜占庭将军问题** ,这和我们日常接触到的 ZooKeeper、Etcd、Consul 等分布式中间件不太一样。
|
||||
|
||||
下面我们来对 Paxos 算法的定义做一个总结:
|
||||
|
||||
|
@ -266,7 +266,15 @@ public final class String implements java.io.Serializable, Comparable<String>, C
|
||||
>
|
||||
> 相关阅读:[如何理解 String 类型值的不可变? - 知乎提问](https://www.zhihu.com/question/20618891/answer/114125846)
|
||||
>
|
||||
> 补充(来自[issue 675](https://github.com/Snailclimb/JavaGuide/issues/675)):在 Java 9 之后,`String` 、`StringBuilder` 与 `StringBuffer` 的实现改用 byte 数组存储字符串。
|
||||
> 补充(来自[issue 675](https://github.com/Snailclimb/JavaGuide/issues/675)):在 Java 9 之后,`String` 、`StringBuilder` 与 `StringBuffer` 的实现改用 `byte` 数组存储字符串。
|
||||
>
|
||||
> **Java 9 为何要将 `String` 的底层实现由 `char[]` 改成了 `byte[]` ?**
|
||||
>
|
||||
> 新版的 String 其实支持两个编码方案: Latin-1 和 UTF-16。如果字符串中包含的汉字没有超过 Latin-1 可表示范围内的字符,那就会使用 Latin-1 作为编码方案。Latin-1 编码方案下,`byte` 占一个字节(8位),`char` 占用2个字节(16),`byte` 相较 `char` 节省一半的内存空间。
|
||||
>
|
||||
> 如果字符串中包含的汉字超过 Latin-1 可表示范围内的字符,`byte` 和 `char` 所占用的空间是一样的。
|
||||
>
|
||||
> 这是官方的介绍:https://openjdk.java.net/jeps/254 。
|
||||
|
||||
`StringBuilder` 与 `StringBuffer` 都继承自 `AbstractStringBuilder` 类,在 `AbstractStringBuilder` 中也是使用字符数组保存字符串,不过没有使用 `final` 和 `private` 关键字修饰,最关键的是这个 `AbstractStringBuilder` 类还提供了很多修改字符串的方法比如 `append` 方法。
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user