​

1 介绍

  注意- 本文档的第1章和第2章是介绍性的，并不定义本协议的规范。

此文档描述了为CPE和ACS之间通信而设计的CWMP协议，CWMP定义了一种机制，此机制包含对CPE进行安全的自动配置，以及将其他的CPE管理功能整合进通用框架。

此文档定义了CMWP方法的通用标准，此标准能应用于任何一台符合TR069的CPE。其他文档为具体的设备或者服务定义了被管理对象，或者数据模型。

1.1 功能组件

CWMP用于支持各种各样的功能来管理CPE，主要功能如下：

  • 自动配置和动态服务提供
  • 软件/固件管理
  • 状态和性能监控
  • 诊断

1.1.1 自动配置和动态服务提供

CWMP允许ACS基于各种各样的标准来给CPE提供服务。

此配置机制允许在CPE首次连接到运营商网络及后续的任何时候为CPE提供配置，还包括支持ACS发起的异步为CPE提供再配置。

CWMP中的身份机制既可以为每个CPE，也为一批CPE(供应商、型号、软件版本号或者其他标准)提供服务。

CWMP也提供可选的工作用于管理CPE特定的功能，这些功能包含可选的、需要额外安全控制的应用或者服务，比如涉及付款的应用。使用数据签名认证的进行功能控制的机制定义在附件C中。

对于没有在协议的当前版本中定义的服务或者能力，通过配置提供机制也很方便进行扩展。

1.1.2 软件/固件管理

CWMP提供工具来管理CPE软件/固件的下载。协议提供版本认证、文件下载(ACS发起下载或者CPE发起下载)、通知ACS文件下载成功或者失败的机制。

CWMP同时定义了一种数字签名的文件格式，可用于下载单个文件或者一整包文件，其中整包文件指明了CPE需要执行的安装操作。数字签名的包格式确保了下载的文件及相关的安装操作的完整性，同时允许对非ACS的文件源进行认证。

1.1.3 状态和性能监控

CWMP支持CPE提供有用的信息给ACS，以此来监控CPE人状态和性能统计。同时也定义了CPE主动上报状态变化给ACS的机制。

1.1.4 诊断

CWMP支持CPE提供有用的信息给ACS，以此来诊断并解决连接性或者服务的问题；同时CPE具备协议规定的诊断测试的能力。

1.1.5 Web身份管理

为了支持CPE LAN侧浏览器访问基于web的应用，CWMP定义了一种可选的机制，此机制允许这些web站点自定义CPE相关的功能，详见附录D。

1.2 端到端架构中的位置

ACS是位于网络中的服务器，用于管理位于用户侧的设备。CWMP既可以管理DSL上行的宽带网络终端，也可以管理其他类型的CPE，比如独立组网的路由器或者LAN侧客户端设备。尽管ACS依赖于设备已经建立的IP层连接，但是它对运营商使用的网络接入媒介不可知。

  注意 - 对B-NT来说，TR-046描述了B-NT自动配置的整体框架，
  而TR-062和TR-044定义了ATM层和IP层的自动配置流程。
  其他类型的CPE应该使用符合自己网络架构的协议来获取IP连接

  注意 - 如果CWMP同时管理一个B-NT(或者其他Internet网关设备)和
  一个位于B-NT(或者其他Internet网关设备)后面的LAN侧设备
  Annex F定义了如何同时管理两种设备的机制

1.3 安全性目标

CWMP提供高度的安全性，而且安全模型可扩展。既允许基本的安全以容纳不太健壮的CPE实现，也允许更高的安全以支持带更先进安全机制的CPE。概况来说，CWMP的安全性目标如下：

  • 阻止对CPE/ACS管理功能的修改，或者对CPE和ACS之间交互的修改。
  • 为CPE和ACS之间交互提供保密
  • 为每种交互提供合适的认证
  • 阻止窃取服务

1.4 架构目标

CWMP提供连接模型的灵活性，具体如下：

  • CPE和ACS都可以发起建立连接，避免CPE和ACS之间维持长连接。
  • ACS和CPE之间的交互独立于哪一端发起连接。特别的，即使ACS不支持发起连接，所有ACS发起的交互应该在CPE发起的连接上生效。
  • 允许一个或者多个ACS服务一批CPE，这些CPE可能属于不同的运营商。

CWMP支持ACS和CPE的发现和关联：

  • 支持CPE发现合适的ACS
  • 允许ACS安全地鉴定一台CPE，并且将CPE关联到用户。关联的过程应该支持包含用户交互和全自动的模型

CWMP允许ACS控制、监控CPE的各种参数，设计这种机制基于如下前提：

  • 不同的CPE可能有不同的能力集，实现不同的可选功能集。另外，一个ACS可能管理不同类型的设备，这些设备提供不同的服务。因此，ACS必须能够发现每个CPE的能力集。
  • ACS必须能控制、监控CPE的当前配置。
  • ACS之外的媒介也可能修改CPE的配置(比如LAN侧自动配置)，因此，CWMP必须允许ACS考虑到CPE配置被ACS以外的媒介修改。同时，ACS需要能够控制哪些参数允许被ACS以外的媒介修改。
  • CWMP允许定义和访问厂家自定义参数

CWMP为最小化实现复杂度而设计，通过提高灵活性来换取复杂性和功能性。协议包含很多可选组件，只有当需要的场景才需要实现。协议也包含很多现有的标准，可以借鉴现成的实现。

CWMP不感知下层的接入网络。

CWMP也很方便扩展。既包含支持标准未来扩展的机制，也包含厂家自定义扩展的机制。

1.5 假设

CWMP基于如下假设制定：

  • 所有类型的CPE(桥、路由或者其他)都需要获取IP地址来跟ACS通信。
  • CPE同一时间只能和一个ACS交互。任何时候，CPE都知道自己能连接哪个ACS(注意：实现负载均衡的一组ACS在本文档中被看作一个ACS)

1.6 术语（略）

1.7 约定（略）

2 架构

2.1 协议组件

CWMP包含几个本协议特定的组件及几个标准协议。CWMP定义的协议栈如图2所示。协议栈的每一层在表1中做了大概的介绍。注意，除非特别说明，CPE和ACS必须遵循下层标准协议的要求。

表1

协议层 描述
CPE/ACS应用 CPE和ACS上分别运行基于CWMP的应用。应用由实现者定义，不在本协议规定范围内
RPC方法 RPC方法由CWMP定义，详见附录A
SOAP 一个基于XML语法的标准，用于远程过程调用。本协议使用SOAP 1.1，详见参考标准【8】
HTTP HTTP 1.1，详见参考标准【5】
SSL/TLS 标准的传输层安全协议，本协议使用SSL 3.0或者TLS 1.0，分别定义在参考标准【10】和参考标准【11】中
TCP/IP 标准的TCP/IP协议

2.2 安全机制

CWMP为交互提供很高的安全性，可以防止CPE和ACS之间的交互被篡改、可以为交互提供加密以及允许各种等级的认证。

CWMP包含下列安全机制：

  • 协议支持对CPE和ACS通信进行SSL/TLS加密，以提供交互加密、确保数据完整性、以及允许CPE和ACS之间基于证书认证。
  • HTTP层提供可选的基于共享密钥的CPE和ACS之间的认证。注意，CPE和ACS如何得到共享密码不在本协议中规定。

CWMP也提供可选的安全机制，凭证签名机制和包签名格式，分别定义在附录C和附录E。

2.3 架构组件

2.3.1 参数

通用机制定义的RPC方法允许ACS通过读写CPE的参数来配置CPE、监控CPE的状态和统计。不同类型CPE的参数定义在不同的文档中。目前TR-069相关的数据模型如下：

  • TR-106：TR-069设备的数据模型模板，参考标准【13】
  • TR-098：TR-069 Internet网关设备数据模型，参考标准【24】
  • TR-104：VoIP型CPE的配置参数，参考标准【25】

每个参数包含name-value对。其中name表示特定的参数，类似文件夹一样的分层结构，每一层通过"."分隔开。value可以是定义的数据类型之一(详见参考标准【13】)

参数可以是只读的或者可写的。ACS通过只读参数来判断CPE的特征、观察CPE的当前状态或者收集统计值。ACS通过可写参数来定制CPE的功能。所有可写参数必须可读，包括含有保密用户信息的参数，比如密码，读取是可以返回空(定义在相应的数据模型中)。一些可写参数可能被ACS之外的媒介修改(比如有些参数也可以通过LAN侧自动配置协议修改)。

因为其他协议(还有用户操作)都可能修改CPE的配置，所有ACS不能假定自己是唯一可以修改设备配置的实体。另外，LAN侧机制修改的配置可能与ACS提供的配置冲突了，所以WAN侧和LAN侧自动配置机制以及用户操作在实现是需要注意，避免产生配置冲突。

CWMP支持发现机制，此机制允许ACS判断CPE支持哪些参数、定义了哪些可选参数、以及支持未来标准的参数扩展。

CWMP也支持扩展在此协议定义之外的厂家自定义参数。

2.3.2 文件传输

RPC方法(见附录A)定义了文件下载和上传(可选)的规范，用于固件升级或者配置文件上传下载。

文件传输可以使用单播，对于下载来说，还可以使用组播。单播协议包含HTTP/HTTPS，FTP，SFTP和TFTP。组播协议包含FLUTE和DSM-CC。其中HTTP/HTTPS必须要支持，其他协议可选支持。

当ACS发起文件传输时，先告知CPE传输的文件的位置或者需要加入的组播组，然后CPE开始传输，完成之后通知ACS成功或者失败。

下载也可以由CPE发起，此时CPE首先向ACS发起特定文件类型的下载请求，然后ACS按上述ACS发起文件传输的步骤开始下载过程。

下载也可以通过外部事件发起，比如组播固件可用的通告。这种情况下，CPE自动开始文件传输，并通知ACS成功或者失败。

