OSI七层模式简单通俗理解

本文详细解析了网络通信中的七层协议及其在数据传输过程中的工作原理,从物理层到应用层逐步深入,揭示了每层的功能与作用,强调了各层之间协议的一致性和数据标识的重要性。
网络中的七层协议为:应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。那么介绍一下在网络七层协议中传输数据时的工作原理是:
在数据的实际传输中,发送方将数据送到自己的应用层,加上该层的控制信息后传给表示层;表示层如法炮制,再将数据加上自己的标识传给会话层;以此类推,每一层都在收到的数据上加上本层的控制信息并传给下一层;最后到达物理层时,数据通过实际的物理媒体传到接收方。接收端则执行与发送端相反的操作,由下往上,将逐层标识去掉,重新还原成最初的数据。由此可见,数据通讯双方在对等层必须采用相同的协议,定义同一种数据标识格式,这样才可能保证数据的正确传输。

这个模型学了好多次,总是记不住。今天又看了一遍,发现用历史推演的角度去看问题会更有逻辑,更好记。本文不一定严谨,可能有错漏,主要是抛砖引玉,帮助记性不好的人。总体来说,OSI模型是从底层往上层发展出来的。
 这个模型推出的最开始,是是因为美国人有两台机器之间进行通信的需求。

需求1:

科学家要解决的第一个问题是,两个硬件之间怎么通信。具体就是一台发些比特流,然后另一台能收到。于是,科学家发明了 物理层
主要定义物理设备标准,如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流(就是由1、0转化为电流强弱来进行传输,到达目的地后在转化为1、0,也就是我们常说的数模转换与模数转换)。这一层的数据叫做比特。

需求2:

现在通过电线我能发数据流了,但是,我还希望通过无线电波,通过其它介质来传输。然后我还要保证传输过去的比特流是正确的,要有纠错功能。
于是,发明了 数据链路层
定义了如何让格式化数据以进行传输,以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正,以确保数据的可靠传输。

需求3:

现在我能发正确的发比特流数据到另一台计算机了,但是当我发大量数据时候,可能需要好长时间,例如一个视频格式的,网络会中断好多次(事实上,即使有了物理层和数据链路层,网络还是经常中断,只是中断的时间是毫秒级别的)。
那么,我还须要保证传输大量文件时的准确性。于是,我要对发出去的数据进行封装。就像发快递一样,一个个地发。
于是,先发明了 传输层(传输层在OSI模型中,是在网络层上面)
例如TCP,是用于发大量数据的,我发了1万个包出去,另一台电脑就要告诉我是否接受到了1万个包,如果缺了3个包,就告诉我是第1001,234,8888个包丢了,那我再发一次。这样,就能保证对方把这个视频完整接收了。
例如UDP,是用于发送少量数据的。我发20个包出去,一般不会丢包,所以,我不管你收到多少个。在多人互动游戏,也经常用UDP协议,因为一般都是简单的信息,而且有广播的需求。如果用TCP,效率就很低,因为它会不停地告诉主机我收到了20个包,或者我收到了18个包,再发我两个!如果同时有1万台计算机都这样做,那么用TCP反而会降低效率,还不如用UDP,主机发出去就算了,丢几个包你就卡一下,算了,下次再发包你再更新。
TCP协议是会绑定IP和端口的协议,下面会介绍IP协议。

需求4:

传输层只是解决了打包的问题。但是如果我有多台计算机,怎么找到我要发的那台?或者,A要给F发信息,中间要经过B,C,D,E,但是中间还有好多节点如K.J.Z.Y。我怎么选择最佳路径?这就是路由要做的事。
于是,发明了 网络层。即 路由器交换机那些具有寻址功能的设备所实现的功能。这一层定义的是IP地址,通过IP地址寻址。所以产生了IP协议。

需求5:

现在我们已经保证给正确的计算机,发送正确的封装过后的信息了。但是用户级别的体验好不好?难道我每次都要调用TCP去打包,然后调用IP协议去找路由,自己去发?当然不行,所以我们要建立一个自动收发包,自动寻址的功能。
于是,发明了 会话层。会话层的作用就是建立和管理应用程序之间的通信。

