本發(fā)明涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，具體涉及一種檢測推廣URL的有效性的方法和裝置。

背景技術(shù)：

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，互聯(lián)網(wǎng)用戶日益增多，形成巨大的推廣受眾，越來越多的具有推廣需求的推廣方希望通過互聯(lián)網(wǎng)進行推廣和宣傳，以提高推廣效率。通常情況下，推廣方通過URL鏈接的方式將推廣內(nèi)容發(fā)布給瀏覽者，該URL表征了一個具體的推廣內(nèi)容在互聯(lián)網(wǎng)上的地址，被稱作“推廣URL”，當(dāng)瀏覽者點擊推廣URL時，對應(yīng)的目標(biāo)推廣內(nèi)容將顯示在瀏覽器上，并且根據(jù)目標(biāo)推廣內(nèi)容的類型進行打開和運行，實現(xiàn)了向瀏覽者推送推廣內(nèi)容的方案。

然而，當(dāng)推廣URL中包含的目標(biāo)推廣內(nèi)容的信息發(fā)生異常，如信息過期或信息刪除等情況時，將導(dǎo)致瀏覽者無法訪問該推廣URL，即該推廣URL失效，成為失效的推廣鏈接。大量失效的推廣鏈接在白白占用互聯(lián)網(wǎng)資源的同時，不僅無法滿足推廣方的推廣需求，也無法滿足瀏覽者對推廣內(nèi)容的瀏覽需求。

目前，在發(fā)布的推廣URL中，有相當(dāng)一部分推廣URL尤其是人工維護的推廣URL，只通過人工來檢測推廣URL的有效性，該檢測方案效率較低且檢測結(jié)果誤差較大。

技術(shù)實現(xiàn)要素：

鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的一種檢測推廣URL的有效性的方法和裝置。

依據(jù)本發(fā)明的一個方面，提供了一種檢測推廣URL的有效性的方法，該方法包括：

獲取待檢測的推廣URL；

對于每個待檢測的推廣URL，先對該推廣URL發(fā)起HEAD請求；

若HEAD請求成功，則確定該推廣URL有效；

若HEAD請求失敗，再對該推廣URL發(fā)起GET請求；若GET請求成功，則確定該推廣URL有效；若GET請求失敗，則確定該推廣URL無效。

可選地，該方法進一步包括：

對于HEAD請求失敗，但GET請求成功的推廣URL，統(tǒng)計其HEAD請求失敗的次數(shù)，如果HEAD請求失敗的次數(shù)未達(dá)到預(yù)設(shè)值則仍采用先發(fā)送HEAD請求的方式進行檢測，當(dāng)HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后，采用直接發(fā)送GET請求的方式進行檢測。

可選地，該方法進一步包括：

為HEAD請求失敗，但GET請求成功的推廣URL設(shè)置一個計數(shù)器；

每當(dāng)關(guān)于該推廣URL的HEAD請求失敗時該計數(shù)器記一次數(shù)；

當(dāng)該計數(shù)器的計數(shù)次數(shù)未達(dá)到預(yù)設(shè)值時，如果該推廣URL的HEAD請求成功，則該計數(shù)器復(fù)位。

可選地，所述計數(shù)器為加法計數(shù)器，該計數(shù)器的初始值為0。

可選地，所述計數(shù)器為減法計數(shù)器，該計數(shù)器的初始值為所述預(yù)設(shè)值。

可選地，該方法進一步包括：

對于HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后采用直接發(fā)送GET請求的方式進行檢測的推廣URL，在經(jīng)過預(yù)設(shè)時間后，重新采用先發(fā)起HEAD請求，若HEAD請求失敗，再發(fā)起GET請求的方式進行檢測。

依據(jù)本發(fā)明的另一個方面，提供了一種檢測推廣URL的有效性的裝置，該裝置包括：

獲取單元，適于獲取待檢測的推廣URL；

檢測單元，適于對于每個待檢測的推廣URL，先對該推廣URL發(fā)起HEAD請求；

若HEAD請求成功，則確定該推廣URL有效；若HEAD請求失敗，再對該推廣URL發(fā)起GET請求；若GET請求成功，則確定該推廣URL有效；若GET請求失敗，則確定該推廣URL無效。

