Enjoy your life

中心化的，边缘十万级节点 DHCP Server 设计

2026-08-08T08:42:26.000Z

最近运维同事提出了一个需求：
在上层，我们目前有一个中央配置中心（依托于我们内部的CMDB）用于管理DHCP服务器和PXE相关的的配置和策略（运维平台），以便在需要时可以动态调整；
在下层一个大型数据中心网络中，需要设计一个能够支持十万级节点的DHCP服务器系统，同时还需要兼具PXEServer用于提供PXE启动服务（包括：裸金属装机、无盘启动）。
这个系统需要具备高可用性、可扩展性和负载均衡能力，以确保在高并发环境下能够稳定运行。

在这个量级，传统的单体架构已经无法满足需求，因此需要采用分布式架构来实现dhcp服务的可扩展性和高可用性。

目前，有两类ip分配：纯动态：在地址池中随机分配；纯静态：根据mac地址分配固定ip。

Pxe server：对于特定mac+来自pxe client的请求，我们还需要修改本机的配置文件（grub）用于实现特定配置(如ubuntu，windows，centos)pxe启动，这又涉及到了文件的并发读写。

整体系统实现思路很简单，但要保证一致性还是有一定难度的，下面我将详细描述这个系统的设计思路。

架构

graph TB    subgraph Center[中心管理服务]        direction TB        A[统一IP地址池管理] --> B[动态/静态IP分配引擎]        B --> C[gRPC服务端]        D[(IP地址池数据库)]        A -.-> D    end    subgraph Room1[机房A]        direction LR        S1[DHCP Server Agent 1] --> G1[gRPC客户端]    end    subgraph Room2[机房B]        direction LR        S2[DHCP Server Agent 2] --> G2[gRPC客户端]    end    subgraph RoomN[机房N]        direction LR        S3[DHCP Server Agent N] --> G3[gRPC客户端]    end    C <-->|双向流式gRPC| G1    C <-->|双向流式gRPC| G2    C <-->|双向流式gRPC| G3    classDef center fill:#e1f5fe,stroke:#01579b,stroke-width:2px    classDef room fill:#f3e5f5,stroke:#4a148c,stroke-width:2px    classDef agent fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px    class Center center    class Room1,Room2,RoomN room    class S1,S2,S3 agent

中心管理(我们内部的运维平台)：作为大脑，维护全局IP地址池数据库，并内置动态/静态IP分配引擎。所有分配决策均由中心服务做出。

通信机制：通过双向流式gRPC连接，支持中心服务实时推送配置变更，同时各机房Agent可上报状态与请求。

机房集群：每个机房内可部署多个DHCP Server Agent实例，形成高可用集群。所有Agent均以客户端身份与中心建立长连接。

需求核心策略

在接到一个需求时，我们首先要想的是这个需求的目的是什么：很明显，各业务节点都需要从dhcp server获取IP地址用于上网(当前，
有的节点在系统上配置了静态ip，但绝大多数仍然需要动态分配，无论是mac-ip静态绑定还是从地址池中随机分配，都是为了让节点能够上网)。

那很显然，系统要是崩了（含超时、故障等），节点就无法上网了，这就是我们要解决的核心问题 -> 稳定性问题。

如果ip分配冲突了，那么节点受路由，arp策略自然也无法上网了。
这个问题会出现的时机：agent与配置中心配置版本不一致、本地dhcp ippool分配逻辑错误，这就是我们要解决的第二个核心问题 -> 配置一致性问题（边缘节点与配置中心）。

Grub配置文件读写竞态：有的节点正在开机->读取grub配置；此时若云端下发其它节点的pxe配置 -> 并发读写问题。

约束点：配置都放在配置中心，所有的dhcp server agent都从配置中心拉取配置，这基本能够保证一致性，不需要担心传统分布式系统去中心化共识带来的一系列问题，
在纯分布式架构中，各dhcp server节点需要抢锁选举leader作为事实来源。但在中心-边缘架构中，中央服务是唯一的事实来源。

性能在这个系统里不是主要的考虑点，毕竟请求是很轻量的，对请求响应耗时要求也不高。

好，现在我们开始解决 需求核心策略 提到的关注点。

稳定性问题：

服务自动拉起

这个很好办，搭建一个dhcp 多节点server集群，每节点只负责特定mac段段处理请求，避免冲突。每个节点都可以独立处理请求，互不干扰。
dhcpserver交由systemd托管，宿主机开机、服务挂掉可以自动拉起重试。

断网时网络分区自保

网络断连时，agent无法与中心服务通信，但仍然可以继续提供dhcp服务。
因为agent在本地维护了静态mac-ip映射表和dhcp ip池，能够独立处理请求，但是这有一个期限：在配置中心不可用期间，agent只能基于本地配置提供服务
（时长为2分钟），直到配置中心恢复；如若两分钟内配置中心恢复，agent会立即与中心服务重新建立连接，并同步最新配置；若未恢复，则停止服务并重启。

配置中心：检测到 agent grpc流断开，中央服务立即回收之前授予该 agent 的 ip token池，将其标记为“待分配”，并在 120 秒后授权给其他存活 agent。

配置一致性问题：

配置中心管理静态macip映射、dhcp ip池、pxe参数，GRUB 模板。由于是双向流，下发必须保证幂等性和顺序性。

静态策略

同步机制：agent启动建立连接时，会携带本地配置版本号，
中心服务会根据版本号判断是否需要下发最新配置。若版本不一致，中心服务会将最新配置推送给agent，确保所有agent的配置保持一致（配置分为全量下发和增量下发）。

双向ack：agent收到配置后，会返回ack给中心服务，中心服务在收到ack后才会认为该agent的配置已更新成功。若未收到ack，中心服务会重试下发，直到成功为止
（对于网络抖动，下发重复配置，agent 依据配置版本号进行幂等忽略）。

直至配置同步完成，agent才会正式对外提供dhcp服务，避免配置不一致导致的ip冲突。

pxe参数与grub

pxe策略：pxe策略不存储于本地，毕竟数十万节点中，pxe dchp请求是少数，我这里采用的策略是收到请求后再去同步拉取响应。

当agent收到请求时，会携带请求的mac地址和pxe请求类型（如uefi/legacy等），
中心服务会根据mac地址查询pxe策略，并将对应的grub配置下发给agent，agent再将配置写入本地grub文件中（需要加文件锁），
确保pxe启动的正确性（读修复）。

动态ip dhcp地址池分配

虽然只有少部分节点是这种分配方式：比如我们有的客户，他们自己管自己虚拟机，没有报mac给我们，但要我们提供分配：即未知mac->动态分配

如果每个请求都同步阻塞等待中央服务，性能虽不至于雪崩，但也绝对不高效。我才用的策略是双向流异步批量仲裁。

在agent启动时，服务端会下发特定ip段（你可以理解为访客段）IP租赁许可证。{Agent_ID: AgentA, 授权IP段: 10.0.1.1~10.0.1.100, 排除: [10.0.1.7], 有效期: 120s, 版本号: 5}
IP 冲突彻底消失，因为中央服务将 IP 段切成互不重叠的“时间片”分配给不同 Agent。
若 Agent A 宕机，其持有的 Token 在 60s 后过期，中央服务可立即将该 IP 段授权给 Agent B（故障转移），且绝不重叠。

agent 会在 pool 内存中做快速fifo分配，毫秒级响应，然后再上报ip-mac分配.
配置中心收到后，会将该分配结果写入数据库，并在下次配置下发时同步给所有agent，确保全局一致性。

当时设计时询问了AI，AI说还有一种极少数情况：若中央服务发现批量日志中的某个 ip 已被其它 agent 的 token 占用
（极少数时钟/逻辑 BUG 导致），中央服务会立即在 gRPC 流中下发 Force_Revoke(IP, MAC)
指令给当前 Agent。Agent 收到后，必须对该 MAC 主动发送 DHCP FORCERENEW 或拒绝续租，强制纠错（最终一致性兜底），不过我感觉这是不必要的。

并发读写：

PXE启动时，grub配置文件的读写是并发的。为了解决这个问题，我们在agent中实现了文件锁机制。
这样，就算同时收到dhcp请求、grub请求和配置下发，所有操作依然是串行化的，避免了并发读写导致的配置文件损坏或不一致问题。
毕竟，就算pxe dhcp请求再怎么多，量级也不会特别大；而且pxe dhcp请求的bios中设置的超时往往特别长，所以只要加了锁，这个问题的影响是可控的。

设计一个nats消息队列负载均衡系统

2025-06-27T10:18:29.000Z

试着回答一下这个有趣的消费-生产问题吧:

这是一个使用消息队列解耦多个生产者和多个消费者的系统。
生产者生产的消息是有分区的(按project_id分区),分区也会动态分配。
消费者需要竞争消费消息,每个消费者可以消费多个分区。
对于一个分区,最多有不超过1/n个消费者在消费。
生产者和消费者根据性能和数据量,会在kubernetes中进行动态的扩缩容。

消息需要尽可能的被均匀地分配到消费者上,以实现负载均衡。

消息需要尽可能的N等分，这N份消息将分配给消费者服务A(A的数量N>=2A)

e.g: 1/10 情景: 消息需要尽可能的10等分，这10份消息将分配给消费者服务A(A的数量>=5),对于不满足5的倍数情况，如23个消费者，则余下3个随机分配

在这种动态输入输出的情况下,我们该如何设计一个消息队列负载均衡系统呢，如何保证3个9的SLA呢?

流量路径

客户的IoT Devices -> StreamGateway(nginx)四层负载均衡 -> DataGateway(生产者集群) -> NATS JetStream(消息队列集群) -> DataHandler(消费者数据存储集群)

背景

上述问题就是我在工作中遇到的一个实际场景。我们需要设计一个系统来处理多个生产者和消费者之间的消息传递，同时确保负载均衡和动态扩缩容。

这套系统使用mermaid图来描述其架构和工作流程如下:

graph TD    subgraph Producers["生产者"]        P1[生产者 1]        P2[生产者 2]        P3[生产者 ...]    end    subgraph MessageQueue["消息队列 (按 project_id 分区)"]        Partition1[分区 1]        Partition2[分区 2]        Partition3[分区 ...]    end    subgraph Consumers["消费者"]        C1[消费者 1]        C2[消费者 2]        C3[消费者 ...]    end    subgraph Kubernetes["Kubernetes 集群"]        ScaleUpDown[动态扩缩容根据性能和数据量]    end    P1 -->|生产消息| Partition1    P2 -->|生产消息| Partition2    P3 -->|生产消息| Partition3    Partition1 -->|竞争消费最多1/n消费者| C1    Partition1 -->|竞争消费最多1/n消费者| C2    Partition2 -->|竞争消费最多1/n消费者| C2    Partition2 -->|竞争消费最多1/n消费者| C3    Partition3 -->|竞争消费最多1/n消费者| C1    Partition3 -->|竞争消费最多1/n消费者| C3    Producers -->|动态扩缩容| Kubernetes    Consumers -->|动态扩缩容| Kubernetes

你可能会注意到,在这个系统中,生产者和消费者都是动态的,并且消息队列是按project_id分区的。这意味着我们需要一个灵活的机制来处理消息的分发和消费。

那么,为什么他们是动态的呢?

在实际应用中,生产者和消费者的数量会根据业务需求和系统负载进行调整。例如,在高峰期可能需要增加更多的消费者来处理大量的消息，而在低峰期则可以减少消费者以节省资源。

扩缩容策略：

消费者leader会根据性能(Cpu>=90%)或数据量(单个消费者消费的消息条数超过消费者数量的50倍(这个数据也可以动态配置)，如100个消费者消费超过5000条),leader会调用kubernetes api进行动态的扩容。

当每个消费者平均消费的消息小于2条时缩容。

工作背景:

系统是一个物联网系统,需要处理不同客户上报的数据,并对其进行处理.

所有客户上报的数据(消息)会遵循一定的规律.在这里,它是一个project, 因此会有唯一的project_id

