Forem: Michael

排序(collation)探究

Michael — Mon, 03 Jun 2024 08:14:31 +0000

应用程序中到处可见排序，特别是需要国际化的时候，排序更是多种多样。面对这些排序的时候，刚开始的本能就是应该是这样的，比如2排在123后面，但是仔细琢磨下，好像也可以排在前面，因为2小于123，还有各种本地语言更是充满特色。本文主要探究下各种语言对排序支持情况, 如何支持的以及底层库如何运作的。

现状

大部分时候终端数据拿到的是有序数据，如果需要排序，比如表单中表单头字段点击下，可以切换排序方式，发送请求给后端，后端一般在数据库中排序，然后拿到区间数据给终端。有时候数据比较少，或者数据简单，希望直接在终端操作。

根据以上的描述，数据经过的每一个端都有可能排序，那每一端使用的底层排序库不一样，排序结果也有可能大相径庭。

Linux系统排序

系统排序使用 glibc 提供的排序功能。每个linux都需要设置locale，其中就包括排序相关的设置。glibc 和应用程序、函数库使用区域设置显示本地化的文字、货币、时间、日期、特殊字符等包含地域属性的内容。其中的 LC_COLLATE 就是用于系统排序设置参数，不同的值排序结果导致不同排序，比如如果使用原生的"C"排序时，字符'A'在'a'前面；而使用"en_US.UTF-8"时，顺序相反。

man 5 locale
man 7 locale

LC_COLLATE="en_US.UTF-8" sort <<< $'a\nA\n一\n测\n123\n2\n'
# 123\n2\na\nA\n一\n测\n

LC_COLLATE="C" sort <<< $'a\nA\n一\n测\n123\n2\n'
# 123\n2\nA\na\n一\n测\n

默认情况下是"C"，可以看下/usr/lib/locale/C.utf8/LC_COLLATE，提供了基础的ASCII码字符的顺序。其他的可以查看/usr/share/locale/文件夹，但是没有LC_COLLATE文件，猜测直接在glibc中处理。glibc的版本的排序方式一般是很稳定的，但是也有例外。

数据库支持情况

关系型数据库一般使用Postgresql和Mysql，在各自的文档中描述的非常清晰。

Postgresql

Postgresql collation主要用于排序。Postgresql排序目前使用两种方式，libc(表示系统自带的库，比如glibc)和ICU，前者使用数据库编译时操作系统支持的collation，后者是引入第三方库icu，扩展性更高，官方docker镜像编译时默认带入了icu。

# 自定义一个collation，使用icu提供的'zh-u-kn-kf-upper-kr-digit-latn'规则排序，kf表示大小写字母排序自定义，kr表示reorder各种字符顺序，总体表示使用zh的locale，大写字母在前，整体顺序是数字，拉丁字符，中文拼音
create collation zh_num_upper (provider = icu, locale = 'zh-u-kn-kf-upper-kr-digit-latn');
select name from (values ('123'), ('1'),('a'),('A'),('一'),('测')) _(name) order by name COLLATE "zh-u-kn-kf-upper-kr-digit-latn";

Mariadb

# 默认支持的collation
show character set;

# 默认支持的字符集，包括字符集默认的collation，gbk默认的是gbk_chinese_ci, utf8mb4默认的collation是utf8mb4_general_ci
create table test(name character set utf8mb4 collation utf8mb4_unicode_ci not null);
insert into test values ('1'), ('A'), ('a'), ('一'), ('变'), ('导'), ('测'), ('用');
select * from test order by name CONVERT(**name using gbk**);

总结

相比较而言，由于Postgresql引入了第三方库ICU，排序功能空前多，mysql系列显得很轻量。

语言支持

Java

引入ICU库maven配置

<dependencies>
    <dependency>
        <groupId>com.ibm.icu</groupId>
        <artifactId>icu4j</artifactId>
        <version>LATEST</version>
    </dependency>

    <dependency>
        <groupId>com.ibm.icu</groupId>
        <artifactId>icu4j-charset</artifactId>
        <version>LATEST</version>
    </dependency>

    <dependency>
        <groupId>com.ibm.icu</groupId>
        <artifactId>icu4j-localespi</artifactId>
        <version>LATEST</version>
    </dependency>
</dependencies>

Java默认版本和ICU库排序比较

import com.ibm.icu.text.Collator;
import com.ibm.icu.util.ULocale;

import java.util.ArrayList;
import java.util.List;
import java.util.Locale;

public class Demo {
    public static void main(String[] args) {
        Collator col = null;
        try {
            col = Collator.getInstance(Locale.CHINA);
        } catch (Exception e) {

        }

        List<String> l = new ArrayList<String>();
        l.add("123");
        l.add("2");
        l.add("A");
        l.add("a");
        l.add("一");
        l.add("测");
        l.sort(col);
        System.out.format("icu中Locale.CHINA结果: %s\n", l);
        java.text.Collator c = java.text.Collator.getInstance(Locale.CHINA);
        l.sort(c);
        System.out.format("java原生Locale.CHINA结果: %s\n", l);
        Collator cus = Collator.getInstance(new ULocale("zh-u-kr-Latn-Hani-digit"));
        l.sort(cus);
        System.out.format("icu中custom locale结果: %s\n", l);

        byte[] b = col.getCollationKey("一").toByteArray();
        for(byte item : b) {
            System.out.format("%x ", item);
        }
    }
}

// icu中Locale.CHINA结果: [123, 测, 一, a, A]
// java原生Locale.CHINA结果: [123, a, A, 测, 一]
// icu中custom locale结果: [123, a, A, 测, 一]
// 97 39 1 5 1 5 0

Javascript

Javascript文档讲的很清晰。

