网络IO模型的介绍引出nginx的网络IO模型

最新推荐文章于 2024-07-04 10:18:51 发布
原创 最新推荐文章于 2024-07-04 10:18:51 发布 · 220 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#网络io #Nginx #io模型 #服务器开发 #Linux

 

1. 什么是IO？

简单来说就是输入输出

2. 网络IO经历步骤

  1. 用户在获取网络资源是在进入网卡，经过网络七层模型将请求交给nginx用户进程

  2. 用户进程无法直接获取磁盘上的资源，会将请求获取什么资源翻译并转发给内核，内核驱动磁盘寻道找到文件（最耗时间的环节）

  3. 文件同样也不能直接交给用户进程，首先磁盘将文件放至内核缓冲区，然后内核告知用户进程请求的资源结果已准备好（耗时比较短）

  4. 内核缓冲区将文件拷贝一份至用户进程缓冲区，用户进程拿到文件 构建响应报文，通过http回传给用户

 

 

总结：

IO总共要经历两个阶段

1.磁盘读取数据，将数据拷贝至内核缓冲区

2.将内核缓冲区数据拷贝至用户进程缓冲区

 

3. 网络IO模型种类

 

同步阻塞

比如你要去完成这样一件事情，把水烧开，灌入暖瓶

现在给你一口普通的锅，你也不知道水什么时候可以烧开，你决定守在旁边等待水开。

这个时候的你是什么也做不了的，是不是觉得很浪费时间

当水开了就需要你把水灌入暖瓶，你还是做不了其他的事情

 

 

 

 

同步非阻塞

比如还是烧一锅开水，你还是不知道水什么时候会开，你选择了另外一个策略，去忙其它的事情但是要时不时看下谁开没开

 

改进了什么呢？

你可以在空挡时间忙其它的事情

 

