跳转到主要内容

主题

软件生命周期与供应商锁定

在主题维度下,软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径,涵盖相关报道、证据来源、市场参与者和基础设施影响,并给出足够背景,帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题,而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道,以及该主题对运营商、客户、投资者和关注政策的读者为何重要。

IETF“丢失”的会议纪要其实还在,档案需要一份完整性清单

IETF

IETF“丢失”的会议纪要其实还在,档案需要一份完整性清单

两份会议纪要从网页上“消失”时,文件并没有随之消失。IETF 84 的 AVTCORE 与 MMUSIC 纪要仍存在于一份同步副本中,旧网页只是无法把不带扩展名的链接解析到正确文件。服务器规则修好后,读者重新获得了入口。但对一个承担制度记忆的档案来说,能点开只是第一关:它还应说明打开的是哪一个对象、哪一版,以及此刻返回的字节能否核验。

2026年9月6日
告诉 TCP 数据从哪里开始的数字:Data Offset

互联网历史

告诉 TCP 数据从哪里开始的数字:Data Offset

Data Offset 划定完整 TCP 首部与应用数据第一个字节之间的边界。

2026年9月6日
从未发送的报头:TCP 为什么要校验 IP 地址

互联网历史

从未发送的报头:TCP 为什么要校验 IP 地址

TCP 并不把额外的地址报头放进线上的 TCP 段。它让两端根据 IP 提供的上下文重建一组计算输入,再用这组输入验证传输内容。

2026年9月6日
占据空间的两个标志:TCP 为何计算 SYN 和 FIN

互联网历史

占据空间的两个标志:TCP 为何计算 SYN 和 FIN

TCP 为字节编号,同时也为两个控制事件保留逻辑位置。SYN 位于首个数据字节之前,FIN 位于最后一个数据字节之后;二者因此能够沿用数据流的确认与重传机制,却不会变成应用字节。

2026年9月5日
从未成为消息边界的 PUSH:TCP 的 PSH 标志

互联网历史

从未成为消息边界的 PUSH:TCP 的 PSH 标志

它要求字节流继续前进,却没有把字节流变成一条条消息。

2026年9月5日
被一端遗忘的连接:TCP 半开放状态的复位

互联网历史

被一端遗忘的连接:TCP 半开放状态的复位

一端重启后可能丢失一条连接的状态,而另一端仍把它视为已建立。下一次报文交换会暴露这段分歧:RST 清除过时状态,为随后通过普通握手建立新连接腾出路径。

2026年9月5日

全球机构趋势

当 ISC 软件出现漏洞时,谁控制修复时钟?

对 BIND 与 Kea 而言,影响安全响应的不只是漏洞本身,也包括谁先获得信息、谁制作官方修复版本、哪些版本仍受支持,以及运营商最终是否部署。ISC 在这条链上拥有显著的实际维护权力,但这种权力并不等于对所有下游用户的法律命令权。

2026年9月5日
当双方同时敲门:TCP 的同时打开

互联网历史

当双方同时敲门:TCP 的同时打开

*TCP 的三次握手并不要求固定的客户端和服务器;两个端点可以同时发起,并建立一条连接。*

2026年9月5日
必须先等待再开口的主机:TCP 重启后的静默时间

互联网历史

必须先等待再开口的主机:TCP 重启后的静默时间

重启后的主机看似一尘不染,可能只是忘记了太多。TCP 的静默时间把这种记忆丢失转化为可控等待:先让旧报文消失,再重新使用可能重叠的序列号空间。

2026年9月5日
过早结束等待的重置:TCP TIME-WAIT 的“暗杀”风险

互联网历史

过早结束等待的重置:TCP TIME-WAIT 的“暗杀”风险

TIME-WAIT 看起来只是关闭后的暂存状态。RFC 1337 证明,它也可能被协议行为提前清除:一个旧报文触发 ACK,ACK 又促使没有连接状态的对端发送 RST,原本用来隔离旧重复报文的保护因此消失。

2026年9月5日
那个并非重传计时器的期限:TCP 用户超时

互联网历史

