xiaolincoder / cs-base Goto Github PK

要是能做个按钮将左边的目录隐藏起来就更好了，在使用 ipad 阅读的时候左边的目录栏占据了一定的空间，导致无法全屏阅读文章的内容。

解析器会做如下两件事情。
第一件事情，词法分析。MySQL 会根据你输入的字符串识别出关键字出来，构建出 SQL 语法树，这样方便后面模块获取 SQL 类型、表名、字段名、 where 条件等等。
第二件事情，语法分析。根据词法分析的结果，语法解析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。

这里构建语法树其实应该是语法分析部分的工作? 编译原理里面 Parser 构建语法推导树这个过程事实上就是语法检查的过程吧。

https://xiaolincoding.com/mysql/lock/mysql_lock.html#%E5%85%A8%E5%B1%80%E9%94%81
mysql 锁这篇有错别字。文中多张数据库表的”更细"，应该是更新

原文给出的方法是“将 10.100.122.2 和 255.255.255.0 进行按位与运算，就可以得到网络号和主机号”
配图中显示主机号是“00000000”
但实际上主机号的计算方法应该是将子网掩码取反后与IP地址进行按位与运算
正确的主机号应该是“00000010”

我有个疑问，就是二级索引不存放实际数据，但是下面又说，如果查询的数据能在二级索引里查询的到，既然没有存放实际数据，那怎么能查询到的呢？

当 TCP 完成快速恢复后，在进入下一次拥塞避免前应该要调整 cwnd=ssthresh。

点击“使用GitHub登录”后，按照GitHub提示进行验证，此时重定向到源网站，提示正在初始化，稍后弹出“评论加载失败”错误
因此，我也不知道小林是咋登上去的……
截图传不上来

https://xiaolincoding.com/redis/cluster/sentinel.html

这篇文章里的 leeder 应该改为 leader 吧

./CS-Base/network/1_base/what_happen_url.md

如上，路径的图片引入地址拼写错误 hhttps--->https

原文1：事务隔离级别是怎么实现的？
文中“可重复读隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View。”

原文2：在MySQL 可重复读隔离级别，完全解决幻读了吗？
文中“在可重复读隔离级别下，事务 A 第一次执行普通的 select 语句时生成了一个 ReadView，之后事务 B 向表中新插入了一条 id = 5 的记录并提交。”

个人看法：
原文1和原文2的描述有冲突，
可重复读隔离级别Read View生成时机不是在事务启动后第一次执行普通的 select 语句时才生成的 Read View吗？

请教下：
在 https://xiaolincoding.com/mysql/lock/show_lock.html 的 “为什么会发生死锁” 一节中，提到了 time1 中，update 语句加的是“间隙锁”。这个锁为什么不是“记录锁”呢？

在 https://xiaolincoding.com/mysql/lock/update_index.html 的 “update 没加索引会锁全表” 一节中，提到了 “在 update 语句的 where 条件使用了唯一索引，那么 next-key 锁会退化成记录锁，也就是只会给一行记录加锁”；在 time1 中，update 语句是带了 where id = 25 的，应该是满足 使用了“唯一索引”这一条件的，为什么加的是“间隙锁”而非“记录锁”呢？

文章网址: 执行一条 select 语句，期间发生了什么？
具体错误: SQL语法树的构建应该是语法分析阶段的任务, 文中错把其归类到词法分析下

个人理解是：在去访问客户端配置的 DNS 服务器之前，应该会先去看下本地 host 文件查看该域名是否存在，如果存在则直接取这个 IP，否则再是访问客户端配置的 DNS 服务器

本地hosts文件举例：

➜  ~ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost
# Added by Docker Desktop
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section

127.0.0.1 bs.studycoder.com
10.10.102.158 *.127-0-0-1.nip.io
127.0.0.1 arana-mysql

10.10.136.208 foo.com
10.10.136.208 bar.com
172.20.0.2    canary.higress.io

高亮的部分前面，是否还需要添加一个步骤，即查询本地hosts文件

mysql-日志-undo-log、redo-log、binlog-有什么用
查询缓存情空的
应该为清

