大家都要作網紅與直播帶貨

前兩天，又 … 又 … 又 有一位大哥要來作網紅直播及帶貨平台，對於這個再 2024年大家都已經很熟悉的銷售模式來說，真的不是什麼偉大的創新及發明，不過為什麼有這麼多人要投入這塊市場，我想應該是原本的產品銷售通路或者是渠道，已經慢慢無法發揮影響力，所以才會需要來作一個平台然後將整個銷售數量提升

很多人說可以用 Youtube 就可以了阿，為什麼還要自行打造一個整合系統 ? 因為 YT 只能夠直播沒有銷售的系統，所以如果網紅要直接作拆帳或者是推廣介紹收入，目前是靠廣告及留言招攬，但是如果您的電商平台可以有一個 Refer Code 給網紅，讓他的直播串流可以直接用 QR code 下單，那這樣的話就可以有一個完整的拆帳及銷售紀錄，讓網紅或者 KOL 能夠清楚知道透過自己的推廣賣多少東西及賺多少錢

下面這個簡報，不是新鮮事，只是有客戶需求，所以我們就幫他設計規劃一下，當然有金主大哥有興趣來從作這樣的平台與系統，歡迎與我們聯絡與洽談

主機效能及連線

剛開始接觸 IPTV 的時候，大部份的服務商主機都是採用美國的實體機，單台一個月的租金都要699-799 美金，後來有降到499或者399美金，照理說一台不作編碼及重編碼的主機，應該不會佔用到太大的 CPU，主要是佔用網路及暫存的記憶體

但是通常 Linux 預設的 TCP/IP 或者是網路設定，都是在一個安全可用的情況下的設定，如果沒有調校的話，是無法發揮 1G 或者 10G 網路的效能，早在 6-7 年前美國就可以租用到 10G 網路頻寬的主機，但是通常有這樣的頻寬及主機，確發揮不出這台主機的效能，而因佌多租用的很多沒用到的主機，造成成本上面的增加

而為了解決這個坑，需要從 Linux 最底層的網路設定改起，也因為有這樣的經歷所以讓我們有了 10G 優化的網路設定，可以讓整個頻寬吃好吃滿，處了最底層的網路問題外，防火牆也需要作相關的配合與設定，既要保護主機又要兼顧效能，這樣才可以最大的連線數量

除了串流的網路底層要改外，在用戶的 API 連接及使用上，常會有很多 Session 爆滿狀況，明明就 CPU 還有，RAM 還有，頻寬還有，但是用戶就是無法登入及操作使用，這樣的問題就是 TCP/IP Session 被佔滿所造成，這個需要作調校才能讓大規模併發的系統安全運作，API 所使用的 HTTPS 主機服務也會有 Session 連滿的情況，如果依照一般的設定下去跑，保證沒幾百個客戶上線後，整個系統就會 GG 了

當然單主機的效能畢竟還是會有其極限，最後沒辦法的情況下勢必要增加主機的數量，那加了之後就要解決串流復用的問題，也就是說需要把 S1 的串流打一份到 S2 的主機上面，這樣用戶連到 S2 主機後才能夠正常收視，一般服務商的作法是把所有頻道作 Forward ，但是這樣在用戶都還沒有使用系統的情況下，輸出頻寬就佔了一大半，可以服務的連線數來說是打打折扣的，我們是採用被動出流的方式來作為整個骨幹的傳輸，然後再搭配樹狀分發的 CDN 讓串流只在需要的時候出流給需要的主機，這對於一些熱門頻道來說是很有用的，如果您有看過整個用戶的收視情況來說的話，前 10 名的頻道收視大概就佔一半的收視率，前 20 大概就佔 70% 收視率，所以要復用的就是這些大量用戶收視的頻道，而不要浪費資源在沒有用到的頻道上面

所以各位大大，想要降低營運成，想要減少跳坑的時間，直接找我們吧 !!

價格合理收費公道，點以下的連結就可以有專人為您服務

