wordpress 问答悬赏功能,网站优化公司方案,wordpress 文章 页面 区别,wordpress超时退出一、HTTP1.1和HTTP2的区别 HTTP/1#xff08;主要指 HTTP/1.1#xff09;和 HTTP/2 是 Web 协议发展中的两个重要版本#xff0c;二者在性能、协议机制和功能特性上有显著差异。以下从多个维度对比分析#xff0c;并结合具体案例说明#xff1a; 一、连接与请求处理方式 1…一、HTTP1.1和HTTP2的区别 HTTP/1主要指 HTTP/1.1和 HTTP/2 是 Web 协议发展中的两个重要版本二者在性能、协议机制和功能特性上有显著差异。以下从多个维度对比分析并结合具体案例说明 一、连接与请求处理方式 1. HTTP/1.1串行请求与队头阻塞 特点 虽支持持久连接Keep-Alive但同一 TCP 连接同一时刻只能处理一个请求请求需按顺序排队执行。若某个请求阻塞如响应慢或失败会导致后续请求被阻塞即队头阻塞Head-of-Line Blocking。 示例 浏览器加载一个网页包含 1 个 HTML 文件主资源3 张图片image1.jpg、image2.jpg、image3.jpg1 个 CSS 文件style.css1 个 JS 文件script.js 在 HTTP/1.1 中浏览器需逐个发起请求 请求顺序HTML → CSS → JS → image1 → image2 → image3
每个请求需等待前一个响应完成总耗时较长2. HTTP/2多路复用Multiplexing 特点 同一 TCP 连接中可并行发送多个请求 / 响应通过流Stream和帧Frame机制区分不同请求。彻底解决队头阻塞问题多个资源可同时传输无需排队。 示例 同样加载上述网页HTTP/2 中所有资源请求同时发起浏览器通过唯一流ID标识每个请求如流 1HTML流 2CSS流 3JS流 4-6 图片。 服务器将响应数据拆分为二进制帧如 HEADERS 帧、DATA 帧混合传输后由客户端按流 ID 重组。 总耗时大幅减少尤其适合高延迟或带宽受限场景。 二、协议格式文本 vs 二进制 1. HTTP/1.1纯文本格式 特点 请求和响应头部、实体均为文本格式可读性强但解析效率低冗余量大。 例如每次请求需重复传输相同头部字段如Host: example.com。 2. HTTP/2二进制分帧Binary Framing 特点 将整个请求 / 响应分解为最小单位的帧如 HEADERS 帧、DATA 帧、SETTINGS 帧等以二进制格式传输。解析速度更快且帧结构可精确控制如标记流优先级、结束流等。 示例 一个 HTTP/2 请求的 HEADERS 帧包含压缩后的头部数据DATA 帧包含实体内容。客户端收到混合的帧后按流 ID 合并为完整的请求 / 响应。 对比HTTP/1.1 的文本格式需逐行解析而 HTTP/2 的二进制格式可通过位运算快速处理提升性能。 三、头部压缩机制 1. HTTP/1.1无头部压缩 问题 每次请求 / 响应的头部字段重复传输如Accept、User-Agent、Cookie等尤其在移动端或低带宽场景下浪费流量。 2. HTTP/2HPACK 压缩算法 机制 客户端和服务器维护一个共享的头部字段缓存表Header Table首次请求时传输完整头部后续重复字段通过索引引用缓存表。对未缓存的字段采用哈夫曼编码压缩。 示例 首次请求https://example.com/page1时头部包含 GET /page1 HTTP/2
Host: example.com
User-Agent: Chrome/115... 第二次请求/page2时Host和User-Agent字段可直接引用缓存表中的索引仅传输变化的字段如GET /page2。 效果头部体积可压缩至原大小的 10%~20%节省带宽。 四、服务器推送Server Push 1. HTTP/1.1无此功能 客户端需主动发起所有资源请求服务器无法主动推送资源。 2. HTTP/2主动推送关联资源 机制 服务器可根据客户端请求主动推送其可能需要的资源如 CSS、JS、图片等避免客户端二次请求。示例 客户端请求index.html服务器解析 HTML 后发现需加载style.css和main.js可通过Link头或 API 主动推送这两个文件 !-- HTML中声明推送资源 --
link relpreload hrefstyle.css asstyle /
link relpreload hrefmain.js asscript /效果客户端无需额外请求style.css和main.js直接从服务器缓存中获取减少 RTT往返时间。 五、优先级与流量控制 1. HTTP/1.1无显式优先级 资源按请求顺序处理无法指定优先级如先加载 CSS 再加载图片。 2. HTTP/2流优先级Stream Priority 机制 客户端可通过:priority头部为每个流设置优先级如权重、依赖关系服务器根据优先级分配资源如先处理 CSS 流再处理图片流。示例 加载网页时CSS 样式表的优先级高于图片客户端可声明 :method: GET
:path: /style.css
:priority: weight200, depend0 # 权重200无依赖流 服务器优先处理该流确保 CSS 先加载避免页面渲染阻塞。 六、性能对比总结 特性HTTP/1.1HTTP/2连接方式单连接串行请求单连接多路复用协议格式文本格式二进制分帧头部压缩无HPACK 算法服务器推送不支持支持队头阻塞存在消除典型页面加载耗时1000ms假设300ms假设多路复用 压缩 二、 TCP的重传机制 一、TCP 可靠传输的基础序列号与确认应答ACK 序列号Sequence Number 每个 TCP 报文段的数据部分会被分配一个序列号用于标识数据在字节流中的位置如首字节序号。作用确保接收方按顺序重组数据检测重复或丢失的报文段。 确认应答ACK 接收方收到报文段后会向发送方返回 ACK其中包含 “期望接收的下一个字节的序号”即确认号。示例若接收方成功收到序号为 x、长度为 L 的数据则 ACK 的确认号为 xL表示 “已收到 x 到 xL-1 的数据期望接收 xL 开始的数据”。 二、重传机制的触发条件 当发送方发现数据未被正确确认时会触发重传。常见触发场景包括 超时未收到 ACK超时重传 发送方为每个报文段设置 重传超时时间RTORetransmission Timeout。若超过 RTO 未收到对应 ACK则认为报文段丢失触发重传。 收到重复 ACK快速重传 当接收方发现中间某个报文段丢失时后续收到的报文段会触发重复 ACK即连续发送多个相同的确认号。发送方若收到 3 个重复 ACK即 “累计 3 次确认号未更新”则认为该报文段丢失立即重传无需等待超时以降低延迟。 三、重传策略详解 1. 超时重传Timeout Retransmission 核心逻辑 发送方发送数据后启动定时器若超时未收到 ACK则重传该数据。首次 RTO 通常设为 初始值如 3 秒后续根据网络情况动态调整。 RTO 的动态计算 通过 往返时间RTTRound-Trip Time 测量网络延迟公式如下 平滑往返时间SRTTSRTT (1 - α) * SRTT α * RTTα 通常为 0.125。偏差值RTTVARRTTVAR (1 - β) * RTTVAR β * |RTT - SRTT|β 通常为 0.25。RTORTO SRTT δ * RTTVARδ 通常为 2。 Karn 算法重传时不更新 RTT避免因重传报文段的 ACK 无法区分原始 / 重传报文导致 RTT 测量误差。 缺点 超时时间较长时重传延迟高网络波动可能导致 RTO 调整不及时。 2. 快速重传Fast Retransmission 核心逻辑 当接收方发现数据失序时会针对已接收的后续数据连续发送重复 ACK确认号为失序报文段的起始序号。发送方收到 3 个重复 ACK 后立即重传丢失的报文段无需等待超时。示例 发送方按顺序发送报文段 1、2、3、4若报文段 2 丢失 接收方收到 1 后ACK 确认号为 2收到 3 后因 2 未到再次 ACK 确认号为 2重复 ACK收到 4 后继续 ACK 确认号为 2累计 3 次重复 ACK发送方触发快速重传立即重传报文段 2。 优点 相比超时重传能更快检测到丢失减少延迟。 3. 选择性重传Selective RetransmissionSACK 背景 传统重传机制会重传 整个窗口内未确认的数据如超时重传即使只有部分数据丢失导致效率低下。选择性确认SACKSelective Acknowledgment 是 TCP 的扩展选项允许接收方告知发送方 哪些数据已正确接收哪些数据丢失从而仅重传丢失的部分。 实现方式 接收方在 ACK 中通过 SACK 选项 携带多个连续字节块的范围如 “已收到 1-1000 和 2001-3000”。发送方根据 SACK 信息仅重传未被确认的字节块避免重传已接收的数据。 前提 需要双方在 TCP 连接建立时协商启用 SACK 选项通过 SYN 报文段携带。 四、重传次数限制与资源释放 重传次数上限 为避免无限重传消耗资源TCP 会限制最大重传次数如 Linux 默认值为 15 次对应 RTO 从初始值指数级增长到约 30 分钟。超过上限后TCP 会断开连接并通知应用层。 与拥塞控制的协同 重传机制与拥塞控制紧密关联 超时重传通常触发 拥塞避免Congestion Avoidance 或 慢启动Slow Start 机制降低发送速率以缓解网络拥堵快速重传后通常进入 快恢复Fast Recovery 阶段在不降低拥塞窗口的前提下调整发送策略。 三、TCP的拥塞控制 TCP 的拥塞控制是通过动态调整发送端的 拥塞窗口Congestion Window, cwnd 来实现的目的是避免网络过载导致的丢包和性能下降。其核心机制包括以下四种算法的协同工作慢启动Slow Start、拥塞避免Congestion Avoidance、快重传Fast Retransmit 和 快恢复Fast Recovery。以下是详细解析 一、核心概念 拥塞窗口cwnd 发送端维护的一个状态变量表示当前网络允许发送端发送的数据量上限单位为「报文段个数」。 发送端实际的发送窗口大小 min (cwnd, 接收端通告的窗口大小)。cwnd 会根据网络拥塞情况动态调整。 慢启动阈值ssthresh 区分「慢启动阶段」和「拥塞避免阶段」的阈值 当 cwnd ssthresh 时处于慢启动阶段当 cwnd ≥ ssthresh 时进入拥塞避免阶段。 二、四大拥塞控制算法 1. 慢启动Slow Start 目标初始阶段快速探测网络可用带宽避免突发流量拥塞。规则 初始时cwnd 1单位为 MSS最大段大小。每收到一个确认ACKcwnd 1。每经过一个往返时间RTTcwnd 呈指数增长如 1→2→4→8→…。 触发条件 新连接建立时超时重传后进入慢启动阶段。 阈值调整 当 cwnd 增长到等于 ssthresh 时切换至「拥塞避免阶段」。若中途检测到拥塞如超时执行 ssthresh max(cwnd/2, 2)取半最小为 2cwnd 1重新进入慢启动。 2. 拥塞避免Congestion Avoidance 目标避免网络拥塞使 cwnd 线性增长稳定传输。规则 每经过一个 RTTcwnd 1线性增长而非指数。 触发条件 cwnd ≥ ssthresh 时自动进入。 阈值调整拥塞发生时 若检测到超时严重拥塞 ssthresh cwnd/2cwnd 1回到慢启动阶段。若检测到「三个重复 ACK」轻度拥塞见快重传 执行快重传 快恢复算法见下文。 3. 快重传Fast Retransmit 目标尽早检测到单个报文段丢失避免不必要的超时等待。触发条件 接收端收到失序报文段时重复发送前一个正确报文段的 ACK。当发送端收到 3 个重复 ACK 时判定为「丢包」立即重传丢失的报文段无需等待超时。 操作 重传丢失的报文段进入「快恢复阶段」不执行慢启动。 4. 快恢复Fast Recovery 目标在轻度拥塞三个重复 ACK时快速恢复传输避免过度降低 cwnd。规则 ssthresh cwnd/2设置新的阈值cwnd ssthresh 3假设丢失的报文段已被接收端缓存允许发送 3 个新报文段每收到一个重复 ACKcwnd 1线性增加快速恢复当收到丢失报文段的 ACK 时cwnd ssthresh进入「拥塞避免阶段」。 与慢启动的区别 不将 cwnd 重置为 1而是基于当前阈值快速恢复减少吞吐量波动。 三、关键对比 场景处理方式cwnd 调整ssthresh 调整新连接 / 超时重传慢启动重置为 1设为 cwnd/2三个重复 ACK快重传 快恢复设为 ssthresh 3设为 cwnd/2拥塞避免阶段正常传输线性增长 cwndcwnd 1每 RTT不变 四、TCP的流量控制 TCP 的流量控制Flow Control是通过 滑动窗口机制Sliding Window 实现的主要用于解决 发送方发送速率过快导致接收方处理不及而丢包 的问题。其核心思想是接收方根据自身接收能力动态通知发送方调整发送窗口大小从而控制数据传输速率。以下是详细解析 一、核心机制滑动窗口Sliding Window 1. 基本概念 接收窗口Receiver Window, rwnd 接收方在 ACK 报文 中通告给发送方的 可用接收缓冲区大小表示接收方当前能接收的数据量。 单位字节Byte。范围0 ≤ rwnd ≤ 接收缓冲区大小。 发送窗口Send Window, swnd 发送方根据接收方通告的 rwnd 维护的 允许发送的数据范围实际大小由 rwnd 决定可能受拥塞窗口限制此处先不考虑拥塞控制。 2. 窗口滑动过程 发送方维护以下四个指针以字节为单位 [已发送并确认] --- [已发送未确认] --- [未发送但可发送] --- [未发送且不可发送]^左边界 ^右边界 ^发送窗口右边界 ^数据末尾已发送并确认数据已被接收方确认可从缓冲区删除。已发送未确认数据已发送但未收到确认处于窗口内。未发送但可发送未超出发送窗口可直接发送。未发送且不可发送超出发送窗口需等待窗口滑动后才能发送。 窗口滑动条件 当 已发送未确认的数据被确认 时左边界右移窗口滑动释放空间允许发送新数据。当 接收方通告新的 rwnd 时右边界可能扩大或缩小调整发送窗口大小。 二、流量控制的具体实现 1. 接收方通告窗口大小Window Advertisement 接收方在 ACK 报文 的 窗口字段Window Field 中告诉发送方当前可用的接收缓冲区大小rwnd。发送方根据 rwnd 更新发送窗口 swnd公式为 swnd min(rwnd, 拥塞窗口 cwnd) 此处先忽略拥塞窗口 cwnd假设仅受流量控制影响则 swnd rwnd。 2. 动态调整窗口大小 窗口扩大接收方处理完数据释放接收缓冲区后通过增大 rwnd 通知发送方可以发送更多数据。窗口缩小接收方缓冲区快满时通过减小 rwnd 通知发送方降低发送速率。零窗口Zero Window当接收缓冲区已满时接收方将 rwnd 设为 0发送方停止发送数据进入 窗口关闭状态。 3. 零窗口与窗口探测Zero Window Probe 问题当接收方通告 rwnd0 后发送方停止发送数据。若接收方后续释放了缓冲区但未及时通知发送方会导致双方僵持死锁。解决方案 发送方启动 零窗口定时器Zero Window Timer超时后发送一个 探测报文段仅含 1 字节数据询问接收方当前 rwnd。接收方收到探测报文后回复新的 rwnd若仍为 0则重新开启定时器若 rwnd0则发送方恢复数据发送。 三、流量控制与拥塞控制的区别 维度流量控制拥塞控制目标防止接收方缓冲区溢出点对点控制防止网络拥塞全局网络负载控制控制方接收方通过 rwnd 通告发送方根据网络状态动态调整机制滑动窗口基于接收方能力慢启动、拥塞避免、快重传、快恢复等作用范围发送方与接收方之间所有网络主机端到端 四、示例流量控制过程 初始状态 接收方缓冲区大小为 1000 字节初始 rwnd1000发送方 swnd1000发送 500 字节数据。此时接收方缓冲区剩余 500 字节回复 ACK 并通告 rwnd500发送方将 swnd 调整为 500。 窗口缩小 接收方处理缓慢缓冲区剩余 200 字节回复 ACK 并通告 rwnd200发送方 swnd 调整为 200仅允许发送 200 字节新数据。 零窗口 接收方缓冲区满通告 rwnd0发送方停止发送启动零窗口定时器。定时器超时后发送方发送探测报文接收方处理数据后释放缓冲区通告 rwnd300发送方恢复发送。 五、TCP 连接建立、状态管理及销毁的完整过程 在 TCP 连接建立过程中当客户端发起第一次握手SYN 包到达服务器时服务器会创建 TCBTCP Control Block并将该连接放入半连接队列SYN 队列。此时连接处于未完全建立状态。待客户端发送 ACK 完成第三次握手服务器会把连接从半连接队列移至全连接队列accept 队列同时将 TCB 标记为 ESTABLISHED 状态意味着连接已成功建立。这里需要注意连接进入全连接队列时状态就已变为 ESTABLISHED而非在 accept () 调用之后。accept () 函数的作用是从全连接队列中取出连接将 TCB 与应用层 socket 关联分配 fd 和文件结构体把已建立的连接交付给应用层。即使应用程序未调用 accept ()全连接队列中的连接依然维持 ESTABLISHED 状态直到队列满时会触发 SYN 重传或拒绝新连接。在 Linux 系统中半连接队列和全连接队列的大小可分别通过 net.ipv4.tcp_max_syn_backlog 和 somaxconn 参数进行配置。当连接断开如完成四次挥手主动关闭方会进入 TIME_WAIT 状态此时 TCB 不会立即销毁而是会保留一段时间默认 60 秒可配置以避免旧数据包对新连接造成干扰。 六、TCP连接状态如何变化 TCP 连接管理通过有限状态机FSM实现共有11 种状态涵盖连接建立、数据传输、连接关闭的完整生命周期。以下是各状态的详细说明及状态转换流程 一、TCP 连接的 11 种状态 1. CLOSED关闭状态 描述虚拟初始状态表示无连接或连接已关闭。转换 客户端主动发起连接时从CLOSED→SYN_SENT。服务端被动监听时从CLOSED→LISTEN。 2. LISTEN监听状态 描述服务端等待客户端连接请求。触发条件服务端调用listen()后进入此状态。转换 收到客户端SYN包发送SYNACK→SYN_RCVD。主动关闭连接→CLOSED。 3. SYN_SENT同步已发送状态 描述客户端已发送SYN包等待服务端确认。触发条件客户端调用connect()后发送SYN。转换 收到服务端SYNACK→ESTABLISHED三次握手完成。超时未收到回复→重发SYN若多次失败→CLOSED。 4. SYN_RCVD同步已接收状态 描述服务端已收到客户端SYN并回复SYNACK等待客户端确认。触发条件服务端收到SYN后发送SYNACK。转换 收到客户端ACK→ESTABLISHED。超时未收到ACK→重发SYNACK失败则→CLOSED。 5. ESTABLISHED已建立连接状态 描述连接已建立双方可双向传输数据。触发条件三次握手完成客户端和服务端均进入此状态。转换 主动关闭连接发送FIN→FIN_WAIT_1客户端或CLOSE_WAIT服务端。被动关闭连接收到对方FIN→CLOSE_WAIT客户端或LAST_ACK服务端。 6. FIN_WAIT_1终止等待 1 状态 描述主动关闭方如客户端已发送FIN等待对方确认。触发条件主动关闭方调用close()或shutdown()发送FIN。转换 收到对方ACK→FIN_WAIT_2。收到对方FINACK→直接处理FIN→TIME_WAIT跳过FIN_WAIT_2。 7. FIN_WAIT_2终止等待 2 状态 描述主动关闭方已收到对方ACK等待对方发送FIN。触发条件从FIN_WAIT_1收到ACK后进入。转换 收到对方FIN→发送ACK→TIME_WAIT。对方长期不关闭→可能保持此状态直到超时需系统配置支持。 8. CLOSE_WAIT关闭等待状态 描述被动关闭方如服务端收到FIN但尚未发送自身FIN需处理剩余数据。触发条件被动关闭方收到FIN后回复ACK进入此状态。转换 处理完数据后主动发送FIN→LAST_ACK。若直接关闭未发送FIN→可能导致连接泄漏需程序主动调用close()。 9. LAST_ACK最后确认状态 描述被动关闭方已发送FIN等待主动关闭方的ACK。触发条件被动关闭方发送FIN后进入此状态。转换 收到ACK→CLOSED。超时未收到ACK→重发FIN失败则→CLOSED。 10. TIME_WAIT时间等待状态 描述主动关闭方在发送ACK后等待一段时间2 倍 MSL确保连接安全关闭。触发条件主动关闭方在FIN_WAIT_2收到FIN并回复ACK后进入。作用 防止最后一个ACK丢失导致对方重发FIN时可重新响应。避免旧连接的数据包混入新连接MSL 为最大段生存时间。 转换 等待超时2MSL→CLOSED。收到重发的FIN→重新回复ACK并重置超时。 11. CLOSING关闭中间状态 描述罕见状态双方同时主动关闭时可能出现双方同时发送FIN。触发条件双方同时从ESTABLISHED发送FIN各自进入FIN_WAIT_1收到对方FIN后→CLOSING。转换 发送ACK并收到对方ACK→TIME_WAIT。 七、TCP如何保证可靠传输的 TCP传输控制协议通过多种机制确保数据的可靠传输核心思路是确认应答、重传机制、流量控制、拥塞控制、顺序控制等。以下是具体实现方式 1. 序列号Sequence Number与确认应答ACK 作用 唯一标识数据字节每个字节的数据都有唯一的序列号32 位用于标记数据顺序解决网络中数据乱序问题。确认应答机制接收方收到数据后通过确认号ACK Number告知发送方已成功接收的数据的下一个字节的序列号表示该序列号之前的数据均已正确接收。 示例 发送方发送序列号为 1000、长度为 200 的数据即字节范围 1000~1199接收方收到后返回 ACK1200表示 1200 之前的数据1000~1199已确认接收。发送方通过未确认的序列号判断哪些数据需要重传。 2. 重传机制Retransmission 作用 当数据丢失或确认超时发送方重新传输数据确保数据最终到达。 实现方式 超时重传Timeout Retransmission 发送方发送数据时启动定时器若超时未收到对应 ACK则重传数据。定时器初始值由 RTT往返时间 估算得出超时时间会动态调整如 Karn 算法 避免重传时的 RTT 计算误差。 快速重传Fast Retransmission 接收方发现数据失序时立即发送重复确认Dup ACK指向最后一个正确接收的连续序列号。发送方若收到 3 个相同的 Dup ACK判断为数据包丢失立即重传对应的数据包无需等待超时减少延迟。 3. 流量控制Flow Control 作用 通过 ** 滑动窗口Sliding Window** 机制让发送方的发送速率匹配接收方的处理能力避免接收方缓冲区溢出。 实现方式 接收窗口rwnd接收方在 ACK 中携带自己当前的接收缓冲区剩余大小即允许发送方发送的数据量。发送方根据 rwnd 调整发送窗口确保发送的数据不超过接收方的处理能力。若 rwnd0发送方暂停发送直到接收方通过 ACK 通知窗口更新如 TCP Keepalive 机制防止死锁。 4. 拥塞控制Congestion Control 作用 避免网络中数据流量过大导致拥塞如路由器队列溢出、丢包率上升实现全局网络稳定性。 核心算法 慢启动Slow Start 初始时发送方以 **1 个 MSS最大段大小** 为窗口大小每收到一次 ACK 就将窗口大小翻倍指数增长快速探测网络容量。当窗口大小超过慢启动阈值ssthresh时进入拥塞避免阶段。 拥塞避免Congestion Avoidance 窗口大小线性增长每轮往返时间增加 1 个 MSS避免网络过载。若检测到丢包如超时或 3 次 Dup ACK触发拥塞处理。 快重传Fast Retransmit与快恢复Fast Recovery 若通过 3 次 Dup ACK 检测到丢包执行快重传并将 ssthresh 设为当前窗口的一半进入快恢复阶段窗口大小线性减少而非重置为 1继续线性增长以快速恢复传输。若通过超时检测到丢包视为严重拥塞ssthresh 设为当前窗口的一半窗口重置为 1重新进入慢启动。 5. 校验和Checksum 作用检测数据在传输过程中是否损坏或篡改。实现方式发送方在头部计算伪首部 数据的校验和接收方进行校验。若校验失败直接丢弃数据包不返回 ACK触发发送方重传。 6. 顺序控制与重复数据删除 顺序控制接收方通过序列号对数据排序将失序的数据暂存于缓冲区等待缺失的数据包到达后按顺序交付应用层。重复数据删除若收到重复序列号的数据包直接丢弃并返回相同的 ACK避免重复处理。 7. 连接管理三次握手与四次挥手 三次握手确保双方初始序列号同步建立可靠连接避免历史连接干扰。四次挥手确保双方数据完全传输完毕后断开连接释放资源如 TIME_WAIT 状态防止最后一个 ACK 丢失导致的连接异常。 总结可靠传输的核心机制 机制作用描述序列号 / 确认号标记数据顺序确认应答确保数据到达重传机制超时重传和快速重传处理丢包流量控制端到端控制发送速率避免接收方缓冲区溢出拥塞控制全局控制发送速率避免网络拥塞校验和检测数据损坏丢弃错误包顺序与重复控制排序数据、去重确保按序交付连接管理可靠建立和释放连接同步状态 八、DNS域名解析的过程 DNS域名系统域名解析是将人类易读的域名如www.example.com转换为计算机可识别的 IP 地址的过程。这一过程涉及多级域名服务器的协同工作通常分为递归查询和迭代查询两个阶段。以下是详细解析过程 一、初始请求客户端发起查询 本地缓存检查 当用户在浏览器输入域名如www.baidu.com时操作系统会首先检查本地 DNS 缓存包括浏览器缓存、系统缓存。若缓存中有该域名对应的 IP 地址直接返回结果解析过程结束。 浏览器缓存浏览器会存储近期解析过的域名记录存活时间由 DNS 响应中的 TTL 字段决定。系统缓存操作系统如 Windows 的nscd、Linux 的systemd-resolved也会缓存 DNS 结果减少重复查询。 本地 DNS 服务器递归解析器 若本地缓存中无记录客户端会向本地 DNS 服务器通常由 ISP 提供或手动设置为公共 DNS 如 114.114.114.114发送递归查询请求。 递归查询的特点本地 DNS 服务器需负责全程查询直到返回最终结果或失败。 二、递归查询本地 DNS 服务器的迭代查询过程 本地 DNS 服务器若未缓存目标域名需通过迭代查询向上级域名服务器逐步获取信息流程如下 1. 根域名服务器Root DNS Server 本地 DNS 服务器首先向根域名服务器发起查询。根服务器负责管理顶级域名如.com、.cn 等的解析权返回对应 ** 顶级域名服务器TLD Server** 的地址。 根服务器全球共 13 组A~M通过任播技术分布在全球各地。示例查询www.baidu.com时根服务器会返回.com顶级域名服务器的地址。 2. 顶级域名服务器TLD Server 本地 DNS 服务器根据根服务器返回的地址向 **.com顶级域名服务器查询。TLD 服务器负责管理该顶级域名下的所有二级域名如baidu.com返回对应权威域名服务器Authoritative Server** 的地址。 示例.com TLD 服务器会返回baidu.com的权威服务器地址如ns1.baidu.com。 3. 权威域名服务器Authoritative Server 本地 DNS 服务器向权威域名服务器发起最终查询。权威服务器是域名所有者配置的服务器存储该域名的具体解析记录如 A 记录、AAAA 记录直接返回域名对应的 IP 地址。 示例baidu.com的权威服务器会返回www.baidu.com的 IP 地址如 14.215.177.38。 三、结果返回与缓存 响应回传 权威服务器将 IP 地址返回给本地 DNS 服务器后者再将结果回传给客户端。客户端收到 IP 地址后即可与目标服务器建立连接如 HTTP 请求。 缓存记录 本地 DNS 服务器会缓存解析结果供后续其他客户端查询使用。客户端也会将结果存入本地缓存缓存时间由 DNS 响应中的TTL生存时间字段控制如 TTL3600 秒表示缓存 1 小时。 关键概念补充 递归查询 vs. 迭代查询 递归查询客户端只需向本地 DNS 服务器发起一次请求服务器全程负责查询“代劳到底”。 迭代查询本地 DNS 服务器逐次向根→TLD→权威服务器查询每次获取下一步地址“逐步问路”。 DNS 协议细节 使用UDP 协议端口 53因查询数据量小UDP 效率更高若响应超时可能 fallback 到 TCP。支持DNSSEC域名系统安全扩展通过数字签名防止 DNS 欺骗DNS 污染。 现代扩展技术 DNS over HTTPSDoH/ DNS over TLSDoT加密 DNS 查询避免中间人攻击常用于浏览器如 Chrome、Firefox。任播Anycast根服务器和部分公共 DNS 通过任播技术让客户端就近连接最近的节点提升响应速度。 九、生动讲解HTTPS加密过程 我们以「用户访问招商银行官网cmbchina.com并登录」为例全程模拟 HTTPS 加密过程每个步骤都对应具体的操作和数据让你像看电影一样理解整个流程 场景设定 你坐在电脑前的用户打开浏览器输入 https://cmbchina.com招商银行服务器真正的银行服务器持有合法数字证书黑客小明躲在中间试图窃听或篡改通信假设存在但最终失败 一、客户端发起连接你「敲门」问安全能力TLS 握手第 1 步 你的浏览器动作 发送一个「Hello 请求」给招商银行服务器内容包括 随机数 A20250521_abc123好比你随手写的一串乱码支持的加密算法[ECDHE-RSA-AES256-GCM-SHA384, RSA-AES256-CBC-SHA]TLS 版本TLS 1.3最新安全版本 类比你隔着门喊“我带了 AES256 和 RSA 两种密码本用 TLS 1.3 协议聊这是我的乱码片段 A” 黑客小明的动作试图拦截这个请求但此时还没加密内容可见但他不知道接下来会发生什么。 二、服务器验证身份银行「出示身份证」TLS 握手第 2-3 步 招商银行服务器动作 回复「Hello 响应」内容包括 选择加密算法ECDHE-RSA-AES256-GCM-SHA384选了你支持的最强算法随机数 Bserver_20250521_def456服务器的乱码片段数字证书 证书内容 域名cmbchina.com必须和你访问的域名一致公钥-----BEGIN PUBLIC KEY-----...服务器的公钥用于加密数据有效期2024.01.01 - 2026.12.31未过期CA 签名由 DigiCert知名 CA 机构用私钥签名的哈希值 比喻服务器递给你一张 “身份证”上面有银行照片域名、有效期、公安局盖章CA 签名。 你验证证书真伪浏览器自动完成 检查域名确认证书里的域名是cmbchina.com不是cmbchina-fake.com。检查有效期当前时间是 2025 年 5 月证书未过期。用 DigiCert 的公钥浏览器内置根 CA 公钥解密证书中的「数字签名」对比证书内容的哈希值是否一致确保证书没被篡改。 如果证书有问题比如黑客伪造了一个cmbchina.com的证书但没有 DigiCert 的私钥签名验证失败浏览器会弹出 “不安全” 警告。 黑客小明的动作 想冒充银行服务器伪造了一个证书但签名无法通过 CA 验证你根本不会信任他。或直接拦截服务器的真实证书替换成自己的假证书但你的浏览器发现签名不对拒绝继续通信。 三、密钥交换生成「只有你和银行知道的密码本」TLS 握手第 4-5 步 你的浏览器动作 生成「预主密钥」pre_master_key_xyz789真正的密码本核心。用招商银行证书中的公钥加密预主密钥发送给服务器公钥加密(pre_master_key_xyz789) 比喻你用银行身份证上的公钥公开的锁把密码本核心锁在盒子里只有银行的私钥唯一的钥匙能打开。 招商银行服务器动作 用自己的私钥解密收到的密文得到预主密钥pre_master_key_xyz789。双方独立计算「会话密钥」 公式会话密钥 哈希(预主密钥 随机数A 随机数B)结果双方得到相同的对称密钥比如session_key_secure123用于后续加密的密码本。 比喻你用A片段预主密钥拼出密码本银行用B片段预主密钥拼出同样的密码本黑客即使知道 A 和 B但没有预主密钥被公钥加密保护无法算出会话密钥。 黑客小明的动作 截获了随机数 A、B 和加密后的预主密钥但没有银行私钥无法解密预主密钥更算不出会话密钥。 四、安全通信用密码本加密传输登录数据TLS 握手完成后 你发送登录请求假设账号user123密码pass456 浏览器用「会话密钥」加密数据 明文{username:user123, password:pass456, action:login}密文AES256-GCM加密(session_key_secure123, 明文)变成乱码 发送密文给银行服务器。 招商银行服务器接收并解密 用「会话密钥」解密密文得到明文user123和pass456。验证登录信息正确后返回加密的账户余额 明文{balance:100000元, timestamp:2025-05-21 14:30}密文AES256-GCM加密(session_key_secure123, 明文) 黑客小明的动作 截获了密文但没有会话密钥无法解密看到的只是乱码NwSC...想篡改密文中的 “balance” 为 “1000000 元”但篡改后密文的完整性校验GCM 模式带认证会失败服务器会丢弃该数据。 五、关键细节如果中间人参战会怎样 假设黑客小明成功冒充路由器实施中间人攻击 伪造证书小明生成一个假的cmbchina.com证书自签名证书无 CA 签名。 你的浏览器验证时发现证书签名无效弹出警告“该网站证书不可信”你选择 “继续访问”危险操作此时进入 “不安全通道”小明可窃取密钥。 成功欺骗的极端情况 小明是某机构员工持有伪造的 CA 证书现实中几乎不可能因根 CA 私钥极难窃取。你的浏览器信任该 CA认为证书有效此时小明可充当 “中间人”解密你和银行的通信这就是为什么根 CA 安全至关重要。 总结例子中的核心对应关系 HTTPS 流程具体例子场景安全作用数字证书招商银行的 “官方身份证”防止冒充验证身份公钥加密预主密钥用银行公钥锁密码本核心确保密钥传输安全会话密钥你和银行的共享密码本高效加密大量数据对称加密通信加密传输登录密码和账户余额防止窃听和篡改 十、浏览器从输入url到展示页面经历了哪些过程 一、导航准备阶段处理 URL 安全校验 场景你在地址栏输入zhihu.com并按回车 URL 标准化 浏览器自动补全协议http:// → https://若默认启用 HTTPS修正格式去除多余空格处理特殊字符如%20转空格示例输入zhihu.com → 转为https://www.zhihu.com/可能带默认路径 安全检查关键 协议校验 http: 直接跳转https: 需走加密流程触发 TLS 握手 跨站脚本防护XSS 检查 URL 是否包含恶意脚本如javascript:alert(1)拦截危险内容 浏览器安全策略 遵循Content Security Policy (CSP)头若有限制资源加载来源 二、DNS 解析从域名到 IP 的「地址翻译」 场景需要知道www.zhihu.com的服务器 IP 多级缓存查询速度优先 浏览器缓存先查本地缓存如 Chrome 输入chrome://net-internals/#dns可看若有 IP有效期内直接使用系统缓存查本机hosts文件Windows 在C:\Windows\System32\drivers\etc\hosts可手动绑定 IP路由器缓存家用路由器可能缓存 DNS 记录减少重复查询 递归查询流程若缓存失效 本地 DNS 服务器LDNS 你的网络服务商提供的 DNS如电信 / 联通的 DNS先查其缓存若没有则根 DNS 服务器返回.com顶级域服务器地址如a.gtld-servers.net顶级域TLD服务器返回zhihu.com的权威 DNS 服务器地址权威 DNS 服务器返回www.zhihu.com的真实 IP如180.163.151.35耗时全程约 50-200msHTTPS 站点可能用DNS-over-HTTPS (DoH)加密查询防中间人攻击 三、网络连接建立安全通道TCPTLS 场景与知乎服务器180.163.151.35:443建立连接 1. TCP 三次握手可靠传输 你→服务器发送 SYN 包请求建立连接 seq1001 服务器→你回复 SYNACK 包 seq2001, ack1002 你→服务器发送 ACK 包 ack2002 连接建立关键点确认双方收发能力正常避免旧连接干扰 2. TLS 握手HTTPS 加密通道 你发送 ClientHello 支持的 TLS 版本如 1.3、加密算法列表如 ECDHE-RSA-AES256-GCM、随机数 A服务器返回 ServerHello 证书 选定算法、服务器数字证书含公钥、随机数 B你验证证书 检查域名www.zhihu.com、有效期、CA 签名内置根证书验证若证书无效则弹窗警告生成会话密钥 你用服务器公钥加密「预主密钥」发送双方用预主密钥 随机数 A/B 算出相同的对称密钥如session_key_secure耗时约 1-RTT往返时间现代浏览器支持「TLS 会话复用」减少后续连接耗时 四、HTTP 请求与响应获取页面原始数据 场景向知乎服务器请求首页 HTML 发送请求Request 请求行GET / HTTP/2使用 HTTP/2 协议多路复用请求头 { Host: www.zhihu.com, User-Agent: Mozilla/5.0 Chrome/115..., // 标识浏览器 Accept: text/html, // 声明接受HTML格式 Cookie: session_idabc123 // 携带登录状态
} 请求体GET 方法无POST/PUT 等方法携带数据 服务器处理请求 解析请求头验证 Cookie若已登录返回个性化页面生成响应内容读取 HTML 文件、查询数据库如用户信息、推荐内容添加响应头 { Content-Type: text/html; charsetutf-8, // 声明内容类型 Cache-Control: max-age3600, // 浏览器缓存策略 Set-Cookie: new_sessionxyz789 // 可能更新Cookie
} 返回响应Response 状态码200 OK成功、302 Found临时重定向、404 Not Found等响应体HTML 文本如知乎首页的htmlhead.../headbody.../body/html耗时取决于服务器处理速度、网络延迟通常几十到几百毫秒 五、浏览器解析渲染从代码到像素 场景将知乎 HTML 转换为屏幕上的文字、图片、按钮 1. 构建渲染树Render Tree 解析 HTML→DOM 树 逐行解析 HTML生成节点对象如div classheader形成树状结构 遇到script srcmain.js暂停解析下载 JS 并执行默认阻塞渲染遇到link relstylesheet hrefstyle.css并行下载 CSS不阻塞 HTML 解析 解析 CSS→CSSOM 树 解析 CSS 规则生成样式对象如.header { color: #333; }合并为渲染树 过滤不可见元素如display: none保留需显示的节点如visibility: hidden仍保留 2. 布局计算Layout 计算每个元素的几何属性 位置基于 Flex/Grid 布局、盒模型margin/padding/border尺寸宽高如.header宽 100%高 80px 示例知乎首页头部导航栏通过 CSS 计算得出左对齐、高度 60px、内边距 10px 3. 绘制Paint 将元素的视觉属性颜色、阴影、边框转换为像素数据 文字渲染调用系统字体引擎生成字形像素图片解码将下载的 JPEG/PNG 转为位图可能触发「图片解码阻塞渲染」 优化点浏览器将不同层级元素如浮层、视频分到不同图层避免重复绘制 4. 合成Composite 将多个图层按层级合并如背景层→内容层→浮层输出到屏幕 使用 GPU 加速合成transform/opacity动画不会触发重排重绘回流Reflow若修改布局如width: 50%需重新计算布局→绘制→合成重绘Repaint仅修改样式如color: red只需重新绘制→合成 六、资源加载与优化并行获取图片、JS、CSS 场景知乎首页 HTML 中引用了 LOGO 图片、JS 交互脚本、CSS 样式表 优先级与并行加载 关键资源CSS阻塞渲染、JS阻塞解析除非标记async/defer非关键资源图片、字体、视频异步加载浏览器策略 同一域名下最多建立 6-8 个 TCP 连接HTTP/1.1HTTP/2 支持多路复用单个连接并发加载预加载提示HTML 中link relpreload hrefmain.js告知浏览器提前下载 示例资源加载流程 HTML 解析到img srclogo.png发起 GET 请求获取图片并行于 DOM 解析解析到script srcanalytics.js defer下载 JS 但不阻塞渲染DOM 构建完成后执行CSS 文件下载完成后触发「样式重新计算」可能导致部分元素重新布局 七、JS 执行动态交互的核心 场景知乎首页的搜索框自动补全、按钮点击事件 引擎编译执行 V8 引擎Chrome将 JS 代码编译为机器码 解析阶段生成抽象语法树AST优化阶段JIT即时编译优化热点代码如循环 事件循环Event Loop处理异步操作如setTimeout、AJAX 回调避免阻塞主线程 DOM 操作与性能影响 示例代码 // 点击按钮修改文本触发重绘
document.getElementById(button).addEventListener(click, () { document.getElementById(text).style.color red; // 重绘
});
// 调整布局触发回流重绘
document.getElementById(box).style.width 200px; 优化建议 批量修改 DOM如先改display: none改完再显示使用requestAnimationFrame处理动画 八、收尾阶段页面完成与后续处理 onLoad 事件触发 所有资源HTML/CSS/JS/ 图片加载完成后执行window.onload回调示例知乎首页在此阶段初始化全页面 JS 组件如评论区、推荐算法 浏览器优化机制 预渲染推测用户可能访问的链接如鼠标悬停提前加载页面内容内存管理垃圾回收机制清理无效变量避免内存泄漏 十一、HTTP协议中的cookie和session的区别 一、核心定义 1. Cookie 本质存储在客户端浏览器 / 手机本地的小型文本数据键值对形式。作用用于服务器识别用户身份实现会话状态的持久化如保持登录状态。工作原理 服务器通过响应头Set-Cookie向客户端发送 Cookie。客户端后续请求时会自动在请求头Cookie中携带该 Cookie回传给服务器。 例子 用户登录网站后服务器返回一个包含user_id123的 Cookie客户端保存后下次访问时自动携带该 Cookie服务器通过user_id识别用户已登录。 2. Session 本质存储在服务器端的会话数据如用户权限、购物车信息等。作用用于记录用户在一次会话中的动态状态如登录状态、临时数据。工作原理 服务器创建 Session 时生成一个唯一的Session ID如session_idabc123。通过 Cookie 将 Session ID 发送给客户端客户端后续请求携带该 ID服务器通过 ID 查找对应的 Session 数据。 例子 用户在电商网站添加商品到购物车服务器创建一个 Session 存储购物车内容并返回session_id给客户端。用户浏览其他页面时携带session_id服务器根据 ID 找到对应的购物车数据。 二、关键区别对比 维度CookieSession存储位置客户端浏览器、本地文件服务器端内存、数据库、文件系统等安全性较低数据明文存储于客户端易被篡改或窃取较高敏感数据存储在服务器客户端仅存 Session ID数据容量小单个 Cookie 通常限制为4KB浏览器对每个域名的 Cookie 数量有限制大取决于服务器配置可存储复杂数据结构有效期可设置Expires或Max-Age支持持久化默认仅在浏览器会话期间有效关闭浏览器即过期也可设置持久化跨域支持受同源策略限制只能在同域名下使用依赖 Cookie 传递 Session ID因此同样受同源策略限制服务器压力无数据存储在客户端有每个用户会话占用服务器资源典型用途存储非敏感信息如用户偏好、登录令牌存储敏感或动态信息如登录状态、购物车、表单临时数据 三、典型应用场景 场景 1用户登录状态保持 Cookie 方案 服务器验证用户密码后返回一个包含auth_token的 Cookie设置有效期为 7 天。用户下次访问时浏览器自动携带该 Cookie服务器验证令牌有效则允许登录。 风险若 Cookie 被窃取攻击者可伪造身份需配合HttpOnly和Secure属性增强安全性。 Session 方案 服务器验证用户密码后创建 Session 存储用户信息如user_roleadmin并返回session_id的 Cookie。用户后续请求携带session_id服务器通过 ID 查找 Session 并验证权限。 优势敏感信息如user_role不暴露在客户端安全性更高。 场景 2电商购物车 Cookie 方案 将购物车商品 ID 存储在 Cookie 中如cartitem1,item2。 缺点数据容量有限且用户在不同设备登录时无法同步购物车。 Session 方案 购物车数据存储在服务器 Session 中客户端仅存储session_id。用户更换设备后重新登录即可同步购物车需结合用户账号体系。 优势支持大容量数据跨设备同步方便。 四、配合使用Cookie Session 实际开发中两者常结合使用 服务器创建 Session生成session_id。通过 Cookie 将session_id返回给客户端这是 Session 机制的核心。客户端后续请求携带session_id服务器通过 ID 识别用户会话。 优点 利用 Cookie 的跨请求传递能力避免每次请求都重新认证。敏感数据存储在服务器降低客户端安全风险。 五、面试高频问题 为什么 Session 需要依赖 Cookie 答Session 通过session_id识别用户会话而session_id需要通过 Cookie 传递给客户端。若客户端禁用 Cookie则需通过 URL 重写如http://example.com/?session_idabc123传递但安全性和兼容性较差。 Cookie 的HttpOnly和Secure属性有什么用 HttpOnly禁止 JavaScript 读取 Cookie防止 XSS 攻击窃取 Cookie。Secure仅在 HTTPS 连接下发送 Cookie防止明文传输被劫持。 分布式系统中如何管理 Session 答单机 Session 无法跨服务器共享需使用分布式 Session 方案如 Redis 集群存储 Session 数据所有服务器共享同一存储。 十二、http和grpc的区别 一、核心定义与设计目标 1. HTTP 本质基于请求 - 响应模型的应用层协议用于规范客户端如浏览器与服务器之间的通信。设计目标 实现超文本文本、图片、视频等的传输与展示是 Web 服务的基础。强调通用性和可读性支持跨平台、跨语言的交互如浏览器可访问任何支持 HTTP 的服务器。 典型场景 浏览器访问网页如 GET https://example.com/index.html。对外提供 RESTful API如调用第三方天气接口 GET https://api.weather.com/city上海。 2. RPCRemote Procedure Call 本质一种进程间通信机制允许程序像调用本地函数一样调用远程服务器的函数。设计目标 隐藏网络通信细节如序列化、传输、反序列化让开发者专注于业务逻辑。追求高效性和强类型约束适用于分布式系统内部服务间的高频交互。 典型场景 微服务架构中用户服务调用订单服务的接口如 userService.createOrder(userId, productId)。高性能场景下的内部通信如电商系统中库存服务与支付服务的实时交互。 二、关键区别对比 维度HTTPRPC通信模型严格的请求 - 响应模型一问一答支持请求 - 响应、单向调用如通知、流式传输如 gRPC 的双向流协议层级应用层协议基于 TCP/IP通常基于 TCP 或 HTTP/2可自定义传输层协议数据格式文本格式JSON/XML可读性强但体积较大二进制格式如 Protobuf/Thrift体积小、解析快接口定义松散通过 URL 和 HTTP 方法定义接口如 GET /users/{id}强类型通过 IDL接口定义语言明确接口参数和返回值如 .proto 文件调用方式显式需手动构造请求 URL、参数、 headers隐式自动生成客户端 Stub像调用本地函数性能相对较低文本解析、协议开销较大较高二进制协议、连接复用、更少网络开销跨语言支持天然跨语言基于标准协议依赖框架支持需为每种语言生成对应 Stub服务治理需依赖外部组件如 API 网关、Nginx内置支持如负载均衡、服务发现、熔断限流 三、核心机制对比 1. 数据格式与序列化 HTTP 以 JSON 为例请求体可能是 {method: getUser,params: { userId: 123 }
}优点易读、易调试适合对外接口或需要人工介入的场景如前端调试。 缺点文本格式冗余解析性能较低如 JSON 转对象需遍历键值对。 RPC 以 Protobuf 为例通过 .proto 文件定义接口 service UserService {rpc getUser(GetUserRequest) returns (UserResponse) {}
}
message GetUserRequest { string userId 1; }编译后生成二进制数据如 userId123 可能编码为 0x0A\x03\x31\x32\x33。 优点二进制格式紧凑体积通常比 JSON 小 30%~50%解析速度快基于字段编号而非字符串匹配。 缺点可读性差需依赖工具生成代码。 2. 调用方式对比 HTTP 调用以 RESTful 为例 客户端需手动构造 HTTP 请求例如用 Python 的 requests 库 import requests
response requests.get(https://api.example.com/users/123, headers{Authorization: Bearer token})
data response.json()特点需显式处理网络请求细节URL、headers、错误处理。 RPC 调用以 gRPC 为例 客户端通过自动生成的 Stub 调用例如 import user_service_pb2_grpc, user_service_pb2channel grpc.insecure_channel(order-service:50051)
stub user_service_pb2_grpc.UserServiceStub(channel)
request user_service_pb2.GetUserRequest(userId123)
response stub.getUser(request) # 像调用本地函数一样特点网络通信细节序列化、传输、反序列化由框架自动处理代码更简洁。 四、适用场景对比 适合用 HTTP 的场景 对外提供开放接口 如第三方开发者调用的 API如微信支付接口需跨语言、跨平台兼容HTTPJSON 的组合简单易用。需要浏览器直接访问的场景 浏览器原生支持 HTTP无需额外客户端库如前端通过 fetch 调用接口。低性能要求的简单场景 如内部管理系统的 API对速度要求不高但需要易调试和维护。 适合用 RPC 的场景 微服务架构内部通信 如电商系统中用户服务、订单服务、库存服务之间的高频交互需高性能和强类型接口如库存扣减时要求参数必须为整数。实时性要求高的场景 如即时通讯、实时数据同步如股票行情推送RPC 的二进制协议和连接复用如 HTTP/2 的多路复用可减少延迟。需要服务治理的复杂系统 RPC 框架如 Dubbo、gRPC内置负载均衡、熔断、限流等功能适合大规模分布式系统。 五、典型框架对比 类型框架 / 工具特点HTTPFlask/Django快速开发 Web 服务适合中小型项目。HTTPSpring Boot基于 Java支持 RESTful API适合企业级应用。RPCgRPC基于 HTTP/2支持多语言性能高Google 开源如用于 Kubernetes 内部通信。RPCDubbo阿里巴巴开源支持丰富的服务治理功能适合 Java 生态的微服务架构。RPCThrift/Protobuf专注于序列化和接口定义可独立于传输层使用如通过 TCP 直接传输。 六、面试高频问题 为什么 RPC 比 HTTP 快 答 RPC 使用二进制协议如 Protobuf体积更小、解析更快通常复用长连接如 HTTP/2 的持久连接减少 TCP 三次握手开销框架层优化如连接池、批量请求进一步提升性能。 HTTP 和 RPC 可以共存吗 答可以。例如 对外提供 HTTP API 供浏览器 / 第三方调用内部微服务之间使用 RPC 通信以提升性能如电商平台的前端用 HTTP 调用网关网关内部通过 RPC 调用各个服务。 gRPC 是 HTTP 还是 RPC 答gRPC 是基于 HTTP/2 的 RPC 框架。它复用了 HTTP/2 的多路复用、二进制分帧等特性但通过 IDL 实现了强类型的 RPC 调用属于 RPC 范畴。 十三、HTTP方法GET、POST、PUT和PATCH的区别是什么 一、核心功能对比 方法功能描述GET请求获取资源如查询数据、获取文件等不改变服务器状态。POST用于创建新资源如提交表单、上传文件等通常会导致服务器状态变化。PUT更新资源覆盖式更新需指定完整资源数据常用于替换已有资源或创建指定 ID 的资源。PATCH部分更新资源只需提交需要修改的字段无需提供完整数据比 PUT 更灵活高效。 二、关键特性对比 1. 幂等性Idempotence 幂等性多次执行相同操作结果与一次执行相同不会产生副作用。 GET幂等。多次获取同一资源结果不变如查询商品列表。POST非幂等。多次提交可能创建多个资源如重复提交订单。PUT幂等。多次覆盖同一资源结果一致如用 PUT 更新用户信息每次传入完整数据。PATCH非幂等。多次部分更新可能产生累积效果如先修改用户邮箱再修改手机号。 2. 安全性Safety 安全性方法是否仅用于获取资源不修改状态。 GET安全。仅用于读取数据不影响服务器状态。POST/PUT/PATCH非安全。会修改服务器资源如创建、更新数据。 3. 参数位置 GET参数通过 URL 传递如 ?keyvalue明文可见长度受限浏览器 / 服务器限制。POST/PUT/PATCH参数通常放在请求体Request Body中可传输较大数据且不暴露在 URL 中。 4. 资源定位 GET/POST资源由 URL 定位如 GET /users 获取用户列表POST /users 创建用户。PUT/PATCH需指定具体资源的完整 URL如 PUT /users/123 更新 ID 为 123 的用户。 三、典型使用场景 1. GET 查询数据如获取用户信息、商品详情GET /users/1。非敏感数据请求如获取静态文件图片、API 列表。 2. POST 创建资源如用户注册POST /users 提交用户数据、提交表单。非幂等操作如支付请求重复提交会导致多笔交易。 3. PUT 完整更新资源如修改用户全部信息需传入完整用户数据。创建指定资源如上传文件到固定路径PUT /files/abc.txt。 4. PATCH 部分更新资源如仅修改用户邮箱PATCH /users/1 传入 {email: newexample.com}。高效更新避免传输未修改的字段减少数据量如 RESTful API 中优化更新操作。 四、对比总结表格 特性GETPOSTPUTPATCH用途读取资源创建资源全量更新部分更新幂等性✅ 幂等❌ 非幂等✅ 幂等❌ 非幂等安全性✅ 安全❌ 非安全❌ 非安全❌ 非安全参数位置URL请求体请求体请求体典型场景查询列表提交表单替换资源修改字段 五、常见误区与最佳实践 不要滥用 POST 传统 Web 开发中常用 POST 处理所有操作但在 RESTful 设计中应根据操作类型选择方法如更新用 PUT/PATCH删除用 DELETE。 PUT vs. PATCH 的选择 需要覆盖整个资源时用 PUT如重置用户密码。只需修改部分字段时用 PATCH如更新用户头像 URL。 幂等性的重要性 在分布式系统中幂等性可避免重复请求导致的数据不一致如接口重试时PUT 比 POST 更安全。 0voice · GitHub
