數據推送方法及裝置與流程

本發明涉及網絡通信技術領域，尤其涉及一種數據推送方法及裝置。

背景技術：

目前，以CDN(Content Delivery Network，內容分發網絡)為主的網絡加速技術已應用于國內外各大運營商。以CDN為例，通過在網絡各處設置CDN節點以在現有互聯網的基礎上構成一層智能虛擬網絡，CDN節點接收到用戶終端的請求后向源站回源，存儲用戶終端訪問的數據，其他用戶終端繼續訪問該數據時，由已經存儲數據的CDN節點直接提供服務。然而，源站的響應有很多是重定向URL，CDN節點存儲重定向URL后，用戶終端需要根據重定向URL繼續訪問數據內容，有些數據甚至需要多次重定向跳轉，導致用戶終端需要較長時間才能獲取到目標數據內容，現有技術中，存在用戶終端獲取數據效率較低的問題。

技術實現要素：

本發明的主要目的在于提供一種數據推送方法及裝置，旨在提高用戶終端獲取數據的效率。

為實現上述目的，本發明提供一種數據推送方法，所述數據推送方法包括：

在接收到用戶終端發送的業務請求時，內容分發網絡CDN節點判斷當前是否存儲有所述業務請求指向的業務數據；

在當前未存儲有所述業務請求指向的業務數據，且所述業務請求指向的業務數據攜帶有重定向統一數據定位符URL時，所述CDN節點基于所述重定向URL獲取未攜帶重定向URL的業務數據；

所述CDN節點將所述未攜帶重定向URL的業務數據存儲為所述業務請求指向的業務數據，并將所述未攜帶重定向URL的業務數據發送至所述用戶 終端；

在當前存儲有所述業務請求指向的業務數據時，所述CDN節點直接將所述業務請求指向的業務數據發送至所述用戶終端。

優選地，所述CDN節點直接將所述業務請求指向的業務數據發送至所述用戶終端的步驟之前，還包括：

在當前存儲有所述業務請求指向的業務數據時，所述CDN節點判斷所述業務請求指向的業務數據是否攜帶有重定向URL；

在所述業務請求指向的業務數據未攜帶有重定向URL時，執行所述CDN節點直接將所述業務請求指向的業務數據發送至所述用戶終端的步驟；

所述判斷所述業務請求指向的業務數據是否攜帶有重定向URL的步驟之后，所述數據推送方法還包括步驟：

在所述業務請求指向的業務數據攜帶有重定向URL時，所述CDN節點基于所述重定向URL獲取未攜帶重定向URL的業務數據；

所述CDN節點采用未攜帶重定向URL的業務數據更新所述業務請求指向的業務數據，并將未攜帶重定向URL的業務數據發送至所述用戶終端

優選地，所述業務請求指向的業務數據攜帶有HTTP狀態碼，所述CDN節點判斷所述業務請求指向的業務數據是否攜帶有重定向URL的步驟包括：

所述CDN節點判斷所述業務請求指向的業務數據所攜帶的HTTP狀態碼是否與預設HTTP狀態碼一致，其中，當所述HTTP狀態碼與預設HTTP狀態碼一致時，所述業務請求指向的業務數據攜帶有重定向URL。

優選地，當所述業務請求指向的業務數據的類型為網頁數據時，所述CDN節點發送所述業務請求指向的業務數據的步驟之前，還包括：

所述CDN節點判斷所述業務請求指向的業務數據所采用的編碼方式是否與所述用戶終端采用的編碼方式相同；

在所述業務請求指向的業務數據所采用的編碼方式與所述用戶終端采用的編碼方式相同時，執行所述CDN節點發送所述業務請求指向的業務數據的步驟。

優選地，所述CDN節點判斷所述業務請求指向的業務數據所采用的編碼方式是否與所述用戶終端采用的編碼方式相同的步驟之后，還包括：

在所述業務請求指向的業務數據所采用的編碼方式與所述用戶終端采用 的編碼方式不同時，所述CDN節點采用所述用戶終端的編碼方式對所述業務請求指向的業務數據進行重編碼，并將重編碼后的業務數據發送至所述用戶終端。

此外，為實現上述目的，本發明還提供了一種數據推送裝置，所述數據推送裝置包括：

第一判斷模塊，用于當其所在內容分發網絡CDN節點接收到用戶終端發送的業務請求時，判斷所述CDN節點當前是否存儲有所述業務請求指向的業務數據；

獲取模塊，用于在所述CDN節點當前未存儲有所述業務請求指向的業務數據，且所述業務請求指向的業務數據攜帶有重定向統一數據定位符URL時，基于所述重定向URL獲取未攜帶重定向URL的業務數據；

發送模塊，用于將所述未攜帶重定向URL的業務數據存儲為所述業務請求指向的業務數據，并將所述未攜帶重定向URL的業務數據發送至所述用戶終端；

