什么是HTTP？HTTP和HTTPS的区别
- HTTP
HTTP是超文本运输协议，是一种无状态（每次请求都是独立的）的应用层协议。- 用于在客户端和服务器之间传输超文本数据（如HTML文件）。
- 默认端口是
80 - 数据以明文形式传输，没有加密功能，安全性差，但性能好。
- HTTPS
HTTPS是HTTP+安全层(TLS/SSL)，是一种加密的超文本传输协议。- 数据在传输过程中经过加密，防止被窃听、篡改或伪造。
- 默认端口是
443 - 需要依赖证书（
SSL/TLS证书）来建立安全连接。性能相比HTTP要差一些。
HTTP请求头中有哪些常见的信息？
Cache-Control：缓存控制（no-cache、max-age等）。Connection：控制是否保持连接（keep-alive、close）。Host：指定请求的目标主机和端口（必须字段）。User-Agent：客户端信息（如浏览器名称、版本、操作系统等）。Accept：客户端可接收的媒体类型（如text/html、application/json）。Authorization：客户端提供的身份认证凭证。Cookie：客户端发送的Cookie数据，用于会话管理。Referer：指定请求的来源页面URL。Origin：知名跨域请求的来源，用于CORS（跨域资源共享）。Content-Type：请求体的MIME类型（application/json、application/x-www-form-urlencoded、multipart/form-data）。
HTTPS 如何保证安全性？
- 对称加密：采用协商的密钥对数据加密。
- 对称加密指的是加密和解密使用的密钥都是同一个，是对称的。
- 非对称加密：实现身份认证和密钥协商。
- 非对称加密分为公钥和私钥，公钥 是公开 可以获取的，而私钥 是只有服务器有。
HTTPS通过非对称加密来交换用于对称加密的密钥，然后通过对称密钥来加密通信。- 在加密对称密钥的过程中，公钥 用来加密对称密钥（客户端），而私钥用来解密（服务端）。
- 而在验证数字签名/证书时，私钥用来生成数字证书（服务端），而公钥用来验证数字证书（客户端）。
- 摘要算法：验证信息的完整性。
- 数字签名：身份验证。
- 证书颁发机构(CA)：CA使用自己的私钥对服务器提交的证书进行签名，CA的公钥会内置在浏览器中。
HTTPS工作流程：- 客户端发起请求，发送支持的
TLS和加密算法版本等信息。 - 客户端回应请求，发送确定的
TLS和加密算法版本，还有服务器的数字证书。 - 客户端通过CA的公钥，验证服务器的数字证书 ，并获取到服务器的公钥。
- 客户端通过服务器的公钥 加密对称密钥并发送给服务器。
- 服务器通过私钥解密，获取对称密钥，然后使用对称密钥进行加密通信。
- 客户端发起请求，发送支持的
UDP和TCP的区别，以及各自的应用场景?
一、UDP
UDP，用户数据报协议，是一种简单的传输层协议，提供了无连接 、不可靠的数据传输服务。- 无连接意味着数据传输前，发送方和接收放不需要建立专门的连接。
UDP只是简单地将数据封装成UDP数据报，然后通过网络层发送出去。
二、TCP
TCP，传输控制协议，是一种面向连接的 、可靠的传输层协议。- 面向连接：三次握手建立连接。
TCP通过序列号、确认应答、重传机制、拥塞控制等一系列复杂的机制来确保数据的可靠传输。
三、TCP和UDP的对比
- 连接方式：
UDP无连接，TCP面向连接，三次握手。 - 可靠性：
UDP是不可靠传输协议，不保证数据一定到达目的地，也不保证数据的顺序和完整性。而TCP是可靠传输。通过序列号、确认应答和重传机制等确保数据准确无误地传输，并能保证数据的顺序。 - 传输效率：
UDP比TCP高。 - 数据量和应用场景：
UDP通常用于数据量较小，实时性要求高的应用。比如：DNS（域名解析）、DHCP（动态主机配置）、VoIP（语音通信）、视频直播、在线游戏。TCP则适用于数据量大、对数据准确性要求高的应用。比如：HTTP/HTTPS（网页浏览）、FTP（文件传输）、SMTP（邮件传输）、SSH（远程登录）。
- 数据流方式：
TCP面向字节流，而UDP面向数据报。 - 头部开销：
TCP头部最少20字节，UDP头部固定为8字节。
OSI 七层模型
- 应用层：提供应用程序接口。
DNS、HTTP、SMTP等 - 表示层：负责数据的格式转换和加密解密。
- 会话层：建立、管理和终止会话。
- 传输层：负责端到端传输。
TCP和UDP - 网络层：负责路由和寻址。
IP层 - 数据链路层：数据帧传输。
- 物理层：比特流传输。
TCP/IP 五/四层模型
- 五层模型
- 应用层
- 传输层
- 网络层
- 数据链路层
- 物理层
- 四层模型
- 应用层
- 单位：消息/报文。
- 功能：负责实现一切与应用程序相关的功能，属于用户态，对用
OSI的上三层。 - 代表协议：FTP（文件传输协议）、HTTP（超文本传输协议）、DNS（域名服务器协议）、SMTP（简单邮件传输协议）、NFS（网络文件系统协议）等。
- 传输层
- 单位：报文段。
- 功能：负责提供可靠的传输服务，为应用层提供网络支持，可用于不同应用间的传输。
- 代表协议：TCP（传输控制协议）、UDP（用户数据报协议）。
- 网络层
- 单位：数据包。
- 功能：负责网络间的寻址数据传输。
- 代表协议：IP（网际协议）、ICMP（网际控制消息协议）、ARP（地址解析协议）、RARP（反向地址解析协议）。
- 网络接口层（即将5层模型的数据链路层和物理层合并为了网络接口层）
- 单位：帧。
- 功能：负责时间数据的传输。
- 代表协议：HDLC（高级链路控制协议）、PPP（点对点协议）、SLIP（串行线路接口协议）。
- 应用层
DNS协议是什么？完整的DNS查询是怎么样的？
- DNS（Domain Name System）协议 是用于将域名解析为IP地址的协议，它运行在 应用层
- DNS查询类型：
- 递归查询：一查到底，直到获取解析结果。
- 迭代查询：DNS服务器只会返回下一步查询的地址，不会主动查。
- DNS查询完整流程：
- 依次查询以下的缓存，如果命中，则返回结果。
- 浏览器缓存
- 操作系统缓存（本地缓存）
- 本地域名服务器缓存
- 如果以上的缓存全部没有命中，那么将会依次访问如下服务器，进行查询
- 根域名服务器
- 顶级域名服务器
- 权威域名服务器
- 返回结果并在各级缓存中进行缓存
- 依次查询以下的缓存，如果命中，则返回结果。
什么是CDN，实现原理是什么？
CDN，内容分发网络，是一种通过分布式部署的服务器将内容快速的传输给用户的网络架构。CDN的主要目的是为了加速内容分发，提高用户访问速度，减少服务器压力，增强网络的稳定性和可靠性。- 简略实现原理：不同位置部署很多缓存服务器，用户访问时，就近获取可用资源，而不是直接从源服务器获取。
- 详细实现原理：
- 分布式缓存部署：大范围部署边缘节点服务器，就近访问缓存内容。
- DNS解析与就近原则：DNS重定向到CDN网络，调度到最优边缘服务器。
- 内容分发与缓存：
- 主动缓存：CDN主要从源服务器拉取内容，预先存储到边缘节点。
- 被动缓存：用户首次访问此资源时进行缓存，并遵循一定的过期策略。
- 负载均衡与调度：在某边缘节点繁忙或不可用时，自动调度到其他可用节点。
HTTP 1.0/1.1/2.0/3.0 的区别
一、HTTP/1.0
HTTP/1.0是早期版本，每次请求都需要建立一个新的TCP连接。
二、HTTP/1.1
HTTP/1.1是目前广泛使用的版本。- 相比1.0，主要优化有
- 持久连接：无需为每个请求重新建立连接。
Connection:keep-alive - 管道化：在同一个TCP连接中，客户端可以并行发送多个请求，无需等待前一个请求响应。但可能会队头阻塞。
- 分块传输编码：服务器可以将响应数据分块传输，适用于动态生成的内容，
Transfer-Encoding:chunked - 缓存机制：
Cache-Control、ETag、If-Modified-Since Host头：HTTP/1.1要求每个请求必须包含Host字段，用于支持虚拟主机。- 支持断点续传：使用
Range头部实现，允许客户端只请求部分资源。
- 持久连接：无需为每个请求重新建立连接。
三、HTTP/2.0
HTTP/2.0主要解决了HTTP/1.1的性能瓶颈，通过引入二进制分帧 和多路复用等机制，显著提升传输性能。- 二进制分帧 ：
HTTP/2.0将数据分为二进制帧进行传输，而非文本格式。更高效且易于解析。 - 多路复用 ：在同一TCP连接中，可互不影响地并行发送多个请求和响应，解决了队头阻塞的问题。
- 头部压缩：减少了数据传输体积。
- 服务器推送：服务可以在客户端请求某资源时，主动将相关资源（如CSS和JS文件）推送给客户端，减少延迟。
- 流优先级：支持对不同流设置优先级，优化资源分配，提升用户体验。
四、HTTP/3
- 最新的HTTP版本，基于
QUIC协议，使用UDP。 - 减少了握手延迟。
- 无队头阻塞问题，因为
QUIC在UDP上实现了流的独立传输。 - 更快的重传机制，适用于移动网络等不稳定环境。
HTTP常见状态码，相应的适用场景是什么？
1XX（信息类）
100 Continue：表示可以继续发送，用于上传大文件前先验证请求头。101 Switching Protocols：服务器同意切换协议。
2XX（成功类）
200 OK：请求成功，常见于GET和POST请求的正常返回。201 Created：资源已成功创建，通常用于POST请求。202 Accepted：请求已接收，但尚未处理，通常用于异步任务。204 No Content：请求成功，但无返回内容。比如删除资源时。
3XX（重定向类）
301 Moved Permanently：资源永久移动到新位置。比如旧网址重定向到新网址。302 Found：资源暂时移动到其他位置。比如重定向到登录页面。304 Not Modified：资源未修改，可使用缓存版本。
4XX（客户端错误类）
400 Bad Request：请求无效或参数错误。401 Unauthorized：未授权，需要身份验证。403 Forbiden：服务器拒绝执行请求。比如一些越权操作。404 Not Found：资源不存在或路径错误。405 Method Not Allowed：请求方法不被允许。429 Too Many Requests：客户端请求过多，被限制访问。
5XX（服务器错误类）
500 Internal Server Error：服务器内部出现未预期的错误。比如数据库连接失败或代码逻辑错误。502 Bad Gateway：网关或代理服务器从上游服务器接收到无效响应。比如反向代理连接到服务不可用的后端。503 Service Unavailable：服务器因超载或维护暂时无法处理请求。504 Gateway Timeout：网关或代理服务器等待上游服务器超时。
HTTP中GET和POST的区别
- 用途
GET方法用于请求数据，通常用于获取资源或内容。POST方法用于发送数据，通常用于创建资源或提交表单。
- 数据传输方式：
GET：参数通过URL查询字符串传递，数据量受URL长度限制，数据以明文形式暴露在URL中。POST：参数通过HTTP请求体传递，数据量较大，受限于服务器和客户端配置。
- 安全性
GET参数暴露在URL中，可能被浏览器记录、缓存，或在访问历史中暴露。不适合传递敏感信息。POST参数在请求体中传输，适合传输敏感信息，但仍需依赖HTTPS来加密传输数据。
- 幂等性：
GET是幂等的。POST不是幂等的。
浏览器地址栏输入URL敲下回车后发生了什么？
- URL解析，将URL拆分
- 协议：如
http或https - 主机名（域名/ip）
- 端口：浏览器使用
URL指定端口，若无指定，则http默认80，https默认443。 - 路径
- 查询字符串
- 片段标识符
- 协议：如
- DNS解析：将域名解析为
ip地址 - 建立
TCP连接 - 发送
HTTP请求 - 服务器处理请求
- 服务器返回响应
- 浏览器解析并渲染页面
- 解析
HTML，构建DOM树。 - 解析
CSS，生成CSS规则树。 - 合成
DOM树和CSS规则树，生成Render树。 - 绘制
Render树，绘制页面像素信息。 - 浏览器将各层信息发给GPU,GPU将各层合成，显示在屏幕上。
- 解析
- 加载额外资源（JS、CSS、图片等）
- 执行JavaScript
TCP为什么需要三次握手和四次挥手
- 三次握手：三次握手用于建立 TCP 连接，主要作用是确认双方的接收 能力和发送 能力是否正常、指定自己的初始化序列号为后面的可靠性传输做准备。
- 客户端发送SYN（同步）包，该数据包中 SYN = 1，并且客户端会随机选择一个序列号 Seq = x。
SYN, Seq = x - 服务器回应SYN-ACK包：
SYN, Ack = x + 1, Seq = y - 客户端确认ACK包：
Ack = y + 1, Seq = x + 1
- 客户端发送SYN（同步）包，该数据包中 SYN = 1，并且客户端会随机选择一个序列号 Seq = x。
- 四次挥手：四次挥手用于断开 TCP 连接。由于 TCP 是全双工的（即通信双方都可以独立发送和接收数据），因此关闭连接时需要双方独立关闭发送和接收通道。
- 主动关闭方发送FIN标志的数据包，表示无数据需要发送，但仍可接收数据。
FIN, Seq = u - 被动关闭方回应ACK包，确认客户端的关闭请求，但自己可能仍然有数据要发送。。
Ack = u + 1, Seq = v - 被动关闭方发送FIN包，表示服务器也不再发送数据。
FIN, Seq = v + 1 - 主动关闭方回应ACK包，确认服务器的关闭请求，连接正式关闭。
Ack = v + 2
- 主动关闭方发送FIN标志的数据包，表示无数据需要发送，但仍可接收数据。
- 为什么需要三次握手？而不是两次？
- 三次握手是为了确保双方能够同步序列号，并确认双方都准备好开始数据传输。
- 第一次握手时，确认了客户端的发送能力，
- 第二次握手时，确认了服务端的接收能力和发送能力。
- 第三次握手时，确认了客户端的接收能力。
- 为什么需要四次挥手，而不是三次？
- 四次挥手是为了保证双方都能独立关闭发送和接收通道，避免丢失数据，并确保连接完全关闭。
- 第一次挥手，意味着客户端没有数据需要发送了，但如果服务端还有数据，它是可以接收的。
- 第二次挥手，只是回复客户端，意味着服务器收到消息了，后面可以继续发送文件或决定不再发送。
- 第三次挥手，服务端确定自己也要关闭发送了。
- 第四次挥手，客户端收到了服务端关闭请求，等待2*MSL，以防一些延迟的请求或消息接收不到，然后应答服务端的请求。
WebSocket是什么？有什么应用场景？
WebSocket，是一种网络传输协议。位于应用层。可以在单个TCP连接上进行全双工通信，能更好的节省服务器资源并达到实时通讯 。客户端和服务器只需要完成一次握手 ，二者就可以创建持久性的连接，并进行双向数据传输。- 优点：
- 低延迟
- 全双工通信
- 节省带宽
- 实时性强
- 应用场景：
- 实时聊天应用
- 在线游戏
- 金融交易平台
- 协作编辑工具
- 实时监控
- 直播
WebSocket与HTTP和UDPWebSocket：适合实时、双向通信的场景（如聊天应用、实时推送通知）。相比 HTTP 更高效，但相比 UDP 性能稍逊。HTTP：适合请求-响应模型，内容加载较简单的应用，但不适合实时通信。UDP：适合低延迟、大规模实时数据传输的场景（如视频直播、在线游戏），但缺乏可靠性和顺序保证。