Nginx的nginx_http_push_module模块测试

Nginx的nginx_http_push_module模块，能够使nginx服务器成为一个comet服务器

 

能够接受Client端的一个长链接请求，当server端有消息push时，则返回消息给Client

 

1. 编译很简单：

 

–add-module=../slact-nginx_http_push_module

 

2.配置以下：

 

折叠 展开 复制代码

 

1. push_max_reserved_memory 20M;
2. push_authorized_channels_only on;
3. 
    
4. server{
5. listen 80;
6. server_name localhost test.ysz.com;
7. access_log /opt/work/log/nginx_access_ysz.log main;
8. error_log /opt/work/log/nginx_error_ysz.log error;
9. 
    
10. location /publish {
11. set $push_channel_id $arg_id;
12. push_publisher;
13. push_store_messages on;
14. push_message_timeout 2h;
15. push_max_message_buffer_length 10;
16. }
17. location /activity {
18. push_subscriber;
19. set $push_channel_id $arg_id;
20. push_subscriber_concurrency broadcast;
21. default_type text/plain;
22. }
23. }

 

 

3.测试：

 

浏览器端访问http://localhost/activity?id=10000，则请求会被堵塞

 

用python写一个简单的post程序，向http://localhost//publish?id=10000上post数据，则浏览器端会立刻获得该消息

 

注意：请求publish时，若是要发布消息，则必须得是POST请求，并且对应的Content-Type会被转发给长链接的Client。Get请求会返回当前是否有存在的channel_id。具体的Http Push协议细节，可参考http://pushmodule.slact.net/protocol.html

 

 

 

4.一些问题：

 

• 若是push模块放在后端的nginx上，而前段nginx反响代理到后端，当Client发送长链接请求时，
  默认1分钟会直接断掉链接，返回504，不过能够设置proxy_read_timeout时间足够长来解决
• 设置push_subscriber_concurrency broadcast，能够将push消息同时发送给同一个用户开启的多个浏览器窗口，但我在一个浏览器里开多个tab也来请求，却只有一个能获得消息，另一个请求仍旧没有返回。当设置成first时，对应同一个channel_id，若是有多个长链接请求，则只有第一个会等待返回，其它的都返回409。设置成last时，个人测试结果是全部请求都会断掉，彷佛是一个Bug?
• 设置push_store_messages on，当没有对应的长链接请求时，能够暂时把msg缓存起来
• 设置push_authorized_channels_only on能够打开认证功能，只有当publisher给对应的
  channel_id发送过消息后，Client端才能够发起一个长链接请求，不然会返回403 Forbidden错误
• 当client发起一个长链接请求时，accesslog和后端应用是没法知道其发送请求。不过，经过向publish发送一个Get请求来判断是否有对应channel_id的长链接请求.

 

5.部分协议细节：

 

• 订阅者：
  The server MUST accept all valid HTTP GET requests to the subscriber location. All other request methods SHOULD be responded to with a 405 Method Not Allowedstatus code.
  

  Subscriber requests are considered notifications of intent to receive some message. Subscribers may request existing messages, messages that are not yet available, and messages that are no longer available. The requested message is identified using the If-Modified-Since and If-None-Match request headers. A request with no If-Modified-Since header MUST be assumed to be requesting the oldest available message in a channel. Each 200 OK response containing a message MUST have itsLast-Modified and Etag headers set so that a request using those headers will be interpreted as a request for the next available message. Additionally, said 200 OKMUST contain the Content-Type header of the message publisher request, unless no Content-Type header had been provided or it is explicitly overridden by server configuration.

   

  There are several common mechanisms for performing an HTTP server push. The rest of the behavior of the server in response to a subscriber request SHOULD be configurable and MUST be selected from the following list of mechanisms:

   

  Long-Polling

  Requests for existing messages will be responded to immediately; responses to requests for messages not yet available MUST be delayed until the message becomes available. Delayed responses MUST satisfy all of the following conditions:
  

  • A 200 OK response containing the message (and its Content-Type) MUST be sent immediately after the message becomes available
    . The entire response must be indistinguishable from a response to a request for an existing message.
  • If the channel the subscriber is waiting on is deleted or for some reason becomes unavailable, the server MUST immediately send a 410 Gone response.
  • If another subscriber has conflicted with this request, the server MUST immediately send a 409 Conflict response.

   

  Interval-Polling

  All requests will be responded to immediately. Requests for messages not yet available MUST produce a 304 Not Modified response code.

   

  In addition, when the server receives more than one concurrent subscriber request on the same channel, it MUST do one of the following:

   

  Broadcast

  No additional actions are performed

  Last-in, first-out

  All but the most recent long-held subscriber request on the channel are sent a 409 Conflict response.

  First-in, last-out

  All but the oldest request will be sent a 409 Conflict

  
  The server SHOULD make this selection configurable, and MUST default to broadcast behavior.

   

• 发送者：
  
  The server MUST accept all valid HTTP requests to the publisher location. The server, when sent a publisher request, MUST satisfy all of the following conditions:
  

  • GET requests receive a 200 OK response for existing channels and a 404 Not Found otherwise.
  • PUT requests receive a 200 OK response. The request creates a channel if no channel with the given channel id exists.
  • DELETE requests receive a 200 OK if the channel identified by the channel id exists and has been completely deleted. All subscribers MUST have been sent a410 Gone response. Requests for nonexistent channels MUST be responded to with a 404 Not Found.

  • POST requests are used to send messages. The request MAY contain a body in any encoding representing a message to be sent over thechannel. Themessage MUST be immediately delivered to all currently long-held subscriber requests. Additionally, the message MAY be stored for future retrieval and the oldest message stored for the channel MAY be deleted.

     

    A POST request MUST be replied to with a 201 Created if there were any long-held subscribers that have been sent thismessage, and with a 202 Acceptedotherwise.

     

    The Content-Type header of the request MUST be forwarded with the message.