DOROMOLLL ∎

全新的专业猫粮数据网站：喵吃（miaaochi.com）

Google TV Chromecast Android 12似乎修改了DNS逻辑，我之前是使用Surge的网关模式对Google TV的网络进行接管，将Google TV的DNS设置成了198.18.0.2，今天更新Android 12后发现Google系的服务全都无法正常使用，但其他的流媒体（如Netflix）是正常的。

因为在之前的Google TV上，系统服务会无视DNS设置，强行使用8.8.8.8/8.8.4.4进行解析，所以之前的做法一般是在Surge对这两个DNS进行劫持，这部分被劫持的DNS请求则是直接被转发到代理服务器了，而新Google TV系统则可能修改了这个策略，并不会无视系统DNS设置进行请求，而是老老实实的走系统指定的DNS，但依然是本机直接解析。

我截了两张图，可以清楚的看到Google服务和Netflix请求的差别，Google服务的URL根本不会到网关上来，而是本机解析得到IP，再发往网关，Netflix则是让URL走向网关，让网关决定如何处置。所以Google TV访问Google服务的时候，Surge网关接收到请求的指向的是Google TV自行解析域名得到的IP，也就无法match配置的规则进行DNS解析转发了。

而因为新版Google TV的Google服务会使用系统设置的DNS进行解析（看起来是默认DNS-over-TLS），所以如果还是设置为198.18.0.2就无法正常解析，也就无法使用了。

解决办法就是，如果之前使用了198.18.0.2作为Google TV的DNS配置，则需要将Google TV的DNS修改为正常的8.8.8.8/8.8.4.4/1.1.1.1，并且在代理服务上将这几个IP纳入代理规则的范围，使用软路由的也需要注意将“仅代理常用端口”给关掉，这样才能让Google TV的DNS-over-TLS进行正常的DNS解析。

小时候在中国内地，卫星电视还是很多人在玩的，当时中国内地可以买台商版的 DISH HD 看国家地理、Discovery 和动物星球这些频道，也有麦格 TV 这种高端的灰色服务商。但那时候自己还在念初中，不好意思找家里要钱，加上年费确实有些高了，当时也只是久仰其大名，但没有体验过。

后来因为众所周知的原因，中国内地的卫星电视渐渐消失了，麦格 TV 也被打击了。

现在虽说是一个流媒体的时代，国家地理的纪录片在 Disney+ 都有，Discovery 也有了自己的 Discovery+ 流媒体，通过特定的方式都可以收看到高质量的片源，成本也都很亲民，看这些纪录片也不用费尽心思去找资源了。但想要看这些电视台，却依然很困难。

关于境外电视台的管制不管是国内政策层面还是他们版权层面都受到了极其严格的管理，正版电视直播的价格 (Sling TV/ YouTube TV/ Hulu Live TV) 因为加入了体育直播的原因都水涨船高，从三十多刀涨到了六七十、一百刀一个月，但是想看的频道只有那几个新闻台和纪录片台，这个价格确实是有些太贵了。

曾经 DISH HD 虽然名头上是「台商版」，但桌底下基本上都靠中国内地的灰色市场维持，相关政策一下来，服务就运营不下去了，随即宣告倒闭。而现在回想起 DISH HD，无疑是非常有性价比的选择，画质好，频道也刚好，天线要求也很低，价格也合理。

难道就没有一个办法能看到这些频道了吗，翻来翻去，发现台湾的中华电信 MOD 是有这些频道的中文版的 (据说内容质量要差一些)，中华电信 MOD 一个月全开的费用是 NTD 350 (CNY 80)，相比起来真的超划算了，节目也超丰富，基本是大 network 在亚洲落地的频道的最丰富的收录了，居住在中国内地的我真的很羡慕。

我甚至都在脑袋里构思，在台湾找一个地方，开一个中华电信 MOD，搭建一台用于推流的主机，HDMI 直接采集推流到香港的服务器上，自己写一个用于远程红外遥控和实时播放的 APP，实现随时随地在内地看电视。虽然这个方案如果是要自己租房子、自己办宽带（宽频）是很不现实的，但如果有这样的机会可以做这套方案，实现私人 IPTV 服务，岂不是很爽。

准备有时间做一下实验，把这个方案实践验证一下，争取未来有机会的时候能用的上😵‍💫

If you have any questions about this app, please contact me with no hesitation.

使用中若有任何问题，请立即联系我。

Email: [email protected]

