1-计算机网络

1.计算机网络

2025.10.29 DAY01

1.1 介绍一下TCP/IP模型和OSI模型的区别

OSI：物联网叔会使用

TCP/IP：接网叔用

OSI模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系，它将网络通信精细地划分为了七个层级，每个层级都负责特定的功能，而且每个层级都构建在下方的层级之上，为上面的层级提供服务。从下到上依次是物理层，数据链路层，网络层，传输层，会话层，表示层和应用层。虽然OSI模型在理论上更全面，但在实际网络通信中，TCP/IP模型更为实用。

TCP/IP模型分为四个层级，从下到上依次是，网络接口层、网络层、传输层、应用层。它将OSI中一些在实践中紧密联系、难以完全分开的层次进行了合并。

  1. 网络接口层：该层对应OSI模型的物理层和数据链路层。负责物理传输媒介的传输，例如跑在网线上的以太网或者空中的电波（Wi-Fi），并提供错误检测和纠正的功能。此外，网络接口层还包含硬件地址（MAC地址）的管理。

  2. 网络层：该层对应OSI模型中的网络层。主要协议是IP，它负责数据包最佳路线选择和转发，选择最佳路径将数据从源主机传到目标主机。IP协议使用IP地址来标识主机和网络，并进行逻辑地址寻址。

  3. 传输层：该层对应OSI模型的传输层。它负责端到端的数据传输，主要的传输层协议有两种，分别是TCP和UDP。TCP提供可靠的数据传输，如果数据包丢失，他会负责重发，速度稍慢，但绝对稳妥。确保了数据的正确性和完整性。而UDP是无连接不可靠的，只管发出数据包，追求速度快，丢一些数据包也无所谓，如实时音频和视频流。

  4. 应用层：该层与OSI模型的应用层和表示层以及会话层类似，直接面向用户，提供直接与用户应用程序交互的接口。它为网络上的各种应用程序提供服务，如网页（HTTP）、电子邮件（SMTP）、文件传输（FTP）等。

1.2 从输入 URL 到页面展示到底发生了什么？

  1. 输入网址，解析URL，准备发出HTTP请求。
  2. 检查浏览器缓存是否有该资源，如果有则直接返回，如果没有则进行下一步网络请求。
  3. DNS域名解析：网络请求前进行DNS解析，以获取请求域名的IP地址。DNS解析时会按本地浏览器缓存（自己的记事本）->本地Host文件（电脑的通讯录）->路由器缓存（小区门卫）->DNS服务器（打114查号台）->根DNS服务器（全国总登记处）的顺序查询域名对应的IP，直到找到为止。
  4. TCP三次握手建立连接：浏览器与服务器IP建立TCP连接。
  5. 客户端发送HTTP请求：连接建立后，浏览器端会构建请求行、请求头等信息，并把和该域名相关的Cookie等数据附加到请求头中，向 服务器构建请求信息。如果是HTTPS的话，还涉及到HTTPS的加解密流程。
  6. 服务器处理请求并返回HTTP资源：服务器接收到请求信息，根据请求生成响应数据。
  7. TCP四次挥手断开连接：浏览器与服务器IP断开TCP连接。
  8. 浏览器解析响应并渲染页面：
  • 浏览器解析响应头。若响应头状态码为301（永久重定向）、302（临时重定向），会重定向到新地址；若响应数据类型是字节流类型，一般会将请求提交给下载管理器；若是HTML类型，会进入下一部渲染流程。
  • 浏览器解析HTML文件，创建DOM树（毛坯框架，只有结构、没有颜色和样式的“架子”），解析CSS（装修风格指南）进行样式计算，然后将CSS和DOM合并，构建渲染树（最终装修效果图）；最后布局和绘制渲染树，完成页面展示。

2025.10.30 DAY02

1.3 HTTP请求报文和响应报文是怎样的，有哪些常见的字段？

HTTP报文主要分为请求报文和响应报文。

