计算机网络

# 计算机网络

# 1. 计算机网络概述

计算机网络（Computer Network）是由多个计算设备（如计算机、服务器、路由器、交换机等）通过通信介质（如光纤、电缆、无线信号等）互连，并按照特定的通信协议进行数据交换和资源共享的系统。计算机网络的主要目标包括：

数据通信：在不同设备之间传输数据。
资源共享：如共享打印机、文件存储、数据库等。
远程访问：支持远程办公、云计算等应用。
负载均衡：通过多个设备协调工作，提高系统性能和可靠性。
安全管理：采用加密、认证等方式保护数据安全。

计算机网络可按覆盖范围分为局域网（LAN）、城域网（MAN）、广域网（WAN）和互联网（Internet）；按拓扑结构分为总线型、星型、环型、网状等网络；按传输方式可分为电路交换、分组交换和报文交换。

# 2. 计算机网络体系结构

计算机网络体系结构是指网络功能的分层组织方式，它规定了数据如何在不同层次之间传输。5层只是OSI和TCP/IP的综合，是业界产生出来的非官方协议模型，但是很多具体的应用。实际应用还是TCP/IP的四层结构。为了方便可以把下两层称为网络接口层。五层体系结构包括：应用层、运输层、网络层、数据链路层和物理层。

# 2.1 OSI 七层模型（Open Systems Interconnection Model）

OSI 模型是国际标准化组织（ISO）提出的网络通信参考模型，它将网络通信划分为 7 层，每一层负责特定功能，从底层的物理传输到高层的应用数据处理。

层级	名称	主要功能	代表协议/技术
7	应用层（Application）	提供应用程序间的通信	HTTP、FTP、SMTP
6	表示层（Presentation）	处理数据格式转换、加密解密	JPEG、SSL/TLS
5	会话层（Session）	维护会话连接、管理数据交换	RPC、NetBIOS
4	传输层（Transport）	提供端到端的通信、可靠传输	TCP、UDP
3	网络层（Network）	负责数据的寻址和路由	IP、ICMP
2	数据链路层（Data Link）	组帧、差错检测、介质访问控制	以太网（Ethernet）、PPP
1	物理层（Physical）	物理信号传输	光纤、电缆、无线信号

OSI 模型提供了理论上的参考，但在实际应用中，互联网主要采用 TCP/IP 四层模型。

# 2.2 TCP/IP 四层模型

TCP/IP 是目前互联网的主要协议体系，它将网络通信划分为 4 层：

层级	OSI 对应层	名称	主要协议
4	7、6、5	应用层（Application）	HTTP、FTP、DNS、SMTP
3	4	传输层（Transport）	TCP、UDP
2	3	网络层（Internet）	IP、ICMP、ARP
1	2、1	网络接口层（Link）	以太网、Wi-Fi、PPP

TCP/IP 体系结构更加简化，适用于实际网络部署，因此成为现代互联网的标准。

# 3. 浏览器地址栏输入 URL到显示网页的过程

这个过程包括多个步骤，涵盖了 DNS 解析、TCP 连接、发送 HTTP 请求、服务器处理请求并返回 HTTP 响应、浏览器处理响应并渲染页面等多个环节。

DNS 解析：浏览器会发起一个 DNS 请求到 DNS 服务器，将域名解析为服务器的 IP 地址。
TCP 连接：浏览器通过解析得到的 IP 地址与服务器建立 TCP 连接。这一步涉及到 TCP 的三次握手，用于确保双方都已经准备好进行数据传输了。
发送 HTTP 请求：浏览器构建 HTTP 请求，包括请求行、请求头和请求体；然后将请求发送到服务器。
服务器处理请求：服务器接收到 HTTP 请求后，根据请求的资源路径，经过后端处理，生成 HTTP 响应消息；响应消息包括状态行、响应头和响应体。
浏览器接收 HTTP 响应：浏览器接收到服务器返回的 HTTP 响应数据后，开始解析响应体中的 HTML 内容；然后构建 DOM 树、解析 CSS 和 JavaScript 文件等，最终渲染页面。
断开连接：TCP 四次挥手，连接结束。

# 3. DNS解析过程

浏览器将域名转换为服务器的 IP 地址的过程：

浏览器缓存：浏览器会先检查自己的 DNS 缓存，看看是否已经解析过这个域名。
操作系统缓存：如果浏览器缓存没有找到，浏览器会向操作系统查询本地的 DNS 缓存（如 hosts 文件）。
本地 DNS 服务器（ISP 解析）：如果本地没有缓存，操作系统会向 ISP 提供的 DNS 服务器查询。
递归查询根 DNS 服务器：
- 本地 DNS 服务器向 根 DNS 服务器 查询顶级域（如 .com）。
- 根服务器指向 TLD 服务器（如 .com 顶级域的 DNS 服务器）。
- TLD 服务器指向 权威 DNS 服务器（管理 example.com 的 DNS）。
- 权威 DNS 服务器返回 目标 IP 地址（如 93.184.216.34）。
DNS 解析完成，浏览器获得目标服务器的 IP 地址。

# 4. TCP的建立与终止

