当上游出错时，作为负载均衡的Nginx可以实时更换Server，在客户端无感知的情况下重新转发HTTP请求。这一功能在Nginx指令中称为next upstream，本文将详细介绍其用法及实现原理。
在OSI网络模型中，传输层的TCP协议通过内核提供的系统调用向Nginx反馈错误，表示层的TLS/SSL协议通过openssl库向Nginx返回错误，而应用层的HTTP协议（或者uwsgi、gRPC、CGI、memcached等协议）通过Response的Decode解码流程返回错误。当Nginx能够通过重试解决这些错误时，我们可以使用next upstream机制对客户端隐藏个别上游Server由于宕机、网络异常产生的错误，这可以极大的提升整个分布式系统的可用性。
接管局通知，个人站点不得有评论功能，原先wordpress+mysql的博客站点（搭建方式见这里）需要重构。干脆基于hexo搭建了静态站点，原先的文章已经迁移了过来，大家的评论只能放弃了。本文介绍hexo静态站点的搭建方法。
静态站点的优点在于部署简单、性能优异，比如你可以将其部署在免费的github page上，甚至无须购买域名即可对外提供服务（你可以点击russelltao.github.io查看我的github页面）。再比如，公有云提供的静态站点服务，可以将其自动部署到CDN站点上（腾讯云的Hexo部署插件见这里），用户体验非常好。文章、图片等资源的备份也很简单，可以直接连同代码一起存放在git仓库中。
负载均衡是Nginx的核心应用场景，本文将介绍官方提供的5种负载均衡算法及其实现细节。
Nginx提供的Scalability，主要由复制扩展（AKF X轴）和用户数据扩展（AKF Z轴）组成。所谓复制扩展，是指上游Server进程是完全相同的，因此可以采用最少连接数、Round Robin轮询、随机选择等算法来分发流量。所谓用户数据扩展，是指每个上游Server只处理特定用户的请求，对这种场景Nginx提供了支持权重的哈希算法，以及支持虚拟节点的一致性哈希算法。
自2017年起HTTP3协议已发布了34个Draft，推出在即，Chrome、Nginx等软件都在跟进实现最新的草案。本文将介绍HTTP3协议规范、应用场景及实现原理。
2015年HTTP2协议正式推出后，已经有接近一半的互联网站点在使用它：
（图片来自https://w3techs.com/technologies/details/ce-http2）
HTTP2协议虽然大幅提升了HTTP/1.1的性能，然而，基于TCP实现的HTTP2遗留下3个问题：
上一篇文章中，我介绍了如何定制属于你自己的Nginx，本文将介绍nginx.conf文件的配置语法、使用方式，以及如何学习新模块提供的配置指令。
每个Nginx模块都可以定义自己的配置指令，所以这些指令的格式五花八门。比如content_by_lua_block后跟着的是Lua语法，limit_req_zone后则跟着以空格、等号、冒号等分隔的多个选项。这些模块有没有必然遵循的通用格式呢？如果有，那么掌握了它，就能快速读懂生产环境复杂的nginx.conf文件。