js是干嘛用的;js主要用来做什么 收藏 0

WebSocket能干些啥？

1）通知功能：

保持一个长连接，当服务端游新的消息，能够实时的推送到使用方。像知乎的点赞通知、评论等，都可以使用WebSocket通信。

某些使用H5的客户端，为了简化开发，也会使用WebSocket进行消息的通知，由于它是实时推送的，会有更好的用户体验。

2）数据收集：

一些次优级别的数据，比如行为日志、trace、异常执栈收集等，都可以开辟专门的WebSocket通道进行传输。这能够增加信息的集中度，并能及时的针对用户的行为进行合适的配置推送。由于大多数浏览器内核都支持，它将使客户端APM编程模型变得简单。

3）加密 && 认证：

虽然使用Fiddler、Charles等能够抓到很多WebSocket包。但如果同时开启SSL，传输加密后的二进制数据，会大幅增加破解的成本，会安全的多。

4）反向控制钩子：

这个…由于是双工长连接，服务端完全可以推送一些钩子命令，甚至直接是代码，在客户端进行执行。比如截个屏，录个音，种个小马。用户只要通过了授权申请，剩下的就随你发挥了。

所以就一个梗：支付宝偷偷调用你的相机给你拍照

下面我们就来了解websocket协议：

1.单工： 数据传输只允许在一个方向上的传输，只能一方来发送数据，另一方来接收数据并发送。例如：对讲机

2.半双工：数据传输允许两个方向上的传输，但是同一时间内，只可以有一方发送或接受消息。例如：打电话

3.全双工：同时可进行双向传输。例如：websocket

分版本，版本不同，工作模式不同

1.http1.0：单工。因为是短连接，客户端发起请求之后，服务端处理完请求并收到客户端的响应后即断开连接。

2.http1.1：半双工。默认开启长连接keep-alive，开启一个连接可发送多个请求。

3.http2.0：全双工，允许服务端主动向客户端发送数据。

WebSocket和http一样，都是处于OSI模型中的最高层：应用层。

WebSocket借助http协议进行握手，三次握手成功后，就会变身为TCP通道，从此与http不再相见。

WebSocket是一种在单个TCP连接上进行全双工通信的协议。在WebSocket API中，浏览器和服务器只需要完成一次握手（不是指建立TCP连接的那个三次握手，是指在建立TCP连接后传输一次握手数据），两者之间就直接可以创建持久性的连接，并进行双向数据传输。

不是。目前此协议的受众的也不仅仅是web开发者。

WebSocket只是一种协议，它和http协议一样，使用类似okhttp的组件，可以在任何地方进行调用，甚至可以借助WebSocket实现RPC框架。

• 长轮询就是客户端发送一个请求，服务端将一直在这个连接上等待（当然有一个超长的超时时间），直到有数据才返回，它依然是一个一问一答的模式。比如著名的comted。WebSocket在握手成功后，就是全双工的TCP通道，数据可以主动从服务端发送到客户端，处于链接两端的应用没有任何区别。WebSocket创建的连接和Http的长连接是不一样的。由于Http长连接底层依然是Http协议，所以它还是一问一答，只是Hold住了一条命长点的连接而已。长轮询和Http长连接是阻塞的I/O，但WebSocket可以是非阻塞的（具体是多路复用）

WebSocket的连接创建是借助Http协议进行的。这样设计主要是考虑兼容性，在浏览器中就可以很方便的发起请求，看起来比较具有迷惑性。

下图是一个典型的由浏览器发起的ws请求，可以看到和http请求长的是非常相似的。

但是，它只是请求阶段长得像而已：

请求的地址: 一般是：ws://***，或者是使用了SSL/TLS加密的安全协议wss:，用来标识是WebSocket请求。

1）首先，通过Http头里面的Upgrade域，请求进行协议转换。如果服务端支持的话，就可以切换到WebSocket协议。简单点讲：连接已经在那了，通过握手切换成ws协议，就是切换了连接的一个状态而已。

2）Connection域可以认为是与Upgrade域配对的头信息。像nginx等代理服务器，是要先处理Connection，然后再发起协议转换的。

3）Sec-WebSocket-Key 是随机的字符串，服务器端会用这些数据来构造出一个 SHA-1 的信息摘要。如此操作，可以尽量避免普通 HTTP 请求被误认为 WebSocket 协议。

其他的，像Sec-WebSocket*字样的头信息，表明了客户端支持的子协议以及其他信息。像loT中很流行的mqtt，就可以作为WebSocket的子协议。