TCP（Transmission Control Protocol，传输控制协议）是面向连接的、可靠的传输层协议，它通过三次握手建立连接，并通过四次挥手断开连接，确保数据能够正确、完整地传输。

# 4.1 TCP 连接的建立（三次握手）

三次握手（Three-Way Handshake） 用于确保客户端和服务器双方都具备发送和接收数据的能力，并且可以防止已失效的连接请求包被错误接收。

假设客户端 A 要与服务器 B 建立 TCP 连接：

第一次握手（Client → Server）：
- 客户端 A 发送 SYN（同步）报文，并携带初始序列号 seq = x，告诉服务器请求建立连接。
- A 进入 SYN_SENT 状态。
第二次握手（Server → Client）：
- 服务器 B收到 A的 SYN后，回复 SYN + ACK报文，表示同意连接：
  - SYN = 1（同意连接）
  - ACK = 1（确认收到 A 的 SYN）
  - 服务器生成自己的初始序列号 seq = y
- B 进入 SYN_RECEIVED 状态。
第三次握手（Client → Server）：
- 客户端 A 收到 SYN + ACK 后，回复ACK 报文（ACK = 1，确认 B 的 SYN）。
- A 进入 ESTABLISHED（连接建立）状态，服务器收到 ACK 后，也进入 ESTABLISHED 状态。
- TCP 连接建立成功！

# 4.2 TCP 连接的终止（四次挥手）

四次挥手（Four-Way Handshake） 用于确保双方都能优雅地断开连接，避免数据丢失。

# 四次挥手流程

第一次挥手（Client → Server）：
- 客户端 A 发送 FIN（终止标志）报文，表示不再发送数据，但仍能接收数据。
- A 进入 FIN_WAIT_1 状态。
第二次挥手（Server → Client）：
- 服务器 B 收到 FIN 后，回复 ACK（确认），表示同意关闭客户端的发送通道，但服务器仍可能有数据要发送。
- A 进入 FIN_WAIT_2 状态，等待 B 的 FIN。
第三次挥手（Server → Client）：
- 服务器 B 处理完剩余数据后，发送 FIN 报文，表示服务器端也不再发送数据。
- B 进入 LAST_ACK 状态。
第四次挥手（Client → Server）：
- 客户端 A 收到 FIN 后，回复 ACK，并进入 TIME_WAIT 状态（等待 2 * MSL，确保 B 收到 ACK）。
- B 收到 ACK 后，直接进入 CLOSED 状态，连接关闭。
- A 经过 TIME_WAIT 后，进入 CLOSED 状态，完成连接释放。

# 4.3 为什么建立连接需三次握手？

确认双方的收发能力：

三次握手的核心目的是为了建立一个可靠的通信信道，确保双方都具备发送和接收数据的能力。每一方通过三次握手确认自己和对方的通信状态。
- 第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
- 第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
- 第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常
序列号可靠同步：
- 在建立连接时，双方都需要交换初始的序列号，用于后续的数据包排序。如果只有两次握手，服务端无法确认客户端是否已经收到自己的初始序列号（SYN 中的序列号）。如果第二次握手报文丢失，客户端就无法得到服务端的初始序列号，导致数据传输无法进行。
- 三次握手确保了客户端和服务器都能够确认彼此的初始序列号，并进行同步，确保可靠的数据传输。
阻止重复历史连接的初始化：
- 由于网络环境的复杂性，旧的 SYN 包可能在网络中延迟并先于新的 SYN 包到达服务器。如果只是两次握手，服务器会立即对第一个 SYN 包建立连接，无论这个 SYN 包是否是之前的连接请求。如果服务器收到的是旧的 SYN 包（可能已经过时），会导致异常连接的建立。
- 三次握手通过使用序列号和确认机制来防止这种情况。客户端在收到第二次握手的 SYN+ACK 包时，会检查序列号，如果收到的是旧的 SYN 包，就会发送 RST（重置）包，通知服务器此连接请求是过时的，并且服务器也会中止连接。直到正常的 SYN 包到达，连接才会真正建立。

# 4.4 为什么需要四次挥手而不是两次？

连接的建立和关闭是双向的。这意味着，在建立连接时，客户端和服务器都需要确认自己能发送和接收数据；而在关闭连接时，双方都需要独立地关闭自己的数据发送通道。因为 TCP 是全双工的通信协议，双方都可能仍有数据要发送，因此关闭连接时需要特别小心，确保每一方都完成了数据发送任务。

建立连接时，当服务端收到客户端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。

关闭连接时，当服务端收到 FIN 报文时，可能服务器还有未发送完的报文，并不会立即关闭 SOCKET。

先回复一个 ACK 报文，告诉客户端，”你发的 FIN 报文我收到了”
只有等到服务端所有的报文都发送完了，才能发送 FIN 报文

# 4.5 TIME_WAIT 状态的作用

客户端进入 TIME_WAIT 状态，会等待 2 * MSL（Maximum Segment Lifetime，报文最大存活时间） 才真正关闭连接。

为什么需要 TIME_WAIT？

