现象：
1.如下两个url，被解析到同一台服务器，由Istio的Gateway及VirtualService完成软路由：
https://dev-test.pconline.com.cn/login.html
2.在浏览器中始终无法同时访问这两个url，总有一个会报404，该现象与网络无关，普遍存在
3.清除缓存后，或者过足够时间长后，原本访问结果为404的url可以恢复访问
4.挂上代理、使用curl、使用postman时该问题不存在
5.部分浏览器如夸克浏览器，也存在相同情况，但是只需要等待数分钟，便可恢复访问
6.部分浏览器如老版本的Chrome浏览器，等待足够长时间后，便可恢复访问
问题分析：
1.我认为，极有可能是keep-alive之类的东西，印象了Istio的软路由
实验设计：
1.删除所有的ingress pod，等待k8s重新建立pod，此时两个url优先访问的能正常访问（已证实）
2.同时监听两个pod的端口，并过滤ip地址为公司公网ip，此时如果未用公司电脑进行访问，应该是不会有任何信息的（已证实）
3.使用一台电脑访问url，并查看端口，过滤ip地址，应该可以看到一条记录（已证实）
4.抵用第二胎电脑访问url，并查看端口，过滤ip地址，应该可以看到两条记录（已证实）
5.此时两个url中必然存在一个不可以访问的（现象）
6.删除所有pod，等待k8s重建，立即访问之前不可访问的url，发现其可以访问， 而另一个不可访问（已证实）
6_1.如果不删除所有pod，等待netsta -an结果消失的瞬间，再去访问，可以肯定是可以正常访问的（实验条件苛刻，未实验）
实验结论分析：
1.因为没有办法直接关闭一个established，所以采用了直接杀掉一个pod的方案，如果具有关闭一个established的方法，相信结果更具备说服力。
2.正如实验中的图片中显示，当netstat -an具有结果的时候，则表示客户端始终和服务端保持着连接，而这个时候也正是第二个url无法访问的时候
3.结合之前得到的istio-proxy日志中，request_server_name总是为前一个成功访问的服务的host名，这儿可以认为就是因为连接始终处于保持状态，导致二次请求时，istio-proxy配置没有起到作用
4.另外，在学习istio时，注意到istio是区分tcp请求和http请求的，这儿有一种感觉，我们的http请求总是被当做tcp请求处理了。但是这个绝对不是我们配置产生的问题
问题解决思路：
1.将Istio升级到较新的版本，尝试能否解决这个问题，避免低版本的Istio存在更多的问题
2.在升级Istio后，如果无法解决问题，可以考虑安排时间研究envoy，尝试在envoy上解决这个问题。同时，较好的掌握envoy，也可以提升定位和分析问题的能力
2.为什么会建立一个keep alive，是nginx引发的这个问题么，如果有可能的话，需要对nginx进行配置，或者建立两个简单的项目进行试验。如果是这个层面的原因，解决起来将会很方便。
对问题的进一步分析：
1.在对http进行试验后，发现两次访问，建立了不止一个tcp通道，可以肯定问题的核心原因不在于keep-alive，而在于两个不同域名的https请求，只建立一个tcp通道，而且还在复用这个通道
进一步实验：
http部分的实验：
1.删除所有ingress，查看端口，并过滤公网IP，此时没有任何连接；查看客户端连接，过滤slb ip，此时没有任何连接
2.访问如下链接，注意，我用的是http，同时观察istio-proxy的日志和客户端的日志，发现两边同时建立了两条tcp通道，这是和期待想符合的（已证实，截图如下）
3.访问如下链接，注意，我用的是http，同时观察istio-proxy的日志和客户端的日志，发现两边同时建立了三条tcp通道，这是和期待想符合的（已证实，截图如下）
http://dev-test.pconline.com.cn/login.html
4.同时删除pod，并查看客户端，发现所有的通道都关闭了，这是和期待想符合的（已证实）
https部分的实验
1.删除所有ingress，查看端口，并过滤公网IP，此时没有任何连接；查看客户端连接，过滤slb ip，此时没有任何连接
2.访问如下链接，查看客户端请求，发现建立了一条tcp通道，这是和期待想符合的（已证实，未截图）
3.访问如下链接，查看客户端请求，发现建立了两条tcp通道，这是和期待想符合的，此时观察服务端的tcp通道发现只有一条（已证实，截图如下）
https://dev-test.pconline.com.cn/login.html
实验结论：
1.我们第二次请求是可以正常与istio通信的，这个现象可以从日志中看到，但是通信中request_server_name是一个错误的值
2.https请求中服务端tcp通道数与预期不符合，说明我们的通道被中间某个组件给处理过，且它认为我们是在同一个域名下的请求
3.我又做了一部分实验，得出的结论如下，阿里云已经开始介入处理这个问题了，我们不打算在这个问题上花费太多的时间：
