樱花客栈

作者： 大嘴巴小牙齿

  • Load AVG（Linux）

    【Load Average】：代表机器在某一时间段内，处于“可运行状态”或“不可中断等待状态”的进程平均数量。

    三个数值统计跨度分别为：1分钟平均 5分钟平均 15分钟平均

    一台4核心的处理器的Load为 1.21 1.34 1.12

    1、CPU压力为 1.21 / 4 ≈ 0.30

    2、CPU压力为 1.34 / 4 ≈ 0.34

    3、CPU压力为 1.12 / 4 ≈ 0.28

    平均只有约1个任务在运行或等待CPU，而系统有4核心，完美胜任服务

    在Linux中，平均负载并非在每个时钟滴答时计算，而是由一个基于HZ频率设置的变量值驱动，并在每个时钟滴答时进行检测。该设置定义了内核时钟滴答速率（单位：赫兹，即每秒次数），默认值为100，对应10毫秒的滴答间隔。内核活动使用这些滴答数进行计时。具体来说，calc_load() 函数（位于loadavg.h文件，原为 sched.h）负责计算平均负载，它大约每LOAD_FREQ（5*HZ+1）个滴答运行一次，即略多于5秒。

  • TOPS和TFLOPS

    选择

    TOPS和TFLOPS代表了计算系统中不同的硬件性能。
    TOPS代表 Tera Operations Per Second
    TFLOPS 代表 Tera Floating Point Operations Per Second

    TOPS衡量芯片每秒能完成多少万亿次整数运算（整数的加法/乘法）。这对于吞吐量比最终精度更重要的任务尤为关键——例如，自动驾驶车辆中的神经处理单元（NPU）或RTX 5070显卡提供数千个TOPS以快速处理传感器数据。 相比之下，TFLOPS计算的是每秒可执行的万亿次浮点（十进制）计算。 浮点数学对于高精度工作至关重要，比如训练神经网络或科学模拟。


    如果工作目标是AI训练或任何需要高精度的任务，选择TFLOPS评分很高的GPU。
    如果是边缘或移动端的实时AI推理，选择高TOPS的NPU或GPU。

    关键区别

    精度与速度：浮点运算涉及小数且精度更高，因此优化TFLOPS（每秒万亿次浮点运算）的硬件用于对精度敏感的任务（如图形处理或气候模型）。整数运算（以TOPS，即每秒万亿次运算衡量）使用整数，更简单快速。正如资料所示，浮点运算“涉及小数点”，适用于高精度场景；而整数运算用于更简单的任务。实践中，GPU（英伟达、AMD独显等）为复杂计算强调TFLOPS，而NPU（神经网络处理器）和数字信号处理单元则强调TOPS以快速处理大量推理任务。

    硬件效率：整数运算比浮点运算简单，硬件通常能实现更高吞吐量。这就是NPU和其他推理加速器宣传极高TOPS值的原因。例如，现代PC CPU如英特尔酷睿Ultra系列或高通骁龙芯片集成了擅长整数运算的NPU，能以低功耗实现每秒数万亿次运算。相比之下，在相同制程下，GPU的浮点单元每秒运算次数少于NPU的整数单元，因为浮点运算更复杂。

    应用适用性：根据工作负载选择合适的指标。若进行AI训练或重型计算，需要高TFLOPS。数据中心GPU和加速器（英伟达A100/H100、AMD Instinct、谷歌TPU）使用FP32、FP16或BF16精度提供巨大的TFLOPS（通常达数十或数百）。TOPS与TFLOPS数值不能直接等同比较。例如，NPU的“130 TOPS”并不天然优于或劣于GPU的“65 TFLOPS”——它们反映不同类型的吞吐能力。TOPS反映通用（通常为低精度）运算，而TFLOPS反映十进制精度运算。高TOPS芯片可能擅长实时运行图像分类器，但在训练需要高浮点精度的模型时可能吃力。反之，高TFLOPS芯片能训练庞大模型，但在相同推理任务上可能功耗更高、成本更大。

  • 对象存储（Object Storage Service）

    OSS（对象存储服务）以存储空间（Bucket）作为数据的逻辑容器，用来统一管理对象。每个Bucket都具有唯一性，并绑定了固定的存储类别、访问权限策略以及所属地域，用户可以通过Bucket对应的访问域名在互联网上定位并访问其中的数据。

    在OSS中，对象（Object）是最基本的数据存储单元，可以理解为“文件 + 属性信息”的整体。一个对象由Key、Metadata和Data三部分组成。Key即对象的唯一名称，是经过UTF-8编码的字符串，在同一个Bucket内不能重复；Metadata是对象的描述信息，以键值对形式存在，用于说明对象的各种属性；Data则是对象实际存储的二进制数据内容。Metadata又分为系统元数据和用户元数据，其中系统元数据由OSS自动维护，用于对象管理和传输，例如内容长度、最后修改时间、ETag等；用户元数据则由用户在上传时自定义，用来补充描述对象的业务属性。

    OSS根据数据访问频率和成本需求提供了多种存储类别。标准存储具备高可靠性、高可用性和高性能，访问时延低、吞吐能力强，适合需要频繁访问的热点数据场景，如网站图片、音视频内容和移动应用资源。低频存储面向访问次数较少但仍需实时读取的数据，存储成本低于标准存储，适合长期备份类数据，但对象存储时间不足30天提前删除会产生费用。归档存储则以最低的存储成本支持长期保存的数据，适合日志、档案和影视素材等几乎不访问的数据，取回时需要等待一定时间，并且对最短存储周期有更严格的限制。

    在底层能力上，OSS通过多副本和纠删码等冗余机制，将数据分布在跨可用区甚至跨设备的存储节点上，即使多台设备同时发生故障，也能保证数据不丢失、业务不中断，并自动完成冗余修复。同时，系统会周期性校验数据完整性，发现异常后利用冗余数据进行重建，进一步保障数据可靠性。

    OSS还提供对象级别的强一致性保障。所有对象操作都是原子的，不存在中间状态：操作要么成功，要么失败。只要用户收到成功响应，数据就已经处于可用状态。例如对象上传完成后即可立即读取，更新对象时，其他并发读请求只会读到旧数据，而不会读到部分或损坏的数据。这种强一致性特性使得OSS在使用方式上更接近传统存储系统，简化了应用架构设计。

    在数据组织方式上，OSS采用Key-Value模型，而不是传统文件系统的目录树结构。对象的Key是访问数据的唯一标识，即使Key看起来像“FolderA/FolderB/file.jpg”，在OSS内部也只是一个普通字符串，并不代表真实存在的层级目录。因此，不同Key的访问效率基本一致，不会因为“目录层级”变深而降低性能。所谓的目录操作，本质上是对前缀匹配的一批对象进行处理，成本较高，也不被推荐频繁使用。

    由于OSS不支持对象的在线修改，即使只改动一个字节，也需要重新上传整个对象，因此它天然适合“一次写入，多次读取”的业务模型。依托分布式架构和Key-Value存储方式，OSS能够支持海量数据和高并发访问，非常适合静态资源分发、备份归档等场景。

    在访问和管理方式上，用户可以通过网页形式的管理控制台直观地创建Bucket、上传下载文件并配置权限；也可以使用支持S3接口的客户端工具（如S3Browser）进行本地化管理；对于开发场景，OSS提供了封装良好的SDK，方便应用程序直接调用对象存储能力；同时还提供基于HTTPS、数据格式为JSON的RESTful API，满足更底层或统计类的接口调用需求。

  • 工具iproute2命令

    Iproute2是一组用于控制Linux中TCP/IP网络和流量控制的工具

    通过ip命令使用，搭配以下选项

    link — 逻辑网络设备

    address — 协议，设备上的（IPv4或IPv6）地址

    neighbour — ARP或NDISC缓存条目

    route — 路由表入口

    rule — 规则数据库

    maddress — 组播地址

    mroute — 路由缓存条目

    tunnel — IP协议通道

    使用

    ip neigh 