所述發送模塊還用于在所述CDN節點當前存儲有所述業務請求指向的業務數據時，直接將所述業務請求指向的業務數據發送至所述用戶終端。

優選地，所述數據推送裝置還包括第二判斷模塊，用于在所述CDN節點當前存儲有所述業務請求指向的業務數據時，判斷所述業務請求指向的業務數據是否攜帶有重定向URL；

所述發送模塊還用于在所述業務請求指向的業務數據未攜帶有重定向URL時，直接將所述業務請求指向的業務數據發送至所述用戶終端；

所述獲取模塊還用于在所述業務請求指向的業務數據攜帶有重定向URL時，基于所述重定向URL獲取未攜帶重定向URL的業務數據；

所述發送模塊還用于采用未攜帶重定向URL的業務數據更新所述業務請求指向的業務數據，并將未攜帶重定向URL的業務數據發送至所述用戶終端。

優選地，所述業務請求指向的業務數據攜帶有HTTP狀態碼，所述第二判斷模塊還用于判斷所述業務請求指向的業務數據所攜帶的HTTP狀態碼是否與預設HTTP狀態碼一致，其中，當所述HTTP狀態碼與預設HTTP狀態 碼一致時，所述業務請求指向的業務數據攜帶有重定向URL。

優選地，當所述業務請求指向的業務數據的類型為網頁數據時，所述數據推送裝置還包括第三判斷模塊，用于判斷所述業務請求指向的業務數據所采用的編碼方式是否與所述用戶終端采用的編碼方式相同；

所述發送模塊還用于在所述業務請求指向的業務數據所采用的編碼方式與所述用戶終端采用的編碼方式相同時，將所述業務請求指向的業務數據發送至所述用戶終端。

優選地，所述發送模塊還用于在所述業務請求指向的業務數據所采用的編碼方式與所述用戶終端采用的編碼方式不同時，采用所述用戶終端的編碼方式對所述業務請求指向的業務數據進行重編碼，并將重編碼后的業務數據發送至所述用戶終端。

本發明通過CDN節點在接收到用戶終端的業務請求時，若當前未存儲所述業務請求指向的業務數據，且所述業務請求指向的業務數據攜帶重定向URL，則基于所述重定向URL獲取未攜帶重定向URL的業務數據，并將所述未攜帶重定向URL的業務數據存儲為所述業務請求指向的業務數據，以及將所述未攜帶重定向URL的業務數據作為所述業務請求指向的業務數據發送至所述用戶終端，當再次接收到所述業務請求時，所述CDN節點即可用存儲的所述未攜帶重定向URL的業務數據提供服務，無需用戶終端進行重定向跳轉，提高用戶終端獲取數據的效率。

附圖說明

圖1為本發明數據推送方法第一實施例的流程示意圖；

圖2為本發明數據推送裝置第一實施例的功能模塊示意圖。

本發明目的的實現、功能特點及優點將結合實施例，參照附圖做進一步說明。

具體實施方式

應當理解，此處所描述的具體實施例僅僅用以解釋本發明，并不用于限定本發明。

本發明提供一種數據推送方法，參照圖1，在本發明數據推送方法的第一實施例中，所述數據推送方法包括：

步驟S10，在接收到用戶終端發送的業務請求時，內容分發網絡CDN節點判斷當前是否存儲有所述業務請求指向的業務數據；

本實施例提供的數據推送方法可以應用于互聯網訪問中，例如，CDN節點在接收到用戶終端的網頁訪問請求，且當前未存儲有所述網頁訪問請求指向的網頁數據時，根據所述網頁訪問請求向源站服務器回源所述網頁訪問請求指向的網頁數據，并在所述源站服務器響應的網頁數據攜帶重定向URL時，基于所述重定向URL獲取未攜帶重定向URL的網頁數據；所述CDN節點將所述未攜帶重定向URL的網頁數據作為所述網頁訪問請求指向的網頁數據存儲，并將所述未攜帶重定向URL的網頁數據發送至所述用戶終端，容易理解的是，當存儲的所述未攜帶重定向URL的網頁數據再次被訪問時，所述CDN節點即可用存儲的所述未攜帶重定向URL的網頁數據提供服務，減小響應時間，提高用戶終端獲取數據的效率。

具體的，用戶終端在接收到用戶基于瀏覽器的地址欄輸入的URL，或者基于瀏覽器顯示的超鏈接地址觸發的點擊操作，或者基于流媒體播放器觸發的播放操作時，生成攜帶相應URL(或者IP地址)的業務請求發送至所述CDN節點；所述CDN節點在接收到所述用戶終端發送的業務請求時，判斷當前是否存儲有所述業務請求指向的業務數據，以根據判斷結果執行相應的操作，例如，在存儲有所述業務請求指向的業務數據時，所述CDN節點即可直接將所述業務請求指向的業務數據發送至所述用戶終端。

