一、 HTTP协议互联网世界的“普通话”1. 什么是 HTTPHTTP超文本传输协议就是浏览器和服务器之间沟通的“普通话”。它规定了浏览器怎么向服务器要数据服务器怎么把数据给浏览器。2. 它的三大核心特点通俗版无状态不认人HTTP 就像是一个“金鱼记忆”的快递员。你刚给他下了一单买鞋他送完货就忘了你是谁。如果你再下一单买衣服他不知道你就是刚才买鞋的那个人。实际开发举例这就是为什么我们需要Cookie和Token的原因。因为 HTTP 不认人我们必须给每个用户发一张“身份识别卡Token”每次请求都带上服务器才知道“哦这是张三他有权限看这个页面”。请求-响应模型一问一答浏览器不问服务器绝不主动说话。实际开发举例如果网页想实现“别人给你点赞你的网页自动弹出红点”用纯 HTTP 是做不到的因为服务器不能主动推给你。前端通常只能用“轮询”每隔1秒问一次服务器有新消息吗但这太浪费资源了。所以后来才催生了WebSocket这种能双向沟通的协议。明文传输裸奔HTTP 发送的数据是不加密的。实际开发举例如果你在 HTTP 协议下输入了银行卡密码黑客只要在你的网络节点上抓个包就能像看报纸一样清清楚楚地看到你的密码。二、 HTTPS协议给 HTTP 穿上“防弹衣”1. 什么是 HTTPS简单来说HTTPS HTTP SSL/TLS加密层。它并不是一个全新的协议而是在 HTTP 的基础上加了一层加密保护。2. 它是怎么工作的非对称加密与对称加密你可以把它想象成“配钥匙”的过程非对称加密用来交换钥匙浏览器和服务器一开始先通过一种复杂的方式安全地交换一把“通用钥匙”。这个过程就算被黑客看到他也偷不走。对称加密用来传数据双方拿到“通用钥匙”后接下来所有的聊天、传数据都用这把钥匙进行加密和解密。实际开发举例这就是为什么你打开银行网站、淘宝支付页面时浏览器地址栏会出现一个“小锁”图标。它告诉用户“放心咱们现在的对话是加密的就算有人在网吧里抓包看到的也是一堆乱码。”三、 HTTP vs HTTPS核心对比为了让你一目了然我整理了一张对比表。在实际开发中这也是我们做技术选型和排查问题时的核心依据对比维度HTTPHTTPS安全性极低。明文传输容易被窃听、篡改。极高。数据加密传输防窃听、防篡改。性能消耗低。不需要进行加密和解密计算速度快。较高。需要消耗 CPU 进行加解密且首次连接握手会稍微慢一点点。端口号默认使用80端口。默认使用443端口。证书成本免费。不需要申请任何证书。收费/需配置。需要向 CA 机构申请 SSL 证书现在也有很多免费证书如 Let’s Encrypt。SEO 友好度一般。更好。搜索引擎如百度、谷歌会优先展示 HTTPS 网站。浏览器态度会提示“不安全”。显示“小锁”图标给予信任。四、HTTP底层协议1. HTTP 属于哪一层—— 应用层在经典的OSI 七层模型或者更常用的 TCP/IP 四层模型中HTTP 属于最顶层的“应用层”。通俗理解应用层就像是“写信的内容”。它规定了咱们俩聊天用什么语言、格式是什么比如我要买一双鞋请发货。实际开发举例作为前端你平时写的fetch()或axios请求配置的Header请求头、Body请求体都是在跟应用层的 HTTP 协议打交道。2. HTTP 的底层协议是什么—— TCP 协议HTTP 自己是个“甩手掌柜”它只负责规定内容格式不管数据怎么安全、准确地送达。这个苦力活交给了它的底层协议——TCP传输控制协议。通俗理解TCP 就像是“靠谱的快递物流网”。HTTP 把信件内容数据交给 TCPTCP 负责把信件打包成一个个小包裹规划路线确保对方一个不少地收到。如果中途有个包裹丢了TCP 还会自动重发。实际开发举例你有没有遇到过网页加载到一半图片突然裂开了或者请求卡住不动这往往就是底层的 TCP 连接出了问题比如网络波动导致数据包丢失TCP 正在疯狂尝试重传。3. TCP 的底层又是什么—— IP 协议TCP 虽然靠谱但它不知道收件人的具体地址在哪。这就需要它的底层协议——IP网际协议。通俗理解IP 就像是“快递单上的地址和导航系统”。它负责在茫茫互联网中找到目标服务器的 IP 地址并把包裹送达。实际开发举例前端开发中经常听到的“DNS 解析”就是把域名如baidu.com翻译成底层的 IP 地址如110.242.68.4这就是在给 IP 协议提供导航信息。4. 最底层的基石是什么—— 网络接口层网卡与物理介质IP 知道地址后数据最终要通过网线、光纤或者 Wi-Fi 信号发送出去。通俗理解这就是“运货的卡车、公路和桥梁”。实际开发举例这属于硬件和底层驱动的范畴。前端通常不直接碰这一块但如果你在公司内网开发发现接口死活不通最后排查发现是机房的光纤被老鼠咬断了那就是最底层出了问题。五、OSI 七层模型1. 物理层Physical Layer公路与卡车核心功能负责硬件层面的物理信号传输把数据变成 0 和 1 的电信号、光信号或无线电波。通俗理解这是快递运输的“物理基础设施”。没有公路、铁路卡车就开不动。实际开发举例你手里的网线、光纤或者手机连接的 Wi-Fi 信号都属于这一层。如果你发现电脑右下角的网络图标变成了一个“地球仪未连接”大概率就是物理层出问题了比如网线松了。2. 数据链路层Data Link Layer同城快递站核心功能负责局域网内的数据传输用MAC 地址进行寻址并将数据封装成“帧”。通俗理解快递在同一个城市里快递站是怎么把包裹准确送到你手上的靠的是你家门牌号MAC 地址。实际开发举例你家里的路由器、交换机就是这一层的设备。它们通过 MAC 地址识别你家里的手机、电脑和智能电视。3. 网络层Network Layer跨国导航系统核心功能负责跨网络的寻址IP 地址和路由选择找到最优路径。通俗理解包裹要从北京寄到纽约走哪条航线最快这就需要“导航系统”来规划路线。实际开发举例IP 协议IPv4/IPv6和路由器Router是这一层的核心。前端常说的“DNS 解析”就是把域名翻译成 IP 地址好让网络层知道目的地在哪。4. 传输层Transport Layer靠谱的物流保障核心功能负责端到端的可靠传输通过端口号区分不同的应用程序并提供流量控制和错误重传。通俗理解包裹到了对方城市怎么确保交到“你”手里而不是邻居手里如果包裹丢了怎么保证能补发实际开发举例这就是我们上次聊的TCP和UDP协议。TCP 负责“靠谱”比如下载文件丢一个包都不行UDP 负责“快”比如视频直播丢一帧画面就丢了没必要重传。5. 会话层Session Layer电话接线员核心功能负责建立、管理和终止两个应用程序之间的通信会话。通俗理解就像你打长途电话接线员帮你接通聊完后帮你挂断。如果聊到一半断线了接线员还能帮你重连。实际开发举例你在网页上登录了一个后台系统哪怕你刷新页面、切换标签页系统依然知道“你还是你”。这背后就有会话层在维持你们的“对话状态”。6. 表示层Presentation Layer数据翻译官核心功能负责数据的格式转换、加密与解密、压缩与解压缩。通俗理解你写了一封中文信表示层负责把它翻译成英文或者放进加密保险箱确保对方能看懂且不被偷看。实际开发举例我们上次聊的HTTPS 加密SSL/TLS就是在这一层完成的另外前端发送 JSON 数据、图片JPEG/PNG表示层会确保这些数据在网络中以正确的格式传输。7. 应用层Application Layer写信的人核心功能直接面向用户为应用程序提供网络服务接口。通俗理解这是离你最近的一层也就是你真正在用的软件。实际开发举例作为前端你天天打交道的HTTP/HTTPS 协议、网页浏览、FTP 文件传输都属于应用层。你在浏览器里敲下网址回车就是应用层开始工作了。六、TCP/IP 四层模型1. 网络接口层Network Interface Layer合并了 OSI 的物理层 数据链路层核心功能负责将数据变成电信号/光信号并在物理硬件如网卡、网线、路由器之间传输。通俗理解就是“公路和卡车”。它不关心你寄的是什么只负责把货物从一个物理节点搬到下一个物理节点。实际开发举例前端平时基本不碰这一层。但如果你的公司突然断网了或者你发现电脑连不上 Wi-Fi那就是这一层出了问题。2. 网络层Internet Layer对应 OSI 的网络层核心功能负责在庞大的互联网中寻找目标地址IP 地址并规划最佳传输路线。通俗理解就是“导航系统”。不管包裹从哪里寄出这一层都要确保它能跨越千山万水准确找到目的地的服务器。实际开发举例最核心的协议就是IP 协议。前端常说的“DNS 解析”把域名变成 IP 地址就是为了给网络层提供导航坐标。3. 传输层Transport Layer对应 OSI 的传输层核心功能负责端到端的可靠传输。通过端口号区分不同的应用程序并提供流量控制和错误重传。通俗理解就是“快递公司的分拣中心”。包裹到了目标服务器后怎么知道是交给微信、浏览器还是游戏靠的就是端口号。如果包裹丢了它还负责补发。实际开发举例这一层有两个大明星TCP靠谱保证数据完整不丢包比如你下载文件、请求接口。UDP速度快但不保证一定送达比如视频直播、打语音电话稍微卡一下没关系但不能等它重传。4. 应用层Application Layer合并了 OSI 的应用层 表示层 会话层核心功能直接面向用户为应用程序提供网络服务接口。同时兼顾了数据的格式转换、加密解密和会话管理。通俗理解就是“写信的内容和信封”。规定了大家用什么语言沟通HTTP信件要不要加密HTTPS以及怎么证明“我是我”Session/Token。实际开发举例这是前端工程师天天打交道的一层你写的fetch()、axios请求配置的请求头Headers处理的JSON 数据全都是应用层的工作。七、TCP协议严谨的“顺丰快递”1. 什么是 TCPTCP传输控制协议最大的特点就是“靠谱”。它就像是一个极度负责任的顺丰快递员在送货前会先确认你在家送货时会让你签字如果包裹丢了他绝对会给你重新送一份直到你完完整整地收到为止。2. 核心特点面向连接在发数据前必须先建立连接也就是面试必考的“三次握手”。可靠传输不丢包、不乱序、有重传机制。速度相对较慢因为要各种确认、排队开销比较大。实际开发举例作为前端你平时用axios或fetch请求后端的接口比如获取用户信息、提交订单底层用的全都是TCP。因为订单数据少一个字节都不行必须保证 100% 准确送达。3. 三次握手详解建立连接的“契约”在 TCP 协议中有三个非常核心的英文缩写你必须先记住SYNSynchronize同步序列号。通俗点说就是“呼叫请求”。ACKAcknowledge确认字符。通俗点说就是“收到/确认”。SEQSequence序列号。相当于快递单号用来保证数据不乱序。详细过程拆解第一次握手客户端 → 服务端动作客户端向服务端发送一个 SYN 报文比如SYN1, SEQx。状态变化客户端进入SYN_SENT已发送请求状态。通俗翻译客户端说“喂我想跟你建立连接我的初始单号是 x。”第二次握手服务端 → 客户端动作服务端收到 SYN 后如果同意连接就回复一个 SYNACK 报文SYN1, ACK1, SEQy, ACKx1。状态变化服务端进入SYN_RCVD已收到请求状态。通俗翻译服务端说“我收到你的请求了我也同意连接。我的初始单号是 y并且我确认收到了你的 xx1。”第三次握手客户端 → 服务端动作客户端收到确认后再发送一个 ACK 报文ACK1, SEQx1, ACKy1。状态变化双方都进入ESTABLISHED连接已建立状态可以开始传 HTTP 数据了通俗翻译客户端说“好的我也确认收到你的单号 y 了咱们正式开始聊天吧”面试必问为什么不能是两次握手防止“历史连接”导致资源浪费假设客户端发出的第一个 SYN 因为网络卡顿迟迟没到服务端。客户端超时后重发了第二个 SYN这次顺利建立了连接。聊完后连接断开了。就在这时那个迟到的“第一个 SYN”突然到了服务端。如果只有两次握手服务端会直接同意并分配内存资源。但客户端其实根本不需要这个连接了服务端就会白白浪费资源这叫“历史幽灵”。有了第三次握手客户端发现这不是自己想要的连接就会发送一个RST重置报文服务端收到后就会释放资源。4. 四次挥手详解断开连接的“体面告别”断开连接之所以比建立连接多一次是因为 TCP 是全双工的双方都能随时发数据。当一方说“我说完了”时另一方可能还有数据没发完。详细过程拆解第一次挥手客户端 → 服务端动作客户端发送 FIN 报文FIN1, SEQu。状态变化客户端进入FIN_WAIT_1等待服务端确认状态。通俗翻译客户端说“我这边要说的话说完了准备挂电话了。”第二次挥手服务端 → 客户端动作服务端收到 FIN 后回复 ACK 报文ACK1, SEQv, ACKu1。状态变化服务端进入CLOSE_WAIT等待本地应用处理完状态客户端进入FIN_WAIT_2状态。通俗翻译服务端说“收到我知道你要挂了。但我这里可能还有最后一点数据没传完你先别急着挂等我一下。”注意此时连接处于**“半关闭”**状态客户端不能再发数据但服务端还能发。第三次挥手服务端 → 客户端动作服务端把剩下的数据都发完后发送自己的 FIN 报文FIN1, SEQw。状态变化服务端进入LAST_ACK等待最后确认状态。通俗翻译服务端说“好了我这边也彻底处理完了现在可以正式挂断了。”第四次挥手客户端 → 服务端动作客户端收到后回复 ACK 报文ACK1, ACKw1。状态变化客户端进入TIME_WAIT时间等待状态服务端收到后直接关闭连接。通俗翻译客户端说“好的拜拜”注意客户端发完最后一次 ACK 后不会立刻关闭而是会原地等待2MSL最大报文生存时间才彻底关闭。面试必问为什么客户端最后要等 2MSL 才彻底关闭为了保证最后一次 ACK 能安全送达如果客户端发完最后一次 ACK 就立刻关闭了万一这个 ACK 在半路丢了怎么办服务端没收到就会重新发送第三次挥手的 FIN。如果客户端已经彻底关闭了就收不到重发的 FIN服务端就会一直傻等。客户端等待 2MSL 的时间足够让服务端重发的 FIN 到达或者确认自己发出的 ACK 已经安全抵达。八、UDP协议随性的“发传单小哥”1. 什么是 UDPUDP用户数据报协议主打一个“快”。它就像是一个骑着摩托车狂飙的发传单小哥只管把手里的传单数据扔出去根本不管你收没收到也不管传单有没有被风吹跑。2. 核心特点无连接不需要提前打招呼有数据直接发。不可靠可能会丢包可能会乱序它不管。速度极快没有那么多繁琐的确认流程开销极小。实际开发举例如果你在做网页版视频直播、多人在线语音通话或者网页游戏底层通常用的是UDP。为什么因为视频和语音对“实时性”要求极高。如果刚才那一秒的画面卡了直接扔掉看下一帧就行了如果像 TCP 那样非要等重传你的视频就会一直卡顿缓冲用户体验极差。九、 TCP vs UDP核心对比对比维度TCP顺丰快递UDP发传单小哥可靠性极高。保证数据完整、按序到达丢包会重传。低。不保证送达不保证顺序丢了就丢了。连接方式面向连接。发送前必须“三次握手”结束后“四次挥手”。无连接。随时可以发数据不需要提前打招呼。传输速度较慢。因为有各种确认机制和排队等待开销大。极快。没有繁琐的确认流程直接“扔”数据。系统资源消耗高。需要维护连接状态占用较多内存和 CPU。低。不需要维护连接状态非常轻量。应用场景要求数据绝对准确的场景如网页请求、文件下载、支付。要求实时性高、允许少量丢包的场景如视频直播、语音、游戏。十、HTTPS 加密HTTPS 并不是一个全新的协议它其实就是HTTP SSL/TLS加密层。为了让你秒懂它是怎么工作的咱们继续用“寄绝密文件”的例子把它扒个底朝天1. SSL/TLS 是什么SSLSecure Sockets Layer安全套接层和TLSTransport Layer Security传输层安全本质上是一回事——TLS 是 SSL 的升级版现在主流用的是TLS 1.2 / 1.3但大家习惯上还是统称为 SSL。通俗理解SSL/TLS 就像是给 HTTP 这封信加了一个“防拆封条”和“加密保险箱”。快递员中间人虽然能帮你送信但他拆不开、改不了也看不懂里面的内容。2. HTTPS 加密的核心武器混合加密HTTPS 的加密机制其实用的是非对称加密 对称加密的组合拳也就是“混合加密”。为什么不能只用一种咱们用寄绝密文件的场景来解释场景设定你要给远方的朋友寄一封绝密信件但快递员可能会偷看。你怎么保证信件内容只有你和朋友能看到非对称加密用来传钥匙你有一把公开的锁公钥和一把私藏的钥匙私钥。你把锁寄给朋友朋友用这把锁把一封信箱锁好寄回来——这封信箱里装的就是你们接下来要用的“通用钥匙”。除了你没人能用私钥打开这把锁。对称加密用来传正文双方拿到“通用钥匙”后接下来所有的绝密信件都用这把钥匙来加密和解密。速度快效率高。为什么不能只用非对称加密因为非对称加密非常慢如果全部数据都用它加密网页加载会慢到让你怀疑人生。为什么不能只用对称加密因为双方一开始根本没有一个安全的方式来交换那把“通用钥匙”——如果直接通过网络传可能被中间人偷走。所以HTTPS 的聪明之处就在于用非对称加密保护“对称加密钥匙”的交换再用对称加密保护真正的数据传输——扬长避短安全又高效。3. HTTPS 握手全过程寄绝密文件四步走HTTPS 在真正传数据之前浏览器和服务器之间会先走一个SSL/TLS 握手流程协商好加密方式、交换好密钥。整个过程可以拆解为四步第一步客户端打招呼Client Hello浏览器向服务器发送一个“打招呼”消息内容包括浏览器支持的TLS 版本比如 TLS 1.2 / 1.3。浏览器支持的加密套件密码算法列表比如TLS_AES_256_GCM_SHA384。一个随机数客户端随机数后续用于生成密钥。通俗翻译浏览器说“嘿我想跟你安全通信我支持这几种加密方式你看看哪个合适”第二步服务端回应Server Hello服务器收到打招呼后回复浏览器选定的TLS 版本和加密套件。一个随机数服务端随机数后续用于生成密钥。数字证书包含服务器的公钥由 CA 机构签发用来证明“我就是我”。通俗翻译服务器说“好的咱们就用这个加密方式这是我的身份证数字证书里面有我的公钥你先验一下。”第三步客户端验证证书 生成密钥浏览器拿到证书后会做两件事验证证书检查证书是否由受信任的 CA 签发、是否过期、域名是否匹配。如果验证失败浏览器会直接弹出“不安全”警告。生成预主密钥用一个Pre-Master Secret预主密钥通过服务器的公钥加密后发送给服务器。接着客户端和服务端各自用客户端随机数 服务端随机数 预主密钥独立计算出同一把会话密钥Session Key。通俗翻译浏览器验完身份证确认对方不是冒牌货后把一把“临时钥匙”用服务器的公钥锁好寄回去。现在双方手里都有相同的三样东西两个随机数 临时钥匙就能拼出同一把通用钥匙了。第四步双方确认开始加密通信客户端发送一个Finished消息用会话密钥加密告诉服务器“我准备好了之后所有内容都用这把密钥加密”。服务端收到后也回复一个加密的Finished消息。握手结束接下来所有 HTTP 数据都用对称加密传输。通俗翻译双方互相确认“钥匙没问题开始正式通信”之后所有的绝密信件都用这把钥匙加密快递员再也看不懂了。4. 数字证书与 CA谁来保证“公钥”是真实的你可能会有个疑问在第二步服务器把公钥发给了浏览器万一中间人把服务器发的公钥掉包换成自己的公钥怎么办这就是中间人攻击MITM。解法数字证书 CA证书颁发机构CACertificate Authority是一个权威的第三方机构如 DigiCert、Let’s Encrypt负责给网站颁发“身份证”——数字证书。证书里包含网站的域名、网站的公钥、证书有效期、CA 的数字签名。浏览器内置了受信任的 CA 列表。拿到证书时浏览器会用 CA 的公钥验证 CA 的数字签名——如果签名合法就说明证书里的公钥确实是该网站的公钥没有被掉包。通俗理解你不是直接相信对方说“我是张三”而是要看对方拿出的身份证并且用公安局的印章来验证身份证的真伪。CA 就是那个“公安局”数字证书就是“身份证”。5. HTTPS 的加密流程总结为了让整个过程一目了然这里用一张表帮你梳理 HTTPS 的完整加密流程阶段干什么用的加密方式通俗类比SSL/TLS 握手验证身份、协商密钥非对称加密RSA/ECDH 等“验身份证 交换通用钥匙”数据传输加密传输 HTTP 数据对称加密AES/ChaCha20 等“用通用钥匙加密信件内容”完整性校验确保数据没被篡改MAC消息认证码“防拆封条撕了就报警”一句话总结HTTPS 用非对称加密完成“身份验证”和“密钥交换”再用对称加密进行“高效数据传输”同时用 MAC 保证数据完整性——三管齐下确保通信安全。十一、HTTP历史版本HTTP 协议从诞生至今经历了多次重大升级每一次迭代都在解决上一代的痛点。了解这些版本差异不仅能帮你应对面试更能让你理解前端性能优化的底层逻辑。1. HTTP/1.0最原始的“单次快递” 特点每次浏览器向服务器要一个文件比如一张图片快递员就要跑一趟。送完这趟两人就“断联”了。如果要下一张图片还得重新建立联系。实际开发场景想象一下你打开一个包含 10 张图片的网页浏览器就得和服务器建立 10 次连接。这不仅慢而且非常消耗服务器资源。这就好比你要寄 10 个包裹快递员每次只拿一个送完就下班你还得重新打电话叫他。补充说明HTTP/1.0 于 1996 年正式发布每个请求都需要建立独立的 TCP 连接请求结束后立即断开。这种短连接模式在高并发场景下会造成严重的性能瓶颈——频繁的 TCP 握手和挥手消耗了大量 CPU 和内存资源。2. HTTP/1.1有了“长连接”但依然会“堵车” 特点为了解决 1.0 的问题1.1 引入了持久连接Keep-Alive。快递员送完一个包裹不用下班了可以接着送下一个。但是它有一个致命弱点队头阻塞Head-of-Line Blocking。实际开发场景虽然不用频繁建立连接了但在同一条车道TCP 连接上包裹必须排队。如果第一个大文件比如一个很大的 JS 文件传输卡住了后面的小文件比如 CSS 样式、小图标哪怕早就准备好了也只能干等着。这就好比单车道隧道前面一辆车抛锚了后面的车全得堵着。补充说明HTTP/1.1 还引入了管道化Pipelining——客户端可以连续发送多个请求而不用等待上一个响应。但管道化要求服务端必须按顺序返回响应队头阻塞问题依然存在因此浏览器默认都关闭了管道化功能。此外HTTP/1.1 还新增了Host 头部支持虚拟主机、缓存协商机制Cache-Control、ETag等以及断点续传Range请求等实用特性。3. HTTP/2.0多车道并行的“高速公路” ️特点这是前端开发中非常熟悉的一个版本。它引入了多路复用Multiplexing和二进制分帧Binary Framing。实际开发场景它把单车道变成了多车道的高速公路。浏览器和服务器之间虽然还是只有一条 TCP 连接但数据被切分成了一个个小帧Frame。请求 A 的帧和请求 B 的帧可以在这条路上交错着同时跑。如果请求 A 卡住了请求 B 依然可以畅通无阻地到达。这极大地提升了我们前端页面的加载速度。补充说明HTTP/2.0 于 2015 年发布除了多路复用还带来了以下关键特性头部压缩HPACKHTTP/1.x 的请求头每次都要全量发送包含大量重复字段如 Cookie、User-Agent。HTTP/2 使用 HPACK 算法对这些头部进行压缩大幅减少传输体积。服务器推送Server Push服务器可以主动把客户端可能需要的资源如 CSS、JS提前推送过去省去客户端再次请求的往返时间。不过实际生产中由于兼容性和缓存问题这个特性使用较少。流优先级Stream Prioritization可以为不同的请求设置优先级让重要资源如 HTML优先传输。注意HTTP/2.0 虽然解决了应用层的队头阻塞但底层的 TCP 协议仍然存在传输层的队头阻塞——如果某个 TCP 数据包丢失整个连接的所有流都会被阻塞等待重传。4. HTTP/3.0不走寻常路的“无人机快递” 特点HTTP/2.0 虽然快但底层的 TCP 协议还是有点笨重。于是 HTTP/3.0 诞生了它直接抛弃了 TCP改用基于 UDP 的QUIC协议。实际开发场景如果说 HTTP/2.0 是高速公路HTTP/3.0 就是无人机。它最大的优势是连接建立极快0-RTT并且在移动网络下表现极佳。比如你在地铁上用手机看网页从 4G 切换到 Wi-Fi以前的协议可能因为 IP 变了要重新连接但 HTTP/3.0 根本不在乎它能无缝衔接视频都不会卡顿。补充说明HTTP/3.0 的核心优势0-RTT 连接建立QUIC 在首次连接后缓存密钥再次连接时无需握手即可直接发送数据延迟极低。彻底解决队头阻塞QUIC 在 UDP 之上实现了类似 TCP 的可靠传输但以流为单位独立传输——一个流的丢包不会阻塞其他流。连接迁移QUIC 使用 Connection ID 而非 IP 端口来标识连接即使网络切换Wi-Fi → 4G连接也能无缝迁移不会断开。内置加密QUIC 默认集成了 TLS 1.3所有数据都加密传输不像 TCP 需要额外叠加 TLS。版本发布时间底层协议核心特性主要痛点HTTP/1.01996TCP短连接一问一答每次请求都要重新建立连接性能极差HTTP/1.11997TCP持久连接、管道化、缓存协商队头阻塞并发请求有限HTTP/2.02015TCP多路复用、二进制分帧、头部压缩TCP 层队头阻塞仍然存在HTTP/3.02022UDPQUIC0-RTT、连接迁移、彻底解决队头阻塞部署成本较高部分网络环境兼容性有限十二、什么是多路复用核心原理HTTP/2.0 的多路复用直接把这单车道升级成了多车道的高速公路。它是怎么做到的呢它引入了两个关键概念二进制分帧Binary Framing它不再用以前那种纯文本格式发数据了而是把你要请求的数据HTML、CSS、JS全部切成一个个非常小的、二进制的数据块叫做帧Frame。流Stream每一个请求和响应都被分配了一个独立的流StreamID。通俗场景假设你要下载 1 个 JS 文件、1 个 CSS 文件和 5 张图片。在 HTTP/2.0 下这些数据被切成了无数个小帧。虽然它们都在同一条 TCP 连接同一条高速公路上跑但每个帧都带着自己的身份证号Stream ID。服务器发数据时JS 的帧、CSS 的帧、图片的帧可以交错着、并行地发过来。浏览器收到后再根据身份证号把它们拼装回原来的文件。结果哪怕 JS 文件的传输卡住了CSS 和图片的帧依然可以从旁边超车过去完美解决了 HTTP/1.1 的队头阻塞一张图理解多路复用 vs 传统请求对比维度HTTP/1.1单车道HTTP/2.0 多路复用多车道连接数同一域名通常建立 6~8 个 TCP 连接浏览器限制只需1 个TCP 连接请求方式串行排队前面的请求卡住后面的全等并行交错互不阻塞数据格式纯文本明文 HTTP 报文二进制帧体积更小解析更快资源加载文件一个一个来瀑布流明显所有文件同时加载谁先到先拼装头部开销每次请求都带完整头部重复浪费HPACK 压缩头部体积大幅减少补充理解为什么多路复用能提升性能减少 TCP 连接数HTTP/1.1 时代浏览器为了解决队头阻塞只能同时开多个 TCP 连接比如 Chrome 最多对同一域名开 6 个。但这会消耗大量资源而且多个连接之间存在竞争。HTTP/2 只用一条连接省去了连接管理的开销。避免连接风暴多个 TCP 连接同时传输时会互相抢占带宽反而导致整体效率下降。单连接多路复用能够更合理地分配带宽。更快的首屏加载所有资源并行传输关键渲染路径上的 CSS 和 JS 可以更快地到达浏览器加速页面渲染。
七、浏览器网络通信
一、 HTTP协议互联网世界的“普通话”1. 什么是 HTTPHTTP超文本传输协议就是浏览器和服务器之间沟通的“普通话”。它规定了浏览器怎么向服务器要数据服务器怎么把数据给浏览器。2. 它的三大核心特点通俗版无状态不认人HTTP 就像是一个“金鱼记忆”的快递员。你刚给他下了一单买鞋他送完货就忘了你是谁。如果你再下一单买衣服他不知道你就是刚才买鞋的那个人。实际开发举例这就是为什么我们需要Cookie和Token的原因。因为 HTTP 不认人我们必须给每个用户发一张“身份识别卡Token”每次请求都带上服务器才知道“哦这是张三他有权限看这个页面”。请求-响应模型一问一答浏览器不问服务器绝不主动说话。实际开发举例如果网页想实现“别人给你点赞你的网页自动弹出红点”用纯 HTTP 是做不到的因为服务器不能主动推给你。前端通常只能用“轮询”每隔1秒问一次服务器有新消息吗但这太浪费资源了。所以后来才催生了WebSocket这种能双向沟通的协议。明文传输裸奔HTTP 发送的数据是不加密的。实际开发举例如果你在 HTTP 协议下输入了银行卡密码黑客只要在你的网络节点上抓个包就能像看报纸一样清清楚楚地看到你的密码。二、 HTTPS协议给 HTTP 穿上“防弹衣”1. 什么是 HTTPS简单来说HTTPS HTTP SSL/TLS加密层。它并不是一个全新的协议而是在 HTTP 的基础上加了一层加密保护。2. 它是怎么工作的非对称加密与对称加密你可以把它想象成“配钥匙”的过程非对称加密用来交换钥匙浏览器和服务器一开始先通过一种复杂的方式安全地交换一把“通用钥匙”。这个过程就算被黑客看到他也偷不走。对称加密用来传数据双方拿到“通用钥匙”后接下来所有的聊天、传数据都用这把钥匙进行加密和解密。实际开发举例这就是为什么你打开银行网站、淘宝支付页面时浏览器地址栏会出现一个“小锁”图标。它告诉用户“放心咱们现在的对话是加密的就算有人在网吧里抓包看到的也是一堆乱码。”三、 HTTP vs HTTPS核心对比为了让你一目了然我整理了一张对比表。在实际开发中这也是我们做技术选型和排查问题时的核心依据对比维度HTTPHTTPS安全性极低。明文传输容易被窃听、篡改。极高。数据加密传输防窃听、防篡改。性能消耗低。不需要进行加密和解密计算速度快。较高。需要消耗 CPU 进行加解密且首次连接握手会稍微慢一点点。端口号默认使用80端口。默认使用443端口。证书成本免费。不需要申请任何证书。收费/需配置。需要向 CA 机构申请 SSL 证书现在也有很多免费证书如 Let’s Encrypt。SEO 友好度一般。更好。搜索引擎如百度、谷歌会优先展示 HTTPS 网站。浏览器态度会提示“不安全”。显示“小锁”图标给予信任。四、HTTP底层协议1. HTTP 属于哪一层—— 应用层在经典的OSI 七层模型或者更常用的 TCP/IP 四层模型中HTTP 属于最顶层的“应用层”。通俗理解应用层就像是“写信的内容”。它规定了咱们俩聊天用什么语言、格式是什么比如我要买一双鞋请发货。实际开发举例作为前端你平时写的fetch()或axios请求配置的Header请求头、Body请求体都是在跟应用层的 HTTP 协议打交道。2. HTTP 的底层协议是什么—— TCP 协议HTTP 自己是个“甩手掌柜”它只负责规定内容格式不管数据怎么安全、准确地送达。这个苦力活交给了它的底层协议——TCP传输控制协议。通俗理解TCP 就像是“靠谱的快递物流网”。HTTP 把信件内容数据交给 TCPTCP 负责把信件打包成一个个小包裹规划路线确保对方一个不少地收到。如果中途有个包裹丢了TCP 还会自动重发。实际开发举例你有没有遇到过网页加载到一半图片突然裂开了或者请求卡住不动这往往就是底层的 TCP 连接出了问题比如网络波动导致数据包丢失TCP 正在疯狂尝试重传。3. TCP 的底层又是什么—— IP 协议TCP 虽然靠谱但它不知道收件人的具体地址在哪。这就需要它的底层协议——IP网际协议。通俗理解IP 就像是“快递单上的地址和导航系统”。它负责在茫茫互联网中找到目标服务器的 IP 地址并把包裹送达。实际开发举例前端开发中经常听到的“DNS 解析”就是把域名如baidu.com翻译成底层的 IP 地址如110.242.68.4这就是在给 IP 协议提供导航信息。4. 最底层的基石是什么—— 网络接口层网卡与物理介质IP 知道地址后数据最终要通过网线、光纤或者 Wi-Fi 信号发送出去。通俗理解这就是“运货的卡车、公路和桥梁”。实际开发举例这属于硬件和底层驱动的范畴。前端通常不直接碰这一块但如果你在公司内网开发发现接口死活不通最后排查发现是机房的光纤被老鼠咬断了那就是最底层出了问题。五、OSI 七层模型1. 物理层Physical Layer公路与卡车核心功能负责硬件层面的物理信号传输把数据变成 0 和 1 的电信号、光信号或无线电波。通俗理解这是快递运输的“物理基础设施”。没有公路、铁路卡车就开不动。实际开发举例你手里的网线、光纤或者手机连接的 Wi-Fi 信号都属于这一层。如果你发现电脑右下角的网络图标变成了一个“地球仪未连接”大概率就是物理层出问题了比如网线松了。2. 数据链路层Data Link Layer同城快递站核心功能负责局域网内的数据传输用MAC 地址进行寻址并将数据封装成“帧”。通俗理解快递在同一个城市里快递站是怎么把包裹准确送到你手上的靠的是你家门牌号MAC 地址。实际开发举例你家里的路由器、交换机就是这一层的设备。它们通过 MAC 地址识别你家里的手机、电脑和智能电视。3. 网络层Network Layer跨国导航系统核心功能负责跨网络的寻址IP 地址和路由选择找到最优路径。通俗理解包裹要从北京寄到纽约走哪条航线最快这就需要“导航系统”来规划路线。实际开发举例IP 协议IPv4/IPv6和路由器Router是这一层的核心。前端常说的“DNS 解析”就是把域名翻译成 IP 地址好让网络层知道目的地在哪。4. 传输层Transport Layer靠谱的物流保障核心功能负责端到端的可靠传输通过端口号区分不同的应用程序并提供流量控制和错误重传。通俗理解包裹到了对方城市怎么确保交到“你”手里而不是邻居手里如果包裹丢了怎么保证能补发实际开发举例这就是我们上次聊的TCP和UDP协议。TCP 负责“靠谱”比如下载文件丢一个包都不行UDP 负责“快”比如视频直播丢一帧画面就丢了没必要重传。5. 会话层Session Layer电话接线员核心功能负责建立、管理和终止两个应用程序之间的通信会话。通俗理解就像你打长途电话接线员帮你接通聊完后帮你挂断。如果聊到一半断线了接线员还能帮你重连。实际开发举例你在网页上登录了一个后台系统哪怕你刷新页面、切换标签页系统依然知道“你还是你”。这背后就有会话层在维持你们的“对话状态”。6. 表示层Presentation Layer数据翻译官核心功能负责数据的格式转换、加密与解密、压缩与解压缩。通俗理解你写了一封中文信表示层负责把它翻译成英文或者放进加密保险箱确保对方能看懂且不被偷看。实际开发举例我们上次聊的HTTPS 加密SSL/TLS就是在这一层完成的另外前端发送 JSON 数据、图片JPEG/PNG表示层会确保这些数据在网络中以正确的格式传输。7. 应用层Application Layer写信的人核心功能直接面向用户为应用程序提供网络服务接口。通俗理解这是离你最近的一层也就是你真正在用的软件。实际开发举例作为前端你天天打交道的HTTP/HTTPS 协议、网页浏览、FTP 文件传输都属于应用层。你在浏览器里敲下网址回车就是应用层开始工作了。六、TCP/IP 四层模型1. 网络接口层Network Interface Layer合并了 OSI 的物理层 数据链路层核心功能负责将数据变成电信号/光信号并在物理硬件如网卡、网线、路由器之间传输。通俗理解就是“公路和卡车”。它不关心你寄的是什么只负责把货物从一个物理节点搬到下一个物理节点。实际开发举例前端平时基本不碰这一层。但如果你的公司突然断网了或者你发现电脑连不上 Wi-Fi那就是这一层出了问题。2. 网络层Internet Layer对应 OSI 的网络层核心功能负责在庞大的互联网中寻找目标地址IP 地址并规划最佳传输路线。通俗理解就是“导航系统”。不管包裹从哪里寄出这一层都要确保它能跨越千山万水准确找到目的地的服务器。实际开发举例最核心的协议就是IP 协议。前端常说的“DNS 解析”把域名变成 IP 地址就是为了给网络层提供导航坐标。3. 传输层Transport Layer对应 OSI 的传输层核心功能负责端到端的可靠传输。通过端口号区分不同的应用程序并提供流量控制和错误重传。通俗理解就是“快递公司的分拣中心”。包裹到了目标服务器后怎么知道是交给微信、浏览器还是游戏靠的就是端口号。如果包裹丢了它还负责补发。实际开发举例这一层有两个大明星TCP靠谱保证数据完整不丢包比如你下载文件、请求接口。UDP速度快但不保证一定送达比如视频直播、打语音电话稍微卡一下没关系但不能等它重传。4. 应用层Application Layer合并了 OSI 的应用层 表示层 会话层核心功能直接面向用户为应用程序提供网络服务接口。同时兼顾了数据的格式转换、加密解密和会话管理。通俗理解就是“写信的内容和信封”。规定了大家用什么语言沟通HTTP信件要不要加密HTTPS以及怎么证明“我是我”Session/Token。实际开发举例这是前端工程师天天打交道的一层你写的fetch()、axios请求配置的请求头Headers处理的JSON 数据全都是应用层的工作。七、TCP协议严谨的“顺丰快递”1. 什么是 TCPTCP传输控制协议最大的特点就是“靠谱”。它就像是一个极度负责任的顺丰快递员在送货前会先确认你在家送货时会让你签字如果包裹丢了他绝对会给你重新送一份直到你完完整整地收到为止。2. 核心特点面向连接在发数据前必须先建立连接也就是面试必考的“三次握手”。可靠传输不丢包、不乱序、有重传机制。速度相对较慢因为要各种确认、排队开销比较大。实际开发举例作为前端你平时用axios或fetch请求后端的接口比如获取用户信息、提交订单底层用的全都是TCP。因为订单数据少一个字节都不行必须保证 100% 准确送达。3. 三次握手详解建立连接的“契约”在 TCP 协议中有三个非常核心的英文缩写你必须先记住SYNSynchronize同步序列号。通俗点说就是“呼叫请求”。ACKAcknowledge确认字符。通俗点说就是“收到/确认”。SEQSequence序列号。相当于快递单号用来保证数据不乱序。详细过程拆解第一次握手客户端 → 服务端动作客户端向服务端发送一个 SYN 报文比如SYN1, SEQx。状态变化客户端进入SYN_SENT已发送请求状态。通俗翻译客户端说“喂我想跟你建立连接我的初始单号是 x。”第二次握手服务端 → 客户端动作服务端收到 SYN 后如果同意连接就回复一个 SYNACK 报文SYN1, ACK1, SEQy, ACKx1。状态变化服务端进入SYN_RCVD已收到请求状态。通俗翻译服务端说“我收到你的请求了我也同意连接。我的初始单号是 y并且我确认收到了你的 xx1。”第三次握手客户端 → 服务端动作客户端收到确认后再发送一个 ACK 报文ACK1, SEQx1, ACKy1。状态变化双方都进入ESTABLISHED连接已建立状态可以开始传 HTTP 数据了通俗翻译客户端说“好的我也确认收到你的单号 y 了咱们正式开始聊天吧”面试必问为什么不能是两次握手防止“历史连接”导致资源浪费假设客户端发出的第一个 SYN 因为网络卡顿迟迟没到服务端。客户端超时后重发了第二个 SYN这次顺利建立了连接。聊完后连接断开了。就在这时那个迟到的“第一个 SYN”突然到了服务端。如果只有两次握手服务端会直接同意并分配内存资源。但客户端其实根本不需要这个连接了服务端就会白白浪费资源这叫“历史幽灵”。有了第三次握手客户端发现这不是自己想要的连接就会发送一个RST重置报文服务端收到后就会释放资源。4. 四次挥手详解断开连接的“体面告别”断开连接之所以比建立连接多一次是因为 TCP 是全双工的双方都能随时发数据。当一方说“我说完了”时另一方可能还有数据没发完。详细过程拆解第一次挥手客户端 → 服务端动作客户端发送 FIN 报文FIN1, SEQu。状态变化客户端进入FIN_WAIT_1等待服务端确认状态。通俗翻译客户端说“我这边要说的话说完了准备挂电话了。”第二次挥手服务端 → 客户端动作服务端收到 FIN 后回复 ACK 报文ACK1, SEQv, ACKu1。状态变化服务端进入CLOSE_WAIT等待本地应用处理完状态客户端进入FIN_WAIT_2状态。通俗翻译服务端说“收到我知道你要挂了。但我这里可能还有最后一点数据没传完你先别急着挂等我一下。”注意此时连接处于**“半关闭”**状态客户端不能再发数据但服务端还能发。第三次挥手服务端 → 客户端动作服务端把剩下的数据都发完后发送自己的 FIN 报文FIN1, SEQw。状态变化服务端进入LAST_ACK等待最后确认状态。通俗翻译服务端说“好了我这边也彻底处理完了现在可以正式挂断了。”第四次挥手客户端 → 服务端动作客户端收到后回复 ACK 报文ACK1, ACKw1。状态变化客户端进入TIME_WAIT时间等待状态服务端收到后直接关闭连接。通俗翻译客户端说“好的拜拜”注意客户端发完最后一次 ACK 后不会立刻关闭而是会原地等待2MSL最大报文生存时间才彻底关闭。面试必问为什么客户端最后要等 2MSL 才彻底关闭为了保证最后一次 ACK 能安全送达如果客户端发完最后一次 ACK 就立刻关闭了万一这个 ACK 在半路丢了怎么办服务端没收到就会重新发送第三次挥手的 FIN。如果客户端已经彻底关闭了就收不到重发的 FIN服务端就会一直傻等。客户端等待 2MSL 的时间足够让服务端重发的 FIN 到达或者确认自己发出的 ACK 已经安全抵达。八、UDP协议随性的“发传单小哥”1. 什么是 UDPUDP用户数据报协议主打一个“快”。它就像是一个骑着摩托车狂飙的发传单小哥只管把手里的传单数据扔出去根本不管你收没收到也不管传单有没有被风吹跑。2. 核心特点无连接不需要提前打招呼有数据直接发。不可靠可能会丢包可能会乱序它不管。速度极快没有那么多繁琐的确认流程开销极小。实际开发举例如果你在做网页版视频直播、多人在线语音通话或者网页游戏底层通常用的是UDP。为什么因为视频和语音对“实时性”要求极高。如果刚才那一秒的画面卡了直接扔掉看下一帧就行了如果像 TCP 那样非要等重传你的视频就会一直卡顿缓冲用户体验极差。九、 TCP vs UDP核心对比对比维度TCP顺丰快递UDP发传单小哥可靠性极高。保证数据完整、按序到达丢包会重传。低。不保证送达不保证顺序丢了就丢了。连接方式面向连接。发送前必须“三次握手”结束后“四次挥手”。无连接。随时可以发数据不需要提前打招呼。传输速度较慢。因为有各种确认机制和排队等待开销大。极快。没有繁琐的确认流程直接“扔”数据。系统资源消耗高。需要维护连接状态占用较多内存和 CPU。低。不需要维护连接状态非常轻量。应用场景要求数据绝对准确的场景如网页请求、文件下载、支付。要求实时性高、允许少量丢包的场景如视频直播、语音、游戏。十、HTTPS 加密HTTPS 并不是一个全新的协议它其实就是HTTP SSL/TLS加密层。为了让你秒懂它是怎么工作的咱们继续用“寄绝密文件”的例子把它扒个底朝天1. SSL/TLS 是什么SSLSecure Sockets Layer安全套接层和TLSTransport Layer Security传输层安全本质上是一回事——TLS 是 SSL 的升级版现在主流用的是TLS 1.2 / 1.3但大家习惯上还是统称为 SSL。通俗理解SSL/TLS 就像是给 HTTP 这封信加了一个“防拆封条”和“加密保险箱”。快递员中间人虽然能帮你送信但他拆不开、改不了也看不懂里面的内容。2. HTTPS 加密的核心武器混合加密HTTPS 的加密机制其实用的是非对称加密 对称加密的组合拳也就是“混合加密”。为什么不能只用一种咱们用寄绝密文件的场景来解释场景设定你要给远方的朋友寄一封绝密信件但快递员可能会偷看。你怎么保证信件内容只有你和朋友能看到非对称加密用来传钥匙你有一把公开的锁公钥和一把私藏的钥匙私钥。你把锁寄给朋友朋友用这把锁把一封信箱锁好寄回来——这封信箱里装的就是你们接下来要用的“通用钥匙”。除了你没人能用私钥打开这把锁。对称加密用来传正文双方拿到“通用钥匙”后接下来所有的绝密信件都用这把钥匙来加密和解密。速度快效率高。为什么不能只用非对称加密因为非对称加密非常慢如果全部数据都用它加密网页加载会慢到让你怀疑人生。为什么不能只用对称加密因为双方一开始根本没有一个安全的方式来交换那把“通用钥匙”——如果直接通过网络传可能被中间人偷走。所以HTTPS 的聪明之处就在于用非对称加密保护“对称加密钥匙”的交换再用对称加密保护真正的数据传输——扬长避短安全又高效。3. HTTPS 握手全过程寄绝密文件四步走HTTPS 在真正传数据之前浏览器和服务器之间会先走一个SSL/TLS 握手流程协商好加密方式、交换好密钥。整个过程可以拆解为四步第一步客户端打招呼Client Hello浏览器向服务器发送一个“打招呼”消息内容包括浏览器支持的TLS 版本比如 TLS 1.2 / 1.3。浏览器支持的加密套件密码算法列表比如TLS_AES_256_GCM_SHA384。一个随机数客户端随机数后续用于生成密钥。通俗翻译浏览器说“嘿我想跟你安全通信我支持这几种加密方式你看看哪个合适”第二步服务端回应Server Hello服务器收到打招呼后回复浏览器选定的TLS 版本和加密套件。一个随机数服务端随机数后续用于生成密钥。数字证书包含服务器的公钥由 CA 机构签发用来证明“我就是我”。通俗翻译服务器说“好的咱们就用这个加密方式这是我的身份证数字证书里面有我的公钥你先验一下。”第三步客户端验证证书 生成密钥浏览器拿到证书后会做两件事验证证书检查证书是否由受信任的 CA 签发、是否过期、域名是否匹配。如果验证失败浏览器会直接弹出“不安全”警告。生成预主密钥用一个Pre-Master Secret预主密钥通过服务器的公钥加密后发送给服务器。接着客户端和服务端各自用客户端随机数 服务端随机数 预主密钥独立计算出同一把会话密钥Session Key。通俗翻译浏览器验完身份证确认对方不是冒牌货后把一把“临时钥匙”用服务器的公钥锁好寄回去。现在双方手里都有相同的三样东西两个随机数 临时钥匙就能拼出同一把通用钥匙了。第四步双方确认开始加密通信客户端发送一个Finished消息用会话密钥加密告诉服务器“我准备好了之后所有内容都用这把密钥加密”。服务端收到后也回复一个加密的Finished消息。握手结束接下来所有 HTTP 数据都用对称加密传输。通俗翻译双方互相确认“钥匙没问题开始正式通信”之后所有的绝密信件都用这把钥匙加密快递员再也看不懂了。4. 数字证书与 CA谁来保证“公钥”是真实的你可能会有个疑问在第二步服务器把公钥发给了浏览器万一中间人把服务器发的公钥掉包换成自己的公钥怎么办这就是中间人攻击MITM。解法数字证书 CA证书颁发机构CACertificate Authority是一个权威的第三方机构如 DigiCert、Let’s Encrypt负责给网站颁发“身份证”——数字证书。证书里包含网站的域名、网站的公钥、证书有效期、CA 的数字签名。浏览器内置了受信任的 CA 列表。拿到证书时浏览器会用 CA 的公钥验证 CA 的数字签名——如果签名合法就说明证书里的公钥确实是该网站的公钥没有被掉包。通俗理解你不是直接相信对方说“我是张三”而是要看对方拿出的身份证并且用公安局的印章来验证身份证的真伪。CA 就是那个“公安局”数字证书就是“身份证”。5. HTTPS 的加密流程总结为了让整个过程一目了然这里用一张表帮你梳理 HTTPS 的完整加密流程阶段干什么用的加密方式通俗类比SSL/TLS 握手验证身份、协商密钥非对称加密RSA/ECDH 等“验身份证 交换通用钥匙”数据传输加密传输 HTTP 数据对称加密AES/ChaCha20 等“用通用钥匙加密信件内容”完整性校验确保数据没被篡改MAC消息认证码“防拆封条撕了就报警”一句话总结HTTPS 用非对称加密完成“身份验证”和“密钥交换”再用对称加密进行“高效数据传输”同时用 MAC 保证数据完整性——三管齐下确保通信安全。十一、HTTP历史版本HTTP 协议从诞生至今经历了多次重大升级每一次迭代都在解决上一代的痛点。了解这些版本差异不仅能帮你应对面试更能让你理解前端性能优化的底层逻辑。1. HTTP/1.0最原始的“单次快递” 特点每次浏览器向服务器要一个文件比如一张图片快递员就要跑一趟。送完这趟两人就“断联”了。如果要下一张图片还得重新建立联系。实际开发场景想象一下你打开一个包含 10 张图片的网页浏览器就得和服务器建立 10 次连接。这不仅慢而且非常消耗服务器资源。这就好比你要寄 10 个包裹快递员每次只拿一个送完就下班你还得重新打电话叫他。补充说明HTTP/1.0 于 1996 年正式发布每个请求都需要建立独立的 TCP 连接请求结束后立即断开。这种短连接模式在高并发场景下会造成严重的性能瓶颈——频繁的 TCP 握手和挥手消耗了大量 CPU 和内存资源。2. HTTP/1.1有了“长连接”但依然会“堵车” 特点为了解决 1.0 的问题1.1 引入了持久连接Keep-Alive。快递员送完一个包裹不用下班了可以接着送下一个。但是它有一个致命弱点队头阻塞Head-of-Line Blocking。实际开发场景虽然不用频繁建立连接了但在同一条车道TCP 连接上包裹必须排队。如果第一个大文件比如一个很大的 JS 文件传输卡住了后面的小文件比如 CSS 样式、小图标哪怕早就准备好了也只能干等着。这就好比单车道隧道前面一辆车抛锚了后面的车全得堵着。补充说明HTTP/1.1 还引入了管道化Pipelining——客户端可以连续发送多个请求而不用等待上一个响应。但管道化要求服务端必须按顺序返回响应队头阻塞问题依然存在因此浏览器默认都关闭了管道化功能。此外HTTP/1.1 还新增了Host 头部支持虚拟主机、缓存协商机制Cache-Control、ETag等以及断点续传Range请求等实用特性。3. HTTP/2.0多车道并行的“高速公路” ️特点这是前端开发中非常熟悉的一个版本。它引入了多路复用Multiplexing和二进制分帧Binary Framing。实际开发场景它把单车道变成了多车道的高速公路。浏览器和服务器之间虽然还是只有一条 TCP 连接但数据被切分成了一个个小帧Frame。请求 A 的帧和请求 B 的帧可以在这条路上交错着同时跑。如果请求 A 卡住了请求 B 依然可以畅通无阻地到达。这极大地提升了我们前端页面的加载速度。补充说明HTTP/2.0 于 2015 年发布除了多路复用还带来了以下关键特性头部压缩HPACKHTTP/1.x 的请求头每次都要全量发送包含大量重复字段如 Cookie、User-Agent。HTTP/2 使用 HPACK 算法对这些头部进行压缩大幅减少传输体积。服务器推送Server Push服务器可以主动把客户端可能需要的资源如 CSS、JS提前推送过去省去客户端再次请求的往返时间。不过实际生产中由于兼容性和缓存问题这个特性使用较少。流优先级Stream Prioritization可以为不同的请求设置优先级让重要资源如 HTML优先传输。注意HTTP/2.0 虽然解决了应用层的队头阻塞但底层的 TCP 协议仍然存在传输层的队头阻塞——如果某个 TCP 数据包丢失整个连接的所有流都会被阻塞等待重传。4. HTTP/3.0不走寻常路的“无人机快递” 特点HTTP/2.0 虽然快但底层的 TCP 协议还是有点笨重。于是 HTTP/3.0 诞生了它直接抛弃了 TCP改用基于 UDP 的QUIC协议。实际开发场景如果说 HTTP/2.0 是高速公路HTTP/3.0 就是无人机。它最大的优势是连接建立极快0-RTT并且在移动网络下表现极佳。比如你在地铁上用手机看网页从 4G 切换到 Wi-Fi以前的协议可能因为 IP 变了要重新连接但 HTTP/3.0 根本不在乎它能无缝衔接视频都不会卡顿。补充说明HTTP/3.0 的核心优势0-RTT 连接建立QUIC 在首次连接后缓存密钥再次连接时无需握手即可直接发送数据延迟极低。彻底解决队头阻塞QUIC 在 UDP 之上实现了类似 TCP 的可靠传输但以流为单位独立传输——一个流的丢包不会阻塞其他流。连接迁移QUIC 使用 Connection ID 而非 IP 端口来标识连接即使网络切换Wi-Fi → 4G连接也能无缝迁移不会断开。内置加密QUIC 默认集成了 TLS 1.3所有数据都加密传输不像 TCP 需要额外叠加 TLS。版本发布时间底层协议核心特性主要痛点HTTP/1.01996TCP短连接一问一答每次请求都要重新建立连接性能极差HTTP/1.11997TCP持久连接、管道化、缓存协商队头阻塞并发请求有限HTTP/2.02015TCP多路复用、二进制分帧、头部压缩TCP 层队头阻塞仍然存在HTTP/3.02022UDPQUIC0-RTT、连接迁移、彻底解决队头阻塞部署成本较高部分网络环境兼容性有限十二、什么是多路复用核心原理HTTP/2.0 的多路复用直接把这单车道升级成了多车道的高速公路。它是怎么做到的呢它引入了两个关键概念二进制分帧Binary Framing它不再用以前那种纯文本格式发数据了而是把你要请求的数据HTML、CSS、JS全部切成一个个非常小的、二进制的数据块叫做帧Frame。流Stream每一个请求和响应都被分配了一个独立的流StreamID。通俗场景假设你要下载 1 个 JS 文件、1 个 CSS 文件和 5 张图片。在 HTTP/2.0 下这些数据被切成了无数个小帧。虽然它们都在同一条 TCP 连接同一条高速公路上跑但每个帧都带着自己的身份证号Stream ID。服务器发数据时JS 的帧、CSS 的帧、图片的帧可以交错着、并行地发过来。浏览器收到后再根据身份证号把它们拼装回原来的文件。结果哪怕 JS 文件的传输卡住了CSS 和图片的帧依然可以从旁边超车过去完美解决了 HTTP/1.1 的队头阻塞一张图理解多路复用 vs 传统请求对比维度HTTP/1.1单车道HTTP/2.0 多路复用多车道连接数同一域名通常建立 6~8 个 TCP 连接浏览器限制只需1 个TCP 连接请求方式串行排队前面的请求卡住后面的全等并行交错互不阻塞数据格式纯文本明文 HTTP 报文二进制帧体积更小解析更快资源加载文件一个一个来瀑布流明显所有文件同时加载谁先到先拼装头部开销每次请求都带完整头部重复浪费HPACK 压缩头部体积大幅减少补充理解为什么多路复用能提升性能减少 TCP 连接数HTTP/1.1 时代浏览器为了解决队头阻塞只能同时开多个 TCP 连接比如 Chrome 最多对同一域名开 6 个。但这会消耗大量资源而且多个连接之间存在竞争。HTTP/2 只用一条连接省去了连接管理的开销。避免连接风暴多个 TCP 连接同时传输时会互相抢占带宽反而导致整体效率下降。单连接多路复用能够更合理地分配带宽。更快的首屏加载所有资源并行传输关键渲染路径上的 CSS 和 JS 可以更快地到达浏览器加速页面渲染。