Dai Wei

应用层是离业务最近的一层，协议数量也最多。与其逐个死记端口和缩写，不如按”每个协议解决什么问题”来组织记忆，再抓住 HTTP 这一个最常用协议的方法语义与状态管理机制深入下去。 它解决什么问题传输层（TCP/UDP）只负责把字节可靠或尽力地送到对端进程，但”送过去的字节是什么意思、双方按什么顺序对话”得由应用自己约定。应用层协议就是这些约定的成文标准：浏览器和服务器靠 HTTP 对话，发邮件靠 SMTP，域名翻译靠 DNS。标准化的价值在于——Chrome 不需要知道对面跑的是 Nginx 还是 Tomcat，只要双方都按 RFC 说话就能互通。下面按问题域逐一展开。 核心原理：每个协议管哪件事网页与接口：HTTP/HTTPSHTTP 解决”客户端如何从服务器获取和提交资源”的问题，采用请求-响应模型：客户端发一个请求，服务器回一个响应。它基于 TCP（HTTP/3 改为基于 UDP 的 QUIC），默认端口 80。HTTP 本身是明文且无状态的——服务器天生不记得上一次请求是谁发的。HTTPS 不是新协议，而是 HTTP over TLS：报文...

TCP 连接的一生从三次握手开始，以四次挥手落幕。握手要解决的从来不是”交换几个包”，而是同步双方的初始序列号、确认双向收发能力；挥手则是因为全双工连接的两个方向必须各自独立关闭。本文按报文级视角逐步拆解这两个过程。 它解决什么问题IP 网络只承诺尽力投递：报文可能丢失、重复、乱序，也可能在网络里滞留很久才送达。TCP 要在这样的地基上提供可靠有序的字节流，建立连接前必须先解决两件事： 起点对齐：可靠性靠序列号给每个字节编号，双方必须对”从哪个序号开始计数”达成一致，否则接收方无法分辨收到的是新数据还是历史残留报文。 能力互验：连接是全双工的，建立前需要确认”我能发、对方能收”在两个方向上都成立，而不是只验通一个方向。 关闭连接时问题反过来：一个方向的”我发完了”不代表另一个方向也没话可说，所以两个方向要分别关闭、分别确认。握手三次、挥手四次，就是为这两组问题设计的最小动作集。 核心原理三次握手：同步序列号，确认双向可达Client Server | ---------- SYN seq=x --...

本篇是计算机网络专题的学习地图：把模块内的文章按主题分组，标清彼此依赖与推荐学习顺序，帮助你先搭框架、再填细节，避免只见树木不见森林。 主题分组总览与分层基础 网络面试题（上）（下）：高频问题清单，先知道考什么，带着问题学。 OSI 与 TCP/IP 分层模型：理解每层的职责划分与数据封装过程，是一切的地基。 输入 URL 到页面展示全过程：用一次真实请求把 DNS、TCP、TLS、HTTP 串成完整链路。 应用层 应用层协议总结：HTTP、WebSocket、SMTP、FTP、SSH、DNS 一锅端，建立协议全景。 HTTP vs HTTPS、RSA vs ECDHE：加密、证书、前向安全三件事讲清。 HTTP/1.0 vs 1.1、常见状态码：长连接、缓存策略与响应语义。 DNS 详解：递归与迭代、缓存层级与 TTL。 HTTP vs RPC：厘清两者的层次关系与选型边界。 传输层 三次握手与四次挥手：连接状态机，面试重灾区。 TCP 可靠性保障：序号、确认、重传、流量控制与拥塞控制的协作。 TIME_WAIT 详解：为什么等 2MSL、堆积如何排...