防止已关闭连接的旧数据包影响新连接：
- 可能有延迟的 TCP 数据包仍在网络中，如果立即建立相同端口的新连接，旧数据包可能被误认为新连接的数据，造成混乱。
确保服务器接收到了最后的 ACK：
- 如果 客户端 直接关闭连接，而 服务端 的 FIN 重新传输（因丢包），A 无法回应 ACK，服务器会一直等待，导致连接资源无法释放。

# 4.6 TCP流量控制与拥塞控制详解

# 4.61 为什么需要引入这两个机制？

TCP的基本传输逻辑是：

发送方发出数据段；
接收方收到后发送ACK确认；
发送方确认ACK后继续发送下一段。

TCP是可靠的面向连接的协议。如果严格按照这个流程，一个RTT（Round-Trip Time）只能发送一个数据段，效率太低。实际上，大多数数据段都能可靠到达，因此我们希望在等待ACK的同时也能继续发送更多数据——前提是不能发送太快导致：

接收方处理不过来（流量控制的问题）；
网络本身过载（拥塞控制的问题）。

# 4.62 TCP流量控制（Flow Control）

TCP的接收端在内存中开辟一段缓冲区用于临时保存收到的数据段，直到应用程序来读取这些数据。如果接收端来不及处理，缓冲区可能溢出，造成数据丢失。

为了解决这个问题，TCP引入了滑动窗口协议，核心思路：

接收方告知发送方：当前我还有多少空间（通过TCP头部中的Window字段）；
发送方根据这个窗口大小，控制最多可以发送但未被确认的数据字节数。

📝这个窗口就是“流量控制窗口”（有时简称rwnd，receive window），由接收端定义。

滑动窗口的工作方式：

每收到一个ACK确认，窗口向前滑动；
当接收缓存快满了，接收方可以通告一个窗口值为0，告知发送方暂停发送。

# 4.63 TCP拥塞控制（Congestion Control）

即使接收方可以处理数据，如果网络本身负载太重（如路由器缓存满，丢包率上升），也会引起性能问题，甚至造成网络“雪崩”。这就是拥塞。

为了避免引起网络拥堵，TCP发送方引入了一个拥塞窗口 CWND：

这是发送端自身维护的参数；
表示当前网络允许我发送的数据量估计值。

发送方每次实际可以发送的最大数据量取决于三个窗口中的最小值：

Effective Window Size = min (rwnd, cwnd)

即：既不能超过接收方能接受的量（流量控制），也不能超过网络能承载的量（拥塞控制）。

# 4.64 拥塞控制的四个经典阶段

TCP 拥塞控制并不是静态的，而是根据网络反馈动态调整 CWND。典型策略如下：

# 4.1 慢启动（Slow Start）

初始 CWND 值较小（通常是1个MSS）；
每收到一个ACK，CWND就加1（指数增长）；
当CWND达到一个阈值（ssthresh）时，进入下一个阶段。

# 4.2 拥塞避免（Congestion Avoidance）

CWND线性增长，每个RTT增加1个MSS；
避免像慢启动那样指数扩张，造成网络崩溃。

# 4.3 快速重传（Fast Retransmit）

如果连续收到三个重复的ACK（说明有分包丢失），就不等超时，立刻重传丢失的数据段。

# 4.4 快速恢复（Fast Recovery）

快速重传后，不是回到慢启动初始阶段；
将CWND减半（进入拥塞避免），逐渐恢复。

# 5. TCP与UDP区别

TCP（Transmission Control Protocol，传输控制协议）和UDP（User Datagram Protocol，用户数据报协议）是两种主要的传输层协议，它们在数据传输方式、可靠性、性能等方面存在显著区别。

# 5.1 UDP 是面向报文的协议

UDP 传输数据时，应用层发送的每一个消息（即用户数据）都会被封装成一个独立的 UDP 数据报（Datagram），并作为一个整体进行传输，不会被拆分或合并。换句话说，UDP 以完整的数据报为单位进行传输，一个 UDP 报文就对应一个用户消息。

例如，应用层发送了一条 500 字节的消息，UDP 直接将其封装为一个 500 字节的 UDP 报文，并通过 IP 层传输。
如果应用层发送两条消息，UDP 也会分别发送两个独立的 UDP 报文。

因此，UDP 传输时不会出现消息边界模糊的问题，也不存在粘包（多个消息被合并）或拆包（一个消息被拆成多个包）的情况。

# 5.2 TCP 是面向字节流的协议

TCP 传输数据时，应用层发送的消息并不会被保留成独立的报文，而是被看作连续的字节流，然后由 TCP 根据底层网络的传输情况进行拆分、合并、重新排序。

例如，应用层发送了一条 5000 字节的消息，TCP 可能会拆分成多个 TCP 报文（MSS 限制，通常每个 TCP 报文大小在 1460 字节左右）。
反之，应用层发送了两条小消息（各 100 字节），TCP 可能会合并在同一个 TCP 报文中一起发送，以提高传输效率。

由于 TCP 传输的是没有边界的字节流，在接收端读取数据时，可能会遇到以下问题：

