引言：面试时，你是否会遇到这个经典问题：从输入 URL 到页面展示，到底发生了什么？

这道题几乎是计算机网络面试的必考题，一道题就能考察你对DNS 域名解析、TCP/IP 协议、HTTP/HTTPS、网络层、应用层等整个网络体系的理解。

总体来说，整个过程可以分为这几个关键步骤：

  1. 在浏览器中输入指定网页的 URL。

  2. 浏览器通过 DNS 协议，获取域名对应的 IP 地址。

  3. 浏览器根据 IP 地址和端口号，向目标服务器发起一个 TCP 连接请求。

  4. 浏览器在 TCP 连接上，向服务器发送一个 HTTP 请求报文，请求获取网页的内容。

  5. 服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。

  6. 浏览器接收响应报文，解析 HTML、CSS、JS，进行页面渲染；同时根据页面中的图片、样式、脚本等资源 URL，继续发起请求，直到页面完整显示。

  7. 浏览器在不需要和服务器通信时，可以主动关闭 TCP 连接，或者等待服务器的关闭请求。

下面，我将带你一步一步学习下面的相关技术 ⭐

网络模型

OSI 七层模型

为了使得多种设备能通过网络相互通信，和为了解决各种不同设备在网络互联中的兼容性问题，国际标准化组织制定了开放式系统互联通信参考模型，也就是 OSI 网络模型，该模型主要有 7 层，分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物

每一层负责的职能都不同，如下：

  • 应用层：负责为各类应用程序提供统一的网络服务接口。

  • 表示层：负责把数据转换成兼容另一个系统能识别的格式，包括加密、压缩等。

  • 会话层：负责建立、管理和终止表示层实体之间的通信会话。

  • 传输层：负责端到端的数据传输任务（端：端口 / 进程）。

  • 网络层：负责主导数据的路由与转发工作，通过 IP 地址进行逻辑寻址。

  • 数据链路层：负责数据的封帧和差错检测，以及 MAC 寻址。

  • 物理层：负责在物理网络中传输比特流，定义电气、机械等接口标准。

由于 OSI 模型实在太复杂，提出的也只是概念理论上的分层，并没有提供具体的实现方案。

事实上，我们比较常见，也比较实用的是四层模型，即 TCP/IP 网络模型，Linux 系统正是按照这套网络模型来实现网络协议栈的。

TCP/IP 四层模型

TCP/IP协议被组织成四个概念层，其中有三层对应于ISO参考模型中的相应层。TCP/IP协议族并不包含物理层和数据链路层，因此它不能独立完成整个计算机网络系统的功能，必须与许多其他的协议协同工作。TCP/IP 网络通常是由上到下分成 4 层，分别是应用层，传输层，网络层和网络接口层。

  • 应用层：为各类网络应用提供统一通信服务接口，让应用程序不用关心底层的网络传输细节。

  • 传输层：实现两台主机上应用程序的 "端到端" 通信，提供通用的数据传输服务

  • 网络层：负责主导数据包的跨网络路由与转发工作，通过 IP 地址实现主机级寻址（IP 协议）

  • 网络接口层：负责数据的封帧、MAC 寻址与差错检测，以及在物理介质中传输比特流

应用层

DNS（域名系统）

一、DNS 是什么？

DNS（域名系统），就是把域名转换成对应的 IP 地址的协议。你可以把它理解成：网络的电话本。我们记不住每台服务器的 IP 地址，就像记不住所有人的电话号码，只需要记住名字，DNS 帮我们查到对应的地址，才能找到目标服务器。

二、为什么要用 DNS？

  1. 方便用户记忆：人们更容易记住 www.baidu.com，很难记住一串数字 IP。

  2. 屏蔽底层复杂地址：让用户用域名访问，不用关心真实 IP 是什么。

  3. 支持服务器切换和迁移：域名不变，背后 IP 可以更换，用户无感知。

  4. 实现负载均衡：同一个域名可以解析到多个 IP，让流量分到多台服务器。

三、DNS 的核心原理

当你在浏览器输入一个域名时：

  1. 你的电脑先查本地缓存，有没有记住这个域名对应的 IP。

  2. 如果没有，就去问本地 DNS 服务器（比如运营商提供的 DNS）。

  3. 本地 DNS 没有的话，会逐级去问根服务器、顶级域名服务器、权威 DNS 服务器。

  4. 最终查到 IP 地址，返回给你的电脑。

  5. 你的电脑拿到 IP，才真正开始和服务器通信。

四、DNS 的典型工作过程（举例）

  1. 你打开浏览器，输入 www.baidu.com。

  2. 你的电脑发现不知道 IP，发送 DNS 查询请求。

  3. DNS 服务器查询后，返回 IP：110.242.68.3。

  4. 你的电脑拿到 IP，开始连接百度服务器。

  5. 网页加载出来，整个过程你完全不用关心 IP 是多少。

一句话总结：DNS 是网络的 "电话本"，负责把好记的域名翻译成机器能识别的 IP 地址，是我们上网访问网站最基础的服务。

本地域名服务器

  1. 减轻根服务器压力：如果没有本地域名服务器，全球几十亿用户的每一次 DNS 查询都要直接访问根服务器，会让根服务器不堪重负，甚至 "冒烟" 瘫痪。本地域名服务器承担了大部分查询任务，极大减轻了根服务器和顶级域名服务器的压力，保证了整个 DNS 系统的稳定运行。

  2. 提升查询速度：本地域名服务器就像一个 "家门口的缓存电话本"，它会把近期查询过的域名和对应 IP 地址缓存起来。当你再次访问同一个网站时，主机直接向本地域名服务器查询，就能快速得到结果，不用再去根服务器兜一圈，大大提升了上网速度。

  3. 降低网络流量：本地域名服务器还能降低网络流量消耗，让大部分查询在局域网或运营商网络内部完成，减少了跨网传输的带宽压力，让整个互联网的运行更高效、更流畅。

DNS的底层协议

DNS 基于UDP协议实现，DNS使用UDP协议进行域名解析和数据传输。因为基于UDP实现DNS能够提供低延迟、简单快速、轻量级的特性，更适合DNS这种需要快速响应的域名解析服务。

  • 低延迟： UDP是一种无连接的协议，不需要在数据传输前建立连接，因此可以减少传输时延，适合DNS这种需要快速响应的应用场景。

  • 简单快速： UDP相比于TCP更简单，没有TCP的连接管理和流量控制机制，传输效率更高，适合DNS这种需要快速传输数据的场景。

  • 轻量级：UDP头部较小，占用较少的网络资源，对于小型请求和响应来说更加轻量级，适合DNS这种频繁且短小的数据交换。

尽管 UDP 存在丢包和数据包损坏的风险，但在 DNS 的设计中，这些风险是可以被容忍的。DNS 使用了一些机制来提高可靠性，例如查询超时重传、请求重试、缓存等，以确保数据传输的可靠性和正确性。

HTTP

HTTP报文

HTTP报文包含请求报文和响应报文。

请求报文：

  • 请求行：包含请求方法、请求目标（URL或URI）和HTTP协议版本。

  • 请求头：包含关于请求的附加信息，如Host、User-Agent、Content-Type（application/json）等。

  • 空行：请求头部和请求体之间用空行分隔。

  • 请求体：可选，包含请求的数据，通常用于POST请求等需要传输数据的情况。

响应报文：

  • 状态行：包含HTTP协议版本、状态码和状态信息。

  • 响应头部：包含关于响应的附加信息，如Content-Type、Content-Length等。

  • 空行：响应头部和响应体之间用空行分隔。

  • 响应体：包含响应的数据，通常是服务器返回的HTML、JSON等内容。

HTTP状态码

HTTP 状态码分为 5 大类

  • 1xx ：协议中间提示信息，实际较少使用。

  • 2xx ：服务器成功处理客户端的请求。

  • 3xx ：客户端请求的资源发生变动，需重新定向访问。

  • 4xx ：客户端发送的请求报文有误，服务器无法处理。

  • 5xx ：客户端请求报文正确，但服务器内部出现错误。

其中常见的具体状态码有：

  • 200 OK：请求成功，服务器正常处理并返回数据。

  • 301 Moved Permanently：永久重定向（资源永久迁移，浏览器会记住新地址）

  • 302 Found：临时重定向（资源临时迁移，本次跳转不永久记录）

  • 400 Bad Request：客户端发送的请求报文格式或参数有误，导致服务器无法解析。

  • 404 Not Found：请求资源不存在，服务器无法找到对应内容。

  • 405 Method Not Allowed：请求方法不被支持（你用的GET方法，服务器端的目标接口是POST，不支持）

  • 500 Internal Server Error：服务器内部出错（服务器正常接收请求，但处理时出现错误）。

HTTP的301与302状态码

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

  • 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

  • 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

HTTP层常见的请求类型

  • GET：用于请求获取指定资源，通常用于获取数据。

  • POST：用于向服务器提交数据，通常用于提交表单数据或进行资源的创建。

  • PUT：用于向服务器更新指定资源，通常用于更新已存在的资源。

  • DELETE：用于请求服务器删除指定资源。

  • HEAD：类似于GET请求，但只返回资源的头部信息，用于获取资源的元数据而不获取实际内容。

HTTP中GET和POST请求

根据 RFC 规范，GET 的语义是从服务器获取指定的资源，这个资源可以是静态的文本、页面、图片视频等。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符 ，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。

比如，你打开博客文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源。

根据 RFC 规范，POST 的语义是根据请求负荷（报文 body）向指定资源提交数据，让服务器对该资源做出处理，具体的处理方式视资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中，body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制。

比如，你在我文章底部，敲入了留言后点击「提交」，浏览器就会执行一次 POST 请求，把你的留言文字放进了报文 body 里，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器。

如果从 RFC 规范定义的语义来看：

  • GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。因此，浏览器通常可以对 GET 请求的数据进行缓存处理。

  • POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。因此，浏览器一般不会缓存 POST 请求。

但是实际过程中，开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如：

  • 可以用 GET 方法实现新增或删除数据的请求，这样实现的 GET 方法自然就不是安全和幂等。

  • 可以用 POST 方法实现查询数据的请求，这样实现的 POST 方法自然就是安全和幂等。

HTTP的长连接和短连接

HTTP 协议采用「请求 - 应答」模式，客户端发起请求，服务端返回响应。

HTTP 基于 TCP 传输协议实现，客户端与服务端通信前需先建立 TCP 连接，客户端发送 HTTP 请求后，服务端收到请求并返回响应，完成一次「请求 - 应答」流程，随后释放 TCP 连接。

每次请求都经历建立 TCP 连接、请求资源、响应资源、释放连接的过程，即为 HTTP 短连接。

因此，HTTP 的 Keep-Alive 特性支持使用同一个 TCP 连接发送和接收多个 HTTP 请求与应答，避免重复建立和释放连接的开销，这种方式称为 HTTP 长连接。

HTTP 长连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

HTTP默认的端口

http 是 80，https 默认是 443。

HTTP请求拆包