不是。65535 只是端口号的取值上限（16 位字段），而 TCP 连接靠四元组区分，不是靠本地端口单独标识。服务端的连接数上限取决于机器资源，理论上远超 65535；真正容易撞到端口天花板的，是高频短连接的客户端。 问题的本质：四元组而非端口一条 TCP 连接由四元组唯一标识： 源 IP、源端口、目的 IP、目的端口 假设服务器监听 192.168.1.100:8080，以下三条连接服务端 IP 和端口完全相同，但仍是三条独立连接： (10.0.0.1, 50000, 192.168.1.100, 8080)(10.0.0.1, 50001, 192.168.1.100, 8080)(10.0.0.2, 50000, 192.168.1.100, 8080) 服务端只有一个监听 socket，但每次 accept() 内核都生成一个新的已连接 socket，按四元组区分，多个连接共享同一端口毫无冲突。纯从组合空间算：固定服务端 IP 与端口后，客户端 IP 有约 2^32 种、客户端端口有 2^16 种变化，理论上限是天文数字。 实际瓶颈在哪里理论归理论，机器资源先顶不...

HTTP 状态码是服务器给客户端的处理结果摘要：首位数字定类别，看到它就能大致判断请求是成功、要跳转、客户端的错还是服务端的错。难点不在记忆数字，而在几组语义相近的码之间划清边界——这正是面试和线上排查最常考的地方。 五类状态码的语义边界 1xx 信息性：请求已收到，继续处理。日常几乎遇不到，较有用的是 100 Continue——客户端先发个 Expect: 100-continue 试探，服务器同意后再传大请求体，避免白传。 2xx 成功：请求被正确处理。200 OK 是最常见的”成功并返回内容”；201 Created 表示成功且创建了新资源（POST 建单）；202 Accepted 只表示”受理了但还没处理完”，适合异步任务；204 No Content 表示成功但无响应体（如删除接口）。 3xx 重定向：资源在别处，客户端需要进一步动作。除 301/302 外，304 Not Modified 最常用——协商缓存命中，让客户端直接用本地副本。 4xx 客户端错误：问题出在请求方。改请求再试，而不是怪服务器。 5xx 服务端错误：请求本身合法，但服务端没能...

计算机基础不是需要一次背完的题库，而是理解软件运行边界的四组模型：网络解释数据如何跨主机传递，操作系统解释程序如何使用硬件，数据结构决定信息如何组织，算法则决定计算如何推进。 四条主线如何衔接学习网络时，先建立分层视角，再追踪一次请求经历的 DNS、TCP、TLS 和 HTTP。重点不只是记协议字段，而是能解释超时、重传、连接复用与拥塞控制如何影响接口延迟。抓包分析比单纯背诵更容易形成可靠理解。 操作系统部分应围绕资源抽象展开：进程和线程对应执行与隔离，虚拟内存连接地址空间与物理内存，文件系统组织持久化数据，I/O 多路复用解决大量连接的等待问题。学习每个机制时，都应追问它解决了什么竞争或成本，以及应用程序能观察到哪些现象。 数据结构与算法最好结合学习。数组、链表、哈希表、树和图提供不同的访问与更新能力；二分、搜索、回溯、动态规划和贪心则在这些结构上探索答案。复杂度分析用于估算增长趋势，但工程选择还要考虑缓存局部性、常数成本、数据规模和可维护性。 推荐练习方式每个主题采用“模型—实验—复盘”三步。先画出关键组件与状态变化，再用最小实验验证，例如用 curl 和抓包观...

Java 基础面试的「下篇」覆盖异常体系、反射与动态代理、序列化、I/O 模型四条主线。这组题横跨语言机制与框架底层，想答出深度，需要把「编译器和 JVM 在背后做了什么」讲清楚，而不是停留在概念背诵。 考察地图 异常体系：Exception 与 Error 的分工、Checked 与 Unchecked 之争、finally 的执行时机、try-with-resources。考察的是对「程序出错路径」的设计判断。 反射与动态代理：反射的能力与代价、JDK 与 CGLIB 两条代理路线。考察对 Spring 等框架底层的理解。 序列化：transient 的语义、JDK 原生序列化被弃用的原因。考察网络传输与持久化的工程常识。 I/O：字节流与字符流的分工、BIO/NIO/AIO 的演进。考察对操作系统 I/O 模型的认知。 建议自行查阅：泛型类、泛型接口、泛型方法三种声明方式，注解的编译期与运行期两种解析时机，SPI 与 API 的区别，Throwable 常用方法清单，常见语法糖盘点——这些偏纯记忆或框架使用层面，面试中多...