['一', 123, 2, 'a', 'A', '测','].sort(new Intl.Collator('zh').compare)

初始化文档说明很清晰，locales后面后说明，根据BCP 47文档来定义的，可惜现在还不支持reorder(kr)，options可配置项也很丰富。

Intl.Collator(locales, options)

排序国际化

综上所描述的各个层面的排序支持和结果情况，结果可以说极其不统一。排序是国际化概念中的一个分支，使用统一的排序算法支持的（https://unicode.org/reports/tr10/），并且基于此有有一个ICU库实现（https://unicode-org.github.io/icu/userguide/collation/），为什么推荐使用ICU统一实现各个层的排序呢？

清晰的规则，icu基于标准，规则可解释，也方便定制
一致的规则，比如glibc各个版本的排序规则就不统一，如果postgres使用libc规则，不同的glibc版本可能出现排序不一致的情况
Postgres使用icu，业务代码中可以使用icu，保证了各个微服务模块统一的排序，不然各个微服务使用自己理解的排序，导致终端服务排序不一致（Mysql目前不支持ICU collation）
易于扩展，比如如果按照中文偏旁或者bpmf排序怎么办，而且这些规则都是正常的规则；比如出海（国际化），不仅排序，currency，datetime等规则也有这个需要

排序规则拓展

Language Tags

ICU库里面使用Locale初始化Collator，ICU中Locale概念与POSIX定义的Locale是不一样的，POSIX定义的是[language][_TERRITORY][.CODESET][@modifier]，ICU中的没有codeset相关的设置。现在icu中使用language tag标识locale，而且她具有可扩展性，包括各种tailoring设置等。在HTML的lang设置或者http中的Accept-Language等都使用标准的BCP 47定义的language tag。

网上的BCP 47的定义的RFC文档比较细节，建议看其他入门后可以再看，这里主要推荐先看https://www.w3.org/International/articles/language-tags/，主要描述性讲述language tags（结合https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry）。

格式：language[-extlang][-script][-region][-variant][-extension][-privateuse]

language，也叫 the primary language subtag，比如en表示English，ISO 639描述了language code，可以在上面的language subtag registry中查看类别为language的item，使用2个或者3个小写字符表示，比如

%%
Type: language
Subtag: es
Description: Spanish
Description: Castilian
Added: 2005-10-16
Suppress-Script: Latn
%%

extlang，也叫 the extended language subtag，比如zh-yue表示粤语，使用3个小写字符表示。一般情况下，如果使用单个language可以表示的尽量不适用，比如yue可以单独表示language，替换zh-yue

%%
Type: language
Subtag: yue
Description: Yue Chinese
Description: Cantonese
Added: 2009-07-29
Macrolanguage: zh
%%

script，也叫the script subtag，比如zh-Hans中的Hans表示简体中文，表示书写方式，后面的region表示表达方式，比如HK等，同样在IANA中也有相关描述。四个字符表示，首字符大写，比如Hans，Hant，Latn
region，也叫the region subtag，比如zh-Hans-HK，表示Traditional Chinese as used in Hong Kong。使用2个大写字符或者3位数字表示
variant，这个没用过，Variant subtags are values used to indicate dialects or script variations not already covered by combinations of language, script and region subtag
extension和privateuse，extension以一个注册的字符开头，比如u表示unicode相关设置，这个在icu中用到很多，比如zh-u-kn-kf-upper-kr-digit-latn，zh是language，u开始时unicode的extension；privateuse是自定义使用，通常以x开始，意义自己解释

ICU中language tag扩展UNICODE

很多引用ICU的库，比如Chromium就是使用类似的定义，Javascript中的Intl.Locale初始化参数就是类似，还有Postgresql中定义collation的locale参数也是如此。

扩展注册见https://www.iana.org/assignments/language-tag-extensions-registry/language-tag-extensions-registry，扩展的各个item见https://unicode.org/reports/tr35/tr35-collation.html#Collation_Tailorings

这些扩展都有对应的rule，比如kf用于设置是否大小写顺序，en-u-kf-upper

kf	upper	`[caseFirst upper]`

上表中的[caseFirst upper]可以写入rule table文件中，这个文件用于判断各个字符的顺序，可以通过Python里面的语句获取(需要安装pyicu)

import icu
zh_collator = icu.Collator.createInstance(icu.Locale('zh-CN'))
zh_collator.getRules()
sorted(['a', 'A'], key = zh_collator.getSortKey)
rules = icu.Collator.createInstance(icu.Locale('zh-CN')).getRules()
rules = '[caseFirst upper]' + rules
zh_rule_coll = icu.RuleBasedCollator(rules)
sorted(['a', 'A'], key = zh_rule_coll.getSortKey)

Unicode Collation Algorithm（UCA）

Unicode提供默认的顺序给CLDR的root collation，用于各种语言，locale或者其他配置tailor，https://unicode.org/reports/tr10/#Order_DUCET

Unicode字符比较受到多个方面的影响，比如语言(同样两个字符，不同国家排序不一样)，使用场景(德国电话本和字典里面的字符顺序可能不一样)，自定义(大小写顺序)等，为了描述这些复杂性，使用多层结构描述，见下表

Level	Description	Examples
L1	Base characters	role < roles < rule
L2	Accents	role < rôle < roles
L3	Case/Variants	role < Role < rôle
L4	Punctuation	role < “role” < Role
Ln	Identical	role < ro□le < “role”

level与weight通用，这些level在配置中使用strength表示，比如setStrength

以下这段解释了多个名词，DUCET，CLDR（Unicode Common Locale Data Repository，UCA的各种扩展和补充），tailor，Collation Element转化为Sort key便于比较

The Unicode Collation Algorithm (UCA) details how to compare two Unicode strings while
remaining conformant to the requirements of the Unicode Standard. This standard includes the
Default Unicode Collation Element Table (DUCET), which is data specifying the default collation
order for all Unicode characters, and the CLDR root collation element table that is based on
the DUCET. This table is designed so that it can be *tailored* to meet the requirements of
different languages and customizations.

Briefly stated, the Unicode Collation Algorithm takes an input Unicode string and a Collation
Element Table, containing mapping data for characters. It produces a sort key, which is an
array of unsigned 16-bit integers. Two or more sort keys so produced can then be binary
compared to give the correct comparison between the strings for which they were generated.

CU使用RuleBasedCollator现Unicode方的collation order，具体见文档https://github.com/unicode-org/icu/blob/main/docs/userguide/collation/customization/index.md，这个提供很多细粒度的order设置，比如想把a放在b的后面等

Variable collation elements, which typically include punctuation characters and which may or
may not include a subset of symbol characters, require special handling in the Unicode
Collation Algorithm.

比如空格，-等这些需要设置特别对待，glibc对于这种17，28版本的默认设置有变化（https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade.html ）

以下是CLDR的root collation的locale默认tailors，对于中文

zh/defaultCollation=pinyin
zh/pinyin
zh/stroke
zh-Hant/defaultCollation=stroke

zh_pinyin = icu.Collator.createInstance(icu.Locale('zh'))
zh_stroke = icu.Collator.createInstance(icu.Locale('zh-Hant'))
zh_pinyin.compare('一'，'测') # 1
zh_stroke.compare('一'，'测') # -1

https://www.unicode.org/reports/tr35/tr35-collation.html#Setting_Options CLDR中也描述了各种unicode的扩展描述，以及对应的rule syntax

引用链接

https://symbl.cc/en/unicode/blocks/cjk-unified-ideographs/ unicode table

https://www.flokoe.de/posts/database-character-sets-and-collations-explained/ mysql中character set和collation解释

https://gitlab.pyicu.org/main/pyicu python版本icu仓库
https://github.com/dverite/icu_ext/tree/master postgresql icu扩展
https://unicode.org/reports/tr10/ unicode官方collation算法文档

https://www.unicode.org/reports/tr35/tr35-collation.html CLDR collation algorithm，collation算法的补充文档

https://peter.eisentraut.org/blog/2023/03/14/how-collation-works collation工作机制描述

https://peter.eisentraut.org/blog/2023/04/12/how-collation-of-punctuation-and-whitespace-works 同上

https://peter.eisentraut.org/blog/2023/05/16/overview-of-icu-collation-settings#colalternate icu中collation设置参数描述

 https://peter.eisentraut.org/blog/2023/06/13/overview-of-icu-collation-settings-part-2 同上

https://www.postgresql.org/docs/current/collation.html pg中collation官方文档

https://unicode-org.github.io/icu/userguide/collation/ icu中collation文档

https://gist.github.com/dpk/8325992 pyicu cheatsheet

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Collator 前端国际化对象Intl的collator支持文档

https://github.com/unicode-org/icu/blob/main/docs/userguide/collation/customization/index.md icu collation自定义文档

https://www.rfc-editor.org/rfc/rfc4647.html Unicode中collation的locale标准，html中lang也是使用这个

https://aticleworld.com/strxfrm-in-c/ glibc strxfrm示例

https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade.html glibc升级对pg带来的影响

https://github.com/awslabs/compat-collation-for-glibc/tree/2.17-326.el7 aws应对glibc不同版本影响collate新建的库

https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/don-t-let-collation-versions-corrupt-your-postgresql-indexes/ba-p/1978394 collation版本对pg索引的影响

https://xobo.org/unicode-normalization-nfd-nfc-nfkd-nfkc/ Unicode normalization中文示例

https://www.w3.org/International/articles/language-tags/ Language tags描述

https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry Language subtag注册表

https://www.w3.org/International/questions/qa-choosing-language-tags 如何选择language tags

https://icu4c-demos.unicode.org/icu-bin/collation.html Unicode官方collation在线例子

https://github.com/unicode-org/icu-demos/tree/main/webdemo/collation Unicode官方collation例子仓库

Ubuntu上默认证书库是怎么回事

Michael — Sat, 01 Jun 2024 10:58:06 +0000

背景

最近整HTTP3客户端时候，需要验证服务端证书，中间出了点小插曲，老是报错见上篇文章，问题解决了但是想到另外个问题，浏览器和客户端都是怎么验证证书的，我们都知道服务端给出证书，客户端根据本地的或者用户提供的根证书校验，但是系统根证书在哪儿，为什么我没有设置，他们就自动找到了？本文旨在根据这个问题，梳理Ubuntu系统自带证书库和浏览器的证书库。本文主要聚焦Ubuntu系统，但是其他系统的流程大致相似。

系统证书库

Ubuntu系统的证书目录位于/etc/ssl/certs, 根证书是/etc/ssl/certs/ca-certificates.crt。其他平台的默认证书可以查看golang源码文件。

查看/etc/ssl/certs发现里面有很多pem格式证书，这里就是系统根证书目录，我的机器上面有部分软链接到/usr/share/ca-certificates/mozilla（这个是系统读取/etc/ca-certificates.conf配置加入的）。文件/etc/ssl/certs/ca-certificates.crt是这些证书的合集，可以使用如下命令查看所有证书的subject

awk -v cmd='openssl x509 -noout -subject' '/BEGIN/ {close(cmd)}; {print | cmd}' < /etc/ssl/certs/ca-certificates.crt

系统证书更新

系统不建议我们自己手动证书到这个目录和文件中，那我们如何添加证书到系统呢？系统提供了命令update-ca-certificates

man 8 update-ca-certificates

根据manpage介绍，update-ca-certificates更新etc/ssl/certs和ca-certificates.crt。我们将pem格式证书以.crt后缀放到/usr/local/share/ca-certificates，一个证书一个文件，然后执行命令就会自动添加到根目录证书中。

寻找证书

刚才不建议咱们自己添加证书，因为其中有些步骤是看不见的，比如c_rehash过程。寻找证书通过证书的subject，如果通过打开文件找到subject比对，那这样效率太低了，所以通过将证书的subject的hash值作为文件名，就可以提高寻找效率了，rehash就是干这个事。比如，我的系统中有个Go_Daddy_Class_2_CA.pem证书

ll /etc/ssl/certs | grep 'Go_Daddy_Class_2_CA'
# f081611a.0 -> Go_Daddy_Class_2_CA.pem 这个是rehash生成文件
# Go_Daddy_Class_2_CA.pem -> /usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt

可以通过以下命令看下hash值是否正确(当然是正确的)

openssl x509 -hash -fingerprint -noout -in $(readlink -f /etc/ssl/certs/Go_Daddy_Class_2_CA.pem)
# f081611a
# SHA1 Fingerprint=27:96:BA:E6:3F:18:01:E2:77:26:1B:A0:D7:77:70:02:8F:20:EE:E4

最后的.0是为了防止hash碰撞产生一样的值。

OpenSSL

OpenSSL默认情况使用系统证书库

openssl version -d # 打印OpenSSL目录
ls -l $(openssl version -d | tr -d '"' | awk '{print $2}') # 查看OpenSSL目录内容

通过查看OpenSSL目录，里面的certs文件夹默认是软链接到/etc/ssl/certs。因此OpenSSL编写代码使用默认证书库就是系统证书库

SSL_CTX_set_default_verify_paths(ssl_ctx);

浏览器

浏览器一般使用图形界面设置，但是我就觉得纳闷了，我在浏览器中设置了，但是根目录证书中没有，猜想肯定使用自己证书库，查找后确定是这样的。

Firefox和Chrome都使用sqlite存储用户导入证书，具体放在文件cert9.db中，早期放在cert8.db，这里咱们不溯源历史，有兴趣可以查看相关文档。同样，这个数据库不建议直接操作，浏览器都使用了NSS_Shared_DB管理数据库，提供了命令certutil操作，Ubuntu需要安装libnss3-tools

sudo apt install libnss3-tools

Chromium源码文档中有提供如何操作。

查找浏览器证书库地址

命令操作没啥问题，但是关键是制定证书的数据库地址。Ubuntu一般使用snap(尽管不想使用)按照Chrome，会放在snap目录$HOME/snap/[chromium|firefox]，如果没有snap目录，可以查看个人目录隐藏文件夹$HOME/.pki/nssdb，可能会不一样，可以通过查找方式查询：

find $HOME -type f -name 'cert9.db'

注意浏览器都是以用户(profile)形式生成cert9.db的，Chromium系列明显亲民点，可以使用比如$HOME/snap/chromium/current软链接到当前用户目录。

JKS(Java Key Store)

在前面查看/etc/ssl/certs目录时，看到有个文件夹java，翻看资料后发现，JAVA平台可以使用自己的证书库，支持多种存储格式，JKS的store位于$JAVA_HOME/lib/security/cacerts或者$JAVA_HOME/jre/lib/security/cacerts，JKS使用JDK提供的工具keytool管理。JKS的store默认密码是changeit。

# find JAVA_HOME
export JAVA_HOME=readlink -f $(which java) | sed 's/\/bin\/java//'

# List
keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit | head -5
# OR
keytool -list -cacerts -storepass changeit | head -5

# Add
keytook -import -alias testCert -keystore $JAVA_HOME/lib/security/cacerts -file ca_cert.crt

有用知识

工具mkcert是cert操作相关的库，里面有上面的相关信息，有兴趣可以仔细查看阅读。

HTTP3之key update

Michael — Wed, 29 May 2024 07:25:30 +0000

背景

Key update属于传输协议(QUIC)的特点之一，必须在handshake完成以后进行。
TLS1.3的key update使用专门的握手消息通知对方，我这边要修改密钥了，下次我们使用新的密钥沟通，起到密钥同步效果。
而QUIC-TLS中则使用short header packet中的Key Phase bit是否翻转(toggled)来通知key update。1-RTT包中默认为0，不兼容TLS1.3的key update message。
另外，QUIC-TLS要求双方同时更新keys,而TLS1.3双方是独立的处理。

实现

实现使用ngtcp2库

首先一方endpoing使用接口初始化key udpate, 告诉库应用程序想要更新keys，告知对方要key update

    if ((res = ngtcp2_conn_initiate_key_update(c->conn, timestamp())) != 0)
    {
        print_debug(ERROR, "ngtcp2_conn_initiate_key_update: %s(The previous key update has not been confirmed yet; or key update is too frequent; or new keys are not available yet.)", ngtcp2_strerror(res));
        return -1;
    }

使用ngtcp2的key update callback，他用于库告诉应用程序你需要key update了

const ngtcp2_crypto_ctx *crypto_ctx = ngtcp2_conn_get_crypto_ctx(c->conn);
const ngtcp2_crypto_aead *aead = &(crypto_ctx->aead);
int keylen = ngtcp2_crypto_aead_keylen(aead);
int ivlen = ngtcp2_crypto_packet_protection_ivlen(aead);

uint8_t rx_key[64], tx_key[64];
if (ngtcp2_crypto_update_key(c->conn, rx_secret, tx_secret,rx_aead_ctx,rx_key, rx_iv, tx_aead_ctx, tx_key, tx_iv, current_rx_secret, current_tx_secret, secretlen) != 0)
{
    print_debug(ERROR, "ngtcp2_crypto_update_key failed");
    return -1;
}

HTTP3之QUIC协议early data

Michael — Wed, 29 May 2024 07:24:57 +0000

背景

上回实现了QUIC协议的Connection Migration，本章实现early data。首先要浓情以这个概念，early data跟0-RTT不是一个概念，前者基于后者，在首次发送初始frame时候就将请求内容一起发送过去，这里涉及到PSK和session ticket概念，这个可以通过过QUIC协议整明白，网上也有文章说明，后面有机会整理。
https://datatracker.ietf.org/doc/html/rfc9000
https://datatracker.ietf.org/doc/html/rfc9001#name-0-rtt

实现

本文主要使用ngtcp2和nghttp3实现early data请求，下面主要描述主要代码步骤，如果不明白，可以参考全部文件。

OpenSSL session管理
TLS1.3目前已经抛弃前面版本使用的Session IDs, 转而使用PSK(Pre Shared Key)。OpenSSL库还是使用Session的概念管理TLS1.3的Session Resumption。
OpenSSL可以配置使用外部pem文件保存session数据

/* 在成功新建SSL Context后配置callback保存PSK数据 */
if (c->session_file)
{
     // session stored externally by hand in callback function
     SSL_CTX_set_session_cache_mode(c->ssl_ctx, SSL_SESS_CACHE_CLIENT | SSL_SESS_CACHE_NO_INTERNAL);
     SSL_CTX_sess_set_new_cb(c->ssl_ctx, new_session_cb);
}

Session callback中先使用max_early_data参数判断当前连接是否支持early data, 然后保存session数据

uint32_t max_early_data;
if ((max_early_data = SSL_SESSION_get_max_early_data(session)) != UINT32_MAX)
{
     fprintf(stderr, "max_early_data_size is not 0xffffffff: %#x\n", max_early_data);
}
BIO *f = BIO_new_file(c->session_file, "w");
if (f == NULL)
{
     fprintf(stderr, "Could not write TLS session in %s\n", c->session_file);
     return 0;
}

if (!PEM_write_bio_SSL_SESSION(f, session))
{
     fprintf(stderr, "Unable to write TLS session to file\n");
}

BIO_free(f);

新建SSL对象后, 加载session数据

BIO *f = BIO_new_file(c->session_file, "r");
if (f == NULL) /* open BIO file failed */
{
     fprintf(stderr, "BIO_new_file: Could not read TLS session file %s\n", c->session_file);
}
else
{
     SSL_SESSION *session = PEM_read_bio_SSL_SESSION(f, NULL, 0, NULL);
     BIO_free(f);
     if (session == NULL)
     {
          fprintf(stderr, "PEM_read_bio_SSL_SESSION: Could not read TLS session file %s\n", c->session_file);
     }
     else
     {
          if (!SSL_set_session(c->ssl, session))
          {
               fprintf(stderr, "SSL_set_session: Could not set session\n");
          }
          else if (!c->disable_early_data && SSL_SESSION_get_max_early_data(session))
          {
               c->early_data_enabled = 1;
               SSL_set_quic_early_data_enabled(c->ssl, 1);
          }
          SSL_SESSION_free(session);
     }
}

保存QUIC协议中的Transport Prameters为pem格式文件，用于下次early data时发送，可以在ngtcp2的handshake_completed的callback中保存

/* save quic transport parameters */
if (c->tp_file)
{
     uint8_t data[256];
     ngtcp2_ssize datalen = ngtcp2_conn_encode_0rtt_transport_params(c->conn, data, 256);
     if (datalen < 0)
     {
          fprintf(stderr, "Could not encode 0-RTT transport parameters: %s\n", ngtcp2_strerror(datalen));
          return -1;
     }
     else if (write_transport_params(c->tp_file, data, datalen) != 0)
     {
          fprintf(stderr, "Could not write transport parameters in %s\n", c->tp_file);
     }
}

在应用代码侧, 如果可以使用early data功能, 传递上次保存的Quic Transport Parameters,

/* load quic transport parameters */
if (c->early_data_enabled && c->tp_file)
{
     char *data;
     long datalen;
     if ((data = read_pem(c->tp_file, "transport parameters", "QUIC TRANSPORT PARAMETERS", &datalen)) == NULL)
     {
          fprintf(stderr, "client quic init early data read pem failed\n");
          c->early_data_enabled = 0;
     }
     else
     {
          rv = ngtcp2_conn_decode_and_set_0rtt_transport_params(c->conn, (uint8_t *)data, (size_t)datalen);
          if (rv != 0)
          {
               fprintf(stderr, "ngtcp2_conn_decode_and_set_0rtt_transport_params failed: %s\n", ngtcp2_strerror(rv));
               c->early_data_enabled = 0;
          }
          else if (make_stream_early(c) != 0) // setup nghttp3 connection and populate http3 request
          {
               free(data); // free memory which allocated in read_pem function
               return -1;
          }
     }
     free(data); // free memory which allocated in read_pem function
}

后续

下次继续QUIC特性key update。

HTTP3之QUIC协议中的Connection Migration

Michael — Wed, 29 May 2024 07:24:17 +0000

背景

Connection Migration是QUIC协议的特性之一。协议通信一般依赖网络标识比如(IP和port), 如果网络切换，通信需要重新开始，这对于频繁网络切换场景体验很差，比如无线网络使用APP时，网络切换可能需要重新登陆，终端用户可能莫名其妙。QUIC协议设计的时候，使用Connection ID标识对方，网络切换只要保证Connection ID正确就可以。Connection Migration就是描述这一过程交互规范。

细节

Connection Migration需要在Handshake完成后才能执行。发送方可能发送PATH_CHALLANGE帧给对方，对方可能发送PATH_RESPONSE帧回应。发送方也可以不发送probe frame, 直接切换继续通信。

实现

本地实验最好的方式就是变更port,比如从9000变为9001。下面使用ngtcp2库实现Connection Migration的代码片段。

生成新的UDP socket

struct sockaddr_in source;
source.sin_addr.s_addr = htonl(INADDR_ANY);
source.sin_family = AF_INET;
source.sin_port = htons(9001);
fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
bind(fd, (struct sockaddr *)&source, sizeof(source));
connect(fd, (struct sockaddr *)(&remote), remote_len);
getsockname(fd, (struct sockaddr *)&local, &local_len)

使用ngtcp2提供的Connection Migration接口。

int ngtcp2_conn_initiate_immediate_migration(ngtcp2_conn *conn, const ngtcp2_path *path, ngtcp2_tstamp ts)
int ngtcp2_conn_initiate_migration(ngtcp2_conn *conn, const ngtcp2_path *path, ngtcp2_tstamp ts)

ngtcp2提供了两种接口，都会发送PATH_CHALLANGE, 但是前者不会等待对方的PATH_RESPONSE就迁移。后者会等待对端的PATH_RESPONSE帧才迁移本地的网络路径。

ngtcp2_addr addr;
ngtcp2_addr_init(&addr, (struct sockaddr *)&local, local_len);
if (0) // nat rebinding
{
     ngtcp2_conn_set_local_addr(conn, &addr);
     ngtcp2_conn_set_path_user_data(conn, client);
}
else
{
     ngtcp2_path path = {
          addr,
          {
               (struct sockaddr *)&remote,
               remote_len,
          },
          client,
     };
     if ((res = ngtcp2_conn_initiate_immediate_migration(conn, &path, timestamp())) != 0)
     // if ((res = ngtcp2_conn_initiate_migration(conn, &path, timestamp())) != 0)
     {
          fprintf(stderr, "ngtcp2_conn_initiate_immediate_migration: %s\n", ngtcp2_strerror(res));
          return -1;
     }
}

处理path validation callback，比如对端回复了PATH_RESPONSE帧

int path_validation(ngtcp2_conn *conn, uint32_t flags, const ngtcp2_path *path,
                    const ngtcp2_path *old_path,
                    ngtcp2_path_validation_result res, void *user_data)
{
    (void)conn;
    if (old_path)
    {
        get_ip_port((struct sockaddr_storage *)(old_path->local.addr), ip, &port);
        fprintf(stdout, ", old local: %s:%d", ip, port);
    }

    if (flags & NGTCP2_PATH_VALIDATION_FLAG_PREFERRED_ADDR)
    {
        struct client *c = (struct client *)(user_data);
        memcpy(&c->remote_addr, path->remote.addr, path->remote.addrlen);
        c->remote_addrlen = path->remote.addrlen;
    }
    return 0;
}

最后

可以参考ngtcp2的example(https://github.com/ngtcp2/ngtcp2/tree/main/examples), 如果想看简单的，可以参考我的http3 client

HTTP3之编译nginx

Michael — Wed, 29 May 2024 07:23:38 +0000

关于

nginx目前最新版本提供了HTTP3服务，为了测试环境，本文记录从源码编译nginx的过程，其中包括依赖的编译。

环境

lsb_release -a
# Distributor ID: Ubuntu
# Description:    Ubuntu 22.04.4 LTS
# Release:        22.04
# Codename:       jammy

gcc --version
# gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

编译Nginx

编译或安装依赖

SSL Library

Nginx实现HTTP3底层依赖SSL库，可以选择BoringSSL, LibreSSL, QuicTLS，如果选择OpenSSL兼容层将不会提供early data的功能。本次我们选择QuicTLS，她也是基于OpenSSL修改的版本。

git clone --depth 1 -b openssl-3.1.5+quic https://github.com/quictls/openssl
cd openssl
./config enable-tls1_3
make
make install

注意

如果Linux机器上已经安装了libssl和libssl-dev，会有冲突和报错，本质问题及解决方法参考另外一篇文章，如果那边整不明白，可以查看man ldconfig，或者直接添加相关库的ld config文件，相信走到这里的，动态库这些个问题应该都差不多了:)。
编译默认动态库位于/usr/local/lib64，include文件位于/usr/local/include

其他依赖

apt install build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libxml2 libxml2-dev libxslt1-dev

编译Nginx

./configure \
--prefix=/home/michael/nginx \
--with-debug \
--with-http_ssl_module \
--with-http_v2_module \
--with-http_v3_module \
--with-cc-opt="-I/usr/local/include" \
--with-ld-opt="-L/usr/local/lib64" \
--with-cc-opt="-DNGX_QUIC_DEBUG_PACKETS -DNGX_QUIC_DEBUG_FRAMES -DNGX_QUIC_DEBUG_ALLOC -DNGX_QUIC_DEBUG_CRYPTO" \
--add-dynamic-module="$HOME/download/njs-0.8.4/nginx" # 添加njs模块
make
make install

默认情况下，nginx会安装到/root/nginx，进入文件夹后，默认会有如下文件夹

conf 里面有默认的配置文件nginx.conf，可以按照自己要求修改
html 里面对应的默认的index.html页面，可以按照自己要求修改
logs 里面对应nginx的access和error日志
sbin 包括nginx等命令
moudles 如果有添加模块编译比如njs，会有这个目录，包括模块的动态链接库

建议将nginx命令加入到path中

echo 'export PATH="${PATH}:/root/nginx/sbin"' >> ~/.bashrc

测试Nginx

使用如下命令启动nginx，再访问试下，看是否正常

nginx -V #查看详细信息
nginx -t -v #测试配置是否正常
nginx -s start # 启动nginx
curl localhost

配置HTTP3

自签证书

#! /usr/bin/env bash

# Generate self signed ca and server cert for localhost test

set -eou pipefail

CA="ca.pem"
CA_KEY="ca_key.pem"
SERVER_CERT="server_cert.pem"
SERVER_KEY="server_key.pem"
HOST="localhost"
IP="127.0.0.1"

# NOTICE quictls
export LD_LIBRARY_PATH=/usr/local/lib64
openssl version

# clean
rm -f $CA $CA_KEY $SERVER_CERT $SERVER_KEY

# 1. Generate self-signed certificate and private key
openssl req -x509 \
    -newkey rsa:4096 \
    -days 365 \
    -keyout "${CA_KEY}" \
    -out "${CA}" \
    -subj "/C=CN/ST=Hubei/L=Wuhan/O=QUIC/OU=QUICUNIT/CN=localhost/emailAddress=ca@example.com" \
    -noenc > /dev/null 2>&1

echo "CA's self-signed certificate DONE"
# openssl x509 -in "${CA}" -noout -text

# 2. Generate server cert and private key
openssl req -x509\
    -newkey rsa:4096 \
    -keyout "${SERVER_KEY}" \
    -out "${SERVER_CERT}" \
    -subj "/C=CN/ST=Hubei/L=Wuhan/O=QUIC/OU=QUICUNIT/CN=localhost/emailAddress=server@example.com" \
    -addext "subjectAltName=DNS:${HOST},IP:${IP}" \
    -CA "${CA}" \
    -CAkey "${CA_KEY}" \
    -copy_extensions copyall \
    -days 365 \
    -noenc

echo "Server's certificate DONE"
# openssl x509 -in "${SERVER_CERT}" -noout -text

# 6. Verify server certificate
openssl verify \
    -verbose \
    -show_chain \
    -trusted ${CA} \
    "${SERVER_CERT}"

注意脚本里面的IP和HOST，将生成的server_cert.pem和server_key.pem放到前面nginx的安装目录/root/nginx/certs，并且将ca_cert.pem添加到信任列表(浏览器可以直接导入)。

Nginx配置文件

修改/root/nginx/conf/nginx.conf中的server块添加如下内容

listen 443 quic reuseport;
listen 443 ssl;
http2 on;
server_name  localhost;

ssl_protocols TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384;
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers off;

ssl_certificate     /root/nginx/certs/server_cert.pem;
ssl_certificate_key /root/nginx/certs/server_key.pem;

重新启动Nginx, 测试HTTP3服务。这里ssl_cihpers和ssl_conf_command Ciphersuites跟man openssl-cihpers一致。

测试

浏览器

firefox可以直接使用http3服务, 关于浏览器导入自签证书，后面整个专门文章介绍。

curl

curl需要自编译添加http3服务，是另外一个话题了，curl官网关于编译写的很清晰

curl --http3 --cacert ca_cert.pem -v https://localhost

HTTP3之QUICTLS编译冲突问题

Michael — Wed, 29 May 2024 07:22:46 +0000

背景

本文主要介绍QUICTLS依赖库编译时与OpenSSL冲突问题和使用时找不到依赖库问题。

环境

操作系统: Ubuntu 22.04.4 LTS

编译工具: gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

QUICTLS库描述

OpenSSL官方支持QUIC协议进度太慢，于是出现了基于OpenSSL库改的QUICTLS库，原因是QUIC协议不是使用原生的TLS1.3协议。QUICTLS是基于OpenSSL修改了TLS1.3相关内容的库，OpenSSL用户态命令还是一样。

问题描述

本机上原先通过apt安装了OpenSSL3.x, 编译QUICTLS后, QUICTLS默认的openssl命令位于/usr/local/bin/openssl, 官方OpenSSL位于/usr/bin/openssl, 环境变量PATH中也是按照这个目录顺序。

如果键入openssl version，使用的是QUICTLS版本的openssl命令, 这时会报错:

openssl: error while loading shared libraries: libssl.so.81.3: cannot open shared object file: No such file or directory

问题原因

openssl 命令运行时找不到依赖的动态库, 使用ldd命令可以查看依赖共享库情况:

ldd $(which openssl)
     linux-vdso.so.1 (0x00007fff7****000)
     libssl.so.81.3 => not found
     libcrypto.so.81.3 => not found
     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb650****00)
     /lib64/ld-linux-x86-64.so.2 (0x00007fb65****000)