那个并非重传计时器的期限:TCP 用户超时

TCP 可以继续重传,同时在另一只时钟上判断等待已经太久。

2026年9月5日
这不是协商的报价:TCP MSS 如何限定两个方向

互联网历史

这不是协商的报价:TCP MSS 如何限定两个方向

每个 SYN 都可以携带发送方对自身接收能力的声明。两个方向的数值可以不同;MSS 既不是共同分组大小,也不是路径 MTU 证明。

2026年9月5日
必须记住上一次握手的握手:RFC 5746 如何绑定 TLS 重协商

互联网历史

必须记住上一次握手的握手:RFC 5746 如何绑定 TLS 重协商

TLS 握手可以证明自身完成,却不一定证明它延续了哪段连接历史。RFC 5746 让这种连续性成为可以由密码学验证的协议状态。

2026年9月5日
邻居变得不可达后仍留在缓存中:RFC 7048 如何把故障转移与遗忘分开

互联网历史

邻居变得不可达后仍留在缓存中:RFC 7048 如何把故障转移与遗忘分开

第三次单播探测仍无回应时,节点不必立即抹去最后一份链路层地址记录。它可以暂时降低该邻居的路由优先级,同时保留这份记录继续寻找证据。

2026年9月5日
尚未证明唯一,地址却先开口:乐观 DAD 如何限制早期使用

互联网历史

尚未证明唯一,地址却先开口:乐观 DAD 如何限制早期使用

新配置的 IPv6 地址可以在唯一性检查完成前传输流量,但在证据到来之前,不能像一个无争议的邻居那样改写邻居缓存状态。

2026年9月5日
安全 TACACS+ 迁移中的不安全阶段:RFC 9887 与双路径认证的代价

IETF

安全 TACACS+ 迁移中的不安全阶段:RFC 9887 与双路径认证的代价

TLS TACACS+ 客户端在 TLS 失败时不得退回非 TLS;但设备不能同时迁移时,组织仍可能为未迁移设备暂时保留独立的非 TLS 服务器。只要这条旧路径仍可达,混合迁移阶段在完成前就仍是不安全的。新 TLS 端点能够正确工作,并不等于双路径已经安全收束。

2026年9月5日

案例档案

通知已经发布,一台后端却仍然无物可取

RRDP 的通知文件很小,却代表一项很重的承诺:它列出的 snapshot 与 delta 已经可以被依赖方取得。IETF 正在征求最后意见的 RPKI 发布服务草案,把这项承诺写成明确顺序——先让内容就位,再让通知出现。负载均衡不能把这个顺序拆散。

2026年9月5日

案例档案

控制器说路径已经送达,转发面却从未答应:RFC 9830

控制器日志写着“发布成功”,BGP 表也确实出现了一条 SR Policy 路由。值班人员于是把这两条记录拼成“路径已生效”。真正缺失的,恰恰是中间最有决定权的几步:该通告是否被目标头端导入,SRPM 是否认可其中的段与 Binding SID,它是否赢过 PCEP 或本地配置中的候选路径,以及硬件是否真的装入了对应转发表。RFC 9830 证明提案到达了 BGP;它没有让到达自动变成执行。

2026年9月5日
邮件写明了权限,解码器仍不能替收件系统授权:RFC 1505

互联网历史

邮件写明了权限,解码器仍不能替收件系统授权:RFC 1505

一封邮件的 `Encoding` 字段写着 `Signature`,它可能指密码学签名,也可能只是正文末尾那几行姓名与格言。1993 年的 RFC 1505 把两者放进同一套描述语言,也因此留下一个至今仍尖锐的问题:机器认出了一个词,究竟认出了格式、证据,还是行动权限?

2026年9月5日

案例档案

挑战放行了邮件,邮件却还没有抵达列表

IETF 计划在 9 月 11 日切换邮件基础设施。新系统把挑战验证、列表处理、地址改写、签名与出站传输拆成不同环节。拆分带来的真正价值,不是让每个容器都显示绿色,而是迫使运营者回答:每一次“成功”究竟只证明了哪一道边界?

2026年9月5日