计算机网络

• 从输入一个URL到页面加载完成的过程
  • 整体流程
    • DNS查询过程
    • SSL四次握手
    • HTTP 的长连接与短连接
  • HTTP 的 GET 和 POST 区别
  • 浏览器访问资源没有响应，怎么排查?
• OSI七层参考模型
  • TCP/IP四层参考模型
  • 比较 TCP/IP 参考模型与 OSI 参考模型
• TCP三次握手&四次挥手
  • TCP标志位
  • TCP序列号、确认号
  • 三次握手
    • 三次握手过程
    • 为什么不是两次握手？
    • 为什么不是四次握手？
  • 为什么超时重传？如何处理丢包
    • 为什么需要超时重传?
    • 如何处理丢包？
  • 四次挥手
    • 四次挥手过程
    • 为什么需要四次挥手
    • 为什么四次挥手，客户端的TIME-WAIT状态必须等待2MSL的时间，才能返回到CLOSED状态
  • 如果已经建立了连接，但是客户端出现故障了怎么办？
  • 使用tcpdump抓包分析
    • 操作
• 子网掩码的作用
• ABC类网络
• TCP和UDP区别

不会就强调“在同一内网下”

从输入一个url到页面加载完成的过程

整体流程

1、用户在某个标签页输入 URL 并回车后，浏览器主进程会新开一个网络线程，发起 HTTP 请求
2、浏览器会进行 DNS 查询，将域名解析为 IP 地址
3、浏览器获得 IP 地址后，向服务器请求建立 TCP 连接
4、浏览器向服务器发起 HTTP 请求
5、服务器处理请求，返回 HTTP 响应
6、浏览器的渲染进程解析并绘制页面
7、如果遇到 JS/CSS/图片 等静态资源的引用链接，重复上述过程，向服务器请求这些资源

DNS查询过程

DNS 是应用层的协议，作用是将域名转化为 IP，以供传输层建立 TCP 连接。

整体流程：浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地DNS 服务器进行查询等。

SSL四次握手

SSL 位于传输层和应用层之间，TCP 和 HTTP 之间。SSL 协议的目的是，为通信双方提供一种在不安全的网络环境中，安全地协商一个密钥的方法。

SSL 实现的核心是非对称式密码学。非对称密码包含两个部分：公钥和私钥，一个用作加密，另一个则用作解密。使用其中一个密钥把明文加密后所得的密文，只能用相对应的另一个密钥才能解密得到原本的明文；甚至连最初用来加密的密钥也不能用作解密。

HTTPS 本质上就是 HTTP + SSL。通过 SSL 四次握手过程，客户端和服务端会商定一个共同的随机密钥，用来对称加密。握手结束后，双方都会使用这个约定的随机密钥来加密、解密会话内容，使用的完全是普通的 HTTP 协议。

HTTP 的长连接与短连接

HTTP/1.0 默认使用的是短连接。也就是说，浏览器每请求一个静态资源，就建立一次连接，任务结束就中断连接。

HTTP/1.1 默认使用的是长连接。长连接是指在一个网页打开期间，所有网络请求都使用同一条已经建立的连接。当没有数据发送时，双方需要发检测包以维持此连接。长连接不会永久保持连接，而是有一个保持时间。实现长连接要客户端和服务端都支持长连接。

长连接的优点：TCP 三次握手时会有 1.5 RTT 的延迟，以及建立连接后慢启动（slow-start）特性，当请求频繁时，建立和关闭 TCP 连接会浪费时间和带宽，而重用一条已有的连接性能更好。

长连接的缺点：长连接会占用服务器的资源。

HTTP 的 GET 和 POST 区别

特性	GET	POST
用途	获取数据	提交数据
数据传输	数据附加在 URL 后	数据在请求体中
数据长度	受 URL 长度限制（通常 2000 字符以内）	没有严格限制
缓存	可缓存	不缓存
历史记录	被记录在浏览器历史中	不会出现在浏览器历史中
数据可见性	数据暴露在 URL 中	数据不暴露在 URL 中
安全性	不适合传输敏感数据	相对更安全，但仍需要 HTTPS
幂等性	幂等	非幂等

