码厩技术博客

#380 Linux 磁盘使用情况检查

我们一般使用 du 命令，不正是做这个用的么（Disk Usage）？

du -hsc          # 当前目录占用空间大小
du -hsc *.log*   # 查看文件大小
du -hsc a b c d  # 查看指定几个目录的大小

#379 SSL/TLS 相关信息

名称

TLS, Transport Layer Security, 传输层安全性协议
SSL, Secure Sockets Layer, 安全套接层

历史

1. 90 年代，WWW 先驱网景公司开发 SSL，用于提升 Web 安全性。
2. 1996，SSL 开始由 IETF (The Internet Engineering Task Force, 互联网工程任务组) 标准化，最后在 1999 年成为 RFC 2246，名字改成了 TLS。
3. TLS 1.0 约等于 SSL 3.0
4. 微软 IE 也支持 TLS 1.0
5. 现在，SSL 时期的三个版本，均已被彻底废弃。
6. 由于历史原因，很多场合如果不严格区分版本，SSL 等于 TLS。
7. TLS 1.2 在 2008 年成为 IETF 推荐的版本（2018 年被 TLS 1.3 淘汰）
8. TLS 1.3 于 2018 年 8 月发表，它的突破性改进包括握手更快从而加快连接速度、简化支持的加密方式、速度和性能优于 TLS 1.2。

旧版本的废弃

1. SSL 1.0 从未发布。
2. 2011 年 3 月，RFC 6176 删除了对 SSL 的兼容，避免通过协商使用已经被废弃的 SSL 2.0 而出现安全问题。
3. 2014 年 10 月，Google 发现 SSL 3.0 有设计缺陷，可以将 TLS 安全连接强行降级到过时且不安全的 SSL 3.0。之后，Google 在自己公司相关产品中陆续禁止回溯兼容，强制使用 TLS 协议。
4. 2015 年，正式废弃 SSL 3.0。
5. 微软、Google、苹果、Mozilla 四家浏览器厂商在 2020 年终止支持 TLS 1.0 及 1.1。
6. 2021 年 3 月，RFC 8996 标准弃用了 TLS 1.0 和 TLS 1.1。

现在主流的是 TLS 1.2 和 TLS 1.3。

相比之下，TLS 1.3 安全性更好，性能也更好。
搜索一下 tls1.2 tls1.3 difference 或者 tls1.2 tls1.3 performance 就能看到很多相关比较。

作用

SSL/TLS 的本质就是非对称加密。

细节

安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。
该协议由两层组成：

• TLS 记录协议（TLS Record）
• TLS 握手协议（TLS Handshake）

握手协议（handshake protocol）
密钥规格变更协议（change cipher spec protocol）
应用数据协议（application data protocol）
警报协议（alert protocol）。

参考资料与拓展阅读

• 维基百科(en)，Transport Layer Security
• 维基百科(zh)，传输层安全性协议
• OSCHINA, IETF 正式弃用 TLS 1.0 和 TLS 1.1
• OSCHINA, npm registry 正在弃用 TLS 1.0 和 TLS 1.1
• OSCHINA, 传输层安全协议 TLS 1.3 RFC 8446 正式发布
• OSCHINA, HTTP/2 没有强制要求 TLS

  HTTP/2 规范并没有要求使用 TLS，但是主流浏览器开发商全部选择在 TLS 之上实现 HTTP/2。

• OSCHINA, 微软将在 9 月禁用 TLS 1.0/TLS 1.1 传输协议

  微软宣布从 2022 年 9 月 13 日起， Internet Explorer 和 EdgeHTML（ WebView 控件的呈现引擎） 将默认禁用 TLS 1.0 和 1.1。禁用 TLS 1.0 和 1.1 的工作早在 2020 年提出，但当时新冠病毒在全球爆发，大量开发者居家办公，微软只能推迟淘汰 TLS 1.0 和 1.1 的时间。
  注意：不是弃用，仍然可以通过配置打开相关支持。

#378 一些不足道哉的开发经验

1. 编码：
2. 遵守一个社区比较公认的编码规范和编程实践，不要试图自己搞一套。
   尤其是命名风格保持统一。
3. 拆分的思想：分服务，分模块，分文件，分函数，分层。
   不同部分之间的依赖应该非常清晰，严禁无序调用。
4. 代码复用：尽可能不要重复写类似的代码。
   业务无关代码应该采用公共库，组织内复用，不要重复实现相同的逻辑