所有的消息以projectid进行分区，
生产者(数据网关)会将projectid投送至DATASTORE_PROJECT，
消费者在通过订阅获取到DATASTORE_PROJECT后，
发送成功请求至DATASTORE_PROJECT_REG_RESP，并订阅DATASTORE_PROJECT_DATA数据开始消费

const (
    DATASTORE_PROJECT = "/handler/data/partitions/p%d" // e.g., /handler/data/partitions/p0, ... p127
    DATASTORE_PROJECT_REG_RESP = DATASTORE_PROJECT + "/%s/reg/response"
    DATASTORE_PROJECT_CLOSE = DATASTORE_PROJECT + "/%s/close"
    DATASTORE_PROJECT_DATA= DATASTORE_PROJECT + "/%s/data"
)

Language And Tools

Golang
NATS(JetStream)
Kubernetes
Etcd

Solution

我们的解决目标是构建一个能够动态伸缩、自动负载均衡的消费者集群。

我们将采用 分区(Partitioning)和服务协调(Coordination) 相结合的策略。

核心思路

我们将放弃 “所有消费者都去订阅同一个发现Topic” 的模式，因为这会导致所有消费者产生 惊群效应 ,并需要复杂的分布式锁来争抢和校验projectId

取而代之的核心思想是：

固定分区：
我们将projectid的空间预先划分成一个固定的、数量较多的分区，例如 P = 128 个。每个projectid通过哈希计算后，将永远属于同一个分区。
动态分配：
通过一个中心化的协调服务（etcd），将这 P 个分区动态地、均衡地分配给当前所有存活的 N 个消费者。
领导者选举：
在所有消费者中，选举出一个 Leader。这个 Leader 负责监控消费者的增减，并执行分区的重新分配和动态扩缩容决策。

这个设计类似于 Kafka 的 Consumer Group 机制，具有高可用性和水平扩展性。

生产者逻辑（分区划分）

当一个projectid需要被处理时，生产者会：

计算该projectid的哈希值。
对哈希值取模，得到分区号 partition_id = hash(projectid) % P。
将该projectid投递到对应的分区Topic，例如 /handler/data/partitions/p42。
生产者不需要关心消费者的数量和状态，只需将消息投递到正确的分区。

import (
  "crypto/sha256"
  "math/big"
)

func GetPartition(id string, totalPartitions int) int {
  hash := sha256.Sum256([]byte(id))
  hashInt := new(big.Int).SetBytes(hash[:])
  return int(hashInt.Mod(hashInt, big.NewInt(int64(totalPartitions))).Int64())
}

服务协调和leader选举

etcd 终于登场了。在这个部分，它扮演了项目里至关重要的协调角色。在项目里，我利用它的几个特性：

键值存储：存储分区分配状态和消费者信息。
Watch机制：实时监控消费者变化。
Lease机制(TTL)：实现消费者心跳和故障检测。
分布式锁：实现领导选举。

数据结构

/consumers/
/{consumer-id} -> {“cpu”: 25.5, “project_count”: 30, “last_message_id”: “uuid” } (Lease attached)
每个消费者启动后，都会在这个目录下创建一个以自己唯一ID为名的key，并关联一个Lease（租约，带TTL）。消费者需要定期续约（”心跳”），如果Lease过期，key会自动删除，代表该消费者已下线。值用来存放该消费者的性能指标。
/partitions/
/{partition_id} -> {consumer-id}
这个目录存储了每个分区当前被哪个消费者占有。例如 /partitions/42 -> consumer-abc。
/leader
一个用于分布式锁的key，成功写入该key的消费者成为Leader,同样需要关联Lease。

消费者逻辑（Leader）

Leader消费者负责以下任务：

赢得选举：启动后，所有消费者实例尝试获取 /leader 这个key上的锁。成功的成为Leader。
监控消费者变化：Leader WATCH etcd中的 /consumers/ 目录，获取事件变化。
- 新消费者加入 (PUT)：触发再均衡 (Rebalance)。
- 消费者下线 (DELETE)：触发再均衡。
- ?什么时候消费者数量会变化？
  - 一般是消费者崩溃时（数据处理有可能导致崩溃，不过崩溃并不会导致数据丢失，数据会因为没有ACK重新回到分区）
执行再均衡：
- 获取当前所有存活的消费者列表 C (from /consumers/)。
- 获取当前所有的分区列表 P (0 to 127)。
- 执行分配算法：为每个消费者 c in C 分配 P/N 个分区。
  - 最简单的分配方式是 partition_id % len(C)，将分区 i 分配给 C[i % len(C)]。
  - 为了最小化分区迁移，可以采用更优化的算法（如一致性哈希环的变种），不过，取模方式已足够均衡。
- 更新etcd：将新的分配结果 map[partition_id]consumer_id 写入到 /partitions/ 目录。
执行扩缩容：Leader 定期（在代码里，项目里设置了30s）执行一次监控和扩缩容决策。

消费者逻辑（Worker【include leader】）

注册和发送心跳：启动后，生成唯一ID，在etcd /consumers/{consumer-id} 创建自己的key，并持续续约Lease。
监控任务分配：WATCH etcd中的 /partitions/ 目录。
响应任务变更：
- 当发现某个分区 p 的负责人变成了自己 (/partitions/p -> my-id)，并且自己之前未订阅该分区：
- a. 立刻通过NATS订阅对应的分区Topic: /handler/data/partitions/p{p}。
- 当发现某个分区 p 的负责人不再是自己 (/partitions/p 被删除或值变为其他id)，并且自己正在订阅该分区：
- a. 立刻取消NATS对该分区Topic的订阅，并完成正在处理的消息后，停止处理来自该分区的任何新消息。
消费数据：从已订阅的分区Topic中接收到 projectid 后，执行原有的业务逻辑：
- 发送成功请求至 DATASTORE_PROJECT_REG_RESP。
- 订阅 DATASTORE_PROJECT_DATA。
上报状态：定期更新自己在etcd中 /consumers/{consumer-id} 的值，报告信息，供Leader决策。

动态扩缩容策略（Leader）

数据定义：

cpu: cpu使用率
cpu_max_usage: 节点触发扩容的CPU使用率
project_count: 消费者当前处理的项目数量
max_project_count：触发扩容的项目数量阈值
N: 消费者数量

Leader会定期（30秒）检查所有消费者的状态，并根据以下规则决定是否扩缩容：

超过CPU上限：如果有任何消费者的 cpu 使用率超过 cpu_max_usage（90%），则触发扩容。
超过负载上限：
1. 计算N.
2. 获取所有消费者的 project_count，并计算平均值 avg_project_count = sum(project_count) / N。
3. 如果 avg_project_count > max_project_count（50）
4. 触发扩容:
  - Leader调用Go的Kubernetes客户端，更新对应Deployment的 replicas 字段，使其 replicas = replicas + 1
  - 冷静期：为防止频繁扩缩容，一次操作后，进入一个冷却期（10分钟），在此期间不执行扩缩容轮询操作。
平均负载过低：
1. 计算N。
2. 计算总项目数 avg_project_count = sum(project_counts) / N。
3. if N > min_replicas (e.g., 2) && avg_project_count / N < 2。
4. 触发缩容:
  - Leader调用Go的Kubernetes客户端，更新对应Deployment的 replicas 字段，使其 replicas = replicas - 1
  - 冷静期：同样，为防止频繁扩缩容，一次操作后，进入一个冷却期（10分钟），在此期间不执行扩缩容轮询操作。

工作流程：

K8s启动消费Pod。
该Pod内的服务实例启动，生成唯一ID consumer-hostname。
consumer-hostname 连接etcd，在 /consumers/consumer-hostname 创建了一个带10秒Lease的key，并开始每5秒续约一次。
Leader正在 WATCH /consumers/，收到 consumer-hostname 的 PUT 事件。
Leader触发再均衡逻辑。假设之前有3个消费者 c1, c2, c3，现在有4个了。分区总数是128。
- 旧分配：c1 (0,3,6,…), c2 (1,4,7,…), c3 (2,5,8,…)。
- 新分配：c1 (0,4,8,…), c2 (1,5,9,…), c3 (2,6,10,…), consumer-hostname (3,7,11,…)。
Leader将新的分配结果批量更新到etcd的 /partitions/ 目录下。
所有消费者（包括c1,c2,c3,consumer-hostname）都在WATCH /partitions/。
c1, c2, c3 发现自己的一些分区被剥夺了，它们会取消对这些分区Topic的NATS订阅。
consumer-hostname 发现自己被分配了一批新的分区，它会去订阅这些分区对应的NATS Topic。
系统在没有停机的情况下，自动将负载均衡到了新的消费者上。

数据一致性保障：

你可能会担心：在消费者宕机时（这系统在消费者因为外部逻辑的问题，存在处理数据时崩溃的可能），数据的一致性和完整性如何保障。
在这套系统里，我们采用以下策略来处理这些情况：

JetStream

NATS JetStream支持一种数据应答机制，确保消息在被消费者处理后，才会从队列中删除。
消费者在处理完数据后，必须发送一个确认消息（ACK）给JetStream，只有收到ACK后，JetStream才会将该消息从队列中移除。

Stream定义：

Subjects: “/handler/data/partitions/*”
Storage: “Memory” (Quickly)
Retention Policy: WorkQueuePolicy (消息被成功消费后即可删除)
Replicas: 3
Ack Policy: AckExplicit
Ack Wait Timeout: 5s(我们经过统计，5秒足够处理客户的数据了，数据SLA已达到6个9要求[99.9999%]，再长的等待时间会导致资源浪费)

消费者宕机时的数据处理

如果消费者在处理数据(已拉取，发送uuid响应，但没写入最终结果)时宕机，系统会自动将其数据重新投入队列，其触发流程如下：

消费者在处理数据时，发送了成功请求至 DATASTORE_PROJECT_REG_RESP，但未完成最终数据处理。
NATS JetStream在 5秒后未收到ACK时，将该消息重新放回队列。

总结

通过上述设计，我们项目组实现了一个高效、动态的消息队列负载均衡系统。

它能够在生产者和消费者数量变化时，自动调整分区分配，确保负载均衡，并且在消费者宕机时，能够保证数据的一致性和完整性。

我去哪了...

2025-06-25T10:09:32.000Z

最近有朋友问我去哪了，为什么不更新文章了…

时光飞逝，转眼间已经2025年了，距离上次更新文章已经过去了一年有余。

在这一年里经历了很多事情，生活和工作上也有了新的挑战和成长。

虽然没有时间更新文章，但我一直在思考如何更好地分享我的一切。

这一年…

从南昌到杭州, 从杭州到北京, 从南到北, 走过喧嚣的大城市…

在福州平潭的小岛上, 领略惬意的海风

在南宁品鉴水果,与故友相见

在广州的珠江新城, 奔波于各大写字楼

我似乎老了, 但更多的是释然

祖国的大好河山还等着我们去探索,

放下眼前的苦楚吧,睁开眼拥抱世界

本地Web应用-实现文件/目录选择器-获取文件完整路径

2024-03-13T14:34:07.000Z

有时候我们需要需要实现通过浏览器选择文件获取文件信息而不上传文件, 这个时候JavaScript的内置api就足以完成需求. 但是,如果我们需要获取到文件的完整路径, 那么对不起, 由于为了安全避免xss攻击, 现代的浏览器仅能获取到一个虚假的路径或者根本无法获取(IE10之前的浏览器可以获取到完整路径).

如果我们是本地Web应用, 这个问题就可以得到解决.解决方案有Electron封装,或者提供一个运行在本地的Agent用于获取文件路径,再由前端选择文件提交至 Agent或后端, 如果选择前者,再由Agent将路径间接传递至后端.

本文分享使用Go作为后端,Vue作为前端的,一起运行在本地的Web应用解决方案.

(附完整代码)

效果图

我们的需求

后端需要获取到选择路径=>通过图形化/命令行获取

图形化获取=>需要选择实现图形化的方案=>Web方案

Web需要获取本地路径=>通过Api获取=>方案行不通X 通过后端返回路径供前端选择,再由前端选择后提交回后端:行得通√

后端设计

数据类型定义

在前后端交互过程中,我们需要规定一个表单格式

前端向后端发出获取目录文件列表的请求体

{
    id:"xxx", 
    nowDir:"./",
}

后端向前端返回的目录格式

{
    File:[name:"",time:"",isDir:false],
  allowBack:true,
  status:"selectSuccess/ok/fail",
}

代码

Golang-Gin

路由路径

api/v1/file/xxx

Gin初始化和中间件设置


var RouterGroupApp []CommonRouter

func InitRouter() {
  // 初始化路由
  global.Router = gin.Default()
  global.Router.MaxMultipartMemory = 50 << 20 //设置最大上传文件大小50 Gb
  global.Router.Use( /*使用中间件*/ )
  static()
  //路由组
  RouterGroupApp = commonGroups()
  PrivateGroup := global.Router.Group("/api/v1")
  for _, router := range RouterGroupApp {
    router.InitRouter(PrivateGroup)
  }
  //启动
  err := global.Router.Run(":18088") //设置侦听端口
  if err != nil {
    logrus.Errorln("Web Server start error, error Info is: ", err)
    logrus.Info("Web Server will not start, please check the configuration or error Info.")
    return
  }
}
func static() { 
  //设置静态资源
  global.Router.Static("/static", "./res")
  global.Router.Static("/assets", "./res")
  global.Router.Static("/index.html", "./index.html")
  global.Router.GET("/favicon.ico", func(context *gin.Context) {
    context.Redirect(302, "/static/favicon.ico")
  })
  global.Router.LoadHTMLGlob("res/html/*.html")
  global.Router.NoRoute(func(c *gin.Context) {
    c.HTML(http.StatusOK, "404.html", gin.H{
      "title": "404",
    })
  })
}

