DES与3DES深度解析:分组密码原理、安全性局限与系统迁移实践
很多人一看到“DES”三个字母第一反应是这个算法不是早就退休了吗还有什么可讲我在课堂上每次抛出这个话头底下总有人点头。但我紧接着会放一组数据直到这几年全球支付网络里仍有相当比例的PIN加密、报文校验、密钥传输在用它的升级版3DES不少机构的加密机里还摆着3DES的密钥文件。这个“过气算法”并没有真正消失它只是在你看不见的地方继续运转。这两讲的内容我每年都要重新过一遍。原因很简单DES是理解现代分组密码绕不开的地基。它为什么能统治密码学界近二十年它最终败在什么地方为什么直接加密两次不够、必须加密三次3DES那个“加密-解密-加密”的奇怪结构里到底藏着哪些工程妥协如果你是在校生这两讲帮你把分组密码的基本功打牢如果你在维护老系统这两讲也能帮你理清“存量3DES到底该怎么处理”。1. 一个“过气算法”为什么还要花两讲去拆它1.1 说它退休了可它在存量系统里还活着先纠正一个印象DES退出历史舞台不等于DES/3DES从世界上消失了。算法退场是一个漫长的过程尤其当它被写进金融标准、烧进了硬件加密芯片之后替换成本远不是“改一行代码”这么简单。我见过很多真实的存量场景3DES还活得好好的传统金融终端的PIN块加密很多还是3DES的CBC模式硬件加密机里存着的密钥类型仍然列着“3DES”这一项老的报文签名、MAC计算底层用的还是TDEA一些嵌入式设备、IC卡应用出于兼容性考虑固件里保留了3DES实现。这意味着什么做安全评估的人如果连3DES的结构和弱点都说不清到了现场只能抓瞎。我甚至遇到过一种情况某系统号称“已迁移到AES”但双端接口为了兼容老设备偷偷保留了3DES降级通道。这种问题不懂DES/3DES的技术细节根本审不出来。所以这两讲并不是“考古”更像是在给未来会碰到的真实系统打预防针。1.2 教学意义上的不可替代性从教学角度看DES几乎是完美的案例。它结构清晰、参数适中既不像AES那样轮函数紧凑得让人一眼看不懂也不像某些流密码那样上来一堆反馈移位寄存器。把DES的每一轮拆开看你能直观地理解一组现代分组密码的通用语言轮函数、异或、置换、S盒、密钥扩展、混淆与扩散。更重要的是DES的失败路径特别有教育价值。它不是被某种神乎其神的数学攻击击倒的而是被最朴素的“密钥空间太小”和“块长太短”两个工程问题慢慢磨死的。这种失败方式比任何复杂的密码分析都更能警示后人设计密码系统时安全冗余要给够。学习DES你会明白一个道理一个加密算法的生命周期取决于它在特定时代对抗具体攻击手段的能力而不是它的名字有多大牌。2. DES的设计骨架一套左右分半、不断迭代的经典结构2.1 核心参数和整体结构先把DES的家底一次性列清楚记不住没关系下面的内容会一遍遍用到这些数字。参数值算法类型对称分组密码分组长度64比特密钥长度64比特其中有效密钥56比特8比特奇偶校验轮数16轮网络结构左右分半迭代结构基本运算异或、置换、查表替换每轮子密钥48比特这里有一个经常被问到的点密钥不是64位的吗怎么说只有56位因为DES密钥的第8、16、24、32、40、48、56、64位是奇偶校验位用来保证每个字节有奇数个1实际参与运算的只有56位。这个设计在物理密钥时代方便硬件做校验但也正是这56位成了后来整个算法的命门。整体结构一句话就可以概括把64位明文分成左右各32位然后重复16轮同样的操作最后再做一次逆置换输出。每一轮只有一半数据被“加工”另一半只参与异或然后两边互换位置。这种结构的优点在于加解密可以共用同一套逻辑解密时只需把子密钥顺序反过来操作本身不用另写一套。2.2 轮函数混淆和扩散是怎么落地的每一轮的核心是一个轮函数这是DES真正在做“加密”的地方。它的流程是固定的拿右半边的32位数据开刀扩展置换E把32位扩展成48位。这一步会让某些比特重复出现目的是让子密钥的异或操作影响到更宽的位宽。与48位子密钥异或这是子密钥第一次起作用也是“混淆”的起点。分成8个6位块分别进入8个S盒每个S盒输出4位最终拼成32位。S盒本质上是一张查表把6位输入映射为4位输出。这是整个算法里唯一的非线性操作也是DES安全性的核心。P置换把32位结果重新打乱一次让一个S盒的输出尽量扩散到下一轮的其他位置。理解这一轮关键在S盒。为什么说S盒是非线性的因为如果它是线性函数整个DES就可以被化简成一组线性方程破解难度会急剧下降。S盒的查表规则是一开始就设计好的而且设计者当年对S盒的具体设计准则保密了相当长时间。后来的研究逐渐还原出它的设计约束每个S盒要有很好的差分分布、输出对输入的改变要敏感还要避免某些导致线性逼近的优秀路径。2.3 16个轮密钥是怎么排出来的子密钥不是直接用56位主密钥跟每轮数据异或的它经过了一套专门的密钥调度。第一步用PC-1置换表把56位有效密钥打乱同时剔除8个校验位。第二步把56位分成C、D两半各28位。第三步每轮对C、D分别做循环左移第1、2、9、16轮左移1位其他轮左移2位。第四步左右拼回56位后用PC-2置换选出48位作为这一轮的轮密钥。这个过程的妙处在于16轮结束后C和D恰好又回到了初始状态。所以DES的密钥调度是可逆的知道最终子密钥也能倒推出原始密钥。这也是“最后几轮子密钥泄露等同于主密钥泄露”这类攻击思路的根源。如果你只是用密码库调用DES这些细节看起来不重要。但一旦你做代码审计或者需要自己实现一套兼容老系统的加密逻辑密钥调度顺序就非常容易出错。比如解密时要反向生成子密钥很多初学者在这里会卡很久。我建议动手写一遍简化版的轮函数left, right block[:32], block[32:] for r in range(16): f_output round_function(right, round_keys[r]) left, right right, left ^ f_output # 最后一轮不交换输出 left right这不难但亲手写过一遍之后你对“迭代分组结构”的理解会完全不一样。3. DES被打下来的原因不是结构太弱是密钥太短3.1 穷举搜索从理论威胁变成现实威胁直接说结论DES的16轮结构、S盒设计在密码分析上并没有出现灾难性的数学突破。真正压垮它的是56位密钥的穷举空间在现代计算能力面前变得太小。56位密钥空间有多大2的56次方约7.2乘以10的16次方。这个数字单独看挺吓人但要看跟谁比。在今天一台普通GPU每秒可以轻松做上亿次哈希运算专用FPGA阵列和ASIC芯片在这个数量级上的表现更是惊人。1997年前后密码学界搞过公开的破解挑战。有人用互联网上分布式的闲置计算资源耗时几个月破掉了一个DES密钥1998年一台造价约25万美元的专用破解设备把时间压缩到56小时1999年同一个思路进一步提速大约22小时就能完成一次穷举。这个进步速度告诉我们一个残酷的事实任何对称加密算法安全边界都要按“摩尔定律再走二十年”来预留。56位密钥在1977年可能是安全的到了1998年就已经是裸奔了。3.2 互补性把搜索量再砍掉一半穷举空间已经够小了DES还有一个“自带的折扣”叫互补性。DES有一个数学性质如果对密钥和明文同时取反那么得到的密文也会是对原始密文取反。用公式表达就是DES(~K, ~P) ~DES(K, P)这里的“~”是按位取反。为什么会这样因为DES的轮函数大量使用异或操作而取反操作和异或操作之间存在特殊的抵消关系当你把密钥和明文都取反后轮函数内部异或的结果反而保持不变最终密文自然也是取反后的结果。这个性质的实际意义是攻击者在穷举搜索时不需要测试全部2的56次方个密钥只需要测试一半。如果某个密钥K加密P得到C那么你顺便就知道了补密钥~K加密~P会得到~C。聪明一点的搜索设备就把搜索量降到了2的55次方。这个折扣不算大但在硬件设计上意味着少一半的枚举时间非常实在。3.3 弱密钥和半弱密钥容易被忽略的配置风险DES还有一组特殊的密钥叫弱密钥和半弱密钥。它们不是通常意义上的“后门”而是密钥调度结构带来的必然产物。弱密钥有4个。特征是经过PC-1之后C和D两半要么全0要么全1。这会导致16轮的轮密钥完全一样。结果就是加密和解密变成同一个操作用这个密钥加密后再加密一次明文就回来了。半弱密钥至少有12个成6对出现。它们的特征是子密钥序列呈周期2一对密钥之间互为加解密逆操作。用K1加密的数据用K2再加密一次明文也能回来。这些密钥本身被命中的概率极低随机生成几乎不可能撞上。但在系统里如果允许用户手动录入密钥、或者从老设备同步密钥参数就存在配置错误的可能。安全设计上一般会要求生成密钥后,检查是否落在弱密钥/半弱密钥集合里如果是则拒绝使用。这个检查虽然简单但我见过不少老系统的代码里漏掉了。3.4 差分分析和线性分析为什么反而“夸”了DES穷举是DES明面上的死穴但密码学界对DES的研究远不止于此。差分密码分析是1990年前后公开的一种方法后来研究发现DES的S盒设计实际上已经针对这种攻击做了充分的防护——完整16轮的DES差分攻击需要约2的47次方个选择明文对理论上比穷举2的56次方有优势但“选择明文”这个条件在实际攻击环境里很难满足。线性密码分析更厉害一些。它只需要约2的43次方个已知明文对就能攻击16轮DES比差分攻击更实用。理论上这意味着DES的最强数学攻击点不在穷举而在线性逼近。但即便如此2的43次方仍然是一个天文数字在当时并不构成现实威胁。更有意思的是这两大分析方法的提出恰恰证明了DES的S盒设计水准极高。一个1970年代定型的算法在二十年后被学术界用更成熟的工具审视结构上依然没有出现被一击致命的漏洞。DES退役更多是输给了时代而不是输给了数学。4. 2DES的教训为什么加密两次不等于安全翻倍4.1 直觉陷阱两次DES密钥长度总该翻倍了吧DES密钥太短那就再加密一次这大概是所有人都会想到的思路。假设加密过程是C E_K2(E_K1(P))密钥长度从56位变成112位穷举空间瞬间变成2的112次方。这个直觉看起来无懈可击破解者不知道K1和K2除了全部枚举还能有什么办法如果故事到这里结束那的确很完美。但密码学最不缺少的就是“反直觉的反例”。两次DES不仅没有把安全性轻松翻到112位反而被一个叫“中间相遇攻击”的方法直接打回原形。4.2 中间相遇攻击一张表攻破两重锁中间相遇攻击的思路极其精巧一句话说就是既然你加密了两次那我就从两头同时往中间走在这个过程的中间点碰头。假设攻击者已经掌握了一组已知明文P和对应的密文C攻击步骤是用所有可能的K12的56次方个对已知明文P进行第一次加密得到一个中间值M把“K1对应M”存进一张大表里用所有可能的K22的56次方个对已知密文C进行第一次解密也就是反推倒数第一轮也能得到一个中间值M在表里查找是否存在某个哈希中遇见M如果遇到就找到了一个K1、K2匹配的组合用额外的明密文对验证确认这一组密钥是正确的。第1步和第2步各需要2的56次方量级的计算但代价在于第1步需要存储2的56次方个中间值。这看起来是天文数字级的存储需求在上世纪90年代不行但问题在于它把“破解112位密钥”的时间降到了“破解57位密钥”的规模。更准确地说2DES的有效安全强度大约是57比特——不是112也不是56而是比单DES只多1比特的强度。这个攻击的可怕之处在于它揭示了分组密码组合的一个普遍规律当你要把两个加密级联起来提高强度时安全性不是简单相加而是受限于中间状态的可枚举性。4.3 为什么3DES能逃过中间相遇既然3次加密就是3DES那中间相遇攻击能不能同样作用于3DES可以但代价完全不同。对于三重加密结构要从两头往中间碰中间状态分裂成了两个节点。攻击者需要枚举K1、K2、K3的组合才有机会在中间节点相遇存储规模直接上升到2的112次方量级时间复杂度也是类似级别。2的112次方在当前和可见的未来都是物理上不可能完成的搜索任务。所以结论是2DES的失败催生了必须采用三重结构的共识而三重结构在面对中间相遇攻击时才算真正把安全性推到了112位以上。这个选择不是过度设计是两重DES用鲜血换来的教训。5. 3DES的工程密码EDE结构、密钥选项与兼容性5.1 EDE结构为什么中间偏偏要“解密”3DES最常见的模式是EDE也就是加密-解密-加密C E_K3(D_K2(E_K1(P)))很多第一次接触的人会问加密算法里面套一个解密操作是不是多此一举恰恰相反这个“中间解密”是整个设计里最妙的一笔至少有三大理由第一兼容单DES。如果K1K2K3那么E和D相互抵消整个操作退化为单DES。这意味着老系统只要把三个密钥设成同一个就能无缝跑原来的DES流程。对迁移场景来说这是巨大的工程便利。第二安全性并不受影响。解密操作本身和加密操作一样复杂中间用D而不是E只是把那个步骤变成“逆函数”不会削弱整体强度。因为K2仍然是未知的攻击者依然无法绕开这段逆运算。第三符合某些遗留标准里的互操作约定。金融领域很多老标准直接在硬件层实现了EDE结构新系统若用EEE反而没法对接。如果改成EEE加密-加密-加密虽然也能用但就失去了“三密钥相同退化为单DES”的兼容性在老设备共存的场景里会非常痛苦。所以EDE不是数学上的最优而是工程上的智慧。5.2 双密钥与三密钥名义强度和有效强度怎么算3DES在实际部署中通常有两种密钥用法用法密钥组成名义密钥长度有效安全强度双密钥3DESK1 K3K2独立112位约112位理论上界实际可能因攻击模型下降三密钥3DESK1、K2、K3独立168位应用上通常按112位估算这里有个很有意思的点三密钥3DES虽然名义上有168位密钥但中间相遇攻击决定了它的有效安全强度只能按112位量级来算。所以在写安全评估报告时千万不要把“168位”直接当成“安全级别168比特”这会闹笑话。业内一般把3DES的有效强度标注为112比特和AES-128相比仍有差距这也是为什么新系统优先推荐AES-128/256。还有一个经常被忽略的问题是已知明文攻击。3DES在已知明文场景下如果攻击者能积累海量明密文对安全性评估需要重新建模。这也是为什么我不建议把3DES用在超大数据量的长期加密场景里。5.3 64位分组的代价生日界限与Sweet323DES继承了DES的64位分组长度这成了压垮骆驼的最后一根稻草。分组密码在CBC等模式下加密数据量达到一定程度后分组之间必然出现碰撞。根据生日悖论64位分组在加密约2的32次方个分组后碰撞概率就会显著上升。2的32次方个分组是什么概念也就是大约32GB的数据。对于现代大数据系统32GB完全可能被一个后台任务跑出来。2016年前后公开的Sweet32攻击利用的就是这个64位分组的碰撞特性攻击者通过诱导系统反复加密已知数据收集足够多的密文分组然后利用碰撞推导出明文的异或关系。它的危害不在于直接拿到密钥而在于长期、大量加密场景下的信息泄露。这直接给3DES的合理使用画了一条边界大量数据加密不要用长生命周期密钥不要用高吞吐场景不要用。它适合处理短小的PIN块、报文MAC这类几十个字节的数据而不是往GB级别的数据库里灌。6. 如果必须维护老系统怎么和3DES安全共存6.1 先盘清楚存量里哪里还在用3DES如果你接手了一个还在用3DES的老系统别急着对代码一顿猛改。第一步应该是先盘清楚3DES到底用在哪里数据量多大密钥生命周期多长。我通常建议按这几个维度来摸底使用场景是PIN block加密、MAC计算、密钥包装还是普通的数据加密前两类是轻量级使用第三类风险更高。数据总量每天加密的数据量是否接近“十GB级”如果只是K字节级Sweet32的压力会小很多。密钥轮换频率3DES密钥是不是几年不换如果是无论数据量大小风险都在累积。周边兼容性有没有老终端、加密芯片只能支持3DES如果有要考虑降级风险。这一份清单做完你对“3DES风险到底有多大”就有了具象的判断而不是张口就来“赶紧换AES”。6.2 短期缓解措施在正式迁移完成之前有一些立刻能做的缓解措施限制单密钥加密总量。这是我反复强调的一点。建议把每个3DES密钥的生命周期内加密数据量控制在一个安全阈值以内比如单密钥不超过几十GB只管短消息。这样Sweet32类攻击的碰撞收集难度会显著增加。缩短密钥轮换周期。密钥一换攻击者之前收集的密文就失去了继续利用的价值。对于老系统密钥季度轮换比年度轮换能降低不少风险。避免可预测明文。如果攻击者无法构造或预测明文碰撞攻击的实施条件就会被破坏。尽量不要用固定前缀的报文格式加同一个密钥。检查算法被调用的上下文。如果3DES只用于少量PIN块的加解密而且数据路径受到物理保护那短期继续使用是可以接受的。但要时刻盯住审计日志看有没有异常的加密请求量。6.3 中长期迁移路线长期方案只有一个方向往AES迁移。AES-128在目前的安全评估里已经足够追求更高冗余的可以用AES-256。关键是迁移过程不要搞成“一次切换、全员停服”而是两层结构协议层做兼容。在接口协议里同时保留AES和3DES两种套件新老设备各用各的等老设备全部退网后再在协议层彻底移除3DES套件。密钥体系做隔离。3DES密钥和AES密钥不能放在同一个密钥层级里交叉使用否则一处泄露可能带动全局。密钥管理系统要支持按算法类型分别管理、分别轮换。平滑验证。在切换前搞一轮并跑测试同一批报文分别用3DES和AES处理核对结果、性能、上下游兼容性。只有并跑稳定了才敢正式切流量。迁移过程里最容易翻车的其实是“看起来像AES私下还保留3DES”这种偷懒方案。安全审计真正要查的就是这类隐藏后门。我见过不止一次开发为了省事在配置中心里闭一个开关AES加密失败就自动回落到3DES。这种设计比直接用3DES还要危险因为它把降级行为隐藏起来了审计方根本看不到。7. 离开这两讲时我希望你带走这几条判断力DES和3DES的完整故事其实是一套非常实用的安全判断方法论。我总结成几条你可以直接用在未来的工作中。第一评估一个加密算法的安全性不要只看“还能不能被破解”。DES没有被彻底数学破解但它照样退役。真正要问的是有效安全强度多少在特定攻击模型下有没有已知的突破口在目标场景里成本和收益是否划算第二密钥长度和分组长度是两个维度都必须满足要求。DES的教训是密钥短3DES保留64位分组又把自己坑了。今后你评价任何一个加密算法都要把这个二元组拿出来看少任何一个维度的冗余早晚都会出问题。第三工程妥协有时比数学完美更重要。3DES的EDE结构在数学上并不比EEE更“安全”但就是因为它能兼容单DES才让无数老系统有了平滑过渡的可能。做技术选型时兼容性、迁移路径、运维成本这些东西和算法强度一样都是真实的安全属性。第四标准组织的“移除/弃用”通知不是学术建议是明确的安全信号。当标准组织把3DES从推荐算法清单里删掉时意味着新系统再选用它就要自己承担全部安全责任。除非有极其特殊的历史包袱否则新设计里不该出现3DES这个名字。最后再说一句实在话我给学生讲这两讲时总喜欢留一个课外作业——找一个支持老密码套件的测试环境亲手生成一对DES和3DES密钥加密同一段数据再对比一下密钥长度变化、密文长度变化、计算耗时差异。很多抽象的“有效强度”概念自己动手跑一遍立刻就具体了。密码学这个东西光看书没有任何感觉亲手碰过才记得住。

