腾讯云cdn设置websocket

发布于


1.添加域名 https://console.cloud.tencent.com/cdn/access
2.源站填写IP，需要注意的是：加速类型选择流媒体点播加速

3.https配置
高级配置，添加Https。
ssl证书直接从之前的宝塔面板复制过来,腾讯云的‘证书内容’对应宝塔的‘证书(PEM格式)’注意复制过来之后中间有一行空格需要手动删除；腾讯云的‘私钥内容’对应宝塔的‘密钥(KEY)’
回源记得选择协议跟随
4.访问控制-把过滤参数关闭
缓存配置-全部改成0
回源设置-关闭Range回源

域名解析

在自己的域名解析服务商添加‘CNAME’记录


来源：https://sixu.life/bt-v2ray-tencent-cloud-cdn.html

评论

发表评论

此博客中的热门博文

硬盘功耗要多少及配套电源选择依据（功率多少瓦）

发布于
机械硬盘 都会在产品标贴醒目位置标注有功耗。以下都以 希捷 8TB酷鱼为例，其运行需要+5V和+12V两种电压，只有同时满足这两种需求才能正常工作。具体需求为：+5V需要电流为0.55A，+12V需要电流为0.37A。如图1所示： 图1 通过简单计算可知，其运行时+5V需要2.75W的功率，+12V是4.44W，合计功耗是7.19W。但实际的 硬盘 功耗，特别是启动瞬间的功耗不止于此。如果仅以此为依据计算购买电源的话很可能导致供电不足。 通过希捷官网的PDF文件可查知如下信息： 图2 启动时+12V所需电流是2A，那就是24W的功耗。以8盘位NAS插满为例，在机器启动时光硬盘就需要24W*8=192W的功率。 再往下看详细内容： 图3 可见硬盘在不同工作状态对电源需求是不同的。启动时只需要+12V的供电，其他诸如空闲、读写、待机、休眠时除+12V以外还需+5V供电，但这些状态所需电流都较启动电流要小好多。整理表格总结如下： 图4 可见只有启动时所需功耗最大，但此时对+5V供电没要求。除此状态外，以日常读写功耗为最高，达到5瓦以上，但是对+5V供电就有了要求。如果你要组4U24盘位的机架 服务器 的话，就需要选择+5V供电能力超过1.4W*24=33.6W的电源，+12V供电能力》24W*24=576W的电源。这还只是硬盘部分，算上其他板卡、 CPU 后对电源供电能力的要求就更高了。以上都是以希捷的8TB酷鱼为例，如果你选用更大容量的硬盘，那电流需求就会更多。 正因硬盘启动时对电流要求远超日常，所以一些RAID卡增加了交错启动功能，让某些硬盘先启动，另一些后启动。达到减小对电源压力的目的。但我在使用过程中遇到过启用交错启动后，有硬盘无法启动的故障。不知是RAID的原因还是硬盘的原因。 图5 目前家用PC电源多数都是+5V和+3.3V联合供电，有部分电量需要分给+3.3V用电设备，如图6，所以选购电源时只看+12V供电和+5V供电能力是否满足仍有不足，还要考虑交叉负载以及其它设备供电情况。留出充足的余量为好。 图6 综上，日常使用可参考硬盘盘面标贴计算硬盘的功耗，但是启动时所需功耗最好还是查验官方文档为佳。 总结...
阅读全文

Mifare Classic card(M1卡)破解过程记录(准备+理论+获取扇区密钥+数据分析)

发布于
首先认识一下一卡通的类型，市面上常见的一卡通是IC卡的一种，IC卡即集成电路卡，也是广义上的智能卡，准备篇介绍一些智能卡的基础知识，帮助我们确定卡的类型和使用的设备， 目前淘宝上提供了设备和全套软件，确定好方法就可以自动化破解，下面的内容比较详细，不用全部看完也能破解，但了解一下可以提高效率 。 按照使用方式分类： · 接触式IC卡： 符合 ISO 7816 标准，卡片表面包含金属触点，读写需要 IO 线路接触，即需要插卡使用，如手机的 SIM 卡模块 · 非接触式IC卡： 符合 ISO/IEC 14443 标准，由 IC 芯片、感应天线组成，封装在一个标准的 PVC 卡片内，芯片及天线无任何外露 部分，通过 RFID 感应使用，校园卡及身份证都是这一类型。 · 双界面卡IC： 又称组合卡 / 双端口 卡，是 同时兼备接触和非接触两种界面通信的多功能卡 ，将非接触 IC 卡的方便性和接触 IC 卡的安全性融为一体，使之成为一卡多用的极佳载体，代表着未来 IC 卡的主要发展方向，银行卡就是这一类型。 需要注意的是我们平时见到的某些门禁卡虽然也是通过感应使用，但不一定是IC卡，现在有相当一部分便宜的门禁使用的是磁卡和ID卡，ID卡使用RFID射频技术，但其频率一般较低，一般为125KHz,如爱特梅尔的T5577卡，不可写入用户数据，其记录内容仅限卡号只可由芯片厂一次性写入，开发商只可读出卡号加以利用，所以只用于身份识别，不能用于消费，其成本相对非接触式IC卡较低，一般使用字典攻击的方式就能复制。 智能卡按照工作频率分类： 区分ID卡和IC卡——读卡判断法 读卡判断法是判断卡智能卡类型最准确的方法，这需要可识别多类型卡的设备支持，例如手机NFC或者pn532开发板、ACR122U读卡器以及Proxmark3。使用手机NFC是最为便捷的方法，在支持全功能NFC的手机上下载MIFARE Classic Tools，给予权限后将卡片贴在NFC感应区根据提示读取标签后查看标签信息。下面是两种不同容量的IC卡的显示，如果RF技术这栏显示ISO/IEC 14443，说明就是典型的13.56MHz的非接触式IC卡，这也是生活中使用最多的类型。             ...
阅读全文