可選地，所述檢測單元，進一步適于對于HEAD請求失敗，但GET請求成功的推廣URL，統(tǒng)計其HEAD請求失敗的次數(shù)，如果HEAD請求失敗的次數(shù)未達(dá)到預(yù)設(shè)值則仍采用先發(fā)送HEAD請求的方式進行檢測，當(dāng)HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后，采用直接發(fā)送GET請求的方式進行檢測。

可選地，所述檢測單元，進一步適于為HEAD請求失敗，但GET請求成功的推廣URL設(shè)置一個計數(shù)器；每當(dāng)關(guān)于該推廣URL的HEAD請求失敗時該計數(shù)器記一次數(shù)；當(dāng)該計數(shù)器的計數(shù)次數(shù)未達(dá)到預(yù)設(shè)值時，如果該推廣URL的HEAD請求成功，則該計數(shù)器復(fù)位。

可選地，所述計數(shù)器為加法計數(shù)器，該計數(shù)器的初始值為0。

可選地，所述計數(shù)器為減法計數(shù)器，該計數(shù)器的初始值為所述預(yù)設(shè)值。

可選地，所述檢測單元，進一步適于對于HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后采用直接發(fā)送GET請求的方式進行檢測的推廣URL，在經(jīng)過預(yù)設(shè)時間后，重新采用先發(fā)起HEAD請求，若HEAD請求失敗，再發(fā)起GET請求的方式進行檢測。

由上述可知，在通過推廣URL推送推廣內(nèi)容的場景中，需要對推廣URL的有效性進行高效、準(zhǔn)確地檢測，以保證推送的有效性；本發(fā)明提供的技術(shù)方案在未獲知待檢測推廣URL是否支持HEAD請求的情況下，對于待檢測的推廣URL，采用先發(fā)送HEAD請求，若HEAD請求失敗再發(fā)送GET請求的方法檢測推廣URL的有效性，在HEAD請求和GET請求中任一個請求成功時，確定該推廣URL有效；在HEAD請求和GET請求均失敗時，確定該推廣URL無效。該方案通過先發(fā)送HEAD請求的方式，盡可能最大程度地節(jié)省請求過程的流量和帶寬，又通過在失敗的HEAD請求后追加一條GET請求的方式，消除了在推廣URL可能不支持HEAD請求的情況下導(dǎo)致的對HEAD請求返回結(jié)果的誤判，進一步提高了檢測的效率、可靠性和有效性。

上述說明僅是本發(fā)明技術(shù)方案的概述，為了能夠更清楚了解本發(fā)明的技術(shù)手段，而可依照說明書的內(nèi)容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的具體實施方式。

附圖說明

通過閱讀下文優(yōu)選實施方式的詳細(xì)描述，各種其他的優(yōu)點和益處對于本領(lǐng)域普通技術(shù)人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認(rèn)為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：

圖1示出了根據(jù)本發(fā)明一個實施例的一種檢測推廣URL的有效性的方法的流程圖；

圖2示出了根據(jù)本發(fā)明一個實施例的一種檢測推廣URL的有效性的數(shù)據(jù)流示意圖；

圖3示出了根據(jù)本發(fā)明一個實施例的一種檢測推廣URL的有效性的裝置的示意圖。

具體實施方式

下面將參照附圖更詳細(xì)地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應(yīng)當(dāng)理解，可以以各種形式實現(xiàn)本公開而不應(yīng)被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達(dá)給本領(lǐng)域的技術(shù)人員。

在互聯(lián)網(wǎng)領(lǐng)域中，對于推廣方利用推廣URL向瀏覽者推送推廣內(nèi)容的場景，為保證推送過程的有效性，需要定期檢測推廣URL的有效性，以避免由于推廣URL失效而給推廣方和瀏覽方帶來的不便與損失?；诖?，本發(fā)明提供了一種檢測推廣URL的有效性的方法和系統(tǒng)，下文將通過具體的實施例對其進行詳細(xì)的說明。

圖1示出了根據(jù)本發(fā)明一個實施例的一種檢測推廣URL的有效性的方法的流程圖。如圖1所示，該方法包括：

