工作上雖然和cdn沒關系但是技術方向還是很多相似之處的，例如：負載均衡，緩存，分布式，路由等。
cdn簡單的說就是個復雜的大緩存，由于目標用戶（包括源和端）廣泛直接導致了其復雜性，遍布廣節點多則需要分流負載甚至自組織，應用繁雜則需要分流路由，提速則需要緩存，穩定則需要監控調度，為了透明則需要各種映射。
由于接入面廣和網絡的復雜性，不可能讓客戶端直接面對源，于是就有了專門接入客戶端的邊緣服務器/組，這些邊緣服務器和后端的調度，監控，源服務器通訊。既然是緩存就涉及到數據一致性的問題，最簡單的就是各接入端的邊緣服務器在需要的時候到后臺拉取，或者更智能的他們之間可以相互拉取，甚至后臺調度提前推送。
邊緣接收到請求后首當其沖的問題就是對請求的內容 “去哪找”和“怎么去”，想要知道內容的位置，一般緩存的實現不外乎就是統一到一個目錄服務器找，或者廣播所有自己知道的節點問一圈，更高效的方法是將請求url哈希后直接找到目的地址，當然只要是緩存都會過期也就有TTL的概念。“怎么去”的方式多種多樣，由于互聯網web服務居多基于DNS的路由使用最廣泛，缺點是客戶端和中繼點會緩存，更新需要一定時間。HTTP重定向，URL改寫，也有直接在網絡設備路由器上做，直接在路由表中保持路徑。這些方法在cdn這個龐雜的系統中根據需要使用，例如邊緣服務器為了接收到客戶端的請求可以使用dns重定向，然后再用哈希或者url改寫轉發到后端的源。
現如今的網絡內容有許多是動態生成的，對這些無法提前緩存的內容可以直接略過只存靜態內容（分段緩存），組裝的時候發送回客戶端或者直接賦予邊緣服務器生成動態內容的能力（邊緣計算）當然這對網頁的制作有規范。
面向大眾的服務都有潮汐效應，在熱點時段的訪問量是平時的幾十上百倍（根據二八理論，80%的問題都是在20%的地方出現的，熱點訪問量也是大多訪問小部分數據，如果能提前將熱點緩存于各邊緣服務器最直接有效），如果有自適應的動態調整功能整個服務會健壯很多。邊緣服務器是離用戶最近的，可以將每個節點看成組，組長監控負載自適應的添加刪除組員（緩存服務器）以及更新dns，不允許組員跨組拉數據。當然如果客戶端之間可以使用P2P相互取數據也是一個辦法。
當前出現了基于流媒體的cdn，視頻內容分發在后端以文件的形式傳輸（適合傳輸的格式更高效），到邊緣服務器再以流的形式和客戶端傳輸（不需要全部傳完即可開始播放）。同時也要綜合考慮時段需求，視頻編碼策略也很重要。