A lot of occurrence of "accpet" (I found them mainly in 4.1 network-tcp, at least 11 places, but haven't check other places).

"accpet" is a typo for "accept".

Redis部分的“为什么要有哨兵”文章中图片中“leeder”应该为“leader”。

原文：
那么，我们可以使用线程池的方式来避免线程的频繁创建和销毁，所谓的线程池，就是提前创建若干个线程，这样当由新连接建立时，将这个已连接的 Socket 放入到一个队列里，然后线程池里的线程负责从队列中取出已连接 Socket 进程处理。

错别字：
"已连接 Socket 进程处理" 中的"进程"应该修改为"进行"

小林你好，最近我在给系统进行压测，压测的情况为：一分钟服务器建立和断开连接总次数达到4000次(各2000次)，服务器为40核，64GB内存，负载情况为CPU usage达到99%，CPU load达到29。在这一分钟的压测过程中服务器丢弃了很多数据包。下图是其中的一例，想问一下这种情况是由于什么原因导致服务端发送RST给客户端的呢？

看到 * 这个字符的时候，是不是大家觉得是读取记录中的所有字段值？

对于 selete *这条语句来说是这个意思，但是在 count(*) 中并不是这个意思。

selete *应该为select *

图解网络-基础篇-2.3 Linux 发送网络包的流程-第一行

"如上图的有半部分，发送网络包的流程正好和接收流程相反。"

"有半部分"->"右半部分"

Linux2.6版本后有了libaio，这完全是内核级别的异步IO，IO请求完全由底层自由调度（以最佳次序的磁盘调度方式）。

libaio的缺点是，想要使用该种方式的文件必须支持以O_DIRECT标志打开，然而并不是所有的文件系统都支持。如果你没有使用O_DIRECT打开文件，它可能仍然“工作”，但它可能不是异步完成的，而是变为了阻塞的。

“内核会定时重发 FIN 报文，其中重发次数由 tcp_orphan_retries 参数控制（注意，orphan 虽然是孤儿的意思，该参数却不只对孤儿连接有效，事实上，它对所有 FIN_WAIT1 状态下的连接都有效）”

其实这段话意思理解了，孤儿连接是主动方发送FIN后，调用close的连接，但是孤儿连接不是不能收发数据么，为什么还会重发报文，而且后面的

“对于普遍正常情况时，调低 tcp_orphan_retries 就已经可以了。如果遇到恶意攻击，FIN 报文根本无法发送出去，这由 TCP 两个特性导致的：

首先，TCP 必须保证报文是有序发送的，FIN 报文也不例外，当发送缓冲区还有数据没有发送时，FIN 报文也不能提前发送。
其次，TCP 有流量控制功能，当接收方接收窗口为 0 时，发送方就不能再发送数据。所以，当攻击者下载大文件时，就可以通过接收窗口设为 0 ，这就会使得 FIN 报文都无法发送出去，那么连接会一直处于 FIN_WAIT1 状态。
解决这种问题的方法，是调整 tcp_max_orphans 参数，它定义了「孤儿连接」的最大数量”

这段话说明一直处于FIN_WAIT1状态的孤儿连接，要通过 tcp_max_orphans 调整防止过多占用资源，后面讲FIN_WAIT2状态，

“这时，如果连接是用 shutdown 函数关闭的，连接可以一直处于 FIN_WAIT2 状态，因为它可能还可以发送或接收数据。但对于 close 函数关闭的孤儿连接，由于无法再发送和接收数据，所以这个状态不可以持续太久，而 tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒：

它意味着对于孤儿连接（调用 close 关闭的连接），如果在 60 秒后还没有收到 FIN 报文，连接就会直接关闭。
这个 60 秒不是随便决定的，它与 TIME_WAIT 状态持续的时间是相同的，后面我们再来说说为什么是 60 秒。”

为什么孤儿连接还会等60秒收到FIN报文，孤儿连接不是完全关闭不收发数据的么？

该章节的两张示意图中将「堆顶指针」写成了「堆定指针」

全队列满的时候，客户端是在ESTABLISHED状态
服务端没有监听，客户端在SYN_SENT的状态

这里不是说，服务器推送的资源，stream id是偶数吗，push_promise不属于服务器推送资源吗？

问题：

鼠标放在 图解 MySQL 和 图解 Redis 两个 nav 上的时候，整个前面的导航条目(包括搜索框) 都会向左移动，放在其他 nav 上没有这个问题。

截图：

环境：

操作系统：windows 10
屏幕分辨率：1920 * 1080
浏览器：Chrome [版本 103.0.5060.114（正式版本） （32 位）]

在作者大大的【图解系统介绍】篇的【要怎么阅读】中，“所以肯定是没有教科书那么细致和全面，当然也不就不会有很多废话，都是直击重点，不绕弯，而且有的知识点书上看不到”，完整的表述是否应该是“所以肯定是没有教科书那么细致和全面，当然也就不会有很多废话，都是直击重点，不绕弯，而且有的知识点书上看不到”？当然也有可能是我理解错了。

https://xiaolincoding.com/os/2_os_structure/linux_vs_windows.html#elf
“不过，Linux 也实现了动态加载内核模块的功能，例如大部分设备驱动是以可加载模块的形式存在的，与内核其他模块解藕，让驱动开发和驱动加载更为方便、灵活。”
解藕-->解耦。

请问网站是用什么开源框架搭建的呢，网上已经看到好几款相同UI风格的，想学习一下

3.1 HTTP 常见面试题中的HTTP与HTTPS模块中，HTTPS 一定安全可靠吗这部分中：中间人要拿到私钥只能通过如下方式下第三点：3.自己签发证书，切要被浏览器信任；切是不是应该是<且>?

小林，有一个问题想请您解答一下。我看您写的资料，HTTP /2 的队头阻塞发生在TCP层传输的多个包，其中某一个包如果丢失了，那么后面的字节数据存放在内核缓冲区中，只有该数据包的数据到达，才能从内核中拿到数据。我想问，假设多条请求stream1、2、3同时到达，stream2的某个数据包丢失了，stream2因为后续数据包存放在缓冲区，或超时重传等操作等待，但是这个会影响stream1、3的响应么，我的问题是，因为流式传输、多路复用，服务器并不需要按照顺序去处理请求，但是如果sream2阻塞了，会影响后续请求的处理么。如果会影响的话，这个和 HTTP /1.1的区别是HTTP /1.1的队头阻塞是因为响应必须按照请求的顺序做出回应，如果某一个请求的没收到响应，后续都会阻塞，而HTTP /2 没有顺序这一概念，这是我阅读完后的理解，请麻烦看下是否正确。而且我理解了下您文章部分的内容，我描述下个人理解的HTTP /2这部分内容，由于不同的 Stream 的帧可以是乱序发送的，所以在服务器的内核缓冲区部分，数据包的顺序可能不是按照同一个请求的顺序发送过来的，这句话正确么，假设stream1、2发送过来，内核缓冲区接收到的情况可能是，stream2的数据包1、stream1的数据包1，stream2的数据包2、stream2的数据包3、stream1的数据包2...这种情况，由于每个帧都有Stream Id信息，所以在发送完后会有序组装，这样子如果stream2的数据包丢失了，后面的数据包都会在内核缓冲区等待，所以stream1的数据包尽管接收完毕，也没办法读取完整，所以也阻塞了，也请麻烦看下我这么理解是否正确。

部分文章中图片如上所示，加载失败，readme中是否可以使用相对位置~~

Hi 作者你好,

在 a = 1 + 2 執行具體過程 這個章節, 有提到說數據與指令是放於不同的記憶體區間, 認知中程式碼應該是位於記憶體中的 text section, 而 text section 應該相對於其他區間是位在比較低記憶體的位置!?
因此文中提到的正文段 (text section) 是否其記憶體位置應該要比數據段還低呢?
若觀念有誤, 還請見諒!

您好，对于tcp三次握手，第三次握手client发出ack，紧接着发出数据包，并且数据包先于ack到达server，这个情景下会发生什么

根据文章的意思，压缩列表中每个节点会记录前一个节点的长度，所以压缩列表在插入新数据的时候，可能会引起连锁更新的问题，对此我有个问题，为什么每个节点要记录前一个节点的长度，查询其它资料后，了解到是为了实现节点从后往前遍历，知道前一个节点的长度，就可以计算前一个节点的偏移量。而作为替代的ListPack中，每个节点只记录自己的长度，那么问题来了，ListPack如何实现节点从后往前遍历的功能，还是说最新的Redis版本不支持这个功能了？

作者你好，请问一下是否会提供你画的图的drawio文件呢？

作者好。
关于在文章 《HTTP 常见面试题》中，_HTTPS 一定安全可靠吗？_模块里中子模块 为什么抓包工具能截取 HTTPS 数据？
有一段这样的描述

中间人要拿到私钥只能通过如下方式：

去网站服务端拿到私钥；
去CA处拿域名签发私钥；
自己签发证书，切要被浏览器信任；

不用解释，抓包工具只能使用第三种方式取得中间人的身份。

使用抓包工具进行 HTTPS 抓包的时候，需要在客户端安装 Fiddler 的根证书，这里实际上起认证中心（CA）的作用。

抓包工具能够抓包的关键是客户端会往系统受信任的根证书列表中导入抓包工具生成的证书，而这个证书会被浏览器信任，也就是抓包工具给自己创建了一个认证中心 CA，客户端拿着中间人签发的证书去中间人自己的 CA 去认证，当然认为这个证书是有效的。

个人觉得可以修改的几个点：

1. 此处「切要被浏览器信任」应该为 且要被浏览器信任 ？
2. 文段上下文中均使用 抓包工具 作为代称，此处是否将Fiddler（具体的工具）也使用代称 抓包工具 较好
3. 第二段和第三段的第一句话有一些重复；「而这个证书会被浏览器信任」，应该跟前一段话是因果关系，此处用「而」有点像转折关系，整体理解起来语义怪怪的..同时，整体的流程应该为抓包工具导入根证书，通过该根证书签发访问域名的证书，浏览器向根证书（CA)验证后认为该证书可信

