TCP 和 UDP 的区别

• TCP 是面向连接的协议，需要在数据传输前建立连接；UDP 是无连接的，不需要建立连接。
• TCP 提供可靠的数据传输，保证数据包的顺序和完整性；UDP 不保证数据包的顺序或完整性。

TCP 能够检测并重传丢失或损坏的数据包；UDP 不提供错误恢复机制。

• TCP 具有拥塞控制机制，可以根据网络状况调整数据传输速率；UDP 没有拥塞控制，发送速率通常固定。
• TCP 通过滑动窗口机制进行流量控制，避免接收方处理不过来；UDP 没有流量控制。
• TCP 有复杂的报文头部（20-60字节），包含序列号、确认号等信息；UDP 的报文头部相对简单（8字节）。
• 由于 TCP 的连接建立、数据校验和重传机制，其性能开销通常比 UDP 大；UDP 由于简单，性能开销小。
• ==适用场景：==TCP 适用于需要可靠传输的应用，如网页浏览、文件传输等；UDP 适用于对实时性要求高的应用，如语音通话、视频会议等。

TCP 连接是如何确保可靠性的

TCP 通过序列号、确认报文、超时重传、数据校验、流量控制、拥塞控制等机制，确保了数据传输的可靠性和效率。

1. 序列号与确认应答（ACK）
   TCP 将数据分割成一个个报文段，并为每个字节分配一个序列号，以确保数据包的顺序。接收方收到数据后，会发送确认（ACK）告知发送方已成功接收，ACK 中带有期望收到的下一个序列号。发送方通过 ACK 知道数据已到达，若未收到 ACK 则触发重传。
2. 超时重传
   发送方为每个发送的报文段设置一个定时器，如果在规定时间内未收到对应的 ACK 报文（确认报文），就认为该报文段丢失，立即重新发送。
3. 数据校验——校验和
   TCP 使用校验和来检测数据在传输过程中是否出现错误，如果检测到错误，接收方会丢弃该数据包，并等待重传。
4. 拥塞控制
   TCP 通过算法如慢启动、拥塞避免、快重传和快恢复等，来控制数据的发送速率，防止网络拥塞，间接保证数据的可靠传输
5. 流量控制（滑动窗口）
   TCP 通过滑动窗口机制进行流量控制，确保接收方能够处理发送方的数据。

TCP 报文中：
序列号-报文段中第一个数据字节的序号
确认号-期望收到对方下一个报文段的首个字节序号，同时表明 之前的数据已经收到

TCP 流量控制

流量控制就是接收方通过滑动窗口，动态告诉发送方 “我还能收多少”，从而控制发送速率，避免数据溢出。

TCP 通过滑动窗口机制实现流量控制：
接收方—>发送方：

• 接收方在每个ACK 报文的窗口字段中，通告自己当前的接收窗口 rwnd，表示还能接收多少数据。（利用确认报文的接收窗口字段）
• 发送方的发送窗口由 rwnd 决定，以此控制发送量。（发送窗口 同时 受 拥塞控制机制 控制）（发送窗口受到接受窗口控制）
  接收窗口的性质：
• 接收窗口大小是动态调整的：缓冲区空闲空间大，窗口就大；缓冲区快满时，窗口就减小，甚至设为 0，让发送方暂停发送。
• 为了防止窗口更新报文丢失，发送方会使用持续计时器，定时发送窗口探测报文，确保及时获取最新的窗口大小。

TCP 拥塞控制机制

TCP 拥塞控制可以在网络出现拥塞时动态地调整数据传输的速率，以防止网络过载。TCP 拥塞控制的主要机制包括以下几个方面：

1. 慢启动 (Slow Start)：初始阶段，TCP 发送方会以较小的发送窗口开始传输数据（10个最大报文段长度以前是1个）。随着每次成功收到确认的数据，发送方逐渐增加发送窗口的大小，实现指数级的增长，这称为慢启动。这有助于在网络刚开始传输时谨慎地逐步增加速率，以避免引发拥塞。

2. 拥塞避免 (Congestion Avoidance)：一旦达到一定的阈值（通常是慢启动阈值），TCP 发送方就会进入拥塞避免阶段。在拥塞避免阶段，发送方以线性增加的方式增加发送窗口的大小，而不再是指数级的增长。这有助于控制发送速率，以避免引起网络拥塞。