在 HTTP/1.1 中，请求的拆包机制基于 Content-Length 头字段实现，具体流程和逻辑如下：

  1. 客户端发送请求时，携带 Content-Length 头字段：当客户端需要向服务端传输包含正文的请求时，会在请求头中添加 Content-Length 字段，该字段的值明确表示请求正文的字节数。

  2. 服务端接收请求，解析 Content-Length 字段服务端接收到请求后，首先解析请求头中的 Content-Length 字段，获取请求正文的总字节长度。

  3. 服务端按字节长度读取正文，完成拆包服务端根据 Content-Length 指示的字节数，从请求数据流中读取对应长度的内容，以此确定请求正文的边界。当读取的字节数达到 Content-Length 声明的值时，服务端判定请求正文已完整接收，完成请求拆包。

  4. 机制作用这种基于 Content-Length 的拆包方式，能确保服务端准确识别请求的完整范围，避免因数据流粘连导致的请求截断或解析错误问题。

HTTP 断点续传

HTTP 断点续传是下载文件时如果中途中断，不用重新从头下载，而是从断开的那个断点位置继续下载的功能。它的核心是基于 HTTP/1.1 的 Range 范围请求机制，专门解决大文件下载中断后重复下载的痛点。

它依靠 HTTP/1.1 的Range 范围请求实现，具体流程如下：

  1. 服务端先声明支持断点续传

客户端开始下载时，服务端在响应头返回 Accept-Ranges: bytes，表示支持按字节范围传输文件。

  1. 下载中断时，客户端记录断点位置

例：文件总大小 1024KB，下载到 512KB 时断网，客户端会记住当前位置：512000 字节。

  1. 重新联网后，客户端指定从断点开始请求

客户端在请求头带上 Range: bytes=512000-，告诉服务端从 512000 字节处开始传输剩余内容。

  1. 服务端按范围返回数据，并返回对应状态码

      服务端从指定位置读取文件，在响应头返回：

    1. Content-Range: bytes 512000-/1024000（本次范围和文件总大小）

    2. Content-Length: 512000（本次传输的内容长度），同时返回 206 Partial Content，表示是部分内容。

  2. 范围无效时的异常处理

若客户端请求的范围超文件大小，服务端返回 416 Requested Range Not Satisfiable，表示无法满足该范围请求。

HTTP的不安全性

HTTP 之所以不安全，核心原因是其数据传输过程是明文的，没有加密保护。

我们可以用通俗的方式拆解它的不安全之处：

  1. 数据容易被窃听

HTTP 传输的所有数据（比如你输入的账号密码、浏览的网页内容、提交的表单信息）都是「明文」状态。如果你的网络环境不安全（比如连了公共 Wi-Fi），黑客可以通过抓包工具轻松获取这些数据，直接看到里面的内容。

举个例子：你用 HTTP 登录某网站，输入的用户名 user123 和密码 123456 会直接以明文形式在网络上传输，黑客抓到这个数据包后，就能直接拿到你的账号密码。

  1. 数据容易被篡改

因为没有加密和校验机制，黑客不仅能窃听数据，还能修改数据内容后再发送给目标服务器。

举个例子：你用 HTTP 下单买一个价格为 99 元 的商品，黑客抓包后把价格改成 9.9 元，再发送给商家服务器。如果服务器没有额外校验，就可能按 9.9 元 完成交易。

  1. 无法验证通信方的身份

HTTP 没有身份验证机制，你无法确认自己访问的服务器是不是真正的网站。

举个例子：黑客可以搭建一个和某银行官网一模一样的假网站，并让你的设备访问这个假网站。因为 HTTP 无法验证服务器身份，你输入的银行账号密码会直接发送给黑客的假服务器，导致信息泄露。

补充：怎么解决 HTTP 的不安全问题？

对应的解决方案就是 HTTPS，它相当于给 HTTP 加了一层「加密外衣」：

  • HTTPS 会用 SSL/TLS 协议对传输的数据进行加密，数据在网络上传输时是「密文」状态，黑客即使抓到数据包，也无法看懂内容。

  • HTTPS 有身份验证机制（通过数字证书），可以确认你访问的服务器是真实合法的，避免被钓鱼网站欺骗。

简单总结：HTTP 是明文传输，HTTPS 是加密传输。

HTTP和HTTPS 的区别

HTTP（超文本传输协议）和 HTTPS（超文本传输安全协议）的核心区别是 HTTPS 在 HTTP 基础上增加了 SSL/TLS 加密层，解决了 HTTP 明文传输的安全隐患，两者的详细区别可以从以下 4 个维度清晰梳理：

1. 传输安全性（核心区别）

  • HTTP：

    • 传输内容为明文，没有加密机制，数据在网络中传输时，任何中间节点（如路由器、黑客抓包工具）都能直接读取、篡改数据。

    • 无身份验证和数据完整性校验，无法确认通信方是否为真实目标，也无法判断数据是否被篡改。

    • 典型风险：公共 Wi-Fi 下登录账号，密码可能被直接窃取。

  • HTTPS：

    • 在 TCP 和 HTTP 之间加入了 SSL/TLS 协议层，对传输的报文进行对称加密（传输阶段高效加密）+ 非对称加密（协商加密密钥），数据以密文形式传输，即使被抓包也无法直接解读。

    • 具备身份验证（通过数字证书确认服务器身份）和数据完整性校验（通过哈希算法防止数据被篡改）。

    • 典型优势：网银、电商平台等涉及敏感信息的场景，必须使用 HTTPS 保障安全。

2. 连接建立流程

HTTP流程简单，仅需 TCP 三次握手：

  1. 客户端向服务端发起 TCP 连接请求；

  2. 服务端响应请求，确认连接；

  3. 客户端再次确认，TCP 连接建立；

  4. 直接开始 HTTP 报文传输。

HTTPS流程多了 SSL/TLS 握手阶段，整体为 TCP 三次握手 + SSL/TLS 握手：

  1. 先完成 TCP 三次握手，建立基础连接；

  2. 客户端向服务端请求数字证书，验证服务端身份；

  3. 双方协商加密算法和会话密钥；

  4. 确认加密参数，SSL/TLS 连接建立；

  5. 基于密钥进行加密的 HTTP 报文传输。

3. 默认端口号

HTTP：默认端口为 80。

HTTPS：默认端口为 443。

4. 证书要求

HTTP：无需任何证书，只要服务端开放 80 端口，就能提供 HTTP 服务，无门槛。

HTTPS：必须配置 CA 颁发的数字证书：证书用于证明服务器的合法性，防止钓鱼网站；若使用自签名证书（非 CA 颁发），客户端访问时会弹出安全警告，提示证书不可信。

HTTPS防范中间人攻击

主要通过加密和身份校验机制来防范中间人攻击的:

  • 加密：https 握手期间会通过非对称加密的方式来协商出对称加密密钥。（防止中间人破解加密内容）

  • 身份校验：服务器会向证书颁发机构申请数字证书，证书中包含了服务器的公钥和其他相关信息。当客户端与服务器建立连接时，服务器会将证书发送给客户端。客户端会验证证书的合法性，包括检查证书的有效期、颁发机构的信任等。如果验证通过，客户端会使用证书中的公钥来加密通信数据，并将加密后的数据发送给服务器，然后由服务端用私钥解密。（防止中间人冒充身份）

中间人攻击的关键在于攻击者冒充服务器与客户端建立连接，并同时与服务器建立连接。

但由于攻击者无法获得服务器的私钥，因此无法正确解密客户端发送的加密数据。同时，客户端会在建立连接时验证服务器的证书，如果证书验证失败或存在问题，客户端会发出警告或中止连接。

HTTP1.1和2.0的区别

HTTP/2 相比 HTTP/1.1 的核心区别，集中在性能优化层面，具体改进可分为以下 4 个核心维度，内容完全基于你给出的要点梳理：

1. 头部压缩：消除头信息冗余，降低传输体积

HTTP/2 会对请求头（Header）进行压缩。当同时发送多个请求，且请求头相同或相似时，协议会自动消除重复的头部内容，减少数据传输量。

2. 二进制帧格式：提升解析效率，消除文本解析开销

HTTP/1.1 的报文是纯文本格式，计算机需要先将文本转换成二进制才能解析，存在额外的转换开销。HTTP/2 则将所有传输内容（头信息 + 数据体）统一封装为二进制帧，无需文本转二进制的步骤，大幅提升传输和解析效率。

3. 基于 Stream 的并发传输：解决队头阻塞问题

HTTP/1.1 存在队头阻塞缺陷：同一 TCP 连接中，多个请求需要按顺序排队处理，前一个请求如果阻塞（如响应慢），后续所有请求都会被卡住。HTTP/2 引入 Stream（流） 的概念，一条 TCP 连接可以同时承载多个 Stream，每个 Stream 对应一个独立的请求 / 响应，实现单连接多并发。

4. 服务端主动推送：优化资源加载流程

HTTP/1.1 遵循请求 - 应答的被动模式，只有客户端发起请求，服务端才会响应数据。HTTP/2 支持服务端主动推送：服务端可以预判客户端的资源需求（比如客户端请求一个 HTML 页面时，服务端可以主动推送页面依赖的 CSS文件）；无需等待客户端的后续请求，提前将资源推送到客户端；减少客户端的请求次数，优化页面加载速度。

HTTP、WebSocket 和 SSE

SSE、HTTP、WebSocket 均是 Web 开发中用于客户端与服务器通信的核心技术，三者的相同点与不同点围绕通信方向、连接特性、使用场景展开，具体梳理如下：

HTTP（超文本传输协议）

核心定位：基于 TCP 的应用层协议，是 Web 通信的基础标准。

通信方向：单向通信—— 只能由客户端主动发起请求，服务器被动响应，响应完成后连接立即断开（HTTP/1.1 默认开启 Keep-Alive 可复用连接，但通信模式仍是「请求 - 响应」）。

连接特性：无状态（服务器不保留客户端的通信状态）、短连接（默认），每次请求都需要携带完整的请求头，存在一定的开销。

使用方式：客户端通过 GET/POST 等方法发起请求，服务器返回状态码和数据；浏览器原生支持，无需额外依赖。

典型场景：前端获取页面资源、普通接口调用（如查询商品列表、用户登录）、文件上传下载。

举例：你在浏览器输入网址访问首页时

  1. 客户端（浏览器）发送 HTTP GET 请求，携带请求头信息；

  2. 服务器接收到请求后，返回 HTML 页面数据和 200 状态码；

  3. 响应完成后，连接关闭；后续你点击页面按钮查询数据，会再次发起新的 HTTP 请求。

WebSocket（全双工通信协议）

核心定位：基于 TCP 的全双工通信协议，专为解决 HTTP 单向通信的痛点设计。

通信方向：全双工通信—— 客户端和服务器建立连接后，双方可同时双向发送数据，无需等待对方的请求或响应。

连接特性：长连接—— 连接建立后会持续保持，直到主动断开；握手阶段基于 HTTP 协议（发送 Upgrade: websocket 请求头），握手成功后切换为 WebSocket 协议，数据帧格式更轻量，开销低于 HTTP。

