前端开发者必备的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;  
} 

最小毗连数计策

（编辑：湖南网）

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