有哪些轻量级web服务器？

“轻量级” Web 服务器，例如 lighthttpd、 litespeed 和 mongrel，可以为项目带来很多的好处。本文调查这种可能性，并展示这些 Web 服务器的适用性。
一个 Web 服务器需要哪些东西？
第一个重要的方面是清楚地理解所调查的领域（请参阅 参考资料，以了解更详细的信息）。终端用户在 Internet 上的基本动作就是 “进入一个 Web 页面”。从大处讲，这牵涉到两个应用程序之间的协作：

• 一个 Web 浏览器，例如 Firefox 或 Internet Explorer，用于请求一个特定的页面，并且以人类可读的方式显示从另一个应用程序那里收到的内容。
• 一个 Web 服务器，通常是在远程机器上，负责对页面请求作出响应，返回 HTML 编码的或类似的数据流。

所有 Web 用户直接与浏览器交互，因此他们的选择和分析相应地有些狂热。而服务器只对站点的技术人员可见。根据 Netcraft 最近的调查，虽然存在很多不同的 Web 服务器，但是其中两种 Web 服务器就占据了 90% 的份额，这两种 Web 服务器是 Apache 和 Internet Information Server (IIS)。它们都是经过高度锤炼的产品，并且声称不仅具有广泛的内在技术特性，而且有很多配套的书籍、增件、顾问、提供商等。那么，它们是否还有值得改造的地方呢？
答案是肯定的。评价一个 Web 服务器的重要指标有：

• 性能：对请求作出响应的速度有多快？
• 可伸缩性：当很多用户同时访问它时，服务器还能继续可靠地运行吗？
• 安全性：服务器是否只执行它应该执行的操作。它在认证用户和加密传输方面提供了怎样的支持？它的使用是否使附近的应用程序或主机变得更易受攻击？
• 可靠性：服务器的失效模式和故障发生率如何？
• 标准遵从性：服务器遵从相关的 RFC 吗？
• 灵活性：是否可以对服务器进行调优，以支持较重的请求负载、需要计算的动态页面或者代价不菲的认证等等？
• 平台需求：该服务器可用于哪些平台？它是否有特定的硬件需求？
• 易管理性：服务器是否易于设置和维护？它是否与日志记录、审计、成本计算等组织标准兼容？

Apache 和 IIS 不能同时在那么多的标准方面做到最好。理论上讲，显然那些定向的产品至少能在以上的一至两个方面超越市场领头产品。
关于轻量级 Web 服务器的一件有趣的、值得调查的事情是，它们之间的竞争远远不止是理论上的：仔细研究表明，它们有很多 东西可以提供，并且即使在很多常见的情况下，它们相对于 Apache 和 IIS 也坚持了自己的风格。虽然可以合理地认为市场领头产品已经经过了小心的优化，从而能够有效地在性能（举个例子）方面避免被击败，但是很多小型的竞争对手因为只提供简单的静态 Web 页面服务，速度反而更快。当使用这些 Web 服务器运行测试时，您会感觉好像是在赛道上驾驶一辆 go-kart 小车，不知不觉竟然超过了 Porsche 和 Viper 车。这还不是全部：有时候，轻量级 Web 服务器可作为那些大哥级服务器的有效补充，而不只是与它们竞争。即使您知道自己将使用 Apache，有时候通过将它与一个轻量级伙伴搭档，反而可以最大限度地利用它。最好的解决方案有时候需要两个或更多 Web 服务器的协作。

