1、筆者在前面的講座中也提到過，兩個開源平臺的技術架構基本上是完全一致的，但是可能在解釋上可能有所不同。今天，我們分別對各自的架構做一個說明。這里，我們首先介紹Kamailio 技術架構。根據(jù)以下圖例我們可以看到，Kamailio的核心的架構包括九大部分。它們分別是：
- SIP Parser 負責解析SIP消息內容。
- SIP Transport Layer 負責收發(fā)UDP，SCTP，TUP和TLS加密。
- Configuration file Interpreter負責處理各種配置文件，并且在runtime執(zhí)行。
- Variabels Framework是一個API接口負責處理系統(tǒng)偽變量，選擇和轉譯功能。
- Locking Manager負責對內部資源的同步管理。
- DNS Resolver負責執(zhí)行DNS查詢和對結果進行緩存處理。
- Control Interface API是一個API接口負責處理系統(tǒng)的控制命令。
- Memory Manager負責對private和shared 內存進行管理。
- Modules Interface 是一個API接口，負責加載模塊和導入已導出參數(shù)和函數(shù)。
2、OpenSIPS 核心模塊介紹和kamailio模塊基本上是一樣架構。只是模塊的命名稍微有差異。
筆者會根據(jù)Kamailio的命名來進一步介紹各個模塊的具體功能。
3、因為兩個軟交換的架構基本一致，所以我們這里我們重點介紹一下Kamailio的九大模塊的基本功能：
- SIP Parser解析器。Kamailio有自己的解析器，其主要作用是支持SIP proxy的解析需要。和一些SIP終端的解析器相比，它可以同時處理上千個transactions和dialogcs，而一般終端只能同時處理幾個dialogcs。另外，解析器可以僅處理它本身需要的消息內容，無需全部解析，同時對解析的消息進行緩存處理。解析器可以對SIP消息體中的消息頭和body解析解析并且根據(jù)需要對部分信息進行刪除添加等功能。
- Memory Manager內存管理器。Kamailio有自己的內存管理工具對其進程進行管理。因為Kamailio是基于多進程設計的平臺，它本身的同步管理管理比較簡單。有時，為了配合第三方的軟件平臺，系統(tǒng)又需要共享內存的支持。Kamailio的內存管理器可以按照不同的內存需求來靈活調整內存大小。啟動時附加不同的內存參數(shù)設置來實現(xiàn)共享內存和私有內存的配置。啟動命令設置時用戶需要根據(jù)內存命令來設置。例如，kamailio -m 521 -M 8 表示 使用的是512M的共享內存，使用 8M的私有內存。這里，讀者一定要注意大小寫的區(qū)別。M表示設置的是私有內存，m表示設置的是共享內存。另外，配置的變量存儲在共享內存還是私有內存完全取于變量類型。大部分情況下，一般的SIP屬性參數(shù)保存在私有內存（$ru,$fu,$dbr等），一些avp變量/shv變量則保存在共享內存。但是明確一點，如果當正在處理一個SIP請求時，想保存此變量值用于處理相應的響應時，則必須使用共享內存變量。
Locking manager 制鎖管理。通過API支持互斥管理和內存范圍管理。因為有時系統(tǒng)同時使用一個變量時，我們需要更新一個變量時，如果不先鎖定此變量，就不可能對其進行同步更新，因為可能同時有其他進程正在使用此變量。此管理器的目的就是通過先鎖定變量，更新此變量后，然后再其變量進行解鎖操作。例如：
- lock（“x”）；// 鎖定變量x
- $shv（）=$shv（x）+5 // 使用共享內存保存更新后的變量
- unlock（）; // 解鎖操作
Transport layer 傳輸層管理。此模塊支持IPv4和IPv6，支持的傳輸方式包括UDP，TCP，TLS和SCTP。傳輸方式完全取決于用戶的配置文件設置，軟交換本身可以同時支持UDP和TCP傳輸。SCTP協(xié)議設計目的是專門針對SIP技術架構的，但是目前使用的場景比較少，所以也沒有大規(guī)模商用。
Configuration File Interpreter 配置文件解析器。從字面意思我們就可以知道，此接口負責處理對軟交換配置文件的解析。軟交換配置文件是一個文本配置文件，它主要包括三個部分的配置：全局變量設置自定義變量和預處理的文件，模塊名稱和參數(shù)設置和路由管理設置負責SIP路由管理。在軟交換啟動時，系統(tǒng)會加載經(jīng)過優(yōu)化的配置文件存儲在內存中，以便在runtime時使用。解析器會編譯正則表達式，檢測靜態(tài)變量，檢測條件語句判斷，重構路由和子路由路徑結構，在runtime環(huán)境中添加各種函數(shù)的變量值。
Variabels Framework 接口對變量進行處理。軟交換本身支持了很多種變量，而且因為以前項目的繼承和兼容性的問題，導致現(xiàn)在的支持兩種變量：pseudo-variables（來自于OpenSER/Kamailio，使用$開始變量標注） 和selects（來自于SER，使用@開始變量標注）。關于具體每個變量的學習，大家可以查閱兩個軟交換的官方文檔。
DNS Reslover 負責軟交換的DNS查詢處理。目前軟交換支持的DNS類型包括：A（IPv4），AAAA（IPv6），CNAME別名查詢，SRV查詢（服務器主機和端口），NAPTR（傳輸方式，服務地址和端口），TXT（服務器獲取的任意數(shù)據(jù)內容）。軟交換的DNS模塊可以支持基于DNS SRV結果的均衡負載處理和基于DNS記錄的黑名單管理。
Control Interface 接口負責提供兩種對軟交換進行控制的接口命令，這兩個接口包括RPC接口（SER開發(fā)），MI管理接口（Openser/Kamailio開發(fā)而來）。兩種接口都提供同樣的功能-對軟交換通過人工命令進行互動管理，例如獲取內存內容，后臺加載數(shù)據(jù)，在運行時修改一些這些命令，發(fā)送SIP消息等功能。
Modules Interface 此核心模塊負責加載系統(tǒng)執(zhí)行時需要的相關模塊和其模塊的傳遞參數(shù)，并且導入負責導入以導出的函數(shù)參數(shù)等數(shù)值。此模塊是軟交換非常重要的核心模塊，所有的軟交換認證模塊，數(shù)據(jù)庫對接模塊，其他定位服務，路由等都需要相應的模塊提前加載才能執(zhí)行。這個模塊接口對于一個非常龐大的模塊數(shù)量，用戶可以到官方網(wǎng)站查閱對應的模塊使用說明。
4、前面我們提到過，Kamailio是一個多進程的軟交換平臺，進程數(shù)量是一個變量，數(shù)量的多少取決于配置文件的設置。對于每個Kamailio的實例來說，每個進程都有其特別的功能角色。它們包括以下多種進程維護功能：
主進程維護功能：進程啟動，監(jiān)控解析文件配置，設置創(chuàng)建環(huán)境變量，創(chuàng)建SIP worker 進程和定時器。
TCP 維護進程：管理TCP worker 和連接的過程。
SIP TCP 接收方：處理通過TCP收到的數(shù)據(jù)過程。
SIP UDP 接收方：處理通過UDP端口的數(shù)據(jù)。
SIP SCTP 接收方：處理通過SCTP傳輸?shù)臄?shù)據(jù)。
Control Interface Receiver：負責處理MI/RPC 命令的數(shù)據(jù)交互，它們可能是FIFO，TCP/UDP/UNIXSOCK或者XML，RPC 接收方數(shù)據(jù)。
定時器進程：此進程處理正在運行的周期性的任務，可能是core 模塊或其他模塊調用的。定時器進程可能是Core 定時器（main timers和slow times）和自定義的定時器包括NAT ping 定時器（發(fā)送保持NAT 存活數(shù)據(jù)包）和rtimer定時器，在定時器內執(zhí)行執(zhí)行一個配置文件的路由設置。
Modue specific wokers：此進程是通過啟動各種模塊執(zhí)行具體的任務，例如異步處理等。
5、這里我們特別討論一下關于子進程對系統(tǒng)性能的影響（children和tcp_children）。通過以上的介紹，我們知道軟交換配置中的參數(shù)配置可以影響到子進程（默認設置會產生8個進程-默認children=4，兩個UDP socket）數(shù)量的實現(xiàn)，這些進程數(shù)量的多少會直接影響系統(tǒng)的執(zhí)行性能。這些參數(shù)決定著SIP worker的進程數(shù)量。因此我們必須注意，所有進程都是在啟動時創(chuàng)建，啟動以后，在運行環(huán)境中，不能再次創(chuàng)建進程或者結束結束進程。
可能有讀者問，進程數(shù)量到底多少是合適的？不幸的是，沒有一個完整的公式可以計算出一個運行環(huán)境中究竟需要多少進程，這都完全取決于配置文件的復雜程度和腳本邏輯的復雜程度。當然，創(chuàng)建的進程越多，則需要更多的并行處理機制來處理數(shù)據(jù)流量。但是，如果創(chuàng)建了太多的進程則會導致系統(tǒng)性能下降。很多的進程處理的切換需要系統(tǒng)時間，內部同步和制鎖都需要時間處理。因此，讀者需要在系統(tǒng)進程數(shù)量和系統(tǒng)穩(wěn)定性上做一個平衡。
在配置文件的路由邏輯腳本中，很多的邏輯運算是依賴于CPU IO操作和計算能力。例如，基本上無IO操作的DNS，數(shù)據(jù)庫簡單操作和HTTP等。相對比較消耗IO操作的大量頻繁的數(shù)據(jù)庫查詢命令，DNS 查詢等。如果沒有涉及太多的IO操作的進程，系統(tǒng)的默認進程設置基本上可以滿足這些要求；如果是大量的IO操作的進程，需要用戶創(chuàng)建更多的進程來保證運行的穩(wěn)定性。如果涉及到太多的寫入操作或者數(shù)據(jù)庫連接等邏輯，用戶也要考慮數(shù)據(jù)庫的連接問題。
用戶可以通過每個SIP消息對IO操作的平均數(shù)和IO操作的平均時間來大致估算所需進程數(shù)量。大部分的軟交換用戶可能沒有注意到children參數(shù)具體的細節(jié)，其實，這些參數(shù)的設置一開始就已經(jīng)限定了系統(tǒng)的性能，有一些開發(fā)人員僅是一味地強調CPU性能和內存大小。讀者可以查看cfg中的全局變量參數(shù)fork，children和tcp_children來進行配置。另外，如果系統(tǒng)確實確認不需要某些傳輸協(xié)議的話，可以通過配置文件來關閉這些傳輸協(xié)議。但是，一定要注意，UDP是不能關閉的，它總是處于開啟狀態(tài)。
硬件服務器的CPU，網(wǎng)卡都是直接影響CPU性能的重要指標，另外硬件中斷（CPU，網(wǎng)卡，硬盤，語音卡）的優(yōu)先級同樣影響服務器的性能。優(yōu)先級高的中斷可以優(yōu)先運行執(zhí)行某些進程，優(yōu)先級低的中斷則可能稍后執(zhí)行。如果把網(wǎng)卡的優(yōu)先級設置的比較低，則可能直接影響軟交換對SIP數(shù)據(jù)的處理和鎖切換時間。用戶可能需要一些系統(tǒng)工具來嘗試調整所需要的優(yōu)先級（irqblance）。
Italo Dacosta和他的團隊的軟交換（OpenSER）性能研究中也明確了關于數(shù)據(jù)庫和進程數(shù)量影響軟交換性能的測試數(shù)據(jù)。讀者可以根據(jù)參考鏈接做進一步的研究。
6、在本章節(jié)的討論中，筆者和大家分享了Kamailio九大核心接口的主要功能和各自負責的任務處理，另外，也介紹了系統(tǒng)創(chuàng)建的主要進程和各個進程對特定任務的處理。為了幫助讀者能夠掌握軟交換穩(wěn)定性的配置問題，筆者也重點介紹了進程數(shù)量的設置，CPU（核數(shù)量）或IO操作的影響和硬件服務器的CPU，網(wǎng)卡以及相應中斷的優(yōu)先級問題。最后，筆者和大家分享了國外一位研究人員對OpenSER的性能測試數(shù)據(jù)，讀者可以根據(jù)這些測試環(huán)境來進一步掌握本章節(jié)的重點內容。
參考資料：
http://blog.csrpswitch.com/tuning-kamailio-for-high-throughput-and-performance/
Italo Dacosta， Improving Authentication Performance of Distributed SIP Proxies
關注微信公眾號：asterisk-cn，獲得有價值的行業(yè)分享。訪問5060社區(qū)-開源IPPBX論壇獲得技術幫助：www.ippbx.org.cn/www.hiastar.com