CWMP也定义了一种数字签名文件格式用于文件下载，这种签名的包格式定义在附录E中。

2.3.3 CPE发起连接

RPC方法(见附录A)允许CPE在不同条件下向对应的ACS发起Inform，来确保CPE到ACS的通信频率最小化。

RPC方法包含当CPE首次安装时建立通信，用于’bootstrap’初始定制参数到CPE中。也包含CPE后续运行时与ACS的周期性通信，或者当需要通知ACS的事件发生时(比如CPE的外网IP发生变化)。

上述所有场景中，当通信建立时，CPE通过厂商ID和序列号(产品ID可选)被唯一确定，由此ACS就能知道当前与哪个CPE通信，并以恰当的方式回应。

2.3.4 ACS发起的异步连接

服务自动配置的一个重要方面，就是有ACS异步通知CPE配置变化的能力。这种能力允许自动配置机制用在需要准实时配置CPE的服务中。比如，让终端用户立即访问某项业务，或者终端用户订阅的某个功能立即生效，而不用等到下一个周期性连接。

CWMP允许ACS在任何时候都能向CPE发起Connection Request，来通知CPE与ACS建立通信。

尽管CWMP也可以通过CPE来轮询的方式代替ACS发起连接，但是CWMP不依赖由CPE发起的轮询或者长连接来提供异步通知。

CWMP中定义的由ACS发起异步通信的基本机制，假定从ACS到CPE是可以直接IP寻址的。当CPE位于NAT网关下面而不能被ACS直接寻址时，附录G定义了一种替代机制。

3 步骤和要求

本章及相关的附录，定义了CWMP的规范性要求。

本章也引用了许多标准和CWMP的一些规范，除非特别说明，CPE和ACS必须遵循相关规范的要求。

3.1 ACS发现

CWMP定义了如下机制，用于CPE发现与其关联的ACS的地址：

1、CPE本地配置了ACS的URL。比如，通过LAN侧的自动配置协议来完成。CPE需要使用DNS从URL的域名中解析出ACS的IP地址。

2、DHCP服务器可以通过DHCP option 14来配置ACS的URL。CPE需要使用DNS从URL的域名中解析出ACS的IP地址。这种情况下，另外一个DHCP option可能用来配置ProvisioningCode，ProvisioningCode向ACS提供主要的服务提供商及其他的配置信息。

CPE通过将"dslforum.org"放入Vendor Class Identifier(DHCP option 60)中的任意位置来向DHCP服务器表明身份。

CPE使用DHCP服务器提供的Vendor Specific Information (DHCP option 43)来配置表2中相关的参数。这个DHCP option是由一个或者多个参考标准【14】定义的Vendor-Specific Options组成的列表。列表中除了这里罗列的Vendor-Specific Options，也可能包含其他信息。

如果CPE通过DHCP获取了ACS的URL，但是无法访问，CPE必须使用DHCP再次发现ACS的URL。CPE对ACS URL对应的每个IP都使用300秒尝试建立TCP连接，如果都失败，才能认为ACS不可达。如果CPE无法从DHCP服务器中收到回复，必须根据RFC 2131重试。

当CPE要连接ACS时，必须在下面场景中使用DHCP发现机制：

  • 如果CPE的ManagementServer.URL参数为空
  • 如果CPE无法连接ACS，并且首次(最近一次恢复出厂)从DHCP服务器获取ACS的URL。

当CPE没有预配置ACS的URL时，上述行为使CPE能回到DHCP来寻找ACS，比如当CPE预配置的ACS URL不正确时。但是上述行为不意味着ACS回滚机制。

当第一次成功连接ACS时，CPE必须保存本次发现ACS的机制。如果CPE未使用DHCP发现ACS的URL，那么就不应该切换到DHCP来发现ACS的URL。如果CPE首次使用DHCP发现ACS的URL，那么当连接ACS失败时，CPE必须通过DHCP重新发现ACS。即使ACS的URL后来被设置成非DHCP的方式，最近一次成功发现ACS URL的机制也要保留。

表2——封装的Vendor Specific Options

封装选项 封装Vendor-Specific Option编号 参数
ACS的URL 1 …ManagementServer.URL
Provisioning code 2 …DeviceInfo.ProvisioningCode

URL必须是一个绝对路径。URL和ProvisioningCode不能是null结尾。如果CPE收到的URL或者ProvisioningCode是null结尾的，CPE必须要接受这个值，而且不能把null解析成URL或者ProvisioningCode的一部分。

3、CPE可以有一个默认的ACS URL，如果没有提供其他的URL，就使用默认值。

ACS的URL必须是一个有效的HTTP或HTTPS链接(见参考标准【5】)。HTTPS链接说明CPE必须和ACS建立SSL或TLS连接。

一旦CPE与ACS建立连接，ACS可能在任何时候修改CPE存储ACS URL (…ManagementServer.URL，见参考标准【13】)。如果修改了ACS的URL，则CPE在后续的连接中，必须使用新的地址。

当使用基于证书的认证时，CPE使用ACS URL的host部分来校验ACS的证书。因为校验依赖ACS URL的精准性，所以此协议总体的安全性就依赖于ACS URL的安全性。

CPE针对本地修改ACS URL，应该严格限制，并且要提供高度的安全性机制。CPE可能进一步限制ACS只能在初始设置时被修改，一旦首次与ACS连接成功，ACS就不能在本地修改，这样就能保证URL只能被当前的ACS修改。

只有当DHCP服务器和CPE之间的连接安全性有保障时，才能使用DHCP来配置ACS的URL。因为DHCP本身不包括安全机制，所以需要提供其他方法来保证安全性。

ACS的URL可以是DNS主机名，也可以是IP地址。当解析ACS主机名时，DNS服务器可能返回多个IP地址。此时，CPE从IP列表中随机选择一个IP。当此IP无法连接ACS时，CPE应该再随机选择一个IP尝试连接ACS。如果多个IP代表不同的ACS，上述行为能确保多个CPE在不同ACS之间实现负载均衡。

CPE不能缓存TTL到期的DNS服务器回复，除非CPE无法连接DNS服务器来重新解析。这种行为在RFC 1034中被强制要求，方便DNS服务器更新过期的数据。

进一步推荐CPE密切关联特定的ACS IP地址。这意味着CPE只要能通过此IP连接ACS，就尝试一直使用这个IP地址。此机制建立一个更稳定的系统，而且由于缓存让ACS性能更好。为了实现密切关联，CPE需要将最近一次可用的IP地址和包含此IP地址的列表存放在永久性存储中。CPE仍然正常做DNS查询，但是需要使用相同的IP地址，直到CPE无法通过此IP连接ACS或者DNS服务器返回的IP列表变化了。不论是CPE无法通过此IP连接ACS，还是DNS服务器返回的IP列表变化了，CPE都要选择一个新IP。方便服务提供商重新配置网络。

IANA将端口号7547分配给CWMP(参考标准【17】)，ACS的URL可以使用这个端口。

3.2 建立连接

3.2.1 CPE发起连接

CPE可以在任何时候使用预设的ACS地址(见3.1节)向ACS发起连接。CPE必须在下面这些场景下跟ACS建立连接并发Inform RPC方法(按3.7节描述的步骤)：

  • CPE首次安装后第一次连接到网络。

  • 上电或者恢复出厂

  • 每个PeriodicInformInterval(比如，每24小时)

  • 可选的ScheduleInform发生

  • CPE收到来自ACS有效的Connection Request(见3.2.2节)

  • ACS的URL修改

  • 需要发起Inform的参数变化

  • 被SetParameterAttributes标记为“active notification”的参数被ACS之外的媒介修改。ACS通过SetParameterValues修改的参数不能产生一个新的session。如果在CPE通知ACS之前，同一个参数被修改多次，CPE只能产生一次通知。

    如果参数在当前session进行过程中被ACS之外的媒介修改，CPE等当前session结束后发起一个新的session(不能影响当前session)。

    为了避免产生过多到ACS的流量，CPE需要对参数变化通知的频率进行限制。只有在特殊情况下，才能突破这个限制。如果限制被突破，CPE需要延迟本地指定的会话启动数量，再通知ACS。延迟到期之后，CPE必须向ACS发起一个session，来表明从最近一次通知之后所有相应的参数变化(那些被标记为notification的参数)。

  • 假设CPE的策略说明当下载或者上传完成时需要通知ACS，那么下载或者上传完成(不论成功与否)就需要发起Inform。

    如果下载或者上传是ACS发起的，传输完成时， ACS必须被通知。

    如果下载或者上传不是ACS发起的，传输完成时， 由CPE决定ACS是否需要被通知。

  注意 - 此CPE策略允许远程配置。比如，可以配置CPE只通知ACS下载
  或者上传(不是由ACS发起的)

  • 按3.2.1.1节规定的session重试策略重新发起一个非正常结束的session。

当CPE和ACS都完成消息交互时，CPE不再维护到ACS的连接。详见3.7.1.4节——CPE session关闭的标准。

3.2.1.1 session重试策略

CPE必须重启失败的session来发送之前失败的事件，也可以让ACS及时地发起其他的请求。3.7.1.5节详细描述了成功事件发送，重试事件发送及失败事件丢弃。CPE必须记录失败session的重试次数。

如果CPE建立session失败，有可能是因为CPE支持CWMP v1.1(或更高版本)，而ACS只支持v1.0。如果怀疑是这个原因(见3.7.2.1节)，CPE必须降到v1.0再重试失败的session。

CPE必须等待表3中指定间隔之后或者有新的事件发生再重试失败的session，两个条件没有优先级，先到先得。CPE必须从重启后session重试次数对应的时间范围内随机挑选一个间隔。如果session重试过程中发生了重启，CPE必须像首次session重试那样来挑选间隔。换句话说，如果session重试过程中发生了重启以外的事件，即使后续发生的事件可能会导致session发起比表中的频繁，CPE也不会重置等待间隔。不论之前session失败的原因是什么，也不管导致session重试的条件，CPE都必须告诉ACS session的重试次数。

