- 分类于 Network, Ops, AI, Competitions
- 需要 1 分钟阅读时间
Network
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 泛洪攻击。
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 的报文传输格式，通过引入二进制分帧实现性能的提升。
云场景下的网络 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 接收到其连接终止请求的确认 |