回页首
Web 服务的轻巧性
本调查中重点关注的 “轻巧性” 实际上是一种主观质量，就像 “艺术” 或 “风格”。它通常意味着简单、易于安装、流线化、要求低和健壮 —— 比 Apache 和 IIS 更小、更简单，当然，在试图满足大量市场的过程中，它们已经变得异常复杂。出于这个目的，虽然 Java Web Server、AOLserver 和 Zeus 拥有迷人的可移植性和性能优势，但是它们的复杂性和大小使其不得不被拒之门外。
轻量级 Web 服务器可以适用于市场领头产品和其他 “重量级” 服务器无法胜任的情况。例如，整个服务器可以打包在一个文件中。这意味着开发人员可以方便地携带生产环境所需的所有工具。即使在生产服务器上运行的是 Apache，也仍然可以在宾馆的房间里，借助只需数秒钟就可以安装完毕的轻量级 Web 服务器以尝试新想法。而且，由于轻量级 Web 服务器要求很低，因此可以在那些无法负担 IIS 的主机上顺畅地运行。
单文件打包
单文件打包
Apache 需要小心地安装散布在多个目录中的很多文件。与之截然不同的是，下面的 Web 服务器却打包在一个可执行文件中。我的一个雇主 Phaseit 的专长是部署和打包，我们能使 Apache 的安装看上去比平常更简单一些。但是即使我们做得最好，Apache 或 IIS 与轻量级 Web 服务器在 “空间占用” 方面也仍然有很大的差异：前者要占用大量的空间。
小的、轻量级的 Web 服务器还可以在小功率的主机上良好地运行。在我们的公司（Phaseit —— 见 侧栏）中，我们在远程的、条件欠佳或配置较低的环境中的工业计算机上运行专用的 硬件。在这些情况下，能够通过一个对处理能力或磁盘空间要求很低的应用程序来提供 Web 页面是一个很大的优势。这意味着我们的机器可以避免 Apache 的开发和处理能力所带来的开销，构建基于 Web 的管理控制台。
从某种程度上讲，几乎所有轻量级 Web 服务器都是开放源码的。如果我们需要某一款 Web 服务器所特有的行为，那么下面概述的一些 Web 服务器都非常小巧，易于理解，也易于增强，只有两个例外。这些 Web 服务器为嵌入 Web 服务的项目提供极好的原始材料，不管这些 Web 服务是在特殊的硬件中，还是在为在通用计算机上运行而设计的特定应用程序中。它们还广泛用于具有传统外观的 Web 站点：

• YouTube 依靠 lighttpd 快速交付归档的内容，例如视频；
• cdServe 运行 “German Woodworking Machinery and Tools” CD；
• LiteSpeed 宣扬它在 twitter、funnyoride.com、airliners.com、WordPress.com、fanfiction.com、SlashGear、Crer un forum gratuit 和其他著名 Web 站点上担任的角色；
• OpenSUSE、RubyOnRails、MarkaBoo 和其他一些著名站点依赖于 Mongrel；
• http://demon.net、http://bluelight.com、http://mtv.com、The Drudge Report、http://garfield.com 等站点则使用 thttpd；
• 等等。

下面的例子说明了开发人员使用轻量级服务器的轻巧性：在我们公司，我们采用专门的硬件提供办公室电话解决方案。它基于定制的、以传统的 Linux? 应用程序的形式运行的软件。只需一个附加文件和一点 init.d 配置，很容易添加一个强大的 “Web 控制台”，该 Web 控制台能提供硬件和软件的管理界面。 终端用户可以从任何浏览器中监视和配置他们的计算机，而不必安排专门的硬件连接或解决使用 “垂直” 硬件时常见的其他复杂性。
面向服务架构（SOA）被认为难以使用。在我们的经验中，SOA 至少有一部分这方面的缺点阻碍了 Web 服务的使用。我们利用轻量级 Web 服务来设置快速的 SOA，以进行演示。
轻量级服务器甚至可以用于生产数据中心，包括前面列出的 high-profile 站点。性能非常高的站点会将操作分开，从而最大限度地利用缓存、代理等技术。例如，一个基于 Apache 的站点可能采用一种这样的架构：通过小型的 Web 服务器从专用的文件系统提供缓慢变化的图片。终端用户看到的结果实际上是 Apache 和一个或多个辅助 Web 服务器通过协作得到的输出，它们各自担任自己擅长的角色。这样的安排可以以非常低的计算成本提供非常 快的结果。

回页首
手段和目的
虽然轻量级 Web 服务器有很多共同之处，但是各有各的不同。大多数轻量级 Web 服务器是用 C 编写的，但是实践证明，有些其他实现语言也可以成功地用于实现服务器，对此我已经做了实验，这些语言包括 Erlang、Java、Lisp、Lua、Perl、Python 和 Tcl。如果其中有您喜欢的语言，那么也许可以找到适合您的 Web 服务器。
由于很多特定的原因，您可能会将目光投向某种 “不常见” 的语言：