步驟S110，獲取待檢測的推廣URL。

步驟S120，對于每個待檢測的推廣URL，先對該推廣URL發(fā)起HEAD請求。

步驟S130，若HEAD請求成功，則確定該推廣URL有效。

步驟S140，若HEAD請求失敗，再對該推廣URL發(fā)起GET請求。

步驟S150，若GET請求成功，則確定該推廣URL有效。

步驟S160，若GET請求失敗，則確定該推廣URL無效。

上述過程中，所述HEAD請求和GET請求均為HTTP協(xié)議中定義的與服務(wù)器交互的方法。其中，HEAD請求是對資源首部信息的請求，返回的數(shù)據(jù)量較小，而GET請求是對資源整體信息的請求，返回的數(shù)據(jù)量較大，相較而言，在不需要獲取資源整體信息的情況下，HEAD請求更有利于節(jié)省流量和帶寬；但是，由于GET請求是HTTP協(xié)議中的基本請求方式，則對于待檢測的推廣URL來說，均默認(rèn)支持GET請求，卻不一定支持HEAD請求。

因此，圖1所示的方法在未獲知待檢測推廣URL是否支持HEAD請求的情況下，對于待檢測的推廣URL，采用先發(fā)送HEAD請求，若HEAD請求失敗再發(fā)送GET請求的方法檢測推廣URL的有效性，在HEAD請求和GET請求中任一個請求成功時，確定該推廣URL有效；在HEAD請求和GET請求均失敗時，確定該推廣URL無效。該方案通過先發(fā)送HEAD請求的方式，盡可能最大程度地節(jié)省請求過程的流量和帶寬；又通過在失敗的HEAD請求后追加一條GET請求的方式，消除了在推廣URL可能不支持HEAD請求的情況下導(dǎo)致的對HEAD請求返回結(jié)果的誤判，進一步提高了檢測的效率、可靠性和有效性。

通常情況下，在圖1所示的方法中，對推廣URL進行檢測后，如果檢測結(jié)果是HEAD請求失敗且GET請求成功，則可以得知：該推廣URL有效，并且該推廣URL不支持HEAD請求或者該推廣URL的HEAD請求被屏蔽，即該推廣URL的HEAD請求無意義。對于已確定HEAD請求無意義的推廣URL，在對其有效性進行重復(fù)檢測時，無需重復(fù)對其發(fā)送HEAD請求。

為此，在本發(fā)明的一個實施例中，圖1所示的方法進一步包括：對于HEAD請求失敗，但GET請求成功的推廣URL，統(tǒng)計其HEAD請求失敗的次數(shù)，如果HEAD請求失敗的次數(shù)未達(dá)到預(yù)設(shè)值則仍采用先發(fā)送HEAD請求的方式進行檢測，當(dāng)HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后，采用直接發(fā)送GET請求的方式進行檢測。其中，設(shè)置預(yù)設(shè)值的目的是消除由不確定因素引起的單次誤差所造成的影響。

具體地，可以采用如下方式統(tǒng)計HEAD請求失敗次數(shù)：為HEAD請求失敗，但GET請求成功的推廣URL設(shè)置一個計數(shù)器；每當(dāng)關(guān)于該推廣URL 的HEAD請求失敗時該計數(shù)器記一次數(shù)；當(dāng)該計數(shù)器的計數(shù)次數(shù)未達(dá)到預(yù)設(shè)值時，如果該推廣URL的HEAD請求成功，則該計數(shù)器復(fù)位。其中，所述計數(shù)器為加法計數(shù)器，該計數(shù)器的初始值為0；所述計數(shù)器也可以為減法計數(shù)器，該計數(shù)器的初始值為所述預(yù)設(shè)值。

例如，設(shè)置減法計數(shù)器的初始值為128，在多次檢測一個指定的推廣URL的有效性的過程中，每當(dāng)?shù)玫揭粋€HEAD請求失敗的結(jié)果，便令減法計數(shù)器減1；在減法計數(shù)器的值達(dá)到0之前，每當(dāng)?shù)玫揭粋€HEAD請求成功的結(jié)果，便令減法計數(shù)器復(fù)位回到128；在此邏輯下，直至減法計數(shù)器的值為0，確定相應(yīng)的推廣URL不支持HEAD請求，從下次檢測該推廣URL的有效性開始，采用直接發(fā)送GET請求的方式進行檢測。

