301Moved Permanently表示永久重定向，资源不存在了，需改用新的 URL，302 Found表示临时重定向，请求资源还在但是暂时需要另一个URL访问，304 Not Modified不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制；

403表示 Forbidden表示服务器紧张访问，404 Not Found表示请求的资源不存在；

500 Internal Server Error表示服务器内部错误，501表示请求的功能还不支持，502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应，504 Gateway Time-out：为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器收到响应。

报文

请求报文：

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

请求头部：包含关于请求的附加信息，如Host、User-Agent、Content-Type等。

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

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

响应报文：

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

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

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

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

请求类型

GET：用于请求获取指定资源，通常用于获取数据。
POST：用于向服务器提交数据，通常用于提交表单数据或进行资源的创建。
PUT：用于向服务器更新指定资源，通常用于更新已存在的资源。
DELETE：用于请求服务器删除指定资源。
HEAD：类似于GET请求，但只返回资源的头部信息，用于获取资源的元数据而不获取实际内容。

GET vs POST：

GET是从服务器获取指定的资源，请求的参数位置一般写在URL中，参数只允许ASCII，并且浏览器(不是HTTP)对URL长度有限制。GET是安全且幂等的，是“只读”操作，可被浏览器缓存。

POST是根据请求符合(报文body)对指定数据的资源做出处理，POST 请求携带数据的位置一般是写在报文 body 中，body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制。POST是不安全不幂等的，是“新增/提交数据”操作，会修改服务器资源，浏览器一般不会缓存POST请求。

注：理论上，任何请求都可以带 body 的，只是规范上GET不带body；并且URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的。

安全指请求方法不会破坏/修改服务器资源
幂等指多次执行相同的操作结果都相同

常见字段

HTTP字段（HTTP field）是出现在HTTP请求或响应头部的一组键: 值结构，用于携带额外的指令或说明，帮助服务器和客户端正确处理HTTP消息。

HOST：可以将请求发往「同一台」服务器上的不同网站

Content-Length：表明本次回应的数据长度

Connection：最常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用

Content-Type：用于服务器回应时，告诉客户端，本次数据是什么格式

Content-Encoding：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

版本

HTTP/1.0：每次请求都要重新建立 TCP 连接，效率较低。它的最大问题是连接的不持久性。每个请求都必须等待前一个请求的响应完成后才能发送下一个请求。这种模式称为 请求-响应阻塞。

HTTP/1.1：最突出的特点是简单、灵活和易于扩展、应用广泛和跨平台，缺点是明文传输，不安全，无状态。无状态让服务器不用记忆HTTP状态，减轻服务器负担，但是坏处就是进行关联性操作的时候很麻烦，每次都要问身份信息什么的，无状态的解决方法简单的方法是使用Cookie技术，Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。浏览器会自动携带从服务器得到的 Cookie，并在后续请求中发送给服务器。明文传输：在传输过程的信息方便阅读，方便调试，但是内容可能被窃听，不安全。不安全：明文传输，容易被监听和篡改通信内容；缺乏请求验证，不会验证通信方的身份，容易受到伪造请求的攻击；无法证明报文的完整性。

性能：长连接（也叫持久连接），减少了重复TCP连接和断开的开销，只要一端没有明确提出断开连接，始终保持TCP连接状态，如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。管道网络传输：(并没有广泛应用，有队头阻塞问题)建立在长连接的基础上，挂电脑网络传输使在同一个TCP连接里，客户端可以发起多个请求，不需要等前一个请求响应完，减少了整体的响应时间。队头阻塞：如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住。

性能瓶颈：请求 / 响应头部信息不能压缩，只能压缩Body部分，头部冗长；队头阻塞；没有请求优先级控制；请求只能客户端发起服务器响应。

总之，1.1性能一般。

HTTP/2：基于HTTPS，安全性。

性能改进：头部压缩：协议会消除多个请求里相似的头的部分，即所谓的HPACK算法，客户端与服务器共同维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。二进制格式：不再是纯文本形式报文，而是全面采用二进制格式，头信息和数据体统称为帧：头信息帧，数据帧，计算机直接解析二进制报文，增加了效率。并发传输：引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接，解决队头阻塞的问题。针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。服务器推送：服务器可以主动向客户端发消息，客户端和服务器都可以建立Stream，但是客户端的Stream ID必须是奇数，服务器必须是偶数。

缺陷：在TCP层存在“队头阻塞”问题：HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。

HTTP/3：把HTTP下层的TCP换成了UDP来解决HTTP2的队头阻塞问题。虽然UDP是不可靠传输，但是基于UDP的QUIC协议可以实现类似TCP的可靠传输。

UDP的QUIC协议：无队头阻塞：类似HTTP/2的 Stream与多路复用概念，在同一条连接上并发传输多个 Stream，Stream 可以认为就是一条 HTTP 请求。不同的是当某个流丢包只会阻塞这个流，因此不存在队头阻塞问题，不同于HTTP/2影响到其他流。更快的建立连接：在使用 HTTPS 的情况下，HTTP/1.1 和 HTTP/2 都是先进行 TCP 三次握手，再进行 TLS 握手，最后才开始传输加密的 HTTP 数据。 QUIC内部包含了TLS，把 TCP 三次握手 + TLS 握手合并成一次。连接迁移：当客户端的网络发生变化（如从 Wi-Fi 切换到 5G），连接不会断，可以继续复用原连接进行通信。原理是使用连接ID代替传统的IP+端口标识连接，即便IP/端口改变，只要连接ID不变通信可以继续进行。

HTTP/3.0 之前是基于 TCP 协议的，而 HTTP/3.0 将弃用 TCP，改用 基于 UDP 的 QUIC 协议
具体原因包括以下几点：
避免“队头阻塞”问题 HTTP/2 虽然支持多路复用，但依赖于 TCP，而 TCP 是按字节流传输的。一旦某个数据包丢失，整个连接的所有流都要等待它重传，造成 连接级的队头阻塞。 QUIC 在传输层支持多路复用，每个流是独立传输的，不会互相阻塞，大大提升了并发请求效率。
减少连接建立时延 TCP + TLS 通常需要至少 3 次握手才能建立加密连接，而 QUIC 集成了 TLS 1.3，首次连接只需 1 次 RTT，重连甚至 0 RTT，显著减少了连接建立时间。
支持更灵活的连接迁移 QUIC 不再依赖 IP + 端口作为连接标识，而是使用连接 ID，这意味着客户端在 IP 或网络切换时（如 WiFi ⇄ 4G），连接可以继续复用，不需要重新握手。
更易于协议扩展和升级 TCP 是操作系统协议栈的一部分，升级依赖内核。而 QUIC 基于用户态 UDP 协议，可以灵活地在应用层进行更新和优化，推动协议演进。

缓存技术

浏览器/中间服务器在本地保存资源副本，减少重复请求、提示加载速度、节省宽带

有两种实现方式：强制缓存和协商缓存

强制缓存：只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边（过期时间是服务器决定的）。是利用HTTP两个响应头部字段实现的，表示资源在客户端缓存的有效期：Cache-Control，是一个相对时间（优先级高，选项多，设置精细，推荐）；Expires，是一个绝对时间。

协商缓存：协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。成功返回304。基于两种头部实现：1，请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现，浏览器用 If-Modified-Since 告诉服务器“我上次看到的修改时间”，服务器用 Last-Modified 判断资源是否变化，从而决定是否让浏览器继续用旧的；2，请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段，用ETag 表示“资源版本”，浏览器每次带上旧版本号问服务器“这个版本还有效吗？”，服务器比对后决定是否返回新资源。ETag优先级更高，因为它可以解决Last-Modified的几个问题：内容没有修改的情况下文件最后修改时间也可能改变；可能有些文件是在秒级以内修改的，而If-Modified-Since 能检查到的粒度是秒级的；有些服务器不能精确获取文件的最后修改时间。

注：协商缓存是强制缓存的“备胎”，只有强制缓存失效时才会触发协商缓存流程。

ETag 实现协商缓存的过程：

当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 ETag 唯一标识，这个唯一标识的值是根据当前请求的资源生成的。当浏览器再次请求访问服务器中的该资源时，首先会先检查强制缓存是否过期：如果没有过期，则直接使用本地缓存；如果缓存过期了，会在 Request 头部加上 If-None-Match 字段，该字段的值就是 ETag 唯一标识。

服务器再次收到请求后，会根据请求中的 If-None-Match 值与当前请求的资源生成的唯一标识进行比较：如果值相等，则返回 304 Not Modified，不会返回资源；如果不相等，则返回 200 状态码和资源内容，并在 Response 头部加上新的 ETag唯一标识。

如果浏览器收到 304 的请求响应状态码，则会从本地缓存中加载资源，否则更新资源。

HTTP如何保存用户状态

HTTP 协议是无状态的协议，它本身不会记录客户端的请求状态，每次请求都是独立的。这意味着服务器无法直接知道两个请求是否来自同一个用户。

为了在 HTTP 协议上实现用户状态的保存，通常会借助以下几种机制：

方案一

Session (会话) 配合 Cookie (主流方式)：

基本流程是这样的：