https://a-iptv.tw/price

跨國傳輸

如果你很有錢，你可用很貴的頻寬來作 IPTV 服務

整個 IPTV 的系統固定支出中最貴的就是頻寬，在台灣你可以用 1G/600M 或者 2G/1G 的頻寬來作發布，但是在一些東南亞國家，最高只有 100M 雙向，以這樣的頻寬來說能夠撐個 70-80人已經非常利害，能開的號大概也就 200-250 個

所以如果可以用頻寬成本較低的國家來服務，那就可以讓整個營運成本降的非常低，早期的艾克斯及全球看都是用美國中部的機房，更早的全視福有用到美西機房，我們之前的 Xliving 有用到美西，美東，美南三個機房來作服務，主要的考量就是頻寬成本

但是，串流的傳送需要有穩定的碼流，如果因為延遲或者掉包而造成的不同步，這是會影響客戶的使用心情，在跨國部份大部份都採用 UDP 協定來傳送，但是因為該協定沒有強制資料的完整性，所以會有釣包及棄包的問題，不過影片及聲音稍微破格及斷一下音，是不太會影響到客戶的收視

最早大家都是採用原力的傳輸來作轉源，後來改用二高的傳輸來作，兩個跨國或者是 CDN 間的轉送都是用 UDP 方式來解決，自從我們自建機房後就改用 Tvheadend 的軟體來將 DVB-T 訊號抓取後編碼，該前端管理系統是採用 HTTP 作為串流輸出，那時年紀小不懂事想說就可以用這個系統來發布，那知道遇到發布驗證的問題，最後只能將訊號採集編碼後，採用 FFmpeg 作封裝及推流到 CDN 發布系統，不過因為 Theadend 及 FFmpeg 都是採用 TCP/IP 的方式來傳送，也讓串流穩定很多掉包情況也降低很多

直到有一天海纜斷了之後，才發現串流用的優先權太低，所以會被國際機房限制頻寬，整個串流卡到一個不行，為了解決這個問題我們在跨國部份採用 SRT 的 UDP 方式傳送，這個通訊協定類似Google 的 QUIC 通訊協定，可以讓傳送有 UDP 的快速，也有 TCP 的不掉包，除此之外是很多的採集盒及編碼器都有提供 SRT 的方式作跨國或者是遠距離的傳輸

等到串流透過 SRT 送到各國或者個地區的主機群後，再由發布的主機用 RTMP 或者 HTTP 作用戶端的發布處理，這樣的機制在單 UDP 或者單 TCP 的系統中，可以改善很多問題，且穩定性提高很多，所以各位大大，想要降低營運成，想要減少跳坑的時間，直接找我們吧 !! 價格合理收費公道，點以下的連結就可以有專人為您服務

https://a-iptv.tw/price

IPTV 系統版權與費用

早期的 IPTV 服務廠商都是採用 Windows 平台來作為主要的 OS，然後採用盜版的 IPTV 串流系統，然後再採用盜版的 EPG 管理系統，最後再加上盜版的 APP，然後播送盜版的訊號內容，就這樣形成一個盜版及非法大集合，也因為剛開始的小服務商是不可能去買幾百萬的軟體授權，所以很多的地下駭客就有服務的空間與收費的機會，然而也因為這樣的惡性循環，只要你作大了之後，就會被這些牛鬼蛇神來勒索，平常可能一個月 1-2 萬人民幣，之後就會慢慢的增加上去，除非你有自己的駭客團隊，可以隨時打人家或者是保護自己

IPTV 所需要的系統版權很多，以下就列幾個一定會用到的 :

(1) 作業系統 : Windows 是用 Pre Sit 或者 Pre Connedtion 授權，所以單台只要裝了 windows 需要合法的話就要買該作業系統的版權

(2) 資料庫 : 之前大部份的 EPG 或者是串流系統都會採用 MS-SQL 或者是 MS Access 當作是本機或者是遠端的資料庫系統，但是一樣需要使用者版權