可以看到libssl.so.81.3和libcrypto.so.81.3找不到, 官方OpenSSL的动态库是libssl.so.3和libcrypto.so.3, 位于/usr/lib/x86_64-linux-gnu。QUICTLS动态库名称中 81 是 Q 的ASCII码值, 以示区分:

ls -l /usr/lib/x86_64-linux-gnu | grep -E 'libssl|libcrypto'
     -rw-r--r--  1 root root   9098630  2月  1 02:43 libcrypto.a
     lrwxrwxrwx  1 root root        14  2月  1 02:43 libcrypto.so -> libcrypto.so.3
     -rw-r--r--  1 root root   4451632  2月  1 02:43 libcrypto.so.3
     -rw-r--r--  1 root root    418464  2月 17  2023 libssl3.so
     -rw-r--r--  1 root root   1231268  2月  1 02:43 libssl.a
     lrwxrwxrwx  1 root root        11  2月  1 02:43 libssl.so -> libssl.so.3
     -rw-r--r--  1 root root    667864  2月  1 02:43 libssl.so.3

解决过程

解决过程也是理解Linux动态库加载流程的过程, 当程序执行时, 会通过一定的顺序寻找共享库加载。通过阅读ld.so的manpage文档 , 如果共享库没有包含slash, 按照以下的顺序寻找, 下面是原文:

If a shared object dependency does not contain a slash, then it
       is searched for in the following order:

       (1)  Using the directories specified in the DT_RPATH dynamic
            section attribute of the binary if present and DT_RUNPATH
            attribute does not exist.  Use of DT_RPATH is deprecated.

       (2)  Using the environment variable LD_LIBRARY_PATH, unless the
            executable is being run in secure-execution mode (see
            below), in which case this variable is ignored.

       (3)  Using the directories specified in the DT_RUNPATH dynamic
            section attribute of the binary if present.  Such
            directories are searched only to find those objects required
            by DT_NEEDED (direct dependencies) entries and do not apply
            to those objects' children, which must themselves have their
            own DT_RUNPATH entries.  This is unlike DT_RPATH, which is
            applied to searches for all children in the dependency tree.

       (4)  From the cache file /etc/ld.so.cache, which contains a
            compiled list of candidate shared objects previously found
            in the augmented library path.  If, however, the binary was
            linked with the -z nodefaultlib linker option, shared
            objects in the default paths are skipped.  Shared objects
            installed in hardware capability directories (see below) are
            preferred to other shared objects.

       (5)  In the default path /lib, and then /usr/lib.  (On some
            64-bit architectures, the default paths for 64-bit shared
            objects are /lib64, and then /usr/lib64.)  If the binary was
            linked with the -z nodefaultlib linker option, this step is
            skipped.