使用协程的方式运行 (推荐)

编写事件处理方法，可以接收指定的事件消息数据，并在处理方法中对消息数据进行处理。

• connect 为特殊事件，当客户端连接后自动执行
• disconnect 为特殊事件，当客户端断开连接后自动执行
• connect、disconnect与自定义事件处理方法的函数传入参数不同

• 群发sio.emit(\’my event\’, {\’data\’: \’foobar\’})
• 给指定用户发送sio.emit(\’my event\’, {\’data\’: \’foobar\’}, room=user_sid)
• 给一组用户发送SocketIO提供了房间（room）来为客户端分组sio.enter_room(sid, room_name)将连接的客户端添加到一个room @sio.on(\’chat\’)def begin_chat(sid):sio.enter_room(sid, \’chat_users\’)注意：当客户端连接后，socketio会自动将客户端添加到以此客户端sid为名的room中sio.leave_room(sid, room_name)将客户端从一个room中移除 @sio.on(\’exit_chat\’)def exit_chat(sid):sio.leave_room(sid, \’chat_users\’)sio.rooms(sid)查询sid客户端所在的所有房间给一组用户发送消息的示例@sio.on(\’my message\’)def message(sid, data):sio.emit(\’my reply\’, data, room=\’chat_users\’)也可在群组发消息时跳过指定客户端@sio.on(\’my message\’)def message(sid, data):sio.emit(\’my reply\’, data, room=\’chat_users\’, skip_sid=sid)
• 使用send发送message事件消息对于\’message\’事件，可以使用send方法 sio.send({\’data\’: \’foobar\’})sio.send({\’data\’: \’foobar\’}, room=user_sid)

nginx官网已经给出了例子。主要是Upgrade和Connection头的设置。

Nginx的中的配置如下：

map $http_upgrade $connection_upgrade {

default upgrade;

\’\’close;

}

location /chat/{

proxy_pass http://backend;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection $connection_upgrade;

}

需要注意的是，nginx做负载均衡，不需要配置ip_hash等参数，nginx天然支持。由于ip_hash仅使用ip地址的前三个数字做hash，还有可能造成服务端的不均衡。

特别注意：

在IM聊天系统场景下，Nginx提供给WebSocket的这种所谓的“负载均衡”，只能解决传统分布系统中的SLB服务器要做的事。

通俗地说，Nginx只能帮助完成引导WebSocket客户连接到哪一个WebSocket服务端实例，在IM集群情况下，如果两个用户处于不同的WebSocket实例下时，它们之间的跨实例通信，Nginx是没有办法实现的，这一块的逻辑还是得IM开发者自已来实现。

总而言之，Nginx提供给WebSocket的所谓“负载均衡”，并不是IM开发者认为的那种全功能集群！

#

一、什么是长连接

HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

1. HTTP协议与TCP/IP协议的关系

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

**而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

**

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

**HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

**

**2.1. TCP连接

**

当网络通信时采用TCP协议时，在真正的读写操作之前，客户端与服务器端之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时可以释放这个连接。连接的建立依靠“三次握手”，而释放则需要“四次握手”，所以每个连接的建立都是需要资源消耗和时间消耗的。

**2.2. TCP短连接

**

模拟一下TCP短连接的情况：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。

短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。

2.3. TCP长连接

我们再模拟一下长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

TCP的保活功能主要为服务器应用提供。如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态：

客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位。

客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。

客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。

客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。

由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户端适合使用长连接。在长连接的应用场景下，client端一般不会主动关闭连接，当client与server之间的连接一直不关闭，随着客户端连接越来越多，server会保持过多连接。这时候server端需要采取一些策略，如关闭一些长时间没有请求发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件允许则可以限制每个客户端的最大长连接数，这样可以完全避免恶意的客户端拖垮整体后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费较多时间和带宽。

长连接和短连接的产生在于client和server采取的关闭策略。不同的应用场景适合采用不同的策略。

由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个的客户端连累后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

几句话说清楚JavaScript、V8引擎、NodeJS、NPM，到底是什么东东

小程序开发如火如荼，如果你是程序员，你还不懂小程序的开发，恐怕会被同行认为太LOW了吧！不过，新入行小程序开发者确实会被新的名词搞得一头雾水。

比如JavaScript不是在浏览器端运行吗，怎么还可以写服务器端的程序，NodeJS是干啥的，V8和NodeJS有啥区别，什么NMP命令，它是干嘛的，想把这些东东的本质看透吗，我们来剖析一下吧。

