Independent Submission C. Chung
Request for Comments: 6108 A. Kasyanov
Category: Informational J. Livingood
ISSN: 2070-1721 N. Mody
Comcast
B. Van Lieu
Unaffiliated
February 2011
Independent Submission C. Chung
Request for Comments: 6108 A. Kasyanov
Category: Informational J. Livingood
ISSN: 2070-1721 N. Mody
Comcast
B. Van Lieu
Unaffiliated
February 2011
Comcast's Web Notification System Design
康卡斯特的网络通知系统设计
Abstract
摘要
The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications.
本文档的目的是描述一种向web浏览器提供关键最终用户通知的方法，该方法已由互联网服务提供商（ISP）Comcast部署。这种通知系统被用来向客户提供近乎即时的通知，例如警告他们，他们的流量显示出表明恶意软件或病毒感染的模式。还有其他专有系统可以执行此类通知，但这些系统利用深度数据包检查（DPI）技术。与DPI不同，本文档描述的系统不依赖DPI，而是基于开放IETF标准和开源应用程序。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6108.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6108.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. High-Level Design of the System .................................3
3. Design Requirements .............................................3
3.1. General Requirements .......................................4
3.2. Web Proxy Requirements .....................................6
3.3. ICAP Server Requirements ...................................7
3.4. Messaging Service Requirements .............................8
4. Implementation Details ..........................................8
4.1. Functional Components Described, as Implemented ............9
4.2. Functional Diagram, as Implemented ........................10
5. High-Level Communication Flow, as Implemented ..................11
6. Communication between Web Proxy and ICAP Server, as
Implemented ....................................................12
7. End-to-End Web Notification Flow, as Implemented ...............13
7.1. Step-by-Step Description of the End-to-End Web
Notification Flow .........................................14
7.2. Diagram of the End-to-End Web Notification Flow ...........15
8. Example HTTP Headers and JavaScript for a Web Notification .....16
9. Deployment Considerations ......................................18
10. Security Considerations .......................................19
11. Debating the Necessity of Such a Critical Notification
System ........................................................19
12. Suggesting a Walled Garden as an Alternative ..................20
13. Intended Next Steps ...........................................21
14. Acknowledgements ..............................................21
15. References ....................................................21
15.1. Normative References .....................................21
15.2. Informative References ...................................23
1. Introduction ....................................................3
2. High-Level Design of the System .................................3
3. Design Requirements .............................................3
3.1. General Requirements .......................................4
3.2. Web Proxy Requirements .....................................6
3.3. ICAP Server Requirements ...................................7
3.4. Messaging Service Requirements .............................8
4. Implementation Details ..........................................8
4.1. Functional Components Described, as Implemented ............9
4.2. Functional Diagram, as Implemented ........................10
5. High-Level Communication Flow, as Implemented ..................11
6. Communication between Web Proxy and ICAP Server, as
Implemented ....................................................12
7. End-to-End Web Notification Flow, as Implemented ...............13
7.1. Step-by-Step Description of the End-to-End Web
Notification Flow .........................................14
7.2. Diagram of the End-to-End Web Notification Flow ...........15
8. Example HTTP Headers and JavaScript for a Web Notification .....16
9. Deployment Considerations ......................................18
10. Security Considerations .......................................19
11. Debating the Necessity of Such a Critical Notification
System ........................................................19
12. Suggesting a Walled Garden as an Alternative ..................20
13. Intended Next Steps ...........................................21
14. Acknowledgements ..............................................21
15. References ....................................................21
15.1. Normative References .....................................21
15.2. Informative References ...................................23
Internet Service Providers (ISPs) have a need for a system that is capable of communicating with customers in a nearly immediate manner, to convey critical service notices such as warnings concerning likely malware infection. Given the prevalence of the web browser as the predominant client software in use by Internet users, the web browser is an ideal vehicle for providing these notifications. This document describes a system that has been deployed by Comcast, a broadband ISP, to provide near-immediate notifications to web browsers.
互联网服务提供商（ISP）需要一个能够以近乎即时的方式与客户通信的系统，以传达关键的服务通知，例如关于可能的恶意软件感染的警告。鉴于网络浏览器作为互联网用户使用的主要客户端软件的普及，网络浏览器是提供这些通知的理想工具。本文档描述了一个由宽带ISP Comcast部署的系统，该系统可向web浏览器提供近乎即时的通知。
In the course of evaluating potential solutions, the authors discovered that the large majority of commercially available systems utilized Deep Packet Inspection (DPI) technology. While a DPI-based system would certainly work, Comcast and other ISPs are trying to avoid widespread deployment and use of DPI, and are searching for alternatives. Thus, Comcast desired to use a system that is based on open standards and non-proprietary software, and that did not require the use of DPI. While the system described herein is specific to the Data-Over-Cable Service Interface Specifications (DOCSIS, [CableLabs_DOCSIS]) networks used by most cable-based broadband ISPs, concepts described in this document can generally be applied to many different types of networks should those ISPs be interested in alternatives to DPI.
在评估潜在解决方案的过程中，作者发现绝大多数商用系统都使用了深度数据包检测（DPI）技术。虽然基于DPI的系统肯定会起作用，但康卡斯特和其他ISP正试图避免广泛部署和使用DPI，并正在寻找替代方案。因此，康卡斯特希望使用基于开放标准和非专有软件的系统，并且不需要使用DPI。虽然本文描述的系统特定于大多数基于电缆的宽带ISP使用的有线数据服务接口规范（DOCSI，[CableLabs_DOCSI]）网络，但如果这些ISP对DPI的替代方案感兴趣，则本文中描述的概念通常可应用于许多不同类型的网络。
The web notification system design is based on the use of the Internet Content Adaptation Protocol (ICAP) [RFC3507]. The design uses open source applications, which are the Squid web proxy, GreasySpoon ICAP server, and Apache Tomcat. ICAP, an existing IETF protocol, allows for message transformation or adaptation. An ICAP client passes a HyperText Transport Protocol (HTTP, [RFC2616]) response to an ICAP server for content adaption. The ICAP server in turn responds back to the client with the HTTP response containing the notification message by using the "respmod" method defined in Section 3.2 of [RFC3507].
web通知系统的设计基于互联网内容适配协议（ICAP）[RFC3507]的使用。该设计使用开源应用程序，包括Squid web代理、GreasySpoon ICAP服务器和ApacheTomcat。ICAP是一种现有的IETF协议，允许进行消息转换或自适应。ICAP客户端将超文本传输协议（HTTP，[RFC2616]）响应传递给ICAP服务器以进行内容自适应。ICAP服务器反过来通过使用[RFC3507]第3.2节中定义的“respmod”方法，使用包含通知消息的HTTP响应向客户端作出响应。
This section describes all of the key requirements taken into consideration by Comcast for the design of this system. This information is provided in order to convey important design choices that were made in order to avoid the use of DPI, among other things. An "Additional Background" paragraph is included with each requirement to provide additional information, context, or other useful explanation.
本节描述康卡斯特在设计该系统时考虑的所有关键要求。提供这些信息是为了传达重要的设计选择，这些选择是为了避免使用DPI等。每项要求都包含一个“附加背景”段落，以提供附加信息、上下文或其他有用的解释。
R3.1.1. Must Only Be Used for Critical Service Notifications Additional Background: The system must only provide critical notifications, rather than trivial notifications. An example of a critical, non-trivial notification, which is also the primary motivation of this system, is to advise the user that their computer is infected with malware, that their security is at severe risk and/or has already been compromised, and that it is recommended that they take immediate, corrective action NOW.
R3.1.1。只能用于关键服务通知其他后台：系统必须只提供关键通知，而不是普通通知。一个重要的、非琐碎的通知示例（也是此系统的主要动机）是通知用户其计算机已感染恶意软件，其安全性处于严重风险和/或已受到危害，建议用户立即采取纠正措施。
R3.1.2. Must Use TCP Port 80 Additional Background: The system must provide notifications via TCP port 80, the well-known port for HTTP traffic. Since the large majority of customers use a web browser as their primary application, this was deemed the best method to provide them with an immediate, critical notification.
R3.1.2。必须使用TCP端口80附加后台：系统必须通过TCP端口80（HTTP流量的著名端口）提供通知。由于大多数客户使用web浏览器作为其主要应用程序，因此这被认为是向他们提供即时关键通知的最佳方法。
R3.1.3. Must Support Block Listing Additional Background: While unlikely, it is possible that the HyperText Markup Language (HTML, [RFC2854]) or JavaScript [RFC4329] used for notifications may cause problems while accessing a particular website. Therefore, such a system must be capable of using a block list of website Uniform Resource Identifiers (URIs, [RFC3986]) or Fully Qualified Domain Names (FQDNs, Section 5.1 of [RFC1035]) that conflict with the system, so that the system does not provide notifications in these cases, in order to minimize any errors or unexpected results. Also, while extensive development and testing has been performed to ensure that this system does not behave in unexpected ways, and standard ICAP (which has been in use for many years) is utilized, it is critical that if it does behave in such a way, there must be a method to rapidly exempt specific URIs or FQDNs.
R3.1.3。必须支持块列表附加背景：虽然不太可能，但用于通知的超文本标记语言（HTML[RFC2854]）或JavaScript[RFC4329]在访问特定网站时可能会导致问题。因此，此类系统必须能够使用与系统冲突的网站统一资源标识符（URI，[RFC3986]）或完全限定域名（FQDNs，[RFC1035]第5.1节）的阻止列表，以便系统在这些情况下不提供通知，以将任何错误或意外结果降至最低。此外，虽然已经进行了广泛的开发和测试，以确保该系统不会以意外的方式运行，并且使用了标准ICAP（已使用多年），但如果它确实以这种方式运行，则必须有一种方法快速豁免特定URI或FQDN，这一点至关重要。
R3.1.4. Must Not Cause Problems with Instant Messaging (IM) Clients Using TCP Port 80 Additional Background: Some IM clients use TCP port 80 in their communications, often as an alternate port when standard, well-known ports do not work. Other IM clients may in fact use TCP port 80 by default, in some cases even being based in a web browser. Therefore, this system must not conflict with or cause unexpected results for IM clients (or any other client types) that use TCP port 80.
R3.1.4。不得导致使用TCP端口80的即时消息（IM）客户端出现问题其他背景：一些IM客户端在通信中使用TCP端口80，通常在标准、已知端口不工作时作为备用端口。其他IM客户端实际上可能默认使用TCP端口80，在某些情况下甚至基于web浏览器。因此，此系统不得与使用TCP端口80的IM客户端（或任何其他客户端类型）冲突或导致意外结果。
R3.1.5. Must Handle Pre-Existing Active TCP Sessions Gracefully Additional Background: Since the web notification system may temporarily re-route TCP port 80 traffic in order to provide a critical notification, previously established TCP port 80 sessions must not be disrupted while being routed to the proxy layer. Also, since the critical web notification occurs at a well-defined point in time, it is logical to conclude that an end user may well have an active TCP port 80 session in progress before the notification is sent, and which is still active at the time of the notification. It is therefore important that any such connections must not be reset, and that they instead must be handled gracefully.
R3.1.5。必须优雅地处理预先存在的活动TCP会话其他背景：由于web通知系统可能临时重新路由TCP端口80流量以提供关键通知，因此在路由到代理层时，先前建立的TCP端口80会话不得中断。此外，由于关键web通知发生在定义明确的时间点，因此可以得出这样的结论：最终用户可能在发送通知之前有一个活动的TCP端口80会话正在进行中，并且在发出通知时该会话仍处于活动状态。因此，重要的是，任何此类连接都不得重置，而必须优雅地处理它们。
R3.1.6. Must Not Use TCP Resets Additional Background: The use of TCP resets has been widely criticized, both in the Internet community generally and in [RFC3360]. In Comcast's recent history, for example, the company was criticized for using TCP resets in the course of operating a DPI-based network management system. As such, TCP resets as a function of the system must not be used.
R3.1.6。不得使用TCP重置其他背景：TCP重置的使用受到了广泛的批评，无论是在互联网社区还是在[RFC3360]中。例如，在康卡斯特最近的历史中，该公司因在运行基于DPI的网络管理系统的过程中使用TCP重置而受到批评。因此，不得使用TCP重置作为系统的功能。
R3.1.7. Must Be Non-Disruptive Additional Background: The web notification system must not disrupt the end-user experience, for example by causing significant client errors.
R3.1.7。必须是无中断的附加后台：web通知系统不得中断最终用户体验，例如导致重大客户端错误。
R3.1.8. User Notification Acknowledgement Must Stop Further Immediate Notifications Additional Background: Once a user acknowledges a critical notification, the notification should immediately stop. Otherwise, the user may believe the system is stuck in an error state and may not believe that the critical notification is valid. In addition, it is quite possible that the user will be annoyed that the system did not react to his acknowledgement.
R3.1.8。用户通知确认必须停止进一步的即时通知其他背景：一旦用户确认关键通知，通知应立即停止。否则，用户可能认为系统处于错误状态，并且可能不认为关键通知有效。此外，用户很可能会因为系统没有对他的确认做出反应而感到恼火。
R3.1.9. Non-Modification of Content Should Be Maintained Additional Background: The system should not significantly alter the content of the HTTP response from any website the user is accessing.
R3.1.9。不修改内容应保留在其他后台：系统不应显著改变用户正在访问的任何网站的HTTP响应内容。
R3.1.10. Must Handle Unexpected Content Gracefully Additional Background: Sometimes, developers and/or implementers of software systems assume that a narrow range of inputs to a system will occur, all of which have been thought of beforehand by the designers. The authors
R3.1.10。必须优雅地处理意外内容附加背景：有时，软件系统的开发人员和/或实现人员会假设系统的输入范围很窄，所有这些都是设计者事先想到的。作者
believe this is a poor assumption to make in the design and implementation of a system and, in contrast, that unexpected or even malformed inputs should be assumed. As a result, the system must gracefully and transparently handle traffic that is unexpected, even though there will be cases when the system cannot provide a critical web notification as a result of this. Thus, widely varying content should be expected, and all such unexpected traffic must be handled by the system without generating user-perceived errors or unexpected results.
我们认为，在系统的设计和实现中，这是一个糟糕的假设，相反，应该假设意外甚至错误的输入。因此，系统必须优雅、透明地处理意外的流量，即使在某些情况下系统无法提供关键的web通知。因此，应该期望各种各样的内容，并且系统必须在不产生用户感知错误或意外结果的情况下处理所有此类意外流量。
R3.1.11. Web Content Must Not Be Cached Additional Background: Maintaining the privacy of users is important. As such, content flowing through or incidentally observed by the system must not be cached.
R3.1.11。不得将Web内容缓存到其他后台：维护用户的隐私非常重要。因此，不得缓存流经系统或由系统偶然观察到的内容。
R3.1.12. Advertising Replacement or Insertion Must Not Be Performed Under ANY Circumstances Additional Background: The system must not be used to replace any advertising provided by a website, or to insert advertising into websites. This therefore includes cases where a web page already has space for advertising, as well as cases where a web page does not have any advertising. This is a critical area of concern for end users, privacy advocates, and other members of the Internet community. Therefore, it must be made abundantly clear that this system will not be used for such purposes.
R3.1.12。在任何情况下不得进行广告替换或插入其他背景：系统不得用于替换网站提供的任何广告，或将广告插入网站。因此，这包括网页已经有广告空间的情况，以及网页没有任何广告的情况。这是最终用户、隐私倡导者和互联网社区其他成员关注的关键领域。因此，必须非常清楚地表明，该系统不会用于此类目的。
R3.2.1. Open Source Software Must Be Used Additional Background: The system must use an open source web proxy server. (As noted in Section 2 and Section 4.1, Squid has been chosen.) While it is possible to use any web proxy, the use of open source enables others to easily access openly available documentation for the software, among the other benefits commonly attributed to the use of open source software.
R3.2.1。开源软件必须使用其他后台：系统必须使用开源web代理服务器。（如第2节和第4.1节所述，选择了Squid。）虽然可以使用任何web代理，但使用开源使其他人能够轻松访问该软件的公开可用文档，以及通常归因于使用开源软件的其他好处。
R3.2.2. ICAP Client Should Be Integrated Additional Background: The web proxy server should have an integrated ICAP client, which simplifies the design and implementation of the system.
R3.2.2。ICAP客户端应集成其他背景：web代理服务器应具有集成的ICAP客户端，从而简化系统的设计和实现。
R3.2.3. Access Control Must Be Implemented Additional Background: Access to the proxy must be limited exclusively to the IP addresses of users for which notifications are intended, and only for limited periods of time. Furthermore, since a Session Management Broker (SMB) is utilized, as described in Section 4.1 below, then the proxy must restrict access only to the address of the SMB.
R3.2.3。访问控制必须在其他后台实现：对代理的访问必须仅限于发送通知的用户的IP地址，并且仅限于有限的时间段。此外，由于使用了会话管理代理（SMB），如下文第4.1节所述，因此代理必须仅限制对SMB地址的访问。
R3.3.1. Must Provide ICAP Response Support Additional Background: The system must support response adaptation, in accordance with [RFC3507]. An ICAP client passes a HyperText Transport Protocol (HTTP, [RFC2616]) response to an ICAP server for content adaption. The ICAP server in turn responds back to the client with the HTTP response containing the notification message by using the "respmod" method defined in Section 3.2 of [RFC3507].
R3.3.1。必须提供ICAP响应支持其他背景：根据[RFC3507]，系统必须支持响应自适应。ICAP客户端将超文本传输协议（HTTP，[RFC2616]）响应传递给ICAP服务器以进行内容自适应。ICAP服务器反过来通过使用[RFC3507]第3.2节中定义的“respmod”方法，使用包含通知消息的HTTP响应向客户端作出响应。
R3.3.2. Must Provide Consistency of Critical Notifications Additional Background: The system must be able to consistently provide a specific notification. For example, if a critical alert to notify a user that they are infected with malware is desired, then that notification should consistently look the same for all users and not vary.
R3.3.2。必须提供关键通知的一致性其他背景：系统必须能够一致地提供特定通知。例如，如果需要一个关键警报来通知用户他们感染了恶意软件，那么该通知对于所有用户都应该保持一致，而不是变化。
R3.3.3. Must Support Multiple Notification Types Additional Background: While the initial and sole critical notification sent by the system is intended to alert users of a malware infection, malware is a rapidly and continuously evolving threat. As a result of this reality, the system must be able to evolve to provide different types of critical notifications. For example, if malware begins to diverge into several different categories with substantially different implications for end users, then it may become desirable to provide a notification that has been narrowly tailored to each category of malware.
R3.3.3。必须支持多种通知类型其他背景：虽然系统发送的初始和唯一关键通知旨在提醒用户恶意软件感染，但恶意软件是一种快速且不断演变的威胁。由于这一现实，系统必须能够发展，以提供不同类型的关键通知。例如，如果恶意软件开始分化为几个不同的类别，对最终用户的影响大不相同，那么可能需要提供一个针对每个类别恶意软件的狭义定制的通知。
R3.3.4. Must Support Notification to Multiple Users Simultaneously Additional Background: The system must be able to simultaneously serve notifications to different users. For example, if 100 users have been infected with malware and critically need to be notified about this security problem, then the system must be capable of providing the notification to several users at a time, or all of the users at the same time, rather than to just one user at a time.
R3.3.4。必须支持同时向多个用户发送通知附加后台：系统必须能够同时向不同用户发送通知。例如，如果有100个用户感染了恶意软件，并且迫切需要得到有关此安全问题的通知，那么系统必须能够一次向多个用户或同时向所有用户提供通知，而不是一次只向一个用户提供通知。
R3.4.1. A Messaging Service Must Be Used Additional Background: The Messaging Service, as described in Section 4.1 below, caches the notifications for each specific user. Thus, the notification messages are cached by the system and do not have to be retrieved each time a notification is needed. As a result, the system can be more easily scaled to provide notification to multiple users simultaneously, as noted in an earlier requirement ("Must Support Notification to Multiple Users Simultaneously").
R3.4.1。消息服务必须用于其他后台：如下面第4.1节所述，消息服务缓存每个特定用户的通知。因此，通知消息由系统缓存，不必在每次需要通知时检索。因此，系统可以更容易地扩展，以便同时向多个用户提供通知，如前面的要求所述（“必须支持同时向多个用户发出通知”）。
R3.4.2. Must Process Acknowledgements on a Timely Basis Additional Background: The Messaging Service must quickly process notification acknowledgements by end users, as noted in an earlier requirement ("User Notification Acknowledgement Must Stop Further Immediate Notifications").
R3.4.2。必须及时处理确认其他背景：消息传递服务必须快速处理最终用户的通知确认，如前面的要求所述（“用户通知确认必须停止进一步的即时通知”）。
R3.4.3. Must Ensure Notification Targeting Accuracy Additional Background: The Messaging Service must ensure that notifications are presented to the intended users. For example, if the system intends to provide a critical notification to User A and User B, but not User C, then User C must not be sent a notification.
R3.4.3。必须确保通知目标的准确性其他背景：消息传递服务必须确保通知呈现给预期用户。例如，如果系统打算向用户a和用户B（而不是用户C）提供关键通知，则不得向用户C发送通知。
R3.4.4. Should Keep Notification Records for Customer Support Purposes Additional Background: The Messaging Service should maintain some type of record that a notification has been sent to a user, in case that user inquires with customer support personnel. For example, when a user is presented with the critical notification advising them of a malware infection, that user may choose to call Comcast's Customer Security Assurance team, in the customer service organization. As a result, a Customer Security Assurance representative should be able to confirm that the user did in fact receive a notification concerning malware infection in the course of providing assistance to the end user in remediating the malware infection.
R3.4.4。应保留通知记录以供客户支持之用其他背景：消息传递服务应保留已向用户发送通知的某种类型的记录，以防用户向客户支持人员查询。例如，当向用户提供恶意软件感染的关键通知时，该用户可以选择致电客户服务组织中的康卡斯特客户安全保障团队。因此，客户安全保证代表应能够确认，在向最终用户提供帮助以补救恶意软件感染的过程中，用户确实收到了关于恶意软件感染的通知。
This section defines and documents the various core functional components of the system, as they are implemented. These components are then shown in a diagram to describe how the various components are linked and relate to one another.
本节定义并记录了系统的各种核心功能组件的实现。然后，这些组件将显示在一个图表中，以描述各种组件如何相互链接和关联。
This section accurately and transparently describes the software (S) packages used by the system described herein, as well as all of the details of how the system functions. The authors acknowledge that there may be multiple alternative software choices for each component; the purpose of this section is to describe those selections that have been made and deployed.
本节准确、透明地描述了本文所述系统使用的软件包，以及系统如何工作的所有细节。作者承认，每个组件可能有多个备选软件选择；本节的目的是描述已做出和部署的选择。
S4.1.1. Web Proxy: The system uses Squid Proxy, an open source web proxy application in wide use, which supports an integrated ICAP client.
S4.1.1。Web代理：系统使用Squid代理，这是一种广泛使用的开源Web代理应用程序，支持集成ICAP客户端。
S4.1.2. ICAP Server: The system uses GreasySpoon, an open source application. The ICAP server retrieves the notifications from the Messaging Service cache when content adaption is needed.
S4.1.2。ICAP服务器：系统使用GreasySpoon，一个开源应用程序。当需要内容自适应时，ICAP服务器从消息服务缓存检索通知。
S4.1.3. Customer Database: The Customer Database holds the relevant information that the system needs to provide a critical notification to a given user. The database may also hold the status of which users were notified and which users are pending notification.
S4.1.3。客户数据库：客户数据库保存系统向给定用户提供关键通知所需的相关信息。数据库还可以保存哪些用户已收到通知以及哪些用户正在等待通知的状态。
S4.1.4. Messaging Service: The system uses Apache Tomcat, an open source application. This is a process engine that retrieves specific web notification messages from a catalog of possible notifications. While only one notification is currently used, concerning malware infection, as noted in Section 3.3 the system may eventually need to provide multiple notifications (the specific requirement is "Must Support Multiple Notification Types"). When a notification for a specific user is not in the cache, the process retrieves this information from the Customer Database and populates the cache for a specific period of time.
S4.1.4。消息服务：系统使用ApacheTomcat，一个开源应用程序。这是一个流程引擎，它从可能的通知目录中检索特定的web通知消息。虽然目前仅使用一个通知，但如第3.3节所述，关于恶意软件感染，系统最终可能需要提供多个通知（具体要求是“必须支持多种通知类型”）。当特定用户的通知不在缓存中时，该进程将从客户数据库检索此信息，并在特定时间段内填充缓存。
S4.1.5. Session Management Broker (SMB): A Load Balancer (LB) with a customized layer 7 inspection policy is used to differentiate between HTTP and non-HTTP traffic on TCP port 80, in order to meet the requirements documented in Section 3 above. The system uses a LB from A10 Networks. The SMB functions as a full stateful TCP proxy with the ability to forward packets from existing TCP sessions that do not exist in the internal session table (to meet the specific requirement "Must Handle Pre-Existing Active TCP Sessions Gracefully"). New HTTP sessions are load balanced to the web proxy layer either transparently or using source Network Address Translation (NAT [RFC3022]) from the SMB.
S4.1.5。会话管理代理（SMB）：具有自定义第7层检查策略的负载平衡器（LB）用于区分TCP端口80上的HTTP和非HTTP流量，以满足上面第3节中记录的要求。该系统使用来自A10网络的LB。SMB作为全状态TCP代理运行，能够转发来自内部会话表中不存在的现有TCP会话的数据包（为了满足特定要求，“必须优雅地处理预先存在的活动TCP会话”）。新HTTP会话以透明方式或使用来自SMB的源网络地址转换（NAT[RFC3022]）对web代理层进行负载平衡。
Non-HTTP traffic for established TCP sessions not in the SMB session table is simply forwarded to the destination transparently via the TCP proxy layer (again, to meet the specific requirement "Must Handle Pre-Existing Active TCP Sessions Gracefully").
不在SMB会话表中的已建立TCP会话的非HTTP通信仅通过TCP代理层透明地转发到目标（同样，为了满足特定要求，“必须优雅地处理预先存在的活动TCP会话”）。
+--------+ +------------+ +----------+
| ICAP | <----> | Messaging | <----> | Customer |
| Server | | Service | | Database |
+--------+ +------------+ +----------+
^
| +----------+
| | |
| +-------> | Internet | <-------+
| | | | |
| | +----------+ |
| | ^ |
v v | |
+----------+ v v
|+--------+| +-------+ +--------+
|| ICAP || <----> | SMB | <---> | Access |
|| Client || +-------+ | Router |
|+--------+| +--------+
|| SQUID || ^
|| Proxy || |
|+--------+| v
+----------+ +----------+
| CMTS* |
+----------+
^
|
v
+------+
| PC |
+------+
+--------+ +------------+ +----------+
| ICAP | <----> | Messaging | <----> | Customer |
| Server | | Service | | Database |
+--------+ +------------+ +----------+
^
| +----------+
| | |
| +-------> | Internet | <-------+
| | | | |
| | +----------+ |
| | ^ |
v v | |
+----------+ v v
|+--------+| +-------+ +--------+
|| ICAP || <----> | SMB | <---> | Access |
|| Client || +-------+ | Router |
|+--------+| +--------+
|| SQUID || ^
|| Proxy || |
|+--------+| v
+----------+ +----------+
| CMTS* |
+----------+
^
|
v
+------+
| PC |
+------+
* A Cable Modem Termination System (CMTS) is an access network element.
* 电缆调制解调器终端系统（CMTS）是一种接入网络元件。
Figure 1: Web Notification System - Functional Components
图1：Web通知系统-功能组件
In Section 4, the functional components of the system were described, and then shown in relation to one another in Figure 1 above. This section describes the high-level communication (C) flow of a transaction in the system, in order to explain the general way that the functions work together in action. This will be further explained in much more detail in later sections of this document.
在第4节中，描述了系统的功能组件，然后在上图1中相互关联地显示。本节描述系统中事务的高级通信（C）流程，以解释功能在操作中协同工作的一般方式。这将在本文件后面的章节中进一步详细解释。
C5.1. Setup of Differentiated Services (Diffserv): Using Diffserv [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] [RFC4594], set a policy to direct TCP port 80 traffic to the web notification system's web proxy.
C5.1。区分服务（Diffserv）设置：使用Diffserv[RFC2474][RFC2475][RFC2597][RFC3140][RFC3246][RFC3260][RFC4594]设置策略，将TCP端口80流量定向到web通知系统的web代理。
C5.2. Session Management: TCP port 80 packets are routed to a Session Management Broker (SMB) that distinguishes between HTTP or non-HTTP traffic and between new and existing sessions. HTTP packets are forwarded to the web proxy by the SMB. Non-HTTP packets such as instant messaging (IM) traffic are forwarded to a TCP proxy layer for routing to their destination, or the SMB operates as a full TCP proxy and forwards the non-HTTP packets to the destination. Pre-established TCP sessions on port 80 are identified by the SMB and forwarded with no impact.
C5.2。会话管理：TCP端口80数据包被路由到会话管理代理（SMB），该代理区分HTTP或非HTTP流量以及新会话和现有会话。HTTP数据包由SMB转发到web代理。诸如即时消息（IM）通信的非HTTP数据包被转发到TCP代理层以路由到其目的地，或者SMB作为完整的TCP代理运行并将非HTTP数据包转发到目的地。端口80上预先建立的TCP会话由SMB识别并转发，不会产生任何影响。
C5.3. Web Proxy Forwards Request: The web proxy forwards the HTTP request on to the destination site, a web server, as a web proxy normally would do.
C5.3。Web代理转发请求：Web代理将HTTP请求转发到目标站点（Web服务器），这与Web代理通常所做的一样。
C5.4. On Response, Send Message to ICAP Server: When the HTTP response is received from the destination server, the web proxy sends a message to the ICAP server for the web notification.
C5.4。响应时，将消息发送到ICAP服务器：当从目标服务器接收到HTTP响应时，web代理将向ICAP服务器发送一条消息以获取web通知。
C5.5. Messaging Service: The Messaging Service should respond with appropriate notification content or null response if no notification is cached.
C5.5。消息传递服务：消息传递服务应使用适当的通知内容进行响应，如果未缓存通知，则应使用空响应。
C5.6. ICAP Server Responds: The ICAP server responds and furnishes the appropriate content for the web notification to the web proxy.
C5.6。ICAP服务器响应：ICAP服务器响应并向web代理提供web通知的适当内容。
C5.7. Web Proxy Sends Response: The web proxy then forwards the HTTP response containing the web notification to the client web browser.
C5.7。Web代理发送响应：然后Web代理将包含Web通知的HTTP响应转发给客户端Web浏览器。
C5.8. User Response: The user observes the critical web notification, and clicks an appropriate option, such as: OK/ acknowledged, snooze/remind me later, etc.
C5.8。用户响应：用户观察关键web通知，并单击适当的选项，例如：确定/确认、暂停/稍后提醒我等。
C5.9. More Information: Depending upon the notification, the user may be provided with more information. For example, as noted previously, the system was designed to provide critical notifications concerning malware infection. Thus, in the case of malware infection, the user may be advised to go to a malware remediation web page that provides directions on how to attempt to remove the malware and attempt to secure hosts against future malware infection.
C5.9。更多信息：根据通知，可能会向用户提供更多信息。例如，如前所述，该系统旨在提供有关恶意软件感染的关键通知。因此，在恶意软件感染的情况下，可能会建议用户转到恶意软件修复网页，该网页提供了关于如何尝试删除恶意软件和尝试保护主机免受未来恶意软件感染的说明。
C5.10. Turn Down Diffserv: Once the notification transaction has completed, remove any special Diffserv settings.
C5.10。拒绝区分服务：通知事务完成后，删除任何特殊的区分服务设置。
The web proxy and ICAP server are critical components of the system. This section shows the communication that occurs between these two components.
web代理和ICAP服务器是系统的关键组件。本节显示这两个组件之间发生的通信。
+------------+
| www URI |
+------------+
^ |
(2)| |(3)
| v
+--------+ (4) +--------+ (4) +--------+
| |------------>| |------------>| |
| | (5) | | (5) | |
| Proxy |<------------| ICAP |<------------| ICAP |
| Module | (6) | Client | (6) | Server |
| |------------>| |------------>| |
| | (7) | | (7) | |
| |<------------| |<------------| |
+--------+ +--------+ +--------+
^ |
(1)| |(8)
| v
+------------+ (9) +------------+
| |----------------------------->| |
| Browser | (10) | Web Server |
| |<-----------------------------| |
+------------+ +------------+
+------------+
| www URI |
+------------+
^ |
(2)| |(3)
| v
+--------+ (4) +--------+ (4) +--------+
| |------------>| |------------>| |
| | (5) | | (5) | |
| Proxy |<------------| ICAP |<------------| ICAP |
| Module | (6) | Client | (6) | Server |
| |------------>| |------------>| |
| | (7) | | (7) | |
| |<------------| |<------------| |
+--------+ +--------+ +--------+
^ |
(1)| |(8)
| v
+------------+ (9) +------------+
| |----------------------------->| |
| Browser | (10) | Web Server |
| |<-----------------------------| |
+------------+ +------------+
(1) - HTTP GET (TCP 80)
(2) - Proxy HTTP GET (TCP 80)
(3) - HTTP 200 OK w/ Response
(4) - ICAP RESPMOD
(5) - ICAP 200 OK
(6) - TCP Stream - Encapsulate Header
(7) - ICAP 200 OK Insert Message
(8) - HTTP 200 OK w/ Response + Message Frame
(9) - HTTP GET for Message
(10) - HTTP 200 w/ Message Content
(1) - HTTP GET (TCP 80)
(2) - Proxy HTTP GET (TCP 80)
(3) - HTTP 200 OK w/ Response
(4) - ICAP RESPMOD
(5) - ICAP 200 OK
(6) - TCP Stream - Encapsulate Header
(7) - ICAP 200 OK Insert Message
(8) - HTTP 200 OK w/ Response + Message Frame
(9) - HTTP GET for Message
(10) - HTTP 200 w/ Message Content
Figure 2: Communication between Web Proxy and ICAP Server
图2：Web代理和ICAP服务器之间的通信
This section describes the exact flow of an end-to-end notification, in order to show in detail how the system functions.
本节描述端到端通知的确切流程，以便详细说明系统如何工作。
Policy-Based Routing
基于策略的路由
1. TCP port 80 packets from the user that needs to be notified are routed to the web proxy via policy-based routing.
1. 来自需要通知的用户的TCP端口80数据包通过基于策略的路由发送到web代理。
2. Packets are forwarded to the Session Management Broker, which establishes a session with the web proxy and routes the packets to the web proxy.
2. 数据包被转发到会话管理代理，该代理与web代理建立会话并将数据包路由到web代理。
Web Proxy
网络代理
1. The user's HTTP request is directed to the web proxy.
1. 用户的HTTP请求被定向到web代理。
2. The web proxy receives HTTP traffic and retrieves content from the requested website.
2. web代理接收HTTP流量并从请求的网站检索内容。
3. The web proxy receives the response and forwards it to the ICAP server for response adaptation.
3. web代理接收响应并将其转发给ICAP服务器进行响应自适应。
4. The ICAP server checks the HTTP content in order to determine whether the notification message can be inserted.
4. ICAP服务器检查HTTP内容，以确定是否可以插入通知消息。
5. The ICAP server initiates a request to the Messaging Service cache process with the IP address of the user.
5. ICAP服务器使用用户的IP地址向消息传递服务缓存进程发起请求。
6. If a notification message for the user exists, then the appropriate notification is cached on the Messaging Service. The Messaging Service then returns the appropriate notification content to the ICAP server.
6. 如果存在用户的通知消息，则相应的通知将缓存在消息服务上。然后，消息传递服务将适当的通知内容返回给ICAP服务器。
7. Once the notification message is retrieved from the Messaging Service cache, the ICAP server may insert the notification message in the HTTP response body without altering or modifying the original content of the HTTP response.
7. 一旦从消息传递服务缓存中检索到通知消息，ICAP服务器就可以在不改变或修改HTTP响应的原始内容的情况下将通知消息插入HTTP响应正文中。
8. The ICAP server then sends the response back to the web proxy, which in turn forwards the HTTP response back to the browser.
8. 然后，ICAP服务器将响应发送回web代理，而web代理又将HTTP响应转发回浏览器。
9. If the user's IP address is not found or provisioned for a notification message, then the ICAP server should return a "204 No modifications needed" response to the ICAP client as defined in Section 4.3.3 of [RFC3507]. As a result, the user will not receive any web notification message.
9. 如果未找到或未为通知消息设置用户的IP地址，则ICAP服务器应按照[RFC3507]第4.3.3节中的定义，向ICAP客户端返回“204无需修改”响应。因此，用户将不会收到任何web通知消息。
10. The user observes the web notification, and clicks an appropriate option, such as: OK/acknowledged, snooze/remind me later, etc.
10. 用户观察web通知，并单击适当的选项，例如：确定/确认、打盹/稍后提醒我等。
The two figures below show the communications flow from the web browser, through the web notification system.
下图显示了通过web通知系统从web浏览器进行的通信流。
Figure 3 illustrates what occurs when a notification request cannot be inserted because the notification type for the user's IP address is not cached in the Messaging Service.
图3说明了由于用户IP地址的通知类型未缓存在消息服务中而无法插入通知请求时发生的情况。
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | Proxy | | | | |
+------->| Request | | | | |
| +---------|---------|--------|------->| |
| | | | | 200 OK | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | Check | | |
| | +-------->| Cache | | |
| | | | for IP | | |
| | | | Match | | |
| | | +------->| | |
| | | | Cache | | |
| | | | Miss | | |
| | | |<-------+ Request| |
| | | 204 No | | Type | |
| | | Modif. | +--------|------->|
| | | Needed | | | |
| | No |<--------+ | | Type |
| | Insert | | | |Returned|
| 200 OK |<--------+ | |<-------|--------+
| w/o | | | | | |
| Insert | | | | | |
|<-------+ | | | | |
| | | | | | |
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | Proxy | | | | |
+------->| Request | | | | |
| +---------|---------|--------|------->| |
| | | | | 200 OK | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | Check | | |
| | +-------->| Cache | | |
| | | | for IP | | |
| | | | Match | | |
| | | +------->| | |
| | | | Cache | | |
| | | | Miss | | |
| | | |<-------+ Request| |
| | | 204 No | | Type | |
| | | Modif. | +--------|------->|
| | | Needed | | | |
| | No |<--------+ | | Type |
| | Insert | | | |Returned|
| 200 OK |<--------+ | |<-------|--------+
| w/o | | | | | |
| Insert | | | | | |
|<-------+ | | | | |
| | | | | | |
Figure 3: End-to-End Web Notification Flow - with Cache Miss
图3：端到端Web通知流-缓存未命中
Figure 4 illustrates what occurs when a notification request for the user's IP address is cached in the Messaging Service.
图4说明了在消息传递服务中缓存用户IP地址的通知请求时发生的情况。
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | Proxy | | | | |
+------->| Request | | | | |
| +---------|---------|--------|------->| |
| | | | | 200 OK | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | Check | | |
| | +-------->| Cache | | |
| | | | for IP | | |
| | | | Match | | |
| | | +------->| | |
| | | | Cache | | |
| | | | Hit | | |
| | | Insert |<-------+ | |
| | Return | Type | | | |
| | 200 OK |<--------+ | | |
| | with | | | | |
| | Insert | | | | |
| 200 OK |<--------+ | | | |
| w/ | | | | | |
| Notify | | | | | |
|<-------+ | | | | |
| | | | | | |
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | Proxy | | | | |
+------->| Request | | | | |
| +---------|---------|--------|------->| |
| | | | | 200 OK | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | Check | | |
| | +-------->| Cache | | |
| | | | for IP | | |
| | | | Match | | |
| | | +------->| | |
| | | | Cache | | |
| | | | Hit | | |
| | | Insert |<-------+ | |
| | Return | Type | | | |
| | 200 OK |<--------+ | | |
| | with | | | | |
| | Insert | | | | |
| 200 OK |<--------+ | | | |
| w/ | | | | | |
| Notify | | | | | |
|<-------+ | | | | |
| | | | | | |
Figure 4: End-to-End Web Notification Flow - with Cache Hit
图4：端到端Web通知流-缓存命中
The figure below shows an example of a normal HTTP GET request from the user's web browser to www.example.com, a web server on the Internet.
下图显示了从用户的web浏览器到Internet上的web服务器www.example.com的正常HTTP GET请求示例。
------------------------------------------------------------------------
1. HTTP GET Request to www.example.com
------------------------------------------------------------------------
http://www.example.com/
------------------------------------------------------------------------
1. HTTP GET Request to www.example.com
------------------------------------------------------------------------
http://www.example.com/
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14)
Gecko/20080404 Firefox/2.0.0.14
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
------------------------------------------------------------------------
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14)
Gecko/20080404 Firefox/2.0.0.14
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
------------------------------------------------------------------------
Figure 5: Example HTTP Headers for a Web Notification - HTTP GET
图5：Web通知的HTTP头示例-HTTP GET
In the figure below, the traffic is routed via the web proxy, which communicates with the ICAP server and returns the response from www.example.com. In this case, that response is a 200 OK, with the desired notification message inserted.
在下图中，流量通过web代理路由，该代理与ICAP服务器通信，并从www.example.com返回响应。在这种情况下，该响应为200 OK，并插入了所需的通知消息。
------------------------------------------------------------------------
2. Response from www.example.com via PROXY
------------------------------------------------------------------------
HTTP/1.x 200 OK
Date: Thu, 08 May 2008 16:26:29 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Age: 18
X-Cache: HIT from localhost.localdomain
Via: 1.0 localhost.localdomain (squid/3.0.STABLE5)
Proxy-Connection: keep-alive
------------------------------------------------------------------------
------------------------------------------------------------------------
2. Response from www.example.com via PROXY
------------------------------------------------------------------------
HTTP/1.x 200 OK
Date: Thu, 08 May 2008 16:26:29 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Age: 18
X-Cache: HIT from localhost.localdomain
Via: 1.0 localhost.localdomain (squid/3.0.STABLE5)
Proxy-Connection: keep-alive
------------------------------------------------------------------------
Figure 6: Example HTTP Headers for a Web Notification - HTTP Response
图6：Web通知的HTTP头示例-HTTP响应
The figure below shows an example of the web notification content inserted in the 200 OK response, in this example JavaScript code.
下图显示了插入到200OK响应中的web通知内容的示例，在此示例JavaScript代码中。
------------------------------------------------------------------------
3. Example of JavaScript containing Notification Insertion
------------------------------------------------------------------------
<!--all elements used in a notification should have cascading style
sheet (css) properties defined to avoid unwanted inheritance from
parent page-->
------------------------------------------------------------------------
3. Example of JavaScript containing Notification Insertion
------------------------------------------------------------------------
<!--all elements used in a notification should have cascading style
sheet (css) properties defined to avoid unwanted inheritance from
parent page-->
<style type="text/css">
#example {
position: absolute; left: 100px; top: 50px;
z-index: 9999999; height: auto; width: 550px;
padding: 10px;
border: solid 2px black;
background-color:#FDD017;
opacity: 0.8; filter: alpha(opacity = 80);
}
</style>
<style type="text/css">
#example {
position: absolute; left: 100px; top: 50px;
z-index: 9999999; height: auto; width: 550px;
padding: 10px;
border: solid 2px black;
background-color:#FDD017;
opacity: 0.8; filter: alpha(opacity = 80);
}
</style>
<script language="javascript" type="text/javascript">
// ensure that content is not part of an iframe
if (self.location == top.location) {
// this is a floating div with 80% transparency
document.write('<div id="example" name="example">');
document.write('<h2>IMPORTANT MESSAGE</h2>');
document.write('<p>Lorem ipsum dolor sit amet, consecteteur ');
document.write('adipisicing elit, sed do eiusmod tempor ');
document.write('incididunt ut labore et dolore magna aliqua. ');
document.write('Ut enim ad minim veniam, quis nostrud ');
document.write('exercitation ullamco laboris nisi ut aliquip ex ');
document.write('ea commodo consequat.');
document.write('</div>');
}</script>
------------------------------------------------------------------------
<script language="javascript" type="text/javascript">
// ensure that content is not part of an iframe
if (self.location == top.location) {
// this is a floating div with 80% transparency
document.write('<div id="example" name="example">');
document.write('<h2>IMPORTANT MESSAGE</h2>');
document.write('<p>Lorem ipsum dolor sit amet, consecteteur ');
document.write('adipisicing elit, sed do eiusmod tempor ');
document.write('incididunt ut labore et dolore magna aliqua. ');
document.write('Ut enim ad minim veniam, quis nostrud ');
document.write('exercitation ullamco laboris nisi ut aliquip ex ');
document.write('ea commodo consequat.');
document.write('</div>');
}</script>
------------------------------------------------------------------------
Figure 7: Example JavaScript Used in a Web Notification
图7：Web通知中使用的JavaScript示例
The components of the web notification system should be distributed throughout the network and close to end users. This ensures that the routing performance and the user's web browsing experience remain excellent. In addition, a HTTP-aware load balancer should be used in each datacenter where servers are located, so that traffic can be spread across N+1 servers and the system can be easily scaled.
web通知系统的组件应分布在整个网络中，并靠近最终用户。这确保了路由性能和用户的web浏览体验保持优异。此外，服务器所在的每个数据中心都应使用支持HTTP的负载平衡器，以便流量可以分布在N+1台服务器上，并且系统可以轻松扩展。
This critical web notification system was conceived in order to provide an additional method of notifying end user customers that their computer has been infected with malware. Depending upon the specific text of the notification, users could fear that it is some kind of phishing attack. As a result, care has been taken with the text and any links contained in the web notification itself. For example, should the notification text change over time, it may be best to provide a general URI or a telephone number. In contrast to that, the notification must not ask for login credentials, and must not ask a user to follow a link in order to change their password, since these are common phishing techniques. Finally, care should be taken to provide confidence that the web notification is valid and from a trusted party, and/or that the user has an alternate method of checking the validity of the web notification. One alternate method of validating the notification may be to call customer support (in this example, Comcast's Customer Security Assurance team); this explains a key requirement (specifically, "Should Keep Notification Records for Customer Support Purposes") in Section 3.4.
这个关键的web通知系统是为了提供一种额外的方法来通知最终用户客户他们的计算机已经感染了恶意软件。根据通知的具体文本，用户可能担心这是某种钓鱼攻击。因此，对web通知本身包含的文本和任何链接都非常小心。例如，如果通知文本随时间变化，最好提供一个通用URI或电话号码。与此相反，通知不得要求用户提供登录凭据，也不得要求用户通过链接更改密码，因为这是常见的网络钓鱼技术。最后，应注意确保web通知有效且来自受信任方，和/或用户具有检查web通知有效性的替代方法。验证通知的另一种方法可能是致电客户支持（在本例中，是康卡斯特的客户安全保障团队）；这解释了第3.4节中的一项关键要求（特别是“应保留通知记录以供客户支持之用”）。
Some members of the community may question whether it is ever, under any circumstances, acceptable to modify Internet content in order to provide critical service notification concerning malware infection - even in the smallest of ways, even if openly and transparently documented, even if thoroughly tested, and even if for the best of motivations. It is important that anyone with such concerns recognize that this document is by no means the first to propose this, particularly as a tactic to combat a security problem, and in fact simply leverages previous work in the IETF, such as [RFC3507]. Such concerned parties should also study the many organizations using ICAP and the many software systems that have implemented ICAP.
社区的一些成员可能会质疑，在任何情况下，修改互联网内容以提供有关恶意软件感染的关键服务通知是否可以接受，即使是以最小的方式，即使是公开透明的文件记录，即使是经过彻底测试，即使出于最好的动机。重要的是，任何有这种担忧的人都必须认识到，本文件绝不是第一个提出这一点的人，特别是作为一种解决安全问题的策略，事实上只是利用了IETF中以前的工作，如[RFC3507]。这些相关方还应研究使用ICAP的许多组织以及实施ICAP的许多软件系统。
In addition, concerned members of the community should review Section 1, which describes the fact that this is a common feature of DPI systems, made by DPI vendors and many, if not most, major networking equipment vendors. As described herein, the authors of this document are motivated to AVOID the need for widespread, ubiquitous deployment of DPI, via the use of both open source software and open protocols, and are further motivated to transparently describe the details of how such a system functions, what it IS intended to do, what it IS NOT intended to do, and purposes for which it WILL NOT be used.
此外，社区有关成员应审查第1节，该节描述了这是新闻部系统的一个共同特点，由新闻部供应商和许多（如果不是大多数的话）主要网络设备供应商制造。如本文所述，本文件的作者被激励通过使用开源软件和开放协议来避免广泛、无处不在地部署DPI的需要，并进一步被激励来透明地描述此类系统如何工作、打算做什么、不打算做什么的细节，以及不将其用于的目的。
The authors also believe it is important for ISPs to transparently disclose network management techniques and systems, and to have a venue to do so, as has been done here. In addition, the authors believe it is important for the IETF and other members of the Internet community to encourage and positively reinforce such disclosures. In the publishing of such a document for reference and comment by the Internet community, this may serve to motivate other ISPs to be similarly open and to engage the IETF and other organizations that are part of the Internet community. Not publishing such documents could motivate less disclosure on the part of ISPs and other members of the Internet community, increase the use of DPI, and decrease ISP participation in the critical technical bodies that make up parts of the Internet community.
作者还认为，ISP必须透明地披露网络管理技术和系统，并有一个这样做的场所，就像这里所做的那样。此外，作者认为IETF和互联网社区的其他成员鼓励并积极加强此类披露非常重要。在出版此类文件供互联网社区参考和评论时，这可能有助于激励其他ISP采取类似的开放态度，并与IETF和互联网社区中的其他组织接触。不发布此类文件可能会促使ISP和互联网社区其他成员减少披露，增加DPI的使用，并减少ISP参与组成互联网社区的关键技术机构。
In addition, it is critical that members of the community recognize the good motivations of ISPs like Comcast to combat the massive and continuing proliferation of malware, which is a huge threat to the security of average Internet users and now represents a multi-billion-dollar underground economy engaged in identity theft, financial fraud, transmission of spam, and other criminal activity. Such a critical notification system in fact is only necessary due to the failure of host-based security at defending against and preventing malware infection. As such, ISPs such as Comcast are being urged by their customers and by other parties such as security and/or privacy organizations, as well as governmental organizations, to take action to help solve this massive problem, since so many other tactics have been unsuccessful. For example, as Howard Schmidt, the Special Advisory for Cyber Security to President Obama, of the United States of America, said in 2005: "As attacks on home-based and unsecured networks become as prevalent as those against large organizations, the need for ISPs to do everything they can to make security easier for their subscribers is critical for the preservation of our nation's information backbone. Additionally, there is tremendous potential to grow further the use of broadband around the world; and making safety and security part of an ISP's core offering will enable the end user to fully experience the rich and robust benefits broadband provides".
此外，社区成员必须认识到Comcast等ISP打击大规模持续扩散的恶意软件的良好动机，这对普通互联网用户的安全构成了巨大威胁，目前代表着数十亿美元的地下经济，从事身份盗窃、金融欺诈、，垃圾邮件的传播和其他犯罪活动。事实上，只有在基于主机的安全性无法抵御和防止恶意软件感染的情况下，才需要这样一个关键通知系统。因此，像Comcast这样的ISP正被其客户、安全和/或隐私组织等其他方以及政府组织敦促采取行动帮助解决这一巨大问题，因为许多其他策略都没有成功。例如，正如美国总统奥巴马的网络安全特别顾问霍华德·施密特（Howard Schmidt）在2005年所说：“随着对基于家庭和不安全网络的攻击与对大型组织的攻击一样普遍，ISP需要尽一切努力使其用户的安全更容易，这对于保护我国的信息主干网至关重要。此外，在全世界范围内，宽带的使用有着进一步增长的巨大潜力；将安全和安保作为ISP核心服务的一部分，将使最终用户能够充分体验宽带带来的丰富而强大的好处”。
A "walled garden" refers to an environment that controls the information and services that a subscriber is allowed to utilize and what network access permissions are granted. Placing a user in a walled garden is therefore another approach that ISPs may take to notify users, and this method is being explored as a possible alternative in other documents and community efforts. As such, web notifications should be considered one of many possible notification methods that merit documentation.
“围墙花园”是指一个环境，它控制允许订阅者使用的信息和服务以及授予的网络访问权限。因此，将用户放置在有围墙的花园中是ISP通知用户的另一种方法，目前正在探索这种方法，作为其他文件和社区工作中的一种可能替代方法。因此，web通知应该被视为许多可能的通知方法之一，这些方法值得文档化。
However, a walled-garden approach can pose challenges and may in some cases be considered disruptive to end users. For example, a user could be playing a game online, via the use of a dedicated, Internet-connected game console, which would likely stop working when the user was placed in the walled garden. In another example, the user may be in the course of a telephone conversation, using a Voice Over IP (VoIP) device of some type, which would also likely stop working when the user was placed in the walled garden. In both cases, the user is not using a web browser and would not have a way to determine the reason why their service seemingly stopped working.
然而，围墙花园方法可能会带来挑战，在某些情况下可能会被视为对最终用户造成破坏。例如，用户可以通过使用专用的、连接互联网的游戏机在线玩游戏，当用户被放置在有围墙的花园中时，游戏机可能会停止工作。在另一个示例中，用户可能正在电话对话过程中，使用某种类型的IP语音（VoIP）设备，当用户被放置在有围墙的花园中时，该设备也可能停止工作。在这两种情况下，用户都没有使用web浏览器，无法确定其服务似乎停止工作的原因。
Unfortunately, at the time of this writing, no existing working group of the IETF is focused on issues of malware infection and related issues. As a result, there was not a definite venue for this document, so it was submitted to the Independent Submissions Editor as an independent submission. While documentation and disclosure of this system are beneficial for the Internet community in and of itself, there are other benefits to having this document published. One of those reasons is that members of the community, including members of the IETF, have a stable document to refer to in the case of any potential new work that the community may undertake in the area of malware, security, and critical notification to end users. It is also hoped that, in the tradition of a Request for Comment, other members of the community may be motivated to propose alternative systems or other improvements.
不幸的是，在撰写本文时，IETF没有一个现有的工作组专注于恶意软件感染和相关问题。因此，本文件没有明确的发布地点，因此作为独立提交文件提交给独立提交文件编辑。虽然本系统的文件编制和披露本身对互联网社区有益，但出版本文件还有其他好处。其中一个原因是，社区成员，包括IETF成员，在社区可能在恶意软件、安全和向最终用户发出关键通知方面开展的任何潜在新工作中，都有一份稳定的文件可供参考。我们还希望，按照征求意见的传统，社区的其他成员可能会被激励提出替代系统或其他改进方案。
The authors wish to thank Alissa Cooper for her review of and comments on the document, and Nevil Brownlee for his excellent feedback, as well as others who reviewed the document.
作者希望感谢Alissa Cooper对该文件的审查和评论，以及Nevil Brownlee的出色反馈，以及其他审查该文件的人。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC2854]Connolly，D.和L.Masinter，“文本/html”媒体类型”，RFC 28542000年6月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140]Black，D.，Brim，S.，Carpenter，B.，和F.Le Faucheur，“每跳行为识别码”，RFC 31402001年6月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation Protocol (ICAP)", RFC 3507, April 2003.
[RFC3507]Elson，J.和A.Cerpa，“互联网内容适应协议（ICAP）”，RFC 3507，2003年4月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, April 2006.
[RFC4329]Hoehrmann，B.，“脚本媒体类型”，RFC 4329，2006年4月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 45942006年8月。
[CableLabs_DOCSIS] CableLabs, "Data-Over-Cable Service Interface Specifications", CableLabs Specifications, Various DOCSIS Reference Documents, <http://www.cablelabs.com/ specifications/archives/docsis.html>.
[CableLabs_DOCSIS]CableLabs，“电缆数据服务接口规范”，CableLabs规范，各种DOCSIS参考文件<http://www.cablelabs.com/ 规范/归档文件/docsis.html>。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]Floyd，S.，“不适当的TCP重置被认为是有害的”，BCP 60，RFC 3360，2002年8月。
Authors' Addresses
作者地址
Chae Chung Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: chae_chung@cable.comcast.com URI: http://www.comcast.com
Chae Chung Comcast有线通信一号Comcast中心宾夕法尼亚州费城肯尼迪大道1701号19103美国电子邮件：Chae_chung@cable.comcast.comURI:http://www.comcast.com
Alex Kasyanov Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: alexander_kasyanov@cable.comcast.com URI: http://www.comcast.com
亚历克斯·卡西亚诺夫康卡斯特有线通信一号康卡斯特中心宾夕法尼亚州费城肯尼迪大道1701号，邮编：19103美国电子邮件：亚历山大_kasyanov@cable.comcast.comURI:http://www.comcast.com
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: jason_livingood@cable.comcast.com URI: http://www.comcast.com
Jason Livingood Comcast有线通信一号Comcast中心宾夕法尼亚州费城肯尼迪大道1701号，邮编：19103美国电子邮件：Jason_livingood@cable.comcast.comURI:http://www.comcast.com
Nirmal Mody Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: nirmal_mody@cable.comcast.com URI: http://www.comcast.com
Nirmal Mody Comcast有线通信一号Comcast中心宾夕法尼亚州费城肯尼迪大道1701号，邮编：19103美国电子邮件：Nirmal_mody@cable.comcast.comURI:http://www.comcast.com
Brian Van Lieu Unaffiliated Bethlehem, PA 18018 US EMail: brian@vanlieu.net
Brian Van Liue非附属伯利恒，宾夕法尼亚州18018美国电子邮件：brian@vanlieu.net