从重启后session第十次重试开始，CPE必须从2560到5120秒中选一个值。CPE必须一直重试失败session直到session成功结束。一旦session成功结束，CPE必须将重试计数清零，并且下一个session不再应用session重试策略。

表3——Session重试等待间隔

重启后的重试次数 等待间隔范围（秒）
#1 5-10
#2 10-20
#3 20-40
#4 40-80
#5 80-160
#6 160-320
#7 320-640
#8 640-1280
#9 1280-2560
#10及以上 2560-5120

3.2.2 ACS发起连接

ACS任何时候都可以通过"Connection Request"机制来请求CPE发起到ACS的连接。CPE必须支持这种机制，而ACS推荐支持。

此机制依赖CPE有一个能从ACS路由的IP地址。如果CPE在防火墙后面或者ACS和CPE之间有NAT设备，ACS可能根本无法访问CPE。附录G定义了一种机制，允许ACS连接NAT设备下挂的CPE。

"Connection Request"机制定义如下：

  • "Connection Request"必须向CPE指定的URL发送HTTP 1.1GET。URL的值在CPE上是一个只读参数。URL的路径应该由CPE随机生成，以保证每台CPE都不相同。
  • "Connection Request"必须使用HTTP，而不是HTTPS。对应的URL必须是一个HTTP的URL。
  • "Connection Request"的HTTP GET不带任何数据。CPE应该忽略GET包含的所有数据。
  • CPE在继续操作之前，必须使用digest认证来认证ACS——如果认证失败，CPE不能向ACS发起连接。
  • CPE必须接受认证参数正确的任意来源的"Connection Request"。
  • CPE必须使用"200(OK)"或"204(No Content)“来回复认证成功的"Connection Request”。一旦认证成功，CPE必须立刻在发起随后的session之前发送回复。HTTP回复的消息体长度必须为0。
  • 为了降低DoS攻击的可能性，CPE应该限制指定时间内接收"Connection Request"的数量。如果CPE因为这个原因拒绝"Connection Request"，CPE必须回复HTTP 503(Service Unavailable)。此时，CPE不应该在回复中包含HTTP Retry-After头。
  • 如果CPE按上面的描述成功地认证并回复了"Connection Request"，并且没有session正在运行，则CPE必须在30秒内使用预设的ACS地址(见3.1节)建立session，session的Inform中包含“6 CONNECTION REQUEST”事件号。

  注意 - 实践中，在极少情况下，可能会有一些例外情况导致CPE无法满足此需求

  • 如果ACS收到了"Connection Request"对应的成功回复，但是30秒内CPE没有建立Inform中包含“6 CONNECTION REQUEST”事件号的session，ACS应该向CPE重新发起"Connection Request"。

  • CPE成功认证并回复"Connection Request"之后，但在建立到ACS的session之前，收到了一个或者多个成功认证的"Connection Request"，CPE必须针对每个"Connection Request"发送成功的回复，但是不管在此期间收到多少个"Connection Request"，CPE都不能针对这些额外的"Connection Request"发起session。

  • 当CPE正在运行session，此时收到一个或者多个"Connection Request"，CPE不能因此贸然地结束当前session。CPE必须采取下列的某种操作：

    • 回复HTTP 503(Service Unavailable)来拒绝每个"Connection Request"。此时，CPE不应该在回复中包含HTTP Retry-After头。
    • 当前session结束之后，发起一个Inform中包含“6 CONNECTION REQUEST”事件号的新session(不论在前一个session运行中收到多少个"Connection Request")。这种情况下，当前session结束并且相关的修改都应用到CPE之后，CPE立即发起新的session。

    此要求在CPE运行session的整个过程都生效，也包含CPE正在建立session的过程。

  • 除了上面描述的情景，CPE不能以任何理由拒绝一个合理的通过认证的"Connection Request"。如果CPE以任何上述的理由拒绝了一个"Connection Request"，CPE不能针对拒绝的"Connection Request"发起session。

“Connection Request"机制依赖ACS和CPE之间至少有一次由CPE发起的交互。在交互中，如果ACS希望后续可以通过ACS发起交互，ACS应该使用”…ManagementServer.ConnectionRequestURL"参数的值(见参考标准【13】)。如果用于管理入口的URL修改了，CPE必须通过Inform消息将新的管理IP告知ACS(见参考标准【13】)，由此来保证ACS的信息是最新的。

IANA将端口号7547分配给CWMP(参考标准【17】)，CPE可以在Connection Request URL中使用这个端口。

3.3 SSL/TLS和TCP的使用

尽管CWMP可以直接基于TCP连接工作，但是推荐使用SSL/TLS来传输CWMP。如果不用SSL/TLS，就牺牲了一些安全性。特别的，SSL/TLS提供加密及数据完整性，并且使用基于证书的认证来代替基于共享密码的认证。

使用SSL/TLS和TCP的限制如下：

  • CPE必须支持SSL 3.0(参考标准10)和TLS 1.0(参考标准【11】)中的一个或者全部

  • 如果CPE同时支持SSL 3.0和TLS 1.0，CPE应该根据附录E RFC 2246中的规定将两种能力都发给ACS，由ACS选择用哪个协议。

  • 如果ACS的URL是一个HTTPS的URL，CPE必须使用SSL/TLS与ACS建立连接。

  • CPE必须支持下列SSL/TLS加密套件：

    • RSA_WITH_3DES_EDE_CBC_SHA
    • RSA_WITH_RC4_128_SHA

  • CPE必须能够向ACS发起对外的连接。

  • ACS必须能够接受CPE发起的连接。

  • 如果使用SSL/TLS，CPE必须用ACS提供的证书来认证ACS。对ACS的认证需要CPE认证针对根证书的证书，并且CPE需要确保证书Subject域中CN(Common Name)组件的值完全匹配CPE中ACS URL的主机部分(即使主机部分是IP)。此匹配必须是CN和ACS URL的主机部分的直接比较。如果是主机名的形式(而不是IP)，比较不能涉及主机名对应的IP地址。

    为了根据根证书认证，CPE必须包含一个或者多个可信任的根证书，这些根证书预置在CPE中或者通过本规范范围外的安全机制提供给CPE。

    如果因为HTTP重定向，CPE要访问非预置的ACS URL，CPE必须基于重定向后URL的主机部分来认证ACS证书的CN组件，而不用预置的URL。

    CPE应该等到获取准确的绝对时间后再去连接ACS。如果CPE在获取准确的绝对时间之前(或者CPE不支持绝对时间)，CPE必须忽略ACS证书中有关绝对时间的组件，比如not-valid-before和not-valid-after证书限制。

  • 使用客户端侧证书来认证CPE对CPE和ACS都是可选的。客户端证书必须由合适的链条签名。当使用客户端证书来认证连接ACS的CPE，CPE证书中的CN(Common Name)域必须是下面两种类型之一：

    • 唯一的CPE客户端证书。这种情况下，每个CPE的CN域必须全球唯一。特别的，CN域必须遵循3.4.4中建议的用户/用户ID的格式。
      例子：
      00D09E-0123456789
      012345-STB-0123456789
      012345-Set%2DTop%2DBox-0123456789

    • 通用的CPE客户端证书。这种情况下，一批CPE的CN域可能相同，比如某个供应商一个型号的所有CPE。对应的CN域的内容不在这里规定。

      如果使用通用的CPE客户端证书，ACS应该使用HTTP basic或者digest认证做CPE的补充认证，由此为每个CPE建立身份标识。

3.4 HTTP的使用

CPE和ACS之间的SOAP消息基于HTTP 1.1(参考标准【5】)，其中CPE作为HTTP客户端，而ACS是HTTP服务器。

  注意 - CWMP协议中，HTTP也用于Connection Requests，此时ACS是HTTP客户端
  CPE是HTTP服务器。HTTP的这种用法在3.2.2节中描述

3.4.1 HTTP上的SOAP封装

基于HTTP的SOAP封装扩展了参考标准【8】中第6节中的HTTP SOAP绑定，具体如下：

  • 从ACS到CPE的SOAP请求基于HTTP回应发送，而CPE到ACS SOAP回应基于相应的HTTP POST发送。

  • 当HTTP请求中含有SOAP回应或者SOAP失败回应时，HTTP请求中的SOAPAction头必须为空(没有引用)，表示关于消息意图的SOAPAction头不提供任何信息。格式必须如下：

    SOAPAction：

  • 当HTTP请求或者回应包含SOAP封装，则HTTP Content-Type头必须包含text/xml类型或者子类型。

  • 空HTTP POST不能含有SOAPAction头。

  • 空HTTP POST不能含有Content-Type头。

  • 包含CWMP载荷的HTTP回应(发给CPE的SOAP请求、发给CPE的SOAP成功回应、或者包含3.5节定义的错误元素的SOAP错误回应)必须使用HTTP 200(OK)。

下面是一个来自ACS的包含SOAP请求的HTTP回应：

Content-Type: text/xml; charset="utf-8"
Content-Length: xyz <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> <soap:Body> <cwmp:Request> <argument>value</argument> </cwmp:Request> </soap:Body>
</soap:Envelope>

  注意 - 在上面的例子中，XML namespace前缀的用法只是举例。
  实际的namespace前缀值是任意的，并且只用于声明namespace

  注意 - 在上面的例子中，CWMP namespace ID “urn:dslforum-org:cwmp-1-0”
  只是一个例子，并不是此规范定义的唯一版本

3.4.2 事务session