设置ELF文件的DT_RPATH, 上面文档指出这个参数过时了, 但是依然很多在使用。编译时指定GCC的相关参数, 比如-Wl,-rpath=/usr/local/lib64, 默认情况下文档说是设置DT_RPATH,

man 1 ld
...
--enable-new-dtags
--disable-new-dtags
     This linker can create the new dynamic tags in ELF. But the older ELF systems
     may not understand them. If you specify --enable-new-dtags, the new dynamic tags
     will be created as needed and older dynamic tags will be omitted.  If you 
     specify --disable-new-dtags, no new dynamic tags will be created. By default, the 
     new dynamic tags are not created. Note that those options are only available for ELF systems.
...

但是在我机器 Ubuntu22.04, GCC11.04 验证是默认设置的DT_RUNPATH, 如果要设置DT_RPATH, 需要显式关闭开关-Wl,--disable-new-dtags, 编译完成后可以使用如下命令检验:

readelf -d build/client | grep -E 'RUNPATH|RPATH'

可以设置LD_LIBRARY_PATH, 比如LD_LIBRARY_PATH="/usr/local/lib64" openssl version能正确运行
设置DT_RUNPATH, 方法同1, 但是需要她的使用顺序以及她只应用与DT_NEEDED的依赖库, 他们的子依赖不会使用这个参数指定的地址, 这也是争议的地方, DT_RPATH说是过时了，而且存在安全争议，但是在检索第一位管用
/etc/ld.so.cache本地缓存，这个需要在机器上自己设置，一般在目录 /etc/ld.so.conf.d/ 添加配置文件，然后刷新缓存:

echo "/usr/local/lib64" | sudo tee /etc/ld.so.conf.d/quictls.conf # 添加配置文件
sudo ldconfig # 刷新 ld.so.cache
openssl version # 现在能正常执行
# OpenSSL 3.1.4+quic 24 Oct 2023 (Library: OpenSSL 3.1.4+quic 24 Oct 2023)

解决办法

上述已经列出了所有的解决思路和相应解决办法，一般使用最后一种，会在本机添加多个config文件，比如，我的添加了依赖库QUITLS和ngtcp2的配置文件，配置文件内容也简单，就是依赖库所在地址，即上述的第四种方式。

例子

下面根据QUIC-ECHO工程依赖quictls的例子解释下GCC编译参数, 具体可以参见相关的 Makefile :

gcc -g -Wall -Wextra -DDEBUG -pedantic -Wl,-rpath=/usr/local/lib64  -o build/client client.c connection.c quictls.c stream.c utils.c  \
        -L/usr/local/lib64  \ # 影响后面的-lssl -lcrypto, 使她们使用quictls而不是openssl的共享库
        -lssl -lcrypto \ # 使用前面-L指定目录找到的依赖libssl.so.81.3 libcrypto.so.81.3
        -lngtcp2 -lngtcp2_crypto_quictls

TIPS

ld 默认搜索的动态库路径可以通过如下途径查看：

ld --verbose | grep SEARCH_DIR | tr -s ' ;' '\n'
# OR
ldconfig -v 2>/dev/null | grep '^/'

文件描述符和Bash中的重定向

Michael — Wed, 29 May 2024 07:21:51 +0000

前言

Linux中的文件描述符(File Descritor)和Bash中的重定向(Redirections)网上资料有很多描述，各种各样的都有，有的描述文档内容，有的很深入，但是很理论，本文将理论和实践结合，使用各种例证思考Bash的重定向操作实质。

文件描述符

底层关系结构

一切皆文件，文件描述符自然举足轻重，下面上一张经典图片

很清晰的描述了文件描述符底层运作。最左边一列为进程范围内的数据结构，每个进程都有一张文件描述符结构表(struct fdtable)，每一栏包含close_on_exec的flags和指向OFD(Open File Descriptor)的指针；第二栏(OFD)和第三栏(Inode Table)是系统级别的，其中第二栏包含打开的文件描述符的属性，状态和inode指针，第三栏包含文件的物理信息等。

每个进程都有自己的进程表，ls -l /dev/fd或者ls -l /proc/$$/fd显示当前进程下打开的文件描述符，如下图所示，标准输入输出和错误都指向当前$(tty)

lrwx------ 1 username usergroup 64 10月 26 14:01 0 -> /dev/pts/0
lrwx------ 1 username usergroup 64 10月 26 14:01 1 -> /dev/pts/0
lrwx------ 1 username usergroup 64 10月 26 14:01 2 -> /dev/pts/0
lrwx------ 1 username usergroup 64 10月 26 14:01 255 -> /dev/pts/0

如果想过滤fd，除了使用上述命令扩展下外，还可以使用比如lsof -P -n -p $$ -a -d 0,1,2,10

查看打开的文件表描述符信息cat /proc/$$/fdinfo/2

pos:    0
flags:  02000002
mnt_id: 26
ino:    3

各种操作的影响

dup操作属于process内部fd操作，根据输入fd复制新建fd，如图所示比如会在第一列ProcessA中新生成一行，新旧的file ptr指向OFD同一栏，比如fd1和fd20都指向23，所有她们具有相同的文档offset等属性。
fork会生成子进程，子进程默认继承父进程的描述符表，比如ProcessA的fd2和ProcessB的fd2，同时指向73的OFD。
不同进程中的open操作会生成各自的OFD行，但是会同时指向相同的inode信息，比如ProcessA中的fd0和ProcessB中的fd3，最后都指向了inode table中的1976，所以他们具有不同的file offset信息。

下面使用dup举例说明，打开一个文件，dup后，使用后者修改后，查看前者信息：

// gcc -Wall -Wextra -pedantic -o exapmle example.c
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>

void show(int fd1)
{
    int flags;
    long int offset = 0;
    flags = fcntl(fd1, F_GETFL);

    if (flags & O_APPEND)
    {
        fprintf(stdout, "%d has O_APPEND\n", fd1);
    }
    else
    {
        fprintf(stdout, "%d doesn't have O_APPEND attribute\n", fd1);
    }

    offset = lseek(fd1, 0, SEEK_CUR);
    if (offset == -1)
    {
        fprintf(stderr, "lseek failed: %s\n", strerror(errno));
    }
    fprintf(stdout, "file offset: %ld\n", offset);
    fprintf(stdout, "------------\n");
}

