Nginx官方文档(九)【在Win32平台上使用VisualC构建nginx,转换重写规则,WebSocket代理】

在 Win32 平台上使用 Visual C 构建 nginx

先决条件

要在 Microsoft Win32® 平台上构建 nginx,您需要:

  • Microsoft Visual C编译器。已知 Microsoft Visual Studio® 8 和 10 可以正常工作。
  • MSYS
  • 如果您要构建 OpenSSL® 和有 SSL 支持的 nginx,则需要 Perl。例如 ActivePerlStrawberry Perl
  • Mercurial 客户端
  • PCREzlibOpenSSL 库源代码。

构建步骤

在开始构建之前,确保将 Perl、Mercurial 和 MSYS 的 bin 目录路径添加到 PATH 环境变量中。从 Visual C 目录运行 vcvarsall.bat 脚本设置 Visual C 环境。

构建 nginx:

  • 启动 MSYS bash。
  • 检出 hg.nginx.org 仓库中的 nginx 源代码。例如:
hg clone http://hg.nginx.org/nginx
  • 创建一个 build 和 lib 目录,并将 zlib、PCRE 和 OpenSSL 库源码解压到 lib 目录中:
mkdir objs
mkdir objs/lib
cd objs/lib
tar -xzf ../../pcre-8.41.tar.gz
tar -xzf ../../zlib-1.2.11.tar.gz
tar -xzf ../../openssl-1.0.2k.tar.gz
  • 运行 configure 脚本:
auto/configure --with-cc=cl --builddir=objs --prefix= \
--conf-path=conf/nginx.conf --pid-path=logs/nginx.pid \
--http-log-path=logs/access.log --error-log-path=logs/error.log \
--sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp \
--http-proxy-temp-path=temp/proxy_temp \
--http-fastcgi-temp-path=temp/fastcgi_temp \
--with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre-8.41 \
--with-zlib=objs/lib/zlib-1.2.11 --with-openssl=objs/lib/openssl-1.0.2k \
--with-select_module --with-http_ssl_module
  • 运行 make:
nmake -f objs/Makefile

相关内容

Windows 下的 nginx

原文档

http://nginx.org/en/docs/howto_build_on_win32.html


转换重写规则

重定向到主站点

使用共享主机的用户以前仅使用 Apache 的 .htaccess 文件来配置一切,通常翻译下列规则:

RewriteCond  %{HTTP_HOST}  example.org
RewriteRule  (.*)          http://www.example.org$1

像这样:

server {
    listen       80;
    server_name  www.example.org  example.org;
    if ($http_host = example.org) {
        rewrite  (.*)  http://www.example.org$1;
    }
    ...
}

这是一个错误、麻烦而无效的做法。正确的方式是为 example.org 定义一个单独的服务器:

server {
    listen       80;
    server_name  example.org;
    return       301 http://www.example.org$request_uri;
}

server {
    listen       80;
    server_name  www.example.org;
    ...
}

在 0.9.1 之前的版本,重定向可以通过以下方式实现:

rewrite ^ http://www.example.org$request_uri?;

另一个例子是使用了颠倒逻辑,即 所有不是 example.comwww.example.com

RewriteCond  %{HTTP_HOST}  !example.com
RewriteCond  %{HTTP_HOST}  !www.example.com
RewriteRule  (.*)          http://www.example.com$1

应该简单地定义 example.comwww.example.com其他一切

server {
    listen       80;
    server_name  example.com www.example.com;
    ...
}

server {
    listen       80 default_server;
    server_name  _;
    return       301 http://example.com$request_uri;
}

在 0.9.1 之前的版本,重定向可以通过以下方式实现:

rewrite ^ http://example.com$request_uri?;

转换 Mongrel 规则

典型的 Mongrel 规则:

DocumentRoot /var/www/myapp.com/current/public

RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ %{DOCUMENT_ROOT}/system/maintenance.html [L]

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ $1 [QSA,L]

RewriteCond %{REQUEST_FILENAME}/index.html -f
RewriteRule ^(.*)$ $1/index.html [QSA,L]

RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.*)$ $1.html [QSA,L]

RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

应该转换为:

location / {
    root       /var/www/myapp.com/current/public;

    try_files  /system/maintenance.html
               $uri  $uri/index.html $uri.html
               @mongrel;
}

location @mongrel {
    proxy_pass  http://mongrel;
}

原文档

http://nginx.org/en/docs/http/converting_rewrite_rules.html


WebSocket 代理

要将客户端与服务器之间的连接从 HTTP/1.1 转换为 WebSocket,可是使用 HTTP/1.1 中的 协议切换 机制。

然而,有一个微妙的地方:由于 Upgrade 是一个逐跳(hop-by-hop)头,它不会从客户端传递到代理服务器。当使用转发代理时,客户端可以使用 CONNECT 方法来规避此问题。然而,这不适用于反向代理,因为客户端不知道任何代理服务器,这需要在代理服务器上进行特殊处理。

自 1.3.13 版本以来,nginx 实现了特殊的操作模式,如果代理服务器返回一个 101响应码(交换协议),则客户机和代理服务器之间将建立隧道,客户端 通过请求中的 Upgrade 头来请求协议交换。

如上所述,包括 UpgradeConnection 的逐跳头不会从客户端传递到代理服务器,因此为了使代理服务器知道客户端将协议切换到 WebSocket 的意图,这些头必须明确地传递:

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

一个更复杂的例子是,对代理服务器的请求中的 Connection 头字段的值取决于客户端请求头中的 Upgrade 字段的存在:

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        ...

        location /chat/ {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        }
    }

默认情况下,如果代理务器在 60 秒内没有传输任何数据,连接将被关闭。这个超时可以通过 proxy_read_timeout 指令来增加。 或者,代理服务器可以配置为定期发送 WebSocket ping 帧以重置超时并检查连接是否仍然活跃。

原文档

http://nginx.org/en/docs/http/websocket.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
HTML 5 Web Sockets is a powerful and effective technique for real-time information processing. There exists many techniques such as Poling, Long Poling and Streaming that are said to be better earier days. With web sockets, it shows a better outcome for the end user as well as a proper utilization of the server bandwidth. WebSocket is a web technology providing full-duplex communications channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API for in Web IDL is being standardized by the W3C.WebSocket is designed to be implemented in web browsers and web servers, but it can be used by any client or server application. The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. The WebSocket protocol makes possible more interaction between a browser and a web site, facilitating live content and the creation of real-time games. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open. In this way a two-way (bi-directional) ongoing conversation can take place between a browser and the server. A similar effect has been achieved in non-standardized ways using stop-gap technologies such as Comet.In addition, the communications are done over TCP port number 80, which is of benefit for those environments which block non-standard Internet connections using a firewall. WebSocket protocol is currently supported in several browsers including Google Chrome, Internet Explorer, Firefox, Safari and Opera. WebSocket also requires web applications on the server to support it. Here goes a comparison of polling vs Web Sockets.
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值