websocket默认端口（Nginx代理WebSocket方法）

本文目录

• Nginx代理WebSocket方法
• Express Websocket使用
• 多用户的春天WebSocket安全问题，怎么解决
• websocket和HTTP使用不同端口可以吗
• 刨根问底HTTP和WebSocket协议（二）
• win7上如何架起websocket服务
• 怎么查看现在swoole监听的端口

Nginx代理WebSocket方法

WebSocket是HTML5下一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯的目的。它与HTTP一样通过已建立的TCP连接来传输数据，但是它和HTTP最大不同是：

1） WebSocket是一种双向通信协议。在建立连接后，WebSocket服务器端和客户端都能主动向对方发送或接收数据，就像Socket一样；
2）WebSocket需要像TCP一样，先建立连接，连接成功后才能相互通信。

WebSocket协议相比较于HTTP协议成功握手后可以多次进行通讯，直到连接被关闭。但是WebSocket中的握手和HTTP中的握手兼容， 它使用HTTP中的Upgrade协议头将连接从HTTP升级到WebSocket。这使得WebSocket程序可以更容易的使用现已存在的基础设施。大部分现在的浏览器都支持WebSocket。

在实际的生产环境中，要求多个WebSocket服务器必须具有高性能和高可用，那么WebSocket协议就需要一个负载均衡层，Nginx从「1.3」版本开始支持WebSocket，其可以作为一个反向代理和为WebSocket程序做负载均衡。

WebSocket协议与HTTP协议不同，但WebSocket握手与HTTP兼容，使用HTTP升级工具将连接从HTTP升级到WebSocket。这允许WebSocket应用程序更容易地适应现有的基础架构。例如，WebSocket应用程序可以使用标准HTTP端口80和443，从而允许使用现有的防火墙规则。

WebSocket应用程序可以在客户端和服务器之间保持长时间运行的连接，从而有助于开发实时应用程序。用于将连接从HTTP升级到WebSocket的HTTP升级机制使用Upgrade和Connection头。反向代理服务器在支持WebSocket时面临一些挑战。一个是WebSocket是一个逐跳协议，因此当代理服务器拦截客户端的升级请求时，需要向后端服务器发送自己的升级请求，包括相应的头文件。此外，由于WebSocket连接长期存在，与HTTP使用的典型短期连接相反，反向代理需要允许这些连接保持打开状态，而不是关闭它们，因为它们似乎处于空闲状态。

允许在客户机和后端服务器之间建立隧道，Nginx支持WebSocket。对于NGINX将升级请求从客户端发送到后台服务器，必须明确设置Upgrade和Connection标题。

解释一下map指令的作用：
***隐藏网址***

以上就是通过nginx代理WebSocket的单向TLS认证方式。

「温馨提醒:」 默认情况下，如果代理服务器在 60 秒内没有传输任何数据，连接将被关闭。可以使用proxy_read_timeout指令增加此超时 。

在WebSocket中，只需要服务器和浏览器通过HTTP协议进行一个握手的动作，然后单独建立一条TCP的通信通道进行数据的传送。

需要在nginx上配置几个超时的设置。如下：

生产例子

***隐藏网址***

Express Websocket使用

本文主要介绍express+websocket的使用

WebSocket 协议在2008年诞生，2011年成为国际标准。所有浏览器都已经支持了。
它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于 服务器推送技术 的一种。
其他特点包括：
（1）建立在 TCP 协议之上，服务器端的实现比较容易。
（2）与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。
（3）数据格式比较轻量，性能开销小，通信高效。
（4）可以发送文本，也可以发送二进制数据。
（5）没有同源限制，客户端可以与任意服务器通信。
（6）协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。

依赖库：express-ws

通过express直接创建一个express template工程，或者通过 express-ts-template 创建一个express typescript工程，以下主要介绍在express-ts-template中的使用。
在package.json文件中，添加对express-ws和@types/express-ws的依赖