以下是个人的修改

中间人要拿到私钥只能通过如下方式：

去网站服务端拿到私钥；
去CA处拿域名签发私钥；
自己签发受浏览器信任的证书；

不用解释，抓包工具只能使用第三种方式取得中间人的身份。

因此使用抓包工具进行 HTTPS 抓包的时候，抓包工具会生成根证书，导入到客户端系统的 受信任的根证书列表 中，这里的根证书实际上起认证中心（CA）的作用。

随后抓包工具使用该根证书签发域名的证书，因为根证书受信任，域名的证书同样会被浏览器信任。也就是抓包工具给自己创建了一个认证中心 CA，客户端拿着中间人（抓包工具）签发的证书去中间人（抓包工具）自己的 CA 做认证，这个证书当然被认为是有效的。

想了解一下，计算机网络部分的很多逻辑分析图片用什么软件画出来的？

小林您好
您的圖解系列pdf都有黑暗模式
網站怎麼缺切換為黑暗模式的功能呢？
麻煩您有空時添上，感恩

您的圖解網路讓我受益良多，感謝

在traceroute的介绍中，提到了

traceroute 在发送 UDP 包时，会填入一个不可能的端口号值作为 UDP 目标端口号（大于 3000 ）。当目的主机，收到 UDP 包后，会返回 ICMP 差错报文消息，但这个差错报文消息的类型是「端口不可达」。