(3) 串流發布 : 以原力來說，正版的授權基本上來說台幣 50 萬起跳，除了授權費外，還會依照使用人頭數量來抽取相關費用，其他如 Binstream 及其他系統，也大多是採用這樣的授權方式

(4) APP 及播放器 : 一般網路上面的播放器除了是採用封閉通訊協定的外，大部份都需要依人頭或者是依連接數收取授權費用

(5) 節目內容版權 : 這個是除了系統版權費用外，需要支付的授權費用，大部份依 Mini Guarantee 或者是以人頭數每個月收費

(6) 國際 CND 授權使用費用 : 如果您沒有自己的雲端主機群也沒有頻寬，更沒有全球的 CDN 系統，那就需要額外租用 Akamai 的 CDN ，該服務是用流量或者使用戶算錢

(7) EPG 管理系統 : 這個部份如果不是自行開發，採用公版或者是線上租用的話，就必須要支付額外的授權使用費用

除了上面那堆一外，編碼軟體也需要額外購買授權，如果有廣告播放系統，還需要廣告編排或者是上架管理系統授權，額外如果再增加其他系統的話，就都需要額外的授權費用或者是租金費用，算一算都還沒有開使收錢，就需要一筆非常大的投資了

我們與其他廠商的作法不同，全系列系統都採用 Open Source 或者自行開發技術，除了節目內容無法取得版權外，其他所有系統的建置及使用上都不會有版權的問題發生，可以讓客戶安心的使用，我們的作法如下 :

(1) 作業系統採用 Linux 平台

(2) 資料庫採用 MariaDB 來作為主要資料儲存

(3) 串流發布採用 GPL 授權的 Open Source 系統來作修改與調整

(4)  APP 自行開發，所使用的播放器採用 GPL 授權的 Open Source 程式來使用

(5) 節目內容版權由客戶提供

(6) 國際 CDN 採用自行建置之主機及系統來完成

(7) EPG 管理系統 100% 自有技術開發設計

 所以我們可以幫客戶節省掉很多版權及租金費用，讓客戶可以在安全穩定的系統中運作，如果沒有這樣的話，在 IPTV 系統的服務上都會提心釣膽的走鋼索，以下有我們服務費用的參考，可以點選下網址查看

https://a-iptv.tw/price/

HTTPS – AES – Token

早期的 IPTV 業者真的是膽大到整個系統都沒有加密，除了 EPG 的管理都是用純 HTTP 外，連 API 的連接與資料傳送也都是用 HTTP，因為這樣，所有業者的新節目地址在第一時間改變後，駭客也在第一時間將整套的節目地址給發布到論壇，在用戶都還沒有更新節目地址前，整個節目源就已經都全部公開了

之後開使有在節目地址後面加上 Token，或者是逾期的 KEY，主要用來當節目源被盜後，該節目地址可以失效，但這跟本就無法防範已經流出去的播放地址，就連原立及 Binstream 這些專有通訊協定及專有播放器的系統，也是一樣，只要能取到地址就可以貼到播放器中直接收看節目，在這個沒有加密的年代，駭客依照這樣的方式，盜源賣源，每個都賺的盆滿砵滿的，真是一個最美好的年代

節目源要取得，相當簡單，在 HTTP 的通訊方式下，只要裝個 wireshark 然後開 APP，紀錄整個通訊的封包，那這樣大概就可以抓到所有資訊，也因為這麼的方便，所以我們可能是第一家 EPG 及 API 全面採用 HTTPS 的台灣公司，也因為要上 HTTPS，所以造成很多的服務商都確步，不進行改進與更新，因為改下去就連 APP 的通訊都要改用 HTTPS 才能夠防止網路的監聽與封包抓取

