Linux：Linux网络总结(附下载链接)

下载链接

链接: https://pan.baidu.com/s/1hRTh7rSesikisgRUO2GBpA?pwd=utgp 提取码: utgp

最近总结了Linux网络的内容，总结内容如下：

网络问题

综合问题

访问一个网页的全过程？

• 发过去

  • 应用层

    • 1. 浏览器地址输入URL
      • 1.1 浏览器查看缓存，强制和协商缓存
    • 2. 解析URL获取协议，主机，端口，路径
    • 3. 生成HTTP请求报文
    • 4. 获取主机IP

      • 4.1 浏览器缓存

      • 4.2 主机缓存

      • 4.3 DNS域名解析

      • 4.4 路由器解析

  • 传输层

    • 1. 建立TCP连接，三次握手
    • 2. 给报文添加TCP报头
    • 3. 向下传输，发送报文

  • 网络层

    • 1. 通过解析出的IP添加IP报头
    • 2. 向下传输，发送报文

  • 网卡

    • 转换为电信号

  • 交换机

    • 电信号到达网线接口，交换机里的模块进行接收，接下来交换机里的模块将电信号转换为数字信号

    • 将包存入缓冲区后，接下来需要查询一下这个包的接收方 MAC 地址是否已经在 MAC 地址表中有记录

      • 如果没有匹配，全部转发

  • 路由器(网卡)

    • 检查MAC地址看看是不是给自己的

      • 是，收到缓冲区当中

    • 去掉MAC头部，查询路由表确定端口

    • 发送包

      • 看网关，如果有网关就向这个IP发

        • 利用ARP查询MAC地址

          • 再做一个有MAC的包

            • 通过交换机到达下一个路由器

• 收回来

  • 1. 接收HTTP响应
  • 2. 根据状态码处理情况

• 这个问题我基于TCP/IP的网络模型来回答，并且暂时不考虑浏览器缓存的情况。

首先看一下应用层：对于应用层，当用户输入一个网址后，此时会进行URL解析，根据URL构建出想要请求的资源路径，使用的协议，具体方法，请求的IP和端口信息。其中IP需要使用DNS域名解析协议来进行获取，基于这些内容，一个初步的报文就在应用层构建完毕了，此时应用层就完成了自己的任务。

现在数据包来到传输层了，Http协议基本都是遵循TCP协议的，因此我们只考虑TCP协议的情况，到达传输层后，建立TCP的三次握手，如果是HTTPS再构建四次TLS握手，最终可以进行收发数据，此时就给报文添加一个TCP的报头，然后继续向下传递

现在数据包来到网络层了，网络层根据解析出的IP地址以及自身的属性，最终构建出一个IP的报头，添加到数据包前，然后继续向下传递

此时数据包来到了网络接口层，数据包在网络中的传输依赖于路由器和交换机的协同工作。路由器根据路由表选择最佳路径，将数据包转发到下一个网络。交换机则根据MAC地址表快速转发帧到目标网络接口。如果MAC地址表中没有目标MAC地址，交换机会将帧广播到所有端口，直到找到正确的接收者

数据包在进行传输的过程中，网络中的每一个设备都可以对这个包进行接受，接受到包之后，根据MAC地址来判断是不是给自己的，如果是给自己的就留下来，收到缓冲区中，去掉这个没有用的MAC头部，然后到自己的路由表中进行查询，如果此时网关列中没有信息，那么就说明这个数据包已经传输到了指定的服务器，如果网关列中有数据，那么就根据网关中的这个IP，利用ARP协议来获取IP对应的MAC地址，然后插入到这个包前，然后继续进行发送，通过交换机到达下一个路由器，直到到达指定的服务器

到达指定的服务器后，服务器就会对于包进行层层解析，一直解析到应用层的数据，之后构建一个Http响应，再发回去即可

WebSocket

• 借助HTTP协议进行升级

• 101状态码 -> 协议切换

• 完美继承全双工

• 用报头+有效载荷解决粘包问题

HTTP

HTTP基本概念

• HTTP是什么？

• HTTP常见的状态码有哪些？

• HTTP常见字段有哪些？

GET与POST

• 有什么区别？

• 是安全和幂等的吗？

HTTP特性

• HTTP/1.1 优点有哪些？

  • 简单

  • 跨平台

  • 扩展

    • 报头随意补充

    • 下层随意变化

• HTTP/1.1 缺点有哪些？

  • 无状态

  • 明文传输

  • 不安全