JavaScript

JavaScript是一种属于网络的解释性脚本语言,已经被广泛用于Web应用开发,用来给HTML网页增加动态功能,为用户提供更流畅美观的浏览效果。通常JavaScript脚本是通过嵌入在HTML中来实现自身的功能的。它的解释器被称为JavaScript引擎，为浏览器的一部分。

V8引擎

V8引擎就是JavaScript运行的解释器，是JavaScript一种引擎。它是Google开发的，作为chrome浏览器的JavaScript执行解释器，性能十分优秀，被广泛的使用。

NodeJS

在2009年的欧洲JavaScript大会上， 年轻程序员Ryan Dahl展示了他正在从事的一个项目，该项目是一个集成了Google V8 JavaScript引擎、事件循环和底层I/O应用编程接口(Application Programming Interface, API）的平台。

与其他服务器端的JavaScript平台不同，Dahl的平台中所有I/O原语都是事件驱动的，除此以外别无他途。借助JavaScript的影响力和易用性，Dahl的项目使得编写基于事件驱动的服务器端应用程序的任务由难变易， 因此，该项目受到了热烈欢迎， 并且它的发展、普及和被接受程度都是前所未有的。这个项目被命名为NodeJS。NodeJS不单单是JavaScript引擎，JavaScript引擎只是它的一个子集。

NodeJS中的JavaScript引擎没有BOM、DOM。NodeJS是JavaScript的一种运行环境，是对Google V8引擎进行的封装。是一个服务器端的JavaScript的解释器。

nmp管理工具

除了使用NodeJS语言特性及核心函数，我们还需要使用一些已经编写好的优秀的第三方库， 这也是为什么大多数编程平台都具有一个系统用来下载、 安装和管理第三方模块的原因。 在NodeJS中这个系统被称为NodeJS包管理器(NodePackage Manager, NPM）。NPM是三位一体的系统第三方包库、管理计算机中安装的包的机制以及定义包依赖关系的标准。NPM提供了一种公共注册服务，它包含了程序员在NPM中发布的所有包，NPM还提供了一个命令行工具用来下载、安装和管理这些包。

在早期，NPM和NodeJS是要分别独立安装的，但是从0.6.0版开始，NPM就己经包含在Node的安装包中。NodeJS中含有NPM。

大公司为什么都有API网关？聊聊API网关的作用

API网关我的分析中会用到以下三种场景。

Open API

企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。

Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。

微服务网关

微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。

API服务管理平台

上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。

API网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的API服务管理平台。

一个企业随着信息系统复杂度的提高，必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等，在架构上应该将这三种应用区别开，三种应用的安排级别、访问方式也不一样。

因此在我的设计中将这三种应用分别用不同的网关进行API管理，分别是：API网关（OpenAPI合伙伙伴应用）、API网关（内部应用）、API网关（内部公网应用）。

1、对于OpenAPI使用的API网关来说，一般合作伙伴要以应用的形式接入到OpenAPI平台，合作伙伴需要到 OpenAPI平台申请应用。

因此在OpenAPI网关之外，需要有一个面向合作伙伴的使用的平台用于合作伙伴，这就要求OpenAPI网关需要提供API给这个用户平台进行访问。

如下架构:

当然如果是在简单的场景下，可能并不需要提供一个面向合作伙伴的门户，只需要由公司的运营人员直接添加合作伙伴应用id/密钥等，这种情况下也就不需要合作伙伴门户子系统。

2、对于内网的API网关，在起到的作用上来说可以认为是微服务网关，也可以认为是内网的API服务治理平台。当企业将所有的应用使用微服务的架构管理起来，那么API网关就起到了微服务网关的作用。

而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理，那么API网关起到的就是API服务治理的作用。

架构参考如下：

3、对于公司内部公网应用（如APP、公司的网站），如果管理上比较细致，在架构上是可能由独立的API网关来处理这部分内部公网应用，如果想比较简单的处理，也可以是使用面向合作伙伴的API网关。

如果使用独立的API网关，有以下的好处：

• 面向合作伙伴和面向公司主体业务的优先级不一样，不同的API网关可以做到业务影响的隔离。
• 内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。
• 内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。

基于以上的分析，如果公司有能力，那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关。

1、对于Open API平台的API网关，我分析只能选择API网关作为解决方案，业界没有发现比较好的可以用来作为Open API平台的入口的其他方案。

2、对于作为微服务网关的API网关，业界的选择可以选择的解决方案比较多，也取决于微服务器的实现方案，有一些微服务架构的实现方案是不需要微服务网关的。

Service Mesh，这是新兴的基于无API网关的架构，通过在客户端上的代理完成屏蔽网络层的访问，这样达到对应用层最小的改动，当前Service Mesh的产品还正在开发中，并没有非常成熟可直接应用的产品。发展最迅速的产品是Istio。建议大家密切关注相关产品的研发、业务使用进展。

基于duboo架构，在这个架构中通常是不需要网关的，是由客户端直接访问服务提供方，由注册中心向客户端返回服务方的地址。

私有云开源解决方案如下：

• Kong kong是基于Nginx+Lua进行二次开发的方案， https://konghq.com/
• Netflix Zuul，zuul是spring cloud的一个推荐组件，https://github.com/Netflix/zuul
• orange,这个开源程序是国人开发的， http://orange.sumory.com/

公有云解决方案：

• Amazon API Gateway，https://aws.amazon.com/cn/api-gateway/
• 阿里云API网关，https://www.aliyun.com/product/apigateway/
• 腾讯云API网关， https://cloud.tencent.com/product/apigateway

自开发解决方案：

• 基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于这个方案
• 基于Netty、非阻塞IO模型。通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案，是一种成熟的方案。
• 基于Node.js的方案。这种方案是应用了Node.js天生的非阻塞的特性。
• 基于java Servlet的方案。zuul基于的就是这种方案，这种方案的效率不高，这也是zuul总是被诟病的原因。

如果是要选择一款已有的API网关，那么需要从以下几个方面去考虑。

1、性能与可用性

如果一旦采用了API网关，那么API网关就会作为企业应用核心，因此性能和可用性是必须要求的。

从性能上来说，需要让网关增加的时间消耗越短越好，个人觉得需要10ms以下。系统需要采用非阻塞的IO，如epoll，NIO等。网关和各种依赖的交互也需要是非阻塞的，这样才能保证整体系统的高可用性，如：Node.js的响应式编程和基于java体现的RxJava和Future。

网关必须支持集群部署，任务一台服务器的crash都应该不影响整体系统的可用性。

多套网关应该支持同一管理平台和同一监控中心。如：一个企业的OpenAPI网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。

2、可扩展性、可维护性

一款产品总有不能满足生产需求的地方，因此需求思考产品在如何进行二次开发和维护，是否方便公司团队接手维护产品。

3、需求匹配度

需要评估各API网关在需求上是否能满足，如：如果是OpenAPI平台需要使用API网关，那么需要看API网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OpenAPI核心需求上去思考产品是否能满足要求。如果是微服务网关，那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。

4、是否开源？公司是否有自开发的能力？

现有的开源产品如kong，zuul，orange都有基础的API网关的核心功能，这些开源产品大多离很好的使用有一定的距离，如：没有提供管理功能的UI界面、监控功能弱小，不支持OpenAPI平台，没有公司运营与运维的功能等。当然开源产品能获取源代码，如果公司有比较强的研发能力，能hold住这些开源产品，经过二次开发kong、zuul应该还是适应一些公司，不过需求注意以下一些点：

• kong是基于ngnix+lua的，从公司的角度比较难于找到能去维护这种架构产品的人。需求评估当前公司是否有这个能力去维护这个产品。
• zuul因为架构的原因在高并发的情况下性能不高，同时需要去基于研究整合开源的适配zuul的监控和管理系统。
• orange由于没有被大量使用，同时是国内个人在开源，在可持续性和社区资源上不够丰富，出了问题后可能不容易找到人问。

另外kong提供企业版本的API网关，当然也是基于ngnix+lua的，企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。

5、公有云还是私有云

现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关，当然这些网关的基础功能肯定是没有问题，但是二次开发，扩展功能、监控功能可能就不能满足部分用户的定制需求了。另外很多企业因为自身信息安全的原因，不能使用外网公有网的API网关服务，这样就只有选择私有云的方案了。

在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用，无法做到定制的合作伙伴门户，这也不适合于部分企业的需求。

如果作为微服务网关，大多数情况下是希望网关服务器和服务提供方服务器是要在内网的，在这里情况下也只有私有云的API网关才能满足需求。

综合上面的分析，基础公有云的API网关只有满足一部分简单客户的需求，对于很多企业来说私有云的API网关才是正确的选择。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com