• 教学：使用轻量级 Web 服务器来制定一个重要、但是并不太大的目标。这是获得使用某种语言的经验的好方法。
• 虽然用 C 编写的轻量级 Web 服务器大小为 10-50 KB，更高级的语言有 100 KB 到数 MB 的运行时，但整个 Web 服务器的源文件可能只占几千个字节。这种 Web 服务器占用的空间很小，因此比 Apache 更易于与技术伙伴共享。
• 更高级的语言可以使实验更吸引人 —— 例如，添加一个新的 HTTP/1.1 特性可能只需几行源代码。这些轻量级服务器是非常方便的实验材料。
• 将 HTTP 服务器添加到已有的、用高级语言编写的应用程序中只需增加几行源代码。

Athana 可以作为这些主题的例子。它是用 Python 编写的 Web 服务器。它支持 HTTP 多部分（上传）、会话、 cookie 等。从 0.2.1 版开始，Athana 一直被编写在一个单独的、精心组织的源文件中。
如前所述，不同的轻量级 Web 服务器有着不同的优点，它们或多或少独立于编程语言。所有轻量级 Web 服务器都比 Apache 更小、更易于配置。与 Apache 相比，有些轻量级 Web 服务器更快，有些则快得多。有些则强调安全性、重负载下的从容性、可扩展性或者内存占有量。在任何情况下，都可以以一种不适用于 Apache 的方式彻底地理解这些服务器。
哪些特定的产品使这些可能性成为现实？即使只留意 “轻量级” 服务器，面对的也是一个很大的难于管理的产品集合。不过可以将它们按子类来划分：超轻型、关注安全型、支持特定语言型等等。
我特别喜欢其中的超轻型 Web 服务器，它们比 Apache 小得多。如此小的应用程序可以直接记住，系统地、严密地加以考虑，以证明 它们的安全性或可伸缩性。小型 Web 服务器包括：

• Cheetah Server，用不到一千行的 C 代码编写而成。
• DustMote，一个非常 小的 Web 服务器，用一个大约 3000 字节的 Tcl 源文件实现。
• fnord，大小取决于平台和配置，不超过 20K。虽然很小，但是它支持虚拟主机、CGI 和 keep-alive。
• ihttpd，使用不到 800 行的 C 代码，包括 CGI，并通过 inetd 提供页面。
• im-httpd，非常小的服务器 —— 只有大约 7 KB，链接到 glibc。而且它也非常快。
• mattows，支持 CGI，只有 600 行 C 代码。
• Scrinchy，虽然很小，不到 30KB，但是支持多种脚本编制语言，包括一种特殊用途的、基于栈的 Sy 脚本语言。
• ZWS 演示了一个即使是使用 500 多行带足够注释的 zsh (!) 编写的应用程序 —— 在这里是一个 HTTP 0.9+ 服务器 —— 也可以有多强大。

体积小并不妨碍这些服务器被正式使用。例如，fnord 可以处理数千个同时进行的连接。
也许轻量级作为一个类别最令人印象深刻的成就是高性能服务器：

• cghttpd 是一个小型 Web 服务器，它被理解为使用 2.6 系列内核中可用的异步功能的一个试验品。
• darkhttpd 是一个快速的、单线程的 HTTP/1.1 服务器。
• Gatling 是为高性能设计的。它的特性包括 FTP、IPv6、虚拟主机、CGI 等。
• Kernux 是一个 Linux 内核模块，它实现了一个 HTTP 守护进程。
• lighttpd 是使用率排名第五的 Web 服务器（排名还在上升）。它为很多同时进行的连接进行了优化：“典型的场景是使用 lighttpd 作为一个下载（off-load）服务器，以提供静态内容……”
• LiteSpeed Web Server 是一款轻量级商业 Web 服务器，强调性能和安全性。 LiteSpeed Technologies 公司宣传为静态内容提速了 6 倍，在解释页面方面也有一定的提高。
• Miniature JWS，也称 tjws，它是基于 Java 的 Web 服务器，可以处理 servlet、JSP 和数千个并发连接，而大小只有 77 KB。它的作者声称它 “比 Apache 2.x 快 10%”。
• Yaws 是用 Erlang 编写的一款高性能 HTTP/1.1 服务器。

有些 Web 服务器被实现为类或库，以便嵌入 到较大的应用程序中。 在这些 Web 服务器当中，我发现特别有趣的有：

• EHS —— “嵌入式 HTTP 服务器”，被设计为一个 C++ 类，用于嵌入到较大的 C++ 应用程序；还有
• Embedded TCL Web Server，它是一个很普通的 Web 服务器，支持 SSL 和 Basic Authentication，速度非常快 —— 其作者使它至少与 lighthttpd 和 AOLserver 一样快。它是用不到 100 行 Tcl 编写的。