在其他實施例中，上述步驟S10之前，還包括：

CDN路由設備接收所述用戶終端發送的原始業務請求，所述原始業務請求攜帶有所述用戶終端請求的原始URL，所述原始URL對應的域名為所述用戶終端請求的原始域名；所述CDN路由設備向所述用戶終端返回重定向響應消息，所述重定向響應消息攜帶的URL對應的域名中包括所述CDN路由設備為所述用戶終端選擇的加速節點(第一實施例中所述的CDN節點)的標識，以供所述用戶終端向所述CDN節點發送業務請求，由所述CDN節點提供加速服務。

例如，用戶終端向CDN路由設備發送的業務請求中攜帶的URL為 http://www.ZTE.com/news/a.html，其中，www.ZTE.com對應的內容由CP(Content Provider，內容提供商)提供，并且通過CDN提供內容分發加速服務，CDN路由設備根據預定策略為用戶終端選擇一個加速節點(加速節點的標識為對應第一實施例中所述CDN節點的標識C1)，構造新的URL為http://C1.cdn.net/www.ZTE.com/news/a.html。用戶終端向所述新的URL發送業務請求即可獲取到所述CDN節點存儲的相應頁面的頁面數據。

步驟S20，在當前未存儲有所述業務請求指向的業務數據，且所述業務請求指向的業務數據攜帶有重定向統一數據定位符URL時，所述CDN節點基于所述重定向URL獲取未攜帶重定向URL的業務數據；

本實施例中，在當前未存儲有所述業務請求指向的業務數據時，所述CDN節點根據所述業務請求攜帶的URL(或者IP地址)向源站服務器轉發所述業務請求，以接收所述源站服務器響應的業務數據；在接收到所述源站服務器響應的業務數據時，所述CDN節點判斷所述源站服務器響應的業務數據是否攜帶有重定向URL，本領域技術人員可以理解的是，在所述源站服務器響應的業務數據攜帶有重定向URL時，若所述CDN節點直接將所述源站服務器響應的業務數據返回至所述用戶終端，所述用戶終端將根據接收的業務數據中攜帶的重定向URL重定向后繼續訪問，以獲取目標數據，其中，所述用戶終端在繼續訪問的過程中甚至還可能需要多次重定向。顯然，這與CDN的初衷是有悖的，因此，在本實施例中，當所述業務請求指向的業務數據(即源站服務器基于所述業務請求響應的業務數據)攜帶有重定向URL時，所述CDN節點基于所述重定向URL重定向，在接收到所述重定向URL對應的源站服務器響應的業務數據時，繼續判斷重定向URL對應的源站服務器所響應的業務數據是否攜帶有重定向URL，是則繼續重定向，否則轉入步驟S30。

步驟S30，所述CDN節點將所述未攜帶重定向URL的業務數據存儲為所述業務請求指向的業務數據，并將所述未攜帶重定向URL的業務數據發送至所述用戶終端；

本實施例中，所述CDN節點在獲取到未攜帶重定向URL的業務數據時，將所述未攜帶重定向URL的業務數據存儲為所述業務請求指向的業務數據，以供所述CDN節點再次接收到所述業務請求時，直接使用存儲的所述未攜 帶重定向URL的業務數據提供服務；在存儲所述未攜帶重定向URL的業務數據的同時，所述CDN節點還將所述未攜帶重定向URL的業務數據作為所述業務請求指向的業務數據發送至所述用戶終端，供其呈現給用戶。在其他實施例中，所述CDN節點還可以在存儲所述未攜帶重定向URL的業務數據之前或者之后發送所述未攜帶重定向URL的業務數據至所述用戶終端。

步驟S40，在當前存儲有所述業務請求指向的業務數據時，所述CDN節點直接將所述業務請求指向的業務數據發送至所述用戶終端。

容易理解的是，CDN節點存儲業務數據的目的在于再次接收到指向存儲的業務數據的業務請求時，直接用存儲的所述業務數據提供服務，以達到網絡加速的目的，因此，本實施例中，在當前存儲有所述業務請求指向的業務數據時，所述CDN節點直接將所述業務請求指向的業務數據發送至所述用戶終端，供其呈現給用戶。

在其他實施例中，所述CDN節點還可以在預設時間段內未接收到指向存儲的業務數據的業務請求時，刪除存儲的所述業務數據。

其中，所述預設時間段可按實際需要進行設置，例如，本實施例優選將所述預設時間段設置為24小時，本領域技術人員可以理解的是，通過定期刪除長時間未被訪問的業務數據，能夠提升CDN節點存儲空間的利用率。