但是道高一尺魔高一丈，不能從網路監聽，那就從 APP 下手，各為看官應該也知道， 早期的 Android 都是用 JAVA 來作的，整隻 APK 其實就是一個 .zip 的打包，所以改名 .zip 然後用 7-zip 就可以把整個 apk 所有檔案給解出來，解出來後那就簡單了，有反組譯 .jar 的程式，也有反組譯 .class 的程式，各種破解工具一用，就可以知到整個 API 的地址，也可以知道整個 APP 如何與 API 溝通，然後就透過 API 把節目地址取出，順便作用或者 MAC 及 IP 的白名單登錄，噔　噔　噔　噔，就這樣你可以看免費或者讓更多人可以看免費的節目囉

我們為了解這個坑，採用了以下的處理方式 :

(1) EPG 全面 HTTPS : 防側錄及監聽

(2) API 全面 HTTPS : 防側錄及監聽

(3) API 資料採用 AES 128 加密 : 防網路直接取用無法解開內容

(4) API 採用動態 KEY 生成 : 這部份主要使將解 AES 的 KEY 動態產生，防止 API 地址外洩後，因為沒有 KEY 解不出傳送的內容, 這部份需要有一個動態的 KEY 產生系統，讓用戶每次登入後都可以取到最新的 KEY ，然後用該 KEY 加密資料後送出

(5) 節目地址採用動態 KEY 生成 : 主要在節目地址中用動態的 KEY ，來產生節目地址，這樣就可防止節目地址外洩後，讓原本的地址無法播放直接失效

(6) 串流發布需要透過動態 KEY 驗證後出流 : 這個就是一般的發布系統作不到的，比如常見的原力及Binstream 還有合法串流營運商常用的 Wowza ，都沒有可以有 Call Back API 方式來作用戶出流的驗證與限制，所以之前幫很多服務商作的黑名單 Script，白名單 Script，來從底層的防火牆封鎖，因為是 By IP 所以這個問題只要你加入白名單，就可以看免費節目了

所以，整個 IPTV 的系統要安全，只有作一小塊或者是一部份是無法達到安全保護的等級，每一個安全保護都是一個坑，每個部份都要協同運作良好才可以系統穩定，10 年了，感謝網路上面無數駭客的青睞，每每都產生另人難解的坑，但也因為有這些坑，才能讓我們好好的練兵，至於詳細的作法可以與我們聯絡，或者參考我們的報價列表，然後找到我們，讓我們幫您解決一堆你無法知道的坑

https://a-iptv.tw/price/

大家都要去柬埔寨作 IPTV

很神奇，大家不約而同的都想要到柬埔寨作 IPTV，最少有四位大哥來找過我們，並且去簡報，每個來頭都很大，都是與官方超熟不然就是直達總統，或者是電信公司投資，每個人都想在金邊沾點 IPTV 的邊，但是在柬埔寨這個地方目前頻寬還是比較大的問題，不是用戶上網的頻寬，而是 IDC 機房的頻寬，當地最大電信公司的機房服務雙向 100M 的頻寬價格大概是台灣 1G/600M 的價格，也就是說你如果用當地國內的頻寬來發布的話，那應該收的錢都不夠付網路費用，所以大部份的 IPTV 業者都是用新加坡機房將訊號送入，但是該海纜只有 10G，以一個用戶 800k – 1.5M 的頻寬需求，整箇站滿大概也就幾千戶可以用，若要服務整個金邊數百萬用戶，應該是不太可能的事

所以各位大哥，如果要進入 Combodia 作串流影音的話，請找當地的電信業者合作，且需要改用 Multicast 的方式發布傳送，不然的話上 Internet 後不管直連或者 P2P 都應該會把當地的骨幹頻寬給炸爆，到時應該就會被官方或者當地電信業者給廢了

下面這個簡報，我大概已經說了4 次了，每個都說這次不一樣，我們是金流與 IPTV 執照的最佳取得商，只要技術沒問題，拿證照是很簡單的，不過，到目前為止，都只是在簡報階段，但也不錯因為簡報吃了好幾次好料的飯，當然如果您只是想要小打小鬧的賺的零花錢，那就隨便代理一家機上盒進去賣，量不大也不會影響到當地網路