需求6:

现在我能保证应用程序自动收发包和寻址了。但是我要用Linux给window发包,两个 系统语法不一致,就像安装包一样,exe是不能在linux下用的,shell在window下也是不能直接运行的。于是需要 表示层(presentation),帮我们解决不同系统之间的通信语法问题。

需求7:

OK,现在所有必要条件都准备好了,我们可以写个android程序,web程序去实现需求了。

补充:

Socket:
这不是一个协议,而是一个通信模型。其实它最初是伯克利加州分校软件研究所,简称BSD发明的,主要用来一台电脑的两个进程间通信,然后把它用到了两台电脑的进程间通信。所以,可以把它简单理解为进程间通信,不是什么高级的东西。主要做的事情不就是:
A发包:发请求包给某个已经绑定的端口(所以我们经常会访问这样的地址182.13.15.16:1235,1235就是端口);收到B的允许;然后正式发送;发送完了,告诉B要断开链接;收到断开允许,马上断开,然后发送已经断开信息给B。
B收包:绑定端口和IP;然后在这个端口监听;接收到A的请求,发允许给A,并做好接收准备,主要就是清理缓存等待接收新数据;然后正式接收;接受到断开请求,允许断开;确认断开后,继续监听其它请求。
可见,Socket其实就是I/O操作。Socket并不仅限于网络通信。在网络通信中,它涵盖了网络层、传输层、会话层、表示层、应用层——其实这都不需要记,因为Socket通信时候用到了IP和端口,仅这两个就表明了它用到了网络层和传输层;而且它无视多台电脑通信的系统差别,所以它涉及了表示层;一般Socket都是基于一个应用程序的,所以会涉及到会话层和应用层。
<think>好的,我现在要帮用户分析LVS、Nginx和HAProxy的联系与区别。用户希望用列表形式,结合专业术语、通俗例子和实际应用案例。首先,我需要回忆这三者的基本功能和特点。 根据之前的对话和引用内容,用户已经了解一些关于HAProxy和Nginx的知识。引用[2]提到HAProxy是专业的负载均衡器,而Nginx最初是HTTP服务器,后来增加了负载均衡功能。引用[3]详细说明了Nginx的优点,比如七层处理、正则匹配强大,适合做反向代理和静态资源服务器。引用[4]讨论了正向代理和反向代理的区别,提到Nginx和HAProxy在反向代理中的应用。 接下来,用户想了解LVS、Nginx和HAProxy的联系与区别。LVS是四层负载均衡,工作在传输层,而Nginx和HAProxy主要在七层应用层。需要比较它们的OSI层级、协议支持、调度算法、性能等。 首先,联系部分:三者都用于负载均衡,提升系统可用性。区别方面,LVS在四层,性能高但功能较少;Nginx和HAProxy在七层,功能更丰富。需要结合专业术语,比如四层基于IP和端口,七层基于HTTP头或内容。还要举例子,比如LVS像快递分拣中心,Nginx像智能导购,HAProxy像专业调度员。 实际应用案例部分,LVS用于高并发电商,Nginx处理动静分离,HAProxy用于金融交易系统。需要确保案例贴合各自特点,比如LVS处理大流量,Nginx处理静态资源,HAProxy处理复杂调度。 还要注意引用之前的资料,比如引用[3]提到Nginx的稳定性和抗高并发,引用[2]比较了四层和七层负载均衡。确保回答准确,同时结构清晰,分联系、区别、案例三个部分。检查是否有遗漏点,比如健康检查机制、会话保持等,是否需要提到。最后总结适用场景,帮助用户理解如何选择。</think>### LVS、Nginx、HAProxy 综合对比分析 以下从**技术层级**、**功能特性**和**应用场景**三个维度进行系统性对比,结合专业术语、通俗类比及实际案例说明。 --- #### **一、核心联系** | 维度 | 共同点 | 差异点 | |--------------|------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------| | **核心目标** | 均用于**负载均衡**,提升系统可用性与扩展性 | LVS专注**四层流量分发**,Nginx/HAProxy侧重**七层应用控制**[^2][^4] | | **架构定位** | 可作为**反向代理**,隐藏后端服务器细节 | LVS需配合内核模块(如IPVS),Nginx/HAProxy独立实现代理逻辑[^3][^4] | | **故障处理** | 支持**健康检查**机制(如端口探测、HTTP状态码验证) | LVS检查粒度较粗(TCP层),Nginx/HAProxy可精细化(如响应内容匹配)[^3] | --- #### **二、核心区别** | 对比项 | LVS (Linux Virtual Server) | Nginx | HAProxy | |--------------|---------------------------------------------------------|--------------------------------------------|--------------------------------------------| | **OSI层级** | 四层(传输层) | 七层(应用层) | 四层/七层模式[^2] | | **协议支持** | TCP/UDP | HTTP/HTTPS/WebSocket | TCP/HTTP/MySQL/RDP等[^2] | | **调度算法** | 轮询(RR)、加权轮询(WRR)、最小连接(LC)等 | 加权轮询、IP哈希、最少连接 | 动态加权、基于响应时间、URI哈希等[^3] | | **性能极限** | 百万级并发(内核态转发) | 10万级HTTP并发 | 50万级TCP会话 | | **配置复杂度**| 需内核模块+复杂iptables规则 | 声明式配置,易读性强 | 专业级配置模板,支持条件逻辑[^3] | | **会话保持** | 依赖IP哈希或持久连接超时 | Cookie插入/JWT绑定 | Stick-table动态会话跟踪 | | **典型场景** | 金融交易系统流量入口 | 电商网站动静分离 | 微服务API网关 | --- #### **三、通俗例子对比** | 组件 | 类比对象 | 场景说明 | |--------|-------------------------|--------------------------------------------------------------------------| | **LVS** | **快递分拣中心** | 仅根据包裹大小(类似四层端口)快速分拣,不关心包裹内容(七层数据) | | **Nginx** | **智能导购机器人** | 能理解顾客需求(HTTP请求头),动态推荐商品(URL路由),还能展示样品(静态资源)| | **HAProxy** | **专业调度员** | 根据货物类型(协议)、运输优先级(权重)、实时路况(响应时间)动态分配任务 | --- #### **四、实际应用案例** 1. **LVS案例:高并发证券交易系统** - 场景:某券商交易系统需处理每秒20万笔TCP订单 - 方案:LVS DR模式 + Keepalived,实现订单流量四层分发 - 优势:零拷贝技术减少延迟,内核级转发保障吞吐量[^2] 2. **Nginx案例:内容分发网络(CDN)** - 场景:视频网站需要缓存热门资源并就近分发 - 方案:Nginx + `proxy_cache`模块,通过`location`规则匹配文件类型缓存策略 - 关键配置: ```nginx location ~* \.(mp4|flv)$ { proxy_cache video_cache; proxy_pass http://video_backend; } ``` 3. **HAProxy案例:金融支付网关** - 场景:需对API调用进行熔断和灰度发布 - 方案:HAProxy + `http-check` + `acl`规则,实现: - 故障节点自动隔离(`fall 3`) - 新版本API灰度路由(基于Cookie标识) - 监控指标:`queue_current`监控请求队列深度 --- #### **五、技术选型决策树** ``` 是否需要七层协议解析? ├─ 否 → LVS(高性能四层负载) └─ 是 → 是否需要复杂条件路由? ├─ 否 → Nginx(简单HTTP控制+静态服务) └─ 是 → HAProxy(高级会话管理+动态调度) ``` --- #### 相关问题 1. LVS的DR模式与NAT模式在性能上有何本质差异? 2. 如何通过Nginx实现基于地理位置的负载均衡?[^3] 3. HAProxy的`stick-table`如何实现跨多后端服务的会话一致性?
评论 4
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值