• HTTP/1.1 性能如何？

  • 长连接

    • 对比1.0和1.1

  • 管道

    • 请求和响应的队头阻塞

HTTP缓存技术

• HTTP缓存有哪些实现方式？

  • 强制和协商

• 什么是强制缓存？

• 什么是协商缓存？

HTTP的演变

• HTTP1.1 相比 HTTP/1.0 提高了什么性能？

  • 问题

    • 报头不压缩

    • 冗余头部

    • 响应对头阻塞

    • 无请求优先级

    • 无全双工

• HTTP/2 做了什么优化？

  • 头部压缩

  • 二进制格式

  • 并发传输

  • 服务器主动推送资源

• HTTP/3 做了什么优化？

  • 解决TCP队头阻塞

  • 无队头阻塞

    • 只阻塞当前流，其他流不影响

  • 更快的连接建立

    • 1 个 RTT 就可以完成建立连接与密钥协商

  • 连接迁移

    • TCP换连接成本很高

HTTP1.1 优化

• 如何避免发送HTTP请求？

  • 缓存

• 如何减少HTTP请求次数？

  • 减少重定向次数

  • 合并请求

  • 延迟发送

    • 一个网页里面的内容慢慢加载

• 如何减少HTTP响应数据大小？

  • 无损压缩

  • 有损压缩

HTTPS

HTTP与HTTPS有哪些区别？

• HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程

HTTPS解决了HTTP的哪些问题？

• 窃听风险

  • 篡改风险

    • 冒充风险

• 信息加密

  • 校验机制

    • 身份证书

HTTPS如何解决的？

• 混合加密(不窃听)

  • 非对称加密用于密钥交换

    • 客户端发给服务端一个会话密钥(CA)，服务端用私钥解开，双方就获得了一个通信的密钥对

  • 对称加密用于数据传输

    • HTTPS使用对称加密的会话密钥来加密和解密数据

• 摘要算法+数字签名

  • 通过哈希算法可以确保内容不会被篡改

    • 通过数字签名(私钥解密)确保哈希值不被替换

• 数字证书

  • 防止又换私钥又换公钥

    • 进行一个注册(个人信息 + 公钥 + 数字签名)

• 公钥加密，私钥解密

  • 保证内容传输的安全

• 私钥加密，公钥解密

  • 保证消息不会被冒充

HTTPS是如何建立连接的？

• SSL/TLS 协议基本流程

  • 客户端向服务器索要并验证服务器的公钥

  • 双方协商生产「会话秘钥」

  • 双方采用「会话秘钥」进行加密通信

• TLS 握手

  • ClientHello

  • SeverHello

  • 客户端回应

    • 确认数字证书，取出公钥

  • 服务器的最后回应

    • 计算出本次通信的「会话秘钥」

HTTPS 的应用数据是如何保证完整性的

• 握手协议

  • TLS 四次握手的过程负责协商加密算法和生成对称密钥

• 记录协议

  • 保护应用程序数据并验证其完整性和来源，对 HTTP 数据加密

• 数据加密过程

  • 消息被分割和压缩

  • 加上消息认证码MAC 值

  • 压缩的片段和消息认证码一起进行加密

  • 带上报头，组成报文

HTTPS 一定安全可靠吗？

• https本身一定是没问题的，一定是客户端本身有问题

  • 电脑中病毒，证书被换了

    • 提醒证书可能被劫持，执意访问

• HTTPS双向认证，如果服务端觉得客户端不值得信任，就不通信

TCP

TCP基本认识

• TCP报头？

• 为什么需要TCP？工作在哪？

• 什么是TCP？

  • 面向连接可靠字节流

• 什么是TCP连接？

  • 需要客户端与服务端达成上述三个信息的共识

    • socket

      • ip+端口

    • 序列号

    • 窗口大小

• 如何确定TCP连接？

  • 四元组

    • 这个很重要，当判断TCP连接建立，就要看这个四元组

• TCP和UDP的区别和应用场景？

  • 连接

  • 可靠性

  • 传输方式

  • 服务对象

    • 一对一…

  • 拥塞和流量控制

  • 首部开销

  • 分片不同

• 为什么TCP有首部长度而UDP没有？

• 为什么UDP有包长度而TCP没有？

  • 历史问题

TCP连接建立

• TCP三次握手过程和状态变迁？

  • 第三次握手是可以携带数据的，前两次握手是不可以携带数据的

• 如何查看TCP状态？