//邻居表对象建立协议地址与链路层之间的绑定;为了共享同一物理链路的主机建立地址。邻居对象条目组织成表。IPv4邻居对象表也被称为ARP表。查看邻居表的绑定及其属性，添加新的邻居表条目，并删除旧的。
    ip link
// 链路指的是网络设备。ip link对象及其对应的命令集允许查看并作网络设备的状态。
    ip addr
// 地址指的是连接到网络设备上的协议（IP或IPv6）地址。每个设备必须至少有一个地址，才能使用对应的协议。可以有多个不同的地址连接到一个设备。这些地址在协议结构中并不被区分，因此“别名”一词并不完全适用于此类多地址。
    ip route
// 管理内核路由表中的路由条目。内核路由表保存协议路径与其他网络节点的信息。每个路由条目都有一个密钥，由协议前缀组成，即网络地址和网络掩码长度的配对，以及可选的类型服务（TOS）值。如果IP数据包的目的地址的最高位数等于路由前缀至少是前缀长度，且路由的TOS为零或等于数据包的TOS。
    ss -tlpn
// -t tcp连接 -l监听 -p进程 -n不解析服务名
    tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms
// 限速eth0网卡下行10mbps

tc qdisc del dev eth0 root
// 解除eth0网卡限速
    ip rule
