为什么80%的码农都做不了架构师？>>> 
起因
开发的产品使用到的某服务器后台接口，因为业务的特殊性，在常规的host访问失败时，需要前端再使用指定的ip访问，而且是https。
开始
使用ip访问https的首要问题就是证书验证流程。在提出此需求时，后台同学给了一份阿里云的参考：HTTPS（含SNI）业务场景“IP直连”方案说明 。此中提到的例子是Andriod和ios上的应用，方案就是在使用的对应库中修改https的证书验证过程，使其最终合法。
而开发的桌面App的网络请求使用的是libcurl实现，于是开始查找文档。半天时间里浏览器了一遍libcurl的文档，也看到了有相关ssl相关的参数控制，但一个是看起来很复杂，一个是也没有找到有效解决问题的方法。同时也在网络搜索，意外找到了github上这篇 DNS污染方案调研/iOS防DNS污染方案调研---SNI业务场景 ，里面有清晰的描述，使用 CURLOPT_RESOLVE。
一测试，果然OK。于是欣喜若狂——绕过验证方法的方式太笨，而且还得改请求的地方，将url中的host改为ip。也感叹，浏览了半天我怎么就是没有看到CURLOPT_RESOLVE这个参数呢。
意外
以上发生在评估阶段。等开始进入实质开发阶段，心想，这次可便宜我了。这个周期的任务——秒提。嘿嘿，就好像少了一个需求。不曾想在严格按照需求开发时发生了意外……
首先实际需求：对servicehost 的每次访问需要显式控制是否要使用指定ip（还是偏向常规访问，用ip嘛，只是备案了）。
一个当前情况：App中使用的请求接口是multi handle（设计之初就是为了同时跑多个请求），恰恰是这点——multi handle ——共用 dns cache 。
评估时只是为了验证，简单的在每一个easy handle初始化时写死了如下调用：
host_list_ = curl_slist_append(NULL, "servicehost:443:8.8.8.8");
curl_easy_setopt(curl_handle, CURLOPT_RESOLVE, host_list_); 也即对 servicehost 的每一次（当然包括第一次了）访问都使用 8.8.8.8 这个ip进行访问——8.8.8.8 被 cache 了。后续就算不想使用这个ip也“不行”。
反过来，如果第一次使用常规访问，dns获取到的是9.9.9.9。从测试结果看，即便后续请求设定了servicehost:443:8.8.8.8，实际请求仍然使用的第一次访问servicehost解析到的9.9.9.9——此次调用CURLOPT_RESOLVE不起作用。看起来好像不管是CURLOPT_RESOLVE调用，还是常规请求，dns都被cache了。
收场
再看文档：Remove names from the DNS cache again, to stop providing these fake resolves, by including a string in the linked list that uses the format "-HOST:PORT".
好了，因为场景中对于servicehost的第一次访问是常规host方式，假设ip是9.9.9.9。后续某次想使用8.8.8.8访问，于是需要移除对应的dns cache。
......
host_list = curl_slist_append(host_list, "-servicehost:443");
host_list = curl_slist_append(host_list, "servicehost:443:8.8.8.8");
curl_easy_setopt(curl, CURLOPT_RESOLVE, host);
......如果简单粗暴处理，不开启ip直连时，解析url将对应host的dns cache清除。但实际情况是，只有少量的host才有此需求。一刀切，难免影响了绝大多数常规host访问的效率。
我的做法是：记录那些曾经调用了CURLOPT_RESOLVE的hosts。在每一次请求时判断：当前host没有开启ip访问，但在上述hosts中才清理其dns cache，同时从hosts移除记录。