用户向服务器发送用户名、密码、验证码用于登陆系统。
服务器验证通过后，会为这个用户创建一个专属的 Session 对象（可以理解为服务器上的一块内存，存放该用户的状态数据，如购物车、登录信息等）存储起来，并给这个 Session 分配一个唯一的 SessionID。
服务器通过 HTTP 响应头中的 Set-Cookie 指令，把这个 SessionID 发送给用户的浏览器。
浏览器接收到 SessionID 后，会将其以 Cookie 的形式保存在本地。当用户保持登录状态时，每次向该服务器发请求，浏览器都会自动带上这个存有 SessionID 的 Cookie。
服务器收到请求后，从 Cookie 中拿出 SessionID，就能找到之前保存的那个 Session 对象，从而知道这是哪个用户以及他之前的状态了。

使用 Session 的时候需要注意下面几个点：

客户端 Cookie 支持：依赖 Session 的核心功能要确保用户浏览器开启了 Cookie。
Session 过期管理：合理设置 Session 的过期时间，平衡安全性和用户体验。
Session ID 安全：为包含 SessionID 的 Cookie 设置 HttpOnly 标志可以防止客户端脚本（如 JavaScript）窃取，设置 Secure 标志可以保证 SessionID 只在 HTTPS 连接下传输，增加安全性。

Session 数据本身存储在服务器端。常见的存储方式有：

服务器内存:实现简单，访问速度快，但服务器重启数据会丢失，且不利于多服务器间的负载均衡。这种方式适合简单且用户量不大的业务场景。
数据库 (如 MySQL, PostgreSQL):数据持久化，但读写性能相对较低，一般不会使用这种方式。
分布式缓存 (如 Redis):性能高，支持分布式部署，是目前大规模应用中非常主流的方案。

方案二

当 Cookie 被禁用时：URL 重写 (URL Rewriting)

如果用户的浏览器禁用了 Cookie，或者某些情况下不便使用 Cookie，还有一种备选方案是 URL 重写。这种方式会将 SessionID 直接附加到 URL 的末尾，作为参数传递。例如：http://www.example.com/page?sessionid=xxxxxx。服务器端会解析 URL 中的 sessionid 参数来获取 SessionID，进而找到对应的 Session 数据。

这种方法一般不会使用，存在以下缺点：

URL 会变长且不美观；
SessionID 暴露在 URL 中，安全性较低（容易被复制、分享或记录在日志中）；
对搜索引擎优化 (SEO) 可能不友好。

方案三

Token-based 认证 (如 JWT - JSON Web Tokens)

这是一种越来越流行的无状态认证方式，尤其适用于前后端分离的架构和微服务。

以 JWT 为例（普通 Token 方案也可以），简化后的步骤如下

用户向服务器发送用户名、密码以及验证码用于登陆系统；
如果用户用户名、密码以及验证码校验正确的话，服务端会返回已经签名的 Token，也就是 JWT；
客户端收到 Token 后自己保存起来（比如浏览器的 localStorage ）；
用户以后每次向后端发请求都在 Header 中带上这个 JWT ；
服务端检查 JWT 并从中获取用户相关信息。

HTTPS

HTTP vs HTTPS

主要区别在于安全性，HTTP基于 TCP ，不加密，数据在传输过程是明文；HTTPS加密，通过SSL/TLS协议加密，SSL/TLS 位于 HTTP 和 TCP 之间，在传输过程不可被第三方轻易读取或篡改，HTTPS在TCP三次握手之后还需要SSL/TLS握手。

另外HTTP使用80端口，而HTTPS使用443端口；HTTPS耗费更多服务器资源。

如何解决了HTTP的问题

HTTP是明文存储，存在窃听风险，篡改风险，冒充风险。

HTTPS通过信息加密，校验机制，身份证书解决，具体：

混合加密：保证信息机密性，解决窃听风险。混合加密即对称加密和非对称加密：通信建立前采用非对称加密交换会话密钥，通信过程全部使用对称加密加密明文数据。对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。非对称加密使用两个密钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但是速度慢。

你用锁（非对称加密）把一把钥匙（对称密钥）寄过去，只有朋友能打开锁（只有他有私钥）
接下来你们用这把钥匙通信，聊天内容都上锁（对称加密），别人看不懂。

摘要算法+数字签名：摘要算法即哈希函数，哈希值唯一，且无法通过哈希值推导出内容。它可以保证内容不会被篡改，但是不能保证“内容+哈希值”不会被替换，因为缺少对客户端收到的信息是否来自服务器的证明。比如你可以同时伪造请假说明和家长签字来骗请假。那么就需要非对称加密算法解决：主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份吗，加密内容表示内容本身，因为耗费性能，是对哈希值加密。

原文：我爱Java
摘要：哈希后变成一串64位的码（假设为 abc123）
私钥加密：把 abc123 用私钥加密生成签名
发出去：把“我爱Java” + 签名一起发出
接收方：
用公钥解密签名 → 得到 abc123
对“我爱Java”再哈希 → 也是 abc123
二者相同 → OK，没改过，确实是发的人发的

数字证书：公钥可能被伪造，所以缺少身份验证的环节。通过一个权威机构证明身份（CA），只要证书可信，那么公钥可信。

如果你同时伪造请假说明和家长签字来骗请假的方法被数字签名解决了，也就是家长和老师分别持有私钥和公钥，但是你也可以掉包两方的公私钥，那么家长可以把个人信息在警察局注册成数字证书「个人信息 + 公钥 + 数字签名」，那么老师拿到证书可以去警察局验证是否合法来判断这个公钥是不是家长的。

SSL/TLS 协议

SSL 和 TLS 没有太大的区别。

SSL 指安全套接字协议（Secure Sockets Layer），首次发布与 1996 年。SSL 的首次发布其实已经是他的 3.0 版本，SSL 1.0 从未面世，SSL 2.0 则具有较大的缺陷（DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption）。很快，在 1999 年，SSL 3.0 进一步升级，新版本被命名为 TLS 1.0。因此，TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混称为 SSL/TLS。

工作原理

SSL/TLS 的工作原理可以分为 握手阶段和 数据传输阶段：

1. 握手阶段（Handshake）

握手阶段的目的是在客户端和服务器之间建立一个安全的通信通道。主要过程如下：

客户端发送客户端 Hello：客户端发起连接，向服务器发送支持的加密算法、SSL/TLS 版本号、生成的随机数等信息。
服务器响应服务器 Hello：服务器收到客户端请求后，选择一种双方都支持的加密算法和 SSL/TLS 版本，返回给客户端。服务器还会发送服务器的数字证书（包含公钥）。
客户端验证服务器证书：客户端收到服务器的证书后，会使用证书颁发机构（CA）的公钥验证证书的有效性。如果证书有效，则继续进行，否则会终止连接。
生成密钥（Pre-Master Secret）：客户端生成一个对称加密密钥（称为 Pre-Master Secret），用服务器的公钥加密后发送给服务器。只有服务器才能解密得到这个密钥。
双方生成会话密钥：客户端和服务器根据 Pre-Master Secret 和双方各自的随机数，通过密钥交换算法（如 Diffie-Hellman）生成相同的会话密钥。这个密钥用于后续的数据加密。
客户端和服务器交换 Finished 消息：双方使用对称加密算法（如 AES）生成的会话密钥来加密后续的通信内容。在发送完握手消息后，握手阶段完成。

2. 数据传输阶段（Data Transfer）

在数据传输阶段，客户端和服务器使用对称加密来保护数据传输的机密性，确保数据不被第三方篡改或窃取。过程如下：

数据会使用之前交换的 会话密钥 进行加密传输。
每次数据传输时，SSL/TLS 会生成一个 消息认证码（MAC） 来验证数据的完整性，防止数据在传输过程中被修改。

如何建立连接

SSL/TLS协议流程：1，客户端向服务器索要并验证服务器的公钥，2，双方协商生产「会话秘钥」，3，双方采用「会话秘钥」进行加密通信。前两个阶段就是TLS握手阶段。

TLS握手涉及四次通信，现在常用的密钥交换算法有两种：RSA算法和ECDHE算法。

TLS 协议建立详细流程：

1，ClientHello：客户端向服务器发起ClientHello加密通信请求，发送了客户端支持的TLS协议版本 + 客户端生产的随机数(用来生成对话密钥) + 支持的密码套件系列(加密算法)

2，SeverHello：服务器做出响应，发送确认TLS协议版本(不支持该版本就关闭加密通信) + 服务器生产的随机数(用来生成对话密钥) + 确认密码套件系列 + 服务器的数字证书

3，客户端回应：客户端收到回应后，先通过浏览器/操作系统的CA公钥确认数字证书真实性，随后从数字证书取出服务器公钥，使用它加密报文，向服务器发送一个随机数(pre-master key,会被服务器公钥加密) + 加密通信算法改变通知(“随后的信息都将用「会话秘钥」加密通信”) + 客户端握手结束通知。同时把之前所有内容的发生的数据做摘要，原来供服务端校验。

双方使用三个随机数用协商的加密算法各自生成本次通信的会话密钥。

4，服务器最后回应：加密通信算法改变通知 + 握手结束通知

至此握手阶段结束，进入加密通信，完全使用HTTP协议，只不过使用会话密钥加密内容。

CA 签发证书的过程：1，CA把持有者公钥、用途、颁发者、有效时间等信息打包成一个包，对这些信息进行HASH计算，2，CA使用私钥将该hash值加密，生成Certificate Signature，也就是CA对证书进行了签名，3，将 Certificate Signature 添加在文件证书上，形成数字证书。