3. 快速重传 (Fast Retransmit)：如果发送方连续收到多个（比如3个）相同的确认（例如1,2,3,4发送，2丢失，1收到后，后续对3,4的收到就会是对2的确认，因为期望收到2），它会认为发生了数据包的丢失，并会快速重传未确认的数据包，而不必等待超时。这有助于更快地恢复由于拥塞引起的数据包丢失。

4. 快速恢复 (Fast Recovery)：在发生快速重传后，TCP 进入快速恢复阶段。在这个阶段，发送方不会回到慢启动阶段，而是将慢启动阈值设置为当前窗口的一半，并将拥塞窗口（可以粗略视为发送窗口）大小设置为慢启动阈值加上已确认但未被快速重传的数据块的数量（就是快速重传相同确认的个数）。这有助于更快地从拥塞中恢复。

快速重传 -> 快速恢复 -> 拥塞避免

收到 3 个重复 ACK
    ↓
快速重传（重传丢失包）
    ↓
【快速恢复阶段】 
   - ssthresh = cwnd / 2
   - cwnd = ssthresh + 3
   - 每收到重复 ACK，cwnd++ 
   - 每收到新 ACK，退出快速恢复
    ↓
【拥塞避免阶段】
   - cwnd = ssthresh（刚刚退出时设置的）
   - 窗口线性增长

发送窗口 = min (cwnd 拥塞窗口，rwnd 接收窗口) 两者的最小值

TCP 三次握手的过程，三次握手的原因

(1) 三次握手的过程
第一次握手：客户端向服务端发送 SYN 报文（携带客户端初始序列号 seq=x， ACK = 0 确认号无效），请求连接服务器，客户端进入 SYN_SENT。
第二次握手：服务端收到后回复 SYN+ACK 报文（携带服务端初始序列号 seq=y，确认号 ack=x+1），服务端进入 SYN_RCVD。
第三次握手：客户端收到后发送 ACK 报文（ack=y+1，seq=x+1），双方进入 ESTABLISHED。

初始序列号是随机的

（2）三次握手的原因
通过三次握手，客户端和服务器都能够确认对方的接收和发送能力。第一次握手确认了客户端到服务器的通道是开放的；第二次握手确认了服务器到客户端的通道是开放的；第三次握手则确认了客户端接收到服务器的确认，从而确保了双方的通道都是可用的，双方收发能力正常。（不是更多次的原因）

如果是两次握手，会出现这样的一种情况： 服务器、客户端连接已经关闭，但是由于延迟，之前客户端发送的连接请求报文 到达了服务器，此时服务器会认为客户端想要建立连接，因此发送同步确认报文，此时客户端不会理会，从而会导致一个无效连接挂起，导致资源浪费。

TCP 四次挥手的过程，为什么是四次？

（1）四次挥手的过程
客户端发送完数据：

1. 第一次挥手：客户端发送一个 **FIN 报文给服务端**，表示自己要断开数据传送，报文中会指定一个序列号（seq=x）。然后，客户端进入 FIN-WAIT-1 状态。（客户端数据确认发送完了才会发送fin报文）
2. 第二次挥手：服务端收到 FIN 报文后，回复 ACK 报文给客户端，且把客户端的序列号值 +1，作为 ACK 报文的确认号（ack=x+1）（确认序列号）。然后，服务端进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。假定此时序列号 是 y 。

服务器端发送完数据：

1. 第三次挥手：服务端也要断开连接时，发送 FIN 报文给客户端，且指定一个序列号（seq=y+k，k是第二次挥手后又发送的字节数），随后服务端进入 LAST-ACK 状态。（此时发送完了数据，并且数据得到了ACK确认后才会考虑发送FIN）
2. 第四次挥手：客户端收到 FIN 报文后，发出 ACK 报文进行应答，并把服务端的序列号值 +1 作为 ACK 报文序列号（seq=y+k+1）。此时客户端进入 TIME-WAIT 状态。服务端在收到客户端的 ACK 报文后进入 CLOSE 状态。如果客户端等待 2MSL（报文段最大生存时间） 没有收到回复，才关闭连接（确保延迟的报文）。

