Jacin Blog

计算机网络

分类下的全部文章

ping 延迟、三次握手、 TLS/SSL 握手 延迟
计算机网络
6 分钟

ping 延迟、三次握手、 TLS/SSL 握手 延迟

这篇笔记围绕网络请求中的 RTT 成本展开，用 ping 返回的 time=44ms 说明它表示从发出到收到回复的完整往返时间，系统不会把结果除以二来显示单程延迟。正文先从广州到北京的光纤传播估算切入，指出即使理想直连往返约 22ms，真实链路还会受到骨干路由跳数、线路绕行以及电光转换等因素影响，因此 44ms 中包含明显的网络损耗。随后文章用时间线拆解 TCP 三次握手，强调真正阻塞客户端继续发送数据的是等待 SYN-ACK 返回的 1 个 RTT，第三次 ACK 不必等服务器收到后才进入下一阶段。对于 HTTP 请求，第三次 ACK 可以和 HTTP 数据捎带发送，因此一次未加密请求可近似理解为 TCP 建连 1 个 RTT 加请求响应 1 个 RTT。对于 HTTPS，请求在 TCP 之后还要完成 TLS/SSL 协商，TLS 1.3 通常再消耗 1 个 RTT，TLS 1.2 可能更多，所以 HTTPS 最快约为 3 个 RTT 加服务器处理时间。文章也说明四次挥手通常不计入一次请求的可感知耗时，因为业务代码拿到 response 时关键路径已经结束，断开连接多在后台完成，适合需要估算接口首包延迟、理解 TCP/TLS 建连成本的后端和网络学习者阅读。

计算机网络
3 分钟

洛杉矶机房平均 1ms 延迟，为什么？

这篇解释围绕“洛杉矶同城机房为什么能测到约 1ms Ping”展开，把低延迟拆成物理距离、互联枢纽和链路形态三个层面。正文先用光在光纤中约 20 万公里/秒、Ping 是往返时间来估算：1ms 足够覆盖约 100 公里往返，而洛杉矶核心区域之间的实际光纤传播耗时通常只占 0.1ms 到 0.3ms，剩余时间主要来自路由器处理和排队。随后文章指出，洛杉矶的很多 IDC、运营商和海底光缆接入点会汇聚到 One Wilshire 这类西海岸重要网络枢纽，所谓不同“洛杉矶机房”在网络层面可能只是隔着几层楼或几条街。它还进一步区分了 IDC 之间的暗光纤、内网直连与普通公网绕行的差异，说明低延迟并不只取决于地图上的城市大小，而取决于实际走线和交换位置。文章最后用家庭宽带访问 IDC 作对照，提到 BRAS、计费、鉴权、NAT 等运营商环节会引入额外路径和处理成本。适合网络学习者、VPS 用户和运维人员理解同城机房延迟测试结果，避免把“洛杉矶很大”直接等同于“网络一定很远”。

计算机网络
4 分钟

ICMP与TCPping整理

这份笔记围绕网络连通性排查中常见的 ICMP Ping 与 TCP Ping 做对照整理，核心区别在于前者工作在网络层，通过 Echo Request/Reply 判断主机是否响应，后者工作在传输层，需要指定 IP 和端口并尝试建立 TCP 三次握手。ICMP Ping 适合内网排障、局域网测试和快速确认主机在线状态，但它只反映 ICMP 控制报文是否可达，很多云厂商或防火墙会屏蔽 ICMP，因此容易出现 ping 不通但网站、SSH 或 HTTPS 服务实际正常的假阴性。TCP Ping 更贴近真实业务访问路径，可用 tcping、hping3 或 nmap 指定端口检测 80、443、SSH 等服务端口的可达性与延迟，在互联网服务监控和业务体验评估中更有参考价值。笔记还给出北京、上海部分电信、移动、联通的常用测试 IP，以及 zstaticcdn 面向联通、移动、电信的 80 端口 TCP Ping 目标，便于做跨运营商线路对比。读者可以借此判断排查时该先测主机响应还是直接测业务端口，避免把 ICMP 被封误判为服务故障。适合运维、后端开发、站点维护者和需要做多线路网络质量测试的用户作为速查参考。

计算机网络
15 分钟

精品网络-介绍