客户端校验服务端的数字证书的过程：1，客户端使用同样的Hash算法获取证书Hash值H1，2，通常浏览器和操作系统集成了CA公钥信息，浏览器收到证书后可以使用CA公钥解密Certificate Signature，得到哈希值H2，3，对比H1和H2，如果值相同则可信。

证书信任链问题：因为我们向CA申请的证书一般不是根证书，而是中间证书。1，当客户端收到证书后，发现签发者不是根证书，那就根据证书的签发者找到是“xx中间证书”，向CA请求中间证书，然后发现“xx中间证书”是“xx根证书CA”签发的，也就是说它是根证书，也就是自签证书。应用软件会检查此证书是否已经预载于根证书清单。如果有根证书，则用根证书公钥验证中间证书，通过后再用中间证书去验证收到的证书，依然通过后就可以信任。

为什么要有证书链：为了保证根证书的绝对安全，将根证书隔离，防止根证书失守导致整个信任链路的崩塌。

如何保证数据完整性

TLS分为握手协议和记录协议：握手协议即四次握手，负责协商加密算法和生成对应密钥；记录协议负责保护应用程序数据并验证完整性和来源。

记录协议：主要负责消息的压缩，加密，数据认证：1，消息被分割成多个较短的片段,然后分别对每个片段进行压缩；2，压缩后的片段会加上消息认证码(MAC)，这一步是为了保证完整性，及进行数据认证。同时为了防止重放攻击，在计算消息认证码时还加上了片段编码；3，片段再加上消息认证码会一起通过对称密码进行加密；4，经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头就是最终的报文数据。5，报文数据将传递到传输控制协议 (TCP) 层进行传输。

HTTPS一定安全吗(场景题)

3.1 HTTP 常见面试题 | 小林coding

HTTPS如何优化

3.5 HTTPS 如何优化？ | 小林coding

为什么抓包工具能截取 HTTPS 数据？

工作原理与中间人一致，在服务端面前作为客户端，因为服务端不会校验客户端身份；在客户端面前作为服务端，因为它持有客户端的信任，也就是拥有对应域名的私钥。

客户端会往受系统信任的根证书列表导入抓包工具生成的证书，这个证书会被浏览器信任。

如何避免被中间人抓取数据

保证电脑安全；不点击证书非法的网站；HTTPS双向认证

HTTPS双向认证：一般的HTTPS是单向认证，服务端不会验证客户端身份。双向认证中客户端也有数字证书，并且提供给服务器，服务器要校验客户端身份。

WebSocket

WebSocket 是一种基于 TCP 连接的全双工通信协议，即客户端和服务器可以同时发送和接收数据。WebSocket 协议本质上是应用层的协议，用于弥补 HTTP 协议在持久通信能力上的不足。客户端和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

WebSocket继承了TCP 协议的全双工，并且解决了粘包的问题，因为它有明确的消息边界，每条信息都加了帧头，能让接收端准确解析完整消息。

使用场景：适用于需要服务器和客户端频繁交互的大部分场景

WebSocket vs HTTP

WebSocket 是一种双向实时通信协议，而 HTTP 是一种单向通信协议。并且，HTTP 协议下的通信只能由客户端发起，服务器无法主动通知客户端。

WebSocket 使用 ws:// 或 wss://（使用 SSL/TLS 加密后的协议，类似于 HTTP 和 HTTPS 的关系）作为协议前缀，HTTP 使用 http:// 或 https:// 作为协议前缀。

WebSocket 可以支持扩展，用户可以扩展协议，实现部分自定义的子协议，如支持压缩、加密等。

WebSocket 通信数据格式比较轻量，用于协议控制的数据包头部相对较小，网络开销小，而 HTTP 通信每次都要携带完整的头部，网络开销较大（HTTP/2.0 使用二进制帧进行数据传输，还支持头部压缩，减少了网络开销）。

WebSocket vs 长、短轮询

1.短轮询（Short Polling）

原理：客户端每隔固定时间（如 5 秒）发起一次 HTTP 请求，询问服务器是否有新数据。服务器收到请求后立即响应。
优点：实现简单，兼容性好，直接用常规 HTTP 请求即可。
缺点
- 实时性一般：消息可能在两次轮询间到达，用户需等到下次请求才知晓。
- 资源浪费大：反复建立/关闭连接，且大多数请求收到的都是“无新消息”，极大增加服务器和网络压力。

2.长轮询（Long Polling）

原理：客户端发起请求后，若服务器暂时无新数据，则会保持连接，直到有新数据或超时才响应。客户端收到响应后立即发起下一次请求，实现“伪实时”。
优点
- 实时性较好：一旦有新数据可立即推送，无需等待下次定时请求。
- 空响应减少：减少了无效的空响应，提升了效率。
缺点
- 服务器资源占用高：需长时间维护大量连接，消耗服务器线程/连接数。
- 资源浪费大：每次响应后仍需重新建立连接，且依然基于 HTTP 单向请求-响应机制。

3. WebSocket

原理：客户端与服务器通过一次 HTTP Upgrade 握手后，建立一条持久的 TCP 连接。之后，双方可以随时、主动地发送数据，实现真正的全双工、低延迟通信。
优点
- 实时性强：数据可即时双向收发，延迟极低。
- 资源效率高：连接持续，无需反复建立/关闭，减少资源消耗。
- 功能强大：支持服务端主动推送消息、客户端主动发起通信。
缺点
- 使用限制：需要服务器和客户端都支持 WebSocket 协议。对连接管理有一定要求（如心跳保活、断线重连等）。
- 实现麻烦：实现起来比短轮询和长轮询要更麻烦一些。

WebSocket vs SSE

SSE (Server-Sent Events) 和 WebSocket 都是用来实现服务器向浏览器实时推送消息的技术，让网页内容能自动更新，而不需要用户手动刷新。虽然目标相似，但它们在工作方式和适用场景上有几个关键区别：

通信方式:
- SSE: 单向通信。只有服务器能向客户端（浏览器）发送数据。客户端不能通过同一个连接向服务器发送数据（需要发起新的 HTTP 请求）。
- WebSocket: 双向通信 (全双工)。客户端和服务器可以随时互相发送消息，实现真正的实时交互。
底层协议:
- SSE: 基于标准的 HTTP/HTTPS 协议。它本质上是一个“长连接”的 HTTP 请求，服务器保持连接打开并持续发送事件流。不需要特殊的服务器或协议支持，现有的 HTTP 基础设施就能用。
- WebSocket: 使用独立的 ws:// 或 wss:// 协议。它需要通过一个特定的 HTTP "Upgrade" 请求来建立连接，并且服务器需要明确支持 WebSocket 协议来处理连接和消息帧。
实现复杂度和成本:
- SSE: 实现相对简单，主要在服务器端处理。浏览器端有标准的 EventSource API，使用方便。开发和维护成本较低。
- WebSocket: 稍微复杂一些。需要服务器端专门处理 WebSocket 连接和协议，客户端也需要使用 WebSocket API。如果需要考虑兼容性、心跳、重连等，开发成本会更高。
断线重连:
- SSE: 浏览器原生支持。EventSource API 提供了自动断线重连的机制。
- WebSocket: 需要手动实现。开发者需要自己编写逻辑来检测断线并进行重连尝试。
数据类型:
- SSE: 主要设计用来传输文本 (UTF-8 编码)。如果需要传输二进制数据，需要先进行 Base64 等编码转换成文本。
- WebSocket: 原生支持传输文本和二进制数据，无需额外编码。

为了提供更好的用户体验和利用其简单、高效、基于标准 HTTP 的特性，Server-Sent Events (SSE) 是目前大型语言模型 API（如 OpenAI、DeepSeek 等）实现流式响应的常用甚至可以说是标准的技木选择。

如何建立连接

客户端提供HTTP发送一个带有特殊头部的HTTP请求，请求升级为WebSocket协议；服务器如果支持WebSocket会返回101表示协议升级成功；HTTP通道升级为WebSocket连接，后续变成全双工的持久连接。

工作过程

WebSocket 的工作过程可以分为以下几个步骤：

客户端向服务器发送一个 HTTP 请求，请求头中包含 Upgrade: websocket 和 Sec-WebSocket-Key 等字段，表示要求升级协议为 WebSocket；
服务器收到这个请求后，会进行升级协议的操作，如果支持 WebSocket，它将回复一个 HTTP 101 状态码，响应头中包含，Connection: Upgrade和 Sec-WebSocket-Accept: xxx 等字段、表示成功升级到 WebSocket 协议。
客户端和服务器之间建立了一个 WebSocket 连接，可以进行双向的数据传输。数据以帧（frames）的形式进行传送，WebSocket 的每条消息可能会被切分成多个数据帧（最小单位）。发送端会将消息切割成多个帧发送给接收端，接收端接收消息帧，并将关联的帧重新组装成完整的消息。
客户端或服务器可以主动发送一个关闭帧，表示要断开连接。另一方收到后，也会回复一个关闭帧，然后双方关闭 TCP 连接。

另外，建立 WebSocket 连接之后，通过心跳机制来保持 WebSocket 连接的稳定性和活跃性。

