brotli

Blazor编译后的文件是静态文件，所以我们只需要一个支持静态页面的web server即可。 根据不同项目，会用不同的容器编排，本文已无网关的情况下为例，一步一步展示如何打包进docker 需求 HTTPS 既然无网关，直接面向互联网，所以HTTPS显得尤为重要 HTTP/2 TLS3.0 既然都是静态资源，使用H2和TLS3.0的目的是进一步加快加载速度 Compress 对静态资源的压缩的目的依然是进一步加快加载速度。压缩选型为Brotli和 Gzip 压缩 Dockerfile 官方的 Nginx 镜像，默认不支持Brotli 所以需要自己准备一个具有Brotli支持的镜像，这里推荐使用自卖自夸的 Nginx 镜像,不仅使用最新的openssl编译(避免漏洞)，还支持TLS1.3 http2 brotli和默认东八时区，且配置文件里还有配置示例。欢迎访问 Docker Hub rsnow/nginx ，了解更多。 发布blazor wasm 截至2020.05.26，VS还不能把blazor wasm直接发布到Docker镜像仓库，所以只能自己打包 首先发布Release，不再赘述 在项目根目录创建 Dockerfile FROM rsnow/nginx:amd64-1.18.0 RUN rm /usr/share/nginx/html/index.html && \

Blazor编译后的文件是静态文件，所以我们只需要一个支持静态页面的web server即可。 根据不同项目，会用不同的容器编排，本文已无网关的情况下为例，一步一步展示如何打包进docker 需求 HTTPS 既然无网关，直接面向互联网，所以HTTPS显得尤为重要 HTTP/2 TLS3.0 既然都是静态资源，使用H2和TLS3.0的目的是进一步加快加载速度 Compress 对静态资源的压缩的目的依然是进一步加快加载速度。压缩选型为Brotli和 Gzip 压缩 Dockerfile 官方的 Nginx 镜像，默认不支持Brotli 所以需要自己准备一个具有Brotli支持的镜像，这里推荐使用自卖自夸的 Nginx 镜像,不仅使用最新的openssl编译(避免漏洞)，还支持TLS1.3 http2 brotli和默认东八时区，且配置文件里还有配置示例。欢迎访问 Docker Hub rsnow/nginx ，了解更多。 发布blazor wasm 截至2020.05.26，VS还不能把blazor wasm直接发布到Docker镜像仓库，所以只能自己打包 首先发布Release，不再赘述 在项目根目录创建 Dockerfile FROM rsnow/nginx:amd64-1.18.0 RUN rm /usr/share/nginx/html/index.html && \

ASP.NET团队如期3.16在官方博客发布了 Blazor WebAssembly 3.2.0 Preview 4： https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-preview-4-release-now-available/ ，同时在twitter上发了一条信息带上了下面这张图，这张图很形象的说明了Blazor Webassembly 正在进行最后的准备发射，按照开发计划，将在下周4.23 发布Blazor WebAssembly 3.2.0 Preview 5， 完成功能特性的开发，接下来就是5月初发布Blazor WebAssembly 3.2.0 RC了，将在5.19 的微软Build大会正式发射升空，进入使用C#进行前端开发旅程。 Blazor WebAssembly 3.2.0 Preview 4新增功能： 启动期间访问主机环境：在 WebAssemblyHostBuilder通过 IWebAssemblyHostEnvironment的 HostEnvironment 属性公开，在应用环境中的启动过程中区分（开发，分期，生产等）的细节。如果该应用程序托管在ASP.NET Core应用程序中，则该环境将反映ASP.NET Core环境，因此ASP.NET Core肯定是最佳开发环境

ASP.NET团队如期3.16在官方博客发布了 Blazor WebAssembly 3.2.0 Preview 4： https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-preview-4-release-now-available/ ，同时在twitter上发了一条信息带上了下面这张图，这张图很形象的说明了Blazor Webassembly 正在进行最后的准备发射，按照开发计划，将在下周4.23 发布Blazor WebAssembly 3.2.0 Preview 5， 完成功能特性的开发，接下来就是5月初发布Blazor WebAssembly 3.2.0 RC了，将在5.19 的微软Build大会正式发射升空，进入使用C#进行前端开发旅程。 Blazor WebAssembly 3.2.0 Preview 4新增功能： 启动期间访问主机环境：在 WebAssemblyHostBuilder通过 IWebAssemblyHostEnvironment的 HostEnvironment 属性公开，在应用环境中的启动过程中区分（开发，分期，生产等）的细节。如果该应用程序托管在ASP.NET Core应用程序中，则该环境将反映ASP.NET Core环境，因此ASP.NET Core肯定是最佳开发环境

ASP.NET团队如期3.16在官方博客发布了 Blazor WebAssembly 3.2.0 Preview 4： https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-preview-4-release-now-available/ ，同时在twitter上发了一条信息带上了下面这张图，这张图很形象的说明了Blazor Webassembly 正在进行最后的准备发射，按照开发计划，将在下周4.23 发布Blazor WebAssembly 3.2.0 Preview 5， 完成功能特性的开发，接下来就是5月初发布Blazor WebAssembly 3.2.0 RC了，将在5.19 的微软Build大会正式发射升空，进入使用C#进行前端开发旅程。 Blazor WebAssembly 3.2.0 Preview 4新增功能： 启动期间访问主机环境：在 WebAssemblyHostBuilder通过 IWebAssemblyHostEnvironment的 HostEnvironment 属性公开，在应用环境中的启动过程中区分（开发，分期，生产等）的细节。如果该应用程序托管在ASP.NET Core应用程序中，则该环境将反映ASP.NET Core环境，因此ASP.NET Core肯定是最佳开发环境

