<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??一站式輕松地調用各大LLM模型接口,支持GPT4、智譜、豆包、星火、月之暗面及文生圖、文生視頻 廣告
                [TOC] ## 網絡優化三個方向 * **速度**。在網絡正常或者良好的時候,怎樣更好地利用帶寬,進一步提升網絡請求速度。 * **弱網絡**。移動端網絡復雜多變,在出現網絡連接不穩定的時候,怎樣最大程度保證網絡的連通性。 * **安全**。網絡安全不容忽視,怎樣有效防止被第三方劫持、竊聽甚至篡改。 ## DNS DNS 的解析是我們網絡請求的第一項工作,默認我們使用運營商的 LocalDNS 服務。這塊耗時在 3G 網絡下可能是 200~300ms,4G 網絡也需要 100ms。 解析慢并不是默認 LocalDNS 最大的“原罪”,它還存在一些其他問題: * **穩定性**。UDP 協議,無狀態,容易域名劫持(難復現、難定位、難解決),每天至少幾百萬個域名被劫持,一年至少十次大規模事件。 * **準確性**。LocalDNS 調度經常出現不準確,比如北京的用戶調度到廣東 IP,移動的運營商調度到電信的 IP,跨運營商調度會導致訪問慢,甚至訪問不了。 * **及時性**。運營商可能會修改 DNS 的 TTL,導致 DNS 修改生效延遲。不同運營商的服務實現不一致,我們也很難保證 DNS 解析的耗時。 為了解決這些問題,就有了 HTTPDNS。簡單來說自己做域名解析的工作,通過 HTTP 請求后臺去拿到域名對應的 IP 地址,直接解決上述所有問題。 微信有自己部署的 NEWDNS,阿里云和騰訊云也有提供自己的 HTTPDNS 服務。對于大網絡平臺來說,我們會有統一的 HTTPDNS 服務,并將它和運維系統打通。在傳統的 DNS 基礎上,還會增加精準的流量調度、網絡撥測 / 灰度、網絡容災等功能。 關于 HTTPDNS 的更多知識,你可以參考百度的[《DNS 優化》](https://mp.weixin.qq.com/s/iaPtSF-twWz-AN66UJUBDg)。對客戶端來說,我們可以通過預請求的方法,提前拿到一批域名的 IP,不過這里需要注意 IPv4 與 IPv6 協議棧的選擇問題。 ## IP的選擇 ### 并發 串行 復合連接 串行連接:例如4秒。我們知道移動互聯網具有不穩定的特征,超時時間設置過短,會導致在弱網絡的情況下,connect 總是失敗,導致不可用。 并行連接:服務器需要提供的連接能力是串行連接的N倍,對服務器連接資源是極大的浪費。同時,并發連接是否會引起連接資源的競爭。 微信【復合連接】: ![](https://img.kancloud.cn/1d/d0/1dd0fdaedba4e25653ae53fd3489f769_640x296.png) 初始階段,應用發起對 IP1 &Port1 的 connect 調用。在第4秒的時候,如果第一個 connect 還沒有返回,則發起對 IP2 &Port2 的 connect 調用。以此類推,直至發起了5組 IP&Port 的 connect 調用。? 對比串行連接與并行連接,復合連接有以下特點: * 常規情況下,服務器負載與串行連接策略相同,實現了低負載的目標; * 異常情況下,每4s發起新(IP,Port)組合的 connect 調用,使得應用可以快速的查找可用 IP&Port,實現高性能的目標; * 在超時時間的選擇上,復合方式的“并發”已經實現了高性能、低負載的目標,因此在超時時間的選擇上可以相對寬松,以保障高可用為重。 綜合對比,復合連接能夠維持低資源消耗的情況下,能同時實現低負載、高性能、高可用的目標。 ### IP選擇策略 * 優先上次成功IP選擇 * 定期遺忘 當一個最優服務端出現問題時,會由于災備系統會切換到次優ip,但是由于又第一條【優先上次成功IP選擇】原則的存在,導致當最優服務端恢復時,大家無法恢復到仍然選擇次優ip,因此有了定時遺忘的邏輯 ## 安全 ### Kerberos 使用**Kerberos**作為**用戶和服務的強身份驗證和身份傳播**的基礎。**Kerberos 是一種計算機網絡認證協議,它允許某實體在非安全網絡環境下通信,向另一個實體以一種安全的方式證明自己的身份。** ![](https://img.kancloud.cn/5e/2a/5e2ac1173910f5820abfcd2acc24f6ac_538x548.png) #### 主要角色 * 用戶鑒權后臺AS (Authentication Server) * 票據后臺TGS(Ticket-Granting Server) * 業務后臺App Server #### 流程 * 密碼校驗、安全通道的建立,獲取大票TGT * 獲取業務票據,TGT換取相應的業務小票ST * 使用業務小票ST去訪問業務服務器 ### ECDH ![](https://img.kancloud.cn/7e/d4/7ed4dc7ca17a0e8fc4ff39c2ee08285e_808x488.png) ECC+DH 密鑰交換算法 #### 算法原理 * A 隨機生成一對公私鑰 PrivateA 和 PublicA * B 隨機生成一對公私鑰 PrivateB 和 PublicB * A 和 B 把自己的公鑰(公開參數)發給對方 * A 和 B 使用自己的私鑰和對方公鑰生成 ShareKey * ShareKeyA \= ShareKeyB ### 優化 輪盤 ## 心跳包 ### 為什么需要心跳機制 長連接就是大家建立連接之后, 不主動斷開. 雙方互相發送數據, 發完了也不主動斷開連接, 之后有需要發送的數據就繼續通過這個連接發送. TCP連接在默認的情況下就是所謂的長連接, 也就是說連接雙方都不主動關閉連接, 這個連接就應該一直存在. 但是網絡中的情況是復雜的, 這個連接可能會被切斷. 比如客戶端到服務器的鏈路因為故障斷了, 或者服務器宕機了, 或者是你家網線被人剪了, 這些都是一些莫名其妙的導致連接被切斷的因素, 還有幾種比較特殊的。 ### 影響TCP連接壽命的思素 在Android下,不管是GCM,還是微信,都是通過TCP長連接來進行消息收發的,TCP長連接存活,消息收發就及時,所以要對影響TCP連接壽命的因素進行研究。 #### 1、NAT超時(主要) 大部分移動無線網絡運營商都在鏈路一段時間沒有數據通訊時,會淘汰 NAT 表中的對應項,造成鏈路中斷(NAT超時的更多描述見附錄9.1)。NAT超時是影響TCP連接壽命的一個重要因素(尤其是國內),所以客戶端自動測算NAT超時時間,來動態調整心跳間隔,是一個重要的優化點。 #### 2、DHCP的租期(lease time) 目前測試發現安卓系統對DHCP的處理有Bug,DHCP租期到了不會主動續約并且會繼續使用過期IP,這個問題會造成TCP長連接偶然的斷連。(租期問題的具體描述見附錄9.2)。? #### 3、網絡狀態變化 手機網絡和WIFI網絡切換、網絡斷開和連上等情況有網絡狀態的變化,也會使長連接變為無效連接,需要監聽響應的網絡狀態變化事件,重新建立Push長連接。 ### 心跳包的作用 TCP長連接本質上不需要心跳包來維持,。 心跳機制就是客戶端隔一段時間向服務端發送心跳包,發現連接斷了, 還可以嘗試重連服務器。(如果讓服務器來發送心跳包給客戶端, 萬一連接斷了, 服務器就再也聯系不上客戶) ### 固定心跳包頻率 建議:4-5分鐘 | | WhatsApp | Line | GCM | | --- | --- | --- | --- | | WIFI | 4分45秒 | 3分20秒 | 15分鐘 | | 手機網絡 | 4分45秒 | 7分鐘 | 28分鐘 | ### 智能心跳方案 [Android微信智能心跳方案](https://mp.weixin.qq.com/s/ghnmC8709DvnhieQhkLJpA?) #### 前后臺區分處理 為了保證微信收消息及時性的體驗,當微信處于前臺活躍狀態時,使用固定心跳。 微信進入后臺(或者前臺關屏)時,先用幾次最小心跳維持長鏈接。然后進入后臺自適應心跳計算。這樣做的目的是盡量選擇用戶不活躍的時間段,來減少心跳計算可能產生的消息不及時收取影響。 ## 監控網絡 ### 第一種方法:插樁 為了兼容性考慮,我首先想到的還是插樁。360 開源的性能監控工具[ArgusAPM](https://github.com/Qihoo360/ArgusAPM)就是利用 Aspect 切換插樁,實現監控系統和 OkHttp 網絡庫的請求。 系統網絡庫的插樁實現可以參考[TraceNetTrafficMonitor](https://github.com/Qihoo360/ArgusAPM/blob/bc03d63c65019cd3ffe2cbef9533c9228b3f2381/argus-apm/argus-apm-aop/src/main/java/com/argusapm/android/aop/TraceNetTrafficMonitor.java),主要利用[Aspect](http://www.shouce.ren/api/spring2.5/ch06s02.html)的切面功能,關于 OkHttp 的攔截可以參考[OkHttp3Aspect](https://github.com/Qihoo360/ArgusAPM/blob/bc03d63c65019cd3ffe2cbef9533c9228b3f2381/argus-apm/argus-apm-okhttp/src/main/java/com/argusapm/android/okhttp3/OkHttp3Aspect.java),它會更加簡單一些,因為 OkHttp 本身就有代理機制。 ~~~ @Pointcut("call(public okhttp3.OkHttpClient build())") public void build() { } @Around("build()") public Object aroundBuild(ProceedingJoinPoint joinPoint) throws Throwable { Object target = joinPoint.getTarget(); if (target instanceof OkHttpClient.Builder && Client.isTaskRunning(ApmTask.TASK_NET)) { OkHttpClient.Builder builder = (OkHttpClient.Builder) target; builder.addInterceptor(new NetWorkInterceptor()); } return joinPoint.proceed(); } ~~~ 插樁的方法看起來很好,但是并不全面。如果使用的不是系統和 OkHttp 網絡庫,又或者使用了 Native 代碼的網絡請求,都無法監控到。 ### 第二種方法:Native Hook。 跟 I/O 監控一樣,這個時候我們想到了強大的 Native Hook。網絡相關的我們一般會 Hook 下面幾個方法 : * 連接相關:connect。 * 發送數據相關:send 和 sendto。 * 接收數據相關:recv 和 recvfrom Android 在不同版本 Socket 的邏輯會有那么一些差異,以 Android 7.0 為例,Socket 建連的堆棧如下: ~~~ java.net.PlainSocketImpl.socketConnect(Native Method) java.net.AbstractPlainSocketImpl.doConnect java.net.AbstractPlainSocketImpl.connectToAddress java.net.AbstractPlainSocketImpl.connect java.net.SocksSocketImpl.connect java.net.Socket.connect com.android.okhttp.internal.Platform.connectSocket com.android.okhttp.Connection.connectSocket com.android.okhttp.Connection.connect ~~~ “socketConnect”方法對應的 Native 方法定義在[PlainSocketImpl.c](http://androidxref.com/7.0.0_r1/xref/libcore/ojluni/src/main/native/PlainSocketImpl.c),查看makefile可以知道它們會編譯在 libopenjdk.so 中。不過在 Android 8.0,整個調用流程又完全改變了。為了兼容性考慮,我們直接 PLT Hook 內存的所有 so,但是需要排除掉 Socket 函數本身所在的 libc.so。 ~~~ hook_plt_method_all_lib("libc.so", "connect", (hook_func) &create_hook); hook_plt_method_all_lib("libc.so, "send", (hook_func) &send_hook); hook_plt_method_all_lib("libc.so", "recvfrom", (hook_func) &recvfrom_hook); ... ~~~ 這種做法不好的地方在于會把系統的 Local Socket 也同時接管了,需要在代碼中增加過濾條件。在今天的 Sample 中,我給你提供了一套簡單的實現。其實無論是哪一種 Hook,如果熟練掌握之后你會發現它并不困難。我們需要耐心地尋找,梳理清楚整個調用流程。 ### 第三種方法:統一網絡庫。 盡管拿到了所有的網絡調用,想想會有哪些使用場景呢?模擬網絡數據、統計應用流量,或者是單獨代理 WebView 的網絡請求。 ![](https://img.kancloud.cn/84/e7/84e7ca3a73979060b8c9baecb4d9867e_1652x852.png) 一般來說,我們不會非常關心第三方的網絡請求情況,而對于我們應用自身的網絡請求,最好的監控方法還是統一網絡庫。**不過我們可以通過插樁和 Hook 這兩個方法,監控應用中有哪些地方使用了其他的網絡庫,而不是默認的統一網絡庫。** # 參考資料 [微信終端跨平臺組件 Mars 系列(三)連接超時與IP&Port排序](https://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=2649286458&idx=1&sn=320f690faa4f97f7a49a291d4de174a9&chksm=8334c3b8b4434aae904b6d590027b100283ef175938610805dd33ca53f004bd3c56040b11fa6#rd) [Android微信智能心跳方案](https://mp.weixin.qq.com/s/ghnmC8709DvnhieQhkLJpA?) [看完您如果還不明白 Kerberos 原理,算我輸](https://juejin.cn/post/6844903955416219661) [16 | 網絡優化(中):復雜多變的移動網絡該如何優化?](https://blog.yorek.xyz/android/paid/master/network_2/)
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看