本實施例提出的數據推送方法，CDN節點在接收到用戶終端的業務請求時，若當前未存儲所述業務請求指向的業務數據，且所述業務請求指向的業務數據攜帶重定向URL，則基于所述重定向URL獲取未攜帶重定向URL的業務數據，并將所述未攜帶重定向URL的業務數據存儲為所述業務請求指向的業務數據，以及將所述未攜帶重定向URL的業務數據作為所述業務請求指向的業務數據發送至所述用戶終端，當再次接收到所述業務請求時，所述CDN節點即可用存儲的所述未攜帶重定向URL的業務數據提供服務，無需用戶終端進行重定向跳轉，提高用戶終端獲取數據的效率。

進一步的，基于第一實施例，提出本發明數據推送方法的第二實施例，在本實施例中，上述步驟S40之前，還包括：

在當前存儲有所述業務請求指向的業務數據時，所述CDN節點判斷所述業務請求指向的業務數據是否攜帶有重定向URL；

在所述業務請求指向的業務數據未攜帶有重定向URL時，執行上述步驟S40；

所述判斷所述業務請求指向的業務數據是否攜帶有重定向URL的步驟之后，所述數據推送方法還包括步驟：

在所述業務請求指向的業務數據攜帶有重定向URL時，所述CDN節點基于所述重定向URL獲取未攜帶重定向URL的業務數據；

所述CDN節點采用未攜帶重定向URL的業務數據更新所述業務請求指向的業務數據，并將未攜帶重定向URL的業務數據發送至所述用戶終端。

需要說明的是，在實際應用中，所述CDN節點存儲的業務數據可能是歷史基于現有技術獲取的，可能存在攜帶重定向URL的情況，因此，在本實施例中，為確保所述CDN節點能夠有效的提供加速服務，在當前存儲有所述業務請求指向的業務數據時，所述CDN節點首先判斷所述業務請求指向的業務數據是否攜帶有重定向URL；若所述業務請求指向的業務數據未攜帶有重定向URL時，所述CDN節點直接將所述業務請求指向的業務數據發送至所述用戶終端，供用戶終端將其呈現給用戶；若所述業務請求指向的業務數據攜帶有重定向URL時，所述CDN節點基于所述重定向URL獲取未攜帶重定向URL的業務數據，其中，所述CDN節點基于所述重定向URL獲取未攜帶重定向URL的業務數據具體可參照第一實施例，此處不再贅述；在獲取到未攜帶重定向URL的業務數據時，所述CDN節點采用未攜帶重定向URL的業務數據更新所述業務請求指向的業務數據，并將未攜帶重定向URL的業務數據發送至所述用戶終端，供其呈現給用戶。

進一步的，基于第二實施例，提出本發明數據推送方法的第三實施例，在本實施例中，所述業務請求指向的業務數據攜帶有HTTP狀態碼，所述CDN節點判斷所述業務請求指向的業務數據是否攜帶有重定向URL的步驟包括：

所述CDN節點判斷所述業務請求指向的業務數據所攜帶的HTTP狀態碼是否與預設HTTP狀態碼一致，其中，當所述HTTP狀態碼與預設HTTP狀態碼一致時，所述業務請求指向的業務數據攜帶有重定向URL。

需要說明的是，HTTP狀態碼(HTTP Status Code)是用以表示服務器HTTP響應狀態的3位數字代碼，它由RFC 2616規范定義，并得到RFC 2518、RFC 2817、RFC 2295、RFC 2774以及RFC 4918等規范擴展。具體的，HTTP狀態碼包括1字頭的消息類狀態碼、2字頭的成功類狀態碼、3字頭的重定向類狀態碼、4字頭的請求錯誤類狀態碼以及5字頭的服務器錯誤類狀態碼，例如，常見的HTTP狀態碼“404”表示請求失敗，請求得到的資源未在服務器上發現，“404”被廣泛應用于當服務器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。

本實施例中，所述CDN節點基于3字頭的重定向類狀態碼判斷所述業務請求指向的業務數據是否攜帶有重定向URL，具體的，所述CDN節點優選通過HTTP狀態碼“301”或“302”進行判斷，即本實施例將所述預設HTTP狀態碼設為“301”或“302”。其中，301”表示被請求的資源已永久移動到新位置，且新的永久性的URL在響應的Location字段中返回；“302”表示請求的資源臨時從不同的URL響應，且臨時的URL在響應的Location字段中返回。

例如，當所述CDN節點提取的所述業務請求指向的業務數據攜帶的HTTP狀態碼為“301”或“302”時，確定所述業務請求指向的業務數據攜帶有重定向URL；當所述CDN節點提取的所述業務請求指向的業務數據攜帶的HTTP狀態碼不為“301”且不為“302”時，確定所述業務請求指向的業務數據未攜帶有重定向URL。

