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.