- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
19-Web Cache配置
本章节下载： 19-Web Cache配置 (693.78 KB)
1.6.7 配置Web Cache缓存的最小访问次数以及缓存键的老化时间
1.12.1 配置Web Cache双网关场景下的流量互引功能
1.12.2 开启Web Cache对QueryString请求的文件的缓存功能
1.12.3 配置Web Cache忽略指定的HTTP/HTTPS响应头类型
1.12.4 配置Web Cache设备的上下游连接模式以及代理模式
1.12.6 配置Web Cache的HTTPS证书认证方式
Web Cache（网站缓存）是将用户通过HTTP/HTTPS协议访问过的指定地址服务器的Web页面上的内容，缓存在本地，在缓存文件的老化时间内用户访问相同内容时，直接从本地响应的一种缓存功能，从而减少设备到服务器的访问流量、降低传输成本、缓解目的端服务器压力，同时提高了用户访问网站的速度及响应时间，增强了用户体验。
需要缓存的Web页面内容以文件的形式存放于Web Cache的工作路径中。缓存文件总大小超出缓存允许存储的最大空间时，最旧的缓存文件将被覆盖。
本文中描述的侦听端口分为两类端口。
· Web Cache侦听端口：设备提供Web Cache服务的端口，只有发送给该端口的报文，才会送至Web Cache进程处理。
· Web服务器侦听端口：Web服务器上提供Web服务的端口，只有发送给该端口的报文，才会送至Web进程处理。
每个Web Cache缓存文件的老化时间为30天。设备收到相同Web内容的请求或重启时，会重新计算该缓存文件的老化时间。若超过老化时间仍没有用户请求该缓存文件，则删除该缓存文件。
Web Cache的工作原理如下所示：
图1-1 Web Cache工作原理示意图
(2) 用户主机（Host）发送给Web服务器（Server）的HTTP/HTTPS GET请求报文到达设备（Device）后，若请求服务的目的端口为指定的Web服务器侦听端口，则设备会将该目的端口转换为对应的Web Cache侦听端口以触发Web Cache进程。
(3) Web Cache获取报文的URL，依据URL在Web Cache工作路径下的各个缓存文件中进行查找：
¡ 若找到匹配项，则构建响应报文，并将找到的缓存内容直接返回给主机。
¡ 若未找到匹配项，则继续进行下面的处理。
(4) 设备重新封装HTTP/HTTPS GET请求报文发送给Web服务器。
(5) 当设备收到服务器的响应后，检查是否为可以缓存的文件类型：
¡ 若可以缓存，会将缓存内容保存到工作路径下的缓存文件中，并将缓存内容构建成响应报文发送给主机。
¡ 若不允许缓存，则直接将缓存内容构建成响应报文发送给主机。
设备发送响应报文时，若Web Cache的侦听端口和Web服务器的侦听端口不一致，则设备会将响应报文的源端口替换回Web服务器的侦听端口号后发送。
为了增强Web Cache功能的可靠性，设备支持配置Web Cache主用slot和备用slot，以实现Web Cache的主备功能。正常情况下，Web Cache主用slot对外提供Web Cache服务。当主用slot发生故障时，备用slot上的Web Cache进程接替主用slot上的Web Cache进程继续对外提供Web Cache服务，以便保证Web Cache服务不中断。当主用slot修复且备用slot故障时，Web Cache服务才切换回主用slot。
Web Cache工作路径也支持配置主用工作路径和备用工作路径。主用工作路径为主用slot服务，用于存放Web Cache主用进程工作时的缓存文件和工作数据；备用工作路径为备用slot服务，用于存放Web Cache备用进程工作时的缓存文件和工作数据。
如图1-2所示，为了方便差异化配置，Web Cache存在两个配置层级：
(1) Web Cache视图下的配置：相当于Web Cache的全局配置。
(2) 缓存策略模板中的配置：在Web Cache视图下可以创建多个缓存策略模板，每个缓存策略模板下都可以配置一些Web Cache缓存行为相关策略，包括缓存的匹配规则以及缓存的处理规则等。此机制可以方便用户按需定制个性化的缓存控制方案，扩展Web Cache功能的适用场景。
Web C ache在执行缓存时，将缓存数据通过URI等特性匹配缓存策略模板，如果匹配到了缓存策略模板，则使用该策略模板下的配置对缓存数据进行相应的处理；如果未匹配到任何缓存策略模板，则使用Web Cache视图下的配置对缓存数据进行相应的处理。
图1-2 Web Cache的配置层级
Web Cache需要安装License才能使用。未安装license时，重启设备会自动删除Web Cache的相关配置。有关License的详细介绍，请参见“基础配置指导”中的“License管理”。
请先配置允许缓存Web页面上的文件类型和Web Cache的工作路径，再开启Web Cache功能。如果在Web Cache运行过程中需要修改Web Cache参数，需先关闭Web Cache功能，完成修改后再次开启。
当前手册中的部分配置同时支持在Web Cache视图以及缓存策略模板视图下配置。在两个视图下同时配置时，对于某个缓存资源，优先采用匹配到的缓存策略模板视图下的配置，如果未匹配任何缓存策略模板，才使用Web Cache视图下的配置。
建议在Web Cache功能处于关闭状态时再配置Web Cache相关功能。
Web Cache的配置任务如下：
(1) （可选）创建Web Cache缓存策略模板
(2) （可选）配置Web Cache缓存策略模板
¡ 配置Web Cache缓存的最小访问次数以及缓存键的老化时间
¡ 配置缓存有效时间
(4) （可选）配置Web Cache缓存文件的老化时间
(5) （可选）配置Web Cache源或目的过滤规则
(6) 配置Web Cache侦听端口号
(8) （可选）配置Web Cache扩展功能
¡ 开启Web Cache对QueryString请求的文件的缓存功能
¡ 配置Web Cache忽略指定的HTTP/HTTPS响应头类型
(9) 开启Web Cache功能
(10) （可选）Web Cache逃生功能
(11) （可选）配置Web Cache备份功能
(12) （可选）配置Web Cache预缓存功能
cache-profile命令不能和cached-data exclude命令同时配置。
可通过多次执行cache-profile命令，创建多个Web Cache缓存策略模板，最多支持创建1024个Web Cache缓存策略模板。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 创建Web Cache缓存策略模板，并进入Web Cache缓存策略模板视图。
cache-profile profile-name
缺省情况下，不存在Web Cache缓存策略模板。
在缓存策略模板下，配置了缓存资源的匹配规则以及对缓存资源的处理策略。能通过匹配规则匹配到缓存策略模板的缓存数据则会按照该模板下配置的相关处理策略进行处理。
本功能用来配置URI的匹配规则，决定缓存策略模板的配置对哪些缓存资源生效，并使得Web Cache允许缓存规则匹配到的URI的资源。
目前支持如下匹配规则：
· 精确文本匹配（不指定prefix参数、指定text参数）：仅当URI与指定字符串完全一致时，才匹配成功。
· 正则表达式匹配（不指定prefix参数、指定regular或者regular-case-insensitive参数）：仅当URI整体符合指定的正则表达式时，才匹配成功。
· 前缀文本匹配（指定prefix和text参数）：仅当URI以指定字符串开头时，才匹配成功。
· 前缀正则表达式匹配（指定prefix和regular参数）：仅当URI以符合指定正则表达式的方式开头时，才匹配成功。
指定prefix参数时，指定字符串应当以“/”开头，例如：
· uri prefix regular /(dir1|dir2)，表示匹配前缀为“/dir1”或者“/dir2”的URI。
· uri prefix text /dir1，表示仅匹配前缀为“/dir1”的URI。
在正则表达式匹配模式下，输入的字符串必须满足正则表达式的语法。例如：
uri regular-case-insensitive \\.(docx|pptx|xlsx)$表示匹配以.docx、.pptx或.xlsx 结尾的URI。请确保所填写的正则表达式语法正确，否则可能会影响WebCache缓存功能的正常工作。
如果URI包含空格，需要使用双引号包含参数，例如uri regular "document files"。
如果URI内容包含右斜杠(\)或双引号(")，输入命令行时需要使用转义符(\)。例如命令行输入(\\)，最终结果为(\)，命令行输入(\")，最终结果为(")。
建议配置URI时尽量不要包含上述特殊符号。
如果同时配置了本功能以及Web Cache视图下的文件过滤规则，则匹配了本功能配置的URI的资源一定能被Web Cache缓存，而无需考虑是否符合Web Cache视图下的文件过滤规则。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(4) 配置URI的匹配规则。
uri { prefix { regular | text } | { regular | regular-case-insensitive | text } } uri-string
缺省情况下，未配置URI的匹配规则。
Web Cache存在多种可缓存的资源过滤规则，为了灵活控制资源的可缓存命中率，可以通过本功能配置缓存的命中规则。通过合理设置哪些请求被认为是“相同资源”，可以让更多用户请求命中缓存，减少重复回源，提高系统响应速度和带宽利用率。并且如果不同参数的请求实际上内容不同，却被错误地缓存为同一份内容，用户就会看到不正确的数据。通过细化匹配规则，可以保证内容的准确性。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置缓存的命中规则。
cache-key { ignore-all-args | with-all-args | { specify-args custom-args&<1-10> } }
缺省情况下，命中规则为忽略全部参数。
(4) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(5) 配置缓存的命中规则。
cache-key { ignore-all-args | with-all-args | { specify-args custom-args&<1-10> } }
缺省情况下，命中规则为忽略全部参数。
存在多个缓存策略模板时，多个缓存策略模板之间也存在匹配的优先顺序，具体规则为：
(1) 按URI的匹配规则进行排序：精确文本匹配＞前缀正则表达式匹配＞正则表达式匹配＞前缀文本匹配。在正则表达式匹配规则中，无论是否区分大小写，优先顺序都相同。
(2) 若匹配规则相同，则比较缓存策略模板的优先级值。优先级值越小缓存策略模板越优。
(3) 若匹配规则和优先级值都相同，则按照字母序优选缓存策略模板。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(4) 配置缓存策略模板的优先级值。
priority priority
缺省情况下，未配置缓存策略模板的优先级值。
在正常情况下，HTTP响应头中通常会包含源站设置的缓存有效时间，例如，Cache-Control: max-age=3600表示该资源的缓存有效时间为3600秒。在有效期内，Web Cache 设备会直接使用本地缓存数据对用户的HTTP/HTTPS请求进行响应，无需再次向Web服务器请求。
然而，如果源站设置的有效时间过长，而资源在此期间发生了更新，用户可能会在较长时间内访问到过期的旧资源。
为了解决这一问题，可以通过本功能配置“强制缓存有效时间”。配置后，Web Cache 会将源站有效时间和强制缓存有效时间中的较小值作为最终有效时间。这样，即使源站设置了较长的有效时间，Web Cache 也能及时刷新缓存，确保用户能够尽快访问到最新的资源。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置强制缓存的有效时间。
cache-valid interval interval
缺省情况下，未配置强制缓存的有效时间。
(4) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(5) 配置强制缓存的有效时间。
cache-valid interval interval
缺省情况下，未配置强制缓存的有效时间。
web-cache在处理为较大的缓存内容时，需要把缓存内容分片。通过本功能，可以配置document缓存策略下的分片大小。当缓存内容比分片更小时，缓存不分片。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(4) 配置将Web Cache缓存分片。
cache-block size { 1 | 2 | 4 | 8 | 16 | 32 | 64 }
缺省情况下，缓存不分片。
如果Web Cache缓存请求量较低的资源，会造成设备存储空间的浪费，因此可以设置缓存的最小访问次数。只有当某个资源被客户端请求的次数达到设定的最小访问次数时，Web Cache系统才会将该资源缓存在本地；否则，该资源的内容不会被缓存，后续请求仍需向Web服务器获取。
为了避免不活跃的缓存键持续占用Web Cache设备的内存空间，可以设置缓存键的老化时间。如果在老化时间内某个缓存资源都未达到最小访问次数，则设备会删除内存中的此缓存键。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache缓存的最小访问次数以及缓存键的老化时间。
cache-min-uses hit-count [ aging-time aging-time ]
缺省情况下，未配置Web Cache缓存的最小访问次数以及缓存键的老化时间。
(4) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(5) 配置Web Cache缓存的最小访问次数以及缓存键的老化时间。
cache-min-uses hit-count [ aging-time aging-time ]
缺省情况下，未配置Web Cache缓存的最小访问次数以及缓存键的老化时间。
缺省情况下，Web Cache设备会拦截并替换上游响应中的Date头和Server头，并改写为自身的时间和标识。
如果客户端需要知道内容在Web服务器上生成的准确时间，而不是Web Cache缓存的时间，可以在Web Cache设备上配置本功能并指定date参数使得Web Cache设备保留上游响应中的Date头。
如果客户端需要知道后端具体服务器类型，可以在Web Cache设备上配置本功能并指定server参数使得Web Cache设备保留上游响应中的Server头。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(4) 配置响应头透传相关设置。
pass-header { date | server } *
缺省情况下，Web Cache设备会拦截并替换上游响应中的Date头和Server头，并改写为自身的时间和标识。
每个Web Cache的缓存对象都会有一个缓存键（cache key），用来唯一标识和检索该缓存对象。缓存键最大可用空间是指设备上专门用于保存所有缓存键及其索引信息的空间最大总量。缓存键最大可用空间占满时，新增的缓存键会覆盖最久未用的缓存键。
当出现缓存键数量大幅增加、缓存命中率下降、缓存条目频繁被清理时，建议通过本功能适当增大缓存键的最大可用空间。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置缓存键最大可用空间。
cache-keys-zone size
缺省情况下，缓存键最大可用空间为50MB。
(4) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(5) 配置缓存键最大可用空间。
cache-keys-zone size
缺省情况下，缓存键最大可用空间为50MB。
本功能用于设置Web Cache设备上缓存的最大有效期时间。通过合理配置缓存有效时间，可以在提升系统响应速度和降低Web服务器压力的同时，确保用户获取到较为新鲜的数据。
设置缓存有效时间后，当客户端发起请求时：
· 如果Web Cache的缓存中已经有该请求对应的数据，且该数据的存放时间还没有超过设定的有效时间值，则Web Cache设备会直接返回已缓存的数据，以减轻Web服务器的压力。
· 如果缓存的数据已经存放超过指定的有效时长，则再收到客户端的新请求时，Web Cache设备会重新请求Web服务器，用后端返回的新数据来验证缓存是否仍然有效，并根据新数据更新缓存内容。
对于频繁更新的资源，建议设置较短的有效时间，对于长期不变的静态资源，建议设置较长的有效时间。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(4) 配置缓存有效时间。
cached-data valid-time { http-status-codes | any } valid-time
缺省情况下，未配置缓存有效时间。
缺省情况下，Web Cache可以缓存Web页面上的所有文件。通过配置本功能，可对Web Cache能缓存的文件进行过滤。
管理员可设置三种正向过滤规则：
· 通过文件类型进行过滤。
· 通过文件名称进行过滤。
· 通过文件扩展名进行过滤。
配置上述任意正向过滤规则后，Web Cache将只能缓存满足过滤规则的文件，当上述三种方式均配置时，则满足其中任一配置的Web资源都可以被缓存，优先使用文件名进行完全匹配。
管理员也可以设置反向过滤规则，目前仅支持通过文件名称中包含的关键字进行过滤，配置反向过滤规则后，Web Cache将不允许缓存满足过滤规则的文件，可以缓存未满足过滤规则的文件。
修改Web Cache的文件过滤规则前，需要关闭Web Cache功能，完成修改后再次开启。
正向过滤规则和反向过滤规则互斥，不能同时配置。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置允许缓存Web页面上的文件类型。
cached-data { apk | bmp | doc | docx | gif | gzip | ipa | jar | jpg | jpeg | mp4 | pdf | png | ppt | pptx | rar | swf | tar | txt | xls | xlsx | zip } *
缺省情况下，未配置允许缓存Web页面上的文件类型。
(4) （可选）配置允许缓存Web页面上的文件。
cached-file file-name
缺省情况下，未配置Web Cache允许缓存的文件。
(5) （可选）配置Web Cache允许缓存的文件扩展名。
cached-extension-name extension-name
缺省情况下，未配置可缓存的文件扩展名。
可通过多次执行本命令，配置多个Web Cache允许缓存的文件扩展名，最多同时存在64个文件扩展名。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache不允许缓存的文件。
cached-data exclude { acp | ashx | asp | cgi | chk | chm | eml | ephtml | html | json | php | phtml | shtml | ska | tmp | filename-keyword keyword }
缺省情况下，Web Cache可以缓存所有文件。
多次执行本命令，可以设置多个Web Cache不允许缓存的文件类型和文件，最多支持64个不允许缓存的文件类型和文件。
为了节省设备的存储空间，Web Cache缓存文件如果长时间未被用户请求，则会被设备删除，这一段时间被称为Web Cache缓存文件的老化时间。通过本功能可以修改Web Cache文件的老化时间：
· 如果设备的存储空间资源富余，可以配置较长的老化时间。
· 如果设备的存储空间资源紧张，可以配置较短的老化时间。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache缓存文件的老化时间。
cached-data aging-time aging-time
缺省情况下，Web Cache缓存文件的老化时间为1440分钟。
(4) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(5) 配置Web Cache缓存文件的老化时间。
cached-data aging-time aging-time
缺省情况下，Web Cache缓存文件的老化时间为1440分钟。
缺省情况下，Web Cache可缓存所有Web服务器的数据。通过配置本功能，可以对Web Cache源或目的进行过滤。根据配置object-group命令时指定的参数不同，本功能的具体过滤机制如下：
· 指定exclude参数时：
¡ 如果指定了source参数，Web Cache将不缓存IP地址匹配object-group-name的用户客户端申请的Web数据。
¡ 如果未指定source参数，Web Cache将不缓存IP地址匹配object-group-name的Web服务器响应的Web数据。
· 未指定exclude参数时：
¡ 如果指定了source参数，Web Cache将仅缓存IP地址匹配object-group-name的用户客户端申请的Web数据。
¡ 如果未指定source参数，Web Cache将仅缓存IP地址匹配object-group-name的Web服务器响应的Web数据。
引用了对象组后，设备收到用户主机发送给Web服务器的HTTP/HTTPS GET请求报文时，会检查是否允许缓存该服务器或是否允许缓存该用户主机请求的Web资源，若允许，将报文送达至设备中的Web Cache，否则直接转发到服务器。
Web Cache使用本功能引用了未创建地址对象的空对象组时，如果未指定exclude参数，设备将不对任何Web服务器的Web资源进行缓存、以及拒绝来自任何客户端的Web资源缓存请求；如果指定了exclude参数，设备将可以对任何Web服务器的Web资源进行缓存、以及允许来自任何客户端的Web资源缓存请求。
配置本功能前：
· 请先配置IPv4或IPv6地址对象组。有关地址对象组功能的详细介绍，请参见“安全配置指导”中的“对象组”。
· 需要关闭基于HTTP的Web Cache功能，完成修改后再次开启。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置引用地址对象组来对Web Cache缓存的Web数据进行过滤。
object-group [ exclude ] [ source ] { ip | ipv6 } object-group-name
缺省情况下，Web Cache未对缓存的web数据进行过滤。
缺省情况下，Web Cache侦听HTTP报文的端口为4180，可缓存HTTP报文侦听端口为80的Web服务器资源；Web Cache侦听HTTPS报文的端口为2043，可缓存HTTPS报文侦听端口为443的Web服务器资源。出现以下任一场景时，可以配置本功能：
· Web Cache的缺省侦听端口被本设备的其它业务占用，Web Cache功能无法开启。
· 缓存资源所属的Web服务器侦听端口不是80（HTTP）或443（HTTPS）。
当设备缓存多个Web服务器上的数据时，且这些Web服务器侦听的端口不同，则需要多次执行本命令，逐个配置Web服务器侦听端口，使其与Web Cache侦听端口一一对应，最多可配置对应关系的数量与设备型号有关，详细说明如下表所示。
|
型号 |
数量 |
|
MSR1008 |
8 |
|
MSR1004-G |
8 |
|
MSR1004-G-5GCN |
8 |
|
MSR1104-G、MSR1104-G-DSL-CAT6 |
8 |
|
MSR2630E-X1 |
16 |
|
MSR3610E-X1、MSR3610E-X1-DP |
16 |
|
MSR3610-G-X3-DP、MSR3610-G-X3、MSR3610-G-X3-DP-DC、 MSR3610-G-X3-DC |
16 |
|
MSR3620-G-X3 |
32 |
|
型号 |
说明 |
|
MSR2660-XS |
8 |
|
MSR2680-XS |
16 |
|
型号 |
说明 |
|
MSR2600-12X-WiNet |
8 |
|
MSR2610-13X-WiNet |
16 |
多次配置本功能，将一个Web Cache侦听端口绑定多个Web服务器侦听端口、或者多个Web Cache侦听端口绑定同一个Web服务器侦听端口时，均会将配置覆盖，仅最新配置生效。
配置本功能前：
· 需要关闭Web Cache功能，完成修改后再次开启。
· 请使用display tcp verbose命令来查看当前设备正在使用的TCP端口号，以确保指定的端口号是未被其他业务使用的端口号，否则本功能配置失败。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache的TCP侦听端口号。
¡ 配置Web Cache侦听HTTP报文的端口号。
listen-port port-number [ server-port server-port-number ]
¡ 配置Web Cache侦听HTTPS报文的端口号。
https listen-port port-number [ server-port server-port-number ]
通过配置本功能，可以指定Web Cache的工作路径，设备存储空间有限时，可通过cache-limit命令来限制所有Web Cache缓存文件的总大小的最大值。
指定Web Cache的工作路径时，需要注意的是：
· 指定的工作路径必须是创建Web Cache视图时指定的slot上的路径，且不能为二级目录。否则，配置失败。
· 配置Web Cache的工作路径前，请保证该目录下没有与工作路径最后一级名称相同且不带文件扩展名的文件存在，否则，Web Cache异常退出。
· Web Cache的缓存文件和工作数据通常会占用较大的存储空间（GB级别），建议工作路径配置在存储空间较大的存储介质上。
配置Web Cache的文件存储参数前，需要关闭Web Cache功能，完成修改后再次开启。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache工作路径。
file-directory directory
缺省情况下，未配置Web Cache工作路径。
(4) （可选）配置所有Web Cache缓存文件总大小的最大值。
cache-limit size
缺省情况下，所有Web Cache缓存文件的总大小的最大值为4GB。
指定所有Web Cache缓存文件的总大小的最大值必须小于工作路径中可存储数据的最大值。
(5) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(6) 配置匹配到缓存策略模板的资源的工作路径。
file-directory directory
缺省情况下，未配置Web Cache工作路径。
(7) （可选）配置匹配到当前缓存策略模板的Web Cache缓存文件总大小的最大值。
cache-limit size
缺省情况下，所有Web Cache缓存文件的总大小的最大值为4GB。
本功能用于Web Cache双网关场景，如图1-3所示。在本场景中，Device A和Device B通过接入交换机同时为用户提供Web Cache缓存服务，Web Cache服务的上下行链路均存在等价路径。当用户访问Web资源的上、下行路径不一致时，例如，用户访问Web资源的上行流量经过Device A，而下行流量却经过Device B；此时由于Device B上没有用户记录，无法将下行流量转发给用户，导致用户访问Web资源失败。
在本场景中，上行流量为用户主机发送往Web服务器的HTTP/HTTPS请求报文流量，下行流量为Web服务器返回给用户主机的HTTP/HTTPS响应报文流量。网关设备之间的引流通道为直连的物理链路或GRE隧道，以保证Web Cache网关与对端设备之间的IP连通性。
图1-3 用户访问Web资源失败示意图
通过在Device B上配置本功能，可以让设备和对端网关建立流量互引关系，如图1-4所示：建立互引关系后，如果Device B收到了无法查找到用户的Web Cache下行流量，Device B就会将下行流量从指定的通道接口转发给对端设备Device A处理，使Device A能够正确代理用户所需的Web资源。
在配置与指定对端设备建立流量互引关系前，需要完成以下任务：
· 建立网关之间的引流通道，以保证下行流量能通过引流通道到达对端设备。
· 关闭Web Cache功能，完成修改后再次开启。
在配置dual-gateway-channel命令时，请确保指定对端设备的IPv4地址可达，并且在路由转发表中该地址的出接口为本命令配置的通道接口。
可通过多次执行dual-gateway-channel命令，在多个VPN实例下分别建立流量互引关系。指定公网或同一VPN实例多次执行该命令时，最后一次执行的命令生效。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置与对端设备建立流量互引关系。
dual-gateway-channel [ vpn-instance vpn-instance-name ] interface interface-type interface-number peer ipv4-address
缺省情况下，设备未与对端设备建立流量互引关系。
缺省情况下，URL中QueryString请求的文件不会被Web Cache缓存。配置本功能后，Web Cache可以缓存QueryString请求的文件。Web Cache会结合其他的文件过滤规则最终决定是否缓存QueryString请求的文件。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 开启Web Cache对QueryString请求的文件的缓存功能。
querystring-file-cache enable
缺省情况下，Web Cache对QueryString请求的文件的缓存功能处于关闭状态。
Cache-Control、Set-Cookie以及Vary响应头，对Web Cache服务缓存Web资源的影响如下：
· Web服务器返回的HTTP/HTTPS响应报文中携带Cache-Control响应头时，根据Cache-Control响应头包含的指令，Web Cache可能不会缓存本次请求的Web资源。
· Web服务器返回的HTTP/HTTPS响应报文中携带Set-Cookie响应头时，Web Cache不会缓存本次请求的Web资源。
· Web服务器返回的HTTP/HTTPS响应报文中携带Vary响应头时，根据Vary消息的取值，Web Cache可能不会缓存本次请求的Web资源。
配置本功能后，Web Cache会忽略指定的响应头类型，以确保能够缓存用户请求的Web资源。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache忽略指定的HTTP/HTTPS响应头类型。
cache-ignore { cache-control | set-cookie | vary } *
缺省情况下，Web服务器返回的HTTP/HTTPS响应头类型影响Web Cache服务是否缓存资源。
(4) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(5) 配置Web Cache忽略指定的HTTP/HTTPS响应头类型。
cache-ignore { cache-control | set-cookie | vary } *
缺省情况下，Web服务器返回的HTTP/HTTPS响应头类型影响Web Cache服务是否缓存资源。
Web Cache设备的上游连接为与Web服务器的TCP连接，下游连接为与用户客户端的TCP连接。Web Cache设备代替用户向Web服务器请求资源，相当于客户端的HTTP代理。Web Cache设备可以通过本功能修改连接模式和代理模式，各模式之间的区别如下：
· 长连接：Web Cache设备在完成一次请求-响应后不会立即断开上下游连接，而是保持一段时间，在这段时间内多个HTTP/HTTPS请求和响应都可以复用该链接。长连接可以减少频繁建立TCP连接带来的开销，提高通信效率，因此适合高并发、频繁通信的场景。
· 短连接：每完成一次请求-响应，Web Cache设备的上下游连接就会断开。因此每次请求都要重新建立新的连接。短连接模式的TCP连接开销较高，通信效率较低，但是也意味着每次请求都需要重新认证，可以避免TCP连接复用带来的潜在风险，因此适用于请求量低且安全性要求较高的场景。
· 半透明代理：Web Cache设备在客户端和Web服务器之间代理转发请求和响应。客户端无需显式配置代理，但Web Cache设备会对请求报文进行一定程度的修改（例如修改源端口号）。同时，Web Cache设备的IP地址对Web服务器不可见，服务器感知到的是客户端的真实IP。此模式适用于需要对流量内容进行处理，但又希望Web服务器能感知到用户真实IP的场景。
· 纯透明代理：Web Cache设备在客户端和Web服务器之间代理转发请求和响应。客户端无需显式配置代理，Web服务器也察觉不到Web Cache设备的存在。同时，Web Cache仅做转发，不更改请求或响应内容，即服务器感知到的是客户端的真实IP地址和端口号。此模式适用于Web Cache无需对流量内容进行任何处理，且希望客户端和服务器都无感知代理存在的场景。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache设备的上下游连接模式以及代理模式。
transparent-proxy keepalive [ keep-source-port ] enable
缺省情况下，Web Cache设备的上下游连接方式为长连接，代理模式为半透明。
执行本功能后，设备根据当前所有Web Cache配置生成一个配置文件——webcache-prebuilt.conf。该配置文件存放在设备的Web Cache工作路径中。用户可以将该配置文件取出并加载到远程控制器中，以实现运行环境和配置的快速下发。
(1) 生成Web Cache的预配置文件。
web-cache prebuilt config-file
本命令用于方便网络管理员灵活选择Web Cache在提供HTTPS服务时证书的认证方式。用户客户端在进行HTTPS访问时，证书的运作机制为：
(1) Web服务器将自身的证书发布给Web Cache设备，Web Cache设备认证该证书并与Web服务器建立HTTPS连接。
(2) Web Cache设备将自身的证书发布给用户客户端，用户客户端认证该证书并与Web Cache设备建立HTTPS连接。
目前可以通过两种方式影响用户客户端对Web Cache设备的证书的认证，两种方式的介绍和优劣势对比如下：
· 内置证书认证方式：在此方式下，Web Cache设备使用私有的证书与用户客户端建立HTTPS连接，由于Web Cache设备的私有证书未经过权威CA机构认证，用户客户端必须要在本地安装Web Cache设备发布的私有根证书，才能对来自Web Cache设备的私有证书成功认证。此方式的优势是安装了私有根证书后，理论上用户客户端可以通过HTTPS连接访问任何Web服务器（只要Web Cache设备能够与该Web服务器建立HTTPS连接），而劣势是用户客户端需要自行安装根证书，操作较繁琐，不便于使用。
· 第三方证书认证方式：在此方式下，Web Cache设备使用用户客户端想要访问的Web服务器的证书来与用户客户端建立HTTPS连接。本方式相当于对Web服务器的证书进行代理，在建立HTTPS连接时向用户客户端发布Web服务器的证书而不是自身的私有证书，这样在进行HTTPS连接时全程无需使用私有证书。此方式的优势是简化了用户客户端的操作，劣势是用户客户端只能与Web Cache设备代理了证书的Web服务器建立HTTPS连接。
通过https certificate-mode命令可以切换Web Cache的HTTPS证书认证方式，切换到第三方证书认证方式后，需要通过https ssl certificate directory命令和https ssl certificate domain-name命令指定Web Cache设备需要代理的第三方证书，才能开启基于HTTPS的Web Cache功能。
只有在Web Cache功能处于关闭状态时，才可以修改本功能。
同时配置了https certificate-mode third-party和https ssl certificate directory命令时，如果需要修改https certificate-mode命令的配置，必须先执行undo https ssl certificate directory命令。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache的HTTPS证书认证方式。
https certificate-mode { built-in | third-party }
缺省情况下，Web Cache的HTTPS证书认证方式为内置证书认证方式。
(4) （可选）在第三方证书认证方式下，需要指定HTTPS证书相关文件所在目录。
https ssl certificate directory directory-name
缺省情况下，未配置HTTPS证书相关文件所在目录。
(5) （可选）在第三方证书认证方式下，需要配置Web Cache代理发布的HTTPS域名的证书文件及其对应的密钥文件。
https ssl certificate domain-name domain-name file certificate-file key-file certificate-keyfile
未配置相关证书文件和密钥文件。
开启Web Cache功能前必须配置允许缓存Web页面上的文件类型和Web Cache的工作路径。
在如下情况开启Web Cache功能时，会使已配置的Web Cache功能重启：
· 已配置基于HTTP的Web Cache功能，再开启基于HTTPS的Web Cache功能。
· 已配置基于HTTPS的Web Cache功能，再开启基于HTTP的Web Cache功能。
· 已配置基于HTTP和HTTPS的Web Cache功能，关闭其中的一项。
当用户使用HTTPS访问Web服务器，且通过开启了基于HTTPS的Web Cache功能的设备进行Web资源缓存时，会出现证书告警提示——因为WebCache设备和用户主机建立SSL连接使用的是本设备的数字证书，此证书为私有CA签发，无法通过用户主机HTTPS客户端的验证。此时，可以将Web Cache设备上Web Cache工作路径下名称为webcache_cacert.crt的CA根证书文件导出，并添加到用户主机的“受信任的证书颁发机构”中，用户主机会将Web Cache设备作为其数字证书的CA，以便通过数字证书的校验，避免出现证书告警提示。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 开启Web Cache功能。请至少选择其中一项进行配置。
¡ 开启基于HTTP的Web Cache功能。
http enable
缺省情况下，基于HTTP的Web Cache功能处于关闭状态。
¡ 开启基于HTTPS的Web Cache功能。
https enable
缺省情况下，基于HTTPS的Web Cache功能处于关闭状态。
缺省情况下，Web Cache设备收到来自用户客户端的首次HTTP/HTTPS请求后，会重新封装一个本地始发的HTTP/HTTPS请求发送给目标Web服务器。这一机制实际上将Web Cache设备当做了用户客户端的HTTP代理。如果存在Web Cache设备无法处理的报文，或者出现Web Cache设备与客户端或者Web服务器连接超时等情况，可能出现用户客户端直接请求可以成功，但是经过Web Cache设备代理后反而请求失败的情况。此时需要跳过Web Cache设备的代理，让用户客户端的HTTP/HTTPS请求原样到达目标Web服务器。
逃生功能处于开启状态时，Web Cache设备对于用户客户端对某个Web资源的首次HTTP/HTTPS请求会进行代理。如果能够顺利从目标Web服务器获得HTTP/HTTPS响应，则按照Web Cache正常流程缓存Web资源并代替Web服务器向客户端发送响应。如果Web Cache设备代理客户端向目标Web服务器请求失败，则将用户的请求记录到逃生表项中，后续用户的相同请求如果匹配了逃生表项，则Web Cache设备会直接透传该请求和对应响应的HTTP/HTTPS报文，不对HTTP/HTTPS报文进行重封装，以提高请求成功的机会。
逃生功能处于关闭状态时，任何来自用户客户端的HTTP/HTTPS请求都要经过Web Cache设备的代理。如果Web Cache设备向目标Web服务器请求失败，则用户客户端也请求失败。
逃生表项存在老化时间，如果逃生表项老化，则Web Cache将继续尝试代理该逃生表项对应的HTTP/HTTPS请求，如果代理失败，则生成新的逃生表项。
如果Web Cache设备代理失败的情况较少发生，可以关闭逃生功能以提高系统的隐私性和安全性。
如果Web Cache设备代理失败的情况经常发生，建议开启逃生功能以保障业务的基本运转。
如果Web Cache设备代理失败的情况较少发生，建议配置较小的逃生表项老化时间，反之则建议配置较大的逃生表项老化时间。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
(3) 开启Web Cache逃生功能。
escape enable
缺省情况下，Web Cache逃生功能处于开启状态。
(4) （可选）配置Web Cache逃生表项的老化时间。
escape aging-time aging-time
缺省情况下，Web Cache逃生表项的老化时间为1440分钟。
配置Web Cache的备用工作路径时，需要注意的是：
· Web Cache的缓存文件和工作数据通常会占用较大存储空间（GB级别），建议备用工作路径配置在存储空间较大的存储介质上。
· 指定的备用工作路径是否需要位于备用slot上与设备型号有关，请以设备的实际情况为准。
· 配置Web Cache的工作路径前，必须保证该目录下没有与工作路径最后一级名称相同且不带文件扩展名的文件存在。
(1) 进入系统视图。
system-view
(2) 创建并进入Web Cache视图。
web-cache slot slot-number
(3) 配置Web Cache的备用slot。
backup slot slot-number
缺省情况下，未配置Web Cache的备用slot。
(4) 配置Web Cache的备用工作路径。
file-directory backup directory
缺省情况下，未配置Web Cache备用工作路径。
创建Web Cache备用工作路径后，主用工作路径上的Web Cache缓存文件不会同步备份到备用工作路径上。
(5) 进入Web Cache缓存策略模板视图。
cache-profile profile-name
(6) 配置匹配到缓存策略模板的资源的备用工作路径。
file-directory backup directory
缺省情况下，未配置Web Cache备用工作路径。
在缺省情况下，当用户首次访问尚未被Web Cache缓存的URL资源时，Web Cache设备需要实时向目标Web服务器发起请求获取该资源，因此用户的首次访问仍会受到一定的延迟影响。
为进一步提升用户体验，可以在用户首次请求之前配置Web Cache设备的预缓存功能，主动将指定的URL资源提前下载并缓存在本地。这样，当用户首次访问这些预缓存的资源时，Web Cache设备能够直接从本地缓存中响应请求，大幅缩短响应时间，提高访问速度，显著优化首次访问体验。
设备获取预缓存资源URL的方式为：
(1) 在某个路径下的TXT文件中记录了Web资源的URL。
(2) 执行web-cache precache import url命令导入指定的TXT文件，并获得其中记录的URL。
web-cache precache start命令用来执行预缓存，每执行一次web-cache precache start命令，Web Cache设备就将所配置的预缓存URL全部触发一次下载，并将其中未被缓存过的资源缓存在本地。
在实际应用中，部分URL资源可能存在认证机制，需用户完成登录认证（即用户登录）后才能访问。执行web-cache precache命令时，如果指定了login参数，则Web Cache设备会首先访问web-cache precache login-url命令指定的登录认证URL，然后使用web-cache precache username命令配置的用户名和密码进行认证。认证成功后，设备会获取到Cookie等有效身份认证信息。随后，Web Cache会使用该认证信息访问并下载所有需预缓存的URL资源，确保这些资源能够在用户首次访问时直接被命中。
在预缓存执行过程中，可以随时通过执行web-cache precache stop命令来停止预缓存。
本功能的支持情况与设备型号有关，具体支持情况请参见对应的命令手册。
预缓存功能成功执行依赖如下前置条件：
· Web Cache功能处于开启状态。
· 在Web Cache设备上部署专用于预缓存功能的Docker容器：
a. 网络管理员将预缓存功能专用的镜像导入到Web Cache设备中。镜像文件请联系技术支持获取。
b. 执行docker load -i命令加载预缓存镜像，并完成Docker容器的部署。需要注意的是，部署Docker容器存在一些配置限制，详情请参见“容器管理与源地址配置”。
c. 通过tpa ip source或tpa ipv6 source命令为Docker容器配置源地址，用于与外界设备通信。具体配置步骤请参见“容器管理与源地址配置”。
预缓存资源所在的Web服务器如果需要通过HTTPS方式访问，则需要此服务器支持TLS1.2及以上的版本，否则无法成功完成预缓存。
预缓存成功与否与URL的可达性有关，部分URL的资源可能由于路由不通无法访问。
预缓存执行过程中，无法通过执行web-cache precache import url命令导入新的TXT文件。
在预缓存执行过程中，无法重复执行web-cache precache start命令，需要等待当前预缓存执行结束或执行web-cache precache stop命令强制停止预缓存。
(1) 进入系统视图。
system-view
(2) 从TXT文件中导入预缓存的URL。
web-cache precache import url url-string [ vpn-instance vpn-instance-name ]
(3) （可选）配置Web Cache进行登录认证时使用的用户名和密码。
web-cache precache username username password { simple | cipher } password
缺省情况下，未配置Web Cache进行登录认证时使用的用户名和密码。
如果预缓存的资源需要完成登录认证后才能访问，则必须执行本步骤。
(4) （可选）配置Web Cache进行登录认证的URL。
web-cache precache login-url url-string
缺省情况下，未配置Web Cache进行登录认证的URL。
(5) 开始执行或停止预缓存。
web-cache precache { start [ login ] [ time time date ] | stop }
当Web Cache设备上的本地缓存尚未过期，而Web服务器上的资源已经被更新时，客户端会从Web Cache设备获取到过时的资源。
为了解决这一问题，网络管理员可以：
· 手动执行clear web-cache cached-data命令，清除Web Cache设备上的本地缓存。这样，用户后续请求该资源时，Web Cache设备会从Web服务器重新获取最新的资源并返回给用户，确保用户访问到的是最新内容。
· 手动执行refresh web-cache cached-data命令，将Web Cache设备上的指定本地缓存标记为过期状态。这样，用户后续请求该资源时，Web Cache会主动向Web服务器验证资源是否有更新。若资源未更新，Web Cache继续使用本地缓存响应用户请求，从而节省回源带宽；若资源已更新，Web Cache则从源站获取最新内容进行响应，并同步更新本地缓存数据。
(1) 清除Web Cache的本地缓存数据。
clear web-cache cached-data { all | contents contents | domain-name domain-name | regular-expression regular-expression | url url-string }
(2) 刷新Web Cache的本地缓存数据。
refresh web-cache cached-data { all | contents contents | domain-name domain-name | regular-expression regular-expression | url url-string }
可在任意视图下执行以下命令：
· 显示Web Cache的统计信息。
display web-cache [ history ] [ last { day | 30-days | 365-days | hour | minute | week } | verbose ]
· 显示Web Cache当前已缓存的文件信息。
display web-cache cached-data [ domain-name domain-name ] [ top number | all ]
· 显示设备不缓存的Web服务器IP地址列表。
display web-cache deny-list { ipv4 | ipv6 } [ aged-ip ]
· 显示Web Cache的缓存路径信息。
display web-cache cache-path
· 显示Web Cache的缓存操作历史记录。
display web-cache cached-data clear-refresh history
· 显示Web Cache预缓存的状态信息。
display web-cache precache status
如图1-5所示，Server A、Service B和Service C为HTTP服务器，侦听HTTP报文的端口号分别为8001、8002、80。在Device上使用Web Cache功能，达到缓存页面、节省带宽、缓解服务器压力的目的。同时，通过配置Web Cache备份功能增强Web Cache功能的可靠性。
图1-5 配置基于HTTP的Web Cache组网图
请按照图1-5配置各接口的IP地址和子网掩码，并确保HTTP服务器的IPv4地址对于Device可达。
(1) 创建并进入Web Cache视图
<Device> system-view
[Device] web-cache slot 1
(2) 配置Web Cache参数。
# 配置Web Cache的工作路径为flash:/webcache。
[Device-web-cache-slot1] file-directory slot1#flash:/webcache
# 配置Service A侦听HTTP报文的端口号对应的Web Cache侦听端口号4001。
[Device-web-cache-slot1] listen-port 4001 server-port 8001
# 配置Service B侦听HTTP报文的端口号对应的Web Cache侦听端口号4002。
[Device-web-cache-slot1] listen-port 4002 server-port 8002
# 配置Service C侦听HTTP报文的端口号对应的Web Cache侦听端口号4003。
[Device-web-cache-slot1] listen-port 4003
# 配置Web Cache缓存文件大小的最大值为10G。
[Device-web-cache-slot1] cache-limit 10
# 配置允许缓存Web页面上文件类型为doc和docx的内容。
[Device-web-cache-slot1] cached-data doc docx
# 配置允许缓存Web页面上文件扩展名为cab的内容。
[Device-web-cache-slot1] cached-extension-name cab
# 配置Web Cache的备用slot。
[Device-web-cache-slot1] backup slot 2
# 配置Web Cache的备用工作路径。
[Device-web-cache-slot1] file-directory backup slot2#flash:/webcache2
(3) 开启基于HTTP的Web Cache功能。
[Device-web-cache-slot1] http enable
# 主机第一次向三台服务器发送HTTP请求时，在设备上查看Web Cache的概要信息。
[Device-web-cache-slot1] display web-cache
Capability information
Cache path: slot1#flash:/webcache/proxy
Max connections: 1022
Max cache size: 10GB
Current state information
Cache memory: 25.0MB
Cache count: 3
Statistics
ConnectTop: 4
CacheTop: 25.0MB
Bandwidth saved: 0
Cached data transmission speed: 3.3Mbps
Cached data transmitted: 25.0MB
Download speed: 3.3Mbps
Download size: 25.0MB
CacheHitRate: 0%
Hit count: 0 Miss count: 3
# 主机第二次向三台服务器发送相同HTTP请求时，在设备上查看Web Cache的概要信息。
[Device-web-cache-slot1] display web-cache
Capability information
Cache path: slot1#flash:/webcache/proxy
Max connections: 1022
Max cache size: 10GB
Current state information
Cache memory: 25.0MB
Cache count: 3
Statistics
ConnectTop: 3
CacheTop: 25.0MB
Bandwidth saved: 3.3Mbps
Cached data transmission speed: 3.3Mbps
Cached data transmitted: 25.0MB
Download speed: 0
Download size: 0
CacheHitRate: 100%
Hit count: 3 Miss count: 0
通过对比两次统计信息可知，第一次显示信息中统计最近一分钟内的Miss count计数为3，第二次显示信息中统计最近一分钟内的Hit count计数为3，说明第二次命中Web Cache缓存。Bandwidth saved是指设备节省的带宽，Download size是指服务器到设备的数据，第二次Download size没有增加，Bandwidth saved增加，说明服务器到设备没有流量经过，Web Cache功能生效。
# 当slot 1发生故障后，在设备上查看Web Cache的概要信息。
[Device-web-cache-slot1] display web-cache
Capability information
Cache path: slot2#flash:/webcache/proxy
Max connections: 1022
Max cache size: 10GB
Current state information
Cache memory: 25.0MB
Cache count: 3
Statistics
ConnectTop: 3
CacheTop: 25.0MB
Bandwidth saved: 3.3Mbps
Cached data transmission speed: 3.3Mbps
Cached data transmitted: 25.0MB
Download speed: 0
Download size: 0
CacheHitRate: 100%
Hit count: 3 Miss count: 0
Web Cache功能的工作路径Cache Path已经变更为Web Cache的备用工作路径。
如图1-6所示，Server A、Service B和Service C为HTTPS服务器，侦听HTTPS报文的端口号分别为8001、8002、443。在Device上使用Web Cache功能，达到缓存页面、节省带宽、缓解服务器压力的目的。同时，通过配置Web Cache备份功能增强Web Cache功能的可靠性。
图1-6 配置基于HTTPS的Web Cache组网图
请按照图1-6配置各接口的IP地址和子网掩码，并确保HTTPS服务器的IPv4地址对于Device可达。
(1) 创建并进入Web Cache视图
<Device> system-view
[Device] web-cache slot 1
(2) 配置Web Cache参数。
# 配置Web Cache的工作路径为flash:/webcache。
[Device-web-cache-slot1] file-directory slot1#flash:/webcache
# 配置Service A侦听HTTPS报文的端口号对应的Web Cache侦听端口号4001。
[Device-web-cache-slot1] https listen-port 4001 server-port 8001
# 配置Service B侦听HTTPS报文的端口号对应的Web Cache侦听端口号4002。
[Device-web-cache-slot1] https listen-port 4002 server-port 8002
# 配置Service C侦听HTTPS报文的端口号对应的Web Cache侦听端口号4003。
[Device-web-cache-slot1] https listen-port 4003
# 配置Web Cache缓存文件大小的最大值为10G。
[Device-web-cache-slot1] cache-limit 10
# 配置允许缓存Web页面上文件类型为doc和docx的内容。
[Device-web-cache-slot1] cached-data doc docx
# 配置允许缓存Web页面上文件扩展名为cab的内容。
[Device-web-cache-slot1] cached-extension-name cab
# 配置Web Cache的备用slot。
[Device-web-cache-slot1] backup slot 2
# 配置Web Cache的备用工作路径。
[Device-web-cache-slot1] file-directory backup slot2#flash:/webcache2
(3) 开启基于HTTPS的Web Cache功能。
[Device-web-cache-slot1] https enable
# 主机第一次向三台服务器发送HTTPS请求时，在设备上查看Web Cache的概要信息。
[Device-web-cache-slot1] display web-cache
Capability information
Cache path: slot1#flash:/webcache/proxy
Max connections: 1022
Max cache size: 10GB
Current state information
Cache memory: 25.0MB
Cache count: 3
Statistics
ConnectTop: 4
CacheTop: 25.0MB
Bandwidth saved: 0
Cached data transmission speed: 3.3Mbps
Cached data transmitted: 25.0MB
Download speed: 3.3Mbps
Download size: 25.0MB
CacheHitRate: 0%
Hit count: 0 Miss count: 3
# 主机第二次向三台服务器发送相同HTTPS请求时，在设备上查看Web Cache的概要信息。
[Device-web-cache-slot1] display web-cache
Capability information
Cache path: slot1#flash:/webcache/proxy
Max connections: 1022
Max cache size: 10GB
Current state information
Cache memory: 25.0MB
Cache count: 3
Statistics
ConnectTop: 3
CacheTop: 25.0MB
Bandwidth saved: 3.3Mbps
Cached data transmission speed: 3.3Mbps
Cached data transmitted: 25.0MB
Download speed: 0
Download size: 0
CacheHitRate: 100%
Hit count: 3 Miss count: 0
通过对比两次统计信息可知，第一次显示信息中统计最近一分钟内的Miss count计数为3，第二次显示信息中统计最近一分钟内的Hit count计数为3，说明第二次命中Web Cache缓存。Bandwidth saved是指设备节省的带宽，Download size是指服务器到设备的数据，第二次Download size没有增加，Bandwidth saved增加，说明服务器到设备没有流量经过，Web Cache功能生效。
Web Cache功能启动失败。
原因可能是配置侦听端口已被其他功能使用，不能重复侦听。
当配置的Web Cache的TCP侦听端口正在被其他应用侦听时，启动Web Cache会失败，通过display tcp verbose命令查看到当前正在被侦听的端口，配置未被侦听的端口为Web Cache的TCP侦听端口。
重启Web Cache主用slot后，Web Cache服务没有成功迁移到备份slot。
原因可能是备用工作路径中的存储介质配置错误或者不可访问。
通过dir命令查看配置的file-directory backup备份工作路径中的存储介质是否可以访问。有关dir的详细介绍，请参见“基础配置命令参考”中的“文件系统管理”。
本设备不支持容器化应用管理功能、容器和开放性应用公共配置功能，本节内容仅用于部署和配置预缓存功能专用Docker容器。
设备系统软件基于Linux内核，不同产品使用了不同的CPU体系结构。编译容器以及第三方应用可执行文件时使用的CPU体系结构必须与设备的CPU体系结构一致。
用户运行在设备上的第三方应用必须安全可信，不使用恶意软件，并保证及时更新开源应用的补丁。
禁止通过任何形式的第三方应用对设备及Comware进行逆向工程。
如果安装的第三方应用和Comware自带的应用冲突，设备会优先使用Comware应用。例如，用户开启了Comware中自带了FTP server应用，又在Docker容器中启用了FTP server应用，且这两个应用使用的IP地址和端口号也相同，FTP client通过FTP协议访问设备时，设备会使用Comware自带的FTP server响应请求。只有Comware自带的FTP server被关闭，才会使用Docker容器中FTP server应用来响应请求。
如果创建的第三方容器与Comware容器共享网络命名空间，则该第三方容器仅在Comware系统本次运行过程中可用。Comware系统重启后，如需继续使用该第三方容器，请重新创建。所以，建议以非共享Comware网络命名空间方式创建第三方容器。
为了防止第三方容器过度消耗资源，对Comware容器等设备主要组件造成不利影响，设备出厂时对每个第三方容器可使用的CPU、内存资源进行了限制。在使用docker run命令启动第三方容器时，如果通过--cpuset-cpus、--cpuset-shared、--memory参数指定第三方容器可使用的CPU、内存资源超出了设备出厂限制，则以设备出厂限制为准。
Comware系统集成了Docker并进行了改进，可解析Linux标准docker命令行。用户登录Comware系统后，通过CLI界面可以下发Linux系统的标准docker命令行，来创建、运行和监控容器，以及构建、存储镜像等。
如需创建一个与Comware共享网络命名空间的Docker容器，请使用参数--network container:comware，例如docker run --name tftpd --network container:comware vimagick/tftpd，用来创建并运行一个和Comware共享网络命名空间的TFTP server容器。
如需创建一个与Comware非共享网络命名空间的Docker容器，请使用参数--network tpa，例如docker run --name tftpd --network tpa vimagick/tftpd，用来创建并运行一个和Comware非共享网络命名空间的TFTP server容器。
执行docker load命令前，请使用display memory命令查看主用主控板上剩余内存的大小（即显示信息中Free字段的取值），剩余内存至少要大于镜像文件的大小，否则，在镜像文件加载过程中，可能会因为内存耗尽导致设备自动重启。
设备没有硬盘，所有的程序及文件均保存在内存中，所有容器产生的运行数据也保存在内存中，设备重启后数据会丢失，因此推荐使用无状态的容器。（有状态容器需要在容器内部存储数据,容器重启时需要读取这些数据来恢复到重启前的状态。无状态容器不需要在容器内部存储数据）
执行docker命令时，参数输入要求同Linux系统下的docker命令，可通过输入docker –-help来获取该参数的帮助信息。为方便用户使用docker命令，本手册描述了docker命令的一些常用参数，请参见“附录1 docker命令使用指导”。
修改Docker配置文件时，请确保配置文件没有错误并且经过验证，否则可能导致dockerd无法启动，从而导致Comware无法启动。如果遇到Comware无法启动的情况，请重启设备并进入BootWare，删除错误的Docker配置文件，然后尝试重启设备。如果依然无法启动，请重启设备进入BootWare，并删除flash:/third-party目录，然后尝试再次重启设备。
(1) 下载并导入镜像或者从镜像仓库拉取镜像。
(2) 进入系统视图。
system-view
(3) 部署Docker容器。
docker [ params ]
多次执行本命令，可以部署多个容器。
Guest Shell容器中的应用、RPM应用和Comware共享网络命名空间的Docker容器中的应用，需要和外界跨网段通信时，必须配置源地址，目的设备和源地址之间必须路由可达。配置源地址后，设备将使用指定接口的IP地址作为开放性应用发送的IP报文的源地址。
和Comware非共享网络命名空间的Docker容器中的开放性应用使用Virtual-Eth-Group接口和外界通信，不使用源地址，不需要配置源地址。
请确保指定的接口配置了IP地址，并且接口状态为Up，并且该接口和目的设备之间路由可达。否则，开放性应用不能和外界通信。
通过本功能指定开放性应用发送IPv6报文的源地址时，只能指定IPv6全球单播地址。
因为LoopBack口能够避免受到接口物理状态的影响，所以建议指定LoopBack口作为源接口提高通信的可靠性。
(1) 进入系统视图。
system-view
(2) 指定开放性应用发送IP报文的源地址。（IPv4网络）
tpa ip source interface interface-type interface-number
缺省情况下，开放性应用发送IP报文时的源地址为Loopback0接口的主IP地址。
(3) 指定开放性应用发送IPv6报文的源地址。（IPv6网络）
tpa ipv6 source { interface interface-type interface-number | ipv6 ipv6-address }
缺省情况下，开放性应用发送IPv6报文时的源地址为Loopback0接口的IPv6地址。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 指定开放性应用发送IP报文的源地址。（IPv4网络）
tpa ip source interface interface-type interface-number
缺省情况下，开放性应用发送IP报文时的源地址以系统视图配置的地址为准。
(4) 指定开放性应用发送IPv6报文的源地址。（IPv6网络）
tpa ipv6 source { interface interface-type interface-number | ipv6 ipv6-address }
缺省情况下，开放性应用发送IPv6报文时的源地址以系统视图配置的IPv6地址为准。
执行docker load命令前，请使用display memory命令查看主用主控板上剩余内存的大小（即显示信息中Free字段的取值），剩余内存至少要大于镜像文件的大小，否则，在镜像文件加载过程中，可能会因为内存耗尽导致设备自动重启。
(1) 从镜像库中导出镜像，具体导出方法请参考命令docker save --help及 docker export --help。
(2) 将导出的镜像包下载到设备的存储介质（如Flash）上。
(3) 对于通过docker save得到的镜像的tar文件，执行docker load导入镜像。
(4) 对于通过docker export得到的镜像的tar文件，执行docker import导入镜像。
命令更详细的使用方法请参考docker帮助，docker load --help、docker import --help。
# 导入cadvisor镜像cadvisor.img.tar.gz。
<Sysname> dir *.tar.gz
Directory of flash:
0 -rw- 694482 Jan 03 2019 18:55:02 busybox.tar.gz
1 -rw- 24297962 Jan 13 2019 02:35:51 cadvisor.img.tar.gz
3710740 KB total (1158972 KB free)
<Sysname> system-view
[Sysname] docker load -i cadvisor.img.tar.gz
52a5560f4ca0: Loading layer 5.06MB/5.06MB
f04a25da66bf: Loading layer 31.51MB/31.51MB
f60e27acaccf: Loading layer 26.49MB/26.49MB
Loaded image: google/cadvisor:latest
# 查看镜像。
<Sysname> system-view
[Sysname] docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry latest d1fd7d86a825 Less than a second ago 33.3MB
google/cadvisor latest 75f88e3ec333 Less than a second ago 62.2MB
busybox latest 54511612f1c4 Less than a second ago 1.13MB
bd84340b76a1 comware:MPU "/bin/v9.sh" 18 years ago Up 18 years comware
Docker daemon使用Comware的Loopback0接口访问网络，请确保Loopback0接口和Docker公有镜像库、私有镜像库之间路由可达。
在Docker公有镜像库注册后，即可使用docker pull xxx命令从Docker公有镜像库拉取镜像。
HTTP类型的私有镜像库属于非安全的私有镜像仓库，需要为docker daemon配置insecure-registries。
(1) 修改文件flash:/third-party/autocopy/etc/docker/daemon.json，配置参考如下：
<Sysname> more flash:/third-party/autocopy/etc/docker/daemon.json
{
"live-restore": true,
"insecure-registries":["192.168.111.62","test.io:5000"]
}
其中，192.168.111.62表示私有镜像仓库的IP地址并使用缺省端口号，test.io:5000表示另一个镜像仓库的域名地址和端口号。
(2) 重启设备或者执行docker-config reload使修改的配置生效。
访问HTTPS的私有镜像库根据镜像库服务器的配置可以分为无认证、简单认证和证书认证三种：
· 对于无认证的情况
直接执行docker pull、docker push即可拉取镜像或者上传镜像。
· 对于简单认证的情况
a. 执行docker login，输入认证参数
b. 执行docker pull、docker push等操作
· 对于证书认证的情况
具有证书方式认证的私有镜像库只能使用域名访问，不能直接使用IP地址访问。需要在设备上添加对应镜像服务器的证书，参考步骤如下：
c. 联系服务提供商或管理员获取服务器的证书。
d. 下载证书到设备。
证书的存放路径为flash:/third-party/autocopy/etc/docker/certs.d/服务器域名及端口/ca.crt，如flash:/third-party/autocopy/etc/docker/certs.d/img.example.com:5000/ca.crt。因为Flash文件系统不支持“:”，所以img.example.com:5000需要替换为img.example.com@5000，所以实际文件路径为flash:/third-party/autocopy/etc/docker/certs.d/img.example.com@5000/ca.crt。
e. 重启设备或者执行docker-config reload将新建的文件同步到系统中。
f. 执行docker login，输入认证参数。
g. 执行docker pull、docker push等操作。
# 从镜像服务器192.168.111.62:5000拉取busybox镜像。
<Sysname> system-view
[Sysname] docker pull 192.168.111.62:5000/busybox
Using default tag: latest
latest: Pulling from busybox
Digest: sha256:545e6a6310a27636260920bc07b994a299b6708a1b26910cfefd335fdfb60d2b
Status: Image is up to date for 192.168.111.62:5000/busybox:latest
最常见的运行容器方式是直接执行docker run，docker run会根据用户指定的参数创建并启动容器。参数的详细介绍请查看在线帮助docker run --help。
建议步骤如下：
(1) 进入系统视图。
system-view
(2) 执行docker images查看系统中有哪些镜像以及是否存在想要的镜像。
(3) 执行docker run运行容器。
(4) 执行docker ps查看容器运行情况。
# 运行一个TFTP server容器，该容器和Comware共享命令空间。
<Sysname> system-view
[Sysname] docker run --name tftpd --network container:comware tftpd
# 运行一个TFTP server容器，该容器和Comware非共享命令空间。
<Sysname> system-view
[Sysname] docker run --name tftpd --network tpa tftpd
# 运行一个TFTP server容器，该容器和Comware非共享命令空间，IP地址固定为1.1.1.1/24。
<Sysname> system-view
[Sysname] docker run --name tftpd --network tpa --ip 1.1.1.1 tftpd
# 运行一个TFTP server容器，该容器和Comware非共享命令空间，IP地址固定为1.1.1.1/24，并且设备启动时该容器也自动运行。
<Sysname> system-view
[Sysname] docker run --name tftpd --network tpa --ip 1.1.1.1 --restart=always tftpd
· 设置容器的CPU权重
如果设备上创建了多个容器，那么这些容器会共享设备的CPU资源。为了防止一个容器过多的占用CPU，而导致其他容器无法运行，需要限制容器对CPU的使用。
系统根据容器的CPU权重占所有容器CPU权重总和的比率来确定该容器的任务在一个CPU上占用时间的比率。比如当3个容器的CPU权重分别为10、10、5，则系统为第一个容器分配的CPU时间和为第二个容器分配的时间近似都是第三个容器的CPU时间的2倍，此时和配置权重值分别为2、2、1效果一致。
· 设置容器可使用的CPU列表
用户可以在创建容器或者运行容器时指定容器可以使用的CPU列表，同时用户可以在容器运行时更新容器可使用的CPU列表。容器可使用的CPU列表与设备的型号有关，请以设备的实际情况为准。
· 为容器分配内存空间
容器创建后，这些容器将共享设备的内存空间。为了防止一个容器过多的占用内存，而导致其他容器无法正常运行业务，需要限制容器对内存的使用。
缺省情况下，一个容器可使用的最大内存为256MB，用户可以指定的最大内存为2GB。
为容器分配的内存空间至少需要保证该容器的正常启动并运行。建议等待容器启动完毕后，使用docker stats --no-stream查看容器的资源占用情况，并根据实际情况作出相应调整。
可以在创建容器或者运行容器时为容器分配CPU资源及内存资源，也可以在容器运行过程中更新容器占用的CPU及内存。
请参考docker create --help、docker run --help、docker update --help
# 运行容器ubntu，限制它最多可占用20%的CPU资源。
<Sysname> system-view
[Sysname] docker run -it --cpu-period=100000 --cpu-quota=20000 ubntu /bin/bash
当容器运行在后台时，可以通过docker attach连接到容器。
(1) 进入系统视图。
system-view
(2) 连接到容器。
docker attach 容器名或者容器ID
可使用docker attach --help查看帮助及具体使用方法。
可以通过快捷键<Ctrl+P+Q>离开容器，返回到Comware的命令行编辑界面。
(1) 进入系统视图。
system-view
(2) 查看正在运行的容器。
docker ps
(3) 查看所有容器，包括已停止的容器。
docker ps -a
可使用docker ps --help查看帮助及具体使用方法。
执行save命令时如果选择保存Docker文件，系统会将整个docker数据文件夹打成一个压缩包保存在Flash上的flash:/third-party/container_storage/目录下，系统重启后会将使用该文件恢复容器。
可在任意视图下执行save命令保存容器，被保存的容器将在下次启动时自动恢复到系统中。关于save命令的详细介绍请参见“基础配置命令参考”中的“配置文件管理”。
<Sysname> save
The current configuration will be written to the device. Are you sure? [Y/N]:y
Please input the file name(*.cfg)[flash:/startup.cfg]
(To leave the existing filename unchanged, press the enter key):
flash:/startup.cfg exists, overwrite? [Y/N]:y
Validating file. Please wait...
Saving docker files need some time. Do you want to save docker files in this process? [Y/N]:y
Saving docker files
.....
Done.
Saved the current configuration to mainboard device successfully.
<Sysname>
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