Java 基础面试的「中篇」围绕三条主线展开：面向对象的设计契约、Object 奠定的相等性规则、String 的不可变性与常量池机制。这组题看似基础，却最容易在原理细节上翻车。 考察地图 面向对象：接口与抽象类的区别、深拷贝与浅拷贝。考察的是抽象设计能力，而非背定义。 Object 与相等性：== 与 equals、hashCode 的作用、equals/hashCode 契约。考察对散列容器底层逻辑的理解。 String：三兄弟选型、不可变性的根因、+ 拼接的编译期行为、常量池与 intern。考察对 JVM 内存与编译器优化的掌握。 建议自行查阅：构造方法能否被重写、Object 类常见方法清单、String#equals 与 Object#equals 的差异——这些是纯记忆题，面试中多作为铺垫而非考点本身。 面向对象接口和抽象类有什么共同点和区别？结论：共同点是都不能实例化、都能声明抽象方法；区别在设计意图上——接口约束「能做什么」（行为规范），抽象类表达「是什么」（is-a 的代码复用）。 原理：从语言机制看，一个类只能继承一个父类，但可实现多个接口；...

「Java 到底是值传递还是引用传递」是一个被争论了二十多年的问题。结论可以一句话说完：Java 只有值传递（pass by value）——基本类型传的是值的拷贝，引用类型传的也是拷贝，只不过拷贝的内容是「引用的值」而非对象本体。这篇文章用三组实验把这个结论钉死。 它解决什么问题很多 bug 的根源不是语法，而是对参数传递机制的错误心智模型。比如期望一个方法把传入的对象「换掉」、以为方法内对形参重新赋值能影响调用方、或者看到方法改了对象字段就断言「Java 是引用传递」。这些困惑都指向同一个问题：方法调用那一刻，实参到形参之间到底发生了什么？ 先把两个术语固定下来。**实参（argument）**是调用处实际传入的值，**形参（parameter）**是方法声明中用来接收的那个变量。传参的本质操作只有一步：把实参的值绑定到形参变量上。分歧不在这步操作，而在「绑定的是什么」。 核心原理：三种求值策略编程语言理论中，参数传递的求值策略（evaluation strategy）主要有三种： 传值调用（call by value）：形参得到实参值的副本。方法内对形参的任何修改，都...

sun.misc.Unsafe 是 JDK 的内部类，提供直接内存操作、CAS 原子指令、按偏移量读写字段、线程 park/unpark 等接近 C 指针的低层能力。它是 JUC 并发包和 Netty 高性能的地基，也因绕过 Java 安全模型而被冠以「不安全」之名，如今正被 VarHandle 与 FFM API 逐步取代。 它解决什么问题Java 的安全模型划了几条硬边界：内存由 JVM 分配回收，程序员不能碰裸指针；字段访问要过访问权限检查；线程调度依赖 synchronized 和 Object.wait/notify；任何对象创建必须经过构造器。这些边界保证了安全，却也挡住了高性能基础设施的路： 堆内内存归 GC 管，大缓存、高吞吐 IO 场景下 GC 停顿和堆内外数据拷贝都是负担，需要堆外内存； 无锁并发需要硬件原子指令，Java 语言层面没有暴露比较并交换（Compare And Swap，CAS）能力； AQS 这类同步器需要精确的「挂起/唤醒某个线程」原语，wait/notify 的语义满足不了。 Unsafe 就是这些能力...