查询了下linux的man traceroute，实际应该是：

Probe  packets  are  udp  datagrams with so-called "unlikely" destination ports.  The "unlikely" port of the first probe is 33434, then for each next probe it is incremented by one. Since the ports are expected to be unused, the destination host normally returns "icmp unreach port" as a final response.  (Nobody knows what happens when some application listens for such ports, though).

探针数据包是带着「不可能端口」的udp数据报。第一个探针的「不可能端口」是33434，然后对于每个下一个探针，它都会增加一个。这些端口都是通常认为不会被使用，所以目标主机会返回“icmp unreach port”作为最终响应。（不过，没有人知道当某些应用程序监听此类端口时会发生什么）。

您好，感觉您的个人网站的前端比较好，您的前端是用的开源的吗？帮忙推荐哈。

数据库 - 事务的隔离级别这篇文章，有张图片里面用词不是很准确，read view翻译成了视图，容易和数据库的视图相混淆，其他图片和文字都没有视图二字。

以及这张图片下面的文字也有排版的问题~

希望修改一下，谢谢~~

Http status code 500 描述错字 "类型" -> "类似"

#107

is:issue is:open 图解操作系统 中 2.1 中关于 指令寄存器的描述有错误，指令寄存器中存的是当前正在运行的指令，并不是程序计数器指向的指令，程序计数器指向的指令是下一次要执行的指令

Redis集群
集群脑裂导致数据丢失怎么办
解决方案：
"当主节点发现从节点下线或者通信超时的总数量小于阈值时，那么禁止主节点进行写数据，直接把错误返回给客户端。"

里面的小于是不是应该改为“大于”？