Linux里面tcp协议属于四层服务吗？

TCP/IP 的分层管理

TCP/IP 协议按照层次分为 4 层：应用层、传输层、网络层、数据链路层。 对于分层这个概念，大家一定不陌生，比如我们的分布式架构体系中会分为业务层、服务层、基础支撑层。比如docker，也是基于分层来实现。所以我们会发现，复杂的程序都需要分层，这个是软件设计的要求，每一层专注于当前领域的事情。如果某些地方需要修改，我们只需要把变动的层替换掉就行，一方面改动影响较少，另一方面整个架构的灵活性也更高。 最后，在分层之后，整个架构的设计也变得相对简单了。

分层负载

了解了分层的概念以后，我们再去理解所谓的二层负载、三层负载、四层负载、七层负载就容易多了。

一次 http 请求过来，一定会从应用层到传输层，完成整个交互。只要是在网络上跑的数据包，都是完整的。可以有下层没上层，绝对不可能有上层没下层。

二层负载

二层负载是针对 MAC，负载均衡服务器对外依然提供一个 VIP（虚 IP），集群中不同的机器采用相同 IP 地址，但是机器的 MAC 地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标 MAC 地址的方式将请求转发到目标机器实现负载均衡

二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址

三层负载均衡

三层负载是针对 IP，和二层负载均衡类似，负载均衡服务器对外依然提供一个 VIP（虚 IP），但是集群中不同的机器采用不同的 IP 地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过 IP 将请求转发至不同的真实服务器

三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址

四层负载均衡

四层负载均衡工作在 OSI 模型的传输层，由于在传输层，只有 TCP/UDP 协议，这两种协议中除了包含源 IP、目标 IP 以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。

四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器

七层负载均衡

七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 http、radius、dns 等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web 服务器的负载均衡，除了根据 IP 加端口进行负载外，还可根据七层的 URL、浏览器类别来决定是否要进行负载均衡

比如：在nginx层做7层均衡，让一个uid的请求尽量落到同一个机器上

分层解耦是最常见也被认为是最入门级的架构能力。看似简单，实质具有非常深刻的内涵。

分层的依据有两点，一是职责，另一个是特征。基于职责，软件实体可以根据负载的任务类型不同，把同质化的功能、能力聚合到一个层次中。无论是云计算的IaaS、PaaS、SaaS分层，还是系统软件、中间件、应用分层，还是前后台分层等等，都是基于软件负载的

实质是隔离关注点。依据是软件不同部分具有高度一致的本质。比如WEB开发常见的前端、后端分离，就是建立在前后端具有不同的关注点前提上。前端关注不同的渠道灵活快速支持和用户体验，后端关注服务的沉淀、稳定可靠以及性能容量。<br>当前比较常见的分层还有将领域和应用进行分层，从而获得一个比较稳定的领域能力层，这个是DDD的基本主张，也是当前各种领域PaaS存在的理论参照系。

解耦的实质是分离变化点，这是一种适合不同粒度、不同层次的变化点分离架构方法。大到上面的分层，小到一个功能内的两个实现类，都可以找到解耦方法的影子。

分层与解耦的一个关键**挑战**是最容易被忽略的是只有分和解，没有合。因为软件系统作为一个整体而言，用户对其完成一系列业务case的完整性并没有随着解耦而消失，同时这才是软件产品的根本任务。而解耦只是软件研发组织的内部诉求，不是用户诉求。所以解了以后还要合。“合”比“解”的难度更大。解的同时要考虑合，合要基于解的结果。因此没有先后顺序，要同时考虑解耦与合并才能真正完成“解耦”。

分层是解耦的特例，是完成系统level0的解耦。就企业IT软件看，是完成用户界面、业务逻辑/应用、数据存储几大类IT任务的解耦。围绕着分层有一系列的“合”解决方案的现成实例，如sevlet规范解决界面与业务逻辑的合，jdbc解决业务逻辑与数据存储的合，各类中间件sdk解决业务应用与中间件服务的合。

因此，分层解耦是IT架构最基本也是最有内涵的架构方法。

模块化和简单性是软件工程的基石。蒂姆博纳斯这句充满哲理性的名言可以说准确指明了分层解耦的最终目标或者说最终结果。无论是层次还是一个个有边界的逻辑聚合软件实体，都是一个个模块。无论是高层次的基于特定场景的企业应用、个人消费者应用，亦或是低层次的系统软件，如Linux、Oracle，甚至是编译器软件等等，任何一款软件产品、原型，它的设计者、实现者都会把整个软件系统划分为一个个相互协作的单元，分别实现，再统一整合。这就是软件部分与整体的哲学，是软件实体的内在规律。简单性可以基于划分后的单元是否足够聚焦，是否职责趋于单一。这种简单性你可以通过

分层解耦的好坏取决于软件设计、实现者的水平。主要包括以下几个方面：

* 领域经验，是否能够洞察待解决问题的核心本质，构思软件系统解决方案，这一能力要求必须准确的把握整体解决方案的核心能力要求。基于对整体的理解，进而识别出构成整体的要素，分解为功能层次和单元。

* 技术能力，也就是软件实现能力。必须清晰的为解决方案寻求最佳技术路径。包括技术的能力、竞争力和演进趋势，约束。

组织分工，构建大规模软件的工程基础。

---