“ 智能压缩” 按照又拍云的说法是， 同时支持 Gzip 和 Brotli 压缩算法 。根据用于浏览器开启自动选择不同压缩方式。 Gzip 压缩算法 Gzip 基于 DEFLATE 算法，它是 LZ77 和霍夫曼编码的组合 ，最早用于 UNIX 系统的文件压缩。HTTP 协议上的 Gzip 编码是一种用来进 Web 应用程序性能的技术，Web 服务器和客户端（浏览器）必须共同支持 Gzip，当下主流的浏览器都是支持 Gzip 压缩，包括 IE6、IE7、IE8、IE9、FireFox、Google Chrome、Opera 等。 Brotli 压缩算法 Google 认为互联网用户的时间是宝贵，尤其不应该浪费在无用的网页加载中。 2013年，他们发布了 Zotfli 压缩算法。该算法在默认设置下的输出比 zlib 的最大压缩比输出还要小 3-8%。PNG 优化器、Web 内容预处理等许多压缩方案中都集成了该算法。基于该算法的应用情况，于 2015 年 9 月推出了 无损压缩算法 Brotli， 最初用于用于网络字体的离线压缩。该算法由谷歌压缩团队的 Jyrki Alakuijala 和 Zoltan Szabadka 开发，其中 Jyrki 亦是 Zotfli 压缩算法的创建者。 2015年9月发布了包含通用无损数据压缩的Brotli增强版本， 特别侧重于HTTP压缩

大文件问题 函数计算 对上传的 zip 代码包尺寸限制为 50M。某些场景中代码包中会超过这一限制，比如未经裁剪的 serverless-chrome ，类似的还有 libreoffice ，此外常见的还有机器学习训练的模型文件。 目前解决大文件问题有三种方法 采用更高压缩比的算法，比如本文介绍的 brotli 算法 采用 OSS 运行时下载 采用 NAS 文件共享 简单的比较一下这三种方法的优劣 方法 优点 缺点 高密度压缩 发布简单，启动最快 上传代码包较慢；要写解压代码；大小受限制不超过 50 M OSS 下载解压后文件不超过 512 M 需要预先上传至 OSS；要写下载和解压代码，大概 50M/s 的下载速度 NAS 文件大小没有限制，无需压缩 需要预先上传至 NAS；VPC 环境有冷启动时延(~5s) 正常情况下如果代码包能控制在 50M 以下启动较快。而且工程上也比较简单，数据和代码放在一起，不需要额外的写脚本去同步更新 OSS 或者 NAS。 压缩算法 Brotli 是 Google 工程师开发的开源压缩算法，目前已经被新版的主流浏览器支持，作为 HTTP 传输的压缩算法。下面是在网上找到的关于 Brotli 和其他常见压缩算法对比基准测试。 从上面三幅图我们可以看出:相比于 gzip、xz 和 bz2，brotli 有最高的压缩比，接近于 gzip 的解压速度

github, 也支持py https://github.com/google/brotli 测试代码, 零配置的时候 const fs = require('fs') const brotli = require('brotli') function test(path) { let s = fs.readFileSync(path,) console.log(s.length) let st = +new Date() let compressed = brotli.compress(s) // console.log(compressed) let ed = +new Date() console.log(compressed.length, compressed.length / s.length, ed - st) st = +new Date() let raw = brotli.decompress(compressed) ed = +new Date() console.log(raw.length, ed - st) // console.log(Buffer.from(raw).toString('utf8')) } // 3.5M let big = "D:/data/高考成绩/高考爬虫/json/school.json" // 2k let small =

前言 首先介绍下在本文出现的几个比较重要的概念： 函数计算（Function Compute） : 函数计算 是一个事件驱动的服务，通过函数计算，用户无需管理服务器等运行情况，只需编写代码并上传。函数计算准备计算资源，并以弹性伸缩的方式运行用户代码，而用户只需根据实际代码运行所消耗的资源进行付费。函数计算更多信息 参考 。 Fun : Fun 是一个用于支持 Serverless 应用部署的工具，能帮助您便捷地管理函数计算、API 网关、日志服务等资源。它通过一个资源配置文件（template.yml），协助您进行开发、构建、部署操作。Fun 的更多文档 参考 。 备注: 本文介绍的技巧需要 Fun 版本大于等于 3.0.0-beta.1 。 依赖工具 本项目是在 MacOS 下开发的，涉及到的工具是平台无关的，对于 Linux 和 Windows 桌面系统应该也同样适用。在开始本例之前请确保如下工具已经正确的安装，更新到最新版本，并进行正确的配置。 Docker Fun Fun 和 Fcli 工具依赖于 docker 来模拟本地环境。 对于 MacOS 用户可以使用 homebrew 进行安装： brew cask install docker brew tap vangie/formula brew install fun Windows 和 Linux 用户安装请参考：