Python 是几种适合不寻常环境的 Web 服务器的实现语言，这些 Web 服务器包括：

• cdServer 是一个小型的、用 Python 编写的 HTTP 服务器，它 “被设计用来提供来自 CD-ROM 的（静态）内容” 。它在提供动态内容方面能力有限。我们有几个涉及不受影响的 “live CDs” 的项目，在这些项目中像 cdServer 之类的工具很关键。
• edna，一款智能的用 Python 编写的 MP3 服务器，它是用 HTTP 实现的。

还有其他一些用 Perl 和其他不出名的语言编写的轻量级 Web 服务器：

• Camlserv，用 ocaml 编写的一个完整的 Web 服务器，目标是 “高度交互式的 Web 页面”。它由几千行 ocaml 编写而成，其中大部分代码都与 MySQL 和 HTML 的特殊处理有关。
• dhttpd 用和 Apache 相同的格式记录访问。它支持 CGI，并具有内建的 Perl 解释器、虚拟主机、IPv6、带宽管理和安全性等方面的特性。
• DNHTTPD 是用 Perl 编写的，用于 UNIX?。它支持虚拟主机、SSL 连接、CGI 等。
• Jellybean 是用 Perl 编写的基于 HTTP 的 Perl Object Server。
• lns.http 是一个 Common LISP HTTP/1.1 Web 框架。
• Mongrel 是用 Ruby 编写的、用于 HTTP 的一个库和服务器。
• Nanoweb 是用 PHP 编写的一款快速、健壮的 Web 服务器。它宣称具有丰富的特性，包括完全遵从 HTTP/1.1、访问控制、身份验证、虚拟主机、SSL 兼容性等。
• Naridesh 是用 Perl 编写的 Web 服务器。
• OpenAngel 是用 Perl 编写的。它强调的重点是安全性。
• Xavante 是用 Lua 编写的 HTTP/1.1 Web 服务器。
• XSP 是用 C# 编写的，用于运行 ASP.NET。

有时候您可能需要其他一些用 C 编写的、具有不常见的次要优势的轻量级 Web 服务器：

• ABYSS 可以在 UNIX 和 Win32 之间移植，其 “目的是成为完全遵从 HTTP/1.1 的 Web 服务器”。它占用的内存很少。
• Anti-Web HTTPD（也称 “Anti-Web”、“awhttpd” 和 “AW”）是一款单进程、无线程、支持 CGI 的服务器，它强调安全性和简单性。
• MHTTPD 支持从外部文件或 LDAP 服务器进行的 MHTTPD Basic Authentication。
• mini-httpd 可以在一个系统线程中处理多个并发请求，但是在主机上占用的内存或 CPU 很少。
• Naken Web 类似于很多其他的轻量级服务器 —— 它支持 Basic Authentication、静态内容等 —— 但是它的作者将它设计为用于 Webcam 操作，并且在 Gumstix、WRT54GL、OpenWrt 和其他新的平台上运行。
• Null httpd 是一款多线程的、简单的、可移植的 Web 服务器。
• Seminole 是一款商业 Web 服务器，内存需求较小，功能较多。
• thttpd throttle，支持 chroot、 Basic Authentication 等。

from :

不知道你的轻量级是什么意思，我倒是知道一个开源的，非常轻量级，只要一个java文件，你可以非常轻松地把它嵌入到你的应用程序中。

项目的地址：

项目简介：

Tornado

以前一直用 python 自带的功能调试静态站点 (python -m http.server)，但是感觉很慢，而且点链接点快了会报错。最近用 Go 自己写了一个：

, 支持列出目录下的文件、gzip 压缩、digest 身份认证、自定义 404 文件。

自己用自己写的服务器感觉很好，而且想要什么功能可以自己加。

Nginx是一款非常流行的Web服务器，在Github上已有16K+Star，我们经常用它来做静态资源托管或反向代理。最近发现了一款全新的Web服务器Caddy，Star数超越Nginx，标星38K+Star。试用了一下Caddy，发现它使用起来比Nginx优雅多了，功能也很强大，推荐给大家！
SpringBoot实战电商项目mall（50k+star）地址：github.com/macrozheng/…
Caddy简介
Caddy是一款功能强大，扩展性高的Web服务器，目前在Github上已有38K+Star。Caddy采用Go语言编写，可用于静态资源托管和反向代理。