在 Reddit 看到一篇关于 Apple Music 混乱的 metadata 系统的讨论，提到了混乱的艺人名字，feat 艺人和流派的标签管理等。

Apple Music 目前的 metadata 针对艺人做标签管理，只是简单的字符串存储和匹配，所以在本地资源库会出现「Lady Gaga」和「Lady Gaga & Bradley Cooper」是两个不同艺人的情况。

并且流派（Genre）的标签也极其混乱，目前的设定是一个专辑填写单一的流派，并且子流派和父流派存在于同一个信息层级，相似流派的混乱问题也很严重，作者提到「Hip-Hop」、「Hip-Hop/Rap」和「Rap」竟然是三个不同的流派。当代流行音乐风格多样化复杂化，理应使用多流派标签的管理方式，并且理清父流派和子流派。

此外，因为 Apple Music 本质就是 iTunes 的系统的改版，我观察到 iTunes 时期的诸多问题（feature）也都沿袭至今。相信很多人困扰的一个问题是，多语言歌曲的名字极其混乱，Apple Music 延续了唱片公司提交给 iTunes 的信息格式，其中就有针对不同语言的市场的本地化语言。所以一个歌曲的显示名称会受到「Apple 账号所在地」和「当前设备的显示语言」影响。
所以会出现：
日文歌曲，美区 Apple Music，英文系统，显示为罗马音。（唱片公司针对英文市场填的翻译就是罗马音）
中文歌曲，美区 Apple Music，英文系统，显示为英文翻译或汉语拼音。（同上)
英文歌曲，陆区 Apple Music，中文系统，显示为中文翻译。（同上）

这一设定明显是被很多人吐槽的，因为大多数人都不想要自作聪明的翻译和不明所以的罗马音。猜想这是因为 iTunes 时期，全球的音乐市场并没有如今这么流通，所以我们会更熟悉一些歌曲的译名，例如「我心永恒」和「斯卡布罗集市」，但现在的听众会想要看到「Bang Bang」被译成「砰砰」吗？同理在英文市场，远没有如今这么多听众习惯听 K-POP 和 J-POP 歌曲。而 Spotify 一开始就是做全球流媒体的，它默认显示的都是原始名称，只有艺人名字可能会根据地区和语言不同启用翻译名，对于多语言听众来说，体验感会好很多。

一直以来，Apple Music 都是在 iTunes 的基础上做功能，在有冲突的时候也没有把 iTunes 的基础设定给丢掉，例如当你点击「A Star ls Born」这张专辑的艺人名称「Lady Gaga & Bradley Cooper」的时候，你会直接进入「Lady Gaga」的艺人页面，「Bradley Cooper」会被直接忽略，同样的可以看「The Lockdown Sessions」里的任何一首歌曲。而 Spotify 则不会这样。

这些种种设定，仅仅给用户提供自定义选项，例如允许用户设置显示歌曲原始名称，是远远不够的（虽然连这个选项都没有提供），时过境迁，iTunes 的一整套系统已经不太适用于当今的全球音乐市场了，而我也看到在下一版 macOS Monterey 12.2 里有针对 music.app 进行重构，因为现在的 music.app 还是延续了 iTunes，是大量基于 Web 的应用，所以长期被抱怨卡顿，鲜有切实改进。但客户端的流畅度优化只是一方面，Apple Music 想要解决以上种种问题的话，是需要自底而上重构的，需要拋弃 iTunes，否则如今混乱的音乐库实在是难以称上优秀。

一直有听到Cloud Native（云原生）这个词，但是一直对它不甚了解，对于Cloud，我可以联系起来的关键词有container/database/PaaS/SaaS/serverless/aws S3，从这些词上面，大概也能模糊认识到，Cloud Native，大概就是这些个cloud based的应用吧。

了解了一番，其实Cloud Native是由CNCF（Cloud Native Computing Foundation）来推动标准化发展的，其成员如下：

下面几句话能很好的讲清楚Cloud Native的缘来和特性：

In DevOps, everyone needs to trust that everyone else is doing their best for the business.

that for systems to behave well on the cloud, they need to be written for the cloud.

Cloud-native technologies generally embrace loosely coupled architectures, resiliency, immutable infrastructure, and observability.1

我的理解如下：