消息格式

数据包在WebSocket叫做帧，主要关注以下字段：

opcode字段：标志数据帧的类型，比如1是text(String)，2是二进制数据类型([]byte)，8关闭连接

payload字段：存放想要传输的数据的长度(单位：字节)

payload data字段：真正要传输的数据

DNS

DNS（Domain Name System）域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是域名和 IP 地址的映射问题。

目前 DNS 的设计采用的是分布式、层次数据库结构，DNS 是应用层协议，它可以在 UDP 或 TCP 协议之上运行，端口为 53 。

DNS 服务器

DNS 服务器自底向上可以依次分为以下几个层级(所有 DNS 服务器都属于以下四个类别之一):

根 DNS 服务器。根 DNS 服务器提供 TLD 服务器的 IP 地址。目前世界上只有 13 组根服务器，我国境内目前仍没有根服务器。
顶级域 DNS 服务器（TLD 服务器）。顶级域是指域名的后缀，如com、org、net和edu等。国家也有自己的顶级域，如uk、fr和ca。TLD 服务器提供了权威 DNS 服务器的 IP 地址。
权威 DNS 服务器。在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的 DNS 记录，这些记录将这些主机的名字映射为 IP 地址。
本地 DNS 服务器。每个 ISP（互联网服务提供商）都有一个自己的本地 DNS 服务器。当主机发出 DNS 请求时，该请求被发往本地 DNS 服务器，它起着代理的作用，并将该请求转发到 DNS 层次结构中。严格说来，不属于 DNS 层级结构

世界上并不是只有 13 台根服务器，这是很多人普遍的误解，网上很多文章也是这么写的。实际上，现在根服务器数量远远超过这个数量。最初确实是为 DNS 根服务器分配了 13 个 IP 地址，每个 IP 地址对应一个不同的根 DNS 服务器。然而，由于互联网的快速发展和增长，这个原始的架构变得不太适应当前的需求。为了提高 DNS 的可靠性、安全性和性能，目前这 13 个 IP 地址中的每一个都有多个服务器，截止到 2023 年底，所有根服务器之和达到了 1700 多台，未来还会继续增加。

DNS解析过程/工作流程

DNS（域名系统）是将人类可读的域名（如 www.example.com）转换为计算机可识别的 IP 地址（如 192.168.1.1）的系统。DNS 的工作流程如下：

1. 用户输入网址

当用户在浏览器中输入一个网址（如 www.example.com）时，浏览器首先需要通过 DNS 解析该域名对应的 IP 地址，以便与目标服务器建立连接。

2. 本地 DNS 缓存查询

浏览器会首先检查本地缓存中是否已有该域名的 IP 地址。如果有且未过期，直接使用该 IP 地址进行连接。

3. 操作系统查询本地 DNS 缓存

如果浏览器缓存中没有，操作系统会查看本地 DNS 缓存是否存有对应记录。如果找到，返回结果；如果没有，继续向外部 DNS 服务器查询。

4. 向递归 DNS 服务器发送请求

如果本地缓存中也没有找到，操作系统会将请求发送到 递归 DNS 服务器（通常由 ISP 提供或配置的公共 DNS 服务器，如 Google DNS）。

5. 递归查询过程

递归 DNS 服务器接到请求后，会从根域名服务器开始查询，逐步向下查询，直到找到目标域名对应的 IP 地址。递归查询的步骤如下：

根域名服务器：负责指向负责顶级域（TLD）的 DNS 服务器，如 .com、.org 等。
顶级域（TLD）服务器：负责指向对应域名的权威 DNS 服务器，通常是由域名注册商提供的服务器。
权威 DNS 服务器：最终提供该域名对应的 IP 地址的服务器。

6. 返回 IP 地址

递归 DNS 服务器获取到目标域名的 IP 地址后，会将结果返回给操作系统，再由操作系统返回给浏览器。

7. 浏览器发起连接

浏览器通过获得的 IP 地址，发起与目标服务器的连接，开始数据交换。

DNS报文格式

DNS 报文分为查询和回答报文，两种形式的报文结构相同。

标识符。16 比特，用于标识该查询。这个标识符会被复制到对查询的回答报文中，以便让客户用它来匹配发送的请求和接收到的回答。
标志。1 比特的”查询/回答“标识位，0表示查询报文，1表示回答报文；1 比特的”权威的“标志位（当某 DNS 服务器是所请求名字的权威 DNS 服务器时，且是回答报文，使用”权威的“标志）；1 比特的”希望递归“标志位，显式地要求执行递归查询；1 比特的”递归可用“标志位，用于回答报文中，表示 DNS 服务器支持递归查询。
问题数、回答 RR 数、权威 RR 数、附加 RR 数。分别指示了后面 4 类数据区域出现的数量。
问题区域。包含正在被查询的主机名字，以及正被询问的问题类型。
回答区域。包含了对最初请求的名字的资源记录。在回答报文的回答区域中可以包含多条 RR，因此一个主机名能够有多个 IP 地址。
权威区域。包含了其他权威服务器的记录。
附加区域。包含了其他有帮助的记录。

DNS 劫持

DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址，从而导致用户无法访问正常的网站，或者被引导到恶意的网站。DNS 劫持有时也被称为 DNS 重定向、DNS 欺骗或 DNS 污染。

TCP

是面向连接的(必须一对一)、可靠的(保证一个报文一定到达接收端)、基于字节流(粘/拆包的“罪魁祸首”)的传输层通信协议

TCP 连接由四元组唯一标识：源 IP + 源端口 + 目标 IP + 目标端口

为什么要有TCP：IP层是不可靠的，不保证网络包的交付、按序交付、也不保证网络包的数据的完整性。那么就需要上层TCP协议来负责。TCP是一个工作在传输层的可靠数据传输的服务。

TCP头格式：序列号（解决网络包乱序问题），确认应答号（解决丢包问题），控制位

TCP vs UDP

1，连接，TCP传输数据需要先建立连接；UDP不需要连接，即刻传输数据

2，服务对象，TCP一对一；UDP支持一对一，一对多，多对多

3，可靠性，TCP是可靠交付数据的，确保无差错不丢失不重复按序到达；UDP是尽可能交付，不保证可靠（但是可以改造，比如QUIC）

4，拥塞控制、流量控制，TCP有拥塞控制和流量控制机制，保证数据的安全性；但是UDP都没有，网络非常拥堵也不影响UDP发送速率

5，首部开销，TCP首部较长，有一定开销；UDP首部只有8字节且固定不变

6，传输方式，TCP是流式传输，没有边界，但保证顺序；UDP是一个包一个包发送，有边界但是可能丢包和乱序

7，分片不同，TCP如果数据大小大于MSS，会在传输层分片，目标机也会在传输层组装，中途丢失一个只需要传输缺失的；UDP如果数据大小大于MSS，流程一样但是都是在IP层

8，应用，TCP常用于FTP文件传输，HTTP/HTTPS；UDP常用于较少通信，视频等多媒体通信，广播通信

选择 TCP 还是 UDP，主要取决于你的应用对数据传输的可靠性要求有多高，以及对实时性和效率的要求有多高。

当数据准确性和完整性至关重要，一点都不能出错时，通常选择 TCP。因为 TCP 提供了一整套机制（三次握手、确认应答、重传、流量控制等）来保证数据能够可靠、有序地送达。典型应用场景如下：

Web 浏览 (HTTP/HTTPS): 网页内容、图片、脚本必须完整加载才能正确显示。
文件传输 (FTP, SCP): 文件内容不允许有任何字节丢失或错序。
邮件收发 (SMTP, POP3, IMAP): 邮件内容需要完整无误地送达。
远程登录 (SSH, Telnet): 命令和响应需要准确传输。

当实时性、速度和效率优先，并且应用能容忍少量数据丢失或乱序时，通常选择 UDP。UDP 开销小、传输快，没有建立连接和保证可靠性的复杂过程。典型应用场景如下：

实时音视频通信 (VoIP, 视频会议, 直播): 偶尔丢失一两个数据包（可能导致画面或声音短暂卡顿）通常比因为等待重传（TCP 机制）导致长时间延迟更可接受。应用层可能会有自己的补偿机制。
在线游戏: 需要快速传输玩家位置、状态等信息，对实时性要求极高，旧的数据很快就没用了，丢失少量数据影响通常不大。
DHCP (动态主机配置协议): 客户端在请求 IP 时自身没有 IP 地址，无法满足 TCP 建立连接的前提条件，并且 DHCP 有广播需求、交互模式简单以及自带可靠性机制。
物联网 (IoT) 数据上报: 某些场景下，传感器定期上报数据，丢失个别数据点可能不影响整体趋势分析。

三次握手

TCP 三次握手和四次挥手（传输层） | JavaGuide

为了确保双方接收和发送能力都正常，建立一条可靠的全双工通信通道

1，客户端向服务器发送SYN报文段，请求建立连接，报文包含客户端生成的初始序列号（seq = x），客户端进入SYN_SENT状态

2，服务器向客户端回复SYN+ACK表示同意连接请求，报文包含确认号（ack = x + 1）和自己的初始序列号（seq = y），服务器进入SYN_RECEIVED 状态

3，客户端再向服务器发送ACK报文段，报文包含（ack = y + 1），客户端进入ESTABLISHED 状态，服务器收到后也进入ESTABLISHED 状态，连接正式建立