因为一系列的事件组成一个session，所以CPE应该在整个session阶段都要维持同一个TCP连接。然而，如果TCP连接在一个HTTP请求/回应之后正常关闭了，而session并没有在最后的HTTP回应时结束(不管成功或者失败)，CPE必须在新TCP连接中发送下一个HTTP请求来继续session。

收到认证挑战后，除非ACS通过"Connection: close" HTTP头明确关闭TCP连接，CPE必须在同一个TCP连接中发送下一个HTTP请求(包含"Authorization" HTTP头)。在ACS关闭TCP连接的情况下，CPE必须尊重ACS的请求，关闭TCP连接，并且在新的TCP连接中发送下一个HTTP请求(包含"Authorization" HTTP头)。

不论CPE因为什么原因发生建立TCP连接失败、发送HTTP消息失败、或者接收HTTP回应失败，CPE都必须认为session没有成功结束。CPE在宣告建立TCP连接失败或者接收HTTP回应失败之前，必须至少等待30秒。

ACS应该根据参考标准【7】中的描述使用session cookie来维持session状态。ACS可以使用旧风格“Netscape” cookies，也可以使用参考标准【7】中的新风格cookies。ACS只能使用被标记为"Discard"的cookies，并且不应该假定CPE在session结束之后仍然维护cookie。

为了确认ACS能使用session cookie，CPE必须支持参考标准【7】中定义的cookies用法，并且在每个后续的HTTP POST中都返回cookie值，有一个例外，当session结束时，CPE不需要支持保存之前的cookies。特别的，因为ACS可能发送旧风格、新风格、或者新旧风格混合的cookies，CPE必须支持参考标准【7】9.1节中的兼容性规范。CPE必须支持ACS多cookies的用法，并且至少提供512字节用于存放cookies。

当事务session成功结束或者异常终止，CPE必须关闭相应的到ACS的TCP连接，并且丢弃所有被标记为Discard的cookies。

CPE必须支持ACS HTTP重定向的用法。HTTP重定向对CPE和ACS的要求如下：

  • CPE必须支持302(Found)和307(Temporary Redirect)
  • CPE也可能支持301(Moved Permanently)的重定向
  • CPE必须允许重定向发生在session的任意时刻，并且ACS可能在session的任意时刻宣布重定向。
  • 如果CPE被重定向，就必须使用HTTP重定向回应中的URL尝试继续当前session。具体来说，CPE必须向ACS重定向后的URL再次发送导致重定向回应的HTTP POST，并且CPE必须正确处理当前session，就好像重定向没有发生过。
  • 如果CPE被重定向，重定向后的URL只用于当前session或者直到同一个session中发生再次重定向。重定向后的URL不能被保存到CPE(比如存放在…ManagementServer.URL)用于后续的session或者重试当前的session。即使301(Moved Permanently)用于重定向，此要求也必须被遵守。
  • CPE必须允许最多5个连续的重定向。如果CPE被连续重定向超过5次，可以认为当前session已经异常终止。
  • HTTP重定向提供的URL可能是HTTP或者HTTPS。不论重定向前使用哪种传输机制，CPE都必须和新的目标使用恰当的传输机制(TCP或者SSL/TLS)。
  • 如果重定向后的session使用SSL/TLS，会要求CPE认证ACS，此认证必须基于重定向后的URL，也不是预置的ACS URL(参考3.3节)。
  • ACS发送的包含重定向状态码的HTTP回应中，HTTP消息体的长度必须为0。如果CPE收到了一个带非空消息体的HTTP重定向回应，必须忽略消息体中的内容。
  • 当被重定向时，CPE在后续发给重定向ACS的HTTP请求中必须包含当前session相关的所有cookies。CPE必须认为来自ACS的重定向是一个定义在参考标准【7】中的"可核实事务"，因此CPE必须向重定向的ACS发送cookies，而不需要对每个cookie进行域名验证。

3.4.3 文件传输

如果ACS通过下载或者上传请求要求CPE进行文件传输，并且文件所在的HTTP URL与ACS的主机名相同，那么CPE必须选择下面其中一种方法来执行传输：

  • CPE可能基于已经建立的连接发送HTTP GET/PUT。一旦文件传输完成，CPE可能接着向ACS发送额外的消息而继续维持连接。
  • CPE可能开启一个新的连接来传输文件，然后维持这个连接用于后续发送消息。
  • CPE可能结束当前session，然后执行传输。

如果文件所在的位置不是一个HTTP URL，或者ACS的域名不同，或者使用不同的端口，那么只有后两种选项可以使用。

CPE必须支持3.3节中规定的使用SSL/TLS建立一个独立的TCP连接并使用HTTP来传输文件。当文件所在的位置是一个HTTPS URL时，CPE必须使用SSL/TLS。

CPE必须同时支持HTTP basic和digest文件传输。具体的认证方法由文件服务器凭借提供的basic或者digest认证挑战来选择。如果文件服务器需要认证，则ACS必须使用特定的RPC文件来指定用于文件传输的凭证(比如下载、上传)。

3.4.4 认证

如果CPE未使用SSL/TLS认证，则ACS必须使用HTTP来认证CPE。如果使用SSL/TLS来加密，则ACS可以使用basic或者digest认证(参考标准【6】)。如果没有使用SSL/TLS，则ACS必须使用digest认证。

CPE必须同时支持HTTP basic和digest认证。ACS凭借提供basic或者digest认证挑战来选择认证方法。

如果CPE收到来自ACS的认证挑战(basic或者digest)，则CPE在当前TCP连接的后续HTTP请求中都要发送Authorization头。不论CPE是否发送Authorization头，ACS都可能在当前session任意阶段的单个或者多个TCP连接中再次发起认证挑战。

如果使用HTTP认证来认证CPE，CPE应该使用所有厂家中全球唯一的“用户名/用户ID”组合。具体来说，CPE的“用户名/用户ID”可以在下面格式中选择：
    <OUI>“_”<ProductClass>“_”<SerialNumber>
    <OUI>“_”<SerialNumber>

如果“用户名/用户ID”使用上面的格式，则<OUI>, <ProductClass>和<SerialNumber>域必须与附录A中定义的Inform消息DeviceIdStruct中的相应参数完全匹配。有一种情况例外，为了保证能从"用户名/用户ID"中抽取参数值，<ProductClass>和<SerialNumber>中的字符，如果不是字母，不是数字，也不是下划线(“_”)，则必须根据RFC 3986(参考标准【12】)的定义使用URI百分比编码进行转义。

如果使用上述的"用户名/用户ID"格式，当且仅当ProductClass为空时才使用第二种形式。

举例：
  012345_0123456789
  012345_STB_0123456789
  012345_Set%2DTop%2DBox_0123456789(其中%2D是连字符，实际是Set-Top-Box)

不论使用哪种HTTP认证，每台CPE的密码都应该唯一。也就是说，不同CPE不应该共享相同的密码。密码是共享密钥，因此CPE和ACS都要知道。CPE首次安装时，ACS和CPE如何知道共享密码不在本规范中定义。CPE和ACS都应该采取合理的措施来防止对密码的未授权访问。

3.4.5 Digest认证

此章节概述了CWMP中使用digest认证的规范。这些应用于认证的规范既用于RPC交互的连接，也用于文件传输。注意，ACS和CPE在不同类型的连接下，HTTP客户端和服务器的角色会互换。当ACS发起"Connection Request"时，ACS是HTTP客户端。而当CPE发起到ACS的连接时，CPE是HTTP客户端。

CPE和ACS必须支持RFC 2617中定义的"qop"选项为"auth"的情景。按照RFC 2617，这意味着当HTTP服务器提供"qop"选项时，HTTP客户端必须使用新风格的digest机制。

当使用digest认证时，每打开一个TCP连接，ACS需要生成新的nonce，而CPE需要生成新的cnonce。

  注意 - 如果CWMP的session不使用SSL/TLS，ACS采用的用于HTTP认证的
  nonce重复使用策略极大地影响了session的安全性。特别地，如果ACS
  在多个TCP连接的认证中重复使用同一个nonce，则ACS很容易受回放攻击。
  不过，如果session使用SSL/TLS，风险就极大降低了。

CPE和ACS必须支持MD5 digest算法。CPE必须额外支持MD5-sess digest算法。

3.4.6 HTTP补充规范

HTTP相关的补充规范如下：

  • 当ACS发送空的HTTP回应时，必须使用"204(No Content)"。
  • 当CPE发送空的HTTP回应时，HTTP消息体长度必须为0。
  • CPE不能使用HTTP 1.1中定义的流水线。

3.5 SOAP的使用

CWMP使用SOAP 1.1(参考标准【8】)作为编码格式来传输附录A中定义的RPC方法的调用和回应。

下面定义了RPC方法和SOAP编码的映射关系：

  • 编码必须使用标准的SOAP 1.1封装和序列化namespace：

    • 封装namespace标识符"https://schemas.xmlsoap.org/soap/envelope/"
    • 序列化namespace标识符"https://schemas.xmlsoap.org/soap/encoding/"

  • 本文档CWMP中定义的所有元素和属性都与下面的namespace标识符关联

    • “urn:dslforum-org:cwmp-1-1”

  • CWMP版本号1.n的namespace标识符总是"urn:dslforum-org:cwmp:1-n"，比如对于v1.0，就是"urn:dslforum-org:cwmp:1-0"，而对于v1.42，就是"urn:dslforum-org:cwmp:1-42"。

    • ACS和CPE发送SOAP封装时，应该使用支持的最高版本的namespace标识符。
      注意-为了兼容v1.0的实现，有些情况下ACS和CPE需要使用v1.0的namespace标识符。这些要求在
      3.2.2.1(CPE session’重试)，3.7.1.1(CPE session发起)和3.7.2.1(ACS session发起)中定义。
    • 收到SOAP封装时，ACS和CPE都必须能从namespace标识符中抽取CWMP版本号。

  • 附录A中使用的数据类型直接和SOAP 1.1序列化namespace中定义的数据类型对应。(通常来说，附录A中的数据类型是对应SOAP数据类型的有限子集。)

  • 按SOAP规范(参考标准【8】)，类型为"anySimpleType"的元素必须包含类型属性来表明自己的实际类型。

  • 非"anySimpleType"类型的元素，当且仅当附录A使用确定的数据类型在RPC方法XML schema定义了该元素，才需要包含类型属性。如果包含了类型属性，则类型属性的值必须和schema定义的数据类型完全一致。

  • 对于数组参数，定义数组的表中指定的参数名字，必须作为整个数组元素的名字。数组成员元素的名字必须是定义数组的表中指定的数组的数据类型(不包括括号及圆括号中的长度限制)，而且不能是合格的namespace。比如一个命名为"ParameterList"，成员是"ParameterValueStruct"结构的数组定义如下

    <ParameterList soap-enc:arrayType="cwmp:ParameterValueStruct[2]"> <ParameterValueStruct> <name>Parameter1</name> <value xsi:type="someType">1234</value> </ParameterValueStruct> <ParameterValueStruct> <name>Parameter2</name> <value xsi:type="someType">5678</value> </ParameterValueStruct>