5. 对于功能实现应该有一定的预留空间，对可能发生的调整有一定的包容性
6. 函数简单：一个函数应该尽可能简单，代码行数少，逻辑清晰。
7. Git：
8. 分支管理
9. 提交管理
   1. 每次代码提交应该有一个明确的目的，和这个目的无关的代码应该另外提交。
      尽可能保证每次提交修改的量比较少。
   2. 提交的时候应该做代码风格检查，没有通过的拒绝接受
10. 测试：
11. 单元测试必须要有, 要比业务代码接受更严格的检查
12. 我认为写单元测试的时间应该开发的时间差不多
13. 覆盖率要求
14. 为了保证测试的便利，可以对现有实现进行调整（开发时就应该考虑到测试流程）
15. 集成测试，回归测试，功能测试，性能测试
16. 自动化：
17. 自动化测试
18. 自动化部署
19. 日志：
20. 格式统一
    重点是要能方便地定位到问题, 比如对于同一个请求的所有日志加上相同的标识
21. 日志级别一定要分清楚，方便做异常监控
22. 日志监控
23. 对于请求响应类型的服务，建议分成以下日志文件：
    1. main.log / app.log 主日志，INFO 级别, 保留 15 天
    2. trace.log 调试日志，DEBUG 级别, 保留 3 天
    3. error.log 异常日志，ERROR 级别, 保留 30 天, 可以考虑加上
    4. monitor.log 监控日志
    5. access.log 访问日志
    6. api.log API 调用日志
    7. event.log 重要的时间点记录下来，比如 REQUEST_START, REQUEST_END 等, 保留 30 天
    8. data.log / db.log 数据库操作（包含 Redis）, 保留 30 天
    9. message.log / mq.log MQ 消息, 保留 30 天
24. 对于有监控需求的日志应该加上特殊标识，比如 Monitor:Daily, Monitor:5m, Monitor:UpstreamError
    这个根据监控策略来。
25. 新开发的逻辑可以加入尽可能多的调试信息，日后根据实际情况调整。
26. 设计：
27. 需求评审之后，就要做设计评审（方案评审）
    1. 如果涉及数据库调整，应该由数据库团队参与评审
    2. 如果设计加购调整，应该由架构团队参与评审
28. 对外接口调整需要谨慎
29. 其他：
30. 应当尽可能了解自己参与的项目，重要的数据应该能记住，比如重点客户信息，性能指标，流量等。

#377 Linux 相关标准

• Linux Standard Base (LSB)
• Filesystem Hierarchy Standard (FHS)
• Application Programming Interface (API) Standards
• Single UNIX Specification version 4, The Open Group
• Single UNIX Specification version 3, The Open Group
• Single UNIX Specification version 2, The Open Group
• DWARF Standards
• DWARF Version 4
• DWARF Version 3
• DWARF Version 2.0
• ELF and ABI Standards
• Tool Interface Standard (TIS) Portable Formats Specification, version 1.1
• Tool Interface Standard (TIS) Portable Formats Specification, version 1.2
• System V ABI Edition 4.1
• System V ABI - DRAFT 24 April 2001
• Processor Specific ELF documents
• System V Application Binary Interface Intel386 Architecture Processor Supplment, Fourth Edition
• Intel Itanium Processor specific ABI
• System V Application Binary Interface x86-64 Architecture Processor Supplement Draft Version 0.95 | v0.98 | v0.99
• System V Application Binary Interface MIPS RISC Processor Supplment, 3rd Edition
• System V Application Binary Interface PowerPC Processor Supplment. This is one of two known PPC ELF standards. This one was developed by SunSoft. The two versions are not identical, and applications can only conform to one or the other, while it seems possible for an implementation to support both simulaneously.
• ARM Processor Supplment
• Processor-Specific ELF Supplement for PA-RISC
• Motorola 8 and 16 bit Embedded ABI
• Application Binary Interface (ABI) Specifications/Standards
• gLSB v1.2, Linux Standard Base
• archLSB-IA32 v1.2, Linux Standard Base
• archLSB-PPC32 v1.2, Linux Standard Base
• 3DNow! (AMD K6 & Athlon), AMD
• AMD Extensions to the 3DNow1 and MMX Instruction Set, AMD
• Linux for S/390 (32bit) ELF ABI Supplement, IBM
• Linux for zSeries (64bit) ELF ABI Supplement, IBM
• C++ ABI for Itanium, v1.86
• C++ ABI for Itanium, v1.83
• C++ ABI for Itanium, v1.75
• Intel Itanium Processor-Specific ABI
• Related ABI Projects
• Moblin 1.9.0 spec
• Moblin 1.9.1 spec