注：第三次握手可以顺便携带应用层数据，虽然不常见，但是协议允许；前两次不行，因为未完全建立连接，不安全

为什么要三次？

TCP 采用三次握手建立连接，是为了确保双方都具备发送和接收能力，同时同步双方的初始序列号。更重要的是，第三次握手可以有效防止网络中旧的连接请求被误当成新连接，从而避免服务端错误分配资源，提升连接安全性与可靠性。

当握手丢失了会发生什么：

当第一次握手丢失：当客户端一直收不到第二次握手的回应，会触发超时重传机制，重新发送报文，并且与之前的序列号一样。（每次重传的超时时间是上次的2倍）

当第二次握手丢失：因为第二次丢失对客户端的影响一样，所以也会触发上面的操作。同时对于服务器自然也收不到第三次握手，那么服务端会重传 SYN-ACK 报文，也就是第二次握手的超时重传。

当第三次握手丢失：服务端会重传 SYN-ACK 报文，当服务器重传到最大重传次数就断开连接。ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文。

为什么每次建立TCP连接初始化的序列号都要求不一样？

是为了防止旧数据混入新连接、避免重放攻击，并确保每个连接的独立性和安全性。

假设你第一次和服务器建立连接时，序列号为 0，并传输了数据。后来，连接关闭了，但是某些数据包在网络中滞留。然后你再次建立连接，如果序列号没有变化，滞留的旧数据可能会被服务器误认为是新连接的数据，导致数据混淆或错误处理。通过随机化序列号，服务器可以确保新连接的序列号与旧连接的序列号不同，从而避免这个问题。

并且攻击者可以猜测和伪造数据包，进行TCP 重放攻击。

ISN序列号是怎么随机产生的？

TCP 的初始序列号 ISN 是通过系统内核根据时间和连接信息计算出的伪随机数，确保每次连接的序列号不同且难以被攻击者预测，从而保障连接的正确性和安全性。

如Linux是随着时间每 4 微秒递增的全局计数器 + 基于本地地址、远程地址、端口、时间戳等信息的哈希函数。

四次挥手

四次挥手是 TCP 双方各自独立关闭发送通道的过程，确保数据传输完整、有序关闭连接，其中 FIN 表示主动关闭，ACK 表示确认关闭。

1，客户端向服务器发送FIN报文段，表示没有数据要发送，但是还能接收数据，进入FIN_WAIT_1状态

2，服务器向客户端发送ACK报文段，表示知道客户端不发数据了，进入CLOSE_WAIT状态

3，客户端收到ACK报文后进入FIN_WAIT_2状态，此时服务器仍然可能继续发送数据，服务器发送完数据后发送FIN报文，表示没有数据要发了，进入LAST_ACK状态

4，客户端收到FIN后发送ACK确认，进入TIME_WAIT状态，等待2*MSL后关闭连接，服务端收到ACK后也关闭连接

双方都可以主动断开连接，但是主动关闭连接的，才有 TIME_WAIT 状态

为什么需要四次挥手：服务端通常要等待完成数据的发送和处理，所以服务端的ACK和FIN一般分开发送，因此是四次挥手。

如果服务器回复ACK的同时，自己也准备断开连接，那么第二三次挥手会合并成一个同时带有ACK和FIN的报文，那么就只需要三次挥手。

挥手丢失：

第一次挥手丢失：客户端迟迟收不到服务端ACK，触发超时重传，重发报文，重发次数超过tcp_orphan_retries后会等待一段时间( *=2 )，如果还是没有收到就直接进入close状态

第二次挥手丢失：ACK 报文是不会重传的，客户端重复第一次挥手丢失的操作

注：当客户端处于FIN_WAIT2状态等服务端发送第三次挥手的时候，如果你使用的close()关闭连接，FIN_WAIT2 状态最多持续 tcp_fin_timeout 秒（默认 60 秒）；但如果用 shutdown() 只关闭发送方向，tcp_fin_timeout 不生效，连接可能永远停在 FIN_WAIT2 状态，造成资源泄漏。

第三次挥手丢失：客户端一直停在 FIN_WAIT2 状态，等不到第三次挥手，若客户端使用 close()，tcp_fin_timeout 参数会控制 FIN_WAIT2 的最大时长。服务端会在超时重传 FIN 报文，重传超出系统设定的上限关闭连接

第四次挥手丢失：客户端收到FIN报文后进入TIME_WAIT状态。在 Linux 系统，TIME_WAIT 状态会持续 2MSL 后才会进入关闭状态。但是服务器没有收到ACK报文，重复第三次挥手丢失的操作(重传+断开连接)。这个时候如果客户端又收到了超时重传的FIN，就会重置定时器，等待2MSL时长，断开连接。

如何保证传输的可靠性

TCP 通过一系列机制来保证数据传输的可靠性。首先，TCP 是面向连接的协议，在传输前必须建立一个可靠的连接，即 三次握手，保证双方能够通信。数据传输过程中，TCP 会使用 序列号 和 确认号 来确保数据按顺序到达。

具体来说，TCP 保证可靠性的方式包括：

数据分段与重组：大数据会被分割成小数据包传输，每个数据包都有序列号，接收方可以按序号重新组合数据，确保数据的顺序性。
确认机制：每当接收方收到数据包时，都会向发送方发送一个确认消息，告诉发送方自己已成功接收到数据。
重传机制：如果发送方没有在规定时间内收到确认消息，或者接收到的确认号不符合预期，TCP 会重新发送未确认的数据包，确保数据不丢失。
流量控制：通过滑动窗口机制，TCP 控制发送方的数据发送速度，避免接收方处理不过来导致丢包。
拥塞控制：通过算法如慢开始、拥塞避免、快速重传等，TCP 在网络出现拥塞时，动态调整发送速率，避免网络负载过重导致的数据丢失。

这些机制共同作用，确保了 TCP 数据传输的可靠性。

如何实现流量控制？

TCP 实现流量控制的主要机制是 滑动窗口。流量控制的目的是防止发送方发送的数据超过接收方的处理能力，避免数据丢失。

具体来说，TCP 通过以下方式实现流量控制：

接收窗口：每个 TCP 连接都有一个接收窗口，表示接收方的缓存空间大小。接收方通过 窗口大小 告诉发送方自己当前能接受的最大数据量。窗口的大小会动态变化，反映接收方的处理能力和缓冲区空间。
滑动窗口机制：发送方根据接收方反馈的窗口大小来控制数据的发送量。接收方窗口的大小决定了发送方能在没有确认的情况下发送的数据量。窗口的滑动意味着随着接收方处理完部分数据，接收窗口逐渐“打开”，发送方可以继续发送更多数据。
调整发送速率：如果接收方的窗口大小变小（比如缓冲区已满），发送方会减少数据发送的速率，避免产生溢出或丢包。

通过滑动窗口机制，TCP 能够根据接收方的处理能力动态调整发送的数据量，确保数据传输不会因为接收方处理能力不足而丢失或造成过载。

拥塞控制是怎么实现的

TCP 的拥塞控制通过动态调整数据发送速率来避免网络拥塞，确保网络的稳定性。TCP 使用了四种主要的拥塞控制算法：

慢启动（Slow Start）：当连接开始时，TCP 发送方会将拥塞窗口设置为一个较小的值（通常是 1 或 2 个最大段大小 MSS）。每当收到一个确认（ACK），拥塞窗口就增加 1 个 MSS，直到达到一个阈值，进入后续阶段。慢启动的目的是迅速探测网络的带宽，避免初期发送过多数据导致拥塞。
拥塞避免（Congestion Avoidance）：当拥塞窗口大小超过慢启动阈值时，进入拥塞避免阶段。此时，TCP 不再以指数增长的方式增加窗口，而是采用线性增长。每收到一个确认，窗口增大 1/MSS，窗口增大速度减缓，以避免过快增加负载导致拥塞。
快速重传（Fast Retransmit）：当发送方连续收到 3 个重复的 ACK 时，表示某个数据包丢失了。此时，TCP 立即重传丢失的数据包，而无需等待超时，从而减少了重传的延迟。
快速恢复（Fast Recovery）：在快速重传后，TCP 进入快速恢复阶段。此时，拥塞窗口大小被设置为丢失数据包时窗口大小的一半，继续通过线性增长的方式进行拥塞避免。这使得 TCP 可以迅速恢复并继续传输数据，而不是重新进入慢启动阶段。

TIME_WAIT状态

为什么TIME_WAIT的等待时间是2MSL？

同样也是**为什么要有TIME_WAIT，不能发送ACK后直接断开？**的原因

MSL是报文最大生存时间；

1，防止因为第四次挥手的ACK丢失导致对方收不到ACK；2，防止旧连接报文干扰新连接：双方都不再发数据，但是不能保证数据都已经送达，所以会有旧数据在网络中，如果新连接使用了相同的四元组（IP+端口），旧包到达时可能被错误当作新连接的数据，等待2MSL是为了确保数据包彻底过期。

过多连接处于TIME-WAIT 状态有什么危害？

占用系统资源；占用端口资源；

如何优化TIME_WAIT

4.1 TCP 三次握手与四次挥手面试题 | 小林coding

SYN攻击

4.1 TCP 三次握手与四次挥手面试题 | 小林coding

