幀同步~延時波動

  曾經我也認爲網絡處時是一個或高或低的固定值，且上行和下行相同。幾年工做下來才理解延時和股勢同樣，實時在變化，且
 

波動產生

• 網絡中路由負載變化
• 網絡同路由緩衝達到上限而隨機丟包
• 通訊線路（包括無線）故障而丟包
• 內核與網卡設置產生延時
• 傳輸協議（如 tcp）算法延時
• 應用層各類緩衝延時

 思路
    我認爲能夠改進的地方無線信號丟包、傳輸協議選擇、應用層各類緩、衝內核與網卡。

     無線信號丟包

        這裏說的是無線信號丟包爲何包括有線呢，主要就是有線丟包率很小基本<1% 有線路如今的工藝已經頗有保障了若是是路由丟包那基本能夠認爲網絡擁塞了，這時就非人力能夠右左的了。

        現大來看看無線丟包，無線信號先天不穩定易受干擾因此在信號差的地方丟包率>20%也是常事。優化點在於無信丟包大可能是由於信號很差而不是回爲網絡擁塞因此能夠提升重發頻率來減小丟包形成的延時波動

    傳輸協議選擇
        tcp or udp 這是個老話題了，但仍是要提一下 tcp因爲算當上的特色，設計應用場合並不適合在高實時和高丟包率應用。udp因爲能夠本身實現可靠傳輸與擁塞因此能夠真對使用環境來進行調整。可是能上比不上 tcp 。具體能夠看後續文章

    因此實時動做類手遊 自定義的 udp 會更適合

    應用層的幾個點

         各類緩衝的存在天然的增長了消息處響應的時間。原本這個不能算在網絡延時上，可是對用戶能感覺到的響應 。

       緩衝有存在可使代碼結構更得結構美觀功能單一，如今大多數所框架代碼結構都會出現。

        若是想保有緩衝又想要減小響應時間這時大多人會分出線程來，分別來處理緩衝的輸入和輸出。

        那麼響應速度就只與邏輯處理線程有關，大多數狀況下邏輯線程會被設計成異步處理（線程儘量不掛起，或定時休眠）。這樣的邏輯線程每次處理或發送數據時間間隔就可能由於間隔時間內處理不一樣影響間隔時間而產生響應波響。

    內核網卡配置

這個基本是運維的工做，具體要和運維溝通。通常配置都是爲了儘量平衡硬件性能發揮物理機的性能，這種配置實時性不是最高的。因此能夠選擇定製配置，提升時實性下降總體性能