RDP ( Reliable Data Protocol )

RFC908 - Reliable Data Protocol
http://www.ietf.org/rfc/rfc0908.txt?number=908

RFC1151 - Version 2 of the Reliable Data Protocol (RDP)
http://www.ietf.org/rfc/rfc1151.txt?number=1151

可靠数据协议 RDP 是一种面向连接的传输协议，其主要设计来为主机监控应用程序如下载 / 上传以及远程调试进行有效的大批数据传输。RDP 尝试只提供那些必需的服务，达到操作有效、尺度小的效果。其主要功能如下：

• RDP 为每个传输层连接端口提供一个全双工通信信道；
• RDP 尝试可靠发送所有用户信息，一旦发送失败，将向用户报告错误。RDP 扩展 IP 数据报服务使之能够可靠发送；
• RDP 尝试侦测并删除所有损坏的和重复的数据段，它在数据段头使用校验码及序列号实现这一过程；
• RDP 随意地提供数据段序列发送，必须在连接建立时就指定数据段的序列发送；
• RDP 会响应确认序列之外的数据段，这会释放发送端的资源。

与 TCP 相比，RDP 所支持的功能更为简单。RDP 的流控制，缓冲以及连接管理模式都是相当简单的。RDP 的目标就是能够简单有效地执行并能适合一系列的应用程序。

RDP 函数集也可能是子集从而进一步减小特殊执行的大小。例如，一台向其它主机请求下载的目标处理器可能执行一个仅支持默认的开放式函数和单连接的 RDP 模块。这个模块也可能选择不执行非顺序响应确认。

协议结构

RDP 第二版协议头结构如下：

1	2	3	4	5	6	8	16bit
SYN	ACK	EAK	RST	NUL	0	Ver No	Header Length
SourcePort
DestinationPort
Data Length
Sequence Number
Acknowledgement Number
Checksum
Variable header area …

Control flags ― 8个控制位划分如下：

• SYN：SYN 位表示当前为同步段。
• ACK：ACK 位表示协议头有效的承认序号。
• EACK：EACK 位表示当前为扩展承认字段。.
• RST：RST 位表示该数据包为复位字段。
• NUL：NUL 位表示该数据包为空字段。
• 0：表示该字段的值必须设置为0。
• Ver no：版本号，当前版本号为2。

Header length ― RDP 协议头长度。

Source Ports ― 源地址，识别通信发生的过程。网络访问协议头中，源地址和目标地址的端口标识符的结合完全限定了连接并形成连接标识符。如此 RDP 可用于区分两台主机间的多连接。

Destination Ports ― 目标地址，识别通信中的目标过程。

Data Length ― 该字段中的数据长度（八位），该数据长度不包括 RDP 协议头。

Sequence number ― 该字段的序列号。

Acknowledgement number ― 如果 ACK 位设置在协议头部，这就是字段序列号，即该字段发送端最后正确按序列接收的顺序。一旦连接成功，就应该发送该字段。

Checksum ― 检验和确保完整性。

Variable Header Area ― 用于传输 SYN 和 EACK 字段的参数。

DHCP+

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IP 宽带接入网中的几种认证技术：

PPPoE技术
PPPoE（PPP over Ethernet）为IETF RFC2516标准协议，是从基于ATM的窄带网引入到宽带以太网的，实现在Ethernet上传输封装PPP报文，由于IP包和PPP报文不兼容，必须有专门的设备终结PPP报文并转换为IP报文，这种设备就是BRAS。用户与BRAS设备之间PPPoE通信过程包含两个阶段：PPPoE发现阶段和PPP会话阶段，发现阶段是无状态的Client/Server模式，目的是获得PPPoE终结端的以太网MAC地址，并建立一个唯一的PPPoE SESSION_ID。发现阶段结束后，就进入标准的PPP会话阶段。一旦PPPoE会话开始，PPP数据就可以像其它的PPP封装形式一样发送。

802.1X技术
802.1X为IEEE Std 802.1X-2001基于端口的访问控制协议，可以克服PPPoE方式带来的诸多问题，并避免引入宽带接入服务器所带来的巨大投资。802.1X协议限制未经授权的用户/设备通过接入端口访问LAN/WAN。在获得交换机或LAN提供的各种业务之前，802.1x对连接到交换机端口上的用户进行认证。在认证通过之前，802.1x只允许EAPoL(基于局域网的扩展认证协议)数据通过设备连接的交换机端口；认证通过以后，正常的数据可以顺利地通过以太网端口。

DHCP+技术

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DHCP+接入认证技术是一种基于DHCP协议通过控制终端用户的IP地址分配实现控制用户接入的认证鉴权技术，DHCP+目前尚处于发展初期阶段，尚未推出正式的标准。常见于PPPoE接入认证方式受限的场合，例如BTV业务应用场合。

DHCP协议是DHCP+接入认证技术的基础，它是RFC组织定义的一种标准，采用客户机－服务器工作机制，实现客户机向服务器请求分配IP地址的流程。 为了解决对用户进行有效的接入认证控制问题和提高接入网络的安全性，DHCP+接入认证技术在网络安全、网络监控以及用户控制和终端识别等方面对DHCP 协议进行了扩展。

网络安全方面，在报文入接口通过对报文匹配DHCP Snooping绑定表项，防止了IP盗用、用户私接、DHCP Server仿冒、IP/MAC Spoofing攻击、DoS（Deny of Service）攻击，规避了DHCP协议的安全缺陷。

网络监控方面，通过对丢弃的非法报文分别计数，在网管系统的配合下，实现针对各种攻击的阀值告警分别输出，提高运维部门的故障定位和解决效率，以降低运营成本。

用户控制方面，DHCP PS（DHCP Policy Server）通过建立基于用户物理位置信息的本地数据库，对用户进行认证控制。所谓用户物理位置信息就是标识用户所在的设备、端口以及QinQ双层标签 信息，当然，所谓用户是用一个或多个MAC地址来识别的。用这种方法限制了私拉盗接和用户串用等问题，从而减轻了运维压力，保护了合法用户的权益，为营运 增收提供可能。