为什么 TCP 层还需要 MSS ？

IP不是会分片吗，那还要MSS干什么：

IP分片的代价非常大，完整TCP报文被拆成多个多个 IP 数据包，每个包都要独立封装、发送、路由，增加了处理开销；如果一个分片丢了，那么整个报文都要重传。并且分片可能走不同路径，容易丢/乱序；重组由接收端 IP 层完成，增加 CPU 和内存负担；IP 分片可以被利用进行攻击，比如“分片重组攻击”或“DoS 攻击”

所以TCP的MSS的目的就在于主动避免IP分片：发送方会控制每个 TCP 报文段大小不超过对方的 MSS，从而尽量避免 IP 层发生分片。

UDP

IP

IP（Internet Protocol，网际协议） 是 TCP/IP 协议中最重要的协议之一，属于网络层的协议，主要作用是定义数据包的格式、对数据包进行路由和寻址，以便它们可以跨网络传播并到达正确的目的地。

IP地址

IP 地址（Internet Protocol Address）是 分配给每台网络设备的唯一标识，用于在网络中定位和通信。

IP 地址有两种类型：

IPv4：常见的格式是 xxx.xxx.xxx.xxx，每段 0~255，共 32 位，最多约 42 亿个地址，目前已趋近枯竭。
IPv6：为解决 IPv4 地址不足，IPv6 使用 128 位地址，格式如 2001:0db8:85a3::8a2e:0370:7334，地址空间几乎无限。

IP地址过滤

IP 地址过滤（IP Address Filtering） 简单来说就是限制或阻止特定 IP 地址或 IP 地址范围的访问。例如，你有一个图片服务突然被某一个 IP 地址攻击，那我们就可以禁止这个 IP 地址访问图片服务。

IP 地址过滤是一种简单的网络安全措施，实际应用中一般会结合其他网络安全措施，如认证、授权、加密等一起使用。单独使用 IP 地址过滤并不能完全保证网络的安全。

IP 寻址

寻址流程简要描述：

检查是否是同一网段：发送方通过子网掩码判断目标 IP 是否与自己处于同一网段。
- 如果是：直接通过局域网 ARP 协议获取目标设备的 MAC 地址，完成通信。
- 如果不是：将数据包交给默认网关（通常是路由器）转发。
路由转发：如果目标 IP 不在本地网段，数据包会被交给路由器，路由器根据自己的路由表决定下一跳，将数据一跳一跳转发，直到到达目标网络。
最终送达主机：到达目标网络后，最后一跳路由器使用 ARP 找到目标主机的 MAC 地址，完成局域网传输。

IPv4 vs IPv6

主要区别

IPv4 和 IPv6 是两种不同版本的 IP 协议，它们的主要区别如下：

地址长度不同
- IPv4 使用 32 位地址，以点分十进制表示，如 192.168.0.1，最多约 42 亿个地址；
- IPv6 使用 128 位地址，以冒号分隔的十六进制表示，如 2001:0db8::1，地址空间几乎无限。
地址耗尽问题
- IPv4 地址数量有限，已接近枯竭；
- IPv6 地址极其丰富，可满足未来长期需求。
报文结构不同
- IPv6 头部更简洁，设计更高效，易于路由器处理；
- IPv4 报文头较复杂，有更多字段。
NAT（地址转换）
- IPv4 中广泛使用 NAT 解决地址不足；
- IPv6 不需要 NAT，每个设备可拥有唯一公网地址。
安全性和功能扩展
- IPv6 内置了 IPsec 加密支持，增强安全性；
- IPv4 支持较弱，依赖额外配置。
部署现状
- IPv4 是当前主流；
- IPv6 正在逐步推广，特别在移动网络和云计算中增长较快。

IPv6主要优势

IPv6 相较于 IPv4，具备以下几个主要优势：

地址空间极大 IPv6 使用 128 位地址，支持约 21282^{128}2128 个地址，几乎可以为地球上每一个设备分配一个全球唯一的公网地址，彻底解决 IPv4 地址枯竭问题。
不再依赖 NAT 由于地址充足，IPv6 允许设备直接通过公网地址通信，避免了 IPv4 中因 NAT 带来的连接复杂、端到端通信受限等问题。
更高效的路由与转发 IPv6 报文头部设计简洁、固定长度，有利于网络设备更快地解析和转发，提高路由效率。
内置安全机制（IPsec） IPv6 原生支持 IPsec 协议，提供端到端的数据加密与身份认证，增强网络通信的安全性。
自动配置支持（无状态地址配置） 设备接入网络时可通过 SLAAC 自动生成 IPv6 地址，无需手动配置或依赖 DHCP，简化网络管理。
更强的扩展性和服务质量支持 IPv6 增强了对多播、QoS（服务质量）、移动性等功能的支持，更适应现代网络应用。

URL

URL（Uniform Resource Locators），即统一资源定位器。

组成结构

协议://主机:端口/路径?查询参数#片段标识
https://www.example.com:443/docs/index.html?lang=en#top

它的组成可以解释为：

协议（Scheme）：https 表示使用的是安全的超文本传输协议；
主机（Host）：www.example.com 是服务器的域名，也可以是 IP 地址；
端口（Port）：443 是服务器监听的端口，HTTPS 的默认端口是 443，HTTP 是 80；
路径（Path）：/docs/index.html 指定服务器上资源的具体位置；
查询参数（Query）：lang=en 是向服务器传递的参数，多个参数用 & 分隔；
片段标识符（Fragment）：#top 用于标识页面中的某个位置，浏览器使用，不会发送给服务器。

URI vs URL

URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

ARQ 协议

ARQ（Automatic Repeat reQuest，自动重传请求）协议是一种用于确保数据传输可靠性的协议，特别是在存在数据丢失或错误的通信环境中。它的核心功能是通过自动请求重传丢失或损坏的数据包，确保数据能够正确、完整地传输。

ARQ 是一种可靠性机制，在传输层（如 TCP）或数据链路层都可能使用。

ARQ 的基本工作原理：

发送方发送数据：发送方将数据分段后发送给接收方。
接收方接收并校验数据：
- 如果数据包没有错误，接收方发送一个确认消息（ACK）给发送方。
- 如果数据包有错误或丢失，接收方会请求重传，通常通过发送负确认消息（NACK）或者不发送确认来表示。
重传机制：如果发送方未收到确认（ACK）或收到负确认（NACK），它会重新发送该数据包，直到数据成功接收并确认。

ARQ 协议的类型：

停等 ARQ（Stop-and-Wait ARQ）：每次只发送一个数据包，必须等待接收方确认后才能发送下一个数据包。简单但效率较低，特别是在高延迟网络中。
连续 ARQ（Continuous ARQ）：发送方可以连续发送多个数据包，接收方确认每个数据包，丢失或错误的数据包才会被重传。常见的实现包括：
- Go-Back-N ARQ：接收方在丢失数据包时会丢弃所有后续数据包，需要重新发送丢失的那个包及其后的所有包。
- Selective Repeat ARQ：只重传丢失或错误的包，其他未丢失的包不受影响。

ARP 协议

ARP（Address Resolution Protocol，地址解析协议）是用于 将网络层的 IP 地址映射到数据链路层的 MAC 地址 的协议。它工作在 数据链路层，在局域网（LAN）中非常重要。

ARP 工作在 TCP/IP 的网络接口层（相当于 OSI 的数据链路层），和 IP 协议配合使用。

ARP 协议的工作原理：

发送 ARP 请求：当主机 A 想与主机 B 通信时，A 已经知道 B 的 IP 地址，但不知道 B 的 MAC 地址。此时，A 会发送一个 ARP 请求广播到局域网，内容是询问“谁拥有这个 IP 地址？”（目标 IP 地址）。
ARP 响应：网络中的所有设备都会收到这个 ARP 请求，但只有目标 IP 地址匹配的设备（主机 B）会进行响应。主机 B 会通过 ARP 响应消息将自己的 MAC 地址告诉主机 A。
缓存 ARP 响应：主机 A 接收到 ARP 响应后，会将主机 B 的 IP 地址 和 MAC 地址 记录到 ARP 缓存中。接下来，A 就可以直接通过记录的 MAC 地址与 B 进行通信，而不需要再次发送 ARP 请求。
ARP 请求与响应的格式：
- ARP 请求和响应都包含发送方和接收方的 IP 地址、MAC 地址等信息。
- ARP 请求是一个广播帧，ARP 响应则是单播的。

ARP 缓存：

ARP 缓存是操作系统用来存储 IP 地址到 MAC 地址映射的表。当需要通信时，系统会查询这个缓存表，避免每次都发送 ARP 请求。如果映射项在缓存中存在且未过期，系统直接使用缓存的 MAC 地址。

ARP 的常见问题：

ARP 欺骗（ARP Spoofing）：恶意用户可以伪造 ARP 响应，将自己的 MAC 地址关联到一个合法的 IP 地址，从而进行 中间人攻击 或数据劫持。ARP 欺骗是局域网中常见的安全隐患之一。

NAT 协议

NAT 协议详解（网络层） | JavaGuide

NAT 是一种 网络地址转换 技术，主要用于 将私有网络中的 IP 地址转换为公有网络中的 IP 地址，或者反之。NAT 主要用于解决 IP 地址不足 和 内部网络隐蔽性 问题，尤其是在 局域网（LAN）与广域网（WAN）之间的通信中。