MAC 重復

你沒看錯，對，就是全球唯一的 MAC 是會重復的，而且其中有一個 02:00:00:00:00:00 重復率最高，因為之前的機上盒驗證如安博或者彩虹，金雞母，EVPAD，小七… 等，都是用 MAC 來作為 APP 及串流輸出的判斷，所以 APP 抓到的 MAC 送回給後端的 EPG 驗證後，如果有在資料庫中那就會放行出流，但是 Android 上面的系統 MAC 可以透過 APP 來假造，也就是說我只要把 MAC 設定為有開通的 MAC ，那就可以看永久免費的電視，這真是一件太神奇的一件事

早期有個卡巴熊，在其機上盒上面安裝一個可以改變 MAC 的 APP，為的就是要可以每次重新註冊後可以有 2-3 天的免費收視，對於 Cloud TV 非常有效，因為只要改個 MAC 對方的系統就認定為新的機上盒，然後就又可以看 3 天

而這個問題也造成盜源盛行防不勝防，一直到現在你還在用 MAC 當作唯一的驗證碼的話，那保證你的串流應該會被盜的很兇，因為實在太好假造了

這個問題的處理方式需要從 APP 來解決，也就是說我們改用另一種方式來產生各台設備的唯一序號，主要採用 MAC + CPU + Wifi + 主機版號 + Android 號 後再取 MD5，這樣取到的值就可以避免重復，但這樣的驗證方式會有個缺點，因為取值後的序號是存在 APP 資料區塊中，如果被移除 APP 或者是 APP 清除資料，這樣就會有被刪除的問題

也因為這樣，安博及一些市面上的機上盒開發商，都會自定義機上盒，並綁定 MAC，這樣之後當刷機或者重置就可以取得唯一的 MAC 值，但還是有被假造及取出相同 MAC 的問題

無版權謂之非法

如果你想要長長久久的穩定運營 IPTV 系統的話，請合法取得所有要播放內容的版權，如果無法取得的話，那就直接放棄作 IPTV 吧，我們看過太多的大哥，因為作盜版的 IPTV 後，機房被抄，公司被告，產品下架，大前年 2020 年最有名的就是 TvPay ，就因為部份節目內容沒有版權，硬生生的被抄，還有 Yes 5 TV，千尋，樂活 TV ，全視福，金雞母，嘉博，雲瑛，第五台 … 等，族繁不及備載，大陸的廠商更是不計其數

各位大哥及各位大老闆，請清醒一點，如果你沒有版權要怎麼在臺面上賣 ? 又要怎麼作到 30 萬戶呢 ? 這是一個很跟本的問題，為了談版權與找機上盒我花了 8 個月時間，全台跑透透，問了好幾個版權商，當你知道一個頻道一個月一個人頭的就要 4-5 元，Mini guarantee 要 5 萬戶時，你在還沒有任何客戶的狀況下一個月就要付出 20-25 萬，你有多少錢可以燒 ? 而這只是一個頻道，有些頻道的首次授權費用就要 200 萬，多少人頭再算，雖然有些包裹式的授權商可以一次 15 or 20 個頻道授權，但一個人也要 20-30 元一個月，就小算一下，120 個頻道的 IPTV，如果要合法版權的話大概要 450 元左右的授權費用，那有人問說凱擘，中嘉，北都是怎麼賺錢的 ? 他們因為戶數很多大多是採用 15% Ｍini Guarantee 的方式來付錢，比如說，板橋，蘆洲，三重，新莊有 100 萬住戶，授權費用就以 15 萬戶的錢收，看起來好像還 OK，不過那是你有 15 萬戶或者是超過 15 萬戶的情況之下，才可以降低版權費用，不然一開始就要每個月付 15 萬戶的錢