此外，可在DHCP+报文中引入多个灵活的Option字段，满足不同场合的用户需求。例如对于存在多个终端同时使用DHCP的场合，在DHCP +报文中引入Option60以区分终端类型。DHCP PS通过识别Option60选项实现对不同的终端分配不同的地址空间功能。

图-1显示了DHCP+用于城域网接入认证的应用场景。在此解决方案中，Internet业务以原有PPPoE方式通过BRAS设备接入， VoIP、VoD、BTV等业务以DHCP+认证方式接入用户。我们以BTV业务为例，分析一下DHCP+接入认证技术是如何实现在认证和安全方面的上述 功能的。

基于DHCP+接入认证技术的BTV组播接入过程

首先我们了解一下城域网中针对BTV业务的配置情况，自家庭网关传送到DSLAM上的BTV组播业务的PVC，在DSLAM设备上全部映射到组播VLAN 中，在UPE上终结IGMP报文，然后在UPE和NPE以及核心层部署组播路由协议PIM-SSM或者PIM-SM/DM。在UPE设备上配置DHCP Relay功能、DHCP Snooping功能、Option82功能以及相应的报文检查功能，在DSLAM设备上如果功能支持也可以配置DHCP Snooping功能、Option82功能。

客户享受组播服务之前，STB通过两次握手，向DHCP PS申请IP地址的过程：

1、客户端广播DHCP Discover报文，以发现DHCP PS，UPE依据DHCP Snooping功能捕获此报文，并插入Option82，然后把报文中继到DHCP PS。Option82是DHCP报文中的一个选项字段，它携带了DHCP请求报文入端口信息、QinQ双层标签以及UPE设备名称等信息，此选项内容因 生产厂家而略异。如果DSLAM设备配置上述功能，Option82在DSLAM设备插入，则在UPE上通过配置可以重新插入自己的Option82信 息，也可以直接透传DSLAM设备上的Option82信息。

2、DHCP PS收到报文后，通过读取Option82信息分离出其中的设备端口信息、QinQ双层标签等标识用户物理位置的信息，然后将此信息与DHCP PS上的用户数据库相应信息比较。不一致，则DHCP PS不做任何响应；一致，则DHCP PS回送一个DHCP Offer报文。其中含有一个IP地址和携带原有Option82信息，其中的数据库信息是运营商开户时根据用户所在设备端口、QinQ双层标签信息录入 的，供DHCP PS认证用户的数据。

3、此报文通过UPE时，被剥离Option82，从相应的Vlan和端口送出，STB收到后，广播DHCP Request报文，以通知其它未选中的DHCP PS和询问被选中的DHCP PS其它的配置选项，如DNS、网关地址等。

4、此报文在UPE上同样做Option82插入处理并向DHCP PS中继，DHCP PS收到此报文后，将回送一个DHCP ACK报文，其中包括用户IP、网关、DNS等配置信息以及IP租约信息，并携带Option82信息。

5、UPE收到此报文，剥离Option82信息后向STB转发此报文，同时根据报文内容和Option82完成建立DHCP+ Snooping绑定表项。STB收到DHCP ACK报文后，广播一个免费ARP报文，确认自己使用的IP地址没有与其它用户冲突后，开始使用此IP地址，与此同时在DHCP PS上根据配置决定是否将该用户的MAC地址和其用户数据库信息绑定，作为用户再次接入的认证条件。

至此用户与DHCP PS的报文交互完成，客户终端开始发送IGMP请求报文，申请加入组播组，加入成功后，组播业务流开始接入到BTV客户终端。

另外，DHCP+接入认证技术也可以用于运营商的园区网和大客户接入场合，组网模式如图-2所示，其中核心设备可以是三层或者二层交换机，接入过程和原理 与上述相同。用户认证接入之后通过防火墙NAT功能访问Internet和享受其它服务，用于满足小区宽带业务经营者需求、集团用户的个性化需求，也给用 户接入和安全互访带来便利。

DHCP PS对接入用户的控制

DHCP PS在收到自客户终端的DHCP Discover报文后，将依据报文中Option82描述的UPE设备、所在端口、QinQ双层标签信息与开户时录入的用户物理位置数据库信息对照，根 据结果进行下一动作，用户再次认证上线时，DHCP PS将根据用户MAC和录入的用户物理位置数据库信息唯一标识用户。DHCP PS用这种方法对用户做接入权限认证，防止用户私接盗用问题，增强用户控制。如图-1中红色箭头所示，同一个用户从UPE/DSLAM/LAN设备的不同 Vlan接口接入被拒绝分配IP地址，不同的用户从相同UPE/DSLAM/LAN设备Vlan接口接入也被拒绝分配IP地址。

在UPE/LAN上建立DHCP+ Snooping绑定表项内容如表-1所示（各厂家内容略有不同）。其中接口信息正是分析DHCP+ ACK报文中Option82获取的。

Mac addr	IP addr	Lense（s）	Type	Outside-Vlan	Inside-Vlan	Interface
00:02:98:F4:D2:C1	10.110.98.75	060820-1050	STATIC	100	1100	Ethernet4/0/0

表-1 DHCP+ Snooping绑定表

DHCP+接入认证技术应对攻击策略

在采用传统DHCP协议时，用户和服务器可能面临各种各样的攻击和仿冒，DHCP+接入认证技术根据不同攻击类型，提供不同应对策略，见表-2。

攻击类型	DHCP+接入认证技术防攻击策略
DHCP Server仿冒者攻击	端口上设置信任(Trusted)和不信任(Untrusted)工作模式
中间人攻击	通过DHCP Snooping绑定表对攻击报文匹配过滤
IP/MAC Spoofing攻击	通过DHCP Snooping绑定表对攻击报文匹配过滤
改变CHADDR值的DoS攻击	检查DHCP报文的CHADDR字段

表-2 攻击类型与防攻击策略对应表