</ParameterList>

    第二个例子，GetRPCMethodsResponse中的MethodList数组格式如下：

    <MethodList soap-enc:arrayType="xsd:string[3]"> <string>GetRPCMethods</string> <string>Inform</string> <string>TransferComplete</string>
</MethodList>

    注意 - 在上面的例子中，XML namespace前缀只是举例。
    实际的namespace前缀值是任意的，并且只用于声明namespace

    注意 - 给XML namespace前缀指定arrayType属性是必要的。
    CWMP定义的数组类型都是CWMP namespace前缀，其他类型的数组
    要么是XML Schema namespace前缀，要么是SOAP编码namespace前缀。

  • 对编码RPC方法的SOAP规范(参考标准8第7节)来说，附录A中定义的每个方法，方法调用中的每个参数代表入参，方法回应中的每个参数代表出参。不存在既是入参，又是出参的参数。

  • 使用标准SOAP命名规范定义的方法回应，命名时需要在方法名字后缀加上"Response"。

  • 一个SOAP封装必须包含一个Body元素。

  • CPE必须能接受至少32KB大小的SOAP请求，而不产生"Resources Exceeded"的回应。

  • CPE必须能产生任意长度的SOAP回应，而不产生"Resources Exceeded"的回应。比如没有最大CPE SOAP回应长度。

  • ACS必须能接受至少32KB大小的SOAP请求，而不产生"Resources Exceeded"的回应。

  • ACS必须能产生任意长度的SOAP回应，而不产生"Resources Exceeded"的回应。比如没有最大ACS SOAP回应长度。

  • 失败的回应必须使用SOAP Fault元素，要求如下：

    • 不论客户端还是服务器，SOAP "faultcode"元素必须恰当地指明错误的原因。此时，客户端代表SOAP请求的发起者，服务器代表SOAP回应者。 错误回应的接收方不需要使用此元素的值，可能完全忽略SOAP "faultcode"元素。

    • SOAP "faultstring"子元素必须包含"CWMP fault"字符串。

    • SOAP "detail"元素必须包含Fault结构。附录A中RPC方法XML schema正式定义了这种结构。此结构包含如下元素：

      • 一个"FaultCode"元素包含附录A中定义的错误码。

      • 一个"FaultString"元素包含对错误通俗易懂的描述。

      • 一个"SetParameterValuesFault"，只用于回应"SetParameterValues"方法，包含一个或者多个结构的列表，指明每个错误参数对应的具体错误。这个结构包含如下元素：

        • 一个"ParameterName"元素包含错误参数的绝对路径。
        • 一个"FaultCode"元素包含附录A中定义的与特定参数对应的错误码。
        • 一个"FaultString"元素包含对特定参数错误通俗易懂的描述。

    下面是错误回应封装的例子：

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> <soap:Header> <cwmp:ID soap:mustUnderstand="1">1234</cwmp:ID> </soap:Header> <soap:Body> <soap:Fault> <faultcode>Client</faultcode> <faultstring>CWMP fault</faultstring> <detail> <cwmp:Fault> <FaultCode>9000</FaultCode> <FaultString>Upload method not supported</FaultString> </cwmp:Fault> </detail> </soap:Fault> </soap:Body>
</soap:Envelope>

    下面是"SetParameterValues"方法对应的错误回应的例子

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> <soap:Header> <cwmp:ID soap:mustUnderstand="1">1234</cwmp:ID> </soap:Header> <soap:Body> <soap:Fault> <faultcode>Client</faultcode> <faultstring>CWMP fault</faultstring><detail> <cwmp:Fault> <FaultCode>9003</FaultCode> <FaultString>Invalid arguments</FaultString> <SetParameterValuesFault> <ParameterName> InternetGatewayDevice.Time.LocalTimeZone </ParameterName> <FaultCode>9012</FaultCode> <FaultString>Not a valid time zone value</FaultString> </SetParameterValuesFault> <SetParameterValuesFault> <ParameterName> InternetGatewayDevice.Time.LocalTimeZoneName </ParameterName> <FaultCode>9012</FaultCode> <FaultString>String too long</FaultString> </SetParameterValuesFault> </cwmp:Fault> </detail> </soap:Fault> </soap:Body>
</soap:Envelope>

    注意 - 在上面的例子中，XML namespace前缀只是举例。
    实际的namespace前缀值是任意的，并且只用于声明namespace

    注意 - 在上面的例子中，CWMP namespace ID “urn:dslforum-org:cwmp-1-0”
    只是一个例子，并不是此规范定义的唯一版本

  错误回复只用于回应SOAP请求，不能用来回应SOAP回复或者其他的错误回复。

  如果错误回复不满足上述规范，则接收方必须将此SOAP消息视为无效。CWMP的session中无效SOAP的处理在3.7节中定义。

  • 处理收到的报文时，ACS和CPE都应该忽略如下信息：
      (a) 未知的XML元素及他们的子元素或者内容；
      (b) 未知的XML属性及对应的值；
      (c) 嵌入的XML注释；
      (d) XML处理指令。
    或者ACS和CPE应该验证收到的XML的有效性，并且拒绝包含未知元素的封装。注意，根据额外参数排除扩展已有消息，不改变消息的名字。

  • 如果RPC方法参考XML Schema namespace(比如属性的类型，或者数据类型)，必须参考2001版namespace定义，具体来说，就是"http://www.w3.org/2001/XMLSchema-instance"和"http://www.w3.org/2001/XMLSchema"。接收方应该拒绝参考其他版本的RPC方法。

按上述的规则，GetParameterNames请求举例如下：

<soap-env:Envelope xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> <soap-env:Header> <cwmp:ID soap-env:mustUnderstand="1">0</cwmp:ID> </soap-env:Header><soap-env:Body> <cwmp:GetParameterNames> <ParameterPath>Object.</ParameterPath> <NextLevel>0</NextLevel> </cwmp:GetParameterNames> </soap-env:Body>
</soap-env:Envelope>

    注意 - 在上面的例子中，XML namespace前缀只是举例。
    实际的namespace前缀值是任意的，并且只用于声明namespace

    注意 - CWMP namespace前缀只描述CWMP schema顶层定义的元素
    (上面例子中是ID和GetParameterNames)。为顶层元素下层的元素
    指定namespace是不正确的(上面例子中是ParameterPath和NextLevel)
    这是因为CWMP schema为不合格的元素指定elementFormDefault

    注意 - 在上面的例子中，CWMP namespace ID “urn:dslforum-org:cwmp-1-0”
    只是一个例子，并不是此规范定义的唯一版本

CWMP定义了一系列的SOAP头元素，详见表4

表4——SOAP头元素

标签名称 描述
ID 此头元素可以用在SOAP请求和回应中，每个请求使用唯一的ID。ID的值是一个任意的字符串，并且由请求方根据情况设置 。

如果ID头用在SOAP请求中，则ID头也必须在相应的回复中使用(不论回复是成功还是失败)。

因为支持ID头是必须的，所以ID头的mustUnderstand属性必须设置为1(true)
HoldRequests 此头元素用在ACS发往CPE的封装中，规定了CPE请求的发送。此头不能出现在CPE到ACS的封装中。

此标签是bool值。如果标签不存在，则解析为0(false)。

CPE接收到HoldRequests头的行为定义在3.7.1.3节中。CPE必须支持此头元素。

因为支持此头元素是必须的，所以mustUnderstand属性必须设置为1(true)

下面是包含所有上述头元素的消息实例：

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> <soap:Header> <cwmp:ID soap:mustUnderstand="1">1234</cwmp:ID> <cwmp:HoldRequests soap:mustUnderstand="1">0</cwmp:HoldRequests> </soap:Header> <soap:Body> <cwmp:Action> <argument>value</argument> </cwmp:Action> </soap:Body>
</soap:Envelope>

    注意 - 在上面的例子中，XML namespace前缀只是举例。
    实际的namespace前缀值是任意的，并且只用于声明namespace

    注意 - 在上面的例子中，CWMP namespace ID “urn:dslforum-org:cwmp-1-0”
    只是一个例子，并不是此规范定义的唯一版本

3.6 RPC支持要求

表5罗列了所有的方法，并且说明了附录A中定义的RPC方法在相应条件下的实现是必须的还是可选的。

表5——RPC消息要求