通过实现接口和对接口的调用快速初始化各路由组

type CommonRouter interface {
  InitRouter(Router *gin.RouterGroup)
}

func commonGroups() []CommonRouter {
  return []CommonRouter{
    &FileRouter{},
  }
}

实现文件路由组功能:

type FileRouter struct{}

func (s *FileRouter) InitRouter(Router *gin.RouterGroup) {
  fileRouter := Router.Group("file")
  fileApi := v1.ApiGroupApp.FileApi
  fileRouter.POST("/list", fileApi.DirList)
  fileRouter.POST("/select", fileApi.FileSelect)
  fileRouter.POST("/pwd", fileApi.GetNowDir)
  fileRouter.GET("/pwd", fileApi.GetNowDir)
  fileRouter.POST("/chdir", fileApi.Chdir)
}

路由处理:

type FileApi struct {
  dir  map[string]string //id(task) path
  init bool
}

func (f *FileApi) DirList(context *gin.Context) { 
  //列出目录信息
  if !f.init {
    f.dir = make(map[string]string)
    f.init = true
  }
  //解析请求体
  id := context.PostForm("id")
  nowDir := context.PostForm("nowDir")
  if id == "" || nowDir == "" {
    context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
    return
  }
  _, ok := f.dir[id]
  if !ok {
    f.dir[id] = "./" //第一次访问
  } else {
    _, err := os.Stat(path.Join(f.dir[id], nowDir))
    if err != nil {
      //路径不存在 不允许继续
      context.JSON(http.StatusBadRequest, gin.H{"status": "now dir not exist"})
      return
    }
    f.dir[id] = path.Join(f.dir[id], nowDir)
  }
  type file struct {
    Name  string `json:"name"`
    IsDir bool   `json:"isDir"`
    Time  string `json:"time"`
  }
  var Files []file
  files, _ := os.ReadDir(f.dir[id])
  for _, v := range files {
    t, _ := v.Info()
    Files = append(Files, file{v.Name(), v.IsDir(), t.ModTime().Format("2006-01-02 15:04:05")})
  }
  //todo 判断是否允许上一级目录
  context.JSON(200, gin.H{"File": Files, "allowBack": true, "status": "ok"})
}

func (f *FileApi) FileSelect(context *gin.Context) {
  //目录或文件选择
  //{id:"", nowDir:"",}
  if !f.init {
    f.dir = make(map[string]string)
    f.init = true
  }
  id := context.PostForm("id")
  nowDir := context.PostForm("nowDir")
  if id == "" || nowDir == "" {
    context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
    return
  }
  info, err := os.Stat(path.Join(f.dir[id], nowDir))
  if err != nil {
    //文件不存在(一般来说不应该有)
    context.JSON(http.StatusBadRequest, gin.H{"status": "file or dir not exist. fail"})
    return
  } else {
    _, err = os.Stat(path.Join(f.dir[id], nowDir, "go.mod"))
    mod := false
    if err == nil {
      mod = true
    }
    if !info.IsDir() || mod {
      //
      t := builder.UsingAuto(path.Join(f.dir[id], nowDir), "build from web")
      if len(t) != 0 {
        builder.Tasks[id] = t[0]
        logrus.Infoln("select success. Path:", path.Join(f.dir[id], nowDir))
        context.JSON(200, gin.H{"status": "selectSuccess.ID=" + id})
      } else {
        context.JSON(http.StatusBadRequest, gin.H{"status": "fail. Not Config File / Dir?"})
      }
      return
    } else {
      f.DirList(context)
      return
    }
  }

}

func (f *FileApi) GetNowDir(context *gin.Context) {
  if !f.init {
    f.dir = make(map[string]string)
    f.init = true
  }
  var id string
  if context.Request.Method == "POST" {
    id = context.PostForm("id")
  } else if context.Request.Method == "GET" {
    id = context.Query("id")
  }
  if id == "" {
    context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
    return
  }
  abs, err := filepath.Abs(f.dir[id])
  if err != nil {
    context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
    return
  }
  context.JSON(200, gin.H{"status": "success", "dir": abs})
}

func (f *FileApi) Chdir(context *gin.Context) {
  if !f.init {
    f.dir = make(map[string]string)
    f.init = true
  }
  id := context.PostForm("id")
  nowDir := context.PostForm("nowDir")
  if id == "" || nowDir == "" {
    context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
    return
  }
  t, _ := os.Getwd()
  err := os.Chdir(nowDir)
  if err != nil {
    context.JSON(http.StatusBadRequest, gin.H{"status": "PathError."})
    return
  }
  os.Chdir(t)
  //valid dir
  f.dir[id] = filepath.Dir(nowDir)
  f.DirList(context)
}

前端设计

前端的实现:Vue3+ElementPlus

界面组成

一个网页组件容器{
顶端{目录显示框}
主功能区{
一个表格:展示路径
表头:
表格内容{
列1:图标列2:文件名要求点击文件可以选择或者进入目录列3:时间列4:功能区
}
}
}

接口Api设计

接口是前端用于访问后端的桥梁,适当的对接口进行封装可以方便各页面的调用,减少页面端的代码量,减少冗余.

src/api/axiosInstance.js 用于实现axios的各功能

import axios from 'axios'
let Port='18088'
function validateStatus(status) {
  return status<=500
}
const API = axios.create({
  baseURL:'http://localhost:'+Port, //
  timeout: 2000,                   //ms
  withCredentials:true,
  validateStatus
})
export default API

src/api/file.js 用于调用后端接口

import API from "./axiosInstance.js";

export function DirList(data) {
    return API.post('/api/v1/file/list', data)
}
export function FileSelect(data) {
    return API.post('/api/v1/file/select', data)
}
export function Pwd(data) {
    return API.post('/api/v1/file/pwd', data)
}
export function Chdir(data){
    return API.post('/api/v1/file/chdir', data)
}

页面内方法

适用于页面内的JavaScript方法

const regex = /^[^.]+(\.yaml|\.json|\.yml)$/i;

export default {
  data() {
    return {
      tableData: ref([]),
      loading: ref(true),
      dir: ref(''),
    }
  },
  mounted() {
    this.start();
  },
  methods: {
    flashTable(data) { //'id=xxx&nowDir=./'
      this.loading = true
      this.tableData = []
      DirList(data).then(response => {
        if (response.status === 200) {
          let data = response.data
          if (data.allowBack === true) {
            this.tableData.push({ name: "../", time: "", isDir: true })
          }
          for (let i = 0; i < data.File.length; i++) {
            this.tableData.push({ name: data.File[i].name, time: data.File[i].time, isDir: data.File[i].isDir })
          }
        }
        this.loading = false
      }).catch(error => {
      })
      Pwd(data).then(response => {
        if (response.status === 200) {
          //console.log(response.data.dir)
          this.dir = response.data.dir
        }
      })
    },
    select(row) {
      let result = regex.test(row.name) || row.isDir
      if (!result) {
        console.log("请选择json/yaml或目录")
        return
      }
      let params = new URLSearchParams();
      params.append('id', this.id);
      params.append('nowDir', row.name);
      FileSelect(params).then(response => {
        //todo
      })
    },
    entry(row) {
      this.loading = true
      if (row.isDir === true) {
        let params = new URLSearchParams();
        params.append('id', this.id);
        params.append('nowDir', row.name);
        this.flashTable(params);
      } else {
        //todo 打开文件
      }
      this.loading = false
    },
    start() {
      let params = new URLSearchParams();
      params.append('id', this.id);
      params.append('nowDir', "./");
      this.flashTable(params);
    },
    enterClick() {
      let params = new URLSearchParams();
      params.append('id', this.id);
      params.append('nowDir', this.dir);
      Chdir(params)
      this.flashTable(params)
    }
  }
}

页面设计

Vue3变更注意:

从网上找到了很多Vue获取表格行内容的博文,但是都不是针对Vue3的.目前Vue3对表格行绑定做出了变更

我们需要在表格标记中添加 slot-scope=”scope”


    highlight-current-row slot-scope="scope" style="width: 100%" max-height="600px"/>

然后才能在表格行中获取行.

界面部分


  
      Enter
    
  
      highlight-current-row slot-scope="scope" style="width: 100%" max-height="600px">

完整代码参考:

前端部分:

以及上面的两个JavaScript文件

后端部分

app/api/v1/entry.go

package v1

type ApiGroup struct {
    FileApi
}

var ApiGroupApp = new(ApiGroup)

app/api/v1/file.go

package v1

import (
    "github.com/aenjoy/BuilderX-go/app/builder"
    "github.com/gin-gonic/gin"
    "github.com/sirupsen/logrus"
    "net/http"
    "os"
    "path"
    "path/filepath"
)

type FileApi struct {
    dir  map[string]string //id(task) path
    init bool
}

//curl http://localhost:18088/api/v1/file/select  -X POST -d 'id=xxx&nowDir=./'

func (f *FileApi) DirList(context *gin.Context) { //目录
    if !f.init {
       f.dir = make(map[string]string)
       f.init = true
    }
    //POST
    //{id:"", nowDir:"",} id用于记录当前访问时的路径
    //outPut {File:[
    //name:"",
    //time:"",
    //isDir:false,
    //],
    //allowBack:true,
    //status:"selectSuccess/ok/fail",
    //
    //}
    id := context.PostForm("id")
    nowDir := context.PostForm("nowDir")
    if id == "" || nowDir == "" {
       context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
       return
    }
    _, ok := f.dir[id]
    if !ok {
       f.dir[id] = "./" //第一次访问
    } else {
       _, err := os.Stat(path.Join(f.dir[id], nowDir))
       if err != nil {
          //路径不存在 不允许继续
          context.JSON(http.StatusBadRequest, gin.H{"status": "now dir not exist"})
          return
       }
       f.dir[id] = path.Join(f.dir[id], nowDir)
    }
    type file struct {
       Name  string `json:"name"`
       IsDir bool   `json:"isDir"`
       Time  string `json:"time"`
    }
    var Files []file
    files, _ := os.ReadDir(f.dir[id])
    for _, v := range files {
       t, _ := v.Info()
       Files = append(Files, file{v.Name(), v.IsDir(), t.ModTime().Format("2006-01-02 15:04:05")})
    }
    //todo 判断是否允许上一级目录
    context.JSON(200, gin.H{"File": Files, "allowBack": true, "status": "ok"})
}