使用方式：客户端通过 new WebSocket() 建立连接，服务器需要部署 WebSocket 服务（如 Spring WebSocket、Node.js 的 ws 库）；连接成功后，双方通过 send() 发送数据，onmessage 监听接收数据。

典型场景：实时聊天、实时弹幕、股票行情推送、协同编辑（多人同时修改文档）。

举例：你使用在线聊天工具时

  1. 客户端发起 WebSocket 握手请求，服务器响应后建立长连接；

  2. 你发送一条消息，客户端通过 WebSocket 直接将数据推送给服务器，服务器无需等待请求即可接收；

  3. 服务器收到消息后，可立即推送给其他在线用户，其他用户的客户端通过 onmessage 实时接收消息，全程无需重复发起请求。

SSE（Server-Sent Events，服务器推送事件）

核心定位：基于 HTTP 的服务器向客户端单向推送技术，属于 HTTP 协议的扩展。

通信方向：服务器单向推送—— 客户端发起一次 HTTP 请求后，连接保持长开，服务器可以持续向客户端推送数据，客户端只能接收，无法主动向服务器发送数据（若需客户端发数据，需额外发起 HTTP 请求）。

连接特性：长连接、轻量级，数据以「事件流」的形式传输，支持自动重连（浏览器原生实现，断开后会自动发起新请求）；数据格式为文本（默认 UTF-8），不支持二进制数据（WebSocket 支持）。

使用方式：客户端通过 new EventSource() 建立连接，监听 onmessage 事件接收数据；服务器设置响应头 Content-Type: text/event-stream，并持续输出事件数据。

典型场景：服务器主动推送通知（如系统公告、订单状态更新）、实时日志监控、新闻资讯推送。

举例：你订阅某网站的实时新闻推送时

  1. 客户端通过 EventSource 发起 HTTP 请求，服务器保持连接并设置事件流响应头；

  2. 当有新新闻发布时，服务器无需等待客户端请求，直接将新闻数据以事件流的形式推送给客户端；

  3. 客户端实时接收数据并展示，若连接意外断开，浏览器会自动重新建立连接。

相同点

  1. 底层均基于 TCP 协议，保证数据传输的可靠性；

  2. 均可在 Web 环境中使用，浏览器原生支持（无需安装额外插件）；

  3. 都能实现客户端与服务器的远程数据交互。

核心区别表

表格 还在加载中，请等待加载完成后再尝试复制

Cookie、Session、Token

HTTP的无状态性

HTTP是无状态的，这意味着每个请求都是独立的，服务器不会在多个请求之间保留关于客户端状态的信息。在每个HTTP请求中，服务器不会记住之前的请求或会话状态，因此每个请求都是相互独立的。

虽然HTTP本身是无状态的，但可以通过一些机制来实现状态保持，其中最常见的方式是使用 Cookie和Session 来跟踪用户状态。通过在客户端存储会话信息或状态信息，服务器可以识别和跟踪特定用户的状态，以提供一定程度的状态保持功能。

一、 携带 Cookie 的 HTTP 请求：实现了状态保持，但协议本身仍无状态

携带 Cookie 的 HTTP 请求，能够在客户端与服务端之间实现会话状态的维持：

Cookie 的作用是在客户端存储会话信息、用户身份等状态数据；

浏览器每次发送 HTTP 请求时，会自动携带对应域名下的 Cookie 数据；

服务端通过读取请求中的 Cookie，即可识别用户身份、恢复会话状态，完成状态保持的需求。

二、 为什么 HTTP 协议本身仍被定义为「无状态」

HTTP 被称为无状态协议，核心原因在于协议的设计初衷和底层机制本身不保存客户端的状态信息，具体如下：

  1. 请求的独立性：每个 HTTP请求都是完全独立的，服务端在处理请求时，不会主动保存上一次请求的任何信息。即使是同一个客户端的连续请求，服务端也不会默认关联它们的关系。

  2. Cookie 是「补充机制」而非协议固有属性：虽然 Cookie 属于 HTTP 协议簇的一部分，但它只是在无状态协议基础上，实现状态保持的一种额外手段：状态信息并未存储在服务端或协议本身，而是存储在客户端；服务端需要依赖客户端主动携带的 Cookie 才能识别状态，而非协议自身具备记忆能力。

  3. 无状态设计的初衷这种无状态的设计让 HTTP 协议更简单、易于规模化扩展，服务端无需为每个客户端维护会话状态，降低了资源消耗。

cookie，session，token

Session、Cookie、Token 均是 Web 开发中用于跟踪用户状态的核心机制，三者的核心区别围绕存储位置、工作逻辑、状态特性、使用方式展开：

1. Cookie

存储位置：数据存储于客户端（浏览器）。

核心作用：类似「令牌」，主要用来装载 sessionId。

使用方式：浏览器在向服务器发送请求时，会自动将对应域名下的 Cookie 附加到请求中，无需开发者手动操作。

登录时：服务器直接把用户信息写入 Cookie

你输入账号密码登录网站，服务器验证通过后：

  • 不生成 sessionId，也不创建 Session 数据；

  • 把你的「用户名、登录状态、权限等级」等信息加密（避免被篡改），直接写入 Cookie（比如 user=zhangsan; is_login=true）；

  • 把这个 Cookie 通过响应头下发给你的浏览器，浏览器存在本地。

后续访问：服务器直接解析 Cookie 识别状态

你访问网站的个人中心时：

  • 浏览器自动把包含「用户名 + 登录状态」的 Cookie 发给服务器；

  • 服务器不用查任何「状态列表」，直接解密 / 解析 Cookie 里的内容，就能确认「你是已登录的张三」，然后显示你的个人中心数据。

2. Session

存储位置：数据存储于服务器端，可理解为服务器维护的一份「用户状态列表」。

核心标识：拥有唯一的识别符号 sessionId，该 sessionId 通常被存放于 Cookie 中。

工作逻辑：服务器接收到客户端请求后，先解析请求中的 Cookie 提取 sessionId，再通过 sessionId 到「状态列表」中查找对应的 Session 数据。

核心依赖：依赖 Cookie 实现用户状态的关联。

登录时：服务器创建 Session 并下发 sessionId 到 Cookie

你第一次登录某购物网站，输入账号密码后：

  • 服务器验证账号密码正确后，为你创建专属的 Session 数据（比如记录「用户 A 已登录」），并生成唯一的 sessionId（比如 123456）；

  • 服务器把这个 sessionId=123456 写入你的浏览器 Cookie（相当于给你一张编号 123456 的存包小票）。

后续访问：服务器通过 Cookie 中的 sessionId 查找 Session 数据

你接着访问该网站的个人中心页面时：

  • 浏览器自动把包含 sessionId=123456 的 Cookie 发给服务器；

  • 服务器先解析 Cookie，提取出 sessionId=123456；

  • 服务器用 123456 去自己的 Session 列表里查，找到对应的 Session 数据「用户 A 已登录」；

  • 基于这个数据，服务器知道你是已登录的用户 A，能正常显示你的个人中心数据。

3. Token

存储位置：通常放在 Authorization 头中，如 Authorization: Bearer <token值>。

核心特性：类似「令牌」，具备无状态特性，用户相关信息均被加密到 Token 中。

工作逻辑：服务器接收到 Token 后，无需查询额外的状态列表，仅通过解密 Token 即可识别对应的用户。

使用：需要开发者手动将 Token 添加到请求中（如请求头、参数等），而非浏览器自动携带。

你登录时：

  • 服务器验证账号密码正确后，把「用户 ID=123、权限 = 普通用户」加密成 Token（比如 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...）；

  • 服务器把这个 Token 返回给前端，前端把它存到浏览器 LocalStorage 里。

你访问个人中心时：

  • 前端手动把 Token 放到请求头里发给服务器；

  • 服务器解密 Token，直接拿到「用户 ID=123」，不用查任何服务器存储，就能返回该用户的个人数据。

Cookie和Session的区别

Cookie 和 Session 均是 Web 开发中用于跟踪用户状态的核心技术，但二者在存储位置、数据容量、安全性、生命周期、性能等维度存在显著差异：

1. 存储位置

Cookie：数据存储在客户端（浏览器），浏览器向服务器发送请求时，会自动携带对应域名下的 Cookie 数据。

Session：数据存储在服务器端，服务器为每个用户分配唯一的 Session ID，该 ID 通常通过 Cookie 或 URL 重写方式发送至客户端；客户端后续请求会携带此 ID，服务器据此查找对应的 Session 数据。（Set-Cookie 响应头）

2. 数据容量

Cookie：单个 Cookie 大小通常限制在 4KB 左右，且多数浏览器对每个域名的总 Cookie 数量也有明确限制。

Session：数据存储在服务器，理论上无数据大小限制，仅受服务器内存容量的约束。

3. 安全性

Cookie：安全性较低，因数据存储在客户端，易遭受 XSS（跨站脚本攻击）；虽可通过设置 HttpOnly 属性阻止 JavaScript 访问以降低 XSS 风险，但仍可能面临 CSRF攻击。

Session：安全性更高，敏感数据存储在服务器端；但需防范 Session 劫持。

4. 生命周期

Cookie：可手动设置过期时间，到期后自动删除；也可设为会话 Cookie，浏览器关闭时即删除。

Session：默认情况下，用户关闭浏览器后 Session 结束；服务器也可设置 Session 超时时间，超过该时间无用户活动则 Session 失效。

session依赖于cookie实现

Session 的正常工作依赖 sessionId 在客户端与服务器之间的传递，而默认情况下 sessionId 是通过 Cookie 承载的，具体逻辑如下：

  1. 服务器生成 sessionId 后，会默认通过 HTTP 响应头将其写入客户端 Cookie；

  2. 客户端禁用 Cookie 时，浏览器会拒绝保存这个包含 sessionId 的 Cookie；

  3. 后续客户端发送请求时，无法携带 sessionId 给服务器；

  4. 服务器接收不到 sessionId，就无法在「Session 列表」中查找对应的用户状态数据，最终无法识别用户会话，Session 机制失效。

JWT

JWT 令牌详解

JWT 令牌整体结构为 Header.Payload.Signature，由头部、载荷、签名三部分组成，三部分之间用英文句点 . 分隔，具体细节如下：

1. 头部（Header）

暂时无法在飞书文档外展示此内容

  1. 格式：JSON 格式数据。

  2. 作用：主要声明 JWT 的加密算法和令牌类型。

  3. 处理方式：使用 Base64 编码进行序列化，生成字符串作为 JWT 的第一部分。

  4. 示例（JSON 原始内容）：

2.载荷（Payload）

  1. 格式：JSON 格式数据。

  2. 作用：存放需要传递的核心信息，包括标准声明字段和自定义字段。

  3. 处理方式：同样使用 Base64 编码进行序列化，生成字符串作为 JWT 的第二部分。

  4. 注意：Base64 是可逆编码，而非加密，因此载荷中不建议存放敏感信息。

  5. 示例（JSON 原始内容）：