在routers目录创建一个wsRouter.ts文件，用于定义ws的router。 在内部定义了WSRouter类，并使用单例模式通过init方法创建，保证ws只初始化一次。如下：

在bin/www中添加对wsRouter的引用，并初始化

chrome中信息

npm控制台信息

测试通过
测试源码： express-ws-example

多用户的春天WebSocket安全问题，怎么解决

WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。WebSocket通信协议于2011年被IETF定为标准RFC 6455，WebSocket API也被W3C定为标准，主流的浏览器都已经支持WebSocket通信。

WebSocket协议是基于TCP协议上的独立的通信协议，在建立WebSocket通信连接前，需要使用HTTP协议进行握手，从HTTP连接升级为WebSocket连接。浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

WebSocket定义了两种URI格式, “ws://“和“wss://”，类似于HTTP和HTTPS, “ws://“使用明文传输，默认端口为80，”wss://“使用TLS加密传输，默认端口为443。

ws-URI: "ws://host" 

WebSocket 握手阶段，需要用到一些HTTP头，升级HTTP连接为WebSocket连接如下表所示。

一次完整的握手连接如下图:

***隐藏网址***

WebSocket应用安全问题

WebSocket作为一种通信协议引入到Web应用中，并不会解决Web应用中存在的安全问题，因此WebSocket应用的安全实现是由开发者或服务端负责。这就要求开发者了解WebSocket应用潜在的安全风险，以及如何做到安全开发规避这些安全问题。

认证

WebSocket 协议没有规定服务器在握手阶段应该如何认证客户端身份。服务器可以采用任何 HTTP 服务器的客户端身份认证机制，如 cookie认证，HTTP 基础认证，TLS 身份认证等。在WebSocket应用认证实现上面临的安全问题和传统的Web应用认证是相同的，如： CVE-2015-0201 , Spring框架的Java SockJS客户端生成可预测的会话ID，攻击者可利用该漏洞向其他会话发送消息; CVE-2015-1482 , Ansible Tower未对用户身份进行认证，远程攻击者通过websocket连接获取敏感信息。

授权

同认证一样，WebSocket协议没有指定任何授权方式，应用程序中用户资源访问等的授权策略由服务端或开发者实现。WebSocket应用也会存在和传统Web应用相同的安全风险，如：垂直权限提升和水平权限提升。

跨域请求

WebSocket使用基于源的安全模型，在发起WebSocket握手请求时，浏览器会在请求中添加一个名为Origin的HTTP头，Oringin字段表示发起请求的源，以此来防止未经授权的跨站点访问请求。WebSocket 的客户端不仅仅局限于浏览器，因此 WebSocket 规范没有强制规定握手阶段的 Origin 头是必需的，并且WebSocket不受浏览器同源策略的限制。如果服务端没有针对Origin头部进行验证可能会导致跨站点WebSocket劫持攻击。该漏洞最早在 2013 年被Christian Schneider 发现并公开，Christian 将之命名为跨站点 WebSocket 劫持 (Cross Site WebSocket Hijacking)(CSWSH)。跨站点 WebSocket 劫持危害大，但容易被开发人员忽视。相关案例可以参考: IPython Notebook( CVE-2014-3429 ), OpenStack Compute( CVE-2015-0259 ), Zeppelin WebSocket服务器 等跨站WebSocket劫持。

上图展示了跨站WebSocket劫持的过程，某个用户已经登录了WebSocket应用程序，如果他被诱骗访问了某个恶意网页，而恶意网页中植入了一段js代码，自动发起 WebSocket 握手请求跟目标应用建立 WebSocket 连接。注意到，Origin 和 Sec-WebSocket-Key 都是由浏览器自动生成的，浏览器再次发起请求访问目标服务器会自动带上Cookie 等身份认证参数。如果服务器端没有检查 Origin头，则该请求会成功握手切换到 WebSocket 协议，恶意网页就可以成功绕过身份认证连接到 WebSocket 服务器，进而窃取到服务器端发来的信息，或者发送伪造信息到服务器端篡改服务器端数据。与传统跨站请求伪造(CSRF)攻击相比，CSRF 主要是通过恶意网页悄悄发起数据修改请求，而跨站 WebSocket 伪造攻击不仅可以修改服务器数据，还可以控制整个双向通信通道。也正是因为这个原因，Christian 将这个漏洞命名为劫持(Hijacking)，而不是请求伪造(Request Forgery)。

