回答来自于问答智囊团成员：linpeiyang@云通信 专栏：https://cloud.tencent.com/developer/article/1750251 客户提到文字信息没有失败，说明消息上行到云通信IM后台 -> 云通信IM后台处理 -> 云通信IM后台下发消息给用户APP 这条消息收发的通路是没有问题的。 而云通信IM对图片信息&语音信息的处理逻辑 与 文字信息的区别在于， 对前者会将信息以文件形式存储到腾讯云COS，得到一个COS的URL传给云通信IM后台，云通信后台经过处理，同样将URL下发给消息接收方的用户APP， APP通过URL去腾讯云COS下载文件，展示给用户。 显然是与COS有关了。 日志分析 拿到用户终端的SDK日志，很容易发现了问题原因： 📷 usersig参数丢失 图片语音消息上传COS之前，需要调用REST API获取COS Token，此处UserSig这个参数丢失了，导致报错。 关于REST API调用，可参阅：https://cloud.tencent.com/document/product/269/1519 关于UserSig登录鉴权， 可参阅：https://cloud.tencent.com/developer/article/1750246 为什么UserSig会丢失 继续分析终端日志发现，此客户在已经登录成功过的情况下，之后杀掉应用再重新打开应用，SDK初始化之后，此客户的登录逻辑是使用了SDK V1接口autoLogin自动登录： 📷 autologin自动登录 autoLogin接口说明： 自动登录类似“记住密码”的功能，如果上一次已经成功登录，那么一段时间内都只需要传入用户名就可以完成登录。 相比于普通的 login(TIMLoginParam) 接口，该接口可以减少 IM SDK 向您的服务器索要 UserSig 的频率， 既可以加快登录速度，又能减少你的 UserSig 服务器压力，也在一定程度上降低了 UserSig 泄漏的风险。首次登录之后，SDK 会把登录信息存在在本地（UserSig存在内存，登录凭证存在本地），下次登录即可调用自动登录 问题原因： 用户登录成功过一次之后，UserSig存在内存，登录凭证存在本地。当用户杀掉应用或切后台一段时间被自动杀掉应用，原本存储在用户终端内存里的UserSig丢失了，而当重新开启应用，此客户的逻辑是调用autoLogin接口，不去向开发者后台请求UserSig，因此终端SDK一直没有获取到UserSig，此时调用需要UserSig的REST API请求COS token就会报错参数丢失。而用户使用其他功能不受影响是因为登录凭证仍存在本地，其他功能都是用到登录凭证来做鉴权。 问题解决： autoLogin接口早已经在新的SDK V2版本的API里禁用了，引导不要再使用V1版本的接口。