// 路由策略中的规则数据库控制路由选择算法。经典路由互联网中使用的算法仅基于数据包的目的地址，理论上，但实际上不基于TOS字段。在某些情况下，我们希望路由数据包的方式不同，不仅取决于目的地址，还包括其他数据包字段，如源地址、IP协议，传输协议端口甚至数据包有效载荷。这项任务称为“策略路由”。

  • WebSocket和HTTP Upgrade机制

    HTTP协议用于浏览器和服务器之间传输数据。每次请求是独立的，不记历史，HTTP来轮询服务器更新增加性能支出。

    WebSocket协议旨在取代现有利用HTTP作为传输层的双向通信技术，从而利用现有基础设施（代理、过滤、认证）。但WS是基于HTTP层，而不是为了取代HTTP。

    在HTTP协议中，“Upgrade”机制允许客户端告诉服务器把当前的HTTP连接升级到另一种协议。（RFC 2616）。

    WebSocket协议由开启握手和基础消息框架组成，分层叠加在TCP之上， 该技术的目标是为需要与服务器双向通信的浏览器应用提供一种机制，无需开启多个HTTP连接。WS通过HTTP升级协议握手。一条向服务器的WS握手：

    GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
    Origin: http://example.com
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13

    一条向客户端的WS握手：

    HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
    Sec-WebSocket-Protocol: chat

    一旦客户端和服务器都发送了握手，如果握手成功，数据传输阶段才开始。这是一个双向通信通道，双方可以独立地随意发送数据。成功握手后，客户端和服务器以本规范中称为“消息”的概念单元进行数据传递。 在线路上，一条消息由一个或多个组成框架。 WebSocket消息不一定对应于特定的网络层框架，因为分段消息可能被中介合并或拆分。

    Sec-WebSocket-Protocol: chat
    用于防止脚本在网页浏览器中使用 WebSocket API 时未经授权交叉使用该服务器。 服务器会被告知生成WebSocket连接请求的脚本来源。 如果服务器不愿意接受来自该源的连接，可以通过发送相应的HTTP错误代码来拒绝连接。 该头字段由浏览器客户端发送;对于非浏览器客户端，如果在客户端上下文中合理，可能会发送该头字段。

    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
    对于该头部字段，服务器必须将头部字段中的值与全局唯一标识符字符串形式“258EAFA5-E914-47DA- 95CA-C5AB0DC85B11”串联起来，这通常不会被不理解WebSocket协议的网络端点使用。 该连接的SHA-1哈希值（160位），以base64编码，随后在服务器握手中返回。

    HTTP/1.1 101 Switching Protocols
    除了101以外的任何状态码，都表示WebSocket握手尚未完成，HTTP的语义仍然适用。头部紧跟状态码。

    HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
    WebSocket客户端会检查这些字段以查找脚本页面。如果 |Sec-WebSocket-Accept|如果缺少头字段，或者 HTTP 状态码不是 101，则连接无法建立，WebSocket帧也不会发送。

    通过升级器，http服务被升级为websocket服务，除非得到websocket握手，否则连接失败：

    #Go

#An upgrader
var upgrader = websocket.Upgrader{
	CheckOrigin: func(r *http.Request) bool {
		return true
	},
}

var wsClients   = make(map[*websocket.Conn]bool)

func wsHandler(c *gin.Context) {
	conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
	if err != nil {
		return
	}
	defer conn.Close()
	wsClients[conn] = true
	for {
		_, _, err := conn.ReadMessage()
		if err != nil {
			delete(wsClients, conn)
			break
		}
	}
}

func main() {
        r := gin.Default()
        r.GET("/ws", wsHandler)
}

  • CRC(cylic redundancy check)数据帧校验

    crc用于校验数据传输过程的完整性，crc码通常位于数据帧尾部，与数据帧同时传输。

    计算数据帧的crc码与接收的crc码来确认数据完整性：

    初始化一个寄存器为0xFFFF，逐步与每个数据帧进行异或操作。

    # golang