進一步地，為了避免上述過程中可能出現(xiàn)的對推廣URL不支持HEAD請求的誤判，在上述基礎(chǔ)上，圖1所示的方法還包括：對于HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后采用直接發(fā)送GET請求的方式進行檢測的推廣URL，在經(jīng)過預(yù)設(shè)時間后，重新采用先發(fā)起HEAD請求，若HEAD請求失敗，再發(fā)起GET請求的方式進行檢測。

圖2示出了根據(jù)本發(fā)明一個實施例的一種檢測推廣URL的有效性的數(shù)據(jù)流示意圖。如圖2所示，一個或多個任務(wù)代理器獲取待檢測推廣URL，對于獲取的每個推廣URL，按照預(yù)設(shè)策略從檢測服務(wù)器集群中選擇一個檢測服務(wù)器，將該推廣URL發(fā)送給該選擇的檢測服務(wù)器；各檢測服務(wù)器將收到的推廣URL分發(fā)到多個爬蟲調(diào)度器上；各爬蟲調(diào)度器將收到的推廣URL分發(fā)給相應(yīng)的多個爬蟲程序，由爬蟲程序?qū)κ盏降耐茝VURL采用先發(fā)送HEAD請求，若HEAD請求失敗再發(fā)送GET請求的方式進行檢測，獲得推廣URL的有效性的檢測結(jié)果；此外，各爬蟲程序?qū)@得的推廣URL的有效性的檢測結(jié)果返回給相應(yīng)的爬蟲調(diào)度器，再由爬蟲調(diào)度器返回給相應(yīng)的檢測服務(wù)器。

需要說明的是，圖2中可以包括一個或多個任務(wù)代理器，多個任務(wù)代理器的地位是等價的，且其中的每個任務(wù)代理器與一個任務(wù)代理器的執(zhí)行邏輯是一致的，因此，圖2中僅示出一個任務(wù)代理器作為代表進行說明；檢測服務(wù)器集群中的各檢測服務(wù)器與爬蟲調(diào)度器的交互關(guān)系對應(yīng)相同，各爬蟲調(diào)度器與爬蟲程序的交互關(guān)系也對應(yīng)相同；因此，圖2中僅示出第一個檢測服務(wù) 器與多個爬蟲調(diào)度器的交互關(guān)系作為代表進行說明，以及第一個爬蟲調(diào)度器與多個爬蟲程序的交互關(guān)系作為代表進行說明。

在本實施例中，圖2所示的檢測服務(wù)器集群中包括多個檢測服務(wù)器組，每個檢測服務(wù)器組中包括多個檢測服務(wù)器；則任務(wù)代理器對于獲取的每個推廣URL，根據(jù)該推廣URL的域名的哈希值從檢測服務(wù)器集群中選擇一個檢測服務(wù)器組，再從選擇的該檢測服務(wù)器組中選擇一個檢測服務(wù)器。通過這樣的設(shè)置，大量待檢測推廣URL被分散到多個檢測服務(wù)器組中的多個檢測服務(wù)器上進行處理，大大減輕了各檢測服務(wù)器的檢測壓力，提高檢測效率，降低檢測故障發(fā)生率。

具體地，上述從選擇的該檢測服務(wù)器組中選擇一個檢測服務(wù)器包括：向該檢測服務(wù)器組中的各檢測服務(wù)器發(fā)送Ping請求，獲得各檢測服務(wù)器的當(dāng)前響應(yīng)時間，選擇當(dāng)前響應(yīng)時間最短的檢測服務(wù)器，即從選擇的該檢測服務(wù)器中選擇當(dāng)前響應(yīng)最快的一個檢測服務(wù)器，用于接收當(dāng)前待檢測推廣URL。在一些情況下，在上述向該檢測服務(wù)器組中的各檢測服務(wù)器發(fā)送Ping請求，獲得各檢測服務(wù)器的當(dāng)前響應(yīng)時間的過程中，經(jīng)常會由于網(wǎng)絡(luò)抖動而導(dǎo)致各檢測服務(wù)器的當(dāng)前響應(yīng)時間不穩(wěn)定，為此，在獲得各檢測服務(wù)器的當(dāng)前響應(yīng)時間后，將當(dāng)前響應(yīng)時間最短的檢測服務(wù)器與前一次檢測所述推廣URL時選擇的檢測服務(wù)器的當(dāng)前響應(yīng)時間進行比較，如果二者差距超過預(yù)設(shè)范圍，則選擇當(dāng)前響應(yīng)時間最短的檢測服務(wù)器；如果二者差距未超過預(yù)設(shè)范圍，則沿用前一次檢測所述推廣URL時選擇的檢測服務(wù)器。

