生活在字典树上 —— 存储和匹配海量的域名和 IP 地址
如果你经受过正经的 CS 教育(在课堂上亦或是自学),那么你无需花费过多的时间读完本文;本文试图讲解的数据结构非常基础、你理应早就掌握了。原本我甚至不屑于将这些内容写成一篇文章,但是在见识到网络反审查社区参与者的平均水平和技术素养的多样性之后,我觉得这么一篇最基础的数据结构的扫盲科普还是很有必要的。
如果你经受过正经的 CS 教育(在课堂上亦或是自学),那么你无需花费过多的时间读完本文;本文试图讲解的数据结构非常基础、你理应早就掌握了。原本我甚至不屑于将这些内容写成一篇文章,但是在见识到网络反审查社区参与者的平均水平和技术素养的多样性之后,我觉得这么一篇最基础的数据结构的扫盲科普还是很有必要的。
UniFi 网关设备(如 UDM Pro/SE/Pro Max)搭载的 CPU 性能出了名的孱弱、还缺乏 PPPoE 和 NAT 硬件加速的支持,在搭配 PPPoE 拨号的宽带时,UniFi 网关的性能更是捉襟见肘。那么,为什么不把 PPPoE 拨号的任务交给一个单独的设备来处理、让 UniFi 网关专注于路由、IDS/IPS 和 NAT 呢?
让我们抛弃传统的「猫鼠游戏」对抗思维,不去费力寻找 VLESS 和 REALITY 协议在密码学上可能存在的深奥缺陷,而去关注一个更具决定性且无法逾越的变量:@RPRX 在代码工程实现层面所表现出的、近乎结构性的认知局限。通过针对性地审计 XTLS 的实现代码,我们可以在不触碰任何高深算法的前提下,实现对 XTLS VLESS REALITY 代理服务的手术刀式探测与精准识别。
虽然 Microsoft 早早就为 Microsoft 个人账号提供了 Passkey 登录支持,但是对于 Microsoft 365 企业(含教育版),微软的硬件 Passkey 登录支持直到 2025 年年初才姗姗来迟,而可同步的 Synced Passkey(如 1Password、iCloud Keychain、Google Password Manager 等)的支持更是直到最近...
作为互联网基础设施的基石之一,DNS 也是最脆弱的环节之一。在项目从上线、运营维护的整个生命周期中,DNS 记录的变更和管理是不可避免的。传统上,DNS 记录的管理往往依赖于域名注册商或 DNS 服务商提供的 控制平面,操作不直观、不可复现、容易出错、难以追溯、没有自动化。基础设施即代码(Infrastructure as Code, IaC)无疑为脆弱的 DNS 记录管理给出了一个方向。
2001 年 4 月 IETF 通过的 RFC3089 中所描述的 Fake IP,是四层代理分流场景下 性能相对最佳、体验相对最好、实现相对最简单的「最佳实践」。相比之下,Real IP 模式下为了尽可能接近 Fake IP 的性能、体验,需要大量额外配置、付出更多的代价。
最近在「家里云」里搞了个 Proxmox VE 8.3,打算在上面跑几个 VM 玩玩。而作为一名忠实的 Debian 系用户 我才不会告诉你我日用的 Linux 系统是搭载 GNOME 的 Fedora 的,所有的 VM 自然要用 Debian 了。借着制作自己的定制化 Debian Cloud Image 的机会,顺便写一篇文章出来和大家分享一下,并纠正、辟谣一下网上现有的有关教程的一些错误。
和大部分人使用浏览器书签或者导航类网站索引自己的常用网站不同,我强烈依赖基于浏览器地址栏自动补全来访问我常用的网站。那么,将 A-Z 逐一输入到 Google Chrome 的地址栏里,我的 Google Chrome 都会自动补全出哪些域名呢?
好久没写网络相关的科普文了,这次借着搬家的机会,我重新设计了一下的网络架构、给自己的公寓组网,写一篇上万字的组网碎碎念记录一下。
对于全新的 React 项目来说,一开始就使用 Next.js、Remix、Shopify Hydrogen、Gatsby 等 React 元框架(Meta Framework)是最正确的选择,这些元框架替你解决了路由、数据加载、服务端渲染(SSR)、全静态页面导出(SSG)、边缘计算、打包器和编译器配置。然而,如果你需要迁移现有的、纯客户端渲染(Client-side Rendering)的项目到 React、或者从其他打包器(如 Vite 或 Parcel)迁移走时,即使在 2024 年,webpack 仍然不
我使用 Surge Mac 作为网络核心有一段时间了。虽然 Surge 官方提供了一份「中国区用户推荐最小配置」,但是为了发挥 Surge 全部潜力的话、彻底值回 Surge 的售价、实现我的复杂需求,我添加了许多自定义的配置。
使用过 React 构建应用的开发者对 React Context 一定不会陌生。在 React 的世界中,相比于把 prop 不断透传给下一层子组件(prop-drilling),React Context 可以更优雅地自上而下将数据从父组件传递到深层级的子组件、并确保数据在不同子组件之间保持一致。不过,Context 绝不是仅属于 React,在 JavaScript 中 Context 一样可以大展拳脚。
将 A-Z 逐一输入到 Google Chrome 的地址栏里,Google Chrome 都会自动补全出哪些域名呢(诶?)
去年的这个时候,我把博客从 Hexo 迁移到 Next.js。现在,随着 Next.js 13 App Router 已经稳定,我又把博客从 Next.js Pages Directory 迁移到了 Next.js 13 的 App Router 和 React Server Component。
形如 的 Meta Keywords 是 Meta 标签的一种,仅存在于 HTML 代码中、不会在浏览器中展示。过去,Meta Keywords 标签被用于告诉搜索引擎爬虫关于网页的信息。但是,现在搜索引擎还尊重 Meta Keywords 么?Meta Keywords 是否仍然是 SEO 的最佳实践?
将 A-Z 逐一输入到 Google Chrome 的地址栏里,Google Chrome 都会自动补全出哪些域名呢?
更新(重新渲染)是 React 的重要特性 —— 当用户与应用交互的时候,React 需要重新渲染、更新 UI,以响应用户的输入。但是,React 为什么会重新渲染呢?如果不知道 React 为什么会重新渲染,我们如何才能避免额外的重新渲染呢?
React 是一个由 Facebook 开源的、可以在任意平台上构建 UI 的 JavaScript 库。在 React 中,一个常见的 Pattern 是使用 useEffect 搭配 useState 发送请求、将状态从 API(React 外部)同步到 React 内部、用于渲染 UI,这篇文章恰恰在向你介绍为什么你不应该直接这么做。
众所周知,DNS 的作用与电话簿类似,将人类可读的域名映射到机器可读 IP 地址、使人更方便地访问互联网。DNS 是非常重要的互联网基础设施,对于改善上网冲浪的体验中的重要程度不容小觑。
距离上一篇文章发布已有四个月了,是时候写几篇文章给博客除草了。上一次我介绍了我如何迁移、重构了我的博客的架构,这次我想来谈谈我在重构中优化和打磨访客体验时解决的一个问题。 我的博客优化之旅 图片 lazyload 的学问和在 Hexo 上的最佳实践 我的博客有多快? 天下武功,唯快不破 —— 我是这样优化博客的 再快一点,再快一点 —— 优化博客白屏时间的实践 使用 Next.js +...
在咕咕了一整年、只发布了三篇文章(其中两篇还是译文)之后,我决定还是稍微花一点时间好好折腾一下自己的博客,以 React 作为抓手,通过 Next.js 和 Hexo 深度共建,对标 Gatsby,打通静态 HTML 与用户交互之间的垂直领域屏障,实现多维矩阵闭环,为个人博客赋能(咳咳咳),然后水出 2022 年第一篇文章(逃) 技术选型:Gatsby vs Next.js 我使用 H...
加密货币社区对元宇宙和 Web3 的狂热仍在继续,大量投资人和开发者前仆后继加入其中。但是,Web3 真的能实现支持者们的种种愿景吗?亦或是另一个镜中月、水中花?也许让历史照进现实,能给我们答案。
作为一个充满泡沫和噱头的新概念,Web3 和元宇宙在区块链的社区中掀起了一波浪潮。鼓吹者坚信 Web3 就是互联网的未来、不惜砸下大把的金钱和精力、希望能在未来中捞一杯羹;而大部分人保持观望的态度。是时候来一点 Web3 的反对意见了。
我们正生活在一个「Any application that can be written in JavaScript, will eventually be written in JavaScript」的时代。作为一门兼具动态性和简单性的语言,JavaScript 已经占领了客户端、服务端,甚至在机器学习中也占据一席之地;不可避免的,异步执行也逐渐成为这门语言不可缺少的一部分。 TL;...
著名的同人本资源集散地 E-hentai 有一个完全没有人在意的角落 ——「HentaiVerse」,一个纯文字网页 RPG 游戏。虽然这个游戏应该不会有太多新玩家了,不过还是翻译一篇给新玩家的指导文吧。