整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
文分享自华为云社区《GaussDB(DWS)性能调优系列实战篇七：十八般武艺之GUC参数调优-云社区-华为云》，作者： 黎明的风。
GaussDB(DWS)性能调优系列专题文章，介绍了数据库性能调优的思路和总体策略。在系统级调优中数据库全局的GUC参数对整体性能的提升至关重要，而在语句级调优中GUC参数可以调整估算模型，选择查询计划中算子的类型，或者选择不同的执行计划。因此在SQL调优过程中合理的设置GUC参数十分重要。
在GaussDB(DWS)中，SQL语句的执行所需要经历的步骤如下图所示，其中红色部分为DBA可以介入实施调优的环节。
查询计划的生成是基于一定的模型和统计信息进行代码估算，在某些场景由于统计信息不准确或者代价估算有偏差时，就需要通过GUC参数设置的的方式选择更优的查询计划。
在GaussDB(DWS)中，和SQL执行性能相关的GUC参数主要有以下几个：
GaussDB(DWS)是分布式的数据库集群，数据计算尽量在各个DN上并行计算，可以得到最优的性能，在Stream框架下Agg操作可以分为两个场景。
Agg下层算子输出结果集的分布列是Group By列的子集。
这种场景，直接对下层结果集进行汇聚的结果就是正确的汇聚结果，生成算子直接使用即可。例如以下语句，lineitem的分布列是l_orderkey，它是Group By的列。
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey;
查询计划如下：
Agg下层算子输出结果集的分布列不是Group By列的子集。
对于这种场景Stream下的聚集（Agg）操作，优化器可以生成以下三种形态的查询计划：
通常优化器总会选择最优的执行计划，但是众所周知代价估算，尤其是中间结果集的代价估算有时会有比较大的偏差。这种比较大的偏差就可能会导致聚集（agg）的计算方式出现比较大的偏差，这时候就需要通过best_agg_plan参数进行聚集计算模型的干预。
以下通过TPC-H Q1语句分析三种形态的查询计划：
-- TPC-H Q1
select
l_returnflag,
l_linestatus,
sum(l_quantity) as sum_qty,
sum(l_extendedprice) as sum_base_price,
sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
avg(l_quantity) as avg_qty,
avg(l_extendedprice) as avg_price,
avg(l_discount) as avg_disc,
count(*) as count_order
from
lineitem
where
l_shipdate <=date '1998-12-01' - interval '90' day (3)
group by
l_returnflag,
l_linestatus
order by
l_returnflag,
l_linestatus;
}
当best_agg_plan=1时，在DN上进行了一次聚集，然后结果通过GATHER算子汇总到CN上进行了二次聚集，对应的查询计划如下：
该方法适用于DN第一次聚集后结果集较少并且DN数较少的场景，在CN上进行第二次聚集时的结果集小，CN不会成为计算瓶颈。
当best_agg_plan=2时，在DN上先按照Group By的列进行数据重分布，然后在DN上进行聚集操作，将汇总的结果返回给CN，对应的查询计划如下：
该方法适用于DN第一次聚集后结果集缩减不明显的场景，因为这样可以省略DN上的第一次聚集操作。
当best_agg_plan=3时，在DN上进行一次聚集，然后将聚集结果按照Group By的列进行数据重分布，之后在DN上进行二次聚集得到结果，对应的查询计划如下：
该方法使用于DN第一次聚集后中间结果缩减明显，但最终结果行数比较大的场景。
GaussDB(DWS)中，以上三种方法的选择是根据代价来自动选择。在实际的SQL调优时，如果遇到有聚集方式不合理的场景，可以通过尝试设置best_agg_plan参数，选择最优的聚集方式。
GaussDB(DWS)中实现分组聚集操作有两种方法：
以下面的SQL为例：
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey;
如果使用Sort + GroupAgg的方式，在Sort排序算子里执行时间比较长，因为需要对大量数据进行排序操作。
以上这种场景，可以关闭enable_sort参数，选择使用HashAgg的方式来实现聚集操作，可以获得较好的执行性能。
GaussDB(DWS)中通过count distinct来统计多个列的数据时，通常会使用HashAgg来实现每一个列的统计聚集操作，然后将结果通过Join方式关联起来得到最终结果。
以下面的SQL为例：
select
l_orderkey,
count(distinct l_partkey) as count_partkey,
count(distinct l_suppkey) as count_suppkey,
count(distinct l_linenumber) as count_linenumber,
count(distinct l_returnflag) as count_returnflag,
count(distinct l_linestatus) as count_linestatus,
count(distinct l_shipmode) as count_shipmode
from
lineitem
group by
l_orderkey;
从查询计划来看，通过count distinct统计了lineitem表中的6列数据，是通过6个HashAgg操作来实现的，该SQL执行时消耗的资源相对较高。
如果关闭enable_hashagg参数，优化器会选择Sort + GroupAgg的方式，该SQL执行时消耗的资源相对较少。
在应用开发时，可以根据SQL并发和资源使用情况，通过设置enable_hashagg参数来选择合适的执行计划。
GaussDB(DWS)支持行存储和列存储两种存储模型，用户可以根据应用场景，建表的时候选择行存储还是列存储表。向量化执行将传统的执行模式由一次一元组的模型修改为一次一批元组，配合列存特性，可以带来巨大的性能提升。
如果使用行存表或者是行列混存的场景，由于行存表默认走的是行存执行引擎，最终查询无法走向量化执行引擎。
以下面的SQL为例：
select
l_orderkey,
sum(l_extendedprice * (1 - l_discount)) as revenue,
o_orderdate,
o_shippriority
from
customer_row,
orders,
lineitem
where
c_mktsegment='BUILDING'
and c_custkey=o_custkey
and l_orderkey=o_orderkey
and o_orderdate < date '1995-03-15'
and l_shipdate > date '1995-03-15'
group by
l_orderkey,
o_orderdate,
o_shippriority
order by
revenue desc,
o_orderdate
limit 10;
SQL语句中的customer_row表为行存表，orders和lineitem为列存表，该场景在默认参数的情况下无法走向量化引擎，Row Adapter算子表示将列存数据转为行存数据，对应的查询计划为：
这种场景，可以选择开启enable_force_vector_engine参数，通过向量化执行引擎来执行，Vector Adapter算子表示将行存数据转换为列存数据，每个算子前面的Vector表示改算子为向量化引擎的执行器算子，对应的查询计划为：
从上述计划可以看出，向量化引擎相比行执行引擎，执行性能有数倍的提升效果。
GaussDB(DWS)支持并行计算技术，当系统的CPU、内存、I/O和网络带宽等资源充足时，可以充分利用富余硬件资源，提升语句的执行速度。在GaussDB(DWS)中，通过query_dop参数，来控制语句的并行度，取值如下：
query_dop参数设置的一些原则：
设置query_dop=0可以实现自适应调优，在部分场景下语句执行的并行度没有达到最优，这种情况可以考虑通过query_dop参数设置并行度。
例如下面的SQL：
select count(*) from
(
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey
);
在query_dop=0时使用的并行度为2。
设置query_dop=4时使用的并行度为4，执行时间相比并行度为2时有明显的提升。
在使用GaussDB(DWS)时，全局的GUC参数对集群整体性能影响很大，这里介绍一些常用参数以及推荐的配置。
影响数据库性能的五大内存参数有：max_process_memory、shared_buffers、cstore_buffers、work_mem和maintenance_work_mem。
max_process_memory
max_process_memory是逻辑内存管理参数，主要功能是控制单个CN/DN上可用内存的最大峰值。
计算公式：max_process_memory=物理内存*0.665/(1+主DN个数)。
shared_buffers
设置DWS使用的共享内存大小。增加此参数的值会使DWS比系统默认设置需要更多的System V共享内存。
建议设置shared_buffers值为内存的40%以内。主要用于行存表scan。计算公式：shared_buffers=(单服务器内存/单服务器DN个数)0.40.25
cstore_buffers
设置列存和OBS、HDFS外表列存格式（orc、parquet、carbondata）所使用的共享缓冲区的大小。
计算公式可参考shared_buffers。
work_mem
设置内部排序操作和Hash表在开始写入临时磁盘文件之前使用的内存大小。
ORDER BY，DISTINCT和merge joins都要用到排序操作。Hash表在散列连接、散列为基础的聚集、散列为基础的IN子查询处理中都要用到。
对于复杂的查询，可能会同时并发运行好几个排序或者散列操作，每个都可以使用此参数所声明的内存量，不足时会使用临时文件。同样，好几个正在运行的会话可能会同时进行排序操作。因此使用的总内存可能是work_mem的好几倍。
计算公式：
对于串行无并发的复杂查询场景，平均每个查询有5-10关联操作，建议work_mem=50%内存/10。
对于串行无并发的简单查询场景，平均每个查询有2-5个关联操作，建议work_mem=50%内存/5。
对于并发场景，建议work_mem=串行下的work_mem/物理并发数。
maintenance_work_mem
maintenance_work_mem用来设置维护性操作（比如VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等）中可使用的最大的内存。
当自动清理进程运行时，autovacuum_max_workers倍数的内存将会被分配，所以此时设置maintenance_work_mem的值应该不小于work_mem。
连接相关的参数有两个：max_connections和max_prepared_transactions
max_connections
允许和数据库连接的最大并发连接数。此参数会影响集群的并发能力。
设置建议：
CN中此参数建议保持默认值。DN中此参数建议设置为CN的个数乘以CN中此参数的值。
增大这个参数可能导致GaussDB(DWS)要求更多的System V共享内存或者信号量，可能超过操作系统缺省配置的最大值。这种情况下，请酌情对数值加以调整。
max_prepared_transactions
设置可以同时处于"预备"状态的事务的最大数目。增加此参数的值会使GaussDB(DWS)比系统默认设置需要更多的System V共享内存。
NOTICE:
max_connections取值的设置受max_prepared_transactions的影响，在设
max_connections之前，应确保max_prepared_transactions的值大于或等
max_connections的值，这样可确保每个会话都有一个等待中的预备事务。
max_active_statements
设置全局的最大并发数量。此参数只应用到CN，且针对一个CN上的执行作业。
需根据系统资源（如CPU资源、IO资源和内存资源）情况，调整此数值大小，使得系统支持最大限度的并发作业，且防止并发执行作业过多，引起系统崩溃。
当取值-1或者0时，不限制全局并发数。
在点查询的场景下，参数建议设置为100。
在分析类查询的场景下，参数的值设置为CPU的核数除以DN个数，一般可以设置5~8个。
bulk_write_ring_size
数据并行导入使用的环形缓冲区大小。
该参数主要影响入库性能，建议导入压力大的场景增加DN上的该参数配置。
checkpoint_completion_target
指定检查点完成的目标。
含义是每个checkpoint需要在checkpoints间隔时间的50%内完成。
默认值为0.5，为提高性能可改成0.9。
data_replicate_buffer_size
发送端与接收端传递数据页时，队列占用内存的大小。此参数会影响主备之间复制的缓冲大小。
默认值为128MB，若服务器内存为256G，可适当增大到512MB。
wal_receiver_buffer_size
备机与从备接收Xlog存放到内存缓冲区的大小。
默认值为64MB，若服务器内存为256G，可适当增大到128MB
本篇文章主要介绍了GaussDB(DWS)性能调优涉及到的优化器和系统级GUC参数，通过合理配置这些GUC参数，能够充分利用好CPU、内存、磁盘IO和网络IO等资源，提升语句的执行性能和GaussDB(DWS)集群的整体性能。
关注@华为云开发者联盟点击下方，第一时间了解华为云新鲜技术~
华为云博客_大数据博客_AI博客_云计算博客_开发者中心-华为云
器之心报道
作者：蛋酱
在近日公布的 MSU 2020 比赛结果中，首次亮相的字节跳动 BVC2.0 编码器一举收获了「四个第一」。
首先，让我们看两张图片：
(a) BVC2.0 处理后的图像。
(b) x265 处理后的图像。
上面两张图片是在相同压缩比情况下，x265 和 BVC2.0 的压缩图像效果。这样的对比场景，是否似曾相识？
没错，让人想起了视频网站中「流畅」和「高清」的对比。受移动互联网发展、移动智能终端普及等因素的推动，短视频和直播行业近年来实现了爆发式的增长，但对于业务方来说，存储空间和带宽资源的成本仍然高昂；对于普通用户来说，不清晰的画质和卡顿问题还十分普遍。这些目前所存在的挑战，都对视频编解码技术提出了更高的要求。
从 2005 年开始，俄罗斯莫斯科国立大学（Mosow State University，MSU）每年定期在全球范围内征集各大公司及相关机构研发的视频编码器，在不同的应用场景下对其进行综合测评。视频编码器（Video Codecs Comparison）大赛迄今已连续举办十五届，是视频编码行业内影响力最大的比赛。与往年一样，今年也有很多国内外的顶尖技术团队参赛，分别来自谷歌、英特尔、百度、阿里、腾讯等科技公司，且拥有丰富的比赛经验。
在本年度 MSU2020 offline （1fps）视频编码器比赛中，字节跳动先进视频团队（Advanced Video Group）自主研发的 BVC2.0 编码器从竞争中脱颖而出：在 VMAF、PSNR avg. MSE 两个准则测试中摘得第一名的成绩。同时也在 PSNR avg. log、SSIM 两个准则测试中获得并列第一的排名。
四个「第一」
近日，MSU2020 主办方公开了 20 个团队的测试结果，在 VMAF 准则测试中，字节跳动的 BVC2.0 编码器领先第二名 8％，领先第三名 15%；在 PSNR avg. MSE 准则测试中，则是领先第二名 6％。而在 PSNR avg. log 和 SSIM 准则测试中， BVC2.0 编码器以极微小的差距与阿里、微帧的产品并列第一。
VMAF 准则测试，测试数据越小表示压缩率越高，成绩越好。
PSNR avg. MSE 准则测试，测试数据越小表示压缩率越高，成绩越好。
上图为 PSNR avg. log 准则测试，测试数据越小表示压缩率越高，成绩越好。
上图为 SSIM 准则测试，测试数据越小表示压缩率越高，成绩越好。
据了解，BVC2.0 编码器从框架到算法搭建完全由字节跳动先进视频团队自研，尽管参与人员少，开发周期短，但得益于公司在视频压缩标准领域的技术储备，以及算法方面的创新，最终表现出了更好的压缩性能。
目前 BVC2.0 编码器完全基于传统视频编码和优化技术，随着学界和业界越来越多地使用卷积神经网络等深度学习技术以提高压缩效率、编码优化和视频处理能力。字节跳动先进视频团队表示，团队的相关领域成果未来将融合在下一版本的 BVC2.0 编码器中。
带宽成本大幅降低，画质更清晰，更流畅
未来，BVC2.0 编码器可应用于字节跳动旗下大部分产品，包括抖音、西瓜视频、等 App 的视频类内容处理，以及云计算、云游戏等基础架构领域。
字节跳动也正在计划将 BVC2.0 编码器开放给合作伙伴使用。先进视频团队的张莉博士表示：「将 BVC2.0 编码器应用到公司业务中后，将能够节省 20%-50% 的流量带宽和存储成本。假设一年的带宽成本为 10 亿，那么使用 BVC2.0 编码器有望比目前最优的编码器节省 2-5 亿。」
除了帮助业务节省成本外，对于短视频行业的用户，BVC2.0 编码器也很有意义。在有限的网络带宽资源条件下，BVC2.0 的转码能力，可以让普通用户获得更高画质、更流畅的视频体验。例如，原来只能看标清的用户，现在可以获得高清的体验。
在国内视频编解码技术标准领域，字节跳动也有着很高的贡献度。2002 年，数字音视频编解码技术标准工作组（AVS）的成立标志着中国视频标准化工作的正式起步，迄今 AVS 音视频编码标准已经发展到第三代。经过十几年的发展，AVS 视频编码标准的压缩性已经实现了大幅提升。作为 AVS 第三代视频编码标准的重要技术贡献者之一，字节跳动一直通过组织 AVS3 技术研讨会、分享 AVS3 先进技术等各种形式向工业界和学术界推广 AVS 标准。
去年，字节跳动先进视频团队也曾因视频编码国家标准 AVS 方面的技术功效，获得了「2019 年度 AVS 产业技术创新奖」，字节跳动也是该奖项中的唯一一家互联网公司。
此外，字节跳动先进视频团队成员也在多个国际标准化工作组中担任重要角色，如 VVC、H.265/HEVC、H.264/AVC 等多项标准文本主编及编委等，同时，也是多项多媒体国际标准的重要贡献者之一，包括视频编码标准、系统标准、传输协议、文件格式等。过去两年间，字节跳动先进视频团队累计递交了 260 项以上 H.266/VVC 技术提案，被采纳数量超过 130 项。
张莉博士表示：「视频编码优化和传输是一项重要且非常有挑战的工作，只有持续创新，才能保持不断推动技术升级。我们希望与行业一起，为大家提供更好的视频编码技术能力，提升用户的视频体验。」
参考链接：https://www.compression.ru/video/codec_comparison/hevc_2020/main_report.html
译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：Marc Andreessen十年前说的“软件蚕食世界”不仅完全正确，而且似乎不仅如此：软件正在重塑世界。人类世界的运转已经无法离开软件。在浩如烟海的软件代码当中，哪些对我们起到了关键作用呢？Slate网站邀请了各方人士对那些改变了一切的代码进行评选，这里筛选出36个代码片段。如果你有更好的选项，不妨在评论区留下你的意见。原文作者是Future Tense，标题是：The Lines of Code That Changed Everything。鉴于篇幅太长，我们将分三部分刊出，此为第三部分。
人类历史上最重要的36个代码片段（一）
人类历史上最重要的36个代码片段（二）
年代：1990年代中期
它让网站最平凡的元素也能酷炫起来。
JSFX.FireSpark.prototype.changeColour=function
{
var colour="";
r2=Math.random*255;
g2=r2;
b2=0;
if(!(r2 | g2 | b2))
{
r2=255;
g2=255;
b2=0;
}
colour="#" + dec2hex(r2) + dec2hex(g2) + dec2hex(b2);
this.setBgColor(colour);
}
Roy Whittle
Douglas Englebart和Bill English在1960年代后期发明的鼠标改变了我们与计算机沟通的方式。尽管使用鼠标很直观，但当时的显示技术通常无法跟上鼠标的快速移动。操作系统开发人员于是添加了鼠标轨迹，也就是瞬时的阴影图像，显示出光标在之前的位置，从而更易于跟踪和查找。
在1990年代中期，GeoCities 是第一个提供免费服务，让用户可以轻松创建自己的Web内容的公司。GeoCities 所见即所得（WYSIWYG）的编辑器使得创建者可以轻松地拖拽内容，添加自定义的代码段，包括用于定制访问者看到的鼠标轨迹的代码。在GeoCities的网页上，你的光标可以留下童话般的灰尘、气泡或小小的万圣节蝙蝠的痕迹。这些绚丽的像素是一个时代的缩影，说明我们已经能够自己建立自己的“网络空间”——Nikki Stevens，亚利桑那州立大学博士研究生
年代：1999
让大家在一个地方就能阅读《纽约时报》、Gizmodo 以及Garfield Minus Garfield。
http://www.example.com/main.html
http://www.example.com/blog/post/1
维基百科
通过将新闻报道、博客、blawgs（法律博客）、播客以及其它web内容形式发布成标准格式，RSS代码让你可以用一种简单、有效以及高效的方式去消费各种信息来源。在巅峰时期，大概是从2005年Google Reader推出到2013年Aaron Swartz（致力于RSS 1.0开发的互联网自由主义者）不幸去世的这段时间内，RSS几乎就相当于在去中心化的互联网上发布的代名词。尽管Google Reader已经不复存在，但从新闻聚合器到播客应用，RSS依旧站在可用互联网的最前沿。——David S. Levine，埃隆大学法学院副教授
年代：1999
一个数学错误导致一项任务失败
1999年9月23日，NASA的科学家与价值1.25亿美元的火星气候轨道器失去了联系。经过调查，确定了失联的原因：一家承包商用英制单位给轨道器写了程序，但是NASA的软件用的却是公制。就因为两段代码之间简单的沟通错误，导致轨道器飞到了未知的地方。
很容易会把这种公制——英制的错误当作意外错误而一笔勾销，但这说明了当今软件互联的世界是多么的脆弱。所有的连接技术（电话、宇宙飞船、机器人榨汁机等等）都要靠接口来定义与它者的通信方式。哪怕是最小的差错也会导致混乱。——Charles Duan
年代：大约2000–2001年
开辟了无人机战争的先河。
“捕食者”无人机早期版本的武器化是个标志性的时刻，不仅在技术史上如此，在军事和政治史上亦然。现在，无人系统已经遍布整个战场，重塑了士兵的作战方式，甚至改变士兵的来源。捕食者的武器化也使得美国进入了“无人机战争”的时代。而且，随着鉴于机器人日益自动化、武器化引起的问题，我们现在才刚刚开始。一个简单的程序可能就会带来法律上、道德上甚至是生存性的问题。——PW Singer，《连线战争：21世纪的机器人革命与冲突》作者
年代：2002
为技术（和猫）在现实世界的移动建立了新途径
(define-behavior (bounce
:start-when (or (bump?)
bounce-trigger? )
:abort-when (bump-edge?)
:onetime? t
)
)
iRobot
你永远也不会忘记自己的第一台Roomba：我的大概是在17年前在一个朋友家。当它在房子里面嗡嗡地由着自己的性子转来转去时，我正坐在沙发上哈哈大笑。这是机器人革命的曙光，一场看起来很蠢但是又很认真的革命。（跟炸弹清理机器有着一样DNA的机器人正在数百万个家庭里面吸尘，这一点着实让人吃惊。）从那以后，别人再也难以复制它的成功。Roomba证明，尽管我们的注意力重心已经开始向硬件倾斜（比如波士顿动力怪异的膝盖向后弯、会开门的机器狗）上，但软件对于一件产品的广泛采用可能更为重要。阿西莫夫化的iRobot并没有创造出第一个真空吸尘机器人，但是Roomba成为一个必备的利基产品不是因为它吸尘效果好，而是因为它在房间里面的导航效果不错。就像成千上万的小猫视频可以证明那样，在现代计算时代，几乎没有什么东西能比看着Roomba撞到桌腿、转圈一周然后前进更令人满足的了。——Lowen Liu，Slate
年代：约2003年
令手机网络成为可能的解决方案
[~, b_user]=max(drc(i, :)/_avg_thruput(i, :));
avg_thruput(i+1, :)=(i/(i+1))*avg_thruput(i, :);
avg_thruput(i+1, b_user)=(i/(i+1))*avg_thruput(i, b_user)+drc(i, b_user)/(i+1);
“使用路径分集公平地最大化吞吐量的定向发射机多接收机系统”，美国专利第6444990号，2002年9月10日
任何时候在任何一个地方，手机的数量通常都要比基站数量多。如果不进行调解的话，所有的传输都会相互干扰并阻碍信息的可靠接收。因此，基站需要解决优先级问题：确保所有用户都能完成通话，同时还要考虑到在嘈杂环境的用户需要赋予更多资源才能得到同样服务质量这一点。解决方案？要在个体用户需求与网络整体性能之间进行折衷。比例公平调度可确保所有用户至少享有最低级别的服务，同时最大程度地提高总的网络吞吐量。这是通过将较低的优先级赋予预期需要更多资源的用户来实现的。仅三行代码就让全球所有的3G和4G无线网络正常工作。——Lav Varshney
年代：2008年
激发大家对一种货币的信心的代码，没有它就没有这种货币
double AttackerSuccessProbability(double q, int z)
{
double p=1.0 - q;
double lambda=z * (q / p);
double sum=1.0;
int i, k;
for (k=0; k {
double poisson=exp(-lambda);
for (i=1; i poisson *=lambda / i;
sum -=poisson * (1 - pow(q / p, z - k));
}
return sum;
}
中本聪
不管你是比特币的布道者还是怀疑者，或者不大确定它是什么，你大概都知道这可是个大事物。比特币本身已经获得了数千亿美元的直接投资，但是也许更重要的是，其基础的技术原理，也就是区块链，似乎有着无穷无尽的应用，从确保民主选举到结束非自愿的性接触等等都在它的应用范围。
这一切始于2008年，当匿名的中本聪发表了一份白皮书，宣布要推出比特币。上述代码就是实现的一部分，这些代码的作用是计算出攻击者接管比特币区块链的可能性极小。这里的数学让世界相信，由不可靠的人组成的系统仍然可以信任，这为至少2777种其他加密货币的创建铺平了道路。——Elena Botella
年代：2008年10月至2009年
把受感染的计算机变成恶意的机器人大军，同时又保护其他的一些计算机
; BOOL __cdecl HasUkrainianLocale
push ebx
mov ebx, ds:GetKeyboardLayoutList
push ebp
push esi
xor ebp, ebp
push ebp
push ebp
call ebx
mov esi, eax
cmp esi, ebp
jz short loc_37680A
这段代码是安全研究人员Tillmann Werner和Felix Leder 编写的，后来还进行了功能等效性测试，为的是理解和对抗Conficker 蠕虫。
Tillmann Werner和Felix Leder
十年前，感染Conficker的计算机数量多达1500万台。这是一种利用Windows操作系统的漏洞的病毒。这种病毒虽然令人恐惧，但也因为它的老辣而备受推崇：它会邀请每一台计算机加入到庞大的僵尸大军，等候命令下达，还会阻止受感染的计算机打开安全程序或下载可以清除病毒的补丁程序。其最早版本还有一个非常有趣且很能说明问题的怪癖：如果驻留在任何使用乌克兰键盘或乌克兰IP地址的系统就会自毁。多年后，对该病毒进行逆向工程的主管部门和研究人员得出结论，Conficker的开发者确实是乌克兰人，他们这样设计病毒是为了避免违反自己国家的法律。幸运的是，这些黑客一直都没有动用过那支僵尸大军来作恶，截至到2018年，估计仍有35万台计算机感染这种病毒，这提醒我们娴熟的程序员要想发动国际攻击，有选择地对用户造成破坏可以是多么的容易。——Jane C. Hu
年代：2009
它催生了监视经济。
{"__typename":"PageLikeAction","action_type":"LIKE","label":{"text":"Like"}
2019年9月的Facebook.com 网站
Facebook把点“赞”按钮当作向世界展示我们喜欢辛普森一家或炸薯条的一种手段来兜售。。但实际上，它利用了我们的认知偏见，以及设计的力量，去诱使我们分享更多的信息。由于有了前面Sara Wachter-Boettcher介绍过的像素跟踪，它跟踪我们在互联网的行踪，收集有关我们浏览习惯的数据。Facebook拿走这些信息，再把自己的行为定向广告算法卖给广告主。如果一家户外用品公司想要做广告，Facebook可以锁定那些以前“赞”过远足的文章，访问过露营网站以及有户外朋友的人。当这些用户“赞”了相关公司的广告时，这些信息就会反馈会定向广告算法里面。这样一来，监视和商业操纵就形成了周而复始的循环。这一切都是因为一个小小的蓝色大拇指。——Ari Ezra Waldman，纽约法学院教授
年代：2009年左右
默认开启安全通道来保护网站安全
Strict-Transport-Security: max-age=31536000; includeSubDomains
Mozilla开发人员指南
当你通过普通HTTP协议将信息发送到网站时，这是会泄漏的——别人可能会拦截这段信息并窃听你的信用卡、健康信息以及伴侣的宠物名什么的。HTTPS可以加密你的流量，避免别人窥探信息，但是很长一段时间以来，使用这种更先进的协议一直都是可选的。因此就有了HTTP Strict Transport Security，此这种安全措施可确保从一开始往来该网站的流量就是加密的。如果你想要访问http://google.com，它会自动将你重定向到https://google.com。这就是HSTS的作用。
HSTS还没有普及：估计只有11.1％的网站用到。但2015年春天，重要一刻降临，美国联邦政府和行业合作伙伴对19个政府领域实施HSTS，其中包括Whitehouse.gov，AIDS.gov和donotcall.gov。此后不久，所有联邦机构均要求采用该标准。——Rusty D. Pickens，奥巴马政府白宫前代理新媒体总监
年代：2012年编写，2014年被发现
计算史上传播最广、危害最大的安全漏洞之一
buffer=OPENSSL_malloc(1 + 2 + payload + padding);
bp=buffer;
/* Enter response type, length and copy payload */
*bp++=TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);
bp +=payload;
/* Random padding */
RAND_pseudo_bytes(bp, padding);
来自Naked Security
2014年，安全研究人员在OpenSSL（一个非常受欢迎的开源库）中发现了一个漏洞，大约有三分之二的网站（包括DropBox ，Twitter，Yahoo和GitHub）都用到它——用于在两台计算机之间进行在线通信。Heartbleed使得犯罪分子可以通过影响数百万台设备的缓冲区读取漏洞来窃取未加密的机密信息，包括凭据和加密密钥等。这让大家注意到了依靠开源软件来实现关键安全功能所带来的风险，以及识别已被使用多年的代码漏洞的挑战。从更积极的意义上来说，Heartbleed的发现也引发了迅速而有效的全球反应，包括在全球范围内进行的协调宣传和补救工作，其力度和广度均远远超出了以前针对早期漏洞的许多同类行动。-塔夫茨大学助理教授Josephine Wolff
年代：2017年推出
软件错误，加上企业的贪婪，导致数百人丧生，以及大批飞机停飞。
2018年10月，狮航610航班起飞后不久就发生了一次似乎非常怪异的事故，然后坠入海中。波音向公众保证飞机是安全的，并表示需要进行更多的飞行员培训以及“软件升级”。但是仅仅四个月后，埃塞俄比亚航空的一名飞行员抬升机头的努力做了20次，但飞机的自动系统仍然把机头往下推。起飞后的几分钟内，机上所有人员均告死亡。作为对事故的响应，全球的民航当局这这一型号的飞机都停飞了。调查显示，坠机事故是因为737 Max的设计引起的，尤其是鲜为人知，了解程度不高的软件，可能会强制飞机反复做俯冲动作。——技术史学家，《写入程序的不平等》作者Mar Hicks
译者：boxi。
*请认真填写需求信息，我们会在24小时内与您取得联系。