参考资料与拓展阅读

• LSB, Referenced Specifications

#376 丰田生产方式与精益生产

丰田生产方式（Toyota Production System，简称 TPS）是一种以精益生产为核心的生产方式，由日本丰田汽车公司所创立。TPS 的目标是通过消除浪费、提高效率和质量，实现生产过程的最优化，从而提高企业的竞争力。

TPS 的核心思想是“精益生产”，即通过消除浪费来提高生产效率和质量。TPS 将浪费分为七种类型，包括：

1. 过产：生产过多的产品，导致库存过剩。
2. 等待：生产过程中的等待时间，如等待零部件、等待机器维修等。
3. 运输：产品在生产过程中的运输过程中产生的浪费。
4. 过程：生产过程中的不必要的动作和步骤。
5. 库存：过多的库存会占用空间、增加成本，并可能导致产品过期或损坏。
6. 过度加工：对产品进行不必要的加工，增加成本和时间。
7. 缺陷：产品出现缺陷，需要进行返工或废品处理。

TPS 通过消除这些浪费，实现生产过程的最优化。具体来说，TPS 采用了以下几种方法：

1. 一次性流程：生产过程中，每个工人只负责一道工序，避免了多次加工和运输。
2. 拉动生产：根据客户需求，生产所需的产品数量，避免了过产和库存过剩。
3. 精益生产：通过不断改进生产过程，消除浪费，提高效率和质量。
4. Jidoka：自动化生产过程中，发现异常情况时，自动停机，避免生产缺陷产品。
5. Kaizen：不断改进生产过程，提高效率和质量。

TPS 的成功得益于其对生产过程的精细管理和不断改进的精神。TPS 的思想已经被广泛应用于各个领域，成为了一种重要的管理理念。

#375 浏览器端存储

早期只有一种浏览器存储方式，就是万维网早期，由网景公司设计，加入了 HTTP 1.0 的 Cookie。
HTTP5 的时代，一次性加入了三种 API，分别是 Web Storage，IndexedDB，Web SQL。

• Cookie：通过小型文本文件，在浏览器端存储一些字符类型 key-value 数据，支持设置一些属性。
• 有单个 Cookie 的大小限制，也有 Cookie 总数限制。这个因浏览器不同而不同（大小尽可能控制在 4KB 以内）。
• 每一次 HTTP 调用都会自动带上，发送给服务器端。
• Web Storage：可以存储大量字符类型的 key-value 数据。
• localStorage：没有时间限制。
• sessionStorage：会话结束时自动清除。
• IndexedDB：NoSQL 数据库，可以存储大量的结构化数据。API 相对复杂一丢丢
• 功能强大，甚至支持事务和索引。
• 异步 API。
• Web SQL：基于 SQL 的浏览器端数据库，后来被废弃。

Cookie

Set-Cookie: name=value; expires=Mon, 21 Oct 2019 07:28:00 GMT; path=/; domain=.example.com; secure; HttpOnly

• expires 过期时间，GMT 格式。如果不设置该属性，则 Cookie 的生命周期为当前会话，即关闭浏览器后 Cookie 就会被删除。
• path 路径，表示该 Cookie 归属于哪个路径。默认为当前页面的路径。
• domain 域名，表示该 Cookie 归属于哪个域名。默认为当前页面的域名。
• secure 只能通过 HTTPS 协议传输，不能通过 HTTP 协议传输。
• HttpOnly 只在网络传输时使用，不能通过 JavaScript 访问。

Web Storage

localStorage.setItem("key", "value");
var value = localStorage.getItem("key");

sessionStorage.setItem("key", "value");
var value = sessionStorage.getItem("key");

• setItem(key, value) 存储数据
• getItem(key) 读取数据
• removeItem(key) 删除数据
• clear() 清空数据 (删除所有的键值对)
• key(index) 获取键名 (根据索引获取对应的键名)

IndexedDB

没有研究过。

// 打开数据库
var request = indexedDB.open("myDatabase", 1);