所谓DHCP Server仿冒攻击，就是DHCP Server仿冒者通过UPE的其它业务端口发送DHCP Responses （offer、ack、nak）报文给DHCP Client，使其获取错误的IP、网关地址等，达到DoS（Deny of Service）的目的。DHCP+接入认证技术通过仅在接到DHCP PS方向的接口上设置DHCP Snooping“信任”模式，对于“不信任”端口上收到的DHCP Responses报文将直接丢弃，以此达到隔离DHCP Server仿冒者的目的。

中间人攻击是指中间人向客户端发带有自己MAC和服务器IP的报文，又同时向服务器发带有自己MAC和客户端IP的报文，最终使客户端和服务器分别学到自 己的IP和MAC，使服务器发到客户端的报文都会经过中间人。IP/MAC Spoofing攻击是指攻击者向服务器发送带有合法用户IP和MAC的报文，使服务器误以为已经学到这个合法用户的IP和MAC，但真正的合法用户不能 从服务器获得服务。为隔离中间人攻击与IP/MAC Spoofing攻击，DHCP+接入认证技术使用UPE设备上生成的DHCP Snooping绑定表对接口收到的报文进行检查。如果接口收到ARP或者IP报文，就用报文中的“源IP+源MAC”去匹配DHCP Snooping绑定表，如果绑定表中没有匹配项就丢弃该报文，否则正常转发，通过这样匹配方式，不仅可以防止上述攻击，也防止了设置静态IP的用户和 IP盗用者。

对于DHCP饿死攻击（所谓饿死攻击是指攻击者通过不断变换用户物理地址，尝试申请DHCP域中所有的IP地址，以耗尽DHCP Server地址池资源，导致其他正常用户无法获得地址，达到DoS的目的。），我们可以在DSLAM/LAN端口上设置MAC Limit数量来限制此类攻击。但攻击者倘若改变的不是数据帧头部的源MAC，而是改变DHCP报文中的CHADDR（Client Hardware Address）值来不断申请IP地址。那么“MAC地址限制”方案显然是行不通的。为保证业务的安全性，DHCP+接入认证技术检查DHCP Request报文中CHADDR字段。如果该字段跟数据帧头部的源MAC相匹配，便转发报文；否则，丢弃报文，有效阻止这类攻击。

DHCP+接入认证技术的客观局限性

DHCP+接入认证技术优势主要体现在其组播支持方面。众所周知，组播复制点越接近用户越能节省带宽，而组播复制点一般部署在二层和三层网络的分界线。这 就意味着DHCP+接入认证技术组播优势要充分体现，城域网络必须是三层路由到边缘的组网模式。倘若将来视频分发以P2P技术为主，其组播优势便无用武之 地。

DHCP+接入认证技术尚处于其发展初期阶段，协议相关标准还没有最终制定，厂家之间的实现标准尚不统一，使其进一步发展完善受限。DHCP+接入认证技 术目前仅仅适用于包月制收费方式，很难做到根据流量和时长进行计费，从而对用户的不可控因素较多，Internet业务的Wholesale销售模式也难 以进行，这些都是任何运营商所不愿看到的。而且由于其开放性特点，其接入的安全性尚需接受更多的验证和考验。

因而这种接入方式有很大局限性，目前阶段仅适用于小规模部署的部分业务，例如利用傻终端接入的BTV业务，并不能取代PPPoE实现其它业务类型的接入管理。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DHCP+ 解决了PPPoE认证中的PPP包封装和隧道问题，适应IPTV等流媒体业务组播复制的需要。

组播复制问题实际上是组播复制点的选择问题。组播复制点即用户IGMP请求的终结点。在组播复制点，网络设备根据端口是否有IGMP请求向端口 复制组播流。组播复制点越接近用户越能节省网络带宽。由于传统的PPPoE的接入方式，使得组播复制点最低只能在BRAS设备上，在某些地市的城域网中， BRAS往往在汇聚层的层次位置，并下联了几千数量级的用户，这样高层次的组播复制点必然带来大量的重复流量，这本身是与组播协议的初衷相悖的。同时，虽 然BRAS经过多年的发展，性能上已经得到了长足的进步，但是如果需要BRAS设备能够支持到上千组播流的复制还是一个重大的挑战。因此，目前各运营商和 厂商均不推荐PPPoE+BRAS，这种方式已经不适合在IPTV承载网络上作为接入认证技术；而在IPTV的应用场景下以DHCP为基础扩展为接入认证 方式在IPTV的承载网络上显示出了蓬勃的生命力，并越来越被运营商普遍认可和接受。

IP Multicasting

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

介绍IP组播基本概念的几个链接:
http://www.tcpipguide.com/free/t_IPMulticasting.htm
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtssm.htm#wp1026772

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

IP组播应用中的三个主要技术问题:
1. Multicast Addressing (组播编址方法)
2. Multicast Group Management (IGMP related) (有效的通知和交付机制)
3. Multicast Datagram Processing and Routing (有效的网络间转发工具)


Scope of IPv4 and IPv6 multicast addresses


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

(转载)
组播报文基于组的概念，它的接收对象是特定组的主机。想接收组播数据的主机需要利用IGMP报文申明加入某个组播组。
组播报文采用D类地址，即开头为1110的IP地址，范围是224.0.0.0 - 239.255.255.255，映射到01 00 5e 00 00 00 - 01 00 5e 7f ff ff的MAC地址上面。组播地址只可用作目的地址。
一般情况下，网卡只接收MAC地址与自身匹配或者广播地址的数据包，但在802.3标准中，定义了MAC地址的第一个字节的最低位用来指示是否一个组播/广播数据包。标记为组播/广播数据包的仍然会被网卡接收处理。

那为什么我的主机没有申请加入任何组播组，却仍然截获了组播报文呢？原来二层交换机默认会把需要转发的组播包转发给子网内的所有机器，这使得组播机制有名无实。 在二层交换机中一般会采用CGMP或者IGMP Snooping来弥补这一点，前者是Cisco的专有技术，后者是IEEE标准。如果一个交换机启用IGMP Snooping，它会在每个组播包进入交换机之后，解析报文头，如果它是一帧IGMP报文，则按照报文的内容将连接该主机的端口保存到组播表或者从中删除。如果是普通的组播包，则根据设备里保存的组播表进行转发。因为二层交换机不能直接区分IGMP和普通组播包，所以对于每个广播/组播包都要执行这样的检查，在低端设备中通常在软件上实现，对交换速度有很大影响。高端设备采用专用的ASIC，在硬件里实现。
(转载)