粘包（Packet Stick）：多个应用层消息被合并到同一个 TCP 报文中，导致接收端一次读取时拿到了多个消息的数据。
拆包（Packet Fragmentation）：一个应用层消息被拆分成多个 TCP 报文，接收端一次读取时只拿到部分数据，需要等待后续数据到来才能拼接完整。

特性	TCP	UDP
是否面向连接	是	否
传输方式	字节流	数据报
可靠性	可靠（有序、无丢失）	不可靠（可能丢失、乱序）
速度	较慢	快
适用场景	Web、邮件、文件传输	视频、VoIP、DNS、游戏
传输控制	有流量控制、拥塞控制	无
首部开销	20 字节以上	8 字节

TCP 适用于数据可靠性要求高的场景，而 UDP 适用于低延迟、实时性强的应用。

# 5.3 解决 TCP 粘包/拆包问题的方法

由于 TCP 是面向字节流的协议，应用层必须自己定义消息的边界，以便正确解析数据，常见的方法有以下几种：

固定长度消息
- 规定每个消息的长度是固定的，例如 1024 字节，不足的部分用填充字符补齐。
- 这种方式适用于结构化数据传输，但会浪费空间，不够灵活。
特殊分隔符
- 在每个消息结尾添加特定的分隔符，例如 \n（常见于文本协议，如 HTTP 头部）、0xFF 之类的特殊字符。
- 读取数据时，解析到分隔符即可确定消息的边界。
- 需要确保分隔符不会出现在消息内容中，否则会影响解析。
自定义消息结构（长度+数据）
- 采用消息头 + 消息体的格式，其中消息头存储消息的总长度，消息体存储实际数据。
- 例如，先传输 4 字节的消息长度字段（如 int 类型），然后再根据该长度读取完整的消息数据。
- 许多二进制协议（如 TLV、Protobuf）都采用这种方式，既灵活又高效。

# 6. HTTP和HTTPS

HTTP（超文本传输协议）和HTTPS（安全超文本传输协议）都是用于在Web上传输数据的协议，但它们之间有一些关键的区别，主要体现在安全性和加密方面。

# 6.1 HTTP (HyperText Transfer Protocol)

定义：HTTP 是一种无状态的应用层协议，主要用于在客户端（浏览器）和服务器之间传输文本、图片、视频等网页内容。
工作原理：HTTP 使用的是明文传输，即数据在网络上传输时没有加密，任何人都可以截取到传输过程中的内容。
端口：HTTP 默认使用端口80。
安全性：HTTP 是不安全的，数据在传输过程中可能被窃听、篡改或伪造，容易受到中间人攻击（MITM）。
常见场景：适用于对安全性要求不高的场合，如公开的网页浏览、论坛等。

# 6.2 HTTPS (HyperText Transfer Protocol Secure)

定义：HTTPS 是在 HTTP 的基础上加入了 SSL/TLS 协议进行加密，确保数据传输的安全性。它通过使用 SSL/TLS 加密协议保护数据的机密性和完整性，防止数据在传输过程中被窃取或篡改。
工作原理：HTTPS 使用加密传输，通过对数据进行加密处理，确保即使数据被截取，也无法被解读。其过程包括：
1. 加密：使用 SSL/TLS 协议加密数据。
2. 身份验证：通过数字证书验证服务器的身份，确保数据是发送到正确的服务器。
3. 数据完整性：利用消息认证码（MAC）等方法，确保数据在传输过程中未被篡改。
端口：HTTPS 默认使用端口443。
安全性：HTTPS 是安全的，通过加密技术，保障数据的机密性、完整性和身份认证，防止中间人攻击（MITM）。
常见场景：适用于需要保护用户数据安全的场合，如在线支付、网上银行、登录认证、社交媒体等。

# 6.3主要区别

特性	HTTP	HTTPS
安全性	不加密，传输明文	使用SSL/TLS加密，确保数据安全
端口	80	443
协议层	仅应用层协议	应用层协议 + SSL/TLS加密协议
传输速度	较快（无加密开销）	较慢（有加密和解密过程）
验证	无验证	通过证书验证服务器身份
数据保护	无保护	保证数据的机密性、完整性、身份认证
使用场景	适用于无安全需求的网页浏览	适用于需要安全保障的网站，如银行、支付平台等

# 6.4HTTPS的工作流程简述

HTTPS的工作流程主要依赖于SSL/TLS协议，它通过加密和身份验证确保通信的安全性。以下是HTTPS的工作流程，按步骤详细解释：

客户端发起HTTPS请求，向服务器请求建立SSL/TLS连接。
客户端发送“ClientHello”消息，包含支持的SSL/TLS版本和加密套件，随机数等。
服务器收到“ClientHello”后，选择加密套件并返回“ServerHello”消息，包含选定的加密算法、服务器随机数等，发送数字证书。
客户端验证服务器证书，包括检查证书的有效期、签名、CA信任等。
客户端生成预主密钥，用服务器公钥加密后发送给服务器。
服务器用私钥解密预主密钥，得到相同的预主密钥。
客户端和服务器根据预主密钥和随机数生成对称加密会话密钥。
双方使用会话密钥加密后续的数据传输，确保机密性和数据完整性。
数据传输过程中，双方使用消息认证码（MAC）确保数据未被篡改。
会话结束时，双方交换“Close Notify”信号，结束加密连接。
对于后续连接，可以通过会话复用机制提高效率，避免重复握手过程。