// 创建对象仓库
request.onupgradeneeded = function (event) {
  var db = event.target.result;
  var objectStore = db.createObjectStore("users", { keyPath: "id" });
  objectStore.createIndex("name", "name", { unique: false });
  objectStore.createIndex("age", "age", { unique: false });
};

// 存储数据
request.onsuccess = function (event) {
  var db = event.target.result;
  var transaction = db.transaction(["users"], "readwrite");
  var objectStore = transaction.objectStore("users");
  var user = { id: 1, name: "张三", age: 20 };
  var request = objectStore.add(user);
  request.onsuccess = function (event) {
    console.log("数据存储成功");
  };
};

// 读取数据
request.onsuccess = function (event) {
  var db = event.target.result;
  var transaction = db.transaction(["users"], "readonly");
  var objectStore = transaction.objectStore("users");
  var index = objectStore.index("name");
  var request = index.get("张三");
  request.onsuccess = function (event) {
    var user = event.target.result;
    console.log(user);
  };
};

#374 城下之盟（写在十一周年纪念日）

与老婆签订的不平等条约，应她要求公开 😭

#373 Git Hooks

https://mp.weixin.qq.com/s/67qBDteTmHROeMwOBUeyaw
如何通过 Git 和 Husky 添加提交钩子并实现代码任务自动化

示例

pre-receive

#!/usr/bin/env python

"""
每个人都只能提交代码到 username-date-branchName
username 是 git 用户名
date 是 mmdd 日期
branch 是分支描述，支持小写字母、数字、横杠，2 到 16 个字符
"""

import re
import subprocess
import sys

# 获取提交者的用户名
author = subprocess.check_output(['git', 'config', 'user.name']).decode().strip()

# 获取提交的分支名称
branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref', 'HEAD']).decode().strip()

# 定义分支名称的正则表达式
branch_pattern = r'^%s-\d{4}-[a-z0-9\-]{2,}$' % (author,)

# 检查分支名称是否符合正则表达式
if not re.match(branch_pattern, branch):
    print('Error: Branch name "{}" does not match the required pattern "{}"'.format(branch, branch_pattern), file=sys.stderr)
    sys.exit(1)

# 解析日期并检查其是否合法
try:
    _, date_str, _ = branch.split('-')
    month, day = int(date_str[:2]), int(date_str[2:])
    if month < 1 or month > 12 or day < 1 or day > 31:
        raise ValueError
except ValueError:
    print('Error: Invalid date format in branch name "{}"'.format(branch), file=sys.stderr)
    sys.exit(1)

#372 邮件安全：DMARC [编辑中]

:) 本文正在编辑中，暂时不提供浏览...

#371 邮件安全：SPF

简介

SMTP 会话中，发行方会通过 MAIL FROM 命令告诉收信方，这封邮件是谁发出的。

但是，由于邮件系统的设计上没有考虑如何对垃圾邮件进行有效防范，收信方需要一个机制来判断这封邮件的来源是否可靠。因此，人们提出了 SPF 方案：

1. 每个邮件服务都需要为自己的发信域名在 DNS 中配置一下 SPF 记录（TXT 类型），记录值是出信 IP。
2. 收信方拿到 MAIL FROM 地址之后，使用发信方 IP 地址和发信域 DNS 中记录的 IP 地址做一个比对。如果匹配，说明来源正确，否则，这封邮件可以被视为垃圾邮件，直接返回投递失败（硬退）。

该方案 2006 年提交到 Network Working Group 成为草案，然后 2014 年成为建议标准。

注意：SPF 只是验证了邮件确实是从发信域所在网络投递出来的，但是不能防止邮件伪造和欺诈。应该结合其他技术，如 DKIM（DomainKeys Identified Mail）和 DMARC（Domain-based Message Authentication, Reporting, and Conformance），一起增强电子邮件的安全性。

SPF 记录示例

dig +short txt qq.com
"v=spf1 include:spf.mail.qq.com -all"

dig +short txt spf.mail.qq.com
"v=spf1 include:qq-a.mail.qq.com include:qq-b.mail.qq.com include:qq-c.mail.qq.com include:biz-a.mail.qq.com include:biz-b.mail.qq.com include:biz-c.mail.qq.com include:biz-d.mail.qq.com -all"