3. 签名（Signature）

  1. 作用：验证 JWT 的完整性和真实性，防止令牌被篡改。

  2. 生成方式：将编码后的头部、编码后的载荷用句点拼接，再结合密钥，按照头部声明的加密算法进行签名计算，最终生成的字符串作为 JWT 的第三部分。

  3. 核心逻辑（以 HS256 算法为例）：

JWT 令牌的优点

无状态性：

JWT 令牌：具备无状态特性，服务器端无需存储任何会话信息。用户身份、权限等所有必要数据，均被加密封装在 JWT 令牌本身中；服务器接收到令牌后，只需通过密钥解密验证，即可获取用户信息，无需查询服务器本地的会话列表。这种特性让 JWT 更适用于分布式系统，能轻松实现服务扩展。

传统认证方式：基于 Session+Cookie 实现，服务器需要在本地维护 Session 列表存储用户状态，客户端通过 Cookie 携带 sessionId 实现身份关联；在分布式场景下，需要额外做 Session 共享保证多服务节点的身份一致性。

安全性：

JWT 令牌：使用密钥对令牌进行签名处理，能有效保证令牌的完整性和真实性。只有持有正确密钥的服务器，才能对令牌进行验证和解析，可有效防止令牌被篡改；相比传统方式，能更好地抵御 CSRF（跨站请求伪造）等攻击。

传统认证方式：依赖 Cookie 传递 sessionId，Cookie 易被窃取或利用，存在 CSRF 攻击风险；且 Session 数据存储在服务器端，一旦服务器被入侵，可能导致大量用户会话信息泄露。

跨域支持

JWT 令牌：天然支持跨域访问场景。JWT 令牌可通过 HTTP 请求头（如 Authorization）或请求参数携带，能轻松实现跨域身份验证。

传统认证方式：基于 Cookie 传递 sessionId，受同源策略约束，配置复杂且存在安全风险。

JWT的缺点

JWT 存在一个核心问题：令牌一旦发放，在过期前无法被即时撤销，仍保持有效性。

解决该问题的核心方案是在业务层补充校验逻辑，最常用的是黑名单机制：

  1. 借助 Redis 等内存数据库维护 JWT 黑名单；

  2. 若需让某个 JWT 立即失效，将其加入该黑名单；

  3. 每次接收到 JWT 请求时，先校验令牌是否在黑名单中，若在则拒绝请求，以此实现 JWT 的即时撤销。

JWT令牌泄露问题

及时失效令牌：当检测到JWT令牌泄露或存在风险时，可以立即将令牌标记为失效状态。服务器在接收到带有失效标记的令牌时，会拒绝对其进行任何操作，从而保护用户的身份和数据安全。

刷新令牌：JWT令牌通常具有一定的有效期，过期后需要重新获取新的令牌。当检测到令牌泄露时，可以主动刷新令牌，即重新生成一个新的令牌，并将旧令牌标记为失效状态。这样，即使泄露的令牌被恶意使用，也会很快失效，减少了被攻击者滥用的风险。

使用黑名单：服务器可以维护一个令牌的黑名单，将泄露的令牌添加到黑名单中。在接收到令牌时，先检查令牌是否在黑名单中，如果在则拒绝操作。这种方法需要服务器维护黑名单的状态，对性能有一定的影响，但可以有效地保护泄露的令牌不被滥用。

JWT的存储

前端存储 JWT 是最核心的方式，服务器生成 JWT 后会返回给客户端，由客户端保存并在后续请求中携带，主要有 3 种常用位置，也是实际开发中最常使用的：

表格 还在加载中，请等待加载完成后再尝试复制

前端在发起请求时，都需要手动携带 JWT，最规范的方式是放在请求头的 Authorization 字段中：

// 从 LocalStorage 获取 
JWTconst token = localStorage.getItem('token');
// 发起请求时携带
fetch('https://api.example.com/user', {
    headers: {
        'Authorization': `Bearer ${token}` 
        // 标准格式：Bearer + 空格 + JWT
        }
    }
);

传输层

TCP（传输控制协议）

TCP（传输控制协议），是一种面向连接、可靠、基于字节流的传输层协议。它的作用就是在不可靠的网络上，通过序号、确认应答、超时重传、校验和、按序交付机制，保证数据不丢失、不出错、不重复、按顺序从发送方传送到接收方。你可以把它理解成：两个人打电话，必须先拨通（建立连接），说话要对方听清才会继续，挂电话也要礼貌道别，全程保证每句话都完整传达。

为什么要用 TCP？

  • 保证数据可靠：网络本身会丢包、乱序，TCP 能自动修复这些问题，适合必须完整传输的场景。

  • 面向连接：通信前先建立连接，通信后正常断开，更稳定、更安全。

  • 流量控制与拥塞控制：防止发送方发太快把接收方或网络冲垮，让传输更平稳。

  • 全双工通信：双方可以同时发送和接收数据，效率更高。

TCP 的核心原理

  1. 三次握手建立连接：通信双方先确认彼此的发送、接收能力都正常，才正式开始传输数据，避免无效连接。

  2. 可靠传输机制：

  • 给每个数据字节编号（序号），保证按序到达。

  • 接收方收到数据后返回确认（ACK）。

  • 发送方没收到确认就超时重传，确保数据不丢。

  • 用校验和检查数据是否被篡改或损坏。

3. 四次挥手断开连接：双方各自确认 "没有数据要发"，再一步步关闭连接，保证数据都传输完毕。

TCP的头部

序列号：在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小，主要是用来解决网络包乱序问题。

确认应答号：指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收，主要是用来解决丢包的问题。

控制位：

  • ACK：该位为1时，「确认号」的字段变为有效，TCP规定除最初建立连接时的 SYN 包之外该位必须置为 1 。

  • RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。

  • SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。

  • FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

TCP三次握手

TCP 是面向连接的协议，所以使用TCP前须先建立连接，而建立连接是通过三次握手来进行的。

流程：客户端先向服务端发送SYN 包请求建立连接，服务端收到后回复SYN+ACK 包表示同意连接并确认请求，客户端再向服务端回复ACK 包完成最终确认，双方确认彼此的发送和接收能力都正常后，TCP 连接正式建立。

详细流程：客户端首先向服务端发送 SYN 包，携带自己的初始序列号，请求建立连接；服务端收到后，确认客户端发送能力正常，回复一个 SYN+ACK 包，其中 SYN 表示服务端也同意建立连接并携带自身初始序列号， ACK 表示已收到客户端的 SYN；客户端收到 SYN+ACK 后，确认服务端的发送和接收能力都正常，再向服务端发送 ACK 包确认收到服务端的应答，双方都进入连接已建立状态，完成连接建立。

为什么不能两次握手？

这是为了防止已失效的请求报文，突然又传到服务器，引发错误

假设采取两次握手建立连接，客户端向服务端发送一个SYN包，来请求建立连接，因为某些未知的原因，并没有达到服务器，在中间某个网络节点产生了滞留，为了建立连接，客户端会重发SYN包，这次的数据包正常送达，服务端回复SYN+ACK之后，建立起了连接，但是第一包阻塞的网络节点突然恢复，第一包SYN包又送达到服务端，这时服务端会误认为是客户端又发起了一个新连接，从而在两次握手之后，进入数据等待状态，服务端认为是两个连接，而客户端认为是一个连接，造成了状态不一致，如果在三次握手的情况下，服务端收不到最后的ACK包，自然不会认为连接建立成功，所以，三次握手本质上来说，就是为了解决网络信道不可靠问题，为了能在不可靠的信道上，建立可靠的连接。

三次握手的核心作用

三次握手本质是客户端和服务端双向确认 "自己能发、能收，且对方也能发、能收" 的过程：

  1. 第一次握手（客户端→服务端，发 SYN）：客户端告诉服务端 "我有和你建立连接的能力"。

  2. 第二次握手（服务端→客户端，发 SYN+ACK）：服务端告诉客户端 "我收到了你的请求，我也有和你建立连接的能力"。

  3. 第三次握手（客户端→服务端，发 ACK）：客户端告诉服务端 "我收到了你的确认，现在咱们双方都确认就绪，可以正式通信了"。

为什么不能采用两次握手呢？/ 为什么需要第三次握手？

两次握手的致命缺陷：无法处理 "失效的延迟报文"

假设采用两次握手，会引发连接状态不一致的问题，具体场景如下：

  1. 客户端发送的第一个 SYN 包因网络拥堵滞留，长时间未到达服务端。

  2. 客户端超时后重发 SYN 包，这次正常到达服务端；服务端回复 SYN+ACK，两次握手完成，双方建立连接并正常通信。

  3. 通信结束后，之前滞留的旧 SYN 包突然抵达服务端。

  4. 对两次握手来说，服务端收到 SYN 包就会认为是新连接请求，回复 SYN+ACK 后直接进入 "已连接" 状态，等待客户端发送数据。

  5. 但客户端根本没有发起新连接的意愿，会忽略服务端的 SYN+ACK 包；最终服务端维持着一个 "无效连接"，浪费自身的端口和资源。

TCP四次挥手

处于连接状态的客户端和服务端，都可以发起关闭连接的请求，此时需要四次挥手来请求连接关闭。

第一次挥手：假设客户端主动发起连接关闭请求，它需要向服务端发起一个FIN包，表示要关闭连接，自己进入终止等待一状态（FIN-WAIT-1）。

第二次挥手：服务端收到FIN包，发送一包ACK包，表示自己进入了关闭等待状态（CLOZE-WAIT），客户端进入终止等待二状态（FIN-WAIT-2）；

第三次挥手：此时，服务端后还可以发送未发送的数据，而客户端还可以接收数据，待服务端发送完数据之后，发送一包FIN包，进入最后确认状态（LAST-ACK）。

第四次挥手：客户端收到之后，回复ACK包，进入超时等待状态（TIME-WAIT），经过超时时间后关闭连接，而服务端收到ACK包后，立即关闭连接。

为什么需要第四次挥手？/ 为什么不能是三次挥手？

这是为了保证对方已经收到ACK包。因为假设客户端发送完最后一包ACK包之后就释放了连接，一旦ACK包在网络中丢失，服务端将一直停留在最后确认阶段；如果客户端发送最后一包ACK包后，等待一段时间，这时服务端因为没有收到ACK包，会重发FIN包，客户端会响应这个FIN包，重发ACK包并刷新超时时间。

这个机制和第三次握手一样，也是为了保证在不可靠的网络链路中，进行可靠的连接断开确认。

超时重传机制

服务器没有收到客户端发送的第一个 SYN 报文

当客户端发送的第一个 SYN 报文丢失，服务器未收到时，客户端会触发超时重传机制，具体过程如下：

  1. 客户端发送 SYN 报文后，进入 SYN_SENT 状态，等待服务端回复 SYN-ACK 报文；

  2. 若客户端迟迟收不到服务端的第二次握手报文，会判定 SYN 报文可能丢失，触发超时重传，且重传的 SYN 报文序列号保持一致；

  3. SYN 报文的最大重传次数由内核参数 tcp_syn_retries 控制（默认值为 5）；

  4. 重传的超时时间采用指数退避策略：第一次超时重传间隔通常为 1 秒，第二次为 2 秒，以此类推，每次超时时间都是上一次的 2 倍；

  5. 当客户端达到tcp_syn_retries设定的最大重传次数后，会再等待一段超时时间（最后一次间隔的 2 倍），若仍未收到 SYN-ACK 报文，客户端就会断开连接。例如默认最大重传次数为 5 时，总耗时为 1+2+4+8+16+32=63秒，约 1 分钟后客户端终止连接建立流程。