Cloud Native是云时代的必要的标准产物，它由Linux基金会发起，其发展由全球顶级的互联网基础设施厂商推进，其目的就是打造一个尽可能授权中立的、包含云服务各领域所需构件的且有良好的通用性的云应用生态，并且以基于专门为云场景来构建应用的前提出发来设计应用，从而形成一个高效率、互通性好、性能优异、将云特性发挥好并且解决方案丰富的生态，为上层应用开发者提供更高效的解决方案。

云基础设施就像房屋的地基，在以前，当你需要构建一个网站，你需要自己购置一个物理服务器、办理带有独立IP的网络接入服务、自行搭建Web服务器、自行解决数据库的问题、自己用基础的HTML和CSS编写前端网页，以及自己维护服务器所运转所需要的电力供应，处理各种运转过程中会发生的错误，在这样的情况下，网站也难以保证稳定。

IaaS则解决了物理服务器难以稳定运行的问题，IaaS服务商提供全球顶尖的物理服务器解决方案保证服务器正常运行，同时集中化的物理服务器机房也降低了绝大部分的能源损耗，开发者只需要关注在软件层面的应用优化。

PaaS则在基础服务器和操作系统之上进行包装，只为开发者暴露应用的接口，开发者不需要再为了一个数据库而去部署一个服务器，应用之下的服务器和操作系统都由云服务提供商负责维护。诸如Heroku这样的Web应用托管网站就在PaaS的范畴内，开发者只需关注应用，而无需关注网络安全、物理设施安全等等。

SaaS则是更进一步的上层建筑，诸如Dropbox、Zoom、GSuite这样的解决特定需求的应用，开发者能定制化的空间就很小了。

网络设施的发展、网络节点的增加、民用宽带的成本降低、移动互联网的普及、基于互联网的内容载体和应用的变化以及云服务的丰富化都是这个生态中的紧密相连的环节，只有移动互联网普及了并且云服务内容分发成本降低了，才有可能让Netflix和抖音成为人们地铁的消遣，只有网络设施成本降低了、宽带价格降低了以及互联网用户变多了，云服务厂商才得以降低成本并技术升级，开发者才得以获得更多的可能来开发更不一样的应用。

Cloud Native需要应用针对分发性、微服务和可扩展性进行设计，也就是契合云的原生特性进行设计，这就要求应用具有良好的沟通性、稳定性、分布式特性以及安全性。

我发现自己关于云服务、微服务的特性以及部署、扩展、保障大量用户使用的流程比较感兴趣，待我做更多research再来分享。

Defining cloud native - Microsoft

声明：本文章没有干货

第一步一定是找API，我大概从网页端的WWDC资源了解到，Apple对这个资源没有任何限制，基本都是明文视频流URL供开发者抓取，这一步应该不难，那就开始吧。

首先是分析iOS和iPadOS下的Apple官方的WWDC内容平台「Developer」，用QuantumultX抓包，发现Apple也会用aws S3来host一些图片资源文件，一般是WWDC欢迎页的资源文件，考虑大概是aws S3比Apple自身的CDN更稳定，且aws CDN速度更优秀的缘故，借此规避风险。

另外发现应用内的icon是用pdf的形式来保存的，为了顺利缩放，这一点很稀奇。

当然这些只是一些some fun facts about Apple。

我最终需要找到WWDC整个资源描述的文件，但是好几次都没有发现这个文件的存在，同时我也发现在app内加载视频列表非常快，所以怀疑app用了一个统一的资源路径文件进行预加载，而这个文件早就下载好了，并且在现在的运行过程中不会更新，也就抓不到相关请求，于是乎，我将app卸载了又安装，才终于抓到这个文件，也就是这里的contents.json。

contens.json是资源的大集合，包含文章内容，视频内容，代码片段，这也是我第一次见识Apple的Web传输的数据。

这是其中一个WWDC Session的一部分数据内容，可以看到除了id外，有Web网页链接（猜测用作分享用途）、描述字段、名称、时间、涉及到的平台（WWDC Session不同的内容会对应不同平台的开发），甚至有缩略图的样式。

另外还有一部分视频内展示到的代码片段。

然后则是我们要的视频流、字幕URL，这里还有相关的Session和资源的数据。

看media字段，Apple提供了hls的stream传输和mp4格式的成型可供下载的文件，其中hls和tvOShls，（Apple在json中也不会弄错自家专有名词的大小写），用的是一个m3u8，用IINA打开这个m3u8，发现它提供了12路视频流，之前了解到tvOS上的WWDC可以提供4K画质，大概就是这里得到的。其中4K画质提供了12～14Mbps的码率，规格很高，Apple果真有钱。HEVC是High Efficiency Video Coding，顾名思义是高效率的视频编码格式。