# 7. 如何理解 HTTP 协议是无状态的？

HTTP 协议的无状态性指的是：每个 HTTP 请求都是独立的，服务器在处理当前请求时，不会自动记住之前请求的状态或上下文。换句话说，服务器不会主动保存客户端的任何历史信息，每次请求对于服务器来说都像是“全新”的。

你用“我家大门常打开，是人是神都欢迎”来比喻很贴切。可以想象服务器是一个“健忘”的服务员：每次你去点菜（发起请求），服务员都会认真接待，但不会主动记得你上一次点了什么，除非你自己告诉他（通过额外的方式携带状态信息）。这个“告诉他”的方式，就是通过 Cookies、Session 或其他机制实现的。

# 7.1 为什么是无状态的？

设计初衷：HTTP 最初是为传输超文本（HTML页面）设计的，请求一个页面通常是独立的，不需要服务器记住之前的操作。
简单高效：无状态减少了服务器的负担，不需要为每个客户端维护复杂的状态信息。

# 7.2 如何记录状态？

为了弥补无状态的局限性，开发者引入了以下方法：

Cookies：服务器通过 Set-Cookie 响应头将状态信息存储在客户端，客户端后续请求会自动带上 Cookie。
Session：服务器生成一个唯一的 SessionID（会话标识），存储在 Cookie 中，服务器端通过这个 ID 关联状态信息。
Token：如 JWT（JSON Web Token），客户端每次请求携带 Token，服务器验证后获取状态。

# 8 . WebSocket 与 HTTP 的关系与区别

# 8.1 什么是 WebSocket？

WebSocket 是一种 全双工（Full-Duplex）通信协议，它允许 客户端（如浏览器）和服务器之间建立持久连接，并能在连接建立后实现实时、双向的数据传输。
它基于 TCP 传输，与 HTTP 兼容，但一旦建立连接，就不再使用 HTTP 进行数据交换，而是采用 WebSocket 自己的协议格式。

WebSocket 连接过程：

客户端发起 HTTP 请求，并在 Upgrade 头中请求升级到 WebSocket 协议。
服务器同意后，返回 101 Switching Protocols 响应，表示协议切换成功。
连接建立后，客户端和服务器可以随时相互发送数据，而无需重复握手。

常见 WebSocket URL 格式：

ws://example.com/socket（默认端口 80，非加密）
wss://example.com/socket（默认端口 443，使用 TLS 加密）

# 8.2 为什么要使用 WebSocket？

传统的 HTTP 通信方式有一些局限性，尤其在需要低延迟、实时通信的场景下，WebSocket 具有显著优势：

# (1) HTTP 的局限性

请求-响应模式：HTTP 是单向的，客户端必须发起请求，服务器才能响应，服务器无法主动推送数据。
短连接：每次请求都需要新建 TCP 连接，通信开销较大。
轮询（Polling）或长轮询（Long Polling）效率低：
- 轮询：客户端定期向服务器请求更新，导致不必要的网络流量和服务器压力。
- 长轮询：客户端保持 HTTP 连接不关闭，等待服务器返回数据，但仍然存在重复请求的开销。

# (2) WebSocket 的优势

双向通信：服务器和客户端可以随时相互发送数据，不受请求-响应限制，适用于实时应用。
低延迟：WebSocket 连接建立后，不需要每次发送数据都建立新的 TCP 连接，减少网络开销，提高响应速度。
减少服务器压力：相比轮询，大幅减少无效请求，降低服务器负载，提高性能。
更轻量的数据传输：WebSocket 采用二进制数据帧格式（最小头部仅 2 字节），相比 HTTP 头部（通常 200B 以上）要小得多，节省带宽。

# 8.3 WebSocket 与 HTTP 的核心区别

特性	HTTP	WebSocket
连接方式	短连接（每次请求都需要新建 TCP 连接，使用完即关闭）	长连接（建立连接后，客户端与服务器保持通信）
通信模式	请求-响应模式（客户端请求，服务器响应，单向通信）	全双工通信（客户端和服务器可随时相互发送数据）
数据格式	纯文本（如 JSON、HTML）	二进制帧格式（支持文本和二进制数据）
头部开销	每次请求都需要完整的 HTTP 头部（通常几百字节）	连接建立后，数据帧格式轻量（头部仅 2~14 字节）
适用场景	普通网页加载、REST API、静态资源请求等	实时聊天、股票推送、在线游戏等需要低延迟的应用
服务器推送	需要轮询或长轮询（如 SSE）	服务器可主动推送消息给客户端

# 8.4 WebSocket 与 Socket，避免误解！

很多人会混淆 WebSocket 和 Socket，但它们完全不同：