服务器收到第一个 SYN 报文，但在回复时 SYN+ACK 报文丢失

当服务端回复的 SYN+ACK 报文丢失时，客户端和服务端会分别触发超时重传机制，具体过程如下：

  1. 客户端发送 SYN 包后，如果在超时时间内没有收到服务端的 SYN+ACK，会进行重传；当重传次数达到 tcp_syn_retries 的上限仍未收到应答，客户端会超时关闭连接。

  2. 服务端发送 SYN+ACK 包后，如果在超时时间内没有收到客户端的 ACK，同样会进行重传；当重传次数达到 tcp_synack_retries 的上限仍未收到应答，服务端也会超时关闭连接。

TCP 保证传输的可靠性

TCP 作为面向连接的可靠传输协议，核心通过连接管理、序列号与确认应答、重传机制、流量控制、拥塞控制等一系列机制，确保数据无丢失、无重复、无出错、有序地交付，具体实现如下：

1.可靠的连接管理：基于三次握手建立连接，确保客户端和服务端双向确认 "收发能力正常"；通过四次挥手关闭连接，保证双方数据都传输完毕后再断开，为可靠传输奠定基础。

2.序列号与确认应答机制：TCP 会给发送的每个字节数据都分配唯一序列号，接收方收到数据后，会基于序列号对数据包排序重组，并丢弃重复的数据包；同时接收方会回复 ACK 确认报文，告知发送方 "已正确收到某序列号之前的所有数据"，明确数据传输的边界。

3.多重重传机制：针对数据包丢失或延迟的情况，TCP 会触发重传

  1. 超时重传：发送方启动计时器，若超时未收到 ACK，自动重传对应数据包。

  2. 快速重传：当接收方收到失序数据包时，会连续发送重复的 ACK；发送方收到 3 个冗余重复 ACK 后，无需等待计时器超时，立即重传丢失的数据段。

  3. SACK：接收方告知发送方已收到的数据区间，让发送方只重传真正丢失的数据段，提高传输效率。

  4. D-SACK：额外告知发送方哪些数据被重复接收，避免不必要的重传。

4.校验校验和：发送方会对 TCP 报文的首部和数据部分计算一个校验和；接收方收到报文后，也用相同方法重新计算校验和，并与报文中携带的校验和进行对比校验。如果两者不一致，说明数据在传输过程中被篡改或损坏，接收方会直接丢弃该报文，且不回复 ACK，最终触发发送方的超时重传。

5. 流量控制：接收方通过滑动窗口机制，告知发送方自己的缓冲区剩余容量（窗口大小），发送方只能发送窗口大小以内的数据，避免因发送速度过快导致接收方缓冲区溢出而丢包，匹配收发双方的处理能力。

6.拥塞控制：发送方维护拥塞窗口，通过慢开始、拥塞避免、快重传、快恢复四个阶段，感知网络拥塞状态，动态调整发送速率，避免因发送过量数据加剧网络拥堵，从全局层面保障传输可靠性。

TCP拥塞控制

TCP 拥塞控制是一种端到端的网络流量调节机制，它通过动态调整发送方的拥塞窗口（cwnd），来避免发送数据过快导致网络路由器缓存溢出、丢包和整体性能下降。你可以把它理解成：在一条双向车道的公路上，交警（拥塞控制算法）会根据车流密度（网络状况）动态调整车辆放行速度，防止整条路被堵死，保证整体通行效率。

慢开始（Slow Start）

慢开始是 TCP 拥塞控制的初始阶段，它的核心思想是从一个很小的速率开始，快速探测网络的承载能力。

  • 核心机制：拥塞窗口 cwnd 从 1 个 MSS（最大分段大小）开始，每收到一个对新报文段的确认（ACK），cwnd 就增加 1 个 MSS。这意味着，在每个往返时间（RTT）内，cwnd 的大小会指数级增长。

  • 触发条件：当 cwnd 小于慢开始门限 ssthresh 时，TCP 处于慢开始阶段。

  • 终止条件：当 cwnd 增长到 ≥ ssthresh，或者检测到网络拥塞（如超时丢包）时，慢开始阶段结束。

拥塞避免（Congestion Avoidance）

拥塞避免是在慢开始之后的阶段，核心思想是缓慢、线性地增加发送速率，以接近但不超过网络的最大承载能力。

  • 核心机制：当 cwnd 大于等于 ssthresh 时，TCP 进入拥塞避免阶段。此时，即使收到多个 ACK，在一个 RTT 内 cwnd 也只增加 1 个 MSS，使 cwnd 呈线性增长。

  • 触发条件：当 cwnd ≥ ssthresh 时，TCP 从慢开始切换到拥塞避免。

  • 终止条件：当检测到网络拥塞（如超时丢包或收到 3 个重复 ACK）时，拥塞避免阶段结束。

慢开始与拥塞避免的典型工作过程

  1. 初始阶段（慢开始）：连接建立后，cwnd 从 1 开始，每收到一个 ACK 就加 1，呈指数增长。当 cwnd 达到初始的慢开始门限 ssthresh = 16 时，切换到拥塞避免。

  2. 拥塞避免阶段：cwnd 开始线性增长，每经过一个 RTT 增加 1，缓慢逼近网络极限。

  3. 网络拥塞：当 cwnd 增长到 24 时，网络发生拥塞（如超时丢包）。

  4. 响应拥塞：TCP 执行 "乘法减小"，将新ssthresh 设置为当前 cwnd 的一半（即 12），并将 cwnd 重置为 1，重新进入慢开始阶段。

  5. 恢复阶段：cwnd 再次从 1 开始指数增长，当达到新的 ssthresh = 12 时，再次切换到拥塞避免，线性增加发送速率。

一句话总结：TCP 拥塞控制通过慢开始快速探测网络能力，再通过拥塞避免线性逼近带宽极限，一旦检测到拥塞就主动降速，从而在保证网络稳定的前提下最大化传输效率。

UDP（用户数据报协议）

UDP（用户数据报协议），是一种无连接、不可靠、面向数据报的传输层协议。它的作用是在网络上以最小开销、低延迟传递数据，不保证送达、不保证有序，丢包与重传由应用层自行处理。

你可以把它理解成：两个人发微信语音条，不用先拨通等待对方接听，直接发过去就行，对方没听到也不会自动重发，适合追求快、偶尔漏一句也能接受的场景。

为什么要用 UDP？

  • 极致低延迟：无握手、无确认、无拥塞控制，数据直达，适合直播、在线游戏等对实时性要求极高的场景。

  • 头部开销小：仅 8 字节（源端口、目的端口、长度、校验和），远小于 TCP 至少 20 字节，传输效率更高。

  • 面向数据报：保留应用层消息边界，发一个包收一个包，无需拼接拆分，适合短报文交互。

  • 支持多播 / 广播：可向多个接收者同时发送，适合流媒体组播、局域网设备发现等场景。

UDP 的核心原理

  1. 无连接通信：发送前无需建立连接，发送后无需挥手断开；想发就发，接收方随时接收，省去连接开销。

  2. 不可靠传输机制：

    1. 给数据加简单头部，仅用校验和检测数据损坏，不修复。

    2. 不编号、不排序，接收方可能乱序收到或收不到，发送方不重传。

    3. 无流量控制与拥塞控制，网络拥塞时仍按原速率发送，避免延迟但可能加剧拥塞。

  3. 端口与数据交付：通过源端口标识发送应用，目的端口标识接收应用；将应用层数据封装成数据报，交给 IP 层发送，接收方根据端口交付给对应应用。

TCP和UDP的区别

  1. 是否面向连接：

    1. TCP 是面向连接的。在传输数据之前，必须先通过 "三次握手" 建立连接；数据传输完成后，还需要通过 "四次挥手" 来释放连接。这保证了双方都准备好通信。

    2. UDP 是无连接的。发送数据前不需要建立任何连接，直接把数据包（数据报）扔出去。

  2. 是否是可靠传输：

    1. TCP 提供可靠的数据传输服务。它通过序列号、确认应答 (ACK)、超时重传、流量控制、拥塞控制等一系列机制，来确保数据能够无差错、不丢失、不重复且按顺序地到达目的地。

    2. UDP 提供不可靠的传输。它尽最大努力交付，但不保证数据一定能到达，也不保证到达的顺序，更不会自动重传，收到报文后，接收方也不会主动发确认。

  3. 是否有状态：

    1. TCP 是有状态的。为了保证可靠传输，TCP 通信双方需要持续维护连接状态，包括序号、确认号、窗口大小、发送和接收进度等信息。

    2. UDP 是无状态的。UDP 不需要建立连接，也不维护任何传输状态，发送数据后不关心是否到达、是否丢失，因此协议开销更小。

  4. 传输效率：

    1. TCP 因为需要建立连接、发送确认、处理重传等，其开销较大，传输效率相对较低。

    2. UDP 结构简单，没有复杂的控制机制，开销小，传输效率更高，速度更快。

  5. 传输形式：

    1. TCP 是面向字节流的。它将应用程序交付的数据视为一连串无结构的字节流，会对数据进行拆分或合并。

    2. UDP 是面向报文的。UDP 会原样发送应用程序交给它的数据块，既不拆分也不合并，完整保留应用层的消息边界。

TCP与UDP的应用场景

选择 TCP 还是 UDP，核心判断依据是应用对数据传输的可靠性要求，以及对实时性、传输效率的优先级需求。

一、 选择 TCP 的场景

当数据准确性和完整性至关重要，不允许任何丢失或错序时，优先选择 TCP。TCP 具备三次握手、确认应答、超时重传、流量控制等机制，可保障数据可靠、有序地送达。典型应用场景：

  1. Web 浏览（HTTP/HTTPS）：网页内容、图片、脚本需完整加载才能正常显示

  2. 文件传输（FTP、SCP）：文件内容不允许出现字节丢失或顺序错乱

  3. 邮件收发（SMTP、POP3、IMAP）：邮件内容需要完整无误地传递

  4. 远程登录（SSH、Telnet）：命令与响应的传输必须准确无误

二、 选择 UDP 的场景

当实时性、传输速度和效率优先，且应用可以容忍少量数据丢失或乱序时，优先选择 UDP。UDP 无需建立连接，没有复杂的可靠性保障机制，传输开销小、速度快。典型应用场景：

  1. 实时音视频通信（视频会议、直播）：偶尔丢失少量数据包仅会造成短暂卡顿，远优于 TCP 重传机制导致的长时间延迟，部分场景下应用层会自带补偿机制

  2. 在线游戏：需快速传输玩家位置、状态等信息，对实时性要求极高，旧数据无重传价值，少量数据丢失对游戏体验影响较小

  3. DHCP（动态主机配置协议）：客户端请求 IP 时自身无 IP 地址，无法满足 TCP 建立连接的前提；同时 DHCP 支持广播、交互逻辑简单，且自带可靠性保障机制

  4. 物联网（IoT）数据上报：部分传感器定期上报数据的场景中，丢失个别数据点不会影响整体趋势分析