例如，任務(wù)代理器向一個檢測服務(wù)器組中的各檢測服務(wù)器發(fā)送Ping請求，獲得各檢測服務(wù)器的響應(yīng)時間，在上一個時間段，響應(yīng)時間最短的檢測服務(wù)器為A檢測服務(wù)器，而在當(dāng)前時間段，響應(yīng)時間最短的檢測服務(wù)器為B服務(wù)器，為去除網(wǎng)絡(luò)抖動造成的影響，預(yù)設(shè)T₀，將A檢測服務(wù)器的當(dāng)前響應(yīng)時間T_A和B檢測服務(wù)器的當(dāng)前響應(yīng)時間T_B進行比較，如果T_A-T_B≥T₀，則表明在當(dāng)前時間段內(nèi)B檢測服務(wù)器的性能確實優(yōu)于A檢測服務(wù)器，因此選擇B檢測服務(wù)器；如果T_A-T_B<T₀，則表明在當(dāng)前時間段內(nèi)B檢測服務(wù)器的響應(yīng)速度快于A檢測服務(wù)器可能是網(wǎng)絡(luò)抖動所造成的，不能確定B檢測服務(wù)器的性能確實優(yōu)于A檢測服務(wù)器，因此依然沿用A檢測服務(wù)器。

在本實施例中，在各爬蟲程序獲得的推廣URL有效性的檢測結(jié)果最終將返回給相應(yīng)的檢測服務(wù)器之后，進一步地，相應(yīng)的檢測服務(wù)器所在的檢測服務(wù)器組中的所有檢測服務(wù)器同步保存返回的推廣URL有效性的檢測結(jié)果。通過這樣的設(shè)置，使得同一個檢測服務(wù)器組中的所有檢測服務(wù)器能夠分享其中任一個檢測服務(wù)器所得到的推廣URL有效性的檢測結(jié)果，保持組內(nèi)同步更新的狀態(tài)，當(dāng)調(diào)用同一個檢測服務(wù)器組中的任一個檢測服務(wù)器時，即可獲知歷史檢測結(jié)果，無需對相同的推廣URL進行重復(fù)檢測。

本實施例中，爬蟲調(diào)度器可以是檢測服務(wù)器中的模塊，也可以是硬件上獨立于檢測服務(wù)器的機器，當(dāng)爬蟲調(diào)度器是硬件上獨立于檢測服務(wù)器的機器時，圖2中的各檢測服務(wù)器將收到的推廣URL分發(fā)到多個爬蟲調(diào)度器上包括：各檢測服務(wù)器將收到的每個推廣URL進行DNS解析，得到該推廣URL對應(yīng)的IP地址，將該推廣URL分發(fā)到與其IP地址屬于同一地區(qū)的爬蟲調(diào)度器上。其中，各檢測服務(wù)器可以監(jiān)測到多個爬蟲調(diào)度器的運行狀況，當(dāng)一個爬蟲調(diào)度器發(fā)生故障時，檢測服務(wù)器會將該爬蟲調(diào)度器上的待檢測推廣URL轉(zhuǎn)移分配給附近的其他爬蟲調(diào)度器。

在本實施例中，各爬蟲程序具有等價的地位，各爬蟲調(diào)度器基于負(fù)載均衡的原則將收到的推廣URL分發(fā)給相應(yīng)的多個爬蟲程序，即將收到的推廣URL均勻地分配給多個爬蟲程序。

