TechKoala - Input/Output

Linux 内核网络核心：sk_buff 深度解析

Wed, 10 Dec 2025 13:09:56 +0800

本文档基于 Linux 内核开发者视角，深入剖析网络子系统最核心的数据结构 sk_buff (socket buffer)。我们将从内存布局、生命周期、软硬件交互以及性能优化机制（如 GRO, Zero Copy, BQL/TSQ）等多个维度进行全景式描述。

第一部分：sk_buff 的物理与逻辑解剖

1. 核心设计哲学：元数据与数据的分离

在 Linux 内核中，网络包并非存储在一个巨大的连续结构体中，而是被拆分为两部分，分别独立分配内存：

控制结构体 (struct sk_buff)：
- 位置： 分配在 Slab Cache (skbuff_head_cache) 中。
- 作用： 包含管理数据包所需的元数据（如指针、长度、接口、协议、引用计数等）。它的大小固定（约 232~256 字节），随内核配置而变。
数据缓冲区 (Data Buffer)：
- 位置： 通过 kmalloc 分配的连续物理内存块（线性区）或物理页（非线性区）。
- 作用： 存放真实的协议头（MAC/IP/TCP）和用户负载。

2. 内存布局与指针系统

sk_buff 通过四个核心指针管理线性数据区：

[ struct sk_buff ]
      |
      +--- head ----------------------------------+
      |                                           |
      +--- data ---------+                        |
      |                  |                        |
      +--- tail -----------------------+          |
      |                  |             |          |
      +--- end ------------------------------------------------+
                         |             |          |            |
      [   Headroom     ] [   Data      ] [ Tailroom ] [ skb_shared_info ]
      ^                  ^             ^            ^          ^
      |                  |             |            |          |
    head               data          tail          end      end 之后

head：线性内存块的物理起始地址。
data：当前协议层有效数据的起始位置。随协议层变化移动（push/pull）。
tail：当前有效数据的结束位置。
end：线性内存块的物理结束地址。
skb_shared_info：位于 end 之后。它不占用线性区空间，但紧随其后。核心成员是 frags[] 数组，用于挂载非线性区（物理页数据）。

3. 线性区 vs 非线性区

线性区 (head ~ end)：
- 必须存在。用于存放所有的协议头部（MAC, IP, TCP）。
- 原因：CPU 访问协议头时需要使用结构体指针强转（如 (struct iphdr *)skb->data），要求内存物理连续。
- 小包场景：Payload 也直接存放在这里。
非线性区 (frags / Page Based)：
- 可选。存放大数据负载（如文件传输、视频流）。
- 物理形态：skb_shared_info->frags[] 数组指向一组分散的物理页（Page）。
- 硬件要求：网卡必须支持 Scatter-Gather (SG) DMA 才能直接读取这些分散的页。
- 优势：实现 Zero Copy（零拷贝）和 Jumbo Frames（巨型帧）的基础。

第二部分：数据包的生命周期 (Flow)

1. 发送路径 (TX) —— “Push” 与克隆

分配 (Alloc)：
- 调用 send() 时，内核根据 MSS 和 MAX_HEADER 计算大小，分配 sk_buff 和数据区。
- 调用 skb_reserve，移动 data 和 tail 指针，预留 Headroom。
- 用户数据被拷贝（或零拷贝映射）进来。
克隆 (Clone)：
- TCP 为了可靠传输（重传），在交给 IP 层前执行 skb_clone。
- Clone 特性：只复制 sk_buff 结构体，不复制数据区。新旧 skb 指向同一块内存。
- Original skb：留在发送队列，data 指针指向 Payload 开头。
- Clone skb：用于传输，data 指针在 Headroom 中前移（skb_push）以填充协议头。
填头 (Header Filling)：
- TCP 层：skb_push 腾出空间 -> 强转指针 (struct tcphdr*)skb->data -> 填入 Seq/Port。
- IP 层：skb_push -> 填入 IP 头。
- MAC 层：skb_push -> 填入 MAC 头。
硬件交互 (Ring Buffer)：
- 驱动将线性区和 Frags 的物理地址填入 TX Ring Buffer 的描述符。
- 按“门铃”（写寄存器），通知网卡 DMA 搬运。
- 发送完成：指 DMA 将数据搬入网卡 SRAM，内核释放 skb 内存。

2. 接收路径 (RX) —— “Pull” 与聚合

硬件接收：
- 数据到达，网卡 DMA 将其写入预先分配的 Ring Buffer 内存块（可能是 Page）。
- 触发 硬中断，随后调度 软中断 (NAPI)。
GRO (Generic Receive Offload)：
- 在 NAPI 层，将同属于一条流的多个小包合并。
- 保留第一个包的 skb 壳，将后续包的物理页（Frags）挂到第一个包的 shinfo 上，丢弃后续包的壳。
- 效果：协议栈看到一个巨大的包（哪怕超过 MTU），带有 gso_size 标记。
剥离头部 (Header Stripping)：
- 进入协议栈，执行 skb_pull。
- data 指针向后移动，依次跳过 MAC、IP、TCP 头。被跳过的部分变成 Headroom。
接收缓冲：
- 数据包被挂入 Socket 的接收队列（有序链表或乱序红黑树）。
- 接收窗口：并非物理连续内存，而是通过 sk_rmem_alloc 原子计数器限制的总字节数。

第三部分：核心机制与 Q&A

在此部分，我们将之前的讨论整理为问答形式，解答关键的技术细节。

Q1: sk_buff 中的成员都是对应数据的指针吗？真实数据存在哪里？

A: 不全是。head/data/tail/end 是指针。但像 len, protocol 是普通变量。还有一个特殊的 cb[48] (Control Buffer)，它是一个直接存放在结构体内的 48 字节数组。

真实数据：存在于 head 指向的另一块独立分配的内存（线性区）或 frags 指向的物理页（非线性区）。
TCP Seq：在处理过程中，Seq 为了访问速度，被拷贝存放在 cb 数组中，而不是每次都去读 data 里的 TCP 头。

Q2: 一个完整的数据包，是否就包含在 skb->head 和 skb->end 之间？

A: 这是一个误区。

head~end：是内核分配的线性内存容器的总大小。
data~tail：才是当前协议层看到的有效数据。
非线性数据：对于大包，大部分 Payload 存储在 end 指针之后的 skb_shared_info->frags 指向的物理页中，根本不在 head~end 之间。
校验和：存放在 data~tail 包含的协议头内部，绝不会在 tail 后面。

Q3: 为什么会有 skb_clone？它拷贝数据吗？

目的：为了高效实现 TCP 重传、抓包（tcpdump）等功能。
机制：skb_clone完全不拷贝数据区。它只申请一个新的 sk_buff 结构体（元数据），让其 head 指针指向原有的数据区。
副作用：Clone 出来的 skb 对数据区是 只读 (Read-Only) 的。如果需要修改数据，必须触发 CoW（写时复制）。
引用计数：
- users：管 sk_buff 结构体。
- dataref：管数据区。Clone 时 dataref++。

Q4: 环形缓冲区 (Ring Buffer) 在物理上是怎么理解的？

它不是存放数据包的环，而是存放 描述符 (Descriptor) 的数组。
描述符：是一个很小的结构体，里面只有物理地址指针和状态位。
工作流：
- RX：驱动把空闲内存地址填入描述符 -> 网卡 DMA 填数据 -> CPU 读走。
- TX：驱动把数据地址填入描述符 -> 网卡 DMA 读数据 -> 网卡发送。

Q5: 硬中断和软中断具体分工是什么？

硬中断：极短。只负责告诉 CPU “DMA 搬运完了”，然后关闭网卡中断，唤醒软中断。它不拷贝数据。
软中断 (NAPI)：干重活。轮询 Ring Buffer，分配 sk_buff（如果需要），执行 GRO 合并，运行 TCP/IP 协议栈逻辑，直到数据放入 Socket 队列。

Q6: 零拷贝 (Zero Copy) 是如何运作的？

A: 核心在于利用 skb_shared_info->frags。

Sendfile：内核直接把磁盘读取到的 Page Cache（物理页）的地址挂到 frags 数组里，完全跳过 CPU memcpy 到线性区的步骤。
Splice：在两个 Socket 或 Pipe 之间传递物理页的指针/引用，而不是搬运数据。

Q7: 发包时，当驱动说“发送完成”，数据真的发出去了吗？

A: 通常没有。

它只代表数据已经完整进入了 网卡的 SRAM (Tx FIFO)。
内核此时释放内存 (kfree_skb)。
隐患：Bufferbloat（缓冲区膨胀）。数据可能堵在网卡硬件里，导致 Ping 值虚高且内核 QoS 失效。

Q8: 什么是 BQL 和 TSQ？它们解决什么问题？

A: 它们是为了解决上述的 Bufferbloat 问题。

BQL (Byte Queue Limits)：在驱动层。动态调整提交给网卡硬件队列的字节数，保证网卡不饿死但也不多留数据。
TSQ (TCP Small Queues)：在 TCP 层。限制每个 Socket 已发送但未释放（还在网卡或 QDisc 排队）的字节数。
效果：构建了从网卡到应用的背压 (Backpressure) 机制，将排队控制在内核可控的层级（QDisc），从而降低延迟。

Q9: 接收窗口 (Receive Window) 对应一块连续物理内存吗？

A: 不是。

接收缓冲区是一堆散落在内存各处的 sk_buff，通过链表（有序）和红黑树（乱序）组织。
窗口控制：通过原子变量 sk->sk_rmem_alloc 统计所有 skb 的 truesize 总和来实现逻辑限制。

总结建议：理解 sk_buff 的关键在于建立 “元数据(Controller) 与数据(View) 分离” 以及 “线性(Linear) 与非线性(Paged) 混合” 的立体视图。网络优化的本质，往往就是减少元数据的分配（GRO/XDP）和减少数据的拷贝（Zero Copy）。

WireGuard 主要网络拓扑

Tue, 26 Nov 2024 23:41:02 +0800

WireGuard 基础拓扑结构说明

WireGuard 网络连接两个端点时，主要有以下四种拓扑结构可供选择：

点对点（Point to Point）
星型（Hub and Spoke）
点到站点（Point to Site）
站点到站点（Site to Site）

这些拓扑结构都能满足常见的端点连接需求，例如：通过 SSH 进行通信、访问另一端的 HTTP 服务器、访问共享文件夹等。

与其他 VPN 技术不同，WireGuard 没有严格的"客户端"或"服务器"角色之分。所有 WireGuard 节点都具有同等的能力，可以执行传统意义上的"客户端"或"服务器"角色。

为了简化说明，本文将统一使用以下示例：

“端点 A"代表"客户端”（如用户的平板电脑）
“端点 B"代表"服务器端”（如运行 Web 应用的服务器）
端口使用约定：
- 51821：代表"客户端"侧的 WireGuard 节点
- 51822：代表"服务器"侧的 WireGuard 节点
- 51823：用于两者之间的中间 WireGuard 节点（如果存在）

点对点拓扑

点对点是最简单的拓扑结构 —— 就是运行 WireGuard 的一个端点直接连接到另一个运行 WireGuard 的端点。这也是唯一能实现端到端（E2E）加密的拓扑结构。其他所有拓扑结构都涉及 WireGuard 数据包在端点之间的某个中间节点被解密。

要实现点对点连接，两个端点之间的所有防火墙必须允许其中一个端点的 WireGuard 端口接受新连接。

简单点对点场景

在最简单的点对点场景中，两个端点位于同一个局域网（LAN）内，它们之间的防火墙配置为允许任一端点连接到对方的 WireGuard 端口。在这种情况下，任何一个端点都可以随时发起与对方的连接。

复杂点对点场景

在更复杂但常见的场景中，两个端点都位于防火墙和 NAT（网络地址转换）后面，中间通过互联网连接：

端点 A 前面的防火墙只允许已建立的连接通过
端点 B 前面的防火墙允许新连接通过 51822 端口
端点 B 前面的 NAT 将 51822 端口转发到端点 B

在这种场景下：

端点 A 可以随时向端点 B 发起新连接
由于端点 A 位于只允许已建立连接的防火墙后面，如果要使端点 B 能够向端点 A 发起连接，必须在端点 A 上配置 PersistentKeepalive 设置（设置为 25，即每 25 秒发送一个保活数据包，这个值适用于大多数情况）

网状拓扑实际上就是一组端点之间的多个点对点连接的组合。

详细的配置示例请参考WireGuard 点对点配置。

星型拓扑

星型拓扑（也称为星形拓扑）是下一个基本拓扑结构，其中两个运行 WireGuard 的端点通过第三台同样运行 WireGuard 的主机连接。这第三台主机作为连接到它的 WireGuard 端点之间的路由器，将从一个端点通过 WireGuard 隧道收到的数据包通过另一个 WireGuard 隧道转发给第二个端点。

这种拓扑通常用于连接多于两个的端点 —— 这是实现远程访问管理的好方法，可以管理多个远程端点；或者将多个分散的远程主机组成虚拟局域网，在一个中心位置（集线器）集中进行路由规则配置、访问控制和流量检查。

星型拓扑也可以用作连接两个都位于不允许新入站连接的防火墙后面的端点，或者位于不允许端口转发的 NAT 后面的端点（这时集线器充当"跳板服务器"）。

简单星型场景

在最简单的星型场景中，所有主机都在同一个本地网络中：

“分支"端点（端点 A 和端点 B）与"集线器"主机（主机 C）之间的防火墙配置为允许分支连接到集线器的 WireGuard 端口（51823）
同样允许集线器连接到各个分支的 WireGuard 端口（端点 A 的 51821 和端点 B 的 51822）

一旦端点 A 与主机 C 之间的 WireGuard 隧道建立，以及端点 B 与主机 C 之间的单独 WireGuard 隧道建立，主机 C 就可以在端点 A 和端点 B 之间路由数据包。

复杂星型场景

在更复杂的场景中，集线器和分支都位于防火墙和 NAT 后面，中间通过互联网连接：

端点 A 和端点 B 前面的防火墙只允许已建立的连接通过
主机 C 前面的防火墙允许新连接通过 51823 端口
主机 C 前面的 NAT 将 51823 端口转发到主机 C

在这种场景下：

端点 A 和端点 B 都可以独立地与主机 C 建立新连接
由于端点 A 和 B 的防火墙规则，主机 C 无法与它们建立新连接
要使端点 A 能够通过 WireGuard 向端点 B 发起连接，必须在端点 B 上配置 PersistentKeepalive
如果还要允许端点 B 通过 WireGuard 向端点 A 发起连接，则必须在端点 A 上配置 PersistentKeepalive

详细的配置示例请参考《WireGuard 星型拓扑配置》文章。

点到站点拓扑

在点到站点拓扑中，远程端点通过 WireGuard 连接到另一个网络中的主机，该主机可以将远程端点的数据包路由到其网络内的各个本地端点。点到站点类似于星型拓扑，但区别在于一些分支（与集线器位于同一局域网的端点）不使用 WireGuard 隧道。

点到站点适用于多种场景，当您想要允许远程端点访问同一局域网上的多个服务器，而不需要在每个服务器上单独设置和管理 WireGuard 时特别有用。常见场景包括：

远程 PC 连接到办公室局域网的各个服务器（又称"Road Warrior”）
办公室局域网中的工作站连接到云网络中的多个服务器（又称"Point to Cloud"）
云虚拟机连接到您办公室局域网的各个服务器
云服务器连接到另一个云网络中的其他服务器

简单点到站点场景

在最简单的点到站点场景中：

一个运行 WireGuard 的端点（“远程端点”，端点 A）直接连接到另一个运行 WireGuard 的主机（主机 β）
主机 β 可以作为路由器连接到本地站点（站点 B）内的其他端点，包括端点 B（“本地"端点）

在这种场景中，端点 A 和站点 B 之间的防火墙配置为允许端点 A 与主机 β 相互连接。这使得远程端点（端点 A）可以发起与任何本地端点的连接，任何本地端点（如端点 B）也可以发起与远程端点的连接。

复杂点到站点场景

在更复杂（也更常见）的场景中：

远程端点（端点 A）和本地站点（站点 B）都位于防火墙和 NAT 后面，中间通过互联网连接
端点 A 前面的防火墙只允许已建立的连接通过
站点 B 前面的防火墙允许新连接通过 51822 端口
运行 WireGuard 的主机（主机 β）在 51822 端口接受 WireGuard 连接，并将授权流量从其 WireGuard 隧道路由到站点内的端点（如端点 B）

本地站点（站点 B）内的流量不通过 WireGuard 隧道，因此受制于其他本地流量所适用的任何防火墙或路由限制：

HTTP 请求从端点 A 到端点 B 的路径：先通过 WireGuard 隧道从端点 A 到站点 B，然后像任何其他本地流量一样从 WireGuard 隧道路由到端点 B
要使 HTTP 流量从端点 A 完全通过到端点 B 的 80 端口，主机 β 和端点 B 之间的任何防火墙都需要允许来自主机 β 到端点 B 的 80 端口流量

与点对点场景类似：

端点 A 可以随时向端点 B 发起新连接
由于端点 A 位于只允许已建立连接的防火墙后面，如果要使端点 B 能够向端点 A 发起连接，必须在端点 A 上配置 PersistentKeepalive

详细的配置示例请参考《WireGuard 点到站点配置》文章。

站点到站点拓扑

站点到站点拓扑类似于点到站点，但区别在于 WireGuard 隧道的两端都是完整的站点。这是构建虚拟局域网到局域网连接（或云到云、局域网到云等）的简便方法。

与点到站点类似，在一端有一台运行 WireGuard 的主机，该主机可以路由到其站点内的各个端点。在连接的另一端，在不同的站点中也有一台运行 WireGuard 的主机，这台主机同样可以路由到其站点内的端点。

在下面最简单的形式中，有两个相邻的子网（站点 A 和站点 B）通过 WireGuard 隧道连接。站点 A 中的流量（如来自端点 A）如果目的地是站点 B 中的端点（如端点 B），会首先路由到站点 A 中的 WireGuard 主机（主机 α），然后通过 WireGuard 隧道到达站点 B，最后从站点 B 中的 WireGuard 主机（主机 β）发送到站点 B 中的目标端点。

在这种场景中，站点 A 和站点 B 之间的任何防火墙都应配置为允许站点 A 连接到站点 B 的 WireGuard 端口，反之亦然。这使得站点 A 中的任何端点都可以发起与站点 B 中任何端点的连接，反之亦然。

在更复杂的场景中，两个站点都位于防火墙和 NAT 后面，中间通过互联网连接：

站点 A 前面的防火墙允许新连接通过 51821 端口，主机 α 在该端口接受 WireGuard 连接，并将授权流量从其 WireGuard 隧道路由到站点内的端点
类似地，站点 B 前面的防火墙允许新连接通过 51822 端口，主机 β 在该端口接受 WireGuard 流量，并将授权流量从其 WireGuard 隧道路由到站点 B 内的端点

在这种场景中，站点 A 和站点 B 的 WireGuard 主机都位于各自站点的 DMZ（隔离区）中，它们可以从互联网公开访问，同时也可以路由到其所在站点使用的私有地址空间（以及它们所属的 WireGuard 网络使用的私有地址空间）。

在这种场景下，从端点 A 到端点 B 的流量首先路由到主机 α，然后通过站点 A 和站点 B 之间的 WireGuard 隧道，从主机 β 出来，最后到达端点 B：

端点 A 和主机 α 之间的防火墙允许来自端点 A 的出站流量（以及已建立连接的回程流量）
主机 β 到端点 B 之间的防火墙允许到端点 B 的 HTTP（80 端口）入站流量（以及相应的出站流量）

主机 α 和主机 β 之间的防火墙允许任一 WireGuard 主机向另一方发起连接。因此，通常通过使用 WireGuard 隧道，站点 A 中的任何端点都可以向站点 B 中的任何端点发起连接，反之亦然。但是，端点 A 和主机 α 之间的防火墙只允许已建立的连接进入端点 A，从而保护它免受来自站点 B 的新连接。

如果我们想允许站点 B 中的端点能够向端点 A 发起新连接，这不需要进行任何 WireGuard 特定的配置 —— 我们只需要更改端点 A 和主机 α 之间的防火墙规则，允许新连接进入（就像我们对端点 B 所做的那样，允许来自主机 β 的新 HTTP 连接通过 80 端口）。

详细的配置示例请参考WireGuard 站点到站点配置。

其他拓扑

基本上所有其他你会使用的 WireGuard 拓扑都可以通过组合这四种基本模式来构建。例如，对于由多个分散的远程端点（用于移动办公人员）连接到局域网（在你的办公总部）的 WireGuard 网络，你可以将星型拓扑与点到站点拓扑结合使用，其中远程端点作为星型拓扑的分支，而星型拓扑的集线器同时也是点到站点拓扑中的站点 WireGuard 主机。

另一个例子是，对于连接三个办公室局域网加上两个云站点的 WireGuard 网络，你可以在每个单独的站点之间使用站点到站点拓扑，从每个站点的 WireGuard 主机创建单独的 WireGuard 隧道到其他四个站点。或者你可能决定使用星型拓扑与站点到站点拓扑的组合，这允许你在一个地方集中管理站点间的路由和访问控制，并且每个站点的 WireGuard 主机只需要连接到一个所有其他站点也都连接的集线器主机。

原文链接

Primary WireGuard Topologies

服务器基础设置

Fri, 11 Oct 2024 23:45:31 +0800

翻译一篇服务器基本配置的好文章

这是我一直想写的一篇文章。虽然说明如何设置自托管应用程序很简单，但在薄弱的基础上托管应用程序毫无意义。在每篇教程的开头都介绍服务器设置是一件非常麻烦的事，所以我也为自己写了这篇文章，作为我如何为自己托管的应用程序设置服务器的参考。我会从基本的东西开始，比如使用 SSH 正确登录、非根用户设置以及为每个应用程序创建用户。我还会介绍 NGINX 设置、一些让服务器管理更轻松的生活质量工具、日志管理和基本网络安全。

SSH

首先是登录。您需要一种安全访问设备的方法。不要使用用户名和密码。你需要使用 SSH（安全外壳），并确保 SSH 是唯一的登录方式。为此，你需要一个 SSH 密钥和一个新的用户账户。在新配置的 VPS 上，你将以根用户身份登录，你需要保护根用户账户。首先在 VPS 或远程机器上创建一个新的普通用户，并将其添加到 “sudo “组：

sudo adduser techkoala

sudo usermod -aG sudo techkoala

然后在本地电脑是执行：

ssh-keygen -t ed25519 -C "your_email@example.com"

按照说明操作，它会问你想把文件保存在哪里，以及是否需要密码。请确保设置了字符串密码。要将公钥复制到服务器上，请在本地计算机上运行：

ssh-copy-id -i ~/.ssh/id_ed25519.pub newuser@your_server_ip

请记住，newuser@your-server-ip 是用户名，也是你要将公钥复制到的远程设备。提示输入密码时，输入的是远程设备上的账户密码，而不是你刚刚为 SSH 密钥设置的密码。一旦验证通过，它就会复制公钥，现在你就可以通过 SSH 登录了。要关闭用户名和密码登录，请键入：

sudo vim /etc/ssh/sshd_config

找到下列值，并按你在这里看到的进行设置

Port 2222     # Change default port (use a number between 1024 and 65535)
PermitRootLogin no                 # Disable root login
PasswordAuthentication no          # Disable password authentication
PubkeyAuthentication yes           # Enable public key authentication
AuthorizedKeysFile .ssh/authorized_keys # Specify authorized_keys file location
AllowUsers newuser                 # Only allow specific users to login

这将禁止除 SSH 之外的所有登录方式，只能通过你复制了公钥的用户登录。停止以 Root 身份登录，只允许你指定的用户登录。点击 CTL+S 保存，点击 CTL+x 退出文件编辑器。重启 SSH：

sudo systemctl restart ssh

这可能会导致你退出 SSH 会话。如果出现这种情况，这时可以测试其他登录方法，看看是否被拒绝，然后再继续。此外，不言而喻，你需要妥善保管私钥，一旦丢失，你将无法再远程登录：

Protocol 2                 # Use only SSH protocol version 2
MaxAuthTries 3             # Limit authentication attempts
ClientAliveInterval 300    # Client alive interval in seconds
ClientAliveCountMax 2      # Maximum client alive count

现在，让我们再深入研究一下用户，看看如何利用他们来提高组织性和安全性。

Users

在管理 Linux 服务器时，用户非常重要。服务器管理中有一个理念叫做 “最小权限原则”，其基本意思是，你要给予应用程序或进程完成工作所需的最小权限。Root 拥有无限的权限，没有应用程序真正需要它。为正在运行的应用程序设置用户权限有几个好处。如果正在运行的应用程序受到威胁，它可以限制潜在的损害。当运行多个应用程序时，它可以增加隔离性，有助于审计，让你知道哪些应用程序正在使用哪些系统资源。

简而言之，用户是组织系统的好帮手，在出现问题时能帮助你排除故障。要添加新用户，请运行

sudo useradd -rms /usr/sbin/nologin -c "a comment" youruser

该命令将创建一个用户，并为其提供一个存放应用程序数据的主目录，但不允许以该用户身份登录。-c标志是可选的，但最好能知道用户的用途，如 “运行 Nextcloud “之类。将应用程序文件克隆到 /opt 目录中：

sudo mkdir /opt/myapp

该命令会创建一个用户，并为其提供一个存放应用程序数据的主目录，但不允许以该用户身份登录。-c标志是可选的，但最好能知道用户的用途，如 “运行 Nextcloud “之类。将应用程序文件克隆到 /opt 目录中：

sudo chown appuser:appuser /opt/myapp

好了，这样就锁定了你的登录，你也应该对如何使用用户有了一定的了解。接下来是日志。

Logs

日志对系统管理至关重要。它们可以跟踪系统健康状况，帮助排除故障和检测威胁。因此，你需要设置适当的日志轮换，这样日志就不会占用系统太多空间，而且更易于阅读和管理。要设置正确的日志轮换，需要编辑位于 /etc 目录下的 logrotate.conf 文件。单个应用程序的配置通常存储在 /etc/logrotate.d/，因此 NGINX 的配置示例如下：