围绕“精品网络”的技术含义，内容先用 BGP 和自治系统解释互联网跨网络互联的基本逻辑：运营商、云厂商和数据中心通过 ASN 宣告 IP 段、选择出口、配置多线接入与 Peering，从而影响用户访问路径。文章以阿里云 AS45102、腾讯云 AS132203 接入三大运营商为例，说明云厂商并不是简单租用带宽，而是作为独立 AS 参与三网互联和智能选路。随后梳理精品网络从企业专线走向 VPS、IDC、游戏加速和节点服务的背景，并归纳其优势，包括绕开拥堵公网、降低延迟和丢包、提供 QoS 保障以及改善国际出口。运营商部分分别说明电信 CN2 GT/GIA、联通 AS9929 与移动 CMI 的定位、常见 ASN、与普通公网在线路优化、稳定性、拥塞风险和价格上的差异。最后给出 mtr 测试命令、目标地址和路径样例，提示可借助 59.43.x.x 等路由特征初步判断 CN2 GIA 类线路质量。适合准备购买 VPS 或 IDC 服务、评估跨境访问体验、排查三网回程路径的网络学习者和运维人员建立基础判断框架。

计算机网络
11 分钟

gRPC 相关介绍

这篇笔记围绕 gRPC 的组成和使用方式建立整体认知，核心说明它并不是重新发明底层网络协议，而是在 HTTP/2 之上结合 Protobuf 形成的高性能 RPC 规范。内容先拆解 HTTP/2 相比 HTTP/1.1 的差异，包括二进制帧、多路复用、HPACK 头部压缩、流式传输和更少的连接开销，并补充 Nginx 作为反向代理时可能只在客户端侧提供 HTTP/2、后端仍走 HTTP/1.1 的现实边界，以及 Uvicorn、Hypercorn 对 HTTP/2 支持的区别。随后解释 Protobuf 的定位：通过 .proto 预先定义消息结构和服务接口，将字段名替换为字段编号等紧凑二进制表示，从而在体积和序列化速度上区别于 JSON，同时也说明它与 gzip 这类通用压缩算法不是同一层面的优化。实践部分使用 grpcurl 连接 grpcb.in:9000 公开服务，演示安装工具、以 plaintext 明文方式列出服务、查看 grpcbin.GRPCBin 方法，并调用 Empty、DummyUnary 等接口。最后回到 gRPC 的本质：跨网络、跨语言调用远程服务，让 Go、Python、Java 等通过同一份 .proto 生成各自客户端和服务端代码，像调用本地函数一样传输 Protobuf 消息。适合正在理解微服务通信、RPC 框架、HTTP/2 部署边界或准备上手 gRPC 调试工具的后端开发者阅读。

计算机网络
15 分钟

CDN 是什么？

这篇笔记面向刚接触网站加速和对象存储的开发者，解释 CDN 作为内容分发网络如何把 HTML、JS、CSS、图片、视频等静态资源缓存到靠近用户的边缘节点，从而减少跨区域访问延迟、降低源站压力，并在节点故障或大流量场景下提升可用性与抗压能力。正文先用“用户请求资源、节点检查缓存、命中直接返回、未命中回源并缓存”的流程说明 CDN 的基本工作机制，再列出网站加速、App 安装包分发、直播流媒体、电商秒杀和可缓存 GET 接口等典型使用场景。随后通过 jsDelivr、腾讯云 CDN 和 Cloudflare R2 的响应头示例，拆解 cache-control、age、x-cache、x-served-by、x-cache-lookup、cf-cache-status、cf-ray、accept-ranges 等字段，帮助读者判断缓存策略、命中状态、多级节点路径、边缘节点位置以及是否支持断点续传。文章也区分了对象存储与 CDN 的职责：COS、OSS 或 R2 负责保存源数据，CDN 负责分发、缓存和加速，其中 R2 还天然接入 Cloudflare 的全球边缘网络，可通过自定义域名、Worker 或缓存规则进一步优化访问。最后落到业务系统设计，建议数据库保存原始资源路径，由后端接口、序列化器或 DTO 统一拼接 CDN 地址返回给前端，避免把源站链接、展示链接和网关响应改写耦合在一起。

计算机网络
3 分钟

点击劫持-介绍

这篇笔记围绕点击劫持的基本原理和防护响应头展开，适合正在为 Web 应用补齐基础安全配置的后端或全栈开发者阅读。文中用银行转账页面被攻击者通过透明 iframe 嵌入恶意页面的例子，说明用户可能在不知情的情况下点击到真实站点上的操作入口，从而触发非预期行为。防护重点放在两个响应头：X-Frame-Options: DENY 用于直接禁止页面被任何站点以 frame 或 iframe 方式嵌入，SAMEORIGIN 则允许同源嵌入，而 ALLOW-FROM 已不适合依赖现代浏览器支持。另一种方式是使用 CSP 中的 frame-ancestors 'none'，它同样用于限制页面作为祖先框架中的子页面出现，并且比传统 X-Frame-Options 更现代、可扩展。文章最后给出 FastAPI 中间件写法，在每次响应返回前统一添加 X-Frame-Options、Content-Security-Policy、X-Content-Type-Options 和 Referrer-Policy，分别覆盖点击劫持、iframe 限制、MIME 嗅探和 referrer 泄露等基础风险。整体价值在于把点击劫持的攻击场景与可落地的安全头配置连接起来，可作为 FastAPI 项目的最小安全响应头参考。

