tcp 与 udp 的异同
TCP(Transmission Control Protocol)和 UDP(User Datagram Protocol)是两种常见的传输层协议,它们在数据传输方式和应用场景上有显著差异。
TCP 的特点:
- 面向连接:在传输数据前需要建立连接(三次握手)。
- 可靠传输:提供确认机制、重传机制和流量控制,确保数据可靠传输。
- 有序传输:保证数据按顺序到达,避免乱序。
- 数据完整性:通过校验和机制确保数据完整性。
- 适用场景:适用于需要可靠传输的应用,如网页浏览、文件传输和电子邮件。
UDP 的特点:
- 无连接:无需建立连接,直接发送数据。
- 不可靠传输:不提供确认机制和重传机制,数据可能丢失或重复。
- 无序传输:不保证数据按顺序到达。
- 低开销:头部开销小,传输效率高。
- 适用场景:适用于对实时性要求高但对可靠性要求低的应用,如视频直播、在线游戏和 DNS 查询。
总结:
- TCP 提供可靠、有序的数据传输,适用于需要高可靠性的应用。
- UDP 提供快速、低开销的数据传输,适用于对实时性要求高的应用。
通过了解 TCP 和 UDP 的特点和适用场景,可以根据具体需求选择合适的传输协议。
TCP 的三次握手和四次挥手
三次握手:
TCP 连接的建立过程称为“三次握手”,其步骤如下:
- 第一次握手:客户端向服务器发送一个 SYN(同步序列编号)包,请求建立连接。此时,客户端进入 SYN_SENT 状态。
- 第二次握手:服务器收到 SYN 包后,向客户端发送一个 SYN-ACK(同步序列编号和确认序列编号)包,表示同意建立连接。此时,服务器进入 SYN_RECEIVED 状态。
- 第三次握手:客户端收到 SYN-ACK 包后,向服务器发送一个 ACK(确认序列编号)包,确认连接建立。此时,客户端和服务器都进入 ESTABLISHED 状态,连接正式建立。
通过三次握手,TCP 确保了双方的发送和接收能力,建立了可靠的连接通道。
四次挥手:
TCP 连接的断开过程称为“四次挥手”,其步骤如下:
- 第一次挥手:客户端向服务器发送一个 FIN(终止连接)包,表示不再发送数据。此时,客户端进入 FIN_WAIT_1 状态。
- 第二次挥手:服务器收到 FIN 包后,向客户端发送一个 ACK(确认序列编号)包,确认收到终止连接请求。此时,服务器进入 CLOSE_WAIT 状态,客户端进入 FIN_WAIT_2 状态。
- 第三次挥手:服务器向客户端发送一个 FIN 包,表示不再发送数据。此时,服务器进入 LAST_ACK 状态。
- 第四次挥手:客户端收到 FIN 包后,向服务器发送一个 ACK 包,确认连接断开。此时,客户端进入 TIME_WAIT 状态,等待一段时间后进入 CLOSED 状态,服务器进入 CLOSED 状态。
通过四次挥手,TCP 确保了双方都能正常关闭连接,释放资源。
浏览器从输入 URL 到页面展示的整个过程,越细致越好
- DNS 解析:
- 用户在浏览器地址栏输入 URL。
- 浏览器检查本地缓存是否有对应的 IP 地址。
- 如果没有,向本地 DNS 服务器发送查询请求。
- 本地 DNS 服务器查询根 DNS 服务器、顶级域名服务器(TLD DNS)和权威 DNS 服务器,获取目标 IP 地址。
- 将 IP 地址返回给浏览器。
- 建立 TCP 连接:
- 浏览器使用获取的 IP 地址和服务器建立 TCP 连接。
- 通过三次握手(SYN、SYN-ACK、ACK)建立可靠的连接。
- 发送 HTTP 请求:
- 浏览器构建 HTTP 请求报文,包括请求行、请求头和请求体。
- 通过 TCP 连接将请求报文发送到服务器。
- 服务器处理请求:
- 服务器接收请求报文,解析请求内容。
- 根据请求的资源路径和参数,处理请求并生成响应报文。
- 响应报文包括状态行、响应头和响应体(如 HTML、CSS、JavaScript、图片等)。
- 接收 HTTP 响应:
- 浏览器接收服务器返回的 HTTP 响应报文。
- 根据状态码判断请求是否成功(如 200 OK)。
- 解析 HTML:
- 浏览器解析 HTML 文档,构建 DOM 树。
- 解析过程中遇到外部资源(如 CSS、JavaScript、图片等)时,发送请求获取资源。
- 解析 CSS:
- 浏览器解析 CSS 文件,构建 CSSOM 树。
- 将 CSSOM 树与 DOM 树结合,生成渲染树。
- 执行 JavaScript:
- 浏览器解析并执行 JavaScript 代码。
- JavaScript 可能会修改 DOM 树和 CSSOM 树,触发重新渲染。
- 布局和绘制:
- 浏览器根据渲染树进行布局计算,确定每个元素的位置和大小。
- 将布局结果转换为绘制指令,绘制到屏幕上。
- 显示页面:
- 浏览器将绘制结果显示在屏幕上,用户看到完整的网页内容。
通过以上步骤,浏览器完成了从输入 URL 到页面展示的整个过程。每个步骤都可能涉及复杂的操作和优化,以提高页面加载速度和用户体验。
DNS 服务器是什么,如何查询 DNS 的?
DNS 服务器:
DNS(Domain Name System)服务器是用于将域名解析为 IP 地址的服务器。它充当互联网的电话簿,使用户能够通过域名访问网站,而不需要记住复杂的 IP 地址。DNS 服务器分为以下几种类型:
- 根 DNS 服务器:负责顶级域名(如 .com、.org)的解析。
- 顶级域名服务器(TLD DNS):管理特定顶级域名下的所有域名(如 .com 下的所有域名)。
- 权威 DNS 服务器:存储特定域名的实际 DNS 记录,提供最终的解析结果。
- 递归 DNS 服务器:为客户端提供域名解析服务,负责查询其他 DNS 服务器以获取解析结果。
如何查询 DNS:
- 使用命令行工具:
- nslookup:在命令行中输入
nslookup example.com,可以查询域名的 IP 地址。 - dig:在命令行中输入
dig example.com,可以获取详细的 DNS 解析信息。
- 使用在线工具:
- 访问在线 DNS 查询工具网站(如 MXToolbox、DNSstuff),输入域名进行查询。
- 浏览器开发者工具:
- 在浏览器中打开开发者工具,查看网络请求的 DNS 解析信息。
通过这些方法,可以方便地查询域名的 DNS 解析结果,了解域名对应的 IP 地址。
HTTP 常见状态码
HTTP 状态码用于表示客户端请求的响应状态。常见的状态码包括:
- 1xx 信息响应:
- 100 Continue:继续请求,客户端应继续其请求。
- 101 Switching Protocols:服务器根据客户端的请求切换协议。
- 2xx 成功响应:
- 200 OK:请求成功,服务器返回请求的数据。
- 201 Created:请求成功并且资源被创建。
- 204 No Content:请求成功但没有内容返回。
- 3xx 重定向:
- 301 Moved Permanently:资源已永久移动到新位置。
- 302 Found:资源临时移动到新位置。
- 304 Not Modified:资源未修改,客户端可以使用缓存。
- 4xx 客户端错误:
- 400 Bad Request:请求无效,服务器无法理解请求。
- 401 Unauthorized:请求需要用户认证。
- 403 Forbidden:服务器拒绝请求。
- 404 Not Found:请求的资源不存在。
- 5xx 服务器错误:
- 500 Internal Server Error:服务器内部错误。
- 502 Bad Gateway:网关或代理服务器错误。
- 503 Service Unavailable:服务器暂时无法处理请求。
这些状态码帮助客户端了解请求的处理结果,并采取相应的措施。
HTTP/1.x 和 HTTP/2.0 的区别?HTTP/2.0 优点,以及某些情况会比 1.x 速度更慢?
HTTP/1.x 和 HTTP/2.0 是两种不同版本的 HTTP 协议,它们在性能和功能上有显著差异。
HTTP/1.x 的特点:
- 单一连接:每个请求/响应对使用一个 TCP 连接,容易导致连接过多。
- 队头阻塞:一个请求被阻塞会影响后续请求的处理。
- 无状态:每个请求独立,服务器无法跟踪请求之间的关系。
- 明文传输:默认不加密,安全性较低。
HTTP/2.0 的特点:
- 多路复用:一个 TCP 连接上可以发送多个请求和响应,减少连接数。
- 二进制分帧:数据以二进制格式传输,提高解析效率。
- 头部压缩:使用 HPACK 算法压缩头部,减少数据传输量。
- 服务器推送:服务器可以主动向客户端推送资源,减少延迟。
- 优先级控制:客户端可以指定请求的优先级,优化资源加载顺序。
HTTP/2.0 的优点:
- 减少延迟:多路复用和服务器推送减少了请求的等待时间。
- 提高传输效率:二进制分帧和头部压缩减少了数据传输量。
- 更好的资源管理:优先级控制和流量控制优化了资源加载。
HTTP/2.0 在某些情况下比 HTTP/1.x 速度更慢的原因:
- 头部压缩开销:HPACK 压缩和解压缩头部信息需要额外的计算资源。
- 多路复用竞争:多个请求共享一个连接,可能导致带宽竞争和性能下降。
- 网络环境影响:在高延迟或不稳定的网络环境下,多路复用可能导致性能不如预期。
总体来说,HTTP/2.0 在大多数情况下都能显著提高网页加载速度和传输效率,但在某些特定场景下,可能会因为额外的开销和网络环境的影响而表现不如 HTTP/1.x。
HTTP/2.0 压缩头,以及并行请求原理
压缩头:
HTTP/2.0 使用 HPACK 算法对头部进行压缩,以减少数据传输量。HPACK 通过以下方式实现头部压缩:
- 静态表:预定义了一些常见的头字段及其值,客户端和服务器共享这张表。
- 动态表:在通信过程中动态维护的头字段表,客户端和服务器都可以更新。
- 哈夫曼编码:对头字段和头字段值进行哈夫曼编码,进一步减少数据量。
通过 HPACK 算法,HTTP/2.0 可以显著减少头部的传输开销,提高传输效率。
并行请求原理:
HTTP/2.0 引入了多路复用技术,允许在一个 TCP 连接上并行发送多个请求和响应。其工作原理如下:
- 流:每个请求和响应在一个独立的流中传输,流通过唯一的标识符区分。
- 帧:数据被分割成多个帧,每个帧属于一个特定的流。帧可以乱序发送,接收方根据帧头中的流标识符重新组装数据。
- 优先级:客户端可以为每个流分配优先级,服务器根据优先级优化资源分配和响应顺序。
通过多路复用,HTTP/2.0 可以在一个连接上同时处理多个请求和响应,减少连接建立的开销,避免队头阻塞,提高传输效率。
HTTP 缓存机制是什么样的
缓存机制是指在客户端和服务器之间存储和重用资源的过程,以减少延迟和带宽消耗。主要的缓存机制包括:
- 强缓存:
- Expires:HTTP 响应头,指定资源的过期时间,使用绝对时间。
- Cache-Control:HTTP/1.1 引入的响应头,使用相对时间,如
max-age指定资源的有效期。
- 协商缓存:
- Last-Modified 和 If-Modified-Since:服务器在响应头中返回资源的最后修改时间,客户端在后续请求中使用
If-Modified-Since询问服务器资源是否更新。 - ETag 和 If-None-Match:服务器在响应头中返回资源的唯一标识符(ETag),客户端在后续请求中使用
If-None-Match询问服务器资源是否更新。
缓存机制的工作流程如下:
- 强缓存:
- 客户端请求资源时,首先检查本地缓存是否存在且未过期。
- 如果缓存有效,直接使用缓存资源,不发送请求到服务器。
- 如果缓存过期,发送请求到服务器。
- 协商缓存:
- 客户端请求资源时,发送包含
If-Modified-Since或If-None-Match的请求头。 - 服务器检查资源是否更新,如果未更新,返回 304 Not Modified 状态码,客户端使用缓存资源。
- 如果资源已更新,服务器返回新的资源和相应的缓存头,客户端更新缓存。
通过合理使用缓存机制,可以显著提高网页加载速度,减少服务器负载和带宽消耗。
设置了强缓存,如果过了缓存时间呢
当强缓存过了缓存时间后,客户端会向服务器发送请求以获取最新的资源。此时,服务器会根据资源的最新状态返回相应的响应:
- 资源未更新:服务器返回 304 Not Modified 状态码,客户端继续使用本地缓存的资源。
- 资源已更新:服务器返回新的资源和相应的缓存头,客户端更新本地缓存并使用新的资源。
通过这种方式,客户端能够在缓存过期后依然保持资源的最新状态,同时减少不必要的带宽消耗。
解析文档到渲染过程也有优化的点,能介绍一下吗
解析文档到渲染的过程可以通过以下几个方面进行优化:
- 减少阻塞资源:
- CSS:将关键 CSS 内联,减少外部 CSS 文件的加载时间。
- JavaScript:将非关键 JavaScript 文件放在页面底部或使用
async和defer属性,避免阻塞页面渲染。
- 优化资源加载:
- 压缩文件:使用 Gzip 或 Brotli 压缩 CSS、JavaScript 和 HTML 文件,减少文件大小。
- 图片优化:使用合适的图片格式(如 WebP),并进行压缩和尺寸调整。
- 延迟加载:对非关键资源(如图片和视频)使用懒加载技术,减少初始加载时间。
- 使用缓存:
- 浏览器缓存:设置适当的缓存头(如
Cache-Control和Expires),让浏览器缓存静态资源。 - 服务端缓存:使用 CDN 缓存静态资源,减少服务器负载和响应时间。
- 减少 DOM 操作:
- 批量更新:将多次 DOM 操作合并为一次,减少重排和重绘。
- 虚拟 DOM:使用虚拟 DOM 技术(如 React)减少直接 DOM 操作,提高渲染性能。
- 优化渲染路径:
- CSS 优化:避免使用复杂的选择器和过多的嵌套,减少样式计算时间。
- JavaScript 优化:避免长时间运行的脚本,使用
requestAnimationFrame优化动画和交互。
通过这些优化措施,可以显著提高文档解析和渲染的效率,提升用户体验和页面加载速度。
流式传输
流式传输是一种数据传输方式,允许数据在传输过程中逐步处理,而不是等待整个数据集传输完成后再处理。它在处理大文件或实时数据时非常有用。以下是流式传输的主要特点和优势:
- 实时处理:数据在传输过程中可以立即处理,减少延迟。
- 节省内存:无需将整个数据集加载到内存中,适合处理大文件或数据流。
- 持续传输:适用于需要持续传输数据的应用,如视频流、音频流和实时日志。
流式传输的常见应用场景包括:
- 视频和音频流:如在线视频播放和在线音乐服务。
- 实时数据处理:如实时日志分析和传感器数据处理。
- 大文件传输:如文件下载和上传。
通过流式传输,应用程序可以更高效地处理和传输数据,提升用户体验和系统性能。
OAuth2.0 和 JWT 单点登录
OAuth2.0 和 JWT 是实现单点登录(SSO)的常用技术,它们在身份验证和授权方面发挥着重要作用。
OAuth2.0:
OAuth2.0 是一种授权框架,允许第三方应用程序在资源所有者的许可下访问资源服务器上的资源。其工作流程如下:
- 授权请求:客户端向授权服务器请求授权,通常通过重定向用户到授权服务器的授权页面。
- 用户授权:用户在授权页面上登录并同意授权请求。
- 授权码:授权服务器返回一个授权码给客户端。
- 获取令牌:客户端使用授权码向授权服务器请求访问令牌。
- 访问资源:客户端使用访问令牌向资源服务器请求资源。
JWT(JSON Web Token):
JWT 是一种用于在各方之间传递声明的紧凑、安全的令牌格式。JWT 通常用于身份验证和信息交换。其结构包括三个部分:头部(Header)、载荷(Payload)和签名(Signature)。
- 头部:包含令牌类型和签名算法。
- 载荷:包含声明(如用户信息和过期时间)。
- 签名:使用头部中指定的算法对头部和载荷进行签名,确保令牌的完整性和真实性。
单点登录(SSO):
单点登录是一种身份验证机制,允许用户在多个应用程序之间使用一次登录凭证。OAuth2.0 和 JWT 可以结合使用来实现 SSO:
- 用户登录:用户在身份提供者(IdP)上登录,IdP 生成一个 JWT。
- 令牌分发:IdP 将 JWT 返回给客户端,客户端将其存储在浏览器的 Cookie 或本地存储中。
- 访问应用:用户访问其他应用时,客户端将 JWT 附加到请求头中。
- 验证令牌:应用服务器验证 JWT 的签名和有效性,确认用户身份。
通过使用 OAuth2.0 和 JWT,可以实现安全、高效的单点登录,提高用户体验和系统安全性。
HTTP 和 HTTPS 的区别?为什么 HTTPS 更安全一点?HTTPS 为什么也不是十分安全?
HTTP 和 HTTPS 的区别:
- 协议:HTTP(HyperText Transfer Protocol)是明文传输协议,数据不加密。HTTPS(HyperText Transfer Protocol Secure)是在 HTTP 基础上加入 SSL/TLS 协议,数据加密传输。
- 端口:HTTP 默认使用端口 80,HTTPS 默认使用端口 443。
- 安全性:HTTP 不提供数据加密和身份验证,容易被窃听和篡改。HTTPS 提供数据加密、身份验证和数据完整性保护,安全性更高。
为什么 HTTPS 更安全一点:
- 数据加密:HTTPS 使用 SSL/TLS 协议对数据进行加密,防止数据在传输过程中被窃听。
- 身份验证:HTTPS 使用数字证书验证服务器身份,确保客户端连接的是合法服务器。
- 数据完整性:HTTPS 使用消息摘要和数字签名技术,确保数据在传输过程中未被篡改。
HTTPS 为什么也不是十分安全:
- 证书信任问题:如果 CA(证书颁发机构)被攻破或不可信,攻击者可以伪造合法证书,进行中间人攻击。
- 配置不当:服务器配置不当(如使用过时的加密算法或协议)会降低 HTTPS 的安全性。
- 社会工程攻击:攻击者可以通过钓鱼网站等手段骗取用户信任,即使使用 HTTPS 也无法防止此类攻击。
- 性能开销:HTTPS 的加密和解密过程会增加服务器和客户端的计算开销,可能影响性能。
尽管 HTTPS 提供了更高的安全性,但仍需结合其他安全措施(如防火墙、入侵检测系统等)来全面保护数据和系统安全。
https 加密原理
HTTPS(HyperText Transfer Protocol Secure)通过在 HTTP 的基础上加入 SSL/TLS 协议来实现加密。其加密原理如下:
- 建立连接:客户端发起 HTTPS 请求,连接到服务器的 443 端口。
- 服务器响应:服务器返回 SSL 证书,证书中包含公钥和服务器的身份信息。
- 验证证书:客户端验证服务器证书的合法性,确认服务器的身份。
- 生成会话密钥:客户端生成一个随机的对称密钥,并使用服务器的公钥加密该密钥,发送给服务器。
- 建立加密通道:服务器使用自己的私钥解密会话密钥,之后客户端和服务器使用该对称密钥进行加密通信。
CA 证书验证流程
- 证书申请和验证
- 服务器生成密钥对(公钥和私钥)
- 向 CA 提交证书申请(CSR)
- CA 对申请者身份进行严格审核
- CA 使用自己的私钥对申请者的证书进行签名
- 客户端验证过程
- 获取服务器证书
- 检查证书有效期
- 验证证书域名是否匹配
- 检查证书是否被吊销(CRL/OCSP)
- 验证证书链完整性
- 服务器证书由中级 CA 签发
- 中级 CA 证书由更高级 CA 签发
- 形成证书 → 中级 CA→ 根 CA 的信任链
- 每级证书都包含:
- 上级 CA 的数字签名
- 签发者信息
- 有效期
- 公钥信息
-
验证过程:
- 验证服务器证书签名,使用中级 CA 公钥
- 验证中级 CA 证书签名,使用上级 CA 公钥
- 依次向上直到根证书
- 任何一环验证失败都视为证书无效
-
证书防伪机制
-
使用非对称加密保护证书签名
-
CA 的根证书预置在操作系统中
-
数字签名技术原理:
-
CA 使用 Hash 函数计算证书内容的摘要
-
用 CA 的私钥加密摘要生成数字签名
-
将数字签名附加到证书中
-
验证流程:
- 客户端使用相同的 Hash 函数计算证书内容摘要
- 用 CA 的公钥解密证书中的数字签名
- 对比两个摘要是否一致
- 如果一致,证明证书未被篡改
-
安全保障:
- Hash 函数确保内容完整性
- 私钥加密确保签名不可伪造
- 公钥解密验证签名真实性
-
- 实时验证机制
- CRL:定期下载吊销证书列表
- OCSP:实时在线查询证书状态
- OCSP Stapling:服务器主动提供证书状态