func (f *FileApi) FileSelect(context *gin.Context) {
    //目录或文件选择
    //{id:"", nowDir:"",}
    if !f.init {
       f.dir = make(map[string]string)
       f.init = true
    }
    id := context.PostForm("id")
    nowDir := context.PostForm("nowDir")
    if id == "" || nowDir == "" {
       context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
       return
    }
    info, err := os.Stat(path.Join(f.dir[id], nowDir))
    if err != nil {
       //文件不存在(一般来说不应该有)
       context.JSON(http.StatusBadRequest, gin.H{"status": "file or dir not exist. fail"})
       return
    } else {
       _, err = os.Stat(path.Join(f.dir[id], nowDir, "go.mod"))
       mod := false
       if err == nil {
          mod = true
       }
       if !info.IsDir() || mod {
          //
          t := builder.UsingAuto(path.Join(f.dir[id], nowDir), "build from web")
          if len(t) != 0 {
             builder.Tasks[id] = t[0]
             logrus.Infoln("select success. Path:", path.Join(f.dir[id], nowDir))
             context.JSON(200, gin.H{"status": "selectSuccess.ID=" + id})
          } else {
             context.JSON(http.StatusBadRequest, gin.H{"status": "fail. Not Config File / Dir?"})
          }
          return
       } else {
          f.DirList(context)
          return
       }
    }

}

func (f *FileApi) GetNowDir(context *gin.Context) {
    if !f.init {
       f.dir = make(map[string]string)
       f.init = true
    }
    var id string
    if context.Request.Method == "POST" {
       id = context.PostForm("id")
    } else if context.Request.Method == "GET" {
       id = context.Query("id")
    }
    if id == "" {
       context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
       return
    }
    abs, err := filepath.Abs(f.dir[id])
    if err != nil {
       context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
       return
    }
    context.JSON(200, gin.H{"status": "success", "dir": abs})
}

func (f *FileApi) Chdir(context *gin.Context) {
    if !f.init {
       f.dir = make(map[string]string)
       f.init = true
    }
    id := context.PostForm("id")
    nowDir := context.PostForm("nowDir")
    if id == "" || nowDir == "" {
       context.JSON(http.StatusBadRequest, gin.H{"status": "fail"})
       return
    }
    t, _ := os.Getwd()
    err := os.Chdir(nowDir)
    if err != nil {
       context.JSON(http.StatusBadRequest, gin.H{"status": "PathError."})
       return
    }
    os.Chdir(t)
    //valid dir
    f.dir[id] = filepath.Dir(nowDir)
    f.DirList(context)
}

路由部分

route/init.go

package router

import (
    "github.com/aenjoy/BuilderX-go/global"
    "github.com/gin-gonic/gin"
    "github.com/sirupsen/logrus"
    "net/http"
)

var RouterGroupApp []CommonRouter

func InitRouter() {
    // 初始化路由
    global.Router = gin.Default()
    global.Router.MaxMultipartMemory = 50 << 20 //50 Gb
    global.Router.Use(func(c *gin.Context) {
       method := c.Request.Method
       origin := c.Request.Header.Get("Origin") //请求头部
       if origin != "" {
          //接收客户端发送的origin （重要！）
          //Access-Control-Allow-Origin是必须的,他的值要么是请求Origin字段的值,要么是一个*, 表示接受任意域名的请求
          c.Writer.Header().Set("Access-Control-Allow-Origin", origin)
          //服务器支持的所有跨域请求的方法
          c.Header("Access-Control-Allow-Methods", "POST, GET, PUT, DELETE,UPDATE")
          //允许跨域设置可以返回其他子段，可以自定义字段
          //该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。
          //如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。
          c.Header("Access-Control-Allow-Headers", "Authorization, Content-Length, X-CSRF-Token, Token, session, IOMAuth")
          // 允许浏览器（客户端）可以解析的头部 （重要）
          c.Header("Access-Control-Expose-Headers", "Content-Length, Access-Control-Allow-Origin, Access-Control-Allow-Headers")
          //设置缓存时间
          //该字段可选，用来指定本次预检请求的有效期，单位为秒。有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。
          c.Header("Access-Control-Max-Age", "172800")
          //允许客户端传递校验信息比如 cookie (重要)
          c.Header("Access-Control-Allow-Credentials", "true")
       }
       //允许类型校验
       if method == "OPTIONS" {
          c.JSON(http.StatusOK, "ok!")
       }

       defer func() {
          if err := recover(); err != nil {
             logrus.Panic("Panic info is: %v", err)
          }
       }()

       c.Next()
    })
    static()
    //路由组
    RouterGroupApp = commonGroups()
    PrivateGroup := global.Router.Group("/api/v1")
    for _, router := range RouterGroupApp {
       router.InitRouter(PrivateGroup)
    }
    //启动
    err := global.Router.Run(":" + global.WebPort)
    if err != nil {
       logrus.Errorln("Web Server start error, error Info is: ", err)
       logrus.Info("Web Server will not start, please check the configuration or error Info.")
       return
    }
}
func static() {
    global.Router.Static("/static", "./res")
    global.Router.Static("/assets", "./res")
    global.Router.Static("/index.html", "./index.html")
    global.Router.GET("/favicon.ico", func(context *gin.Context) {
       context.Redirect(302, "/static/favicon.ico")
    })
    global.Router.LoadHTMLGlob("res/html/*.html")
    global.Router.NoRoute(func(c *gin.Context) {
       c.HTML(http.StatusOK, "404.html", gin.H{
          "title": "404",
       })
    })
}

route/common.go

package router

import (
    "github.com/gin-gonic/gin"
)

type CommonRouter interface {
    InitRouter(Router *gin.RouterGroup)
}

func commonGroups() []CommonRouter {
    return []CommonRouter{
       &FileRouter{},
    }
}

route/ro_file.go

package router

import (
    v1 "github.com/aenjoy/BuilderX-go/app/api/v1"
    "github.com/gin-gonic/gin"
)

type FileRouter struct{}

func (s *FileRouter) InitRouter(Router *gin.RouterGroup) {
    fileRouter := Router.Group("file")
    fileApi := v1.ApiGroupApp.FileApi
    fileRouter.POST("/list", fileApi.DirList)
    fileRouter.POST("/select", fileApi.FileSelect)
    fileRouter.POST("/pwd", fileApi.GetNowDir)
    fileRouter.GET("/pwd", fileApi.GetNowDir)
    fileRouter.POST("/chdir", fileApi.Chdir)
}

完整代码请访问:https://github.com/aenjoy/BuilderX-go

golang小技巧:返回值简写,func (c *Struct)FunName与func (c Struct)FunName区别

2024-02-22T09:13:38.000Z

本文介绍golang中的返回值有一个语法糖,可以帮助我们减少代码量;

func loadConfigYaml(f string) (defaultConfig yamlConfig)

同时还介绍func (c *Struct)FunName与func (c Struct)FunName区别

golang返回值变量:

golang可以将欲返回的变量值写在函数末尾,并作为一个作用域为函数体内的变量

例如:

func loadConfigYaml(f string) (defaultConfig yamlConfig) {
    file, err := os.Open(f)
    if err != nil {
       fmt.Println("Error opening file:", err)
       return yamlConfig{}
    }
    defer file.Close()
    decoder := yaml.NewDecoder(file)
    err = decoder.Decode(&defaultConfig)
    return
}

此时,我们在函数的末尾使用return时可以不带变量名(返回的值).

这是常规写法,也是大多数编程语言的思维 :定义一个返回内容的变量,赋值后返回

func loadConfigYaml(f string) yamlConfig {
    var defaultConfig yamlConfig
    file, err := os.Open(f)
    if err != nil {
       fmt.Println("Error opening file:", err)
        return yamlConfig{}
    }
    defer file.Close()
    decoder := yaml.NewDecoder(file)
    err = decoder.Decode(&defaultConfig)
    return defaultConfig
}

func 后接的括号里带与不带的区别

在golang中,func 后接一个括号代表是这个结构体(接口)的方法,类似于C++的 classA::func(string a);

即func (b className)func(a string)<==>classA::func(string a);

其中golang代码中的b指代这个结构体对象,类似于Python中的self,c++/java的this

带*表示传递这个对象中的一切通过指针传递,最常用的特性就是可以修改值;不带*表示使用值传递方式,如果要修改结构体中属性的值,则不会生效.

package main

type myStruct struct {
  a string
}

func (s myStruct) setA1(a string) {
  s.a = a
}
func (s myStruct) readA1() {
  println(s.a)
}
func (s *myStruct) setA2(a string) {
  s.a = a
}
func (s *myStruct) readA2() {
  println(s.a)
}

func main() {
  s := myStruct{}
    s.a = "dddd"
  s.setA1("hello")
  s.readA1() //将不会输出 hello , 而是输出dddd
  s.setA2("hello2")
  s.readA2() //输出 hello2
  s.readA1() //输出 hello2
}

执行代码:

$ go run main.go
dddd
hello2
hello2

在go中,并不推荐同时使用func (s myStruct) 与func (s *myStruct),这两种选其一即可.

为你的服务器Nginx支持最新的quic

2024-01-09T05:12:15.000Z

使用最新的nginx主线版本1.25，给网站开启quic支持。

本文不探讨手动编译，而是使用主线安装直接启用quic特性

环境：Debian12+nginx1.25

HTTP 3/QUIC介绍

QUIC/HTTP3 (Quick UDP Internet Connections), 快速 UDP 互联网连接，由Google在2015年提出的SPDY v3演化而来的新协议，传统的HTTP协议是基于传输层TCP的协议，而QUIC是基于传输层UDP上的协议，可以定义成：HTTP3.0基于UDP的安全可靠的HTTP2.0协议。 QUIC是基于UDP协议的，与传统的HTTP1.1/HTTP2不兼容，当浏览器不支持quic/http3时，会自动尝试使用http2、http1.1连接。

HTTP/3 基于 QUIC 传输协议，该协议专门用于支持多路复用连接，并摆脱了对单个 TCP 连接的依赖。QUIC 使用 UDP 作为在客户端和服务器之间的数据包底层传输机制，并为HTTP 请求提供可靠连接。值得注意的是，从HTTP2起，包括HTTP3/QUIC ，都将 TLS作为必选项（即强制加密），如果站点不支持ssl/tls，那就只能回到http1.1了。

主要特性：

基于UDP减少了TCP三次握手及TLS握手时间
解决多路复用丢包时的线头阻塞问题
优化重传策略
流量控制
连接迁移

安装主线nginx1.25版本

由于各大发行版（截止2024年1月9日，我测试了archLinux，openSUSE，Fedora，Debian，ubuntu23.10）目前还没有将1.25合并进存储库，因此我们需要手动添加1.25版nginx源.

参考nginx: Linux packages

本机环境：Debian 12

其它发行版操作类似

安装先决依赖：

apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring

下载nginx官方签名

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

导入签名

gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

输出的内容应包含“573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62”

例如：

pub   rsa2048 2011-08-19 [SC] [expires: 2024-06-14]
      573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62
uid                      nginx signing key

如果不是，那么你需要重新下载并重新导入。

导入主线分支版本库：

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/mainline/debian `lsb_release -cs` nginx" \
    | sudo tee /etc/apt/sources.list.d/nginx.list

固定使用nginx官方的包：

echo -e "Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n" \
    | sudo tee /etc/apt/preferences.d/99nginx

（如果你已经安装了系统源带的nginx，请先卸载（你应该手动备份配置））

卸载系统自带的nginx

sudo apt remove nginx

安装nginx官方的nginx

sudo apt update
sudo apt install nginx

配置nginx.conf

注意：如果你从nginx1.24或更早的版本升级到1.25，应该注意几个重要变更，否则可能会因为nginx版本升级，配置部分选项弃用导致的error。

NGINX1.25重要变更

1.不再支持“http2”标记，已经默认ssl站点全部启用http2（该参数已弃用，但继续使用不会报错，只会报warning，你应该将站点中所有的http2参数移除）