网络层

IP协议

IP 地址（Internet Protocol Address），就是互联网协议地址，是给连接到互联网或本地网络的每一台设备分配的一个唯一的 32 位（IPv4）或 128 位（IPv6）标识符。

  1. 身份标识：给网络中的每一台设备（电脑、手机、服务器等）分配一个唯一的 IP 地址，确保在庞大的互联网中，能精准识别每一个通信主体。比如你访问网站时，首先要通过 IP 地址找到目标服务器。

  2. 路由寻址：定义了数据在网络中的传输路径规则。数据从一台设备发送到另一台设备时，会基于 IP 地址，通过路由器等网络设备的转发，找到最优传输路径，最终送达目标设备。

IPv4 协议

IPv4（互联网协议第 4 版），是目前最广泛使用的网络层协议，负责给网络中的设备分配 IP 地址，并实现数据包的发送和转发。你可以把它理解成：整个互联网的通用地址规则，没有它，设备就找不到对方，数据也无法传输。

为什么要用 IPv4？

  1. 实现设备之间的通信：IPv4 给每台设备分配唯一的 IP 地址，让数据包能从一台设备送到另一台。

  2. 跨网络传输：不管是局域网还是互联网，IPv4 都能统一寻址、路由转发。

  3. 结构简单、成熟稳定：使用几十年，生态完善，所有设备都支持。

  4. 配合路由、NAT、子网划分等技术，构成了今天整个互联网的基础。

IPv4 的核心原理

IPv4 使用 32 位地址，分成 4 段十进制数字，范围 0~255，用点分隔。格式示例：192.168.1.10

IPv4 数据包包含：源 IP、目标 IP、TTL、协议号、校验和等字段。路由器根据目标 IP 地址查表转发，决定数据包走哪条路。IPv4 需要配合 ARP、子网掩码、路由表、NAT 等技术才能正常工作。

IPv4分组

IPv4 分组，也叫 IPv4 数据报，是在 TCP/IP 网络中传输的基本数据单元。它就像网络世界里的 "快递包裹"，把来自上层协议（如 TCP、UDP）的数据封装起来，加上必要的控制信息，在不同的网络节点之间进行路由和转发，最终送达目的地。

IPv4 分组的结构组成

一个完整的 IPv4 分组由首部和数据部分两大部分构成：

  • 首部：长度在 20～60 字节之间，包含了路由、分片等关键控制信息，是路由器处理分组的核心依据。其中 20 字节是所有 IPv4 分组都必须具备的固定首部，其余 0～40 字节为可选字段，用于扩展功能。

  • 数据部分：承载着上层协议（TCP 报文段、UDP 用户数据报等）的有效载荷，是需要传输的实际内容。

IPv4 首部的核心字段

IPv4 首部中包含了多个关键字段，每个字段都有其独特的作用：

  1. 版本：占 4 位，标识 IP 协议版本，IPv4 中该字段值为 4。

  2. 首部长度：占 4 位，表示首部总长度，最小值为 5（20 字节固定首部），最大值为 15（60 字节首部）。

  3. 总长度：占 16 位，以 1 字节为单位，表示整个 IPv4 分组（首部 + 数据）的总长度，最大可达 65535 字节。

  4. 协议：占 8 位，指明数据部分所承载的上层协议类型，例如 6 代表 TCP，17 代表 UDP，1 代表 ICMP。

  5. 源IP地址与目的IP地址：各占 32 位，分别标识分组的发送方和接收方的网络地址，是路由选择的核心依据。

  6. 生存时间：占 8 位，每经过一个路由器该值减 1，当值为 0 时分组被丢弃，用于防止分组在网络中无限循环。

  7. 首部校验和：占 16 位，仅对首部内容进行校验，确保首部在传输过程中未被篡改或损坏。

  8. 分片相关字段：包括标识、标志和片偏移，用于处理当分组长度超过链路 MTU 时的分片与重组问题。

IP 数据报

IP 数据报就是 IPv4 网络中传输的最小数据单元，也常被叫作 IP 分组。可以把它理解成网络里的标准快递包裹，负责把数据从一台电脑送到另一台电脑。

它不保证一定送达、也不保证不乱序、不保证不丢失，只负责尽力传输。网络中的路由器，就是根据 IP 数据报里的地址，不断转发这个包裹。

一个完整的 IP 数据报由两部分组成：首部和数据部分。首部相当于包裹上的快递单，写清来源、目的地、长度、标识等信息；数据部分就是里面真正要传送的内容，比如一段文字、一张图片、一段视频对应的二进制数据。

首部长度不是固定的，最少 20 字节，最多可以到 60 字节。多出的部分是可选字段，用来扩展一些功能。首部里最重要的信息，就是源 IP 地址和目的 IP 地址，路由器就是靠这两个地址决定往哪里转发。

为了能在不同网络里传输，IP 数据报还支持分片和重组。如果数据包太大，路途中的路由器会把它拆成小片，到达目标主机后再拼回去，这靠的是首部里的标识、标志和片偏移字段来实现。

简单说：IP 数据报 = 快递单（首部）+ 货物（数据），是互联网里最基础、最核心的传输单元。

IP地址早期分类方案

A 类地址（1.0.0.0 ~ 126.255.255.255）

  • 结构：第 1 位固定为 0，加上后面 7 位是网络号（8位），剩下 24 位是主机号。

  • 特点：网络数量少（最多 126 个），但每个网络下的主机数量极多（2^24 - 2 ≈ 1677 万台）。

  • 用途：给超大型机构（如政府、大型企业）使用。

B 类地址（128.0.0.0 ~ 191.255.255.255）

  • 结构：前 2 位固定为 10，后面 14 位是网络号（16位），剩下 16 位是主机号。

  • 特点：网络数量中等（最多 16384 个），每个网络下主机数也不少（2^16 - 2 ≈ 65534 台）。

  • 用途：给中型企业、大学等使用。

C 类地址（192.0.0.0 ~ 223.255.255.255）

  • 结构：前 3 位固定为 110，后面 21 位是网络号（24位），剩下 8 位是主机号。

  • 特点：网络数量多（超过 200 万个），但每个网络下主机数少（2^8 - 2 = 254 台）。

  • 用途：给小型企业、局域网使用，也是我们最常见的一类地址。

A、B、C 三类地址都属于单播地址，用于 "一对一" 的通信。

D 类地址（224.0.0.0 ~ 239.255.255.255）

  • 结构：前 4 位固定为 1110。

  • 特点：没有网络号和主机号之分，整个地址就是一个多播（组播）地址。

  • 用途：用于 "一对一组" 的通信，比如视频会议、直播等，把数据同时发给一组设备。

E 类地址（240.0.0.0 ~ 255.255.255.255）

  • 结构：前 4 位固定为 1111。

  • 用途：保留为今后使用，目前不分配给主机。

IP 地址的两级结构 = <网络号>, < 主机号 >

在那个年代，要求每台主机、每个路由器接口被分配的 IP 地址都是全球唯一的

路由器和路由器连接的接口可以不分配 IP 地址，但路由器和其他节点连接的接口必须分配 IP 地址

从属于同一个网络的所有主机、路由器接口的 IP 地址 "网络号" 都相同

当一台新主机接入网络时，需要给它分配一个 IP 地址、并配置 "默认网关"

为什么一个网络里主机数是 2^n - 2？

在一个网络中，主机号占 N 位，理论上有 2^n 种不同的组合。但其中有两个组合有特殊用途：

  • 主机号全 0：代表网络地址，用来标识整个网络本身，不能分配给具体设备。

  • 主机号全 1：代表广播地址，用来向整个网络广播消息，也不能分配给具体设备。

子网划分与子网掩码

一、子网划分是什么？

子网划分，就是把一个大的网络（网络号），按照一定规则，划分成多个更小的、独立的子网络（子网）。

你可以把它理解成：原本一个大的 "小区"（大网络），现在被划分成了多个 "单元楼"（子网）。每个子网都有自己独立的网络地址和广播地址，内部的主机可以直接通信，跨子网则需要路由器转发。

二、为什么要做子网划分？

  1. 解决地址浪费：早期的 A/B/C 类网络地址空间很大，比如一个 C 类网络有 254 个可用地址，如果一个小公司只需要 20 台主机，就会浪费掉 234 个地址。子网划分可以按需分配，避免浪费。

  2. 提升网络性能：大网络里的广播包会影响所有主机，划分子网后，广播域被缩小，网络负载减轻，性能提升。

  3. 便于网络管理：可以按部门、地理位置等划分子网，方便管理和故障排查。

三、子网划分的核心原理

子网划分的本质，就是借用主机号的高位作为子网号，把原来的两级结构（网络号 + 主机号）变成三级结构（网络号 + 子网号 + 主机号）。

子网掩码：用来区分哪部分是网络/子网号，哪部分是主机号。掩码里是 1 的位 → 对应 IP 地址里的网络 / 子网号；掩码里是 0 的位 → 对应 IP 地址里的主机号。

例如：C 类地址 192.168.1.0/24，默认掩码 255.255.255.0。如果借用 2 位主机号作为子网号，新掩码就是 255.255.255.192（/26），这样就把一个大网分成了 4 个子网。

四、子网划分的关键计算

以 C 类地址 192.168.1.0/24，划分为 /26（掩码 255.255.255.192）为例：

  • 子网数：借用了 2 位，子网数 = 2^2=4 个。

  • 每个子网的主机数：主机号还剩 6 位，可用主机数 = 2^6−2=62 台（减去网络地址和广播地址）。

  • 子网地址：

    • 子网 1：192.168.1.0，广播地址：192.168.1.63

    • 子网 2：192.168.1.64，广播地址：192.168.1.127

    • 子网 3：192.168.1.128，广播地址：192.168.1.191

    • 子网 4：192.168.1.192，广播地址：192.168.1.255

一句话总结：子网划分就是通过子网掩码，把一个大网络拆分成多个小网络，从而更高效地利用 IP 地址、提升网络性能和可管理性。

路由聚合

一、路由聚合是什么？

路由聚合，就是把多个连续的小网络，合并成一个更大的网络来表示，也叫作超网。你可以把它理解成：原本很多个相邻的 "小单元楼"（小网络），现在合并成一个大的 "小区"（大网络）。路由器只需要记住这一条大路由，就能代表所有小路由，转发数据时不再需要逐条查找。

二、为什么要做路由聚合？

  1. 减小路由表体积：互联网里小网段数量极多，路由器逐条记录会非常臃肿，聚合后只保留一条汇总路由，大大减少存储压力。

  2. 提高转发效率：路由表越简洁，路由器查找路由的速度越快，数据转发更高效。

  3. 提升网络稳定性：某个小网段出现变化，不会频繁影响整条大的聚合路由，减少网络波动。

  4. 配合 CIDR 高效使用地址：和无分类编址一起使用，让 IP 地址分配和路由管理更合理。