幂等性指的是同一个操作多次执行，结果和副作用相同。

浏览器访问资源没有响应,怎么排查

1、检查浏览器控制台和网络面板，F12进入开发者模式，查看Console和NetWork是否有错误或失败的请求。

2、检查网络连接，确保 DNS 解析和网络连接正常。

3、检查服务器状态，确保服务器运行正常，并查看日志信息。

4、检查 API 或后端服务，确认服务是否正常。

5、清除浏览器缓存或使用无痕模式。

6、检查跨域问题，确保服务器配置了正确的 CORS 头。

7、检查代理或 VPN 设置，确保没有影响请求。

OSI七层参考模型

层级	名称	主要功能	示例协议
7	应用层	直接为用户提供网络服务	HTTP, FTP, SMTP, DNS
6	表示层	数据格式化、加密、解密、压缩	SSL/TLS, JPEG, GIF, ASCII
5	会话层	管理会话的建立、维持和终止	RPC, NetBIOS, SMB
4	传输层	端到端的数据传输、错误检测与修正	TCP, UDP
3	网络层	路由选择、IP地址寻址、数据包转发	IP, ICMP, ARP, IGMP
2	数据链路层	数据封装、物理地址传输、错误检测	Ethernet, PPP, Frame Relay
1	物理层	比特流传输、硬件接口、物理连接	电缆、光纤、无线信号

TCP/IP四层参考模型

• 网络接入层：对应于 OSI 参考模型的物理层和数据链路层，负责相邻的物理节点间的可靠数据传输。协议包括WI-Fi、PPP等
• 网络层（或网际互联层）：对应于 OSI 参考模型的网络层，主要解决主机到主机的路由问题。协议包括 IP（网际协议，是用于分组交换数据网络的一种协议，功能包括寻址、路由、尽最大努力交付数据包）等
• 传输层：对应于 OSI 参考模型的传输层，为应用层实体提供端到端的、通用的通信功能，保证了数据包的顺序传送及数据的完整性。协议包括 TCP（传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议）、UDP（用户数据报协议，是一个简单的、无连接的、不可靠的、面向数据报的通信协议）等
• 应用层：对应于 OSI 参考模型的应用层，为用户提供所需要的各种服务，是用户与网络之间的接口。协议包括 HTTP（超文本传输协议）、FTP（文件传输协议）、DNS（域名系统，域名和 IP 地址相互映射的分布式数据库）等

比较 TCP/IP 参考模型与 OSI 参考模型

共同点：

• 都采用了层次结构的概念
• 都能够提供面向连接和无连接的通信服务机制

不同点：

• OSI 采用了七层模型，而 TCP/IP 是四层
• OSI 的网络层既提供面向连接的服务，又提供无连接的服务；TCP/IP 的网络层只提供无连接的网络服务

TCP三次握手&四次挥手

TCP标志位

TCP标志位代表当前请求的目的，一共有6种

1、SYN（synchronous）：发送/同步标志，用来建立连接，和ACK标志位搭配使用。A请求与B建立连接时，SYN = 1, ACK = 0;B确认与A建立连接时，SYN=1，ACK=1
2、ACK（acknowledgement）：确认标志，表示确认收到请求
3、PSH（push）：推送操作，就是指数据包到达接收端以后，不对其进行队列处理，而是尽可能的将数据交给应用程序处理
4、FIN（finish）：结束标志，表示关闭一个TCP连接
5、RST（reset）：重制复位标志，用于复位对应的TCP连接
6、URG（urgent）：紧急标志位，用于保证TCP连接不被中断，并且督促中间层设备尽快处理

TCP序列号、确认号

• 作用：TCP 使用序列号来记录发送数据包的顺序。TCP 传送一个数据包后，只有在指定时间里收到这个包的确认信息，才会将其从队列中删除，否则会重新发送该数据包。对接收方而言，通过数据分段中的序列号可以保证数据能够按照正常的顺序进行重组。