Caddy具有如下主要特性：

• 对比Nginx复杂的配置，其独创的Caddyfile配置非常简单；
• 可以通过其提供的Admin API实现动态修改配置；
• 默认支持自动化HTTPS配置，能自动申请HTTPS证书并进行配置；
• 能够扩展到数以万计的站点；
• 可以在任意地方执行，没有额外的依赖；
• 采用Go语言编写，内存安全更有保证。

安装
首先我们直接在CentOS 8上安装Caddy，使用DNF工具安装无疑是最简单的，Docker安装方式之后也会介绍。

• 使用如下命令通过DNF工具安装Caddy，安装成功后Caddy会被注册成系统服务；

dnf install 'dnf-command(copr)'
dnf copr enable @caddy/caddy
dnf install caddy

• 使用systemctl status caddy查看Caddy的状态，可以发现Caddy已被注册为系统服务，但是还没开启。

使用
下面我们体验下Caddy的基本使用，对于Web服务器来说都是常用的操作，你准能用的上！
基本使用
首先我们来个Caddy的入门使用，让Caddy运行在2015端口上并返回Hello, world!。

• 直接使用caddy命令将输出Caddy的常用命令，基本看介绍就知道如何使用了，标出来的是常用命令；

• 使用caddy start命令可以让Caddy服务在后台运行；

• Caddy默认使用JSON格式的配置文件，但由于JOSN格式配置书写比较麻烦，又提供了Caddyfile这种更加简洁的配置形式，使用如下命令能自动把Caddyfile转化为JSON配置；

caddy adapter

• 我们可以先创建一个名称为Caddyfile的文件，文件内容如下，然后使用caddy adapter将它转换为JSON配置，再使用caddy reload使配置生效，该配置将监听2015端口，并返回Hello, world!；

:2015

respond "Hello, world!"

• 然后我们使用curl命令访问localhost:2015，将返回指定的信息；

• 当然我们还可以使用Caddy提供的Admin API来查看配置信息，使用如下命令即可；

curl localhost:2019/config/

• 当前JSON配置如下，如果你直接使用JSON配置的话需要书写如下配置，使用Caddyfile确实方便很多！

   "apps":{
      "http":{
         "servers":{
            "srv0":{
               "listen":[":2015"],
               "routes":[{
                  "handle":[{
                     "body": "Hello, world!",
                     "handler": "static_response"
                  }]
               }]
            }
         }
      }
   }
}

• Caddyfile基本语法
• 下面案例将使用Caddyfile来进行配置，我们有必要了解下它的语法，Caddyfile的具体语法规则如下。

• 介绍下上图中的关键字，有助于理解。

反向代理
反向代理就是当请求访问你的代理服务器时，代理服务器会对你的请求进行转发，可以转发到静态的资源路径上去，也可以转发到动态的服务接口上去。下面我们以对域名进行代理为例，来讲讲如何进行静态代理和动态代理。
静态代理
静态代理就是将请求代理到不同的静态资源路径上去，这里我们将对docs.macrozheng.com的请求代理到我的文档项目中，对mall.macrozheng.com的请求代理到mall的前端项目中。

• 首先我们修改下本机的host文件：

192.168.3.106 docs.macrozheng.com
192.168.3.106 mall.macrozheng.com

• 然后将我们的文档项目和mall前端项目上传到Caddy的html目录中去，并进行解压操作：

• 修改Caddyfile文件，使用如下配置，修改完成后使用caddy reload命令刷新配置；

http://docs.macrozheng.com{
        root * /mydata/caddy/html/docs
        file_server browse
}

http://mall.macrozheng.com{
        root * /mydata/caddy/html/mall
        file_server browse
}

• 如果你的Caddyfile文件格式不太合格的话，会出现如下警告，直接使用caddy fmt --overwrite格式化并重写配置即可解决；

• 通过docs.macrozheng.com即可访问部署好的文档项目了：

• 通过mall.macrozheng.com即可访问到部署好的前端项目了。

动态代理
动态代理就是把代理服务器的请求转发到另一个服务上去，这里我们将把对api.macrozheng.com的请求代理到演示环境的API服务上去。

• 首先我们修改下本机的host文件，添加如下规则：

192.168.3.106 api.macrozheng.com

• 修改Caddyfile文件，使用如下配置，修改完成后使用caddy reload命令刷新配置；

http://api.macrozheng.com{
        reverse_proxy http://admin-api.macrozheng.com
}