• 为什么是三次，不是两次四次？

  • 验证收发能力

    • 历史连接

      • 同步序列号

        • 资源浪费

  • 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；

  • 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

• 为什么初始化序列号都不一样？

  • 为了防止历史报文被下一个相同四元组的连接接收

  • 为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收

• 序列号是如何随机产生的？

  • 随机数是会基于时钟计时器递增的，基本不可能会随机成一样的初始化序列号

• TCP层为什么需要MSS？

  • 如果一个 IP 分片丢失，整个 IP 报文的所有分片都得重传

• 第一次握手丢失会怎么样？

• 第二次握手丢失会怎么样？

  • 都发

• 第三次握手丢失会怎么样？

• 什么是SYN攻击？如何避免？

  • 占满服务端的半连接队列

  • 调大 netdev_max_backlog

    • 增大 TCP 半连接队列

      • 开启 tcp_syncookies

        • 减少 SYN+ACK 重传次数

TCP连接断开

• TCP四次挥手过程和状态变迁？

• 为什么需要四次挥手？

  • close和shutdown的区别

• 第一次挥手丢失了会怎么样？

• 第二次挥手丢失了会怎么样？

• 第三次挥手丢失了会怎么样？

• 第四次挥手丢失了会怎么样？

• 为什么TIME_WAIT时间是2MSL？

  • 2个报文最大生存时间

• 为什么需要TIME_WAIT？

  • 防止历史数据

  • 优雅的关闭

• TIME_WAIT太多会怎么样？

  • 系统+端口

• 如何优化TIME_WAIT？

• 如果建立连接后，客户端故障怎么办？

  • TCPkeepalive

    • 失活报文看看活不活

• 如果建立连接后，服务端进程崩溃怎么办？

socket编程

• TCP的socket编程？

• listen参数的意义？

  • accept队列大小

• accept是在哪一步？

• 客户端close后的流程？

• 没有accept还能连接吗？

  • accept只是从队列取元素

• 没有listen还能连接吗？

  • 自连接，哈希表

重传机制

• 超时重传？

  • 数据包丢失

    • 确认应答丢失

• 快速重传？

  • 优化，但不保底

• SACK是什么？

  • 标识已收到的报文

• D-SACK是什么？

  • 标识重复收到的报文

滑动窗口

• 发送窗口？

• 接收窗口？

流量控制

• 缓冲区和滑动窗口的关系？

  • 不能又收缩又少缓存

• 窗口关闭？

  • 打满了，不再收数据

  • 问题？解决？

• 什么是糊涂窗口综合征？

  • 每次发送数据很小，效率低

拥塞控制

• 慢启动

• 拥塞避免

• 拥塞发生

• 快速恢复

TCP缺点

• 升级困难 改内核

• 队头阻塞

• 建立连接延迟

• 网络迁移

如何基于UDP实现可靠传输？

• 序列号

• 确认应答

• 超时重传

• 流量控制

• 拥塞控制

• 优化TCP连接建立

• 网络迁移

TCP优化

• 绕过三次握手

  • cookie

快速复用 TIME_WAIT

• 历史 RST 报文可能会终止后面相同四元组的连接，因为 PAWS 检查到即使 RST 是过期的，也不会丢弃

• 处于新连接建立可能收到旧的FIN+ACK，回RST
  如果第四次挥手的 ACK 报文丢失了，有可能被动关闭连接的一方不能被正常的关闭

QUIC

• 可靠传输

  • Packet Number 单调递增
    配合 Stream ID 与 Offset

    • 可以更加精确计算 RTT，没有 TCP 重传的歧义性问题；

    • 可以支持乱序确认，因为丢包重传将当前窗口阻塞在原地，而 TCP 必须是顺序确认的，丢包时会导致窗口不滑动

• 队头阻塞

  • 每一个stream分配一个独立的滑动窗口

• 流量控制

  • window_update 帧告诉对端自己可以接收的字节数

  • BlockFrame 告诉对端由于流量控制被阻塞了

  • 基于Stream和Connection的控制

• 拥塞控制

  • 在应用层可以随便改算法，主流使用TCP的

• 连接建立

  • 321RTT -> 210RTT

• 网络迁移

  • 基于客户端服务端连接 ID，无需重新建立

序列号和确认号

• 序列号 = 上一次发送的序列号 + len

• 确认号 = 上一次收到的报文中的序列号 + len

Mac地址表

一个是设备的 MAC 地址，

另一个是该设备连接在交换机的哪个端口上