前言：
極光短信屬於極光推送的一塊業務，極光短信最大的優勢是針對推送消息未送達的用戶進行補發短信，既保證消息觸達又節省成本，以及認證短信或者其他業務場景都需要用到短信功能。
極光短信業務最底層是真實對對接運營商，使用的cmpp協議發送短信，而在測試環境中， 不可能對真實環境來驗證短信功能，原因：
1.測試需要發送大量的短信，費用會很高
2.需要模擬各種異常的消息 ，真實運營商有很多規則才能觸發異常
3.需要對運營商快速返回各種錯誤，真實運營商可能會延遲，不利於測試
4.還需要針對大量數據時進行限速設置等各種場景
所以針對以上4點的考慮，最終我們選擇自己“創建”一個運營商來處理數據客戶端發來的數據，滿足日常的短信業務測試
在模擬之前，我們需要對運營商使用的底層協議，交互方式，數據處理方式進行確認，才能更好的建立一個自己的“運營商”。
術語解釋
1.認識cmpp協議
1.1網絡結構
如圖1所示，互聯網短信網關（ISMG）是外部信息資源站實體（SP）與移動網內短信中心之間的中介實體，互聯網短信網關一方面負責接收SP發送給移動用戶的信息和提交給短信中心。另一方面，移動用戶點播SP業務的信息將由短信中心通過互聯網短信網關發給SP。
1.2 CMPP功能概述
以下內容來自cmpp2.0文檔的的介紹
短信接收（Short Message Mobile Terminated，SM MT） 典型的業務操作舉例如圖3所示：
圖3 需要前轉的MT示意圖
1.SP發出數據請求（可能是短信通知或手機鈴聲等），被源ISMG接收；
2.源ISMG對接收到的信息返回響應；
3.源ISMG在本地數據庫中找不到手機號段所對應網關代碼，向GNS（匯接網關）發路由請求信息；
4.匯接網關將路由信息返回；
5.源ISMG根據路由信息將請求轉給目的ISMG；
6.目的ISMG對接收到的信息返回響應；
7.目的ISMG將請求信息發送至SMC；
8.SMC向目的ISMG返回響應；
2.協議棧
CMPP協議以TCP/IP作爲底層通信承載，具體結構由圖2所示：
圖 2.1CMPP協議棧
ICP與ISMG以Clientmdash;Server方式建立TCP連接，用於雙方信息的相互提交。TCP/IP連接建立後，由Client發起建立應用層的連接，這時如果ICP或ISMG認爲需要建立TLS連接，則在傳輸的數據包中置TLS字段，從而在雙方建立TLS連接。
在應用層連接建立後的數據傳輸過程中，如果ICP或ISMG需要向對端發送加密信息，也可建立TLS連接，這時只需要置相應的消息體中Tls_available（是否使用TLS層）屬性字段， 本條消息的消息體中的其他屬性不發送。
消息採用併發方式發送，加以滑動窗口流量控制，即接收方在應答前一次收到的消息多於窗口大小條將予以拒絕。流程圖如圖3所示：
2.1.消息定義
消息定義是客戶端與服務端之間“溝通的方式” 以下是cmpp協議內容的定義 （其中的一個鑑權協議）
基本數據類型
消息結構
消息頭格式（Message Header）
CMPP_CONNECT消息定義（SPàISMG）
CMPP_CONNECT消息定義
CMPP_CONNECT_RESP消息定義（ISMG à SP）
3.構建服務端
3.1短信測試樁架構分析
業務處理流程。如圖3.2所示
圖3.2
處理流程說明
1.服務端收到一條爲39個字節的長度的請求數據，由於頭部固定爲12字節，剩餘爲27個字節
2.根據以上的協議27個字節長度判斷是需要建立連接
3.獲取客戶端的連接的用戶名與密碼，解析AuthenticatorISMG字段驗證是否鑑權成功
4.成功進行下一步操作 （需要回應 鑑權成功），在根據建立的連接後，對獲取的數據進行處理，返回內容
我們以鑑權部分提取它的主要代碼： 取出頭部數據包
獲取主體內容，鑑權內容
日誌展示
3.2效果展示
短信測試樁目前已在測試環境中運行了2年多，幫助公司節省了一大筆測試費用，以下是它展示的效果內容
在iportal上展示，發送成功狀態。
在iportal上展示，發送失敗狀態。
在iportal上展示，已發送的狀態。
Iportal上展示，餘額不足的狀態
3.3短信模擬樁遇到的問題
1.發送的請求數據量已經超過窗口大小
當客戶端發送的數量超過了大小處理大小，服務端進行限流，讓任務進行排隊處理並對它返回響應的code，以減輕服務端壓力
2.代碼建立無效的鏈接，浪費資源
建立一個連接，就存儲一個連接，當無效鏈接時，需要刪除連接，如何判定無效，心跳連接不在建立，或建立連接後，20分鐘內都沒有發送消息（測試環境），服務端對斷鏈進行處理
3.語言的選項，以及方案設計
可選擇java以及Python語言都可以，考慮Python在公司的使用程度較高，選擇Python
選擇Python的類有struct模塊，用戶解析字節數據，使用gevent來解決協程，或者是Python提供的多進程
4.消息粘包
讀取數據時，根據頭部的長度信息，按序讀取ioArgs緩衝區中的數據，若沒有達到長度要求，繼續讀下一個ioArgs解決粘包、半包問題。
我們逐步完善測試樁，它不僅具有解析數據的功能，發送報告，保持心跳、處理不同錯誤code，我們也提升了處理速度，以前是1分鐘處理10個，現在1分鐘能處理300個，滿足我們大批量數據速度的一個提升，完善了我們各種場景的測試。