很多小伙伴的电脑系统都是源于购买时自带的Windows家庭版，或者是卖家直接批量用Ghost方式安装的。存在系统文件被精简、家庭版缺少高级特性、安全性下降之类的问题。本文旨在提供一种绝对原版的重装方式，WinPE快速安装原版镜像的方式之后再另开文章 你可以在微软官网渠道获取，也可以通过一些比较靠谱的整合站，例如ITELLYOU。无论哪种方式，确保自己获取的镜像是原版未经修改的即可 你可能会问：官方不是都有安装小帮手了？ 但是本文列出的方法通用于大部分系统，不仅包括旧版Windows，Linux发行版都可以这样装（只是写引导和选择系统的时候有所差别） 如果你选择上述的ITELLYOU渠道，你会发现下载链接只有ED2K和BT。这个时候就可以选一个靠谱的下载工具了，喜欢用迅雷的倒也可以直接使用，
这几天英国天气太热了，都二十七八度了，家里楼上简直是桑拿。因为英国的房子大多数都很保暖。不过楼下的阳光房简直是冬天冷死，夏天热死。也没有装空调，所以只能拿个小风扇吹吹，吹出来的风确是暖和的。
我那微软的Surface Studio笔记本就突然很热，变得特别的卡，CPU风扇也狂转很吵，然后我就发现系统很卡，重启了也就好使，卡得几乎不能用了，勉强打开WINDOWS任务管理器发现CPU被严重限速了，最低CPU主频只有0.4 GHz，好一点的 0.9, 1.2。这CPU是11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz 平常能到 3.8, 3.9。
Windows 11的任务管理器里显示 Intel i7-11370 CPU的工作频繁能到4.2 GHz 以上
再过一会儿 就蓝屏了/BSOD/Blue Screen of Death。显示的问题是英伟达Nvidia GPU显卡驱动 nvlddmkm.sys。
Windows 蓝屏/天气太热/英伟达显卡/死机
当您的Intel CPU过热时，它会自动降低其时钟速度以降低温度，这一过程称为降频。这种保护措施有助于防止CPU损坏，但会显著影响性能。在进行游戏、视频编辑或运行复杂的模拟等密集任务时，降频现象尤其明显。
尽管NVidia GPU非常强大，但它们也会在高温下出现问题。过热会导致GPU崩溃，从而引发Windows 11上的著名蓝屏（BSOD）。BSOD是Windows在遇到严重错误时执行的紧急停止，通常会导致系统重启并可能丢失未保存的工作。
造成过热的原因有很多：
为了防止降频和崩溃，请考虑以下步骤：
电源管理设置CPU处理器的最小/最大功率/CPU限速Throttle
高温对电脑性能构成了重大风险，特别是对于运行Windows 11的Intel CPU和NVidia GPU系统。通过了解原因并实施有效的冷却和维护策略，您可以减轻降频和崩溃的风险，确保系统即使在高温下也能保持稳定和高效。
保持凉爽，让您的电脑更凉爽！
最近英特尔摊上了大麻烦，简单的说，是严重的产品质量问题。问题发生着酷睿13代和14代的全部中高端型号上包括了i9-13900/KS/KF/K/T，17-13700/K/KF/T，i5-13600/K/KF，还有14代的14900KS/KF/K、14700K/KF，甚至还包括使用13代或者14代的笔记本处理器相当多的型号比如13900HX。这里就不挨个念了。
具体是什么故障呢?就是频繁的程序崩溃、死机和蓝屏。而且一旦出现后，在软件或者主板BIOS上无论怎么更新都无济于事，相当于这个CPU接近报废了。
故障发生率有多高呢?不同的经销商统计标准不一样，但大都要比自己手里AMD的CPU故障率至少高一个数量级。比如，有些经销商经营了CPU十几年，返修率平均只有千分之三，但酷睿13代和14代大约在5%左右。更有经销商的客户是游戏开发人员或者服务器领域的，他们统计这两年卖出的800万块13代处理器，故障率竟然高达25%。
两个经销商故障率差异大主要是因为–面向普通用户，平时使用CPU时大都是办公环培负载很轻:个早服条干游戏开发和服务器，CPU一般都是满载，所以故障率很高。要知道，CPU里是没有任何活动部件的，所以这类产品在普通家庭或者办公中使用是几乎永远也坏不了的。今天我们听说一台电脑里的CPU已经工作15年了，这一点也不稀奇。换掉它的唯一原因是性能不够用了，而很少是因为CPU坏掉了。而那些带活动部件的东西，比如说洗衣机，如果能用15年，相信大家听说后的第一反应就是–真耐用。
英文：Hot Weather Causes Intel CPU Throttle and NVidia GPU Crashes on Windows 11 (Blue Screen)
周四晚上TEAMS开个会，公司电脑崩了，尴尬了，不过这个可能和最近INTEL CPU暴出的漏洞有关，INTEL股价大跌。
开个会 公司电脑崩了 尴尬了
Windows 11的两个设定得关了，否则电脑的性能会大大的受到影响。
微软Windows的隐私设置弊大于利，大部分情况下，关掉这些隐私设置并不会影响使用，相反开启这些设置会让你的系统变卡变慢，甚至可能会有一些安全隐患。
把Windows的隐私都关了
关闭方法：Windows + I 键打开设置，然后在左下角选择隐私/安全（Privacy & Security），然后选择（通用/General），然后把这些设置全关了。
这个更新优化在后台消耗你的网络流量，并且会大量占用你的电脑硬盘（因为会存Windows更新文件），这个优化更新（Delivery Optimisation）的原理就是在别的用户需要下载更新的时候你作为一个P2P节点提供数据，当然这个是两个方向的，你需要下载更新的时候也可以从邻近的用户电脑里下载（速度会快一些），不过这有可能有安全隐私隐患。
Windows操作系统得把更新优化给关了
关闭方法：Windows + I 键打开设置，然后在左下角选择安全更新（Windows Update），然后选择高级选项（Advanced Options），然后关了即可。
更新：今天，微软全球大规模机器宕机，影响了各大行业（金融/航空/酒店等），追其原因是因为杀毒软件CrowdStrike推送的一个更新有问题导致的。
Windows蓝屏出错
当地时间7月19日，微软公司旗下部分应用和服务出现访问延迟、功能不全或无法访问问题，全球大量微软Windows用户遭遇蓝屏，相关话题登上热搜。
据媒体报道，微软支持中心客服人员表示，对于电脑出现批量蓝屏的情况，了解到大部分蓝屏都是公司电脑安装了三方杀毒软件之后出现的。
客服称，目前确认到是相关的杀毒软件更新导致的蓝屏，这种情况如果修改驱动文件名称无效，只能建议联系公司IT进一步处理。
据了解，今天CrowdStrike Falcon的Sensor更新后，内核驱动文件csagent.sys导致全球大面积Windows系统蓝屏。
网络安全软件公司Crowdstrike在其支持平台发布消息称，公司收到大量关于Windows电脑出现蓝屏的报告，公司工程部已确定该问题与“内容部署（content deployment）”有关，目前已恢复了这些更改。建议受影响的用户将电脑启动到安全模式或恢复环境，导航至C:\Windows\System32\drivers\CrowdStrike目录，找到与“C-00000291*.sys”匹配的文件并将其删除，即可正常启动电脑。
有网友支招，通过恢复模式启动，或多次异常重启进入安全模式，重命名以下文件为其他文件名：
C:\Windows\System32\drivers\CrowdStrike\csagent.sys。
或直接重命名C:\Windows\System32\Drivers\Crowdstrike文件夹。
英文：Two Windows Tips: Turn Off Delivery Optimization and Tweak Privacy Settings
本文一共 794 个汉字, 你数一下对不对.
Windows操作系统里有一个很有名的控制面板，从早期Windows版本如Win 3.x就有了。这个控制面板默认只显示了常用的一些选项。
Windows 按大图标分类的控制面板视图
Windows 按大图标分类的控制面板视图
Windows 按目录分类的控制面板视图
Windows 按目录分类的控制面板视图
“上帝模式” = God Mode，是一个隐藏的控制面板模式，启用这个模式后会在一个窗口里列出所有几百项的配置。启用方法也很简单：
第一步：到桌面新建一个文件夹。
第二步：把新建的文件夹重命名为：
GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
就可以了，WINDOWS会自动把该文件夹变成一个控制面板的链接（图标也会相应的更新）
Windows上帝模式的控制面板图标
上帝模式的控制面板：几百项的选项都在一个窗口里列出，非常的方便，有木有。
Windows 上帝模式的控制面板视图
英文：How to Enable the “God Mode” of Control Panel on Windows?
本文一共 346 个汉字, 你数一下对不对.
上周，我收到清华大学出版社编辑寄来的新书《流计算系统图解》。趁着周末的功夫，我快速浏览了本书的主要内容。一句话评价：值得一读，尤其是对开始开发流计算任务或系统一到两年，初步实现过一些功能或作业，但是还没有对流式系统建立起系统认识的开发者。
本书作者是两位 Apache Heron (incubating) 项目的 PMC 成员，Heron 是源自 Twitter 的计划取代 Storm 的流计算系统。据称，两位原本是打算写一本 Heron 的系统介绍，但是考虑到绑定具体系统，很难公平地介绍清楚流计算的基础概念和实现方向，最终选择以图解的方式讲解流式系统的设计重点和难点。
巧合的是，Heron 项目社群后续发展不顺利，已于今年一月放弃孵化。本书不局限于特定项目的定位，反而使得它能够在今天仍然有足够的价值被翻译。
本书译者是傅宇、黄鹏程和张晨。这几位都是流计算系统的专家。如果有读者关注数据处理系统的出版，可能还会知道他们合作翻译过另一本著作《Presto 实战》。应该说，这几位译者在 Data Infra 领域的经验和外文著作翻译的经验都是值得信赖的。
回到这本《流计算系统图解》上来。
本书一大特点就是书名点出的以图解方式介绍流计算系统。流计算作业通常包括多个阶段，每个阶段可以设置并行度，不同阶段之间可以用多种方式连接。一旦流计算作业运行起来，其不同阶段的算子通常会长时间运行，从而形成一个长期在线的流计算执行拓扑图。事件如何产生，如何在不同算子之间流转，连续事件处理的顺序和跨越算子不同扇入扇出时的分发机制，不画图可能还真说不清楚。
本书的另一大特点是提供了各个章节系统讲解的在线参考代码。两位作者删繁就简，设计实现了一个简单的流计算参考系统，并在概念讲解中穿插基于这个系统的实例演示。我在浏览过程中针对一些有趣的主题测试过这份在线代码，应该说，两位作者是用心设计的，读者可以阅读代码理解流计算系统的基础结构，也可以做一些 HACKING 验证书中提出的一些发散的问题和想法。
下面介绍一下本书各个章节的关注点，并附上我写过的文章或者相关章节参考资料。
第一章和第二章是对数据处理系统和流计算系统的简介和 Hello World 示例。
第三章介绍了流计算中的数据并行和任务并行。
这个主题非常重要。因为流计算要想在大数据量下取得良好的延迟和吞吐体验，合理的并行设计是必不可少的。并行的策略会影响数据分发的形式，事件处理的顺序和算子状态的管理。
第四章讨论了流计算作业的拓扑结构。主要介绍的是 DAG 的形式，以及不同算子对应的扇入扇出及其性质。
DAG 也是流计算系统主要支持的作业拓扑结构，目前最热门的流计算系统 Flink 实现的也是 DAG 拓扑结构的作业调度。除此之外，可以补充阅读 Naiad 论文。这篇论文里介绍了用于流图上迭代计算的环结构，其开源实现是 Timely Dataflow 库，被用在流数据库 Materialize 上。不过上次看的时候，Materialize 并未利用上 Timely Dataflow 的迭代计算能力，现如今也不标榜自己是流数据库了，令人唏嘘。
第五章讨论了流计算作业的事件送达语义，即经典的至多一次（At-Most Once）、至少一次（At-Least Once）和恰好一次（Exactly Once）。
书中点出了恰好一次根本是实际一次（Effectively Once），即是通过重试和幂等实现的，而不是真的只投递一次消息并能确保下游收到。这个认识对理解恰好一次语义是至关重要的。
关于流式系统中的恰好一次语义，我也写过一篇文章 Exactly Once 做讨论。其他参考材料如下：
第六章是对前面几章的总结和开启第二部分进阶话题的序章。
第七章讨论了流式系统中的窗口计算。窗口其实可以理解成流计算中的攒批计算，跟批处理中的微批模式形成某种对偶。不过，窗口计算有着语义上的需求，而微批模式主要是性能上的需求。
关于窗口计算和水位线，我写过 Window 和 Watermark 两篇文章。其他参考材料如下：
其中，The Dataflow Model 是 Google 流计算的经典论文，Dataflow 模型的开山之作。这篇论文当中，主要讨论的就是如何设计和实现一个带窗口计算的流计算系统。
第八章讨论了 JOIN 操作，主要涉及到流和表的共轭关系或者说数据的流表二象性。
本书从算子扇入扇出切入，把 JOIN 作为一种特殊的扇入方式引进，还是比较自然的。现实世界中，最复杂的流计算就是涉及双流 JOIN 或维表 JOIN 的计算。书中先从表是流的物化视图引进，接着讨论不同类型的 JOIN 对应的效率和数据完整性考量。
这部分内容涉及《流式系统》整个第二部分，足以见其复杂
第九章讨论了反压。前面提到，流计算系统通常是长期在线运行的系统，因此它需要应对潜在的在线流量洪峰。
反压实际上是一个在线系统实现层面的细节，并不完全跟流计算系统相绑定。关于反压的问题，我推荐 Flink China 社群早年录制的一个教程《Flink 网络流控与反压剖析》。
第十章讨论了有状态计算。实际上，在前面讨论送达语义、窗口计算和 JOIN 操作的时候，或多或少都涉及到了流式系统中的状态管理。
领我入门流计算领域的施晓罡博士说过，Flink 的创造性价值，不在于流计算，而在于实现了带状态的流计算。把状态管理内化到流计算系统的设计当中，解决了 Storm 等系统依赖外部状态存储导致的数据一致性很难保证的问题。直到今天，Flink 官网上巨大的 Slogan 仍然是：数据流上的有状态计算。
关于这个主题，我写过一篇文章 State 讨论。其他参考资料如下：
第十一章终章是对前面章节的总结和展望。
关于其他流式系统的参考资料，我写过一份书单《流式系统阅读指南》。
最后，我想引用《流计算系统图解》最后一节的内容，给有志于深入学习和实践流计算系统的读者分享一些参与方向：
挑选一个开源项目来学习，甚至直接参与到开源项目当中。
开源运动让我们平等地接触到业内领先的流计算系统。它们的代码实现和设计文档，甚至设计过程的讨论和用户使用的反馈都唾手可得。学习流计算从来没有一个时候像现在这样简单。
开始写博客，传授你所学的知识。
上面的参考资料中包括了不少我自己写的博客。在流计算的国内传播上，云邪的博客起到了很大的作用，不少人第一次深入了解流计算就是从阅读他的博客开始的。另外，林小铂的博客也值得一读。当然，还有 Flink 的博客。主动分享和交流是开源开发者技术进步的阶梯。
参加聚会和会议。
Flink Forward 大会几乎每年都会在中国举办。此外，随着 RisingWave 和一系列 MQ 社群的崛起，流计算相关的聚会和会议只会越来越多。
永不放弃。原文写到：
要实现任何卓越的目标，都需要经历一次又一次的失败。接受失败，这将使你变得更优秀。
本文从软件系统、学术论文和出版书籍三个方面介绍研究学习类似 Apache Flink 的流式系统的参考材料。
现实世界的软件系统都是以生产可用为目的的。因此，其代码、文档和讨论不局限于流式计算本身，还有许多分布式系统共通的话题。在这里，我会强调其中和流计算相关的内容。
Apache Flink 大约是国内目前知名度最高的流式系统。要想了解它的流式计算设计，最好的办法是从用户编程接口切入。它提供了两套编程接口，一套参考了 Dataflow 论文的设计，另一套则是致力于兼容和扩展 SQL 标准。
具体的 API 指南目录下，涉及时间（Time）和状态（State）的章节是流式计算核心的差异点。
此外，Flink 还有 Flink Imrpovement Proposal (FLIP) 页面记录和核心设计决策，这里同样介绍流式计算与众不同的一些。
Apache Spark 对标 Flink 的流计算方案，这里仅放几个相关链接。
Apache Beam 是 Google Dataflow 论文的开源实现。不过这个系统仅实现了论文当中的模型概念，实际执行计算需要编译到 Flink、Spark 或者 Google Cloud Dataflow 上。下面文档介绍了 Dataflow 论文当中的领域模型是如何落实到 Beam 的代码中的。
Materialize 是一个专有的流数据库。底下执行逻辑基于 Timely Dataflow 和 Differential Dataflow 搭建，Materialize 上层做了一个 Postgres 模型的 SQL 层。
它是微软研究院 Naiad 系统的转世。不过目前通过 SQL 暴露出来的功能还完全没有用上 Timely Dataflow 尤其 Differential Dataflow 的核心能力，到底能不能跑起来集群，集群容错效果如何，都是未知数。
上面链接里 Timely Dataflow 和 Differential Dataflow 的页面是对应的用户文档，可以当做是一个标注详解版的论文参考手册，值得一读。
正在开发中的流数据库 RisingWave 也开放了 RFC 文档，其中有不少内容可以借鉴学习。我相信他们的研发人员也乐于和有一定基础的开发者做深入的探讨。
首先放一篇调研报告，可以看它引用的论文。后面的是一些我有印象的相关论文，可以看被引用的关系。
大名鼎鼎的《流式系统》其实是 Dataflow 论文的一个超级加长版，扩充了流表二象性和流式 SQL 的内容，必读。
Fundamentals of Stream Processing Application 是基于 IBM InfoSphere 系统介绍流式系统的著作，讲透了很多基础的 Streaming 概念，必读。
Stream Processing with Apache Flink 一本主要介绍流式处理定义、场景和 Flink 的 DataStream API 的书籍，有中文译本。
Stream Processing with Apache Spark 对标 Flink 的书，讲的是 Spark Structured Streaming 的版本。
《设计数据密集型应用》 介绍了通用的分布式数据密集型应用的特点，如果你想参与现实世界的流式系统开发，这本书介绍的内容也不可错过。
《数据库系统内幕》 介绍了数据在存储系统上的组织和多年来发展出的数据库查询及事务语义。今天，一个流式系统要想走近用户群体，支持 SQL 和经典数据库语义是不可或缺的。另外，当前流式系统主要面临的问题，就包括状态和中间结果的存储问题。流数据库的物化视图及其级联，就是中间结果的存储和访问问题。
工作原因，经常要找各种标准用。和过去互联网草莽时代的自由下载不同，现在版权意识走向了另一个极端：不管自己有没有版权的文档（多数没有），各种文库都要圈起来收费。大的百度文库要VIP，小的文库要你微信扫码，到处都要钱。本来应该是免费、公开的文档，找起来愈发困难，也无奈付过不少费用。前几年国家出了这样一个平台，至少国标这一块是省心了：
可以随意浏览下载。
但是推荐国家标准GBT，是不能下载的，只能在线浏览。不知道是基于什么考虑。
很早前就想写一篇关于eBPF的文章，但是迟迟没有动手，这两天有点时间，所以就来写一篇，这文章主要还是简单的介绍eBPF 是用来干什么的，并通过几个示例来介绍是怎么玩的，这个技术非常非常之强，Linux 操作系统的观测性实在是太强大了，并在 BCC 加持下变得一览无余。这个技术不是一般的运维人员或是系统管理员可以驾驭的，这个还是要有底层系统知识并有一定开发能力的技术人员才能驾驭的了的。我在这篇文章的最后给了个彩蛋。
eBPF（extened Berkeley Packet Filter）是一种内核技术，它允许开发人员在不修改内核代码的情况下运行特定的功能。eBPF 的概念源自于 Berkeley Packet Filter（BPF），后者是由贝尔实验室开发的一种网络过滤器，可以捕获和过滤网络数据包。
出于对更好的 Linux 跟踪工具的需求，eBPF 从 dtrace中汲取灵感，dtrace 是一种主要用于 Solaris 和 BSD 操作系统的动态跟踪工具。与 dtrace 不同，Linux 无法全面了解正在运行的系统，因为它仅限于系统调用、库调用和函数的特定框架。在Berkeley Packet Filter (BPF)（一种使用内核 VM 编写打包过滤代码的工具）的基础上，一小群工程师开始扩展 BPF 后端以提供与 dtrace 类似的功能集。 eBPF 诞生了。2014 年随 Linux 3.18 首次限量发布，充分利用 eBPF 至少需要 Linux 4.4 以上版本。
eBPF 比起传统的 BPF 来说，传统的 BPF 只能用于网络过滤，而 eBPF 则可以用于更多的应用场景，包括网络监控、安全过滤和性能分析等。另外，eBPF 允许常规用户空间应用程序将要在 Linux 内核中执行的逻辑打包为字节码，当某些事件（称为挂钩）发生时，内核会调用 eBPF 程序。此类挂钩的示例包括系统调用、网络事件等。用于编写和调试 eBPF 程序的最流行的工具链称为 BPF 编译器集合 (BCC)，它基于 LLVM 和 CLang。
eBPF 有一些类似的工具。例如，SystemTap 是一种开源工具，可以帮助用户收集 Linux 内核的运行时数据。它通过动态加载内核模块来实现这一功能，类似于 eBPF。另外，DTrace 是一种动态跟踪和分析工具，可以用于收集系统的运行时数据，类似于 eBPF 和 SystemTap。[1]
以下是一个简单的比较表格，可以帮助您更好地了解 eBPF、SystemTap 和 DTrace 这三种工具的不同之处：[1]
| 工具 | eBPF | SystemTap | DTrace |
|---|---|---|---|
| 定位 | 内核技术，可用于多种应用场景 | 内核模块 | 动态跟踪和分析工具 |
| 工作原理 | 动态加载和执行无损编译过的代码 | 动态加载内核模块 | 动态插接分析器，通过 probe 获取数据并进行分析 |
| 常见用途 | 网络监控、安全过滤、性能分析等 | 系统性能分析、故障诊断等 | 系统性能分析、故障诊断等 |
| 优点 | 灵活、安全、可用于多种应用场景 | 功能强大、可视化界面 | 功能强大、高性能、支持多种编程语言 |
| 缺点 | 学习曲线高，安全性依赖于编译器的正确性 | 学习曲线高，安全性依赖于内核模块的正确性 | 配置复杂，对系统性能影响较大 |
对比表格[1]
从上表可以看出，eBPF、SystemTap 和 DTrace 都是非常强大的工具，可以用于收集和分析系统的运行情况。[1]
eBPF 是一种非常灵活和强大的内核技术，可以用于多种应用场景。下面是 eBPF 的一些常见用途：[1]
登录
[1][1][1][1]总之，eBPF 的常见用途非常广泛，可以用于网络监控、安全过滤、性能分析和虚拟化等多种应用场景。[1]
eBPF 的工作原理主要分为三个步骤：加载、编译和执行。
eBPF 需要在内核中运行。这通常是由用户态的应用程序完成的，它会通过系统调用来加载 eBPF 程序。在加载过程中，内核会将 eBPF 程序的代码复制到内核空间。
eBPF 程序需要经过编译和执行。这通常是由Clang/LLVM的编译器完成，然后形成字节码后，将用户态的字节码装载进内核，Verifier会对要注入内核的程序进行一些内核安全机制的检查,这是为了确保 eBPF 程序不会破坏内核的稳定性和安全性。在检查过程中，内核会对 eBPF 程序的代码进行分析，以确保它不会进行恶意操作，如系统调用、内存访问等。如果 eBPF 程序通过了内核安全机制的检查，它就可以在内核中正常运行了，其会通过通过一个JIT编译步骤将程序的通用字节码转换为机器特定指令集，以优化程序的执行速度。
下图是其架构图。
（图片来自：https://www.infoq.com/articles/gentle-linux-ebpf-introduction/）
在内核中运行时，eBPF 程序通常会挂载到一个内核钩子（hook）上，以便在特定的事件发生时被执行。例如，
最后 eBPF Maps，允许eBPF程序在调用之间保持状态，以便进行相关的数据统计，并与用户空间的应用程序共享数据。一个eBPF映射基本上是一个键值存储，其中的值通常被视为任意数据的二进制块。它们是通过带有BPF_MAP_CREATE参数的bpf_cmd系统调用来创建的，和Linux世界中的其他东西一样，它们是通过文件描述符来寻址。与地图的交互是通过查找/更新/删除系统调用进行的
总之，eBPF 的工作原理是通过动态加载、执行和检查无损编译过的代码来实现的。[1]
eBPF 可以用于对内核的性能进行分析。下面是一个基于 eBPF 的性能分析的 step-by-step 示例：
第一步：准备工作：首先，需要确保内核已经支持 eBPF 功能。这通常需要在内核配置文件中启用 eBPF 相关的选项，并重新编译内核。检查是否支持 eBPF，你可以用这两个命令查看 ls /sys/fs/bpf 和 lsmod | grep bpf
第二步：写 eBPF 程序：接下来，需要编写 eBPF 程序，用于收集内核的性能指标。eBPF 程序的语言可以选择 C 或者 Python，它需要通过特定的接口访问内核的数据结构，并将收集到的数据保存到指定的位置。
下面是一个Python 示例（其实还是C语言，用python来加载一段C程序到Linux内核）
#!/usr/bin/python3
from bcc import BPF
from time import sleep
# 定义 eBPF 程序
bpf_text = """
#include <uapi/linux/ptrace.h>
BPF_HASH(stats, u32);
int count(struct pt_regs *ctx) {
u32 key = 0;
u64 *val, zero=0;
val = stats.lookup_or_init(&key, &zero);
(*val)++;
return 0;
}
"""
# 编译 eBPF 程序
b = BPF(text=bpf_text, cflags=["-Wno-macro-redefined"])
# 加载 eBPF 程序
b.attach_kprobe(event="tcp_sendmsg", fn_name="count")
name = {
0: "tcp_sendmsg"
}
# 输出统计结果
while True:
try:
#print("Total packets: %d" % b["stats"][0].value)
for k, v in b["stats"].items():
print("{}: {}".format(name[k.value], v.value))
sleep(1)
except KeyboardInterrupt:
exit()
这个 eBPF 程序的功能是统计网络中传输的数据包数量。它通过定义一个 BPF_HASH 数据结构来保存统计结果（eBPF Maps），并通过捕获 tcp_sendmsg 事件来实现实时统计。最后，它通过每秒输出一次统计结果来展示数据。这个 eBPF 程序只是一个简单的示例，实际应用中可能需要进行更复杂的统计和分析。
第三步：运行 eBPF 程序：接下来，需要使用 eBPF 编译器将 eBPF 程序编译成内核可执行的格式（这个在上面的Python程序里你可以看到——Python引入了一个bcc的包，然后用这个包，把那段 C语言的程序编译成字节码加载在内核中并把某个函数 attach 到某个事件上）。这个过程可以使用 BPF Compiler Collection（BCC）工具来完成。BCC 工具可以通过命令行的方式将 eBPF 程序编译成内核可执行的格式，并将其加载到内核中。
下面是运行上面的 Python3 程序的步骤：
sudo apt install python3-bpfcc
注：在Python3下请不要使用 pip3 install bcc （参看：这里）
如果你是 Ubuntu 20.10 以上的版本，最好通过源码安装（否则程序会有编译问题），参看：这里：
apt purge bpfcc-tools libbpfcc python3-bpfcc wget https://github.com/iovisor/bcc/releases/download/v0.25.0/bcc-src-with-submodule.tar.gz tar xf bcc-src-with-submodule.tar.gz cd bcc/ apt install -y python-is-python3 apt install -y bison build-essential cmake flex git libedit-dev libllvm11 llvm-11-dev libclang-11-dev zlib1g-dev libelf-dev libfl-dev python3-distutils apt install -y checkinstall mkdir build cd build/ cmake -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_CMD=python3 .. make checkinstall
接下来，需要将上面的 Python 程序保存到本地，例如保存到文件 netstat.py。运行程序：最后，可以通过执行以下命令来运行 Python 程序：
$ chmod +x ./netstat.py $ sudo ./netstat.py tcp_sendmsg: 29 tcp_sendmsg: 216 tcp_sendmsg: 277 tcp_sendmsg: 379 tcp_sendmsg: 419 tcp_sendmsg: 468 tcp_sendmsg: 574 tcp_sendmsg: 645 tcp_sendmsg: 29
程序开始运行后，会在控制台输出网络数据包的统计信息。可以通过按 Ctrl+C 组合键来结束程序的运行。
下面我们再看一个比较复杂的示例，这个示例会计算TCP的发包时间（示例参考于Github上 这个issue里的程序）：
#!/usr/bin/python3
from bcc import BPF
import time
# 定义 eBPF 程序
bpf_text = """
#include <uapi/linux/ptrace.h>
#include <net/sock.h>
#include <net/inet_sock.h>
#include <bcc/proto.h>
struct packet_t {
u64 ts, size;
u32 pid;
u32 saddr, daddr;
u16 sport, dport;
};
BPF_HASH(packets, u64, struct packet_t);
int on_send(struct pt_regs *ctx, struct sock *sk, struct msghdr *msg, size_t size)
{
u64 id = bpf_get_current_pid_tgid();
u32 pid = id;
// 记录数据包的时间戳和信息
struct packet_t pkt = {}; // 结构体一定要初始化，可以使用下面的方法
//__builtin_memset(&pkt, 0, sizeof(pkt));
pkt.ts = bpf_ktime_get_ns();
pkt.size = size;
pkt.pid = pid;
pkt.saddr = sk->__sk_common.skc_rcv_saddr;
pkt.daddr = sk->__sk_common.skc_daddr;
struct inet_sock *sockp = (struct inet_sock *)sk;
pkt.sport = sockp->inet_sport;
pkt.dport = sk->__sk_common.skc_dport;
packets.update(&id, &pkt);
return 0;
}
int on_recv(struct pt_regs *ctx, struct sock *sk)
{
u64 id = bpf_get_current_pid_tgid();
u32 pid = id;
// 获取数据包的时间戳和编号
struct packet_t *pkt = packets.lookup(&id);
if (!pkt) {
return 0;
}
// 计算传输时间
u64 delta = bpf_ktime_get_ns() - pkt->ts;
// 统计结果
bpf_trace_printk("tcp_time: %llu.%llums, size: %llu\\n",
delta/1000, delta%1000%100, pkt->size);
// 删除统计结果
packets.delete(&id);
return 0;
}
"""
# 编译 eBPF 程序
b = BPF(text=bpf_text, cflags=["-Wno-macro-redefined"])
# 注册 eBPF 程序
b.attach_kprobe(event="tcp_sendmsg", fn_name="on_send")
b.attach_kprobe(event="tcp_v4_do_rcv", fn_name="on_recv")
# 输出统计信息
print("Tracing TCP latency... Hit Ctrl-C to end.")
while True:
try:
(task, pid, cpu, flags, ts, msg) = b.trace_fields()
print("%-18.9f %-16s %-6d %s" % (ts, task, pid, msg))
except KeyboardInterrupt:
exit()
上面这个程序通过捕获每个数据包的时间戳来统计传输时间。在捕获 tcp_sendmsg 事件时，记录数据包的发送时间；在捕获 tcp_v4_do_rcv 事件时，记录数据包的接收时间；最后，通过比较两个时间戳来计算传输时间。
从上面的两个程序我们可以看到，eBPF 的一个编程的基本方法，这样的在Python里向内核的某些事件挂载一段 “C语言” 的方式就是 eBPF 的编程方式。实话实说，这样的代码很不好写，而且有很多非常诡异的东西，一般人是很难驾驭的（上面的代码我也不是很容易都能写通的，把 Google 都用了个底儿掉，读了很多晦涩的文档……）好在这样的代码已经有人写了，我们不必再写了，在 Github 上的 bcc 库下的 tools 目录有很多……
BCC（BPF Compiler Collection）是一套开源的工具集，可以在 Linux 系统中使用 BPF（Berkeley Packet Filter）程序进行系统级性能分析和监测。BCC 包含了许多实用工具，如：
下面这张图你可能见过多次了，你可以看看他可以干多少事，内核里发生什么事一览无余。
一些经典的文章和书籍关于 eBPF 包括：
最后来到彩蛋环节。因为最近 ChatGPT 很火，于是，我想通过 ChatGPT 来帮助我书写这篇文章，一开始我让ChatGPT 帮我列提纲，并根据提纲生成文章内容，并查找相关的资料，非常之顺利，包括生成的代码，我以为我们以很快地完成这篇文章。
但是，到了代码生成的时候，我发现，ChatGPT 生成的代码的思路和方法都是对的，但是是比较老的，而且是跑不起来的，出现了好些低级错误，如：使用了未声明的变量，没有引用完整的C语言的头文件，没有正确地初始化变量，错误地获取数据，类型没有匹配……等等，在程序调试上，挖了很多的坑，C语言本来就不好搞，挖的很多运行时的坑很难察觉，所以，耗费了我大量的时间来排除各种各样的问题，其中有环境上的问题，还有代码上的问题，这些问题即便是通过 Google 也不容易找到解决方案，我找到的解决方案都放在文章中了，尤其是第二个示例，让我调试了3个多小时，读了很多 bcc 上的issue和相关的晦涩的手册和文档，才让程序跑通。
到了文章收关的阶段，我让ChatGPT 给我几个延伸阅读，也是很好的，但是没有给出链接，于是我只得人肉 Google 了一下，然后让我吃惊的是，好多ChatGPT给出来的文章是根本不存在的，完全是它伪造的。我连让它干了两次都是这样，这个让我惊掉大牙。这让我开始怀疑它之前生成的内容，于是，我不得我返回仔细Review我的文章，尤其是“介绍”、“用途”和“工作原理”这三个章节，基本都是ChatGPT生成的，在Review完后，我发现了ChatGPT 给我生造了一个叫 “无损编译器”的术语，这个术语简直了，于是我开始重写我的文章。我把一些段落重写了，有一些没有，保留下来的我都标记上了 [1]，大家读的时候要小心阅读。
最后，我的结论是，ChatGPT只是一个不成熟的玩具，只能回答一些没有价值的日常聊天的问题，要说能取代Google，我觉得不可能，因为Google会基于基本的事实，而ChatGPT会基于内容生成的算法，在造假方面称得上是高手，可以列为电信诈骗的范畴了，我以后不会再使用ChatGPT生成文章内容或是作我的帮手了。StackOverflow把其ban了真是不能太赞了！
附件一：ChatGPT的造假载图和样本
|
|
|
ChatGPT 生成的样本一
ChatGPT 生成的样本二
附件二：发明的术语：无损编译器
|
|
|
（全文完）
（转载本站文章请注明作者和出处 酷 壳 – CoolShell ，请勿用于任何商业用途）
今天来讲一讲TCP 的 TIME_WAIT 的问题。这个问题尽人皆知，不过，这次遇到的是不太一样的场景，前两天也解决了，正好写篇文章，顺便把 TIME_WAIT 的那些事都说一说。对了，这个场景，跟我开源的探活小工具 EaseProbe 有关，我先说说这个场景里的问题，然后，顺着这个场景跟大家好好说一下这个事。
先说一下背景，EaseProbe 是一个轻量独立的用来探活服务健康状况的小工具，支持http/tcp/shell/ssh/tls/host以及各种中间件的探活，然后，直接发送通知到主流的IM上，如：Slack/Telegram/Discrod/Email/Team，包括国内的企业微信/钉钉/飞书， 非常好用，用过的人都说好 。
这个探活工具在每次探活的时候，必须要从头开始建立整个网络链接，也就是说，需要从头开始进行DNS查询，建立TCP链接，然后进行通信，再关闭链接。这里，我们不会设置 TCP 的 KeepAlive 重用链接，因为探活工具除了要探活所远端的服务，还要探活整个网络的情况，所以，每次探活都需要从新来过，这样才能捕捉得到整个链路的情况。
但是，这样不断的新建链接和关闭链接，根据TCP的状态机，我们知道这会导致在探测端这边出现的 TIME_WAIT 的 TCP 链接，根据 TCP 协议的定义，这个 TIME_WAIT 需要等待 2倍的MSL 时间，TCP 链接都会被系统回收，在回收之前，这个链接会占用系统的资源，主要是两个资源，一个是文件描述符，这个还好，可以调整，另一个则是端口号，这个是没法调整的，因为作为发起请求的client来说，在对同一个IP上理论上你只有64K的端口号号可用（实际上系统默认只有近30K，从32,768 到 60,999 一共 60999+1-32768=28,232，你可以通过 sysctl net.ipv4.ip_local_port_range 查看 ），如果 TIME_WAIT 过多，会导致TCP无法建立链接，还会因为资源消耗太多导致整个程序甚至整个系统异常。
试想，如果我们以 10秒为周期探测10K的结点，如果TIME_WAIT的超时时间是120秒，那么在第60秒后，等着超时的 TIME_WAIT 我们就有可能把某个IP的端口基本用完了，就算还行，系统也有些问题。（注意：我们不仅仅只是TCP，还有HTTP协议，所以，大家不要觉得TCP的四元组只要目标地址不一样就好了，一方面，我们探的是域名，需要访问DNS服务，所以，DNS服务一般是一台服务器，还有，因为HTTPS一般是探API，而且会有网关代理API，所以链接会到同一个网关上。另外就算还可以建出站连接，但是本地程序会因为端口耗尽无法bind了。所以，现实情况并不会像理论情况那样只要四元组不冲突，端口就不会耗尽）
那么，为什么TCP在 TIME_WAIT 上要等待一个2MSL的时间？
以前写过篇比较宏观的《TCP的那些事》（上篇，下篇），这个访问在“上篇”里讲过，这里再说一次，TCP 断链接的时候，会有下面这个来来回回的过程。
我们来看主动断链接的最后一个状态 TIME_WAIT 后就不需要等待对端回 ack了，而是进入了超时状态。这主要是因为，在网络上，如果要知道我们发出的数据被对方收到了，那我们就需要对方发来一个确认的Ack信息，那问题来了，对方怎么知道自己发出去的ack，被收到了？难道还要再ack一下，这样ack来ack回的，那什么谁也不要玩了……是的，这就是比较著名的【两将军问题】——两个将军需要在一个不稳定的信道上达成对敌攻击时间的协商，A向B派出信鸽，我们明早8点进攻，A怎么知道B收到了信？那需要B向A派出信鸽，ack说我收到了，明早8点开干。但是，B怎么知道A会收到自己的确认信？是不是还要A再确认一下？这样无穷无尽的确认导致这个问题是没有完美解的（我们在《分布式事务》一文中说过这个问题，这里不再重述）
所以，我们只能等一个我们认为最大小时来解决两件个问题：
1） 为了 防止来自一个连接的延迟段被依赖于相同四元组（源地址、源端口、目标地址、目标端口）的稍后连接接受（被接受后，就会被马上断掉，TCP状态机紊乱）。虽然，可以通过指定 TCP 的 sequence number 一定范围内才能被接受。但这也只是让问题发生的概率低了一些，对于一个吞吐量大的的应用来说，依然能够出现问题，尤其是在具有大接收窗口的快速连接上。RFC 1337详细解释了当 TIME-WAIT状态不足时会发生什么。TIME-WAIT以下是如果不缩短状态可以避免的示例：
2）另一个目的是确保远端已经关闭了连接。当最后一个ACK 丢失时，对端保持该LAST-ACK状态。在没有TIME-WAIT状态的情况下，可以重新打开连接，而远程端仍然认为先前的连接有效。当它收到一个SYN段（并且序列号匹配）时，它将以RST应答，因为它不期望这样的段。新连接将因错误而中止：
TIME_WAIT 的这个超时时间的值如下所示：
sysctl net.inet.tcp | grep net.inet.tcp.mslcat /proc/sys/net/ipv4/tcp_fin_timeout要解决这个问题，网上一般会有下面这些解法
tcp_tw_reuse 。RFC 1323提出了一组 TCP 扩展来提高高带宽路径的性能。除其他外，它定义了一个新的 TCP 选项，带有两个四字节时间戳字段。第一个是发送选项的 TCP 时间戳的当前值，而第二个是从远程主机接收到的最新时间戳。如果新时间戳严格大于为前一个连接记录的最新时间戳。Linux 将重用该状态下的现有 TIME_WAIT 连接用于出站的链接。也就是说，这个参数对于入站连接是没有任何用图的。tcp_tw_recycle 。 这个参数同样依赖于时间戳选项，但会影响进站和出站链接。这个参数会影响NAT环境，也就是一个公司里的所有员工用一个IP地址访问外网的情况。在这种情况下，时间戳条件将禁止在这个公网IP后面的所有设备在一分钟内连接，因为它们不共享相同的时间戳时钟。毫无疑问，禁用此选项要好得多，因为它会导致 难以检测和诊断问题。（注：从 Linux 4.10 (commit 95a22caee396 ) 开始，Linux 将为每个连接随机化时间戳偏移量，从而使该选项完全失效，无论有无NAT。它已从 Linux 4.12中完全删除）对于服务器来说，上述的三个访问都不能解决服务器的 TIME_WAIT 过多的问题，真正解决问题的就是——不作死就不会死，也就是说，服务器不要主动断链接，而设置上KeepAlive后，让客户端主动断链接，这样服务端只会有CLOSE_WAIT。
但是对于用于建立出站连接的探活的 EaseProbe来说，设置上 tcp_tw_reuse 就可以重用 TIME_WAIT 了，但是这依然无法解决 TIME_WAIT 过多的问题。
然后，过了几天后，我忽然想起来以前在《UNIX 网络编程》上有看到过一个Socket的参数，叫 <code>SO_LINGER，我的编程生涯中从来没有使用过这个设置，这个参数主要是为了延尽关闭来用的，也就是说你应用调用 close()函数时，如果还有数据没有发送完成，则需要等一个延时时间来让数据发完，但是，如果你把延时设置为 0 时，Socket就丢弃数据，并向对方发送一个 RST 来终止连接，因为走的是 RST 包，所以就不会有 TIME_WAIT 了。
这个东西在服务器端永远不要设置，不然，你的客户端就总是看到 TCP 链接错误 “connnection reset by peer”，但是这个参数对于 EaseProbe 的客户来说，简直是太完美了，当EaseProbe 探测完后，直接 reset connection， 即不会有功能上的问题，也不会影响服务器，更不会有烦人的 TIME_WAIT 问题。
在 Golang的标准库代码里，net.TCPConn 有个方法 SetLinger()可以完成这个事，使用起来也比较简单：
conn, _ := net.DialTimeout("tcp", t.Host, t.Timeout())
if tcpCon, ok := conn.(*net.TCPConn); ok {
tcpCon.SetLinger(0)
}
你需要把一个 net.Conn 转型成 net.TCPConn，然后就可以调用方法了。
但是对于Golang 的标准库中的 HTTP 对象来说，就有点麻烦了，Golang的 http 库把底层的这边连接对象全都包装成私有变量了，你在外面根本获取不到。这篇《How to Set Go net/http Socket Options – setsockopt() example 》中给出了下面的方法：
dialer := &net.Dialer{
Control: func(network, address string, conn syscall.RawConn) error {
var operr error
if err := conn.Control(func(fd uintptr) {
operr = syscall.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.TCP_QUICKACK, 1)
}); err != nil {
return err
}
return operr
},
}
client := &http.Client{
Transport: &http.Transport{
DialContext: dialer.DialContext,
},
}
上面这个方法非常的低层，需要直接使用setsocketopt这样的系统调用，我其实，还是想使用 TCPConn.SetLinger(0) 来完成这个事，即然都被封装好了，最好还是别破坏封闭性碰底层的东西。
经过Golang http包的源码阅读和摸索，我使用了下面的方法：
client := &http.Client{
Timeout: h.Timeout(),
Transport: &http.Transport{
TLSClientConfig: tls,
DisableKeepAlives: true,
DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
d := net.Dialer{Timeout: h.Timeout()}
conn, err := d.DialContext(ctx, network, addr)
if err != nil {
return nil, err
}
tcpConn, ok := conn.(*net.TCPConn)
if ok {
tcpConn.SetLinger(0)
return tcpConn, nil
}
return conn, nil
},
},
}
然后，我找来了全球 T0p 100W的域名，然后在AWS上开了一台服务器，用脚本生成了 TOP 10K 和 20K 的网站来以5s, 10s, 30s, 60s的间隔进行探活，搞到Cloudflare 的 1.1.1.1 DNS 时不时就把我拉黑，最后的测试结果也非常不错，根本 没有 TIME_WAIT 的链接，相关的测试方法、测试数据和测试报告可以参看：Benchmark Report
下面是几点总结
TIME_WAIT 是一个TCP 协议完整性的手段，虽然会有一定的副作用，但是这个设计是非常关键的，最好不要妥协掉。tcp_tw_recycle ，这个参数是个巨龙，破坏力极大。SO_LINGER(0)，而且使用 tcp_tw_reuse 对服务端意义不大，因为它只对出站流量有用。tcp_tw_reuse 和 SO_LINGER(0)。最后强烈推荐阅读这篇文章 – Coping with the TCP TIME-WAIT state on busy Linux servers
（全文完）
（转载本站文章请注明作者和出处 酷 壳 – CoolShell ，请勿用于任何商业用途）