Socket 是网络通信的底层抽象，是操作系统提供的 API，用于进程间通信（如 TCP、UDP）。
WebSocket 是基于 TCP 的高级协议，它利用 HTTP 进行握手，但实现了全双工通信，适用于 Web 端。

总结：WebSocket 依赖 HTTP 握手，但与 HTTP 通信方式完全不同。同时，WebSocket 不是 Socket，Socket 是更底层的概念，WebSocket 只是基于它的应用协议！

# 9. IP协议的定义和作用

IP协议（Internet Protocol）是用于在计算机网络中传输数据包的协议。它定义了数据包的格式和处理规则，确保数据能够从源设备传输到目标设备，通常需要跨越多个中间网络设备（如路由器）。

IP协议的作用：

寻址：每个连接到网络的设备都有一个唯一的IP地址。IP协议使用这些地址来标识数据包的源地址和目的地址，确保数据能够准确地传输到目标设备。
路由：IP协议负责决定数据包在网络中的传输路径。网络中的路由器通过路由表和IP地址信息来确定数据包的最佳路径。
分片与重组：当数据包过大，无法通过某些网络传输时，IP协议会将数据包分成较小的片段进行传输。接收方根据头部信息重组这些片段，恢复出原始的数据包。

举例说明：

假设设备A（IP地址为192.168.1.1）和设备B（IP地址为203.0.113.5）通过互联网通信，数据包的传输过程如下：

设备A发送数据包：
- 设备A创建IP数据包，源地址为192.168.1.1，目的地址为203.0.113.5，将数据封装到数据部分。
- 数据包通过设备A的网络发送至路由器。
路由器转发数据包：
- 路由器查看路由表，根据目的地址203.0.113.5选择数据包的传输路径。
- 数据包经过多个路由器，每个路由器根据路由表确定下一跳，直到到达目标网络。
设备B接收数据包：
- 设备B接收数据包，验证数据包的完整性。
- 提取数据部分并交给上层协议（如TCP或UDP）处理。

# 10. IP地址的分类

IP地址用于标识网络中的设备，它分为五大类：A类、B类、C类、D类、E类。

A类地址（1~126）：
- 以0开头，网络号占前8位，主机号占后24位。
- 地址范围：1.0.0.0 - 126.0.0.0。
- A类地址适用于大规模网络。
B类地址（128~191）：
- 以10开头，网络号占前16位，主机号占后16位。
- 地址范围：128.0.0.0 - 191.255.255.255。
- B类地址适用于中等规模网络。
C类地址（192~223）：
- 以110开头，网络号占前24位，主机号占后8位。
- 地址范围：192.0.0.0 - 223.255.255.255。
- C类地址适用于小型网络。
D类地址（224~239）：
- 以1110开头，用于多播地址，支持组播通信。
- 地址范围：224.0.0.0 - 239.255.255.255。
E类地址（240~255）：
- 以1111开头，保留地址，未来可能用于特殊用途。
- 地址范围：240.0.0.0 - 255.255.255.255。

# 11. 计算机网络讲解：设备是如何通信的？

在互联网中，设备是如何相互找到对方并进行通信的呢？

MAC地址是用来在局域网内确定目的地设备的物理地址，而IP地址是用来确定目标设备的网络地址

数据在网络中传输时，会按照OSI模型的层次进行封装：

+------------------------+
| 应用层数据 (Payload)    |
+------------------------+
| 传输层头部 (TCP/UDP)    |
+------------------------+
| 网络层头部 (IP)         |
+------------------------+
| 数据链路层头部 (MAC)    |
+------------------------+
| 物理层比特流           |
+------------------------+

1
2
3
4
5
6
7
8
9
10
11

每一层都添加自己的头部信息：

MAC头部：包含源MAC地址和目标MAC地址
IP头部：包含源IP地址和目标IP地址，以及TTL（生存时间）等信息
TCP/UDP头部：包含源端口和目标端口等信息
应用层数据：实际传输的内容

# 11.1 MAC 地址（物理地址）

定义：网卡的全球唯一硬件标识符，长度为48位（6字节），通常以十六进制表示（如 00:1A:2B:3C:4D:5E）
特点：由制造商分配，理论上终身不变
层级：工作在数据链路层（OSI模型第2层）
范围：仅在同一局域网内有效

# 11.2 IP 地址（逻辑地址）

定义：网络层的设备标识符，IPv4为32位（4字节），IPv6为128位（16字节）
特点：可以手动配置或自动分配，可以更改
层级：工作在网络层（OSI模型第3层）
范围：全局有效，用于跨网络通信

# 12. 网络通信设备的演进

# 12.1 早期网络（共享介质时代）

总线拓扑结构：所有设备共享一条通信线路
MAC地址的引入：为了在共享介质上区分设备，每个网卡都有唯一的MAC地址
广播通信：发送方广播数据包，所有设备都能收到，但只有目标MAC地址匹配的设备才处理

# 12.2 局域网发展

交换机的引入：替代了早期的集线器，可以根据MAC地址进行转发决策
交换机的工作原理：
- 维护MAC地址表，记录端口与MAC地址的对应关系
- 根据目标MAC地址进行转发，而不是像集线器那样盲目广播
- 仅在局域网内工作，不处理IP地址