方法名称 CPE要求 ACS要求
CPE相关方法 回复 调用
GetRPCMethods REQUIRED OPTIONAL
SetParameterValues REQUIRED REQUIRED
GetParameterValues REQUIRED REQUIRED
GetParameterNames REQUIRED REQUIRED
SetParameterAttributes REQUIRED OPTIONAL
GetParameterAttributes REQUIRED OPTIONAL
AddObject REQUIRED OPTIONAL
DeleteObject REQUIRED OPTIONAL
Reboot REQUIRED OPTIONAL
Download REQUIRED REQUIRED
Upload OPTIONAL OPTIONAL
FactoryReset OPTIONAL OPTIONAL
GetQueuedTransfers OPTIONAL OPTIONAL
GetAllQueuedTransfers OPTIONAL OPTIONAL
ScheduleInform OPTIONAL OPTIONAL
SetVouchers OPTIONAL OPTIONAL
GetOptions OPTIONAL OPTIONAL
ACS相关方法 回复 调用
GetRPCMethods OPTIONAL REQUIRED
Inform REQUIRED REQUIRED
TransferComplete REQUIRED REQUIRED
AutonomousTransferComplete OPTIONAL REQUIRED
RequestDownload OPTIONAL OPTIONAL
Kicked OPTIONAL OPTIONAL

3.7 事务session的步骤

所有的事务session都必须从CPE发起的带HTTP POST的Inform消息开始。Inform消息用来发起一组事务，并且传达CPE关于消息编码的限制。一个session只能发一个Inform消息(当CPE因为收到“401 Unauthorized”需要认证，或者收到HTTP 3xx状态码需要重定向时，需要重发Inform请求，这个限制不生效)。

当ACS和CPE都没有更多请求需要发送，也没有回复需要接收时，session结束。此时，CPE必须关闭连接。

同一时间，CPE和关联的ACS只能存在一个事务session。

    注意 - 只有当ACS或者CPE有消息传输时，事务session才需要维持。
    当消息交互结束时，session及相应的TCP连接不应该继续保持。

3.7.1 CPE操作

3.7.1.1 session发起

当满足3.2.1节的条件时，CPE就会向ACS发起一个事务session。一旦跟ACS的连接成功建立，CPE就通过向ACS发送初始Inform请求来发起session。用来向ACS表明CPE的当前状态，并且CPE已经做好了接收ACS请求的准备。

当且仅当CPE收到有效的Inform回复，才认为session已经被成功建立。

如果CPE收到有效的Inform回复，其中的namespace ID指明ACS只支持CWMP v1.0，那么CPE在session的后续操作必须降到v1.0。

    注意 - CWMP v1.0是个特例，因为与其他版本的协议不兼容。v1.1中加入了新的规范来确保
    CPE和ACS都支持v1.1(或者后续版本)时，任何一方都不需要降低版本就能实现兼容。
    (也意味着后续的小版本更新不会增加强制要求的RPC方法)。

session从开始到结束，CPE必须保证所有可通过CWMP访问的参数的事务完整性。在session过程中，CPE所有的可配置参数，在ACS看来，是一个只能被ACS修改的完整集合。整个session过程中，CPE必须向ACS屏蔽其他媒介对参数的更新，包含可写参数的值，也包括可写参数或者对象的增加或者删除。CPE实现事务完整性的方法由自身实现。

CPE必须采用必要的措施来保证session的事务完整性。比如，特殊情况下，CPE为了满足CWMP session的要求，需要终止LAN侧的配置session。

3.7.1.2 接收请求

如果session进行中(session成功发起后，并且在3.7.1.4节描述的session结束标准达到之前)，当收到ACS的SOAP请求时，CPE必须在下一个发向ACS的HTTP POST中回应此请求。

3.7.1.3 发送请求

如果session进行中(session成功发起后，并且在3.7.1.4节描述的session结束标准达到之前)，如果CPE有一个或者多个请求需要发给ACS，当且仅当下面所有条件都满足时，CPE才在下一个HTTP POST中发送其中的一个请求：

  • 最近一次来自ACS的HTTP回复不含SOAP请求

  • ACS指明HoldRequests为false(见3.5节)。当且仅当最近一次来自ACS的HTTP回复包含下面某个内容，说明HoldRequests为false：

    • 带HoldRequests头的SOAP封装设置HoldRequests为false。
    • SOAP封装不带HoldRequests头
    • 无SOAP封装(空的HTTP回复)

  • 当前session的前面时间里，到ACS指明HoldRequests为false时，CPE还没有发送过空的HTTP POST。

如果因为上述原因，CPE有多个请求被挂起，除非特别说明，选择哪个请求先发送由CPE决定。

当session进行中，上面所有条件都不满足或者CPE没有请求要发往ACS，并且最近一次ACS的回复不含SOAP请求，CPE必须发送一个空的HTTP POST。

当HoldRequests为false(见3.5节)时，一旦CPE发送了空的HTTP POST，则CPE就不能在当前session中再发送请求了。此时如何CPE有其他的请求需要发给ACS，必须等下一个session。

表6总结了session进行中(session成功发起后，并且在3.7.1.4节描述的session结束标准达到之前)CPE必须发给ACS的内容。

表6——CPE发送消息限制

HoldRequests 有ACS请求 无ACS请求
有CPE请求 False 回复 请求
True 回复 空HTTP POST
无CPE请求 - 回复 空HTTP POST

3.7.1.4 session终止

当下列条件都满足时，CPE必须终止事务session：

  1. ACS没有更多请求需要发送给CPE。当且仅当最近一次ACS的HTTP 回复是空时，CPE才能得出ACS已经没有更多请求的结论。
  2. 当HoldRequests为false，CPE已经没有更多请求需要发给ACS，并且CPE已经发送了空的HTTP POST(向ACS表明CPE当前session下已经没有更多请求)。如表6中的定义，如果本条件没有满足，但是CPE没有更多请求或者回复，必须发送空的HTTP POST，这样就能满足本条件了。
  3. CPE已经从ACS收到了所有未完成的回复消息。
  4. CPE已经将ACS发送了所有由之前的请求导致的未完成的回复消息。

CPE至少要等30秒还没有收到ACS的HTTP回复，CPE才能认为session异常终止。如果CPE没能收到HTTP回复，CPE不能在同一个session中尝试重新发送相应的HTTP请求。

如果CPE收到Inform请求的SOAP层错误回复，并且错误码不是"Retry request"(错误码8005)，CPE必须认为session已经异常终止。

如果CPE收到的HTTP回复，其中XML不符合格式要求、SOAP格式是无效的、包含不在3.5节定义的SOAP错误或者CPE认为已经违反协议，CPE必须认为session已经异常终止。

如果CPE收到的HTTP回复带有CPE无法处理的错误码(4xx或者5xx)，CPE必须认为session已经异常终止。注意，CPE应该接受带"401 Unauthorized"状态码的HTTP回复为正常认证过程的一部分，当CPE接着尝试认证时，如果认证结果仍然带"401 Unauthorized"，则CPE必须认为session已经异常终止。

如果上述的条件都没有满足，则CPE必须继续当前session。

如果CPE收到3.5节定义的SOAP层对非Inform方法的错误回复，并且错误码不是“Retry request”(8005)，CPE必须继续当前session。也就是说，这种类型的错误回复不能使当前session异常终止。

    注意 - 在错误的情况下，ACS产生的错误回复是一个SOAP层错误，或者是一个HTTP层错误，
    完全由ACS决定。其中SOAP层错误使session继续，而HTTP层错误则导致session异常终止

如果session中的消息交互需要CPE重启才能完成请求的操作，CPE重启之前，必须基于上面的标准完全终止session。

如果session异常终止，CPE必须按3.2.1.1节重试session。这种情况下，CPE可能对session的重试次数有一定的限制。

3.7.1.5 事件

事件表明CPE发生了需要通知ACS的事情，事件通过A.3.3.1中定义的Inform请求发送。对每个事件，CPE必须至少尝试发送一次。如果CPE没有正在进行的session，则必须立刻尝试发送事件。否则，必须在当前session结束时发送。CPE必须收到ACS的确认才能认为事件已经发送成功。一旦CPE发送事件成功，就不能再发相同的事件。另一方面，ACS必须做好多次接收相同事件的准备，因为CPE可能没收到ACS发送的回复。许多类型的事件(比如PERIODIC, VALUE CHANGE)即使之前发送成功，后续也允许再次发送。这种情况下，后续session中的事件说明相同类型的事件再次发生，而不是重试之前发送失败的事件。

对每种类型的事件，当前一次发送失败时，都有一个策略来决定CPE是否及何时必须重新发送。如果事件要重新发送，则必须立即在下一个session中进行。发送失败的事件不能在后续的session中忽略，并且稍后重新发送。

对大部分事件，CPE通过接收成功的InformResponse来确认发送成功。4种标准的事件类型(KICKED, TRANSFER COMPLETE, AUTONOMOUS TRANSFER COMPLETE, REQUEST DOWNLOAD)表明一种或者多种方法(分别是Kicked [A.4.2.1节], TransferComplete [ A.3.3.2节], AutonomousTransferComplete [A.3.3.3节], RequestDownload [A.4.2.2节] ) 将在当前session中被调用。这些方法的成功回复触发事件发送。CPE也可以发送厂商自定义事件(使用表7中的格式)，事件的成功发送、重试及丢弃策略都由厂家决定。

如果CPE无新事件而又有旧事件需要重新发送时，CPE必须按3.2.1.1节定义的session重试策略重新发送。

下面是事件列表，包含Inform请求中的编码、累积行为、确认成功发送对应的回复及发送失败时的重试丢弃策略。

表7——事件类型

事件码 累积行为 累积行为 成功时ACS的回复 重试/丢弃策略
"0 BOOTSTRAP" Single CPE第一次被安装或者ACS URL修改。

下列条件将触发BOOTSTRAP事件：

  • CPE出厂后第一次连接ACS
  • CPE恢复出厂后第一次连接ACS
  • 任意方法修改ACS URL后第一次连接ACS

注意，和其他事件一样，BOOTSTRAP可以跟其他事件一起组成事件数组。比如CPE出厂后第一次启动时，CPE应该同时发送BOOTSTRAP和BOOT。

 InformResponse CPE不能丢弃未发送的BOOTSTRAP。

