Nginx upstream与后端的连接默认为短连接,通过HTTP/1.0向后端发起连接,并把请求的"Connection" header设为"close"。Nginx与前端的连接默认为长连接,一个用户跟Nginx建立连接之后,通过这个长连接发送多个请求。如果Nginx只是作为reverse proxy的话,可能一个用户连接就需要多个向后端的短连接。如果后端的服务器(源站或是缓存服务器)处理并发连接能力不强的话,就可能导致瓶颈的出现。
Nginx会在一开始创建connection pool(进程间不共享,可以避免锁),提供给所有向前/后的连接
如果要实现upstream长连接,则每个进程需要另外一个connection pool,里面都是长连接。一旦与后端服务器建立连接,则在当前请求连接结束之后不会立即关闭连接,而是把用完的连接保存在一个keepalive connection pool里面,以后每次需要建立向后连接的时候,只需要从这个连接池里面找,如果找到合适的连接的话,就可以直接来用这个连接,不需要重新创建socket或者发起connect()。这样既省下建立连接时三次握手的时间消耗,又可以避免TCP连接的slow start。如果在keepalive连接池找不到合适的连接,那就按照原来的步骤重新建立连接。假设连接查找时间可以忽略不计,那么这种方法肯定是有益而无害的(当然,需要少量额外的内存)。
具体如何来设计这个keepalive connection pool,不同人有不同的选择。比如Nginx目前的第三方模块upstream keepalive(作者Maxim Dounin)使用了一个queue来做。因为upstream的服务器很可能是多个,所以可能当保持的
Nginx反向代理upstream长连接
最新推荐文章于 2025-03-07 22:17:39 发布