圖3示出了根據(jù)本發(fā)明一個實施例的一種檢測推廣URL的有效性的裝置的示意圖，如圖3所示，該檢測推廣URL的有效性的裝置300包括：

獲取單元310，適于獲取待檢測的推廣URL。

檢測單元320，適于對于每個待檢測的推廣URL，先對該推廣URL發(fā)起HEAD請求；若HEAD請求成功，則確定該推廣URL有效；若HEAD請求失敗，再對該推廣URL發(fā)起GET請求；若GET請求成功，則確定該推廣URL有效；若GET請求失敗，則確定該推廣URL無效。

上述裝置描述中，所述HEAD請求和GET請求均為HTTP協(xié)議中定義的與服務(wù)器交互的方法。其中，HEAD請求是對資源首部信息的請求，返回的數(shù)據(jù)量較小，而GET請求是對資源整體信息的請求，返回的數(shù)據(jù)量較大，相較而言，在不需要獲取資源整體信息的情況下，HEAD請求更有利于節(jié)省 流量和帶寬；但是，由于GET請求是HTTP協(xié)議中的基本請求方式，則對于待檢測的推廣URL來說，均默認(rèn)支持GET請求，卻不一定支持HEAD請求。

因此，圖3所示的裝置在未獲知待檢測推廣URL是否支持HEAD請求的情況下，對于待檢測的推廣URL，采用先發(fā)送HEAD請求，若HEAD請求失敗再發(fā)送GET請求的方法檢測推廣URL的有效性，在HEAD請求和GET請求中任一個請求成功時，確定該推廣URL有效；在HEAD請求和GET請求均失敗時，確定該推廣URL無效。該方案通過先發(fā)送HEAD請求的方式，盡可能最大程度地節(jié)省請求過程的流量和帶寬；又通過在失敗的HEAD請求后追加一條GET請求的方式，消除了在推廣URL可能不支持HEAD請求的情況下導(dǎo)致的對HEAD請求返回結(jié)果的誤判，進一步提高了檢測的效率、可靠性和有效性。

在本發(fā)明的一個實施例中，圖3所示裝置的檢測單元320，進一步適于對于HEAD請求失敗，但GET請求成功的推廣URL，統(tǒng)計其HEAD請求失敗的次數(shù)，如果HEAD請求失敗的次數(shù)未達(dá)到預(yù)設(shè)值則仍采用先發(fā)送HEAD請求的方式進行檢測，當(dāng)HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后，采用直接發(fā)送GET請求的方式進行檢測。

具體地，圖3所示裝置的檢測單元320，進一步適于為HEAD請求失敗，但GET請求成功的推廣URL設(shè)置一個計數(shù)器；每當(dāng)關(guān)于該推廣URL的HEAD請求失敗時該計數(shù)器記一次數(shù)；當(dāng)該計數(shù)器的計數(shù)次數(shù)未達(dá)到預(yù)設(shè)值時，如果該推廣URL的HEAD請求成功，則該計數(shù)器復(fù)位。其中，所述計數(shù)器為加法計數(shù)器，該計數(shù)器的初始值為0；所述計數(shù)器為減法計數(shù)器，該計數(shù)器的初始值為所述預(yù)設(shè)值。

進一步地，為了避免上述過程中可能出現(xiàn)的對推廣URL不支持HEAD請求的誤判，在上述基礎(chǔ)上，檢測單元320，進一步適于對于HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后采用直接發(fā)送GET請求的方式進行檢測的推廣URL，在經(jīng)過預(yù)設(shè)時間后，重新采用先發(fā)起HEAD請求，若HEAD請求失敗，再發(fā)起GET請求的方式進行檢測。

需要說明的是，圖3所示裝置的各實施例與上文圖1-圖2所示各實施例對應(yīng)相同，上文已詳細(xì)說明，在此不再贅述。