• 之后通过api.macrozheng.com/swagger-ui.html即可访问到mall-admin的API文档页面了。

文件压缩
如果我们的服务器带宽比较低，网站访问速度会很慢，这时我们可以通过让Caddy开启Gzip压缩来提高网站的访问速度。这里我们以mall的前端项目为例来演示下它的提速效果。

• 我们需要修改Caddyfile文件，使用encode指令开启Gzip压缩，修改完成后使用caddy reload命令刷新配置；

http://mall.macrozheng.com{
        root * /mydata/caddy/html/mall
        encode{
            gzip
        }
        file_server browse
}

• 有个比较大的JS文件压缩前是1.7M；

• 压缩后为544K，访问速度也有很大提示；

• 另外我们可以看下响应信息，如果有Content-Encoding: gzip这个响应头表明Gzip压缩已经启用了。

地址重写
有的时候我们的网站更换了域名，但还有用户在使用老的域名访问，这时可以通过Caddy的地址重写功能来让用户跳转到新的域名进行访问。

• 我们需要修改Caddyfile文件，使用redir指令重写地址，修改完成后使用caddy reload命令刷新配置；

http://docs.macrozheng.com{
        redir http://www.macrozheng.com
}

• 此时访问旧域名docs.macrozheng.com会直接跳转到www.macrozheng.com去。

按目录划分
有时候我们需要使用同一个域名来访问不同的前端项目，这时候就需要通过子目录来区分前端项目了。

• 比如说我们需要按以下路径来访问各个前端项目；

www.macrozheng.com #访问文档项目
www.macrozheng.com/admin #访问后台项目
www.macrozheng.com/app #访问移动端项目

• 我们需要修改Caddyfile文件，使用route指令定义路由，修改完成后使用caddy reload命令刷新配置。

http://www.macrozheng.com{
        route /admin/*{
                uri strip_prefix /admin
                file_server{
                        root /mydata/caddy/html/admin
                }
        }
        route /app/*{
                uri strip_prefix /app
                file_server{
                        root /mydata/caddy/html/app
                }
        }
        file_server *{
                root /mydata/caddy/html/www
        }
}

HTTPS
Caddy能自动支持HTTPS，无需手动配置证书，这就是之前我们在配置域名时需要使用http://开头的原因，要想使用Caddy默认的HTTPS功能，按如下步骤操作即可。

• 首先我们需要修改域名的DNS解析，直接在购买域名的网站上设置即可，这里以docs.macrozheng.com域名为例；
• 之后使用如下命令验证DNS解析记录是否正确，注意配置的服务器的80和443端口需要在外网能正常访问；

curl "https://cloudflare-dns.com/dns-query?name=docs.macrozheng.com&type=A" \\
  -H "accept: application/dns-json"

• 修改Caddyfile配置文件，进行如下配置；

docs.macrozheng.com{
        root * /mydata/caddy/html/docs
        file_server browse
}

• 然后使用caddy run命令启动Caddy服务器即可，是不是非常方便

caddy run

Docker支持
当然Caddy也是支持使用Docker进行安装使用的，其使用和直接在CentOS上安装基本一致。

• 首先使用如下命令下载Caddy的Docker镜像；

docker pull caddy

• 然后在/mydata/caddy/目录下创建Caddyfile配置文件，文件内容如下；

http://192.168.3.105:80

respond "Hello, world!"

• 之后使用如下命令启动caddy服务，这里将宿主机上的Caddyfile配置文件、Caddy的数据目录和网站目录挂载到了容器中；

docker run -p 80:80 -p 443:443 --name caddy \\
    -v /mydata/caddy/Caddyfile:/etc/caddy/Caddyfile \\
    -v /mydata/caddy/data:/data \\
    -v /mydata/caddy/html:/usr/share/caddy \\
    -d caddy

• 之后使用docker exec进入caddy容器内部执行命令；

docker exec -it caddy /bin/sh

• 输入Caddy命令即可操作，之后的操作就和我们直接在CentOS上安装一样了。

总结
今天体验了一把Caddy，其强大的指令功能，让我们无需多余的配置即可实现各种功能，使用起来确实非常优雅！尤其是其能自动配置实现HTTPS，非常不错！Nginx能实现的功能Caddy基本都能实现，大家可以对比下之前写的Nginx使用教程 ，你就会发现使用Caddy来实现有多么优雅！