前端开发者必备的Nginx知识

HTTP/1.1 默认支持 TCP 持久连接，HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。对于 TCP 持久连接上的 HTTP 报文，客户端需要一种机制来准确判断结束位置，而在 HTTP/1.0 中，这种机制只有 Content-Length。而在HTTP/1.1 中新增的 Transfer-Encoding: chunked 所对应的分块传输机制可以完美解决这类问题。

nginx同样有着配置chunked的属性chunked_transfer_encoding，这个属性是默认开启的。

Nginx 在启用了GZip的情况下，不会等文件 GZip 完成再返回响应，而是边压缩边响应，这样可以显著提高 TTFB(Time To First Byte，首字节时间，WEB 性能优化重要指标)。这样唯一的问题是，Nginx 开始返回响应时，它无法知道将要传输的文件最终有多大，也就是无法给出 Content-Length 这个响应头部。

所以，在HTTP1.0中如果利用Nginx 启用了GZip，是无法获得 Content-Length 的，这导致HTTP1.0中开启持久链接和使用GZip只能二选一，所以在这里gzip_http_version默认设置为1.1。

gzip_comp_level

•  压缩级别，，级别越高压缩率越大，当然压缩时间也就越长（传输快但比较消耗cpu）。
•  默认值为 1
•  压缩级别取值为1-9

gzip_min_length

•  设置允许压缩的页面最小字节数，Content-Length小于该值的请求将不会被压缩
•  默认值:0
•  当设置的值较小时，压缩后的长度可能比原文件大，建议设置1000以上

gzip_types

•  要采用gzip压缩的文件类型(MIME类型)
•  默认值:text/html(默认不压缩js/css)

负载均衡

什么是负载均衡

如上面的图，前面是众多的服务窗口，下面有很多用户需要服务，我们需要一个工具或策略来帮助我们将如此多的用户分配到每个窗口，来达到资源的充分利用以及更少的排队时间。

把前面的服务窗口想像成我们的后端服务器，而后面终端的人则是无数个客户端正在发起请求。负载均衡就是用来帮助我们将众多的客户端请求合理的分配到各个服务器，以达到服务端资源的充分利用和更少的请求时间。

nginx如何实现负载均衡

Upstream指定后端服务器地址列表

upstream balanceServer {  
    server 10.1.22.33:12345;  
    server 10.1.22.34:12345;  
    server 10.1.22.35:12345;  
} 

在server中拦截响应请求，并将请求转发到Upstream中配置的服务器列表。 

server {  
       server_name  fe.server.com;  
       listen 80;  
       location /api {  
           proxy_pass http://balanceServer;  
       }  
   } 

上面的配置只是指定了nginx需要转发的服务端列表，并没有指定分配策略。

nginx实现负载均衡的策略

轮询策略

默认情况下采用的策略，将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的，但是如果其中某一台服务器压力太大，出现延迟，会影响所有分配在这台服务器下的用户。

upstream balanceServer {  
    server 10.1.22.33:12345;  
    server 10.1.22.34:12345;  
    server 10.1.22.35:12345;  
} 

最小连接数策略

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!