[docs fix]403图片修复

Author: Snailclimb

docs/about-the-author/my-article-was-stolen-and-made-into-video-and-it-became-popular.md

@@ -15,19 +15,19 @@ tag:
 
 麻烦这个培训机构看到这篇文章之后可以考虑换一个人做类似恶心的事情哈！这人完全没脑子啊！
 
-![](https://oscimg.oschina.net/oscnet/up-db6b9cf323930786fa2bec8b1e1bfaad732.png)
+![](https://oss.javaguide.cn/github/javaguide/about-the-author/up-db6b9cf323930786fa2bec8b1e1bfaad732.png)
 
-![](https://oscimg.oschina.net/oscnet/up-6395603ab441b74511c6eda28efee8937d7.png)
+![](https://oss.javaguide.cn/github/javaguide/about-the-author/up-6395603ab441b74511c6eda28efee8937d7.png)
 
-![](https://oscimg.oschina.net/oscnet/up-921f60a5c7cee2c5c2eb30f4f7048f648e1.png)
+![](https://oss.javaguide.cn/github/javaguide/about-the-author/up-921f60a5c7cee2c5c2eb30f4f7048f648e1.png)
 
-![](https://oscimg.oschina.net/oscnet/up-acc82a797bd01e27f5b7d5d327b32a21d4e.png)
+![](https://oss.javaguide.cn/github/javaguide/about-the-author/up-acc82a797bd01e27f5b7d5d327b32a21d4e.png)
 
 我随便找了一个视频看，发现也还是盗用别人的原创。
 
-![](https://oscimg.oschina.net/oscnet/up-48d0c5ab086265ae19b7396bc59de2c2daf.png)
+![](https://oss.javaguide.cn/github/javaguide/about-the-author/up-48d0c5ab086265ae19b7396bc59de2c2daf.png)
 
-![](https://oscimg.oschina.net/oscnet/up-366abf0656007ff96551064104e60740a41.png)
+![](https://oss.javaguide.cn/github/javaguide/about-the-author/up-366abf0656007ff96551064104e60740a41.png)
 
 其他的视频就不用多看了，是否还是剽窃别人的原创，原封不动地做成视频，大家心里应该有数。
 
@@ -49,7 +49,7 @@ tag:
 
 谁能想到，培训机构的人竟然找人来让我删文章了！讲真，这俩人是真的奇葩啊！
 
-![](https://oss.javaguide.cn/javaguide/8f8ccafcf5b764a2289a9c276c30728d.png)
+![](https://oss.javaguide.cn/github/javaguide/about-the-author/8f8ccafcf5b764a2289a9c276c30728d.png)
 
 ![](https://oss.javaguide.cn/javaguide/a0a4a45d7ec7b1a2622b2a38629e9b09.png)
 

docs/books/database.md

@@ -14,19 +14,19 @@ head:
 
 [《数据库系统原理》](https://www.icourse163.org/course/BNU-1002842007)这个课程的老师讲的非常详细，而且每一小节的作业设计的也与所讲知识很贴合，后面还有很多配套实验。
 
-![](https://oscimg.oschina.net/oscnet/up-e113c726a41874ef5fb19f7ac14e38e16ce.png)
+![](https://oss.javaguide.cn/github/javaguide/books/up-e113c726a41874ef5fb19f7ac14e38e16ce.png)
 
 如果你比较喜欢动手，对于理论知识比较抵触的话，推荐你看看[《如何开发一个简单的数据库》](https://cstack.github.io/db_tutorial/) ，这个 project 会手把手教你编写一个简单的数据库。
 
-![](https://oscimg.oschina.net/oscnet/up-11de8cb239aa7201cc8d78fa28928b9ec7d.png)
+![](https://oss.javaguide.cn/github/javaguide/books/up-11de8cb239aa7201cc8d78fa28928b9ec7d.png)
 
 GitHub 上也已经有大佬用 Java 实现过一个简易的数据库，介绍的挺详细的，感兴趣的朋友可以去看看。地址：[https://github.com/alchemystar/Freedom](https://github.com/alchemystar/Freedom) 。
 
 除了这个用 Java 写的之外，**[db_tutorial](https://github.com/cstack/db_tutorial)** 这个项目是国外的一个大佬用 C 语言写的，朋友们也可以去瞅瞅。
 
 **只要利用好搜索引擎，你可以找到各种语言实现的数据库玩具。**
 
-![](https://oscimg.oschina.net/oscnet/up-d32d853f847633ac7ed0efdecf56be1f1d2.png)
+![](https://oss.javaguide.cn/github/javaguide/books/up-d32d853f847633ac7ed0efdecf56be1f1d2.png)
 
 **纸上学来终觉浅 绝知此事要躬行！强烈推荐 CS 专业的小伙伴一定要多多实践！！！**
 
@@ -58,7 +58,7 @@ GitHub 上也已经有大佬用 Java 实现过一个简易的数据库，介绍
 - **[《高性能 MySQL》](https://book.douban.com/subject/23008813/)**：MySQL 领域的经典之作！学习 MySQL 必看！属于进阶内容，主要教你如何更好地使用 MySQL 。既有有理论，又有实践！如果你没时间都看一遍的话，我建议第 5 章（创建高性能的索引）、第 6 章（查询性能优化） 你一定要认真看一下。
 - **[《MySQL 技术内幕》](https://book.douban.com/subject/24708143/)**：你想深入了解 MySQL 存储引擎的话，看这本书准没错！
 
-![](https://oscimg.oschina.net/oscnet/up-3d31e762933f9e50cc7170b2ebd8433917b.png)
+![](https://oss.javaguide.cn/github/javaguide/books/up-3d31e762933f9e50cc7170b2ebd8433917b.png)
 
 视频的话，你可以看看动力节点的 [《MySQL 数据库教程视频》](https://www.bilibili.com/video/BV1fx411X7BD)。这个视频基本上把 MySQL 的相关一些入门知识给介绍完了。
 

docs/cs-basics/network/other-network-questions.md

@@ -206,7 +206,7 @@ HTTP 状态码用于描述 HTTP 请求的结果，比如 2xx 就代表请求被
 ![HTTP/2.0 和 HTTP/3.0 对比](https://oss.javaguide.cn/github/javaguide/cs-basics/network/http2.0-vs-http3.0.png)
 
 - **传输协议**：HTTP/2.0 是基于 TCP 协议实现的，HTTP/3.0 新增了 QUIC（Quick UDP Internet Connections） 协议来实现可靠的传输，提供与 TLS/SSL 相当的安全性，具有较低的连接和传输延迟。你可以将 QUIC 看作是 UDP 的升级版本，在其基础上新增了很多功能比如加密、重传等等。HTTP/3.0 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC。
-- **连接建立**：HTTP/2.0 需要经过经典的 TCP 三次握手过程（一般是 3 个 RTT）。由于 QUIC 协议的特性，HTTP/3.0 可以避免 TCP 三次握手的延迟，允许在第一次连接时发送数据（0 个 RTT ，零往返时间）。
+- **连接建立**：HTTP/2.0 需要经过经典的 TCP 三次握手过程（由于安全的 HTTPS 连接建立还需要 TLS 握手，共需要大约 3 个 RTT）。由于 QUIC 协议的特性（TLS 1.3，TLS 1.3 除了支持 1 个 RTT 的握手，还支持 0 个 RTT 的握手）连接建立仅需 0-RTT 或者 1-RTT。这意味着 QUIC 在最佳情况下不需要任何的额外往返时间就可以建立新连接。
 - **队头阻塞**：HTTP/2.0 多请求复用一个 TCP 连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。由于 QUIC 协议的特性，HTTP/3.0 在一定程度上解决了队头阻塞（Head-of-Line blocking, 简写：HOL blocking）问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。
 - **错误恢复**：HTTP/3.0 具有更好的错误恢复机制，当出现丢包、延迟等网络问题时，可以更快地进行恢复和重传。而 HTTP/2.0 则需要依赖于 TCP 的错误恢复机制。
 - **安全性**：HTTP/2.0 和 HTTP/3.0 在安全性上都有较高的要求，支持加密通信，但在实现上有所不同。HTTP/2.0 使用 TLS 协议进行加密，而 HTTP/3.0 基于 QUIC 协议，包含了内置的加密和身份验证机制，可以提供更强的安全性。
@@ -307,5 +307,7 @@ DNS 服务器自底向上可以依次分为以下几个层级(所有 DNS 服务
 
 - 《图解 HTTP》
 - 《计算机网络自顶向下方法》（第七版）
-- 详解 HTTP/2.0 及 HTTPS 协议：https://juejin.cn/post/7034668672262242318
-- HTTP 请求头字段大全| HTTP Request Headers：https://www.flysnow.org/tools/table/http-request-headers/
+- 详解 HTTP/2.0 及 HTTPS 协议：<https://juejin.cn/post/7034668672262242318>
+- HTTP 请求头字段大全| HTTP Request Headers：<https://www.flysnow.org/tools/table/http-request-headers/>
+- HTTP1、HTTP2、HTTP3：<https://juejin.cn/post/6855470356657307662>
+- 如何看待 HTTP/3 ？ - 车小胖的回答 - 知乎: <https://www.zhihu.com/question/302412059/answer/533223530>

docs/cs-basics/network/other-network-questions2.md

@@ -41,7 +41,18 @@ tag:
 
 ~~**HTTP 协议是基于 TCP 协议的**，所以发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。~~
 
-🐛 修正（参见 [issue#1915](https://github.com/Snailclimb/JavaGuide/issues/1915)）：HTTP/3.0 之前是基于 TCP 协议的，而 HTTP/3.0 将弃用 TCP，改用 **基于 UDP 的 QUIC 协议** 。此变化解决了 HTTP/2 中存在的队头阻塞问题。由于 HTTP/2 在单个 TCP 连接上使用了多路复用，受到 TCP 拥塞控制的影响，少量的丢包就可能导致整个 TCP 连接上的所有流被阻塞。另外，HTTP/2.0 需要经过经典的 TCP 三次握手过程（一般是 3 个 RTT）。由于 QUIC 协议的特性，HTTP/3.0 可以避免 TCP 三次握手的延迟，允许在第一次连接时发送数据（0 个 RTT ，零往返时间）。
+🐛 修正（参见 [issue#1915](https://github.com/Snailclimb/JavaGuide/issues/1915)）：
+
+HTTP/3.0 之前是基于 TCP 协议的，而 HTTP/3.0 将弃用 TCP，改用 **基于 UDP 的 QUIC 协议** 。
+
+此变化解决了 HTTP/2 中存在的队头阻塞问题。队头阻塞是指在 HTTP/2.0 中，多个 HTTP 请求和响应共享一个 TCP 连接，如果其中一个请求或响应因为网络拥塞或丢包而被阻塞，那么后续的请求或响应也无法发送，导致整个连接的效率降低。这是由于 HTTP/2.0 在单个 TCP 连接上使用了多路复用，受到 TCP 拥塞控制的影响，少量的丢包就可能导致整个 TCP 连接上的所有流被阻塞。HTTP/3.0 在一定程度上解决了队头阻塞问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。
+
+除了解决队头阻塞问题，HTTP/3.0 还可以减少握手过程的延迟。在 HTTP/2.0 中，如果要建立一个安全的 HTTPS 连接，需要经过 TCP 三次握手和 TLS 握手：
+
+1. TCP 三次握手：客户端和服务器交换 SYN 和 ACK 包，建立一个 TCP 连接。这个过程需要 1.5 个 RTT（round-trip time），即一个数据包从发送到接收的时间。
+2. TLS 握手：客户端和服务器交换密钥和证书，建立一个 TLS 加密层。这个过程需要至少 1 个 RTT（TLS 1.3）或者 2 个 RTT（TLS 1.2）。
+
+所以，HTTP/2.0 的连接建立就至少需要 2.5 个 RTT（TLS 1.3）或者 3.5 个 RTT（TLS 1.2）。而在 HTTP/3.0 中，使用的 QUIC 协议（TLS 1.3，TLS 1.3 除了支持 1 个 RTT 的握手，还支持 0 个 RTT 的握手）连接建立仅需 0-RTT 或者 1-RTT。这意味着 QUIC 在最佳情况下不需要任何的额外往返时间就可以建立新连接。
 
 相关证明可以参考下面这两个链接：
 
@@ -173,5 +184,5 @@ ARP 协议，全称 **地址解析协议（Address Resolution Protocol）**，
 
 - 《图解 HTTP》
 - 《计算机网络自顶向下方法》（第七版）
-- 什么是 Internet 协议（IP）？：https://www.cloudflare.com/zh-cn/learning/network-layer/internet-protocol/
-- What Is NAT and What Are the Benefits of NAT Firewalls?：https://community.fs.com/blog/what-is-nat-and-what-are-the-benefits-of-nat-firewalls.html
+- 什么是 Internet 协议（IP）？：<https://www.cloudflare.com/zh-cn/learning/network-layer/internet-protocol/>
+- What Is NAT and What Are the Benefits of NAT Firewalls?：<https://community.fs.com/blog/what-is-nat-and-what-are-the-benefits-of-nat-firewalls.html>

docs/distributed-system/api-gateway.md

@@ -40,7 +40,7 @@ category: 分布式
 
 下图来源于[百亿规模 API 网关服务 Shepherd 的设计与实现 - 美团技术团队 - 2021](https://mp.weixin.qq.com/s/iITqdIiHi3XGKq6u6FRVdg)这篇文章。
 
-![](https://oscimg.oschina.net/oscnet/up-35e102c633bbe8e0dea1e075ea3fee5dcfb.png)
+![](https://oss.javaguide.cn/github/javaguide/distributed-system/api-gateway/up-35e102c633bbe8e0dea1e075ea3fee5dcfb.png)
 
 ## 有哪些常见的网关系统？
 
@@ -50,7 +50,7 @@ Zuul 是 Netflix 开发的一款提供动态路由、监控、弹性、安全的
 
 Zuul 核心架构如下：
 
-![Zuul 核心架构](https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/api-gateway/zuul-core-architecture.webp)
+![Zuul 核心架构](https://oss.javaguide.cn/github/javaguide/distributed-system/api-gateway/zuul-core-architecture.webp)
 
 Zuul 主要通过过滤器（类似于 AOP）来过滤请求，从而实现网关必备的各种功能。
 
@@ -72,7 +72,7 @@ Zuul 主要通过过滤器（类似于 AOP）来过滤请求，从而实现网
 
 [Zuul 1.x](https://netflixtechblog.com/announcing-zuul-edge-service-in-the-cloud-ab3af5be08ee) 基于同步 IO，性能较差。[Zuul 2.x](https://netflixtechblog.com/open-sourcing-zuul-2-82ea476cb2b3) 基于 Netty 实现了异步 IO，性能得到了大幅改进。
 
-![Zuul2 架构](https://oscimg.oschina.net/oscnet/up-4f9047dc9109e27f9fced1b365e2b976e9d.png)
+![Zuul2 架构](https://oss.javaguide.cn/github/javaguide/distributed-system/api-gateway/zuul2-core-architecture.png)
 
 - GitHub 地址： <https://github.com/Netflix/zuul>
 - 官方 Wiki： <https://github.com/Netflix/zuul/wiki>
@@ -128,7 +128,7 @@ APISIX 是一款基于 Nginx 和 etcd 的高性能、云原生、可扩展的网
 
 与传统 API 网关相比，APISIX 具有动态路由和插件热加载，特别适合微服务系统下的 API 管理。并且，APISIX 与 SkyWalking（分布式链路追踪系统）、Zipkin（分布式链路追踪系统）、Prometheus（监控系统） 等 DevOps 生态工具对接都十分方便。
 
-![APISIX 架构图](https://oscimg.oschina.net/oscnet/up-cc6717d095705a584dd8daaaadb13c5c75b.png)
+![APISIX 架构图](https://oss.javaguide.cn/github/javaguide/distributed-system/api-gateway/apisix-architecture.png)
 
 作为 NGINX 和 Kong 的替代项目，APISIX 目前已经是 Apache 顶级开源项目，并且是最快毕业的国产开源项目。国内目前已经有很多知名企业（比如金山、有赞、爱奇艺、腾讯、贝壳）使用 APISIX 处理核心的业务流量。
 
@@ -141,7 +141,7 @@ APISIX 同样支持定制化的插件开发。开发者除了能够使用 Lua 
 
 > Wasm 是基于堆栈的虚拟机的二进制指令格式，一种低级汇编语言，旨在非常接近已编译的机器代码，并且非常接近本机性能。Wasm 最初是为浏览器构建的，但是随着技术的成熟，在服务器端看到了越来越多的用例。
 
-![](https://oscimg.oschina.net/oscnet/up-a240d3b113cde647f5850f4c7cc55d4ff5c.png)
+![](https://oss.javaguide.cn/github/javaguide/distributed-system/api-gateway/up-a240d3b113cde647f5850f4c7cc55d4ff5c.png)
 
 - Github 地址：<https://github.com/apache/apisix>
 - 官网地址： <https://apisix.apache.org/zh/>
@@ -157,7 +157,7 @@ APISIX 同样支持定制化的插件开发。开发者除了能够使用 Lua 
 
 Shenyu 是一款基于 WebFlux 的可扩展、高性能、响应式网关，Apache 顶级开源项目。
 
-![Shenyu 架构](https://oscimg.oschina.net/oscnet/up-1c2b39f22e5a0bb1730531429c4147bfbf8.png)
+![Shenyu 架构](https://oss.javaguide.cn/github/javaguide/distributed-system/api-gateway/shenyu-architecture.png)
 
 Shenyu 通过插件扩展功能，插件是 ShenYu 的灵魂，并且插件也是可扩展和热插拔的。不同的插件实现不同的功能。Shenyu 自带了诸如限流、熔断、转发、重写、重定向、和路由监控等插件。
 

docs/distributed-system/distributed-id.md

@@ -312,7 +312,7 @@ Leaf 的诞生主要是为了解决美团各个业务线生成分布式 ID 的
 
 Leaf 对原有的号段模式进行改进，比如它这里增加了双号段避免获取 DB 在获取号段的时候阻塞请求获取 ID 的线程。简单来说，就是我一个号段还没用完之前，我自己就主动提前去获取下一个号段（图片来自于美团官方文章：[《Leaf——美团点评分布式 ID 生成系统》](https://tech.meituan.com/2017/04/21/mt-leaf.html)）。
 
-![](https://oscimg.oschina.net/oscnet/up-5c152efed042a8fe7e13692e0339d577f5c.png)
+![](https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-id/leaf-principle.png)
 
 根据项目 README 介绍，在 4C8G VM 基础上，通过公司 RPC 方式调用，QPS 压测结果近 5w/s，TP999 1ms。
 
@@ -324,7 +324,7 @@ Leaf 对原有的号段模式进行改进，比如它这里增加了双号段避
 
 为了搞清楚这个问题，我们先来看看基于数据库号段模式的简单架构方案。（图片来自于 Tinyid 的官方 wiki:[《Tinyid 原理介绍》](https://github.com/didi/tinyid/wiki/tinyid%E5%8E%9F%E7%90%86%E4%BB%8B%E7%BB%8D)）
 
-![](https://oscimg.oschina.net/oscnet/up-4afc0e45c0c86ba5ad645d023dce11e53c2.png)
+![](https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-id/tinyid-principle.png)
 
 在这种架构模式下，我们通过 HTTP 请求向发号器服务申请唯一 ID。负载均衡 router 会把我们的请求送往其中的一台 tinyid-server。
 
@@ -337,7 +337,7 @@ Leaf 对原有的号段模式进行改进，比如它这里增加了双号段避
 
 Tinyid 的原理比较简单，其架构如下图所示：
 
-![](https://oscimg.oschina.net/oscnet/up-53f74cd615178046d6c04fe50513fee74ce.png)
+![](https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-id/tinyid-architecture-design.png)
 
 相比于基于数据库号段模式的简单架构方案，Tinyid 方案主要做了下面这些优化：
 

docs/distributed-system/protocol/gossip-protocl.md

@@ -38,7 +38,7 @@ NoSQL 数据库 Redis 和 Apache Cassandra、服务网格解决方案 Consul 等
 
 我们经常使用的分布式缓存 Redis 的官方集群解决方案（3.0 版本引入） Redis Cluster 就是基于 Gossip 协议来实现集群中各个节点数据的最终一致性。
 
-![](https://oscimg.oschina.net/oscnet/up-fcacc1eefca6e51354a5f1fc9f2919f51ec.png)
+![Redis 的官方集群解决方案](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/up-fcacc1eefca6e51354a5f1fc9f2919f51ec.png)
 
 Redis Cluster 是一个典型的分布式系统，分布式系统中的各个节点需要互相通信。既然要相互通信就要遵循一致的通信协议，Redis Cluster 中的各个节点基于 **Gossip 协议** 来进行通信共享信息，每个 Redis 节点都维护了一份集群的状态信息。
 
@@ -79,7 +79,7 @@ Gossip 设计了两种可能的消息传播模式：**反熵（Anti-Entropy）**
 
 伪代码如下：
 
-![](https://oscimg.oschina.net/oscnet/up-df16e98bf71e872a7e1f01ca31cee93d77b.png)
+![反熵伪代码](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/up-df16e98bf71e872a7e1f01ca31cee93d77b.png)
 
 在我们实际应用场景中，一般不会采用随机的节点进行反熵，而是需要可以的设计一个闭环。这样的话，我们能够在一个确定的时间范围内实现各个节点数据的最终一致性，而不是基于随机的概率。像 InfluxDB 就是这样来实现反熵的。
 

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

@@ -61,7 +61,7 @@ Basic Paxos 中存在 3 个重要的角色：
 2. **接受者（Acceptor）**：也可以叫做投票员（voter），负责对提议者的提案进行投票，同时需要记住自己的投票历史；
 3. **学习者（Learner）**：如果有超过半数接受者就某个提议达成了共识，那么学习者就需要接受这个提议，并就该提议作出运算，然后将运算结果返回给客户端。
 
-![](https://oscimg.oschina.net/oscnet/up-890fa3212e8bf72886a595a34654918486c.png)
+![](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/up-890fa3212e8bf72886a595a34654918486c.png)
 
 为了减少实现该算法所需的节点数，一个节点可以身兼多个角色。并且，一个提案被选定需要被半数以上的 Acceptor 接受。这样的话，Basic Paxos 算法还具备容错性，在少于一半的节点出现故障时，集群仍能正常工作。
 

docs/distributed-system/rpc/dubbo.md

@@ -456,4 +456,4 @@ Kryo 和 FST 这两种序列化方式是 Dubbo 后来才引入的，性能非常
 
 Dubbo 官方文档中还有一个关于这些[序列化协议的性能对比图](https://dubbo.apache.org/zh/docs/v2.7/user/serialization/#m-zhdocsv27userserialization)可供参考。
 
-![序列化协议的性能对比](https://oscimg.oschina.net/oscnet/up-00c3ce1e5d222e477ed84310239daa2f6b0.png)
+![序列化协议的性能对比](https://oss.javaguide.cn/github/javaguide/distributed-system/rpc/dubbo-serialization-protocol-performance-comparison.png)