消逝中的在线数据

发布于
如果你的数字数据——电子邮件、短信、照片和文档——很快就会在一系列毁灭性的电风暴中消失，你会如何竭力保住它们？ 这就是苏珊·多诺万（Susan Donovan）所设想的未来的灾难，她是一名高中教师，也是一名科幻作家，常驻纽约。在她自行出版的小说《纽约市地理学》（ New York Hypogeographies ）中，她描述了这样一个未来：2250年，由于电力干扰，海量数据遭到删除。 在随后的几年里，考古学家们在被毁坏的城市公寓中遍寻21世纪初的文物。 她说：“我在想，‘ 如果所有的数码产品都不见了，这会给人们带来怎样的变化？ ’” 在她的故事中，灾难性的数据丢失并不是世界末日，但极具破坏性。它促使人们改变保存重要数据的方式。多诺万写道，电风暴带来了印刷业的复兴。但人们也得思考如何储存那些无法打印的东西，比如增强现实游戏。 亚历山大图书馆位于埃及亚历山大，曾是世界上最大的图书馆。由埃及托勒密王朝的国王托勒密一世在公元前3世纪所建造，后来惨遭火灾，因而被摧毁。它实际是什么模样无人知晓，因为它连一个石块实物都没有留下。? wikipedia 数据从来都不是完全安全的。试想一下被烧毁的亚历山大图书馆——毁于一场大火可能是你听说过它的唯一原因。数字数据不会在巨大的火灾中消失，却会消失于一次单击，或随着时间推移，消失于存储介质无声的悄然退化中。 今天，我们已经习惯了这种删除。这样的例子不胜枚举—— 2019年MySpace个人资料消失便是轰动一时的例子之一。多年来许多陆续关闭的谷歌服务也囊括其中。 此外，还有一些在线数据存储公司，为人们的数据提供安全保障。 但讽刺的是，他们有时会指定删除某些数据。 ? Yoors 在其他情况下，这些服务会长时间运行。但用户可能会丢失登录所需的详细信息。或甚至忘记了他们有过账号。他们可能再也无法像在阁楼里找到一鞋盒的旧信件那样，找到存储在那里的数据了。 多诺万之所以对“转瞬即逝的”数字数据感兴趣，原因在于她的个人经历。她在大学专修数学，有多份手写笔记。她笑着说：“有一次我开始记电子笔记，之后却找不到了。” 上世纪90年代末，她还写过在线日记。现在日记没了。她从事的创意项目也不再完好地保存在网络上。 当她创造这些数据时，还以为自己在创造可以长久存在的东西。就像可以无限重放的电影那样。但现在，她对什么是数字数据及其可能持续多久的理解已经改变...
阅读全文

mysql（多级分销）无限极数据库设计方法

发布于
相信有过开发经验的朋友都曾碰到过这样一个需求。假设你正在为一个新闻网站开发一个评论功能，读者可以评论原文甚至相互回复。 　　这个需求并不简单，相互回复会导致无限多的分支，无限多的祖先-后代关系。这是一种典型的递归关系数据。 　　对于这个问题，以下给出几个解决方案，各位客观可斟酌后选择。 一、邻接表:依赖父节点 　　邻接表的方案如下(仅仅说明问题)： CREATE TABLE Comments( 　　　　CommentId　　int　　PK, 　　　　ParentId　　 int,　　　　--记录父节点　　　　ArticleId　　int, 　　　　CommentBody nvarchar(500), 　　　　FOREIGN KEY (ParentId)  REFERENCES Comments(CommentId) 　　--自连接，主键外键都在自己表内　　　　FOREIGN KEY (ArticleId) REFERENCES Articles(ArticleId) 　　) 　　由于偷懒，所以采用了书本中的图了，Bugs就是Articles： 　　 　　这种设计方式就叫做邻接表。这可能是存储分层结构数据中最普通的方案了。 　　下面给出一些数据来显示一下评论表中的分层结构数据。示例表： 　　 　　图片说明存储结构： 　　 　　 邻接表的优缺分析 　　对于以上邻接表，很多程序员已经将其当成默认的解决方案了，但即便是这样，但它在从前还是有存在的问题的。 　　分析1： 查询一个节点的所有后代(求子树)怎么查呢？ 　　我们先看看以前查询两层的数据的SQL语句： SELECT c1.*,c2.*　　FROM Comments c1 LEFT OUTER JOIN Comments2 c2 　　ON c2.ParentId = c1.CommentId 　　显然，每需要查多一层，就需要联结多一次表。SQL查询的联结次数是有限的，因此不能无限深的获取所有的后代。而且，这种这样联结，执行Count()这样的聚合函数也相当困难。 　　说了是以...
阅读全文