（1）请求报文主要由请求行、请求头、空行和请求体构成。

  1. 请求行包括如下字段
    • 方法（Method）：指定要执行的操作，比如GET、POST、PUT、DELETE。
    • 资源路径（Resource Path）：请求的资源的URI（统一资源标识符）。
    • HTTP版本（HTTP Version）：使用的HTTP协议的版本，如HTTP/1.1或HTTP/2.0.
  2. 请求头的字段较多，常使用的包含以下几个：
    • Host：请求服务器的域名。
    • Accept：客户端能处理的媒体类型。
    • Accept-Encoding：客户端能够解码的内容编码。
    • Authorization：用于认证的凭证信息，比如token数据。
    • Content-Length：请求体的长度。
    • Content-Type：请求体的媒体类型。
    • Cookie：存储在客户端的cookie数据。
    • If-None-Match：资源的ETag值，用于缓存控制。
    • Connection：管理连接的选项，如keep-alive。
  3. 空行是请求头和请求体之间的空行，用于分隔请求头和请求体。
  4. 请求体通常用于POST和PUT请求，包含发送给服务器的数据。

（2）HTTP响应报文是服务器向客户端返回的数据格式，用于传达服务器对客户端请求的处理结果以及相关的数据。一个标准的HTTP响应报文通常包含状态行、响应头、空行、响应体。

  1. 状态行包含HTTP版本、状态码和状态消息。例如：HTTP/1.1 200 OK
  2. 响应头部也是以键值对的形式提供的额外信息，类似于请求头部，用于告知客户端有关响应的详细信息。一些常见的响应头部字段包括：
    • Content-Type：指定响应主体的媒体类型。
    • Content-Length：指定响应主体的长度（字节数）。
    • Server：指定服务器的信息。
    • Expires: 响应的过期时间，之后内容被认为是过时的。
    • ETag: 响应体的实体标签，用于缓存和条件请求。
    • Last-Modified： 资源最后被修改的日期和时间。
    • Location：在重定向时指定新的资源位置。
    • Set-Cookie：在响应中设置Cookie。
    • Access-Control-Allow-Origin: 跨源资源共享（CORS）策略，指示哪些域可以访问资源。
  3. 空行（Empty Line）在响应头和响应体之间，表示响应头的结束。
  4. 响应体是服务端实际传输的数据，可以是文本、HTML页面、图片、视频等，也可能为空。

1.4 HTTP有哪些请求方式？

  1. GET：请求指定的资源，但是资源不会有任何的改变。
  2. POST：向指定资源提交数进行处理请求（例如提交表单），用于新建资源。
  3. PUT：完全更新或替换指定资源。
  4. DELETE：删除指定资源。
  5. HEAD：获取报文首部（状态行和响应头）。，不返回报文主体。
  6. OPTIONS：查询服务器支持的请求方法。
  7. PATCH：对资源进行部分更新。

1.5 GET请求和POST请求的区别

  1. 用途：GET请求通常用于获取数据，POST请求用于提交数据。
  2. 数据传输：GET请求将参数附加在URL之后，POST请求将数据放在请求体中。
  3. 安全性：GET请求由于参数暴露在URL中，安全性较低；POST请求参数不会暴露在URL中，相对更安全。
  4. 数据大小：GET请求受到URL长度限制，数据量有限；POST请求理论上没有大小限制。
  5. 幂等性：GET请求是幂等的，即多次执行相同的GET请求，资源的状态不会改变；POST请求不是幂等的，因为每次提交都可能改变资源状态。

幂等性：一个操作，你执行 1 次，和连续执行 10 次，对系统状态造成的“最终结果”是完全一样的。

  1. 缓存：GET请求可以被缓存，POST请求默认不会被缓存。

2025.10.31 DAY03

1.6 HTTP中常见的状态码有哪些？

image-20230811164251602

常用的包括以下几个：

200：表示客户端请求成功，且 响应中一定有数据/页面要返回。

201：客户端请求成功，创建了新资源。

204 ：无内容，服务器成功处理请求，但未返回任何内容。