綜上所述，在通過推廣URL推送推廣內(nèi)容的場景中，需要對推廣URL的有效性進行高效、準(zhǔn)確地檢測，以保證推送的有效性；本發(fā)明提供的技術(shù)方案在未獲知待檢測推廣URL是否支持HEAD請求的情況下，對于待檢測的推廣URL，采用先發(fā)送HEAD請求，若HEAD請求失敗再發(fā)送GET請求的方法檢測推廣URL的有效性，在HEAD請求和GET請求中任一個請求成功時，確定該推廣URL有效；在HEAD請求和GET請求均失敗時，確定該推廣URL無效。該方案通過先發(fā)送HEAD請求的方式，盡可能最大程度地節(jié)省請求過程的流量和帶寬；又通過在失敗的HEAD請求后追加一條GET請求的方式，消除了在推廣URL可能不支持HEAD請求的情況下導(dǎo)致的對HEAD請求返回結(jié)果的誤判，進一步提高了檢測推廣URL的有效性的效率、可靠性和有效性，保證了推廣內(nèi)容的推送過程的有效性，能夠更完美地滿足當(dāng)前互聯(lián)網(wǎng)領(lǐng)域的推廣需求。

需要說明的是：

在此提供的算法和顯示不與任何特定計算機、虛擬裝置或者其它設(shè)備固有相關(guān)。各種通用裝置也可以與基于在此的示教一起使用。根據(jù)上面的描述，構(gòu)造這類裝置所要求的結(jié)構(gòu)是顯而易見的。此外，本發(fā)明也不針對任何特定編程語言。應(yīng)當(dāng)明白，可以利用各種編程語言實現(xiàn)在此描述的本發(fā)明的內(nèi)容，并且上面對特定語言所做的描述是為了披露本發(fā)明的最佳實施方式。

在此處所提供的說明書中，說明了大量具體細(xì)節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細(xì)節(jié)的情況下實踐。在一些實例中，并未詳細(xì)示出公知的方法、結(jié)構(gòu)和技術(shù)，以便不模糊對本說明書的理解。

類似地，應(yīng)當(dāng)理解，為了精簡本公開并幫助理解各個發(fā)明方面中的一個或多個，在上面對本發(fā)明的示例性實施例的描述中，本發(fā)明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而，并不應(yīng)將該公開的方法解釋成反映如下意圖：即所要求保護的本發(fā)明要求比在每個權(quán)利要求中所明確記載的特征更多的特征。更確切地說，如下面的權(quán)利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個實施例的所有特征。因此，遵循具體實施方式的權(quán)利要求書由此明確地并入該具體實施方式，其中每個權(quán)利要求本身都作為本發(fā)明的單獨實施例。

本領(lǐng)域那些技術(shù)人員可以理解，可以對實施例中的設(shè)備中的模塊進行自適應(yīng)性地改變并且把它們設(shè)置在與該實施例不同的一個或多個設(shè)備中。可以把實施例中的模塊或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設(shè)備的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。

此外，本領(lǐng)域的技術(shù)人員能夠理解，盡管在此所述的一些實施例包括其它實施例中所包括的某些特征而不是其它特征，但是不同實施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實施例。例如，在下面的權(quán)利要求書中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。

本發(fā)明的各個部件實施例可以以硬件實現(xiàn)，或者以在一個或者多個處理器上運行的軟件模塊實現(xiàn)，或者以它們的組合實現(xiàn)。本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，可以在實踐中使用微處理器或者數(shù)字信號處理器(DSP)來實現(xiàn)根據(jù)本發(fā)明實施例的檢測推廣URL的有效性的裝置中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設(shè)備或者裝置程序(例如，計算機程序和計算機程序產(chǎn)品)。這樣的實現(xiàn)本發(fā)明的程序可以存儲在計算機可讀介質(zhì)上，或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網(wǎng)網(wǎng)站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。

應(yīng)該注意的是上述實施例對本發(fā)明進行說明而不是對本發(fā)明進行限制，并且本領(lǐng)域技術(shù)人員在不脫離所附權(quán)利要求的范圍的情況下可設(shè)計出替換實施例。在權(quán)利要求中，不應(yīng)將位于括號之間的任何參考符號構(gòu)造成對權(quán)利要求的限制。單詞“包含”不排除存在未列在權(quán)利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當(dāng)編程的計算機來實現(xiàn)。在 列舉了若干裝置的單元權(quán)利要求中，這些裝置中的若干個可以是通過同一個硬件項來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序?？蓪⑦@些單詞解釋為名稱。