理解了跨站WebSocket劫持攻击的原理和过程，那么如何防范这种攻击呢?处理也比较简单，在服务器端的代码中增加 对Origin头的检查，如果客户端发来的 Origin 信息来自不同域，服务器端可以拒绝该请求。但是仅仅检查 Origin 仍然是不够安全的，恶意网页可以伪造Origin头信息，绕过服务端对Origin头的检查，更完善的解决方案可以借鉴CSRF的解决方案-令牌机制。

拒绝服务

WebSocket设计为面向连接的协议，可被利用引起客户端和服务器端拒绝服务攻击，相关案例可参考: F5 BIG-IP远程拒绝服务漏洞( CVE-2016-9253 )。

1. 客户端拒绝服务

WebSocket连接限制不同于HTTP连接限制，和HTTP相比，WebSocket有一个更高的连接限制，不同的浏览器有自己特定的最大连接数,如：火狐浏览器默认最大连接数为200。通过发送恶意内容，用尽允许的所有Websocket连接耗尽浏览器资源，引起拒绝服务。

2. 服务器端拒绝服务

WebSocket建立的是持久连接，只有客户端或服务端其中一发提出关闭连接的请求，WebSocket连接才关闭，因此攻击者可以向服务器发起大量的申请建立WebSocket连接的请求，建立持久连接，耗尽服务器资源，引发拒绝服务。针对这种攻，可以通过设置单IP可建立连接的最大连接数的方式防范。攻击者还可以通过发送一个单一的庞大的数据帧(如, 2^16)，或者发送一个长流的分片消息的小帧，来耗尽服务器的内存，引发拒绝服务攻击, 针对这种攻击，通过限制帧大小和多个帧重组后的总消息大小的方式防范。

中间人攻击

WebSocket使用HTTP或HTTPS协议进行握手请求，在使用HTTP协议的情况下，若存在中间人可以嗅探HTTP流量，那么中间人可以获取并篡改WebSocket握手请求，通过伪造客户端信息与服务器建立WebSocket连接，如下图所示。防范这种攻击，需要在加密信道上建立WebSocket连接，使用HTTPS协议发起握手请求。

输入校验

WebSocket应用和传统Web应用一样，都需要对输入进行校验，来防范来客户端的XSS攻击，服务端的SQL注入，代码注入等攻击。

websocket和HTTP使用不同端口可以吗

1. 防火墙会阻止掉非常用端口
   你可以用80来代理

2. 也就是说websocket一般监听80端口，但个人感觉HTTP和websocket放到一起出错率会变大

3. 如果是个人做小实验的话完全可以，但是实际生产上需要考虑一些安全方面的问题
   

刨根问底HTTP和WebSocket协议（二）

上篇介绍了HTTP1.1协议的基本内容，这篇文章将继续分析WebSocket协议，然后对这两个进行简单的比较。

WebSocket协议还很年轻，RFC文档相比HTTP的发布时间也很短，它的诞生是为了创建一种「 双向通信 」的协议，来作为HTTP协议的一个替代者。那么首先看一下它和HTTP（或者HTTP的长连接）的区别。

上一篇中提到WebSocket的目的就是解决网络传输中的双向通信的问题，HTTP1.1默认使用持久连接（persistent connection），在一个TCP连接上也可以传输多个Request/Response消息对，但是HTTP的基本模型还是一个Request对应一个Response。这在双向通信（客户端要向服务器传送数据，同时服务器也需要实时的向客户端传送信息，一个聊天系统就是典型的双向通信）时一般会使用这样几种解决方案：