/var/log/nginx/*.log {
    weekly
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

该配置每周轮换日志，保留 52 周的日志，压缩旧日志，以正确的权限创建新日志，然后在轮换后向 NGINX 发出信号以重新打开日志文件。您可以使用以下配置进行测试

sudo logrotate -d /etc/logrotate.conf

这将显示它在不实际旋转日志的情况下会做什么。有了这些设置，你就可以开始做更高级的事情了，比如根据日志条目触发警报。现在，这对单台服务器来说还算不错，但如果你管理的服务器不止一台，最好还是了解一下 Grafana Loki、Graylog 和 Fluentd 等工具。在此我就不详细介绍了，但如果你想提高你的日志游戏水平，这些都是不错的起点。

Backups

备份，更重要的是测试备份，在服务器管理中极其重要。请记住：除非经过测试，否则备份就不是备份。未经测试的备份基本上是无用的。

备份主要有三种类型。完全备份、差异备份和增量备份。完全备份是磁盘上所有数据的完整副本。这种备份占用资源最多，但最容易恢复。差异备份备份的是上次完整备份后的所有变化，这是一种在空间和恢复速度上都处于中间位置的备份策略。增量备份备份自上次备份后发生变化的数据，这是最快的备份方式，但恢复起来可能最复杂。

我是这样想的。我使用增量备份来备份照片、文档或项目文件和经常编辑的文件夹。我会使用完全备份来备份整个服务器或磁盘。差异备份用于备份完整文件夹，如 /etc、/opt 和日志文件夹。

现在该如何存储呢？如果您遵循 3-2-1 原则，您就会如虎添翼。3 份数据副本、2 种存储类型和 1 个异地备份。我想说的是，如果这看起来太多，那么 “异地 “存储是最重要的，不能省略。万一发生灾难性的数据崩溃，拥有一个带有备份的硬盘是非常宝贵的。异地/离线备份还能让您免受勒索软件的威胁。因此，请牢记这一点。现在有大量的备份软件。我使用 Sync-thing、Borg 备份和老式 FTP 的组合。

请记住，备份、日志和服务器监控是一个根据您的需求不断发展的过程。您实施的具体策略应符合您的需求和数据的关键性。

Basic Network Safety

保护服务器安全的下一步是锁定那些不需要暴露在互联网上的端口，并禁止那些在不应该登录的情况下尝试登录的东西。UFW 和 Fail2Ban 是目前广泛使用的两种工具。它们简单易用，UFW 可让你为端口设置流量规则，而 Fail2Ban 则会在 IP 地址进入不应进入的端口或在某些预定义规则后仍无法登录时将其封禁。UFW 或不复杂的防火墙通常会预装在许多 VPS 服务中，Fail2Ban 也是如此，但如果你使用的是新机器且不确定，请运行：

sudo apt install ufw

sudo apt install fail2ban

UFW

关于 Fail2Ban，我们稍后再讨论，现在让我们重点讨论 UFW 设置。首先运行一些默认策略：

sudo ufw default deny incoming
 
sudo ufw allow outgoing

这被认为是最佳做法，因为它遵循了我前面提到的 “最少权限 “理念。它减少了机器的攻击面，让你可以精确控制暴露的内容。简而言之，这种配置在安全性和功能性之间取得了平衡。你的服务器可以根据需要接入互联网，但外部实体只能通过你明确允许的方式连接到你的服务器。现在，让我们允许一些东西进入。

sudo ufw allow ssh
sudo ufw allow 80
sudo ufw allow 443

如果要运行网络服务器，则需要打开 80 端口和 443 端口。80 端口用于 HTTP，443 端口用于 HTTPS。默认情况下，22 端口是 SSH，如果更改了端口，则需要指定端口，而不是使用 “allow ssh “命令。下面是其他一些有用的命令：

#List rules with numbers:
sudo ufw status numbered
#Delete by number:
sudo ufw delete NUMBER
#Delete by rule specification:
sudo ufw delete allow 80
#You can allow connections from specific IP addresses:
sudo ufw allow from 192.168.1.100
#You can also only allow an IP to connect to a specfic port with: 
sudo ufw allow from 192.168.1.100 to any port 22
#If you neeed to allow a range of ports: 
sudo ufw allow 6000:6007/tcp
#To further protect from brut force attacks you can rate limit specific ports with: 
sudo ufw limit ssh
#This would limit port 22 to 6 connections in 30 seconds from a single IP. To see the status of the firewall you can use: 

#Adding this goves you more info
sudo ufw status verbose
#and to reset incase you need to start over: 
sudo ufw reset
#and to enable and disable: 
sudo ufw enable 
sudo ufw disable 

#finaly to enable logging and adjusting the log level: 
sudo ufw logging on
sudo ufw logging medium # levels are low, medium, high, full

现在开始 Fail2Ban。

Fail2Ban

主要配置文件位于 /etc/fail2ban/jail.conf，但建议创建本地配置文件：

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

jail.local 部分的[DEFAULT]部分有一些基本设置，它们是

bantime = 10m
findtime = 10m
maxretry = 5

封禁时间是指 IP 被封禁的时间。查找时间是 Fail2Ban 寻找重复失败的时间范围，最大重试次数是 IP 被禁用前的失败次数。您可以根据需要调整这些参数。您还可以设置自定义封禁，Fail2Ban 也支持 SSH 等常用服务的封禁。您还可以采取更多步骤，但我认为这已经涵盖了基本内容。

NGINX

您可以使用的网络服务器有很多。Apache, Caddy, nginx, IIS 等等。我使用 Nginx。这是我所熟悉的，而且它运行得非常好。Nginx（发音为 engine-x）是一个网络服务器、反向代理和负载平衡器。作为 Web 服务器，它擅长提供静态内容，并能以相当低的资源占用率处理大量并发连接。作为反向代理，它可以位于应用程序服务器之前，将流量转发给它们，同时确保应用程序的安全。它的负载平衡功能可有效平衡服务器之间的流量，提高可靠性和可扩展性。

通过 apt 安装时，nginx 的默认位置是 /etc/nginx/，nginx.conf 主要用于全局服务器配置，包括 /etc/nginx/sites-enabled 文件夹中的文件。这种模块化结构便于管理多个站点。需要注意的两个文件夹是 sites-enabled 文件夹和 sites-available 文件夹。您可以将可用站点视为测试站点配置的暂存区，而启用站点则用于实时站点和应用程序。常见的做法是在可用站点中的站点中设置和测试配置，然后当你准备上线并获得 SSL 证书时，将文件链接到启用站点文件夹。具体方法如下

ln -s /etc/nginx/sites-available/yoursitefile /etc/nginx/sites-enabled

然后重新加载nginx，并再次检查nginx状态：

sudo systemctl reload nginx

sudo systemctl status nginx

您的网站现在应该已经上线。

下面，我将向您展示一些模板化的 Nginx 网站配置。请务必考虑您的应用程序或网站需求，因为这些只是起点。对于静态网站，这是一个不错的起点。

基本静态网站配置：

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/html;
    index index.html index.htm;
    location / {
        try_files $uri $uri/ =404;
    }
    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

    # Logging
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log warn;

    # SSL configuration (uncomment after running Certbot)
    # listen 443 ssl http2;
    # listen [::]:443 ssl http2;
    # ssl_protocols TLSv1.2 TLSv1.3;
    # ssl_prefer_server_ciphers on;
    # ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # Certbot will add its own SSL certificate paths
    # ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    # ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

代理通行证配置：

server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

    # Logging
    access_log /var/log/nginx/app.example.com.access.log;
    error_log /var/log/nginx/app.example.com.error.log warn;

    # SSL configuration (uncomment after running Certbot)
    # listen 443 ssl http2;
    # listen [::]:443 ssl http2;
    # ssl_protocols TLSv1.2 TLSv1.3;
    # ssl_prefer_server_ciphers on;
    # ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # Certbot will add its own SSL certificate paths
    # ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    # ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
}

WebSocket 升级配置：

server {
    listen 80;
    listen [::]:80;
    server_name ws.example.com;
    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

    # WebSocket timeout settings
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
    # Logging
    access_log /var/log/nginx/ws.example.com.access.log;
    error_log /var/log/nginx/ws.example.com.error.log warn;

    # SSL configuration (uncomment after running Certbot)
    # listen 443 ssl http2;
    # listen [::]:443 ssl http2;
    # ssl_protocols TLSv1.2 TLSv1.3;
    # ssl_prefer_server_ciphers on;
    # ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # Certbot will add its own SSL certificate paths
    # ssl_certificate /etc/letsencrypt/live/ws.example.com/fullchain.pem;
    # ssl_certificate_key /etc/letsencrypt/live/ws.example.com/privkey.pem;
}

基本配置用于为简单的静态网站提供服务。它指定了域名，IPv4 和 IPv6 都使用 80 端口监听，设置了网站的根目录，使用 try_files 配置了错误处理，添加了一些防止常见网络漏洞的基本标头，设置了访问和错误日志，还包括一个注释掉的 SSL 部分。大部分 SSL 配置将由 certbot 处理，但其中有几行添加了一些 SSL 安全性，可以在运行 certbot 后取消注释。

代理通行配置与基本配置类似，但它不是直接提供文件，而是将请求代理到本地应用程序（在本例中，运行于 3000 端口）。

第三个配置文件面向需要网站连接的应用程序，它与代理通行证配置很相似，只是在允许网络套接字方面做了一些改动。

如果不谈 SSL，任何有关网络服务器的内容都是不完整的。对于普通用户来说，certbot 是他们最好的朋友。它免费，速度快，还他妈的好用。我使用的是 python 版本的 certbot。安装方法如下：

sudo apt install certbot python3-certbot-nginx

安装完成后，你只需在终端运行 “certbot”，它就会检测你的站点启用文件夹中的配置，并询问你要做什么（续费、重发等……）。按照 certbot 提供的步骤操作就可以了，非常简单。

因此，现在 certbot 在获取新证书时会为你设置自动续费，所以这只是个 “坐等 “任务。但为了确保成功，你可以运行

如果运行正常，使用 systemd 的用户就可以放心使用了。

Quality Of Life Tools

关于 “让系统管理更轻松的工具 “这个话题，我将介绍一些我在服务器上使用的工具，我认为它们能让管理变得更轻松。我不会深入介绍任何工具。所有这些都是可选的，没有特定的顺序。其中很多都是我在网站上找到的，如果你和我一样是个终端迷，那么这个网站很值得浏览。

第一个工具，这是我的个人必备清单。Btop 是一款资源终端监控器。它能实时显示电脑的 CPU、内存、磁盘、网络和运行附魔的可视化使用统计信息，它由 C++ 编写，可通过大多数软件包管理器安装。

对于有大量外部连接的服务器（如 nostr 中继站），类似的工具很有帮助。Neoss 的目标是取代常用的 ss 命令，满足基本使用需求。它提供了一个使用中的 TCP 和 UDP 套接字列表及其各自的统计信息。与 SS 原始输出相比，它的主要优势在于清晰简洁的 TUI（终端用户界面），允许你对连接到机器的内容进行排序、刷新和导航。它通过 NPM 安装，这意味着你需要安装 JavaScript。

是一款基于终端的网络服务器日志分析器。它非常适合在终端上快速实时查看日志，还能实时生成 HTML、JSON 和 CSV 报告。GoAccess 可通过大多数软件包管理器安装，适用于所有平台。

接下来要介绍的是 Its，它是一款功能强大的基于文本的文件管理器，具有双面显示屏和许多操作文件和目录的功能。它还具有跨平台特性，可通过大多数软件包管理器进行安装。

与服务器文件管理同属一个主题的是 .NET Framework。这是我的必备清单。它是一款磁盘使用分析器，专门用于查找占用空间的文件。它运行速度快，操作简单。它可以安装在大多数系统和软件包管理器上。Windows 需要安装 Linux 子系统才能使用它。

希望你能从中找到一些有用的东西。我想谈的最后一个话题是 DNS，这是个比较大的话题，所以我不会做大规模的深入探讨，但如果你是自助托管，掌握一些 DNS 的基本知识还是有帮助的。

DNS

DNS 或域名系统是我们所熟知的互联网运作方式的核心部分。不管你喜欢还是讨厌，如果你想访问更广泛的互联网，我们就必须使用它。(我不喜欢它现在的样子，但我不会在这里说这个）。基本上，把 DNS 想象成电话簿。它可以让你在每次需要搜索互联网时输入 duckduckgo.com，而不是 “52.250.42.157”。它将人类容易记住的东西转化为计算机所需的信息，从而真正到达 “duckduckgo.com”。

如果您使用的是 VPS 主机，您唯一需要知道的就是在决定使用某个域名后，如何将 A 记录指向您的服务器 IP。几乎所有的 VPS 主机都可以为你提供一个静态 IP，所以这主要是一种设置和遗忘类型的交易。

在家托管会遇到一些挑战。一个突出的问题是（我经常听到的一个有效问题）没有静态 IP 地址。如今，由于需要 IP 地址的在线设备数量众多，我们要做的事情很多，而且大多数 IP 地址都是动态分配的，除非你从 ISP 付费购买。但还是有解决办法的。这就是动态 DNS 或 DDNS。每当 IP 地址发生变化时，DNS 服务器就会自动更新。设置动态 DNS 的方法多种多样。您可以托管自己的服务或使用主机。下面是一些主机和项目的链接，可供参考。

简而言之，它是这样工作的。你可以选择一个服务提供商，也可以自己设置。你可以获得一个域名，将客户端安装在家庭路由器或服务器上，客户端会定期检查 IP 地址是否发生变化，如果发生变化，它就会更新该域名的 DNS 记录。

Docker

在这里我不会介绍如何安装 docker。无论如何，最好还是按照官方的安装指南来安装。但我想谈几点。首先，docker 在测试新应用程序时非常有用。但我认为也仅此而已。我个人不太喜欢使用 docker，而是尽可能直接运行应用程序。以下是一些值得注意的利弊。

优点

如果你的系统可以运行 docker，你就可以运行大多数 docker 应用程序。它有助于隔离，减少应用程序之间的冲突。在某些情况下，它可以帮助提高效率，因为它比传统的虚拟机占用更少的资源。微服务架构也很有用，因为它可以将应用程序分解成更小的可管理服务，从而实现服务的独立扩展。最后，该社区规模庞大，文档完善，社区支持总是很有帮助，而且还有大量现成的 docker 映像可供部署。

缺点

首先是开销。虽然它比传统的虚拟机要好，但它比直接在主机上运行要耗费更多的资源，而且输入/输出操作可能会更慢。docker 共享系统内核的事实意味着，一个受损的应用程序可能会影响系统。持久化数据是可行的，但增加了一层复杂性，可能会导致新用户的数据丢失，也会使备份变得更加复杂。使用 docker 时，网络连接也会变得更加复杂，因此不会那么简单。值得注意的是，如果使用 UFW 或 firewalld 作为防火墙，docker 会绕过这些规则。Docker 只与 iptables 兼容。此外，管理良好的 docker 容器有助于管理服务器资源，但管理不当也会对资源造成损害。容器可能会变得过大，从而影响磁盘大小，而错误的配置则会占用过多的服务器资源。在监控和调试应用程序时，尤其是跨多个容器时，它还会增加额外的复杂性。

总结

好了，关于服务器设置和工具的基础知识就介绍到这里。有一个工具可以帮你完成大部分工作。我写它是为了让自己的服务器设置更快。你可以在这里获得它，它包含了我所有的必备工具，并做了一些基本配置。请根据自己的需要进行调整，并一如既往地注意安全。

原文

[1] Server Setup Basics

拥抱Follow

Mon, 09 Sep 2024 23:21:54 +0800

follow认证信息，欢迎关注订阅

This message is used to verify that this feed (feedId:55939235463397383) belongs to me (userId:55938341809190912). Join me in enjoying the next generation information browser https://follow.is.

搭建 CouchDB 数据库

Wed, 11 Oct 2023 17:54:00 +0800

记录一下 CouchDB 搭建流程，用于同步 MoonFM、Obsidian

很早之前就购买了 MoonFM，但是鉴于没有自带同步服务，所以一直使用 Spotify 听播客。现在终于忍不了这种音乐和播客混在一起，乱七八糟的感觉了，因此抽空研究了 MoonFM 使用的 Couchdb 数据库同步方案，实现了自建同步服务。同时也刚好一并将 Obsidian 的同步服务从Remotely save迁移到了obsidian-livesync，实现了更好的同步体验！

Docker 安装 CouchDB

首先需要创建一个 data 文件夹和一个 local.ini 用于 docker 内部文件夹和配置文件的映射。其中 local.ini 如下：

[couchdb]
single_node=true

[chttpd_auth]
require_valid_user = true
authentication_redirect = /_utils/session.html

[httpd]
WWW-Authenticate = Basic realm="couchdb"
enable_cors = true

[cors]
origins = capacitor://localhost,http://localhost
credentials = true
headers = accept, authorization, content-type, origin, referer
methods = GET, PUT, POST, HEAD, DELETE
max_age = 3600

[couch_peruser]
database_prefix = userdb_
delete_dbs = false
enable = true

docker-compose 文件如下，需要自己修改一下映射端口，账号密码等：

version: "3"
services:
couchdb:
ports:
  - "5984:5984"
volumes:
  - "./data:/opt/couchdb/data"
  - "./local.ini:/opt/couchdb/etc/local.ini"
environment:
  - COUCHDB_USER=管理后台账户名
  - COUCHDB_PASSWORD=管理后台密码
restart: always
network_mode: bridge
container_name: couchdb
image: couchdb

然后使用docker-compose up -d启动 docker

数据库管理

通过http://IP地址:端口号/_utils/访问数据口后台，账号密码就是上一步自己定义的密码。

页面中就可以创建并管理自己的数据库和用户，但是我更习惯使用命令行进行管理：

以 MoonFM 同步数据库创建为例，依次执行下面的命令即可：

创建用户

curl -X PUT http://管理后台账户名:管理后台密码@IP地址:端口号/_users/org.couchdb.user:用户账号名
-H "Accept: application/json"
-H "Content-Type: application/json"
-d '{"name": "用户账号名", "password": "用户密码", "roles": [], "type": "user"}'

创建数据库

curl -X PUT http://管理后台账户名:管理后台密码@IP地址:端口号/数据库名

添加用户到数据库

curl -X PUT http://管理后台账户名:管理后台密码@IP地址:端口号/数据库名/_security
-H "Accept: application/json"
-H "Content-Type: application/json"
-d '{"admins": {"names": [], "roles": []}, "members": {"names": ["用户账号名"], "roles": []}}'

获得的同步链接如下：

http://用户账号名:用户账号密码@IP地址:端口号/数据库名

这里需要注意区分 curl 参数填入的管理后台账户名密码和数据库用户名密码

此后还可以进行反向代理等操作，这里可以参考使用 Nginx 实现多服务复用端口

fly.io 搭建免费 CouchDB 数据库

未完待续

Google One VPN 愉快玩耍指南

Fri, 24 Feb 2023 20:22:43 +0800

Google 取消了 Google One 订阅用户的 VPN 功能，本文已实质性失效

更新 三月份开始，谷歌又对检测方式进行了更改，要求域名（*.googleapis.com）和原本的检测服务器来自同一区域 IP，否则将一直提示VPN连接中断 因此需增加将此网址加入检测分流中，见先连接上章节

机制说明

首先，要想愉快使用，需要明确 Google One VPN 的以下几点机制：

目前仅 Android 手机可以正常连接。（当然如果你在 iPhone 上使用境外卡或使用 Android 虚拟机依然是可以的，但此不在本文讨论范围）
该服务仅在如下国家提供（且对于大陆来说，通常只有部分地区有实用性）：

- 奥地利
- 澳大利亚
- 比利时
- 加拿大
- 丹麦
- 芬兰
- 法国
- 德国
- 冰岛
- 爱尔兰
- 意大利
- 日本
- 墨西哥
- 荷兰
- 挪威
- 韩国
- 西班牙
- 瑞典
- 瑞士
- 台湾
- 英国
- 美国

基于第 2 点，即使真正的服务器可以直连，那么我们也需要先欺骗 IP 检测服务器，具体机制如下：

准入 IP 限制" >

准入 IP 限制

即便通过了第 3 点连接上服务器后，Google 依然还会在你每使用 1G 流量的后，再次对你的原始 IP 进行检测。如果此时检测到你的 IP 不在上述地区了，就会强制断开 VPN 连接。

因此，不仅在于连上，还要避免 1G 断开，才叫做愉快玩耍！So,go on…

先连接上

想要连接上，其实不难，从上面的内容就可以看出，只需要使用受支持地区的 IP 欺骗检测服务器就可以了。并且，检测服务器的地址是固定的，后缀如下：

*.cloud.cupronickel.goog
*.googleapis.com

于是，我们需要在代理工具（如 clash for android）中，将此连接加入代理清单即可。

如果你使用 rule-provider，那么可以如下写规则：

payload:
- DOMAIN-SUFFIX,cloud.cupronickel.goog
- DOMAIN-SUFFIX,googleapis.com

手机通过代理后，即可使用 Google One app 成功连接上对应地区的 Google One VPN 服务器

再共享出来

等手机连接上后，那么你可以使用诸如 everyproxy 这样的软件在手机上开启 HTTP 或者 socks 代理，分享给局域网的其他设备使用。

愉快使用

经过上面两步，你其实已经可以正常使用 VPN 了，但是前面说到了，每当你使用了 1G 流量，Google 会再次检测你的 IP，这样你就会掉线。因为手机上只能同时开启一个 VPN 软件，所以 clash 此时没有代理这个检测服务器流量了。

你有软路由？

如果你有软路由的话，那一切都简单很多。以 opeclash 为例：

首先，同样将上面检测服务器加入代理，并一直保持代理
将手机共享出来的 socks 代理或和 HTTP 代理作为一个节点加入文件文件中，如这样：

  - name: "🪜 GoogleOne"
    type: socks5
    server: 192.168.XXX.XXX
    port: 1080

为了避免嵌套代理，请添加 VPN 服务器 IP 端到新的 rule-provider 中：

  - '136.22.64.0/24'
  - '136.22.65.0/24'
  - '136.22.67.0/24'
  - '136.22.76.0/24'
  - '136.22.83.0/24'
  - '136.22.85.0/24'
  - '136.22.86.0/24'
  - '136.22.87.0/24'
  - '136.22.92.0/24'
  - '136.22.93.0/24'
  - '136.22.94.0/24'
  - '136.22.95.0/24'
  - '136.22.96.0/24'
  - '136.22.97.0/24'
  - '136.22.98.0/24'
  - '136.22.99.0/24'
  - '136.22.100.0/24'
  - '136.22.101.0/24'
  - '136.22.102.0/24'
  - '136.22.103.0/24'
  - '136.22.104.0/24'
  - '136.22.105.0/24'
  - '136.22.106.0/24'
  - '136.22.107.0/24'
  - '136.22.108.0/24'
  - '136.22.109.0/24'
  - '136.22.110.0/24'
  - '136.23.1.0/24'
  - '136.23.2.0/24'
  - '136.23.3.0/24'
  - '136.23.4.0/24'
  - '136.23.5.0/24'
  - '136.23.6.0/24'
  - '136.23.7.0/24'
  - '136.23.8.0/24'
  - '136.23.9.0/24'
  - '136.23.10.0/24'
  - '136.23.11.0/24'
  - '136.23.12.0/24'
  - '136.23.13.0/24'
  - '136.23.14.0/24'
  - '136.23.15.0/24'
  - '136.23.16.0/24'
  - '136.23.17.0/24'
  - '136.23.18.0/24'
  - '136.23.19.0/24'
  - '136.23.20.0/24'
  - '136.23.21.0/24'
  - '136.23.22.0/24'
  - '136.23.23.0/24'
  - '136.23.24.0/24'
  - '136.23.25.0/24'
  - '136.23.26.0/24'
  - '136.23.27.0/24'
  - '136.23.28.0/24'
  - '136.23.29.0/24'
  - '136.23.30.0/24'
  - '136.23.31.0/24'
  - '136.23.32.0/24'
  - '136.23.33.0/24'
  - '136.23.34.0/24'
  - '136.23.35.0/24'
  - '209.107.176.0/24'
  - '209.107.177.0/24'
  - '209.107.178.0/24'
  - '209.107.179.0/24'
  - '209.107.180.0/24'
  - '209.107.181.0/24'
  - '209.107.182.0/24'
  - '209.107.183.0/24'
  - '209.107.184.0/24'
  - '209.107.185.0/24'
  - '209.107.186.0/24'
  - '209.107.187.0/24'
  - '209.107.188.0/24'
  - '209.107.189.0/24'
  - '209.107.190.0/24'
  - '209.107.191.0/24'

可以更加精确的将协议限定为 UDP（虽然实际上也只会走 UDP）

script:
    shortcuts:
      GoogleVPNbypass: match_provider('GoogleVPNbypass') and network == 'udp'

并将其加入直连：

  - SCRIPT,GoogleVPNbypass,🚀 直接连接

至此，你每使用 1G 流量，由于你的前置代理一直都在，也不会掉线。并且通过将其作为节点，可以更加灵活的控制分流规则。

没有软路由？

那也没关系，你可以在电脑上使用 clash for windows 实现类似的效果（其他设备也一样，如 iPhone 上的 stash）。思路如下：

clash for windows 的配置文件里要对代理检测服务器进行代理
手机 WiFi 代理中设置电电脑 IP 以及 7890（clash 默认代理地址）
在 clash for windows 配置文件里面新增一个 http 或者 socks 代理地址就是手机 IP 和 every proxy 共享出来的 http 或 socks 端口

你只有安卓？

抱歉，目前我还没有发现如何避免断开的方法。但是你可以使用如下两种方式，出门外面的时候也能仅使用单设备连接上 VPN。

方法 1：

1. clash-设置-网络-关闭 自动路由系统流量
2. 打开clash开关 global选项卡选择一个支持的国家，例如美国，日本，台湾等
3. WiFi-设置-高级-代理-服务器写入127.0.0.1 端口填入7890 排除项填入 1.com
4. 开启Google One VPN
5. 成功后 clash global 选择direct
6. WiFi-高级设置-代理 修改 排除项1.com为任意 比如1.cn。没有排除选项的会造成网页无法打开

方法 2：

1. clash-设置-网络-关闭 自动路由系统流量
2. clash 挂一个支持的国家，例如美国，日本，台湾等。只用代理模式，不要用全局模式。
3. 在数据卡的设置里，设置一个新的 APN ，把 APN 的代理服务器里面设置为 127.0.0.1:7890
4. 直接用 Google one VPN 连接成功，成功后打开 wifi 和关闭 clash 均能保持连接状态

注意：连接成功后记得把clash设置为直连模式，且不可切换APN或关闭clash

参考

开始使用 Google One VPN

Wi-Fi 7 物理层解读

Fri, 20 Jan 2023 11:20:05 +0800

Wi-Fi 7 物理层变化总结

PHY 变化

以目前的 802.11be Draft 1.0 版本为蓝本，Wi-Fi 7 相比 Wi-Fi 6 在技术上没有根本性的改变，主要是在原来的基础上对以下特性进行了加强或改进：

6GHz 频段和 320MHz 带宽
4K QAM 调制
增强 MIMO
MLD（MLO 的基础）
OFDMA 改进

下两图展示了 WiFi 发展历程中重要的参数信息的变化：

6GHz&320MHz

6GHz 的频段并非 Wi-Fi 7 首次采用（由 Wi-Fi 6E 引入），但是 Wi-Fi 7 在此基础上将 Wi-Fi 6/6E 最大单信道宽带由 160MHz 提升到了 320MHz 。

6GHz

随着 6GHz 频段的引入，未来 Wi-Fi 的频段一共将有三部分组成，如下图所示：

具体到 6GHz 的位置，其可容纳的信道数量如下：

新的 6GHz 频段 (5925-7125 MHz)，宽度为 1.2 GHz，可容纳 3 或 6 个 320MHz 的频带，4 个 240MHz 的频带，7 个 160MHz 的频带，或 14 个 80MHz 的频带。支持首选扫描信道 (PSC) 的通道 (5, 21, 37, 53, 69, 85, 101, 117, 133, 149, 165, 181, 197) , 进行快速被动扫描。

320MHz

320MHz信道化: 由6GHz的任意2个连续160MHz组成，包含2种类型：

320MHz-1（信道号为 31, 95, 159）
320MHz-2（信道号为 63, 127, 191）

冲突

虽然一些国家和地区（如美国和欧盟）已经批准 6GHz 中或宽或窄的频段用于 Wi-Fi，但采用 6GHz 也需要考虑如下几种场景可能占用 6GHz 带来冲突：

5G NR-U（5G New Radio in Unlicensed Spectrum）在 3GPP R16 版本里定义，5G 空中接口可工作于免许可频段。在一些地区，如美国，NR-U 也将被用于部署在 6GHz 频段的服务。此外，基于 NR-U Sidelink 的 C-V2X 服务如果部署，也会占用 6GHz 部分频宽。
美国已经划分了 5.9GHz 的 20MHz 给 5G C-V2X，部署需要考虑共存问题。
2023 年世界无线大会 WRC-23 将会讨论是否将 6GHz 频谱授权给 6G。

4K-QAM

为什么要有 QAM？

QAM 在用于 Wi-Fi 数字信号调制时，与普通幅度调制和相位调制相比能得到更高的速率。因为幅度调制和相位调制仅有 2 种符号（symbol）来区分 0 或 1。

幅度调制：通过改变载波的振幅来区分 0 和 1。
相位调制：通过改变载波的相位来区分 0 和 1。例如我们常见的 BPSK，就是使用 0° 和 180° 共 2 个相位表示 0 和 1，即 2 种符号；QPSK 则是使用 0°、90°、180° 和 270° 共 4 个相位，能够表示 00、01、10 和 11 共 4 种符号，传递 2 bit 的信息。其实 QPSK 就是一种特殊的 QAM，即 4-QAM。

而 QAM 则有更多的符号，每个符号都有相应的相位和幅度值。

以 16-QAM 为例，通过 QAM 调制可得到 16 个不同的波形，分别代表 0000，0001…. 这也意味着一共有 16 种符号，一个符号可以传递 4 bit 信息。

16-QAM示意图" >

16-QAM示意图

QAM 是如何工作的？

QAM 是将信号加载到 2 个正交的载波上（通常是正弦和余弦），通过对这两个载波幅度调整并叠加，最终得到相位和幅度都调制过的信号。这两个载波通常被称为 I 信号，另一个被称为 Q 信号，所以这种调制方式也被称为 IQ 调制。

IQ 调制" >

IQ 调制

由于 QAM 最终调制后的信号包含了相位和幅度的变换，因此 QAM 也被认为相位调制和幅度调制的组合。

QAM 的星座图

在数字信号调制中，星座图通常用于表示 QAM 调制二维图形。星座图相对于 IQ 调制而言，将数据调制信息映射到极坐标中，这些信息包含了信号的幅度信息和相位信息。

星座图上的每一个点，都表示一个符号。该点 I 轴和 Q 轴的分量分别代表着正交的载波上的幅度调整。该点到原点的距离 A 就是调制后的幅度，夹角 φ 就是调制后的相位。

而星座图上点的数量，决定了每个符号传输的比特数。例如：

256-QAM，256 是 2 的 8 次方，每个符号能传输 8bit 的数据。
1024-QAM，1024 是 2 的 10 次方，每个符号能传输 10bit 的数据。
4096-QAM，4096 是 2 的 12 次方，每个符号能传输 12bit 的数据。

因此，作为比 Wi-Fi 6 1024-QAM 更高阶的 4096-QAM，数据传输的峰值速率进一步提高 20%。

QAM 对 Wi-Fi 标准速率影响

在 Wi-Fi 标准中，定义了调制和编码方案 MCS（Modulation and Coding Scheme）。MCS 对应一组调制和编码方式。以 Wi-Fi 6 为例，MCS 索引有 12 个。

Wi-Fi 6 中 MCS 索引对应的调制方式以及编码率" >

Wi-Fi 6 中 MCS 索引对应的调制方式以及编码率

如果 MCS 为 1，则使用的是 QPSK 的调制方式；如果 MCS 为 11，则使用的是 1024 的调制方式。对于每个 MCS 的索引值，根据信道带宽、空间流数和保护间隔（Guard Interval，GI）可以计算出不同的速率。计算公式如下：

Wi-Fi 标准的速率计算公式" >

Wi-Fi 标准的速率计算公式

代价

尽管较高阶的调制速率能够为无线电通信系统提供更快的数据速率和更高水平的频谱效率，但这是有代价的。较高阶的调制方案对噪声和干扰的适应性要差得多。

因为发送一个符号所用的载波频宽是固定的，发送时长也是一定的，较高阶意味着两个符号之间差异就越小。这不仅对接收双方的器件要求很高，而且对环境的要求也很高。也就是说，如果环境过于恶劣，终端将无法使用高阶的 QAM 模式通信，只能使用较低阶次的调制模式。

4K-QAM 对信号的 EVM 要求已经到了 -38dB 了，已经是一个非常高的要求了

MIMO 增强

在 Wi-Fi 6 里面，最大的空间流是 8×8，在 Wi-Fi 7 里面，最大空间流提升到了 16×16。不过需要注意一点的是，这个空间流实际上是跑的 MU-MIMO，而不是单纯的 MIMO，实际里面终端部分不会有那么多的天线链路。

MLD

MLD（Multi-Link Device）其实是MLO在物理层（PHY）的体现，传统的WiFi仅仅包含单个链路的连接能力，MLD能够允许一块IC里面包含多个device的连接能力。在之前部分厂商已经具备并实现该技术，如QCA的DBS以及MTK的DBDC，落实到具体的功能为双WiFi技术。

下图为传统的芯片结构，由两个独立的RF前端，一个基带处理部分，然后对应到上层接口，该方案只可以做到双频单发（DBSC）。

改进后的芯片结构大致如下图，由两个独立的 RF 前端，这两个独立的 RF 前端对应到两个独立的基带处理，然后对应到上层接口，因此可以在一块 IC 内部，做到两个频段同时连接，即双频双发（DBDC）。

802.11be对MLD部分做了一些改动，一个MLD设备由多个AP或者多个STA组成，并且引入新的MAC来标识MLD设备。新增的功能总结大致如下三点：

多链路发现和设置：MLD具有能够动态更新每对链路上同时进行帧交换的能力。每个单独的AP/STA还可以提供关于同一MLD内其他附属AP/STA的操作参数的信息。
流量链路映射：在多链路集里面，对数据帧进行分类的服务质量（QoS）标识符（TID）会映射到所有链路中。该映射会被MLD下所有链路协商更新。此外，MLD接收方将利用buff缓存对多个链路传输的相同TID的QoS数据帧进行重排。
信道访问和节省功率：MLD的每个AP/STA都会通过它自己所在链路频段接入信道，并独自维护其自身的功率状态。为了更有效的对STA功率管理，AP还可以利用多条链路中已连接的其中一条链路，通过缓冲数据来通知其他链路的功率调整。

OFDMA 增强

RU

OFDMA 允许同时提供具有不同带宽需求的多个用户，从而有效利用可用频谱。子载波被分成若干组，每组表示为具有最小尺寸为 26 个子载波（2MHz 宽）和最大尺寸为 996 个子载波（77.8MHz 宽）的资源单元（RU）。

前导码打孔 & MRU

假设 S20 被雷达信号占用：

Wi-Fi 6，STA 只能使用 P20 传输信号，40MHz 带宽被浪费
Wi-Fi 7，允许分配打孔 RU 组成 MRU，STA 可以使用 60MHz 带宽

打孔的类型：1. 静态打孔（建立 BSS 时打孔）；2. 动态打孔（传输 PPDU 时，在静态打孔的基础上，打孔附加的信道） 80MHz 允许打孔 20MHz 信道，160MHz 允许打孔 20/40MHz，320MHz 允许打孔 40/80/80+40MHz

Wi-Fi 7 支持在 EHT PPDU 中使用 MRU，以获得更高的频谱效率，实际上 MRU 就是支持多种 tone 根据需要进行组合，使得 RU 分配更加灵活，减小延迟。

参考

[1] Key Advantages of Wi-Fi 7 MediaTek Whitepaper

Wi-Fi 7 概述

Fri, 20 Jan 2023 11:03:05 +0800

Wi-Fi 7 变化的总结

Wi-Fi 7 的发布时间

IEEE 802.11be EHT 工作组已于 2019 年 5 月成立，802.11be（Wi-Fi 7）的开发工作仍在进行中，整个协议标准将按照两个 Release 发布，Release1 预计在 2021 年将发布第一版草案 Draft1.0，预期在 2022 年底发布标准；Release2 预计在 2022 年初启动，并且在 2024 年底完成标准发布。

会议进程" >

会议进程

Wi-Fi 7 vs Wi-Fi 6

特性对比" >

特性对比

Wi-Fi 7 支持的新特性

Wi-Fi 7 协议的目标是将 WLAN 网络的吞吐率提升到 30Gbps，并且提供低时延的接入保障。为了满足这个目标，整个协议在 PHY 层和 MAC 层都做了相应的改变。相对于 Wi-Fi 6 协议，Wi-Fi 7 协议带来的主要技术变革点如下：

新频段

相比 Wi-Fi 6，7 引入了 6GHz 频段（6e 也有），上下限分别为 5.925 —— 7.125 GHz：

频段说明" >

频段说明

支持最大 320MHz 带宽

2.4GHz 和 5GHz 频段免授权频谱有限且拥挤，现有 Wi-Fi 在运行 VR/AR 等新兴应用时，不可避免地会遇到 QoS 低的问题。为了实现最大吞吐量不低于 30Gbps 的目标，Wi-Fi 7 将继续引入 6GHz 频段，并增加新的带宽模式，包括连续 240MHz，非连续 160+80MHz，连续 320 MHz 和非连续 160+160MHz。

支持 Multi-RU 机制

在 Wi-Fi 6 中，每个用户只能在分配到的特定 RU 上发送或接收帧，大大限制了频谱资源调度的灵活性。为解决该问题，进一步提升频谱效率，Wi-Fi 7 中定义了允许将多个 RU 分配给单用户的机制。当然，为了平衡实现的复杂度和频谱的利用率，协议中对 RU 的组合做了一定的限制，即：小规格 RU（小于 242-Tone 的 RU）只能与小规格 RU 合并，大规格 RU（大于等于 242-Tone 的 RU）只能与大规格 RU 合并，不允许小规格 RU 和大规格 RU 混合使用。

引入更高阶的 4096-QAM 调制技术

Wi-Fi 6 的最高调制方式是 1024-QAM，其中调制符号承载 10bits。为了进一步提升速率，Wi-Fi 7 将会引入 4096-QAM，使得调制符号承载 12bit。在相同的编码下，Wi-Fi 7 的 4096-QAM 比 Wi-Fi 6 的 1024-QAM 可以获得 20% 的速率提升。

引入 Multi-Link 多链路机制

为了实现所有可用频谱资源的高效利用，迫切需要在 2.4 GHz、5 GHz 和 6 GHz 上建立新的频谱管理、协调和传输机制。工作组定义了多链路聚合相关的技术，主要包括增强型多链路聚合的 MAC 架构、多链路信道接入和多链路传输等相关技术。

支持更多的数据流，MIMO 功能增强

在 Wi-Fi 7 中，空间流的数从 Wi-Fi 6 的 8 个增加到 16 个，理论上可以将物理传输速率提升两倍以上。支持更多的数据流也将会带来更强大的特性——分布式 MIMO，意为 16 条数据流可以不由一个接入点提供，而是由多个接入点同时提供，这意味着多个 AP 之间需要相互协同进行工作。

支持多 AP 间的协同调度

目前在 802.11 的协议框架内，AP 之间实际上是没有太多协作的关系。自动调优、智能漫游等常见的 WLAN 功能都属于厂商自定义的特性。AP 间协作的目的也仅是优化信道选择，调整 AP 间负载等，以实现射频资源高效利用、均衡分配的目的。Wi-Fi 7 中的多 AP 间的协同调度，包括小区间的在时域和频域的协调规划，小区间的干扰协调，以及分布式 MIMO，可以有效降低 AP 之间的干扰，极大的提升空口资源的利用率。

多 AP 间的协同调度的方式有很多，包括 C-OFDMA（Coordinated Orthogonal Frequency-Division Multiple Access）、CSR（Coordinated Spatial Reuse）、CBF（Coordinated Beamforming）和 JXT（Joint Transmission）等。

Ubuntu LVM 磁盘扩容指南：以 Hyper-V 为例

Thu, 02 Sep 2021 11:25:59 +0800

详细介绍如何在 Hyper-V 环境下为 Ubuntu 虚拟机扩展 LVM 磁盘空间

前置条件

Hyper-V 虚拟机运行 Ubuntu 系统
使用 LVM（Logical Volume Management）进行磁盘管理
具有 root 或 sudo 权限

快速操作指南

对于熟悉 LVM 的用户，以下是扩容的快速步骤：

检查当前分区：fdisk -l
启动分区工具：parted
扩展分区：resizepart，选择分区 3，输入 100%
扩展物理卷：pvresize /dev/sda3
扩展逻辑卷：lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
调整文件系统：resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
验证结果：df -h

详细操作步骤

1. 检查当前磁盘使用情况

首先查看文件系统使用情况：

$ df -h
Filesystem                         Size  Used  Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv  3.9G  3.2G   489M  87% /
/dev/sda2                         976M   77M   833M   9% /boot
# ... 其他输出省略

查看详细的磁盘分区信息：

$ sudo fdisk -l
Disk /dev/sda: 25 GiB, 26843545600 bytes, 52428800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: ED41F7A6-5D09-457B-A55C-C7F1E30DE419

Device      Start      End    Sectors  Size Type
/dev/sda1    2048     4095      2048    1M BIOS boot
/dev/sda2    4096  2101247   2097152    1G Linux filesystem
/dev/sda3 2101248 52426751  50325504   24G Linux filesystem

2. 在 Hyper-V 中扩展虚拟磁盘

关闭虚拟机
打开 Hyper-V 管理器
选择目标虚拟机 → 设置
找到硬盘驱动器 → 编辑
选择"扩展"并输入新的大小
启动虚拟机

3. 调整 Linux 分区

使用 parted 工具调整分区大小：

$ sudo parted
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.

# 查看当前分区情况
(parted) print
Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 26.8GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
1      1049kB  2097kB  1049kB               bios_grub
2      2097kB  1076MB  1074MB  ext4
3      1076MB  26.8GB  25.8GB

# 调整分区大小
(parted) resizepart
Partition number? 3
End? [26.8GB]? 100%

(parted) quit

4. 扩展 LVM 卷

扩展物理卷（PV）：

$ sudo pvresize /dev/sda3
Physical volume "/dev/sda3" changed
1 physical volume(s) resized

扩展逻辑卷（LV）：

$ sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
Size of logical volume ubuntu-vg/ubuntu-lv changed from 4.00 GiB to 23.00 GiB.
Logical volume ubuntu-vg/ubuntu-lv successfully resized.

调整文件系统大小：

$ sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/mapper/ubuntu--vg-ubuntu--lv is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 3
The filesystem on /dev/mapper/ubuntu--vg-ubuntu--lv is now 6029312 (4k) blocks long.

5. 验证扩容结果

$ df -h
Filesystem                         Size  Used  Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv   23G  3.2G    19G  15% /
/dev/sda2                         976M   77M   833M   9% /boot
# ... 其他输出省略

故障排除

分区未显示新增空间
- 检查 Hyper-V 设置中的磁盘大小是否正确更改
- 确认虚拟机是否完全重启
LVM 扩展失败
- 确保 PV、VG 和 LV 的名称正确
- 检查是否有足够的未分配空间
- 查看系统日志获取详细错误信息
文件系统扩展失败
- 确保文件系统支持在线调整
- 检查文件系统是否有错误（使用 fsck）

参考资料

不容错过的 Bash 技巧

Fri, 04 Jun 2021 11:06:47 +0800

一些提升 Bash 使用效率的小技巧

在使用 Bash 时，我们通常使用上 ↑ 下 ↓ 箭头来快速切换历史命令，然而一些重复的、不想要的命令（例如最简单的 ls，敲击比切换快，同时也会增加切换到别的命令的按键次数）也在历史记录里保存，这降低了切换的效率。下面一些技巧可以更好的帮助我们切换到想要的命令：

说明

下文中需要编辑的内容均在.bashrc中，使用常用的文本编辑器打开它，例如：

$ vim ~/.bashrc

使用 HISTIGNORE 移除历史记录中无意义的命令

有一些命令极为常用，我们不想它出现在历史记录里，那么在.bashrc中添加下述内容忽略它即可：

export HISTIGNORE='pwd:exit:fg:bg:top:clear:history:ls:uptime:df'

作为补充，如果我们不希望某些敏感的命令出现在历史记录中，例如在命令行中指定密码或 API 密钥，那么可以使用下面的选项来确保任何以空格开头的命令不会出现在历史文件中：

export HISTCONTROL=ignorespace

另外：

export HISTCONTROL=ignoredups

则表示当同一个命令重复出现时，只存储命令的一个副本。

设置历史记录数量

为了防止历史记录的丢失，可以适当的将记录数量调整的更大：

shopt -s histappend
export HISTSIZE=10000

更有效的调用命令

!!可以调用前一行的命令。

例如：

$ pwd
/etc
$ !!
pwd
/etc

同时，!!也可以作为参数加入别的命令配合使用，例如：

$ sudo !!

就将使用 root 权限再次执行此前的命令。

此外，我们还可以通过在历史命令提供的行号前加一个!来运行历史上的命令，但是请注意不要打错行号，避免执行出错：

$ rm -r temp/
$ mkdir temp
$ touch temp/test
$ !!
touch temp/test
$ history | tail -4
  179  rm -r temp/
  180  mkdir temp
  181  touch temp/test
  182  touch temp/test
  183  history | tail -5
$ !179:p
rm -r temp
$ !180
touch temp/test

我们也可以用前面的!来调用一个命令的最后一次出现，例如：

$ !ping

将运行我们最后运行的以 ping 开头的命令。

为了避免上述内容出错，可以添加一个:p来显示命令内容，而不实际执行它们。

使用 !$ 和 !* 调用前一行参数

和!!不同，!$和!*仅指代前一行，命令的部分内容。

$ mv list.txt items.txt
$ vim !$
vim items.txt
$ cp !$ shopping.txt
cp items.txt shopping.txt

可以看到!$指代上一行命令的最后一个参数。

而!*指代上一行命令除了第一个以外的所有参数：

$ rm /var/log/httpd/access.log /var/log/httpd/error.log
$ touch !*
touch /var/log/httpd/access.log /var/log/httpd/error.log

用 ^ 替换前一行的匹配词

^符号允许你在切换一个匹配的单词后重复前一个命令，比如说：

$ rm /var/log/httpd/error.log
$ ^error^access
rm /var/log/httpd/access.log

参考

[1] Be more productive with use of your BASH history

使用 Docker 部署 FreshRSS：搭建私有 RSS 阅读服务

Fri, 28 May 2021 23:25:46 +0800

本文介绍如何使用 Docker 部署 FreshRSS，搭建自己的 RSS 阅读服务。相比商业服务（如 Inoreader），自托管 FreshRSS 无需付费且无功能限制。

服务器要求

为确保 RSS 源的可靠访问，建议使用境外服务器部署。

一、部署准备

1.1 系统要求

Docker 和 Docker Compose
稳定的网络连接
建议 1GB 以上内存

1.2 创建工作目录

# 创建并进入 FreshRSS 工作目录
mkdir ~/freshrss && cd ~/freshrss

二、Docker 配置

2.1 创建配置文件

创建 docker-compose.yml 文件：

version: "3"

services:
  # PostgreSQL 数据库服务
  freshrss-db:
    image: postgres:latest
    container_name: freshrss-db
    hostname: freshrss-db
    restart: always
    volumes:
      - freshrss-db:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: freshrss         # 设置数据库用户名
      POSTGRES_PASSWORD: freshrss     # 设置数据库密码
      POSTGRES_DB: freshrss          # 设置数据库名

  # FreshRSS 应用服务
  freshrss-app:
    image: freshrss/freshrss:latest
    container_name: freshrss-app
    hostname: freshrss-app
    restart: always
    ports:
      - "39954:80"                   # 端口映射，可根据需要修改
    depends_on:
      - freshrss-db
    volumes:
      - ./data:/var/www/FreshRSS/data
      - ./extensions:/var/www/FreshRSS/extensions
    environment:
      CRON_MIN: '*/45'               # RSS 更新间隔（分钟）
      TZ: Asia/Shanghai              # 时区设置