本發(fā)明公開了A1、一種檢測推廣URL的有效性的方法，其中，該方法包括：

獲取待檢測的推廣URL；

對于每個待檢測的推廣URL，先對該推廣URL發(fā)起HEAD請求；

若HEAD請求成功，則確定該推廣URL有效；

若HEAD請求失敗，再對該推廣URL發(fā)起GET請求；若GET請求成功，則確定該推廣URL有效；若GET請求失敗，則確定該推廣URL無效。

A2、如A1所述的方法，其中，該方法進一步包括：

對于HEAD請求失敗，但GET請求成功的推廣URL，統(tǒng)計其HEAD請求失敗的次數(shù)，如果HEAD請求失敗的次數(shù)未達(dá)到預(yù)設(shè)值則仍采用先發(fā)送HEAD請求的方式進行檢測，當(dāng)HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后，采用直接發(fā)送GET請求的方式進行檢測。

A3、如A2所述的方法，其中，該方法進一步包括：

為HEAD請求失敗，但GET請求成功的推廣URL設(shè)置一個計數(shù)器；

每當(dāng)關(guān)于該推廣URL的HEAD請求失敗時該計數(shù)器記一次數(shù)；

當(dāng)該計數(shù)器的計數(shù)次數(shù)未達(dá)到預(yù)設(shè)值時，如果該推廣URL的HEAD請求成功，則該計數(shù)器復(fù)位。

A4、如A3所述的方法，其中，

所述計數(shù)器為加法計數(shù)器，該計數(shù)器的初始值為0。

A5、如A3所述的方法，其中，

所述計數(shù)器為減法計數(shù)器，該計數(shù)器的初始值為所述預(yù)設(shè)值。

A6、如A2所述的方法，其中，該方法進一步包括：

對于HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后采用直接發(fā)送GET請求的方式進行檢測的推廣URL，在經(jīng)過預(yù)設(shè)時間后，重新采用先發(fā)起HEAD請求，若HEAD請求失敗，再發(fā)起GET請求的方式進行檢測。

本發(fā)明還公開了B7、一種檢測推廣URL的有效性的裝置，其中，該裝 置包括：

獲取單元，適于獲取待檢測的推廣URL；

檢測單元，適于對于每個待檢測的推廣URL，先對該推廣URL發(fā)起HEAD請求；

若HEAD請求成功，則確定該推廣URL有效；若HEAD請求失敗，再對該推廣URL發(fā)起GET請求；若GET請求成功，則確定該推廣URL有效；若GET請求失敗，則確定該推廣URL無效。

B8、如B7所述的裝置，其中，

所述檢測單元，進一步適于對于HEAD請求失敗，但GET請求成功的推廣URL，統(tǒng)計其HEAD請求失敗的次數(shù)，如果HEAD請求失敗的次數(shù)未達(dá)到預(yù)設(shè)值則仍采用先發(fā)送HEAD請求的方式進行檢測，當(dāng)HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后，采用直接發(fā)送GET請求的方式進行檢測。

B9、如B8所述的裝置，其中，

所述檢測單元，進一步適于為HEAD請求失敗，但GET請求成功的推廣URL設(shè)置一個計數(shù)器；每當(dāng)關(guān)于該推廣URL的HEAD請求失敗時該計數(shù)器記一次數(shù)；當(dāng)該計數(shù)器的計數(shù)次數(shù)未達(dá)到預(yù)設(shè)值時，如果該推廣URL的HEAD請求成功，則該計數(shù)器復(fù)位。

B10、如B9所述的裝置，其中，

所述計數(shù)器為加法計數(shù)器，該計數(shù)器的初始值為0。

B11、如B9所述的裝置，其中，

所述計數(shù)器為減法計數(shù)器，該計數(shù)器的初始值為所述預(yù)設(shè)值。

B12、如B8所述的裝置，其中，

所述檢測單元，進一步適于對于HEAD請求失敗的次數(shù)達(dá)到預(yù)設(shè)值后采用直接發(fā)送GET請求的方式進行檢測的推廣URL，在經(jīng)過預(yù)設(shè)時間后，重新采用先發(fā)起HEAD請求，若HEAD請求失敗，再發(fā)起GET請求的方式進行檢測。