计算机网络-OSI 七层模型

1. 网络协议的分层模型

计算机网络的核心是 “分层协议栈”,最经典的是OSI 七层模型(物理层、数据链路层、网络层、传输层、会话层、表示层、应用层)和实际应用中更常用的TCP/IP 四层模型(网络接口层、网络层、传输层、应用层)。

分层的目的是 “分工明确、各司其职”:

  • 每一层只处理特定任务,例如:
    • 物理层:负责电信号 / 光信号的传输(二进制 0/1 的物理载体);
    • 数据链路层:处理设备间的直接连接(如 MAC 地址、以太网帧);
    • 网络层:负责跨网络的路由(如 IP 地址、路由选择);
    • 传输层:负责端到端的数据可靠传输(如 TCP 的重传、UDP 的无连接);
    • 应用层:处理具体的业务逻辑(如 HTTP、FTP、聊天协议)。
  • 数据传输时,通常需要从应用层逐层向下封装(每一层添加本层的头部信息),到达目标设备后再从物理层逐层向上解封装(每一层移除本层头部,交给上层)。

二、“跳过部分层次” 的场景与原理

正常情况下,数据包必须经过完整的分层处理(封装→传输→解封装)才能完成通信。但在某些特殊需求下(如性能优化、底层调试),可以人为让数据包跳过部分层次,核心原因是:分层是逻辑上的分工,而非物理上的强制限制,底层硬件和驱动可以被直接操控。

可以把网络分层理解成 “快递运输的分工流程”—— 就像寄快递要经过 “发件人→快递点→中转站→目的地快递点→收件人” 多个环节,每个环节只干自己的事,网络通信也把复杂的传输过程拆成多个 “分层”,每层专注一件事,最后合力完成数据传递。

下面用 “你用微信给朋友发消息” 的例子,逐个解释每层的作用:

1. 应用层:“打包要寄的东西”

  • 作用:处理 “人类能看懂的内容”,并按照应用自己的规则打包。
  • 举例:你在微信里输入 “吃了吗?”,微信会先把这句话按照自己的聊天协议(比如加密、加上发送时间、头像信息等)处理成 “应用层数据”,就像你把想寄的文件装进一个写着 “给朋友的信” 的信封里。
  • 常见协议:HTTP(网页)、FTP(传文件)、微信 / QQ 的私有协议等。

2. 传输层:“写清楚收件人是谁家的哪个房间”

  • 作用:给应用层的数据加上 “端口号”,确保数据能准确送到对方设备上的对应程序(比如微信、浏览器)。
  • 举例:微信的应用层数据传到传输层后,会被加上 “源端口”(你手机上微信进程的端口,比如 12345)和 “目标端口”(你朋友手机上微信进程的端口,比如 67890)。这就像快递单上写 “收件人:朋友家,302 房间”(端口 = 房间号),确保快递不会送错房间。
  • 常见协议
    • TCP:像 “挂号信”,传输前先确认对方收到,丢了会重发(适合聊天、文件传输等需要可靠的场景);
    • UDP:像 “普通平信”,发了就不管,速度快但可能丢(适合视频通话、游戏等需要快的场景)。

3. 网络层:“写清楚收件人的地址”

  • 作用:给传输层的数据加上 “IP 地址”,负责找到 “对方设备” 在哪个网络位置。
  • 举例:加上端口号的数据传到网络层后,会被加上 “源 IP”(你手机的 IP,比如 192.168.1.2)和 “目标 IP”(你朋友手机的 IP,比如 10.0.0.5)。这就像快递单上写 “收件人地址:北京市朝阳区 XX 小区”(IP = 小区地址),确保快递能找到大致区域。
  • 核心协议:IP 协议(所以常说 “TCP/IP 协议”,IP 就是网络层的核心)。

4. 数据链路层:“写清楚邻居是谁,怎么传到下一个节点”

  • 作用:给网络层的数据加上 “MAC 地址”,负责在 “相邻设备” 之间传输(比如你家路由器→小区路由器→朋友家路由器)。
  • 举例:带 IP 的数据传到数据链路层后,会被加上 “源 MAC”(你手机的网卡地址,比如 AA:BB:CC:DD:EE:FF)和 “目标 MAC”(你家路由器的 MAC 地址)。这就像快递在小区内传递时,快递员先看 “下一个中转站是小区门口的快递柜”(MAC = 快递柜的编号),确保能传到下一站。
  • 常见场景:同一局域网内的设备通信(比如你手机连家里 WiFi,和路由器之间的传输)。

5. 物理层:“把数据变成电信号 / 光信号传出去”

  • 作用:把数据链路层的二进制数据转换成物理信号(比如网线里的电信号、WiFi 的无线电波、光纤里的光信号),通过物理介质(网线、空气、光纤)传输。
  • 举例:数据链路层的二进制数据(010110...)被转换成电信号(高电平 = 1,低电平 = 0),通过你家的 WiFi 信号发出去,就像快递员把包裹装进货车,开上公路(物理介质 = 公路)。

总结:分层就像 “接力赛”,每层只干一件事

  1. 你发微信消息→应用层打包内容;
  2. 传输层加上端口(确保到对方微信);
  3. 网络层加上 IP(确保到对方设备);
  4. 数据链路层加上 MAC(确保在相邻设备间传递);
  5. 物理层变成电信号 / 光信号传出去;
  6. 对方设备收到后,从物理层到应用层反向拆解,最后朋友的微信显示 “吃了吗?”。

这样分工的好处是:每层只关心自己的任务,不用管其他层。比如微信只需要处理聊天内容(应用层),不用管信号怎么变成电信号(物理层),就像你寄快递不用管货车怎么开,效率更高。

分布式微服务企业级系统是一个基于Spring、SpringMVC、MyBatis和Dubbo等技术的分布式敏捷开发系统架构。该系统采用微服务架构和模块化设计,提供整套公共微服务模块,包括集中权限管理(支持单点登录)、内容管理、支付中心、用户管理(支持第三方登录)、微信平台、存储系统、配置中心、日志分析、任务和通知等功能。系统支持服务治理、监控和追踪,确保高可用性和可扩展性,适用于中小型企业的J2EE企业级开发解决方案。 该系统使用Java作为主要编程语言,结合Spring框架实现依赖注入和事务管理,SpringMVC处理Web请求,MyBatis进行数据持久化操作,Dubbo实现分布式服务调用。架构模式包括微服务架构、分布式系统架构和模块化架构,设计模式应用了单例模式、工厂模式和观察者模式,以提高代码复用性和系统稳定性。 应用场景广泛,可用于企业信息化管理、电子商务平台、社交应用开发等领域,帮助开发者快速构建高效、安全的分布式系统。本资源包含完整的源码和详细论文,适合计算机科学或软件工程专业的毕业设计参考,提供实践案例和技术文档,助力学生和开发者深入理解微服务架构和分布式系统实现。 【版权说明】源码来源于网络,遵循原项目开源协议。付费内容为本人原创论文,包含技术分析和实现思路。仅供学习交流使用。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值