listen 443 ssl http2；会出现警告

2.“ssl”参数完全丢弃，如果你的站点参数中有ssl参数，则会报error

如果有ssl on;则会报错

配置项

启用SSL：

由于http2、http3/quic强制加密，如果你的站点没有SSL支持，将不支持启用http2、http3/quic。

什么？你还没有ssl证书？你可以了解下acme.sh。

ssl_protocols  TLSv1.3; #启用TLS1.3加密（如果你考虑支持老旧浏览器和系统，则可以增加TLSv1.2，TLSv1.1）
      ssl_certificate /root/uhttpd.crt;#SSL证书
      ssl_certificate_key /root/uhttpd.key;#SSL密钥
      ssl_ecdh_curve secp384r1;#SSL加密算法
      ssl_stapling on;
      # Path of the file with Diffie-Hellman parameters for EDH ciphers.
      # TIP: Generate with: `sudo openssl dhparam -out /etc/nginx/dh2048.pem 2048`
      #ssl_dhparam /etc/ssl/nginx/dh2048.pem;
      ssl_dhparam /etc/nginx/dh2048.pem;#使用ssl_dhparam扩展，可以根据以上命令创建
      # Specifies that our cipher suits should be preferred over client ciphers.
      # Default is 'off'.
      ssl_prefer_server_ciphers on; 
      # Enables a shared SSL cache with size that can hold around 8000 sessions.
      # Default is 'none'.
      ssl_session_cache shared:SSL:2m;
      # Specifies a time during which a client may reuse the session parameters.
      # Default is '5m'.
      ssl_session_timeout 1h; 
      # Disable TLS session tickets (they are insecure). Default is 'on'.
      ssl_session_tickets off;
      ssl_early_data on; #开启 0-RTT的支持 quic部分特性

在全局段启用http3/quic支持：

在http{}内增加

quic_retry on;
      quic_gso on;
      http3 on;

在server{}段中有关quic的配置

增加单独的quic标记

listen 443 quic;
      listen [::]:443 quic;

当然，如果只有这样的配置，那么站点就是只支持quic访问。我们可以增加传统http2支持

listen 443 ssl;
      listen [::]:443 ssl;

这两端代码合在一起是可以的，不会报错。毕竟，quic监听的是443udp，ssl侦听的是443tcp。

此外，我们还要增加标头，向浏览器报告我们支持quic

在location中增加如下内容：

add_header Alt-Svc 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"';

这段代码的意思是，在443端口启用http3的以下草案支持：h3，h3-29,h3-q050,h3-q046,h3-q043,quic。

一段完整的示例：

server{
        #listen 80; #站点不支持传统http（可以设置一个默认监听80端口跳转至443）
        #listen [::]:80; 
        
        listen 443 quic;  #在IPv4/IPv6的443端口监听udp连接（quic/http3）
        listen [::]:443 quic;
        
        listen 443 ssl;  #在IPv4/IPv6的443端口监听传统httptcp连接（默认http2、如若客户端不支持则变为http1.1）
        listen [::]:443 ssl;
        
        server_name xxx.sample.com;
        location /{
        add_header Alt-Svc 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"';
                proxy_pass http://192.168.31.1;
        }
}

保存，退出，重启nginx服务器

浏览器测试

使用最新版edge/chrome 打开F12，在网络栏的协议可以看到，已经启用http3/quic

手机浏览器访问：（Chrome）

Quic站点的好处：

1.加速访问

2.过滤GFW的TCP-SNI阻断（GFW目前还没有识别http3站点的技术），可以在DNS配置正确的情况下直接打开诸如 www.v2ex.com 这类的，只被DNS污染和SNI打断但又支持QUIC的站点。

利用域前置技术绕过GFW的SNI阻断

2023-11-11T16:29:15.000Z

在某些特殊时期，我们的科学上网工具不太好使的时候，我们还有要经常上github找资源、浏览v2ex和查询维基百科的需求，我们可以通过绕过GFW的SNI阻断来避免一些简易网站访问难的问题。

支持的站点

维基百科
Pixiv（支持登录，注册暂不支持）
Steam社区
GitHub
Tumblr
Instagram
Quora
Google reCAPTCHA
reddit
APKMirror
vimeo
日本亚马逊
Microsoft OneDrive
Niconico（部分页面有问题，见#19）
BBC
Dropbox
日本时报
Kobo
Medium
Pinterest
TheTVDB
雅虎搜索
Imgur
MEGA
OpenAI API

完整列表https://github.com/URenko/Accesser/blob/master/accesser/pac

GFW的过滤规则

轻度污染级别

DNS污染：

我兔通过通知运营商、国内的DNS服务商（运营商DNS、公共DNS等）对指定的域名请求进行污染，使之查询不到一个正确的IP，从而使我们没法访问。

你可能说我们在电脑、路由器里设置国外的dns就能解决？NO，没用。

国外的DNS只会徒增你的查询时间，降低网络体验，而且污染问题得不到解决。因为dns查询所用的53端口已经被劫持了，所以你用国外dns和运营商dns是一样的（传统dns查询）。解决方法：使用国外、权威和加密的DNS查询。如使用DoT，DoH，DoQ等代替传统dns查询，解决污染。

解决方案：

部署、使用加密DNS服务器最简单的方法是在局域网内搭建一个加密DNS服务器的中转站，局域网下的其它设备依然使用传统dns查询，但是传统dns查询的ip地址指向的是局域网dns服务器。

一般我们使用 AdGuard Home

它的用法可参考这几篇文章：

使用 AdGuard Home 来守护自己的 DNS 查询

AdGuard Home 调整

AdGuard Home 中文指南 - TimochanのBlog

由于这种污染级别实在是太低了，我们绕过它也极其容易，目前已经很少单独使用了。往往是轻度污染级别+中度污染级别一起出现使用。

中度打断级别

如果你侥幸绕过了DNS污染，正确获取到了服务器的IP，GFW就拿你没办法了吗，你就可以名言正顺的访问被墙的网页？NO！只要我检测到你在访问黑名单页面，我一样可以Ban掉。

怎么发现我们在访问黑名单网站呢？

通过对请求头的host进行判断在不在白名单内的IP+黑名单的域名。

curl 172.67.3.188 -H “host:www.v2ex.com“

如果IP在白名单内（对应的域名肯定都在白名单），那当然皆大欢喜，全部放行。

如果是非黑白名单IP+非白名单域名，那就给你定期打断。如github.com的定时抽风。

如果是非黑白名单IP+黑名单域名，那就给你一直打断TLS握手，让你没办法完成TLS握手，重置连接，无法访问。

对于一般的网站，这种方法足够了。

如果是黑名单IP，那就丢进路由黑洞，下文会有解释。

SNI阻断：

SNI域名阻断（Server Name Indication Domain Blocking）是一种用于在网络上屏蔽特定网站的技术手段。SNI是Transport Layer Security（TLS）协议的一部分，它允许客户端在与服务器建立加密连接时传输所需访问的网站域名信息。SNI域名阻断利用这一特性，通过检查网络传输中的SNI字段，阻止用户访问特定的网站。

SNI域名阻断通常由网络管理员、政府或互联网服务提供商（ISP）实施，目的是限制或屏蔽特定网站的访问。这可以用于防止用户访问敏感内容、限制言论自由、打击非法网站或控制互联网使用等目的。然而，SNI域名阻断也引发了一些争议，因为它可能影响用户隐私、言论自由和互联网开放性。

HTTPS（更准确来讲是TLS）有一个扩展，使得在Client Hello阶段，浏览器会向服务器明文发送要访问网站的域名。而GFW根据这一原理对特定的SNI进行阻断，这就是俗称的SNI阻断。更多的可以去看：维基百科，看完秒懂什么是SNI - 知乎 (zhihu.com)

解决方案：域前置(Domain Fronting)代理技术。

就是利用有的服务器不验证SNI的这一特点，给GFW和服务器一个假的SNI进行前置代理。因为GFW没有私钥，只能通过SNI和IP判断你要访问的网站，而假的SNI就能欺骗GFW。但服务器本身有私钥，解开后，服务器是通过HTTP请求头判断你要访问哪个网站的。（但注意，特殊的比如虚拟主机、Cloudflare免费版等能在一个IP上部署多个证书的，是一定要SNI的，否则会出错。这种唯一的绕过办法就是ESNI，如果有空的话，以后再讲）因此可以通过这种方式绕过GFW的SNI阻断。

重度黑洞级别

GFW针对特定的IP段直接进行路由黑洞处理（BGP路由劫持的最高形式）。

因为 BGP 是基于互连网络真实表述它们拥有的 IP 地址这一事实，所以 BGP 劫持几乎是无法停止的。

路由劫持

什么是 BGP 劫持？-腾讯云开发者社区-腾讯云 (tencent.com)

路由黑洞

一条路由无论是静态还是动态，都需要关联到一个出接口，在众多的出接口中，有一种接口非常特殊，即Null（无效）接口，这种类型的接口只有一个编号0，类似（交换机、路由器）的出接口Interface g或e 0/0/0; Null0是系统保留的逻辑接口，当转发网络设备在转发某些数据包时，如果使用出接口为Null0的路由，那么这些报文会被直接丢弃，就像直接丢进一个黑洞里，永远无法到达，因此出接口为Null0的路由被称为黑洞路由。

到了这一级别的最强黑名单，黑上黑级别的，那甚至不需要污染域名和sni了，根本连不上！（dns污染也经常是将被污染的域名直接指向这一类IP以达到污染的目的）。当然，这种方法封禁是最彻底的，成本也是最高的。需要在路由器上设置跳过路由的自动学习，手动添加黑名单IP段、出口。

解决方案

使用科学上网工具代理（代理的IP需要不在黑名单内，且可以访问目标IP）

使用工具绕过SNI阻断

下载和运行URenko/Accesser:

URenko/Accesser: 🌏一个解决SNI RST导致维基百科、Pixiv等站点无法访问的工具 | A tool for solving SNI RST (github.com)

需要先安装Python3.10及以上更高版本

pip3 install -U accesser[doh,doq]

如果我们不需要 DNS-over-HTTPS 和 DNS-over-QUIC，则可以不用带[doh,doq]。

然后通过如下命令启动：

accesser

对于Windows系统，默认情况下（没有指定--notsetproxy）会设置PAC代理为http://localhost:7654/pac/?t=<随机数>，如果没有可以手动设置。

此外，对于Windows系统，默认情况下（没有指定--notimportca）会自动导入证书至系统（第一次运行命令会弹框询问，选择是），如果没有可以手动导入，请看这里。

支持的站点列表：

编辑配置文件

编辑命令执行路径下的config.toml

我们一般只需要修改DNS部分即可，当然，如果你没有部署无污染的DNS服务器，或者说它预置的DNS服务器你（有其一）都可以访问也是不需要修改的。

nameserver = [
  #"https://185.222.222.222/dns-query",# https://host|IP[:port]/path # DNS-over-HTTPS (DoH)
  #"https://45.11.45.11/dns-query",
  #"https://149.112.112.112/dns-query",
  #"https://149.112.112.10/dns-query",
  #"tls://149.112.112.112",            # tls://host|IP[:port]  # DNS-overTLS (DoT)
  #"tls://149.112.112.10",
  #"tls://dot.sb",
  # "quic://dns.adguard-dns.com",     # quic://host|IP[:port] # DNS-over-QUIC (DoQ)
  "192.168.31.53"                       # host|IP[:port]        # 传统 UDP DNS | traditional UDP DNS
]

因为我的内网有一台安全的DNS服务器，IP是192.168.31.53，所以这里我就把其它的dns全部注释了，使用内网dns服务器加快查询速度

保存设置，重启服务 Enjoy it！

附：在手机上使用：

确保手机与服务器同属于一个局域网。

编辑命令执行路径下的config.toml

找到[server]的address，改为

address = “0.0.0.0”

将pac_host = “127.0.0.1”设置为代理的局域网ip地址。