三、路由聚合的核心原理

路由聚合的本质，就是把多个连续、前缀相近的小网络，提取共同的高位作为新的网络前缀，缩短前缀长度，形成一个更大的地址块。它和子网划分刚好相反：子网划分是把大网切小，让前缀变长；路由聚合是把小网拼大，让前缀变短。例如：8 个连续的 C 类网段 192.168.0.0/24～192.168.7.0/24，可以聚合成一条路由 192.168.0.0/21。

四、路由聚合的关键计算

以 8 个连续 C 类网段聚合为例：

  • 聚合前：192.168.0.0/24、192.168.1.0/24…… 一直到 192.168.7.0/24，共 8 条路由。

  • 共同前缀长度：原来 / 24，聚合后变为 / 21，前缀缩短 3 位。

  • 聚合后路由：192.168.0.0/21，子网掩码为 255.255.248.0。

  • 覆盖范围：192.168.0.0～192.168.7.255，包含原来所有 8 个小网段。

一句话总结：路由聚合就是把多个连续小网络合并成一个大网络，减小路由表、提高转发效率，是 CIDR 中用来优化互联网路由的关键技术。

CIDR（无分类编址）

一、CIDR 是什么？

CIDR（无分类编址）抛弃了早期 A/B/C 类地址的固定分类，用 "网络前缀长度" 来灵活划分网络的一种编址方式。

它把 32 位 IP 地址分成两部分：

  • 网络前缀：长度可变，用来标识一个网络（或地址块）

  • 主机号：剩下的位，用来标识网络内的主机

写法就是：IP地址/前缀长度，比如 128.14.32.0/21，意思是前 21 位是网络前缀，后 11 位是主机号。

二、为什么要有 CIDR？

早期的分类编址（A/B/C 类）有两个大问题：

  1. 地址浪费严重：一个小公司申请一个 C 类网（256 个地址），只用 20 台，剩下 236 个就浪费了；如果申请 B 类网（65536 个地址），浪费更夸张。

  2. 路由表膨胀：大量小网络号让路由器的路由表越来越大，转发效率变低。

CIDR 就是为了解决这两个问题而生的：

  • 按需分配地址块，不再受 A/B/C 类的限制

  • 支持路由聚合，把多个小网络合并成一个大的路由条目，减小路由表

三、用你这张图的例子来理解

例子：某单位有 2000 台主机，分配了 128.14.32.0/21

  1. 主机号位数：32 - 21 = 11 位

    1. 可用主机数 = 211−2=2046 台，刚好满足 2000 台的需求，不浪费。

  2. 子网掩码：前缀 21 位全是 1，后 11 位全是 0

    1. 二进制：11111111.11111111.11111000.00000000

    2. 十进制：255.255.248.0

  3. 地址块范围：

    1. 起始地址：网络前缀不变，主机号全 0 → 128.14.32.0

    2. 结束地址：网络前缀不变，主机号全 1 → 128.14.39.255

    3. 所以这个 CIDR 块覆盖的地址是：128.14.32.0 ~ 128.14.39.255

一句话总结：CIDR 就是用 "/ 前缀长度" 的方式，灵活地划分和分配 IP 地址块，既节约了地址，又优化了路由，是现在互联网的主流编址方式。

CIDR和子网划分的区别

子网划分是在一个已有的大网络内部进行操作，把它拆分成多个更小的子网，本质是 "从大到小" 地切分地址空间；而 CIDR 则是抛弃了 A/B/C 类地址的固定分类，通过 "前缀长度" 灵活定义网络边界，既可以按需分配地址块，也能把多个小网合并成大网，操作方向更灵活。

子网划分主要解决企业内部的地址浪费和网络管理问题，比如把一个 C 类网切成多个小网，按部门分配，缩小广播域；而 CIDR 则是为了解决全球互联网层面的地址枯竭和路由表膨胀问题，通过按需分配和路由聚合，提高地址利用率并优化路由转发。

子网划分的核心是借用主机号的高位作为子网号，让网络前缀变长，比如从 / 24 变成 / 26；而 CIDR 的核心是 "前缀长度可变"，既可以变长（子网划分），也可以变短（路由聚合），比如把 8 个 / 24 合并成一个 / 21。

在实际使用中，子网划分是企业拿到地址块后，内部精细化管理的工具；而 CIDR 是 ISP 和 ICANN 在全球层面分配地址、优化路由的方案，两者通常配合使用：先通过 CIDR 获得地址块，再用子网划分做内部管理。

NAT（网络地址转换）

一、NAT 是什么？

NAT（网络地址转换），就是在路由器上把内网私有 IP 地址和外网公有 IP 地址互相转换的技术。你可以把它理解成：一个公司只有少数几个对外 "门牌号"（公网 IP），却有很多员工（内网设备），大家共用这几个门牌号上网，外面看不到内部具体是谁。

二、为什么要用 NAT？CIDR 还不够吗？

  1. 解决地址枯竭：CIDR 只是优化分配，不能变出更多地址，而 NAT 能让几十上百台设备共用 1 个公网 IP。

  2. 节省公网 IP 成本：一个公司几百台设备，不需要几百个公网 IP，只要 1 个或少数几个就能全部上网。

  3. 隐藏内网结构：外部网络看不到内部设备的真实 IP，内网更安全。

  4. 实现内网设备访问互联网：没有公网 IP 的设备，通过 NAT 也能正常上网。

三、NAT 的核心原理

NAT 的核心是在路由器上建立一张地址端口映射表，在路由器上做地址转换，当数据包经过路由器时，NAT 会把源 IP 换成路由器的公网 IP，再发出去。外面的服务器只看到公网 IP，不知道你内网的真实地址。配合端口号后，多台设备可以共用同一个公网 IP，靠不同端口区分，这就是最常用的 NAPT。

四、NAT 的典型工作过程

  1. 你的手机 IP：192.168.1.10（内网私有 IP，不能上互联网）

  2. 你打开浏览器访问百度

  3. 数据包到路由器，NAT 把源 IP 改成路由器的公网 IP，并记录端口号

  4. 百度收到请求，以为是路由器在访问，把数据返回给路由器

  5. 路由器根据端口号，把数据转给你的手机

  6. 你看到网页，整个过程外网不知道你的真实 IP

一句话总结：NAT 是让大量内网设备共用少量公网 IP 上网的技术，和 CIDR 互补，从根本上延缓了 IPv4 地址耗尽，是现代局域网必须使用的核心技术。

Port（端口号）

一、端口号是什么？

端口号，就是用来区分同一台设备上不同应用或服务的编号，它和 IP 地址配合使用。你可以把它理解成：IP 地址是找到一栋大楼（设备），端口号是找到这栋楼里具体的房间（应用程序），数据才能准确送到对应的软件。

二、为什么需要端口号？

  1. 一台设备同时运行很多程序：浏览器、QQ、微信、服务器等，只靠 IP 只能找到设备，分不清该给哪个应用。

  2. 让一台主机同时提供多种服务：比如一台服务器既开网站（80），又开邮件（25），必须用端口号区分。

  3. 和 IP 地址组合成 "套接字 Socket"，实现网络里精确的端到端通信。

  4. 配合 NAT 实现多设备共用一个公网 IP，是内网能上网的关键。

三、端口号的分类和特点

端口号是一个 0~65535 的数字，主要分为三类：

  1. 知名端口（0~1023）：固定给系统服务使用

    1. 80：HTTP 网页

    2. 443：HTTPS 加密网页

    3. 22：SSH 远程登录

    4. 21：FTP 文件传输

  2. 注册端口（1024~49151）：给普通应用程序使用

  3. 动态 / 临时端口（49152~65535）：客户端上网时随机使用

四、端口号和 IP、NAT 的关系

IP 地址负责找到哪一台设备，端口号负责找到设备上的哪个程序。在 NAT 里，正是靠端口号区分不同内网设备：

  • 多台内网设备可以共用同一个公网 IP

  • 路由器用不同端口号标记每一个连接

  • 外网数据回来时，根据端口号转发给正确的内网主机

没有端口号，NAT 就无法让多个人同时上网。

一句话总结：端口号是设备上区分不同应用的编号，和 IP 配合实现精准通信，也是 NAT 能让多设备共享一个公网 IP 的核心。

ARP（地址解析协议）

一、ARP 是什么？

ARP（地址解析协议），就是在同一个局域网内，把已知的 IP 地址 转换成对应设备的 MAC 地址 的协议。你可以把它理解成：你知道了邻居家的 "门牌号"（IP 地址），但不知道他家的 "具体位置"（MAC 地址），于是在小区里大喊一声 "谁是这个门牌号的主人？"，邻居听到后就会告诉你他的具体位置，这样你才能把东西准确送过去。

二、为什么要用 ARP？

  1. 实现局域网通信：在以太网中，数据帧是通过 MAC 地址来转发的，只知道 IP 地址无法直接发送数据。

  2. 建立 IP 与 MAC 的映射：让网络层的 IP 地址和数据链路层的 MAC 地址能够对应起来，是跨层通信的关键。

  3. 提高转发效率：设备会缓存解析过的 IP-MAC 映射（ARP 缓存表），下次通信时直接查表，不用广播询问。

三、ARP 的核心原理

当设备 A 要和同一局域网内的设备 B 通信时：

  1. 设备 A 先查自己的 ARP 缓存表，如果找到了设备 B 的 MAC 地址，就直接发送数据。

  2. 如果没找到，设备 A 会发送一个 ARP 请求广播包，内容是 "IP 地址为 xxx 的设备，你的 MAC 地址是什么？"，整个局域网的设备都能收到这个广播。

  3. 只有 IP 地址匹配的设备 B 会响应，发送一个 ARP 响应单播包，把自己的 MAC 地址告诉设备 A。

  4. 设备 A 收到响应后，把这个 IP-MAC 映射存入 ARP 缓存表，后续通信就可以直接使用。

四、ARP 的典型工作过程

  1. 设备 A（192.168.1.10）要给设备 B（192.168.1.20）发数据。

  2. 设备 A 查 ARP 表，没有 192.168.1.20 的 MAC 地址，于是发送 ARP 请求广播。

  3. 设备 B 收到请求，发现 IP 匹配，回复 ARP 响应，告知自己的 MAC 地址是 AA:BB:CC:DD:EE:FF。

  4. 设备 A 更新 ARP 表，后续数据直接发往这个 MAC 地址。

DHCP（动态主机配置协议）

一、DHCP 是什么？

DHCP（动态主机配置协议），是在网络中自动给主机分配 IP 地址、子网掩码、默认网关、DNS 服务器等网络配置信息的协议。你可以把它理解成：小区门口有个 "物业前台"（DHCP 服务器），新搬来的住户（新接入的设备）不用自己去查地址，直接去前台登记，前台就会把 "门牌号（IP）、小区出口（网关）、快递点（DNS）" 等信息一次性告诉你，省得自己手动配置。

