注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

itoedr的it学苑

记录从IT文盲学到专家的历程

 
 
 

日志

 
 

利用nginx/tengine实现页面拦劫新增页脚弹窗  

2014-09-05 17:32:17|  分类: nginx编程 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

利用nginx/tengine可以直接实现页面新增页脚生成友好弹窗内容,比如告示等.

ngx_http_footer_filter_module

在请求的响应末尾输出一段内容。输出内容可配置,并支持内嵌变量。

    location / {
        root html;
        footer_types "text/plain" "text/css" "application/x-javascript";
        footer "$host_comment";
    }

指令

Syntax: footer format
Default: -
Context: http, server, location

在每个HTTP响应的正文结尾插入指定的format内容。如果format中含有变量,会被替换为变量当前的值。

举例:

    location / {
        footer "<!-- $hostname, $year/$month/$day $hour:$minute:$second, $request -->";
        index index.html;
    }

Syntax: footer_types type1 [type2] [type3]
Default: footer_types text/html
Context: http, server, location

定义需要插入footer的响应类型(Response Content-Type)。

原理图示


利用nginx/tengine实现页面拦劫新增页脚弹窗 - itoedr - itoedr的it学苑
 

会话保持ngx_http_upstream_session_sticky_module

::利用此模块实现依据会话来调度upstream的负载均衡

该模块是一个负载均衡模块,通过cookie实现客户端与后端服务器的会话保持, 在一定条件下可以保证同一个客户端访问的都是同一个后端服务器。(这对于一些多回合认证的应用成为重要)

Example 1

# 默认配置:cookie=route mode=insert fallback=on
upstream foo {
   server 192.168.0.1;
   server 192.168.0.2;
   session_sticky;
}

server {
    location / {
        proxy_pass http://foo;
    }
}

Example 2

#insert + indirect模式:
upstream test {
  session_sticky cookie=uid domain=www.xxx.com fallback=on path=/ mode=insert option=indirect;
  server  127.0.0.1:8080;
}

server {
  location / {
    #在insert + indirect模式或者prefix模式下需要配置session_sticky_hide_cookie
    #这种模式不会将保持会话使用的cookie传给后端服务,让保持会话的cookie对后端透明
    session_sticky_hide_cookie upstream=test;
    proxy_pass http://test;
  }
}

指令


语法:session_sticky [cookie=name] [domain=your_domain] [path=your_path] [maxage=time] [mode=insert|rewrite|prefix] [option=indirect] [maxidle=time] [maxlife=time] [fallback=on|off] [hash=plain|md5]

默认值:session_sticky cookie=route mode=insert fallback=on

上下文:upstream

说明:

本指令可以打开会话保持的功能,下面是具体的参数:


cookie设置用来记录会话的cookie名称


domain设置cookie作用的域名,默认不设置


path设置cookie作用的URL路径,默认不设置


maxage设置cookie的生存期,默认不设置,即为session cookie,浏览器关闭即失效


mode设置cookie的模式:


insert: 在回复中本模块通过Set-Cookie头直接插入相应名称的cookie。


prefix: 不会生成新的cookie,但会在响应的cookie值前面加上特定的前缀,当浏览器带着这个有特定标识的cookie再次请求时,模块在传给后端服务前 先删除加入的前缀,后端服务拿到的还是原来的cookie值,这些动作对后端透明。如:"Cookie: NAME=SRV~VALUE"。


rewrite: 使用服务端标识覆盖后端设置的用于session sticky的cookie。如果后端服务在响应头中没有设置该cookie,则认为该请求不需要进行session sticky,使用这种模式,后端服务可以控制哪些请求需要sesstion sticky,哪些请求不需要。


option 设置用于session sticky的cookie的选项,可设置成indirect或direct。indirect不会将session sticky的cookie传送给后端服务,该cookie对后端应用完全透明。direct则与indirect相反。


maxidle设置session cookie的最长空闲的超时时间


maxlife设置session cookie的最长生存期


fallback设置是否重试其他机器,当sticky的后端机器挂了以后,是否需要尝试其他机器


hash 设置cookie中server标识是用明文还是使用md5值,默认使用md5



语法: session_sticky_hide_cookie upstream=name;

默认值: none

上下文: server, location

说明:

配合proxy_pass指令使用。用于在insert+indirect模式和prefix模式下删除请求用于session sticky的cookie,这样就不会将该cookie传递给后端服务。upstream表示需要进行操作的upstream名称。




主动式后端服务器健康检查ngx_http_upstream_check_module


该模块可以为Tengine提供主动式后端服务器健康检查的功能。

该模块在Tengine-1.4.0版本以前没有默认开启,它可以在配置编译选项的时候开启:./configure --with-http_upstream_check_module

Examples

http {
    upstream cluster {
        # simple round-robin
        server 192.168.0.1:80;
        server 192.168.0.2:80;

        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "GET / HTTP/1.0\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://cluster;
        }

        location /status {
            check_status;

            access_log   off;
            allow SOME.IP.ADD.RESS;
            deny all;
       }
    }
}

指令


Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]

Default: 如果没有配置参数,默认值是:interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp

Context: upstream

该指令可以打开后端服务器的健康检查功能。

指令后面的参数意义是:


interval:向后端发送的健康检查包的间隔。


fall(fall_count): 如果连续失败次数达到fall_count,服务器就被认为是down。


rise(rise_count): 如果连续成功次数达到rise_count,服务器就被认为是up。


timeout: 后端健康请求的超时时间。


default_down: 设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的。


type:健康检查包的类型,现在支持以下多种类型


tcp:简单的tcp连接,如果连接成功,就说明后端正常。


ssl_hello:发送一个初始的SSL hello包并接受服务器的SSL hello包。


http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活。


mysql: 向mysql服务器连接,通过接收服务器的greeting包来判断后端是否存活。


ajp:向后端发送AJP协议的Cping包,通过接收Cpong包来判断后端是否存活。


port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口,比如后端提供的是443端口的应用,你可以去检查80端口的状态来判断后端健康状况。默认是0,表示跟后端server提供真实服务的端口一样。该选项出现于Tengine-1.4.0。

  评论这张
 
阅读(94)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017