三次握手

三次握手过程

图片来源：https://juejin.im/post/5ddd1f30e51d4532c42c5abe

• 第一次握手（SYN）：
  • 客户端向服务端发送一个同步报文（SYN），表示请求建立连接，并告知自己的初始序列号（Seq）
  • 第一次握手主要是为了：服务端确认“自己收、客户端发”报文功能正常
• 第二次握手（SYN + ACK）：
  • 服务端收到客户端的SYN报文后，回复同步确认报文（SYN + ACK），同时指定自己的初始序列号（Seq），并对客户端的序列号进行ACK确认（确认号=客户端的序列号 + 1）
  • 第二次握手主要是为了：客户端确认“自己发、自己收、服务端收、服务端发”报文功能正常，因此客户端认为连接已建立
• 第三次握手（ACK）：
  • 客户端收到服务器的 SYN + ACK 之后，回复一个 ACK 报文，表示自己确认了服务器的 SYN，并对服务器的序列号进行 ACK 确认（确认号 = 服务器的序列号 + 1）。
  • 第三次握手主要是为了：服务端确认“自己发、客户端收”报文功能正常，此时双方都认为连接已建立，TCP 连接正式建立

三次握手可以解决的问题：

1、防止历史连接误触发： 旧的 SYN 可能会因网络问题延迟到达服务器，导致服务器误以为是新的连接，三次握手确保客户端仍在等待通信。

2、确保双方的收发能力都正常： 三次握手能确保双方的 发送能力 和 接收能力 都正常，不会出现服务器单方面认为连接成功的情况。

为什么不是两次握手？

两次握手无法确保客户端和服务器的发送、接收能力都正常，可能会导致旧连接被误认为是新的连接，进而影响数据的可靠性。

假设采用两次握手：
1、客户端发送 SYN（请求建立连接）。
2、服务器收到后，直接返回 SYN + ACK，认为连接建立成功。
3、服务器直接开始发送数据。
4、问题：如果客户端因网络延迟或其他原因没有收到服务器的 SYN + ACK，或者客户端已经关闭，服务器仍然认为连接有效，会导致无效连接或错误数据传输。

为什么不是四次握手？

如果使用四次握手，就会多出一步额外的 ACK 确认报文，但这在建立连接时是不必要的，因为：

• 在第三次握手中，客户端发送的 ACK 已经明确表示它收到了服务器的 SYN + ACK，并准备好通信。
• 服务器只需要确认这个 ACK 是否到达即可，而不需要再发送一个额外的确认报文。

但是，在 TCP 断开连接时，为什么是四次挥手？
断开连接涉及双方数据传输的结束，需要确保双方都不再发送数据，因此需要四次挥手来确保数据彻底传输完毕。

为什么超时重传？如何处理丢包

为什么需要超时重传?

在TCP传输过程中，网络环境肯能会导致数据包丢失或ACK（确认）丢失。为了确保数据能够可靠地传输，TCP采用超时重传机制

1、发送方发送数据后，会开启一个定时器，等待接收方的ACK确认。
2、如果在超时时间内没有收到ACK，发送方会重新发送该数据包。
3、如果仍然没有收到确认，TCP可能会指数退避地延长超时时间，并继续重传（如：RTO值递增）。
4、当达到一定的重传上限后，TCP会认为连接中断，并向应用层报告失败。

超时重传机制保证了即使网络环境不稳定，TCP仍然能够提供可靠的数据传输。

如何处理丢包？

TCP采用超时重传和快速重传两种机制来处理丢包。

1、超时重传

应用场景：适用于网络不稳定、长时间丢包
触发条件：在RTO内未收到ACK
处理方式：重新发送数据包

• 发送方在发送数据时，启动一个定时器（RTO）
• 如果在RTO时间内没有收到ACK，TCP认为数据包丢失，重新发送该数据包
• TCP会指数退避地调整RTO，比如1s、2s、4s…直到达到最大重传次数。