int main(int argc, char *argv[])
{
    int fd1, fd2;
    int flags;

    if (argc != 2)
    {
        fprintf(stderr, "Usage: %s file_path\n", argv[0]);
        exit(1);
    }

    fd1 = open(argv[1], O_RDWR);
    fd2 = dup(fd1);

    printf("fd1: %d, fd2: %d\n", fd1, fd2);

    show(fd1);

    flags = fcntl(fd2, F_GETFL);
    flags |= O_APPEND;
    fcntl(fd2, F_SETFL, flags);

    if (lseek(fd2, 3, SEEK_SET) == -1)
    {
        fprintf(stderr, "lseek set failed: %s\n", strerror(errno));
        exit(-1);
    }

    show(fd1);

    close(fd1);
    close(fd2);
    return 0;
}

Bash中的重定向(Redirectons)

Bash中的重定向就是操作文件和描述符的关系，自己的理解，符号化文件操作，天才设计。一行简单的命令，文件描述符的处理在命令执行之前。

顺序问题

官方文档关于重定向有个命令

ls > dirlist 2>&1
ls 2>&1 > dirlist

上述两个命令重定向先后顺序重要性，后者是不能满足1，2定向到dirlist文件要求，为什么呢，讲的很清楚，正确的前者是先执行> dirlist，将output指向dirlist文件，然后将error指向output，而此时output指向了dirlist，所有1，2均指向了文件dirlist。前面说到，标准的1，2，3是软链接到tty的，错误的命令先将2指向1，就是说2指向了1的终极指向tty，后面再将1指向了dirlist，没有达到目的。下面咱们验证下理论：

ls -l /dev/fd/ > test1.txt 2>&1
ls -l /dev/fd/ 2>&1 > test2.txt

cat test1.txt
lrwx------ 1 username usergroup 64 10月 26 20:18 0 -> /dev/pts/0
l-wx------ 1 username usergroup 64 10月 26 20:18 1 -> /home/shouhua/test.txt
l-wx------ 1 username usergroup 64 10月 26 20:18 2 -> /home/shouhua/test.txt
lr-x------ 1 username usergroup 64 10月 26 20:18 3 -> /proc/7756/fd

cat test2.txt
lrwx------ 1 username usergroup 64 10月 26 20:18 0 -> /dev/pts/0
l-wx------ 1 username usergroup 64 10月 26 20:18 1 -> /home/shouhua/test.txt
lrwx------ 1 username usergroup 64 10月 26 20:18 2 -> /dev/pts/0
lr-x------ 1 username usergroup 64 10月 26 20:18 3 -> /proc/7759/fd

注意上述使用/dev/fd/而不是/proc/$$/fd/，前者是unix系统先出现的，后者算是部分系统支持，Bash操作的是前者，如果使用后者，则没有变化。

文件offset影响

使用文件描述符处理文件需要注意file offset(pos)，比如下面例子','加到了offset=6的地方：

echo hello world > test.txt
exec 10<> test.txt
read -n 5 -u 10
echo $REPLY
cat /proc/$$/fdinfo/10 # 查看输出的pos参数
echo -n ',' >&10
cat test.txt
exec 10>&-

redirection各种操作

&用于分割>和<与fd，不然就不知道解析1>2，为算数表达式？还是重定向？所以涉及到两端为数字时候，想到&，有个特殊的情况，echo hello >& test.txt，但是这种情况也可以这样 echo hello &> test.txt。默认情况下10以上的fd可能被系统占用。

# 基础文件操作
echo hello >test.txt
echo hello >>test.txt
echo hello &>test.txt
cat < test.txt
# here document
# here string
# duplicate file descriptor，注意下面的`&`，下面两个效果一样，不同的是当11没有写的时候，前者默认0，后者默认1
exec 11<&10
exec 11>&10
# move file descriptor
exec 11>&10- # 复制10到11， 并且关闭10
exec 11<&10-
# open file for reading and writing
exec 10<>test.txt
# 系统分配fd
exec {fd}<>test.txt
echo $fd

重定向对应文件描述符各种操作

exec 11>&10复制，相当于dup，复制后，具有相同的OFD(Open File Descriptor)项，因此具有相同的offset
不同的terminal同时使用同一个fd打开相同的文件，类似第三种情况，不同的OFD项，但是指向相同的inode table项
使用ls -l /dev/fd/ > test.txt时，类似上面第二种fork情况，ls会使用子进程执行，复制父进程fd table，所以能通过test.txt文件看到父进程中的fd信息

Bash中子进程解惑

Michael — Wed, 29 May 2024 07:14:03 +0000

问题

Bash使用或者读各种文档时候，提到很多情况使用子进程执行，另外有的文档说执行命令时候，直接新建子进程，然后在子进程中执行，父进程等待知道子进程执行结束，对此有些疑惑，本文使用strace查看子进程和信号情况。本次使用Bash版本为5.1.x

bash --version
# GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
# ...

背景知识

新建进程和执行过程。Linux进程执行先使用fork库函数(glibc)调用系统调用clone新建子进程，然后在子进程中使用exec各种库函数(glibc)(比如execl等)调用execve系统调用执行命令。上面提到的两个系统调用clone和execve可以使用strace查看。
Bash有多种情况会使用子进程执行，比如$(command), |, 外部命令等
strace工具用于trace系统调用和信号，官方的man文档可以很快的掌握。本次主要使用如下命令查看：

# 2763是Bash进程pid
# `-f` 跟踪子进程
# `-v` 查看详细参数
# 如果想过滤掉signal，比如SIGCHLD，使用`-e signal=none`
# 如果想过滤掉exit和attach消息，使用`-qq`或者自定义`--quiet=exit`
sudo strace -f -e execve -p 2763

实操

使用`strace`查看子进程和信号情况

打开两个terminal，一个用于执行Bash命令，一个执行strace查看结果。

获取前者的进程id

echo $$ # 获取Bash pid，比如2763

在另一个terminal中输入上面所述的strace命令，使用获取的pid替换
在Bash终端中输入echo hello, 会发现strace终端没有输出
在Bash终端中输入echo hello | xargs printf "%s\n", 后者会有类似输出

strace: Process 2763 attached
strace: Process 3016 attached
strace: Process 3017 attached
[pid  3016] +++ exited with 0 +++
[pid  3017] execve("/usr/bin/xargs", ["xargs", "printf", "%s\\n"], 0x5575977a96d0 /* 55 vars */) = 0
strace: Process 3018 attached
[pid  3018] execve("/home/shouhua/.local/bin/printf", ["printf", "%s\\n", "hello"], 0x7fffdf063448 /* 55 vars */) = -1 ENOENT (No such file or directory)
[pid  3018] execve("/usr/local/sbin/printf", ["printf", "%s\\n", "hello"], 0x7fffdf063448 /* 55 vars */) = -1 ENOENT (No such file or directory)
[pid  3018] execve("/usr/local/bin/printf", ["printf", "%s\\n", "hello"], 0x7fffdf063448 /* 55 vars */) = -1 ENOENT (No such file or directory)
[pid  3018] execve("/usr/sbin/printf", ["printf", "%s\\n", "hello"], 0x7fffdf063448 /* 55 vars */) = -1 ENOENT (No such file or directory)
[pid  3018] execve("/usr/bin/printf", ["printf", "%s\\n", "hello"], 0x7fffdf063448 /* 55 vars */) = 0
[pid  3018] +++ exited with 0 +++
[pid  3017] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3018, si_uid=1000, si_status=0, si_utime=0, si_stime=1} ---
[pid  3017] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3016, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---

上述输出很清晰涉及到三个进程，pipe，xargs和printf，每个进程退出时发送SIGCHLD信号

使用`strace`查看执行细节

上述输出日志中可以看到各种执行时参数，这对于调式某些shell expansion情况特别有用，比如参数是否expansion等。比如ls *.txt和ls "*.txt"。
前者的输出，可以看到*.txt的使用pattern match进行了filename expansion

strace: Process 2763 attached
strace: Process 3055 attached
[pid  3055] execve("/usr/bin/ls", ["ls", "--color=auto", "plain.txt", "request.txt", "test.txt"], 0x5575977a96d0 /* 55 vars */) = 0
[pid  3055] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3055, si_uid=1000, si_status=0, si_utime=0, si_stime=1} ---

后者输出，对比之下，发现double quote下的没有进行filename expansion，并且Bash报错，'*.txt': No such file or directory

strace: Process 2763 attached
strace: Process 3071 attached
[pid  3071] execve("/usr/bin/ls", ["ls", "--color=auto", "*.txt"], 0x5575977a96d0 /* 55 vars */) = 0
[pid  3071] +++ exited with 2 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3071, si_uid=1000, si_status=2, si_utime=0, si_stime=0} ---

还可以通过给strace添加-v查看子进程继承的环境变量。当然上述也可以通过命令set -x输出调试结果。

`bash -c`执行情况

默认情况下会新建进程执行里面的命令，然后里面的命令如果是builtin命令在本进程执行，如果是外部命令则在子进程中执行，但是最后一个命令会在本进程执行。

strace: Process 2763 attached
strace: Process 3088 attached
[pid  3088] execve("/usr/bin/bash", ["bash", "-c", "echo hello; sleep .5; ls; hostna"...], 0x5575977a96d0 /* 55 vars */) = 0
strace: Process 3089 attached
[pid  3089] execve("/usr/bin/sleep", ["sleep", ".5"], 0x564ff0d5df60 /* 55 vars */) = 0
[pid  3089] +++ exited with 0 +++
[pid  3088] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3089, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
strace: Process 3090 attached
[pid  3090] execve("/usr/bin/ls", ["ls"], 0x564ff0d5df60 /* 55 vars */) = 0
[pid  3090] +++ exited with 0 +++
[pid  3088] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3090, si_uid=1000, si_status=0, si_utime=0, si_stime=1} ---
[pid  3088] execve("/usr/bin/hostname", ["hostname"], 0x564ff0d61c00 /* 55 vars */) = 0
[pid  3088] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3088, si_uid=1000, si_status=0, si_utime=0, si_stime=2} ---