CGMP和IGMP Snooping的区别：(在IGMPv2中)
两者都是为了解决二层switch转发多播包时的效率问题。
在实现上两者的主要区别在于在何处解析IGMP包的内容。
在CGMP 的实现中，是由multicast router在收到某主机通过switch传过来的IGMP report时，发送一条CGMP join消息给switch, switch收到后会把该主机的相关信息加入到对应多播组的content addressable memory (CAM) table里。
在IGMP Snooping中，解析IGMP包的工作是在二层switch上做的。switch会检查所有通过它外发的多播包，分辨其中的IGMP report消息并在收到该类消息时把发送的主机的信息保存到对应组的table entry里。
由于IGMP Snooping的实现中，switch需要检查所有的多播包，所以在数据吞吐量很大时会对switch的性能有很大影响，所以IGMP Snooping技术一般只实现在高端的switch中。而CGMP技术可以被应用在低端的switch中。关于二者的更详尽的阐述可参考本文的第二个链接。

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

IGMP和组播编址方法指定了主机怎样和本地路由器交互，如何通过单个网络传送组播数据报，但没有指定路由器怎样交换群组成员信息，或者怎样确保每个数据报的副本能够到达所有群组成员。

常规转发/选路和组播转发/选路的区别：

• 在单播选路中，只有当拓扑结构改变或设备出故障时才会发生路由改变；而组播路由则不同，应用程序加入或退出一个组播群组就会发生组播路由的变化。
• 组播转发需要路由器检查多个目的网络。
• 组播数据报可以从非组播群组成员的计算机上发起，并且可以路由通过没有任何组播成员的网络。

基本组播选路：
因为组播目的代表了一个计算机集合，最佳转发系统将使数据报到达该集合中的所有成员，并且一个数据报不会两次通过同一个网络。
为了避免选路环路，组播路由器必须依靠数据报的源地址。

当进行转发决策时，组播路由器使用了数据报的源地址和目的地址。
基本转发机制称为截尾反向路径转发(TRPF - Truncated Reverse Path Forwarding)
组播选路的一种最早形式是从TRPF派生的，称为反向路径组播RPM(Reverse Path Multicasting)
最早的组播选路协议之一是矢量距离组播选路协议DVMRP(Distance Vector Multicast Routing Protocol). mrouted是在UNIX下实现DVMRP的著名程序。

DVMRP的局限性意味着他从规模上无法处理大量路由器、更大量的组播群组或者成员关系的迅速变化。因此其不适合作为Internet的通用组播选路协议。
为克服DVMRP的局限性，IETF研究了其他一些组播协议：

• 核心基干树CBT(Core Based Trees)
• 协议无关组播PIM(Protocol Independent Multicast)
• OSPF组播扩展(MOSPF)

Multicast Distribution Trees:
Multicast router会创建multicast distribution trees来控制发送traffic的路径。
一般会有两种建立分布树的算法：Source Trees 和 Shared Trees。
详尽的阐述参考本文第二个链接。

组播转发树被定义为一系列通过组播路由器的路径，这些路径从源站到组播群组的所有成员。对于某组播群组，每个可能的数据报源都能确定一个不同的转发树。

组播选路的实质：
成员关系问题是选路的核心 - 所有组播选路方法都提供了一种传播成员信息的机制，还提供了转发数据报时使用该信息的方式。
一般来讲，因为成员关系会迅速改变，从给定路由器可得到的信息是不完整的，因此选路可能滞后于变化。所以，组播设计代表了选路通信量超载和低效数据传输之间的一种折衷。

可靠组播和ACK内爆(ACK implosion)：
可靠组播(reliable multicast)指的是这样的系统：使用组播交付并能够保证所有群组成员收到按序到达、无丢失、无重复且未遭破坏的数据。
为了避免ACK内爆问题，可靠组播方法或者使用确认点层次结构，或者发送冗余信息。

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

HTTP (HyperText Transfer Protocol)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1
http://www.ietf.org/rfc/rfc2616.txt?number=2616

RFC2617 - HTTP Authentication: Basic and Digest Access Authentication
http://www.ietf.org/rfc/rfc2617.txt?number=2617

RFC2145 - Use and Interpretation of HTTP Version Numbers
http://www.ietf.org/rfc/rfc2145.txt?number=2145

RFC2964 - Use of HTTP State Management
http://www.ietf.org/rfc/rfc2964.txt?number=2964

RFC2965 - HTTP State Management Mechanism
http://www.ietf.org/rfc/rfc2965.txt?number=2965

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

超文本传输协议 (HyperText Transfer Protocol, HTTP)的特点：

• 应用层 (Application Level)。HTTP在应用层上操作，采用稳定的，面向连接的传输协议，但不提供可靠性或重传机制。
• 请求/响应 (Request/Response)。一旦建立了传输会话，一端必须向响应的另一端发送HTTP请求
• 无状态 (Stateless)。每个HTTP请求都是自包含的，服务器不保留以前的请求或会话的历史记录。
• 双向传输 (Bi-Directional Transfer)。多数情况下，浏览器请求Web页，服务器把副本传输给浏览器；HTTP也允许从浏览器向服务器传输。
• 协商能力 (Capability Negotiation)。HTTP允许浏览器和服务器协商一些细节。
• 支持高速缓存 (Support For Caching)。
• 支持中介 (Support For Intermediaries)。代理服务器将Web页放入高速缓存并从中应答浏览器的请求。
  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

HTTP GET 请求：

浏览器发送HTTP GET 命令从服务器上请求Web页。
请求由一行文本组成，这行文本以关键字GET 开头，然后是URL以及HTTP版本号。
例如 - GET http://www.cs.purdue.edu/people/comer/HTTP/1.1

在浏览器和Web服务器之间使用超文本传输协议（HTTP）。浏览器向服务器发送GET请求，服务器则发送请求的内容作为响应。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