所有其他的未发送事件在BOOTSTRAP时必须被丢弃。
"1 BOOT" Single CPE上电或者重启时建立session。包含CPE首次启动、任何原因导致的重启(也包括Reboot方法) InformResponse 重试发送直到重启才能丢弃。
"2 PERIODIC" Single 周期建立session InformResponse CPE不能丢弃未发送的PERIODIC事件。
"3 SCHEDULED" Single 因为ScheduleInform方法调用建立的session。

此事件码必须与“M ScheduleInform”同时使用。

 InformResponse CPE不能丢弃未发送的SCHEDULED事件。
"4 VALUE CHANGE" Single 说明从上次Inform成功(A 3.2.4节定义的条件)后，一个或者多个使能了被动或者主动上报的参数(包含必须强制主动上报的参数)被修改了(即使是恢复到前一次成功Inform的值)

如果事件数组中包含"4 VALUE CHANGE"，所有符合要求的参数都必须在Inform的ParameterList中。如果此事件被丢弃，则列表中的参数也同时被丢弃。

 InformResponse CPE必须重新发送直到重启或者ACS URL修改才能丢弃。
"5 KICKED" Single 表明为了web身份管理(参考附录D)建立session，Kicked方法(参考A.4.2.1节)将在当前session被调用一次或者多次 KickedResponse CPE自己决定是否重新发送。
"6 CONNECTION REQUEST" Single 表明因为收到3.2节定义的ACS"Connection Request"而建立session InformResponse CPE不能重新发送。
"7 TRANSFER COMPLETE" Single 建立session来说明之前的下载或者上传已经完成(不论是否成功)，而且TransferComplete方法将在当前session被调用一次或者多次。

此事件码必须与“M Download” 和/或“M Upload”一起使用

 TransferCompleteResponse CPE不能丢弃未发送的TRANSFER COMPLETE。
"8 DIAGNOSTICS COMPLETE" Single 当完成一个或者多个由ACS发起的诊断测试时，用于重新建立连接 InformResponse CPE必须重新发送直到重启才能丢弃。
"9 REQUEST DOWNLOAD" Single 当CPE要调用一次或者多次RequestDownload方法时，用来建立session RequestDownloadResponse CPE自己决定是否重新发送。
"10 AUTONOMOUS TRANSFER COMPLETE" Single 建立session来说明非ACS发起的下载或者上传已经完成(不论是否成功)，而且AutonomousTransferComplete方法将在当前session被调用一次或者多次。 AutonomousTransferCompleteResponse CPE不能丢弃未发送的AUTONOMOUS TRANSFER COMPLETE。
"M Reboot" Multiple CPE在收到Reboot RPC发送的ACS请求时重启。与"1 BOOT"叠加使用 InformResponse CPE不能丢弃未发送的"M Reboot"。
"M ScheduleInform" Multiple ACS请求一个预定的Inform InformResponse CPE不能丢弃未发送的"M ScheduleInform”。
"M Download" Multiple ACS之前使用Download方法(参考A.3.2.8节)请求的下载完成，与"7 TRANSFER COMPLETE"叠加使用 TransferCompleteResponse CPE不能丢弃未发送的"M Download”。
"M Upload" Multiple ACS之前使用Upload方法(参考A.4.1.5节)请求的上传完成，与"7 TRANSFER COMPLETE"叠加使用 TransferCompleteResponse CPE不能丢弃未发送的"M Upload”。
"M " <vendor-specific method> 未定义 厂家自定义方法请求的操作完成。CPE的行为及ACS的回复由厂家自定义。一个厂家自定义方法必须按A.3.1.1的格式。

比如：“M X_012345_MyMethod”

 未定义 未定义
“X “<OUI> ” ” <event> 未定义 厂家自定义事件。OUI是由6位16进制数组成唯一标识。16进制全部大写，并且前面的0不省略。OUI必须符合参考标准【9】的规定，并且必须是分配给自定义事件厂家的OUI。事件具体的值及解析由厂家自定义

比如：“X 012345 MyEvent”

 未定义 未定义

上表中累积行为那一列，分成了不累积(“Single”)和累积(“Multiple”)两种。比如，如果前一个"1 BOOT"还没发，CPE就重启了，下次Inform包含2个"1 BOOT"是毫无意义的。相反的，如果前一个"M Download"还没发，下一个下载又结束了，下次Inform应该包含两个"M Download"，因为每个对应不同的ACS请求。"Single"和"Multiple"累积行为定义如下：

  • 如果"Single"累积行为的事件发生，不论有多少相同相同类型的事件没有发送，下一个Inform的事件列表中只能包含一个EventCode。
  • 如果"Multiple"累积行为的事件发生，新EventCode必须加入事件列表，独立于未发送的相同类型的事件，也不能影响这些未发送的事件。

当一个或者多个事件关联相同的原因，则所有这些事件必须包含在事件数组中。举例如下(没有列举所有可能性)：

  • 由Reboot RPC方法导致的重启。此时Inform必须至少包含下面的EventCode：
        “1 BOOT”
        “M Reboot”

  • 下载请求对应的TransferComplete，并且传输完成之后没有触发重启：
        “7 TRANSFER COMPLETE”
        “M Download”

  • 自最近的Inform开始，设置了被动通知的一个或者多个参数值修改了，并且周期Inform发生(在这种情况下，所有事件必须包含在同一个Inform里面，因为对被动通知来说，“4 VALUE CHANGE”事件可能由其他原因产生——在这个例子里，是周期Inform)：
        “2 PERIODIC”
        “4 VALUE CHANGE”

对于不同原因产生的事件，如果他们同时发生，CPE可以在同一个Inform消息里包含所有事件，也可以为每个事件发送不同的Inform消息。举例如下：
     “2 PERIODIC”
     “7 TRANSFER COMPLETE”

3.7.1.6 方法重试行为

如果ACS在回复CPE的请求时，发送给CPE一个“Retry request”回复(错误码8005)，CPE必须在当前session的下一个HTTP POST中再次发送同一个请求。所有ACS方法都适用此规则(包含Inform)。

如果CPE收到了错误码不是8005的错误回复，并且回复对应的方法不是Inform，则CPE必须继续当前session，并且不能尝试重试之前的方法(按3.7.1.4节描述，回复对应的方法如果是Inform，将终止session)。

3.7.2 ACS操作

3.7.2.1 session发起

当ACS收到CPE的Inform请求，如果ACS允许建立session，必须回应一个Inform回复。

如果ACS收到CPE的Inform请求，其中的namespace ID指明CPE只支持CWMP v1.0，那么ACS在session的后续操作必须降到v1.0。

    注意 - CWMP v1.0是个特例，因为与其他版本的协议不兼容。v1.1中加入了新的规范来确保
    CPE和ACS都支持v1.1(或者后续版本)时，任何一方都不需要降低版本就能实现兼容。
    (也意味着后续的小版本更新不会增加强制要求的RPC方法)。

    注意 - 只支持CWMP v1.0的ACS期望CPE使用v1.0 namespace标识"urn:dslforum-org:cwmp-1-0"
    来发起Inform请求，并且只包含v1.0定义的事件类型。这种ACS收到v1.1(或者更高版本)Inform请求
    之后的行为无法预测。ACS可能无法感知CPE支持了新版本，此时ACS将回Inform回复；也有可能
    回复一个SOAP层错误；还有可能回复HTTP层错误。如果ACS回复错误，CPE将决定重试失败
    session时，是否降到CWMP v1.0。

ACS必须忽略无法识别的事件类型。

3.7.2.2 接收请求

如果session进行中(session成功发起后，并且在3.7.2.4节描述的session结束标准达到之前)，ACS必须在下一个发往CPE的HTTP回复中，回应来自CPE的SOAP请求。

如果ACS打算阻止CPE在session中发送请求，可以通过设置每个发往CPE的封装HoldRequests头为true来实现，直到ACS再次允许CPE发送请求。ACS必须在session完成之前允许CPE的请求(可以通过HoldRequests头显性地设置，也可以通过发送空的HTTP回复来隐性地设置)。

3.7.2.3 发送请求

如果session进行中(session成功发起后，并且在3.7.2.4节描述的session结束标准达到之前)，如果ACS有一个或者多个请求需要发给CPE，并且最近一次来自CPE的HTTP POST不含SOAP请求，则ACS必须在下一个HTTP回复中发送某个请求。

另外，在session中，如果ACS没有请求需要发送，并且最近一次来自CPE的HTTP POST不含SOAP请求，ACS必须发送空的HTTP回复。

表8总结了在session进行中(session成功发起后，并且在3.7.2.4节描述的session结束标准达到之前)，ACS必须发送给CPE的内容。

表8——ACS发送消息限制

CPE有未完成请求 CPE无未完成请求
有ACS请求 回复 请求
无ACS请求 回复 空的HTTP回复

3.7.2.4 session终止

因为到ACS的HTTP连接由CPE驱动，所以只有CPE能发起和结束连接。

当下面所有条件满足时， ACS必须认为session已经终止：

  1. CPE没有更多请求要发给ACS。当且仅当ACS收到空的HTTP POST，并且HoldRequests为false，ACS才能得出ACS已经没有更多请求的结论。
  2. ACS没有更多请求要发给CPE，并且最近的ACS发给CPE的HTTP回复是空的(用来告诉CPE，ACS已经没有请求要发送)。
  3. ACS已经发送由前一个请求产生的所有未完成的回复消息给CPE。
  4. ACS已经从CPE收到所有未完成的回复消息。

如果在ACS发送最终的HTTP回复之前，上述条件都满足，则ACS最后一个HTTP回复必须为空。