func CalculateCRC(data []byte) uint16 {
	crc := uint16(0xFFFF)
	for _, b := range data {
		crc ^= uint16(b)
		for i := 0; i < 8; i++ {
			if crc&0x0001 != 0 {
				crc >>= 1
				crc ^= 0xA001
			} else {
				crc >>= 1
			}
		}
	}
	return crc
}

  • RandKey-QT 生成随机密码 桌面端工具

    RandKey-QT -> Github Page

    解决需要生成随机字符的燃眉之急

    Solve the urgent need to generate random characters && numbers temporatily

    ScreenShot ScreenShot

    用法 Usage

    确保用的是Qt 6.8。 make sure Qt version is 6.8.

    • 下载二进制 Download binary, 直接运行 run directly.

    • 或者克隆这个文件夹，然后在Qt craetor打开。 or clone this repository, open in Qt craetor.

    国际化 International

    1. lupdate . RandKey_QT_en_GB.ts

    2. linguist RandKey_QT_en_GB.ts

    或者使用以下脚本 or use the below Shell script:

    TS_DIR="./RandKey-QT" # .ts file
QM_DIR="$TS_DIR/translations" # output .qm dir

for tsfile in "$TS_DIR"/*.ts; do
    if [ -f "$tsfile" ]; then
        echo "Updating $tsfile "
        lupdate . -ts "$tsfile" -no-obsolete
    fi
done
this
for tsfile in "$TS_DIR"/*.ts; do
    filename=$(basename "$tsfile" .ts)   
    qmfile="$QM_DIR/$filename.qm"      
    echo "Generating $qmfile "
    lrelease "$tsfile" -qm "$qmfile"
done

  • Golang Range

    Golang的range可以用来遍历array，slice，string，map或channel

    range array：

    func main() {
	animals := [3]string{}
	animals[0] = "tiger"
	animals[1] = "cat"
	animals[2] = "lion"
	for index, animal := range animals {
		fmt.Println(index, animal)
	}
}

//output:
//0 tiger
//1 cat
//2 lion

    range slice：

    func main() {
	urls := []string{"ziyaun.work", "https://ziyuan.work"}
	for index, url := range urls {
		fmt.Println(index, url)
	}
}

//output:
//0 ziyaun.work
//1 https://ziyuan.work

    range string：

    func main() {
	url := "ziyuan.work"
	for i, v := range url {
		fmt.Println(i, v)
	}
}

//output:
//0 122
//1 105
//2 121
//3 117
//4 97
//5 110
//6 46
//7 119
//8 111
//9 114
//10 107

    range map：

    func main() {
	userList := make(map[string]string)
	userList["url"] = "ziyuan.work"
	for key, value := range userList {
		value = "I change myself" //改变的只是提取item的值，userlist不受影响
		fmt.Println(userList[key])
		fmt.Println(value)
	}
}

// output:
//ziyuan.work
//I change myself

    range channel：

    func main() {
	wg := sync.WaitGroup{}
	wg.Add(1)

	c := make(chan int)
	go func() {
		defer wg.Done()
		for i := 0; i < 10; i++ {
			c <- i
		}
	}()

	go func() {
		wg.Wait()
		close(c)
	}() // 当使用range对channel操作时，会无限遍历，最终变成死锁，因此需要关闭channel

	for value := range c {
		log.Println(value)
	}
}

//output:
//0
//1
//2
//3
//4
//5
//6
//7
//8
//9

  • BLE应用层

    低功耗蓝牙（Bluetooth Low Energy，BLE）分为三个部分组成。应用（Application）+主机（Host）+控制器（Controller）。单模BLE设备的应用层包含：

    • 通用访问配置文件 Generic Access Profile（GAP）
    • 通用属性配置文件 Generic Attribute Profile（GATT）
    • 逻辑链路控制和适配协议 Logical Link Control and Adaption Protocol （L2CAP）
    • 属性协议 Attribute Protocol（ATT）
    • 安全管理 Security Manager（SM）
    • 主机控制器接口 Host Controller Interface（HCI）

    通用属性配置文件（Generic Attribute Profile，GATT）建立在属性协议（Attribute Protocol，ATT）之上，通过在其上层引入层级化的数据组织结构和抽象模型，实现了对BLE数据的统一建模与访问控制。在BLE协议体系中，GATT可视为应用层数据交互的核心框架，其定义了数据在不同设备应用之间的组织方式及交换机制。GATT定义了一组通用的数据对象，可被各类基于GATT的应用配置文件复用。其继承了ATT所采用的客户端–服务器（Client–Server）架构，但通过引入“服务（Service）”这一逻辑容器，对数据进行了更高层次的封装。每个服务由一个或多个特征（Characteristic）组成。特征用于描述具体的用户数据单元，其不仅包含实际数据值（Value），还可关联多种元数据（Metadata），例如访问权限、用户可读名称、单位、描述符等，从而为数据的发现、访问和解释提供支持。

    通用访问配置文件（Generic Access Profile，GAP）定义了设备在BLE协议栈中进行连接和控制交互的行为规范。GAP被视为BLE的顶层控制模型，描述了设备在不直接涉及具体数据内容的情况下，如何完成设备发现、连接建立、安全机制协商以及角色管理等流程，以确保不同厂商设备之间的互操作性。为实现设备间一致且可互操作的通信行为，GAP进一步规范了以下内容：

    • 设备角色及其交互关系
    • 设备可发现性与可连接性模型及其状态转换
    • 建立可靠通信所需的控制流程
    • 安全模式、安全级别及相关流程
    • 用于广播和扫描的非协议数据（如Advertising Data）的格式定义

    “蓝牙连接”分为广播(broadcasting)或者连接(connections)

    广播(broadcasting)

    在BLE中，广播机制定义了两种相互独立的角色：广播者（Broadcaster）和观察者（Observer）。广播者负责在预定义的广播信道上周期性地发送不可连接的广播数据（Advertising Data），这些数据可被任意处于监听状态的设备接收。广播过程中，广播者不与接收设备建立连接关系。观察者则持续扫描指定的广播信道，以接收当前正在广播的、不可连接的广播数据包。观察者仅被动接收信息，不参与任何连接或数据确认过程。

    广播机制在BLE体系中具有重要意义，因为它是BLE中唯一一种支持单个设备在同一时间向多个设备分发数据的通信方式。该机制充分利用了BLE的低功耗和无连接特性，适用于向周围设备周期性发布状态信息或少量数据的场景。

    标准BLE广播数据包包含最多31字节的有效负载（Payload），用于承载描述广播发送者身份、能力以及服务信息的数据，同时也可包含用户自定义的广播内容。当该负载空间不足以容纳所需信息时，BLE允许使用可选的扫描响应数据（Scan Response）。在此机制下，观察设备在接收到广播数据后，可向广播者发送扫描请求，从而获取额外的31字节扫描响应负载，使单次广播相关的数据总量达到62字节。

    由于广播方式具有实现简单、延迟低且支持多设备同时接收的特点，当需要按照固定周期推送少量数据，或向多个设备发布公共信息时，广播是一种高效且实用的选择。然而，与基于连接的通信方式相比，广播机制存在显著的安全与隐私局限性。广播数据在未加密的情况下发送，任何处于监听状态的观察设备均可接收并解析广播内容。因此，该方式通常不适用于传输敏感或私密数据。

    连接(connections)

    当需要在设备之间进行双向数据传输，或所需传输的数据量超过广播与扫描响应所能承载的容量时，应采用基于连接（Connection）的通信方式。BLE连接是一种在两个设备之间建立的持续通信关系，连接建立后，设备双方在约定的时间点周期性地交换数据。与广播相比，连接通信具有天然的隐私性，其数据仅在连接的两端设备之间传输，不会被其他设备接收，除非第三方设备通过非正常手段对无线信道进行嗅探。

    BLE连接模型中定义了两种通信角色：中心设备（Central）与外围设备（Peripheral）。中心设备通过周期性扫描广播信道，以发现可连接的广播数据包。当检测到符合条件的广播后，中心设备发起连接请求并建立连接。连接建立后，中心设备负责控制连接时序（Timing），并调度周期性的数据交换过程。外围设备则以周期性发送可连接的广播数据包为主要行为，并在接收到连接请求后接受并进入连接状态。在连接建立后，外围设备需遵循中心设备所控制的连接时序，在预定的连接事件（Connection Event）中与中心设备进行数据交换。

    需要注意的是，尽管中心设备负责连接的建立与时序控制，但在每一个连接事件中，数据的发送方向是双向对等的。中心设备与外围设备在数据吞吐量和访问优先级方面并不存在协议层面的强制限制。自蓝牙4.1版本起，BLE规范取消了对角色组合方式的限制，允许设备在同一时间承担多种角色。具体而言：

    • 单个设备可以同时作为中心设备和外围设备
    • 一个中心设备可以同时与多个外围设备建立连接
    • 一个外围设备也可以同时与多个中心设备建立连接

    相较于早期规范中对外围设备只能连接单一中心设备的限制，上述改动显著增强了BLE网络拓扑的灵活性。连接通信的最大优势在于其支持通过更高层协议对数据进行精细化组织和访问控制。BLE通过在连接之上引入通用属性配置文件（Generic Attribute Profile，GATT），将数据组织为服务（Service）和特征（Characteristic）等逻辑单元。服务可包含多个特征，每个特征均具备独立的访问权限及描述性元数据，从而构建出结构清晰、可扩展的数据模型。

    此外，基于连接的通信方式还具备更高的数据吞吐能力、支持安全加密链路的建立，并允许在连接建立过程中协商连接参数，以优化数据传输效率与功耗表现。在功耗方面，连接通信在某些场景下甚至可能优于广播方式。由于通信双方可预先确定连接事件的时间点，无线模块可在非通信时段进入休眠状态，从而降低整体能耗。相比之下，广播方式需要持续在固定频率下发送完整负载，且不区分是否存在接收设备，这在数据量较大或通信频率较高的情况下可能导致额外的能耗开销。

    通用访问配置文件（GAP）

    GAP是BLE设备实现互操作性的基础框架。GAP为所有BLE实现定义了一套统一的行为规范，要求设备能够以标准化的方式完成设备发现、广播数据、建立连接、协商安全机制以及执行其他基础控制操作。对GAP的深入理解至关重要，因为在许多BLE协议栈实现中，GAP通常被作为向上层应用暴露的最底层功能接口之一，为应用开发者提供设备控制和连接管理能力。

    BLE核心规范中，GAP主要从以下几个方面定义了设备之间的交互行为：

    • 角色（Roles）每个BLE设备可以同时承担一个或多个角色。不同角色对设备行为施加特定的约束，并规定了设备在交互过程中的强制行为要求。某些角色组合允许设备之间建立通信关系，而GAP则精确定义了这些角色之间的交互方式。尽管并非绝对如此，角色通常与特定类型的设备或应用场景相关联。在大多数实际实现中，设备角色往往在其生命周期内保持稳定，并不会频繁发生变化。
    • 模式（Modes）模式是在角色之上的进一步抽象，用于描述设备在特定时间段内为实现某一目标而进入的运行状态。模式通常对应某一具体流程的执行条件，用以允许或限制设备在该阶段的行为。模式的切换既可由用户操作触发，也可由协议栈根据运行需要自动触发，其发生频率通常高于角色的切换。
    • 流程（Procedures）流程是指设备为达成特定目标而执行的一系列操作步骤，通常涉及链路层控制或必要的数据交换。一个流程往往依赖于对端设备处于特定模式之中，因此流程与模式在实际交互中通常紧密关联、协同执行。
    • 安全性（Security）GAP在底层安全管理协议之上，通过定义安全模式和安全等级，规定了设备在不同数据交换需求下应采用的安全策略，并描述了这些安全等级的建立与强制执行流程。此外，GAP还定义了一些不依赖于特定模式或流程的通用安全特性，使设备能够根据具体应用需求灵活提升数据保护级别。
    • GAP相关数据格式。为支持设备发现和控制流程，GAP定义了用于广播和扫描的附加数据格式，用以描述设备的基本属性、能力以及服务信息，从而确保设备之间能够以统一且可互操作的方式完成初始交互。

    属性配置文件（GATT）

    通用属性配置文件（Generic Attribute Profile，GATT）定义了如何在蓝牙低功耗（BLE）连接之上交换应用数据和用户数据。与负责设备发现、连接建立及控制行为的通用访问配置文件（GAP）不同，GATT专注于实际数据的组织方式、访问规则以及数据交换流程。

    GATT同时为基于GATT的各类标准配置文件提供了统一的参考框架。这些配置文件由蓝牙SIG定义，用于覆盖特定的应用场景，并确保来自不同厂商的设备能够实现互操作性。所有标准的BLE应用配置文件均建立在GATT之上，并必须遵循其定义的数据模型和操作规则。因此，GATT构成了BLE规范中至关重要的组成部分，所有面向应用和用户的数据项都必须依据GATT的规则进行格式化、封装并传输。

    GATT通过属性协议（Attribute Protocol，ATT）作为底层传输机制，实现设备之间的数据交换。数据在逻辑上按照层级结构进行组织，其中一组相关属性被封装为服务（Service），而服务中与具体用户数据语义相关的最小功能单元被定义为特征（Characteristic）。这一数据组织方式构成了GATT的基本结构模型。

    GATT角色（Roles）

    与蓝牙规范中其他协议和配置文件一致，GATT通过定义参与通信的角色来描述设备间的交互方式。

    • 客户端（Client）GATT客户端与属性协议（ATT）中的客户端角色相对应。客户端负责向服务器发送请求并接收响应，包括读取、写入属性值以及接收由服务器发起的属性更新。初始状态下，GATT客户端并不了解服务器端所包含的属性结构，因此必须首先执行服务发现（Service Discovery）流程，以获取服务器上可用服务及其特征的相关信息。完成服务发现后，客户端即可对已发现服务中的属性进行访问，并接收来自服务器的通知或指示。
    • 服务器（Server）GATT服务器对应于ATT中的服务器角色，负责接收来自客户端的请求并返回相应的响应。在特定配置下，服务器还可以主动向客户端发送属性更新。作为服务器角色，设备需要负责存储和组织用户数据，并以属性的形式向客户端提供访问接口。所有已投入使用的BLE设备至少必须包含一个基本的GATT服务器，以便能够响应客户端请求，即便该响应仅为错误返回。

    需要强调的是，GATT角色与GAP角色之间不存在依赖关系。GATT客户端或服务器角色可以与任意GAP角色组合使用。因此，GAP中的中心设备或外围设备既可以作为GATT客户端，也可以作为GATT服务器，甚至在同一设备中同时承担两种GATT角色。

    UUID（Universally Unique Identifier）

    通用唯一标识符（Universally Unique Identifier，UUID）是一种128位（16字节）的标识符，用于在全球范围内唯一标识对象。UUID并非蓝牙专有，其格式、生成方式和使用规则由ITU-T Rec. X.667（亦即 ISO/IEC 9834-8:2005）进行规范。

    由于完整的128位UUID在BLE链路层中会占用较大的数据负载空间，BLE规范引入了两种压缩形式的UUID：16位UUID和32位UUID。这些缩短形式仅适用于由蓝牙SIG定义和分配的标准UUID，用于标识标准服务、特征及相关类型。缩短形式的UUID可通过嵌入至蓝牙基础UUID（Bluetooth Base UUID）中恢复为完整的128位UUID，其格式如下：

    xxxxxxxx-0000-1000-8000-00805F9B34FB

    其中，xxxxxxxx表示16位或32位的SIG分配值（高位补零）。

    蓝牙SIG为所有标准服务、特征及其定义的配置文件分配了对应的UUID。当应用需求无法由现有标准UUID满足，或需要实现规范之外的自定义功能时，可生成厂商自定义（Vendor-Specific）的UUID。此类UUID必须使用完整的128位形式，并通常通过ITU所规定的UUID生成机制生成。对于不基于蓝牙基础UUID的厂商自定义UUID，不允许使用16位或32位的缩短形式，必须在整个协议交互过程中始终使用完整的128位UUID。

    启动一个广播服务

    // golang

import (
    "github.com/muka/go-bluetooth/api"
    "github.com/muka/go-bluetooth/bluez/profile/adapter"
)

func main() {
    a, err := adapter.GetDefaultAdapter()
    if err != nil {
        panic(err)
    }

    a.SetPowered(true)
    a.SetDiscoverable(true)
    a.SetAlias("My-BLE-Device")

    select {}
}

  • Nginx代理基础

    常用目录

    • /var/www/html/ 默认的站点目录，供外部访问
    • /etc/nginx/ 配置文件目录：

    nginx.conf
    Nginx的核心配置文件，用于设置全局参数（如worker进程数、日志路径、PID文件等）、事件处理模块（events块）以及HTTP服务相关配置，包括http、server和location等模块。

    conf.d/
    该目录用于存放扩展配置文件，常用于按站点或功能划分虚拟主机配置。主配置文件中通常通过include指令引入该目录下的所有.conf文件，实现配置模块化管理。

    mime.types
    该文件用于定义文件扩展名与MIME类型之间的映射关系。Nginx根据此文件确定响应头中的内容类型，例如将.jpg映射为image/jpeg。

    fastcgi_params、uwsgi_params、scgi_params
    这些参数文件定义了与FastCGI、uWSGI、SCGI等后端通信所需的环境变量，便于Nginx在与PHP、Python等应用服务器交互时传递请求信息。

    • /usr/share/nginx/ 默认站点目录，最终为页面看到的内容。

    /usr/share/nginx/html/ 存放默认站点的index.html、404.html等文件

    • /var/log/nginx 日志目录

    代理

    正向代理与反向代理的区别：正向代理，客户端通过代理服务器向远程服务器发送请求；反向代理，客户端访问远程服务器，远程服务器将请求再转发至目标可用服务器。

    负载均衡：代理多个后端服务器时，Nginx可按轮询、IP hash等策略分发请求。

    工作原理

    Nginx包括基于事件驱动、异步非阻塞的高性能Web服务器架构，擅长处理高并发请求，常用于静态资源服务、反向代理、负载均衡等场景。

    Nginx启动一个Master主进程，然后根据配置文件创建一个或多个Worker子进程。Master主进程负责读取配置、管理进程（启动、重载、关闭），只负责“调度管理“。

    Nginx采用异步非阻塞的请求处理机制，使其具备高效处理海量并发请求的能力。相比之下，Apache默认采用的工作模式（尽管也提供异步非阻塞版本，但由于与部分内置模块存在兼容性问题而较少使用）会为每个请求分配独立的工作线程。当并发量达到数千级别时，就意味着需要同时维持数千个运行线程。这种设计会给系统带来显著负担：一方面，大量线程会消耗可观的内存资源；另一方面，频繁的线程上下文切换会产生巨大的CPU开销。这些额外的系统资源消耗不仅无法提升性能，反而会成为系统瓶颈。

    在Nginx中，阻塞式系统调用是大忌。既然不能阻塞，那就必须采用非阻塞的方式——比如某个事件还没准备好，系统调用会立即返回EAGAIN，告诉你：“别急，数据还没到位，等会儿再来查！”于是，你可以先去做别的事情，过会儿再来检查。虽然这种方式避免了线程阻塞，但需要不断轮询事件状态，仍然存在不小的开销。

    于是，更高效的异步非阻塞事件驱动模型应运而生，其核心就是select、poll、epoll（Linux）或kqueue（BSD）这样的系统调用。它们的共同特点是：

    • 批量监控多个事件：调用时虽然是阻塞的，但可以设置超时时间，期间只要有事件就绪，就会立即返回。
    • 高效的事件管理：以epoll为例，未就绪的事件会被注册到epoll中，待其就绪后再处理；如果读写时返回EAGAIN，就重新放回epoll等待。这样，程序只需在所有事件都未就绪时才会真正等待，其余时间都在高效处理就绪事件。

    这种模式下，虽然单线程在同一时刻只能处理一个请求，但由于采用了事件循环机制，可以在多个请求间快速切换。关键在于：

    • 切换无代价：不同于多线程的上下文切换，Nginx的切换是主动让出（因事件未就绪），本质上只是循环处理已就绪的事件。
    • 资源占用极低：无需创建线程，每个请求仅消耗少量内存，没有线程切换的开销，使得高并发时不会浪费CPU资源。

    master-workers的好处

    Nginx采用多进程架构，每个Worker进程独立运行，这种设计带来了诸多优势：

    1. 无锁高性能
      • 由于Worker进程之间不共享内存，无需加锁，避免了锁竞争带来的性能损耗，同时也降低了编程复杂度和问题排查难度。
    2. 无缝热升级
      • 支持 nginx -s reload 热部署，在不中断服务的情况下更新配置或二进制文件，确保业务持续可用。
    3. 故障隔离，服务不中断
      • Worker进程之间相互独立，即使某个进程崩溃，也不会影响其他进程，Master进程会迅速重启新的Worker，保证服务稳定运行。
      • 虽然异常的Worker会导致当前处理的请求失败，但仅影响部分请求，不会造成全局服务中断，降低了整体风险。
    4. 高效请求处理
      • 所有Worker进程公平竞争处理请求，即使某个Worker异常退出，剩余进程仍能继续处理新请求，确保服务高可用。

    这种进程隔离+Master守护的机制，使得Nginx在保持高性能的同时，具备极强的稳定性和容错能力。