持久连接和长度：

HTTP的早期版本通过为每个数据传输使用新的TCP连接，遵循和FTP一样的模式。

HTTP1.1 版本不是为每个传输使用TCP连接，而是把持久连接(persistent connection)作为默认方法。即一旦客户打开了和特定服务器的TCP连接，客户就让该连接在多个请求和响应过程中一直存在。当客户或服务器准备关闭连接时，则通知另一端，然后关闭该连接。

持久连接的主要优点在于减少开销，TCP连接越少，意味着响应时间、底层网络上系统开销、缓冲区使用的内存和使用的CPU时间就会减少。可以使用流水线技术(pipelining)请求进一步优化使用持久连接的浏览器（也就是逐个连续地发送请求，不必等待响应）。

使用持久连接需要标识通过连接发送的每一项的开头和结尾。为了避免在标记值和数据之间的多义性，HTTP使用先发送长度，然后发送具有该长度的数据项的方法。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

数据长度和程序输出：

大多服务器使用CGI (Common Gateway Interface)机制，该机制允许计算机程序在服务器上运行，动态创建Web页。这意味着服务器不能提前知道准确的数据大小。

因此，为了提供动态Web页，HTTP标准指定，如果服务器预先不知道数据项的长度，那么服务器可以通知浏览器 (用Connection:close 首部代替Content-Length首部)，它将在传送完项目后关闭连接。

为了允许TCP连接在多个请求和响应中持久存在，HTTP要在每个响应前发送长度；如果不知道长度，服务器通知客户，发送响应，然后关闭连接。

长度编码和首部：

服务器发送长度信息时，HTTP借用了电子邮件的基本格式，使用822格式和MIME扩展格式。
每个HTTP传送包含一个首部、一个空行和要发送的数据项；其中，首部中的每一行包含关键字、冒号和信息。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

协商：

除了指定有关正在发送的数据项的详细信息之外，HTTP还使用首部允许客户和服务器协商(negotiate)各种能力。有两种类型的协商：服务器驱动(server-driven)和代理驱动(agent-driven)(也就是浏览器驱动)。

服务器驱动是从浏览器发出请求开始的。请求指定首选列表以及要求的数据项的URL，服务器从可用的表示法中选出符合浏览器首选要求的一项。
代理驱动只是意味着浏览器用两步过程执行选择操作。首先，浏览器向服务器发送请求，询问可用的内容，服务器返回可能的内容列表。浏览器选择其中一个可能项，发送第二个请求获得该数据项。代理驱动的缺点是要求两个服务器互相作用，优点是浏览器得到了对选项的完全控制权。

HTTP使用类似于MIME的首部传送元信息。浏览器和服务器都发送首部，允许它们对要使用的文档表示和编码进行协商。

条件请求：

HTTP允许发送方有条件地进行请求。即当浏览器发送请求时，它包括的首部限定了在何种条件下应该兑现请求，如果不符合指定的条件，服务器不返回请求的数据项。

条件请求通过避免不必要的传输，从而允许浏览器优化检索过程。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

支持代理服务器：

代理服务器提供了优化机制，能够降低等待时间并减少服务器的负担。

为了保证正确性，HTTP明确支持代理服务器。协议准确地指定代理服务器如何处理每个请求，代理服务器应该如何解释首部，浏览器如何与代理服务器协商，代理服务器如何与服务器协商。另外，已经设计了几个专门用于代理服务器的HTTP首部。

高速缓存：

高速缓存的目的是提高效率，通过消除不必要的传输，高速缓存减少了等待时间和工作量。

HTTP允许服务器以两种方式控制高速缓存：

首先，当HTTP应答对Web页的请求时，服务器可以指定高速缓存的细节，包括该页能否全部缓存，代理服务器是否可以高速缓存该页，哪些人可以共享高速缓存的页面，高速缓存的副本的到期时间，可应用于副本的传输的限制。

其次，HTTP允许浏览器强制Web页重新生效。为此，浏览器发送对该页的请求，使用首部指定最长的“寿命”（也就是自从存储Web页的副本以来的时间）不能大于0。不能使用高速缓存中该页的副本来满足这个请求，因为副本的年龄不是0。这样只有初始服务器将应答该请求。路径上的中介代理服务器将接收到新的高速缓存的副本，发布请求的浏览器也会接收到新的副本。

高速缓存是有效操作Web的关键。HTTP允许服务器控制是否能高速缓存页面、如何高速缓存页面以及页面的生命期；浏览器可以强制页面请求绕过高速缓存，从拥有该页的服务器上得到新的副本。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

HTTP Method:

• OPTIONS
• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE
• CONNECT
  

Several timers in TCP

对于每个连接，TCP管理4个不同的定时器：

1. 超时定时器使用于当希望收到另一端的确认
2. 坚持定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口
   
3. 保活定时器可检测到一个空闲连接的另一端何时崩溃或重启
4. 2MSL定时器测量一个连接处于TIME_WAIT状态的时间

超时定时器

超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

超时时间的计算是超时的核心部分，TCP要求这个算法能大致估计出当前的网络状况，虽然这确实很困难。要求精确的原因有两个：(1)定时长久会造成网络利用率不高。(2)定时太短会造成多次重传，使得网络阻塞。

有了超时就要有重传，但是就算是重传也是有策略的，而不是将数据简单的发送。

关于相关算法和策略的具体内容在TCPv1的21章中有详细叙述。(慢启动，拥塞避免算法，快速重传与快速恢复算法)


坚持定时器

坚持定时器用于防止通告窗口为0以后双方互相等待死锁的情况。

坚持定时器的原理是简单的，当TCP服务器收到了客户端的0滑动窗口报文的时候，就启动一个定时器来计时，并在定时器溢出的时候向向客户端查询窗口是否已 经增大，如果得到非零的窗口就重新开始发送数据，如果得到0窗口就再开一个新的定时器准备下一次查询。通过观察可以得知，TCP的坚持定时器使用1，2， 4，8，16……64秒这样的普通指数退避序列来作为每一次的溢出时间。