進一步的，基于第一實施例，提出本發明數據推送方法的第四實施例，在本實施例中，當所述業務請求指向的業務數據的類型為網頁數據時，所述CDN節點發送所述業務請求指向的業務數據的步驟之前，還包括：

所述CDN節點判斷所述業務請求指向的業務數據所采用的編碼方式是否與所述用戶終端采用的編碼方式相同；

在所述業務請求指向的業務數據所采用的編碼方式與所述用戶終端采用的編碼方式相同時，執行所述CDN節點發送所述業務請求指向的業務數據的步驟。

需要說明的是，在互聯網中，存在多種類型的數據，例如，網頁數據、音頻數據以及視頻數據等。我們在顯示器上看見的文字、圖片等信息在電腦里面其實并不是我們看見的樣子，即使你知道所有信息都存儲在硬盤里，把它拆開也看不見里面有任何東西，只有些盤片。假設，你用顯微鏡把盤片放 大，會看見盤片表面凹凸不平，凸起的地方被磁化，凹的地方是沒有被磁化；凸起的地方代表數字1，凹的地方代表數字0。硬盤只能用0和1來表示所有文字、圖片等信息。那么字母“A”在硬盤上是如何存儲的呢？可能小張電腦存儲字母“A”是1100001，而小王電腦存儲字母“A”是11000010，這樣雙方交換信息時就會誤解。比如小張把1100001發送給小王，小王并不認為1100001是字母”A”，可能認為這是字母”X”，也就是說，小張和小王的電腦使用了不同的編碼方式。本領域技術人員可以理解的是，當所述業務請求指向的業務數據的類型為網頁數據時，只有所述用戶終端采用的編碼方式與所述業務請求指向的業務數據采用的編碼方式相同時，所述用戶終端才能正常的將所述業務請求指向的業務數據呈現給用戶，確保顯示的網頁不出現亂碼。

本實施例中，所述用戶終端向所述CDN節點發送的所述業務請求包括所述用戶終端采用的編碼方式，同時，所述CDN節點可以通過解析出所述業務請求指向的業務數據中的“charset＝xxx”字段，確定所述業務請求指向的業務數據所采用的編碼方式，其中的“xxx”部分就是所述業務請求指向的業務數據采用的編碼，常用的編碼包括GB2312，GBK，UTF-8，ISO8859-1等。在確定所述用戶終端采用的編碼方式以及確定所述業務請求指向的業務數據采用的編碼方式之后，即可進行判斷。

進一步地，為確保網頁能夠正常顯示，所述CDN節點判斷所述業務請求指向的業務數據所采用的編碼方式是否與所述用戶終端采用的編碼方式相同的步驟之后，還包括：

在所述業務請求指向的業務數據所采用的編碼方式與所述用戶終端采用的編碼方式不同時，所述CDN節點采用所述用戶終端的編碼方式對所述業務請求指向的業務數據進行重編碼，并將重編碼后的業務數據發送至所述用戶終端。

容易理解的是，在所述用戶終端采用的編碼方式與所述業務請求指向的業務數據采用的編碼方式不同時，所述CDN節點采用所述用戶終端的編碼方式對所述業務請求指向的業務數據進行重編碼，重編碼后的業務數據即可供所述用戶終端正常解析，將網頁內容呈現給用戶。

本領域技術人員可以理解的是，在其他實施例中，所述CDN節點在從源站服務器獲取到未攜帶重定向URL的業務數據之后，還可以分別采用多種 常用的編碼方式對所述未攜帶重定向URL的業務數據進行重編碼，并分別存儲重編碼后的業務數據，以進一步提升用戶終端獲取數據的效率。

進一步的，本發明還提供一種數據推送裝置，參照圖2，在本發明數據推送裝置的第一實施例中，所述數據推送裝置包括：

第一判斷模塊10，用于當其所在內容分發網絡CDN節點接收到用戶終端發送的業務請求時，判斷所述CDN節點當前是否存儲有所述業務請求指向的業務數據；

本實施例提供的數據推送裝置可以應用于互聯網訪問中，例如，本實施例提供的數據推送裝置內置于CDN節點運行，所述CDN節點在接收到用戶終端的網頁訪問請求，且當前未存儲有所述網頁訪問請求指向的網頁數據時，根據所述網頁訪問請求向源站服務器回源所述網頁訪問請求指向的網頁數據，并在所述源站服務器響應的網頁數據攜帶重定向URL時，基于所述重定向URL獲取未攜帶重定向URL的網頁數據；所述CDN節點將所述未攜帶重定向URL的網頁數據作為所述網頁訪問請求指向的網頁數據存儲，并將所述未攜帶重定向URL的網頁數據發送至所述用戶終端，容易理解的是，當存儲的所述未攜帶重定向URL的網頁數據再次被訪問時，所述CDN節點即可用存儲的所述未攜帶重定向URL的網頁數據提供服務，減小響應時間，提高用戶終端獲取數據的效率。

