对于DHCP+Web方式，用户认证通过后，同样由接入服务器向后台的RADIUS服务器发送计费开始包，当用户需要下线时，需要通过点击Web页面挂断按钮，触发宽带接入服务器向后台的RADIUS服务器发送计费结束包。在这种正常情况下，计费数据较准。但如果用户是异常下线，接入服务器需要根据设置的用户空闲最长时间来判断，如果超过最长空闲时间。则认为是用户已下线，此时宽带接入服务器向后台的RADIUS服务器发送计费结束包。后台计费系统便
对于DHCP+Web方式，用户认证通过后，同样由接入服务器向后台的RADIUS服务器发送计费开始包，当用户需要下线时，需要通过点击Web页面挂断按钮，触发宽带接入服务器向后台的RADIUS服务器发送计费结束包。在这种正常情况下，计费数据较准。但如果用户是异常下线，接入服务器需要根据设置的用户空闲最长时间来判断，如果超过最长空闲时间。则认为是用户已下线，此时宽带接入服务器向后台的RADIUS服务器发送计费结束包。后台计费系统便可根据计费起始包、结束包按时长、按流量进行实时计费。利用这种判断用户异常下线方式，可能最后的计费结束包的时间比用户实际的下线时间要多出一段时间。要解决这个问题，需要将用户空闲的最长时间设短，但此时间如果太短，又有可能让用户在上网的过程中（比如较长时间的阅读，没有通信流量的时候，会被
BAS认为是用户已下线），出现多次需要重新进行认证，带来使用的不方便性。
对网络环境的要求
PPPoE的本质就是在以太网上跑PPP协议。由于PPP协议认证过程的第一阶段是Discovery阶段，广播只能在二层网络，才能发现BAS。因此，也就决定了在用户主机和BAS之间，不能有路由器或三层
交换机。另外，由于PPPoE的点对点的本质，在用户主机和BAS之间，限制了组播协议的存在。这样，将会在一定程度上，影响今后视频业务的开展。不过国际上为了解决这个问题， 提出了一些草案（
IPmulticasting and broadcasting extension for PPPoE Protocol），希望能解决PPPoE上的组播问题。DHCP+Web认证不存在二层网络的限制，同样也不存在组播协议的限制。
可管理性
对于PPPoE方式，宽带接入服务器与RADIUS服务器配合，可以进行一定程度的服务质量控制。较多的接入服务器能够实现Policing和rate-limiting等功能。Policing是一种接收控制功能，只容许指定速率的流量通过。类似的，rate-limiting是发送控制功能，只容许指定速率的流量发送。
对于DHCP+Web方式，当采用旁路方式的网络架构时，不能对用户进行带宽管理。如果是直路的网络架构，可以根据用户的不同，对带宽进行不同等级的限速控制。
IP地址分配
PPPoE方式下的IP地址分配，完全是由宽带接入服务器和RADIUS服务器配合完成，用户不能修改。同时，后台的支撑系统还能够根据不同的用户分配不同范围、不同性质的IP地址，如某些用户使用公网地址，某些用户使用私有地址。
DHCP+Web则不能根据用户的不同，在IP地址的分配上做不同的区分。另外，使用DHCP来动态分配IP地址，还可以基于策略化分配。
客户端软件限制
使用PPPoE进行用户认证，必须在客户端安装虚拟拨号软件。通过此虚拟拨号软件来与运营商局端的宽带接入服务器完成PPPoE的连接。但随着Windows XP的发布，微软已把PPPoE虚拟拨号的功能集成到操作系统中。
DHCP+Web认证方式最大的一个优势就在于客户端不需要安装任何拨号软件，认证完全依靠浏览器来完成，在维护上很方便。
多服务选择能力
在PPPoE方式下，许多厂家的宽带接入服务器提供类似“虚设备”的处理
模块，不同的用户能够基于不同的“虚设备”，而引导至不同的服务区域。