缺点：

• 如果RTO设置过长，丢包恢复慢，影响性能。
• 如果RTO设置过短，可能导致不必要的重传，加重网络负担。

2、快速重传

应用场景：适用于部分丢包、轻微网络抖动
触发条件：收到3个相同的ACK
处理方式：立即重传丢失的数据包

当TCP发送方收到连续3个相同的ACK（即3次确认同一个数据包）时，认为该数据包可能已经丢失，会立即重传，而不等待超时。

示例：
1、发送方发送 Seq=1, 2, 3, 4。
2、Seq=2 丢失，但 Seq=3、4 仍然到达 接收方。
3、接收方发现 Seq=2 缺失，于是对 Seq=1 发送 3 次 ACK（ACK=2）。
4、发送方收到 3 次相同的 ACK=2，认为 Seq=2 丢失，立即重传 Seq=2。

优点：

• 比超时重传更快恢复丢包，提高 TCP 传输效率。

四次挥手

四次挥手过程

图片来源：https://juejin.im/post/5ddd1f30e51d4532c42c5abe

• 第一次挥手：客户端向服务端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待服务端的确认
  • 序列号 seq = u，即客户端上次发送的报文的最后一个字节的序号 + 1
  • 确认号 ack = k, 即服务端上次发送的报文的最后一个字节的序号 + 1
• 第二次挥手：服务端收到连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = k，确认号 ack = u + 1

这时 TCP 连接处于半关闭状态，即客户端到服务端的连接已经释放了，但是服务端到客户端的连接还未释放。这表示客户端已经没有数据发送了，但是服务端可能还要给客户端发送数据。

• 第三次挥手：服务端向客户端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待 ACK 的确认
  • 序列号 seq = w，即服务端上次发送的报文的最后一个字节的序号 + 1。如果半关闭状态，服务端没有发送数据，那么 w == k
  • 确认号 ack = u + 1，与第二次挥手相同，因为这段时间客户端没有发送数据
• 第四次挥手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = u + 1，确认号为 ack = w + 1

此时，客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放，必须经过 2*MSL（最长报文段寿命）的时间后，才进入 CLOSED 状态。而服务端只要收到客户端发出的确认，就立即进入 CLOSED 状态。可以看到，服务端结束 TCP 连接的时间要比客户端早一些。

TCP 规定，[FIN/ACK] 包即使没有传送数据，也会消耗掉一个序列号。[FIN/ACK] 包是第一、三次挥手：

• 第一次挥手时，客户端的序列号 seq = u，消耗一个序列号。因此：
  • 第二次挥手时，服务端的确认号 ack = u + 1
  • 第四次挥手时，客户端的序列号 seq = u + 1
• 第三次挥手时，服务端的序列号 seq = w，消耗一个序列号。因此：
  • 第四次挥手时，客户端的确认号 ack = w + 1

为什么需要四次挥手

因为 TCP 是全双工的，一方关闭连接后，另一方还可以继续发送数据。所以四次挥手，将断开连接分成两个独立的过程

为什么四次挥手，客户端的TIME-WAIT状态必须等待2MSL的时间，才能返回到CLOSED状态

主要有两个原因：

(1) 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。

第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK 报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。

MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端重传的 FIN/ACK 报文，然后客户端重传一次 ACK 报文，并重新启动 2MSL 计时器。如此保证服务端能够正常关闭。

那如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，会怎样？服务端会继续超时重试直到断开连接，见下文。

(2) 防止已失效的连接请求报文段出现在之后的连接中。

TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。

如果已经建立了连接，但是客户端出现故障了怎么办？

或者说，如果三次握手阶段、四次挥手阶段的包丢失了怎么办？比如上面描述的“服务端重发 FIN”的问题。

简而言之，通过定时器 + 超时重试机制，尝试获取确认，直到最后会自动断开连接。

