填写正确后，会进入路由器暗码修改页面，在系统东西——修改登录口令页面即可完成修改（原用户名和口令和2中填写的一致）
六、如何防备DNS挟制（应用层面）本小节内容来自美图在HTTPS情况的DNS优化实践，通过该优化方案，使美图App请求耗时节省近半。 真实案例，提供应各人参考。 美图的移动端产物在实际用户情况下谋面对 DNS 挟制、耗时颠簸等问题，这些 DNS 环节的不不变因素，导致后续网络请求被挟制或是直接失败, 对产物的用户体验发生欠好的影响。 为此，对移动端产物的 DNS 理会举办了优化摸索，发生了相应的 SDK。在这进程中，参考警惕了业内的主流方案，也举办了一些实践上的思考。 下面的内容会主要以 Android 平台来举办说明。
LocalDNS VS HTTP DNS 在恒久的实践中，互联网公司发明 LocalDNS 会存在如下几个问题：
域名缓存: 运营商 DNS 缓存域名理会功效，将用户导向网内缓存处事器;
理会转发 & 出口 NAT: 运营商 DNS 转发查询请求或是出口 NAT 导致流量调治计策失效;
为了办理 LocalDNS 的这些问题，业内也催生了 HTTP DNS 的观念。 它的根基道理如下: 原本用户举办 DNS 理会是向运营商的 DNS 处事器提倡 UDP 报文举办查询，而在 HTTP DNS 下，我们修改为用户带上待查询的域名和本机 IP 地点直接向 HTTP WEB 处事器提倡 HTTP 请求，这个 HTTP WEB 将返回域名理会后的 IP 地点。 好比 DNSPod 的实现道理如下:
对比 LocalDNS, HTTP DNS 会具备如下优势:
根治域名理会异常: 绕过运营商的 DNS，向具备 DNS 理会成果的 HTTP WEB 处事器提倡查询;
调治精准: HTTP DNS 可以或许直接获取到用户的 IP 地点，从而实现精确导流;
扩展性强: 自己基于 HTTP 协议，可以实现更强大的成果扩展;
那么，是否直接全部走 HTTP DNS 呢?
美图移动端 DNS 优化计策摸索 HTTP DNS 对比 LocalDNS 存在一些优势, 然而 HTTP DNS 自己也是存在必然的本钱问题。 美图的产物线富厚，涉及的域名也较为遍及，为了适应各产物的实际场景，在实践中设计了较为机动的计策节制。 首先，在计策上并未完全放弃 LocalDNS。 一个 App 涉及的域名浩瀚，在计策上可以或许设置其焦点 API 域名走 HTTP DNS，而对付非焦点请求仍但愿它先实验走 LocalDNS, 在异常环境下才进级走 HTTP DNS。 那么如何判定 LocalDNS 的异常环境呢? 选择一下三个指标来权衡一个 DNS 处事器的质量环境:
IP 记录的 TTL 时间: 在 DNS 挟制产生的环境下，返回的 TTL 大概会有很是大的值;
理会耗时: 假如一个 DNS 处事器理会耗时不抱负，那么它也不是我们但愿的;
返回的 IP 的可毗连性: 对返回的 IP 举办质量测试，假如毗连状况不佳，那么这个 DNS 处事器有挟制的可疑;
在 Android 平台上，通过系统要领得到的理会功效信息长短常有限的，上面的指标有的将无法获取，因此在实践中我们会本身去结构 DNS 查询报文，向运营商的多个 DNS 处事器提倡查询。 通过上面几个指标的综合评定，当 LocalDNS 表示不佳的时候，计策上我们将进级走 HTTP DNS，实验让用户获取更好的 DNS 理会结果。 在 DNS 理会环节，尚有一个我们较量体贴的指标，那就是 DNS 理会的耗时： LocalDNS 在逾期的环境下，会提倡递归查询，这个时间是不行控的，在部门环境下甚至能到达数秒级别； HTTP DNS 相对会好一些，但正常来看，也会有200ms 阁下的耗时。 这个时间可否再优化一些呢？ 我们 SDK 在当地构建了本身的记录缓存池，每次通过 LocalDNS 或是 HTTP DNS 理会获得记录都存在缓冲池中。 虽然，这个是普遍的做法，系统底层的 netdb 库也是这样实现。 区别在于我们做了一个小窜改： 对付逾期的记录我们回收懒更新的计策，当查到逾期的缓存记录时，先返回逾期记录给用户，同时再异步从头提倡 DNS 查询更新缓存记录。 这个小窜改可以或许担保我们二次理会时都能掷中当地缓存，极大地低落 DNS 理会耗时，不外它也带来了必然的风险性。 因此实践中，我们也会添加异步按期的 DNS 记录缓存池扫描成果，实时发明缓存中的逾期记录并举办更新，也低落 App 掷中逾期记录的环境。