具體的，用戶終端在接收到用戶基于瀏覽器的地址欄輸入的URL，或者基于瀏覽器顯示的超鏈接地址觸發的點擊操作，或者基于流媒體播放器觸發的播放操作時，生成攜帶相應URL(或者IP地址)的業務請求發送至第一判斷模塊10所在的CDN節點；所述第一判斷模塊10在基于所述CDN節點在接收到所述用戶終端發送的業務請求時，判斷所述CDN節點當前是否存儲有所述業務請求指向的業務數據，以根據判斷結果執行相應的操作，例如，在存儲有所述業務請求指向的業務數據時，可直接將所述業務請求指向的業務數據發送至所述用戶終端。

在其他實施例中，所述第一判斷模塊10判斷所述CDN節點當前是否存儲有所述業務請求指向的業務數據之前，還包括：

CDN路由設備接收所述用戶終端發送的原始業務請求，所述原始業務請 求攜帶有所述用戶終端請求的原始URL，所述原始URL對應的域名為所述用戶終端請求的原始域名；所述CDN路由設備向所述用戶終端返回重定向響應消息，所述重定向響應消息攜帶的URL對應的域名中包括所述CDN路由設備為所述用戶終端選擇的加速節點(第一實施例中所述的CDN節點)的標識，以供所述用戶終端向所述CDN節點發送業務請求，由所述CDN節點提供加速服務。

例如，用戶終端向CDN路由設備發送的業務請求中攜帶的URL為http://www.ZTE.com/news/a.html，其中，www.ZTE.com對應的內容由CP(Content Provider，內容提供商)提供，并且通過CDN提供內容分發加速服務，CDN路由設備根據預定策略為用戶終端選擇一個加速節點(加速節點的標識為對應第一實施例中所述CDN節點的標識C1)，構造新的URL為http://C1.cdn.net/www.ZTE.com/news/a.html。用戶終端向所述新的URL發送業務請求即可獲取到所述CDN節點存儲的相應頁面的頁面數據。

獲取模塊20，用于在所述CDN節點當前未存儲有所述業務請求指向的業務數據，且所述業務請求指向的業務數據攜帶有重定向統一數據定位符URL時，基于所述重定向URL獲取未攜帶重定向URL的業務數據；

本實施例中，在所述CDN節點當前未存儲有所述業務請求指向的業務數據時，獲取模塊20根據所述業務請求攜帶的URL(或者IP地址)向源站服務器轉發所述業務請求，以接收所述源站服務器響應的業務數據；在基于所述CDN節點接收到所述源站服務器響應的業務數據時，所述獲取模塊20判斷所述源站服務器響應的業務數據是否攜帶有重定向URL，本領域技術人員可以理解的是，在所述源站服務器響應的業務數據攜帶有重定向URL時，若直接將所述源站服務器響應的業務數據返回至所述用戶終端，所述用戶終端將根據接收的業務數據中攜帶的重定向URL重定向后繼續訪問，以獲取目標數據，其中，所述用戶終端在繼續訪問的過程中甚至還可能需要多次重定向。顯然，這與CDN的初衷是有悖的，因此，在本實施例中，當所述業務請求指向的業務數據(即源站服務器基于所述業務請求響應的業務數據)攜帶有重定向URL時，所述獲取模塊20基于所述重定向URL重定向，在接收到所述重定向URL對應的源站服務器響應的業務數據時，繼續判斷重定向URL對應的源站服務器所響應的業務數據是否攜帶有重定向URL，是則繼續 重定向，否則將獲取的未攜帶有重定向URL的業務數據推送至發送模塊30進行處理。

發送模塊30，用于將所述未攜帶重定向URL的業務數據存儲為所述業務請求指向的業務數據，并將所述未攜帶重定向URL的業務數據發送至所述用戶終端；

本實施例中，在獲取到未攜帶重定向URL的業務數據時，發送模塊30將所述未攜帶重定向URL的業務數據存儲為所述業務請求指向的業務數據，供再次接收到所述業務請求時，直接使用存儲的所述未攜帶重定向URL的業務數據提供服務；在存儲所述未攜帶重定向URL的業務數據的同時，所述發送模塊30還將所述未攜帶重定向URL的業務數據作為所述業務請求指向的業務數據發送至所述用戶終端，供其呈現給用戶。在其他實施例中，所述發送模塊30還可以在存儲所述未攜帶重定向URL的業務數據之前或者之后發送所述未攜帶重定向URL的業務數據至所述用戶終端。

所述發送模塊30還用于在所述CDN節點當前存儲有所述業務請求指向的業務數據時，直接將所述業務請求指向的業務數據發送至所述用戶終端。

