xkwy001 最近的时间轴更新 xkwy001 最近的时间轴更新 |
xkwy001🏢 xkwyStudio / CEO V2EX 第 442187 号会员，加入于 2019-09-20 08:43:41 +08:00今日活跃度排名 8537 |
xkwy2018.com
xkwy001 最近回复了
7 天前 回复了 jiuzhougege 创建的主题 › Apple › Mac Mini M4 有扬声器吗？ |
23 天前 回复了 shangnengfanfo 创建的主题 › 硬件 › 有熟悉硬件的不，如果两个 USB2.0 并联到一个接口，传输速度会不会翻倍，或者对硬件是否有危害，谢谢！ |
USB 是点对点的，只有 Hub 芯片可以将一路 USB 拆分成几路，而且 Hub 所有下行口共享上行口的带宽。
想要提升速度最简单的办法就是 2.0 升级 3.0 ，带宽可由 480Mbps 提高到 5Gbps ，提升十倍。
或者，买两个硬盘”手动并联“，但要注意两个硬盘同时使用时尽量要分别插到电脑前面和后面的 USB 口上。
因为电脑上的多个 USB 口很大概率是用 Hub 分出来的，相邻的 USB 口如果挂在同一个 Hub 下面则它俩同时使用时速度总和不会高于 480Mbps 带宽。
想要提升速度最简单的办法就是 2.0 升级 3.0 ，带宽可由 480Mbps 提高到 5Gbps ，提升十倍。
或者，买两个硬盘”手动并联“，但要注意两个硬盘同时使用时尽量要分别插到电脑前面和后面的 USB 口上。
因为电脑上的多个 USB 口很大概率是用 Hub 分出来的，相邻的 USB 口如果挂在同一个 Hub 下面则它俩同时使用时速度总和不会高于 480Mbps 带宽。
30 天前 回复了 bugmakerxs 创建的主题 › 程序员 › 一事不明：代理工具是怎么解决 https 证书问题和 dns 污染问题的？ |
代理工具工作在传输层，即 TCP/UDP
https （应用层）是基于 TCP 的，代理工具负责把 TCP 链路打通，后续的证书什么的都走这个 TCP 通道，应用层（ https ）的业务不关心传输层（ TCP ）是怎么走的，所以不会有证书问题，代理服务器也无法监听 https 密钥交换过程。
至于 DNS 解析，通常的做法是本地将域名直接发到代理服务器（远端），由远端自己解析 IP 地址并完成 TCP 三次握手连接，这种远端解析 DNS 可以防止 DNS 污染。
当然也可以本地解析 DNS ，将要连接的 IP 地址发给远端直连 IP 。
代理服务器不需要开启 DNS 服务，它只需要具备域名到 IP 的转换能力就行了（ DNS 客户端角色）
https （应用层）是基于 TCP 的，代理工具负责把 TCP 链路打通，后续的证书什么的都走这个 TCP 通道，应用层（ https ）的业务不关心传输层（ TCP ）是怎么走的，所以不会有证书问题，代理服务器也无法监听 https 密钥交换过程。
至于 DNS 解析，通常的做法是本地将域名直接发到代理服务器（远端），由远端自己解析 IP 地址并完成 TCP 三次握手连接，这种远端解析 DNS 可以防止 DNS 污染。
当然也可以本地解析 DNS ，将要连接的 IP 地址发给远端直连 IP 。
代理服务器不需要开启 DNS 服务，它只需要具备域名到 IP 的转换能力就行了（ DNS 客户端角色）
73 天前 回复了 v2hh 创建的主题 › 推广 › 我们用了 4 年时间，一直在做一款远程控制工具 |
@iMusic #72 免费版对标免费版，专业版对标专业版
107 天前 回复了 weiweiwitch 创建的主题 › Linux › 绕过了一个 VPS 上恶心问题，但不确定原因。麻烦大佬们提供下排查思路。 |
@JieS sudo ln -sf /bin/bash /bin/sh
283 天前 回复了 weiweiwitch 创建的主题 › Linux › 绕过了一个 VPS 上恶心问题，但不确定原因。麻烦大佬们提供下排查思路。 |
使用 strace 命令可以明显看出二者区别。
根本原因在于 bash 和 dash 对 read 这个 shell 内建命令的具体实现不一样。
dash 的实现是 read(0, &c, 1)直接使用 read 系统调用，一个字符一个字符地读取；
https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/miscbltin.c#n151
而 bash 是使用 zreadc(fd, &c)实现的，其内部会有一个 4K 缓冲，每次执行 zreadc 会一次性从文件中读入 4K 内容。
http://git.savannah.gnu.org/cgit/bash.git/tree/builtins/read.def#n683
http://git.savannah.gnu.org/cgit/bash.git/tree/lib/sh/zread.c#n132
对于常规的磁盘文件，使用 read 系统调用也还好，因为内核层面其实也有一层 buffer ，顶多会频繁进/出内核，并不涉及随机读写的磁盘 io 瓶颈。
猜测/sys/firmware/qemu_fw_cfg/by_name/etc/cloud-init/vendor-data/raw 这个文件不是普通的常规硬盘文件，每一次执行 read 系统调用都会触发异常->qemu 处理->balabala 一顿操作才返回，绕了好大一圈，且相对常规文件也没有内核缓冲，等于是每读一个字符都来一遍
根本原因在于 bash 和 dash 对 read 这个 shell 内建命令的具体实现不一样。
dash 的实现是 read(0, &c, 1)直接使用 read 系统调用，一个字符一个字符地读取；
https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/miscbltin.c#n151
而 bash 是使用 zreadc(fd, &c)实现的，其内部会有一个 4K 缓冲，每次执行 zreadc 会一次性从文件中读入 4K 内容。
http://git.savannah.gnu.org/cgit/bash.git/tree/builtins/read.def#n683
http://git.savannah.gnu.org/cgit/bash.git/tree/lib/sh/zread.c#n132
对于常规的磁盘文件，使用 read 系统调用也还好，因为内核层面其实也有一层 buffer ，顶多会频繁进/出内核，并不涉及随机读写的磁盘 io 瓶颈。
猜测/sys/firmware/qemu_fw_cfg/by_name/etc/cloud-init/vendor-data/raw 这个文件不是普通的常规硬盘文件，每一次执行 read 系统调用都会触发异常->qemu 处理->balabala 一顿操作才返回，绕了好大一圈，且相对常规文件也没有内核缓冲，等于是每读一个字符都来一遍
Select Language