相关新闻

SPI通信四大契约:CPOL/CPHA、主从角色、速率与CS时序

SPI通信四大契约:CPOL/CPHA、主从角色、速率与CS时序

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 1:25:00 阅读更多 →
两节串联磷酸铁锂主动均衡方案:MP2642GR-Z+PIC18F86K90

两节串联磷酸铁锂主动均衡方案:MP2642GR-Z+PIC18F86K90

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 1:25:00 阅读更多 →
ZTMR开发板+DHT11温湿度传感器入门:接线、代码与避坑指南

ZTMR开发板+DHT11温湿度传感器入门:接线、代码与避坑指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 1:25:00 阅读更多 →

最新新闻

双 11 会场性能全链路压测与故障注入复盘:弱网丢包下 100% 消除白屏实录

双 11 会场性能全链路压测与故障注入复盘:弱网丢包下 100% 消除白屏实录

双 11 的战场不仅是后端数据库与并发网关的狂欢,更是前端工程抗压韧性的终极大考。每年大促零点,数千万消费者涌入主会场,他们可能正处于晚高峰拥挤的地铁车厢、偏远的农村基站,或是家庭 Wi-Fi 信号衰减严重的卫生间角落。一旦前端…

2026/10/15 2:13:17 阅读更多 →
OpenClaw 记忆机制完全指南:Markdown 记忆文件、压缩前自动刷新与向量语义搜索

