计算机网络

目录

• • 1.计算机网络模型
  • 2.应用层的常见协议:
  • 3.HttP状态码
  • 4.TCP协议
  • • 流量控制:
    • 滑动窗口:
    • 超时重传:
    • 快速重传:
  • 5.拥塞控制
  • [6. TCP的三次握手和四次挥手](#6. TCP的三次握手和四次挥手)
  • • • 三次握手
      • 四次挥手
  • 7.输入网址到网页显示的整个过程

1.计算机网络模型

2.应用层的常见协议:

• HTTP（超文本传输协议 ）：用于在 Web 浏览器和 Web 服务器之间传输超文本，是网页浏览的基础协议。客户端通过发送 HTTP 请求获取网页内容，服务器返回 HTTP 响应，包含网页的 HTML、CSS、JavaScript 等数据 。

• HTTPS（安全超文本传输协议 ）：是 HTTP 的安全版本，在 HTTP 的基础上通过 SSL/TLS 协议对数据进行加密传输，保证数据的安全性，常用于涉及敏感信息传输的场景，如网上银行、在线支付等 。

• FTP（文件传输协议 ）：用于在网络上进行文件的上传和下载，它提供了一种可靠的文件传输方式，用户可以通过 FTP 客户端连接到 FTP 服务器，进行文件的浏览、上传、下载等操作 。

注:HTTP必须要依赖传输层的TCP

1.用户触发：用户操作（如输网址）让浏览器发起请求

2.建 TCP 连接：浏览器 ↔ 服务器通过 TCP 三次握手，建立可靠传输通道

3.HTTP 请求：浏览器用 HTTP 格式打包 "需求"（如要网页），经 TCP 发服务器

4.HTTP 响应：服务器解析请求→处理→用 HTTP 格式打包 "结果"（如网页内容），经 TCP 回传

5.浏览器呈现：浏览器解析 HTTP 响应，把内容（网页、数据）展示给用户

3.HttP状态码

自己的理解:

http常见的响应状态码:200响应成功，301表示永久重定向302是临时重定向，400是请求参数有误，404是请求url有误，在服务器上找不到，500是服务器有误，503是服务器很繁忙，因为处理用户的请求太多了.

• 200：请求成功，服务器正常返回数据（最常见的成功状态）
• 301：资源永久迁移到新地址，浏览器会记住新地址（比如域名更换）
• 302：资源临时迁移，下次请求仍会用原地址（比如临时维护跳转）
• 400：客户端发送的请求参数有误，服务器无法理解（比如表单格式错误）
• 401:未认证，未登录。（检测token令牌）
• 404：请求的 URL 对应的资源在服务器上不存在（比如输错网址）
• 500：服务器内部发生错误，无法处理请求（比如代码 bug）
• 503：服务器暂时无法处理请求，通常是负载过高（比如高峰期网站崩溃）

4.TCP协议

流量控制:

自己理解:流量控制就是当发送包，发送方发送很多数据，数据包时，此时会，可能发送太多，会导致接收方的缓冲区放不下，它就会提醒发送方速度减慢。

流量控制的核心就是防止发送方发送数据的速度过快，导致接收方的缓冲区被填满而无法处理，进而造成数据丢失。具体来说，接收方会通过TCP报文首部的"窗口大小"字段，告知发送方自己当前缓冲区的空闲容量（即还能接收多少数据）。如果接收方缓冲区快满了，就会减小窗口大小（甚至设置为0），发送方收到后就会相应减慢发送速度或暂停发送，直到接收方处理完数据、缓冲区有了空闲空间，再增大窗口大小允许发送方继续发送。这样就实现了发送方和接收方之间的数据传输速率匹配。

滑动窗口:

自己理解:滑动窗口就是作用在窗口上的一种思想吧，它是平衡发送方和接收方的传送数据的一种思想。当发送方收到接收方的ACK指令时，它就会滑动，确保数据在移动。如果它未收到，它就会将那个这些数据放在窗口里，等待着下一次的滑动。

滑动窗口是 TCP 协议中用于平衡发送方与接收方数据传输效率和可靠性的核心机制，其核心是通过"窗口"来动态控制发送数据的范围和量：接收方会根据自身缓冲区状态确定窗口大小并告知发送方，发送方据此设定发送窗口，在窗口范围内可连续发送数据而无需等待逐个确认；当发送方收到接收方对部分数据的确认（ACK）后，窗口会向前滑动，将已确认的数据移出窗口并纳入新的可发送数据，未收到确认的数据则留在窗口中，等待通过重传机制处理，以此实现高效且可靠的数据传输，同时避免接收方缓冲区溢出。

超时重传:

自己理解:超时重传就是发送方发一个数据包在规定的时间范围内没有收到ack确认应答，就认为这个包可能丢失了，于是重新发这个数据包，以确保接收方收到。

超时重传的核心逻辑就是：

发送方发送数据包后启动计时器。

若超时未收到对应 ACK 确认，判定数据包可能丢失。

发送方重新发送该数据包，以此保障数据能可靠到达接收方。

这正是 TCP 协议实现可靠传输的关键机制之一～

快速重传:

当发送方发送了一系列数据（比如包1、2、3、4、5），如果接收方发现中间某个包丢了（比如收到了1、3、4、5，却没收到2），接收方会主动向发送方连续发送多个相同的 ACK（比如连续发3个"我需要包2"的确认）。发送方收到这3个重复的 ACK 后，就知道"包2可能丢了"，于是不等超时，直接重传包2------这个过程才是快速重传。

5.拥塞控制

什么是拥塞控制?

就是发送方发送很多的数据包时，导致数据包延迟，丢失，这时候可能重传。但重传导致网络的负担就会加重，这时可能造成网路拥堵，这时可能出现拥塞。

为了控制发送方的发送数据包的速率，tcp采用了四个算法来进行拥塞控制。

- 慢启动:  拥塞窗口(数据包的数量)从1开始，每收到一个ACK就指数增长。但当拥塞窗口达到慢开始门限（ssthresh，slow start threshold）时，就会进入拥塞避免阶段 

- 拥塞避免:因为慢启动过程中指数增长后续会使发送数据包的速率很快，所以TCP会设置一个慢启动的门限值，当达到这个门限就改为线性增长。

- 拥塞发生: 虽然指数增长改为线性增长了，但是还是一直增长，只是增长的速度变慢了，当网络拥塞了此时就进行重传机制。

当拥塞很严重，就发生了超时重传，此时将拥塞窗口变为1，门限值(阈值)变为上一个拥塞窗口的一半，进入慢启动。

当拥塞不那么严重，当发送方收到 3 个重复确认时，就认为对应的数据段丢失了，就快速重传。此时将拥塞窗口变为上一个拥塞窗口的一半，门限值设为上一个拥塞窗口的值。然后开始执行快速恢复。

- 快速恢复: 拥塞窗口从上一个阈值+3开始线性增长。快速恢复传输效率，避免从头慢启动。

6. TCP的三次握手和四次挥手

三次握手

我的理解:

​ 客户端先发送一个建立连接的请求报文，携带SYN=1。服务器收到这个请求报文，并同意连接，向客户端发送一个SYN=1，ACK=1的响应报文。然后客户端再次发送一个含ACK=1的请求报文，表示我收到你的确认。此时双方就可以互相通信了。我的解释怎摸样。那我光这样说不行吗

四次挥手

我的理解:

客户端发送一个携带FIN=1的释放连接请求报文，服务端先回应一个ACK=1的响应报文，表示我收到了。因为此时服务端缓冲区还有很多数据没有给客户端发送，当将数据发送完之后。会再次向客户端发送一个ACK=1，FIN=1的报文段（数据包）,表示我释放了客户端的连接。客户端收到服务端的报文并回应ACK=1，表示我知道你释放了连接了。

为啥要三次挥手？二次不行吗？三、四次呢？

我的理解:

三次握手的主要原因是:避免网络延迟导致的重复连接问题,（服务端收到了因网络延迟的旧连接（SyN=1）,然后发SYN=1,ACK=1.因为客户端和服务端之间已经建立连接了，它如果只有两次握手，所以它不会对服务端的请求做出反应）。第二个是确保双方的seq都能收到初始化，确保双方都能进行可靠性连接。

具体解释:

在TCP连接建立过程中，需要三次握手而不是两次，核心原因是为了防止失效的连接请求报文被误处理，确保双方都确认彼此的收发能力正常。

• 两次握手的问题：如果客户端发送的第一个连接请求报文因网络延迟未及时到达，客户端会超时重发并建立连接。若延迟的旧报文后来到达服务器，服务器会误认为是新请求，直接发送确认并建立连接，但客户端此时已不需要该连接，会忽略确认，导致服务器一直等待，浪费资源。

• 三次握手的作用：第三次握手由客户端发送确认，让服务器知道"客户端已收到自己的确认"，双方彻底确认彼此能正常收发数据。这一步能有效过滤掉延迟的旧请求------若客户端收到旧请求的确认，会拒绝并发送复位报文，避免服务器建立无效连接。

简单说，三次握手通过最终确认，确保双方对连接建立达成共识，避免因网络延迟导致的资源浪费或连接异常。

7.输入网址到网页显示的整个过程

自己的理解:

当在浏览器输入一个网址，就在应用层根据http协议生成一个请求报文，

在浏览器会通过DNS服务器将域名解析为ip地址，

然后通过socket套接字调用操作系统的协议栈就到了传输层，在传输层给TCP加上TCP头部(主要包含源端口和目的端口),

网络层添加IP头部（主要加上源ip地址，目的IP地址),