301：永久重定向。

302： 临时重定向。

304：请求的内容没有修改过，所以服务器返回此响应时，不会返回网页内容，而是使用缓存。

401：请求需要身份验证。

403：请求的对应资源禁止被访问。

404：服务器无法找到对应资源。

500：服务器内部错误。

503： 服务由于超载或维护等临时原因不可用，通常只是暂时状态。

1.7 什么是强缓存和协商缓存

强缓存和协商缓存是HTTP缓存机制的两大类型，旨在减少服务器负担和提高网页加载速度。

  1. 强缓存是客户端在有效期内，不用向服务器发送请求，直接从本地读取资源。

    • Expires强缓存是指设置一个强缓存时间，在这个时间范围内，从内存直接读取缓存并返回。
      • 但缺点是依赖客户端本地时间。如果客户端本地时间不准，会导致缓存的有效期验证错误。
    • Cache-Control强缓存指定资源在获取后多少秒内有效，
      • 不再依赖本地时间，解决了Expires的主要缺陷，是目前现在的主流。

  2. 协商缓存是指当强缓存失效后，客户端必须向服务器发送请求，服务器根据资源状态判断是否可以使用本地缓存。

    • 如果资源未被修改，则服务器返回304 Not Modified，客户端使用本地资源
    • 如果资源已修改，则服务器返回200 OK，并附带最新内容。

    2.1 基于 Last-Modified 的协商

    • 机制：
      1. 服务器在响应头中提供Last-Modified（资源的最后修改时间）。
      2. 客户端在后续请求中，通过 If-Modified-Since 头部带上此时间。
      3. 服务器比较 If-Modified-Since 的值与资源的实际 Last-Modified 值。
    • 缺陷：
      1. 时间戳不精确：文件内容未变，但修改时间（如元数据更新）可能变化，导致缓存失效。
      2. 精度问题：修改时间以“秒”为单位，如果在 1 秒内发生多次修改，Last-Modified 不会变化，导致无法感知更新。

    2.2 基于 Etag 的协商

    • 机制：
      1. 服务器为资源生成一个唯一的标识符（ETag，通常是文件内容的哈希值或指纹）。
      2. 客户端在后续请求中，通过 If-None-Match 头部带上此 ETag。
      3. 服务器比较 If-None-Match 的值与资源的当前 ETag 值。
    • 优势：
      • 精确：ETag 基于文件内容生成。只要内容有变动，ETag 就会改变。
      • 可靠：解决了 Last-Modified 的所有缺陷，不受文件修改时间或修改频率的影响。

    ETag 提供了比 Last-Modified 更高精度的缓存校验机制。在实际应用中，服务器通常会同时支持两者，而客户端（浏览器）会优先使用 ETag 进行协商。

2025.11.01 DAY04

1.8 HTTP1.0和HTTP1.1的区别

1. 连接方式 (一长一短)

  • 1.0 默认短： 每次请求都“新建连接”，效率低。（需要 Connection: keep-alive 才能变长）
  • 1.1 默认长： 默认“持久连接”，一个连接传多个请求，效率高。

2. 管道机制 (一管一慢)

  • 1.0 效率慢： 严格“请求-等待-响应”，下一个请求必须等上一个回来。
  • 1.1 支持管： 支持“管道化”，可以一口气发多个请求，再按顺序收响应。（像子弹上膛）

3. 缓存策略 (一新一旧)

  • 1.0 策略旧： 主要靠“修改时间” (Expires, If-Modified-Since) 判断，不够准。
  • 1.1 策略新： 增加“文件指纹” (Etag, If-None-Match) 判断，更精确。

4. Host 头部 (一虚一实)

  • 1.0 没 Host (实)： 认为一台服务器 (IP) 就对应一个网站。
  • 1.1 必须有 Host (虚)： 必须带上 Host 头，告诉服务器你想访问哪个网站，支持“虚拟主机”（一台服务器放N个网站）。