容易理解的是，CDN節點存儲業務數據的目的在于再次接收到指向存儲的業務數據的業務請求時，直接用存儲的所述業務數據提供服務，以達到網絡加速的目的，因此，本實施例中，在當前存儲有所述業務請求指向的業務數據時，所述發送模塊30直接將所述業務請求指向的業務數據發送至所述用戶終端，供其呈現給用戶。

在其他實施例中，所述數據推送裝置還包括刪除模塊，用于當所述CDN節點在預設時間段內未接收到指向存儲的業務數據的業務請求時，刪除存儲的所述業務數據。

其中，所述預設時間段可按實際需要進行設置，例如，本實施例優選將所述預設時間段設置為24小時，本領域技術人員可以理解的是，通過定期刪除長時間未被訪問的業務數據，能夠提升CDN節點存儲空間的利用率。

本實施例提出的數據推送裝置，內置于CDN接收到運行，所述CDN節點在接收到用戶終端的業務請求時，若當前未存儲所述業務請求指向的業務數據，且所述業務請求指向的業務數據攜帶重定向URL，則基于所述重定向URL獲取未攜帶重定向URL的業務數據，并將所述未攜帶重定向URL的業 務數據存儲為所述業務請求指向的業務數據，以及將所述未攜帶重定向URL的業務數據作為所述業務請求指向的業務數據發送至所述用戶終端，當再次接收到所述業務請求時，所述CDN節點即可用存儲的所述未攜帶重定向URL的業務數據提供服務，無需用戶終端進行重定向跳轉，提高用戶終端獲取數據的效率。

進一步的，基于第一實施例，提出本發明數據推送裝置的第二實施例，在本實施例中，所述數據推送裝置還包括第二判斷模塊，用于在所述CDN節點當前存儲有所述業務請求指向的業務數據時，判斷所述業務請求指向的業務數據是否攜帶有重定向URL；

所述發送模塊30還用于在所述業務請求指向的業務數據未攜帶有重定向URL時，直接將所述業務請求指向的業務數據發送至所述用戶終端；

所述獲取模塊20還用于在所述業務請求指向的業務數據攜帶有重定向URL時，基于所述重定向URL獲取未攜帶重定向URL的業務數據；

所述發送模塊30還用于采用未攜帶重定向URL的業務數據更新所述業務請求指向的業務數據，并將未攜帶重定向URL的業務數據發送至所述用戶終端。

需要說明的是，在實際應用中，所述CDN節點存儲的業務數據可能是歷史基于現有技術獲取的，可能存在攜帶重定向URL的情況，因此，在本實施例中，為確保所述CDN節點能夠有效的提供加速服務，在當前存儲有所述業務請求指向的業務數據時，第二判斷模塊首先判斷所述業務請求指向的業務數據是否攜帶有重定向URL；若所述業務請求指向的業務數據未攜帶有重定向URL時，所述發送模塊30直接將所述業務請求指向的業務數據發送至所述用戶終端，供用戶終端將其呈現給用戶；若所述業務請求指向的業務數據攜帶有重定向URL時，所述獲取模塊20基于所述重定向URL獲取未攜帶重定向URL的業務數據，其中，所述獲取模塊20基于所述重定向URL獲取未攜帶重定向URL的業務數據具體可參照第一實施例，此處不再贅述；在獲取到未攜帶重定向URL的業務數據時，所述發送模塊30采用未攜帶重定向URL的業務數據更新所述業務請求指向的業務數據，并將未攜帶重定向URL的業務數據發送至所述用戶終端，供其呈現給用戶。

此外，在本實施例中，所述獲取模塊20判斷所述源站服務器響應的業務數據是否攜帶有重定向URL通過調用所述第二判斷模塊實現。

進一步的，基于第二實施例，提出本發明數據推送裝置的第三實施例，在本實施例中，所述業務請求指向的業務數據攜帶有HTTP狀態碼，所述第二判斷模塊還用于判斷所述業務請求指向的業務數據所攜帶的HTTP狀態碼是否與預設HTTP狀態碼一致，其中，當所述HTTP狀態碼與預設HTTP狀態碼一致時，所述業務請求指向的業務數據攜帶有重定向URL。

需要說明的是，HTTP狀態碼(HTTP Status Code)是用以表示服務器HTTP響應狀態的3位數字代碼，它由RFC 2616規范定義，并得到RFC2518、RFC 2817、RFC 2295、RFC 2774以及RFC 4918等規范擴展。具體的，HTTP狀態碼包括1字頭的消息類狀態碼、2字頭的成功類狀態碼、3字頭的重定向類狀態碼、4字頭的請求錯誤類狀態碼以及5字頭的服務器錯誤類狀態碼，例如，常見的HTTP狀態碼“404”表示請求失敗，請求得到的資源未在服務器上發現，“404”被廣泛應用于當服務器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。

