计算机网络

网络模型（20260319）

1.网络OSI模型和TCP/IP模型

OSI7层模型

OSI 七层模型 是国际标准化组织提出一个网络分层模型，其大体结构以及每一层提供的功能如下图所示：

TCP/IP模型

TCP/IP 四层模型 是目前被广泛采用的一种模型,我们可以将 TCP / IP 模型看作是 OSI 七层模型的精简版本，由以下 4 层组成：

应用层：应用层位于传输层之上，主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。 我们把应用层交互的数据单元称为报文。
传输层

传输层的主要任务就是负责向两台终端设备进程之间的通信提供通用的数据传输服务。 应用进程利用该服务传送应用层报文。"通用的"是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。
网络层

网络层负责为分组交换网上的不同主机提供通信服务。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。网络层的还有一个任务就是选择合适的路由，使源主机运输层所传下来的分组，能通过网络层中的路由器找到目的主机。
网络接口层

可以把网络接口层看作是数据链路层和物理层的合体。

数据链路层(data link layer)通常简称为链路层（两台主机之间的数据传输，总是在一段一段的链路上传送的）。数据链路层的作用是将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异

应用层

1.HTTP

1.1 HTTP的报文结构

分请求报文和响应报文来说明。.

请求报文：

请求行：包含请求方法、请求目标（URL或URI）和HTTP协议版本。
请求头部：包含关于请求的附加信息，如Host、User-Agent、Content-Type等。
空行：请求头部和请求体之间用空行分隔。
请求体：可选，包含请求的数据，通常用于POST请求等需要传输数据的情况。

响应报文：

状态行：包含HTTP协议版本、状态码和状态信息。
响应头部：包含关于响应的附加信息，如Content-Type、Content-Length等。
空行：响应头部和响应体之间用空行分隔。
响应体：包含响应的数据，通常是服务器返回的HTML、JSON等内容。

1.2 HTTP常用的状态码

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。
2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。
- 200：请求成功
3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。
- 301：永久重定向；302：临时重定向；
4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。
- 404：无法找到此页面；405：请求的方法类型不支持
5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。
- 500：服务器内部出错
- 502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
- 504 Gateway Time-out：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器收到响应。

1.3 HTTP层请求的类型

GET：用于请求获取指定资源，通常用于获取数据。

POST：用于向服务器提交数据，通常用于提交表单数据或进行资源的创建。

PUT：用于向服务器更新指定资源，通常用于更新已存在的资源。

DELETE：用于请求服务器删除指定资源。

HEAD：类似于GET请求，但只返回资源的头部信息，用于获取资源的元数据而不获取实际内容。

1.4HTTP1.0,HTTP1.1,HTTP2

HTTP1.0

是无状态、无连接的协议。每次请求都需要建立一个新的 TCP 连接，服务器处理完请求后立即断开连接。（HTTP短连接）

HTTP1.1

长连接 ：默认启用 Connection: keep-alive，允许在一个 TCP 连接中传输多个请求和响应，减少了连接建立和断开的开销。

新增功能：支持分块传输（Chunked Transfer Encoding）、断点续传（Range 请求）、Host 头字段（支持虚拟主机）等。

半双工的协议；当需要服务器主动推送数据到客户端的场景，使用WebSocket协议

HTTP2.0

通过并发传输（Stream）、二进制分帧（不是纯文本形式的报文，全是二进制格式）和头部压缩（维护一张头信息表，用索引号代替字段）等技术，彻底解决了队头阻塞

1.5HTTPS

HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。默认端口是443

本质上是加密的传输一个对话秘钥，这个密钥可以用公钥加密，私钥解密进行传输，但是传输过程中，公钥可能被篡改

为了防止信息被篡改，用私钥加密，公钥解密做数字签名，但是用作验签的公钥也可能被篡改，所以找一个第三方权威机构（CA）

TLS 第一次握手

客户端主要向服务器发送以下信息：

（1）客户端支持的 TLS 协议版本，如 TLS 1.2 版本。
（2）客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一
（3）客户端支持的密码套件列表，如 RSA 加密算法。

TLS 第二次握手

服务器回应的内容有如下内容：

（1）确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。
（2）服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一
（3）确认的密码套件列表，如 RSA 加密算法。（4）服务器的数字证书。（CA的私钥对服务器公钥进行加密）

TLS 第三次握手

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。
（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

TLS 第四次握手

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。

然后，向客户端发送最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

1.6 HTTP进行TCP连接之后，在什么情况下会中断

当服务端或者客户端执行 close 系统调用的时候，会发送FIN报文，就会进行四次挥手的过程
当发送方发送了数据之后，接收方超过一段时间没有响应ACK报文，发送方重传数据达到最大次数的时候，就会断开TCP连接
当HTTP长时间没有进行请求和响应的时候，超过一定的时间，就会释放连接