二、为什么要用 DHCP？

  1. 避免 IP 地址冲突：如果手动配置IP，很容易出现多台设备用同一个IP的情况，导致网络不通，DHCP会统一分配，保证地址不重复。

  2. 简化网络管理：在有大量设备环境中，DHCP可以自动完成每台设备配置网络信息工作，大幅降低管理成本。

  3. 实现地址复用：设备离开网络后，DHCP 可以回收分配的 IP 地址，再分配给新设备，提高地址利用率。

  4. 支持移动设备接入：手机等移动设备在不同网络间切换时，DHCP可以自动获取新的网络配置，无需手动修改。

三、DHCP 的核心原理

DHCP 采用 "客户端 - 服务器" 模式，工作过程主要分为 4 个阶段：

  1. 发现：客户端刚接入网络，不知道 DHCP 服务器在哪，会发送一个广播的 DHCP Discover 包，寻找可用的 DHCP 服务器。

  2. 提供：网络中的 DHCP 服务器收到 Discover 包后，会从地址池中挑选一个未分配的 IP，发送一个单播或广播的 DHCP Offer 包，向客户端提供这个 IP 及其他配置信息。

  3. 请求：客户端可能收到多个 Offer 包，会选择其中一个，然后发送广播的 DHCP Request 包，正式向选中的服务器请求使用这个 IP。

  4. 确认：DHCP 服务器收到 Request 包后，会发送单播的 DHCP ACK 包，确认分配成功，客户端就可以使用这个 IP 地址。

四、DHCP 的典型工作过程

  1. 你的笔记本电脑刚连上公司 WiFi，没有任何网络配置。

  2. 笔记本发送 DHCP Discover 广播："谁能给我一个 IP 地址？"

  3. 公司的 DHCP 服务器收到后，回复 DHCP Offer："我可以给你分配 192.168.1.100，子网掩码 255.255.255.0，网关 192.168.1.1，DNS 114.114.114.114。"

  4. 笔记本选择这个 Offer，发送 DHCP Request 广播："我确认要使用 192.168.1.100。"

  5. DHCP 服务器回复 DHCP ACK："确认分配，租期 8 小时。"

  6. 笔记本拿到配置后，就可以正常访问网络。

一句话总结：DHCP 是自动给网络设备分配 IP 及相关配置的协议，大幅简化了网络管理，避免了地址冲突，是现代局域网中必不可少的基础服务。

ICMP（网际控制报文协议）

一、ICMP 是什么？

ICMP（网际控制报文协议），是在 IP 网络中传递控制消息和诊断信息的协议，它依附于 IP 协议，但不属于传输层，而是网络层的重要补充。你可以把它理解成：网络中的 "信使" 和 "质检员"，当网络出现问题时，它会回来报告错误；当你想检查网络是否通畅时，它会帮你 "探路" 并反馈结果。

二、为什么要用 ICMP？

  1. 传递网络错误信息：当 IP 数据包无法送达时，路由器或目标主机可以通过 ICMP 报告原因，比如目标不可达、超时、端口不可达等，帮助定位问题。

  2. 网络诊断与测试：ping和traceroute命令都是基于ICMP实现的，是排查网络连通性和路径问题的工具。

  3. 辅助网络优化：ICMP可提供路径 MTU 发现等功能，帮助设备选择合适的数据包大小，避免分片，提升效率。

三、ICMP 的核心原理

ICMP 报文封装在 IP 数据包中，主要分为两大类：

  1. 差错报告报文：用于反馈网络中出现的问题，例如：

    1. 目标不可达（Destination Unreachable）：数据包无法到达目标主机或端口。

    2. 超时（Time Exceeded）：数据包的 TTL（生存时间）耗尽，被路由器丢弃。

    3. 源点抑制（Source Quench）：通知发送方降低发送速率，避免拥塞。

  2. 查询报文：用于主动查询网络信息，例如：

    1. 回显请求 / 回显应答（Echo Request / Echo Reply）：ping 命令的基础，测试连通性。

    2. 时间戳请求 / 应答：用于网络时间同步。

当网络中出现异常时，中间设备或目标主机会生成对应的 ICMP 差错报文，返回给源主机；而诊断工具则主动发送查询报文，根据响应判断网络状态。

四、ICMP 的典型工作过程

例子 1：使用 ping 测试网络连通性

  1. 你在电脑上执行 ping www.baidu.com。

  2. 你的主机发送一个 ICMP 回显请求（Echo Request） 报文到百度服务器。

  3. 百度服务器收到后，回复一个 ICMP 回显应答（Echo Reply） 报文。

  4. 你的主机收到应答，计算往返时间（RTT），并显示 "来自 xxx.xxx.xxx.xxx 的回复：字节 = 32 时间 = xxms TTL=xx"，表示网络连通。

例子 2：数据包超时

  1. 你的主机发送一个 TTL=1 的数据包到远程服务器。

  2. 数据包到达第一个路由器后，TTL 减 1 变为 0，路由器将其丢弃。

  3. 路由器向你的主机发送一个 ICMP 超时（Time Exceeded） 报文。

  4. 你的主机收到报文，得知数据包在传输过程中被丢弃，从而判断网络路径可能存在问题。

一句话总结：ICMP 是 IP 网络的 "控制与诊断中心"，负责传递错误信息和支持网络测试，是排查网络问题、理解网络行为的关键协议。

IPv6 协议

一、IPv6 是什么？

IPv6（互联网协议第 6 版），是用来替代 IPv4 的新一代网络地址协议，用来给网络设备分配唯一的标识，实现设备之间的通信。你可以把它理解成：IPv4 是老式小区，门牌太少不够用；IPv6 是超级巨大的新城，能给世界上每一粒沙子都分配一个独立地址，再也不用担心地址不够。

二、为什么要用 IPv6？

  1. 解决 IPv4 地址枯竭：IPv4 只有 32 位，地址数量有限，早就不够用了。

  2. 地址空间极大：IPv6 是 128 位，地址数量几乎无限，满足未来所有设备联网需求。

  3. 不需要 NAT：每个设备都能拥有独立公网地址，点对点通信更简单、更高效。

  4. 网络更快更稳定：头部结构简化，路由器转发更快，支持更高速度的网络。

  5. 安全性更强：原生支持 IPsec 加密，数据传输更安全。

  6. 支持海量设备接入：适合智能家居、物联网、工业互联网等大量设备同时在线。

三、IPv6 的核心原理

IPv6 使用 128 位地址，分成 8 组，每组 4 个十六进制数，用冒号分隔。格式示例：2001:0db8:85a3:0000:0000:8a2e:0370:7334

为了方便书写，可以简化：

  • 一组全是 0，可以直接写成一个 0

  • 连续多组 0，可以用 双冒号 :: 代替

IPv6 不再使用 ARP，而是用 NDP（邻居发现协议） 实现地址解析。IPv6 也支持 自动配置，设备开机就能自己获得地址，不用依赖 DHCP 也能上网。

IPv4 和 IPv6 的区别

IPv4 和 IPv6 是两个不同版本的互联网协议，核心区别在于地址空间，同时在配置、性能等方面也有显著差异，具体如下：

  1. 地址空间与格式：IPv4 采用 32 位地址，格式是点分十进制（如123.89.46.72），总地址数约 42 亿，早已面临耗尽问题；IPv6 采用 128 位地址，格式是冒分十六进制（如2001:0db8:85a3::8a2e:0370:7334），地址数量极大，可满足万物互联需求。

  2. 配置与 NAT 依赖：IPv4 需依赖 DHCP 分配地址，且因地址不足广泛使用 NAT 技术实现内网设备共享公网 IP；IPv6 支持无状态地址自动配置（SLAAC），主机可自行生成全局唯一地址，NAT 仅作为可选项。

  3. 协议头与性能：IPv4 报头字段复杂，处理开销高；IPv6 简化了报头结构，减少处理开销，同时支持可选扩展头，功能更灵活；且 ICMPv6 优化了邻居发现、路径 MTU 发现等功能，提升了网络可靠性。

网络接口层

广域网与局域网

按分布范围分类是最基础、最常见的计算机网络分类方式，核心是看网络覆盖的地理范围：

  • 局域网（LAN）

    • 覆盖范围：小，通常是一个办公室、一栋楼或一个校园。

    • 特点：传输速率高、延迟低、误码率低，由单位自行建设和管理（如公司内网、校园网）。

    • 典型技术：以太网（Ethernet）、Wi-Fi。

  • 城域网（MAN）

    • 覆盖范围：中等，覆盖一个城市或一个大型园区。

    • 特点：介于 LAN 和 WAN 之间，用于连接多个 LAN。

    • 典型技术：早期的 FDDI，现在更多是运营商的城域以太网。

  • 广域网（WAN）

    • 覆盖范围：大，跨城市、国家甚至全球。

    • 特点：传输速率相对较低、延迟高，由电信运营商提供（如互联网、专线）。

    • 典型技术：PPP、帧中继、ATM、MPLS。

  • 个域网（PAN）

    • 覆盖范围：极小，个人设备之间的连接（如手机与耳机、电脑与鼠标）。

    • 典型技术：蓝牙、NFC、Zigbee。

感谢你的阅读！✿

# 计算机网络 # 开发语言 # java # spring boot # spring
Logo
腾讯云开发者社区

腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。

更多推荐

终极指南：Flink SQL连接器版本管理从混乱到有序的升级之路

Apache Flink作为流处理领域的佼佼者，其SQL连接器的版本管理一直是开发者面临的核心挑战。本文将系统讲解Flink SQL连接器版本管理的最佳实践，帮助你轻松应对版本兼容性问题，实现从混乱到有序的升级之旅。## 连接器版本管理的常见痛点 😫在Flink应用开发中，连接器版本管理常常让开发者头疼不已。不同版本的连接器可能导致各种兼容性问题，例如API变更、功能差异甚至运行时错误。

avatar 腾讯云开发者社区

Elasticsearch复杂数据类型终极指南：从入门到精通

Elasticsearch作为功能强大的搜索引擎，支持多种复杂数据类型，让开发者能够灵活处理各种结构化和非结构化数据。本文将带你全面了解Elasticsearch中的复杂数据类型，从基础概念到实际应用，助你轻松掌握数据建模的核心技巧。## 内部对象：构建层级化数据结构在Elasticsearch中，对象类型（Object）是最基础的复杂数据类型之一，用于表示具有嵌套关系的数据。例如，我们可

avatar 腾讯云开发者社区

如何快速搭建Neon无服务器PostgreSQL：面向初学者的完整指南

Neon是一款革命性的无服务器PostgreSQL解决方案，它通过分离存储和计算层，实现了自动扩缩容、类代码式数据库分支以及零级扩展能力。本指南将帮助你从零开始搭建Neon开发环境，体验这款创新数据库的强大功能。## 准备工作：环境要求与依赖项在开始搭建Neon环境前，请确保你的系统满足以下要求：- Linux操作系统（推荐Ubuntu 20.04+或Debian 11+）- Git

avatar 腾讯云开发者社区