NAT 运行在网络层附近，但它不是某个数据包中明确标识的协议，更像是网络设备做的“动作”。

NAT 的工作原理：

NAT 通常由路由器或防火墙设备实现。当私有网络中的设备需要访问外部网络时，NAT 会根据预设的规则，对请求包的源地址进行转换，将源地址从私有 IP 地址改为公有 IP 地址，并在返回时进行相反的转换。

私有 IP 地址访问外部网络：内部设备通过私有 IP 地址发起网络请求，NAT 设备（如路由器）接收到请求后，将私有 IP 地址转换为公有 IP 地址，然后将数据包转发到目标服务器。
外部响应转换为私有地址：外部服务器响应时，返回的是公有 IP 地址。NAT 设备通过记录的映射关系（通常是通过 连接跟踪表），将返回的数据包的目标地址转换为相应的私有 IP 地址，并将数据包发送给内部设备。

NAT 的类型：

静态 NAT（Static NAT）：
- 静态 NAT 将一个私有 IP 地址固定映射到一个公有 IP 地址。每个私有 IP 地址对应一个公有 IP 地址，转换是固定的。
- 适用于服务器或固定外部访问的设备。
动态 NAT（Dynamic NAT）：
- 动态 NAT 在私有 IP 地址和公有 IP 地址池之间建立映射。当内部设备需要外部访问时，NAT 从公有 IP 池中分配一个公有 IP 地址。
- 不同的内部设备可以共享同一个公有 IP 地址，适合大多数临时访问场景。
端口地址转换（PAT，Port Address Translation）：
- PAT 是最常见的 NAT 类型，也叫做 NAT Overloading。它允许多个私有 IP 地址共享一个公有 IP 地址。通过不同的端口号来区分不同的连接。
- 比如，多个内部设备（IP 地址）通过同一个公有 IP 地址访问互联网，每个连接使用不同的端口号进行区分。
- 这使得在有限的公有 IP 地址池下，可以支持更多的内部设备访问外部网络。

NAT 的优缺点：

优点：

节省 IP 地址：NAT 可以让多个设备共享一个公有 IP 地址，缓解了 IPv4 地址短缺的问题。
提高安全性：通过隐藏内部网络的 IP 地址，外部网络无法直接访问内部设备，提供了一定的安全性。

缺点：

破坏端到端通信：NAT 会修改 IP 地址和端口号，可能导致一些基于 IP 地址的协议或服务（如 P2P、IPsec 等）出现问题。
复杂性：NAT 需要维护映射表，可能增加网络配置的复杂性，且可能影响某些实时应用（如 VoIP）。

网络攻击

DDOS攻击

分布式拒绝服务。指的是处于不同位置的多个攻击者同时向一个或数个目标发动攻击，是一种分布的、协同的大规模攻击方式。单一的 DoS 攻击一般是采用一对一方式的，它利用网络协议和操作系统的一些缺陷，采用欺骗和伪装的策略来进行网络攻击，使网站服务器充斥大量要求回复的信息，消耗网络带宽或系统资源，导致网络或系统不胜负荷以至于瘫痪而停止提供正常的网络服务。

如何应对：

应对 DDoS 攻击的关键在于提前防御 + 实时检测 + 快速缓解。针对不同类型的 DDoS 攻击，应采取分层防护策略，主要包括以下几方面：

第一，接入层限流与黑名单过滤。 在接入层（如负载均衡器、防火墙或 CDN）对异常流量进行限速、封禁可疑 IP、过滤无效请求。例如 SYN Flood 攻击，可以通过启用 SYN Cookie 或连接速率限制来抵御。

第二，使用抗 DDoS 服务。 对于大规模攻击，企业自身往往难以承受，可以接入第三方抗 DDoS 平台或云厂商的清洗服务，如阿里云、腾讯云、Cloudflare、Akamai 等。这些平台具备大规模流量牵引和清洗能力。

第三，加固服务器和网络架构。 包括部署负载均衡、使用多节点或多机房架构，将服务部署在弹性集群上，提高系统的抗压能力。此外，还可以通过分布式部署和故障转移机制提升可用性。

第四，监控与自动化响应机制。 建立实时流量监控系统，一旦发现突发异常流量或资源占用激增，自动触发报警和限流、切换策略等应急措施，减少人工介入时间。

最后，提前准备应急预案。 针对不同攻击类型制定完整的应急方案，包括隔离攻击源、快速更换 IP、通知上游运营商等操作，确保在攻击发生时可以快速反应。

SYN Flood

SYN Flood 是一种典型的 DDoS 攻击方式，属于资源消耗型攻击，针对的是 TCP 协议的三次握手机制。

在正常的 TCP 建立连接过程中，客户端先发送 SYN 报文，服务器收到后会分配资源并返回 SYN-ACK，最后客户端再发送 ACK，连接才正式建立。

但在 SYN Flood 攻击中，攻击者大量伪造源 IP 的 SYN 请求发送给服务器，而不完成最后一步的 ACK。这样，服务器会不断地为这些“半开连接”分配资源并等待客户端确认，直到连接超时。

当攻击量足够大时，服务器的连接队列（如 TCP 半连接队列）会被填满，导致无法处理新的正常连接，从而使服务陷入瘫痪。

常见防御手段包括：

启用 SYN Cookie，不立刻为半连接分配资源，而是将状态信息编码进初始序列号中，等客户端确认后再真正建立连接。
缩小半连接队列超时时间，减少资源被占时间。
限制单个 IP 的连接频率，防止恶意刷请求。
接入高防或抗 DDoS 服务，将攻击流量在源头进行清洗。

UDP Flood

UDP Flood 是一种基于 UDP 协议的 DDoS 攻击方式，攻击目标是消耗服务器的处理能力和带宽资源。

由于 UDP 是无连接的协议，发送方无需建立连接即可不断发送数据包。因此在 UDP Flood 攻击中，攻击者持续向目标服务器发送大量伪造的 UDP 数据报，通常是随机端口号的数据。服务器在接收到这些请求后，会尝试：

检查目标端口是否开放；
如果端口未开放，还可能返回一个 ICMP 不可达响应。

这种处理会占用大量计算资源和网络带宽，尤其在大流量攻击下，可能导致服务器资源耗尽或网络拥塞，最终导致服务不可用。

防御措施包括：

限制 UDP 速率：在防火墙、网关或操作系统层面配置对 UDP 流量的速率限制。
启用智能流量过滤：通过 DPI（深度包检测）识别异常 UDP 流量特征。
接入抗 DDoS 清洗服务：在云平台或运营商层引流清洗大规模 UDP 攻击流量。
禁用不必要的 UDP 服务：减少攻击面，例如关闭不使用的 TFTP、DNS、NTP 等端口。

HTTP Flood

HTTP Flood 是一种应用层 DDoS 攻击，攻击者伪装成正常用户，通过持续发送大量合法的 HTTP 请求来压垮服务器。

与传统的网络层攻击（如 SYN Flood、UDP Flood）不同，HTTP Flood 不依赖伪造 IP，也不直接消耗带宽，而是通过不断请求目标网站的页面、接口或资源来消耗服务器的 CPU、内存和数据库连接等后端资源。

攻击请求往往看起来非常“正常”，可能是访问首页、搜索接口、提交表单等，这使得它很难通过传统的黑名单或协议规则过滤。

特点：

高隐蔽性：请求形式和路径与正常用户几乎一致；
低带宽高消耗：相比网络层攻击，占带宽不大，但对服务器压力极高；
攻击效果强：容易绕过基础防火墙，直接影响 Web 服务稳定性。

防御手段包括：

行为分析与挑战机制：引入验证码（如图形验证码、JS 校验）过滤掉非人类请求；
接入 Web 应用防火墙（WAF）：识别异常访问行为和请求模式；
使用 CDN 进行缓存和流量缓冲：减少源站压力；
IP/UA 访问频率限制：针对高频访问 IP 做封禁或限流。

DNS Flood

DNS Flood 是一种针对域名系统（DNS）的 DDoS 攻击，攻击者向目标 DNS 服务器发送大量请求，试图耗尽其处理能力，从而导致域名解析服务不可用。

DNS 是互联网的“电话簿”，将域名解析为 IP 地址，一旦 DNS 服务瘫痪，用户将无法访问网站或服务。攻击者通过构造大量合法或伪造的 DNS 查询请求，向目标服务器持续施压，导致其资源耗尽，无法响应正常用户请求。

特点：

目标明确：攻击 DNS 服务，使整个网站不可访问；
速率高、请求轻：单个 DNS 查询数据量小，但高频请求会迅速压垮服务器；
可结合反射放大攻击：攻击者伪造源 IP，将请求发送给开放的 DNS 服务器，使其响应放大后打向目标，效果更猛烈。

防御手段包括：

启用速率限制：限制单位时间内每个 IP 的 DNS 查询次数；
使用 Anycast 和多节点分发：将请求分流到多个地理节点，缓解单点压力；
接入云 DNS 或防护平台：借助第三方清洗服务抵御大规模攻击；
关闭递归查询（对外）：避免 DNS 被用于反射攻击；
缓存优化：提高命中率，减少服务器重复计算压力。