5. 带宽优化 (一全一断)

  • 1.0 只能拿全： 服务器必须把整个文件发给你，不支持“断点续传”。
  • 1.1 支持分断： 靠 Range 头，可以“只请求一部分”（比如视频拖拽、断点续传），返回 206 状态码。

6. 错误处理 (补充)

  • 1.1 更多状态： 增加了 100 Continue 等新状态码，沟通更灵活。

1.9 HTTP2.0与HTTP1.1的区别？

1. 传输格式：“读信” 变 “扫码”

  • 1.1 (读信): 传文本，像服务器在读“英文信”，解析慢。
  • 2.0 (扫码): 传编码 (二进制)，像机器“扫条形码”，解析飞快。

2. 连接方式：“单道” 变 “多道”

  • 1.1 (单道): 挨个请求，易“队头阻塞”（前车不动，后车干等）。
  • 2.0 (多道): 并发请求，在一个连接上开“多条车道”（多路复用），互不干扰。

3. 头部处理：“全表” 变 “简报”

  • 1.1 (全表): 每次都发完整头部，内容重复，浪费流量。
  • 2.0 (简报): 压缩头部 (HPACK)，只发“变化的部分”，轻装上阵。

4. 资源获取：“被动” 变 “主动”

  • 1.1 (被动): 客户端要一个，才给一个。
  • 2.0 (主动): 服务器主动推送，猜到你需要，提前给你。

5. 加载顺序：“按序” 变 “按急”

  • 1.1 (按序): 基本是“先来后到”。
  • 2.0 (按急): 可设置优先级，分“轻重缓急”，先加载重要的。

1.10 HTTP3.0有了解过吗？

1. 无队头阻塞 (UDP 基础)

  • HTTP/2 (TCP 阻塞): 多路复用跑在 TCP 上。一个 TCP 包丢了，整条路（所有流）都会卡住。
  • HTTP/3 (QUIC 解决): 跑在 QUIC (UDP) 上，流与流之间完全独立。一个流的包丢了，只会阻塞那一个流，其他流继续传输，彻底解决了 TCP 级别的队头阻塞。

2. 零 RTT 连接建立 (快速握手)

  • HTTP/2 (多次握手): 建立连接需要 TCP 握手（1 RTT） + TLS 握手（1 RTT），总共 2 RTT。
  • HTTP/3 (合并握手): QUIC 将二者合并，首次连接只需 1 RTT。更重要的是，对于后续连接，它可以利用缓存实现 0-RTT，直接发送业务数据，极大降低延迟。

3. 连接迁移 (认 ID 不认 IP)

  • 传统连接 (认 IP): 靠“IP + 端口”来识别。当你从 Wi-Fi 切换到 5G，IP 变了，连接就断了。
  • QUIC (认 ID): 使用一个“连接 ID” (Connection ID) 来标识连接。即使网络切换、IP 变了，只要 ID 不变，连接就能无缝迁移，不会中断。

4. 优化的可靠性机制 (SACK)

  • HTTP/3 (QUIC 内置): 自己实现了一套可靠传输机制。它抛弃了早期 gQUIC 复杂且浪费带宽的 FEC（前向纠错）。
  • 当前方案: 依赖更高效的 “选择性重传” (SACK) 和先进的拥塞控制。这使得它能更精确地知道“哪个包丢了”，只重传必要的包，比 TCP 更智能。

5. 安全性 (强制内置)

  • HTTP/1 & 2 (可选): 加密 (HTTPS) 只是一个“选项”。
  • HTTP/3 (标配): TLS 1.3 加密是 QUIC 协议的“标配”，直接内置在协议中，无法关闭。所有通信天生就是加密的，更加安全。

2025.11.03 DAY05

1.11 HTTPS和HTTP有哪些区别

  1. 加密层：HTTP 数据传输是明文的，容易受到攻击，而HTTPS 在HTTP 的基础上增加了SSL/TLS 协议作为加密层，确保数据传输的安全性。
  2. HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
  3. 端口：而HTTP 使用端口80，HTTPS 通常使用端口443 。
  4. HTTPS 协议需要向 CA 申请数字证书，来保证服务器的身份是可信的。