session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session，依赖cookie。(有状态，需要存储到服务器)

cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。

token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户，需要开发者手动添加。（分布式，无状态）

1.8 JWT

JWT令牌由三个部分组成：头部（Header）、载荷（Payload）和签名（Signature）。其中，头部和载荷均为JSON格式，使用Base64编码进行序列化，而签名部分是对头部、载荷和密钥进行签名后的结果

JWT的优点：分布式，无状态，服务器端无需存储会话信息

缺点：一旦派发出去，在失效之前都是有效的，没办法即使撤销JWT。可以添加黑名单

2.DNS

2.1DNS概述

DNS的全称是Domain Name System（域名系统），它是互联网中用于将域名转换为对应IP地址的分布式数据库系统。

2.2DNS 域名解析的工作流程？

3.Nginx的负载均衡算法

轮询：按照顺序依次将请求分配给后端服务器。这种算法最简单，但是也无法处理某个节点变慢或者客户端操作有连续性的情况。
IP哈希：根据客户端IP地址的哈希值来确定分配请求的后端服务器。适用于需要保持同一客户端的请求始终发送到同一台后端服务器的场景，如会话保持。
URL哈希：按访问的URL的哈希结果来分配请求，使每个URL定向到一台后端服务器，可以进一步提高后端缓存服务器的效率。
最短响应时间：按照后端服务器的响应时间来分配请求，响应时间短的优先分配。适用于后端服务器性能不均的场景，能够将请求发送到响应时间快的服务器，实现负载均衡。
加权轮询：按照权重分配请求给后端服务器，权重越高的服务器获得更多的请求。适用于后端服务器性能不同的场景，可以根据服务器权重分配请求，提高高性能服务器的利用率。

TCP

1.TCP头部格式

2.三次握手

第一次握手 客户端随机生成一个初始序列号（client_isn ），将其放入 TCP 报文的序号字段，并将 SYN 标志位置为 1，表示发起连接请求。此时，客户端进入 SYN-SENT 状态。（不包含应用层数据）
第二次握手 服务端收到客户端的 SYN 报文后，也随机生成一个初始序列号（server_isn ），并将其放入序号字段。同时，将确认号字段设置为 client_isn + 1 ，并将 SYN 和 ACK 标志位置为 1，表示确认客户端的请求并发起自己的连接请求。此时，服务端进入 SYN-RCVD 状态。（不包含应用层数据）
第三次握手 客户端收到服务端的 SYN+ACK 报文后，发送一个 ACK 报文作为确认。此报文的确认号字段设置为 server_isn + 1 ，并可以携带数据。此时，客户端进入 ESTABLISHED 状态。（可以携带数据）

3.为什么要三次握手？

三次握手才可以阻止重复历史连接的初始化（主要原因）

有两次确认，确保双方是针对同一个syn包建立的链接
三次握手才可以同步双方的初始序列号
三次握手才可以避免资源浪费

跟第一条类似

4.TCP 三次握手，数据包丢失时会发生什么

第一次握手丢失：客户端超时重传，有最大重传次数，每次超时重传时间是上次的二倍

第二次握手丢失：这个数据包既是对第一次客户端syn数据的响应，同时它又期待客户端第三次握手的确认。所以服务器和客户端都会超时重传

第三次握手丢失：服务器超时重传

本质上超时重传是由于syn的发送方在一定时间内没有得到对方的ack响应导致的

5.第一次握手，客户端发送SYN报后，服务端回复ACK报，那这个过程中服务端内部做了哪些工作？

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。

6. 大量SYN包发送给服务端服务端会发生什么事情？

有可能会导致TCP 半连接队列打满，这样当 TCP 半连接队列满了，后续再在收到 SYN 报文就会丢弃，导致客户端无法和服务端建立连接。

避免 SYN 攻击方式，可以有以下四种方法：

调大网卡接收队列；
增大 TCP 半连接队列；
开启 tcp_syncookies；可以在不使用 SYN 半连接队列的情况下成功建立连接
减少 SYN-ACK 重传次数

7.四次挥手

客户端主动调用关闭连接的函数，于是就会发送 FIN 报文，这个 FIN 报文代表客户端不会再发送数据了，进入 FIN_WAIT_1 状态；

服务端收到了 FIN 报文，然后马上回复一个 ACK 确认报文，此时服务端进入 CLOSE_WAIT 状态。在收到 FIN 报文的时候，TCP 协议栈会为 FIN 包插入一个文件结束符 EOF 到接收缓冲区中，服务端应用程序可以通过 read 调用来感知这个 FIN 包，这个 EOF 会被放在已排队等候的其他已接收的数据之后，所以必须要得继续 read 接收缓冲区已接收的数据；

