1.如下兩個url，被解析到同一臺伺服器，由istio的gateway及virtualservice完成軟路由：
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通道，這是和期待想符合的（已證實，截圖如下）
4.同時刪除pod，並檢視客戶端，發現所有的通道都關閉了，這是和期待想符合的（已證實）
https部分的實驗
1.刪除所有ingress，檢視埠，並過濾公網ip，此時沒有任何連線；檢視客戶端連線，過濾slb ip，此時沒有任何連線
2.訪問如下鏈結，檢視客戶端請求，發現建立了一條tcp通道，這是和期待想符合的（已證實，未截圖）
3.訪問如下鏈結，檢視客戶端請求，發現建立了兩條tcp通道，這是和期待想符合的，此時觀察服務端的tcp通道發現只有一條（已證實，截圖如下）
1.我們第二次請求是可以正常與istio通訊的，這個現象可以從日誌中看到，但是通訊中request_server_name是乙個錯誤的值
2.https請求中服務端tcp通道數與預期不符合，說明我們的通道被中間某個元件給處理過，且它認為我們是在同乙個網域名稱下的請求
mysql遠端訪問問題
1 進入mysql，建立乙個新使用者xuys 格式 grant 許可權 on 資料庫名.表名 使用者 登入主機 identified by 使用者密碼 grant select,update,insert,delete on to xuys 192.168.88.234 identified by ...
疑問 NSArray 訪問問題
h檔案 import import inte cehelper.h import quartzcore quartzcore.h inte ce fanweiandleixingviewcontroller uiviewcontroller property nonatomic,retain nss...
解決github訪問問題
github這是個好地方。但是，上不去就蛋疼。今天github上不去，果斷f12下，看下network。發現裡面好多請求都是指向 github.global.ssl.fastly.net這個網域名稱的，然後請求都無法成功。想到了改hosts，於是cmd裡ping github.global.ssl....