有关此定时器的内容在TCPv1的22章中有详细叙述。(糊涂窗口综合症)


保活定时器

保活定时器更加的简单，还记得FTP或者Http服务器都有Sesstion Time机制么？因为TCP是面向连接的，所以就会出现只连接不传送数据的“半开放连接”，服务器当然要检测到这种连接并且在某些情况下释放这种连接，这 就是保活定时器的作用。另外要提到的是，当其中一端如果崩溃并重新启动的情况下，如果收到该端“前生”的保活探察，则 要发送一个RST数据报文帮助另一端结束连接。

有关此定时器的内容在TCPv1的23章有详细叙述。


2MSL定时器

TIME_WAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifttime)。它是任何报文段被丢弃前在网络内的最长时间。

对于一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失(另一端超时并重发最后的FIN)

这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口(客户的IP地址和端口号，服务器的IP地址和端口号)不能再被使用。这个连接只能在2MSL结束之后才能再被使用。

SCTP: Stream Control Transmission Protocol

/* TCP、UDP和SCTP同属传输层协议 */

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
UDP:
RFC768 - User Datagram Protocol
http://www.ietf.org/rfc/rfc0768.txt?number=768

TCP:
RFC793 - Transmission Control Protocol
http://www.ietf.org/rfc/rfc0793.txt?number=793

RFC1323 - TCP Extensions for High Performance
http://www.ietf.org/rfc/rfc1323.txt?number=1323

RFC2581 - TCP Congestion Control
http://www.ietf.org/rfc/rfc2581.txt?number=2581

RFC2988 - Computing TCP's Retransmission Timer
http://www.ietf.org/rfc/rfc2988.txt?number=2988

RFC3390 - Increasing TCP's Initial Window
http://www.ietf.org/rfc/rfc3390.txt?number=3390

SCTP:
RFC2960 - Stream Control Transmission Protocol
http://www.ietf.org/rfc/rfc2960.txt?number=2960

RFC3286 - An Introduction to the Stream Control Transmission Protocol (SCTP)
http://www.ietf.org/rfc/rfc3286.txt?number=3286

RFC3309 - Stream Control Transmission Protocol (SCTP) Checksum Change
http://www.ietf.org/rfc/rfc3309.txt?number=3309

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

SCTP与TCP一样也是一种可靠的传输协议，不过它提供消息边界、传输级别多宿(multihoming)支持以及将头端阻塞(head-of-line blocking)减小到最小的一种方法。

SCTP是一个面向连接的提供可靠全双工关联(association)的协议。SCTP像TCP那样给应用层提供可靠性、排序、流量控制以及全双工的数据传输服务。

SCTP中使用“关联(association)”取代“连接(connection)”是为了避免这样的内涵：一个连接只涉及两个IP地址之间的通信。一个关联指代可能因为多宿而涉及不止一个地址的两个系统之间的一次通信会话。因为SCTP是多宿的，每个关联涉及的源宿两端各有一组IP地址和单个端口号。

与TCP不同的是，SCTP是面向消息的(message-oriented)。SCTP提供消息服务，也就是维护来自应用层的记录边界，它提供各个记录的按序投递服务。与UDP一样，由发送端写入SCTP的每个记录的长度随数据一道传递给接收端应用程序。

SCTP能够在所连接的端点之间提供多个流，每个流各自可靠地按序投递消息。一个流上某个消息的丢失不会阻塞同一关联其他流上消息的投递，这与TCP正好相反。SCTP还提供多宿特性，使得每个SCTP端点能够支持多个IP地址。

Why need Three-way handshake in TCP

握手的第一个报文段可以通过码元字段的SYN比特置1来识别。
第二个报文的码元字段的SYN和ACK比特均置1，指出这是对第一个SYN报文段的确认并继续握手操作。
最后一个握手报文仅仅是一个确认信息，通知目的主机已成功建立了双方所同意的这个连接。







三次握手协议是连接的两端正确同步的充要条件：
因为TCP建立在不可靠的分组交付服务之上，报文可能出现丢失、延迟、重复和乱序的情况，因而协议必须使用超时机制，重传丢失的连接请求。
如果重传的连接请求和原先的连接请求在连接正在建立时到达，或是当一个连接已经建立、使用和结束之后，某个被延迟的连接请求才到达，都会出现麻烦。
三次握手协议（加上这样的规则：在连接建立以后TCP不再理睬又一次的连接请求）就能解决这些问题。

DHCP

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

RFC2131 - Dynamic Host Configuration Protocol
http://www.ietf.org/rfc/rfc2131.txt?number=2131

RFC2132 - DHCP Options and BOOTP Vendor Extensions
http://www.ietf.org/rfc/rfc2132.txt?number=2132

RFC3046 -DHCP Relay Agent Information Option
http://www.ietf.org/rfc/rfc3046.txt?number=3046

RFC3396 - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)
http://www.ietf.org/rfc/rfc3396.txt?number=3396

RFC3925 - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
http://www.ietf.org/rfc/rfc3925.txt?number=3925

RFC3495 - Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration
http://www.ietf.org/rfc/rfc3495.txt?number=3495

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

为做到通用，DHCP允许分配3种类型的地址：

• 类似BOOTP，DHCP允许手工配置，管理人员可为特定的某台计算机配置特定的地址
• DHCP也允许自动配置，管理人员允许DHCP服务器为第一次上网的机器分配一个永久地址
• DHCP允许完全动态配置，服务器可使计算机在一段有限的时间内“租用”一个地址

由于DHCP允许一台主机无人工干预即可获得通信所需的全部参数，所以DHCP是允许自动配置的。当然，自动配置受到管理上的约束。

为适应各种可能的环境，DHCP不指定租用期的固定长度，而是让客户申请某一个租用期，并由服务器通知客户它认可的租用期。

BOOTP和DHCP都使用中继代理(relay agent)，中继代理允许计算机与非本地网络上的服务器联系。当中继代理接收到来自客户的广播申请，他将申请转发到服务器，然后返回服务器发给主机的响应。中继代理使多地址配置变得复杂，因为服务器可能收到同一台机器发出的多个请求。由于BOOTP和DHCP都使用了客户标识符，我们假定一个多地址客户发送识别特定接口的一个值(如一个唯一的硬件地址)，因此即使是通过中继代理收到请求，服务器也能区分一台多地址主机发出的多个请求。


