主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
互联网历史
无法宣布空闲对端已失效的探测：TCP Keep-Alive
空闲的 TCP 连接可以长时间没有动静，却并不一定已经断开。Keep-Alive 试图获取传输状态的迹象，但不把一次未获回复变成确定结论。
IETF
混合 SSH 密钥交换让算法协商成为迁移边界
安装后量子代码，并不等于 SSH 会话已经使用它。RFC 10042 定义了三种把 ML-KEM 与传统椭圆曲线交换结合起来的混合方法。只有双方都提供同一方法、协商确实选中它、两个组成交换都成功，而且主机密钥仍正确认证服务器，保护才真正发生。
互联网历史
拒绝逐字节打开的窗口：TCP 如何避免愚蠢窗口综合征
接收端刚腾出几字节空间，并不等于必须立刻把这几字节通告给发送端。TCP 正是靠这种克制，避免一次微小的窗口增长演变成持续不断的小报文循环。
互联网历史
那扇关上却没有结束连接的窗口：TCP 持续状态
接收窗口降到零，意味着发送方必须停下，却不意味着连接已经死亡。真正棘手的是：如果“窗口重新打开”这条消息丢了，双方怎样走出等待。
互联网历史
让不在通信路径上的攻击者更难预测的数字：TCP 初始序列号
TCP 连接以交换数字开始。历史上的关键改动不是隐藏这次交换，而是让一次可见的数字不再泄露下一条连接的起点。
全球机构趋势
有效的软件签名并不是持久的授权记录
即使发布者的职权已经变化，签名验证仍可能显示成功。密码学能证明字节与签名操作之间的关系，却不能单独证明签名者当时有权发布该版本。
互联网历史
让公钥变得可信的链条：PEM 证书管理
公钥只是一段密码学材料，并不会自行说明持有者是谁。RFC 1422 为隐私增强邮件设计了证书、认证机构、验证路径与吊销信息，使收件人能够检查“姓名与密钥之间的绑定”由谁作出、又凭什么值得信任。
互联网历史
从未真正带外的指针：TCP 紧急数据
TCP 紧急数据是一个很小、却有漫长历史的控制面。URG 标志使 16 位紧急指针生效，但 RFC 793 对它标记的边界给出了两种彼此矛盾的描述。这一歧义从规范进入了实现和应用 API。
全球云服务趋势
移除根证书，先要迁移整套终端信任，再谈浏览器更新
根证书计划可以在某个版本中撤销信任，但许多应用仍可能依据旧版、私有或内置的信任库作出判断。只有关键验证端能够证明预期的拒绝已经生效，这次安全变更才算完成。
IETF
位图只说明 UDP 选项出现过，不说明它做了什么：RFC 9870
RFC 9870 为 IPFIX 导出器提供了一种紧凑方式，用来报告一个流中观察到哪些 UDP 选项类型。它的价值恰恰来自结论范围有限：记录的是出现事实，而不是逐包历史、接收端处理决定或应用结果。
案例档案
在 Python，已接受的 PEP 既不是发布承诺，也不是实现凭证
Python 的规则把提案的裁决、参考实现的完成和版本发布分在不同位置。它们可能构成一条连续链路，但任何一环都不能替另一环开具证明。
互联网历史
六个字节只有在传输域明确后才成为地址：RFC 1449
一份旧配置完整保存了六个字节，却没有保存它们属于哪个传输域。今天的工程师很容易把前四个解释为 IPv4 地址，把后两个解释为 UDP 端口，而且能得到一个看上去完全合理的结果。RFC 1449 提醒我们：合理的解码不等于真实的原意。字节必须与选择其语法的域标识一起存在。
互联网历史
数据库写着一个地址，回复却沿请求来路返回：RFC 1445
控制系统面对两份不一致的事实：配置表说管理站在甲处，刚收到的请求却来自乙处。RFC 1445 没有把其中一份抹掉。新请求仍按配置出发，这次回复则必须沿实际来路返回。运行中的路径只获得一次回程权，没有因此变成永久身份。
案例档案
在 Apache，发布投票既不是代码否决，也不是 Board 的技术决定
在 Apache Software Foundation 中，committer 可以修改代码，合格投票者可以阻止一项代码修改，PMC 可以作出正式发布决定，Board 可以行使公司层面的监督。这些行为属于同一 Foundation，却不是同一种授权。把它们都写成“Apache 已批准”，会让记录看似简洁，却抹掉了决定真正发生的位置。
报道
RIPE 的纸板配对试验：认识之后，谁来接住问题
把研究者与运营商带进同一间会场并不难。RIPE NCC 一份新的复盘提出了更实际的问题：怎样让一次交谈变成双方愿意继续的工作，又不把交换联系方式误当成数据授权或长期维护承诺。
互联网历史
时钟倒退了，密钥必须更换：RFC 1446
设备断电时，网络上的时间并没有暂停。报文仍可能被保存，管理站仍在推进自己的记录，原本有效的操作也在逐渐过期。真正危险的不是机器停了多久，而是它醒来后带着旧密钥，却把自己的安全时钟恢复到了更早的位置。RFC 1446 看见了这个裂缝：一旦时钟倒退，过去的报文就可能重新进入“尚未过期”的范围，因此密钥必须同时改变。
互联网历史
密钥先于回执改变，管理器只能同时记住新旧两把：RFC 1446
代理已经换上新密钥，管理器却还在等回执，准备收到以后才更新自己的记录。此时代理用新密钥生成回复，管理器手里只有旧密钥。RFC 1446 写下了一个看似反常、实则精确的时刻：变更已经成功，成功回执却可能因此无法通过验证。
案例档案
名字没有变，模块却变了：RFC 9890 修正了什么
RFC 9890 澄清了 YANG 登记中的一条关键界线：模块名和 XML 命名空间在修订间保持稳定，因此它们只能证明谱系，不能证明服务器实际使用了哪一版定义。
互联网历史
模块名字没有变，设备却没有证明自己运行哪一版：RFC 1442
管理平台里的一份 MIB 可以标着最新修订时间，机房里的设备却可能从未实现那次修订。两件事并不矛盾：前者是定义文件的履历，后者是运行代码的事实。RFC 1442 为 SNMP 信息模块建立了稳定身份与修订记忆，同时清楚地把 `MODULE-IDENTITY` 放在实现阶段，而不是把它设计成设备现场可询问的版本证词。
互联网历史
同一个应用跨过两个版本，代理却改写了操作：RFC 1452
应用发出的是批量读取，旧版代理收到的却只是“取下一个”。中间的双语管理器先查本地数据库，再把两个重复参数清零并改掉 PDU 类型。RFC 1452 希望这层转换对应用透明；它同时留下了另一条更重要的记录：接口连续，不等于两端执行了同一项操作。