WebSocket的目的是取代HTTP在双向通信场景下的使用，而且它的实现方式有些也是基于HTTP的（WS的默认端口是 80 和 443 ）。现有的网络环境（客户端、服务器、网络中间人、代理等）对HTTP都有很好的支持，所以这样做可以充分利用现有的HTTP的基础设施，有点向下兼容的意味。

简单来讲，WS协议有两部分组成：握手和数据传输。

出于兼容性的考虑，WS的握手使用HTTP来实现（此文档中提到未来有可能会使用专用的端口和方法来实现握手），客户端的握手消息就是一个「普通的，带有Upgrade头的，HTTP Request消息」。所以这一个小节到内容大部分都来自于RFC2616，这里只是它的一种应用形式，下面是RFC6455文档中给出的一个客户端握手消息示例：

可以看到，前两行跟HTTP的Request的起始行一模一样，而真正在WS的握手过程中起到作用的是下面几个header域。

如果服务器接受了这个请求，可能会发送如下这样的返回信息，这是一个标准的HTTP的Response消息。 101 表示服务器收到了客户端切换协议的请求，并且同意切换到此协议。RFC2616规定只有切换到的协议「比HTTP1.1更好」的时候才能同意切换。

ws协议默认使用 80 端口，wss协议默认使用 443 端口。

在握手之前，客户端首先要先建立连接，一个客户端对于一个相同的目标地址（通常是域名或者IP地址，不是资源地址）同一时刻只能有一个处于CONNECTING状态（就是正在建立连接）的连接。从建立连接到发送握手消息这个过程大致是这样的：

如果客户端没有处于代理环境中，它就要首先建立一个到达目标地址的直接的TCP连接。

服务端指的是所有参与处理WebSocket消息的基础设施，比如如果某服务器使用Nginx（A）来处理WebSocket，然后把处理后的消息传给响应的服务器（B），那么A和B都是这里要讨论的服务端的范畴。

如果请求是HTTPS，则首先要使用TLS进行握手，如果失败，则关闭连接，如果成功，则之后的数据都通过此通道进行发送。

之后服务端可以进行一些客户端验证步骤（包括对客户端header域的验证），如果需要，则按照RFC2616来进行错误码的返回。

如果一切都成功，则返回成功的Response握手消息。

此握手消息是一个标准的HTTP Response消息，同时它包含了以下几个部分：

一旦这个握手发出去，服务端就认为此WebSocket连接已经建立成功，处于OPEN状态。它就可以开始发送数据了。

Sec-WebSocket-Version可以被通信双方用来支持更多的协议的扩展，RFC6455中定义的值为 13 ，WebSocket的客户端和服务端可能回自定义更多的版本号来支持更多的功能。其使用方法如上文所述。

WebSocket中所有发送的数据使用帧的形式发送。客户端发送的数据帧都要经过掩码处理，服务端发送的所有数据帧都不能经过掩码处理。否则对方需要发送关闭帧。

一个帧包含一个帧类型的标识码，一个负载长度，和负载。负载包括扩展内容和应用内容。

帧类型是由一个4位长的叫Opcode的值表示，任何WebSocket的通信方收到一个位置的帧类型，都要以连接失败的方式断开此连接。
RFC6455中定义的帧类型如下所示：

具体的每一项代表什么意思在这里就不做详细的阐述了。

同样作为应用层的协议，WebSocket在现代的软件开发中被越来越多的实践，和HTTP有很多相似的地方，这里将它们简单的做一个纯个人、非权威的比较：

这一篇简单地将WebSocket协议介绍了一遍，篇幅有点长了，数据帧也没有来得及详述。下篇会继续深扒WebSocket帧传输，另外将通过实例探讨一些WebSocket协议实际使用中的问题。