上图为客户使用DHCP获取其IP地址时的6个主要状态和状态间的转换

为使用DHCP，一台主机通过把报文广播给本地网上服务器而成为客户。然后该主机收集服务器提供的地址，从中选择一个地址并验证服务器是否接受。

当不再需要租用地址时，DHCP允许客户终止租用，不再等待租用到期。

当DHCP客户进入已绑定状态后，客户设置3个定时器，分别控制租用更新、重新绑定和到期。

• 第一个定时器的默认值通常是总租用期的50%，当其到期时客户必须尝试重新租用期。

• 第二个定时器在租用期的87.5%时到期，并使客户从更新状态转换到重绑定状态。

• 客户转换到重绑定状态后，已经请求原服务器和本地网络上其他服务器延长其租用期，很少有客户在第三个定时器到期前还没有从任何一个服务器收到响应。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DHCP Options的总结

The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing
configuration information to hosts on a TCP/IP network.  Configuration parameters and
other control information are carried in tagged data items that are stored in the 'options' field
of the DHCP message.  The data items themselves are also called "options."

RFC2132:
0   - pad option
255 - end option
1   - subnet mask
2   - time offset
3   - router option
4   - time server option
5   - name server option
6   - domain name server option
7   - log server option
8   - cookie server option
9   - LRP server option
10  - impress server option
11  - resource location server option
12  - host name option
13  - boot file size option
14  - merit dump file
15  - domain name
16  - swap server
17  - root path
18  - extensions path
19  - IP Forwarding Enable/Disable Option
20  - Non-Local Source Routing Enable/Disable Option
21  - Policy Filter Option
22  - Maximum Datagram Reassembly Size
23  - Default IP Time-to-live
24  - Path MTU Aging Timeout Option
25  - Path MTU Plateau Table Option
26  - Interface MTU Option
27  - All Subnets are Local Option
28  - Broadcast Address Option
29  - Perform Mask Discovery Option
30  - Mask Supplier Option
31  - Perform Router Discovery Option
32  - Router Solicitation Address Option
33  - Static Route Option
34  - Trailer Encapsulation Option
35  - ARP Cache Timeout Option
36  - Ethernet Encapsulation Option
37  - TCP Default TTL Option
38  - TCP Keepalive Interval Option
39  - TCP Keepalive Garbage Option
40  - Network Information Service Domain Option
41  - Network Information Servers Option
42  - Network Time Protocol Servers Option
43  - Vendor Specific Information
44  - NetBIOS over TCP/IP Name Server Option
45  - NetBIOS over TCP/IP Datagram Distribution Server Option
46  - NetBIOS over TCP/IP Node Type Option
47  - NetBIOS over TCP/IP Scope Option
48  - X Window System Font Server Option
49  - X Window System Display Manager Option
50  - Requested IP Address
51  - IP Address Lease Time
52  - Option Overload
53  - DHCP Message Type
54  - Server Identifier
55  - Parameter Request List
56  - Message
57  - Maximum DHCP Message Size
58  - Renewal (T1) Time Value
59  - Rebinding (T2) Time Value
60  - Vendor class identifier
61  - Client-identifier
64  - Network Information Service+ Domain Option
65  - Network Information Service+ Servers Option
66  - TFTP server name
67  - Bootfile name
68  - Mobile IP Home Agent option
69  - Simple Mail Transport Protocol (SMTP) Server Option
70  - Post Office Protocol (POP3) Server Option
71  - Network News Transport Protocol (NNTP) Server Option
72  - Default World Wide Web (WWW) Server Option
73  - Default Finger Server Option
74  - Default Internet Relay Chat (IRC) Server Option
75  - StreetTalk Server Option
76  - StreetTalk Directory Assistance (STDA) Server Option

RFC3495：
122 - CableLabs Client Configuration Option

RFC3925：
The Dynamic Host Configuration Protocol (DHCP) options for Vendor
Class and Vendor-Specific Information can be limiting or ambiguous
when a DHCP client represents multiple vendors.  This document
defines two new options, modeled on the IPv6 options for vendor class
and vendor-specific information, that contain Enterprise Numbers to
remove ambiguity.

124 - Vendor-Identifying Vendor Class Option
125 - Vendor-Identifying Vendor-Specific Information Option

RFC3046:
82  - Relay Agent Information Option

IGMP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

IGMP标准的演进:
RFC1112 - Host Extensions for IP Multicasting
http://www.ietf.org/rfc/rfc1112.txt?number=1112

RFC2236 - Internet Group Management Protocol, Version 2
http://www.ietf.org/rfc/rfc2236.txt?number=2236

RFC3376 - Internet Group Management Protocol, Version 3
http://www.ietf.org/rfc/rfc3376.txt?number=3376

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

其他一些相关标准:
/* IGMP proxy-routing function */
RFC4605 - Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
http://www.ietf.org/rfc/rfc4605.txt?number=4605

/* SSM(source-specific multicast) */
RFC3569 - An Overview of Source-Specific Multicast (SSM)
http://www.ietf.org/rfc/rfc3569.txt?number=3569
RFC4604 - Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast
http://www.ietf.org/rfc/rfc4604.txt?number=4604

/* MLD */
RFC2710 -Multicast Listener Discovery (MLD) for IPv6
http://www.ietf.org/rfc/rfc2710.txt?number=2710
RFC3590 - Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
http://www.ietf.org/rfc/rfc3590.txt?number=3590
RFC3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6
http://www.ietf.org/rfc/rfc3810.txt?number=3810

/* IGMP snooping */
RFC4541 - Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
http://www.ietf.org/rfc/rfc4541.txt?number=4541

/* PIM-SM */
RFC2362 - Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
http://www.ietf.org/rfc/rfc2362.txt?number=2362

/* MBGP */
RFC2283 - Multiprotocol Extensions for BGP-4
http://www.ietf.org/rfc/rfc2283.txt?number=2283

