超级会员免费看
互联网应用协议与网络管理概述
1. HTTP协议请求与响应
HTTP（Hypertext Transfer Protocol）是互联网应用中常用的协议，下面以一个客户端请求和服务器响应的示例来详细说明。
客户端发送的请求如下：
GET/index.html HTTP/1.1
Host: www.elsevier.com
Date: Tue, 01 April 2004 11:59:01 GMT
Cache-Control: max-age 300
Accept: text/html
Accept-Encoding: identity
From: ethelred.2@palace.gov.uk
User-Agent: FriendlyAppl/v.7.2 build/147b
这个请求是从根目录获取
index.html
文件，使用的HTTP版本是1.1，目标主机是
www.elsevier.com
，未指定端口则使用默认端口。请求于2004年4月1日格林威治标准时间中午前发送。客户端表示愿意接收不超过300秒（5分钟）的缓存副本，并且只接受以HTML文本编码且未被服务器压缩或格式化的文件。同时，客户端还插入了当前登录用户的电子邮件地址以及客户端应用程序的产品名称、版本号和构建版本信息。
当请求到达代理服务器时，代理服务器发现其缓存中有该文件的副本，且该副本仅存在了4分钟，符合客户端的要求。因此，代理服务器无需将请求转发到源服务器，而是可以构建并发送如下响应：
HTTP/1.1 200
Warning: 199 proxy.yournetwork.net:80 This file comes from a proxy cache
Date: Tue, 01 April 2004 11:59:37 GMT
Age: 240
Content-Type: text/html
Content-Length: 17152
Last-Modified: Wed, 26 Mar 2004 16.31.12 GMT
Expires: Thu, 01 May 2004 12:00:00 GMT
响应以HTTP版本号和状态码200（“OK”）开头。服务器包含一个警告消息，告知用户该文件来自缓存，使用通用警告代码199。响应中还包含了日期戳、缓存文件的年龄（240秒）、内容类型（HTML文本）、消息体长度（略超过4千字节）、文件在源服务器上的最后修改时间（3月26日）以及缓存副本的过期时间（5月初）。
2. HTTP协议头部标签及用途
HTTP协议中有多种头部标签，用于传递不同的信息，以下是一些常见头部标签及其用途的表格：
2.1 HTTP通用头部标签
| 标签 | 用途 |
|---|---|
| Cache-Control | 指定请求 - 响应链中所有缓存机制应遵守的指令 |
| Connection | 允许发送者指定特定连接所需的选项 |
| Date | 消息发起的日期和时间 |
| Pragma | 用于包含可能适用于请求 - 响应链中接收者的特定实现指令 |
| Trailer | 指示在使用分块传输编码的消息尾部存在给定的头部字段集 |
| Transfer-Encoding | 指示为安全传输消息体在发送者和接收者之间应用的转换类型（如果有） |
| Upgrade | 允许客户端指定其支持的其他通信协议，并表示如果服务器认为切换协议合适，客户端愿意使用 |
| Via | 网关和代理用于指示用户代理和服务器之间（请求时）以及源服务器和客户端之间（响应时）的中间协议和接收者 |
| Warning | 用于携带关于消息状态或转换的额外信息，这些信息可能未反映在消息中 |
2.2 HTTP请求头部标签
| 标签 | 用途 |
|---|---|
| Accept | 指定响应可接受的媒体类型 |
| Accept-Charset | 指示响应可接受的字符集 |
| Accept-Encoding | 与Accept类似，但限制内容编码 |
| Accept-Language | 与Accept类似，但限制自然语言集 |
| Authorization | 包含用户代理访问请求资源的认证信息的凭证 |
| Expect | 用于要求服务器执行特定行为 |
| From | 控制请求用户代理的人类用户的电子邮件地址 |
| Host | 请求资源的互联网主机和端口号 |
| If-Match | 使方法取决于与提供的实体标签的匹配 |
| If-Modified-Since | 使方法取决于实体自指定日期和时间以来是否被修改 |
| If-None-Match | 使方法取决于与提供的实体标签无匹配 |
| If-Range | 允许客户端请求实体的特定部分 |
| If-Unmodified-Since | 使方法取决于实体自指定日期和时间以来是否未被修改 |
| Max-Forwards | 限制可以将请求转发到下一个入站服务器的代理或网关的数量 |
| Proxy-Authorization | 允许客户端向需要认证的代理标识自身（或其用户） |
| Range | 指示消息体包含实体的一部分 |
| Referer | 允许客户端为服务器指定请求URI所源自的资源地址（URI） |
| TE | 指示客户端在响应中愿意接受的扩展传输编码以及是否愿意接受分块传输编码中的尾部字段 |
| User-Agent | 包含发起请求的用户代理的信息 |
2.3 HTTP响应头部标签
| 标签 | 用途 |
|---|---|
| Accept-Ranges | 允许服务器指示其对资源的范围请求的接受情况 |
| Age | 传达发送者对响应（或其重新验证）在源服务器生成以来的时间估计，在响应来自缓存时很有用 |
| ETag | 请求实体的当前实体标签值，可用于与同一资源的其他实体进行比较 |
| Location | 将接收者重定向到除请求URI之外的位置，以完成请求或识别新资源 |
| Proxy-Authenticate | 一个挑战，指示适用于此请求URI的代理的认证方案和参数 |
| Retry-After | 指示失败的服务预计不可用的时长 |
| Server | 关于源服务器用于处理请求的软件的信息 |
| Vary | 指示缓存是否允许在响应新鲜时，在不重新验证的情况下对后续请求进行回复 |
| WWW-Authenticate | 一个挑战，指示适用于请求URI的认证方案和参数 |
2.4 HTTP实体头部标签
| 标签 | 用途 |
|---|---|
| Allow | 请求URI所标识的资源支持的方法集 |
| Content-Encoding | 作为媒体类型的修饰符，其值指示对消息体应用的额外内容编码，以及必须应用的解码机制 |
| Content-Language | 描述实体预期受众的自然语言（可能不是消息体中使用的完整语言集） |
| Content-Length | 以十进制字节数指示实体（即消息体）的大小，在HEAD方法中，是如果请求为GET时将发送的实体大小 |
| Content-Location | 当消息中包含的实体也主要可从其他位置访问时，可用于提供该实体的位置 |
| Content-MD5 | 实体体的MD5摘要，用于提供端到端的消息完整性检查，但不建议作为安全机制 |
| Content-Range | 与部分实体一起发送，指定其在完整实体中的位置 |
| Content-Type | 指示消息体的媒体类型，在HEAD方法中，是如果请求为GET时将发送的媒体类型 |
| Expires | 给出响应中携带的实体数据应被视为过期的日期和时间 |
| Last-Modified | 指示源服务器认为实体最后修改的日期和时间 |
3. 常见互联网应用协议
互联网中有众多应用协议，以下是一些常见协议及其用途：
3.1 设备管理协议
| 协议 | RFC编号 | 用途 |
|---|---|---|
| BOOTP | RFC 951 | 引导协议，允许无盘客户端机器发现自己的IP地址、服务器主机地址以及要加载到内存并执行的文件名称 |
| DHCP | RFC 2131 | 动态主机配置协议，用于向TCP/IP网络上的主机传递配置信息，是BOOTP的发展 |
| NTP | RFC 958 | 网络时间协议，使用一组分布式客户端和服务器同步一组网络时钟 |
3.2 远程访问协议
| 协议 | RFC编号 | 用途 |
|---|---|---|
| RLOGIN | RFC 1282 | 类似于Tenet的功能，允许从远程站点登录到计算机 |
| RPC | RFC 1831 | 远程过程调用，可访问远程计算机上的服务，使这些服务作为功能单元供无需用户干预运行的应用程序使用 |
| NFS | RFC 3010 | 网络文件系统，提供通过互联网对文件的远程访问 |
| Gopher | RFC 1436 | 基于字符的协议，用于发布和访问文本文件，是HTTP的前身 |
3.3 邮件和新闻协议
| 协议 | RFC编号 | 用途 |
|---|---|---|
| SMTP | RFC 821 | 简单邮件传输协议，允许消息代理交换电子邮件消息 |
| POP3 | RFC 1939 | 邮局协议版本3，供客户端邮件应用程序用于检索邮件服务器为其存储的邮件 |
| IMAP | RFC 2060 | 互联网邮件访问协议，允许用户将消息存储在远程服务器上，与POP3不同，消息可继续存储在远程服务器上，用户可从中读取和操作 |
| NNTP | RFC 977 | 网络新闻传输协议，用于使用可靠的基于流的新闻传输来分发、查询、检索和发布新闻文章 |
3.4 目录服务协议
| 协议 | RFC编号 | 用途 |
|---|---|---|
| LDAP | RFC 2252 | 轻量级目录访问协议v3，提供读写访问的目录访问协议 |
4. 网络管理的必要性
在网络运行中，网络管理至关重要。所有网络设备在一定程度上都需要管理，即使是最简单的设备在投入使用和连接电源时也有物理管理需求。大多数设备需要某种形式的配置，以明确其在网络中的角色和行为。
网络管理的必要性体现在以下几个方面：
-
设备配置
：许多网络设备复杂，需要大量配置参数。虽然很多参数可以使用默认值，但为确保网络最佳运行，可能需要进行微调，这就需要对设备进行管理访问。
-
网络监控
：了解网络运行情况对于网络的正常运行至关重要。通过检查每个节点，可以观察其行为，例如哪些资源处于活动状态、承载了多少流量，找出导致CEO电子邮件瓶颈的连接是谁配置的，以及为何无法向某个主机发送数据包等问题。为了从设备检索的管理信息中获取最大价值，通常会以逻辑和模块化的方式对其进行分解。
-
服务提供
：网络管理还需要具备提供新服务的能力。这可能需要在网络路径上的每个节点调配资源，或者如果使用了信令协议，则只需向新连接的起点发出管理请求。
5. 网络管理面临的挑战
互联网服务提供商（ISPs）在网络管理方面面临诸多挑战。他们的网络性质不断变化，市场也在不断推动他们提供新的和不同的服务。这些变化给现有的网络管理工具带来了压力，要求服务提供商迅速调整其技术以满足客户的需求。
过去，托管互联网服务是最高需求，但如今企业希望服务提供商支持内联网或外联网服务。这意味着服务提供商需要为单个企业客户提供整个“网络”，而不仅仅是一组简单且无关的互联网连接。新的网络服务以虚拟专用网络（VPN）的形式通过服务提供商拥有的公共共享网络基础设施提供给客户。这种网络资源的共享对服务提供商的网络管理能力提出了新的挑战，他们必须能够对资源进行分区并在客户之间共享。
综上所述，互联网应用协议和网络管理是互联网运行中不可或缺的部分。了解HTTP协议的请求响应机制、头部标签用途以及常见的互联网应用协议，对于构建和管理网络至关重要。同时，认识到网络管理的必要性和面临的挑战，有助于我们更好地应对网络运行中的各种问题。
互联网应用协议与网络管理概述
6. 标准化网络管理模型
为了实现有效的网络管理，出现了一些标准化的管理模型，下面将对这些模型进行介绍。
6.1 管理信息库（MIBs）
管理信息库（Management Information Bases，MIBs）是一种用于存储网络设备管理信息的数据结构。它以树形结构组织，每个节点代表一个管理对象，通过唯一的标识符（OID）进行访问。MIBs 提供了一种标准化的方式来表示和管理网络设备的各种参数和状态信息，使得不同厂商的设备可以被统一管理。
6.2 简单网络管理协议（SNMP）
简单网络管理协议（Simple Network Management Protocol，SNMP）是一种广泛使用的网络管理协议，用于在网络设备和管理系统之间进行信息交换。SNMP 基于 UDP 协议，采用客户端 - 服务器模型，其中管理系统作为客户端，网络设备作为服务器。管理系统可以通过 SNMP 协议向网络设备发送请求，获取设备的状态信息或进行配置操作。SNMP 协议主要包括三个版本：SNMPv1、SNMPv2 和 SNMPv3，其中 SNMPv3 在安全性方面有了显著提升。
6.3 可扩展标记语言（XML）
可扩展标记语言（Extensible Markup Language，XML）是一种用于存储和传输数据的标记语言。在网络管理中，XML 可以用于描述网络设备的配置信息和管理策略。XML 的优点是具有良好的可读性和可扩展性，能够方便地与其他系统进行集成。通过使用 XML，网络管理系统可以更加灵活地处理和交换管理信息。
6.4 公共对象请求代理体系结构（CORBA）
公共对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）是一种分布式对象计算的标准，用于实现不同平台和编程语言之间的对象通信。在网络管理中，CORBA 可以用于构建分布式的网络管理系统，使得不同地理位置的管理节点可以协同工作。CORBA 提供了一种透明的方式来调用远程对象的方法，提高了网络管理系统的可扩展性和灵活性。
以下是这些标准化管理模型的对比表格：
| 管理模型 | 特点 | 适用场景 |
| — | — | — |
| MIBs | 以树形结构组织管理对象，提供标准化的信息表示方式 | 适用于对网络设备参数和状态信息的统一管理 |
| SNMP | 基于 UDP 协议，简单易用，广泛应用 | 适用于大规模网络的设备监控和管理 |
| XML | 具有良好的可读性和可扩展性，方便与其他系统集成 | 适用于需要灵活处理和交换管理信息的场景 |
| CORBA | 支持分布式对象计算，实现不同平台和编程语言之间的对象通信 | 适用于构建分布式的网络管理系统 |
7. 通用开放策略服务（COPS）协议及策略应用
通用开放策略服务（Common Open Policy Service，COPS）协议是一种用于在网络设备和策略服务器之间传递策略信息的协议。策略在现代网络中起着重要的作用，它可以用于控制网络流量、分配资源、实施安全策略等。
COPS 协议的工作流程如下：
1. 网络设备（客户端）向策略服务器（服务器）发送请求，请求获取特定的策略信息。
2. 策略服务器根据客户端的请求，查询本地的策略数据库，并生成相应的策略响应。
3. 策略服务器将策略响应发送给网络设备，网络设备根据接收到的策略信息进行相应的配置和操作。
以下是一个使用 mermaid 绘制的 COPS 协议工作流程流程图：
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(网络设备):::process -->|发送请求| B(策略服务器):::process
B -->|查询策略数据库| C(生成策略响应):::process
C -->|发送响应| A
A -->|应用策略| D(网络操作):::process
通过使用 COPS 协议和策略，可以实现对网络的精细化管理，提高网络的性能和安全性。例如，可以根据用户的身份和权限分配不同的网络资源，或者根据网络流量的情况动态调整网络设备的配置。
8. 选择合适的应用协议
互联网上的应用协议众多，在选择应用协议时，需要考虑多个因素，如协议的功能、性能、安全性、兼容性等。以下是一些选择应用协议的建议：
-
明确需求
：首先要明确自己的需求，例如是需要进行文件传输、远程访问、邮件通信还是其他功能。根据需求选择相应的协议。
-
考虑性能
：不同的协议在性能上可能存在差异，例如传输速度、延迟等。在选择协议时，需要根据实际情况考虑性能因素。
-
关注安全性
：对于涉及敏感信息的应用，如在线商业交易、电子邮件等，安全性是至关重要的。选择具有良好安全机制的协议，如 HTTPS、SSL/TLS 等。
-
兼容性
：确保选择的协议与现有的网络设备和系统兼容，避免出现兼容性问题。
综上所述，互联网应用协议和网络管理是一个复杂而重要的领域。了解各种应用协议的特点和用途，以及标准化的网络管理模型和策略应用，对于构建高效、安全的网络系统至关重要。同时，面对网络管理中不断出现的挑战，需要不断探索和应用新的技术和方法，以提高网络管理的水平和效率。在实际应用中，应根据具体需求选择合适的应用协议和管理策略，确保网络的稳定运行和服务质量。
扫一扫
1887
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