在手机上的WiFi进行如下设置：

效果图

axios发送简单POST请求，Gin简单处理

2023-11-01T16:51:26.000Z

自己在写一个项目，目前遇到的问题是：根据csdn和axios官网的说明，发送简单POST请求的时候，后端可能没办法正确处理数据，浅浅记录一下解决方案。

传递类型对比

即key:value 键值对，不使用JSON封装

类似于get请求，可以很简单的从命令行中看出key:value

我们进行下对比

curl发送对比

1.简单POST

curl http://localhost:8088/api/auth/signin -X POST -d ‘username=admin&password=passwords’

2.简单GET

curl “http://localhost:8088/api/auth/signin?username=admin&password=passwords“

3.JSON型POST

curl -X POST -H “Content-Type: application/json” http://localhost:8088/api/auth/signin -d ‘{“username”:”admin”,”password”:”passwords”}’

接收端对比

1.处理简单POST请求

func method(context *gin.Context) {
  if global.IsCookieAuthValid(context) { //防止反复登录授权
    //context.String(http.StatusOK, "ok")
    context.String(http.StatusOK, "Verified")
    return
  }
  //println(context.Request.Body)
  un := context.PostForm("username")
  pw := context.PostForm("password")
    //Code
}

2.处理简单GET请求

func method(context *gin.Context) {
  if global.IsCookieAuthValid(context) { //防止反复登录授权
    //context.String(http.StatusOK, "ok")
    context.Redirect(302, "/dashboard")
    return
  }
  un := context.DefaultQuery("username", "")
  pw := context.DefaultQuery("password", "")
  //Code
}

可以发现简单方法获取参数都是一行代码的事，比较简单

而

3.JSON数据处理…

func method(context *gin.Context) {
  if global.IsCookieAuthValid(context) { //防止反复登录授权
    //context.String(http.StatusOK, "ok")
    context.Redirect(302, "/dashboard")
    return
  }    
  json := make(map[string]interface{}) //注意该结构接受的内容
  context.BindJSON(&json)
    un := json["username"]
  pw := json["password"]
    //Code
   
}

好吧也还算简单，但是我们想实现简单的数据传递，而根据axios官网的数据传递方法：

axios({
  method: 'post',
  url: '/user/12345',
  data: {
    firstName: 'Fred',
    lastName: 'Flintstone'
  }
});

这种传递方法会使传递的值后端想进行简单处理是不行的，后端没办法获取到数据，或者直接线程panic了，返回500。

解决

我们需要使用标准的JavaScript方法

login(formName) {
      console.log(formName)
      var params = new URLSearchParams();
      params.append('username', formName.name);//标准简单请求参数
      params.append('password', formName.password);//标准简单请求参数
      axios.post('/api/api/auth/signin', params).then(response => {
        if (response.status == 200) {
          goRouter({ name: 'Dashboard' });
          //ok
        } else if (response.status == 401) {
          ElMessageBox.alert("用户名或密码错误", "登录失败", {})
        }
      }, error => {
        console.log('E', error.message)
      })
    }

问题解决，后端可以按（1.）正常获取数据。

或者转换为标准json，按（3.）处理

解决前端Vue3+vite+axios+cookie跨域报错问题后端Go+gin

2023-10-29T09:50:57.000Z

自己在写一个项目，目前遇到了问题：前端需要向后端执行ajax请求获取数据，需要传递cookie。如果使用默认的代码不进行配置则会出现跨域问题cors报错，本文将解决问题.

前端(node.js+Vite)：http://localhost:5173

后端(golang + gin)：http://localhost:8088/

问题出现

前端需要向后端请求数据/api/devices/snlspjrnzxcevyfk/info,后端通过前端传递过来的cookie进行身份识别，授权成功返回200，JSON数据, 失败返回401未授权或404.

当我们使用默认参数不做配置时，直接请求会被拦截，进而无法获取数据。参考网上的教程在解决请求跨域后，又少有解决cookie传递的，参考几篇资料后，结合本人项目，目前问题已解决。

cookie:IOMAuth

解决措施

前端部分

vite.config.js

export default defineConfig({
  plugins: [
    vue(),
    AutoImport({
      resolvers: [ElementPlusResolver()],
    }),
    Components({
      resolvers: [ElementPlusResolver()],
    }),
  ],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  },
  server: {
    host: '0.0.0.0',
    //port: 8088,
    proxy: {
      '/api': {
        // 后台地址
        target: 'http://localhost:8088/',
        changeOrigin: true,
        secure: false,
        ws: true,
        followRedirects: true, //cookie自动跳转传递
        rewrite: path => path.replace(/^\/api/, ''),
        onProxyReq(proxyReq, req, res) {
          originHost = req.headers['x-forwarded-for']
          const cookie = req.headers['cookie']
          if (cookie) {
            proxyReq.setHeader('cookie', cookie)
          }
        },
        onProxyRes(proxyRes, req, res) {
          if (proxyRes.headers['set-cookie']) {
            // cookie 传递重点
            proxyRes.headers['Access-Control-Allow-Credentials'] = 'true';
          }
        }

      },
    }
  },
})

axios配置 axiosInstance.js

import axios from 'axios'

axios.defaults.withCredentials = true; //重点

const API = axios.create({
  baseURL:'http://localhost:8088', 
  timeout: 2000,                   
  withCredentials:true //重点 这参数可以放上边，也可以放里面
})

export default API

后端

go gin路由设置

func RouterInit() {
  global.Router = gin.Default()
  global.Router.Use(func(c *gin.Context) {
    method := c.Request.Method
    origin := c.Request.Header.Get("Origin") //请求头部
    if origin != "" {
      //接收客户端发送的origin （重要！）
      //Access-Control-Allow-Origin是必须的,他的值要么是请求Origin字段的值,要么是一个*, 表示接受任意域名的请求
      c.Writer.Header().Set("Access-Control-Allow-Origin", origin) //设置为*会报错
      //服务器支持的所有跨域请求的方法
      c.Header("Access-Control-Allow-Methods", "POST, GET, OPTIONS, PUT, DELETE,UPDATE")
      //允许跨域设置可以返回其他子段，可以自定义字段
      //该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。
      //如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。
      c.Header("Access-Control-Allow-Headers", "Authorization, Content-Length, X-CSRF-Token, Token, session, IOMAuth")
      // 允许浏览器（客户端）可以解析的头部 （重要）
      c.Header("Access-Control-Expose-Headers", "Content-Length, Access-Control-Allow-Origin, Access-Control-Allow-Headers")
      //设置缓存时间
      //该字段可选，用来指定本次预检请求的有效期，单位为秒。有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。
      c.Header("Access-Control-Max-Age", "172800")
      //允许客户端传递校验信息比如 cookie (重要)
      c.Header("Access-Control-Allow-Credentials", "true")
    }
    //允许类型校验
    if method == "OPTIONS" {
      c.JSON(http.StatusOK, "ok!")
    }

    defer func() {
      if err := recover(); err != nil {
        logrus.Panic("Panic info is: %v", err)
      }
    }()
    c.Next()
  })
  regRouter()
  global.Router.Run(":" + global.WebPort)
}

rootfs版CatWrt(OpenWrt)启动镜像定制

2023-10-17T09:38:16.000Z

rootfs版CatWrt(OpenWrt)启动镜像的定制

包括镜像扩容，源修改，软件包定制

熟悉软路由的朋友们都知道我们在下载固件(镜像)的时候，一般都是选择带有squashfs字样的镜像，然而往往还有另一个神秘的选择- rootfs。它却很少被人们提起，它的一般用途是拿来做docker的镜像，但是我们还可以拿做另一件事，OpenWrt的系统分区制作。

我们平时接触到的OpenWrt的根文件系统一般都是 squashfs，这个文件系统给我们带来一定的安全感，我们在软路由上装插件、修改配置导致OpenWrt出现异常时可以通过清除挂载的文件修改操作来还原初始状态；在硬路由上，squashfs+配置分区的外挂载使我们可以轻易的通过外置按键还原对路由器的更改。虽然squashfs很好，但是它也阻止了我们直接往系统分区增添、删除、修改我们想要的文件、配置和程序。

想要解决系统分区不能修改的解决方法很简单，也是OpenWrt系默认的操作，

第一种方式：建立一个overlay分区，将所有修改后的文件存放于此，使用挂载的方式直接覆盖系统分区，实现修改，这种操作类似建立一个镜像，通过对镜像的修改而改动系统。

当我们清空/overlay分区的时候，便实现了对系统分区修改的还原。

第二种方式，就是将系统分区的squashfs文件系统中的文件移动到其它可写的文件系统，如f2fs，ext4，xfs等，并建立启动信息启动系统。OpenWrtx86可以在系统->挂载点->/->修改，通过拷贝/下的文件到新的可写路径，并建立启动项来实现对/的可读写，但是这种方式对新手并不友好，甚至一些老手都在此栽过跟头。

除此之外，我们还有第三种方式：使用Linux kernel+rootfs+grub(bootlodaer)制作一个可启动的Linux系统，这种方式建立的系统，根路径在root权限下是可读写的，本文将介绍此种方法。

实现的原理：同Linux启动过程

第一步：准备阶段

准备内核(kernel)、引导(grub))和rootfs。