具体而言，TCP 设有一个保活计时器。服务器每收到一次客户端的数据，都会重新复位这个计时器，时间通常是设置为 2 小时。若 2 小时还没有收到客户端的任何数据，服务器就开始重试：每隔 75 秒发送一个探测报文段，若一连发送 10 个探测报文后客户端依然没有回应，那么服务器就认为连接已经断开了。

使用tcpdump抓包分析

操作

tcpdump是一个命令行工具，可以打印网络接口上传输的 TCP 报文。

在一个终端窗口执行以下命令，监听与www.baidu.com传输的数据包

tcpdump -n host www.baidu.com # 可能需要 sudo 权限

参数说明：

• -n：不要将 host.port 转成域名
• host：监听发到特定主机与端口的流量
  如图，开始成功监听：
  

随后再开启一个终端窗口，执行以下命令，访问 www.baidu.com

curl www.baidu.com：

可以看到 tcpdump 打印了信息

其中一定包含三次握手建立连接、发送数据包、四次挥手断开连接这几个过程。接下来一一分析。约定：客户端就是本机，服务端就是百度的服务器。

子网掩码的作用

子网掩码是用于划分网络地址和主机地址的一个32位二进制数。
它与IP地址结合使用，用于确定一个IP地址中哪些位表示网络地址，哪些位表示主机地址。

子网掩码的作用主要有两个方面：

1、确定网络地址：子网掩码通过将IP地址中的网络部分与主机部分进行分隔，将网络地址和主机地址进行划分。子网掩码中的1表示网络部分，0表示主机部分。通过与IP地址进行逻辑与运算，可以得到网络地址。
2、确定主机地址范围：子网掩码中的0表示主机部分，确定了主机地址的范围。主机地址范围就是同一个网络中可以分配给主机的不同IP地址。子网掩码中主机部分的位数可以决定主机地址的数量，可以根据主机地址范围来分配IP地址给不同的主机。

总的来说：它可以帮助路由器和交换机等网络设备正确地识别网络地址和主机地址，实现数据的正确传输和路由。

ABC类网络

类别	地址范围	默认子网掩码	网络部分	主机部分	每个网络支持的主机数量	可用网络数量
A类	0.0.0.0 - 127.255.255.255	255.0.0.0 /8	8 位	24 位	16,777,214	128 个
B类	128.0.0.0 - 191.255.255.255	255.255.0.0 /16	16 位	16 位	65,534	16,384 个
C类	192.0.0.0 - 223.255.255.255	255.255.255.0 /24	24 位	8 位	254	2,097,152 个

应用场景：

A 类网络：适用于需要大量主机的非常大的网络（例如，大型 ISP 或跨国公司），但网络数量较少。

B 类网络：适用于中型网络，既能支持较多的主机，又能支持一定数量的子网。常用于中型公司或组织。

C 类网络：适用于小型网络，适合家庭、个人用户或小型企业，支持的主机较少，但支持较多的子网。

1100000000
255.255.255.192

TCP和UDP的区别

特性	TCP	UDP
连接类型	面向连接（需要建立和断开连接）	无连接（无建立过程）
可靠性	提供可靠的传输，保证数据完整性	不保证可靠性，可能丢包、重复或乱序
速度	较慢，延迟较高	较快，延迟较低
重传机制	有，丢包时会自动重传	无，丢包时不会重传
顺序控制	有，保证数据按顺序到达	无，数据可能乱序
使用场景	需要高可靠性、顺序保证的应用（如网页、文件传输）	对实时性要求高、丢包可容忍的应用（如视频流、在线游戏）

• 选择 TCP：如果你的应用需要确保数据传输的可靠性、顺序控制，并且可以容忍一定的延迟（如网页浏览、文件传输、电子邮件等），就应该使用 TCP。
• 选择 UDP：如果你的应用需要快速传输数据，且对丢包有一定容忍度，且不需要顺序控制（如流媒体、在线游戏、DNS 查询等），就应该使用 UDP。

状态码

200 - 成功处理请求

400 - 客户端不理解请求的语法。

401 - 未授权

404 - 未找到页面

500 - 服务器遇到错误，无法请求