3个不稳定版本

0.2.1 2021年5月9日
0.2.0 2021年5月9日
0.1.1 2021年3月22日

#1133 in HTTP服务器

MIT许可证

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 kcupminiserve快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