#729 转载：Linux/UNIX 编程如何保证文件落盘

Linux 2022-11-10

我们编写程序 write 数据到文件中时，其实数据不会立马写入磁盘，而是会经过层层缓存。每层缓存都有自己的刷新时机，每层缓存都刷新后才会写入磁盘。这些缓存的存在是为了加速读写操作，因为如果每次读写都对应真实磁盘操作，那么读写的效率会大大降低。带来的坏处是如果期间发生掉电或者别的故障，还未写入磁盘的数据就丢失了。对于数据安全敏感的应用，比如数据库，比如交易程序，这是无法忍受的。所以操作系统提供了保证文件落盘的机制。我们来看下这些机制的原理和使用。

#728 为什么 C/C++ 不可替代

编程语言 Clang 2022-10-31

英文原文：https://levelup.gitconnected.com/why-modern-alternative-languages-never-replace-c-c-cbf0afc5f1dc
中文翻译：https://mp.weixin.qq.com/s/tr69w96gOO7ia81ttilgVA

总结一下：

  1. C/C++ 是优秀的系统级编程语言，无数基础设施是用 C/C++ 开发的
  2. C/C++ 可以完全控制机器，开发者拥有最大的灵活性
  3. C/C++ 性能非常好
  4. C/C++ 学术友好，简单，高效，直接（没有封装得很抽象）
  5. 所有操作系统提供 C API，其他语言也都提供了和 C 交互的方式

#727 服务丧尸？为什么

开发者 2022-10-31

发现一个问题，暂时没有任何思路：

一个线上执行了 66 天的服务，突然在前天凌晨 1:30 没有日志输出了，从外网连接不上，内网可以连上。

等后续有了进展再更新。

#726 CSDN 免登陆复制

个人 2022-10-27

CSDN 会拦截复制，提示需要登录。

近日在网上学到一招，在控制台输入一行代码就好了：

document.designMode = 'on'

#725 ping github.com 得到 127.0.0.1 问题

计算机网络 2022-10-27 
git clone git@github.com:tornado/tornado
Cloning into 'tornado'...
ssh: connect to host github.com port 22: Connection refused
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

ping github.com

正在 Ping github.com [::1] 具有 32 字节的数据:
来自 ::1 的回复: 时间<1ms
来自 ::1 的回复: 时间<1ms
来自 ::1 的回复: 时间<1ms

::1 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms，最长 = 0ms，平均 = 0ms
Control-C

ping -4 github.com

正在 Ping github.com [127.0.0.1] 具有 32 字节的数据:
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64

127.0.0.1 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms，最长 = 0ms，平均 = 0ms
Control-C

nslookup github.com
Server:         192.168.31.1
Address:        192.168.31.1#53

Non-authoritative answer:
Name:   github.com
Address: 127.0.0.1
Name:   github.com
Address: ::1

配置 DNS 为 AliDNS 223.5.5.5，233.6.6.6：

nslookup github.com
Server:         223.5.5.5
Address:        223.5.5.5#53

Non-authoritative answer:
Name:   github.com
Address: 20.205.243.166

问题依旧。

ping 20.205.243.166

正在 Ping 20.205.243.166 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。

20.205.243.166 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 0，丢失 = 3 (100% 丢失)，
Control-C

ping baidu.com

正在 Ping baidu.com [39.156.66.10] 具有 32 字节的数据:
来自 39.156.66.10 的回复: 字节=32 时间=23ms TTL=52
来自 39.156.66.10 的回复: 字节=32 时间=24ms TTL=52
来自 39.156.66.10 的回复: 字节=32 时间=23ms TTL=52

39.156.66.10 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 23ms，最长 = 24ms，平均 = 23ms
Control-C

总结：

  1. hosts 没有特殊配置
  2. 改成可用 DNS，问题没有修复
  3. ipconfig /flushdns 也不管用
  4. 重启也没有好

那就奇怪了，这个 ping 里面的本地回环地址是哪里来的呢？

最后，

ipconfig /displaydns 可以看到，还是用的回环地址
ipconfig /all 发现还有一个 DNSv6 配置。。。

DNSv6 设置成 AliDNS 的 IPv6 地址：2400:3200::1，2400:3200:baba::1 再试，

ping github.com

正在 Ping github.com [20.205.243.166] 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。
请求超时。

20.205.243.166 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 0，丢失 = 4 (100% 丢失)，

终于好了。😂

事情的起源是 git clone 失败，最后 git clone 可以了。
ping 不通，可能是网络问题，也可能是 github 网络配置。
这就不管了。

#723 Go 谚语

Golang 2022-09-13

得知了 Go 谚语这么个东西，搜索一番，找到：

  • https://go-proverbs.github.io/
  • https://github.com/jboursiquot/go-proverbs
  • https://www.youtube.com/watch?v=PAAkCSZUG1c