/* MADCAP */
RFC2730 - Multicast Address Dynamic Client Allocation Protocol
http://www.ietf.org/rfc/rfc2730.txt?number=2730

/* MZAP */
RFC2776 - Multicast-Scope Zone Announcement Protocol
http://www.ietf.org/rfc/rfc2776.txt?number=2776

/* IP Router Alert Option */
RFC2113 -IP Router Alert Option
http://www.ietf.org/rfc/rfc2113.txt?number=2113

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

IGMP协议是IP协议的组成部分，被封装在IPv4数据包里进行传输。包含IGMP协议的IP包的TTL值被置为1，限定IGMP只会在本子网内传播。组播路由器和实现组播的主机必须使用IGMP来进行群组成员信息的通信。

IGMP的工作分为两个阶段：

1. 当主机加入一个新的组播群组时，他把一个IGMP报文发送给群组的组播地址，宣布其成员。本地组播路由器接收到这个报文之后，向互联网上其他组播路由器传播这个群组成员信息，以建立必要的路由。
2. 为适应动态的成员，本地组播路由器周期性地轮询本地网络上的主机，以便确定现在各个群组中有哪些主机。如果若干次轮询后，某个群组中始终没有成员，组播路由器就认为该群组中不再有本地网络中的主机，于是停止向其他组播路由器通告该群组的成员信息。

IGMP通过几种方式使得对网络的影响最小：

• 主机与组播路由器之间的所有通信都使用IP组播。当IGMP报文封装到IP数据报中进行传输时，IP目的地址是个组播地址（路由器把通用的IGMP查询发送到全主机组播地址，主机把一些IGMP报文发送给所有路由器地址，主机和路由器都把特定于一个群组的IGMP报文发送到该群组的地址）。因此携带IGMP报文的数据报在传输过程中尽量利用硬件的组播能力。其结果是在支持硬件组播的网络上，不参与IP组播的主机就不会收到IGMP报文。【IGMP Snooping的功能】
• 当轮询确定群组成员时，组播路由器不会为每个群组发送单独报文，而是发送单个查询请求得到关于所有群组的信息。
• 如果多个组播路由器连接到同一个网络，他们会迅速而有效地选用一个路由器来轮询主机成员。因此当网络中添加其他组播路由器时，网络上的IGMP通信量总量不会增加。
• 主机不会同时响应路由器的IGMP查询，每个查询包含一个N值，指定了最大响应时间。当查询到达时，主机选择0到N之间的一个随机时延，在这个时延之后发送响应报文。
• 每台主机监听群组中其他主机的响应，并抑制那些不必要的响应通信量。时延最小的主机首先发送自己的响应，该响应发送给群组的组播地址，所有其他成员都会和组播路由器一样收到副本。其他成员就会取消自己的定时器并抑制传输。因此，实践中每个群组中只有一台主机对请求报文做出响应。

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

IGMPv3 详解:
/*
IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers.
Version 2 added support for "low leave latency";
Version 3 adds support for "source filtering"
*/

1. The Service Interface for Requesting IP Multicast Reception (support source filters)

IPMulticastListen (socket, interface, multicast-address,filter-mode, source-list）

2. IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2.
Every IGMP message described in this document is sent with an IP Time-to-Live of 1,
IP Precedence of Internetwork Control (e.g., Type of Service 0xc0),
and carries an IP Router Alert option [RFC-2113] in its IP header.

3. IGMPv3 支持的消息

0x11 Membership Query
0x22 Version 3 Membership Report
0x12 Version 1 Membership Report
0x16 Version 2 Membership Report
0x17 Version 2 Leave Group

4. Membership Query 消息的IP目的地址

In IGMPv3, General Queries are sent with an IP destination address of
224.0.0.1, the all-systems multicast address. Group-Specific and
Group-and-Source-Specific Queries are sent with an IP destination
address equal to the multicast address of interest. *However*, a
system MUST accept and process any Query whose IP Destination
Address field contains *any* of the addresses (unicast or multicast)
assigned to the interface on which the Query arrives.

5. V3 Membership Report 消息的IP源地址

An IGMP report is sent with a valid IP source address for the
destination subnet. The 0.0.0.0 source address may be used by a
system that has not yet acquired an IP address. Note that the
0.0.0.0 source address may simultaneously be used by multiple systems
on a LAN. Routers MUST accept a report with a source address of 0.0.0.0

6. V3 Membership Report 消息的IP目的地址

Version 3 Reports are sent with an IP destination address of
224.0.0.22, to which all IGMPv3-capable multicast routers listen.
A system that is operating in version 1 or version 2 compatibility
modes sends version 1 or version 2 Reports to the multicast group
specified in the Group Address field of the Report. In addition, a
system MUST accept and process any version 1 or version 2 Report
whose IP Destination Address field contains *any* of the addresses
(unicast or multicast) assigned to the interface on which the Report
arrives.

7. IGMP is an asymmetric protocol, specifying separate behaviors for
group members -- that is, hosts or routers that wish to receive
multicast packets -- and multicast routers.

8. The all-systems multicast address, 224.0.0.1, is handled as a special
case. On all systems -- that is all hosts and routers, including
multicast routers -- reception of packets destined to the all-systems
multicast address, from all sources, is permanently enabled on all
interfaces on which multicast reception is supported. No IGMP
messages are ever sent regarding the all-systems multicast address.

9. The purpose of IGMP is to enable each multicast router to learn, for
each of its directly attached networks, which multicast addresses are
of interest to the systems attached to those networks. IGMP version
3 adds the capability for a multicast router to also learn which
*sources* are of interest to neighboring systems, for packets sent to
any particular multicast address. The information gathered by IGMP
is provided to whichever multicast routing protocol is being used by
the router, in order to ensure that multicast packets are delivered
to all networks where there are interested receivers.

10. IGMPv3 specifies two types of Membership Reports: Current-State and State Change.
"Current-State" Reports are sent in response to Queries; while "State Change" Reports
are sent as a result of a change in interface state.



// To be continue