# 12.3 网络互联

路由器的出现：连接不同网络的设备
IP地址的引入：为了解决跨网络通信的问题，需要一个网络层的地址系统
路由器的功能：
- 维护路由表，决定数据包的转发路径
- 连接不同的网络（如LAN和WAN）
- 实现网络地址转换（NAT）

# 13. 通信过程详解

# 13.1 局域网内通信

当两台设备在同一局域网内通信时：

发送方知道目标IP地址，但需要知道目标MAC地址
发送ARP请求广播："谁拥有IP地址192.168.1.2？请回复你的MAC地址"
目标设备回复ARP响应："我的IP是192.168.1.2，MAC地址是00:1B:2C:3D:4E:5F"
发送方构建数据包，填入目标MAC地址和IP地址
交换机根据目标MAC地址将数据包转发给目标设备

# 13.2 跨网络通信

当通信需要跨越多个网络（如访问互联网）时：

发送方检查目标IP是否在同一网段
如果不在同一网段，发送方将数据包发送给默认网关（路由器）
路由器移除原始MAC头部，添加新的MAC头部（下一跳的MAC地址）
数据包经过多个路由器转发，每一跳都会更新MAC头部
IP头部在整个过程中保持不变（除非经过NAT）
最终路由器将数据包发送到目标网络，目标设备接收数据包

# 14.网络地址转换技术（NAT）

NAT技术允许多台设备共享一个公网IP地址，解决了IPv4地址短缺的问题：

# 14.1 SNAT（源地址转换）

作用：将内部私有IP地址转换为公共IP地址
原理：
- 内网设备（如192.168.1.2:3456）发送数据包到互联网
- 路由器将源IP:端口（192.168.1.2:3456）转换为公网IP:端口（203.0.113.1:5678）
- 外部服务器回复数据包到203.0.113.1:5678
- 路由器查询NAT表，将目标IP:端口转换回192.168.1.2:3456
应用：家庭网络、企业网络上网

# 14.2 DNAT（目标地址转换）

作用：将公网IP地址的特定端口映射到内网设备
原理：
- 外部请求访问公网IP:端口（203.0.113.1:80）
- 路由器将目标IP:端口转换为内网IP:端口（192.168.1.3:80）
- 内网服务器处理请求并回复
- 路由器将源IP:端口转换为公网IP:端口
应用：内网服务器外部访问、远程桌面连接、P2P通信

# 15. DHCP 协议（动态主机配置协议）

DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）是一种自动分配 IP 地址的协议，让设备连接网络时无需手动设置 IP 地址、子网掩码、网关等信息。

# 15.1 DHCP 工作流程

DHCP 采用客户端-服务器模式，工作流程如下：

发现（Discover）：客户端广播请求 IP 地址。
提供（Offer）：DHCP 服务器响应，提供一个可用的 IP 地址。
请求（Request）：客户端向服务器确认使用这个 IP 地址。
确认（ACK）：服务器确认分配，客户端成功获取 IP 地址。

🚀 示例：当手机连接 Wi-Fi 时，路由器作为 DHCP 服务器，自动分配 IP 地址给手机。

# 15.2 DHCP 作用

自动分配 IP，减少手动配置工作量。
避免 IP 地址冲突，服务器统一管理 IP 资源。
支持地址租约，定期更新 IP，防止 IP 资源耗尽。

# 15.3 DHCP 中继（DHCP Relay）

如果 DHCP 服务器不在同一网段，路由器可以充当 DHCP 中继代理，将 DHCP 请求转发到远程服务器。

# 16. ARP 协议与 ARP 攻击

ARP（Address Resolution Protocol，地址解析协议）用于在局域网内解析 IP 地址对应的 MAC 地址。

# 16.1 ARP 工作原理

设备 A 发送广播：
- “谁是 192.168.1.1？请告诉我你的 MAC 地址。”
设备 B（192.168.1.1）响应：
- “我是 192.168.1.1，我的 MAC 地址是 AA:BB:CC:DD:EE:FF。”
设备 A 记录这个 IP-MAC 对应关系，并用它进行数据通信。

# 16.2 ARP 表

设备会维护一个 ARP 缓存表，存储最近解析的 IP-MAC 地址映射，减少网络查询开销。

# 16.3 ARP 攻击

由于 ARP 没有身份认证，黑客可以伪造 ARP 响应，导致：

ARP 欺骗（ARP Spoofing）：黑客伪装成网关，让流量经过自己，进行中间人攻击（MITM）。
ARP 洪泛（ARP Flooding）：发送大量 ARP 请求，导致交换机的 ARP 表溢出，影响网络通信。

# 16.4 防御 ARP 攻击

静态 ARP 绑定：手动指定 IP-MAC 绑定，防止篡改。
ARP 监控：使用防火墙或安全软件检测异常 ARP 流量。
VLAN 隔离：限制不同网络之间的 ARP 广播，提高安全性。

# 17. ICMP 协议（互联网控制报文协议）

ICMP（Internet Control Message Protocol，互联网控制报文协议）用于网络设备之间传递诊断和错误信息，它是 IP 协议的辅助协议。