数据链路层（把这个ip的数据包）添加以太网头部（主要加上源MAC地址，目的MAC地址），然后打包成一个以太网真正能传输的数据包，数据经路由器，交换机转发最终到了服务器。

服务器收到了这个数据包，在每一层拆掉对应的报文头部，得到了请求的数据进行处理，形成响应内容。

在生成一个响应报文，这个响应报文再通过相同的过程传送给浏览器，浏览器进行解析得到我们看到的内容。

1. 域名解析（找 IP） ：浏览器先查本地 DNS 缓存，若没有就向 DNS 服务器发送请求，把域名（如www.xxx.com）解析成服务器的 IP 地址（如 192.168.1.1），确定 "要发给谁"。
2. 建立 TCP 连接（三次握手）：解析出 IP 后，浏览器通过 Socket 调用系统协议栈，在传输层与服务器建立 TCP 连接（三次握手确认双方通信能力），同时确定源端口（浏览器随机分配）和目的端口（如 HTTP 默认 80、HTTPS 默认 443）。
3. 发起 HTTP 请求（应用层封装）：连接建立后，浏览器在应用层按 HTTP 协议生成请求报文（包含请求头、请求体，比如 "GET /index.html"），并将报文往下传递。
4. 数据分层封装（往下传） ：
   • 传输层：给请求报文加 TCP 头部（源 / 目的端口），变成 TCP 段；
   • 网络层：加 IP 头部（源 / 目的 IP），变成 IP 数据包；
   • 数据链路层：加以太网头部（源 / 目的 MAC 地址），变成可在物理网传输的帧，通过网线 / 无线发给路由器、交换机，最终传到服务器。
5. 服务器处理并响应：服务器接收帧后，从下往上逐层拆包（拆以太网头→IP 头→TCP 头），拿到 HTTP 请求，处理后生成响应报文（含状态码、响应内容），再按同样的分层封装流程，把响应发回浏览器。
6. 浏览器渲染页面：浏览器接收响应后，拆包拿到 HTML、CSS、JS 等资源，解析并渲染，最终呈现出我们看到的网页；若 TCP 连接不再用，会通过四次挥手断开。