volumes:
  freshrss-db:

2.2 启动服务

docker-compose up -d

三、FreshRSS 配置

3.1 初始化设置

访问 http://your-domain:39954 进行初始化配置：

数据库配置
- 主机名：freshrss-db（与 Docker 容器名对应）
- 用户名：与 POSTGRES_USER 值相同
- 密码：与 POSTGRES_PASSWORD 值相同
- 数据库名：与 POSTGRES_DB 值相同
- 表前缀：可自定义
管理员账户
- 设置管理员用户名和密码
- 配置网站基本信息

3.2 优化设置

阅读设置
- 建议关闭：阅读 => 合适将文章标记为已读 => 在滚动浏览后
- 原因：避免意外将未读文章标记为已读
扩展功能
- 推荐安装 Auto Refresh 扩展实现自动刷新
- 安装步骤：
  1. 下载扩展文件
  2. 解压到 ~/freshrss/extensions/ 目录
  3. 在 FreshRSS 后台启用扩展
  4. 修改刷新间隔：编辑 xExtension-AutoRefresh/static/script.js

四、Nginx 反向代理配置

如需配置 Nginx 反向代理，请参考：使用 Nginx 实现多服务复用端口

五、移动端配置

5.1 启用 API 访问

进入 FreshRSS 设置
开启：认证 => 允许 API 访问
设置：用户账户 => API 管理 => API 密码

5.2 客户端配置

Fluent Reader

API 地址：https://your-domain/api/fever.php
用户名：您的用户名
密码：API 密码

FeedMe

API 地址：https://your-domain/api/greader.php
用户名：您的用户名
密码：API 密码
服务类型：选择 FreshRSS

注意

FeedMe 请使用 Google Reader API（greader.php），Fever API 可能导致认证失败。

参考资料

常用 youtube-dl 命令

Tue, 18 May 2021 15:19:43 +0800

记录一些常用的 youtube-dl 命令，拯救脑容量。

下载播放列表视频+音频

Windows

youtube-dl.exe -o "D:\xxxxxx\%(title)s.%(ext)s" -f bestvideo+bestaudio https://www.youtube.com/playlist?list=x

仅下载播放列表音频

youtububedl.exe -o D:\%(title)s.%(ext)s -f bestaudio --extract-audio --audio-format mp3 --audio-quality 0 https://www.youtube.com/playlist?list=xxxxxxxxxxxx

-o D:\%(title)s.%(ext)s     #保留原始名称和后缀
-f bestaudio                #最佳音频
--extract-audio             #提取音频
--audio-format mp3          #设置音频格式，下载文件若不同，则调用ffmpeg转换
--playlist-items 1,2,5      #下载播放列表中的哪些项
--playstart-start 2         #从第二项开始下载播放列表
--playstart-end 2
-f 'bestvideo[height<=1080]+bestaudio/best[height<=1080]'             #设置最大下载分辨率

持久化 Gist file raw 链接

Mon, 03 May 2021 22:22:32 +0800

如何持久化 Gist file raw 链接地址？

问题

通常，Gist 文件的 raw 链接会随着版本而更改，但在使用上往往不便，因此需要持久化文件的 raw 链接地址。

解决方法

获得 Gist 文件列表中的第一个文件： https://gist.github.com/gist_user/gist_id/raw/

例如: https://gist.github.com/atenni/5604522/raw/

即便更改了文件名，上述方法依然可以获得列表中的第一个文件。
获得多个文件： https://gist.github.com/gist_user/gist_id/raw/file_name

例如: https://gist.github.com/atenni/5604522/raw/README.md

参考

[1] How to permalink to a gist’s raw file

Windows 网络连接优先级设置

Thu, 29 Apr 2021 20:42:25 +0800

Windows10 默认优先使用有线连接，但是如需优先使用无线连接，除了拔网线/禁用有线网卡外，还可以通过修改接口跃点数，实现不同网络连接的优先级。

优先级设置方法

方法一：控制面板中修改

接口跃点数通过以下步骤找到：

首先打开控制面板 > 网络和 Internet > 网络连接

找到想要修改的网络连接，右键打开属性

接下来打开Internet 协议版本 4 属性 > 高级

控制面板设置界面" >

控制面板设置界面

取消勾选自动跃点，填入需要设置的数值即可，有关数值设置的注意事项将在后续说明。

方法二：Powershell 中修改

更便捷的方式是通过 Powershell 进行修改。

首先以管理员身份运行 Windows PowerShell，并使用命令

PS C:\Users\xxxx> Get-NetIPInterface

获得当前所有的网络连接，其中InterfaceMetric即为接口跃点数的值。

Powershell 设置界面" >

Powershell 设置界面

找到想要修改的网络连接以及它的 ifIndex (接口索引)值，例如 x，使用命令

PS C:\Users\xxxx> Set-NetIPInterface -InterfaceIndex x -InterfaceMetric 10

即可将其跃点数设置为 10。

想要恢复跃点数的话，运行以下命令即可：

PS C:\Users\xxxx> Set-NetIPInterface -InterfaceIndex x -AutomaticMetric enabled

跃点数的设置范围

跃点数越小，网络优先级越高。

跃点数的理论范围是 1 ~ 999，但跃点数低于 10 ，可能会导致某些网络访问失败，同时，合理的跃点数值也要参考网络带宽。

分流方法

在同时使用 Wi-Fi 和有线网络的环境下可以用 route 命令实现特定网段使用特定接口。

举例：

可以连接到互联网的 Wi-Fi 网关地址是 192.168.0.1，有线网网关 IP 是 10.0.0.1。分流：需要访问的内网资源都位于 10.0.0.0/8 段，其他流量都走 Wi-Fi。

首先打开管理员身份的命令提示符，输入以下命令删除默认的路由表。

route delete 0.0.0.0

添加一个默认路由，指定所有流量走 Wi-Fi。

route add 0.0.0.0 mask 0.0.0.0 192.168.0.1

添加另一个路由，指定 10.0.0.1~10.255.255.254 流量走有线网络。

route add 10.0.0.0 mask 255.0.0.0 10.0.0.1

参考

使用 Nginx 实现多服务复用端口

Tue, 20 Apr 2021 14:17:01 +0800

利用 Nginx 在单一服务器上搭建多个同端口的服务

说明

目前服务器上运行以下服务：

Trojan
Xray
frp + Bitwarden 实现内网穿透访问
FreshRSS

三个服务使用了不同域名进行区分，但为了便捷，都使用 443 端口。

流程概览

采用 Docker 在本地服务器上搭建 Bitwarden，配置并运行 frpc 指向服务器上的 frps
在服务器上搭建其他网站或者需要使用 443 端口的服务（如：Trojan)，配置运行 frps
采用 Docker 搭建 FreshRSS，首先使用 IP:Port 完成相关配置，然后配置域名，申请证书
安装 Nginx，这里需要利用 Nginx 的 stream_ssl_preread 模块，使用nginx -V查看是否包含该模块。（该模块在 Nginx 1.19.2 已默认包含，但 Ubuntu 等发行版还在使用更老的 stable 版本，需要手动添加 mainline 版本源，并更新 Nginx 到最新版本）

获取 SSL 证书

$ sudo apt install certbot python3-certbot-nginx
$ sudo certbot --nginx -d example.com -d www.example.com

本地配置文件

frpc.ini

[common]
server_addr = xxx.xxx.xxx.xxx           # 服务器地址
server_port = xxx                       # 与服务器 frps 通信的端口
token = xxxxxx                          # frp 验证密钥

[bitwarden_https]
type = https
local_port = 443
custom_domains = xxx.xxx.xxx            # Bitwarden 域名

本地 nginx.cof

