Linux 中五种 IO 模型
在 Linux 中，常见的五种 I/O（Input/Output）模型包括：
- 阻塞 I/O（Blocking I/O）：
- 当应用程序调用 I/O 操作时，它会一直阻塞，直到数据被完全传输或操作失败。期间，应用程序无法执行其他任务。
- 这种模型适用于简单和同步的 I/O 操作，但对多个并发连接的应用程序来说，可能会导致性能问题。
- 非阻塞 I/O（Non-blocking I/O）：
- 在非阻塞 I/O 模型中，应用程序发起 I/O 操作后，不会等待操作完成。如果操作不能立即完成，应用程序会立即返回并继续执行其他任务。
- 应用程序需要通过轮询来检查 I/O 操作的状态，以确定是否已经完成。这种方式可以实现并发处理多个 I/O 操作，但会消耗一定的 CPU 资源。
- I/O 复用（I/O Multiplexing）：
- 使用 I/O 复用模型时，应用程序可以同时等待多个 I/O 事件的到达。它使用 select、poll 或 epoll 等系统调用来监视多个文件描述符的状态。
- 当至少一个文件描述符准备好进行 I/O 操作时，应用程序将被通知，并可以针对就绪的文件描述符执行相应的操作，而不会阻塞其他文件描述符。
- 这种模型适用于同时处理多个连接的服务器应用程序。
- 信号驱动 I/O（Signal-driven I/O）：
- 在信号驱动 I/O 模型中，应用程序通过向内核注册信号处理函数来请求异步通知。
- 当 I/O 操作完成时，内核将发送一个信号给应用程序，应用程序可以在信号处理函数中执行相应的操作。
- 这种模型可以使应用程序在等待 I/O 完成时继续执行其他任务，但信号驱动 I/O 的实现可能有限制，且需要处理信号相关的竞争条件。
- 异步 I/O（Asynchronous I/O）：
- 在异步 I/O 模型中，应用程序发起 I/O 操作后，可以立即返回并继续执行其他任务。当 I/O 操作完成时，应用程序会得到通知，并处理已传输的数据。
- 这种模型通过使用专门的系统调用（如 aio_read、aio_write）来实现异步 I/O 操作。
- 异步 I/O 模型可以在不阻塞应用程序的情况下进行高效的 I/O 处理。
这些 I/O 模型提供了不同的方式来处理输入输出，选择合适的模型取决于应用程序的需求和设计考虑。
四次挥手之后为什么还要等待 2msl
在 TCP 连接的四次挥手过程中，等待 2MSL（Maximum Segment Lifetime）是为了确保连接中的所有数据包都已经被网络完全丢弃，以避免出现类似于 “僵尸连接” 的问题。
- MSL 的定义：MSL 是指一个数据包在网络中最长的存活时间，通常默认为两倍的最大报文段寿命。最大报文段寿命是一个 IP 数据包在网络中能够存活的最长时间，它的具体值由操作系统决定，一般为几十秒至几分钟。
- 等待 2MSL 的原因：
- 可靠性：等待 2MSL 可以确保连接中所有的 ACK（确认应答）报文都能够被另一端接收到。这是因为在 TCP 中，ACK 报文的丢失是可能发生的，所以发送端需要确保对方收到了自己发送的 FIN（连接终止）报文。
- 避免旧连接干扰：等待 2MSL 也可以防止旧的、已经关闭的连接的数据包出现在新建立的连接中。如果新连接的第一个 SYN 报文与上一个连接传输的 FIN 报文相撞，就可能导致错误的连接建立。
- 2MSL 大小的选择：2MSL 的选取应该足够长，以确保网络中的所有数据包都已经被丢弃，同时又不应过长以避免资源浪费。通常，2MSL 的时间推荐为两倍的最大报文段寿命。
总之，在 TCP 连接的四次挥手完成后等待 2MSL 是为了确保连接的可靠关闭，并避免新旧连接的混淆。这是一种网络协议设计上的保护机制，确保网络通信的稳定性和可靠性。
cookie 和 session 的区别是什么
Cookie 和 Session 是两种常用的 web 开发中用于跟踪用户状态的机制，它们的主要区别如下：
- 数据存储位置：
- Cookie: Cookie 是存储在客户端（浏览器）中的小型文本文件，以键值对的形式存在。它会被保存在用户的硬盘上，每次用户发送请求时都会自动附带在请求头中。
- Session: Session 是存储在服务器端的数据结构，用于保存用户的会话信息。每个客户端与服务器之间建立连接时，会在服务器端创建一个唯一的 session，并将 session ID 发送给客户端，通常以 Cookie 的形式存储在客户端。
- 数据存储内容：
- Cookie: Cookie 主要用于存储少量的简单数据，例如用户的偏好设置、登录凭证等。它的大小限制为每个域名下的总共 Cookie 大小通常不超过 4KB。
- Session: Session 可以存储较大量和复杂的数据，通常存储用户的登录状态、购物车内容等。服务器端会维护一个 session 数据结构，通过 session ID 将用户的数据与对应的会话关联起来。
- 安全性：
- Cookie: Cookie 存储在客户端，可以被客户端篡改，因此安全性较低。但可以通过设置 Cookie 的属性来增加一定的安全性，例如设置 HttpOnly 属性可以防止客户端的 JavaScript 访问 Cookie。
- Session: Session 存储在服务器端，在客户端只保存了一个 session ID。相比 Cookie，Session 的安全性较高，因为用户无法直接修改服务器端的数据。
- 生命周期：
- Cookie: Cookie 可以设置过期时间，可以是会话级别的（浏览器关闭后失效）或具体的日期时间。如果没有设置过期时间，Cookie 默认为会话级别。
- Session: Session 的生命周期依赖于用户会话的开始和结束。当用户打开网站时，服务器会创建一个 session；当用户关闭浏览器或长时间不活动时，session 会被销毁。
总结来说，Cookie 存储在客户端的小型文本文件中，主要用于存储简单的数据；而 Session 存储在服务器端，用于保存用户的会话信息，可以存储较大量和复杂的数据。Cookie 的安全性较低，但具有较长的生命周期；Session 的安全性较高，但随着用户会话的结束而销毁。在实际使用中，Cookie 和 Session 可以配合使用，以实现更灵活和安全的用户状态跟踪。
tcp 怎么保证可靠性
TCP（Transmission Control Protocol）通过一系列的机制来保证数据传输的可靠性：
- 序列号和确认应答：发送方为每个数据包分配一个唯一的序列号，接收方通过确认应答来告知发送方已经成功接收到数据包。如果发送方在一定时间内没有收到确认应答，将会重传该数据包。
- 超时重传：发送方在发送数据包后会启动一个定时器，如果在规定时间内没有收到确认应答，发送方会认为数据包丢失，会重新发送该数据包。
- 流量控制：接收方可以通过 TCP 标准中的滑动窗口机制告诉发送方自己还有多少可用缓冲区来接收数据。发送方根据接收方的滑动窗口大小来控制发送数据的速率，以避免接收方的缓冲区溢出。
- 拥塞控制：TCP 通过拥塞窗口来控制发送方发送数据的速率。拥塞窗口的大小由网络的拥塞程度决定，如果网络拥塞，拥塞窗口会减小，从而降低发送方发送数据的速率；反之，如果网络通畅，拥塞窗口会增大，提高发送方的数据发送速率。
- 重排序和丢包恢复：接收方在接收到乱序的数据包时，会将其缓存起来，并按正确的顺序重新组装。当发生数据包丢失时，接收方会通过选择性重传机制告知发送方重新发送丢失的数据包。
通过上述机制，TCP 可以确保数据在网络中可靠地传输，并且可以应对网络中的各种情况，如丢包、延迟和拥塞等。这使得 TCP 成为一种广泛使用的可靠传输协议。
css实现图片自适应宽高的几种方法
有几种方法可以使用 CSS 实现图片的自适应宽高：
- 使用
max-width和max-height：
img { max-width: 100%; max-height: 100%; }
- 这样设置后，图片的宽度和高度将自动根据容器的宽度和高度进行调整，保持比例不失真。图片会根据容器的大小等比例缩放，并且不会超出容器的范围。
- 使用
width: auto和height: auto：
img { width: auto; height: auto; }
- 这样设置后，图片的宽度和高度会自动根据原始图片的宽高比例进行调整，以适应容器的大小。图片会根据容器的大小进行缩放，保持比例不失真。
- 使用
object-fit属性：
img { width: 100%; height: 100%; object-fit: contain; /* 可选值：contain、cover、fill、none、scale-down */ }
object-fit属性指定图片如何适应其容器。contain值会保持图片的比例，缩放图片以适应容器，并在容器内居中显示。其他可选值还包括cover、fill、none和scale-down，可以根据需要选择适合的值。- 使用
flexbox或grid布局：
.container { display: flex; /* 或 display: grid; */ } img { width: 100%; height: 100%; object-fit: contain; }
- 使用
flexbox或grid布局可以让容器自动调整图片的大小，以填充整个容器。将图片的宽度和高度设置为100%，并使用适当的布局属性，可以实现自适应宽高。
以上是几种常用的方法，根据实际需求和使用场景选择合适的方法来实现图片的自适应宽高效果。