如果上述条件没有被满足，但是ACS在一定时间内没收到CPE的HTTP POST(至少30秒)，ACS可能认为session已经终止。在这种情况下，ACS可能通过"Connection Request"(见3.2.2节)尝试重新建立session。

如果ACS收到的HTTP POST，其中XML不符合格式要求、SOAP格式是无效的、包含不在3.5节定义的SOAP错误或者CPE认为已经违反协议，ACS必须用HTTP 400状态码(Bad Request)回复CPE，并且必须认为session已经异常终止。此错误回复不能包含任何SOAP内容，但是可以包含通俗易懂的文本来解释错误的特征。

如果ACS收到一个请求，其对应的session已经认为终止、或者ACS判定违反了协议、或者ACS自定义的其他原因，ACS可以通过发送HTTP 400状态码(Bad Request)来终止session。此错误回复不能包含任何SOAP内容，但是可以包含通俗易懂的文本来解释错误的特征。

如果ACS收到来自CPE的SOAP错误回复，按3.5节定义，ACS必须将9000-9799(包含)中不识别的错误码解析为9001(Request denied)，并且可能采取如下某种操作：

  • ACS可以强制异常终止session。ACS必须通过回复CPE HTTP 400状态码(Bad Request)来实现。此错误回复不能包含任何SOAP内容，但是可以包含通俗易懂的文本来解释错误的特征。这会导致CPE重试session。
  • ACS可以尝试正常终止session，此时CPE不重试session。为了达到此目的，ACS应该告知CPE没有更多请求，并且应该按上面定义的规则来判断何时终止session。
  • ACS可以继续当前session，继续向CPE发送额外的请求。

3.7.3 事务举例

在图3的例子中，ACS首先读取一组参数值，基于读取的结果，然后设置其中的一些参数。

图3——事务session举例

图4的例子中，ACS首先发起文件下载，CPE随后在同一个session中发送"TransferComplete"。注意，下面的场景只有当要下载的文件比较小时才会发生，并且CPE能够在session进行中传输文件(此要求对CPE不是必须的)。为了达到这种效果，ACS将HoldRequests设置为true，直到完成ACS向CPE发送请求。

图4——ACS设置HoldRequests为true的例子

参考标准

本规范参考的文档罗列如下。除非特别说明，CWMP中引用的参考标准，默认支持参考标准的所有的必选功能。

下面的参考标准与CWMP的约定或者上下文有关，但是并不直接与CWMP相关联。

【1】RFC 2119，RFCs中表示需求等级的关键字， http://www.ietf.org/rfc/rfc2119.txt

【2】TR-046，自动配置架构和框架

【3】TR-062，DSL B-NT和ATM网络之间连接的自动配置

【4】TR-044，基础网络服务的自动配置

下面的参考标准与CWMP的必选功能相关联。

【5】RFC 2616，HTTP/1.1，http://www.ietf.org/rfc/rfc2616.txt

【6】RFC 2617，HTTP认证：Basic和Digest认证，http://www.ietf.org/rfc/rfc2617.txt

【7】RFC 2965，HTTP状态管理机制， http://www.ietf.org/rfc/rfc2965.txt

【8】SOAP 1.1，Simple Object Access Protocol (SOAP) 1.1

【9】OUIs，http://standards.ieee.org/faqs/OUI.html

【10】 SSL 3.0，http://wp.netscape.com/eng/ssl3

【11】 RFC 2246，TLS 1.0， http://www.ietf.org/rfc/rfc2246.txt

【12】RFC 3986， URI：通用语法，http://www.ietf.org/rfc/rfc3986.txt

【13】TR -106 Amendment 1， TR-069设备的数据模型模板。

下列标准与CWMP的可选或者推荐的功能相关。

【14】RFC 2132，DHCP option和BOOTP Vendor扩展，http://www.ietf.org/rfc/rfc2132.txt

【15】XML签名语法和处理，http://www.w3.org/2000/09/xmldsig

【16】PKCS #7，加密消息语法标准， http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html 或者 http://www.ietf.org/rfc/rfc2315.txt

【17】端口号，http://www.iana.org/assignments/port-numbers

【18】IANA私有企业注册号，http://www.iana.org/assignments/enterprise-numbers

【19】RFC 2104，HMAC：用于消息身份验证的密钥哈希，http://www.ietf.org/rfc/rfc2104.txt

【20】RFC 2131，DHCP，http://www.ietf.org/rfc/rfc2131.txt

【21】RFC 3489，STUN - NAT的UDP简单穿越，http://www.ietf.org/rfc/rfc3489.txt

【22】RFC 3925，DHCPv4 供应商身份Vendor Options ，http://www.ietf.org/rfc/rfc3925.txt

【23】HTML 4.01标准，HTML 4.01 Specification

【24】TR-098 Amendment 1

【25】TR-104，VoIP型CPE的配置参数

​

《TR-069_Amendment-2》翻译相关推荐

  1. 《Git版本控制管理（第2版）》——4.3　Git在工作时的概念

    本节书摘来自异步社区<Git版本控制管理(第2版)>一书中的第4章,第4.3节,作者:[美]Jon Loeliger , Matthew McCullough著,更多章节内容可以访问云栖社 ...

  2. 【Git版本控制管理】Gitee(码云)和GitHub的使用

    远程仓库的使用 文章目录 远程仓库的使用 使用码云(Gitee) 使用GitHub 远程仓库是指托管在因特网或其他网络中的你的项目的版本库. 你可以有好几个远程仓库,通常有些仓库对你只读,有些则可以读 ...

  3. java中git版本控制,git版本控制管理是什么？git如何实现版本控制？

    大家好,今天要跟大家讲的是关于git版本控制管理的一点小知识,git相信程序员小伙伴们都已经很熟悉了,很多项目开发都需要git,所以,git版本控制管理到底是干嘛的呢?Git又如何实现版本控制呢?下面 ...

  4. Git 版本控制管理(一)

    Git 是一个分布式版本控制工具,它的作者 Linus Torvalds 是这样给我们介绍 Git  -- The stupid content tracker(傻瓜式的内容跟踪器) 关于 Git 的 ...

  5. Git版本控制管理——简介

    说明 在大型项目开发或者多人协作开发时,都希望可以对软件代码进行管理和追踪,以便确认开发的进度和方便问题追溯.这就需要使用到版本控制系统(VCS),比如Git就是一款很优秀的版本控制工具.如今很多项目 ...

  6. 3.git版本控制-管理修改、撤销、删除

    管理修改 第一次修改 -> git add -> 第二次修改 -> git commit,Git管理的是修改,当你用git add命令后,在工作区的第一次修改被放入暂存区,准备提交, ...

  7. Git版本控制管理——远程版本库

    之前提到的Git的所有操作都是在本地完成的,而实际项目开发并不是一个人就可以搞定的,通常需要团队的协作,而这些协作可能又不是在同一个地区的,这就涉及到Git的分布式特性了. Git的分布式特定会涉及到 ...

  8. Git版本控制管理(二)--git配置

    在系统上安装好 Git后,还需要配置Git 环境. 每台计算机上只需要配置一次,程序升级时会保留配置信息,也可以在任何时候再次通过运行命令来修改它们. 配置文件位置 Git 自带一个 git conf ...

  9. Git版本控制管理——版本库管理

    本文主要说明如何发布Git仓库. 发布版本库 对于Git来说,服务器并不是必需的.Git更乐于与同一台机器上的同级版本库直接交换文件,而不需要某个服务器来进行代理,或通过各种不需要上级服务器的协议与不 ...

  10. Git版本控制管理——基本Git概念

    基本概念 版本库 Git版本库(repository)只是一个简单的数据库,其中包括所有用来维护与管理项目的修订版本和历史信息.而Git版本不仅会维护项目整个生命周期的完整副本,还会提供版本库本身的副 ...

最新文章

  1. java 对变量加锁_Java最全锁剖析：独享锁/共享锁+公平锁/非公平锁+乐观锁/悲观锁...
  2. 维护一套同时兼容 iOS 6 和 iOS 7，并且能够自动适应两个系统的 UI 风格的代码...
  3. speech_to_text_demo powered by IBM!
  4. Spring-Cloud中的 熔断、限流、降级
  5. [(转)hystar整理]Entity Framework 教程
  6. Unity（一）Unity脚本程序开发
  7. win 7 ×××自动拨号设置
  8. Spark基础学习笔记10：Scala集成开发环境
  9. Linux使用openssl实现RSA非对称加密
  10. mysql 主从 日志_mysql主从复制基于日志复制
  11. 2021-06-29提交表单事件
  12. python分析html文件_如何用Python解析HTML?
  13. 子进程 已安装 pre-removal 脚本 返回了错误号 1或2 与 子进程 已安装 post-installation 脚本 返回了错误号 1或2
  14. 医院医疗类报表免费用，提反馈，还能赢取P30！
  15. ArcGIS计算地形湿度指数
  16. 中级软件评测师下午题总结
  17. 数据分析三大神器之一：Numpy
  18. 如何让cmd一直默认以管理员身份打开
  19. 将Flutter添加到现有应用——过程中遇到的问题
  20. 我的世界服务器ess配置文件,《我的世界》ess指令大全及用法详解

热门文章

  1. 时空行为检测数据集 JHMDB UCF101_24 详解
  2. html 安卓解锁,【华为手机解账户锁教程】手撕篇3 完美解锁华为EMUI8.0,8.1,8.2系统...
  3. 高等数学 常用数学公式
  4. VS-RK3399 and VS-RK3288 Audio 开发指南
  5. UIControl 纠错
  6. 妙味课堂原创JavaScript视频教程基础+提高+项目
  7. java 定时器 的中断程序,AVR单片机教程——定时器中断
  8. C中字符串常量字符数组字符常量
  9. xlsx xlsx-style 设置导出的exce表格样式
  10. python webqq机器人_使用Python的Tornado框架实现一个简单的WebQQ机器人