dig +short txt qq-{a..c}.mail.qq.com biz-{a..d}.mail.qq.com
"v=spf1 ip4:101.226.139.0/25 ip4:101.91.43.0/25 ip4:101.91.44.128/25 ip4:112.64.237.128/25 ip4:116.128.173.0/25 ip4:121.51.40.128/25 ip4:121.51.6.0/25 ip4:162.62.52.214 ip4:162.62.55.67 ip4:162.62.57.0/24 ip4:162.62.58.211 ip4:162.62.58.216 -all"
"v=spf1 ip4:162.62.58.69 ip4:162.62.63.194 ip4:180.163.24.128/25 ip4:183.2.187.0/25 ip4:203.205.221.128/25 ip4:203.205.251.0/25 ip4:210.51.43.0/25 ip4:58.246.222.128/25 ip4:58.250.143.128/25 ip4:61.241.55.128/25 -all"
"v=spf1 ip4:113.108.92.0/25 ip4:121.14.77.0/25 ip4:81.69.217.16/28 ip4:54.164.151.162 -all"
"v=spf1 ip4:114.132.122.39 ip4:114.132.123.192 ip4:114.132.124.171 ip4:114.132.125.233 ip4:114.132.197.227 ip4:114.132.224.180 ip4:114.132.233.22 ip4:114.132.58.0/24 ip4:43.155.65.254 ip4:114.132.62.0/24 ip4:106.55.200.77 -all"
"v=spf1 ip4:114.132.63.24 ip4:114.132.64.0/26 ip4:114.132.65.219 ip4:43.155.67.158 ip4:114.132.67.179 ip4:114.132.73.137 ip4:114.132.74.132 ip4:43.154.209.5 ip4:43.154.197.177 ip4:43.154.155.102 ip4:43.155.80.173 ip4:43.154.221.58 -all"
"v=spf1 ip4:54.204.34.129 ip4:54.204.34.130 ip4:54.243.244.52 ip4:52.205.10.60 ip4:35.173.142.173 ip4:54.207.22.56 ip4:54.207.19.206 ip4:54.254.200.92 ip4:54.254.200.128 ip4:54.92.39.34 ip4:54.206.16.166 ip4:54.206.34.216 ip4:114.132.75.215 -all"
"v=spf1 ip4:52.59.177.22 ip4:18.194.254.142 ip4:18.132.163.193 ip4:18.169.211.239 ip4:13.245.186.79 ip4:13.245.218.24 ip4:15.184.224.54 ip4:15.184.82.18 ip4:114.132.76.87 ip4:114.132.77.159 ip4:114.132.78.196 ip4:114.132.79.153 ip4:43.154.54.12 -all"

语法

1. "v=spf1"：指定 SPF 记录的版本，目前只有 SPFv1 版本。

2. 机制（Mechanisms）：SPF 使用机制来指定哪些服务器被授权发送邮件。常用的机制有：

3. "all"：定义了所有情况下的默认结果。可以是 "+all"（通过验证）或 "-all"（不通过验证）。例如，"-all" 表示除非匹配其他通过机制，否则所有情况都不通过验证，即严格拒绝伪造邮件。

4. "ip4" 和 "ip6"：指定允许发送邮件的 IPv4 和 IPv6 地址。例如："ip4:192.0.2.1" 表示允许来自 192.0.2.1 的服务器发送邮件。
5. "a" 和 "mx"：允许域名的 A 记录和 MX 记录指定的主机发送邮件。

6. "include"：允许引用其他域名的 SPF 记录。例如："include:example.com" 表示允许按照 example.com 的 SPF 记录来验证。

7. 修饰符（Modifiers）：修饰符可以在机制之后指定，用于调整验证的结果。常用的修饰符有：

8. "+"：显示通过验证。

9. "-"：显示不通过验证，相当于 "-all"。
10. "~"：软失败，邮件可能被接受，但会标记为不可信。
11. "?"：中性结果，邮件可能被接受，但不影响验证的结果。

SPF 记录示例：

v=spf1 ip4:192.0.2.1 a mx ~all

以上示例表示允许 IP 地址为 192.0.2.1 的服务器、A 记录和 MX 记录指定的主机发送邮件，但验证结果为软失败，邮件可能会被接受，但标记为不可信。

DNS SPF 类型

IANA 设计了一种专门的 DNS 类型用来记录 SPF 信息，但是采用率非常低。
可以忽略，继续使用 TXT 类型来保存 SPF 信息。

参考资料与拓展阅读

• Sender Policy Framework