- 分类于 Network, Ops, AI, Competitions
- 需要 1 分钟阅读时间
Aethoce's Blog
ASC 22-23 回忆录
写在前面
这是一篇关于 ASC 22-23 的回忆录，出于技术保密的考虑，几乎没有任何技术干货，只是我的一些碎碎念。
ASC 22-23 在中国科学技术大学举行，我作为初次参与 ASC 的新人，很幸运的一路来到了决赛现场。
在本届比赛之前，学校并没有一个具体的超算队概念。而是济南超级计算技术研究院和数学与统计学院有深入的合作，从 AIDC 组织遴选了一些有能力的同学来参与相关的的比赛。而我作为 QLU 网络运维（后来单独分离出网络与高性能计算协会）的成员，得到了奇妙熟人关系的推荐和介绍，光速走完流程加入了 AIDC，并顺利的被遴选成为有资格参与 ASC22-23 竞赛的队员。
在参加这个比赛之前，我更多的是做一些网络安全和算法相关的东西，外加从 QLU 网络运维那边得到的 Linux Ops 和集群组建运维的能力。可以说我在 HPC 这个领域算是彻底的小白。在确定了 ASC22-23 的参赛资格后，我在短时间内速成了基本的体系结构和 CUDA 编程、MPI、OpenMP，以及部分高端设备（A100 和 InfiniBand Switch/HCA）的软硬件组建调试能力。
在此必须要感谢拉我上车的好哥们儿，例如旭哥、烁哥以及涛哥，也必须要感谢济南超级计算技术研究院/国家超算济南中心为我们提供的强大经费和先进资源 (括号大学万岁)。
镜像站遭遇 SYN 泛洪攻击的诊断与防御
异常的连接数
近日，镜像站莫名遭到多次攻击，症状表现为 TCP 连接数异常上升，久久得不到释放。后台监控检测到大量 5XX 错误，CPU 负载高，正常业务受到较大影响。
通过使用 netstat 命令可以统计服务器当前的各种 TCP 状态：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
我站在受攻击时的状态列表如下：
TIME_WAIT 168
CLOSE_WAIT 9
SYN_SENT 3
FIN_WAIT1 229
FIN_WAIT2 113
ESTABLISHED 234
SYN_RECV 1272
CLOSING 3
LAST_ACK 97
可以明显发现 SYN_RECV 连接数异常增多。
仅通过这一现象就可以判断为服务器受到了 SYN Flood 泛洪攻击。
Pytorch 学习回顾--线性回归
生成数据集
我们可以调用框架中现有的 API 来读取数据。我们将features和labels作为 API 的参数传递，并在实例化数据迭代器对象时指定batch_size。此外，布尔值is_train表示是否希望数据迭代器对象在每个迭代周期内打乱数据。
def load_array(data_arrays, batch_size, is_train=True):
"""构造一个 PyTorch 数据迭代器。"""
dataset = data.TensorDataset(*data_arrays)
return data.DataLoader(dataset, batch_size, shuffle=is_train)
batch_size = 10
data_iter = load_array((features, labels), batch_size)
HTTP/2带来了什么特性
QLUT 镜像站在圣诞节维护中带来了 HTTP/2 协议的支持。新协议提供了诸多新特性。
如何在服务端启用 BBR 拥塞控制算法
2016 年底，Google 发表了一篇优化 TCP 传输算法的文章，极大的提高了 TCP 的 throughput（吞吐量），并且已经集成到 Linux 4.9 内核中。这个算法就是 BBR(Bottleneck Bandwidth and Round-trip propagation time)。
作为一个软件源镜像站，启用 BBR 将显著提升服务器的带宽利用率。但由于服务器所用的 CentOS 内核版本过低，我们需要先升级系统内核。
如何在 Nginx 上支持 HTTP/2
HTTP/2（原名HTTP 2.0）即超文本传输协议第二版，使用于万维网。HTTP/2 主要基于 SPDY 协议，通过对 HTTP 头字段进行数据压缩、对数据传输采用多路复用和增加服务端推送等举措，来减少网络延迟，提高客户端的页面加载速度。HTTP/2 没有改动 HTTP 的应用语义，仍然使用 HTTP 的请求方法、状态码和头字段等规则，它主要修改了 HTTP 的报文传输格式，通过引入二进制分帧实现性能的提升。
Pytorch 学习回顾--数据预处理
为了能用深度学习来解决现实世界的问题，我们经常从预处理原始数据开始，而不是从那些准备好的张量格式数据开始。在 Python 中常用的数据分析工具中，通常使用pandas软件包。
高性能计算 - 基准测试程序 Linpack（HPL）
自通用计算机时代开始以来，就出现了各种用于评估计算机性能的基准测试程序。这些程序的性质通常反映了构建计算机的预期目的，同时还提供了可以与制造商的理论性能估计进行比较的经验性能测量。
高性能计算中最广泛使用的基准之一就是 Linpack 基准，它的起源是一个线性代数运算包，后来被 Lapack 库和其他竞争对手取代。但 Linpack 的基准测试程序在以后的日子里继续发挥强大的影响力。
HPL，即 (High-Performance Linpack) 是早期 Linpack 的衍生产品，其高度并行化的设计，使得它用于评估 TOP500 超级计算机的性能排名。
QLUT 镜像站的日志监控及预警方案
十分意外镜像站用户增长速度如此之快，面对日均五万左右的用户量，服务器频繁出现各种性能问题。在故障排查的过程中，我意识到服务器需要一套成熟、完整、可靠的日志监控及预警方案。
先前长期使用 goaccess 静态分析 Nginx 的日志，具有滞后性。只能用于单纯的分析总结一段时间内的网站流量状况，而无法做到实时监看服务状态和运行数据。
既然是开源镜像站，那么我们就需要把目光投向开源社区。
云场景下的网络 QoS
公共的网络链路总会不可避免的产生带宽抢占的问题，我们通常使用 QoS 技术保障大多数用户的服务质量。
一台服务器能控制的只有出方向的 QoS，通过 Shaping 将出站流量整形，至于入栈流量只能通过 Policy 决定丢弃哪一部分数据包。
TCP 状态机
一个 TCP 连接在它的生命周期内会有不同的状态。
下图说明了 TCP 连接可能会有的状态，以及基于事件的状态转换。事件中有的是应用程序的操作，有的是接收到了网络发过来的请求。
TCP 状态及其描述如下表。
| 状态 | 描述 |
|---|---|
| LISTEN | 等待来自远程 TCP 应用程序的请求 |
| SYN_SENT | 发送连接请求后等待来自远程端点的确认。TCP 第一次握手后客户端所处的状态 |
| SYN-RECEIVED | 该端点已经接收到连接请求并发送确认。该端点正在等待最终确认。TCP 第二次握手后服务端所处的状态 |
| ESTABLISHED | 代表连接已经建立起来了。这是连接数据传输阶段的正常状态 |
| FIN_WAIT_1 | 等待来自远程 TCP 的终止连接请求或终止请求的确认 |
| FIN_WAIT_2 | 在此端点发送终止连接请求后，等待来自远程 TCP 的连接终止请求 |
| CLOSE_WAIT | 该端点已经收到来自远程端点的关闭请求，此 TCP 正在等待本地应用程序的连接终止请求 |
| CLOSING | 等待来自远程 TCP 的连接终止请求确认 |
| LAST_ACK | 等待先前发送到远程 TCP 的连接终止请求的确认 |
| TIME_WAIT | 等待足够的时间来确保远程 TCP 接收到其连接终止请求的确认 |