本實施例中，所述第二判斷模塊基于3字頭的重定向類狀態碼判斷所述業務請求指向的業務數據是否攜帶有重定向URL，具體的，所述第二判斷模塊優選通過HTTP狀態碼“301”或“302”進行判斷，即本實施例將所述預設HTTP狀態碼設為“301”或“302”。其中，301”表示被請求的資源已永久移動到新位置，且新的永久性的URL在響應的Location字段中返回；“302”表示請求的資源臨時從不同的URL響應，且臨時的URL在響應的Location字段中返回。

例如，當所述第二判斷模塊提取的所述業務請求指向的業務數據攜帶的HTTP狀態碼為“301”或“302”時，確定所述業務請求指向的業務數據攜帶有重定向URL；當所述CDN節點提取的所述業務請求指向的業務數據攜帶的HTTP狀態碼不為“301”且不為“302”時，確定所述業務請求指向的業務數據未攜帶有重定向URL。

進一步的，基于第一實施例，提出本發明數據推送裝裝置的第四實施例， 在本實施例中，當所述業務請求指向的業務數據的類型為網頁數據時，所述數據推送裝置還包括第三判斷模塊，用于判斷所述業務請求指向的業務數據所采用的編碼方式是否與所述用戶終端采用的編碼方式相同；

所述發送模塊還用于在所述業務請求指向的業務數據所采用的編碼方式與所述用戶終端采用的編碼方式相同時，將所述業務請求指向的業務數據發送至所述用戶終端。

需要說明的是，在互聯網中，存在多種類型的數據，例如，網頁數據、音頻數據以及視頻數據等。我們在顯示器上看見的文字、圖片等信息在電腦里面其實并不是我們看見的樣子，即使你知道所有信息都存儲在硬盤里，把它拆開也看不見里面有任何東西，只有些盤片。假設，你用顯微鏡把盤片放大，會看見盤片表面凹凸不平，凸起的地方被磁化，凹的地方是沒有被磁化；凸起的地方代表數字1，凹的地方代表數字0。硬盤只能用0和1來表示所有文字、圖片等信息。那么字母“A”在硬盤上是如何存儲的呢？可能小張電腦存儲字母“A”是1100001，而小王電腦存儲字母“A”是11000010，這樣雙方交換信息時就會誤解。比如小張把1100001發送給小王，小王并不認為1100001是字母”A”，可能認為這是字母”X”，也就是說，小張和小王的電腦使用了不同的編碼方式。本領域技術人員可以理解的是，當所述業務請求指向的業務數據的類型為網頁數據時，只有所述用戶終端采用的編碼方式與所述業務請求指向的業務數據采用的編碼方式相同時，所述用戶終端才能正常的將所述業務請求指向的業務數據呈現給用戶，確保顯示的網頁不出現亂碼。

本實施例中，所述用戶終端向所述CDN節點發送的所述業務請求包括所述用戶終端采用的編碼方式，同時，所述第三判斷模塊可以通過解析出所述業務請求指向的業務數據中的“charset＝xxx”字段，確定所述業務請求指向的業務數據所采用的編碼方式，其中的“xxx”部分就是所述業務請求指向的業務數據采用的編碼，常用的編碼包括GB2312，GBK，UTF-8，ISO8859-1等。在確定所述用戶終端采用的編碼方式以及確定所述業務請求指向的業務數據采用的編碼方式之后，所述第三判斷模塊即可進行判斷。

進一步地，為確保網頁能夠正常顯示，所述發送模塊30還用于在所述業務請求指向的業務數據所采用的編碼方式與所述用戶終端采用的編碼方式不同時，采用所述用戶終端的編碼方式對所述業務請求指向的業務數據進行重 編碼，并將重編碼后的業務數據發送至所述用戶終端。

容易理解的是，在所述用戶終端采用的編碼方式與所述業務請求指向的業務數據采用的編碼方式不同時，所述發送模塊30采用所述用戶終端的編碼方式對所述業務請求指向的業務數據進行重編碼，重編碼后的業務數據即可供所述用戶終端正常解析，將網頁內容呈現給用戶。

本領域技術人員可以理解的是，在其他實施例中，在所述獲取模塊20從源站服務器獲取到未攜帶重定向URL的業務數據之后，所述發送模塊30還可以分別采用多種常用的編碼方式對所述未攜帶重定向URL的業務數據進行重編碼，并分別存儲重編碼后的業務數據，以進一步提升用戶終端獲取數據的效率。

以上僅為本發明的優選實施例，并非因此限制本發明的專利范圍，凡是利用本發明說明書及附圖內容所作的等效結構或等效流程變換，或直接或間接運用在其他相關的技術領域，均同理包括在本發明的專利保護范圍內。