操作系统云原生虚拟化网络【免费下载链接】IncludeOSA minimal, resource efficient unikernel for cloud services项目地址https://gitcode.com/gh_mirrors/in/IncludeOS点击查看免费下载IncludeOS 是一个面向云服务的最小化、资源高效型 unikernel。本文以test/integration/util/tar_gz/tar_example/l1_f1/l2/README.mdIncludeOS Demo Service 使用说明为骨架完整讲解该演示服务的构建、运行与网络配置方法并深入其所在仓库上下文——即它作为 tar 归档集成测试载荷如何被打包、内嵌进内核镜像、再通过 IncludeOS 的tar库在运行时解压读取与逐字段验证。读完本文你将掌握 IncludeOS 演示服务的启动流程、tar/tar.gz资源的构建期内嵌与运行期解析方法以及整套集成测试的断言机制。一、Demo Service 快速上手构建与运行关联文档 README.md 给出了这个演示服务最简明的启动方式make ./run.sh该服务的作用是启动一个 IncludeOS 实例在 80 端口上提供一个提供静态内容的最小 Web 服务原文should start an instance of IncludeOS that brings up a minimal web service on port 80 with static content。文档同时强调了一个运行前提——QEMU 环境下要使网络可用需要先执行桥接创建脚本etc/create_bridge.sh这是文档所述演示工程自带的网络环境准备步骤README 原文脚注Remember to run the bridge creation script for networking to work on qemu。需要说明的是在当前仓库中该测试的构建与运行并非直接调用make/run.sh而是由集成测试框架驱动详见下文第三节与第八节make ./run.sh更准确地说是这份 README 所描述的服务本体在其原始工程模板中的启动方式。二、Demo Service 的实现80 端口上的静态 HTTP 服务README 所说的80 端口 Web 服务其真实源码位于 tar_example/l1_f1/l2/service.cpp与测试根目录下的 service.cpp 为同一服务测试目录中保留了多份副本以验证 tar 归档的目录结构。核心启动逻辑如下void Service::start(const std::string) { // DHCP on interface 0 auto inet net::Inet::ifconfig(10.0); // static IP in case DHCP fails net::Inet::ifconfig( { 10,0,0,42 }, // IP { 255,255,255,0 }, // Netmask { 10,0,0,1 }, // Gateway { 10,0,0,1 }); // DNS // Set up a TCP server on port 80 auto server inet.tcp().bind(80); server.on_accept( [] (auto socket) - bool { ... return true; }) // 允许所有连接 .on_connect( [] (auto conn) { conn-on_read(1024, [conn] (net::tcp::buffer_t buf, size_t n) { std::string data { (char*)buf.get(), n }; if (data.find(GET / ) ! std::string::npos) { std::string response HTML_RESPONSE(); conn-write(response.data(), response.size(), ...); } else { conn-write(NOT_FOUND.data(), NOT_FOUND.size()); } }); ... }); }实现要点网络配置优先在接口10.0上走 DHCP同时配置静态 IP10.0.0.42/24、网关与 DNS10.0.0.1作为 DHCP 失败时的兜底方案TCP 服务inet.tcp().bind(80)在 80 端口监听on_accept放行所有连接on_connect中以 1024 字节缓冲异步读取请求静态内容收到GET /请求后返回HTML_RESPONSE()生成的一段硬编码 HTML含随机配色、Uubuntu 字体引用、TCP 状态说明等并附带手写 HTTP 头HTTP/1.1 200 OK、Content-Type: text/html; charsetUTF-8、Content-Length等其他请求返回404 Not Found。README 所称静态内容即指这份服务端硬编码的响应体。三、这份 README 为何住在 tar.gz 里归档集成测试的定位单纯从文件树看这份 README 位于test/integration/util/tar_gz/tar_example/l1_f1/l2/下其上一层tar_example/是特意构造的、结构丰富的测试归档内容tar_example/l1_f1/l2/含README.md与service.cpp两级嵌套目录tar_example/l1_f1/service.cpp另一份服务源码副本tar_example/l1_f2/virtio.hpp拷贝进归档的 virtio 头文件tar_example/first_file.txt、tar_example/second_file.md扁平文件也就是说这份 README 本身就是测试数据的一部分它会被打包进tar_example.tgz随内核镜像一起发布再在运行期被读回来、逐行打印、逐字段断言。这正是 test/integration/util/tar_gz/CMakeLists.txt 所做的事add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/tar_example.tgz COMMENT Creating tar file COMMAND tar cfvz ${CMAKE_CURRENT_BINARY_DIR}/tar_example.tgz -C ${CMAKE_CURRENT_SOURCE_DIR} tar_example BYPRODUCTS ${CMAKE_CURRENT_BINARY_DIR}/tar_example.tgz ) os_add_executable(util_tar_gz Tar.gz Test Service service.cpp) os_add_binary_blob(util_tar_gz ${CMAKE_CURRENT_BINARY_DIR}/tar_example.tgz input.bin binary)三步走即可看懂构建期链路tar cfvz将tar_example目录递归打包为tar_example.tgz含README.mdos_add_executable编译测试服务service.cppos_add_binary_blob实现在 cmake/os.cmake用objcopy把 tgz 转换为对象文件并整体链接进内核生成 blob 符号_binary_input_bin_start/_binary_input_bin_size见 api/util/tar.hpp。测试服务的Service::start随即在运行期消费这段内嵌数据service.cppconst auto decompressed Reader::decompress_tar(); // 解压内嵌的 tar_example.tgz Tar read_tarfile Reader::read(decompressed.data(), decompressed.size()); // 1) 列出归档内全部元素名 auto found_elements read_tarfile.element_names(); // 2) 按路径精确取文件README.md const std::string path1 tar_example/l1_f1/l2/README.md; auto element read_tarfile.element(path1); // 3) 按路径取文件夹注意目录路径必须带结尾 / const std::string path2 tar_example/l1_f1/l2/; auto element2 read_tarfile.element(path2); // 4) 遍历所有元素并打印 name 与 typeflag auto elements read_tarfile.elements();四、在归档中定位元素Tar::element与Element头字段tar库位于 api/util/tar.hpp核心 API 如下Reader::read_tar()/Reader::decompress_tar()直接读取或解压链接期内嵌的 blobReader::read(data, size)把已解压的tar 数据解析为Tar对象Tar::element_names()返回所有元素名字符串Tar::element(path)按精确路径查找元素目录名必须带结尾/——否则抛出Tar_exception源码实现见 src/util/tar.cppPath ... doesnt exist. Folder names should have a trailing /Tar::elements()返回全部元素的引用容器。Element将 tar 头Tar_header的每个字段都封装成了可读的 gettername()、mode()、uid()、gid()、size()、mod_time()、checksum()、typeflag()、linkname()、magic()、version()、uname()、gname()、devmajor()、devminor()、prefix()、pad()另有is_dir()、is_ustar()、num_content_blocks()等判定方法api/util/tar.hpp。测试服务的print_header()逐项打印了这 17 个字段与 test.py 的断言一一对应。五、底层实现512 字节块的 ustar 头解析Tar_header完整对应 POSIX ustar 格式api/util/tar.hpp各字段定长定义如下字段长度字节说明name100元素路径名mode8权限与模式位八进制字符串uid/gid8 / 8属主 / 属组 IDsize12文件大小八进制mod_time12最后修改时间八进制 Unix 时间戳checksum8头记录校验和typeflag1元素类型0普通文件5目录linkname100链接目标名magic6ustar标识version2ustar 版本uname/gname32 / 32属主 / 属组名devmajor/devminor8 / 8设备主 / 次号prefix155文件名前缀pad12填充Reader::read()的解析算法src/util/tar.cpp以SECTOR_SIZE 512为步长遍历整份数据数据总长必须是 512 的整数倍否则抛出Tar_exception(Invalid size of tar file)每个 512 字节块先被解释为Tar_header若name为空则跳过归档尾部填充块依据typeflag判断目录DIRTYPE即5没有内容块普通文件REGTYPE即0则在头块后按num_content_blocks()计算出内容占用的 512 字节块数并记录内容起始指针Element::size()使用strtol(header_.size, pEnd, 8)以八进制解析大小字段src/util/tar.cppis_ustar()通过比较magic字段与TMAGIC判断是否为 ustar 格式。从测试断言可知README.md 的Size为293字节、Magic为ustar、Typeflag为0文件目录l2的Typeflag为5、Size为0。六、解压链路Reader::decompress与 uzlib对tar.gz的支持来自内嵌的 uzlib见 deps/uzlib 与#include tinf.h核心流程在 src/util/tar.cpp首次调用时执行uzlib_init()has_uzlib_init全局标志保证只初始化一次通过uzlib_gzip_parse_header解析 gzip 头失败抛出Tar_exception用uzlib_uncompress_init与uzlib_uncompress_chksum循环解压到目标缓冲区解压长度由decompressed_length()从数据末尾 4 字节按 256 进制推算src/util/tar.cpp这是 gzip ISIZE 字段的编码方式。值得注意的两个能力边界tar 内嵌 tar.gzReader::decompress(const Element)可对归档内某个元素继续解压配合Element::is_tar_gz()按.tar.gz后缀判断可实现嵌套归档解析api/util/tar.hpp校验和Reader::checksum(element)返回crc32校验值。单元测试 test/unit/util/tar_test.cpp 对这些行为做了覆盖单元素/多元素 tar 读取、无效 tar 与损坏 tar.gz 抛出异常、tar 内嵌 tar.gz 的解压等并用 corrupt-tar-gz.sh 向 gzip 尾部写入破坏字节来构造损坏样本。七、验证机制test.py 的逐行断言集成测试由 test.py 驱动它启动虚拟机镜像util_tar_gz.elf.bin默认 30 秒超时并注册对服务输出的正则/子串监听器全部通过后以 All tests passed 退出。断言要点元素总数10 个元素名分别被element_names()与elements()两处打印共触发 20 次num_elements 20README 头字段17 行头输出逐行匹配Size of README.md: 293、Typeflag of README.md: 0、Magic of README.md: ustar等num_header1 17README 内容校验First block of content:打印出的正文即这份文档的开头三行——### IncludeOS Demo Service、This demo-service should start an instance of IncludeOS ...、Note: Remember to run the bridge creation script ...目录判定l2 is a folder目录无内容全量遍历10 个元素的Name: ... Typeflag: X组合断言验证0/5两种类型flagnum_elements累计到 20。虚拟机的硬件配置见 vm.jsonvirtio 网卡MACc0:01:0a:00:00:2a、128 MB 内存。八、运行环境与注意事项小结构建方式当前仓库中以 test/integration/util/tar_gz/CMakeLists.txt 为入口经os_add_executableos_add_binary_blob生成镜像README 中的make ./run.sh是其原始工程模板的快捷方式网络前提QEMU 下需先执行桥接创建脚本README 所提etc/create_bridge.sh以打通宿主机与虚拟机网络本仓库测试环境则由 vm.json 的 virtio 设备配置承载目录路径规范通过Tar::element()取目录必须带结尾/取文件必须用精确全路径否则会触发Tar_exception内容读取Element::content()返回原始内容指针未做拷贝print_content用%.512s打印首个 512 字节块实际生产使用时应结合size()按需读取格式约束tar 数据总长必须是 512 字节的整数倍gzip 数据末尾须保留合法的 ISIZE 字段否则Reader::read/Reader::decompress会分别抛出异常。整体来看这份 README 所描述的 Demo Service 既是可独立构建运行的 80 端口 Web 服务示例又是 IncludeOS tar 归档能力打包内嵌、ustar 解析、uzlib 解压、按路径查找的端到端验证载体——从一行make命令到 512 字节块上的逐字段解析构成了一个完整可追溯的实战闭环。赞分享操作系统云原生虚拟化网络【免费下载链接】IncludeOSA minimal, resource efficient unikernel for cloud services项目地址https://gitcode.com/gh_mirrors/in/IncludeOS点击查看免费下载相关推荐使用 AWS SDK for JavaScript 构建与运维高弹性 Web 服务wkflw-resilient-service 实战指南使用 AWS SDK for JavaScript 构建与运维高弹性 Web 服务wkflw resilient service 实战指南 导读 本指南基于示例工程教程后端esp-adf CLI Service 实战指南用 esp_console 串口 REPL 构建服务调试与控制终端esp adf CLI Service 实战指南用 esp_console 串口 REPL 构建服务调试与控制终端 esp adf 的 esp_cli_ser音视频音频处理嵌入式物联网语音IncludeOS实战构建高性能HTTP/HTTPS服务器IncludeOS实战构建高性能HTTP/HTTPS服务器 在云计算时代 IncludeOS 作为一个革命性的 unikernel 操作系统为构建 高性能操作系统云原生虚拟化网络上一篇Zag.js 开发工作流全指南pnpm Monorepo 的构建、测试与 E2E 工程实践下一篇7步轻松搞定Umi-OCR离线文字识别的终极完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/15 20:48:52 · 阅读 1.2k IncludeOS Demo Service 实战指南：构建运行 80 端口 Web 服务与内嵌 tar.gz 归档读取
操作系统云原生虚拟化网络【免费下载链接】IncludeOSA minimal, resource efficient unikernel for cloud services项目地址https://gitcode.com/gh_mirrors/in/IncludeOS点击查看免费下载IncludeOS 是一个面向云服务的最小化、资源高效型 unikernel。本文以test/integration/util/tar_gz/tar_example/l1_f1/l2/README.mdIncludeOS Demo Service 使用说明为骨架完整讲解该演示服务的构建、运行与网络配置方法并深入其所在仓库上下文——即它作为 tar 归档集成测试载荷如何被打包、内嵌进内核镜像、再通过 IncludeOS 的tar库在运行时解压读取与逐字段验证。读完本文你将掌握 IncludeOS 演示服务的启动流程、tar/tar.gz资源的构建期内嵌与运行期解析方法以及整套集成测试的断言机制。一、Demo Service 快速上手构建与运行关联文档 README.md 给出了这个演示服务最简明的启动方式make ./run.sh该服务的作用是启动一个 IncludeOS 实例在 80 端口上提供一个提供静态内容的最小 Web 服务原文should start an instance of IncludeOS that brings up a minimal web service on port 80 with static content。文档同时强调了一个运行前提——QEMU 环境下要使网络可用需要先执行桥接创建脚本etc/create_bridge.sh这是文档所述演示工程自带的网络环境准备步骤README 原文脚注Remember to run the bridge creation script for networking to work on qemu。需要说明的是在当前仓库中该测试的构建与运行并非直接调用make/run.sh而是由集成测试框架驱动详见下文第三节与第八节make ./run.sh更准确地说是这份 README 所描述的服务本体在其原始工程模板中的启动方式。二、Demo Service 的实现80 端口上的静态 HTTP 服务README 所说的80 端口 Web 服务其真实源码位于 tar_example/l1_f1/l2/service.cpp与测试根目录下的 service.cpp 为同一服务测试目录中保留了多份副本以验证 tar 归档的目录结构。核心启动逻辑如下void Service::start(const std::string) { // DHCP on interface 0 auto inet net::Inet::ifconfig(10.0); // static IP in case DHCP fails net::Inet::ifconfig( { 10,0,0,42 }, // IP { 255,255,255,0 }, // Netmask { 10,0,0,1 }, // Gateway { 10,0,0,1 }); // DNS // Set up a TCP server on port 80 auto server inet.tcp().bind(80); server.on_accept( [] (auto socket) - bool { ... return true; }) // 允许所有连接 .on_connect( [] (auto conn) { conn-on_read(1024, [conn] (net::tcp::buffer_t buf, size_t n) { std::string data { (char*)buf.get(), n }; if (data.find(GET / ) ! std::string::npos) { std::string response HTML_RESPONSE(); conn-write(response.data(), response.size(), ...); } else { conn-write(NOT_FOUND.data(), NOT_FOUND.size()); } }); ... }); }实现要点网络配置优先在接口10.0上走 DHCP同时配置静态 IP10.0.0.42/24、网关与 DNS10.0.0.1作为 DHCP 失败时的兜底方案TCP 服务inet.tcp().bind(80)在 80 端口监听on_accept放行所有连接on_connect中以 1024 字节缓冲异步读取请求静态内容收到GET /请求后返回HTML_RESPONSE()生成的一段硬编码 HTML含随机配色、Uubuntu 字体引用、TCP 状态说明等并附带手写 HTTP 头HTTP/1.1 200 OK、Content-Type: text/html; charsetUTF-8、Content-Length等其他请求返回404 Not Found。README 所称静态内容即指这份服务端硬编码的响应体。三、这份 README 为何住在 tar.gz 里归档集成测试的定位单纯从文件树看这份 README 位于test/integration/util/tar_gz/tar_example/l1_f1/l2/下其上一层tar_example/是特意构造的、结构丰富的测试归档内容tar_example/l1_f1/l2/含README.md与service.cpp两级嵌套目录tar_example/l1_f1/service.cpp另一份服务源码副本tar_example/l1_f2/virtio.hpp拷贝进归档的 virtio 头文件tar_example/first_file.txt、tar_example/second_file.md扁平文件也就是说这份 README 本身就是测试数据的一部分它会被打包进tar_example.tgz随内核镜像一起发布再在运行期被读回来、逐行打印、逐字段断言。这正是 test/integration/util/tar_gz/CMakeLists.txt 所做的事add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/tar_example.tgz COMMENT Creating tar file COMMAND tar cfvz ${CMAKE_CURRENT_BINARY_DIR}/tar_example.tgz -C ${CMAKE_CURRENT_SOURCE_DIR} tar_example BYPRODUCTS ${CMAKE_CURRENT_BINARY_DIR}/tar_example.tgz ) os_add_executable(util_tar_gz Tar.gz Test Service service.cpp) os_add_binary_blob(util_tar_gz ${CMAKE_CURRENT_BINARY_DIR}/tar_example.tgz input.bin binary)三步走即可看懂构建期链路tar cfvz将tar_example目录递归打包为tar_example.tgz含README.mdos_add_executable编译测试服务service.cppos_add_binary_blob实现在 cmake/os.cmake用objcopy把 tgz 转换为对象文件并整体链接进内核生成 blob 符号_binary_input_bin_start/_binary_input_bin_size见 api/util/tar.hpp。测试服务的Service::start随即在运行期消费这段内嵌数据service.cppconst auto decompressed Reader::decompress_tar(); // 解压内嵌的 tar_example.tgz Tar read_tarfile Reader::read(decompressed.data(), decompressed.size()); // 1) 列出归档内全部元素名 auto found_elements read_tarfile.element_names(); // 2) 按路径精确取文件README.md const std::string path1 tar_example/l1_f1/l2/README.md; auto element read_tarfile.element(path1); // 3) 按路径取文件夹注意目录路径必须带结尾 / const std::string path2 tar_example/l1_f1/l2/; auto element2 read_tarfile.element(path2); // 4) 遍历所有元素并打印 name 与 typeflag auto elements read_tarfile.elements();四、在归档中定位元素Tar::element与Element头字段tar库位于 api/util/tar.hpp核心 API 如下Reader::read_tar()/Reader::decompress_tar()直接读取或解压链接期内嵌的 blobReader::read(data, size)把已解压的tar 数据解析为Tar对象Tar::element_names()返回所有元素名字符串Tar::element(path)按精确路径查找元素目录名必须带结尾/——否则抛出Tar_exception源码实现见 src/util/tar.cppPath ... doesnt exist. Folder names should have a trailing /Tar::elements()返回全部元素的引用容器。Element将 tar 头Tar_header的每个字段都封装成了可读的 gettername()、mode()、uid()、gid()、size()、mod_time()、checksum()、typeflag()、linkname()、magic()、version()、uname()、gname()、devmajor()、devminor()、prefix()、pad()另有is_dir()、is_ustar()、num_content_blocks()等判定方法api/util/tar.hpp。测试服务的print_header()逐项打印了这 17 个字段与 test.py 的断言一一对应。五、底层实现512 字节块的 ustar 头解析Tar_header完整对应 POSIX ustar 格式api/util/tar.hpp各字段定长定义如下字段长度字节说明name100元素路径名mode8权限与模式位八进制字符串uid/gid8 / 8属主 / 属组 IDsize12文件大小八进制mod_time12最后修改时间八进制 Unix 时间戳checksum8头记录校验和typeflag1元素类型0普通文件5目录linkname100链接目标名magic6ustar标识version2ustar 版本uname/gname32 / 32属主 / 属组名devmajor/devminor8 / 8设备主 / 次号prefix155文件名前缀pad12填充Reader::read()的解析算法src/util/tar.cpp以SECTOR_SIZE 512为步长遍历整份数据数据总长必须是 512 的整数倍否则抛出Tar_exception(Invalid size of tar file)每个 512 字节块先被解释为Tar_header若name为空则跳过归档尾部填充块依据typeflag判断目录DIRTYPE即5没有内容块普通文件REGTYPE即0则在头块后按num_content_blocks()计算出内容占用的 512 字节块数并记录内容起始指针Element::size()使用strtol(header_.size, pEnd, 8)以八进制解析大小字段src/util/tar.cppis_ustar()通过比较magic字段与TMAGIC判断是否为 ustar 格式。从测试断言可知README.md 的Size为293字节、Magic为ustar、Typeflag为0文件目录l2的Typeflag为5、Size为0。六、解压链路Reader::decompress与 uzlib对tar.gz的支持来自内嵌的 uzlib见 deps/uzlib 与#include tinf.h核心流程在 src/util/tar.cpp首次调用时执行uzlib_init()has_uzlib_init全局标志保证只初始化一次通过uzlib_gzip_parse_header解析 gzip 头失败抛出Tar_exception用uzlib_uncompress_init与uzlib_uncompress_chksum循环解压到目标缓冲区解压长度由decompressed_length()从数据末尾 4 字节按 256 进制推算src/util/tar.cpp这是 gzip ISIZE 字段的编码方式。值得注意的两个能力边界tar 内嵌 tar.gzReader::decompress(const Element)可对归档内某个元素继续解压配合Element::is_tar_gz()按.tar.gz后缀判断可实现嵌套归档解析api/util/tar.hpp校验和Reader::checksum(element)返回crc32校验值。单元测试 test/unit/util/tar_test.cpp 对这些行为做了覆盖单元素/多元素 tar 读取、无效 tar 与损坏 tar.gz 抛出异常、tar 内嵌 tar.gz 的解压等并用 corrupt-tar-gz.sh 向 gzip 尾部写入破坏字节来构造损坏样本。七、验证机制test.py 的逐行断言集成测试由 test.py 驱动它启动虚拟机镜像util_tar_gz.elf.bin默认 30 秒超时并注册对服务输出的正则/子串监听器全部通过后以 All tests passed 退出。断言要点元素总数10 个元素名分别被element_names()与elements()两处打印共触发 20 次num_elements 20README 头字段17 行头输出逐行匹配Size of README.md: 293、Typeflag of README.md: 0、Magic of README.md: ustar等num_header1 17README 内容校验First block of content:打印出的正文即这份文档的开头三行——### IncludeOS Demo Service、This demo-service should start an instance of IncludeOS ...、Note: Remember to run the bridge creation script ...目录判定l2 is a folder目录无内容全量遍历10 个元素的Name: ... Typeflag: X组合断言验证0/5两种类型flagnum_elements累计到 20。虚拟机的硬件配置见 vm.jsonvirtio 网卡MACc0:01:0a:00:00:2a、128 MB 内存。八、运行环境与注意事项小结构建方式当前仓库中以 test/integration/util/tar_gz/CMakeLists.txt 为入口经os_add_executableos_add_binary_blob生成镜像README 中的make ./run.sh是其原始工程模板的快捷方式网络前提QEMU 下需先执行桥接创建脚本README 所提etc/create_bridge.sh以打通宿主机与虚拟机网络本仓库测试环境则由 vm.json 的 virtio 设备配置承载目录路径规范通过Tar::element()取目录必须带结尾/取文件必须用精确全路径否则会触发Tar_exception内容读取Element::content()返回原始内容指针未做拷贝print_content用%.512s打印首个 512 字节块实际生产使用时应结合size()按需读取格式约束tar 数据总长必须是 512 字节的整数倍gzip 数据末尾须保留合法的 ISIZE 字段否则Reader::read/Reader::decompress会分别抛出异常。整体来看这份 README 所描述的 Demo Service 既是可独立构建运行的 80 端口 Web 服务示例又是 IncludeOS tar 归档能力打包内嵌、ustar 解析、uzlib 解压、按路径查找的端到端验证载体——从一行make命令到 512 字节块上的逐字段解析构成了一个完整可追溯的实战闭环。赞分享操作系统云原生虚拟化网络【免费下载链接】IncludeOSA minimal, resource efficient unikernel for cloud services项目地址https://gitcode.com/gh_mirrors/in/IncludeOS点击查看免费下载相关推荐使用 AWS SDK for JavaScript 构建与运维高弹性 Web 服务wkflw-resilient-service 实战指南使用 AWS SDK for JavaScript 构建与运维高弹性 Web 服务wkflw resilient service 实战指南 导读 本指南基于示例工程教程后端esp-adf CLI Service 实战指南用 esp_console 串口 REPL 构建服务调试与控制终端esp adf CLI Service 实战指南用 esp_console 串口 REPL 构建服务调试与控制终端 esp adf 的 esp_cli_ser音视频音频处理嵌入式物联网语音IncludeOS实战构建高性能HTTP/HTTPS服务器IncludeOS实战构建高性能HTTP/HTTPS服务器 在云计算时代 IncludeOS 作为一个革命性的 unikernel 操作系统为构建 高性能操作系统云原生虚拟化网络上一篇Zag.js 开发工作流全指南pnpm Monorepo 的构建、测试与 E2E 工程实践下一篇7步轻松搞定Umi-OCR离线文字识别的终极完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考