3个不稳定版本
0.2.1 | 2021年5月9日 |
---|---|
0.2.0 | 2021年5月9日 |
0.1.1 | 2021年3月22日 |
#1133 in HTTP服务器
23KB
294 代码行
kcup
kcup
是一个单文件服务器。它将对每个收到的GET
请求返回指定文件(由ENV、CLI参数或STDIN指定)的内容,对于其他请求(任何其他HTTP方法或路径),它返回404。
kcup
是为了帮助处理在特定路径上需要发送通常较小的文件的情况而发明的,例如 MTA STS的/.well-known/mta-sts.txt
。您可以在此相关博客文章中了解更多信息。
请注意该项目和仓库非常简单,甚至没有测试——我可能在轻量级使用后添加一些。单元测试、集成测试和端到端测试的机制(Makefile目标、CI集成等)都已存在,但还没有测试。尽管没有测试,但它确实“正常工作”已进行了基准测试。请自行承担风险。
另请参阅 kcup-go
快速入门
kcup
只需要一个文件的路径即可运行
$ kcup -f <file path>
默认情况下,kcup
将在主机 127.0.01
的端口 5000
上提供服务。kcup
还可以从STDIN获取文件内容,如下所示
$ kcup <<EOF
> your file content
> goes here
> EOF
用法
kcup 0.1.0
USAGE:
kcup [OPTIONS]
FLAGS:
--help Prints help information
-V, --version Prints version information
OPTIONS:
-f, --file <FILE> File to read [env: FILE=]
-h, --host <host> Host [env: HOST=] [default: 127.0.0.1]
-p, --port <port> Port [env: PORT=] [default: 5000]
--stdin-read-timeout-seconds <stdin-read-timeout-seconds>
Amount of seconds to wait for input on STDIN to serve [env: STDIN_READ_TIMEOUT_SECONDS=] [default: 60]
环境变量
环境变量 | 默认值 | 示例 | 描述 |
---|---|---|---|
HOST |
127.0.0.1 |
0.0.0.0 |
kcup 将监听的主机 |
PORT |
5000 |
3000 |
kcup 将监听的端口 |
STDIN_READ_TIMEOUT_SECONDS |
60 |
10 |
尝试从STDIN读取的秒数 |
FILE |
不适用 | /path/to/your/file |
将提供服务的文件的路径 |
TLS_KEY |
不适用 | /path/to/your/tls.key |
包含PEM编码TLS密钥的文件路径 |
TLS_CERT |
不适用 | /path/to/your/tls.crt |
包含CA证书(s)的文件路径 |
有用的Makefile目标
以下目标主要用于开发,测试当前构建,因为它们大多数都依赖于cargo run
。
使用HEREDOC运行当前构建的kcup
$ make run <<EOF
>
> You enter some text
> EOF
cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.04s
Running `target/debug/kcup`
[2021-05-09T02:51:58Z INFO kcup] Server configured to run @ [127.0.0.1:5000]
[2021-05-09T02:51:58Z INFO kcup] No file path provided, waiting for input on STDIN (max 60 seconds)...
[2021-05-09T02:51:58Z INFO kcup] Successfully read input from STDIN
[2021-05-09T02:51:58Z INFO kcup] Read [16] characters
[2021-05-09T02:51:58Z INFO kcup] Starting HTTP server...
在仓库中提供示例文件
$ make example
您还可以使用TLS在仓库中提供示例文件
$ make example-tls
请注意,示例页面不包括在kcup
二进制文件中,您需要在生产时间提供自己的文件来提供。
常见问题解答
为什么这个项目命名为"kcup"?
Keurig创建了一个"K-Cup"冲泡系统,这已经变得有些臭名昭著。
替代方案
miniserve
tl;dr kcup
比miniserve
快2倍,这是预期的,因为它做得更少。
miniserve
是一个旨在通过HTTP提供文件和目录的项目,这是在Reddit上由/u/vlmutolo建议的。由于miniserve
也具有提供单个文件的能力,我使用通常的wrk
命令对其进行了测试,以下是一些结果表。
$ kcup -f /tmp/testfiles/file-1M &
$ miniserve /tmp/testfiles/file-1M -p 5001 &
$ wrk -t12 -c400 -d30s --latency http://127.0.0.1:5000/any/path/will/work # a few times
$ wrk -t12 -c400 -d30s --latency http://127.0.0.1:5001 # a few times
kcup |
miniserve |
|
---|---|---|
延迟 50%(毫秒) | 21.09 | 83.94 |
延迟 75%(毫秒) | 31.04 | 95.73 |
延迟 90%(毫秒) | 40.81 | 107.23 |
延迟 99%(毫秒) | 58.54 | 129.38 |
(线程统计)平均延迟(毫秒) | 23.29 | 84.94 |
(线程统计)延迟标准差(毫秒) | 12.57 | 17.11 |
(线程统计)最大延迟(毫秒) | 120.18 | 182.87 |
每秒请求数 | 11,900 | 4599 |
每秒传输(MB) | 1162 | 450 |
正如您所期望的,kcup
做得很少(尽管重叠部分有一些功能差异),因此其性能比miniserve
好约2倍。
我没有限制进程数量,我的机器相当强大:6个物理核心(12个超线程)和32GB的RAM,因此这些进程使用了它们所需的所有空间。
依赖关系
~16–29MB
~504K SLoC