Windows Server 管理
IIS：认真对待的 Windows Web 服务器
IIS 是内置于 Windows Server 中的 Web 服务器：用于进程隔离和回收的应用程序池、用于身份验证和 URL 重写的模块以及与 Microsoft 堆栈的集成（ASP.NET、面向 ADFS 的前端、ARR 类反向代理）。它值得比它作为笨拙的 Apache 替代品的刻板印象更好；它真正的限制是建筑上的，并且知道这些咬合的位置使其易于管理。
要点
- 应用程序池是核心组织单元：每个池都是一个w3wp进程边界，有自己的标识、回收设置和管道模式；标准的大小调整实践是每个应用程序一个池，因为回收崩溃隔离而不会影响邻居。
- 回收需要治理：默认的定期回收（通常为 29 小时）是为了掩盖泄漏，但它们会导致无法解释的会话下降；故意调整回收时间、AlwaysRunning 预加载和空闲超时，而不是接受默认值。
- 模块携带配置：URL 重写、ARR（反向代理）、Windows/Forms 身份验证和通过 ACME 模块进行加密；将 Apache 的公共模块与 IIS 模块进行镜像，但要注意内存，因为模块堆栈是 IIS 膨胀的原因。
- 反向代理形态是合法的：一个或多个 IIS Web 场前面的 ARR 镜像 nginx-as-proxy 模式；当流量主要是静态或大规模 API 反向代理时，nginx 或专用 LB 在成本和简单性方面获胜。
- 配置是底层的 XML（applicationHost.config 加 web.config）；配置转换和种子数据可以通过 CI 很好地发布，但层次结构级别之间的配置斗争是真实存在的；尽可能保留单一事实来源。
- 性能快捷方式：输出缓存（可能的情况下为内核模式）、压缩（静态压缩预热）、WOFF/Brotli 模块和 ARR 缓存规则； SSL/TLS 设置遵循 Windows 密码套件故事（通过注册表或加密策略实现 TLS 1.2/1.3），这是大多数审计结果的来源。
一线手记
我们继承的 IIS 盒子的应用程序池默认为 29 小时回收，这意味着每个客户注销票证都属于日历。设置AlwaysRunning和诚实的调整停止了票证；客户认为我们发现了一个错误。我们找到了默认值。
常见问题
IIS 应该在混合堆栈中位于 nginx 后面吗？
一种常见的、经过验证的模式：nginx 终止 TLS，提供静态文件，并将动态请求反向代理到 IIS 应用程序池，将边缘效率与 Microsoft 应用程序集成相结合；额外的移动部件需要从相同的仪表板进行监控。
.htaccess-class 灵活配置可用吗？
IIS 在目录级别使用带有 URL 重写规则和 IP/安全限制部分的 web.config；存在等效行为，但 IIS 配置层次结构不同，并且必须单独学习重写模块语法。
是什么导致 IIS 应用程序随机注销？
通常回收与进程内会话状态或横向扩展场配对，无需粘性会话/机器密钥对齐；修复是配置（会话状态服务器或AlwaysRunning），而不是神秘的重新启动。
总体而言，它与 Apache 和 nginx 相比如何？
如果应用程序是 Windows 上的 .NET，则 IIS 是一致的选项；对于 Linux 集群和边缘/代理角色，根据我们的网络服务器比较，nginx 或 Apache 是诚实的选择。
Kinetikatech 如何在windows server 管理方面为您提供帮助
这是我们的日常工作：即将推出：Windows Server 的监控、修补和强力保护、相同的 24/7 规则、本机工具。我们的Windows Server 监控和服务器管理服务提供端到端覆盖：评估、实施、24/7 监控，以及 30 分钟内的应急响应。