在最後還有在作 IPTV 的幾年裏，很多大哥都來找我們要作 IPTV，但是我們都以貴公司無法取得合法版權為由拒絕了，也有人硬著頭皮要作，但都是小打小鬧成不了氣候，也因為如此，你在台灣看不到有百萬用戶的 IPTV 第四台服務商，頂多就 3-4 萬戶，再大應該就會被版權商盯上，或者是電信警察直接抄了

無頻寬成不了 IPTV

在台灣如果你要作 IPTV，有解決的版權問題，再來就是頻寬了，之前千尋在台灣不過 3 萬多戶，就因為佔用電信骨幹頻寬，硬生生的 40G 頻寬被抄，所以很多大哥與老闆都說，我們只要用 P2P 就可以解決頻寬問題，但是 P2P 怎麼 P 可是一個大問題，一Ｐ下去整個網路從北到南都被炸的亂七八遭，再加上骨幹設備要處裏這些北到南或者南到北的流量，你說電信公司不把你抄了才有鬼

如果要避免因為 P2P 造成的流量亂竄，應該改用 P4P 的定向點對點傳輸，也就是說如果在台北市北區的客戶，就在該北區自己 P 起來，不要 P 到台中高雄，如果在高雄南區的客戶，就在南區自己 P 起來，不要 P 到台北市，這樣不僅可以節省骨幹頻寬，也可以達到 P2P 省頻寬的效果，如果無法達到這樣的系統，請直接使用各地 CDN，讓用戶連接到最近的主機群出流，這樣可以達到分流及不會被抄的需求

有人問說那中花電信的 MOD 為什麼可以全省收視 ? 那是因為他們不是用 Unicast 的方式來作連接，而是採用 Multicast 的廣播方式來連接，所以在骨幹的頻寬使用上來說會很節省，也可以在各地的 CDN 主機作發布, 說明如以下圖片資料 

串流防盜用

串流的保護工作除了驗證外，比你想的還要更多，一般基本的驗證不外乎就是是用戶或者 Token 的限定，但是在 Internet 上面來說是遠遠不夠的

1. 線路斷訊備用 : 在跨國服務中最常發生就是海纜有問題或者是頻寬阻塞，為了保證串流正常推用與發布，必須要有備用的訊號來源，一般我們會採用雙串流備用，或者是將各頻道交插在 4-5 路的路由主機，讓線路斷訊時不會造成所有頻道的斷訊，而也因為這樣也會造成一些成本上面的增加

2. 即時封鎖 : 在第一時間發現有異常串流輸出或者是異常連接時，就需要馬上將該 session 給斷開，並封鎖該來源 IP 及帳號，這樣可以在流量發生異常時作處理

3. 串流出流套餐驗證 : 用戶的帳號密碼是基本款，還有該用戶是否有盜用其他套餐的驗證，之前有很多大哥很喜歡作免費收視頻道，結果一堆人都用免費收視頻道的方便性通過驗證，然後因為串流沒有再作二次的套餐驗證，活生生的就全部免費了，所以在每個頻道出流前一定要作二次的套餐驗證

4. 串流出流的 IP 驗證 : 當有一個用戶在網路上面來了 10-20 個 IP 時，那就代表說你的串流被盜了，這個問題需要在串流主機上面持續紀錄來源 IP ，如果只有開放兩個設備可以用，那超過部份的 IP 就不可以出流，如果還是出流的話，就只要到網路上面公告播放地址就可以盜到訊號

5. 串流出流的用戶驗證 : 除了使用者的帳號與密碼外，用戶的唯一性要確認，不可以因為有了帳號與密碼就到處可以播放串流，那就失去保護的意義

6. 串流主機 : 因為 IPTV 的大量併發及傳輸，再 Linux 底層需要作修改，讓 TCP/IP 運作及主機運作順暢，還有驗證資料庫主機的 Cache，如果不開大的話，應該是頂不住大量的用戶使用

7. DDos : 為了保護串流主機群的安全，上 CDN 及分散多台主機及地點是必需要的，因為沒有分散的話很容意就因為單點攻擊而造成系統停服