回答来自于问答智囊团成员：王超超-Ryanccwang 专栏：https://cloud.tencent.com/developer/column/89781 故障现象 通过和客户沟通，客户反馈通过公网直接访问IDC-A Redis数据库时不存在偶发性延时超过1S现象，通过云上访问时存在该现象，详见客户监控视图： 📷 图一-故障现象 网络架构 客户本地有两个IDC，通过两条专线打通IDC和云上资源互访通道，目前两条专线通道之间以互备方式运行，网络拓扑架构详见下图： 📷 图二-网络拓扑架构 流量模型 客户IDC-A通过通道1访问云上资源；客户IDC-B通过通道2访问云上资源，流量交互模型如下图： 📷 图三-流量模型 业务模型 1、客户在云上部署了WEB服务和DNS解析服务了， 2、公网请求到达CVM后会通过内部DNS进行域名解析获取云下Redis数据库访问地址 3、CVM通过专线通道完成和云下Redis数据库交互 备注：目前客户在Module3/4各部署了一套内部DNS。 排查思路 根据客户提供信息，结合客户业务模型进行初步分析，怀疑故障点可能位于专线质量和DNS解析，特制定了以排查思路： 1、客户提供CVM到redis的访问延时参考 2、客户配置本地解析，观察通过专线读取Redis数据库是否有异常 3、查看内网DNS 解析log是否有异常 4、通过抓包获取高延时访问报文，需要核心节点部署抓包 排查步骤 1、客户快ping 5000个报文，测试结果正常 2、通过分析现象复现时捕获报文，发现有TCP报文丢失导致的报文重传 📷 图四-报文分析 3、联系客户快ping 20000个报文探测云下Redis数据库，发现互访确实存在丢包，需要进一步定位故障点 📷 图五-ping 探测报文 4、在图二所示的专线接入点1设备上部署双向流统，通过匹配ping ICMP报文进一步定位故障点 5、通过流统结果，发现云上报文正常发送至云下；云下报文发送至云上时有报文丢弃，定位故障点位于专线侧 📷 图五-流统统计结果 6、客户联系供应商对专线进行质量排查，供应商通过排查监控发现专线有CRC告警 📷 图六-专线CRC 案例回顾 回顾该CASE案例在处理过程中整体排查结果符合预期，但还存在可优化的空间： 1、排查思路点1优化 可以通过快ping 更大数量的报文为进一步定位故障提供更可靠的判断依据，提升故障处理效率，建议探测报文数量为20000。 2、监控告警机制优化 对专线CRC监控部署更严格的监控指标，发现CRC告警后立刻通知客户，该案例涉及供应商已完成监控机制优化。

刚好最近关注了音视频方面的，我就来回答一下吧。 首先，要想知道音视频技术在物联网中发挥了多大的作用，就必须要清楚物联网的构成。 标准的物联网系统可以大致分为四个层面：感知识别层，网络构建层，管理服务层，综合应用层。 1）感知识别层： 通过感知识别技术，让物品“开口说话、发布信息”，这些要实现起来，其实就是通过传感网。它位于物联网四层模型的最底端，是所有上层结构的基础。联系到我们的音视频技术，就是摄像头、声音传感器。 2）网络构建层： 网络是物联网最重要的基础设施之一。简而言之就是传输数据。采集了音视频数据，你需要进行传输呀，必须保证信号质量、时延等，个环节也是非常重要的一部分。 3）管理服务层： 这个层面就是把收集到的信息进行有效整合和利用，而这个层面往往就是物联网的精髓所在。联系到本话题，也就是要对音视频数据进行分析和处理了。 4）综合应用层： 物联网丰富的内涵催生出更加丰富的外延应用。举个例子，在追捕犯罪嫌疑人时，往往都需要调用大量的视频监控数据，有时候在犯罪嫌疑人从一个摄像头覆盖的区域到另外一个摄像头覆盖的区域时，传统方法就需要调用另外一个摄像头的数据，这样做不仅费时费力，而且还极大地影响了办案效率。而现在，就可以通过综合应用层的软件，直接实现人脸识别、自动跟踪。 介绍完了物联网的构成，再来说说音视频技术吧。物联网的音视频和传统的音视频还不太一样，在处理物联网中的音视频数据时，需要用到音视频云技术。物联网的终端不像互联网的终端一样都具备处理功能，有的物联网终端可能只是发送和接收数据，对数据的处理则放到了云端进行处理。所以对技术上就又有了更高的要求。 在对音视频的处理方面，又有了很多技术上的指标： 稳定和流畅的保障； 音视频方面的清晰度如何，是否有噪声； 并发效果如何； 特定的场景化需求； 技术支持如何； 目前来讲，音视频服务都是由第三方提供的，不同的服务商提供的效果也会有一些差异，也会对整个物联网的质量产生一定影响。 除了音视频处理技术在物联网中产生的影响，还有很重要的一方面就是交互方式上，这个有很多商业化的产品了。比如智能音响、智能电视等。它可以听懂你说的话，对你的指令做出反应，这也是音视频在物联网上发挥的作用之一吧。 目前就想到这么多，后续有其他想法再来回答，也欢迎大佬们继续补充哈。

楼上回答和憨批一样 谁不知道？