计算机网络知识点

发表于 更新于 分类于
如果我是一串电信号，我要去向何方呢？

概览

OSI 七层模型：应用层、表示层、会话层、传输层、网罗层、数据链路层、物理层

TCP/IP 四层模型：应用层、传输层、网络层、网络接口层

  • 应用层，直接服务于用户。唯一运行在用户态的层：HTTP、FTP、Telnet、DNS、SMTP、DHCP

  • 传输层，应用层的技术支持。应用层数据超过 MSS 会将其切分成 TCP 段，传输层报文中包括了端口号，用于区分报文属于哪个应用：TCP、UDP

  • 网络层，负责数据在网络中的传输，即寻址和路由。超过 MTU 会切分，IP地址代表网络号和主机号：IP、ARP、ICMP

  • 传输层，关注链路级别的传输

应用数据转换到传输块的过程：

img

访问网站的过程

image-20240730153032143
  1. 解析 URL
  2. DNS 查询服务器 IP 地址（本地域名服务器->根域名服务器->顶级域名服务器）
  3. 操作系统协议栈，包括传输层和网络层协议实现
  4. TCP 建立连接（SYN_SEND、SYN_RECE、ESTABLISHED）
  5. 基于端口的 TCP 可靠传输
  6. 基于地址的 IP 定位传输
  7. 头部加上发送和接收方的 MAC 头部，ARP 查找接收端的 MAC
  8. 网卡，帧校验符
  9. 交换机，以太网设备，基于 MAC 地址表转发，没有缓存就广播
  10. 路由器，和网卡类似，各个端口都具有 MAC 和 IP。通过路由表确定要到目的地 IP 需要走哪个端口，并替换帧的源、目标 MAC

在网络包传输的过程中，源 IP 和目标 IP 始终是不会变的（前提：没有使用 NAT 网络的），一直变化的是 MAC 地址，因为需要 MAC 地址在以太网内进行两个设备之间的包传输

校验过程：MAC 地址、IP 地址、序列号、端口

  1. TCP 四次挥手（FIN_WAIT_1、FIN_RECE、FIN_WAIR_2、LAST_ACK）

Linux 实现数据包收发

发送

NAPI 机制：不采用中断的方式读取数据，而是首先采用中断唤醒数据接收的服务程序，然后 poll 的方法来轮询数据

DMA 技术：将网络包写入到指定的内存地址，接着网卡向 CPU 发起硬件中断，当 CPU 收到硬件中断请求后，根据中断表，调用已经注册的中断处理函数

硬中断先把收到的数据存在内存中，暂时屏蔽 CPU 中断，后续软中断统一处理先前的数据

接收

  1. 将用户待发送的数据从用户态拷贝到内核态 sk_buff 内存，并将其加入到发送缓冲区；
  2. 克隆一份 sk_buff 的副本，用于网络层传输，传输层保留原始 sk_buff 直到接收到 ACK，以保证可靠传输；
  3. 当 IP 层发现数据包大于 MTU 时，会申请额外的 sk_buff，并将原来的数据包拆分成多个小的 sk_buff；

应用层 HTTP

HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」

字段

  • Content-Length：HTTP 协议，通过设置回车符、换行符作为 HTTP header 的边界；通过 Content-Length 字段作为 HTTP body 的边界。这两个方式都是为了解决“粘包”的问题。

HTTP 缓存技术：

  • 强制缓存，缓存如果没有过期浏览器就直接使用；
  • 协商缓存，304状态码，表示直接使用本地已过期的缓存，因为服务器数据未更新

HTTP/1.0

  • 无状态；
  • 每发起一个请求，都要新建一次 TCP 连接；

HTTP/1.1

  • 长连接，复用 TCP 连接
  • 基于管道传输，可以同时发出多个请求，而不需要等到收到前一个个请求的响应，再发送下一个请求。解决了请求的对头阻塞问题，但依然存在 HTTP 层的队头阻塞问题。

请求的对头阻塞：前一个请求结束后才能处理下一个请求；

HTTP 层队头阻塞：服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后， 才能处理下一个请求；