增加了什么麻烦呢？

  1. 你得时不时的确认水开没开(就意味着得不停的调用cpu，占用cpu资源）

  2. 可能你上一次刚看的时候水没开，等你刚看完水开了，那就得等下一次查看的时候才能发现，增加了延迟，等你知道了水开了，自己去把水灌好

 

 

 

Linuxc/c++服务器开发高阶视频学习资料+qun720209036获取

更多视频内容包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，MongoDB，ZK，流媒体，P2P，K8S，Docker，TCP/IP，协程，DPDK多个高级知识点分享。

 

异步阻塞

这个就比较二了

假如给你一个智能热水壶，水开了会自动的提醒你的，但是你还是要傻傻的等

完全没有利用好智能热水壶的优势（不做解释）

 

 

同步异步：关注的是消息的通知机制

阻塞非阻塞：关注的是在收到结果之前调用者的状态是等待还是忙自己的事情

 

IO多路复用

还拿烧水的例子

不要你来管水开没开，直接交给一个代理，假如代理名叫select，select在那帮你监控水开没开，捎带他还会看饭有没有煮好，你把所有的事情都交代给它，可以去忙自己的事情了在饭还没熟，水还没开的时候select就处于一个等待的状态，假如这个时候水开了select会水开了的结果写到一个小黑板你可以看到并知道水开了，不需要你去查看水开没开，接下来由你将烧开的水灌进暖瓶（用户进程前半部分不阻塞，后半部份阻塞）

 

 

 

select、poll、epoll的区别

无论是select、poll、epoll都可以面对多个用户进程的请求，它相当于一个代理人，收集很多用户进程的请求，他帮你从磁盘上获取数据，复制到内核中，那么这个数据准备没准备好它的实现机制是不一样的

通知方式：假设有一个用户数据准备好了，那么还有很多用户数据还没有准备好，那么如何通知？

select和poll是遍历扫描，效率低下

epoll采用回调机制，epoll会主动通知，效率更高（nginx支持）

 

信号驱动IO

举例：比如我们的智能热水壶我么设定好烧水以后，会给你一个反馈结果为设定成功，然后你就可以去忙其他的事情了，等到水烧开了会发给你一条短息，这个时候你再回去把水灌入暖瓶

 

 

通知机制： 水平触发：多次通知 边缘触发：只通知一次

 

 

研究一下Socket和IO模型
心有猛虎 细嗅蔷薇
11-10 1153
目录 Socket Socket通信流程 Socket IO模型 IO IO交互过程 IO模型 一、阻塞IO模型 二、非阻塞IO模型 三、IO复用模型 四、信号驱动式IO模型 五、异步IO模型 五大IO模型的比较 关于Socket和WebSocket的区别 Socket 和IP可以标识一台计算机一样，进程在网络里面通信也是需要被唯一标识，那么如果是在一台计算机里，PI...
Redis面试系列：从底层了解IO多路复用模型
Viper的程序员修炼手册
12-04 4247
从底层了解IO多路复用模型 前言 当我们去面试的时候，问到了 redis，nginx，netty他们的底层模型分别是什么？ redis -> epoll nginx-> epoll netty-> epoll? 需要从操作系统的层面上来谈 BIO 当我们开机的时候，首先被加载进内存的是我们的Kernel（内核），内核是用于管理我们的硬件的，同时内核还会创建一个GDT表，然后划分两个空间（用户空间和内核空间），同时空间中的内容是开启了保护模式，无法被修改的。 同时还有一个CPU的概念，C
Nginx高级（四）：nginx网络服务模型
大胡子哥哥
08-18 824
网络服务模型 网络IO的本质是socket的读取，socket在linux中被抽象为流，IO操作可以理解为对流的操作。为了操作系统的安全性等考虑，进程是无法直接操作I/O设备的，其必须通过系统调用请求内核来协助完成I/O动作，而内核会为每个I/O设备维护一个buffer。 整个请求过程可以概括为： 用户进程发起请求，内核接受到请求后，从I/O设备中获取数据到buffer中，再将buffer中的数据copy到用户进程的地址空间，该用户进程获取到数据后再响应客户端。 如下图所示： 在整个请求过程中，数据从IO
180天云计算小白到大神-Nginx基础网络IO模型
weixin_51622071的博客
08-10 347
6Nginx基础网络IO模 型 6Nginx基础网络IO模型 1.IO基本概述 1.1 什么是IO 1.2 什么是网络IO 2.IO网络模型 2.1 同步/异步 2.2 阻塞/非阻塞 2.3 IO组合模型 3.五种常见IO模型 3.1同步阻塞IO 3.2 同步非阻塞IO 3.3 IO多路复用 3.4 信号驱动IO 3.5 异步非阻塞IO 3.6 IO模型对比 4.IO模型实现 4.1 几种网络IO模型实现 4.2 select、poll、epool区别 1.IO基本概述 1.1 什么是IO 所谓 IO，无非
Nginx深入详解之多进程网络模型
12-01 1179
一、进程模型         Nginx之所以为广大码农喜爱，除了其高性能外，还有其优雅的系统架构。与Memcached的经典多线程模型相比，Nginx是经典的多进程模型。Nginx启动后以daemon的方式在后台运行，后台进程包含一个master进程和多个worker进程，具体如下图： 图1 Nginx多进程模型         master进程主要用来管理worker进程，具体包括如
nginx网络IO模型
liwenbo_csu的博客
08-01 1861
nginx支持很多的网络IO模型，不同的平台支持的IO模型也有一定的区别，nginx正常情况下会根据平台自动选择有效的模型， 也可以使用use命令指定需要使用的IO模型。       支持模型列表： 1、select   多路复用，在支持select的平台中会自动编译， --with-select_module和 --without-select_module可以手动的启用改IO
白话Nginx的IO模型
happy_teemo的博客
07-31 768
本文主要介绍linux的5种IO模型，已经nginx和apache的IO模型区别。我会尽量用口语化的语言来解释。 纯属个人理解，如果有不对的地方欢迎指正。 针对结论党 首先先说三个名字： select、poll、epoll 效率： select < poll < epoll 栗子： 学生做题，老师检查 方案1：老师一个个问 — select 方案2：多个老师 — poll 方案3：学生做完了主动回答。— epoll 显然，方案3效率更高。 Linux的5种IO模型 网络IO的本质是socket的
Linux后端服务器网络编程之线程模型丨reactor模型详解
Linuxhus的博客
03-31 372
前言   上一篇文章《后端服务器网络编程之 IO 模型》中讲到服务器端高性能网络编程的核心在于架构，而架构的核心在于进程/线程模型的选择。本文将主要介绍传统的和目前流行的进程/线程模型，在讲进程/线程模型之前需要先介绍一种设计模式： Reactor 模式，不明白的看这里《Reactor 模式详解》，文中有一句话对 Reactor 模式总结的很好，引用下。 对Reactor 模式还不了解的朋友可以看看这个视频讲解：详解网络编程相关的细节处理丨 reactor模型 Reactor 模式首先是事件驱动的，
6. C++网络编程-网络io与io多路复用select/poll/epoll
weixin_45842249的博客
05-15 331
首先看看这个学习计划samba配置可以看这个。
[Holo_wo]-一文说透网络编程中的服务端模型
HL545454的博客
05-22 952
缓存 I/O 又被称作标准 I/O，大多数文件系统的默认 I/O 操作都是缓存 I/O。在 Linux 的缓存 I/O 机制中，操作系统会将 I/O 的数据缓存在文件系统的页缓存（ page cache ）中，也就是说，。在Linux中，对于一次I/O对于一次I/O写入的操作，和上面是类似的，过程相反。
NGINX的IO模型详解
a226433955的博客
10-31 663
普及： 用户空间与内核空间： 现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操作系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。针...
Nginx学习笔记（三）—Nginx的I/O模型详解
ranrancc_的博客
01-18 669
同步阻塞方式，发送方向接收方发送请求后，一直等待响应；接收方处理请求是进行的IO操作如果不能马上得到结果，就一直等到返回结果后，才响应发送方，期间不能进行其他工作。比如、在超时排队付账时，客户（发送方）想收款员（接收方）付款（发送请求）后需要等待收款员找零，期间不能做其他的事情；而收款员要等待收款机返回结果（IO操作）后才能把零钱取出来交给客户（响应请求），期间也只能等待，不能做其他的事情。这种方...
Nginx(二)—IO模型详解
敲代码的小小酥的博客
07-04 357
现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操作系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。
Nginx 网络事件模型
小楼一夜听春雨，深巷明朝卖杏花
12-06 3133
 Oracle 进程结构 Oracle 的进程分为用户进程、服务器进程和后台进程。 用户进程是在客户机内存上运行的程序，在用户请求连接 Oracle 数据库时建立。用户 进程不能直接同 Oracle 服务器交互，而是把操作请求提交给服务进程。服务进程是在用户同 Oracle 数据库建立会话之后自动在服务器端创建的进程。服务进程直接同 Oracle 服务器交互，执行用
就这一次把网路的几种IO模型以及Nginx基本原理彻底搞清楚
Java圈全能架构师的博客
10-25 689
网络IO模型 1.1 网络IO基本概念理解 IO分别表示输入(input)和输出(output)。它描述的是计算机的数据流动的过程，因此IO第一大特征是有数据的流动；那么对于IO的整个过程大体上分为2个部分，第一个部分为IO的调用，第二个过程为IO的执行。IO的调用指的就是系统调用，IO的执行指的是在内核中相关数据的处理过程，这个过程是由操作系统完成的，与程序员无关。 IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通过该进程，目前支持I/O多路复用的系统调用有 s...
redis/nginx/memcached等网络编程模型
weixin_52259848的博客
06-21 601
redis/nginx/memcached等网络编程模型
Nginx专题（1）：进程网络IO模型及工作原理、操作配置
新技术革命
11-12 428
1、什么是nginx? nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器；Nginx可以作为一个HTTP服务器进 行网站的发布处理，另外Nginx可以作为反向代理进行负载均衡的实现。 1.1、Nginx三个主要应用场景 1、静态资源服务（通过本地文件系统提供服务） 2、缓存、负载均衡服务器 3、API服务（OpenResty） 2、为什么选择nginx? （1）更快 这表现在两个方面：一方面，在...
Kubernetes和nginx的关系
最新发布
06-04
<think>嗯，用户想了解Kubernetes和Nginx之间的关系以及它们如何协同工作，特别是集成方式和作用。这个问题很基础但也很重要，涉及到Kubernetes网络架构的核心组件。用户可能正在学习Kubernetes的网络管理部分，或者在工作中需要部署web应用。从引用内容看，用户已经接触过Ingress、Controller等概念，但需要系统化的梳理。用户特别强调"关系"和"协同工作"，说明需要整体框架而非碎片化知识。深入分析用户需求：1）基础关系：Nginx如何从独立服务转变为K8s网络基础设施？2）价值定位：为什么选择Nginx而不是其他负载均衡方案？3）技术动因：K8s需要Nginx解决哪些原生缺陷？引用材料提供了重要线索：引用[5]提到NginxIngressController是"守门人"，这是个很好的切入点。引用[1][2]展示了配置方式的进化，引用[3]则指向定制化需求。引用[4]的架构图特别关键，正好用来解释数据/控制平面协作。构建回答时要注意层次：先解释K8s原生服务暴露方式的局限性，自然引出对7层代理的需求。然后聚焦Nginx的三大价值——这正是用户问的"作用"部分。技术实现上，需要区分控制平面（Controller组件）和数据平面（Nginx进程）的分工，引用[4]的架构图很适用。用户可能忽略的要点在于部署模式差异：传统Nginx是独立部署，而K8s集成后变成动态生成配置的集群组件。补充的自定义部署场景特别重要，引用[3]的自编译案例说明高级用户可能需要这个知识。</think> Kubernetes 与 Nginx 的集成主要体现在 **Nginx Ingress Controller** 的部署和使用上，二者协同工作为集群提供高效、灵活的流量管理和服务暴露能力。以下是核心集成方式及作用： --- ### **1. Nginx Ingress Controller 的角色** **作用**： - **7层负载均衡**：解析 HTTP/HTTPS 请求的 URI、域名等，将流量按规则路由至后端 Service。 - **统一入口网关**：替代 NodePort/LoadBalancer 暴露服务，减少公网 IP 和端口管理成本。 - **高级路由能力**：支持路径重写、SSL 终止、熔断限流、灰度发布等（需搭配 Annotation 或 CRD）。 **集成方式**： - 在 Kubernetes 中部署 **Nginx Ingress Controller**（即独立 Pod），监听 Ingress 资源变化。 - 通过 **ConfigMap** 管理 Nginx 配置模板（如超时时间、日志格式），实现动态更新 [^1][^5]。 --- ### **2. 核心协同流程** ```mermaid graph LR A[用户创建 Ingress 资源] --> B[Ingress Controller 监听到变化] B --> C[生成 Nginx 配置文件] C --> D[重载 Nginx 服务] D --> E[外部请求经 Nginx 路由至后端 Pod] ``` **关键组件交互**（引用自 [^4]）： ``` 监控变化 提供配置 Ingress 资源 --(定义规则)--> ConfigMap --(配置模板)--> Nginx Controller ↑ ↓ 用户定义 动态生成配置并重载 ↓ ↓ Kubernetes API Server ←------------ Nginx 进程 (数据平面) ``` --- ### **3. 典型集成方案** #### **(1) 标准部署（Helm 或 Manifest）** ```bash # 使用 Helm 部署（引用自 [^2]） helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm install nginx-ingress ingress-nginx/ingress-nginx --namespace nginx-ingress ``` **作用**： - 自动创建 Deployment、Service（类型为 LoadBalancer/NodePort）、RBAC 规则等。 - 默认集成 Prometheus 指标接口，便于监控。 #### **(2) 自定义 Nginx 编译集成** **场景**：需要特定模块（如 GeoIP、Lua）或安全加固（引用自 [^3]）。 **步骤**： 1. 从源码编译 Nginx，替换官方镜像中的二进制文件。 2. 构建新 Docker 镜像并推送至私有仓库。 3. 修改 Ingress Controller 的 Deployment 使用自定义镜像。 **优势**：避免云厂商锁定，满足合规性需求。 --- ### **4. 与传统 Nginx 的差异对比** | **维度** | 传统 Nginx | Kubernetes Nginx Ingress Controller | |-------------------|-------------------------------|-------------------------------------------| | **配置方式** | 手动编辑 nginx.conf | 通过 Ingress 资源声明式配置 | | **动态更新** | 需手动重载 `nginx -s reload` | Controller 自动监听并重载 | | **高可用** | 需自建 Keepalived | Kubernetes 自动调度 Pod + Service 负载均衡 | | **扩展性** | 垂直扩容 | 水平扩容（HPA 支持） | --- ### **5. 协同价值总结** 1. **基础设施解耦**： Nginx 作为数据平面处理流量，Kubernetes 控制平面管理声明式配置，职责分离 [^5]。 2. **弹性与自动化**： 结合 HPA 自动扩缩容，无需人工干预流量激增场景。 3. **安全强化**： 集中管理 SSL 证书（如 cert-manager 自动续签），减少配置泄露风险。 4. **多云兼容性**： 统一入口屏蔽底层基础设施差异（AWS/阿里云等）[^4]。 --- **相关问题**： 1. 如何为 Nginx Ingress Controller 配置自定义错误页面？ 2. Nginx Ingress 与 Traefik 的性能差异如何测试？ 3. 如何通过 Ingress 实现金丝雀发布（Canary Release）？ 4. 为什么需要避免在 Pod 内直接部署 Nginx？ > 深度实践可参考官方文档：[Kubernetes Nginx Ingress 项目](https://github.com/kubernetes/ingress-nginx)
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值