中间人攻击

中间人攻击是一种典型的被动+主动结合的网络攻击方式，攻击者通过“夹在通信双方中间”，拦截、篡改或伪造双方传输的数据，从而窃取敏感信息或干扰通信内容。

这种攻击一般发生在客户端与服务器之间的数据传输过程中，尤其在通信未加密或加密方式被破坏的情况下更容易发生。

常见的中间人攻击方式包括：

Wi-Fi 嗅探：攻击者搭建恶意热点或监听公共 Wi-Fi，截获明文传输数据；
ARP 欺骗：在局域网中伪装为网关，拦截局域网中的通信；
DNS 劫持：篡改域名解析结果，将用户引导到钓鱼网站；
SSL 劫持：伪造证书，欺骗客户端建立“假”的 HTTPS 连接，窃取加密数据。

危害包括：

用户账户、密码、身份证号等敏感信息泄露；
会话被劫持，用户以为自己在和目标网站通信，实际是与攻击者通信；
通信数据被修改，例如转账金额、验证码等。

防御措施：

使用 HTTPS + 合法数字证书，保障通信加密和身份认证；
启用 HSTS（HTTP Strict Transport Security），强制浏览器使用 HTTPS；
验证证书合法性，防止伪造证书欺骗；
避免连接不可信 Wi-Fi 网络，提升客户端安全意识；
在局域网中启用 ARP 防护和网络隔离，防止本地伪造。

TCP重置攻击

TCP 重置攻击是一种利用 TCP 协议特性，强行中断正常连接的攻击方式。

在 TCP 协议中，通信双方通过三次握手建立连接后，通过发送数据并维持状态。而如果任意一方收到一个带有 RST（Reset）标志位的 TCP 报文，就会立即断开连接，释放资源，不再继续通信。

攻击者正是利用这一点，通过伪造源地址、端口以及 TCP 序列号，向通信的一方伪造发送一个 带 RST 标志的 TCP 报文，使其误以为对方要求断开连接，从而造成通信中断。

攻击特点：

无需占用目标资源，只需构造一个伪造的 RST 包即可终止连接；
攻击隐蔽，数据包看起来像合法中断；
高危场景：VPN、数据库、SSH 远程连接、长时间保持的 TCP 连接。

发起条件：

攻击者必须监听到或预测到 TCP 序列号和连接信息（源/目标 IP + 端口号），因此通常在以下场景下可能发生：

攻击者处于局域网或中间网络路径中；
应用未启用加密保护（如 TLS）；
存在信息泄露或默认端口可预测。

防御方式：

使用 TLS/SSL 加密通信，即使连接被断，也能校验完整性，避免数据丢失或伪造；
使用更随机的初始序列号，增加攻击者预测难度；
在防火墙或网关中启用 TCP 检查机制，过滤伪造 RST 包；
启用 IDS/IPS 检测，发现频繁或异常的 RST 包行为。

IP欺骗

IP 欺骗是一种伪造 IP 数据包源地址的攻击技术，攻击者通过将自己的 IP 地址伪装成另一个主机的地址，使得目标主机认为数据包是从一个信任的来源发送的。

在正常的数据传输过程中，数据包的源 IP 地址会告诉接收方是谁发送了数据。而在 IP 欺骗中，攻击者伪造源 IP 地址，使得接收方误以为数据来自可信的源。

IP 欺骗的目的：

隐藏真实身份：攻击者可以隐藏自己的身份，避免被追踪。
绕过身份验证：通过伪装成受信任的主机，突破防火墙或安全认证机制。
发起其他攻击：例如 SYN Flood、DDoS 攻击等，攻击者利用伪造的 IP 地址将流量分散或隐藏攻击来源。

攻击特点：

伪造简单：攻击者只需要修改数据包的源 IP 地址即可。
难以追踪：由于源 IP 地址被伪造，目标无法直接追踪到攻击者的真实位置。
依赖于网络拓扑和协议漏洞：攻击通常针对特定协议（如 TCP）和网络环境进行，利用目标网络的特定漏洞。

防御手段：

启用入站和出站过滤（ACL）：通过访问控制列表（ACL）限制不可信的 IP 地址。
启用 IPsec：通过加密和认证机制确保通信的真实性和完整性。
使用反向路径过滤（RPF）：检查返回路径，确保接收到的 IP 地址是合法的。
数据包完整性验证：使用防火墙和 IDS/IPS 系统，检测和阻止伪造的数据包。

其他

MAC 地址

MAC 地址的全称是 媒体访问控制地址（Media Access Control Address）。如果说，互联网中每一个资源都由 IP 地址唯一标识（IP 协议内容），那么一切网络设备都由 MAC 地址唯一标识。

MAC 地址的长度为 6 字节（48 比特），地址空间大小有 280 万亿之多（$2^{48}$），MAC 地址由 IEEE 统一管理与分配，理论上，一个网络设备中的网卡上的 MAC 地址是永久的。不同的网卡生产商从 IEEE 那里购买自己的 MAC 地址空间（MAC 的前 24 比特），也就是前 24 比特由 IEEE 统一管理，保证不会重复。而后 24 比特，由各家生产商自己管理，同样保证生产的两块网卡的 MAC 地址不会重复。

MAC 地址具有可携带性、永久性，身份证号永久地标识一个人的身份，不论他到哪里都不会改变。而 IP 地址不具有这些性质，当一台设备更换了网络，它的 IP 地址也就可能发生改变，也就是它在互联网中的定位发生了变化。

最后，记住，MAC 地址有一个特殊地址：FF-FF-FF-FF-FF-FF（全 1 地址），该地址表示广播地址。

PING

PING 命令是一种常用的网络诊断工具，经常用来测试网络中主机之间的连通性和网络延迟。

PING 命令的输出结果通常包括以下几部分信息：

ICMP Echo Request（请求报文）信息：序列号、TTL（Time to Live）值。
目标主机的域名或 IP 地址：输出结果的第一行。
往返时间（RTT，Round-Trip Time）：从发送 ICMP Echo Request（请求报文）到接收到 ICMP Echo Reply（响应报文）的总时间，用来衡量网络连接的延迟。
统计结果（Statistics）：包括发送的 ICMP 请求数据包数量、接收到的 ICMP 响应数据包数量、丢包率、往返时间（RTT）的最小、平均、最大和标准偏差值。

如果 PING 对应的目标主机无法得到正确的响应，则表明这两个主机之间的连通性存在问题（有些主机或网络管理员可能禁用了对 ICMP 请求的回复，这样也会导致无法得到正确的响应）。如果往返时间（RTT）过高，则表明网络延迟过高。

工作原理

PING 基于网络层的 ICMP（Internet Control Message Protocol，互联网控制报文协议），其主要原理就是通过在网络上发送和接收 ICMP 报文实现的。

ICMP 报文中包含了类型字段，用于标识 ICMP 报文类型。ICMP 报文的类型有很多种，但大致可以分为两类：

查询报文类型：向目标主机发送请求并期望得到响应。
差错报文类型：向源主机发送错误信息，用于报告网络中的错误情况。

PING 用到的 ICMP Echo Request（类型为 8 ）和 ICMP Echo Reply（类型为 0）属于查询报文类型。

PING 命令会向目标主机发送 ICMP Echo Request。
如果两个主机的连通性正常，目标主机会返回一个对应的 ICMP Echo Reply。

从输入`URL`到界面展示

1，对URL解析，确定服务器主机名和请求路径，生成完整HTTP请求

2，查询服务器域名对应的IP地址：也就是域名解析，浏览器检查本地，操作系统检查其DNS缓存，查询本地DNS服务器，递归查询（根DNS服务器-顶级域DNS服务器-权威DNS服务器），返回该域名对应的IP地址给浏览器

3.建立TCP连接：浏览器通过操作系统的Socket接口向目标IP发起TCP连接，TCP三次握手

4.生成HTTP请求报文：请求行、请求头、请求体

5.发送HTTP请求：浏览器通过建立的TCP连接将HTTP请求报文发送到目标服务器。在此过程中，HTTP请求报文会被传递给下层的TCP协议，TCP会将其封装成数据包，并通过IP层为其加上IP头。

6.网络层(IP层)的封装与转发：在此过程中，HTTP请求报文会被传递给下层的TCP协议，TCP会将其封装成数据包，并通过IP层为其加上IP头。

7.数据链路层(MAC层)：数据包到达目标设备所在网络时，路由器通过ARP（地址解析协议）查找目标设备的MAC地址。如果目标设备在同一局域网内，路由器通过ARP获取目标设备的MAC地址，并将IP包封装成以太网帧。交换机使用MAC地址表，将帧转发到正确的端口，确保数据到达目标主机。

8.目标服务器接收数据：目标服务器解析MAC头、IP头，然后解析TCP头来获取数据，服务器检查TCP段的目的端口号，以确定该数据是由哪一个应用程序处理。服务器应用程序（如Web服务器）提取出HTTP请求报文，开始处理请求。

9.服务器生成HTTP响应报文：响应行、响应头、响应体

10.服务器通过TCP连接返回HTTP响应

11.浏览器接收响应，解析HTTP头部，处理响应体内容，渲染网页

12.关闭连接（HTTP/1.1，连接可能保持一段时间但最终会被关闭），TCP四次挥手关闭连接