4.1流媒體分發
在流媒體分發中，通常對flv的支持會更好。原因是flv根據文件偏移量執行快進和快退。 mp4編碼會隨著時間的推移而快進和快退。一些CDN供應商可能不正確支持mp4，或者可能根本不支持mp4。但是，flv通常可以直接應用。實際上，flv格式是由播放器計算的，這降低了分發伺服器的技術要求。這裡的困難主要是由作為上述來源的返回模塊的複雜性引起的。如果需要進一步處理索引，則程序級別將變得更加複雜。
另外，如果分布式流媒體的容量相對較大，建議主動拆分文件（小於100MB）。這樣，您可以對某些配置錯誤的伺服器進行一些優化。例如，在沒有陣列或陣列卡損壞的系統上，避免將大文件放在單個磁碟上，以便最大程度地從多個磁碟讀取文件，從而有效地提高了吞吐量。
前端SDK應該能夠收集數據，例如啟動客戶端IP，連接到伺服器IP，解析伺服器IP時間開銷。連接到伺服器IP的時間成本，第一個數據包的時間成本以及數據中斷率。伺服器返回狀態值，數據傳輸時間等。因為整個網絡中都有一些「代理伺服器」，所以某些請求永遠不會到達伺服器，或者該請求已被修改。將日誌放在前端和後端一起可以使分析更好，更清晰，從而可以改進方法並改善用戶體驗。數據是系統演進的重要組成部分。
必須考慮反延伸鏈的設計。在不嚴重影響客戶端和伺服器端性能的情況下，打破熱鏈規則的難度應儘可能高。引薦來源網址很容易偽造，但可以用作過濾請求的第一道防線。它通過複雜的規則增加了熱連結的成本。分析前端和後端日誌以了解流量消耗，並根據需要定期修改防盜鏈算法。
4.2應用程式分布
當前正在部署許多行動應用程式，並且許多應用程式面臨連結劫持的問題。如果您面臨DNS劫持，則基本上只能使用HttpDns之類的第三方解決方案。如前所述，如果您的http層由「代理伺服器」緩存，則可以通過構造動態URL來配置緩存。對於http劫持，您可以參考參考信息中的連結。原則上，了解問題的性質後，您會發現某些方法更具針對性，但有些方法不容易解決。發現問題後，您可以儘快提出投訴。因此，每個人都可以通過查看我稍後提供的參考連結來學習如何找到各種千斤頂。4.3在Linux上優化Nginx的性能
與CDN系統相比，伺服器程序主要使用系統的網絡IO和磁碟IO。對於較小的請求（從幾千字節到幾十千字節），所測量的關鍵指標將更多地關注於每秒可以響應的請求數。由於請求的文件很小，因此nginx對小文件進行了很多優化。例如，sendfile函數可以避免將文件讀取到內存中（由系統緩存到用戶內存中，然後傳遞給系統以用於網絡接口），並使作業系統內核直接發送文件。當然，此功能也有其缺點。換句話說，如果文件太大，則帶寬將被請求佔用，因此nginx具有內部限制來防止這種情況。相對較大的請求通常更加關注磁碟IO和內存優化。對於大請求，nginx使用固定長度的緩衝區來減少用於每個請求的網絡和磁碟IO。這樣，您可以更公平地將有限的IO分配給多個請求，並且浪費不均。
Nginx本身由事件模型驅動，並且在多個進程中，在正常情況下，每個進程只有一個線程。但是，使用事件模型，即使是一個線程也可以響應數千個請求。
當nginx在Linux機器上運行時，服務文件的存儲空間遠遠大於機器內存，並且如果這些文件是熱文件，則連接到nginx伺服器可能會導致連接超時或慢速連結設置問題。
必須從兩個方面解決這個問題。 Linux文件訪問操作分為兩類。
一種使用作業系統的虛擬存儲來緩存熱文件，這可以加快磁碟訪問速度。接口的另一種類型稱為直接訪問模式，繞過作業系統緩存並將文件直接加載到用戶進程存儲空間中。 Linux上的第一類訪問模式不支持「異步操作」，即不兼容的事件模式。第二種訪問模式與「異步操作」兼容，但是該接口不友好，因為沒有用於磁碟緩存的作業系統。第二種類型主要是沒有高速緩存管理，這會大大降低系統性能。在Linux上，nginx始終將第一種訪問模式投入運行。 Nginx的設計目標是為多個流程提供更好的穩定性，並減少流程之間的交互。使用第二種模式會增加複雜性，並會導致進程之間的交互受到更多的阻止（考慮到對數據緩存機制的支持）。這意味著，如果無法將請求的資源放入系統的內存中，則事件模型將被文件操作中止，並且無法正常響應連接。在nginx 1.7.12及更高版本1.8中，nginx引入了線程池來緩解上述問題。當主線程決定啟動文件系統操作時，它將創建一個特殊作業並刪除工作隊列中的作業。線程池中的線程繼續在隊列中執行文件操作，然後將執行的結果放入返回隊列中，主線程繼續進行後續操作。通過此操作，主線程不再被阻塞，因此連接建立不會中斷。
但是，如果IO嚴重不足，則請求時間可能仍然很長，或者客戶端請求可能會超時。在這種情況下，您可以執行其他優化，例如磁碟調度算法，文件存儲結構優化和存儲升級。上一篇文章說，nginx使用線程池性能提高了9倍，這實際上是Linux上的性能問題。這個問題在FreeBSD系統上不存在，因為FreeBSD系統上的異步IO支持使用內存作為文件緩存。
不支持Linux的原因是因為社區辯論。而不是系統本身的功能。
4.4如何降低成本
CDN的價格不是特別透明，知名製造商通常會與銷售商協商。而且，根據流量的不同會有一些折扣。但是，CDN在市場上的價格基本上可以考慮如下：
文件的價格小於流媒體的價格，大於下載的價格。
直播價格也將高於點播流媒體價格。
如果籤訂的價格合同基於標準峰值帶寬+ 95計費方法，那麼降低峰值通常是常用的方法。但是，根據您的特定使用情況，您需要執行峰去除。例如，以下情況可能不適用或可能屬於峰去除。我們緊急發布一個修復嚴重錯誤或安全漏洞的版本。這時，可能會提示用戶儘快升級。很高的山峰。開展新業務時，您的舊流量並沒有發生明顯變化，並且在一些熱門時期創造了新的高峰。大規模的黑客攻擊創造了額外的流量並帶來了新的高峰。峰值消除方法是交錯請求以避免同時請求。以下方案更適合去除峰。我們將發布非關鍵升級，並期望用戶逐步過渡。要減少最大值，可以限制通知升級用戶的數量。針對不健康流量的自動日誌分析具有自動應變計劃，例如自動拒絕某些請求。
4.5包含SDK對客戶的影響
實際上，類似於HttpDns或p2p加速，此處的sdks是代碼安全性問題，由於大小，穩定性問題，集成額外成本（小型客戶沒有人力或能力），需求等導致的CDN成本增加。您將面對此事。它是否真的存在（小客戶可能沒有能力考慮它）。這也是SDK解決方案通常難以推廣的問題。開源SDK可以大大減少客戶對代碼安全性的擔憂，但是成本和集成成本並不容易解決。5. P2P穿牆打孔
讓我們從Internet添加臨時補充內容。幫助所有人簡要了解P2P的核心技術並突破壁壘。
通常，P2P是多對多傳輸，但實際上可以分為:控制部分和傳輸部分，P2P網絡需要一些服務節點來交換信息並協調鑽孔。當然，這些服務節點通常還具有查詢資源位置和相關節點的能力。與傳輸部分相關的對象分為兩類：可直接訪問的對象和隱藏在NAT後面的對象。只要一個或多個參與方可以直接訪問，控制部分就可以用來建立傳輸通道，而無需鑽孔。如果兩個實體都隱藏在NAT之後，則會發生打孔問題。
所謂的打孔實際上是指當NAT的內部伺服器連接到外部實體時，隱藏在NAT伺服器中的「臨時」映射關係。這樣，NAT伺服器可以將數據包從外部網絡正確發送到內部實體。
在P2P鑽孔過程中，每個實體必須主動連接到P2P網絡中的伺服器，並向伺服器報告其自己的外部網絡IP和鑽探的「臨時」埠。這樣，伺服器可以將實體的資源信息和網絡信息存儲在一起，並為後續的連接請求提供輸入參數。
當實體A準備好連接到實體B時，您要做的就是通過P2P網絡上的伺服器獲取連接信息並直接連接。這是因為先前已設置了「臨時」孔。
實際上，還有一些其他要求。
每個實體都必須像P2P網絡伺服器一樣定期發送心跳。心跳是為了確保打孔的「臨時」埠不會被擦除。
NAT伺服器是圓錐型伺服器。這意味著從外部主機發送到該埠的任何信息都可以傳遞到打孔主機。這種類型的NAT伺服器在大多數情況下都可以解決。
如果NAT打孔失敗，最好放棄或切換到伺服器轉發模式。
上面是一個相對簡單的UDP打孔，TCP也可以在牆上打孔，但是比較複雜。國內製造商有很多在牆上鑽孔的專家，簡單的算法無法解決複雜的家庭Internet環境中的許多詳細問題。 「高速通道」中的P2P傳輸效果非常好，因為這些製造商已經在該領域工作了很長時間。