刨根问底HTTP和WebSocket协议(一）
WebSocket和Socket的区别（WebSocket外传）
刨根问底HTTP和WebSocket协议(三）

win7上如何架起websocket服务

一、进入Windows 7的 控制面板，选择打开或关闭Windows功能.
二、出现安装Windows功能的选项菜单，手动选择需要的功能：WEB管理工具和万维网服务，建议全选。
三、安装完成后，再次进入 控制面板，选择 管理工具，双击 Internet(IIS)管理器 选项，进入IIS设置。
四、进入到IIS7控制面板。
五、选择 Default Web Site，并双击 ASP 的选项，
六、IIS7中ASP 父路径 是没有启用的，要 开启父路径，选择True，搞定父路径选项。
七、配置IIS7的站点。 单击右边的 高级设置 选项，可以设置网站的目录。
八、点击右侧的 绑定...，设置网站的 端口 。
九、点击 默认文档， 设置网站的默认文档。
至此，Windws 7的IIS7设置已经基本完成了，ASP+Access程序可以调试成功。
让同一局域网里面的人也能访问自己的电脑上的网站。
1、依次选择：开始---所有程序---管理工具---高级安全 Windows 防火墙。
（有的电脑在所有程序里面可能没有”管理工具”，这时可以开始----在空白处鼠标右击---属性---自定义---找到系统管理工具，选择“在所有程序菜单上显示”，这样在所有程序里面就有管理工具了
）
2、在高级安全 Windows 防火墙的左边栏，选择“入站规则”。
3、在右边栏选择"新建规则“。
4、在弹出的窗口依次选择：选中端口---下一步---选中TCP以及特定本地端口，填入要开放的端口号（这里填入80，当让也可以选择开放所有端口）---下一步---选中允许连接---下一步---选中所有选项---下一步---填入名称（这里填入IIS）---完成。完成这些之后，跟你处在同一个局域网里面的人就能访问到你电脑上的网站了，到此，在Win7上的ISS就和平时在XP里面一样了。

怎么查看现在swoole监听的端口

监听端口
Swoole-1.8.0新增了对多端口混合协议的支持。Server可以监听多个端口，每个端口都可以设置不同的协议处理方式(set)和回调函数(on)。SSL/TLS传输加密也可以只对特定的端口启用。
未设置协议处理选项的监听端口，默认使用无协议模式
未设置回调函数的监听端口，使用$server对象的回调函数
监听端口返回的对象类型为swoole_server_port
不同监听端口的回调函数，仍然是相同的Worker进程空间内执行
主服务器是WebSocket或Http协议，新监听的TCP端口默认会继承主Server的协议设置。必须单独调用set方法设置新的协议才会启用新协议
监听新端口
$port1 = $server-》listen("127.0.0.1", 9501, SWOOLE_SOCK_TCP);
$port2 = $server-》listen("127.0.0.1", 9502, SWOOLE_SOCK_UDP);
$port3 = $server-》listen("127.0.0.1", 9503, SWOOLE_SOCK_TCP | SWOOLE_SSL);
设置网络协议
$port1-》set(
’open_length_check’ =》 true,
’package_length_type’ =》 ’N’,
’package_length_offset’ =》 0,
’package_max_length’ =》 800000,
);
$port3-》set(
’open_eof_split’ =》 true,
’package_eof’ =》 "\r\n",
’ssl_cert_file’ =》 ’ssl.cert’,
’ssl_key_file’ =》 ’ssl.key’,
);
设置回调函数
$port1-》on(’connect’, function ($serv, $fd){
echo "Client:Connect.\n";
});
$port1-》on(’receive’, function ($serv, $fd, $from_id, $data) {
$serv-》send($fd, ’Swoole: ’.$data);
$serv-》close($fd);
});
$port1-》on(’close’, function ($serv, $fd) {
echo "Client: Close.\n";
});
$port2-》on(’packet’, function ($serv, $data, $addr) {
var_dump($data, $addr);
});
Http/WebSocket
***隐藏网址***
在这样的场景中，可以先创建Http/WebSocket服务器，然后再进行listen监听RPC服务器的端口。 伪代码演示如下：
***隐藏网址***
***隐藏网址***
***隐藏网址***
......设置各个回调......
//多监听一个tcp端口，对外开启tcp服务,并设置tcp服务器的回调
***隐藏网址***
***隐藏网址***