Bash不同版本细节差异

在bash -c中执行的日志中发现，最后hostname命令没有新开子进程执行，而是直接在父进程3088中执行，但是在Bash另外一个版本4.4.x中是在子进程中执行的，可以猜测，新版本的Bash在bash -c执行命令时，如果只有一个命令或者命令组中最后一个命令的情况会在当前进程中执行，不新建子进程。

bash --version
# GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
# ...

以下为输出日志，注意hostname那行使用进程52098执行的，此时父进程为51801

strace: Process 51801 attached
strace: Process 52095 attached
[pid 52095] execve("/bin/bash", ["bash", "-c", "sleep .5; ls; hostname"], 0x5654ba8e1490 /* 31 vars */) = 0
strace: Process 52096 attached
[pid 52096] execve("/bin/sleep", ["sleep", ".5"], 0x55910809ad80 /* 31 vars */) = 0
[pid 52096] +++ exited with 0 +++
[pid 52095] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=52096, si_uid=3001, si_status=0, si_utime=0, si_stime=0} ---
strace: Process 52097 attached
[pid 52097] execve("/bin/ls", ["ls"], 0x55910809ad80 /* 31 vars */) = 0
[pid 52097] +++ exited with 0 +++
[pid 52095] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=52097, si_uid=3001, si_status=0, si_utime=0, si_stime=0} ---
strace: Process 52098 attached
[pid 52098] execve("/bin/hostname", ["hostname"], 0x55910809ad80 /* 31 vars */) = 0
[pid 52098] +++ exited with 0 +++
[pid 52095] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=52098, si_uid=3001, si_status=0, si_utime=0, si_stime=0} ---
[pid 52095] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=52095, si_uid=3001, si_status=0, si_utime=0, si_stime=0} ---

调试`trap`命令

trap "echo child exit" SIGCHLD

HTTP3之QUICTLS报错: "unable to get local issuer certificate"

Michael — Wed, 29 May 2024 07:12:57 +0000

2024-06-06更新

https://github.com/openssl/openssl/issues/9436 有人在OpenSSL仓库提出了这个问题，但是官方也没有时间整这个。

看了评论后，我感觉这个问题确实不是官方的问题，当然是我的观点哈。为什么呢？因为人家仓库默认出来空的，正常，况且那么多平台，每个平台的证书库都不一样，如果随着操作系统迭代，那这个库就有点太不正经了。。。，所以最好是让各个平台自己编译成平台包的时候添加就好，比如我们使用Ubuntu等系统的时候，默认(目录位于/usr/lib/ssl)会跟系统的证书库(/etc/ssl)链接在一起了，这些都是在系统包维护者编译包的时候干的。

https://salsa.debian.org/debian/openssl/-/blob/debian/unstable/debian/rules#L122 这个地址是debian编译OpenSSL使用的rules文件，其中122行明确的新建了软链接到debian平台的官方证书库(/etc/ssl)。

所以如果自己编译certs文件夹是空的，正常，别慌，但是通过问题找到这个问题就已经成功了。。。 :)

背景

最近使用QUICTLS整HTTP3时候，将自签证书加入到系统默认cert store,然后加载默认证书路径时总是报错:

"unable to get local issuer certificate"

QUICTLS在以前文章中介绍过。总的来说，就是为了让OpenSSL支持QUIC协议，基于OpenSSL仓库修改的仓库。系统原本安装了OpenSSL，通过编译QUICTLS后也安装了OpenSSL。注意依赖库时要分清楚使用哪个动态库。

本文是在使用QUICTLS动态库时导致的问题，QUICTLS依赖库默认位于/usr/local/lib64，下面代码打印出证书相关默认目录。

// test.c
#include <stdio.h>
#include <openssl/x509.h>

int main()
{
     const char *file_path = X509_get_default_cert_file();
     const char *dir_path = X509_get_default_cert_dir();
     const char *file_env = X509_get_default_cert_file_env();
     const char *file_env = X509_get_default_cert_dir_env();
     printf(format: "file: %s, dir: %s, file_env: %s, dir_env: %s\n", 
          file_path, dir_path, file_env, dir_env);

     return 0;
}
// 打印原生OpenSSL相关证书地址
// gcc -o test test.c -lcrypto && ./test
// file: /usr/lib/ssl/cert.pem, dir: /usr/lib/ssl/certs, file_env: SSL_CERT_FILE, dir_env: SSL_CERT_DIR

// 打印QUICTLS相关证书地址
// gcc -o test test.c -L/usr/local/lib64 -lcrypto && ./test
// file: /usr/local/ssl/cert.pem, dir: /usr/local/ssl/certs, file_env: SSL_CERT_FILE, dir_env: SSL_CERT_DIR

根本原因

根本原因是因为使用quictls后, OpenSSL使用了新的配置目录/usr/local/ssl, 里面只有certs文件夹, 而且里面是空的。

是的，怎么也没有想到是这么回事，就这个问题整了好长时间！！！

在进行证书验证时候, 找不到最终的根证书(找得到才怪), 就会报错: "unable to get local issuer certificate"

解决办法

解决办法是跟原生的OpenSSL目录(/usr/lib/ssl)里面设置的一样就好。

QUICTLS_DIR=/usr/local/ssl
sudo rmdir "$QUICTLS_DIR/certs"
sudo ln -s /etc/ssl/certs "$QUICTLS_DIR/certs"

sudo rmdir "$QUICTLS_DIR/private"
sudo ln -s /etc/ssl/private "$QUICTLS_DIR/private"

sudo rm "$QUICTLS_DIR/openssl.cnf"
sudo ln -s /etc/ssl/openssl.cnf "$QUICTLS_DIR/openssl.cnf"

/usr/local/bin/openssl version -a # QUICTLS的各种配置
openssl version -a # 原生OpenSSL的各种地址, 特别是OPENSSLDIR

另外，openssl命令始终使用原生的, 因为原生是/usr/bin/openssl, QUICTLS的openssl命令位于/usr/local/bin/openssl。

Ubuntu热点问题

Michael — Wed, 29 May 2024 07:10:16 +0000

最近从公司出来了，自己电脑重新启动，升级到Ubuntu24.04LTS, 目前基本稳定。使用过程中碰到一个需求，需要开启热点供手机联网。虽然是最新版本LTS, 其他版本应该也能使用。下面就遇到的问题整理下。

开启热点注意点
开启热点不能使用wifi, 所以如果要开启热点上网需要使用有线连接，以前使用MAC有类似经历，所以这个对我不是问题。
笔记本网络正常，开启热点正常，手机能连上，但是显示“无网络连接”
这个在网上找了半天答案，发现是由于防火墙问题，~~临时打开防火墙就好，完事后开启就好~~。
经过网友提醒，ufw可以不用关闭，添加相关ufw策略就好，主要是运行无线网卡数据进入，物理网卡可以路由数据，因为无线网卡数据会通过物理网卡流出。

sudo ufw allow in on wlp4s0

sudo ufw status numbered
sudo ufw delete

连上网络后，我们希望手机流量全部通过SOCKS5流量到server端口，比如本地的1080端口。这需要借助redsocks和iptables, 前者相当于本地的SOCKS5的客户端，接受手机流量，后者将手机流量全部导入到redsocks,通过他发送到SOCKS5服务端。

# 1. 安装和设置redsocks
sudo apt install redsocks
# 修改redsocks配置，主要是客户端和服务端接口
sudo vi /etc/redsocks.conf 
# 客户端监听所有网卡
# local_ip = 0.0.0.0
# 服务端接口设置
# port = 1080

# 2. iptable设置
sudo iptables -t nat -N REDSOCKS # 新建链

# 将无线网卡流量全部交给新链处理
sudo iptables -t nat -A PREROUTING -i wlp4s0 -p tcp -j REDSOCKS 

# 在nat表中添加新链处理，所有新链流量给到redsocks设置的客户端端口
sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-port 12345

# 相关删除操作，看着处理，最好有点iptables知识
sudo iptables -t nat -L PREROUTING -v --line-numbers
sudo iptables -t nat -D PREROUTING 2 # 数字需要看上面打印出来的行号
sudo iptables -t nat -D REDSOCKS 1 # 数字需要看上面打印出来的行号
# OR
sudo iptables -t nat -F REDSOCKS # 清空自定义链
# 规则全部删除完毕后，才能删除自定义链
sudo iptables -t nat -X REDSOCKS

自动化脚本

暂时不贴上来了，就是上面的放在一起，另外可以使用nmcli来自动化开启和删除hotspot

nmcli dev wifi hotspot con-name MyHotspot ssid ubuntu password 88888888
nmcli connection show | grep 'MyHotspot'
nmcli connection delete MyHotspot

DNS到底怎么运作的

Michael — Wed, 29 May 2024 07:09:07 +0000

背景

上文讲到Ubuntu中热点遇到的一些问题，涉及到了Ubuntu环境中网络管理的各个组件，总是很模糊。本文主要通过梳理DNS管理来整理Ubuntu中网络管理组件分工，以及DNS管理细节，本文不会涉及DNS协议细节。

环境

system：Ubuntu24.04
libc: glibc2.39

Ubuntu24.04网络管理

Linux环境中有多个网络管理组件，比如Network Manager, systemd-networkd等，不同组件有不同的上下文概念和配置方式，这对于网络管理和配置来说很有挑战性。后面推出了netplan，作为网络管理抽象层，使用YAML文件配置，使用上面列到的组建作为渲染器，一份配置文件适配多种渲染器，目前支持两种渲染器：Network Manager和systemd-networkd。