TCP 层队头阻塞：一旦发生丢包，就会阻塞住所有的 HTTP 请求；

HTTP/2

  • 头部压缩
  • 二进制格式数据代替报文
  • 并发传输，多个请求复用一个 TCP 连接，解决了HTTP 层的队头阻塞，但依然存在 TCP 层的队头阻塞问题
  • 服务端主动推送
  • 二进制帧格式传输

HTTP/3

  • 提出了 QUIC 传输层协议代替 tcp。QUIC 是基于udp实现的，在无连接的基础上实现了可靠和安全
    • 更快的请求多路复用，解决 TCP 层队头阻塞问题
    • 建立连接更快

HTTPS

  • 在 HTTP 的基础上
    • 在三次握手后，还需要 SSL/TLS 的握手过程，使得报文能够加密传输；
    • 使用时需要向 CA 申请数字证书，来保证服务器的身份是可信的；
  • 加密传输
    • 混合加密【机密性，防窃听】：建立连接用非对称加密：数字签名，通过「私钥加密，公钥解密」的方式，来确认消息的身份；传输数据用对称加密：一个密钥，信息传输；
    • 摘要算法【完整性，防篡改】：用摘要算法（哈希函数）来计算出内容的哈希值，哈希值是唯一的，且无法通过哈希值推导出内容；
    • 数字证书【防冒充】：通过第三方 CA 保证服务器的公钥私钥没有被别人替换过
  • 【TLS 握手阶段】RSA算法
    • 客户端向服务器索要并验证服务器的公钥
      • ClientHello 客 ==> 服：随机数 Client Random、TLS 版本号、密码套件；
      • SeverHello 服 ==> 客：随机数 Server Random、TLS 版本号 ACK、使用密码套件 RSA、数字证书；
    • 双方协商生产「会话秘钥」
      • 客户端回应 客 ==> 服：获取 CA 证书中的服务器公钥确认服务端数字证书、「会话秘钥」加密通信通知、公钥加密随机数 pre-master key；
      • 服 ==> 客；三个随机数算出会话密钥，双方都通知对方后续请求都使用会话密钥加密通信；
    • 双方采用「会话秘钥」进行加密通信

传输层 TCP

负责为应用层提供网络支持，实现应用到应用的数据传输

TCP ：面向连接的、可靠的、基于字节流的

三次握手

TCP 三次握手

四次挥手【closed_wait；last_ack】

客户端主动关闭连接 —— TCP 四次挥手
  • 首先确认客户端不会再发送请求给服务端
  • 然后服务端在发送完数据后，再向客户端发送断开连接

为什么这么设计？因为TCP是双向通信的可靠的协议，需要确保客户端和服务端都有收发数据包的能力；为后续传输做准备：序列号

流量控制、超时重传、拥塞控制

拥塞控制：慢开始（每经过一个传输轮次，拥塞窗口 cwnd 就加倍）、拥塞避免（慢开始门限 ssthresh）、快重传（连续收到三个重复确认就立即重传对方尚未收到的报文段，不等待重传计时器到期）、快恢复

网络层 IP

负责路径传输过程中路径和节点的选择，实现设备到设备的数据传输

寻址能力：网络号+主机号（子网掩码）

路由：数据包每到达一个节点，通过路由算法决定下一步走哪条路径

分片重组：以太网的 MTU（最大传输单元）是 1500 字节。在分片传输中，一旦某个分片丢失，则会造成整个 IP 数据报作废，所以 TCP 引入了 MSS 也就是在 TCP 层进行分片不由 IP 层分片，那么对于 UDP 我们尽量不要发送一个大于 MTU 的数据报文

网络协议

DNS：域名解析

NAT：私有网络与公共网络之间转换 IP 地址

ICMP：传输控制信息（不用于传输应用层数据），以帮助管理和维护网络

DHCP：自动为网络中的设备分配 IP 地址及其他网络配置参数，如子网掩码、网关和 DNS 服务器

ARP：下一跳的 MAC 地址

IGMP：组播

命令ip router 查看路由表