非HEVC的视频流提供的是MPEG-2的编码格式，兼容性更好。

这时，我对devstreaming-cdn.apple.com这个域名产生了兴趣，我用站长之家的工具Ping了一下，发现中国大陆范围普遍将这个域名解析到了国内的CDN，其中出现了少数的网宿的身影，据说Apple Music的资源也给网宿CDN了，下次研究一下网宿。

这不是重点，我发现所有除中国大陆以外的地区，这个域名都被解析到了Apple名下的17.253.*.*的IP地址，而且Apple在这么多区域都有CDN节点（有钱)，这也不意外，毕竟Apple这么多服务，包括但不限于App Store、Apple Music、Apple Store、Apple TV+、Apple Push Notification Service等等，都得依靠强大的网络做分发，但是当我继续搜索相关资料的时候，我发现了这个。

意思就是说AS714和AS6185管辖范围内的17.0.0.0/8这个block内的2^24-2个地址都属于Apple，holy moly

此外我还查了一下Apple名下的AS号码

发现中国上海还有一个Apple的AS，在「苹果贸易（上海）有限公司」名下，这个大概就是负责Apple在中国大陆的apple.com.cn域名的管辖吧。

话说回来，这个/8的IP段确实了不得，除了保留的诸如10.0.0.0/8、127.0.0.0/8这种地址段之外，拿到/8的IP段的单位都是美国国防部（DoD）和全球的区域运营商，中国运营商也有一部分。

但是/8这个巨大的IP段有七个是在美国私企手中的，

其中有AT&T Services（美国顶级运营商），Apple Inc.（美国苹果公司），Ford Motor Company（美国福特），PSINet, Inc.（一家美国ISP），Pridential Securities Inc.（一家美国保险公司），US Postal Service（美国邮政），Comcast Corporation（美国康卡斯特电缆通信有限公司）。

Web的许多标准都是美国以国家标准最先实行的，所以美国这么多企业拥有/8的IP地址如此宝贵的网络资源并不意外，但是除了AT&T，和某些ISP外，勉强算上当年还在做电脑的Apple，这些企业其实是用不到这么多的IP资源的，特别是汽车企业和电缆企业，但这些全球7*1/255的IPv4资源被这些企业大量占据，是否是IPv4资源的巨大浪费呢？同时美国国防部也占据了13个/8的IP网段，合理性有待考究。

IPv4的分配情况就研究到这里，我又想到一个问题，在中国大陆境内提供视听服务是需要相关的许可的，Apple的WWDC视频从中国大陆访问走的都是中国大陆境内的CDN，我猜测有两种可能：

1. Apple自身有《信息网络传播视听节目许可证》
2. 网宿科技有《信息网络传播视听节目许可证》，Apple通过这样规避政策风险

于是我跑去「国家广播电视总局」的相关页面找到了这份「《信息网络传播视听节目许可证》持证机构目录」，可以看到这份名单大多数是一些广播电视台和出版机构，以及少数一部分互联网公司。

譬如，在这边可以看到「上海宽娱数码科技有限公司」也就是Bilibili的身影，但没有看到微博的身影。

一搜才想起来，微博、AcFun和凤凰网在2017年曾被要求强行关闭过视听节目服务，也就是因为这个「《信息网络传播视听节目许可证》」，有一点需要注意，「《信息网络传播视听节目许可证》」从2008年以后必须要求国企或国企控股的企业才能申请，所以目前大多数视频网站都没有，政府的处理方式则是，不轻易按无证经营进行查处，发现有违规问题则要求整改。微博当时的应对措施则是给予有「《信息网络传播视听节目许可证》」的用户上传视听节目的权限，但现在微博的UGC内容看似并未影响，只是审核敏感度太高，大概也是有这个无证经营的可能性拦在前面的缘故。

所以Apple在中国大陆提供本地CDN的WWDC资源，不能说是擦边球，但在内容经过严格审查的情况下也应该没有太大的政策风险，但对于也许有本地CDN的Apple TV+和外区Apple Music，有没有政策风险就难以确定了，我下次再研究研究。

搞了这么久，只把WWDC资源的API给找了出来，但意外发现了一些关于Apple的小趣事，希望下一节能正式开始Flutter的WWDC客户端的开发工作（小声）。