From 5a6bffb462d6a6668f189cbbd6079838ff3ae90b Mon Sep 17 00:00:00 2001 From: dichgrem Date: Sun, 18 Jan 2026 14:15:38 +0800 Subject: [PATCH] remove:some --- content/Network-cdn.md | 255 ------------------------ content/Network-ssl.md | 103 ---------- content/about-accurate-pronunciation.md | 78 -------- 3 files changed, 436 deletions(-) delete mode 100644 content/Network-cdn.md delete mode 100644 content/Network-ssl.md delete mode 100644 content/about-accurate-pronunciation.md diff --git a/content/Network-cdn.md b/content/Network-cdn.md deleted file mode 100644 index cc9d2b2..0000000 --- a/content/Network-cdn.md +++ /dev/null @@ -1,255 +0,0 @@ -+++ -title = "网络艺术:CDN技术与应用" -date = 2024-02-16 - -[taxonomies] -tags = ["Network"] -+++ - -前言 内容分发网络（CDN）是一组分布在不同地理位置的服务器网络,使用户能够就近获取内容，从而降低延迟并缓解源站压力​. - - - -## 什么是CDN？ - -内容分发网络（CDN）是一组分布在不同地理位置的服务器网络，旨在将网站或应用的静态资源（如HTML、图片、视频等）缓存到距离用户更近的节点，以缩短传输路径、降低带宽成本并提高访问速度​.CDN通过“缓存”机制，在全球多个数据中心临时存储内容副本，用户发起请求时无需回源到主服务器，就能从最近的缓存节点获取数据，从而显著改善页面加载时间和整体用户体验​.相比传统的单点源站访问，CDN在用户和源站之间增加了分层缓存，通过负载均衡技术和智能路由，将访问请求定向到最优节点，既减轻了源站压力，又提升了网络抗拥塞能力和可用性​. - -在现代互联网中，内容分发网络（CDN）和域名系统（DNS）相互配合，共同提升了网页和多媒体内容的访问速度与可靠性.CDN通过在全球分布的缓存节点上存储静态资源，使用户能够就近获取内容，从而降低延迟并缓解源站压力​.而DNS则负责将用户的域名请求导向适当的CDN节点，通过CNAME重定向、全局负载均衡（GSLB）、Anycast及EDNS扩展等技术，实现智能化的流量调度和最优路径选择​. - -**CDN的核心功能与优势** - -- 加速访问：将内容存储于距离用户更近的节点，减少传输延迟，常见于视频点播、大文件下载等场景​. - -- 减轻源站压力：缓存请求可直接由CDN节点响应，降低源站带宽和计算资源消耗，有助于应对突发流量和DDoS攻击​. - -- 高可用与弹性扩展：全球分布的节点架构，使内容分发具备冗余能力，单点故障不会影响整体服务，且可动态扩容以应对业务增长. - -## CDN与DNS的结合方式 - -1. **通过CNAME实现权威DNS指向CDN** - -当用户在浏览器中输入域名发起请求时，首先触发本地DNS解析过程；如果该域名已开通CDN服务，其DNS解析记录通常配置为一条CNAME（别名）记录，指向CDN运营商提供的专用域名；本地DNS服务器再将解析权交给CDN的权威DNS服务器，从而实现对CDN网络的接入​. - - -CDN的权威DNS服务器根据用户请求的域名，返回一个“全局负载均衡设备”的IP地址，该IP并非最终缓存节点，而是GSLB层用于智能调度的入口地址；浏览器接收到该IP后，向GSLB层发起实际内容请求​. - -2. **全局负载均衡（GSLB）与智能DNS** - -GSLB（Global Server Load Balancing）是CDN架构中最核心的部分，负责根据多种因素（用户IP地理位置、节点健康状态、节点负载情况等）动态选择最优区域负载均衡节点或缓存服务器，向用户提供最低延迟和最佳性能的服务​. - -这一过程通常也基于DNS解析完成：当GSLB层接到DNS查询请求时，智能DNS服务器会返回针对该用户最优的缓存节点IP，从而实现“DNS级”的流量调度和负载均衡​. - -3. **Anycast与EDNS扩展** - -Anycast路由：部分CDN运营商在全球部署相同IP的多个节点，利用BGP Anycast技术使得用户请求自动路由到网络拓扑上“最近”的节点，增强访问的网络路径效率与容灾能力​. - -EDNS Client Subnet（EDNS-CS）：传统DNS仅看到发起查询的递归DNS服务器IP，难以准确判断终端用户位置；EDNS-CS协议在DNS请求中携带部分客户端IP前缀，使权威DNS能更细粒度地进行地理定位与节点选取，大幅提升了基于DNS的智能调度精度​. - - - -## 为什么加了CDN之后网站的自签名证书也被信任了？ - -> 在启用 CDN 后，终端用户看到的并不是您在源站（origin）上配置的自签名证书，而是 CDN 边缘节点（edge）所出示的、由受信任 CA 签发的“边缘证书”.也就是说，浏览器与 CDN 边缘之间的 TLS 握手完全独立于您源站和自签名证书的存在，源站的自签名证书仅用于 CDN 与源站之间的“后端”加密连接，不会暴露给最终用户浏览器​. - - -**CDN 模式下的 TLS 终止** - -- **DNS/CNAME 指向** - 当您为域名启用 CDN 后，通常会在 DNS 中将该域名的 CNAME 记录指向 CDN 运营商提供的专用域名，本地递归 DNS 随后会将解析权交给 CDN 供应商的权威 DNS，实现请求切入 CDN 网络​. - -- **边缘节点出示证书** - 用户发起 HTTPS 请求时，浏览器直接与就近的 CDN 边缘节点建立 TLS 连接，边缘节点会出示由受信任 CA（如 Let's Encrypt、DigiCert 等）签发的“边缘证书”，而非您源站的自签名证书​. - -- **源站连接加密** - 在边缘节点接收并缓存用户流量后，CDN 再以 HTTPS（或 HTTP，根据配置）向源站发起请求.此时，您可以在源站使用自签名证书（或 Cloudflare Origin CA 自签名证书），仅保证 CDN 与源站之间的加密传输，且该证书对终端用户浏览器不可见​. - -### SSL/TLS 加密模式对自签名证书的影响 - -以 Cloudflare 为例，常见的四种 SSL/TLS 模式对自签名证书的处理策略如下： - -- **Flexible**：浏览器 ↔ CDN 边缘 使用 HTTPS；CDN 边缘 ↔ 源站 使用 HTTP，不接触证书验证. - -- **Full**：浏览器 ↔ CDN 边缘 使用 HTTPS；CDN 边缘 ↔ 源站 使用 HTTPS，但不验证源站证书的 CA 链和域名匹配，可使用自签名证书​. - Cloudflare Docs - -- **Full (strict)**：浏览器 ↔ CDN 边缘 使用 HTTPS；CDN 边缘 ↔ 源站 使用 HTTPS，严格验证源站证书是否由受信任 CA 签发且域名匹配，不支持自签名证书​. - Cloudflare Docs - -- **Off**：关闭 HTTPS，加密支持完全关闭. - -若您选择 Full 或 Flexible 模式，即使源站使用自签名证书，CDN 也不会在边缘层对其进行验证，仍会正常转发和缓存内容；而用户浏览器只会看到 CDN 边缘提供的受信任证书，因此不会出现“不受信任”警告​. - -> 为什么浏览器会信任? 浏览器内置了受信任的根证书列表，CDN 边缘出示的证书链会完整地链接到某个系统信任根，而您的自签名证书则不在此列表内，因而只有源站连接可被 CDN 信任，而非终端浏览器​.CDN 则作为“可信中间人”，它信任自签名证书以加密与源站的通信，而浏览器仅信任 CDN 边缘的 CA 签发证书，二者互不干扰，有效隔离了自签名的风险. - - -### 如何开启Full (Strict)模式？ - - -​要在 Cloudflare 上启用 Full (Strict) 模式，以确保 CDN 与源站之间的通信既加密又验证证书的有效性，请按照以下步骤操作：​ - -✅ 步骤 1：确保源站配置了有效的 SSL/TLS 证书 - -在启用 Full (Strict) 模式之前，您的源站必须安装一个有效且受信任的 SSL/TLS 证书.​您可以选择以下方式之一：​ - - 使用公共 CA 颁发的证书：如 Let's Encrypt、DigiCert、GlobalSign 等. - - 使用 Cloudflare Origin CA 证书：这是 Cloudflare 提供的免费证书，专为与其边缘节点通信设计.​ - -确保证书未过期，且域名匹配正确.如果使用 Cloudflare Origin CA 证书，请在源站服务器上正确安装，并配置服务器（如 Nginx、Apache）以使用该证书.​ - -✅ 步骤 2：在 Cloudflare 仪表板中启用 Full (Strict) 模式 -``` -登录到您的 Cloudflare 仪表板. - -选择您要配置的站点. - -在左侧菜单中，点击 “SSL/TLS”. - -在 “概览（Overview）” 标签下，找到 “SSL/TLS 加密模式（SSL/TLS encryption mode）”. - -选择 “Full (Strict)” 模式.​ -``` - -更改后，Cloudflare 会立即应用此设置.​建议等待几分钟，然后通过浏览器访问您的网站，确保一切正常运行.​ - -🔗 注意事项 - -如果源站使用的是自签名证书或过期的证书，启用 Full (Strict) 模式后，Cloudflare 将无法建立连接，用户可能会看到 526 错误. - -确保源站服务器的时间设置正确，以避免因时间不一致导致的证书验证失败. - -## DNSSEC是什么？ - -DNSSEC（Domain Name System Security Extensions，域名系统安全扩展）是一组为 DNS 协议设计的安全机制，旨在通过数字签名验证 DNS 数据的真实性和完整性，防止域名解析过程中的数据篡改和伪造. - -1. DNSSEC 的工作原理 - -DNSSEC 通过引入以下关键机制来增强 DNS 的安全性：​ - -- 数字签名（RRSIG 记录）：​每个 DNS 记录集（如 A、MX、CNAME 等）都会生成一个对应的数字签名，确保记录在传输过程中未被篡改.​ - -- 公钥发布（DNSKEY 记录）：​用于存储验证数字签名所需的公钥.​这些公钥本身也通过上级域的签名进行验证，形成信任链.​ - -- 委派签名者（DS 记录）：上级域使用 DS 记录存储下级域的 DNSKEY 记录的摘要，确保公钥的真实性. - -- 不存在性证明（NSEC/NSEC3 记录）：用于明确指示某个 DNS 记录不存在，防止攻击者伪造不存在的记录. - -通过这些机制，DNSSEC 建立了一条从根域开始的信任链，逐级验证每个域的 DNS 数据，确保其未被篡改且来源可信. - -2. DNSSEC 的局限性 - -- 不加密数据内容：DNSSEC 仅对 DNS 数据进行签名验证，并不加密查询和响应内容，因此无法防止数据被监听. - -- 部署复杂性：​实施 DNSSEC 需要域名注册商、DNS 服务提供商和客户端解析器的共同支持，部署和维护相对复杂.​ - -- 性能影响：​由于引入了额外的签名验证过程，DNSSEC 可能会增加 DNS 查询的响应时间和系统资源消耗.​ - -3. DNSSEC 的优势 - -- 防止 DNS 欺骗和缓存投毒：​通过验证 DNS 数据的真实性，DNSSEC 能有效防止攻击者伪造 DNS 响应，将用户引导至恶意网站.​ - -- 增强互联网基础设施安全性：​作为互联网信任体系的一部分，DNSSEC 为其他安全协议（如 DANE）提供基础支持.​ - -## CDN的位置选择 - -Netlify在考虑到CDN成本以及可用性的情况下选择了以下这些地区以保证全球大部分访客访问他们的服务都能有不错的连接性和访问速度。 - -``` -欧洲中部（德国法兰克福） -南美（巴西圣保罗） -美东（美国弗吉尼亚） -美西（美国旧金山） -亚洲（新加坡） -大洋洲（澳大利亚悉尼） -``` -那么Netlify为什么会选择把CDN节点放到这些地区呢？ - -1.弗吉尼亚，美东的弗吉尼亚被誉为“全球数据中心之都"，美国政府对这个地区的网络投入非常大，使得弗吉尼亚的全球互联（美国本土、欧洲以及到南美洲）优秀。 - -2.旧金山，面向亚太和美西的访客。需要注意的是美西对亚太的网络连接比较优秀，但是到南美不太理想，甚至还有丢包的情况。 - -3.法兰克福，面向欧洲用户，德国法兰克福或者荷兰阿姆斯特丹都是不错的选择。 - -4.新加坡，亚太地区数据中心的枢纽，到印度、日本、越南、香港、中国移动的联通性都不错。 - -5.悉尼，土澳出了名的国际互联不太好，悉尼节点主要是服务本地和周边。 - -6.圣保罗，南美市场。 - - -## 常见CDN的IP列表 - -> 需要注意的是有些CDN的回源IP并不用作节点IP，比如Cloudflare的回源IP仅作回源IP使用，如果要获取Cloudflare的节点IP，可前往https://bgp.tools/as/13335#prefixes。而有些CDN的回源IP同时被用作CDN节点，比如BunnyCDN和Gcore CDN。 - -Cloudflare -```bash -# https://www.cloudflare.com/ips-v4 -103.21.244.0/22 -103.22.200.0/22 -103.31.4.0/22 -104.16.0.0/13 -104.24.0.0/14 -108.162.192.0/18 -131.0.72.0/22 -141.101.64.0/18 -162.158.0.0/15 -172.64.0.0/13 -173.245.48.0/20 -188.114.96.0/20 -190.93.240.0/20 -197.234.240.0/22 -198.41.128.0/17 - -# https://www.cloudflare.com/ips-v6 -2400:cb00::/32 -2405:8100::/32 -2405:b500::/32 -2606:4700::/32 -2803:f800::/32 -2a06:98c0::/29 -2c0f:f248::/32 -``` -Gcore -```bash -https://api.gcore.com/cdn/public-ip-list -``` -BunnyCDN -```bash -https://api.bunny.net/system/edgeserverlist -https://api.bunny.net/system/edgeserverlist/plain -``` -Cloudfront -```bash -https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips -https://files.imunify360.com/static/whitelist/v2/cloudfront-cdn.txt -``` -CDN77 -```bash -https://files.imunify360.com/static/whitelist/v2/cdn77.txt -``` -Fastly -```bash -https://api.fastly.com/public-ip-list -``` -Keycdn -```bash -https://www.keycdn.com/shield-prefixes.json -``` -quic.cloud -```bash -https://quic.cloud/ips -``` -Google CDN -```bash -https://files.imunify360.com/static/whitelist/v2/google-cdn.txt -``` -CacheFly -```bash -https://cachefly.cachefly.net/ips/cdn.txt -``` -Akaima -```bash -https://techdocs.akamai.com/origin-ip-acl/docs/update-your-origin-server -``` ---- -**Done.** diff --git a/content/Network-ssl.md b/content/Network-ssl.md deleted file mode 100644 index 65a3b41..0000000 --- a/content/Network-ssl.md +++ /dev/null @@ -1,103 +0,0 @@ -+++ -title = "网络艺术:SSL/TLS证书" -date = 2024-02-15 - -[taxonomies] -tags = ["Network"] -+++ - -前言 什么是SSL/TLS证书？它有什么作用？如何部署？ - - -## 什么是SSL/TLS证书 - -SSL 的全称是 ``Secure Sockets Layer``（安全套接字层），而 TLS 的全称是 ``Transport Layer Security``（传输层安全协议）。最初由 Netscape 开发的 SSL 协议用于保护网络通信，但由于其存在的安全漏洞，后来被更新、更安全的 TLS 协议所取代。 - -如今，当我们谈论“SSL 证书”时，实际上指的是支持 TLS 协议的数字证书，``两者在功能上没有本质区别，只是在命名上沿用了历史传统``。该证书是由受信任的数字证书颁发机构 CA，在验证服务器身份后颁发，且具有服务器身份验证和数据传输加密功能。简单来说就是``HTTP+SSL/TLS证书=HTTPS.`` - -## SSL证书是如何工作的 - -- 当我们点击一个超链接（HTTP），浏览器帮我们跳转到新标签页； -- 通过DNS（Domain name system）查询找到该域名（地址栏中的如www.xxx.com之类的字符）对应的IP地址，可能是某个CDN的地址； -- 服务器上已经配置好certificate.crt（公钥）和private.key（私钥）； -- CDN随后与真正的服务器建立连接，服务器上的反向代理（可能是nginx或者caddy）检测连接，并用配置好的证书将连接升级为HTTPS； -- HTTPS握手并将内容显示在浏览器上。 - -## SSL/TLS证书的握手过程 - -- 客户端发送"ClientHello"消息，包含支持的加密算法和TLS版本； -- 服务器回应"ServerHello"消息，选择加密算法并发送SSL/TLS证书； -- 客户端验证证书的有效性(通过内置的CA根证书)； -- 客户端使用服务器公钥加密一个"预主密钥"并发送给服务器； -- 双方根据预主密钥生成会话密钥； -- 使用会话密钥进行加密通信； -- 加密通信：握手完成后，所有数据传输都使用协商好的对称密钥加密。 - -> 使用公钥加密的数据只能用对应的私钥解密，使用私钥加密(签名)的数据可以用对应的公钥验证。 - -> 客户端和服务器都支持非常多的密码套件，比如“ECDHE-RSA-AES256-GCM-SHA384”。格式是“密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”，这个密码套件的意思就是：“握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数。” - -## CA证书 - -可以看到，验证证书的有效性需要通过CA证书，由CA机构（如DigiCert -Let's Encrypt）等颁布，CA证书的层级结构如下： - -- 根CA证书：最高级别的证书，自签名，是整个信任链的起点. -- 中间CA证书：由根CA签发，可以签发终端实体证书或其他中间CA证书. -- 终端实体证书：由根CA或中间CA签发给网站、服务器等实体使用. - -操作系统和浏览器``内置了受信任的根CA证书列表``,当验证网站证书时，系统会沿着证书链向上追溯至根CA;如果能找到一个受信任的根CA，且证书链上所有签名有效，则验证通过.这就是保护我们上网安全的``信任链``的基础。 - -当我们访问网页时，往往会看到左上角的``锁``图标，里面是``Google Trust Services``或者``DigiCert Inc``等等，代表证书的颁发来源。如果锁提示不安全，可能是证书过期或者找不到CA证书，即有可能是自签名证书。``什么是自签名证书？`` - -## 证书颁发 - -我们先来看证书颁发的流程。 -- 证书申请：网站所有者向证书颁发机构(CA)申请SSL/TLS证书，提供域名和组织信息。 -- 身份验证：CA验证申请者的身份和域名所有权。验证方式包括域名验证(DV)、组织验证(OV)或扩展验证(EV)。 -- 证书签发：验证通过后，CA使用其私钥为申请者签发数字证书，包含公钥、域名信息、颁发者信息和有效期等。 -- 安装部署：网站管理员将证书安装到Web服务器上。 - -可以看到过程有点麻烦，个人建站的话往往使用自签名证书，即``ssh-keygen``生成的公钥和私钥，由于没有CA所以会显示不安全。 - -## 申请证书 - -- [sslforfree](https://www.sslforfree.com/)由 ZeroSSL 支持颁发的免费SSL证书. - -- 通过[AMH](https://amh.sh/ssl.htm)提供的自助在线申请服务申请SSL通配符证书.需要注册AMH账号. - -- [letsencrypt](https://letsencrypt.osfipin.com/)，支持申请多渠道SSL证书. - -- 借助[Punchsalad](https://punchsalad.com/ssl-certificate-generator/)提供的在线服务申请SSL证书，无需登录，仅需邮箱即可完成SSL通配符证书申请和签发. - -## DV/OV/EV SSL证书的区别 - -以下是三种主要SSL证书验证类型的对比： - -| 特性 | 域名型SSL (DV SSL) | 企业型SSL (OV SSL) | 增强型SSL (EV SSL) | -|------|-------------------|-------------------|-------------------| -| **验证级别** | 最低 | 中等 | 最高 | -| **验证内容** | 仅验证域名所有权 | 验证域名所有权和组织信息 | 最严格的验证，包括法律、物理和运营存在的全面验证 | -| **验证流程** | 自动化验证（邮件、DNS记录等） | 半自动验证 | 人工审核为主 | -| **签发时间** | 几分钟到数小时 | 1-3个工作日 | 5-7个工作日 | -| **浏览器显示** | 普通锁图标 | 普通锁图标 | 地址栏绿色显示（部分浏览器已取消） | -| **适用场景** | 个人博客、信息网站 | 企业网站、电子商务 | 银行、金融机构、大型电商 | -| **成本** | 低 | 中等 | 高 | -| **信任度** | 基本 | 中等 | 最高 | -| **证书信息** | 只包含域名信息 | 包含组织名称和域名 | 包含完整的组织详细信息 | -| **安全加密强度** | 相同 | 相同 | 相同 | - -## 证书类型 - -有时候可以购买如``*.xxx.com``的通配符证书，即一个证书通用与所有子域名。以及还有其他如多域名证书和上面提到的DV/OV/EV证书的类型。 - -| 证书类型 | 覆盖范围 | 安全级别 | 验证过程 | 适用场景 | 价格范围 | -|---------|---------|---------|---------|---------|---------| -| 单域名证书 | 仅一个特定域名 | 基本到高 | DV/OV/EV | 个人网站或小型企业 | 低到高 | -| 通配符证书 | 主域名及其所有一级子域名 | 基本到中等 | DV/OV | 拥有多个子域名的网站 | 中等到高 | -| 多域名证书(SAN) | 多个不同域名 | 基本到高 | DV/OV/EV | 管理多个不相关域名的企业 | 中等到高 | -| 自签名证书 | 任意 | 低 | 无需验证 | 测试环境、内部网络 | 免费 | - - ---- -**Done.** diff --git a/content/about-accurate-pronunciation.md b/content/about-accurate-pronunciation.md deleted file mode 100644 index 3c89622..0000000 --- a/content/about-accurate-pronunciation.md +++ /dev/null @@ -1,78 +0,0 @@ -+++ -title = "乱七八糟:常见发音错误术语集合" -date = 2023-08-25 - -[taxonomies] -tags = ["乱七八糟"] -+++ - -前言 中文和英语发音习惯不同，容易引起误解。本文旨在帮助您准确发音常见的科技术语，欢迎随时补充。 - - - -**常见发音错误指南：公司/产品名** - -- Youtube: 正确念法是 "You-tube" [tju:b]，而不是 "优吐毙"，应该是 "优tiu啵"。 - -- Skype: 应该念为 [ˈskaɪp]，而不是 "死盖屁"，应该是 "死盖破"。 - -- Adobe: 正确的发音是 [əˈdəʊbi]，不是 "阿斗伯"，而是 "阿兜笔"。 - -- C#: 应该念为 "C Sharp"，即"C煞破"。 - -- GNU: 正确的发音是 [(g)nuː]， 即"哥怒"。 - -- GUI: 应该念为 [ˈɡui]，即"故意"。 - -- JAVA: 正确的发音是 [ˈdʒɑːvə]，而不是 "夹蛙"，应该是 "扎蛙"。 - -- AJAX: 应该念为 [ˈeɪdʒæks]，而不是 "阿贾克斯"，应该是 "诶(ei) 贾克斯"。 - -- Ubuntu: 正确的发音是 [uˈbuntuː]，而不是 "友邦兔"，应该是 "巫不恩兔"。 - -- Debian: 应该念为 [ˈdɛbiən]，即"得(dei)变"。 - -- Linux: 正确的发音有两种，[ˈlɪnəks] 或 [ˈlɪnʊks]，"丽娜克斯" 或 "李扭克斯"都可以。 - -- LaTeX: 正确的发音是 [ˈleɪtɛk] 或 [ˈleɪtɛx] 或 [ˈlɑːtɛx] 或 [ˈlɑːtɛk]，即"雷泰克" 或 "拉泰克"。 - -- GNOME: 念法可以是 [ɡˈnoʊm] 或 [noʊm]，即"格弄姆" 或 "弄姆"。 - -- App: 应该念为 [ˈæp]，即 "阿破"。 - -- null: 正确的发音是 [nʌl]，即"闹"。 - -- jpg: 应该念为 [ˈdʒeɪpɛɡ]，而不是 "勾屁记"，应该是 "zhei派个"。 - -- WiFi: 正确的发音是 [ˈwaɪfaɪ]，即"歪fai"。 - -- mobile: 念法可以是 [moˈbil] 或 [ˈmoˌbil] 或 [ˈməubail]，即"膜拜哦" 或 "牟bou"。 - -- integer: 正确的发音是 [ˈɪntɪdʒə]，而不是 "阴太阁儿"，应该是 "音剃摺儿"。 - -- cache: 应该念为 [kæʃ]，而不是 "卡尺"，即"喀什"。 - -- @: 应该念为 "at"。 - -- Tumblr: 应该念为 "Tumbler"，而不是 "贪不勒"。 - -- nginx: 正确的发音是 "Engine X"，应该是 "恩静 爱克斯"。 - -- Apache: 应该念为 [əˈpætʃiː]，即"阿趴气"。 - -- Lucene: 正确的发音是 [ˈluːsin]，即"鲁信"。 - -- MySQL: 应该念为 [maɪ ˌɛskjuːˈɛl] 或 [maɪ ˈsiːkwəl]，可以是 "买S奎儿" 或 "买 吸扣"。 - -- Exposé: 念法可以是 [ɛksˈpəʊzeɪ]，重音在Z上。 - -- RFID: 官方念法是四个字母分开读 "R F I D"。 - -- JSON: 应该念为 "jason"，即"zhei森"。 - -- Processing: 重音在 "Pro" 上。 - -- avatar: 正确的发音是 [ˌævə'tɑr]，即"艾瓦塌儿"。 - -## 后记 -虽然许多的词汇常常被错误发音，但在中国遵守拼音原则是入乡随俗的一种表现，且往往并没有所谓的官方读法，不必太过于纠结100%纯正的读法。 \ No newline at end of file