原来是类似 Python 之禅（import this）一样的东西。

  1. Don't communicate by sharing memory, share memory by communicating. 别通过共享内存通信，要通过通信共享内存。
  2. Concurrency is not parallelism. 并发不是并行。
  3. Channels orchestrate; mutexes serialize.
  4. The bigger the interface, the weaker the abstraction. 接口越大, 抽象越弱。
  5. Make the zero value useful.
  6. interface{} says nothing.
  7. Gofmt's style is no one's favorite, yet gofmt is everyone's favorite. 别争论风格问题，不管喜不喜欢，用 gofmt 就是了。
  8. A little copying is better than a little dependency. 少量的复制好过引入新的依赖。
  9. Syscall must always be guarded with build tags.
  10. Cgo must always be guarded with build tags.
  11. Cgo is not Go. 别用 cgo。
  12. With the unsafe package there are no guarantees. 慎用 unsafe 包（安全无保障）
  13. Clear is better than clever. 清晰的代码比聪明的代码好。
  14. Reflection is never clear. 慎用反射（代码不清晰）。
  15. Errors are values.
  16. Don't just check errors, handle them gracefully.
  17. Design the architecture, name the components, document the details.
  18. Documentation is for users. 文档是给用户的（注意代码本身的可读性）。
  19. Don't panic. 不要滥用 panic。

#722 转载：USB 的前世今生

USB 计算机硬件 2022-08-30

在人类的历史长河中，很少有一种技术或者传输标准能像USB那样跟我们的生活息息相关，甚至到了没有不行的地步。
USB对于今天的人们来说，就好像是空气，是水，是我们每天必需但是又熟视无睹的东西，没有多少人知道它从哪来，也没多少人关心它要往哪去，对于大多数人来说，它平凡得不能再平凡了。
但是，在我们“电子攻城狮”的眼里，它太有趣了，它是目前使用率最高的接口，它是我们身边林林总总电子设备之间的高速公路。
因此我们必须关注它，如果有必要，我们还不得不去了解如何才能实现它。作为一个USB开发者（电子爱好者），接下来我会为大家揭开USB神秘的面纱，带大家去了解USB是怎么出现并且逐渐演化的，以及在它出现后给我们带来了什么。

#720 HTTP/2 的几个特性

HTTP 2022-08-20
  • Server Push 服务器主动推送资源，客户端请求 A 的时候，服务器把 A 相关的资源 B, C, D 都一起推送给客户端。

  • Early Hints HTTP 103 状态码。客户端请求 A 的时候，

    1. 如果是普通情况，服务器返回 200 状态码，带上资源信息
    2. 如果应用上 Early Hints，服务器返回 103 状态码，带上需要资源信息（Link 头），然后是资源信息

    好处就是节省了浏览器解析 HTML 获取子资源信息的延迟。刚解析 103 头，就可以开始请求子资源了。
    就最近的几个月，主流浏览器开始提供支持。

  • Preload Critical Assets 就是 HTML link 头中的 rel="preload"，提前加载文件，避免按照文件解析生成的调用链顺序来加载，而提升资源加载速度。

Chrome 将禁用 HTTP/2 服务器推送（Server Push）支持

谷歌博客显示，在 Chrome 106 和其他基于 Chromium 的浏览器的下个版本中，默认情况下将禁用对 HTTP/2 服务器推送（HTTP/2 Server Push）的支持。

HTTP/2 允许服务器在实际请求之前 “推送” 服务端可能需要的资源， HTTP/2 的 Server Push 特性解决了 HTTP/1.x 的无脑按顺序加载资源的问题，本意是提高网页的响应性能。

然而这功能逻辑本身就有问题，比如资源存放在单个业务服务器上，并行推送多个静态资源只会降低响应速度，性能不升反降。而对于前后端分离的业务来说，HTTP/2 本身就支持多路复用，server push 只能稍微降低浏览器解析 html 的时间，对现代浏览器来说性能提升可以忽略不计。

HTTP/2 时代也只有 1.25% 的 HTTP/2 站点使用了这个特性。在 HTTP/3 出来之后，该功能更是彻底被遗忘了，最新的分析中，网站对 HTTP/2 的支持率从 1.25% 下降到 0.7%。

替代方案

103 Early Hints  是 Server Push 的首选替代方案，它具有 Push 的许多优点，而缺点则少得多。与服务器推送资源不同，103 Early Hints 只向浏览器发送可能受益于请求的资源提示。浏览器可以控制它是否需要这些资源，比如浏览器已经在 HTTP 缓存中拥有这些资源，则无需额外加载。

预加载关键资源是另一种选择，它允许页面和浏览器一起工作，在页面加载的早期抢先加载关键资源。它不如 Server Push  或 Early Hints   快 —— 但它不会延迟关键页面资源，而另外两种解决方案都可能发生这种情况。

参考资料与拓展阅读

#719 代码中的 TODO 注释

开发者 2022-08-19

《Stop Using TODO for Everything》建议采用更加明确的标记来注释代码：

  • FIXME/BUG 需要修复（缺陷）
  • CHECKME/REVIEW 需要审查
  • DOCME 需要文档
  • TESTME 需要测试
  • HACK/OPTIMIZE 需要优化