启动引导(bootlodaer)启动引导程序(grub），引导程序启动内核(kernel)，内核初始化(mount and init)rootfs，启动rootfs里的进程。

下载启动分区 EFI引导的传统BIOS引导方式

由于一般的OpenWrt都不提供单独的内核和引导，我们只能下载我们要制作的目标版本镜像来做底包修改。选择适当引导方式的底包制作镜像将可以很方便的在对应目标的系统启动openwrt系统。

下载rootfs 链接一般rootfs都是以 xxx-rootfs.tar.gz结尾

wget https://github.com/miaoermua/CatWrt/releases/download/v23.8/CatWrt.v23.8.x86_64-squashfs-combined-efi.img

wget https://github.com/miaoermua/CatWrt/releases/download/v23.8/CatWrt.v23.8.x86_64-rootfs.tar.gz

准备多分区挂载工具 kpartx

Kpartx is a tool that creating device mappings for partitions.

Debian/Ubuntu:

apt install kpartx -y

alpineLinux:

apk add kpartx

CentOS/Fedora/OpenRuler:

yum install kpartx -y

第二步：镜像处理

1.使用cfdisk(fdisk)工具删掉镜像里的系统分区

cfdisk CatWrt.v23.8.x86_64-squashfs-combined-efi.img

完成Delete后，选择Write，输入yes，然后Quit退出

等待同步完成

2.使用dd命令给镜像增加空间

dd if=/dev/zero bs=1M count=256 >>CatWrt.v23.8.x86_64-squashfs-combined-efi.img

bs参数数字+单位 count参数数量 >> 代表追加

意思是从/dev/zero中取出1M*256的容量追加到镜像中（扩容256M）

我们可以根据需要给镜像扩容任意大小

比如 dd if=/dev/zero bs=1G count=5 >>CatWrt.v23.8.x86_64-squashfs-combined-efi.img 代表扩容5G

3.使用cfdisk给扩容后的镜像尾建立分区

cfdisk CatWrt.v23.8.x86_64-squashfs-combined-efi.img

选择Free space

接着，会询问我们要创建的分区大小，这里直接回车就行

完成后选择Write，yes，Quit

fdisk操作类似

4.使用kpartx挂载镜像为硬盘回环设备

losetup /dev/loop7 CatWrt.v23.8.x86_64-squashfs-combined-efi.img

如果/dev/loop7被占用就换其它的loop0 loop1什么的

查看映射的分区表

kpartx -av /dev/loop7

其中 loop7p2就是我们的目标

格式化该分区

mkfs.ext4 /dev/mapper/loop7p2

!CatWrt内核支持f2fs，格式化成f2fs格式也可以(f2fs适合将镜像刷写在闪存存储介质上如U盘，移动硬盘SSD,固态硬盘(包括nvme固态，m2SATA，SATASSD等)) 命令mkfs.f2fs /dev/mapper/loop7p2

5.查看分区UUID （在格式化之后分区UUID会改变，因而需要先格式化再查看）

cfdisk /dev/loop7

分区UUID用于在后续引导系统

6.建立一个临时挂载路径并挂载系统分区

mkdir /mnt/mount
mount /dev/mapper/loop7p2 /mnt/mount

7.解压rootfs

tar -xzvf CatWrt.v23.8.x86_64-rootfs.tar.gz -C /mnt/mount
cd /mnt/mount
ls

可以看到我们已经制作完成启动镜像了

第七步结束。如果不需要修改系统，请转到第八步

此时这个镜像的系统分区就已经处理好了。当然，我们还可以优化一下镜像

chroot /mnt/mount

编辑源，更新部分软件等 (CatWrt具有)

bash-5.2# vim /etc/opkg/distfeeds.conf

换腾讯源

src/gz openwrt_core https://mirrors.cloud.tencent.com/lede/snapshots/targets/x86/64/packages
src/gz openwrt_base https://mirrors.cloud.tencent.com/lede/snapshots/packages/x86_64/base
src/gz openwrt_luci https://mirrors.cloud.tencent.com/lede/releases/18.06.9/packages/x86_64/luci
src/gz openwrt_packages https://mirrors.cloud.tencent.com/lede/snapshots/packages/x86_64/packages
src/gz openwrt_routing https://mirrors.cloud.tencent.com/lede/snapshots/packages/x86_64/routing
src/gz openwrt_telephony https://mirrors.cloud.tencent.com/lede/snapshots/packages/x86_64/telephony

bash-5.2# mkdir /var/lock -p
bash-5.2# opkg update

安装程序包等…（可看文末）

退出

bash-5.2# exit

exit

8.卸载系统分区

root@pve:~# umount /mnt/mount

9.挂载boot分区，修改启动项

mount /dev/mapper/loop7p1 /mnt/mount

ls /mnt/mount

root@pve:~/OpenWrt# cd /mnt/mount/boot/grub/

root@pve:/mnt/mount/boot/grub# ls

boot.img core.img grub.cfg

root@pve:/mnt/mount/boot/grub# vim grub.cfg

10.将前面记录的UUID填入(替换)到PARTUUID中

11.保存文件，卸载分区

umount /mnt/mount

12.卸载回环设备

root@pve:~# losetup -d /dev/loop7

完成

将新的镜像（CatWrt.v23.8.x86_64-squashfs-combined-efi.img）刷入启动盘，启动。（PVE添加硬盘）

这个时候应该改名叫CatWrt.v23.8.x86_64-6G-ext4-rootfs-efi.img才对

Enjoy Image！

截图

以下是10G版本扩容的截图

10G扩容版的下载链接：Here

优化

虚拟化环境下卸载amdGPU、IntelGPU驱动

opkg remove amdgpu-firmware

opkg remove i915-firmware

更新curl

opkg upgrade libcurl4 curl

可安全更新的程序列表(等)

xray-core v2ray-core v2ray-geoip fdisk blkid mount-utils libopenssl-conf node libfdisk1 samba4-libs cfdisk parted samba4-server tailscale ethtool libblkid1 lsblk libmount1 tailscaled zerotier libopenssl3 terminfo

不建议更新的 :kmod-xxx uci docker(d) dnsmasq-full containerd strongswan等

安装apk包管理器&&neofetch

*显示 Linux 系统信息和发行版图标

opkg install apk alpine-keys alpine-repositories
apk update --allow-untrusted
apk add neofetch --allow-untrusted
neofetch

使用apk包管理器，我们可以安装一些其它东西，比如java，可以搭建mc服务器。安装装glibc支持运行其它程序，安装完整开发环境、做远程测试服务器等…

CatWrt扩展

CatWrt 扩展应用安装，全系生态通用 - 喵二の小博客 (miaoer.xyz)

PVE部署CatWrt(OpenWrt)

2023-09-21T09:17:57.000Z

在PVE下部署安装和配置CatWrt，实现软路由的虚拟化。

CatWrt是什么？

CatWrt 是基于开源的 Lean LEDE 仓库编译的 OpenWrt 发行版，LEDE相较于OpenWRT官方添加了更多符合中国用户的插件，其更符合中国用户的操作习惯。

CatWrt是由饱受好评的LEDE源代码直接*编译而来，其提供了相似于LEDE的硬路由私有化付费版本QWRT的体验，同时提供了较为完善的社区支持和多种硬件及架构的支持。

项目地址：

GitHub - miaoermua/CatWrt: 🌠 客制化 OpenWrt 智能网关

官网地址：CatWrt.v23.8 超强性能超稳固件，支持多款热门 mt798x 路由 - 喵二の小博客 (miaoer.xyz)

而但免费的技术支持*和更新。

在PVE上安装OpenWrt

1.创建虚拟机

此处选择不使用任何介质，客户机操作系统选择Linux，版本默认

这里的BIOS选项根据自己的喜好选择默认(SeaBIOS)，或是OVMF(UEFI)，关系到后面添加镜像时选择的版本。

如果选择UEFI，不勾选添加EFI磁盘。显卡建议保持默认或者标准VGA,VMware兼容

此处，将磁盘删除。

此处，根据自己电脑的情况设置CPU核心数，类别可以保持默认，也可以根据自己的情况选择。为了提升性能，这里选择host，并设置了CPU权重以提升调度积极性->提升性能。

内存设置：如果不跑代理类软件，仅用于拨号，设置512MB，768MB即可，如果需要跑代理类软件，建议设置更高，如1024.如果需要跑容器（docker），建议设置2048或更高。

勾选Ballooning设备将使内存变更为动态分配，如果需要使用监控内存类的软件(如htop，pcdn内存检测)，则不建议勾选。部分软件会因为此无法判断内存大小而出现内存泄露。

网络设置：我们知道，非(单臂、庞)路由器是有两类接口的，一类WAN，一类LAN。

而CatWrt的第一个接口默认设置为LAN接口，第二个接口默认为WAN，因此在此处应谨慎操作，避免因接口顺序设置出错导致前期配置困难。

在完成配置后，添加第二个网口。

找到刚刚创建的设备，点击之，选择硬件，添加->网络设备->选择另一接口(WAN)

2.导入CatWrt硬盘

大部分的OpenWrtx86都提供.img格式磁盘镜像或相应的打包压缩文件，这里需要对应系统夹选择BIOS或EFI而选择相应系统。

比如，我前面选择的是OVMF(EFI)则我应该下载efi的镜像，选择SeaBIOS的，则因下载不带EFI的镜像。

下载地址：Releases · miaoermua/CatWrt (github.com)

使用ssh连接PVE主机，或是在网页的Shell中

下载镜像并导入虚拟磁盘。

root@pve:~# wget https://github.com/miaoermua/CatWrt/releases/download/v23.8/CatWrt.v23.8.x86_64-squashfs-combined.img
root@pve:~# qm importdisk 104 ./CatWrt.v23.8.x86_64-squashfs-combined.img local-lvm

qm importdisk是命令

104是虚拟机ID

./CatWrt.v23.8.x86_64-squashfs-combined.img是镜像路径。

如果是通过浏览器上传的，则在/var/lib/vz/template/iso/xxx.img下。

local-lvm是存储位置，选用本地存储

导入成功后显示successful

Successfully imported disk as 'unused0:local-lvm:vm-104-disk-0'
root@pve:~#

接着，按如下步骤导入磁盘

完成后启动。

使用网线通过与vmbr0桥接的交换机相连，在浏览器输入192.168.1.4进入，进行后续拨号，DHCP，更高网口信息等配置。

用户名root，密码password.

1)*.CatWrt相较于LEDE有一部分软件包的修改和配置的修改

2)*.基础问题提供免费技术支持，特殊问题除外

Proxmox Virtual Environment 7.x升级8.0教程

2023-06-16T14:16:14.000Z

Debian 12已经发布了，紧跟Debian发布节奏的PVE也随之发布了8.0（Beta）[目前已经正式版了2023-6-24 15:30:36]。本文将展示PVE8的一些新特性和如何升级至最新版本。

主要的更新内容

1.从5.15.x更新到Linux 6.2.16的新内核

PVE8(Beta)默认搭载Linux6.2.16新内核，只有待下一个LinuxKernelLTS时才会在正式版中搭载长期服务分支内核。

6.2.x内核相较于5.15.x内核的主要变化

1.添加更多设备支持：优化Intel13代等。几乎支持至2023-06的所有硬件
2.内核支持Rust
3.Btrfs，EXT4文件系统性能改进

PVE7.4->8

主要变化

1.自动优化Ceph集群配置
2.完善笔记对markdown的支持
3.手机访问管理页面UI优化
4.QEMU8

通过包管理器更新到最新版本

首先，通过ssh或者在网页终端输入命令，将PVE7.x更新到7.4.x最新版本

apt update
apt dist-upgrade

接着，运行

pve7to8 --full

检查有没有什么不兼容的部分（主要是各种软件包）

如果输出的内容包含FAILURES: 0，则可以更新，否则，你可以根据提示排障。

然后，在终端执行以下命令，切换到新的存储库

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list

使用ls命令查看/etc/apt/sources.list.d/路径的各种文件，将里面的其它版本库文件一同切换到新版本。

root@pve:/etc/apt/sources.list.d# ls
docker.list  pve-enterprise.list  pve-no-subscription.list
root@pve:/etc/apt/sources.list.d# sed -i 's/bullseye/bookworm/g' docker.list
root@pve:/etc/apt/sources.list.d# sed -i 's/bullseye/bookworm/g' pve-no-subscription.list

如果不需要使用PVE8的测试版，以下切换分支内容可以忽略（2023-6-24 15:33:37）

由于目前PVE8还是测试版我们还必须将PVE版本库分支切换为测试分支。

（pve-no-subscription为我的PVE包存储库仓库文件，可能和你的不一样）

sed -i 's/pve-no-subscription/pvetest/g' pve-no-subscription.list

然后，更新包存储器和系统并重启

apt update
apt full-upgrade -y
reboot

重启后，你将会在左上角看到PVE8.

ProxmoxVE 7.x 换源及更新系统内核以提升IntelN5105机器的整体稳定性

2023-05-06T17:10:39.000Z

换源加快PVE更新/下载包速度，更新内核和Intel微码提升天坑N5105工控机跑PVE虚拟机的稳定性

康耐信N5105 0x0步进第一版i225-v3

本文阅读约12分钟。

本文最后更新于2023-5-8 23:26:13 版本v2。

一.N5105机器自身问题带来的噩梦

我手上有两台N5105工控机，一台是康耐信的，一台是畅网的。

前者用来跑虚拟化，简直是噩梦，后者裸机单跑CatWrt(OpenWrt)，两台设备都是第一版N5105设备。如果你不使用虚拟化技术，那么本文对你参考意义不大。

说说我2022年10月左右玩虚拟化遇到的问题吧

1.Windows Server 2022：网卡直通失败

2.PVE异常