（2）四次挥手的原因
==TCP 是全双工通信，==每个方向的数据传输是独立的，因此每个方向都需要单独的一对 FIN 和 ACK。主动关闭方发送 FIN 只表示自己不再发送新的数据，但被动关闭方可能还有数据未发完，所以不能立即回复 FIN，只能先回复 ACK 确认收到关闭请求。等到自己的数据发完，再发送 FIN。这就形成了四次交互，完全关闭TCP连接

最后等待2MSL的原因——防止确认报文的丢失
最后一次ACK（第四次挥手）是主动方对被动方FIN的确认。主动方发送后会进入TIME-WAIT状态，等待2MSL。这样即使最后一个ACK丢失，被动方超时重传FIN，主动方也能重新ACK，保证双方都能正确关闭，避免资源挂起或数据混乱。

UDP 怎么实现可靠传输

UDP 它不属于连接型协议，并且是不可靠的。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照 tcp 可靠性传输的方式。关键在于两点，从应用层角度考虑：
(1) 提供确认序列号，可以对数据确认和排序
(2) 提供超时重传，能避免数据报丢失

简洁性：发送方为每个包加序列号和时间戳，采用等-停方式发送，当时间超时就进行超时重传并加倍重传的超时时间；接收方根据序列号对 数据包 排序、去重并发送确认。

详细：
本端：首先在 UDP 数据报定义一个首部，首部包含确认序列号和时间戳，时间戳是用来计算 RTT (数据报传输的往返时间)，计算出合适的 RTO (重传的超时时间)。然后以等 - 停的方式发送数据报，即收到对端（接收方）的确认之后才发送下一个的数据报。当时间超时，本端重传数据报，同时 RTO 扩大为原来的两倍，重新开始计时。

对端：接受到一个数据报之后取下该数据报首部的时间戳和确认序列号，并添加本端的确认数据报首部之后发送给对段。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。

HTTP 的 Keep-Alive 和 TCP 的 Keepalive 的区别？

1. HTTP 的 Keep-Alive，是由应用层实现的，称为 HTTP 长连接 （http 1.0 默认短连接通过设置 HTTP 头 Connection: keep-alive 来实现，1.1 默认使用长连接）

每次请求都要经历这样的过程：建立 TCP 连接 -> HTTP 请求资源 -> 响应资源 -> 释放连接，这就是 HTTP 短连接。但是这样每次建立连接都只能请求一次资源，所以 HTTP 的 Keep-Alive 实现了使用同一个 TCP 连接来发送和接收多个 HTTP 请求 / 应答，避免了连接建立和释放的开销，这就是 HTTP 长连接。

通过设置 HTTP 头 Connection: keep-alive 来实现。

---

2. TCP 的 Keepalive，是由 TCP 层（内核态）实现的，称为 TCP 保活机制，是一种用于在 TCP 连接上检测空闲连接状态的机制

当 TCP 连接建立后，如果一段时间内没有任何数据传输，TCP Keepalive 会发送探测包来检查连接是否仍然有效。（多次探测无效就会关闭）

DNS 查询过程

DNS（Domain Name System） 用来将主机名和域名转换为 IP 地址，其查询过程一般通过以下步骤：

浏览器缓存检查 —> 系统缓存检查/Hosts文件 —> 本地DNS服务器（运营商提供） —> 根DNS服务器(引路人，不负责具体解析，告诉本地DNS服务器去哪找) —> 顶级域DNS服务器（引路人，不负责具体解析，告诉本地DNS服务器去哪找） —> 权威DNS服务器(负责域名解析) —> IP 地址 返回 本地DNS服务器,并缓存 —> 返回 IP 给 系统 并缓存 —> 返回 IP 地址 给 浏览器 并缓存 —> 浏览器 利用 IP 建立连接

![[Pasted image 20260306210835.png]]

CDN 是什么？

CDN(Content Delivery Network, 内容分发网络) 是一种分布式网络服务，将内容存储到分布式的服务器上，使用户可以从距离将近的服务器快速获得所需的内容，实现内容的快速、可靠传输。

CDN 的 核心工作原理有三点（就近+缓存+可用）：

1. 就近访问：
   CDN在全球范围内部署了多个服务器节点，用户的请求会被路由到距离最近的CDN节点，提供快速的内容访问。
