• nginx 反向代理(Reverse Proxy)与耗时记录


              反向代理服务器位于实际的服务器之前,他能够缓存服务器响应,加速访问,同时也启到了负载均衡服务器的效果。反向代理服务器解析客户端请求,根据负载均衡算法转发到不同的后台服务器上。用户和后台服务器之间不再有直接的链接。请求,响应都由反向代理服务器进行转发。优点是和负载均衡服务集成在一起,部署简单。缺点是所有的请求回应都需要经过反向代理服务器。其本身可能会成为性能的瓶颈。著名的 Nginx服务器就可以部署为反向代理服务器,实现WEB 应用的负载均衡。

    image

    代理模式的含义如下图,接受和返回都转发:

    image

    nginx 的反向代理业务流程图如下图:

    image

    通过wireshark监控可以看到,返回的确实是无法看到代理之后的。

    image

    需要注意的是:反向代理负载均衡是工作在OSI网络模型中的应用层,我们可以统称为应用层负载均衡(七层负载均衡)。

    image

    注意:

    反向代理负载均衡不是数据链路层的负载均衡,数据链路层的负载均衡可以实现三角传输。

    image

    数据链路层负载均衡,顾名思义,就是工作在TCP/IP协议最底层的数据链路层,进行负载均衡。我们常用的以太网中,在这一层主要采用数据帧进行通信,每个网卡都具有唯一的MAC地址,数据帧用MAC地址来标识数据的来源与目的地。数据链路层负载均衡通过修改数据包的MAC地址,实现负载均衡。


    这种数据传输方式又称为三角传输,负载均衡数据分发过程中不修改IP地址,只修改目的MAC地址,通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP一致,从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的,由于实际处理请求的真实物理服务器IP和数据请求目的IP一致,不需要通过负载均衡服务器进行地址交换,可将响应数据包直接返回给用户,避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称之为直接路由方式(DR).


    如上图所示,用户请求到达负载均衡服务器114.100.20.200后,负载均衡服务器将数据包的目的MAC地址更改为00:1e:ec:bc:5e:03,并不修改数据包目的IP,由于服务器集群所有服务器的虚拟IP地址和负载均衡服务器IP地址一致,因此数据可以正常传输到达MAC地址为00:1e:ec:bc:5e:03的机器上,该服务器处理完之后,将响应数据包发送到网关服务器,网关服务器直接将数据包发送给用户,响应数据不需要通过负载均衡服务器,这样就避免了负载均衡服务器成为传输瓶颈的可能。


    数据链路层负载均衡是目前使用最广泛的一种负载均衡方式。著名的负载均衡开源产品LVS(Linux Virtual Server),同时支持上面的IP负载均衡和数据链路层负载均衡。

    nginx的负载均衡是通过nginx的upstream模块和proxy_pass反向代理来实现的。

    nginx模块一般被分成三大类:handler、filter和upstream。从本质上说,upstream属于handler,只是他不产生自己的内容,而是通过请求后端服务器得到内容,所以才称为upstream(上游)。这个请求并取得响应内容的整个过程已经被封装到nginx内部。

    参考:
    http://tengine.taobao.org/book/chapter_05.html  
    http://wiki.jikexueyuan.com/project/nginx/load-balancing-module.html 

    在负载均衡时,upstream指令一般用于定义的后端主机列表和负载算法。

    proxy_pass URL 指定代理的后端主机,可以指定 "http" 或 "https" 协议,域名可以是 ip 地址,也可以是 upstream 池名字

      参考: http://liaoph.com/nginx-tutorial/

       

      nginx 的请求配置参考下图:

      image

      nginx日志的耗时

      官方文档:
      http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
      
      ||
      |$request_time|
          request processing time in seconds with a milliseconds resolution;
          time elapsed between the first bytes were read from the client and
          the log write after the last bytes were sent to the client
      
      |$request_time指的就是从接受用户请求数据到发送完回复数据的时间。|
      
      http://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables
      
      ||
      |$upstream_response_time|
          keeps servers response times in seconds with a milliseconds
          resolution. Several responses are also separated by commas and colons.
      
      |$upstream_response_time说的有点模糊,它指的是从Nginx向后端建立连接开始 
      到接受完数据然后关闭连接为 止的时间。||因为会有重试,||它可能有多个时间 
      段。一般来说,||$upstream_response_time 会比||$request_time时间短。|
      
      对于HTTP POST的请求,两者相差特别大。因为Nginx会把HTTP request body缓存 
      住,接受完毕后才会把数据一起发给后端。
      参考:
      http://code.taobao.org/pipermail/tengine-cn/2012-May/000295.html
      http://wuzhangshu927.blog.163.com/blog/static/114224687201310674652147/
      http://blog.chinaunix.net/uid-22312037-id-4089710.html
       

      参考资料:

      构建负载均衡服务器之一 负载均衡与集群详解
      http://linuxnote.blog.51cto.com/9876511/1654565

    • 相关阅读:
      jQuery技巧大放送
      网页挂马工作原理完全分析
      C#常见问题
      网站优化之页面优化
      SQL大全分享
      获得本机的可用的所有打印机
      C#文件操作方法大全
      编程范式及其代表语言
      23种模式简說
      C# Open Source
    • 原文地址:https://www.cnblogs.com/ghj1976/p/5140159.html
    Copyright © 2020-2023  润新知