# 17.1 ICMP 常见应用

Ping（回显请求和回复）：测试目标 IP 是否可达。
Traceroute（路由跟踪）：检查数据包经过的路径。
目标不可达消息：当目标主机或端口不可达时返回错误信息。
超时消息：TTL（生存时间）为 0 时，返回超时报文。

# 17.2 ICMP 攻击

ICMP 泛洪（Ping Flood）：大量 Ping 请求导致目标设备过载。
Smurf 攻击：伪造源 IP，向广播地址发送 Ping，导致目标设备收到大量回复数据包。
ICMP 重定向攻击：伪造 ICMP 重定向消息，引导流量到恶意主机。

# 17.3 防御 ICMP 攻击

限制 Ping 速率：防止 ICMP 泛洪攻击。
关闭不必要的 ICMP 功能：减少被攻击面。
使用防火墙过滤 ICMP：阻止恶意 ICMP 报文进入网络。

# 18. GET和POST的区别

GET和POST是HTTP协议中最常用的两种请求方法，它们在设计和使用上有显著差异。以下是详细对比：

特性	GET请求	POST请求
定义和用途	用于从服务器获取资源，幂等，无副作用	用于向服务器发送数据，可能改变状态，非幂等
参数传递方式	参数通过URL的查询字符串传递，例如`?key=value`	参数通过请求体传递，通常为JSON或表单数据
可见性	参数在URL中可见，适合非敏感信息	参数在请求体中不可见，适合敏感信息
缓存	可被浏览器和服务器缓存，适合重复访问	通常不缓存，但若幂等可缓存
长度限制	受URL长度限制，通常约2000字符	无长度限制，适合大数据传输
安全性	不适合传输敏感信息，URL可能被记录	更安全，适合传输密码等敏感数据
典型使用场景	获取网页、图片、搜索结果	提交表单、上传文件、创建资源

注意事项：

GET请求理论上可以包含请求体，但这不是标准实践，大多数服务器和框架会忽略GET的请求体。
POST请求也可以在URL中携带参数，但这不常见，通常参数通过请求体传递。

# 19. HTTP协议的发展历史

HTTP（超文本传输协议）是互联网上最常用的应用层协议，用于浏览器和服务器之间的通信。其发展历程如下：

HTTP/0.9（1991）：最初版本，只支持GET请求，用于传输纯文本内容。
HTTP/1.0（1996）：引入请求头、响应头、状态码，支持多种内容类型。
HTTP/1.1（1997）：引入持久连接（persistent connections），允许多个请求复用同一个TCP连接，提高性能。还增加了缓存机制和管道化（pipelining）。
HTTP/2（2015）：基于SPDY协议，引入多路复用（multiplexing）、头部压缩（header compression）和服务器推送（server push），显著提升性能。
HTTP/3（2020）：基于QUIC协议，使用UDP代替TCP，提供更低的延迟和更高的安全性。

HTTP的发展反映了Web技术的不断演进，从简单的文本传输到支持复杂的多媒体和高性能通信。

# 20. RPC（远程过程调用）与HTTP的关系

RPC是一种允许程序在远程服务器上执行过程的机制，历史可以追溯到20世纪80年代，比HTTP（90年代初）更早。以下是RPC与HTTP的对比和共存关系：

RPC的发展：
RPC最初用于分布式系统中的客户端-服务器（C/S）架构，允许程序通过网络调用远程函数。早期的RPC协议包括Sun RPC（1986）、XML-RPC、JSON-RPC等。现代RPC框架如gRPC和Thrift广泛用于微服务通信。
HTTP vs RPC：
- HTTP：主要用于浏览器-服务器（B/S）架构，是Web通信的标准协议，设计初衷是资源传输和操作。
- RPC：更通用，适用于任何分布式系统，不限于Web。RPC可以基于多种传输协议（如TCP、UDP），而HTTP通常基于TCP。
为什么两者共存？
- HTTP是为Web设计的标准协议，适合外部API和Web服务。
- RPC用于内部高性能通信，尤其在微服务架构中，适合低延迟、高吞吐量的场景。
- 现代系统中，B/S和C/S架构的界限逐渐模糊，许多应用同时支持Web端和移动端，使用HTTP对外通信，使用RPC对内通信。

历史背景与共存原因

HTTP的出现（90年代初）晚于RPC（80年代），这与互联网的发展阶段有关：

在HTTP出现之前，TCP/IP协议已经存在，但缺乏统一的应用层协议，各公司开发了自己的通信协议，RPC作为通用远程调用机制填补了这一空白。
HTTP是为Web设计的，解决了浏览器与服务器的通信需求，成为B/S架构的标准。
RPC则更多用于C/S架构和公司内部分布式系统，随着微服务架构的兴起，RPC在内部通信中仍占重要地位。

例如，许多公司使用HTTP/RESTful API对外提供服务，而在内部集群中使用gRPC进行微服务间的通信。这种分层设计提高了效率和可维护性。

编辑

上次更新: 2025/04/20, 07:45:33

← 设计模式锁核心类AQS→