1.一条url输入到浏览器最后显示页面的过程
- URL解析与处理
浏览器解析URL（如https://www.example.com/page）
分离协议（https）、域名（www.example.com）和资源路径（/page）
检查HSTS预加载列表强制使用HTTPS
处理特殊字符（如空格转义为%20）
- DNS域名解析
浏览器检查本地缓存（浏览器缓存→系统缓存→路由器缓存）
未命中则向配置的DNS服务器发起递归查询
DNS服务器通过层级解析（根域名→顶级域→权威DNS）获取IP地址
结果缓存到本地（TTL决定有效期）
- 建立TCP连接
通过操作系统网络栈向目标IP的80/443端口发起请求
三次握手建立TCP连接：
text
客户端 → SYN → 服务端
客户端 ← SYN-ACK ← 服务端
客户端 → ACK → 服务端
启用TLS时额外进行SSL/TLS握手（协商加密套件、证书验证、密钥交换）
- 发送HTTP请求
组装HTTP请求报文：
text
GET /page HTTP/1.1
Host: www.example.com
User-Agent: Chrome/…
Accept: text/html,application/xhtml+xml
Cookie: sessionid=…
包含请求行、请求头、空行和可选的请求体
启用HTTPS时数据通过TLS记录协议加密传输
- 服务器处理请求
反向代理（如Nginx）接收请求，根据配置路由到应用服务器
应用服务器（如Node.js/Django）执行业务逻辑：
读取数据库（MySQL/MongoDB）
调用微服务（gRPC/REST）
渲染模板（Jinja2/JSX）
生成响应：状态码+响应头+响应体
接收HTTP响应
- 浏览器接收响应流：
text
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600
根据状态码处理（301重定向/200成功/404错误等）
解压gzip/brotli压缩内容
- 关键渲染路径（浏览器引擎工作）
DOM构建：边下载边解析HTML，生成DOM树（遇到
CSSOM构建：解析CSS规则，计算层叠样式
渲染树：合并DOM+CSSOM，排除不可见元素
布局：计算元素几何位置（Reflow）
绘制：填充像素到图层（Paint）
合成：GPU加速合成最终界面
2.DNS域名系统，简述描述其原理
DNS（Domain Name System）是一种分布式层级数据库系统，其核心功能是将人类可读的域名（如 www.example.com）转换为机器可识别的IP地址（如 192.0.2.1）。其工作原理基于分层查询和分布式存储：
- 域名空间结构：
采用树状层级结构：根域（.）→ 顶级域（.com, .org）→ 二级域（example）→ 子域名（www）
每级由不同权威服务器管理，实现责任分散
- 解析流程：
本地查询：浏览器首先检查本地缓存 → 操作系统缓存 → 路由器缓存
递归查询：本地DNS服务器（ISP提供）作为代理发起全流程解析：
查询根域名服务器（全球13组）获取顶级域服务器地址
查询顶级域（.com）服务器获取二级域授权服务器
查询二级域（example.com）权威服务器获取具体主机IP
迭代响应：每级服务器仅返回下一级线索，不直接提供最终答案
- 记录类型：
A记录：存储IPv4地址
AAAA记录：存储IPv6地址
CNAME：域名别名（如将 www 指向主域名）
MX记录：邮件服务器地址
NS记录：指定域名的权威服务器
- 缓存机制：
各级DNS服务器根据TTL（Time to Live）缓存查询结果
显著减少根服务器负载（全球日均万亿次查询）
缓存过期后自动重新查询
- 协议特性：
默认使用UDP端口53（快速查询）
大响应时切换TCP
支持DNSSEC提供数据完整性验证
3.七层网络模型是什么、TCP/IP四层网络模型是什么
- 七层OSI模型（理论参考框架）：
物理层：通过物理介质传输比特流（如网线电压/光纤信号）
数据链路层：MAC寻址、帧同步、差错控制（交换机工作层）
网络层：IP寻址、路由选择、分组转发（路由器工作层）
传输层：端到端连接管理（TCP可靠传输/UDP快速传输）
会话层：建立/维护/终止会话（如RPC调用）
表示层：数据格式转换、加密/解密（如SSL/TLS）
应用层：用户接口和网络服务（HTTP/FTP/SMTP协议）
- 四层TCP/IP模型（实际应用标准）：
网络接口层：对应OSI物理层+数据链路层，处理硬件连接和帧封装
网际层：对应OSI网络层，核心IP协议实现跨网络寻址
传输层：与OSI传输层完全对应，提供TCP/UDP端到端控制
应用层：合并OSI会话层+表示层+应用层，直接承载HTTP/DNS等协议
4. TCP和UDP有什么区别
- TCP（传输控制协议）：
连接导向：通信前需三次握手建立可靠连接（SYN→SYN-ACK→ACK）
可靠传输：
数据包排序（序列号机制）
丢失重传（ACK确认+超时重发）
完整性校验（校验和）
流量控制：滑动窗口动态调整发送速率（避免接收方溢出）
拥塞控制：慢启动→拥塞避免→快速恢复（保障网络稳定性）
头部开销大：20-60字节（含序列号/确认号/控制标志等）
典型应用：网页（HTTP）、邮件（SMTP）、文件传输（FTP）
- UDP（用户数据报协议）：
无连接：直接发送数据包，无握手过程
不可靠传输：
不保证数据包顺序
无重传机制（可能丢失）
仅基础校验（校验和可选）
无流控与拥塞控制：持续以恒定速率发送
头部开销小：固定8字节（仅源/目标端口+长度+校验和）
支持广播/多播：可同时向多个主机发送数据
典型应用：视频流（RTP）、DNS查询、在线游戏、IoT传感器数据
本质区别：TCP是"电话通话"（有序可靠但延迟敏感），UDP是"寄明信片"（快速投递但不保证送达）。现代技术如QUIC协议（HTTP/3）正融合两者优势，在UDP上实现TCP级可靠性。
5.TCP的三次握手四次挥手的过程，为什么不能是两次握手，为什么不是三次挥手
- 三次握手建立连接（确保双向通信可靠）：
客户端→服务端：发送SYN包（同步序列号，如SEQ=100）
服务端→客户端：响应SYN-ACK包（确认SEQ=101，自带SEQ=300）
客户端→服务端：发送ACK包（确认SEQ=301）
至此连接建立，双方就初始序列号达成共识。
为何不能两次握手：
若仅两次握手，服务端无法确认客户端是否收到自己的SYN-ACK响应。网络延迟可能导致旧的SYN包突然到达，服务端误建连接（资源浪费），而客户端因未发送ACK会拒绝此连接，导致服务端长期等待（资源耗尽）。三次握手通过最后确认彻底排除历史包干扰。四次挥手终止连接（安全关闭双工通道）：
主动方→被动方：发送FIN包（请求终止发送）
被动方→主动方：立即响应ACK包（确认收到终止请求）
此时被动方可能仍有数据待发送（半关闭状态）
被动方→主动方：数据发送完毕后发送FIN包
主动方→被动方：响应最终ACK包（连接完全关闭）
- 为何不是三次挥手：
被动方收到FIN后需先发ACK（快速响应），再继续处理剩余数据（如未传完的文件），之后才发FIN。若合并为三次（ACK+FIN一起发送），会强制被动方立即终止所有操作，可能导致：
数据丢失（未传输完成即关闭）
资源冲突（FIN过早发送但数据仍在传输中）
四次挥手通过分离ACK和FIN，实现连接的安全有序关闭。
关键设计哲学：TCP通过三次握手防止"僵尸连接"，四次挥手适应"双工通道独立关闭"。这种设计在保证可靠性的同时，完美平衡了效率与资源安全，成为互联网通信的基石。
6.TIME_WAIT 和CLOSE_WAIT 是什么
- CLOSE_WAIT 状态
触发位置：被动关闭方（接收 FIN 包的服务端）
产生场景：
主动关闭方（客户端）发送 FIN 请求断开连接
被动关闭方回复 ACK 确认后进入 CLOSE_WAIT 状态
核心意义：
等待被动关闭方的应用程序处理剩余数据（如未发送完的响应）
风险警示：
大量 CLOSE_WAIT 表明应用程序未正确关闭连接（如未调用 close()）
→ 导致连接泄漏（可通过 netstat 监测）
- TIME_WAIT 状态
触发位置：主动关闭方（发起 FIN 的客户端）
产生场景：
主动关闭方发送最终 ACK 后进入 TIME_WAIT
持续 2MSL（Max Segment Lifetime，通常 60-120 秒）
双重使命：
确保最后 ACK 送达：若被动方未收到 ACK 会重发 FIN，主动方可响应
清除残余报文：等待网络中旧连接数据包消亡，避免污染新连接
设计必要性：
防止历史数据包被相同四元组（源IP+端口，目标IP+端口）的新连接错误接收
7. HTTP是什么，与HTTPS有什么区别
- HTTP（超文本传输协议）：
互联网应用层协议，基于TCP端口80通信
明文传输：请求/响应内容未加密，易被窃听（如密码泄露）
无身份验证：无法验证服务器真实性，存在中间人攻击风险
数据完整性缺失：传输内容可能被篡改（如插入广告代码）
- HTTPS（HTTP Secure）：
HTTP的安全升级版，本质是HTTP over TLS/SSL
加密传输：通过TLS握手建立安全通道（非对称加密交换密钥 + 对称加密传输数据）
身份认证：CA机构颁发数字证书验证服务器身份（防钓鱼网站）
数据完整性保护：HMAC算法防止内容篡改
默认使用TCP端口443，需服务器配置有效证书
本质差异：HTTPS = HTTP + TLS加密层，如同为普通信件（HTTP）添加防弹装甲和指纹锁（TLS）。现代浏览器已标记HTTP站点为"不安全"，HTTPS成为Web安全基石。
8. GET和POST请求有哪些区别
- GET 请求：
数据位置：参数附加在 URL 后（?key1=value1&key2=value2），暴露在地址栏
设计用途：获取数据（如加载网页、查询信息），不应修改服务器状态
特性限制：
URL 长度受限（通常 ≤ 2048 字符，浏览器差异）
数据仅支持 ASCII 字符
可被缓存/书签保存/历史记录保留
安全性与幂等性：
明文传输（无加密）
天然幂等（多次请求结果相同）
- POST 请求：
数据位置：参数封装在请求体（Request Body）中，地址栏不可见
设计用途：提交数据（如登录表单、文件上传），可修改服务器状态
特性优势：
支持大数据传输（理论无上限，实际受服务器配置限制）
支持二进制数据（如图片/文件）
不可缓存/书签保存
安全性与幂等性：
仍依赖 HTTPS 实现加密（Body 本身不加密）
非幂等（重复提交可能产生副作用，如多次下单）
9.HTTP长连接与短链接区别
- 短连接（Short-Lived Connections）：
工作模式：每次HTTP请求均需独立建立TCP连接（三次握手），请求响应后立即断开（四次挥手）
性能开销：
高延迟（每次请求重复握手/挥手）
高资源消耗（频繁开关连接占用CPU/内存）
适用场景：
低频请求（如传统网页浏览）
兼容老旧服务器（HTTP/1.0默认）
- 长连接（Persistent Connections / HTTP Keep-Alive）：
工作模式：单次TCP连接处理多个HTTP请求/响应，通过Connection: keep-alive头部启用
性能优势：
减少60%以上延迟（避免重复握手）
降低服务器负载（连接复用减少50%+ TCP开销）
管理机制：
超时关闭（服务器设置Keep-Alive: timeout=60）
最大请求数限制（max=100）
协议支持：
HTTP/1.1 默认启用
HTTP/2 基于长连接实现多路复用（Multiplexing）
短连接如 “一次性电话”（每次沟通需重新拨号）
长连接如 “持续通话”（保持线路处理多次对话）
长连接通过复用TCP通道，显著提升网络效率，成为现代互联网基础设施的核心优化手段。
10.Websocket是什么
WebSocket 是一种基于 TCP 的全双工通信协议（标准端口 80/443），在单个持久连接上实现客户端与服务器的实时双向数据流。其通过 HTTP 协议升级握手建立连接（Upgrade: websocket），之后脱离 HTTP 范式独立传输数据。
诞生背景：
解决传统 HTTP 的痛点：
轮询低效：客户端需反复请求获取新数据（高延迟）
单向通信：服务器无法主动推送数据（如聊天消息）
11.全双工与半双工有什么区别
- 全双工（Full Duplex）：
核心能力：通信双方可同时双向传输数据（发送与接收并行）
技术实现：
物理层：使用两对独立线路（如网线的发送/接收线对）
协议层：通过频率分割（FDD）或时间插空（如TDD-LTE）实现并发
类比模型：电话通话——双方能同时说话且听到对方声音
典型应用：
现代电话网络（4G/5G VoLTE）
WebSocket实时通信
以太网（千兆以上）
- 半双工（Half Duplex）：
核心限制：通信双方交替传输数据（发送时不能接收，反之亦然）
技术特征：
共享单通道（如Wi-Fi同一频段）
依赖冲突检测（CSMA/CD）或请求响应（RTS/CTS）机制
类比模型：对讲机对话——按PTT键说话时无法收听，需释放按键接收
典型场景：
传统对讲机系统
早期以太网（10BASE2）
工业总线（CAN协议）
12.什么是跨域问题，有哪些解决办法
跨域问题本质：
浏览器同源策略（Same-Origin Policy）的安全限制，阻止网页向协议/域名/端口任一不同的目标发起请求。例如：
http://a.com → https://a.com（协议不同）❌
http://a.com → http://api.a.com（域名不同）❌
http://a.com:80 → http://a.com:8080（端口不同）❌
- CORS（跨域资源共享） - 主流方案
服务端设置响应头：
http
Access-Control-Allow-Origin: * // 允许所有域
Access-Control-Allow-Methods: GET, POST // 允许的HTTP方法
Access-Control-Allow-Headers: Content-Type // 允许的请求头
预检请求：复杂请求前自动发OPTIONS探路
- 反向代理 - 前端工程化首选
开发环境：Webpack/Vite配置proxy将/api代理到目标服务器
生产环境：Nginx配置路由转发
nginx
location /api {
proxy_pass http://target-server.com;
}
13.QUIC协议是什么
QUIC（Quick UDP Internet Connections）是由Google主导设计的基于UDP的现代化传输协议，旨在解决TCP的固有缺陷，现已成为HTTP/3的底层标准（RFC 9000）。
关键技术创新
- 0-RTT建连：
通过缓存会话密钥，首次连接需1-RTT，重连实现零握手延迟（比TCP+TLS快3倍）
- 彻底消除队头阻塞：
基于UDP实现真正多路复用，单连接内数据流独立传输（某流丢包不影响其他流）
- 无缝连接迁移：
使用连接ID而非IP+端口标识连接，切换网络（WiFi→5G）无断连
- 原生加密传输：
内置TLS 1.3（协议头部全部加密），防运营商篡改
- 智能拥塞控制：
改进BBR算法，动态适应网络波动（尤其提升高丢包环境性能）
14.什么是多路复用
多路复用（Multiplexing） 是一种在单条物理连接上并发传输多个独立数据流的技术，通过共享信道资源大幅提升传输效率。其本质是解决"如何让多个通信流共享同一通道"的问题，避免为每个数据流建立独立连接的开销。
关键实现方式
- HTTP/2 中的多路复用
突破HTTP/1.1队头阻塞：将请求/响应拆分为二进制帧（Frame）
帧标识机制：每个帧携带唯一Stream ID，接收方可并行重组
效果：单TCP连接同时处理数十个请求（如图片/CSS/JS并行加载）
- QUIC协议的多路复用
基于UDP实现真并行：数据流完全独立（某流丢包不影响其他流）
0-RTT连接复用：加密会话缓存实现瞬时重连
- 硬件层多路复用
频分复用（FDM）：不同频率载波传输多路信号（如有线电视）
时分复用（TDM）：时间片轮转分配信道（传统电话网络）