（CA 就是一个权威的、受信任的第三方机构，专门负责在互联网上核实身份，并发放“身份证”。）

1.12 HTTPS的工作原理(HTTPS建立连接的过程）

1. 交换（亮证）

  • 客户端发起请求。
  • 服务器回送公钥证书（里面有公钥和身份信息）。

2. 验证（验明）

  • 客户端检查证书的 CA（是不是可信机构颁发？）。
  • 检查证书的有效期（是不是过期了？）。

3. 加密（送暗号）

  • 验证通过！客户端生成一个“对称密钥”（临时暗号）。
  • 用服务器的公钥把这个“暗号”锁起来，发给服务器。

4. 建连（对暗号）

  • 服务器用自己的私钥解开“暗号”。
  • 此时，双方都拥有了同一个“对称密钥”，安全连接建立。

5. 传输（加密聊）

  • 后续所有的数据，都用这个对称密钥加密后传输。
  • （因为对称加密速度非常快，适合大量数据传输）。

6. 校验（防篡改）

  • 数据附带消息认证码 (MAC)，像个“防伪封条”。
  • 接收方用“对称密钥”验证封条，确保数据没被坏人改过。

7. 结束（销毁）

  • 数据传完，连接断开。
  • 双方立即销毁这个“对称密钥”，下次再聊重新走一遍流程。

1.13 TCP和UDP的区别

1. 连接方式

  • TCP (面向连接): 必须在数据传输前建立连接（像打电话，需要先拨号接通）。
  • UDP (无连接): 不需要建立连接，直接发送数据（像寄明信片，写完地址就扔邮筒）。

2. 可靠性与顺序

  • TCP (可靠): 提供可靠的数据传输。保证数据包的顺序和完整性（有确认和重传机制）。
  • UDP (不可靠): 不保证数据包的顺序或完整性（丢了就丢了，顺序可能乱）。

3. 流量控制与拥塞控制

  • TCP (有控制):
    • 拥塞控制： 能根据网络状况自动调整数据传输速率，避免网络崩溃。
    • 流量控制： 通过“滑动窗口”机制，避免发送方把接收方“撑爆”。
  • UDP (无控制):
    • 无拥塞控制： 以固定速率发送，不管网络是否堵塞。
    • 无流量控制： 不管接收方是否处理得过来，只管猛发。

4. 错误处理

  • TCP (有): 能够检测并重传丢失或损坏的数据包。
  • UDP (无): 不提供错误恢复机制，错了就错了。

5. 头部开销与性能

  • TCP (复杂/开销大): 报文头部复杂（包含序列号、确认号等），用于实现可靠性，因此性能开销较大。
  • UDP (简单/开销小): 报文头部非常简单，因此性能开销小，速度快。

6. 适用场景

  • TCP (追求可靠): 适用于需要可靠传输的应用。
    • 例如： 网页浏览 (HTTP/HTTPS)、文件传输 (FTP)、电子邮件 (SMTP)。
  • UDP (追求实时): 适用于对实时性要求高、能容忍少量丢包的应用。
    • 例如： 语音通话、视频会议、在线直播、DNS 查询。

2025.11.04 DAY06

1.14 TCP连接如何确保可靠性

1. 序列号：编号排队，不怕顺序乱

  • 解释： 每个包都有个“页码”（序列号），接收方按页码拼装，保证数据顺序正确。

2. 数据校验：校验查错，坏包直接扔

  • 解释： 每个包都有个“校验码”。接收方一算，发现“码”对不上（数据损坏），就丢弃这个包，等着发送方重传。

3. 确认应答 (ACK)：收到回信，才算完事

  • 解释： 接收方每收到一个正确的包，就必须回一个“确认 (ACK)”消息。发送方收到“确认”，才知道对方收到了。

4. 超时重传：设个闹钟，超时就重发

  • 解释： 发送方每发一个包，就启动一个定时器（闹钟）。如果在闹钟响之前没收到“确认 (ACK)”，就当这个包丢了，立即重传。

5. 流量控制：滑动窗口，看你(接收方)能吃多少

  • 解释： 接收方会告诉发送方：“我的缓存（窗口）还能装多少？” 发送方根据接收方的处理能力来调整发送速度，防止把接收方“撑爆”。

6. 拥塞控制：观察路况(网络)，动态调速

  • 解释： 这是防止把网络“堵死”。发送方会（通过慢启动、拥塞避免等算法）试探网络，如果发现网络很堵（开始丢包），就主动降低发送速率。

1.15 既然提到了拥塞控制，那你能说说说拥塞控制是怎么实现的嘛

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

  1. 慢启动（Slow Start）： 初始阶段，TCP发送方会以较小的发送窗口开始传输数据。随着每次成功收到确认的数据，发送方逐渐增加发送窗口的大小，实现指数级的增长，这称为慢启动。这有助于在网络刚开始传输时谨慎地逐步增加速率，以避免引发拥塞。
  2. 拥塞避免（Congestion Avoidance）： 一旦达到一定的阈值（通常是慢启动阈值），TCP发送方就会进入拥塞避免阶段。在拥塞避免阶段，发送方以线性增加的方式增加发送窗口的大小，而不再是指数级的增长。这有助于控制发送速率，以避免引起网络拥塞。
  3. 快速重传（Fast Retransmit）： 如果发送方连续收到相同的确认，它会认为发生了数据包的丢失，并会快速重传未确认的数据包，而不必等待超时。这有助于更快地恢复由于拥塞引起的数据包丢失。
  4. 快速恢复（Fast Recovery）： 在发生快速重传后，TCP进入快速恢复阶段。在这个阶段，发送方不会回到慢启动阶段，而是将慢启动阈值设置为当前窗口的一半，并将拥塞窗口大小设置为慢启动阈值加上已确认但未被快速重传的数据块的数量。这有助于更快地从拥塞中恢复。

1.16 TCP流量控制是怎么实现的？

流量控制就是让发送方发送速率不要过快，让接收方来得及接收。利用滑动窗口机制就可以实施流量控制，主要方法就是动态调整发送方和接收方之间数据传输速率。

  • 滑动窗口大小： 在TCP通信中，每个TCP报文段都包含一个窗口字段，该字段指示发送方可以发送多少字节的数据而不等待确认。这个窗口大小是动态调整的。
  • 接收方窗口大小： 接收方通过TCP报文中的窗口字段告诉发送方自己当前的可接收窗口大小。这是接收方缓冲区中还有多少可用空间。
  • 流量控制的目标： 流量控制的目标是确保发送方不要发送超过接收方缓冲区容量的数据。如果接收方的缓冲区快满了，它会减小窗口大小，通知发送方暂停发送，以防止溢出。
  • 动态调整： 发送方会根据接收方的窗口大小动态调整发送数据的速率。如果接收方的窗口大小增加，发送方可以加速发送数据。如果窗口大小减小，发送方将减缓发送数据的速率。
  • 确认机制： 接收方会定期发送确认（ACK）报文，告知发送方已成功接收数据。这也与流量控制密切相关，因为接收方可以通过ACK报文中的窗口字段来通知发送方它的当前窗口大小。

1.17 UDP怎么实现可靠传输

UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。关键在于两点，从应用层角度考虑：

（1）提供超时重传，能避免数据报丢失。

（2）提供确认序列号，可以对数据报进行确认和排序。

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

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

2025.11.05 DAY07

1.18 TCP连接三次握手的过程，为什么是三次，可以是两次或者更多吗？

(1) 三次握手的过程

*第一次握手：客户端向服务器发送一个SYN （同步序列编号）报文，请求建立连接，客户端进入SYN_SENT 状态。

  1. 第二次握手：服务器收到SYN 报文后，如果同意建立连接，则会发送一个SYN-ACK （同步确认）报文作为响应，同时进入SYN_RCVD 状态。
  2. 第三次握手：客户端收到服务器的SYN-ACK 报文后，会发送一个ACK （确认）报文作为最终响应，之后客户端和服务器都进入ESTABLISHED 状态，连接建立成功。

(2)为什么需要三次握手

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

而如果仅使用两次握手，服务器可能无法确定客户端的接收能力是否正常，比如客户端可能已经关闭了连接，但之前发送的连接请求报文在网络上延迟到达了服务器，服务器就会主动去建立一个连接，但是客户端接收不到，导致资源的浪费。而四次握手可以优化为三次。

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

（1）四次挥手的过程

  1. 第一次挥手：客户端发送一个FIN报文给服务端，表示自己要断开数据传送，报文中会指定一个序列号 (seq=x)。然后,客户端进入FIN-WAIT-1 状态。
  2. 第二次挥手：服务端收到FIN报文后，回复ACK报文给客户端，且把客户端的序列号值+1，作为ACK报文的序列号(seq=x+1)。然后，服务端进入CLOSE-WAIT(seq=x+1)状态，客户端进入FIN-WAIT-2状态。
  3. 第三次挥手：服务端也要断开连接时，发送FIN报文给客户端，且指定一个序列号(seq=y+1)，随后服务端进入LAST-ACK状态。
  4. 第四次挥手：客户端收到FIN报文后，发出ACK报文进行应答，并把服务端的序列号值+1作为ACK报文序列号(seq=y+2)。此时客户端进入TIME-WAIT状态。服务端在收到客户端的ACK 报文后进入CLOSE 状态。如果客户端等待2MSL没有收到回复，才关闭连接。

（2）为什么需要四次挥手

TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。 当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后才会完全关闭 TCP 连接。因此两次挥手可以释放一端到另一端的TCP连接，完全释放连接一共需要四次挥手。

只有通过四次挥手，才可以确保双方都能接收到对方的最后一个数据段的确认，主动关闭方在发送完最后一个ACK后进入TIME-WAIT 状态，这是为了确保被动关闭方接收到最终的ACK ，如果被动关闭方没有接收到，它可以重发FIN 报文，主动关闭方可以再次发送ACK 。

而如果使用三次挥手，被动关闭方可能在发送最后一个数据段后立即关闭连接，而主动关闭方可能还没有接收到这个数据段的确认。

1.20 HTTP的Keep-Alive是什么？TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是一个东西吗？

  1. HTTP 的 Keep-Alive，是由应用层实现的，称为 HTTP 长连接

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

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

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

补充说明：

其实这里tcp的keepalive，不只是支持http，还可以支持ftp和smtp的，他是一个能力，类似于gc。

http的这个keepalive感觉更是一种策略吧，比如你有一个http用了keepalive，然后过了一会，你不传输数据了，这个时候没有通知对方close，这个时候tcp的keepalive就会起到用处去关闭这次链接。

2025.11.06 DAY08

1.21 DNS查询过程

1. 客户端：本地缓存检查

  • 检查本地DNS缓存：
    • 浏览器/操作系统首先查询本地DNS缓存（包括浏览器缓存、系统缓存、Hosts文件等）。
    • 如果缓存中有对应的 IP 地址，并且未过期，则直接返回结果，查询结束。

2. 本地 DNS 服务器：递归查询

  • 发起查询：
    • 如果本地缓存中没有，客户端会向本地 DNS 服务器（通常由 ISP 提供，如中国移动）发送查询请求。
  • 检查本地 DNS 缓存：
    • 本地 DNS 服务器首先检查自己的缓存。如果它有该域名的解析记录，就直接返回 IP 地址，查询结束。
  • 逐级查询（如果缓存没有）：
    1. 查询根服务器 (.):
      • 本地 DNS 向根 DNS 服务器发出请求。
      • 根服务器不负责具体解析，但它会告诉本地 DNS 应该去问哪个顶级域（TLD）服务器（例如 .com）。
    2. 查询顶级域服务器 (.com):
      • 本地 DNS 接着向 .com 顶级域服务器发出请求。
      • 顶级域服务器也不负责具体解析，但它会告诉本地 DNS 应该去问哪个权威 DNS 服务器（例如 example.com 的服务器）。
    3. 查询权威 DNS 服务器 (example.com):
      • 本地 DNS 最后向权威 DNS 服务器发送请求。
      • 权威 DNS 服务器是唯一存储着 example.com 域名和 IP 地址映射的服务器。
      • 权威 DNS 服务器查询后，将最终的 IP 地址返回给本地 DNS 服务器。

3. 本地 DNS 服务器：缓存并响应

  • 缓存结果：
    • 本地 DNS 解析器将收到的 IP 地址缓存在本地（以便下次同一请求能快速响应）。
  • 返回结果给客户端：
    • 本地 DNS 解析器将该 IP 地址返回给你的计算机（浏览器）。

4. 客户端：发起连接

  • 建立连接：
    • 浏览器最终获得 IP 地址，开始使用该 IP 地址与目标服务器建立连接（如 TCP 连接），开始获取网页内容。

1.22 CDN是什么，有什么作用？

CDN 是一种分布式网络服务，它通过将内容存储在靠近用户的分布式服务器上，加速互联网内容的传输。

1. 就近访问（提升速度）

  • 全球节点： CDN 在全球范围内部署了多个服务器节点。
  • 智能路由： 用户的请求会被自动路由到距离最近的 CDN 节点。
  • 效果： 提供最快的内容访问速度，降低延迟。

2. 内容缓存（减轻源站压力）

  • 缓存静态资源： CDN 节点会缓存网站的静态资源（如图片、样式表、脚本等）。
  • 缓存命中（有缓存）：
    • 当用户请求资源时，CDN 节点会首先检查本地缓存。
    • 如果有，CDN 节点直接返回缓存的资源，速度极快。
  • 缓存未命中（无缓存 / 回源）：
    • 如果没有缓存该资源，CDN 节点会“回源”（即向原始服务器）获取资源。
    • 获取后，CDN 节点将资源返回给用户，并同时缓存一份在节点中，供后续请求使用。
  • 效果： 大幅减少对原始服务器的请求，极大减轻了源站的负载压力。

3. 可用性（提升稳定性）

  • 自动重定向： 即使 CDN 的某个节点出现故障或下线。
  • 无缝切换： 用户的请求可以被自动重定向到其他健康的节点上。
  • 效果： 保证了服务的高可用性，避免因单点故障导致网站无法访问。

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

(1) Cookie和Session是什么？

Cookie 和 Session 都用于管理用户的状态和身份, Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。

  1. Cookie
  • 通常，服务器会将一个或多个 Cookie 发送到用户浏览器，然后浏览器将这些 Cookie 存储在本地。
  • 服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的Cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。
  1. Session

客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。Session 主要用于维护用户登录状态、存储用户的临时数据和上下文信息等。服务器为每个用户分配一个唯一的Session ID，通常存储在Cookie中。

（2） Cookie和Session的区别？

  • 存储位置：Cookie 数据存储在用户的浏览器中，而 Session 数据存储在服务器上。
  • 数据容量：Cookie 存储容量较小，一般为几 KB。Session 存储容量较大，通常没有固定限制，取决于服务器的配置和资源。
  • 安全性：由于 Cookie 存储在用户浏览器中，因此可以被用户读取和篡改。相比之下，Session 数据存储在服务器上，更难被用户访问和修改。
  • 生命周期：Cookie可以设置过期时间，Session 依赖于会话的持续时间或用户活动。
  • 传输方式：Cookie 在每次 HTTP 请求中都会被自动发送到服务器，而 Session ID 通常通过 Cookie 或 URL 参数传递。
posted @ 2025-11-22 20:15  JuanWenhao  阅读(1)  评论(0)    收藏  举报