OpenClaw 记忆机制完全指南:Markdown 记忆文件、压缩前自动刷新与向量语义搜索

人工智能大模型LLM 网关AI Agent即时通讯 【免费下载链接】openclaw-zero-token OpenClaw: Use All Major AI Models NO API Token! Claude/ChatGPT/Gemini/DeepSeek/Doubao/Grok/Qwen/Manus/Kimi 项目地址: https://gitcode.com/gh_mirrors/op/openclaw-zero-token…

2026/10/15 2:13:17 阅读更多 →
客户拜访总漏关键信息?2026年7款拜访记录工具实测横评,附选型建议

客户拜访总漏关键信息?2026年7款拜访记录工具实测横评,附选型建议

做To B销售、商务BD、渠道的朋友,应该都遇到过这种场面:一趟客户拜访聊了近两小时,客户在中间随口提了预算区间、验收标准、竞品的名字,回到车上怎么也想不全。掏出手机翻那段录音,杂音比人声还大,来回听三…

2026/10/15 2:13:17 阅读更多 →
生产应急响应机制沉淀:从故障发现到业务自愈恢复的 1-5-10 原则落地

生产应急响应机制沉淀:从故障发现到业务自愈恢复的 1-5-10 原则落地

去年双 11 狂欢夜,我们经历过一次刻骨铭心的线上惊魂:某营销组件因为一个偶发的 Redis 慢查询引发级联阻塞,从监控报警、值班人员被拉进应急群、大家七嘴八舌排查根因、层层请示技术总监是否允许关停该功能,直到最后执行配置变更&…