user www www;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
worker_rlimit_nofile 8192;
events {
    worker_connections 4096;
}
http {
    include mime.types;
    default_type application/octet-stream;

    client_max_body_size 0;
    client_body_buffer_size 512k;

    sendfile on;
    sendfile_max_chunk 1m;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;

    types_hash_max_size 4096;

    proxy_cache_path /var/run/nginx-proxy-cache levels=1:2 keys_zone=cache_one:20m inactive=1d max_size=500m;
    proxy_cache cache_one;
    proxy_temp_path /var/run/proxy_temp_dir;
    proxy_temp_file_write_size 128k;
    proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
    proxy_buffer_size 16k;
    proxy_busy_buffers_size 24k;
    proxy_buffers 64 4k;

    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_http_version 1.1;
    gzip_comp_level 2;
    gzip_types text/plain application/javascript application/x-javascript text/javascript text/css application/xml;
    gzip_vary on;
    gzip_proxied expired no-cache no-store private auth;
    gzip_disable "MSIE [1-6]\.";

    server_tokens off;

    server {
        listen 443 ssl http2;
        server_name xxx.xxx.xxx;                        # 域名

        ssl_certificate /xxx/cert/fullchain.pem;        # 证书路径
        ssl_certificate_key /xxx/cert/privkey.pem;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers off;
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 1d;

        location / {
            proxy_pass http://127.0.0.1:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        location /notifications/hub {
            proxy_pass http://127.0.0.1:3012;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }

        location /notifications/hub/negotiate {
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

服务器配置文件

服务器 nginx.cof

user www-data;
worker_processes auto;
pid /var/run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
	worker_connections 768;
	# multi_accept on;
}

stream {
    map $ssl_preread_server_name $name {
        xxx.techkoala.net frps-bitwarden;   # Bitwarden 域名
        xxx.techkoala.net trojan;           # Trojan 域名
        xxx.techkoala.net rss;              # FreshRSS 域名
        xxx.techkoala.net xtls;             # Xray 域名
    }
    upstream frps-bitwarden {
        server 127.0.0.1:8080;         # Bitwarden的 frps 端口
    }
    upstream trojan {
        server 127.0.0.1:4443;         # Trojan 本地监听端口
    }
    upstream rss {
        server 172.17.0.1:39955;       # FreshRSS Docker IP 以及映射本地监听端口
    }
    upstream xtls {
        server 127.0.0.1:8443;       # Xray 本地监听端口
    }
    server {
        listen 443 reuseport;
        listen [::]:443 reuseport;
        proxy_pass	$name;
        ssl_preread on;               # 开启 ssl_preread
    }
}

http {
	##
	# Basic Settings
	##

	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	# server_tokens off;

	# server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	##
	# SSL Settings
	##

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
	ssl_prefer_server_ciphers on;

	##
	# Logging Settings
	##

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;

	##
	# Gzip Settings
	##

	gzip on;

	# gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

	##
	# Virtual Host Configs
	##

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;     # 启用的网站配置放置在此文件夹下
}

Bitwarden 相关配置

frps.ini

[common]
bind_port = xxxx                # 与本地 frpc 通信的端口
vhost_https_port = xxxx         # 虚拟 https 端口，需要和 nginx.conf 内一致
authentication_method = token
token = xxxxxx                  # frp 验证密钥

Bitwarden Nginx 站点配置

放置在/etc/nginx/sites-available/下，文件与域名同名

## Bitwarden 配置。只负责只将 http 重定向至 https
## Bitwarden 的 SSL 握手交给本地服务器端的 Nginx 处理
server {
        listen 80;
        listen [::]:80;
        server_name xxx.techkoala.net;                    # Bitwarden 域名
        return 301 https://xxx.techkoala.net$request_uri; # Bitwarden 域名
}

链接配置文件

ln -s /etc/nginx/sites-available/xxx.techkoala.net /etc/nginx/sites-enabled/

Trojan 相关配置

Trojan Nginx 配置

放置在/etc/nginx/sites-available/下，文件与域名同名

server {
    listen 127.0.0.1:80 default_server;
    server_name xxx.techkoala.net;             # 自己的域名
    location / {
        proxy_pass https://www.digitalocean.com; # 伪装的网站
    }
}
server {
    listen 127.0.0.1:80;
    server_name xxx.techkoala.net;                 # 自己服务器的 IP
    return 301 https://xxx.techkoala.net$request_uri;  # 自己的域名
}
server {
    listen 0.0.0.0:80;
    listen [::]:80;
    server_name _;
    return 301 https://$host$request_uri;
}

链接配置文件

ln -s /etc/nginx/sites-available/xxx.techkoala.net /etc/nginx/sites-enabled/

Trojan 配置文件

{
    "run_type": "server",
    "local_addr": "0.0.0.0",
    "local_port": 4443,             # 本地监听端口，与 nginx.conf 保持一致
    "remote_addr": "127.0.0.1",
    "remote_port": 80,              # 伪装站点的端口
    "password": [
        "xxxxxx"                    # 密钥
    ],
    "log_level": 1,
    "ssl": {
        "cert": "/usr/local/etc/ssl/certificate.crt",
        "key": "/usr/local/etc/ssl/private.key",
        "key_password": "",
        "cipher": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384",
        "cipher_tls13": "TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384",
        "prefer_server_cipher": true,
        "alpn": [
            "http/1.1"
        ],
        "alpn_port_override": {
            "h2": 81
        },
        "reuse_session": true,
        "session_ticket": false,
        "session_timeout": 600,
        "plain_http_response": "",
        "curves": "",
        "dhparam": ""
    },
    "tcp": {
        "prefer_ipv4": false,
        "no_delay": true,
        "keep_alive": true,
        "reuse_port": false,
        "fast_open": false,
        "fast_open_qlen": 20
    },
    "mysql": {
        "enabled": false,
        "server_addr": "127.0.0.1",
        "server_port": 3306,
        "database": "trojan",
        "username": "trojan",
        "password": "",
        "key": "",
        "cert": "",
        "ca": ""
    }
}

FreshRSS 站点配置

放置在/etc/nginx/sites-available/下，文件与域名同名

server {
        listen 80;
        listen [::]:80;
        server_name xxx.techkoala.net;
        return 301 https://xxx.techkoala.net$request_uri;
    }

server {
    listen 39955 ssl http2;          # FreshRSS 本地监听端口
    #===注意，nginx 1.25.1之后这里需要修改为
    listen 39955 ssl;
    http2 on;
    #===
    server_name rss.techkoala.net;
    ssl_certificate /etc/letsencrypt/live/xxx.techkoala.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/xxx.techkoala.net/privkey.pem;

    location / {
       proxy_pass http://127.0.0.1:39954;   # 转发到 FreshRSS 容器映射的端口
    }
}

链接配置文件

ln -s /etc/nginx/sites-available/xxx.techkoala.net /etc/nginx/sites-enabled/

Xray

Xray Nginx 配置

server {
        listen 80;
        server_name xxx.techkoala.net;
        if ($host = xxxx.techkoala.net) {
                return 301 https://$host$request_uri;
        }
        return 404;
}

server {
        listen 127.0.0.1:23333;
        server_name xxxx.techkoala.net;
        location / {
                proxy_pass https://www.digitalocean.com; # 伪装的网站
        }
}

Xray 配置

{
    "log": {
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "listen": "127.0.0.1", # 仅监听在本地防止探测到下面的 8443 端口
            "port": 8443, # 这里的端口对应 nginx 主配置文件内的 upstream 端口
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "7f46753a-6a4b-4284-94c0-760340f96f1e", # 填写你的UUID
                        "flow": "xtls-rprx-direct",
                        "level": 0
                    }
                ],
                "decryption": "none",
                "fallbacks": [
                    {
                        "dest": "23333" # 回落站点的端口号，与 Xray Nginx 配置一致
                    }
                 ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "xtls",
                "xtlsSettings": {
                    "alpn": [
                        "http/1.1"
                    ],
                    "certificates": [
                        {
                            "certificateFile": "/usr/local/etc/ssl/fullchain.pem", # 你的域名证书
                            "keyFile": "/usr/local/etc/ssl/privkey.pem" # 你的证书私钥
                        }
                    ]
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom"
        }
    ]
}

防火墙设置

上述操作后，服务器需要打开80,443,xxx（frp 通信端口）

OpenWRT 使用 dnscrypt-proxy2 实现 DoH 查询及分流

Fri, 29 Jan 2021 20:36:35 +0800

OpenWRT 默认并不支持 DoH 或 DoT，存在 DNS 泄露问题，本文介绍如何 dnscrypt-proxy2 进行加密查询，以及如何与上网插件进行搭配使用

安裝 dnscrypt-proxy2

如果使用 OpenWrt 19.07+版本，那么直接使用 opkg 即可完成安装，命令如下：

opkg update
opkg install dnscrypt-proxy2

不过，版本可能不是最新，如果需要最新版本可以自行编译。

配置

基本使用只需要

vim /etc/dnscrypt-proxy2/dnscrypt-proxy.toml

修改

listen_addresses = ['127.0.0.1:5335']

server_names = ['google', 'cloudflare']

即可

软件已经内置了常见的 DoH/DoT 服务器了，因此只需要填入名称即可

然后

/etc/init.d/dnscrypt-proxy restart

重启软件，dnscrypt-proxy2 就会监听在 5335 这个端口了。

分流（搭配 SSR+）

SSR+ 使用大陆 IP 白名单并使用 5335 的 DNS 解析的方式
dnscyrpt-proxy2 配置监听在 5335，仅使用 DoH 协议向 Cloudflare/Google 服务器查询（这些 Https 的查询请求全部会被 SSR+ 代理转发）
iptables 劫持所有目标为 53 端口的流量到路由器的 53 端口（默认）
53 端口使用默认的 dnsmasq 作为 DNS 服务，上游设置为 127.0.0.1#5335，配置文件/etc/dnsmasq.conf最后添加 conf-dir=/etc/dnsmasq.d
在/etc/dnsmasq.d/(如无则新建）中放入https://github.com/felixonmars/dnsmasq-china-list/blob/master/accelerated-domains.china.conf

这样实现了凡是大陆的和在大陆有 cdn 的以及返回 AAAA 记录的域名全部直连查询并直连访问，其余的全部走代理查询，且结果在大陆以外的走代理访问（IP+域名的双白名单机制）

参考

[1] lede
[2] Installation on OpenWrt

Vim 小技巧

Tue, 19 Jan 2021 19:34:18 +0800

记录使用 Vim 时遇到实用的小技巧

全局命令 g(lobal)

vim 进入文件，命令行模式下执行

:[range]global[!]/{pattern}/{command}

也即：

:[range]g/pattern/command

[range] 指定文本范围，默认为整个文档
pattern 在范围 range 内的行如果匹配 pattern，则执行 command
! 表示取反，也就是不匹配的行，也可以使用 vglobal
command 默认是打印文本

Tip.1 范围匹配

20 行到 200 行之间，每一行下插入空行

:20,200g/^/pu _

Tip.2 删除包含字符 pattern 的所有行

:g/pattern/d

Tip.3 删除空白行

:g/^$/d

Tip.4 删除不匹配的行

:g!/pattern/d
:v/pattern/d

Tip.5 删除大量匹配行

Vim 在删除操作时，会先把要删除的内容放到寄存器中，假如没有指定寄存器，会默认放到一个未命名的寄存器中。对于要删除大量匹配行的行为，可能导致 Vim 花一些时间处理这些拷贝。避免花费不必要的时间可以指定一个 blackhole 寄存器 _

:g/pattern/d_

Tip.6 移动匹配的行

将所有匹配的行移动到文件的末尾

:g/pattern/m$

Tip.7 复制匹配的行

将所有匹配的行复制到文件末尾

:g/pattern/t$

Tip.8 复制到 register a

Vim 每个字母都是一个寄存器，所以使用全局命令也可以将内容复制到某一个寄存器，比如 a

qaq:g/pattern/y A

qaq 清空寄存器 a，qa 开始记录命令到 a 寄存器，q 停止记录
y A 将匹配的行 A（append）追加到寄存器 a 中存放到 a 寄存器之后就可以使用 “ap 来粘贴使用或者其他操作了

Tip.9 反转文件中的每一行

:g/^/m0

:g 命令一行行匹配，匹配第一行时将第一行 m0 放到文件顶部，第二行放到文件顶部，当跑完一遍之后整个文件的每一行就反转了

Tip.10 在匹配行后添加文字

使用 s 命令可以实现，同样使用全局 g 命令也可以实现同样的效果

:g/pattern/s/$/mytext

To be continued…

参考

[1] Vim 全局命令 g

LTE 系列：功率控制

Mon, 02 Nov 2020 21:16:56 +0800

LTE 功率控制

功率控制

针对上行和下行信号的发送特点，物理层定义了相应的功率控制的机制。

对于上行信号，终端的功率控制在节能和抑制用户间干扰的方面具有重要意义，所以，相应的采用闭环功率控制的方式，控制终端在上行单载波符号上的发送功率。
对于下行信号，基站合理的功率分配和相互之间的协调能够抑制小区间的干扰，提高组网的系统性能，所以，相应的采用开环功率分配的机制，控制基站在下行各个子载波上的发送功率。

上行功率控制

上行功率控制以各个终端为单位，控制终端到达基站的接收功率，使得不同距离的用户都能以适当的功率到达基站，避免远近效应。物理层上行采用部分功率控制（Fractional Power Control）结合闭环功率控制的方案，对无线链路的大尺度衰落和小尺度衰落进行补偿。

在子帧 i，终端 PUSCH 信道的发射功率可以表示为：

$P_{PUSCH}(i)=min\{P_{CMAX},10log_{10}(M_{PUSCH}(i))+P_{O_{PUSCH}} (j)+α(j)·PL+∆TF (i)+f(i)\}[dBm]$

其中：

$P_{CMAX}$ 表示终端的最大发射功率
$M_{PUSCH}(i)$ 表示 PUSCH 的传输带宽（RB 数目）
$PL$ 是终端测量得到的下行大尺度损耗
$∆TF (i)$ 表示由调制编码方式和数据类型（控制信息或者数据信息）所确定的功率偏移量。
$KS＝1.25$ 或者 0，表示是否针对不同的调制方式进行补偿
$f(i)$ 是由终端闭环功率控制所形成的调整值。它的数值根据 PDCCH Format0/3/3A 上的功率控制命令进行调整

物理层有两种闭环功率控制类型：

累计型（accumulation）
绝对值型（absolute）

与上行数据调度相类似

在 FDD 情况下，PDCCH Format 0/3/3A 功率控制命令和相应的 PUSCH 发送之间的时延是 4ms
在 TDD 情况下，该时延的数值根据上下行时间分配比例的不同而有所不同

与功率控制相结合，可以通过小区之间交换干扰情况的信息，进行协调的调度，抑制小区间的同频干扰，小区间 X2 接口上交互的信息有两种：

过载指示（Overload Indicator，OI）：指示本小区每个 PRB 上受到的上行干扰情况。相邻小区通过交换该消息了解对方目前的负载情况，并进行适当的调整
干扰指示（High Interference Indicator，HII）：指示本小区每个 PRB 对于上行干扰的敏感度情况。该消息反映了本小区的调度安排，相邻小区通过交换该信息了解对方将要采用的调度安排，并进行适当的调整以实现协调的调度。

下行功率分配

下行功率分配以每个 RE 为单位，控制基站在各个时刻各个子载波上的发射功率。

下行功率分配中包括了

提高导频信号的发射功率（即 power boosting）
用户调度相结合实现小区间干扰抑制的相关机制

小区公用导频信号（CRS）在频率上和时间上采用恒定的发射功率，基站通过高层信令指示该发射功率的数值，在接收端，终端通过测量该信号的平均接收功率并与信令指示的发射功率进行比较，获得大尺度衰落的数值。

下行共享信道 PDSCH 的发射功率表示为 PDSCH RE 与 CRS RE 的功率比值，即 $ρA$ 和 $ρB$ 。其中

$ρA$ 表示时隙内不带有 CRS 导频信号的 OFDM 符号上（例如：2 天线、Normal CP 的情况下，时隙内的第 1、2、3、5、6 个 OFDM 符号），PDSCH RE 与 CRS RE 的功率比值
$ρB$ 表示时隙内带有 CRS 导频信号的 OFDM 符号上（例如：2 天线、Normal CP 的情况下，时隙内第 0、4 个 OFDM 符号），PDSCH RE 与 CRS RE 的功率比值

提高 CRS 导频信号的发射功率（即 power boosting）

小区通过高层信令指示 $\frac{ρB}{ρA}$，通过不同的比值可以设置导频信号在基站总功率中不同的开销比例，由此实现了不同程度地提高 CRS 导频信号发射功率的功能。

例：以发射天线数目等于 2 为例，支持 4 种不同的小区配置 $\frac{ρB}{ρA}=[\frac{5}{4},1,\frac{3}{4},\frac{1}{2}]$，分别对应于导频占总功率开销为$[\frac{1}{6}，\frac{1}{3}，\frac{3}{6}，\frac{2}{3}]$的情况。

下图表示了 $\frac{ρB}{ρA} =1$ 和 $\frac{ρB}{ρA} =\frac{1}{2}$ 时天线端口 #0 的信号功率情况，分别实现了导频信号以 3dB 和 9dB 高于同一 OFDM 符号中数据元素的发送功率。

两种情况下天线端口 #0 的信号功率" >
两种情况下天线端口 #0 的信号功率

用户功率分配和小区间干扰协调

在指示 $\frac{ρB}{ρA}$ 的基础上，通过高层参数 $P_A$ 可以确定 $ρA$ 的具体数值，得到基站下行针对用户的 PDSCH 发射功率，该信息将用于 16QAM、64QAM 和 MU-MIMO 等需要幅度信息的检测过程。$P_A$ 和 $ρA$ 的数值关系是

$ρ_A =δ_{power-offset} +P_A$

其中 $δ_{power-offset}$ 用于 MU-MIMO 的场景，例如 $δ_{power-offset} =−3dB$ 可以表示功率平均分配给两个用户的情况。

参考

[1] LTE-Advanced 关键技术详解

告知你不为人知的 UDP —— 疑难杂症和使用

Mon, 26 Oct 2020 11:06:30 +0800

UDP 说来简单，但是一些细节你都清楚吗？

注：本文系全文转载，原文信息如下：

作者：贺嘉

链接：https://zhuanlan.zhihu.com/p/25622691

来源：知乎

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

UDP 疑难杂症

UDP 的传输方式：面向报文

面向报文的传输方式决定了 UDP 的数据发送方式是一份一份的，也就是应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文。那么 UDP 的报文大小由哪些影响因素呢？UDP 数据包的理论长度是多少，合适的 UDP 数据包应该是多少呢？

UDP 报文大小的影响因素，主要有以下 3 个

UDP 协议本身，UDP 协议中有 16 位的 UDP 报文长度，那么 UDP 报文长度不能超过 $2^{16}=65536$.
以太网(Ethernet)数据帧的长度，数据链路层的 MTU(最大传输单元)。
socket 的 UDP 发送缓存区大小

UDP 数据包最大长度

根据 UDP 协议规范，UDP 数据包的最大理论长度为 65507 字节，计算方式如下：

UDP 包头占用 8 字节
IP 包头占用 20 字节
UDP 协议中长度字段为 16 位，即 $2^{16} - 1 = 65535$ 字节
因此最大理论长度为：65535 - 8 - 20 = 65507 字节

如果发送的数据包超过此长度限制，send 或 sendto 函数会返回错误码 1（Operation not permitted，Message too long）。此外，实际可发送的最大长度还受限于 UDP 发送缓冲区大小（Linux 系统下可通过 cat /proc/sys/net/core/wmem_default 查看）。如果发送缓冲区小于要发送的数据包大小，同样会返回错误码 1（Operation not permitted，No buffer space available）。

UDP 数据包理想长度

虽然 UDP 报文理论上可以达到 65507 字节，但在实际应用中应当考虑网络传输的效率和可靠性。为了减少 UDP 包在传输过程中被分片的风险，建议控制数据包大小不超过 MTU。

以太网 MTU 通常为 1500 字节，考虑到 IP 头（20 字节）和 UDP 头（8 字节），建议将 UDP 数据包的大小控制在 1472 字节以内。考虑到互联网上的标准 MTU 值为 576 字节，在进行 Internet 的 UDP 编程时，建议将 UDP 数据长度控制在 548 字节（576-8-20）以内。

UDP 数据包的发送和接收问题

UDP 的通信有界性

在阻塞模式下，UDP 的通信是以数据包作为界限的，即使 Server 端的缓冲区再大也要按照 Client 发包的次数来多次接收数据包，Server 只能一次一次的接收，Client 发送多少次，Server 就需接收多少次，即客户端分几次发送过来，服务端就必须按几次接收。

UDP 数据包的无序性和非可靠性

Client 依次发送 1、2、3 三个 UDP 数据包，Server 端先后调用 3 次接收函数，可能会依次收到 3、2、1 次序的数据包，收包可能是 1、2、3 的任意排列组合，也可能丢失一个或多个数据包。

UDP 数据包的接收

Client 发送两次 UDP 数据，第一次 500 字节，第二次 300 字节，Server 端阻塞模式下接包，第一次 recvfrom( 1000 )，收到是 1000，还是 500，还是 300，还是其他？

由于 UDP 通信的有界性，接收到只能是 500 或 300，又由于 UDP 的无序性和非可靠性，接收到可能是 300，也可能是 500，也可能一直阻塞在 recvfrom 调用上，直到超时返回(也就是什么也收不到)。

在假定数据包是不丢失并且是按照发送顺序按序到达的情况下，Server 端阻塞模式下接包，先后三次调用：recvfrom( 200)，recvfrom( 1000)，recvfrom( 1000)，接收情况如何呢？

由于 UDP 通信的有界性，第一次 recvfrom( 200)将接收第一个 500 字节的数据包，但是因为用户空间 buf 只有 200 字节，于是只会返回前面 200 字节，剩下 300 字节将丢弃。第二次 recvfrom( 1000)将返回 300 字节，第三次 recvfrom( 1000)将会阻塞。

UDP 包分片问题

如果 MTU 是 1500，Client 发送一个 8000 字节大小的 UDP 包，那么 Server 端阻塞模式下接包，在不丢包的情况下，recvfrom(9000)是收到 1500，还是 8000。如果某个 IP 分片丢失了，recvfrom(9000)，又返回什么呢？

根据 UDP 通信的有界性，在 buf 足够大的情况下，接收到的一定是一个完整的数据包，UDP 数据在下层的分片和组片问题由 IP 层来处理，提交到 UDP 传输层一定是一个完整的 UDP 包，那么 recvfrom(9000)将返回 8000。如果某个 IP 分片丢失，UDP 里有个 CRC 检验，如果包不完整就会丢弃，也不会通知是否接收成功，所以 UDP 是不可靠的传输协议，那么 recvfrom(9000)将阻塞。

UDP 丢包问题

在不考虑 UDP 下层 IP 层的分片丢失，CRC 检验包不完整的情况下，造成 UDP 丢包的因素有哪些呢？

UDP socket 缓冲区满造成的 UDP 丢包

通过 cat /proc/sys/net/core/rmem_default 和 cat /proc/sys/net/core/rmem_max 可以查看 socket 缓冲区的缺省值和最大值。如果 socket 缓冲区满了，应用程序没来得及处理在缓冲区中的 UDP 包，那么后续来的 UDP 包会被内核丢弃，造成丢包。在 socket 缓冲区满造成丢包的情况下，可以通过增大缓冲区的方法来缓解 UDP 丢包问题。但是，如果服务已经过载了，简单的增大缓冲区并不能解决问题，反而会造成滚雪球效应，造成请求全部超时，服务不可用。

UDP socket 缓冲区过小造成的 UDP 丢包

如果 Client 发送的 UDP 报文很大，而 socket 缓冲区过小无法容下该 UDP 报文，那么该报文就会丢失。

ARP 缓存过期导致 UDP 丢包

ARP 的缓存时间约 10 分钟，APR 缓存列表没有对方的 MAC 地址或缓存过期的时候，会发送 ARP 请求获取 MAC 地址，在没有获取到 MAC 地址之前，用户发送出去的 UDP 数据包会被内核缓存到 arp_queue 这个队列中，默认最多缓存 3 个包，多余的 UDP 包会被丢弃。

被丢弃的 UDP 包可以从 /proc/net/stat/arp_cache 的最后一列的 unresolved_discards 看到。当然我们可以通过 echo 30 > /proc/sys/net/ipv4/neigh/eth1/unres_qlen 来增大可以缓存的 UDP 包。UDP 的丢包信息可以从 cat /proc/net/udp 的最后一列 drops 中得到，而倒数第四列 inode 是丢失 UDP 数据包的 socket 的全局唯一的虚拟 i 节点号，可以通过这个 inode 号结合 lsof(lsof -P -n | grep 25445445)来查到具体的进程。

UDP 冗余传输

在外网通信链路不稳定的情况下，有什么办法可以降低 UDP 的丢包率呢？

一个简单的办法来采用冗余传输的方式。一般采用较多的是延时双发，双发指的是将原本单发的前后连续的两个包合并成一个大包发送，这样发送的数据量是原来的两倍。这种方式提高丢包率的原理比较简单，例如本例的冗余发包方式，在偶数包全丢的情况下，依然能够还原出完整的数据，也就是在这种情况下，50% 的丢包率，依然能够达到 100% 的数据接收。

UDP 真的比 TCP 要高效吗

相信很多同学都认为 UDP 无连接，无需重传和处理确认，UDP 比较高效。然而 UDP 在大多情况下并不一定比 TCP 高效，TCP 发展至今天，为了适应各种复杂的网络环境，其算法已经非常丰富，协议本身经过了很多优化，如果能够合理配置 TCP 的各种参数选项，那么在多数的网络环境下 TCP 是要比 UDP 更高效的。

影响 UDP 高效因素

无法智能利用空闲带宽导致资源利用率低

一个简单的事实是 UDP 并不会受到 MTU 的影响，MTU 只会影响下层的 IP 分片，对此 UDP 一无所知。在极端情况下，UDP 每次都是发小包，包是 MTU 的几百分之一，这样就造成 UDP 包的有效数据占比较小(UDP 头的封装成本)；或者，UDP 每次都是发巨大的 UDP 包，包大小 MTU 的几百倍，这样会造成下层 IP 层的大量分片，大量分片的情况下，其中某个分片丢失了，就会导致整个 UDP 包的无效。由于网络情况是动态变化的，UDP 无法根据变化进行调整，发包过大或过小，从而导致带宽利用率低下，有效吞吐量较低。而 TCP 有一套智能算法，当发现数据必须积攒的时候，就说明此时不积攒也不行，TCP 的复杂算法会在延迟和吞吐量之间达到一个很好的平衡。

无法动态调整发包

由于 UDP 没有确认机制，没有流量控制和拥塞控制，这样在网络出现拥塞或通信两端处理能力不匹配的时候，UDP 并不会进行调整发送速率，从而导致大量丢包。在丢包的时候，不合理的简单重传策略会导致重传风暴，进一步加剧网络的拥塞，从而导致丢包率雪上加霜。更加严重的是，UDP 的无秩序性和自私性，一个疯狂的 UDP 程序可能会导致这个网络的拥塞，挤压其他程序的流量带宽，导致所有业务质量都下降。

改进 UDP 的成本较高

可能有同学想到针对 UDP 的一些缺点，在用户态做些调整改进，添加上简单的重传和动态发包大小优化。然而，这样的改进并比简单的，UDP 编程可是比 TCP 要难不少的，考虑到改造成本，为什么不直接用 TCP 呢？当然可以拿开源的一些实现来抄一下(例如：libjingle)，或者拥抱一下 Google 的 QUIC 协议，然而，这些都需要不少成本的。

上面说了这么多，难道真的不该用 UDP 了吗？其实也不是的，在某些场景下，我们还是必须 UDP 才行的。那么 UDP 的较为合适的使用场景是哪些呢？

UDP 的使用场合

通信实时性和持续性

在分组交换通信当中，协议栈的成本主要表现在以下两方面：

封装带来的空间复杂度
缓存带来的时间复杂度

以上两者是对立影响的，如果想减少封装消耗，那么就必须缓存用户数据到一定量在一次性封装发送出去，这样每个协议包的有效载荷将达到最大化，这无疑是节省了带宽空间，带宽利用率较高，但是延时增大了。如果想降低延时，那么就需要将用户数据立马封装发出去，这样显然会造成消耗更多的协议头等消耗，浪费带宽空间。

因此，我们进行协议选择的时候，需要重点考虑一下空间复杂度和时间复杂度间的平衡。

通信的持续性对两者的影响比较大，根据通信的持续性有两种通信类型：

短连接通信
长连接通信

对于短连接通信，一方面如果业务只需要发一两个包并且对丢包有一定的容忍度，同时业务自己有简单的轮询或重复机制，那么采用 UDP 会较为好些。在这样的场景下，如果用 TCP，仅仅握手就需要 3 个包，这样显然有点不划算，一个典型的例子是 DNS 查询。另一方面，如果业务实时性要求非常高，并且不能忍受重传，那么首先就是 UDP 了或者只能用 UDP 了，例如 NTP 协议，重传 NTP 消息纯属添乱(为什么呢？重传一个过期的时间包过来，还不如发一个新的 UDP 包同步新的时间过来)。如果 NTP 协议采用 TCP，撇开握手消耗较多数据包交互的问题，由于 TCP 受 Nagel 算法等影响，用户数据会在一定情况下会被内核缓存延后发送出去，这样时间同步就会出现比较大的偏差，协议将不可用。

多点通信

对于一些多点通信的场景，如果采用有连接的 TCP，那么就需要和多个通信节点建立其双向连接，然后有时在 NAT 环境下，两个通信节点建立其直接的 TCP 连接不是一个容易的事情，在涉及 NAT 穿越的时候，UDP 协议的无连接性使得穿透成功率更高(原因详见：由于 UDP 的无连接性，那么其完全可以向一个组播地址发送数据或者轮转地向多个目的地持续发送相同的数据，从而更为容易实现多点通信。)

一个典型的场景是多人实时音视频通信，这种场景下实时性要求比较高，可以容忍一定的丢包率。比如：对于音频，对端连续发送 p1、p2、p3 三个包，另一端收到了 p1 和 p3，在没收到 p2 的保持 p1 的最后一个音（也是为什么有时候网络丢包就会听到嗞嗞嗞嗞嗞嗞…或者卟卟卟卟卟卟卟卟…重音的原因），等到到 p3 就接着播 p3 了，不需要也不能补帧，一补就越来越大的延时。对于这样的场景就比较合适用 UDP 了，如果采用 TCP，那么在出现丢包的时候，就可能会出现比较大的延时。

UDP 使用原则

通常情况下，UDP 的使用范围是较小的，在以下的场景下，使用 UDP 才是明智的：

实时性要求很高，并且几乎不能容忍重传。例子：NTP 协议，实时音视频通信，多人动作类游戏中人物动作、位置
TCP 实在不方便实现多点传输的情况
需要进行 NAT 穿越
对网络状态很熟悉，确保 UDP 网络中没有氓流行为，例如疯狂抢带宽
熟悉 UDP 编程

参考

[1] Netfilter,iptables/OpenVPN/TCP guard

DNS 报文详解

Tue, 20 Oct 2020 13:24:18 +0800

本文主要讲解 DNS 的报文结构

DNS 简介

DNS（域名系统）负责将我们熟知的域名翻译成 IP 地址，其相关定义由 RFC 1034 和 RFC 1035 给出。

为了实现更好的扩展性，DNS 采用分层次的服务器组织结构，主要分为三层：

根 DNS 服务器
顶级域名（TLD）DNS 服务器
权威 DNS 服务器

这些服务器的层次结构如下图所示：

DNS 的层次结构" >

DNS 的层次结构

关于 DNS 的工作过程及相关信息，请参见深入浅出 DNS 解析，本文主要介绍 DNS 报文结构。

DNS 报文结构

DNS 的报文结构" >

DNS 的报文结构

DNS 报文包含以下几个部分：

首部（前 12 个字节）：
- 标识符（2 字节）：用于标识请求及其响应报文
- 标志（2 字节）：
  - QR（1 bit）：查询/响应标志，0 表示查询，1 表示响应
  - opcode（4 bit）：操作码
    - 0：标准查询
    - 1：反向查询
    - 2：服务器状态请求
    - [3,15]：保留值
  - AA（1 bit）：授权回答标志，表示响应服务器是否为域名的权威服务器
  - TC（1 bit）：截断标志，表示报文是否因超过长度而被截断
  - RD（1 bit）：期望递归标志，由请求方设置，响应方返回相同值
  - RA（1 bit）：支持递归标志，由响应方设置，表示是否支持递归查询
  - rcode（4 bit）：返回码
    - 0：无错误
    - 1：格式错误
    - 2：服务器失败
    - 3：域名不存在
    - 4：查询类型不支持
    - 5：查询被拒绝
    - [6,15]：保留值
数量字段（8 字节）：
- Questions：查询问题数量
- Answers：回答数量
- Authoritative nameservers：授权域名服务器数量
- Additional records：附加信息数量

问题（Questions）部分包括：
- 查询的域名 8bit 为单位，长度不受限
- 查询的协议类型 16bit
- 查询的类 16bit
回答（Answers）/权威（Authoritys）/附加（Additionals）部分格式相同：
- NAME 资源记录包含的域名.
- TYPE 表示 DNS 协议的类型.
- CLASS 表示 RDATA 的类.
- TTL 4 字节无符号整数表示资源记录可以缓存的时间。0 代表只能被传输，但是不能被缓存。
- RDLENGTH 2 个字节无符号整数表示 RDATA 的长度
- RDATA 不定长字符串来表示记录，格式根 TYPE 和 CLASS 有关。比如，TYPE 是 A，CLASS 是 IN，那么 RDATA 就是一个 4 个字节的 ARPA 网络地址。

RRs 说明

每个 DNS 响应报文包含一条或者多条资源记录（resource records ，RRs），资源记录包含下列字段的 4 元组：

（Name，Value，Type，TTL）

其中 TTL 表示生存时间，决定了资源记录应该从缓存中删除的时间。

如果是 Type=A，Name 为主机名，Value 是对应的 IP 地址（如 bar.foo.com，xxx.xxx.xxx.xxx，A）
如果是 Type=NS，Name 为一个域（如 foo.com），Value 是知道如何获取该域中的主机 IP 地址的权威 DNS 服务器的主机名（如 foo.com，dns.foo.com，NS）
如果是 Type=CNAME，Value 是别名为 Name 的主机对应的规范主机名。（如 foo.com，relay1.bar.foo.com，CNAME）
如果是 Type=MX，Value 是别名为 Name 的邮件服务器对应的规范主机名。（如 foo.com，mail.bar.foo.com，MX）

实例

这里我们使用 WireShark 抓包实际看看，启动 WireShark 时可以设置捕获过滤器为：

udp port 53

这样我们只抓取通过 UDP 53 端口的 DNS 请求，此外如果需要仅仅显示特定的 DNS 查询，还可以进一步应用显示过滤器，例如这里我们仅查看www.techkoala.top的查询记录，则显示过滤器设置为：

dns.qry.name==www.techkoala.top

16 进制表示" >

16 进制表示

WireShark 中 DNS 请求报文及其结构" >

WireShark 中 DNS 请求报文及其结构

可以看出

标识为：0x0000cd13
这是一个请求报文，仅在 Questions 部分有值

标志部分各个字段的值：" >

标志部分各个字段的值：

查询部分各个字段的值" >

查询部分各个字段的值

同时 WireShark 还贴心的告诉我们，响应报文的在总抓取包的编号为 10，方便我们快速找到请求报文对应的响应报文。

16 进制表示" >

16 进制表示

WireShark 中 DNS 响应报文及其结构" >

WireShark 中 DNS 响应报文及其结构

标志部分各个字段的值" >

标志部分各个字段的值

查询部分各个字段的值" >

查询部分各个字段的值

参考

[1] Computer Networking A Top-Down Approach
[2] DNS 请求报文详解

ARP & RARP 详解

Fri, 16 Oct 2020 15:56:34 +0800

ARP 以及 RARP 如何工作？

为什么要有 MAC 地址？

在说明 ARP 以及 RARP 之前，有必要首先说一下 MAC 地址的必要性。

引用《Computer Networking A Top-Down Approach》中的描述：

KEEPING THE LAYERS INDEPENDENT

There are several reasons why hosts and router interfaces have MAC addresses in addition to network-layer addresses. First, LANs are designed for arbitrary network-layer protocols, not just for IP and the Internet. If adapters were assigned IP addresses rather than “neutral” MAC addresses, then adapters would not easily be able to support other network-layer protocols (for example, IPX or DECnet). Second, if adapters were to use network-layer addresses instead of MAC addresses, the network-layer address would have to be stored in the adapter RAM and reconfigured every time the adapter was moved (or powered up). Another option is to not use any addresses in the adapters and have each adapter pass the data (typically, an IP datagram) of each frame it receives up the protocol stack. The network layer could then check for a matching network-layer address. One problem with this option is that the host would be interrupted by every frame sent on the LAN, including by frames that were destined for other hosts on the same broadcast LAN. In summary, in order for the layers to be largely independent building blocks in a network architecture, different layers need to have their own addressing scheme. We have now seen three types of addresses: host names for the application layer, IP addresses for the network layer, and MAC addresses for the link layer.

简单来说：

局域网不仅仅为 IP 和因特网设计，MAC 地址的“中立性”为各种网络层协议（比如 IPX 或者 DECnet)提供了灵活的施展空间
网络层地址往往是动态的，每次更换网络或者重启都需要对适配器进行重新配置
如果取消 MAC 地址，让适配器把收到的每帧都往上层传递，就会带来一个问题：主机会去处理局域网中的每个帧，即使这个帧不属于自己，这就带来了不必要的消耗。

ARP

一句话概括 ARP（Address Resolution Protocol，地址解析协议）的目的就是：负责将网络层地址（最常见的就是 IP 地址）解析为/映射到链路层地址（MAC 地址）。

报文结构

ARP 包结构" >

ARP 包结构

一般我们讨论以太网中的 ARP 报文时候，ARP 数据会被封装在以太网报文中，其中：

以太网报文：
- 目标以太网地址：目标 MAC 地址，FF:FF:FF:FF:FF:FF （二进制全 1）为广播地址
- 源以太网地址：发送方 MAC 地址
- 帧类型：以太类型，ARP 为 0x0806
ARP 报文数据：
- 硬件类型：如以太网（0x0001）、分组无线网
- 协议类型：如网际协议(IP)（0x0800）、IPv6（0x86DD）
- 硬件地址长度：每种硬件地址的字节长度，一般为 6（以太网）
- 协议地址长度：每种协议地址的字节长度，一般为 4（IPv4）
- 操作码 OP：1 为 ARP 请求，2 为 ARP 应答，3 为 RARP 请求，4 为 RARP 应答
- 源硬件地址：n 个字节，n 由硬件地址长度得到，一般为发送方 MAC 地址
- 源协议地址：m 个字节，m 由协议地址长度得到，一般为发送方 IP 地址
- 目标硬件地址：n 个字节，n 由硬件地址长度得到，一般为目标 MAC 地址
- 目标协议地址：m 个字节，m 由协议地址长度得到，一般为目标 IP 地址

工作原理

每台主机都会在自己的 ARP 缓冲区（ARP Cache）中建立一个 ARP 列表，表示 IP 地址和 MAC 地址的对应关系。
当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址，如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包（即将目的硬件地址设置为全 1），查询此目的主机对应的 MAC 地址。此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。
网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 单播响应数据包，告诉对方自己是它需要查找的 MAC 地址；
源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。

代理 ARP

代理 ARP 是指当 ARP 目标不在同一网段时，网关会拦截该 ARP 请求，然后把自己的 MAC 地址回复给请求者：

代理 ARP" >

代理 ARP

但是需要网关需要满足：

开启代理 ARP 功能
有目标的路由信息

假如不存在网关但使用代理 ARP，则情况如下：

代理 ARP" >

代理 ARP

存在网关的情况下，使用正常 ARP，则情况如下：

代理 ARP" >

代理 ARP

总结而言：

没有网关（采用代理 ARP）时：跨网段访问谁，就问谁的 MAC
有网关（采用正常 ARP）时：跨网段访问谁，都问网关的 MAC
无论使用哪种 ARP，跨网段通信时，发送方请求得到的目标 MAC 地址都是网关 MAC

RARP

RARP（Reverse Address Resolution Protocol，逆地址解析协议），顾名思义，用于将 MAC 地址映射为网络层地址（例如 IP 地址），用于给 MAC 地址分配 IP 地址（通常在需要远程启动（类似无盘工作站）的系统中使用）。其由于受限于 IP 地址的运用以及其他的一些缺点，因此渐为更新的 BOOTP 或 DHCP 所取代。

RARP 使用与 ARP 相同的报头结构，只是其中的操作码有所区别，见上文。

工作原理

发送主机发送一个本地的 RARP 广播，在此广播包中，声明自己的 MAC 地址并且请求任何收到此请求的 RARP 服务器分配一个 IP 地址；
本地网段上的 RARP 服务器收到此请求后，检查其 RARP 列表，查找该 MAC 地址对应的 IP 地址；
如果存在，RARP 服务器就给源主机发送一个响应数据包并将此 IP 地址提供给对方主机使用；
如果不存在，RARP 服务器对此不做任何的响应；
源主机收到从 RARP 服务器的响应信息，就利用得到的 IP 地址进行通讯；如果一直没有收到 RARP 服务器的响应信息，表示初始化失败。

安全问题

ARP 欺骗

源主机通过 ARP 协议在局域网内发送广播请求包，按照 ARP 协议的设想应该是对应主机回复，但如果攻击者进行回复，源主机依然会选择相信。这是由 ARP 协议的不验证引起的，它不验证对方是否是所声称 IP 地址的主机。同时，由于 ARP 协议是一种无状态协议，既不验证应答者的身份，也不判断是否发送过 ARP 请求，当收到一条 ARP 应答报文时，它就会更新 ARP 应答缓存表。因此，攻击者甚至可以主动向源主机发送 ARP 响应包，迫使源主机更新其 ARP 缓存表。

对此，一个简单的方法是使用静态绑定地址，但是此方法维护起来较为麻烦。

参考

[1] Computer Networking A Top-Down Approach
[2] 地址解析协议
[3] 逆地址解析协议
[4] 网络协议补完计划–ARP 协议和 RARP 协议

OpenWRT overlay 空间扩容

Fri, 09 Oct 2020 15:57:29 +0800

安装 AdguardHome 运行几天后，可怜的剩余空间被日志耗尽，不得不对 OpenWRT overlay 进行扩容，本文对此进行了记录

什么是 overlay

OpenWRT 一般使用的文件系统是 SquashFS ，这个文件系统的特点就是：只读。

一个只读的文件系统要怎么做到保存设置和安装软件的呢？这里就是使用 /overlay 的分区，overlay 顾名思义就是覆盖在上面一层的意思。虽然原来的文件不能修改，但把修改的部分放在 overlay 分区上，然后映射到原来的位置，读取的时候就可以读到修改过的文件了。

为什么要用这么复杂的方法呢？ OpenWRT 当然也可以使用 EXT4 文件系统，但使用 SquashFS + overlay 的方式有一定的优点。

SquashFS 是经过压缩的，在路由器这种小型 ROM 的设备可以放下更多的东西。
OpenWRT 的恢复出厂设置也要依赖于这个方式。在你重置的时候，它只需要把 overlay 分区清空就可以了，一切都回到了刚刷进去的样子。

如果是 EXT4 文件系统，就只能够备份每个修改的文件，在恢复出厂设置的时候复制回来，十分复杂。

当然，SquashFS + overlay 也有它的缺点：

修改文件的时候会占用更多的空间。首先你不能够删除文件，因为删除文件实际上是在 overlay 分区中写入一个删除的标识，反而占用更多的空间。
另外在修改文件的时候相当于增加了一份文件的副本，占用了双份的空间。

overlay 示意图" >

overlay 示意图

创建新分区

首先，需要创建一个新的分区，这里使用的是 cfdisk

如果此前没有安装，首先使用下列命令进行安装：

opkg update
opkg install cfdisk

然后输入

cfdisk

打开磁盘管理界面：

磁盘界面" >

磁盘界面

这里可以看到，目前一共有两个已有分区，现在新建一个分区：

选中 Free Space，再选中 New，输入需要的大小，比如 5G。

接着选择 primary

选择主分区" >

选择主分区

选择 Write

写入更改" >

写入更改

输入 yes，完成新分区的创建

确认" >

确认

格式化分区

使用命令：

mkfs.ext4 /dev/sda3

格式化分区

格式化分区" >

格式化分区

挂载新分区

使用命令：

mount /dev/sda3 /mnt/sda3

挂载分区

转移到新分区

然后将原来 upper 层中的数据复制到新的分区中：

cp -r /overlay/* /mnt/sda3

Web 界面配置修改

进入 OpenWRT Web 界面的挂载点对配置进行修改：

Web 界面" >

Web 界面

在挂载点下方点击添加，然后如下配置：

挂载点配置" >

挂载点配置

完成

到这一步，只需要重启 OpenWRT 即可成功扩容。

重启后到 系统 -> 软件包 可以看到变大后的空间容量。

自动挂载

分区默认会在 OpenWRT 重启后会自动挂载，如果遇到没有挂载的情况，需要编辑 /etc/rc.local

vim /etc/rc.local

在 exit 0 之前加入一行 mount /dev/sda3 /overlay 即可。

参考

单独编译 OpenWRT ipk 插件

Fri, 09 Oct 2020 15:57:29 +0800

本文介绍如何单独编译 OpenWRT 的 ipk 插件

说明

必须首先完整编译一次固件才能单独编译 ipk

当需要单独更新 OpenWRT 某个插件或者需要增加安装某个插件的时候，可以单独编译对应的 ipk 插件进行安装，而不必编译整个系统。

下载源码

使用 git clone 对应的源码插件到下面的文件夹中

存放路径

~/lede/package

配置

make menuconfig

然后进入对应的子菜单中找到对应插件按表示选中插件，但不编译进固件。

编译

make package/xxxxx/compile V=99

xxxxx 就是你需要单独编译的程序。

ipk 生成路径

~/lede/bin/packages/x86_64/xxxx

上传 ipk 至路由器

scp xxxxxxx.ipk root@192.168.1.1:/tmp

安装

opkg install /tmp/xxxxx.ipk

5G 将是一个彻底的失败

Sat, 03 Oct 2020 00:17:12 +0800

为什么说 5G 将是一个彻底的失败？

注：本文系全文转载，原文信息如下：

作者：杨学志

链接：https://www.txrjy.com/thread-1061715-1-1.html

来源：通信人家园

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

无线通信产业发展史

无线通信产业已经发展了四代，目前正处于 5G 产业化前夕，是当下到一个最热的话题，5G 如何发展，前景如何，是各个方面包括学术界、产业界、投资界以及政府都非常关心的。另外，中国已经启动 6G 研究的消息也见诸报端，未来无线通信产业如何发展，是不是会继续有 6、7、8、9G，也引起了大家的关切。为了回答这些问题，我们首先简单地回顾一下无线通信产业发展的历史。

无线通信产业是由需求和技术两个轮子驱动前进的。

早在 1947 年，贝尔实验室的科学家就提出了蜂窝通信的概念，其中的核心技术是频率复用和切换。基于这一概念，贝尔实验室于 1978 年研制出先进移动电话系统（Advanced Mobile Phone Service，AMPS），这就是第一代移动通信系统。AMPS 是一个模拟通信系统，采用频分多址（FDMA）的复用技术，主要技术手段是滤波器，容易受噪声的干扰，语音质量较差。

随着集成电路技术的发展，第二代移动通信系统采用了数字技术，并采用 TDMA 和信道编码技术，使得通信系统向宽带化发展，语音质量得到了较大的改善。其中欧洲制定的 GSM 系统非常成功，至今仍在广泛使用。

20 世纪 90 年代互联网蓬勃发展，顺应这一时代要求，产业界制订了 3G 标准用以实现移动互联网。3G 采用了高通公司开发的 CDMA 技术。CDMA 一度被认为是一个神奇的技术，高通公司宣称 CDMA 的频谱效率可以达到 AMPS 的 18 倍，但是实践表明这个观点太过于浮夸了，CDMA 存在自干扰问题，其频谱效率只比 GSM 高 10%左右，并且 3G 的主流标准 WCDMA 的系统设计过于复杂，导致部署成本比较高，所以一直无法替代 GSM 系统。

第四代移动通信采用了 OFDM 技术，从根本上克服了 CDMA 的技术缺陷，并且简化了系统设计，成就了一代成功的移动通信系统。OFDM 如何克服 CDMA 的缺陷，具体可以参考我的《通信之道-从微积分到 5G》。

如果我们稍微总结一下，可以发现，1G 发掘出了移动通信的巨大需求，但是采用了比较落后的技术体制，因此长不大。2G 进行了数字化革命，从而获得巨大成功。3G 是为了新出现的移动互联网需求而诞生，但是在技术上走了弯路，全球的 3G 业务都不是太成功；而 4G 回归了正确的技术路线，目前 4G 业务蓬勃发展。

随着 4G 的成功商用，按照无线通信十年一代的发展规律，产业界开始了 5G 的研发。按照业界目前的一般口径，5G 在 2020 年左右开始规模商用。中国政府已经为 5G 分配了 500MHz 的频谱，三大运营商也已经在多个城市开展了商用实验，商用前的准备工作正在紧锣密鼓地进行。很多人认为 5G 牌照会在年内（2019）发放。

对于 5G 的讨论，也要从技术和需求两条线来讨论。

无线通信技术体制

无线通信产业基本上可以用“端管云”三个字进行概括。端就是终端，包括电脑， PAD，手机等。云就是存储在网络上的内容，如新浪、百度、淘宝的数据中心，而管就是连接终端和云之间的这条通道。

端管云

这条管道可以分为两段。一段是终端到基站（或者路由器），这段是无线通信，也叫空中接口；另一段是基站到云，是有线通信。云都是挂在因特网上的，因此因特网是这条管道当中必经之路。移动通信有核心网，基站首先挂在核心网上，再连接到因特网。核心网主要是起运营支撑作用，比如身份的识别，计费等等。而另一个体系是大家都熟悉的 WiFi，没有核心网，路由器是直接戳到因特网的。这就构成了两大生态体系，也就是传说中的 CT 和 IT，它们之间的合作与竞争将贯穿无线通信产业的走向。

在无线通信产业当中，空中接口这一段的产值，包括终端和基站，占绝大部分。如果做一个类比，通信网络可以类比人体的循环系统或这神经系统。骨干网的部分可以类比中枢神经或者主动脉，虽然容量很大，但是只有几条。骨干网络的销售额不大，但是占据战略制高点；而空中接口部分相当于神经末梢或者毛细血管，数量庞大，占据无线通信产业的主要市场份额。

有线网络现在都光纤化了。光纤的发明是基于高锟的理论，他因此获得诺贝尔奖。光纤的容量大，成本低，彻底改变了人类通信的面貌。最早的光纤线路的速率只有 45Mbps，后来以令人乍舌的速度发展，目前一根光纤已经可以达到 1Tbps。而光纤要比同等长度面条便宜，这是真正的高科技。早期光纤只用于骨干线路（比如北京和上海之间），随着成本的降低，目前光纤已经入户了。由于光纤的存在，有线网络的主要工作在于怎么组织和利用光纤的容量，如 IPV6，SDN 等等，基本上是逻辑性的工作，总体来说是比较简单的。

空中接口部分就比有线网困难多了。在有线通信当中，信号在一个精心制造的介质里面传播，无论是铜线还是光纤，信号质量非常好，随便搞搞就能达到很高的速率。而无线信号的传播环境就恶劣得多得多。无线电波在传播过程中衰减很快，还受到建筑物、山体、树木的阻挡，很多时候需要经过反射或者穿透障碍物才能达到接收机。并且，无线电波不是规规矩矩地沿着规定的路线走，会走到不希望的地方，造成对他人的干扰。但是无线通信有一个好处，就是摆脱了线的束缚，可以拿着手机随便走，这种便利性是有线通信所无法比拟的。所以尽管挑战很大，无数的研究者前仆后继，攻克无线通信当中的道道难关。

网络分层协议

刚才说的这些事，背后是网络的分层结构。最底下的一层叫物理层，其他的可以和合并起来叫高层。物理层是处理物理信号的，比如电或者是光，就是如何把信息转换成可以用来传输的电信号或者光信号。物理层解决的是通信能力的问题，或者是带宽的问题。有了这么多的带宽之后，怎么组织和利用是高层要做的事。

这个和邮政系统非常类似。物理层相当于运送信件或者包裹的方式，可以是马车，汽车、轮船、飞机，这提供了运送的能力。但是寄信的时候，我们要在信封上写通信地址，要跑到邮局交给柜台，后然分拣打包装车，到了目的地后要有邮递员送到收信地址，这些都是高层做的事情。

所以大家能看出来，通信网络的核心技术在物理层。当然高层也必不可少，但相对来说可以变化的空间不大。如果说我们的邮政系统比以前先进，主要不是体现在邮局的布置上，而是运输方式的改进，以前是马车，现在改飞机了。虽说邮局也进步了，比如装了玻璃柜台，或者信件实现了机器分拣，但不是主要的因素。

光纤是现代通信网络的最重要的基石，就是物理层技术。高层技术当中大家最熟悉的是 IP 协议。IPV4 获得广泛应用后，虽说存在一些问题，试图通过 IPV6 去解决。但是 IPV6 经过二三十年也没有取代 IPV4，就是因为高层技术相对简单，改进的空间不大。

无线通信技术演进

同样，空中接口的核心技术也在物理层，每一代移动通信是由这些核心技术所定义的。这些核心技术，也就是《通信原理》课程里面的知识。

3G 核心技术

空中接口的核心技术可以分为 5 个大类，分别是调制、编码、多址、组网和多天线。比核心技术更基础的是基础理论，包括电磁理论和信息论。

大家都知道，高通公司开发了 CDMA 技术，并且成为 3G 三大标准（ WCDMA，CDMA2000 和 TD-SCDMA）的核心技术，从而一跃成为芯片业巨头。上图所示的是 WCDMA 的核心技术。高通的贡献主要在多址和组网两个领域。

虽然普遍认为高通开发了 CDMA 技术，但是 CDMA 并不是高通发明的，发明人是好莱坞艳星海蒂.拉玛。CDMA 技术的标准接收机叫 Rake 接收机，也于 1950 年代由贝尔实验室发明。实际上由于当时普遍认为 CDMA 的保密性好，一直应用于军事通信。而高通解决的是 CDMA 的民用问题，这在当时是普遍不被看好的。

高通解决 CDMA 民用有三招，分别是功率控制（Power Ctrl）、同频复用（UFR）和软切换。功率控制解决远近效应，同频复用提升频谱效率，软切换解决切换连续性。这构成了高通 CDMA 的技术体系。这里只简要介绍一下，技术人员可以参考我的书《通信之道》。因为 UFR 并不是专利，所以高通其实在 CDMA 上就两个核心专利，其中软切换专利获得美国专利局的授权还载入了高通发展史。

3G 在编码领域的主要进展是采用了 Turbo 码，这是法国电信所资助的教授发明的，是通信发展史上的里程碑，因为它首次充分逼近了香农在 1948 年所提出的信道容量。
在多天线领域，Alamouti 编码应用到了广播信道多编码。因为广播信道在整个业务当中的比重并不大，所以这个编码的作用相对重要性低一些。但是这个编码是多天线技术领域的里程碑，有非常大的影响力。
调制是最基础的通信技术，没有之一。因为基础，所以稳定，一直到现在的 5G 都没有太大的变化。

可以看出，高通在 3G 的多址和组网两个方面拥有核心技术。当然，在把核心技术工程化的过程当中也建立起由几千个专利组成的专利组合。凭着这些专利和芯片的联合运作，收取了大量的高通税。

其实从现在的眼光看，Turbo 码和 Alamouti 码是更重要的核心技术。但这两个核心技术在法国电信和 ATT 这样的大公司里面，没有进行商业化运作的机制，只是收了一些专利费，没有形成象高通这么大的商业。

4G 核心技术

到了 4G 之后，CDMA 技术被 OFDM 技术所取代。主要的原因是 CDMA 存在自干扰的问题。高通的功率控制和软切换试图去解决这个问题，但采取的方法是在 CDMA 缺陷的基础上进行补救，但是怎么补也补不彻底。

而 OFDM 从根本上克服了 CDMA 自干扰的缺陷，使得频谱效率得到了很大的提高，那这些补救措施也就没必要了。所以在 4G 时代，高通的技术体系被摧毁了。采用 OFDM 技术带来了新的问题，解决这些问题导致了三个创新的出现，这就是我在华为提出的 sOFDM 和软频率复用（SFR）以及爱立信提出的 SC-FDMA 技术。我在华为还提出了随机波束赋形（random beam forming）技术，解决了非常火热的循环延时分集（Cyclic Delay Diversity）的严重缺陷。在调制和编码领域仍然采用了 3G 的方案。

可以看出，华为在 4G 的核心技术上已经取代了高通。但是很可惜，由于华为公司的跟随基因，无法发挥手上的专利核武的威力，还要向高通交钱，也只是向苹果收了点小钱。但是华为因此避免了专利核武打击，加上华为在产品上的优势，所以华为日子过得很好，在 4G 时代成为第一大设备制造商。

5G 核心技术

5G 标准已经制定完成了，盖棺定论后已经可以看得很清楚了。

首先调制这块还是没有变，太基础了，想变也变不动。

因为联想投票门的事情，编码这块的故事很多人都知道。相比于 3G/4G 采用的 Turbo 码，5G 采用了 LDPC 和 Polar 码。这两个码都是鼎鼎大名，是 Turbo 码之后通信技术发展的里程碑性的技术。但是由于 Turbo 码已经比较接近香农限，虽然这两个码更接近，但是对系统容量的提升已经不大，大概是 1 ～ 2%左右。

多址这块，对于 5G 三大场景之一的 eMBB 这块没有变，还是采用了 OFDM。其中爱立信提出的 SC-FDMA 从 4G 的必选项变成了可选项，这是因为它相对于 OFDMA 并没有什么技术优势。

多址这块 NOMA 有很大的热度，一度被公认为 5G 的必选技术。5G 标准的早期，几乎所有的厂家都支持这个方向。但是经过我的论证，NOMA 比 OFDM 的增益严格为零，这是用信息论严格证明的。所以 NOMA 既复杂又没增益，属于技术退步。

另外华为还推了 F-OFDM，与 sOFDM 正好相反。sOFDM 的思想是所有的带宽所有的环境都用统一的参数，从而获得规模经济效应。F-OFDM 强调对不同的环境采用不同参数从而更好的适应环境。这种做法并没有什么增益，反而丢失了规模效应这个大西瓜，也属于技术退步。

组网方面没有听到什么消息，工作假设应该还是同频复用。SFR 和 CoMP 都是组网方案。SFR 非常简单，不需要标准化。CoMP 虽然一度被认为是更先进的技术，但经历了轰轰烈烈的标准工作和产品开发之后，已经是失败了。

多天线这块最响亮的就是 massive MIMO，号称可以成百倍地提升系统容量，从媒体上看几乎可以是 5G 的代名词。 MIMO 这个理论 1995 年提出，已经 23 年了。它所揭示的对容量的巨大提升致使它一直是学界和工业界的热点。但是这个技术一直到 4G 都不是很成功。这个技术有个特点，一演示就成功，一实用就趴窝。记得 20 年前我还是小白的时候，在电信展上就看到厂家演示空分复用，用相同的时频资源实现两个用户的同时通信，还互不干扰。在一个选择的场景下 MIMO 技术是很容易演示成功的，但是在复杂的实际环境中所涉及的问题的难度，是两个数量级的差别。当然 MIMO 是一个有潜力的领域，但是其实用化问题仍然没有解决。

MIMO 的问题还在于，虽然能够提高容量，但是要增加设备，有成本的。其实 MIMO 最朴素的应用就是古老的三扇区天线，一个全向小区分割成三个扇区，容量在理论上增加了三倍，这就是 MIMO 的原理，虽然说是古板了一点。所以粗暴一点，搞个 9 扇区，12 扇区，也就是 mMIMO 了，这个华为已经有产品了。这和是不是 5G 没关系。

综合来看，5G 相对于 4G 来说，几乎没有技术进步，在一些地方还退步了。比如说 NOMA，F-OFDM，还有为了保证短时延而采用的自包含结构。

还有，5G 采用了更高的频谱。在中国是 3.5GHz，还好一点。美国用了 28GHz。频率越高覆盖越小，这是无线通信的基本知识。所以同样的网络覆盖，比起 4G 的 2.6GHz，3.5GHz 的投资要高出 50%（我也是看来的，看起来合理），而 28GHz 实现覆盖就是开玩笑了，花 5 倍的银子也是正常的。所以从技术角度看，5G 比 4G 没有进步，成本会更高。

5G 需求

5G 的需求，大概可以用高速率、低延迟、大连接来概括。

大家知道，4G 设计当初的速率目标是 100Mbps，随着技术的演进，4G Cat 11 的速率已经达到 600Mbps。5G 进一步把速率目标提高到 1Gbps 以上。为了满足一些低延迟业务的需求，5G 要求空中接口的延迟时间为 1ms，而 4G 的这一指标为 30ms 左右。4G 主要是为移动互联网设计的，强调的是人与网络之间的高速连接，而同时连接到网络的终端的数量并不是一个需要特别考虑的问题。而在蓬勃发展的物联网时代，每一件物体都有可能有联网要求，因此连接数量会有数量级的增加，5G 需要具有支持海量连接的能力。

5G 最抓眼球的就是它的速率。看新闻经常是比光纤还快，一秒下一个大片，快到把人脸吹成骷髅，等等。但是有什么样的业务需要这样的速率呢？

虽然暂时想不出，但是有一个非常流行的观点是，先修好路，自然会有车。3G、4G 都是这样，微博、微信、抖音什么的，以前根本就想不到。等 4G 来了之后，这些应用也就有了。

很显然，这个观点首先在逻辑上就有很大的问题。修好了路没有车也很正常啊，你就没见过没人走的路吗？按照 3G、4G 的情况去推断 5G，这个也不靠谱。就像你已经活了 80 岁，不能按此推断你还能再活 80 岁。2G 和 3G 都处于带宽短缺的时代，所以形成了修好路必有车的错觉。然而到了 4G 之后，带宽已经不再短缺了。

还有一个流行的观点是，科技发展往往超出人的想象力，所以保守的预测往往是错误的。比如比尔盖茨当年说，计算机 640k 内存应该是够了。而现在已经是 640G 了，6 个数量级的增长。

必须认识到，通信和计算机有很大的不同。

计算机所涉及的所有零部件，CPU，内存，硬盘，都有一个共同的源泉就是半导体工艺。半导体集成度在近十年提高了 1000 倍，大家共同水涨船高。但是通信不一样。通信需要一个受体，以目前最广泛的 eMBB 为例，这个受体就是人。人是肉长的而不是沙子做的，它能够处理的最大信息速率，也就是带宽，是固定的，超过了人的带宽是没有意义的。

通俗一点说，我在 PAD 上看片，我一般看缺省的高清格式，尽管有超清格式，我一般不会主动选择。为啥？因为我的老花眼看不出二者的区别。当然眼睛好的人还是应该能分出来的。高清视频也就是 1 ～ 2Mbps 的速率，目前的 WiFi，4G 都远远地超出了我的需求。

当然，有人会反对。比如目前 4K/8K 视频很火热，有朋友跟我说，看了 4K 视频之后，其他的都没法看了。我天天看高清格式视频，倒是没这种感觉了。当然对于 60 寸的大电视，提高分辨率还是有必要的。但是电影院的屏幕，目前还只是 2K，我认为 4K/8K 更多的是心理上的。用户挑电视的时候会靠在跟前看屏幕上的一小块区域，一个像素一个像素地检查，4K/8K 当然要好。如果在正常观看距离上，比如 2 米，4K 和 2K 会有明显区别吗？我没试验过啊，有兴趣的朋友可以做一下双盲实验。

即使是 4K 视频，速率也只有 30Mbps，4G 支持也不费力啊，怎么会有 1Gbps 的需求呢？这就要说到虚拟现实 VR 了。 VR 要求有沉浸式的体验。啥叫沉浸式？在真实的场景当中，如果我们慢慢地转头，看到的景物也就连续地变化，这就是沉浸的意思。VR 要实现这种效果，不光要传给你正在看的东西，没看的东西也要传给你，转头的时候要现传新视角上的数据来不及，会出现卡顿，就不是沉浸式体验了。这样一来，数据量再增加 30 倍，差不多就到 1G 了。5G 的 1G 速率的需求就是这么来的。

VR 作为一种创新的视频形式，相信能够获得一定的应用。VR 的麻烦在于需要一个专门的头盔，哪怕是手机盒做的简易型的，都是不方便携带的。这么一来 VR 一般发生在室内，而且一般是专门用途的场景，比如房地产或者旅游景点的体验店什么的。这些业务一般不会走移动通信，更多的是 WiFi 或者专线。

总是有很多朋友寄希望于未来可能出现的未知业务。虽然具体的业务会层出不穷，我们确实无法预测，但是只要最终的受体是人，人感受信息的通道就是眼睛和耳朵，鼻子舌头皮肤还都用不上，人类进化出新的感觉器官最少也得是 100 万年以后的事情。人眼的带宽就确定了通信的最大速率，这是一个物理瓶颈，不管什么应用出现都是无法突破的。

从现实的情况看，WiFi 的速率总是领先移动网的，即使 WiFi 已经提供给我们 100M 的带宽了，但是我门最多应用的速率还是 1～2M，超出 10M 以上的应用非常少，也只有下载软件的时候有时会达到。所以其实 4G 的速率已经超出需求了，5G 的高速率完全是没必要的。

人的感官能力对时延同样是一个决定因素。

时延当然越短越好，没有人会不喜欢短时延，但是信息论的基本原理决定了短时延会造成高成本。信道编码依靠的是大数定律实现可靠通信，要达到信道容量，理论上需要无穷的时延。因此这个固有原理因素就决定了时延不能非常短。这里就不说其他的处理时延、排队时延和反馈时延了。非要实现低时延也有方法，就是把效率降低，用很高的信噪比去实现很低的速率。这个成本就太高了。任总一直在说，大速率、低时延的通信技术还没有实现。其实根本就不存在这样的技术。

要知道人的感官时延大概是 100 毫秒左右，所以 4G 几十毫秒的时延是比较合适的，1ms 的时延对人没有意义。所以，只要有人参与的应用，就不需要低时延。比如常用的微博微信，甚至是很多人认为需要低时延的手机游戏，在 WiFi 上不都玩得挺好吗。

自动驾驶是被广泛误解为需要低时延的应用。你可以经常看到有文章说，低时延使得刹车距离更短，从而更安全。但是这要基于一个假设，就是刹车指令是通过 5G 网络从远程控制中心传送给汽车的。显然实际的解决方案不是这样。象刹车这种对时延和可靠性要求都非常高的指令，只能由车在本地产生，采用尽量短的回路。依靠网络传输的，是路线规划和路况信息这样的对可靠性和时延没有特殊要求的信息。Google 汽车已经跑了几百万公里了，并不需要一个低时延的网络。甚至没有网络的时候，汽车也应该能跑，这是起码的要求。

基于同样的原因，象无人工厂这些工业应用也无法通过 5G 网络实现。5G 是一个公共网络，对经济性的要求决定了它无法达到工业级的可靠性。不是说技术上做不到工业级的可靠性，而是能做到也不做，太贵了公众用不起。所有的工业应用必须用专线。远程手术也是同样的道理。

对于这个话题，你经常会看到一个很高大上的技术叫网络切片，意思是在 5G 网络上切出一个高可靠性的通道出来，用来满足工业应用。但是这实际是不可能做到的。一个系统的可靠性取决于最薄弱的一环。如果 5G 网络采用统一的硬件设施，如果不想多花钱，就已经决定了这是一个民用级别的可靠性，是不可能在软件上做点工作使之达到工业级的可靠性。就像特朗普车队，要清道、设岗，要有探路车、开道车、救护车、通信车、陆军一号这些硬东西，要花大把的银子。单靠在大街上挂几个标志是无法保证总统安全的。

虽然低时延高可靠性（uRLLC）是 5G 定义的三大场景之一，但是这与 5G 作为一个公共网络的基本特征相矛盾，是绝无可能实现的。

刚才所说的自动驾驶和无人工厂，属于物联网的例子。接下来我们聊聊普遍意义的物联网。

有句非常有名的话，叫做4G 改变生活，5G 改变社会，说的就是物联网。5G 使我们的社会从互联网发展到万物互联的社会。

虽然普遍认为目前处于物联网爆发的前夕，但是有个问题，物联网未必是移动通信的菜。

移动通信是怎么来的呢？起初就是人要打电话，要到处跑，不光在本地跑，还要出差，还要出国。这个特点要求移动需要统一标准，全球统一。所以要有个叫 3GPP 的组织，几百个公司的人一起制定这个标准，扯来扯去效率是很低的。还要搞个核心网去支持运营，运营商还要养着一大票的运维人员，这些特点就决定了移动通信会比较贵。

所以说，除非移动，不然没有必要用移动通信。这样移动通信的客户群就很明确，一是人，二是车，另外还有野生动物。所以 eMBB，车联网，野外科学考察等等，是移动通信的正经业务。

但是大多数东西是不动的。在 WiFi 已经普及的情况下，很大的一块业务会被 WiFi 分流，比如智能家居。并且 eMBB 是 2C 的，而物联网多数是 2B 的，象油田，电力公司这些大企业更倾向于自建网络，就不用向运营商交月租了。以 NB-IoT 为例，一个链接每年 20 块的资费对很多应用是很大的一个负担。这就有了象 Lora 这样的系统的生存空间，成本比 5G 低得多。

所以，从 5G 的三大需求看，高速率和低时延的需求都是不存在的，物联网只有小部分落入 5G 的范围。

移动通信与 WiFi

5G 与 WiFi 的关系是无法回避的问题，这其实是本文开始就提到了 CT 与 IT 两大生态体系的关系问题。

首先有一个每个人都能感觉到的事实，WiFi 承载了 80%的流量，我们却不会为它付一分钱，而会为只承载 20% 流量的 4G 付月租。这是为什么？

在信息社会，手机是我们与社会连接的通道。当我们习惯了这种连接之后，丢失连接后就会感到恐慌。很多人一有机会就查一下微信，微博，电邮，股票，彩票，生怕遗漏了重大机会，或者没能及时回复。也就是说，随时随地与社会连接，是我们的刚需。要满足这种刚需，需要一个广覆盖的网络，这正是移动通信的目标和功能。

在 WiFi 火热的时候，有些城市试图建设 WiFi 城市，用 WiFi 来实现覆盖，但是最终都失败了。因为 WiFi 是由 IT 界设计的，生来就缺乏实现广覆盖的能力。这表现在技术方案上，就不在这里细说了。后来 IT 界把 WiFi 升级到 WiMax，试图与 CT 竞争，但是 IT 界的基因还是导致了 WiMax 的失败，并且导致北电破产。

由于 WiFi 无法实现广覆盖，它被定义为固网的延伸，已经成功渗透到了多数的家庭、酒店和办公室，目前 WiFi 的实测速率已经达到 300～400Mbps。 WiFi 提供的是特定地点的高速率通信。路由器很便宜，二百块钱一个，用户自己买一个回来自己就能搞定，想把这些路由器集中控制起来收月租显然是不可行的。

IT 与 CT 都试图入侵对方领地。早几年的 WiMax 就是 IT 入侵 CT 的一次失败的尝试。这几年，也经常听到各种消息，一会儿是小扎，一会儿是马斯克，都要建全球免费 WiFi，周鸿祎说他掌管中国移动，就全免费。当然都没能成功。移动通信所要求的统一标准、广域覆盖，网归网优，客户管理，都决定了运营商是一个分层的官僚体系，与互联网基因格格不入。中国移动每年营收 8000 亿，够买 6 个 360 了，说免就免了，从哪能捞回来这么些钱？用户愿意交这个钱，非不收，那叫啥呢？

反过来，移动通信能取代 WiFi 吗。WiFi 覆盖小，高速率，成本低，使用非许可频段，决定了其免费的必然性。移动通信要取代 WiFi，也必须达到如此低的成本，并且实现免费。这是否能做到呢？如果 4G 能够利用已有的规模优势，做低成本的 Femto 基站，理论上有可能。但是市场规模太小，菊花大厂看不上眼，现有的管理体制也不能适应。而小厂很难有这个技术能力。所以说也是比较难的。

所以说，移动通信和 WiFi 有各自的应用场景。移动通信能够实现 anytime，anywhere 的连接，能够满足用户的刚需，而 WiFi 便宜，无月租，满足用户高速率的应用需求，将长期共存。

5G 之局

移动通信经过四代的发展之后，人们得到一个似乎的规律，就是单数代不太成功，而偶数代很成功。经过我们的分析后发现，1G 和 3G，都是新的需求促成的，但是技术不太好，而 2G 和 4G 在原有的需求基础上，改进了技术，从而很成功。1G 和 3G 虽然不太成功，但也不能说是失败，毕竟他们是满足新需求的唯一技术。但是到了 5G，需求是虚构的，技术上并没有进步，所以必然是要失败的。

5G 是目前最火热的话题。特别是孟晚舟事件之后，美帝组团打压华为，国人已经把 5G 看成是中美对决的战场。

对于 5G 的立场，任总曾经发表过一个讲话，说 5G 的需求并没有出现。我心里赞叹任总真是到了从心所欲不逾矩的境界，也不为利益所左右。后来徐直军也发表了对 5G 相对保守的观点。但是后来口风变了，任总为自己的讲话向产品线道了歉。后来华为发文表示要坚决打胜 5G 这一仗。

我们已经知道，移动通信的根本的价值在于实现任何时间，任何地点的连接能力，在此基础上提高网络容量。如果没有覆盖这个前提，只是在局部实现高速率是没有商业价值的。比如说大家一直谈论的可见光通信，因为覆盖小只能服务两三个人，速率太高超过了人的带宽，就没有意义了。这个问题对毫米波、太赫兹都是如此。虽然过高的速率没够意义，但是随着用户渗透率的提高，资费的下降，数据量每年增长 30%的情况还会持续很多年。因此移动网络还需要扩容。

移动通信正确对发展方向是，保证连续覆盖的情况下以低成本提高网络容量。当然，并不是我一个人才知道这是正确的方向，实际上这是通信界的常识，2G 和 4G 的成功就是这种模式。

5G 偏离了这种模式，走向了错误的方向。这背后的原因有三个：

通信原理的创新遇到瓶颈
半导体工艺获得了爆炸性的发展
无线产业决策链条太长

通信技术已经发展百年，因为其战略地位和创造财富的能力，全球最强智力投入其中，但凡简单一点的创新早就发掘完了。用于 Turbo 码解码的 BCJR 算法是 1970 年代发明的，在我历经艰辛终于看懂之后，感叹道，这只能与魔鬼做交易才能搞得出来。到 2009 年的时候，随着 Turbo，LDPC，Polar，OFDM，MIMO 等领域的进展并且逼近理论极限，学术界普遍感觉到物理层已经死了，再也无法创新了。象 David Tse 这样的被公认为传承香农衣钵的大咖，也感觉无处可走，转行做生物信息去了。

在此同时，半导体技术得到了爆炸性的发展。大家手上的 U 盘，从 10 年前 128M 变成了现在的 128G。在通信原理无法获得突破的情况下，自然地走上利用强大的算力实现高速率的方向。高算力使得采用更宽的频带，更多的天线成为可能，在通信原理不变的情况下，通过算力使得速率暴力提升 1000 倍是很简单的事情。华为早就整出来 115Gbps 的样机了。看报道我国启动了 6G 研究，速度比 5G 高 10 倍，看得我真是很无奈。

移动通信产业有着与其他产业不同的特点。一般的产业都是研发产品上市，获得反馈并逐步改进，是一个快速迭代的过程。而移动通信要求在什么还没有之前，大家共同商定一个标准，然后按照这个标准做产品。何时启动一代通信标准是战略决策，是由政治领导人和商业领导人来做出的。他们当然会咨询技术专家，但是专家们也未必懂，其中还有巨大的利益博弈，显然并不靠谱。行业认同的宏观规律是十年一代。时间一到，各方力量合力推动，就动手干了。大炮一响，黄金万两。即使实际上不能干，也得创造条件干。所以我们看到 5G 出现了很多奇葩的技术，如全双工，毫米波，现在可见光，太赫兹也要上场了。NOMA 和 F-OFDM 比较起来都算是好的。

一代移动通信标准一旦启动，到产品上市之前，所有的玩家都投入了巨大的成本。鉴于通信产业的战略地位，政府意志也为之背书。大家都绑在这个战车上，即使有问题，在碰到南墙之前是不会停下来的。

所以 5G 的问题，不光是华为的问题，或者是中国的问题，美国、欧洲也都是如此。很多网友看到美帝在 5G 上整华为，就觉得美帝反对的东西肯定很重要。中国长期以来落后，都以美国为灯塔。但是经过改开 40 年，中国国力日渐强盛。而通信产业整体上已经获得了领先地位。在这种竞争格局下，即使美帝也会犯错。什么铱星啊，Wimax 啊，不都是美帝整的吗？所以我们要有独立的判断，而不是被对方的判断左右。随着商用的日益迫近，5G 的问题会逐渐暴露出来。比如最近 ATT 的 5G 造假，韩国 5G 被指无用，澳洲未能按计划推出 5G 服务，等等。希望本文能为各方提个醒，尽量减少损失吧。

因为任总的讲话，我认为华为对 5G 是有清醒的认识的，任总最新的讲话又谈到了 5G 的需求没有出现。5G 成功当然好，又能成为华为的产粮田，况且在舆论上华为 5G 已经领先友商 12 个月。但 5G 失败对华为也是有利的。因为华为有着最齐全的产品线，是行业老大，没有技术创新也就意味着现有格局的固化，华为也就能笑到最后了。当然裁员是避免不了的，这对于通信狗们来说不是个好消息。对于二线的设备商，却是灾难性的，对 5G 的投入无法回收，现有市场份额也会被华为逐渐蚕食。对于高通更是灭顶之灾，3G 专利过期，4G 没专利，然后 5G 没有了，怎么收专利费？早些年嫌设备和手机不赚钱甩给别人了，现在有点傻眼。趁手上还有点银子，想收个恩智浦，也被贸易战给搅黄了。这日子怕是过不下去了。

未来之路

前面已经讲到，移动通信的发展方向是在保证覆盖的情况下，用低成本的技术提高系统容量。这背后的使能器是核心技术的突破。这也是我近二十年的通信技术研究生涯所始终追求的目标。

尽管学界对通信原理的发展前景很悲观，但是情况正在起变化。

我在 2014 年发布了多级软频率复用技术（multilevel soft frequency reuse，MLSFR），是 SFR 技术的增强版。理论表明，SFR 可以提升频谱效率 10%左右，MLSFR 可以提高 30%。值得注意的，这是在不增加任何硬件成本的前提下。这种幅度技术进步，在最近 30 年的通信史上，只有 Turbo 码可以媲美，远远超过高通在 CDMA 领域的技术创新。MLSFR` 将成为未来移动通信组网技术的基石。

影响更加深远的，我已经在信息论上获得了重大突破。大家知道，香农在 1948 年创立了信息论，其中最重要的成果是这个信道容量公式：C=log（1+S/N），是指引着通信技术研究和工业发展的灯塔。

但是香农只给出了最简单的 AWGN 信道的容量。无线通信的信道都是衰落信道，而衰落信道的容量香农只开了个头，后来的学者发展出了一套衰落信道容量的理论，这些可以在经典的通信原理教科书里面找到。

但是，目前的衰落信道容量理论是错误的。

这个问题我思考了 14 年，终于提出了新的衰落信道容量理论并在 2018 年 3 月份完成了论文初稿。大家可以体会一下基础研究的周期。审稿的过程也非常艰苦。开始投稿了 Nature，但是 Nature 认为满篇都是公式的稿件不符合它们的风格，还是投到应属期刊 IEEE Transactions on Information Theory。经过 5 个月的评审被拒，原因是两个评委认为论文对信息论存在误解。想想当年 Turbo 码论文，评委认为存在 3dB 的误差。重大突破被误解恐怕是一个规律，创新者需要有这样的心里准备。但是另外一位评委给予了全面的肯定。当然，所有的评审意见都很容易回答，稿件修改之后再次投稿后，评审又进行了三个月，还没有出结果。在中美贸易战的背景下，美国在整华为，也难保政治不会侵蚀学术道德。不管怎么样，大家很快就能看到了。

基础理论的突破预示着无线通信产业的又一次技术革命，而中国就是这次革命的源头。

成功的道路并不拥挤，我们砥砺前行。

致敬改革开放 40 周年。

Linux 系统信息查询

Sun, 13 Sep 2020 22:35:06 +0800

记录一些常用的 Linux 系统信息查询命令

日常使用 Linux 过程中，偶尔会需要查询一下系统信息，特别是在对于使用云端主机时，了解必要的信息十分重要。本文总结了一些常用的信息以及相应的查询命令。

技巧

善用 grep 类命令作为配合，高效筛选想要的信息内容。

系统信息

$ uname -a              # 查看内核/操作系统/CPU 信息
$ head -n 1 /etc/issue  # 查看操作系统版本
$ hostname              # 查看计算机名
$ lspci -tv             # 列出所有 PCI 设备
$ lsusb -tv             # 列出所有 USB 设备
$ lsmod                 # 列出加载的内核模块
$ env                   # 查看环境变量

系统资源

$ cat /proc/cpuinfo             # 查看 CPU 信息
$ lscpu                         # 查看 CPU 信息
$ lshw -short                   # 当前服务器 CPU、内存、磁盘等详细信息
$ free -m                       # 查看内存使用量和交换区使用量
$ df -h                         # 查看各分区使用情况
$ du -sh                        # 查看指定目录的大小
$ grep MemTotal /proc/meminfo   # 查看内存总量
$ grep MemFree /proc/meminfo    # 查看空闲内存量
$ uptime                        # 查看系统运行时间、用户数、负载
$ cat /proc/loadavg             # 查看系统负载

磁盘和分区

$ mount | column -t         # 查看挂接的分区状态
$ fdisk -l                  # 查看所有分区

网络信息

$ ip                    # 查看网络相关信息，具体用法参见 man 手册
$ iptables -L           # 查看防火墙设置
$ route -n              # 查看路由表
$ netstat -lntp         # 查看所有监听端口
$ netstat -antp         # 查看所有已经建立的连接
$ netstat -s            # 查看网络统计信息

进程查询

$ ps -ef            # 查看所有进程
$ top               # 实时显示进程状态
$ htop              # 实时显示进程状态，加强版 top

用户信息

$ w                             # 查看活动用户
$ id <用户名>                    # 查看指定用户信息
$ last                          # 查看用户登录日志
$ cut -d: -f1 /etc/passwd       # 查看系统所有用户
$ cut -d: -f1 /etc/group        # 查看系统所有组

服务

$ crontab -l                    # 查看当前用户的计划任务
$ chkconfig –list               # 列出所有系统服务
$ chkconfig –list | grep on     # 列出所有启动的系统服务

软件信息

$ apt list --installed          # 显示 apt 安装的软件
$ pacman -Qmeq                  # 显示 aur 软件
$ pacman -Qneq                  # 显示 pacman 安装的软件
$ pactree package_name          # 显示软件的依赖树

5G NR 系列：波束赋形

Wed, 09 Sep 2020 16:14:29 +0800

什么是波束赋形？波束赋形的基本原理是什么？5G 怎样实现波束赋形？

注：本文系全文转载，原文信息如下：

作者：无线深海

链接：https://zhuanlan.zhihu.com/p/144971077

来源：知乎

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

什么是波束赋形？

波束赋形这个概念可以拆分成波束和赋形这两个词来理解。

波束里的波字可以认为是电磁波，束字的本意是“捆绑”，因此波束的含义是捆绑在一起集中传播的电磁波
赋形可以简单地理解为“赋予一定的形状”

合起来，波束赋形的意思就是赋予一定形状集中传播的电磁波。

分散与集中的光线" >

分散与集中的光线

其实，我们常见的光也是一种电磁波，灯泡作为一个点光源，发出的光没有方向性，只能不断向四周耗散；而手电筒则可以把光集中到一个方向发射，能量更为聚焦，从而照地更远。

无线基站也是同理，如下图所示，如果天线的信号全向发射的话，这几个手机只能收到有限的信号，大部分能量都浪费掉了。

分散与集中的电磁波" >

分散与集中的电磁波

而如果能通过波束赋形把信号聚焦成几个波束，专门指向各个手机发射的话，承载信号的电磁能量就能传播地更远，而且手机收到的信号也就会更强。

因此，波束赋形在无线通信中大有可为。

波束赋形的基本原理是什么？

波束赋形的物理学原理，其实就是波的干涉现象。

频率相同的两列波叠加，使某些区域的振动加强，某些区域的振动减弱，而且振动加强的区域和振动减弱的区域相互隔开。

想象一下，在湖边漫步时，你和女朋友在相距很近的两点激起水波，两朵涟漪不断散开，然后交叠起来，形成了下面的图样。

波的干涉现象" >

波的干涉现象

可以看出，有的地方水波增强，有的地方则减弱，并且增强和减弱的地方间隔分布，在最中间的狭窄区域最为明显。

如果波峰和波峰，或者波谷和波谷相遇，则能量相加，波峰更高，波谷更深。这种情况叫做相长干涉。

反之，如果波峰和波谷相遇，两者则相互抵消，震动归于静寂。这种情况叫做相消干涉。

如果把这个现象抽象一下，可以得到下图：

波的干涉" >

波的干涉

在两个馈源正中间的地方由于相长干涉，能量最强，可以认为形成了一个定向的波束，也叫做主瓣；两边则由于相消干涉能量抵消，形成了零陷，再往两边又是相长干涉，但弱于最中间，因此称作旁瓣。

如果我们能继续增强正中央主瓣的能量，使其宽度更窄，并抑制两边的旁瓣，就可以得到干净利落的波束了。

其实，普通天线一直在做这样的事情。

天线内部排布着一系列的电磁波源，称作振子，或者天线单元。这些天线单元也利用干涉原理来形成定向的波束。

单列天线" >

单列天线

由上图可以看出，纵向排列的天线单元越多，最中间的可集中的能量也就越多，波束也就越窄。

但这只是一个垂直截面而已，其实完整的波束在空间是三维的，水平和垂直的宽度可能截然不同。

下图是一个天线的振子排列，以及辐射能量三维分布图。

纵向双列天线" >

纵向双列天线

可以看出，上述天线内振源的排布方式为纵向，横向的数量很少，因此其波束在垂直方向的能量集中，而水平方向的角度还是比较宽的，像一个薄薄的大饼。

这种传统的天线水平方向的辐射角度多为 60 度，进行大面积的地面信号覆盖是一把好手，但要垂直覆盖高楼就有些力不从心了，称作“波束赋形”还是不够格。

如果我们把这些天线单元的排布改成矩形，电磁波辐射能量将在最中央形成一个很粗的主瓣，周边是一圈的旁瓣，这就有点波束赋形的意思了。

矩形天线" >

矩形天线

为了让波束更窄能量更集中，天线单元还需要更多更密，水平和垂直两个维度也都要兼顾，原本的天线就变成了大规模天线阵列。

大规模矩形天线" >

大规模矩形天线

这下，生成的波束就犀利多了，用大规模天线阵列来支持波束赋形，稳了！

但是这样还有问题，那就是这个最大波束位于正中央，且其传播方向和天线阵列垂直，而手机是一直随着用户移动的，所在的位置完全不确定，主波束虽然犀利，但照射不到手机上也是白搭。

那么，能不能让波束偏移一定的角度，对准手机来发射呢？

首先我们看看中央的主波束的形成过程：多列波的相位相同，也就是波峰和波谷在同一时间是对齐的，则它们到达手机时，就可以相长干涉，信号通过叠加得以增强。

到达同相，相长干涉" >

到达同相，相长干涉

如果手机和天线阵列有一定的夹角，则各列波到达手机时，相位难以对齐，可能是波峰和波谷相遇，也可能是在其他相位进行叠加，难以达到相长干涉，信号叠加的效果。

到达异相，无法相长" >

到达异相，无法相长

这可咋办？总不能通过旋转天线来让波束跟随手机吧？

其实，周期性是波最大的特点，不同的相位总是周期性的出现，错过了这个波峰，还有下一个波峰要来，因此相位是可以调整的。

通过调整不同天线单元发射信号的振幅和相位（权值），即使它们的传播路径各不相同，只要在到达手机的时候相位相同，就可以达到信号叠加增强的结果，相当于天线阵列把信号对准了手机。

相位控制" >

相位控制

下图是一个示例，可以看出天线阵列通过调整发射信号的相位，让波束偏移了 θ 度，从而可以精确对准手机发射信号。

相位控制" >

相位控制

5G 怎样实现波束赋形？

由此可见，波束赋形的关键在于天线单元相位的管控，也就是天线权值的处理。

根据波束赋形处理位置和方式的不同，可分为

数字波束赋形
模拟波束赋形
混合波束赋形

模拟波束赋形

所谓模拟波束赋形，就是通过处理射频信号权值，通过移相器来完成天线相位的调整，处理的位置相对靠后。

模拟波束赋形" >

模拟波束赋形

模拟波束赋形的特点是基带处理的通道数量远小于天线单元的数量，因此容量上受到限制，并且天线的赋形完全是靠硬件搭建的，还会受到器件精度的影响，使性能受到一定的制约。

模拟波束赋形框图" >

模拟波束赋形框图

数字波束赋形

数字波束赋形则在基带模块的时候就进行了天线权值的处理，基带处理的通道数和天线单元的数量相等，因此需要为每路数据配置一套射频链路。

数字波束赋形" >

数字波束赋形

数字波束赋形的优点是

赋形精度高
实现灵活
天线权值变换响应及时

缺点是

基带处理能力要求高
系统复杂
设备体积大
成本较高

Sub6G 频段，作为当前 5G 容量的主力军，载波带宽可达 100MHz，一般采用采用数字波束赋形，通过 64 通道发射来实现小区内时频资源的多用户复用，下行最大可同时发射 24 路独立信号，上行独立接收 12 路数据，扛起了 5G 超高速率的大旗。

数字波束赋形框图" >

数字波束赋形框图

在毫米波 mmWave 频段，由于频谱资源非常充沛，一个 5G 载波的带宽可达 400MHz，如果单个 AAU 支持两个载波的话，带宽就达到了惊人的 800MHz！

如果还要像 Sub6G 频段的设备一样支持数字波束赋形的话，对基带处理能力要求太高，并且射频部分功放的数量也要数倍增加，实现成本过高，功耗更是大得吓人。

混合波束赋形

因此，业界将数字波束赋形和模拟波束赋形结合起来，使在模拟端可调幅调相的波束赋形，结合基带的数字波束赋形，称之为混合波束赋形。

混合波束赋形数字和模拟融合了两者的优点：

基带处理的通道数目明显小于模拟天线单元的数量
复杂度大幅下降
成本降低
系统性能接近全数字波束赋形
非常适用于高频系统

混合波束赋形框图" >

混合波束赋形框图

这样一来，毫米波频段的设备基带处理的通道数较少，一般为 4T4R，但天线单元众多，可达 512 个，其容量的主要来源是超大带宽和波束赋形。

在波束赋形和 Massive MIMO 的加成之下，5G 在 Sub6G 频谱下单载波最多可达 7Gbps 的小区峰值速率，在毫米波频谱下单载波也最多达到了约 4.8Gbps 的小区峰值速率。

3GPP Releases

Thu, 03 Sep 2020 15:16:34 +0800

Meanings of 3GPP releases

3GPP Release schedule and summary

3GPP RELEASE	RELEASE DATE	DETAILS
Phase 1	1992	Basic GSM
Phase 2	1995	GSM features including EFR Codec
Release 96	Q1 1997	GSM Updates, 14.4 kbps user data
Release 97	Q1 1998	GSM additional features, GPRS
Release 98	Q1 1999	GSM additional features, GPRS for PCS 1900, AMR, EDGE
Release 99	Q1 2000	3G UMTS incorporating WCDMA radio access
Release 4	Q2 2001	UMTS all-IP Core Network
Release 5	Q1 2002	IMS and HSDPA
Release 6	Q4 2004	HSUPA, MBMS, IMS enhancements, Push to Talk over Cellular, operation with WLAN
Release 7	Q4 2007	Improvements in QoS & latency, VoIP, HSPA+, NFC integration, EDGE Evolution
Release 8	Q4 2008	Introduction of LTE, SAE, OFDMA, MIMO, Dual Cell HSDPA
Release 9	Q4 2009	WiMAX / LTE / UMTS interoperability, Dual Cell HSDPA with MIMO, Dual Cell HSUPA, LTE HeNB
Release 10	Q1 2011	LTE-Advanced, Backwards compatibility with Release 8 (LTE), Multi-Cell HSDPA
Release 11	Q3 2012	Heterogeneous networks (HetNet), Coordinated Multipoint (CoMP), In device Coexistence (IDC), Advanced IP interconnection of Services,
Release 12	March 2015	Enhanced Small Cells operation, Carrier Aggregation (2 uplink carriers, 3 downlink carriers, FDD/TDD carrier
Release 13	Q1 2016	LTE-U / LTE-LAA, LTE-M, Elevation beamforming / Full Dimension MIMO, Indoor positioning, LTE-M Cat 1.4MHz & Cat 200kHz introduced
Release 14	Mid 2017	Elements on road to 5G
Release 15	End 2018	5G Phase 1 specification
Release 16	2020	5G Phase 2 specification
Release 17	~Sept 2021

参考

[1] 3GPP Specification Release Numbers

将静态网站从 GitHub Pages 迁移到 Vercel

Wed, 26 Aug 2020 16:18:53 +0800

本文介绍如何将静态网站从 GitHub Pages 迁移到 Vercel，以获得更快的访问速度和更好的用户体验。

一、迁移背景

1.1 迁移时间

网站于 2020-8-26 完成从 GitHub Pages 到 Vercel 的迁移。

1.2 迁移原因

GitHub Pages 在国内访问速度持续下降
Cloudflare CDN 在国内表现不稳定
需要寻找更适合国内访问的替代方案

二、为什么选择 Vercel

2.1 Vercel 简介

引用

Vercel is a cloud platform for static sites and Serverless Functions that fits perfectly with your workflow. It enables developers to host Jamstack websites and web services that deploy instantly, scale automatically, and requires no supervision, all with no configuration.

2.2 主要优势

全球化部署
- 拥有香港和台湾节点
- 对中国大陆用户访问友好
优质服务
- 自动部署
- 自动扩展
- 零配置部署
- 免费套餐满足小型网站需求

Vercel 平台概览" >

Vercel 平台概览

三、迁移步骤

3.1 项目导入

使用 GitHub 账号登录 Vercel

注意：Vercel 不支持使用 QQ 邮箱作为主邮箱的 GitHub 账号，如有需要请先更改 GitHub 主邮箱。
导入 GitHub 仓库
导入 GitHub 项目" >
导入 GitHub 项目
选择部署目录
选择部署目录" >
选择部署目录

3.2 构建配置

选择构建方式
- 本地构建：选择 Other 并启用 OVERRIDE，无需填写构建命令
- Vercel 构建：选择对应的构建框架（如 Hugo）

构建选项配置" >

构建选项配置

3.3 域名配置

Vercel 设置
- 进入项目设置 > 域名
- 添加自定义域名

Vercel 域名配置" >

Vercel 域名配置

Cloudflare DNS 配置
1. 删除原有 GitHub Pages 的 DNS 记录
2. 添加新的 DNS 记录：
  - 类型：CNAME
  - 名称：www
  - 目标：cname.vercel-dns.com
  - 重要：将 Proxy Status 设置为 DNS only

Cloudflare DNS 配置" >

Cloudflare DNS 配置

根域名配置

如需配置根域名跳转到 www：

添加 A 记录
指向 76.76.21.21
同样设置 Proxy Status 为 DNS only

四、迁移效果

访问速度：显著提升
稳定性：更加可靠
部署体验：自动化程度高

参考资料

常用 DNS 服务器

Fri, 21 Aug 2020 18:44:20 +0800

列举国内外常见的 DNS，方便替换使用

IPv4

国内

知名 DNS 服务

名称	IP 地址（首选）	IP 地址（备选）
114 常规 DNS	114.114.114.114	114.114.115.115
114 拦截钓鱼病毒木马网站	114.114.114.119	114.114.115.119
114 拦截色情网站	114.114.114.110	114.114.115.110
阿里 AliDNS	223.5.5.5	223.6.6.6
百度 BaiduDNS	180.76.76.76
DNSPod DNS+	119.29.29.29	182.254.116.116
CNNIC SDNS	1.2.4.8	210.2.4.8
oneDNS	117.50.11.11	52.80.66.66
DNS 派电信/移动/铁通	101.226.4.6	218.30.118.6
DNS 派联通	123.125.81.6	140.207.198.6

全国各地电信 DNS 服务器 IP 地址

名称	IP 地址（首选）	IP 地址（备选）
安徽电信 DNS	61.132.163.68	202.102.213.68
北京电信 DNS	219.141.136.10	219.141.140.10
重庆电信 DNS	61.128.192.68	61.128.128.68
福建电信 DNS	218.85.152.99	218.85.157.99
甘肃电信 DNS	202.100.64.68	61.178.0.93
广东电信 DNS	202.96.128.86	202.96.128.166
	202.96.134.33	202.96.128.68
广西电信 DNS	202.103.225.68	202.103.224.68
贵州电信 DNS	202.98.192.67	202.98.198.167
河南电信 DNS	222.88.88.88	222.85.85.85
黑龙江电信	219.147.198.230	219.147.198.242
湖北电信 DNS	202.103.24.68	202.103.0.68
湖南电信 DNS	222.246.129.80	59.51.78.211
江苏电信 DNS	218.2.2.2	218.4.4.4
	61.147.37.1	218.2.135.1
江西电信 DNS	202.101.224.69	202.101.226.68
内蒙古电信	219.148.162.31	222.74.39.50
山东电信 DNS	219.146.1.66	219.147.1.66
陕西电信 DNS	218.30.19.40	61.134.1.4
上海电信 DNS	202.96.209.133	116.228.111.118
	202.96.209.5	180.168.255.118
四川电信 DNS	61.139.2.69	218.6.200.139
天津电信 DNS	219.150.32.132	219.146.0.132
云南电信 DNS	222.172.200.68	61.166.150.123
浙江电信 DNS	202.101.172.35	61.153.177.196
	61.153.81.75	60.191.244.5

全国各地联通 DNS 服务器 IP 地址

名称	IP 地址（首选）	IP 地址（备选）
北京联通 DNS	123.123.123.123	123.123.123.124
	202.106.0.20	202.106.195.68
重庆联通 DNS	221.5.203.98	221.7.92.98
广东联通 DNS	210.21.196.6	221.5.88.88
河北联通 DNS	202.99.160.68	202.99.166.4
河南联通 DNS	202.102.224.68	202.102.227.68
黑龙江联通	202.97.224.69	202.97.224.68
吉林联通 DNS	202.98.0.68	202.98.5.68
江苏联通 DNS	221.6.4.66	221.6.4.67
内蒙古联通	202.99.224.68	202.99.224.8
山东联通 DNS	202.102.128.68	202.102.152.3
	202.102.134.68	202.102.154.3
山西联通 DNS	202.99.192.66	202.99.192.68
陕西联通 DNS	221.11.1.67	221.11.1.68
上海联通 DNS	210.22.70.3	210.22.84.3
四川联通 DNS	119.6.6.6	124.161.87.155
天津联通 DNS	202.99.104.68	202.99.96.68
浙江联通 DNS	221.12.1.227	221.12.33.227
辽宁联通 DNS	202.96.69.38	202.96.64.68

全国各地移动 DNS 服务器 IP 地址

名称	IP 地址（首选）	IP 地址（备选）
江苏移动 DNS	221.131.143.69	112.4.0.55
安徽移动 DNS	211.138.180.2	211.138.180.3
山东移动 DNS	218.201.96.130	211.137.191.26

香港地区

名称	IP 地址（首选）	IP 地址（备选）
香港宽频 DNS	203.80.96.10
和记环球电讯 DNS	202.45.84.58	202.45.84.59
Pacific SuperNet DNS	202.14.67.4	202.14.67.14

台湾地区

名称	IP 地址（首选）	IP 地址（备选）
中华电信 DNS	168.95.1.1	168.95.192.1
数位联合电信 DNS	139.175.252.16	139.175.55.244
台湾网路资讯	101.101.101.101	101.102.103.104

韩国

名称	IP 地址（首选）	IP 地址（备选）
KT olleh DNS	168.126.63.1	168.126.63.2
SK Broadband DNS	210.220.163.82	219.250.36.130
LG U+ DNS	164.124.101.2	203.248.252.2
	164.124.107.9	203.248.242.2

美国

名称	IP 地址（首选）	IP 地址（备选）
Cloudflare DNS	1.1.1.1	1.0.0.1
Google DNS	8.8.8.8	8.8.4.4
IBM Quad9	9.9.9.9	149.112.112.112
DNS.SB	185.222.222.222	185.184.222.222
OpenDNS	208.67.222.222	208.67.220.220
V2EX DNS	199.91.73.222	178.79.131.110
HE Public DNS	74.82.42.42	66.220.18.42

其他地区

名称	IP 地址（首选）	IP 地址（备选）
俄罗斯 Yandex Public DNS	77.88.8.8	77.88.8.1
俄罗斯 SafeDNS	195.46.39.39	195.46.39.40
德国 DNS.WATCH Public DNS	84.200.69.80	84.200.70.40
瑞士 xiala.net Public DNS	77.109.148.136	77.109.148.137
丹麦 UncensoredDNS	91.239.100.100	89.233.43.71
荷兰 Freenom World Public DNS	80.80.80.80	80.80.81.81

IPv6

国内

名称	IP 地址（首选）	IP 地址（备选）
百度	2400:da00::6666
阿里	2400:3200::1	2400:3200:baba::1
CNNIC	2001:dc7:1000::1
下一代互联网北京研究中心	240C::6666	240C::6644

高校

名称	IP 地址（首选）	IP 地址（备选）
北京邮电大学	2001:da8:202:10::36	2001:da8:202:10::37
上海交通大学	2001:da8:8000:1:202:120:2:100	2001:da8:8000:1:202:120:2:101
中科院网络信息中心	2001:cc0:2fff:1::6666
北京交通大学	2001:da8:205:2060::188
清华大学	2001:da8:ff:305:20c:29ff:fe1f:a92a
清华大学 TUNA 协会	2001:da8::666
北京科技大学	2001:da8:208:10::6

台湾地区

名称	IP 地址（首选）	IP 地址（备选）
中华电信	2001:b000:168::1	2001:b000:168::2
台湾网路资讯	2001:de4::101	2001:de4::102

美国

名称	IP 地址（首选）	IP 地址（备选）
GOOGLE	2001:4860:4860::8888	2001:4860:4860::8844
CloudFlare DNS	2606:4700:4700::1111	2606:4700:4700::1001
IBM	2620:fe::fe	2620:fe::9
Cisco OpenDNS	2620:0:ccc::2	2620:0:ccd::2
HE Public DNS	2001:470:20::2	2001:470:0:9d::2
Verisign Public DNS	2620:74:1b::1:1	2620:74:1c::2:2
Neustar Recursive DNS	2610:a1:1018::1	2610:a1:1019::1

其他地区

名称	IP 地址（首选）	IP 地址（备选）
俄罗斯 Yandex Public DNS	2a02:6b8::feed:0ff	2a02:6b8:0:1::feed:0ff
德国 DNS.WATCH Public DNS	2001:1608:10:25::1c04:b12f	2001:1608:10:25::9249:d69b
瑞士 xiala.net Public DNS	2001:1620:2078:136::	2001:1620:2078:137::
丹麦 UncensoredDNS	2001:67c:28a4::	2a01:3a0:53:53::

参考

网络分析工具：NetCat

Wed, 19 Aug 2020 23:15:35 +0800

网络瑞士军刀 —— NetCat" >

网络瑞士军刀 —— NetCat

什么是 NetCat

简单来说，NetCat (nc) 是一个命令行工具，能够让你很方便、很灵活地操纵 传输层协议（TCP ＆ UDP）

nc 可以在两台设备上面相互交互，即侦听模式/传输模式

nc 包含以下主要功能：

Telnet 功能
获取 banner 信息
传输文本信息
传输文件 / 目录
加密传输文件，默认不加密
远程控制
加密所有流量
流媒体服务器
远程克隆硬盘

使用 NetCat

一般来说，nc 的命令行包括如下几个部分：

nc 命令选项 主机 端口

命令选项

本文内容基于 OpenBSD 社区的变种（也叫 OpenBSD netcat，部分命令与原版有差异。）

下面列举了一些常用选项，更多选项参见 OpenBSD manual page

选项	   是否有 “选项值”	   说明
-h	   NO	           输出 nc 的帮助
-v	   NO	           在网络通讯时，显示详细的输出信息
-n	   NO	           对命令行中的主机，不进行域名解析，如果主机是 IP 地址，需要用该选项
-p	  YES	           指定端口号
-l	  NO	           开启监听模式，nc 作为服务端，如不加，nc 默认作为客户端
-u	  NO	           使用 UDP 协，如不加该选项，默认是 TCP 协议
-w	  YES	           设置连接的超时间隔（N 秒）
-q	  YES	           让 nc 延时（N 秒）再退出
-z	  NO	           开启 zero-I/O 模式，该选项仅用于端口扫描
-k	  NO	           配合 -l 选项使用，可以重复接受客户端连接
-X	  YES	           指定代理的类型
-x	  YES	           以 IP:port 的格式指定代理
-d    NO               后台模式

主机

这部分可以没有，可以以 IP 地址 形式表示，也可以以 域名 形式表示。

端口

这部分可以没有，可以是单个端口，可以是端口范围。

常用使用场景示例

测试某个远程主机的监听端口是否可达

经常有这种需求，要判断某个主机的监听端口是否能连上。导致监听端口无法连接，通常有两种原因：

监听端口没开启
监听端口虽然开启，但是被防火墙阻拦了

对第 1 个原因，（如果你能在该主机上运行命令）可以直接用 netstat 这个命令查看监听端口是否开启；但对于第 2 个原因，netstat 就用不上了，这时候就可以用 nc 来帮你搞定。

用如下命令可以测试某个 IP 地址上的某个监听端口是否开启:

nc -nv ip port

注：　默认情况下 nc 会等待很久，然后才告诉你连接失败。如果你所处的网络环境稳定且高速（比如：局域网内），那么，你可以追加 -w 选项，设置一个比较小的超时值。在下面的例子中，超时值设为 3 秒。

nc -nv -w 3 ip port

判断防火墙是否允许 or 禁止某个端口

假设你正在配置防火墙规则，禁止 TCP 的 8080 端口对外监听。那么，你如何验证自己的配置生效？

为了叙述方便，设想如下场景：有两台主机 ——主机 C 充当客户端，主机 S 充当服务端。然后要判断主机 S 上的防火墙是否会拦截其它主机对 8080 TCP 端口的连接。

在主机 S 上运行 nc，让它在 8080 端口，命令如下：

nc -lv -p 8080

然后在 “主机 C” 上运行 nc，测试 “主机 S” 上的 8080 端口是否可达

注：　在默认情况下，nc 开启 listen 模式充当服务端，在接受第一次客户端连接之后，就会把监听端口关闭。如果你想要让 nc 始终监听模式，使之能重复接受客户端发起的连接，可以追加 -k 选项。

端口扫描

下面这个命令，用来扫描的端口范围从 1 到 1024

nc -znv ip 1-1024

选项 -z 是指开启 zero-I/O 模式。该模式 nc 只判断某个监听端口是否能连上，连上后不与对端进行数据通讯。

**注：**端口扫描的时候，-v 选项会把成功/失败的结果统统打印出来。通常关注的都是 “扫描成功” 的那些端口。因此，可以用可以配合使用 grep 过滤一下，只打印扫出来的端口

nc -znv ip 1-1024  2>&1 | grep succeeded

此外，由于 -v 选项产生的输出位于 stderr，上述命令中的 2>&1 用来把 stderr 合并到 stdout。

另： nc 默认超时较大，导致扫描速度较慢。建议根据网络情况合理设置超时值，加快扫描速度。

探测服务器类型和软件版本

如果某个服务器运行了 SSH 服务端，那么用如下命令可以看出：该服务器的操作系统类型，以及 SSH server 的版本。

echo "EXIT" | nc -vq 5 -n ip 22
OR
echo "EXIT" | nc -vq 5 domain 22

端口转发

用 nc 进行端口转发，需要运行两个 nc 进程，一个充当服务端，另一个是客户端，然后用管道让把两个进程的标准输入输出``交叉配对。所谓的交叉配对就是——每一个 nc 进程的标准输出都对接到另一个 nc 进程的标准输入。如此一来，就可以完美地建立双向通讯。

步骤 1：创建命名管道

用下面这个简单的命令创建一个 “命名管道”，其名称叫做 nc_pipe

mkfifo nc_pipe

步骤 2：同时启动两个 nc

nc -l -p 1234 < nc_pipe | nc 127.0.0.1 5678 > nc_pipe

运行上述命令之后，就可以把本机的 1235 端口重定向到本机的 5678 端口。

传输文件

为了叙述方便，假设你有两台主机 A 与 B，你要把 A 主机上的文件 file1 传输到 B 主机上，保存为 file2

先在接收端 B 主机运行如下命令
nc -l -p port > file2

然后在发送端 A 主机运行如下命令
nc ip port < file1

两者端口号要相同

远程备份整个磁盘

假设你要把 A 主机 /dev/sda 磁盘的原始数据整个复制到 B 主机的 /dev/sdb 磁盘。

先在接收端（B 主机）运行如下命令
nc -lp port | dd of=/dev/sdb

然后在发送端 A 主机运行如下命令
dd if=/dev/sda | nc ip port

远程控制

将 A 主机的 bash 发给 B 主机

A:
nc -lp port -c bash

B:
nc ip port

流媒体服务

A:
cat test.mp4 | nc -lp port

B:
nc -nv ip port | mplayer -vo x11 -cache 4000

A 让 test.MP4 这个文件成为流的形式发送到 B，B 用 mplayer 播放，接收多少播放多少，指定缓存 4000bytes。

信息收集

收集目标机上的进程信息

nc -l -p port > ps.txt
将远程发送过来的内容保存在本地

Ps aux |nc -nv ip port -q 1
标准输入完成后 delay 一秒钟，会发送到侦听端

参考

HTTPS 工作原理

Sun, 16 Aug 2020 21:52:26 +0800

理解 HTTP 协议，对称和非对称加密，了解 HTTPS 协议的工作原理

注：本文系全文转载，原文信息如下：

作者：猫尾博客

链接：https://cattail.me/tech/2015/11/30/how-https-works.html

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

读完本文，你能明白

什么是 HTTPS，TLS（SSL），TLS 和 HTTPS 是什么关系
什么是证书和数字签名，它们是如何传递信任的
HTTPS 有什么样的功能，它是如何实现这样的功能的

HTTPS 工作原理简介

HTTPS，也称作 HTTP over TLS。TLS 的前身是 SSL，TLS 1.0 通常被标示为 SSL 3.1，TLS 1.1 为 SSL 3.2，TLS 1.2 为 SSL 3.3。本文着重描述 TLS 协议的 1.2 版本。

下图描述了在 TCP/IP 协议栈中 TLS（各子协议）和 HTTP 的关系：

TCP/IP 协议栈中的 TLS 和 HTTP 关系（来源：SSL Handshake and HTTPS Bindings on IIS）" >

TCP/IP 协议栈中的 TLS 和 HTTP 关系（来源：SSL Handshake and HTTPS Bindings on IIS）

其中 Handshake Protocol、Change Ciper Spec Protocol 和 Alert Protocol 组成了 SSL Handshaking Protocols。

HTTPS 和 HTTP 协议相比提供了：

数据完整性：内容传输经过完整性校验
数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
身份认证：第三方无法伪造服务端（客户端）身份

其中，数据完整性和隐私性由 TLS Record Protocol 保证，身份认证由 TLS Handshaking Protocols 实现。

总览

使用 RSA 算法的 SSL 握手过程是这样的：

Source: Keyless SSL: The Nitty Gritty Technical Details" >

Source: Keyless SSL: The Nitty Gritty Technical Details

[明文]客户端发送随机数 client_random 和支持的加密方式列表
[明文]服务器返回随机数 server_random，选择的加密方式和服务器证书链
[RSA]客户端验证服务器证书，使用证书中的公钥加密 premastersecret 发送给服务端
服务端使用私钥解密 premastersecret
两端分别通过 client_random，server_random 和 premastersecret 生成 mastersecret，用于对称加密后续通信内容

证书（Digital Certificate）

那么什么是证书呢？

证书信息" >

证书信息

证书中包含了以下信息

证书信息：过期时间和序列号
所有者信息：姓名等
所有者公钥

为什么服务端要发送证书给客户端?

互联网有太多的服务需要使用证书来验证身份，以至于客户端（操作系统或浏览器等）无法内置所有证书，需要通过服务端将证书发送给客户端。

客户端为什么要验证接收到的证书

中间人攻击

客户端 <------------ 攻击者 <------------ 服务端
        伪造证书            拦截请求

客户端如何验证接收到的证书

为了回答这个问题，需要引入数字签名 (Digital Signature)。

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |              +---------+                +--------+
| is a mathematical   |---- 哈希 --->| 消息摘要  |--- 私钥加密 --->| 数字签名 |
|technique used       |              +---------+                +--------+
|to validate the      |
|authenticity and     |
|integrity of a       |
|message, software    |
|or digital document. |
+---------------------+

将一段文本通过哈希（hash）和私钥加密处理后生成数字签名。

假设消息传递在 Bob，Susan 和 Pat 三人之间发生。Susan 将消息连同数字签名一起发送给 Bob，Bob 接收到消息后，可以这样验证接收到的消息就是 Susan 发送的

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |              +---------+
| is a mathematical   |---- 哈希 --->|  消息摘要 |
|technique used       |              +---------+
|to validate the      |                 |
|authenticity and     |                 |
|integrity of a       |                 |
|message, software    |                 对
|or digital document. |                 比
+---------------------+                 |
                                        |
                                        |
        +---------+               +----------+
        | 数字签名 |--- 公钥解密 --->|  消息摘要 |
        +---------+               +----------+

当然，这个前提是 Bob 知道 Susan 的公钥。更重要的是，和消息本身一样，公钥不能在不安全的网络中直接发送给 Bob。

此时就引入了证书颁发机构（Certificate Authority，简称 CA），CA 数量并不多，Bob 客户端内置了所有受信任 CA 的证书。CA 对 Susan 的公钥（和其他信息）数字签名后生成证书。

Susan 将证书发送给 Bob 后，Bob 通过 CA 证书的公钥验证证书签名。

Bob 信任 CA，CA 信任 Susan 使得 Bob 信任 Susan，信任链（Chain Of Trust）就是这样形成的。

事实上，Bob 客户端内置的是 CA 的根证书 (Root Certificate)，HTTPS 协议中服务器会发送证书链（Certificate Chain）给客户端。

TLS 协议

TLS协议包括TLS Record Protocol和TLS Handshake Protocol。总览中的流程图仅涉及到TLS Handshake Protocol。

TLS Record Protocol

在TLS协议中，有四种子协议运行于Record Protocol之上

Handshake protocol
Alert protocol
Change cipher spec protocol
Application data protocol

Record protocol 起到了这样的作用

在发送端：将数据（Record）分段，压缩，增加 MAC（Message Authentication Code）和加密
在接收端：将数据（Record）解密，验证 MAC，解压并重组

值得一提的是，Record protocol 提供了数据完整性和隐私性保证，但 Record 类型（type）和长度（length）是公开传输的

Record Protocol 有三个连接状态（Connection State），连接状态定义了压缩，加密和 MAC 算法。所有的 Record 都是被当前状态（Current State）确定的算法处理的。

TLS Handshake Protocol和Change Cipher Spec Protocol会导致Record Protocol状态切换。

empty state -------------------> pending state ------------------> current state
             Handshake Protocol                Change Cipher Spec

初始当前状态（Current State）没有指定加密，压缩和 MAC 算法，因而在完成 TLS Handshaking Protocols 一系列动作之前，客户端和服务端的数据都是明文传输的；当 TLS 完成握手过程后，客户端和服务端确定了加密，压缩和 MAC 算法及其参数，数据（Record）会通过指定算法处理。

其中，Record 首先被加密，然后添加 MAC（message authentication code）以保证数据完整性。

TLS Handshake Protocol

Handshakeing protocols 包括 Alert Protocol，Change Cipher Spec Protocol 和 Handshake protocol。本文不会详细介绍 Alert Protocol 和 Change Cipher Spec Protocol。

使用RSA算法的握手过程是这样的（已在总览中提到）

Source: Keyless SSL: The Nitty Gritty Technical Details" >

Source: Keyless SSL: The Nitty Gritty Technical Details

客户端和服务端在握手 hello 消息中明文交换了client_random和server_random，使用RSA公钥加密传输premastersecret，最后通过算法，客户端和服务端分别计算mastersecret。其中，不直接使用premastersecret的原因是：保证secret的随机性不受任意一方的影响。

除了使用RSA算法在公共信道交换密钥，还可以通过Diffie–Hellman算法。Diffie–Hellman算法的原理是这样的

By Original schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons" >

By Original schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons

使用Diffie–Hellman算法交换premastersecret的流程

Source: Keyless SSL: The Nitty Gritty Technical Details" >

Source: Keyless SSL: The Nitty Gritty Technical Details

小结

TLS Handshake Protocol协商了TLS Record Protocol使用的算法和所需参数，并验证了服务端身份；

TLS Record Protocol在协商后保证应用层数据的完整性和隐私性。

TLS Handshake Protocol的核心是在公开信道上传递premastersecret。

Q&A

为什么传输内容不直接使用非对称加密？

因为性能限制。

HTTPS 能保证正常连接？

不能。

引用

There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.

攻击者甚至可以直接丢弃双方的数据包

服务端如何验证客户端身份？

通过Client Certificate

引用

This message conveys the client’s certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating the premaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.

Alert protocol 有什么作用？

Closure Alerts：防止Truncation Attack

引用

In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.

Error Alerts：错误处理

master secret 是如何计算的

  master_secret = PRF (pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

加密，压缩和 MAC 算法参数是如何计算的

Handshaking Protocols使得客户端和服务端交换了三个参数：client_random，server_random和master_secret，通过以下算法生成算法所需要的参数

To generate the key material, compute

  key_block = PRF (SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.`server_random` +
                  SecurityParameters.`client_random`);

until enough output has been generated.  Then, the key_block is
partitioned as follows:

  client_write_MAC_key [SecurityParameters.mac_key_length]
  server_write_MAC_key [SecurityParameters.mac_key_length]
  client_write_key [SecurityParameters.enc_key_length]
  server_write_key [SecurityParameters.enc_key_length]
  client_write_IV [SecurityParameters.fixed_iv_length]
  server_write_IV [SecurityParameters.fixed_iv_length]

引用

The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key

使用Diffie-Hellman算法的TLS握手细节

Source: https://cipherstuff.wordpress.com/" >

Source: https://cipherstuff.wordpress.com/

拓展阅读

Keyless
Let’s Encrypt
Session resume
证书 Revoke

参考

互联网高效搜索技巧指南

Fri, 14 Aug 2020 12:50:34 +0800

本文介绍如何在互联网上高效地检索信息，包括搜索语法、实用技巧和具体应用场景。

一、搜索引擎的困境

尽管搜索引擎极大地方便了信息检索，但在实际使用中我们常常会遇到以下问题：

搜索结果中包含大量垃圾内容
优质内容被SEO优化的内容淹没
中文搜索结果质量普遍较低

为了提高搜索效率，掌握一些专业的搜索技巧是非常必要的。

二、高级搜索语法

2.1 基础运算符

运算符	说明	示例
“短语”	精确匹配引号中的内容	“machine learning”
-关键词	排除包含特定关键词的结果	python -蟒蛇
A AND B	同时包含A和B	python AND javascript
A OR B	包含A或B（或两者）	pdf OR word
site:域名	限定在特定网站内搜索	site:github.com python
filetype:类型	限定特定文件类型	filetype:pdf python

2.2 高级运算符

运算符	说明	示例
inurl:	网址中包含特定关键词	inurl:blog tech
intitle:	标题中包含特定关键词	intitle:教程
allintitle:	标题中包含所有关键词	allintitle:Python 入门
related:	查找相似网站（仅限Google）	related:github.com

三、实用搜索技巧

3.1 网页内容搜索

特定网站内搜索

site:techkoala.top Python

在指定网站中搜索Python相关内容

标题搜索

allintitle:"Git教程" site:github.com

在GitHub上搜索标题中包含"Git教程"的页面

相似网站查找

related:stackoverflow.com

查找类似Stack Overflow的技术问答网站

3.2 邮箱地址搜索

特定域名邮箱

"@company.com" filetype:pdf

查找特定公司的邮箱地址

网站邮箱提取

// 在浏览器控制台运行以下代码提取页面中的邮箱地址
var elems = document.body.getElementsByTagName("*");
var emailPattern = new RegExp("(^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$)");
for (var i = 0; i < elems.length; i++) {
    if (emailPattern.test(elems[i].innerHTML)) {
        console.log(elems[i].innerHTML);
    }
}

3.3 文件搜索

文档文件

filetype:pdf OR filetype:doc OR filetype:docx "机器学习"

搜索机器学习相关的PDF或Word文档

数据文件

filetype:csv OR filetype:xlsx "数据分析"

搜索数据分析相关的表格文件

Google文档

site:docs.google.com "开发教程"

在Google文档中搜索开发教程

3.4 SEO相关搜索

锚文本搜索

inanchor:"web development"

查找锚文本中包含"web development"的链接

反向链接搜索

intext:github.com/tensorflow

查找引用特定资源的网页

通配符搜索

* 编程语言 2023

使用通配符查找2023年流行的编程语言

四、搜索技巧最佳实践

组合使用运算符
- 合理组合多个运算符可以获得更精确的结果
- 例如：site:github.com "machine learning" filetype:pdf -tutorial
选择合适的关键词
- 使用专业术语而非口语化表达
- 优先使用英文关键词搜索技术内容
利用时间筛选
- 对于技术内容，建议限定近期结果
- 使用搜索引擎的时间筛选功能
善用垂直搜索
- 代码搜索优先使用GitHub
- 学术内容使用Google Scholar
- 技术问答使用Stack Overflow

参考资料

使用 Netlify 部署在线版 Koodo Reader

Wed, 12 Aug 2020 11:22:58 +0800

本文介绍如何使用 Netlify 部署一个在线版的 EPUB 电子书阅读器 - Koodo Reader

Netlify 简介

Netlify 是一个现代化的网站托管和自动化平台：

引用

Netlify is a unified platform that automates your code to create high-performant, easily maintainable sites and web apps.

它提供：

静态网站托管服务
持续集成/持续部署（CI/CD）功能
自动从 GitHub、GitLab 等代码仓库构建网站
比 GitHub Pages 更丰富的功能特性

Koodo Reader 介绍

Koodo Reader 是一个跨平台的电子书阅读器，基于 React 和 Electron 开发，支持 EPUB 格式。

Koodo Reader 界面预览" >

Koodo Reader 界面预览

主要特性

📝 强大的笔记和翻译功能，助力高效学习
🚩 支持书架分类管理
🌎 全平台支持：Windows、MacOS 和网页版
🖥 支持云同步：可绑定 OneDrive、Google Drive、Dropbox 等网盘
💻 支持数据导入导出，确保数据安全

更多详情请访问 Koodo Reader 官网。

部署步骤

1. 注册 Netlify

访问 Netlify 官网，可以选择：

使用 GitHub 账号直接登录（推荐）
使用其他第三方账号
使用邮箱注册

Netlify 注册界面" >

Netlify 注册界面

2. 创建新站点

登录后点击右上角的 New Site from Git
创建新站点" >
创建新站点
选择 GitHub 并授权
选择 GitHub 部署" >
选择 GitHub 部署
选择代码仓库
- 需要先 Fork Koodo Reader 的仓库
- 在列表中选择已 Fork 的仓库
  选择代码仓库" >
  选择代码仓库

3. 配置构建选项

设置以下参数：

Build command: yarn build
Publish directory: build/
其他选项保持默认

构建配置" >

构建配置

4. 等待部署完成

Netlify 会自动开始构建和部署过程。

部署进行中" >

部署进行中

5. 自定义域名（可选）

Netlify 默认提供二级域名
如需使用自定义域名：
- 在 Netlify 设置中添加域名
- 在 DNS 提供商处添加 CNAME 记录，指向 Netlify 分配的域名

域名设置" >

域名设置

部署完成后，可以访问在线版 Koodo Reader 体验。

维护说明

项目更新：直接在 GitHub 仓库提交更改
自动部署：Netlify 会自动检测代码更新并重新部署
无需手动干预：整个过程完全自动化

参考资料

网络测试工具：iPerf

Fri, 07 Aug 2020 17:45:55 +0800

TCP、UDP 和 SCTP 的终极速度测试工具

什么是 iPerf

iPerf 是一个用于测量网络最大带宽的小工具。iPerf 可以测试最大 TCP 和 UDP 带宽性能，具有多种参数和 UDP 特性，可以根据需要调整，可以报告带宽、延迟抖动和数据包丢失。对于每个测试，它都会报告带宽，丢包和其他参数。

现在的版本也称 iPerf3，这是对 NLANR/DAST 开发的原始版本的重新设计。

注意：iPerf3 与此前版本的 iPerf 不兼容。

安装 iPerf

iPerf3 官方仅支持 CentOS Linux，FreeBSD 和 macOS，但实际上，官网提供了主流系统的预编译文件。（包括 Windows、Android、iOS、Ubuntu、Arch Linux 等）

类 UNIX 系统直接使用包管理进行安装即可，例如：

$ sudo apt install iperf3

使用 iPerf

首先，介绍服务端和客户端共有的参数：

-p, --port n      服务器用于侦听和客户端连接的服务器端口，两者应该相同，默认值为 5201
--cport n         指定客户端端口
-f, --format      用于指定单位显示格式，支持 'k' = Kbits/sec 'K' = KBytes/sec 'm' = Mbits/sec 'M' = MBytes/sec，默认为自适应格式
-i, --interval n  设置测试信息报告之间的间隔时间（以秒为单位）。如果为零，则不打印任何定期报告。默认值为零。
-F, --file name   客户端：从文件读取并写入网络，而不是使用随机数据；服务器端：从网络读取并写入文件，而不是丢弃数据。
-A, --affinity    如果可以，设置 CPU 关联（仅限 Linux 和 FreeBSD）。
-B, --bind host   绑定到主机。对于客户端，这将设置出站接口。对于服务器，这将设置传入接口。这只适用于具有多个网络接口的多宿主主机。
-V, --verbose     提供更详细的输出
-J, --json        以 JSON 格式输出
--logfile file    输出到日志文件
--d, --debug      发出调试输出
-v, --version     输出版本信息
-h, --help        输出帮助信息

服务端特有参数：

-s, --server      在服务器模式下运行 iPerf（一次只允许一个 iPerf 连接）
-D, --daemon      将服务器作为守护进程在后台运行
-I, --pidfilefile 使用进程ID编写文件，这在作为守护进程运行时非常有用

客户端特有参数:

-c, --client host	    在客户端模式下运行 iPerf
--sctp	                使用 SCTP 而不是 TCP
-u, --udp	            使用 UDP 而不是 TCP
-b, --bandwidth      	将目标带宽设置为 nbits/sec（对于 UDP 默认为 1 Mbit/sec，对于 TCP 为无限制）。如果有多个流（-P 标志），则带宽限制将分别应用于每个流。您还可以在带宽说明符中添加一个 “/” 和一个数字。这称为 “突发模式”。 它会发送给定数量的数据包而不会暂停，即使该数据包暂时超过了指定的带宽限制
-t, --time  	        传输的时间（以秒为单位）。iPerf 通常通过在 t 时间内重复发送 len 长度的字节数组来工作。默认值为 10 秒
-n, --num 	            要传输的缓冲区数量。通常，iPerf 只会发送 10 秒。-n 选项覆盖此设置，并发送 len 长度字节数组 n 次，无论需要多长时间
-k, --blockcount    	要传输的块（数据包）数
-l, --length     	    读取或写入的缓冲区的长度，iPerf 通过多次写入 len 个字节的数组来工作。TCP 的默认值为 128 KB，UDP 的默认值为 8 KB。
-P, --parallel  	    与服务器同时建立的连接数，默认值为 1
-R, --reverse	        以反向模式运行（服务器发送，客户端接收）
-w, --window    	    将套接字缓冲区大小设置为指定值。对于 TCP，这将设置 TCP 窗口大小（这将发送到服务器并在该侧使用）
-M, --set-mss  	        尝试设置 TCP 最大段大小（MSS）。MSS 通常是 MTU-TCP/IP 标头的 40 个字节。对于以太网，MSS 为 1460 字节（1500 字节 MTU）
-N, --no-delay	        设置 “TCP no delay” 选项，禁用 Nagle 的算法。通常，仅对交互式应用程序（如 telnet）禁用此功能
-4, --version4	        仅使用 IPv4.
-6, --version4	        仅使用 IPv6.
-S, --tos               传出数据包的服务类型。(许多路由器会忽略TOS字段。）可以使用十六进制值（0x）作为前缀，使用八进制数（0）作为前缀，或者使用十进制来指定值。 例如，'0x10'十六进制='020'八进制='16'十进制。RFC 1349中指定的TOS编号为：
                        IPTOS_LOWDELAY     minimize delay        0x10
                        IPTOS_THROUGHPUT   maximize throughput   0x08
                        IPTOS_RELIABILITY  maximize reliability  0x04
                        IPTOS_LOWCOST      minimize cost         0x02
-L, --flowlabel  	    设置 IPv6 流标签（当前仅在 Linux 上受支持）
-Z, --zerocopy	        使用 “零拷贝” 方法发送数据，如 sendfile（2），而不是通常的 write（2）。这样可以占用更少的 CPU
-O, --omit  	        省略测试的前 n 秒，以跳过 TCP TCP 慢启动周期
-T, --title             为每个输出行添加此字符串前缀
-C, --linux-congestion  设置拥塞控制算法 (仅适用于 iPerf 3.1 的 Linux 和 FreeBSD)。

注意

从客户端专有选项可以看出，iPerf 默认测试的是从客户端发送到服务端，相对于客户端来说，测试就是上行链路的带宽，对于一般参考意义更大的下行链路需要加上 -R 选项。

常用启用参数：

服务端
$ iperf3 -s -p 12345 -i 1

客户端
$ iperf3 -c 192.168.1.43 -p 12345 -i 1 -t 20 -w 100k

iPerf 使用实例" >

iPerf 使用实例

参考

[1] iPerf user docs
[2] iPerf Github

文件传输系列：SFTP

Thu, 06 Aug 2020 14:07:53 +0800

SCP 的继承者

什么是 SFTP

首先需要明确的是，SFTP（SSH File Transfer Protocol）不是运行在 SSH 上的 FTP，而是由 IETF（Internet Engineering Task Force）工作组设计的新协议，将其作为 SSH 2.0 版的扩展，提供安全的文件传输功能。因此，没有单独的 SFTP 端口，而是使用普通的 SSH 端口。协议本身不提供身份验证和安全性，而是期望底层协议提供。

与仅允许文件传输的 SCP 协议相比，SFTP 协议允许对远程文件进行一系列操作，这使其更像远程文件系统协议。SFTP 客户端还支持包括恢复中断的传输，目录列表和远程文件删除等功能。此外，上传的文件可以与它们的基本属性相关联，例如时间戳。相比普通 FTP 协议，这是一项优势。

尽管 SFTP 最常在 Unix 平台上实现，但 SFTP 在主流平台都可用。

引用

有关 SFTP 详细草案参见 draft-ietf-secsh-filexfer-02

使用 SFTP

sftp 选项 参数

选项

-B：指定传输文件时缓冲区的大小；
-l：使用 ssh 协议版本 1；
-b：指定批处理文件；
-C：使用压缩；
-o：指定 ssh 选项；
-F：指定 ssh 配置文件；
-R：指定一次可以容忍多少请求数；
-v：升高日志等级。

参数

目标主机：指定 SFTP 服务器 IP 地址或者主机名。

参考

[1] SSH File Transfer Protocol
[2] SFTP Command

文件传输系列：rsync

Wed, 05 Aug 2020 20:58:00 +0800

SCP 的另一个绝佳替选

什么是 rsync

rsync (remote synchronize) 是一款实现远程同步功能的软件，它在同步文件的同时，可以保持原来文件的权限、时间、软硬链接等附加信息。

rsync 是类 Unix 系统下的数据镜像备份工具。它能同步更新两处计算机的文件与目录，并适当利用差分编码以减少数据传输量。 rsync 中的一项同类软件不常见的重要特性是每个目标的镜像只需发送一次。rsync 可以拷贝／显示目录内容，以及拷贝文件，并可选压缩以及递归拷贝。

rsync 默认监听 TCP 端口 873，以原生 rsync 传输协议或者透过远程 shell 如 RSH 或者 SSH 提供文件。SSH 模式下，rsync 客户端运行程序必须同时在本地和远程机器上安装。

rsync 算法

信息

此部分内容转载 RSYNC 的核心算法

rsync 的算法如下：（假设源文件名为 fileSrc，目的文件叫 fileDst）

分块 Checksum 算法

首先，我们会把 fileDst 的文件平均切分成若干个小块，比如每块 512 个字节，然后对每块计算两个 checksum，一个叫 rolling checksum，是弱 checksum，32 位的 checksum，其使用的是 Mark Adler 发明的 adler-32 算法，另一个是强 checksum，128 位的，以前用 md4，现在用 md5。为什么要这样？因为若干年前的硬件上跑 md4 的算法太慢了，所以，需要一个快算法来鉴别文件块的不同，但是弱的 adler-32 算法碰撞概率太高了，所以我们还要引入强的 checksum 算法以保证两文件块是相同的。也就是说，弱的 checksum 是用来区别不同，而强的是用来确认相同。

传输算法

同步目标端会把 fileDst 的一个 checksum 列表传给同步源，这个列表里包括了三个东西，rolling checksum (32bits)，md5 checksume (128bits)，文件块编号。同步源机器拿到了这个列表后，会对 fileSrc 做同样的 checksum，然后和 fileDst 的 checksum 做对比，这样就知道哪些文件块改变了。

但是

如果我 fileSrc 这边在文件中间加了一个字符，这样后面的文件块都会位移一个字符，这样就完全和 fileDst 这边的不一样了，但理论上来说，我应该只需要传一个字符就好了。这个怎么解决？如果这个 checksum 列表特别长，而两边相同的文件块可能并不是一样的顺序，那就需要查找，线性的查找起来应该特别慢吧。这个怎么解决？

Checksum 查找算法

同步源端拿到 fileDst 的 checksum 数组后，会把这个数据存到一个 hash table 中，用 rolling checksum 做 hash，以便获得 O(1) 时间复杂度的查找性能。这个 hash table 是 16 bits 的，所以，hash table 的尺寸是 2 的 16 次方，对 rolling checksum 的 hash 会被散列到 0 到 $ 2^{16} – 1 $ 中的某个整数值。

比对算法

取 fileSrc 的第一个文件块（我们假设的是 512 个长度），也就是从 fileSrc 的第 1 个字节到第 512 个字节，取出来后做 rolling checksum 计算。计算好的值到 hash 表中查询。
如果查到了，说明发现在 fileDst 中有潜在相同的文件块，于是就再比较 · 的 checksum，因为 rolling checksume 太弱了，可能发生碰撞。于是还要算 md5 的 128 bits 的 checksum，这样一来，我们就有 $2^{-(32+128)} = 2^{-160} $ 的概率发生碰撞，这小到可以忽略。如果 rolling checksum 和 md5 checksum 都相同，那就可以说明在 fileDst 中有相同的块，记下这一块在 fileDst 下的文件编号。
如果 fileSrc 的 rolling checksum 没有在 hash table 中找到，那就不用算 md5 checksum 了。表示这一块中有不同的信息。总之，只要 rolling checksum 或 md5 checksum 其中有一个在 fileDst 的 checksum hash 表中找不到匹配项，那么就会触发算法对 fileSrc 的 rolling 动作。于是，算法会住后 step 1 个字节，取 fileSrc 中字节 2-513 的文件块要做 checksum，然后继续第一步 – 这就是为什么叫 rolling checksum 。
这样，我们就可以找出 fileSrc 相邻两次匹配中的那些文本字符，这些就是我们要往同步目标端传的文件内容了。

Rolling Checksum 算法

rolling checksum 算法也叫 Rabin-Karp 算法，由 Richard M. Karp 和 Michael O. Rabin 在 1987 年发表，它用来解决多模式串匹配问题。其最大的精髓是，当往后面 step 1 个字符的时候，不用全部重新计算所有的 checksum，也就是说，从 [0, 512] rolling 到 [1, 513] 时，不需要重新计算从 1 到 513 的 checksum，而是重用 [0，512] 的 checksum 直接算出来。

其公式可以表示为：

hash ( t[0, m-1] ) = t[0] * b^(m-1) + t[1] * b^[m-2] ..... t[m-1] * b^0

其中的 b 是一个常数基数，在 Rabin-Karp 算法中，一般取值为 256。

于是，在计算 hash ( t[1, m] ) 时，只需要下面这样就可以了：

hash( t[1, m] ) = hash ( t[0, m-1] ) - t[0] * b^(m-1)  + t[m] * b ^0

rsync 算法示意" >

rsync 算法示意

最终，得到的数据组可以想象为 BT 协议下载 torrent ：一些文件块已下载（匹配上），其他的文件块还未下载（未匹配上）。然后，同步端将这些未匹配上的文件打上标号发送，目的端根据标号重组文件就完成了同步。

使用 rsync

rsync [OPTION]... SRC DEST
rsync [OPTION]... SRC [USER@] host:DEST
rsync [OPTION]... [USER@] HOST:SRC DEST
rsync [OPTION]... [USER@] HOST::SRC DEST
rsync [OPTION]... SRC [USER@] HOST::DEST
rsync [OPTION]... rsync://[USER@] HOST [:PORT]/SRC [DEST]

对应于以上六种命令格式，rsync 有六种不同的工作模式：

拷贝本地文件。当 SRC 和 DES 路径信息都不包含有单个冒号 “:” 分隔符时就启动这种工作模式。如：rsync -a /data/backup
使用一个远程 shell 程序 (如 rsh、ssh) 来实现将本地机器的内容拷贝到远程机器。当 DST 路径地址包含单个冒号 “:” 分隔符时启动该模式。如：rsync -avz *.c foo:src
使用一个远程 shell 程序 (如 rsh、ssh) 来实现将远程机器的内容拷贝到本地机器。当 SRC 地址路径包含单个冒号 “:” 分隔符时启动该模式。如：rsync -avz foo:src/bar/data
从远程 rsync 服务器中拷贝文件到本地机。当 SRC 路径信息包含 “::” 分隔符时启动该模式。如：rsync -av root@192.168.78.192::www /databack
从本地机器拷贝文件到远程 rsync 服务器中。当 DST 路径信息包含 “::” 分隔符时启动该模式。如：rsync -av /databack root@192.168.78.192::www
列出远程主机的文件列表。这类似于 rsync 传输，不过只要在命令中省略掉本地机信息即可。如：rsync -v rsync://192.168.78.192/www

可用选项如下：

-v, --verbose 详细模式输出。
-q, --quiet 精简输出模式。
-C, --cvs-exclude 使用和 CVS 一样的方法自动忽略文件，用来排除那些不希望传输的文件。
-c, --checksum 打开校验开关，强制对文件传输进行校验。
-a, --archive 归档模式，表示以递归方式传输文件，并保持所有文件属性，等于 - rlptgoD。
-r, --recursive 对子目录以递归模式处理。
-R, --relative 使用相对路径信息。
-b, --backup 创建备份，也就是对于目的已经存在有同样的文件名时，将老的文件重新命名为～filename。可以使用 --suffix 选项来指定不同的备份文件前缀。
-u, --update 仅仅进行更新，也就是跳过所有已经存在于 DST，并且文件时间晚于要备份的文件，不覆盖更新的文件。
-l, --links 保留软链结。
-L, --copy-links 想对待常规文件一样处理软链结。
-H, --hard-links 保留硬链结。
-I, --ignore-times 不跳过那些有同样的时间和长度的文件。
-p, --perms 保持文件权限。
-o, --owner 保持文件属主信息。
-g, --group 保持文件属组信息。
-D, --devices 保持设备文件信息。
-t, --times 保持文件时间信息。
-S, --sparse 对稀疏文件进行特殊处理以节省 DST 的空间。
-T --temp-dir=DIR 在 DIR 中创建临时文件。
-n, --dry-run 现实哪些文件将被传输。
-w, --whole-file 拷贝文件，不进行增量检测。
-x, --one-file-system 不要跨越文件系统边界。
-B, --block-size=SIZE 检验算法使用的块尺寸，默认是 700 字节。
-e, --rsh=command 指定使用 rsh、ssh 方式进行数据同步。
-P 等同于 --partial。
-z, --compress 对备份的文件在传输时进行压缩处理。
-h, --help 显示帮助信息。
--backup-dir 将备份文件 (如～filename) 存放在在目录下。
-suffix=SUFFIX 定义备份文件前缀。
--copy-unsafe-links 仅仅拷贝指向 SRC 路径目录树以外的链结。
--safe-links 忽略指向 SRC 路径目录树以外的链结。
--rsync-path=PATH 指定远程服务器上的 rsync 命令所在路径信息。
--existing 仅仅更新那些已经存在于 DST 的文件，而不备份那些新创建的文件。
--delete 删除那些 DST 中 SRC 没有的文件。
--delete-excluded 同样删除接收端那些被该选项指定排除的文件。
--delete-after 传输结束以后再删除。
--ignore-errors 及时出现 IO 错误也进行删除。
--max-delete=NUM 最多删除 NUM 个文件。
--partial 保留那些因故没有完全传输的文件，以是加快随后的再次传输。
--force 强制删除目录，即使不为空。
--numeric-ids 不将数字的用户和组 id 匹配为用户名和组名。
--timeout=time ip 超时时间，单位为秒。
--size-only 当决定是否要备份文件时，仅仅察看文件大小而不考虑文件时间。
--modify-window=NUM 决定文件是否时间相同时使用的时间戳窗口，默认为 0。
--compare-dest=DIR 同样比较 DIR 中的文件来决定是否需要备份。
--progress 显示备份过程。
--exclude=PATTERN 指定排除不需要传输的文件模式。
--include=PATTERN 指定不排除而需要传输的文件模式。
--exclude-from=FILE 排除 FILE 中指定模式的文件。
--include-from=FILE 不排除 FILE 指定模式匹配的文件。
--version 打印版本信息。
--address 绑定到特定的地址。
--config=FILE 指定其他的配置文件，不使用默认的 rsyncd.conf 文件。
--port=PORT 指定其他的 rsync 服务端口。
--blocking-io 对远程 shell 使用阻塞 IO。
-stats 给出某些文件的传输状态。
--progress 在传输时现实传输过程。
--log-format=formAT 指定日志文件格式。
--password-file=FILE 从 FILE 中得到密码。
--bwlimit=KBPS 限制 I/O 带宽，KBytes per second。

参考

Git Log 使用技巧

Sat, 01 Aug 2020 22:30:52 +0800

最常用的 Git Log 技巧的总结

概览提交历史

$ git log —oneline

该命令帮助您以更清晰的方式查看提交。每个提交仅显示为一行，并且只有最少量的信息，比如提交哈希、提交消息。

显示详细更改信息

$ git log -p

此命令会显示更新的详细更改信息，方便查阅。

根据时间筛选

$ git log --after="2020-15-05"

$ git log --after="2020-15-05" --before="2020-25-05"

$ git log --after="yesterday" // 显示昨天的提交

$ git log --after="today" // 显示今天的提交

$ git log --before="10 day ago" // 显示最近十天的提交

$ git log --after="1 week ago" // 显示上周以来的提交

$ git log --after="2 month ago" // 显示近两个月的提交

上述命令将按给定的时间段过滤出提交。例如，--after 将仅筛选给定时间段之后的提交，而 --before 将仅筛选给定时间段之前的提交。

根据作者筛选

$ git log --author="techkoala"

该命令会显示由 techkoala 提交的更改。当然，可以结合上面介绍的命令，进行更加精确的筛选，例如：

$ git log --after="1 week ago" --author="techkoala" -p

根据 log 信息筛选

$ git log --grep="ISSUE-43560"

需要注意的是，上述筛选字段区分大小写，如果需要不区分，请加上 -i 选项。

此外，还支持正则表达式：

$ git log -i --grep="issue-43560\|issue-89786"

根据文件筛选

$ git log Git_Log.md

该命令显示针对特定文件的的提交历史。

当然，可以传入多个文件：

$ git log Git_Log.md Github_Issue.md

同样的，结合别的命令可以做出更精确的筛选，例如：

$ git log -i --grep="fix " Git_Log.md Github_Issue.md

根据文件内容筛选

$ git log -S"function login()"

上述命令帮你在源代码中搜索已添加到提交历史记录中的特定字符串。同样的，加上 -i 可以不区分大小写。

仅显示合并提交

$ git log --merges

该命令显示当前分支上合并的提交。

显示不同分支间的区别

$ git log master..develop

该命令将显示所有来自 develop 但不在 master 分支的提交。

自定义 log 信息格式

$ git log --pretty=format:"%Cred%an - %ar%n %Cblue %h -%Cgreen %s %n"

Git 提供了用于自定义日志消息格式的选项，你可以查看自定义漂亮选项（custom pretty options ）以获得更多选项。

参考

[1] Ten Useful Git Log Tricks
[2] Git 基础 - 查看提交历史

逐步详解 SHA-2 算法（以 SHA-256 为例）

Tue, 28 Jul 2020 16:19:03 +0800

最常见的 SHA-2 算法是如何实现的？本文逐步为你讲解。

SHA-2 (Secure Hash Algorithm 2)，是最流行的哈希算法之一，包括了：SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。这些变体除了生成摘要的长度、循环运行的次数等一些细微差异之外，基本结构是一致的。

SHA-2 以安全和速度著称，在未生成密钥的情况下（例如挖掘比特币），像 SHA-2 这样的快速哈希算法通常占据上风。

哈希函数（Hash Function）

如果，你还不清楚哈希是什么，可以参见我的另外一篇文章

简单来说，哈希函数的拥有如下三个重要特性：

哈希函数对数据进行确定性加扰。
无论输入是什么，哈希函数的输出始终具有相同的长度（大小）。
无法从加扰数据中检索原始数据（单向函数）。

SHA-2 vs SHA-256

有人可能会困惑：欸？我平时看到的都是 SHA-128、SHA-256 等等，这个 SHA-2 又是什么？

SHA-2 是一种算法，一种关于如何哈希数据的广义思想。SHA-256 设置了定义 SHA-2 算法行为的附加常量。其中一个常量是输出大小，“256” 和 “512” 是指它们各自的输出摘要大小（以位为单位）。

逐步详解 SHA-256

接下来举例说明 SHA-256 如何工作:

第一步：消息预处理

将 hello world 转换为二进制

01101000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100
尾部追加单独的 1

01101000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100 1
填充 0 直到数据为 512 的整数倍，再减去 64 位（在本例中剩下 448 位）：

01101000 01100101 01101100 01101100 01101111 00100000 01110111 01101111

01110010 01101100 01100100 10000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
在末尾附加新的 64 位，这 64 位是一个大端整数，用于表示原始二进制输入的长度。在本文的例子中，是 88，或者二进制，1011000。

01101000 01100101 01101100 01101100 01101111 00100000 01110111 01101111

01110010 01101100 01100100 10000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 01011000

现在，得到了初始的输入值（通过对消息进行补位处理，最终的长度应该是 512 位的倍数）。

第二步：初始化哈希值（h）

现在，初始化 8 个哈希值。这些是硬编码的常数，分别代表前 8 个素数（2、3、5、7、11、13、17、19）的平方根的小数部分的前 32 位：

h0 := 0x6a09e667

h1 := 0xbb67ae85

h2 := 0x3c6ef372

h3 := 0xa54ff53a

h4 := 0x510e527f

h5 := 0x9b05688c

h6 := 0x1f83d9ab

h7 := 0x5be0cd19

第三步：初始化圆常数(k)

与步骤 2 类似，初始化一些常量，一共有 64 个。每个值（0-63）是前 64 个素数（2-311）的立方根分数部分的前 32 位。

0x428a2f98 0x71374491 0xb5c0fbcf 0xe9b5dba5 0x3956c25b 0x59f111f1

0x923f82a4 0xab1c5ed5 0xd807aa98 0x12835b01 0x243185be 0x550c7dc3

0x72be5d74 0x80deb1fe 0x9bdc06a7 0xc19bf174 0xe49b69c1 0xefbe4786

0x0fc19dc6 0x240ca1cc 0x2de92c6f 0x4a7484aa 0x5cb0a9dc 0x76f988da

0x983e5152 0xa831c66d 0xb00327c8 0xbf597fc7 0xc6e00bf3 0xd5a79147

0x06ca6351 0x14292967 0x27b70a85 0x2e1b2138 0x4d2c6dfc 0x53380d13

0x650a7354 0x766a0abb 0x81c2c92e 0x92722c85 0xa2bfe8a1 0xa81a664b

0xc24b8b70 0xc76c51a3 0xd192e819 0xd6990624 0xf40e3585 0x106aa070

0x19a4c116 0x1e376c08 0x2748774c 0x34b0bcb5 0x391c0cb3 0x4ed8aa4a

0x5b9cca4f 0x682e6ff3 0x748f82ee 0x78a5636f 0x84c87814 0x8cc70208

0x90befffa 0xa4506ceb 0xbef9a3f7 0xc67178f2

第四步：块循环

对输入的每 512 位分为一块，执行以下步骤：

注意

在本文的例子中，因为 “hello world” 太短了，所以只有一个块。在循环的每一次迭代中，都将对哈希值 h0-h7 进行变更，最终作为结果输出。

第五步：重组信息数组（w）

将步骤 1 中的输入数据重新排列到新数组中，其中每个条目都是一个 32 位字：

01101000011001010110110001101100 01101111001000000111011101101111

01110010011011000110010010000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000001011000
再加上 48 个初始化为零的字，这样就有了一个数组 w [0…63]

01101000011001010110110001101100 01101111001000000111011101101111

01110010011011000110010010000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000001011000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

… …

00000000000000000000000000000000 00000000000000000000000000000000
使用以下算法修改数组末尾的零索引：
```
For i from w[16…63]:
    s0 = (w[i-15] rightrotate 7) xor (w[i-15] rightrotate 18) xor (w[i-15] rightshift 3)

    s1 = (w[i- 2] rightrotate 17) xor (w[i- 2] rightrotate 19) xor (w[i- 2] rightshift 10)

    w[i] = w[i-16] + s0 + w[i-7] + s1
```
以 w[16] 举例说明：

w[1] rightrotate 7:

01101111001000000111011101101111 -> 11011110110111100100000011101110

w[1] rightrotate 18:

01101111001000000111011101101111 -> 00011101110110111101101111001000

w[1] rightshift 3:

01101111001000000111011101101111 -> 00001101111001000000111011101101

s0 = 11011110110111100100000011101110

XOR 00011101110110111101101111001000

XOR 00001101111001000000111011101101

= 11001110111000011001010111001011

w[14] rightrotate 17:

00000000000000000000000000000000 -> 00000000000000000000000000000000

w[14] rightrotate19:

00000000000000000000000000000000 -> 00000000000000000000000000000000

w[14] rightshift 10:

00000000000000000000000000000000 -> 00000000000000000000000000000000

s1 = 00000000000000000000000000000000

XOR 00000000000000000000000000000000

XOR 00000000000000000000000000000000

= 00000000000000000000000000000000
w[16] = w[0] + s0 + w[9] + s1

= 01101000011001010110110001101100
- 11001110111000011001010111001011
- 00000000000000000000000000000000
- 00000000000000000000000000000000
  = 00110111010001110000001000110111
// addition is calculated modulo $ 2^{32} $
总的结果就是：

01101000011001010110110001101100 01101111001000000111011101101111

01110010011011000110010010000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000000000000

00000000000000000000000000000000 00000000000000000000000001011000

00110111010001110000001000110111 10000110110100001100000000110001

11010011101111010001000100001011 01111000001111110100011110000010

00101010100100000111110011101101 01001011001011110111110011001001

00110001111000011001010001011101 10001001001101100100100101100100

01111111011110100000011011011010 11000001011110011010100100111010

10111011111010001111011001010101 00001100000110101110001111100110

10110000111111100000110101111101 01011111011011100101010110010011

00000000100010011001101101010010 00000111111100011100101010010100

00111011010111111110010111010110 01101000011001010110001011100110

11001000010011100000101010011110 00000110101011111001101100100101

10010010111011110110010011010111 01100011111110010101111001011010

11100011000101100110011111010111 10000100001110111101111000010110

11101110111011001010100001011011 10100000010011111111001000100001

11111001000110001010110110111000 00010100101010001001001000011001

00010000100001000101001100011101 01100000100100111110000011001101

10000011000000110101111111101001 11010101101011100111100100111000

00111001001111110000010110101101 11111011010010110001101111101111

11101011011101011111111100101001 01101010001101101001010100110100

00100010111111001001110011011000 10101001011101000000110100101011

01100000110011110011100010000101 11000100101011001001100000111010

00010001010000101111110110101101 10110000101100000001110111011001

10011000111100001100001101101111 01110010000101111011100000011110

10100010110101000110011110011010 00000001000011111001100101111011

11111100000101110100111100001010 11000010110000101110101100010110

第六步：压缩

初始化变量 a，b，c，d，e，f，g，h，并将它们分别设置为等于当前的哈希值：h0，h1，h2，h3，h4，h5，h6，h7
进行压缩循环。压缩循环将改变 a…h 的值。压缩循环如下：
```
for i from 0 to 63:
    S1 = (e rightrotate 6) xor (e rightrotate 11) xor (e rightrotate 25)
    ch = (e and f) xor ((not e) and g)
    temp1 = h + S1 + ch + k[i] + w[i]
    S0 = (a rightrotate 2) xor (a rightrotate 13) xor (a rightrotate 22)
    maj = (a and b) xor (a and c) xor (b and c)
    temp2 := S0 + maj
    h = g
    g = f
    e = d + temp1
    d = c
    c = b
    b = a
    a = temp1 + temp2
```
下面演示第一次迭代，所有加法都是以 $ 2^{32} $ 为模的：

a = 0x6a09e667 = 01101010000010011110011001100111

b = 0xbb67ae85 = 10111011011001111010111010000101

c = 0x3c6ef372 = 00111100011011101111001101110010

d = 0xa54ff53a = 10100101010011111111010100111010

e = 0x510e527f = 01010001000011100101001001111111

f = 0x9b05688c = 10011011000001010110100010001100

g = 0x1f83d9ab = 00011111100000111101100110101011

h = 0x5be0cd19 = 01011011111000001100110100011001

e rightrotate 6:

01010001000011100101001001111111 -> 11111101010001000011100101001001

e rightrotate 11:

01010001000011100101001001111111 -> 01001111111010100010000111001010

e rightrotate 25:

01010001000011100101001001111111 -> 10000111001010010011111110101000

S1 = 11111101010001000011100101001001

XOR 01001111111010100010000111001010

XOR 10000111001010010011111110101000

= 00110101100001110010011100101011

e and f:

01010001000011100101001001111111 & 10011011000001010110100010001100 = 00010001000001000100000000001100

not e:

01010001000011100101001001111111 -> 10101110111100011010110110000000

(not e) and g:

10101110111100011010110110000000 & 00011111100000111101100110101011 = 00001110100000011000100110000000

ch = (e and f) xor ((not e) and g)

= 00010001000001000100000000001100

XOR 00001110100000011000100110000000

= 00011111100001011100100110001100

// k[i] 是圆常数

// w[i] 信息数组

temp1 = h + S1 + ch + k[i] + w[i]

= 01011011111000001100110100011001 + 00110101100001110010011100101011 + 00011111100001011100100110001100 + 1000010100010100010111110011000 + 01101000011001010110110001101100 = 01011011110111010101100111010100

a rightrotate 2:

01101010000010011110011001100111 -> 11011010100000100111100110011001

a rightrotate 13:

01101010000010011110011001100111 -> 00110011001110110101000001001111

a rightrotate 22:

01101010000010011110011001100111 -> 00100111100110011001110110101000

S0 = 11011010100000100111100110011001

XOR 00110011001110110101000001001111

XOR 00100111100110011001110110101000

= 11001110001000001011010001111110

a and b:

01101010000010011110011001100111 & 10111011011001111010111010000101 = 00101010000000011010011000000101

a and c:

01101010000010011110011001100111 & 00111100011011101111001101110010 = 00101000000010001110001001100010

b and c:

10111011011001111010111010000101 & 00111100011011101111001101110010 = 00111000011001101010001000000000

maj = (a and b) xor (a and c) xor (b and c)

= 00101010000000011010011000000101

XOR 00101000000010001110001001100010

XOR 00111000011001101010001000000000

= 00111010011011111110011001100111

temp2 = S0 + maj = 11001110001000001011010001111110 + 00111010011011111110011001100111 = 00001000100100001001101011100101

h = 00011111100000111101100110101011

g = 10011011000001010110100010001100

f = 01010001000011100101001001111111

e = 10100101010011111111010100111010 + 01011011110111010101100111010100 = 00000001001011010100111100001110

d = 00111100011011101111001101110010

c = 10111011011001111010111010000101

b = 01101010000010011110011001100111

a = 01011011110111010101100111010100 + 00001000100100001001101011100101 = 01100100011011011111010010111001

整个计算会继续循环进行了 63 次，期间不断修改了变量 a-h 的值。最终结果为：

a = 4F434152 = 001001111010000110100000101010010

b = D7E58F83 = 011010111111001011000111110000011

c = 68BF5F65 = 001101000101111110101111101100101

d = 352DB6C0 = 000110101001011011011011011000000

e = 73769D64 = 001110011011101101001110101100100

f = DF4E1862 = 011011111010011100001100001100010

g = 71051E01 = 001110001000001010001111000000001

h = 870F00D0 = 010000111000011110000000011010000

第七步：修改最终值

压缩循环完成后，仍然处于在块循环中，通过向哈希值中添加它们各自的变量 a-h 来修改哈希值。同样的，所有的加法都是模 $ 2^{32} $。

h0 = h0 + a = 10111001010011010010011110111001

h1 = h1 + b = 10010011010011010011111000001000

h2 = h2 + c = 10100101001011100101001011010111

h3 = h3 + d = 11011010011111011010101111111010

h4 = h4 + e = 11000100100001001110111111100011

h5 = h5 + f = 01111010010100111000000011101110

h6 = h6 + g = 10010000100010001111011110101100

h7 = h7 + h = 11100010111011111100110111101001

第八步: 组成最终的哈希值

digest = h0 append h1 append h2 append h3 append h4 append h5 append h6 append h7
       = B94D27B9934D3E08A52E52D7DA7DABFAC484EFE37A5380EE9088F7ACE2EFCDE9

搞定！至此，本文非常详细地实现了 SHA-256 中的每一步 🙂。

附录

SHA-2 的第 t 个加密循环" >

SHA-2 的第 t 个加密循环

下面这段伪代码总结了上面执行的所有步骤：

几点说明

所有变量均为 32 位无符号整数，加法以 $ 2^{32} $ 为模
对于每一轮，在消息调度数组 w [i]，0≤i≤63 中有一个循环常数 k [i] 和一个条目。
压缩函数使用 8 个工作变量，a 到 h。
在此伪代码中表示常量时使用大端约定，并且当将消息块数据从字节解析到字时，例如，填充后的输入消息 “abc” 的第一个字是 0x61626380

Initialize hash values:
(first 32 bits of the fractional parts of the square roots of the first 8 primes 2..19):
h0 := 0x6a09e667
h1 := 0xbb67ae85
h2 := 0x3c6ef372
h3 := 0xa54ff53a
h4 := 0x510e527f
h5 := 0x9b05688c
h6 := 0x1f83d9ab
h7 := 0x5be0cd19

Initialize array of round constants:
(first 32 bits of the fractional parts of the cube roots of the first 64 primes 2..311):
k[0..63] :=
   0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
   0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
   0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
   0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
   0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
   0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
   0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
   0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2

Pre-processing (Padding):
begin with the original message of length L bits
append a single '1' bit
append K '0' bits, where K is the minimum number >= 0 such that L + 1 + K + 64 is a multiple of 512
append L as a 64-bit big-endian integer, making the total post-processed length a multiple of 512 bits

Process the message in successive 512-bit chunks:
break message into 512-bit chunks
for each chunk
    create a 64-entry message schedule array w[0..63] of 32-bit words
    (The initial values in w[0..63] don't matter, so many implementations zero them here)
    copy chunk into first 16 words w[0..15] of the message schedule array

    Extend the first 16 words into the remaining 48 words w[16..63] of the message schedule array:
    for i from 16 to 63
        s0 := (w[i-15] rightrotate  7) xor (w[i-15] rightrotate 18) xor (w[i-15] rightshift  3)
        s1 := (w[i- 2] rightrotate 17) xor (w[i- 2] rightrotate 19) xor (w[i- 2] rightshift 10)
        w[i] := w[i-16] + s0 + w[i-7] + s1

    Initialize working variables to current hash value:
    a := h0
    b := h1
    c := h2
    d := h3
    e := h4
    f := h5
    g := h6
    h := h7

    Compression function main loop:
    for i from 0 to 63
        S1 := (e rightrotate 6) xor (e rightrotate 11) xor (e rightrotate 25)
        ch := (e and f) xor ((not e) and g)
        temp1 := h + S1 + ch + k[i] + w[i]
        S0 := (a rightrotate 2) xor (a rightrotate 13) xor (a rightrotate 22)
        maj := (a and b) xor (a and c) xor (b and c)
        temp2 := S0 + maj

        h := g
        g := f
        f := e
        e := d + temp1
        d := c
        c := b
        b := a
        a := temp1 + temp2

    Add the compressed chunk to the current hash value:
    h0 := h0 + a
    h1 := h1 + b
    h2 := h2 + c
    h3 := h3 + d
    h4 := h4 + e
    h5 := h5 + f
    h6 := h6 + g
    h7 := h7 + h

Produce the final hash value (big-endian):
digest := hash := h0 append h1 append h2 append h3 append h4 append h5 append h6 append h7

参考

[1] How SHA-2 Works Step-By-Step (SHA-256)
[2] SHA-2

哈希函数简介

Sat, 25 Jul 2020 16:30:31 +0800

哈希函数入门介绍。

一点说明

本文中英文和二进制之间的相互转换并没有遵循任何模式，请读者不要纠结于这一点。当然，实际中，有很多方法用于将我们熟知的字符（例如中文、英语等）转换为二进制（十六进制），如果感兴趣，可以点击下面的参考中的内容

哈希函数（Hash Function）用来做什么？

哈希函数，又称散列函数，广泛应用于互联网的各处，包括但不限于安全地存储密码、查找重复记录、快速存储和检索数据等。例如，Qvault 应用使用哈希将主密码扩展为私人加密密钥。你还可以点击这里查看哈希函数用于何处。

重要特性

哈希函数的拥有如下三个重要特性，这些特性可以说是最重要的特性：

哈希函数对数据进行确定性加扰。
无论输入是什么，哈希函数的输出始终具有相同的长度（大小）。
无法从加扰数据中检索原始数据（单向函数）。

确定性加扰

想象一下，如果随机扭动一个魔方，到最后会得到一些和开始时不一样的东西。但是，如果重新开始，并做完全相同的一系列动作，那么将能够反复得到完全相同的结果。尽管结果可能看起来是随机的，但它其实是严格按照一定的规则进行变幻地，这就是确定性加扰的含义。

确定性对于安全存储密码很重要。例如，假设我的密码是 iLoveBitcoin，我可以使用哈希函数对其进行加扰：

iLoveBitcoin → “2f5sfsdfs5s1fsfsdf98ss4f84sfs6d5fs2d1fdf15”

现在，任何人看到加扰后的版本，他们都不会知道我的原始密码！这一点很重要，因为这意味着作为一个网站开发人员，我只需要存储我用户密码的哈希(加扰数据)就可以验证它们。当用户注册时，我将用户密码进行哈希运算然后将其存储在我的数据库中。当用户登录时，我只是对他们输入的内容再次进行哈希运算，并比较两个哈希值。因为给定的输入总是生成相同的哈希值，所以能够很方便地进行验证。

输出定长

如果对单个单词进行哈希处理，则输出将具有一定的大小（对于 SHA-256，则为特定的哈希函数，大小为 256 位）。即便我对一本书进行哈希处理，输出同样将是相同的大小。

这是另一个重要的功能，因为它可以节省我们的计算时间。一个典型的例子是使用哈希作为数据映射中的键。数据映射是计算机科学中用来存储数据的一种简单结构。

数据映射" >

数据映射

当程序在映射中存储数据时，会为映射指定一个键和值。当程序想要访问该值时，它只要提供适当的键就能接收相应的值。数据映射很好，因为它们可以立即找到数据。计算机通过键可以立即找到对应的值，而不是花费数小时在数百万条记录中搜索。

因为键类似于地址，所以它们不能太大。如果我想将图书存储在数据映射中，我可以对图书的内容进行哈希，并使用该哈希作为键。

哈希处理如何进行？

接下来，以 LANEHASH 算法为例，简要讲解哈希处理是如何完成的。

首先，选取下面的数据进行哈希处理

iLoveBitcoin
将字母转换成二进制

iLoveBitcoin→ 100010100000101111

注意

在这一步中，我们通过各种预定的步骤来转换我们的原始数据。转换方式可以采用各种方式，但重要的是，每当我们使用 LANEHASH 时，都需要使用相同的步骤，以便我们的算法是确定性的。
将比特前四位从左移到右边

100010100000101111 → 101000001011111000
奇偶分离比特

101000001011111000 → 110011110 & 000001100
分别转化为十进制数

110011110 → 414

000001100→ 12
两数相乘

414 *12 = 4968
乘积平方

4968 ^ 2 = 24681024
再次转换为二进制

24681024 →1011110001001101001000000
剥离右边的 9 个比特以得到 16 位比特

1011110001001101001000000 → 1011110001001101
转换回字母/数字

1011110001001101 → “8sj209dsns02k2”

正如你所看到的，如果在开始时使用相同的单词，则在结束时将始终得到相同的输出。然而，即使你改了一个字母，结果也会发生很大的变化。

总结

哈希函数实际上就是按照特定的规则将数据进行一系列转换，最后得到一串键值用来代替/指代原始数据，但是需要注意的是，哈希函数需要满足确定性、定长性、不可逆性。

参考

[1] (Very) Basic Intro to Hash Functions (SHA-256, MD5, etc)
[2] Hash Function
[3] ASCII
[4] Unicode

文件传输系列：SCP

Sat, 18 Jul 2020 10:28:05 +0800

SCP 就是 SSH 协议的文件传输功能吗？

什么是 SCP

SCP（Secure Copy Protocol，安全复制协议）允许我们在两台计算机之间复制文件（和目录）。

使用起来特别方便：

$ scp local_file remote_host:/home

这将把本地文件 localfile 复制到远程主机的 /home 文件之下。

SCP 使用起来特别便利，因为他能工作在几乎所有的 Unix-like 的系统中，并且 Windows 下拥有许多客户端。但是仅仅复制文件并不是关键。SCP 真正的价值是对 计算机的身份进行验证 以及对 传输文件进行加密（也就是 S 代表的含义）。

使用前需要首先配置到远程主机的 SSH 连接权限。SCP 的验证提示和 SSH 看起很像，因为 SCP 跑在 SSH 的上层，仅仅把它作为文件数据的管道。事实上，SSH 负责处理所有安全相关的任务，SCP 只是将一些文件扔到 SSH 连接上。

维基百科上的条目讲述了 SCP 的历史，简而言之：在旧的 BSD 系统上曾经有一个叫 RCP 的工具，可以在电脑之间移动文件。在当时受信任的网络时代，每个人都是别人的朋友。后来人们意识到，也许并不是每个人在他们的网络上都是这么好的朋友。于是有人把 RCP 的实现复制到 OpenSSH 的前身上，然后简单地在 SSH 会话上运行它，以保护文件不被非好友发现。问题解决了！从此以后，它就留在了 OpenSSH 中。

SCP 工作原理

SCP 并不是一个标准协议，并没有一个 RFC 或者任何官方描述如何实现它。OpenSSH 实现是一个事实上的规范。此实现有两个部分：连接建立和之后的传输协议。

建立连接

实际上，这并不是真正的连接。因为它只是利用 SSH 执行命令后的 STDIN/STDOUT ，有点类似 Unix 管道。OpenSSH 中包含两个程序来完成:sshd 和 scp。sshd 是始终运行的服务器守护进程，接受新的 SSH 连接。SCP 是伪装成 SSH 的客户端程序，发送和接受文件。

当 SCP 运行时，他将开启一个新的 SSH 连接。在该连接上，它会在服务端执行另一个带有特殊标志的 SCP 程序。你可以认为是 ssh exec scp [flags]。主要的标志包含 -t（“to”）和 -f（“from”）用于代表接受和发送，而 -d 表示文件夹，-r 表示递归。

建立连接" >

建立连接

值得注意的是，SCP 协议是单向的，一端发送文件，另一端接收文件。在远程端 SCP 开始运行后，实际的 SCP 协议命令开始通过 STDIN 和 STDOUT 运行。

传输协议

现在，安全的 I/O 通道建立起来，并且已经有效地切换到 RCP 协议上。该协议是顺序（一次一个操作）和同步（每个命令执行完后才执行下一个命令）执行的。

命令格式大致为（不带括号或空格）：[command type][arguments]\n [optional data]

[command type] 通常是一个 ASCII 字符：
- ‘C’- 写入文件
- ‘D’- 输入目录
- ‘E’- 退出最后一个目录
- ‘T’- 设置下一个文件或目录的创建 / 更新时间戳
[arguments] 是特定于命令的，如文件 / 目录名称、文件大小或时间戳。“E” 命令没有参数。
[optional data] 在上一个命令为 “C”（创建文件）时发送。数据的大小指定为 “C” 的参数。

此外，还有控制字节，这些字节是在没有新行的情况下自己发送的：

‘0x00’-“OK”，确认完成最后一个命令（如编写本地文件）。接收方也会在启动时发送此消息，让发送方知道它已准备好接收命令。
‘0x00’-“警告”，后面是要向用户显示的行（由新行终止）。
‘0x00’-“错误” 后跟随可选消息（和警告相同），但连接随后终止。

下面这个带有注释的图片实例，详细讲述了这个过程：

传输过程" >

传输过程

使用 SCP

$ scp 选项 参数

其中选项如下：

-1：使用ssh协议版本1；
-2：使用ssh协议版本2；
-4：使用ipv4；
-6：使用ipv6；
-B：以批处理模式运行；
-C：使用压缩；
-F：指定ssh配置文件；
-l：指定宽带限制；
-o：指定使用的ssh选项；
-P：指定远程主机的端口号；
-p：保留文件的最后修改时间，最后访问时间和权限模式；
-q：不显示复制进度；
-r：以递归方式复制。

参数分别为：

源文件：指定要复制的源文件。
目标文件：格式为 user@host：filename（文件名为目标文件的名称）。

SCP 的问题

看起来，SCP 听起来似乎没什么问题。它是一个简单易用的工具，然而存在一些现实问题。

性能

传输协议的顺序性：每个命令的强制确认都会增加大量开销。例如，如果沿途丢弃单个确认数据包，则整个连接将暂停，直到重新传输开始。最重要的是，发送所有数据而不压缩或询问接收方是否已经拥有该文件并不理想。

有经验的系统管理员可以告诉您，使用 tar 归档文件并发送比使用 scp 递归命令传输要快得多。事实上，这样的话你甚至无需使用 SCP：

# Copy a local folder with 10000 files
$ find /tmp/big_folder/-type f | wc -l
10000

# Using scp
$ time scp -r -q /tmp/big_folder/server:/tmp/big_folder

________________________________________________________
Executed in  882.99 millis	fish       	external
   usr time  114.09 millis	0.00 micros  114.09 millis
   sys time  278.46 millis  949.00 micros  277.51 millis

# Using tar over ssh
$ time sh -c "tar cf - /tmp/big_folder | ssh server 'tar xC /tmp/-f -'"
tar: Removing leading '/' from member names

________________________________________________________
Executed in  215.68 millis	fish       	external
   usr time   93.22 millis	0.00 micros   93.22 millis
   sys time   66.51 millis  897.00 micros   65.62 millis

在这种比较糟糕的情况下，tar&ssh 的 215.68ms 对比 SCP 的 882.99ms，足足有四倍的速度提升。

安全

我们已经知道，SCP 靠 SSH 负担安全工作，因此它完全安全… 吗？

OpenSSH 的发行说明提到：

scp 协议已经过时、不灵活且不容易修复。我们建议使用更现代的协议，如 sftp 和 rsync 来传输文件。

如果远程端的 shell 打印出任何非交互式会话，则本地 SCP 进程将愉快地将该输出解释为 SCP 命令。好的话，这仅仅是打破 SCP 协议中模糊的错误。但在最坏的情况下，远程 shell 启动脚本是恶意的，并向你发送恶意文件，而不是所需的文件。

此外，早在 2018 年，Harry Sintonen 就发现了流行的 SCP 实现（包括 OpenSSH）中的一堆漏洞。包括从修改目录的权限到覆盖任意文件（由于 ～/.ssh/authorized_keys 或 ～/.bashrc）、有效地执行代码，以及注入终端转义序列来隐藏任何追踪。这些漏洞对于任何构建网络 CLI 应用程序的人来说都是一个很好的教训。

SCP 的替代方案

SFTP 被广泛认为是 SCP 的继承者。为了传输层安全性，它仍然在 SSH 上运行，并且不需要单独设置访问。它可以为您提供一个自定义交互式提示来探索远程文件系统，或者您可以使用预先编写的一系列命令编写脚本。缺点是，您需要学习 SFTP 提示命令，协议本身尚未完全标准化（有很多 RFC 草稿，但作者最终放弃了）。

Rsync 是另一个很好的选择。使用与 SCP 命令完全相同 - 它也利用 SSH。Rsync 着重优化性能 - 它执行大量的复杂本地计算从而通过网络发送尽可能少的数据。从技术上讲，它致力于数据同步而不是纯传输文件 - 如果远程和本地内容相似，则只会发送增量。

同样，它也有其自身的缺点：发送方使用大量的 CPU 资源来计算要发送什么，并且接收方使用大量磁盘 IO 将数据按正确的顺序放在一起。与 OpenSSH 不同，Rsync 在大多数系统上并不预安装。

结论

SCP 是一个简单的工具，它在复制文件方面做得很好，但较新的软件在很多方面都优于它。对于您信任的计算机之间的个人简单使用，SCP 仍然适合。

但是，如果您遇到性能问题或需要满足更高的安全标准，则上面列出的任何备选方案都比 SCP 更可取。选择最适合您需求的，然后试着开始使用。

另见

rsync
SFTP

参考

[1] SCP - Familiar, Simple, Insecure, and Slow
[2] Wikipedia Secure copy
[3] Call for testing: OpenSSH 8.0
[4] Scp

TechKoala - Input/Output

Linux 内核网络核心：sk_buff 深度解析

第一部分：sk_buff 的物理与逻辑解剖

1. 核心设计哲学：元数据与数据的分离

2. 内存布局与指针系统

3. 线性区 vs 非线性区

第二部分：数据包的生命周期 (Flow)

1. 发送路径 (TX) —— “Push” 与 克隆

2. 接收路径 (RX) —— “Pull” 与 聚合

第三部分：核心机制与 Q&A

Q1: sk_buff 中的成员都是对应数据的指针吗？真实数据存在哪里？

Q2: 一个完整的数据包，是否就包含在 skb->head 和 skb->end 之间？

Q3: 为什么会有 skb_clone？它拷贝数据吗？

Q4: 环形缓冲区 (Ring Buffer) 在物理上是怎么理解的？

Q5: 硬中断和软中断具体分工是什么？

Q6: 零拷贝 (Zero Copy) 是如何运作的？

Q7: 发包时，当驱动说“发送完成”，数据真的发出去了吗？

Q8: 什么是 BQL 和 TSQ？它们解决什么问题？

Q9: 接收窗口 (Receive Window) 对应一块连续物理内存吗？

WireGuard 主要网络拓扑

点对点拓扑

简单点对点场景

复杂点对点场景

星型拓扑

简单星型场景

复杂星型场景

点到站点拓扑

简单点到站点场景

复杂点到站点场景

站点到站点拓扑

其他拓扑

原文链接

服务器基础设置

SSH

Users

Logs

Backups

Basic Network Safety

UFW

Fail2Ban

NGINX

Quality Of Life Tools

DNS

Docker

优点

缺点

总结

原文

拥抱Follow

搭建 CouchDB 数据库

Docker 安装 CouchDB

数据库管理

fly.io 搭建免费 CouchDB 数据库

Google One VPN 愉快玩耍指南

机制说明

先连接上

再共享出来

愉快使用

你有软路由？

没有软路由？

你只有安卓？

参考

Wi-Fi 7 物理层解读

PHY 变化

6GHz&320MHz

6GHz

320MHz

冲突

4K-QAM

为什么要有 QAM？

QAM 是如何工作的？

QAM 的星座图

QAM 对 Wi-Fi 标准速率影响

代价

MIMO 增强

MLD

OFDMA 增强

RU

前导码打孔 & MRU

参考

1. 发送路径 (TX) —— “Push” 与克隆

2. 接收路径 (RX) —— “Pull” 与聚合