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，甚至是编译器软件等等，任何一款软件产品、原型，它的设计者、实现者都会把整个软件系统划分为一个个相互协作的单元，分别实现，再统一整合。这就是软件部分与整体的哲学，是软件实体的内在规律。简单性可以基于划分后的单元是否足够聚焦，是否职责趋于单一。这种简单性你可以通过

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

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

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

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

概要设计阶段通常得到软件结构图

详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等

概要设计和详细设计

在软件设计中，大家经常问到的一个问题是：概要设计应该怎样一个概要法，详细设计应该怎样一个详细法？

这个问题在公司内部经常有人问。现在陈述一下。

我们公司的研发流程是瀑布型的，这个模型中的分析、设计阶段是基于经典的结构化方法。

结构化设计方法的基本思路是：按照问题域，将软件逐级细化，分解为不必再分解的的模块，每个模块完成一定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。模块的概念，和编程语言中的子程序或函数是对应的。

这样一来，设计可以明显地划分成两个阶段：

概要（结构）设计阶段：把软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块间调用关系和接口。

详细设计阶段：依据概要设计阶段的分解，设计每个模块内的算法、流程等。

概要设计阶段：

在这个阶段，设计者会大致考虑并照顾模块的内部实现，但不过多纠缠于此。主要集中于划分模块、分配任务、定义调用关系。模块间的接口与传参在这个阶段要定得十分细致明确，应编写严谨的数据字典，避免后续设计产生不解或误解。概要设计一般不是一次就能做到位，而是反复地进行结构调整。典型的调整是合并功能重复的模块，或者进一步分解出可以复用的模块。在概要设计阶段，应最大限度地提取可以重用的模块，建立合理的结构体系，节省后续环节的工作量。

概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据，各个模块的详细设计就可以并行展开了。

详细设计阶段：

在这个阶段，各个模块可以分给不同的人去并行设计。在详细设计阶段，设计者的工作对象是一个模块，根据概要设计赋予的局部任务和对外接口，设计并表达出模块的算法、流程、状态转换等内容。这里要注意，如果发现有结构调整（如分解出子模块等）的必要，必须返回到概要设计阶段，将调整反应到概要设计文档中，而不 能就地解决，不打招呼。

详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。一个模块一篇详细设计文档。

概要设计文档相当于机械设计中的装配图，而详细设计文档相当于机械设计中的零件图。文档的编排、装订方式也可以参考机械图纸的方法。

我们公司对模块的认识和传统定义有所不同，认为是较大的软件功能单元才可以称作模块。这种认识使大家对概要设计和详细设计的分工产生了混乱的理解，降低了文档的可用性，应该予以纠正。

概要设计中较顶层的部分便是所谓的方案。方案文档的作用是在宏观的角度上保持设计的合理性。

有的项目采用面向对象的分析、设计方法。可能在概要设计、详细设计的分工上疑问更多。其实，面向对象的分析、设计方法并没有强调结构化方法那样的阶段性，因此一般不引入概要、详细设计的概念。如果按照公司的文档体系，非要有这种分工的话，可以将包的划分、类及对象间的关系、类的对外属性、方法及协作设计看做 概要设计；类属性、方法的内部实现看做详细设计。

1.需求分析--产生软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。不涉及具体实现方法。用户能看得明白，开发人员也可据此进行下面的工作（概要设计）。

2.概要设计--产生软件概要设计说明书，说明系统模块划分、选择的技术路线等，整体说明软件的实现思路。并且需要指出关键技术难点等。

3.详细设计--产生软件详细设计说明书，对概要设计的进一步细化，一般由各部分的担当人员依据概要设计分别完成，然后在集成，是具体的实现细节。理论上要求可以照此编码。

概要设计和详细设计的区别与联系

软件设计采用自顶向下、逐次功能展开的设计方法，首先完成总体设计，然后完成各有机组成部分的设计。

根据工作性质和内容的不同，软件设计分为概要设计和详细设计。概要设计实现软件的总体设计、模块划分、用户界面设计、数据库设计等等；详细设计则根据概要设计所做的模块划分，实现各模块的算法设计，实现用户界面设计、数据结构设计的细化，等等。

概要设计是详细设计的基础，必须在详细设计之前完成，概要设计经复查确认后才可以开始详细设计。概要设计，必须完成概要设计文档，包括系统的总体设计文档、以及各个模块的概要设计文档。每个模块的设计文档都应该独立成册。

详细设计必须遵循概要设计来进行。详细设计方案的更改，不得影响到概要设计方案；如果需要更改概要设计，必须经过项目经理的同意。详细设计，应该完成详细设计文档，主要是模块的详细设计方案说明。和概要设计一样，每个模块的详细设计文档都应该独立成册。

概要设计里面的数据库设计应该重点在描述数据关系上，说明数据的来龙去脉，在这里应该结合我们的一个结果数据，说明这些结果数据的源点，我们这样设计的目的和原因。详细设计里的数据库设计就应该是一份完善的数据结构文档，就是一个包括类型、命名、精度、字段说明、表说明等内容的数据字典。

概要设计里的功能应该是重点在功能描述，对需求的解释和整合，整体划分功能模块，并对各功能模块进行详细的图文描述，应该让读者大致了解系统作完后大体的结构和 *** 作模式。详细设计则是重点在描述系统的实现方式，各模块详细说明实现功能所需的类及具体的方法函数，包括涉及到的sql语句等。

---