接着，当服务端在 read 数据的时候，最后自然就会读到 EOF，接着 read() 就会返回 0，这时服务端应用程序如果有数据要发送的话，就发完数据后才调用关闭连接的函数，如果服务端应用程序没有数据要发送的话，可以直接调用关闭连接的函数，这时服务端就会发一个 FIN 包，这个 FIN 报文代表服务端不会再发送数据了，之后处于 LAST_ACK 状态；

客户端接收到服务端的 FIN 包，并发送 ACK 确认包给服务端，此时客户端将进入 TIME_WAIT 状态；

服务端收到 ACK 确认包后，就进入了最后的 CLOSE 状态；

客户端经过 2MSL 时间之后，也进入 CLOSE 状态；

8.第二次和第三次挥手能合并嘛

当被动关闭方在 TCP 挥手过程中，「没有数据要发送」并且「开启了 TCP 延迟确认机制」，那么第二和第三次挥手就会合并传输，这样就出现了三次挥手

9.超时问题

第一次挥手没有被响应：客户端会触发超时重传机制，如果超过一定次数，就直接关闭

第三次挥手没有发送：如果连接是用 shutdown 函数关闭的，连接可以一直处于 FIN_WAIT2 状态，因为它可能还可以发送或接收数据。但对于 close 函数关闭的孤儿连接，由于无法再发送和接收数据，所以这个状态不可以持续太久，而 tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒：

10.为什么客户端要等待2MSL时间再关闭

如果被动关闭方没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方，一来一去正好 2 个 MSL。

可以看到 2MSL时长这其实是相当于至少允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样被动方重发的 FIN 会在第 2 个 MSL 内到达，TIME_WAIT 状态的连接可以应对。

11.服务端出现大量的timewait有哪些原因?

（1）http没有使用长连接，一个请求需要一次TCP建立和关闭

（2）HTTP启用长连接，大量客户端建立完TCP连接后，很长一段时间没有发送数据，由于超时关闭

（3）HTTP长连接的请求数量达到上限

12.TCP和UDP的区别

连接：TCP 是面向连接的传输层协议，传输数据前先要建立连接；UDP 是不需要连接，即刻传输数据。
服务对象：TCP 是一对一的两点服务，即一条连接只有两个端点。UDP 支持一对一、一对多、多对多的交互通信
可靠性：TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按序到达。UDP 是尽最大努力交付，不保证可靠交付数据。但是我们可以基于 UDP 传输协议实现一个可靠的传输协议，比如 QUIC 协议
拥塞控制、流量控制：TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。
首部开销：TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。UDP 首部只有 8 个字节，并且是固定不变的，开销较小。
传输方式：TCP 是流式传输，没有边界，但保证顺序和可靠。UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

13.TCP为什么可靠传输？

连接管理：即三次握手和四次挥手。连接管理机制能够建立起可靠的连接，这是保证传输可靠性的前提。
序列号：TCP将每个字节的数据都进行了编号，这就是序列号。序列号的具体作用如下：能够保证可靠性，既能防止数据丢失，又能避免数据重复。能够保证有序性，按照序列号顺序进行数据包还原。能够提高效率，基于序列号可实现多次发送，一次确认。
确认应答：接收方接收数据之后，会回传ACK报文，报文中带有此次确认的序列号，用于告知发送方此次接收数据的情况。在指定时间后，若发送端仍未收到确认应答，就会启动超时重传。
超时重传：超时重传主要有两种场景：数据包丢失：在指定时间后，若发送端仍未收到确认应答，就会启动超时重传，向接收端重新发送数据包。确认包丢失：当接收端收到重复数据(通过序列号进行识别)时将其丢弃，并重新回传ACK报文。
流量控制：接收端处理数据的速度是有限的，如果发送方发送数据的速度过快，就会导致接收端的缓冲区溢出，进而导致丢包。为了避免上述情况的发生，TCP支持根据接收端的处理能力，来决定发送端的发送速度。这就是流量控制。流量控制是通过在TCP报文段首部维护一个滑动窗口来实现的。
拥塞控制：拥塞控制就是当网络拥堵严重时，发送端减少数据发送。拥塞控制是通过发送端维护一个拥塞窗口来实现的。可以得出，发送端的发送速度，受限于滑动窗口和拥塞窗口中的最小值。拥塞控制方法分为：慢开始，拥塞避免、快重传和快恢复。

14.TCP粘包如何解决？

TCP 是字节流协议，不是消息边界协议

固定长度的消息；

这种是最简单方法，即每个用户消息都是固定长度的，比如规定一个消息的长度是 64 个字节，当接收方接满 64 个字节，就认为这个内容是一个完整且有效的消息。
特殊字符作为边界；

在两个用户消息之间插入一个特殊的字符串，这样接收方在接收数据时，读到了这个特殊字符，就把认为已经读完一个完整的消息。
自定义消息结构。