2026/10/15 2:13:17 阅读更多 →
录音转文字怕泄密?实测6款隐私向工具,从本地离线到私有化部署怎么选

录音转文字怕泄密?实测6款隐私向工具,从本地离线到私有化部署怎么选

做会议纪要、采访整理、课堂复盘的人,最近两年大概都有同一个动作:录完音,先愣一下——这段音频,我要不要传上去?不是矫情。录音里往往有客户报价、人事谈话、未公开的方案、当事人的个人信息。一旦上传到不透明的服务…

2026/10/15 2:13:17 阅读更多 →
Firebase JS SDK Realtime Database 的 Database 类:实例获取、内部结构与生命周期全解析

Firebase JS SDK Realtime Database 的 Database 类:实例获取、内部结构与生命周期全解析

开发工具后端 【免费下载链接】firebase-js-sdk Firebase Javascript SDK 项目地址: https://gitcode.com/gh_mirrors/fi/firebase-js-sdk 点击查看 免费下载 本篇技术指南聚焦 firebase-js-sdk 仓库中 firebase/database 模块的核心类 Database(即 Fir…

2026/10/15 2:12:16 阅读更多 →

日新闻

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

1. 为什么选择容器化方式部署 LoRa 网络服务LoRa 物联网项目落地时,网络服务器是整个链路的核心枢纽。它负责接收网关上报的数据包、完成去重与解密、再把有效载荷分发给上层应用。早期大家习惯把网络服务器直接装在物理机上,依赖一堆系统库和特定版本的…

2026/10/15 0:00:46 阅读更多 →
共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

1. 共享推理服务里,扩缩容到底难在哪做过大模型推理服务部署的人,大概都经历过这样的场景:一个团队共用一套推理集群,A 业务跑的是 7B 的小模型,B 业务跑的是 72B 的大模型,C 业务白天流量高、晚上几乎归零…

2026/10/15 0:00:46 阅读更多 →
Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

1. 引子:一次内核恐慌引发的追查先从一个真实场景说起。某次我给一台老旧的嵌入式设备折腾系统裁减,为了把启动时间压进两秒以内,我手贱地把一串自认为“没用”的 systemd 服务给 disable 了,其中就包括systemd-remount-fs.servic…

2026/10/15 0:00:46 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/14 3:30:28 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/14 16:30:29 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/14 3:29:58 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 0:14:36 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 22:45:47 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 7:53:34 阅读更多 →