跨站请求-介绍
计算机网络
9 分钟

跨站请求-介绍

跨站请求指浏览器在访问一个站点时向另一个站点发起请求，安全风险集中在浏览器会自动为目标站点携带已有 Cookie，从而让恶意页面可能借隐藏表单、图片或请求触发用户已登录站点的敏感操作。文章用网银转账示例说明 CSRF 的基本链路，同时区分了它与 CORS 的边界：CORS 主要由服务端通过 Access-Control-Allow-Origin 控制跨域资源读取，而同源策略仍会阻止 A 站脚本直接访问 B 站 Cookie。内容进一步解释“允许所有 Cookie”并不等于站点间可以互读 Cookie，它更多涉及第三方 Cookie、iframe、图片或脚本加载时浏览器是否允许目标域存取自己的 Cookie。防护部分围绕 CSRF Token、SameSite、Referer 检查和 POST 身份验证展开，重点说明 SameSite=Strict、Lax、None 对跨站请求携带 Cookie 的不同约束。对于传统 Cookie 登录，Strict 或 Lax 能降低 CSRF 风险；但前后端分离且依赖 Cookie 登录时，可能需要 SameSite=None; Secure，而使用 Authorization Header 或 JWT 的方案则基本不受 SameSite 影响。最后补充 secure=True 或 https_only=True 的含义：浏览器只会在 HTTPS 请求中发送该 Cookie，这能减少中间人窃听风险，但会影响本地 HTTP 测试环境和登录态调试。

计算机网络
10 分钟

CORS与OPTIONS请求

这篇笔记聚焦浏览器跨域访问中的 CORS 判断与 OPTIONS 预检机制，核心澄清“跨域失败”并不是后端主动拦截响应，而是浏览器在安全策略下根据响应头决定是否把结果交给前端 JS。内容从 Access-Control-Allow-Origin 的作用讲起，说明后端必须在响应中明确允许来源，否则即使接口返回 200 或 404，浏览器也会阻止脚本读取内容。对于带 Authorization、自定义 Header、application/json 或 PUT、PATCH、DELETE 等复杂请求，浏览器会先发送 OPTIONS 预检，并通过 Origin、Access-Control-Request-Method、Access-Control-Request-Headers 询问后端是否允许后续真实请求。文章重点记录了 FastAPI CORSMiddleware 的排查细节：只有请求携带 Origin 头时，中间件才会识别并提前处理跨域 OPTIONS；如果 curl、Apifox 等工具模拟预检时漏掉 Origin，请求会落到路由层，未注册 OPTIONS 方法时就可能返回 405。相应的解决路径是用带 Origin 和 Access-Control-Request-Method 的请求复现浏览器行为，并检查 allow_origins、allow_methods、allow_headers 等配置是否能返回 Access-Control-Allow-* 头。它适合后端开发、前端联调人员和接口排查人员，用来区分浏览器 CORS 拦截、后端路由 405、以及测试工具模拟不完整这几类容易混淆的问题。

计算机网络
10 分钟

5G-A技术

这篇笔记从 iOS 18.4 中出现的 5G-A 标识出发，解释 5G-Advanced 作为 3GPP Release 18 定义的 5G 演进标准，定位在现有 5G 与未来 6G 之间的过渡阶段。正文把 5G-A 的增强点概括为更高速率、更低时延、更高连接密度，以及引入 AI/ML 进行网络资源管理和优化，并提到 NTN 卫星与地面网络融合、XR、自动驾驶和工业自动化等新场景。文章进一步按应用场景展开，说明 5G-A 在智能制造的精密控制、车联网实时通信、8K VR/AR 和全息体验、智慧城市多设备协同、偏远地区覆盖等方向的潜在价值，同时强调很多应用仍处在试点或早期部署阶段。部署现状部分列举了北京四环内及行政副中心覆盖、杭州商用网络启动，以及上海、深圳、广州等城市的试点或预期推进情况，帮助读者理解手机显示 5G-A 与实际网络建设之间的关系。为便于对比，文章还补充了 5G 的 eMBB、URLLC、mMTC、毫米波、大规模 MIMO、小基站和网络切片等基础概念，并用表格区分 5G 与 5G-A 在速率、时延、能效、连接密度和成熟度上的差异。最后，针对 iPhone 信号满格但网速慢的问题，正文说明信号格主要反映 RSRP、SINR 等接收质量，不等同于网速，实际体验还会受到频段、网络拥堵、基站距离、遮挡和干扰路径影响，适合想快速理解 5G-A 标识、网络能力与现实体验差距的移动网络用户和技术学习者。