自定义一个消息结构，由包头和数据组成，其中包头包是固定大小的，而且包头里有一个字段来说明紧随其后的数据有多大。

15.TCP的流量控制？

为了解决发送方和接收方速度不同而导致的数据丢失问题,当发送方发送的太快,接收方来不及接受就会导致数据丢失；

由接收端采用滑动窗口的形式，告知发送方允许/停止发包解决TCP丢包问题。

（1）接收端主机向发送端主机通知自已可以接收数据的大小；

（2）于是发送端会发送不超过这个限度的数据，该大小限度就被称作窗口大小。窗口大小的值由接收端主机决定，而在TCP 首部中，专门有一个字段用来通知窗口大小：

（3）接收主机将自己可以接收的缓冲区大小放入这个字段中通知给发送端，这个字段的值越大，说明网络的吞吐量越高。

16.TCP的拥塞控制？

为了解决过多的数据注入到网络导致网络崩溃和超负荷问题；

由发送方采用拥塞窗口的形式去判断网络状态，从而采取不同算法执行TCP动态发包解决网络整体质量问题。

拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。

**慢开始门限（ssthresh）：**为了防止拥塞窗口cwnd的增长过大引起网络拥塞所设置的一个门限值。

拥塞窗口 cwnd 变化的规则：

|当cwnd < ssthresh时，使用慢开始算法；
|当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法；
|当cwnd = ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

其实只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

（1）慢开始：发送方先探测网络拥塞程度，并不是一开始就发送大量的数据，发送方会根据拥塞程度增大拥塞窗口cwnd。

计算方法：每经过一个传输轮次cwnd值就加倍，让cwnd值呈指数增加。直到cwnd=ssthresh（每收到一次ACK +1）

（2）拥塞避免：每经过一个传输轮次cwnd值加1，让cwnd值呈线性缓慢增大。（每收到一次ACK +1/cwnd）

（3）拥塞发生：当网络出现拥塞，也就是会发生数据包重传

超时重传：ssthresh 设为 cwnd/2，cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1），就重新开始慢启动

快速重传和快速恢复：

当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。

则 ssthresh 和 cwnd 变化如下：cwnd = cwnd/2 ，也就是设置为原来的一半;ssthresh = cwnd;进入快速恢复算法

拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
重传丢失的数据包；
如果再收到重复的 ACK，那么 cwnd 增加 1；
如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；

网络场景

1.描述一下打开百度首页后发生的网络过程

解析URL：分析 URL 所需要使用的传输协议和请求的资源路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，则对非法字符进行转义后在进行下一过程。
缓存判断：浏览器缓存 → 系统缓存（hosts 文件） → 路由器缓存 → ISP 的 DNS 缓存，如果其中某个缓存存在，直接返回服务器的IP地址。
DNS解析：如果缓存未命中，浏览器向本地 DNS 服务器发起请求，最终可能通过根域名服务器、顶级域名服务器（.com）、权威域名服务器逐级查询，直到获取目标域名的 IP 地址。
获取MAC地址：当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相结合，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 ARP 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。
建立TCP连接：主机将使用目标 IP地址和目标MAC地址发送一个TCP SYN包，请求建立一个TCP连接，然后交给路由器转发，等路由器转到目标服务器后，服务器回复一个SYN-ACK包，确认连接请求。然后，主机发送一个ACK包，确认已收到服务器的确认，然后 TCP 连接建立完成。
HTTPS 的 TLS 四次握手：如果使用的是 HTTPS 协议，在通信前还存在 TLS 的四次握手。
发送HTTP请求：连接建立后，浏览器会向服务器发送HTTP请求。请求中包含了用户需要获取的资源的信息，例如网页的URL、请求方法（GET、POST等）等。
服务器处理请求并返回响应：服务器收到请求后，会根据请求的内容进行相应的处理。例如，如果是请求网页，服务器会读取相应的网页文件，并生成HTTP响应。
ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。
建立TCP连接：主机将使用目标 IP地址和目标MAC地址发送一个TCP SYN包，请求建立一个TCP连接，然后交给路由器转发，等路由器转到目标服务器后，服务器回复一个SYN-ACK包，确认连接请求。然后，主机发送一个ACK包，确认已收到服务器的确认，然后 TCP 连接建立完成。
HTTPS 的 TLS 四次握手：如果使用的是 HTTPS 协议，在通信前还存在 TLS 的四次握手。
发送HTTP请求：连接建立后，浏览器会向服务器发送HTTP请求。请求中包含了用户需要获取的资源的信息，例如网页的URL、请求方法（GET、POST等）等。
服务器处理请求并返回响应：服务器收到请求后，会根据请求的内容进行相应的处理。例如，如果是请求网页，服务器会读取相应的网页文件，并生成HTTP响应。