8. 傳輸加密 : 串流的地址及帳號密碼被盜都是常見的問題，所以必須在取得資料前就將該資料加密，AES 128 是一個不錯的方式，因為需要有動態 Key 才能夠解，如果沒有的話就無法解，再加上動態的密碼，動態的 IV，這樣可以確保當節目地址流出後，第一時間失效，也不用怕到處論壇都是被盜的播放地址

9. 推流驗證 : 為保護串流主機及不被竄改的情況下，RTMP 的推流需要經過驗證保護後才能夠推流成功，不然隨便阿貓阿狗都可以在知道主機位址後就把串流打上去

10. 主機系統安全防護 : 目前全系統都採用 Linux 主機平台，主要是因為資源吃的比 Window 少，且大部份 Open Source 的程式都在在 Linux 上面運行，再加上不需要版權這一點，我們全面服務都是採用 Linux 系統，在主機上面需要作到幾點 : (1) 將不需要的服務關閉 (2) 開啟防火牆只有將需要用到的 port 打開 (3) 保持更新 (4) 使用安全的系統套件源頭更新如 epel-release (5) 給串流主機足夠的 CPU 及 RAM

11. 平行併發 : 因為大部份的 RTMP 或者是串流服務都是單一行程，如果想要服務更多客戶的話就需要將原本程式平行併發，一般我們在主機上面會啟用 10-15 個 Process 分別監聽或者是統一監廳一個使用 Port，用以擴充單一程序的不足

12. 主機連接安全限定 : 之前有遇過很多服務商，因為工程師操作完系統後忘了開啟防火牆，造成整台主機被盜用，所以應該是全部封鎖連接 IP ，然後限定可以使用的 IP ，這樣就不會有忘記的狀況發生，當然很多主機都會用 SSH Key 的方式直接登入，但是如果 KEY 被盜用的話，你的主機就謝謝再聯絡了.

13. 工程師資安教育 : 不要相信在網路上面與你聯絡的任何一個人，駭客可以透過 QQ WeChat Line … 等通訊軟體，入侵或者盜用工程師的電腦，當取得電腦控制權後，工程師所控制的所有主機將會被完全盜用，不要相信任何防毒軟體或者防木馬軟體可以保護你，都是沒用的，除非你遇到是很 Low 的駭客  

雲端串流主機群

在每一個國家的主機群，都不會是只有一台伺服器，需要由多台伺服器來組成一個 24×7 的主機服務群，特別是串流主機需要很多台來服務客戶，以免大量連線出現時客戶無法使用，當然也要避面因為單一主機有問題時需要作到的備援功能

這個坑我們可是換了很多套系統後才在 2017 年完全穩定下來，因為不是只有串流要發布，還有每個發布都要作驗證，如果沒有驗證的話，可是會讓所有人看光光，這個對於一般宗教公開頻道來說是再好不過的，但商業頻道來說可不得了，因為不僅收不到錢還會造成整個系統的 Loading 過重，影響到其他正常的用戶

在剛開始的全視福是採用 RTSP 的串流服務，所以該串流常有影音不同步的問題，再加上畫質應該只有 360P 所以整個收視體驗非常的差，改用彩虹直播後狀況改善，但是因為該串流主機是由原力的 FDBS FCCS FTDS 三個程式組成的 P2P 發布系統，整個就是一個沒保護，只要有原力的播方器知道地址就可以順利的播放出來，你說這樣要如何保護串流呢 ?

後來為了改善以上的缺點我們改用了 RTMP 的串流服務，雖然是一個 Flash 時代的古老串流，但是穩定度確非常的好，特別是在目前的所有雲端串流服務商都有支援其推流，且因為他是採用直連方式收視，所以我們只要在客戶連到串流主機上面作驗證就可以了

 目前如果有需要作串流服務的客戶或者是廠商，可以採用我們的雲端主機服務，該服務可以在客戶沒有主機沒有頻寬的情況下，作內容的發布與串流