大家都知道奧斯卡有提名，其實在 webrtc 的 ice 中也有提名，有常規的提名，也有激進的提名，而且提名的候選人不一定是最優秀的候選人喔，本文就帶你一探其中玄妙。文章內容主要描述 rfc 5245 中 ice 相關的狀態和 ice 提名機制，並結合 libnice(0.14) 版本進行分析。
分析乙個問題時候遇到這樣的場景：服務端乙個 candidate，客戶端三個不同優先順序的 candidate，但是最後居然選擇了乙個優先順序最低的 pair。
服務端有乙個 relay candidate，埠 50217。
a=candidate:3 1 udp 503316991 11.135.171.187 50217 typ relay raddr 10.101.107.25 rport 40821
客戶端有三個 candidate，埠 50218（中間優先順序），50219（最低優先順序），50220（最高優先順序）。
candidate 1:
candidate:592388294 1 udp 47563391 11.135.171.187 50219 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fo75 network-cost 50
candidate 2:
candidate:592388294 1 udp 48562623 11.135.171.187 50218 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fo75 network-cost 50
candidate 3:
candidate:592388294 1 udp 49562879 11.135.171.187 50220 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fo75 network-cost 50
remote selected pair: 1:1 592388294 udp 11.135.171.187:50219 relayed
candidate 的 foundation: 這裡先提一下 foundation，會涉及到 frozen 狀態。
對於一條相同的通道，可能有不同的 candidate，比如 relay candidate 被發現的時候，就可以生成乙個新的 server reflexive 型別的 candidate，但是他們都是基於相同的本地位址（ip，埠）和協議，則可以認為這些網路是相似的，則他們就會有相同的 foundation。其中 foundation 在 sdp 中為第乙個字段，即下面例子中的 『7』。
a=candidate:7 1 udp 503316991 11.178.68.36 51571 typ relay raddr 30.40.198.7 rport 55896
ice 主要有以下五種狀態，其中前四種是正常的狀態，第五種狀態 frozen 涉及到 ice frozen algorithm。
ice 的五種狀態：
ice 有兩種提名方式：
對於常規提名，主要工作流程如下：
l r
- -
stun request -> \ l's
stun response -> / check
stun request + flag -> \ l's
regular nomination
除了常規提名，還有一種比較激進的提名，常規提名中會新增一次握手。
l r
- -
stun request + flag -> \ l's
stun response -> / check
figure 5: aggressive nomination
真實案例：
原文參考
當乙個新的提名產生時，會對 ice 內部狀態進行對應的變化。
當一端的 binding request 攜帶了 use candidate 的標誌位時，則會產生一次提名（nomination）。
不管 controlling 或者 controlled 模式下的 agent，處理提名的狀態更新規則建議如下：
當某乙個 stream 的所有 compont 都至少擁有乙個提名時，且檢查仍然在進行時：
當檢查列表中的所有 pair 都完成時:
當檢查列表檢查有失敗時:
在描述提名時，還會涉及 ice 對 pair 的排程（當有效 candidate 還在 in progress 的時候但是其他 candidate 的 pair 已經收到 binding request）。
這裡只討論 full，先不描述 lite 模式。
ice 的 checks 分成兩種，ordinary checks and triggered checks。
當 ice 建立乙個 check list （每個 stream 乙個）後，會對每個 check list 新增乙個定時器，當定時器到來時，會進行如下排程：
注：這裡有點不能理解，整個流程看起來是序列的，啟用速度有點慢。
簡單了解了 ice 的流程後，我們回歸最開始的 case。
首先看 add candidate，三個 remote candidate 新增順序不同，依次為 50219，50218，50220，注意，此時 50219 收到了對端的 binding request，激進提名，攜帶 use_candidate，因此很快執行 create permission 並完成，這時候可以開始傳送 binding request 了，屬於 triggered checks 優先排程，傳送 binding request，並進入 in progress 狀態。
注：這裡除了本地 relay 的 pair，還有和 turn 通訊的本地 host 型別的 candidate。
接著在 50219 在其他兩個 create permission 還沒完成時候以迅雷不及掩耳之勢完成了 check，根據 rfc 8.1.2 中的描述，對於不是在 in progress 狀態的 pair，都刪除，並不參考其優先順序，故最後選擇了 50219 這個優先順序最低的 pair。
WebRTC ICE 狀態與提名處理
大家都知道奧斯卡有提名，其實在 webrtc 的 ice 中也有提名，有常規的提名，也有激進的提名，而且提名的候選人不一定是最優秀的候選人喔，本文就帶你一探其中玄妙。文章內容主要描述 rfc 5245 中 ice 相關的狀態和 ice 提名機制，並結合 libnice 0.14 版本進行分析。分析乙...
mysql 導致iis 假死 IIS 假死狀態處理
iis 假死狀態處理 一 1 工作程序 分鐘 選中，值為1740 2 工作程序 請求數目 不選 原先設定為35000 3 在下列時間 工作程序 不填 4 消耗太多記憶體時 工作程序 全不選。2 3 4項可能避免了在訪問量高的時候強制 程序可能引發的伺服器響應問題，導致iis假死不響應 二 效能 只選...
狀態與狀態轉移方程
在之前的兩節中已經討論了兩類較為經典的動態規劃問題的解法，本節將對兩種演算法進行總結，並 解動態規劃問題的統一思路。回顧兩種經典問題的演算法模式，都先定義了乙個數字量，如最長遞增子串行中用dp i 表示以序列中第i個數字結尾的最長遞增子串行長度和最長公共子串行中用dp i j 表示的兩個字串中前 i...