小程序聊天功能都是怎么实现的?可以告知一下吗

小程序聊天功能都是怎么实现的?可以告知一下吗,第1张

程序聊天功能可以通过以下几种方式实现:

WebSocket:小程序可以使用 WebSocket 技术来实现实时聊天功能。WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议,可以实现服务器主动向客户端推送数据,实现实时通信。

轮询:小程序可以使用轮询技术实现聊天功能。轮询是指客户端定时向服务器发送请求,服务器返回数据,客户端再次发送请求,如此循环,以实现实时通信。

长连接:小程序可以使用长连接技术实现聊天功能。长连接是指客户端与服务器建立一条持久的连接,客户端可以随时向服务器发送数据,服务器也可以随时向客户端推送数据,以实现实时通信。

第三方 SDK:小程序可以使用第三方聊天 SDK 实现聊天功能,如融云、环信等。这些 SDK 提供了完整的聊天解决方案,包括聊天界面、消息推送等,可以大大简化开发流程。

无论使用哪种方式,小程序聊天功能都需要考虑安全性、稳定性、性能等因素,以保证用户体验。

公司新上线了一个微信小程序,在测试环境以及小程序体验版上测试一切正常,但上线之后,页面加载尤其慢。

经过运维排查,所有的请求到达服务器后均在1s内处理完成并响应,偶尔有2-3s的请求,极少。

既然服务端处理请求没有问题,那么,加载可能出现在小程序本身或网络延迟,但后者可能性较低。于是,使用fiddler抓包,其中一个加载较慢的请求结果如下:

关键时间节点如下:

· 客户端与服务器完成tcp链接时间是11:31:35(时分秒)

· 客户端开始向服务端发送请求的时间是11:31:36(时分秒)

· 服务端接收到请求的时间是11:31:36(时分秒)

· 服务端开始响应的时间是11:31:46(时分秒)

也就是说,从服务器接收到请求到开始响应耗时10s,可这跟运维查看的日志结果不符!

鉴于上面的抓包结果和生产日志结果相悖,决定使用curl对耗时较长的http请求进行分析。

运行结果如下

对应的结果含义如下:

· time_namelookup :DNS 域名解析的时候,就是把 https://zhihu.com 转换成 ip 地址的过程

· time_connect :TCP 连接建立的时间,就是三次握手的时间

· time_appconnect :SSL/SSH 等上层协议建立连接的时间,比如 connect/handshake 的时间

· time_redirect :从开始到最后一个请求事务的时间

· time_pretransfer :从请求开始到响应开始传输的时间

· time_starttransfer :从请求开始到第一个字节将要传输的时间

· time_total :这次请求花费的全部时间

那么对应的时间点应该是:

· DNS解析耗时:0.005s

· TCP建立连接的耗时:0.035-0.005=0.03s

· SSL握手完成耗时:3.8-0.034=3.7s

· server处理数据的时间:3.8402-3.8401=0.0001s

· 总体的耗时:14.5s

emmm,按照这个结果来看,从服务器开始响应到传输完成一共耗时14.5-3.8=10.7s。

那么这里问题又来了,这结果跟fiddler的结果完全相反,到底是在哪个环节出了问题?

fiddler的结果显示从服务器接收到请求到开始响应耗时10s,是服务器处理请求消耗了10s;而curl显示服务器处理请求只用了0.0001s,响应开始到结束耗时10.7s。到底哪个是对的,难道是根据本身有问题?

于是在跟运维同事一波交流之后,得到请求流转过程如下:

客户端<---------->CDN服务器<---------->Nginx代理<---------->应用服务器<---------->DB

弄清请求流转过程之后,手动发送请求,实时查看Nginx和应用服务器日志,发现请求发出后,间隔一段时间(10s左右)Nginx日志才有输出,接着很快App Server日志也有输出(包括请求和响应)。事实就摆在眼前,是CDN服务器<---------->Nginx代理之间出现了问题,具体是为什么目前还不清楚。

那么fiddler和curl抓包的结果如何解释?

fiddler:从服务器接收到请求到开始响应耗时10s,是正确的。

curl:服务器处理请求只用了0.0001s,响应开始到结束耗时10.7s。这里就有问题了,要想解释得通,只能说time_pretransfer和time_starttransfer是CDN服务器的响应时间,由于配置了CND,在向小程序应用服务器发送请求时,会先请求到CDN服务器此时CDN服务器很快就响应了客户端的请求,但CDN服务器在转发请求到Nginx代理时出现了延迟,因此在curl的请求结果中才会看起来像是响应开始到响应结束耗时较长。

至于为什么请求从CND服务器到应用服务器会出现延迟,目前还没有结论。待更新

http://blog.51cto.com/h2ofly/1957171

http://developer.51cto.com/art/201704/536923.htm?foxhandler=RssReadRenderProcessHandler

1、首先,小程序需要与奶茶点单机建立连接,可以采用网络技术,如TCP/IP协议,将小程序与奶茶点单机连接起来;

2、其次,小程序需要与奶茶点单机进行数据交互,可以采用数据库技术,如MySQL,将小程序与奶茶点单机的数据进行交互;

3、最后,小程序需要实现与奶茶点单机的数据互通,可以采用Web Service技术,将小程序与奶茶点单机的数据进行互通。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/yw/11740347.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-18
下一篇2023-05-18

发表评论

登录后才能评论

评论列表(0条)

    保存