update 2019年7月20日16:22:23

Author: veaba

docs/migrating_from_0.9/parser_protocol_differences.md

@@ -0,0 +1,46 @@
+## 解析器/协议 差异
+
+这只与用其他语言更新socket.io实现、自定义socket.io客户机等相关。
+
+### 差异1 - 数据包编码
+
+解析现在是基于类和异步的。不是返回单个编码字符串，而是使用一个编码数组作为唯一参数对调用回调进行编码。每个编码都应该按顺序写入传输。这更灵活的让二进制数据传输，下面是一个例子：
+
+```js
+const encoding= parser.encode(packet);
+console.log(encoding); //完全编码的数据包
+```
+
+VS:
+```js
+const encoder= new parser.Encoder();
+encoder.encode(packet,encodings=>{
+    for(let i=0;i<encodings.length;i++){
+        console.log(encodings[i]) //包的编码部分
+    }
+})
+```
+
+### 差异2 - 数据包解码
+
+解码将使事情进一步发展，并且是基于事件的。这是因为某些对象（包含二进制）同时在多个部分中进行编码和解码。这个例子应该有助于理解：
+
+```js
+const packet= parser.decode(decoding);
+console.log(packet) // 要处理的成型socket.io包
+
+```
+VS:
+
+
+```js
+const decoder=  new parser.Decoder();
+decoder.on('decoded',(packet)=>{
+    console.log(packet) // 要处理的成型socket.io包
+})
+
+decoder.add(encodings[0]) // encodings 是从传输接收的两个编码的数组
+decoder.add(encodings[1]) // 添加最后一个元素后，解码器将发出“decoded”
+```
+
+### 

docs/using_multiple_nodes/apache_httpd_configuration.md