后来，实在忍受不了N5105的虚拟化问题，在网上看到大家都抱怨N5105虚拟化稳定性后，我选择了单跑了近半年的OpenWrt。直至看了网友们说的，新版本固件软件都优化了，遂于五一节重新搞起了虚拟化，确实坑变少了许多。最核心的解决方案还是更换硬件，如果不能更换，那用软件精修一下毛坯房也不是不行(

2023-5-8 23:19:37 更新：目前所有的虚拟机已经稳定运行四天，PCDN也保持了四天在线的记录。

N5105虚拟化的问题

看了网上很多关于IntelN5105虚拟化踩坑的帖子，无外乎就是这两点：

虚拟机死机，PCIe设备直通失败

目前给出的回复大致都是这样的

第一版N5105工控机存在缺陷（他们往往配置的都是i225-v3网卡，CPU步进0x0），如果是第一代，还是放弃直通吧，真没办法(

问题列表：
1.虚拟机频繁死机，重启
2.Host死机，未响应
3.网卡直通错乱（i226一般没这个问题）
4.无网络
5.管理页面打不开
6.虚拟机无法重启，只能关闭PVE重新启动设备。

在没有更新系统前，我的OpenWrt虚拟机一天死机一次，网心云x86几个小时就死机一次，更新后两者都已经稳定运行两天多了（5-5到5-7）

第三版及之后的，由于使用了更新的BIOS固件，更新的CPU，以及改善的i226，解决了很多问题。据chiphell论坛网友们的评论，基本上解决了N5105虚拟化死机和直通异常的问题。

查看自己的硬件在不在天坑里

最简单的，在你购买的渠道询问：这是第几版的N5105工控机如果卖家回答你：第一版的

那么，恭喜你！中奖了！早期天坑版本。

或者是查看商品信息，一般会写着网卡型号：如果是i255，一般是第一版的；i226一般是较新的，但不好判断，主要还是得手动查看。

一般来说，只有第一版的N5105是0x0CPU步进的，非常容易辨识。

在Linux终端里输入如下命令

cat /proc/cpuinfo | grep stepping

如果输出的有

stepping        : 0

那么，恭喜你！中奖了！早期天坑版本。

天坑们往往会携带着又一天坑网卡：I225-V (rev 03)

在Linux终端里输入如下命令

lspci | grep "Ethernet controller"

如果输出的有

03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)
05:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)
06:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)

那么，恭喜你！中奖了！该网卡不适合虚拟机直通，不过，可以通过创建网桥/半虚拟化方式来使用。

（曲线救国方案：不支持模拟mac设备，不能修改mac地址，不支持在系统内创建桥接）

总而言之，查看是不是第一版的天坑版本有两种有效的方法：查看CPU步进，询问卖家。

二.更新PVE以填部分坑

PVE 是什么

据 PVE 的官网介绍，PVE 是Proxmox Virtual Environment 的缩写，是一个完整的开源服务器管理平台，用于企业虚拟化。它将 KVM 管理程序和 Linux 容器 (LXC)、软件定义的存储和网络功能紧密集成在一个平台上。借助基于 Web 的集成用户界面，您可以轻松管理 VM 和容器、集群的高可用性或集成的灾难恢复工具。

它是基于Debian11的系统，因此，所有的包管理操作同Debian一致，可玩性也十分强大。

PVE下载与安装：

网上教程较多，本文不再赘述

在新版的PVE内核中（推荐5.17+），优化了N5105的整体稳定性和核显稳定性，更好用了。

换源

一、更换阿里云的源

在终端中输入

vi /etc/apt/sources.list

将里面的内容全部替换为：（换成其它源也可以）

deb http://mirrors.aliyun.com/debian/ bullseye main non-free contrib`

deb-src http://mirrors.aliyun.com/debian/ bullseye main non-free contrib

deb http://mirrors.aliyun.com/debian-security/ bullseye-security main

deb-src http://mirrors.aliyun.com/debian-security/ bullseye-security main

deb http://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib

deb-src http://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib

deb http://mirrors.aliyun.com/debian/ bullseye-backports main non-free contrib

deb-src http://mirrors.aliyun.com/debian/ bullseye-backports main non-free contrib

二、去除企业版源并增加社区源

在终端中输入

cd /etc/apt/sources.list.d
vi pve-enterprise.list

注释掉：（增加#号）

找到对应行，输入i，然后注释

#deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise

按ESC -> :wq 退出

接着：

touch pve-no-subscription.list
vi pve-no-subscription.list

然后输入i ->

deb https://mirrors.tuna.tsinghua.edu.cn/proxmox/debian/pve bullseye pve-no-subscription

ESC -> :wq 退出

三、清理、更新系统

使用下面命令清理系统冗余并更新软件包列表

apt clean 
apt autoclean 
apt autoremove --purge
apt update

注释掉5.15内核，否则在全部更新的时候会更新5.15版本

apt-mark hold pve-kernel-5.15

安装最新内核及更新系统：

apt install pve-kernel-6.2.11-1-pve -y
#截至当前发文，最新版本内核已经更新到6.2.11了，而我的是两天前安装的6.2.9
apt dist-upgrade -y

安装/更新Intel微码

apt install intel-microcode -y

接着输入reboot命令重启系统等待微码更新和内核启动即可。

重启后使用uname -a查看内核信息

root@pve:~# uname -a
Linux pve 6.2.9-1-pve #1 SMP PREEMPT_DYNAMIC PVE 6.2.9-1 (2023-03-31T10:48Z) x86_64 GNU/Linux

三、PVE虚拟机注意事项（对于第一版）

本段是根据个人所遇到的情况及相应的处理方案，不一定适用于每个人。

由于我购置的康耐信N5105 r86s工控机是四网口的，可以通过单独为PVE准备一个WAN口解决PVE内无法上网的问题，还可以为此创建docker的macvlan网络。双网口可以参考双网口的文章。

个人网络情况

网口1 enp3s0：接上游网络设备(光猫拨号设备/另一个网关) 已创建桥接（相当于虚拟机的WAN）

网口2 enp4s0：接路由器（AP及下游网络设备）已创建桥接 （为虚拟化路由器系统（CatWrt）准备的LAN）

网口3 enp5s0：接上游网络设备（用于做管理口和PVE上网的网口相当于PVE的WAN）

网口4 闲置

1.使用半虚拟化代替硬件直通

由于第一版N5105及其i225网卡的缺陷，直通将可能导致虚拟机内掉网卡，掉速和拔插网线死机，虚拟机外（Host）网口错乱等问题，故不宜选用此方案。

但我们总得解决设备的网卡需求，因此，我们选用半虚拟化方案。

首先，在数据中心->pve->系统->网络->创建->Linux Bridge

我为我的网络创建了两个bridge，分别对应WAN(vmbr0,enp3s0)和LAN(vmbr1,enp4s0)

名称填自己喜欢的，桥接端口自己选择网口，勾选自动启动

注意：在创建完网络设备和设置网关等信息后需要点击应用配置以使设置生效

在虚拟机上，添加网络设备

选择自己刚刚添加的设备，模型选择 VirtIO(半虚拟化) 这对稳定性非常重要！

防火墙选项：如果没有在PVE下管理流量的需求，可以不勾选。

2.为PVE配置一个单独的WAN口

为什么需要为PVE单独创建一个WAN口而不复用vmbr0呢？

问题1：PVE无法上网

如果在没有创建使用vmbr0的虚拟机前，当然是没有问题的，但当我们创建虚拟机后，就会遇到同网上一样的问题：

PVE Host无法上网：网关，IP设置正确也无效

如果PVE_WAN复用的是LAN（OpenWrt的LAN）

有可能出现以下两种错误：
1 Temporary failure in name resolution
直接报dns的错误
2 failed: Network is unreachable 或Destination Host Unreachable

参考CSDN文章：Here

如果PVE_WAN复用的是WAN（vmbr0）,参考下文。

问题2：无法在网卡上再创建桥接网络设备（vlan，macvlan）

vmbr0，vmbr1 对应enp3s0,enp4s0

假如需要创建多个虚拟WAN，那么在如上（vmbr0，vmbr1 ，enp3s0,enp4s0）设备无法创建虚拟的VLAN设备以达到桥接创建虚拟网口的目的，包括docker的macvlan，当我们指定这些网络设备时会提示设备繁忙。

比如

docker network create -d macvlan --subnet=192.168.31.0/24 --gateway=192.168.31.1 -o parent=enp3s0 test

会提示设备繁忙无法创建（或者创建成功，但我们在添加容器时提示繁忙）。

创建WAN的方法：

有两种途径创建WAN。

1.使用PVE的Web图形化页面创建WAN口

在数据中心->pve->系统->网络，选择一个未桥接的接口，设置静态IP信息。（网关，IP地址，子网长度）

然后点击应用配置

2.在终端中配置（推荐动手能力高的）

输入命令

vi /etc/network/interfaces

手动配置网卡信息。

在enp5s0区段下修改如下信息：

auto enp5s0
iface enp5s0 inet static
        address 192.168.31.41/24
        gateway 192.168.31.1

重启网络

service networking restart

配置路由、DNS信息

如果不执行这一步，你会发现PVE已经出现在了192.168.31.1/24网段了，即已经连接上路由器了，但依然无法访问外网。这是因为路由信息异常导致的，需要单独设置默认网卡和默认路由。

设置enp5s0为默认路由

ip route add default via 192.168.100.1 dev enp5s50
#或
route add default gw 192.168.31.1 enp5s0

查看配置结果：

ip route show

如果出现

default via 192.168.31.1 dev enp5s0 proto kernel onlink

即成功

root@pve:~# ip route show
default via 192.168.31.1 dev enp5s0 proto kernel onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.31.0/24 dev enp5s0 proto kernel scope link src 192.168.31.41

接着配置dns

vi /etc/resolv.conf

添加dns

search com
nameserver 192.168.31.1
nameserver 8.8.8.8

有关PVE的IPv6配置将在后续到来。

测试：

root@pve:~# curl ip.3322.net
61.180.102.151

成功连接Internet。

当然，此后，我们可以在enp5s0 直接创建macvlan网络，vlan设备了

root@pve:~# docker network create -d macvlan --subnet=192.168.31.0/24 --gateway=192.168.31.1 -o parent=enp5s0 dianxin
0ebcd6c39b7e812665ba5176c088b715e196923fca1d3f75aef842dc2f1861d0
root@pve:~# docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
c1a286028953   bridge    bridge    local
0ebcd6c39b7e   dianxin   macvlan   local
1babb0e980ee   host      host      local
ecb39f108081   none      null      local

End.

About me & My Blog

2023-05-02T15:49:07.000Z

记录一次自己发文地点变更想说的话

哈，呼~！已经很久没有写东西了，包括在酷安，IT之家上都很少发消息了。现在总要写点什么吧，证明自己在996下制度依然挣扎着，活了下来(不是)。

时间匆匆而过，人已无少年。时不用以往，现是早上8时起床，开始一整天的工作与学习的生活(摸鱼)，中午，晚上在移动公司兼职，没什么时间搭理自己过去写的东西，也没兴趣写东西（其实是懒了）。

在很久很久之前（2013~2018），我在自己的站点上（shenguo.esy.es）写文章，分享一些Windows系统的小工具，不过主机与域名都已经收回了，况且那段时间写的东西也不堪入目，就不想再拿出来了，也没什么值得发出来的了。

在后来，2020年疫情居家，在酷安上写过几篇很长的图文，主要是Android 搞机有关的文章，最近我会抽时间把文章给搬回来。

五一期间，有了不少时间可以做自己想做的事。看着朋友们都在CSDN、自己个人站点、知乎发文，觉得自己不该摆烂了，才重新拾起了写博文的想法。

我还是我，人已随着年龄改变了，不变的是对互联网的热情。

2020.3~2022.2：

自学Python，结合自己想做一个Android ADB工具包的idea，写了两个项目

adbshellpy

Android ROM解包工具

2022.6:

自学C++DuiLib框架，基于vspoy的Adobe安装包，做了一个联网安装器

2022.10买了N5105四网口工控机，开始了噩梦般的软路由/NAS/PCDN/虚拟化搞机生活。

还好，在众览网友们的N5105玩机经验后，前几天完成了在天坑的Intel N5105平台上玩虚拟化的骚操作。

蓦然回首，畅享IT之海依然是生活最重要的一部分。我会在这里分享我个人的玩机过程，分享生活中的杂碎。

MySkills&Love

C,C++,Java,C#,Python,PyQt,C++Qt,PyTkinter,DuiLib,SpringBoot and IoTcommunication(MQTT,MODBUS)

MyLearning:

Go,Web前后端,Docker&k8s集群 and 云计算

By AEnjoy，2023-5-3 00:29:10.

Hello World

2023-05-02T15:23:35.000Z

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

$ hexo new "My New Post"

More info: Writing

Run server

$ hexo server

More info: Server

Generate static files

$ hexo generate

More info: Generating

Deploy to remote sites

$ hexo deploy

More info: Deployment