建网目标与应用需求分析：从近期到最终目标的网络建设策略
1、网络建设目标分析网络建设目标分析内容包括最终目标分析和短期目标分析。
1.1 最终目标分析
最终的目标分析内容包括：
1.2 短期目标分析
网络建设的短期目标一般比较具体，容易实现，但需要注意的是：（1）短期建设目标确定的网络方案必须有利于向最终建设目标升级扩展; （2）在升级扩建到最终建设目标的过程中，尽量将投资保留在近期建设目标上。
2. 应用需求分析 2.1 应用背景要求
在确定应用目标之前，需要分析应用背景需求，总结当前网络应用的技术背景，明确行业应用的方向和技术趋势，以及企业网络信息化的必然性。同时，应用背景需求分析需要考虑网络集成的实施问题，包括国外同行业的信息化程度以及取得了哪些成果、国外同行业的信息化趋势、网络集成的目的等。企业的信息化程度，以及企业打算采用的信息化程度。步骤等
(1)网络应用目标分析的工作步骤包括：
(2) 典型的网络设计目标包括：
（3）明确网络设计项目的范围，包括：
2.2 网络应用限制
网络规划设计是一个严格的科学技术实施过程，其间存在大量的制约因素。
（1）针对政策、法律法规的约束，需求分析阶段应做到以下几点：
(2)关于预算和成本约束，需求分析阶段应做到以下几点：
(3)关于时间限制，需求分析阶段应做到以下几点：
3. 网络性能分析
网络规划设计具有严谨、科学的技术指标，可以实现对设计的网络性能的量化分析。因此，在网络需求分析阶段，需要确认网络性能的技术指标。许多国际组织都定义了明确的网络性能技术指标。这些指标为我们设计网络提供了性能基线（），主要分为两类：
3.1 延迟
延迟是从网络一端发送一位到网络另一端接收该位所需的时间。
总时延=传播时延+发送时延+重传时延+分组交换时延+排队时延
3.2吞吐量()
吞吐量是单位时间内传输无差错数据的能力。可以为特定连接或会话定义吞吐量，也可以定义网络的总体吞吐量。
3.3 容量()
容量是数据通信设备执行其预期功能的能力，通常描述通信通道或连接的能力。
3.4 网络负载
网络负载用G表示，指单位时间内发送的平均帧数：
吞吐量=GP[发送成功]
3.5 丢包率（Loss Rate）
丢包率是指一定时间内两点之间传输过程中丢失的数据包与发送的数据包总数的比值，也称为丢失率。该指标是反映网络状况最直接的指标。无拥塞时，路径丢包率为0，轻度拥塞时，丢包率为1%~4%，严重拥塞时，丢包率为5%~15%。一般来说，丢包的主要原因是路由器的缓冲队列溢出。与丢包率相关的一个指标是“误码率”，也称为“误码率”，但这个值通常极小。
3.6 时延抖动()
延迟抖动是指数据包单向延迟的变化。变化量小于时延的1%~2%，即对于平均时延为200ms的数据包，时延抖动为2~4ms。延迟抖动对视频和音频干扰的影响最大。下图展示了上述新网络指标之间的关系。
3.7 带宽()
https://img2.baidu.com/it/u=2670068629,1743225242&fm=253&fmt=JPEG&app=120&f=JPEG?w=500&h=631
带宽分为瓶颈带宽和可用带宽。瓶颈带宽是指两台主机之间的路径上最小带宽链路（ link）的值；可用带宽是指当时该路径上可以传输的最大带宽。下表列出了几种典型应用的带宽需求：
应用
带宽
个人计算机通信
14.4kbit/s~/s
数字音频
1Mbit/s~2Mbit/s
压缩音频
2Mbit/秒~/秒
文件备份
/秒~/秒
未压缩的视频
1Gbit/s~2Gbit/s
3.8 响应时间（Time）
响应时间是指从服务器发出请求到收到响应所花费的时间。常用于特指客户端向主机交互发出请求并获得响应信息所需的时间。这也是用户比较关心的网络性能指标。一般来说，当响应时间超过100ms时，就会引起不良反应；如果超过100ms，就会意识到等待网络传输。
3.9 利用()
利用率是指设备的最大容量。例如，网络监控工具显示某个网段的利用率为30%，这意味着有30%的容量正在使用中。在网络分析和设计中，通常考虑两种利用率：CPU利用率和链路利用率。
3.10 效率()
效率是指产生所需输出所需的系统开销。网络效率指定发送通信所需的开销，无论开销是由冲突、错误、重定向还是确认引起的。目前，提高网络效率的主要方法包括：（1）尝试增加MAC层允许的最大帧长度； (2)使用长帧要求链路层有较低的误码率。
3.11 可用性()
可用性是指网络或网络设备可用于执行预期任务的总时间（百分比）。 IP可用性指标用于衡量IP网络的性能，因为许多IP应用的性能直接取决于IP数据包丢失指标；当丢包率指标超过设定阈值时，许多应用程序将变得不可用。因此，该指标反映了IP丢包率对应用性能的影响。
3.12 可扩展性()
可扩展性是指网络技术或设备随着用户需求的增长而扩展的能力。
3.13 安全（）
安全的总体目标是安全问题不应干扰开展业务的能力。
3.14 可管理性()
可管理性 每个用户可能有不同的网络可管理性目标。
3.15 适应性()
适应性是指当用户改变应用需求时网络的适应能力。
3.16 可购买性()
可承受性是基于在给定的财务成本下最大化通信量的目标。
4. 网络流量分析
分析确定当前网络流量和未来网络容量需求是网络规划和设计的基础。具体内容包括：
具体步骤包括：
https://img1.baidu.com/it/u=3975081575,1623349768&fm=253&fmt=JPEG&app=138&f=JPEG?w=608&h=340
分析网络通信流量特征包括识别网络通信的源和目的地，分析源和目的地之间数据传输的方向和对称性。在某些应用中，流量是双向对称的；在某些应用中，它不具有这些特性。例如，客户端发送少量查询数据，而服务器发送大量数据；在广播应用中，流量是单向不对称的。
在分析网络流量的最后，还需要对现有的网络流量进行测量：一是主动测量，通过主动发送测试包序列来测量网络行为；另一种是被动测量，被动捕获通过测试点的流量。数据包来测量网络行为。通信流量的类型包括客户端/服务器（C/S）、点对点（P2P）、分布式计算等。估计的通信负载一般包括应用的性质、每次通信的流量大小、传输对象、并发数、每天各种应用的使用频率等。
5.安全需求分析
满足基本的安全要求是网络成功运行的必要条件。在此基础上提供强有力的安全保障是网络系统安全的重要原则。网络内部署了大量的网络设备和服务器。保护这些设备的正常运行，维护主要业务系统的安全，是网络的基本安全要求。针对各种网络攻击，如何抵御和检测网络攻击并提供跟踪攻击的手段，同时提供灵活高效的网络通信和信息服务，是网络的基本安全要求。主要情况如下：
与普通的网络应用不同，应用系统是网络功能的核心。应用系统应具有最高的网络安全措施。应用系统的安全体系应包括以下内容：
网络平台将支持多种应用系统，每种系统都需要不同程度地充分考虑平台安全与平台性能和功能之间的关系。通常，系统安全性与性能和功能具有矛盾的关系。如果一个系统不向外界提供任何服务，外界就不可能对其构成安全威胁。但是，如果我们要提供更多的服务，把网络建设成一个开放的网络环境，各种安全问题，包括系统级的安全问题也会随之出现。
6.网络容灾分析
容灾技术是系统高可用技术的组成部分。容灾系统更注重处理外部环境对系统的影响，尤其是灾难性事件对整个IT节点的影响，提供节点级的系统恢复功能。根据容灾系统对灾难的抵抗程度，可以分为数据容灾和应用容灾。
数据容灾是指建立异地数据系统，实时复制本地系统的关键应用数据。当灾难发生时，异地系统可以快速接管本地系统，保证业务连续性。
应用容灾比数据容灾更高层次，即在异地建立相当于本地数据系统的完整备份应用系统。灾难发生后，远程应用系统迅速接管或承担本地应用系统的业务运行。
设计容灾备份系统需要考虑很多因素，如备份/恢复数据量、应用数据中心与备份数据中心之间的距离和数据传输方式、灾难发生时所需的恢复速度、备份中心等。根据这些因素和不同的应用场景，容灾备份通常可以分为4个级别：
7. 需求说明
通过需求收集工作，网络设计人员将获得大量的需求信息，这些信息由各种独立的表格、分散的文本和一些统计数据组成。这些需求信息应该整合到正式的需求说明书中，以方便后期的设计。 ，进行实施和维护工作。需求规格说明书是网络设计过程中第一个可以流通的正式且重要的文件。其目的是对收集到的需求信息进行清晰的总结和组织。
7.1 数据准备
数据准备是开始准备需求说明书的前期工作，主要分为两个步骤：
另外，需求收集阶段产生的各种资料，包括手册、报告、原始文件等，应进行编目归档，以备后用。
7.2 需求说明书的构成
编写需求陈述的目的是为管理者提供决策信息，因此需求陈述应尽可能简洁、信息丰富，以节省管理者的时间。网络需求规范有两个要求：
（1）无论需求规格说明书采用何种组织形式，都应包括业务、用户、应用、计算机平台、网络五个方面的需求。
(2)为了规范需求说明书的编制，一般来说，需求说明书应包括以下五个部分：
①概述。
需求陈述的第一部分是概述，应包括以下内容：
②需求分析阶段概述。
需求分析阶段总结主要总结需求分析阶段的工作。摘要内容包括：
③需求数据汇总。
需求调查得到的数据需要认真总结归纳，并以多种形式呈现。汇总需求数据时，应注意以下几点：
④ 按优先级排队的需求列表
对需求数据进行整理、汇总后，根据需求数据的重要性，制作数据的优先级列表。
⑤申请审批部分
编写需求说明书时，需要预留大量内容来确认需求或申请审批。为了确认，需要为用户管理者的签名预留大量的空间。
7.3 修改需求规范
由于需求经常变化，所以在编写需求规格说明时还必须考虑如何设计和修改规格。如果确实需要修改，最好不要改变原有的数据和信息。你可以考虑在需求规范中追加一部分来解释修改的原因，解释管理层的决定，然后给出最终的需求描述。
页:
[1]