@@ -0,0 +1,29 @@
+## Apache HTTPD 配置
+
+```xml
+Header add Set-Cookie "SERVERID=sticky.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
+
+<Proxy "balancer://nodes_polling">
+    BalancerMember "http://app01:3000" route=app01
+    BalancerMember "http://app02:3000" route=app02
+    BalancerMember "http://app03:3000" route=app03
+    ProxySet stickysession=SERVERID
+</Proxy>
+
+<Proxy "balancer://nodes_ws">
+    BalancerMember "ws://app01:3000" route=app01
+    BalancerMember "ws://app02:3000" route=app02
+    BalancerMember "ws://app03:3000" route=app03
+    ProxySet stickysession=SERVERID
+</Proxy>
+
+RewriteEngine On
+RewriteCond %{HTTP:Upgrade} =websocket [NC]
+RewriteRule /(.*) balancer://nodes_ws/$1 [P,L]
+RewriteCond %{HTTP:Upgrade} !=websocket [NC]
+RewriteRule /(.*) balancer://nodes_polling/$1 [P,L]
+
+ProxyTimeout 3
+```
+
+[例子](https://github.com/socketio/socket.io/tree/master/examples/cluster-httpd)

docs/using_multiple_nodes/haproxy_configuration.md

@@ -0,0 +1,21 @@
+## HAProxy 配置
+
+```plain
+# Reference: http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/
+
+listen chat
+  bind *:80
+  default_backend nodes
+
+backend nodes
+  option httpchk HEAD /health
+  http-check expect status 200
+  cookie io prefix indirect nocache # using the `io` cookie set upon handshake
+  server app01 app01:3000 check cookie app01
+  server app02 app02:3000 check cookie app02
+  server app03 app03:3000 check cookie app03
+
+```
+
+[例子](https://github.com/socketio/socket.io/tree/master/examples/cluster-haproxy)
+

docs/using_multiple_nodes/nginx_configuration.md

@@ -0,0 +1,42 @@
+## Nginx 配置
+
+在`nginx.conf`文件的`http {}`部分中，您可以使用要在以下两者之间平衡负载的socket.io进程列表声明`upstream`部分：
+
+```nginx
+http{
+    server{
+        listen 3000;
+        server_name io.yourhost.com;
+
+        location / {
+            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_set_header Host $host;
+
+            proxy_pass http://nodes;
+
+            # 启用websockets
+            proxy_http_version 1.1;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection "upgrade";
+
+            
+            }
+        }
+        upstream nodes {
+            # 基于IP启用粘性会话
+            ip_hash;
+            server app01:3000;
+            server app02:3000;
+            server app03:3000;
+
+        }
+    }
+
+```
+
+请注意`ip_hash`指令，它指示连接将是粘性的。
+
+确保在最顶层配置`worker_process`，以指示nginx应该使用多少worker。您还可能希望调整`events {}`块中的`worker_connections`设置。
+
+[例子](https://github.com/socketio/socket.io/tree/master/examples/cluster-nginx)
+

docs/using_multiple_nodes/passing_events_between_nodes.md

@@ -0,0 +1,13 @@
+## 在节点之间传递事件
+
+既然您有多个Socket.IO节点可以接受连接，那么如果您想向每个人（甚至是某个 [房间](https://socket.io/docs/rooms-and-namespaces/#Rooms) 中的每个人）广播事件，那么就需要在进程或计算机之间传递消息。
+
+负责路由消息的接口就是我们所称的`Apdapter`。您可以在 [socket.io-adapter](https://github.com/socketio/socket.io-adapter) 上实现自己的（通过从socket.io-adapter继承），也可以使用我们在[redis](https://redis.io/)上提供的：[socket.io-redis](https://github.com/socketio/socket.io-redis):
+
+```js
+
+const io = require('socket.io')(3000)
+const redis = require('socket.io-redis');
+io.adapter(redis({host:"localhost",port:6379}));
+
+```

docs/using_multiple_nodes/sticky_load_balancing.md

@@ -0,0 +1,47 @@
+## 粘性负载均衡
+
+如果计划在不同的进程或机器之间分配连接负载，则必须确保与特定会话ID关联的请求连接到发起它们的进程。
+
+
+这是由于某些传输（如xhr轮询或jsonp轮询）依赖于在“socket”的生命周期内触发多个请求。如果不启用粘性负载均衡，这将导致很可怕：
+
+
+```txt
+
+Error during WebSocket handshake: Unexpected response code: 400
+
+```
+
+这意味着升级请求被发送到一个未知socket id的节点，因此是HTTP 400响应。
+
+为了说明为什么需要这样做，请考虑向所有连接的客户机发出事件的示例：
+
+```js
+
+io.emit('hi',"all sockets")
+
+```
+
+很有可能这些客户机中的一些可能有一个活动的双向通信通道，比如`WebSocket`，我们可以立即对其进行写入，但其中一些客户机可能正在使用长轮询。
+
+如果他们使用的是长轮询，那么他们可能已经或可能没有发送一个我们可以写入的请求。他们可能在这些请求之间。在这些情况下，这意味着我们必须在进程中缓冲消息。为了让客户机在发送请求时成功地声明这些消息，最简单的方法是将连接路由到同一进程。
+
+
+如上所述，`WebSocket`传输没有这个限制，因为基础TCP连接在客户机和给定服务器之间保持打开状态。这就是为什么你可能会找到一些只使用`WebSocket`传输的建议：
+
+
+```js
+const client = io('https://io.yourhost.com',{
+    //警告：在这种情况下，没有回滚到长轮询
+    transports:["websocket"] //  或者 [ 'websocket', 'polling' ], 这两者都一样
+})
+```
+
+这两种方法都意味着，当无法建立WebSocket连接时，不会出现长轮询回退，这实际上是socket.io的关键功能之一。在这种情况下，您应该考虑使用原始[WebSocket](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket)，或者像[robust-WebSocket](https://github.com/appuri/robust-websocket)那样的包装器。
+
+
+为了实现粘性会话，有两个主要解决方案：
+
+- 基于起始地址路由客户端
+- 基于cookie路由客户端
+

docs/using_multiple_nodes/using_node.js_cluster.md

@@ -0,0 +1,7 @@
+## 使用Node.js集群
+
+与nginx一样，node.js也通过`cluster`模块提供了内置的集群支持。
+
+Fedor Indutny创建了一个名为[Sticky Session](https://github.com/indutny/sticky-session)的模块，该模块确保文件描述符（即：连接）基于`remoteAddress`（即：IP）进行路由。请注意，这可能会导致路由不平衡，这取决于散列方法。
+
+您还可以根据集群工作进程ID为集群中的每个工作进程分配不同的端口，并使用上面可以找到的配置来平衡负载。