我就是喜欢在代码中写 TODO，以后可以照着这个建议搞些花样。

#718 2FA：双因素身份认证

Auth 信息安全 2022-08-19

2FA / MFA

双因素 / 多因素认证，就是指处理密码之外，再加一些辅助手段用来加强认证。

常见的 2FA 方式：

  1. 密码 + 短信验证码
  2. 密码 + 微信公众号推送验证码
  3. 密码 + 身份验证器
  4. 密码 + U盾

人体特征

应该有人脸，指纹，声纹，虹膜等方式的组合（甚至在异形 4 中有吹气的方式），这些在我们的数字生活中这些认证方式多少都有一些体验吧。

动态口令卡

事先给客户一张密码表，然后需要的时候要求客户按要求输入指定位置的数字用来验证身份。

原理应该和微信让用户指认哪个头像是自己的好友一样。

证书

银行的 U 盾

OTP（动态密码）

一次性密码，One Time Password

TOTP 的全称是"基于时间的一次性密码"（Time-based One-time Password）。它是公认的可靠解决方案，已经写入国际标准 RFC6238。

不知道密码学上是什么原理，只知道可以每分钟生成一个 6 位密码。只要双方算法和密钥一致，就能实现认证。

软件的，谷歌身份验证器，微软身份验证器，这种。
硬件的，银行的动态口令，早些年网易的将军令，这种。

FIDO

FIDO（Fast IDentity Online，线上快速身份验证）联盟是成立于2012年7月的行业协会。其宗旨是为解决强制认证设备的交互性和用户面临大量复杂的用户名和密码。

主要是一些巨头（Google，微软）和搞 2FA 硬件设备的厂商组件的联盟，目标是通过一个标准，让符合标准的技术能够到处适用，用起来更方便、更安全。
官方定义的愿景是 “减少世界对密码的依赖”。

协议：

  1. Universal Authentication Framework (UAF)
    UAF 1.0 Proposed Standard (December 8, 2014)
    UAF 1.1 Proposed Standard (February 2, 2017)
    UAF 1.2 Review Draft (November 28, 2017)
  2. Universal 2nd Factor (U2F)
    U2F 1.0 Proposed Standard (October 9, 2014)
    U2F 1.2 Proposed Standard (July 11, 2017)
  3. FIDO 2.0 (FIDO2, contributed to the W3C on November 12, 2015)[4]
    FIDO 2.0 Proposed Standard (September 4, 2015)
  4. Client to Authenticator Protocol (CTAP)
    CTAP 2.0 Proposed Standard (September 27, 2017)
    CTAP 2.0 Implementation Draft (February 27, 2018)

说明：

  1. FIFO 由两部分组成：通用认证框架 (UAF) 和 通用第二因素 (U2F)。
    我的理解：
    1. UAF 是一套新设计的认证方案，系统对设备进行认证，然后设备在本地通过 PIN 码，指纹等方式（主要是生物特征）对客户进行认证。
      试图取代现在简单密码比对的认证方式。
    2. U2F 是主密码 + 硬件口令，最早由 Yubico 和 Google 设计。。
  2. 现在流行的是 FIDO 联盟和 W3C 共同制定的 FIDO2，将 2FA 的相关技术拓展到 Web 领域。
    FIDO2 主要由 W3C Web 身份验证（WebAuthn）和 CTAP2 （客户端到身份验证器协议）组成。
    浏览器的 WebAuthn JS API + 客户端的 CTAP2。
    WebAuthn 向前兼容 CTAP1 / U2F。
  3. CTAP 支持 USB，蓝牙，NFC 三种方式。
  4. CTAP1（Client-to-Authenticator）约等于 U2F
  5. CTAP2，CBOR 数据格式？
  6. 主流浏览器都已支持 WebAuthn，也就是说网站可以接入了。


阿里巴巴的 IFAA
腾讯的 TUSI

今天的《科技爱好者周刊（第 219 期）：如何防止帐号被黑》中说：

上周有一起安全事件。两家著名的美国互联网公司----Twillo 和 Cloudflare----被攻击了，前者还被攻破了。

手段还是钓鱼，不止钓密码，也钓了 TOTP 验证码。所以阮一峰在文章中的意思是，物理密钥会更安全。
这么说确实有道理，其实我好多次都想买一个，就是太贵，两三百。

阮一峰还提到，有部分实践（Web Authentication）在尝试采用本地设备的认证手段作为第二因子，比如手机和笔记本上的指纹识别和人脸识别。

还是希望有厂商能够推出廉价一些的 Key。

参考资料与拓展阅读

#717 Chrome/Edge 批量删除历史记录

浏览器 Chrome 2022-08-14
  1. 根据域名等关键字搜索出来相关记录
    在历史记录上点击右键菜单中的 来自相同站点的更多内容 也行，其实就是按域名搜索
  2. 选中第一个，然后滚动到最下面，按住 Shift，选中最后一个
  3. 点击右上角的 删除 按钮