Ubuntu上面默认使用前者作为网络管理工具，可以查看man 5 NetworkManager.conf查看相关配置，配置文件位于/etc/NetworkManager/NetworkManager.conf。

网络有很多部分，比如无线，有线，DNS, 蓝牙等，NetworkManager使用不同的软件管理这些组件。无线部分使用wpa_supplicant(见wifi.backend), dhcp client端也有多种选择，默认使用internal。

其中DNS配置很有意思，根据manpage文档，DNS管理使用systemd-resolved(/etc/resolv.conf文件是软连接至/run/systemd/resolve/stub-resolv.conf), 也可以设置使用dnsmasq。

Ubuntu24.04 DNS管理

DNS基础知识 Cloudflare

DNS基础知识 ruanyifeng

resolvectl作为systemd-resolved的命令行管理工具管理包括DNS等。

systemd-resolved会在本地53端口起个DNS服务，并且将nameserver 127.0.0.53写入/etc/resolv.conf文件，那其他软件DNS查找这个文件，都是访问本地53端口服务(这个成为stub resolver)，但是真正的DNS服务server会藏在systemd-resolved的相关配置文件中，可以使用如下命令查看：

resolvectl status

它会列出所有网络设备的resolve信息，比如无线网卡的信息

    Link 3 (wlp4s0)
        Current Scopes: DNS
             Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    Current DNS Server: 192.168.0.1
           DNS Servers: 192.168.0.1
            DNS Domain: lan

上述的192.168.0.1作为DNS server一般是DHCP分配的，局域网内部的DNS server, 会去请求ISP的DNS server(DNS的迭代模式(Iterate)), 最后会进入递归模式，不断从ROOT(.), TLD nameserver(Top Level Domain)(.com), Authoritative nameserver(baidu.com)获取DNS信息，返回信息有各种所谓的Record(上述是全流程，当然可能存在缓存就不用走这些流程了，不然每次请求都消耗很多时间，另外服务器负载也太大了), 下面是常见的Record：

    A - IPV4
    AAAA - IPV6
    NS - Authoritative Name Server
    CNAME - 别名，比如www.baidu.com -> www.shifen.com
    MX - Mail
    TXT - Human readable document
    PTR - reverse DNS lookup, 由ip查域名

查看systemd-resolved的DNS缓存

使用sudo resolvectl statistic可以查看缓存情况，比如缓存个数，命中个数等。如果想查看缓存内容，使用sudo pkill -USR1 systemd-resolve, 然后在syslog中查看 sudo journalctl -u systemd-resolved > ~/resolved.txt。注意上面打印的数据是unique的数据，记录中可能有多个相同域名指向多个IP。

清空systemd-resolved的DNS缓存

清空所有cache

sudo pkill -USR2 systemd-resolve
# OR
sudo resolvectl flush-caches
sudo resolvectl statistic

glibc的DNS服务nsswitch和ncsd

为什么提到了glibc的DNS服务呢？因为在程序中使用比如函数getaddrinfo进行域名解析时候就使用了glibc提供的域名解析服务。下面梳理glibc的DNS相关流程。

glibc提供了各类名称解析服务，比如用户名->USER ID, 组名->GROUP ID, 域名->IP等，其中使用的模块是NSS(Name Service Switch), 这个不要跟Firefox的NSS(Network Security Services)模块弄混淆了。

NSSwitch

可以使用getent database key从数据库中获取NSS支持类型的存储数据, 比如

getent ahosts # get A record host
getent group # get group resolve record
man 5 nss
man 5 nsswitch.conf

getent ahost先使用缓存没有就使用getaddrinfo开始网络请求，详情见man getent。

nsswitch的配置文件见/etc/nsswitch.conf，我们关心DNS相关的是hosts

hosts:          files mdns4_minimal [NOTFOUND=return] dns

其中hosts值规定使用DNS查询的顺序，files代表/etc/hosts; mdns4\_minimal使用系统提供的multicast DNS解析服务，如果有这个服务，调用成功但是没有我们要的结果，就返回，如果没有这个服务，就使用系统提供的DNS服务查询(/etc/resolv.conf)。
使用nsswitch查询DNS整个过程，可以通过strace查看到上述描述细节

sudo strace -e trace=open,openat,connect -f ping -c1 www.baidu.com
     openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
     openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
     openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3
     openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
     openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libunistring.so.5", O_RDONLY|O_CLOEXEC) = 3
     openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
     openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY|O_CLOEXEC) = 5
# nscd缓存
     connect(5, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (没有那个文件或目录)
     connect(5, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (没有那个文件或目录)
# 使用了getaddrinfo, 所以会调用nsswitch查询dns
     openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 5
# hosts中配置files第一顺序
     openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 5
     openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 5
     openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 5
     openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 5
# 使用multicast DNS本地局域网所有example.local机器咨询DNS, 没有这个机器服务，下一个dns系统查询
     openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2", O_RDONLY|O_CLOEXEC) = 5
# hosts配置中的dns, 使用系统提供的dns服务, 即systemd-resolved
     connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
     openat(AT_FDCWD, "/etc/gai.conf", O_RDONLY|O_CLOEXEC) = 5
     ...
     connect(5, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("183.2.172.42")}, 16) = 0
     PING www.a.shifen.com (183.2.172.42) 56(84) bytes of data.
     openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 5
     connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
     64 bytes from 183.2.172.42: icmp_seq=1 ttl=51 time=25.3 ms

     --- www.a.shifen.com ping statistics ---
     1 packets transmitted, 1 received, 0% packet loss, time 0ms
     rtt min/avg/max/mdev = 25.305/25.305/25.305/0.000 ms
     +++ exited with 0 +++

其中可以修改/etc/nsswitch.conf中的hosts: file dns就不会有multicast DNS请求了, 修改是自动刷新的。

NOTICE：上述strace监听openat系统调用，open可能已经没有用了

ncsd

其中nscd(Name Service Cache Daemon)是全局各种解析服务的缓存，数据库中存储了各种解析类型映射的缓存。nscd manpage

网上看到这篇文章总结的不错。
注意，/etc/nscd.conf文件注释必须是首个字符为#，不然会服务可能启动失败。
主要提下调试，有两种方式，一种是使用日志文件，一种是在终端打印日志查看

使用日志文件修改/etc/nscd.conf中日志相关项, logfile(/var/log/nscd.log)和debug-file(0-5, 可以选择5), 然后重启nscd, 就可以查看(tail -f /var/log/nscd.log), 当ping或者getent hosts就会更新日志。
终端查看先暂停sudo systemctl stop nscd, 然后sudo nscd -g, 就会在终端打印日志了，但是也要设置日志等级。

总结

使用getent, ping这些命令都会走glibc提供的DNS服务，底层使用getaddrinfo函数; 其他命令如host(man 1 host), dig, nslookup走的是全局DNS解析服务，但是也可以自己配置DNS服务器直接网络请求。查看manpage, 会发现都是BIND 9提供的命令，在找BIND 9你就会发现他们为什么不走glibc的了 :)

编程语言DNS服务

目前有很多库提供DNS服务，比如libevent, c-ares。

很多语言如果底层使用使用glibc的函数也是走NSS那套，比如python，java等，但是也有的语言提供独立的DNS服务，比如自举后的golang。

NodeJS底层使用c-ares提供DNS服务。
libcurl可以使用自己提供DNS server,但是需要编译时候添加c-ares库; 默认走glibc那套。

Nodejs

Nodejs文档真心不错，最后说明了两种方式的特点和注意点。
默认情况(使用dns.lookup())，使用getaddrinfo走系统那套查询方式; 也可以使用 dns.resolve(), dns.resolve*(), and dns.reverse()，底层使用c-ares,直接网络请求DNS服务器获取解析结果。

小结

又整理了一篇无用知识，发现strace真是个好工具，解决问题都要想到她。

Forem: Michael

排序(collation)探究

现状

Linux系统排序

数据库支持情况

Postgresql

Mariadb

总结

语言支持

Java

Javascript

排序国际化

排序规则拓展

Language Tags

ICU中language tag扩展UNICODE

Unicode Collation Algorithm（UCA）

引用链接

Ubuntu上默认证书库是怎么回事

背景

系统证书库

系统证书更新

寻找证书

OpenSSL

浏览器

查找浏览器证书库地址

JKS(Java Key Store)

有用知识

HTTP3之key update

背景

实现

HTTP3之QUIC协议early data

背景

实现

后续

HTTP3之QUIC协议中的Connection Migration

背景

细节

实现

最后

HTTP3之编译nginx

关于

环境

编译Nginx

编译或安装依赖

SSL Library

其他依赖

编译Nginx

测试Nginx

配置HTTP3

自签证书

Nginx配置文件

测试

浏览器

curl

HTTP3之QUICTLS编译冲突问题

背景

环境

QUICTLS库描述

问题描述

问题原因

解决过程

解决办法

例子

TIPS

文件描述符和Bash中的重定向

前言

文件描述符

底层关系结构

各种操作的影响

Bash中的重定向(Redirectons)

顺序问题

文件offset影响

redirection各种操作

重定向对应文件描述符各种操作

Bash中子进程解惑

问题

背景知识

实操

使用strace查看子进程和信号情况

使用strace查看执行细节

使用`strace`查看子进程和信号情况

使用`strace`查看执行细节

`bash -c`执行情况

调试`trap`命令