2. 内容缓存
   • CDN节点会缓存网站的静态资源（如图片、CSS、JavaScript、视频等）
   • 工作流程：
     用户请求资源 → CDN节点检查是否有缓存
     • 有缓存：直接返回，速度极快
     • 无缓存：节点向源服务器请求资源，获取后缓存到本地再返回给用户，后续相同请求可直接命中缓存
   • 效果：减少源服务器负载，节省带宽成本
3. 可用性：
   即使某些节点出现问题，用户请求可以被重定向到其他健康的节点。保证服务持续可用，提升网站稳定性（负载均衡、故障转移能力）。

Cookie 和 Session 是什么？ 有什么区别？

（它们绑定使用！）

(1) Cookie 和 Session 是什么？

Cookie 和 Session 都是用于在 Web 应用中管理用户状态和身份的机制。由于 HTTP 协议本身是无状态的，服务器无法直接记住多个请求是否来自同一个用户，因此需要借助这两种技术来维持用户状态、识别同一用户。（需求）

1. Cooki

• 定义：Cookie 是一段小型文本数据，由服务器生成并发送给浏览器，浏览器会将其存储在本地（客户端）。当浏览器再次访问同一服务器时，会自动在请求头中携带该 Cookie，服务器通过解析 Cookie 就能识别出用户身份或保存的特定信息（是什么？ + 工作机制）。

• 工作机制：

  • 服务器通过 HTTP 响应头的 Set-Cookie 字段将 Cookie 发送给客户端。
  • 浏览器将 Cookie 保存下来（可以是内存或硬盘，取决于过期时间）。
  • 之后每次请求同一域名下的资源，浏览器都会在请求头的 Cookie 字段中附上之前保存的 Cookie。

• 常见用途：保存用户偏好设置（如语言、主题）、跟踪用户行为（如购物车内容）、实现“记住我”功能等。

2. Session

• 定义：Session 是一种在服务器端保存用户数据的机制。当用户访问服务器时，服务器会为每个用户创建一个独立的 Session 对象，用来存储该用户相关的信息（如登录状态、用户ID、权限等）。每个 Session 都有一个唯一的标识符，称为 Session ID，通常通过 Cookie 传递给客户端。（是什么？ + 工作机制）

• 工作机制：

  • 客户端首次访问服务器时，服务器生成一个 Session 对象，并分配唯一的 Session ID。
  • 服务器通过响应将 Session ID 发送给客户端，通常以 Cookie 的形式存储（也可通过 URL 参数传递，称为 URL 重写）。
  • 后续请求中，浏览器会自动携带包含 Session ID 的 Cookie，服务器据此找到对应的 Session 数据，从而维持用户状态。

• 常见用途：用户登录状态的保持、购物车数据存储、临时数据缓存等。

(2) Cookie 和 Session 的区别？

• 存储位置：Cookie 数据存储在用户的浏览器中，而 Session 数据存储在服务器上。
• 数据容量：Cookie 存储容量较小，一般为几 KB。Session 存储容量较大，通常没有固定限制，取决于服务器的配置和资源。
• 安全性：由于 Cookie 存储在用户浏览器中，因此可以被用户读取和篡改。相比之下，Session 数据存储在服务器上，更难被用户访问和修改（严重会出现盗号）。
• 生命周期：Cookie 可以设置过期时间，Session 依赖于会话的持续时间或用户活动。
• 传输方式：Cookie 在每次 HTTP 请求中都会被自动发送到服务器，而 Session ID 通常通过 Cookie 或 URL 参数传递。

---

当浏览器禁用 Cookie 时，服务器无法通过 Cookie 传递 Session ID，此时可以采用 URL 重写（URL Rewriting） 作为备选方案。具体做法是：

• 服务器在返回给客户端的页面中，将所有站内链接（包括表单的 action 地址）都动态地附加一个特殊的参数，例如 jsessionid=xxxxx（Java 中的常见形式），或者将 Session ID 直接嵌入 URL 路径中。
• 用户点击这些链接或提交表单时，Session ID 会通过 URL 参数传递给服务器，服务器解析后即可恢复对应的 Session。

注意会更加地不安全！

---

Cookie 最核心、最常见的作用之一，就是存 SessionID（临时Cookie），因为Session 是短期存储信息，取决于会话（可能一关就没）

Cookie 本身也可以是 “长期 Cookie”。 记住用户名，记住主题，记住 “7 天内免登录”