一区二区三区日韩精品-日韩经典一区二区三区-五月激情综合丁香婷婷-欧美精品中文字幕专区

分享

網(wǎng)站數(shù)據(jù)統(tǒng)計分析中的日志收集原理及其實現(xiàn)

 firefly87 2016-02-16

網(wǎng)站數(shù)據(jù)統(tǒng)計分析工具是網(wǎng)站站長和運營人員經(jīng)常使用的一種工具,比較常用的有谷歌分析、百度統(tǒng)計  騰訊分析等等。所有這些統(tǒng)計分析工具的第一步都是網(wǎng)站訪問數(shù)據(jù)的收集。目前主流的數(shù)據(jù)收集方式基本都是基于javascript的。本文將簡要分析這種數(shù)據(jù)收集的原理,并一步一步實際搭建一個實際的數(shù)據(jù)收集系統(tǒng)。

1、數(shù)據(jù)收集原理分析

簡單來說,網(wǎng)站統(tǒng)計分析工具需要收集到用戶瀏覽目標(biāo)網(wǎng)站的行為(如打開某網(wǎng)頁、點擊某按鈕、將商品加入購物車等)及行為附加數(shù)據(jù)(如某下單行為產(chǎn)生的訂單金額等)。早期的網(wǎng)站統(tǒng)計往往只收集一種用戶行為:頁面的打開。而后用戶在頁面中的行為均無法收集。這種收集策略能滿足基本的流量分析、來源分析、內(nèi)容分析及訪客屬性等常用分析視角,但是,隨著ajax技術(shù)的廣泛使用及電子商務(wù)網(wǎng)站對于電子商務(wù)目標(biāo)的統(tǒng)計分析的需求越來越強烈,這種傳統(tǒng)的收集策略已經(jīng)顯得力不能及。
后來,Google在其產(chǎn)品谷歌分析中創(chuàng)新性的引入了可定制的數(shù)據(jù)收集腳本,用戶通過谷歌分析定義好的可擴展接口,只需編寫少量的javascript代碼就可以實現(xiàn)自定義事件和自定義指標(biāo)的跟蹤和分析。目前百度統(tǒng)計、搜狗分析等產(chǎn)品均照搬了谷歌分析的模式。
其實說起來兩種數(shù)據(jù)收集模式的基本原理和流程是一致的,只是后一種通過javascript收集到了更多的信息。下面看一下現(xiàn)在各種網(wǎng)站統(tǒng)計工具的數(shù)據(jù)收集基本原理。

1.1 流程概覽

首先通過一幅圖總體看一下數(shù)據(jù)收集的基本流程。


圖1. 網(wǎng)站統(tǒng)計數(shù)據(jù)收集基本流程

首先,用戶的行為會觸發(fā)瀏覽器對被統(tǒng)計頁面的一個http請求,這里姑且先認(rèn)為行為就是打開網(wǎng)頁。當(dāng)網(wǎng)頁被打開,頁面中的埋點javascript片段會被執(zhí)行,用過相關(guān)工具的朋友應(yīng)該知道,一般網(wǎng)站統(tǒng)計工具都會要求用戶在網(wǎng)頁中加入一小段javascript代碼,這個代碼片段一般會動態(tài)創(chuàng)建一個script標(biāo)簽,并將src指向一個單獨的js文件,此時這個單獨的js文件(圖1中綠色節(jié)點)會被瀏覽器請求到并執(zhí)行,這個js往往就是真正的數(shù)據(jù)收集腳本。數(shù)據(jù)收集完成后,js會請求一個后端的數(shù)據(jù)收集腳本(圖1中的backend),這個腳本一般是一個偽裝成圖片的動態(tài)腳本程序,可能由php、python或其它服務(wù)端語言編寫,js會將收集到的數(shù)據(jù)通過http參數(shù)的方式傳遞給后端腳本,后端腳本解析參數(shù)并按固定格式記錄到訪問日志,同時可能會在http響應(yīng)中給客戶端種植一些用于追蹤的cookie。
上面是一個數(shù)據(jù)收集的大概流程,下面以谷歌分析為例,對每一個階段進行一個相對詳細的分析。

1.2 埋點腳本執(zhí)行階段

若要使用谷歌分析(以下簡稱GA),需要在頁面中插入一段它提供的javascript片段,這個片段往往被稱為埋點代碼。下面是我的博客中所放置的谷歌分析埋點代碼截圖:

 

圖2. 谷歌分析埋點代碼

其中_gaq是GA的的全局?jǐn)?shù)組,用于放置各種配置,其中每一條配置的格式為:

1
_gaq.push(['Action''param1''param2', ...]);

Action指定配置動作,后面是相關(guān)的參數(shù)列表。GA給的默認(rèn)埋點代碼會給出兩條預(yù)置配置,_setAccount用于設(shè)置網(wǎng)站標(biāo)識ID,這個標(biāo)識ID是在注冊GA時分配的。_trackPageview告訴GA跟蹤一次頁面訪問。更多配置請參考: https://developers.google.com/analytics/devguides/collection/gajs/ 。實際上,這個_gaq是被當(dāng)做一個FIFO隊列來用的,配置代碼不必出現(xiàn)在埋點代碼之前,具體請參考上述鏈接的說明。

就本文來說,_gaq的機制不是重點,重點是后面匿名函數(shù)的代碼,這才是埋點代碼真正要做的。這段代碼的主要目的就是引入一個外部的js文件(ga.js),方式是通過document.createElement方法創(chuàng)建一個script并根據(jù)協(xié)議(http或https)將src指向?qū)?yīng)的ga.js,最后將這個element插入頁面的dom樹上。

注意ga.async = true的意思是異步調(diào)用外部js文件,即不阻塞瀏覽器的解析,待外部js下載完成后異步執(zhí)行。這個屬性是HTML5新引入的。

1.3 數(shù)據(jù)收集腳本執(zhí)行階段

數(shù)據(jù)收集腳本(ga.js)被請求后會被執(zhí)行,這個腳本一般要做如下幾件事:
(1)通過瀏覽器內(nèi)置javascript對象收集信息,如頁面title(通過document.title)、referrer(上一跳url,通過document.referrer)、用戶顯示器分辨率(通過windows.screen)、cookie信息(通過document.cookie)等等一些信息。
(2)解析_gaq收集配置信息。這里面可能會包括用戶自定義的事件跟蹤、業(yè)務(wù)數(shù)據(jù)(如電子商務(wù)網(wǎng)站的商品編號等)等。
(3)將上面兩步收集的數(shù)據(jù)按預(yù)定義格式解析并拼接。
(4)請求一個后端腳本,將信息放在http request參數(shù)中攜帶給后端腳本。
這里唯一的問題是步驟4,javascript請求后端腳本常用的方法是ajax,但是ajax是不能跨域請求的。這里ga.js在被統(tǒng)計網(wǎng)站的域內(nèi)執(zhí)行,而后端腳本在另外的域(GA的后端統(tǒng)計腳本是http://www./__utm.gif),ajax行不通。一種通用的方法是js腳本創(chuàng)建一個Image對象,將Image對象的src屬性指向后端腳本并攜帶參數(shù),此時即實現(xiàn)了跨域請求后端。這也是后端腳本為什么通常偽裝成gif文件的原因。通過http抓包可以看到ga.js對__utm.gif的請求:

圖3. 后端腳本請求的http包

可以看到ga.js在請求__utm.gif時帶了很多信息,例如utmsr=1280×1024是屏幕分辨率,utmac=UA-35712773-1是_gaq中解析出的我的GA標(biāo)識ID等等。
值得注意的是,__utm.gif未必只會在埋點代碼執(zhí)行時被請求,如果用_trackEvent配置了事件跟蹤,則在事件發(fā)生時也會請求這個腳本。
由于ga.js經(jīng)過了壓縮和混淆,可讀性很差,我們就不分析了,具體后面實現(xiàn)階段我會實現(xiàn)一個功能類似的腳本。

1.4 后端腳本執(zhí)行階段

GA的__utm.gif是一個偽裝成gif的腳本。這種后端腳本一般要完成以下幾件事情:
(1)解析http請求參數(shù)的到信息。
(2)從服務(wù)器(WebServer)中獲取一些客戶端無法獲取的信息,如訪客ip等。
(3)將信息按格式寫入log。
(4)生成一副1×1的空gif圖片作為響應(yīng)內(nèi)容并將響應(yīng)頭的Content-type設(shè)為image/gif。
(5)在響應(yīng)頭中通過Set-cookie設(shè)置一些需要的cookie信息。
之所以要設(shè)置cookie是因為如果要跟蹤唯一訪客,通常做法是如果在請求時發(fā)現(xiàn)客戶端沒有指定的跟蹤cookie,則根據(jù)規(guī)則生成一個全局唯一的cookie并種植給用戶,否則Set-cookie中放置獲取到的跟蹤cookie以保持同一用戶cookie不變(見圖4)。

圖4. 通過cookie跟蹤唯一用戶的原理

這種做法雖然不是完美的(例如用戶清掉cookie或更換瀏覽器會被認(rèn)為是兩個用戶),但是是目前被廣泛使用的手段。注意,如果沒有跨站跟蹤同一用戶的需求,可以通過js將cookie種植在被統(tǒng)計站點的域下(GA是這么做的),如果要全網(wǎng)統(tǒng)一定位,則通過后端腳本種植在服務(wù)端域下(我們待會的實現(xiàn)會這么做)。

2、系統(tǒng)的設(shè)計實現(xiàn)

根據(jù)上述原理,我自己搭建了一個訪問日志收集系統(tǒng)。總體來說,搭建這個系統(tǒng)要做如下的事:

圖5. 訪問數(shù)據(jù)收集系統(tǒng)工作分解

下面詳述每一步的實現(xiàn)。我將這個系統(tǒng)叫做MyAnalytics。

2.1 確定收集的信息

為了簡單起見,我不打算實現(xiàn)GA的完整數(shù)據(jù)收集模型,而是收集以下信息。

名稱 途徑 備注
訪問時間 web server Nginx $msec
IP web server Nginx $remote_addr
域名 javascript document.domain
URL javascript document.URL
頁面標(biāo)題 javascript document.title
分辨率 javascript window.screen.height & width
顏色深度 javascript window.screen.colorDepth
Referrer javascript document.referrer
瀏覽客戶端 web server Nginx $http_user_agent
客戶端語言 javascript navigator.language
訪客標(biāo)識 cookie
網(wǎng)站標(biāo)識 javascript 自定義對象

2.2 埋點代碼

埋點代碼我將借鑒GA的模式,但是目前不會將配置對象作為一個FIFO隊列用。一個埋點代碼的模板如下:

1
2
3
4
5
6
7
8
9
10
<script type="text/javascript">
var _maq = _maq || [];
_maq.push(['_setAccount''網(wǎng)站標(biāo)識']);
  
(function() {
    var ma = document.createElement('script'); ma.type = 'text/javascript'; ma.async = true;
    ma.src = ('https:' == document.location.protocol ? 'https://analytics' 'http://analytics') + './ma.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ma, s);
})();
</script>

這里我啟用了二級域名analytics.,統(tǒng)計腳本的名稱為ma.js。當(dāng)然這里有一點小問題,因為我并沒有https的服務(wù)器,所以如果一個https站點部署了代碼會有問題,不過這里我們先忽略吧。

2.3 前端統(tǒng)計腳本

我寫了一個不是很完善但能完成基本工作的統(tǒng)計腳本ma.js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
(function () {
    var params = {};
    //Document對象數(shù)據(jù)
    if(document) {
        params.domain = document.domain || ''
        params.url = document.URL || ''
        params.title = document.title || ''
        params.referrer = document.referrer || ''
    }   
    //Window對象數(shù)據(jù)
    if(window && window.screen) {
        params.sh = window.screen.height || 0;
        params.sw = window.screen.width || 0;
        params.cd = window.screen.colorDepth || 0;
    }   
    //navigator對象數(shù)據(jù)
    if(navigator) {
        params.lang = navigator.language || ''
    }   
    //解析_maq配置
    if(_maq) {
        for(var in _maq) {
            switch(_maq[i][0]) {
                case '_setAccount':
                    params.account = _maq[i][1];
                    break;
                default:
                    break;
            }   
        }   
    }   
    //拼接參數(shù)串
    var args = ''
    for(var in params) {
        if(args != '') {
            args += '&';
        }   
        args += i + '=' + encodeURIComponent(params[i]);
    }   
  
    //通過Image對象請求后端腳本
    var img = new Image(1, 1); 
    img.src = 'http://analytics./1.gif?' + args;
})();

整個腳本放在匿名函數(shù)里,確保不會污染全局環(huán)境。功能在原理一節(jié)已經(jīng)說明,不再贅述。其中1.gif是后端腳本。

2.4 日志格式

日志采用每行一條記錄的方式,采用不可見字符^A(ascii碼0x01,Linux下可通過ctrl + v ctrl + a輸入,下文均用“^A”表示不可見字符0x01),具體格式如下:
時間^AIP^A域名^AURL^A頁面標(biāo)題^AReferrer^A分辨率高^A分辨率寬^A顏色深度^A語言^A客戶端信息^A用戶標(biāo)識^A網(wǎng)站標(biāo)識

2.5 后端腳本

為了簡單和效率考慮,我打算直接使用nginx的access_log做日志收集,不過有個問題就是nginx配置本身的邏輯表達能力有限,所以我選用了OpenResty做這個事情。OpenResty是一個基于Nginx擴展出的高性能應(yīng)用開發(fā)平臺,內(nèi)部集成了諸多有用的模塊,其中的核心是通過ngx_lua模塊集成了Lua,從而在nginx配置文件中可以通過Lua來表述業(yè)務(wù)。關(guān)于這個平臺我這里不做過多介紹,感興趣的同學(xué)可以參考其官方網(wǎng)站http:///,或者這里有其作者章亦春(agentzh)做的一個非常有愛的介紹OpenResty的slide:http:///misc/slides/ngx-openresty-ecosystem/,關(guān)于ngx_lua可以參考:https://github.com/chaoslawful/lua-nginx-module
首先,需要在nginx的配置文件中定義日志格式:

1
log_format tick "$msec^A$remote_addr^A$u_domain^A$u_url^A$u_title^A$u_referrer^A$u_sh^A$u_sw^A$u_cd^A$u_lang^A$http_user_agent^A$u_utrace^A$u_account";

注意這里以u_開頭的是我們待會會自己定義的變量,其它的是nginx內(nèi)置變量。
然后是核心的兩個location:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
location /1.gif {
#偽裝成gif文件
    default_type image/gif;    
#本身關(guān)閉access_log,通過subrequest記錄log
    access_log off;
  
    access_by_lua "
        -- 用戶跟蹤cookie名為__utrace
        local uid = ngx.var.cookie___utrace        
        if not uid then
            -- 如果沒有則生成一個跟蹤cookie,算法為md5(時間戳+IP+客戶端信息)
            uid = ngx.md5(ngx.now() .. ngx.var.remote_addr .. ngx.var.http_user_agent)
        end 
        ngx.header['Set-Cookie'] = {'__utrace=' .. uid .. '; path=/'}
        if ngx.var.arg_domain then
        -- 通過subrequest到/i-log記錄日志,將參數(shù)和用戶跟蹤cookie帶過去
            ngx.location.capture('/i-log?' .. ngx.var.args .. '&utrace=' .. uid)
        end 
    ";  
  
    #此請求不緩存
    add_header Expires "Fri, 01 Jan 1980 00:00:00 GMT";
    add_header Pragma "no-cache";
    add_header Cache-Control "no-cache, max-age=0, must-revalidate";
  
    #返回一個1×1的空gif圖片
    empty_gif;
}   
  
location /i-log {
    #內(nèi)部location,不允許外部直接訪問
    internal;
  
    #設(shè)置變量,注意需要unescape
    set_unescape_uri $u_domain $arg_domain;
    set_unescape_uri $u_url $arg_url;
    set_unescape_uri $u_title $arg_title;
    set_unescape_uri $u_referrer $arg_referrer;
    set_unescape_uri $u_sh $arg_sh;
    set_unescape_uri $u_sw $arg_sw;
    set_unescape_uri $u_cd $arg_cd;
    set_unescape_uri $u_lang $arg_lang;
    set_unescape_uri $u_utrace $arg_utrace;
    set_unescape_uri $u_account $arg_account;
  
    #打開日志
    log_subrequest on;
    #記錄日志到ma.log,實際應(yīng)用中最好加buffer,格式為tick
    access_log /path/to/logs/directory/ma.log tick;
  
    #輸出空字符串
    echo '';
}

要完全解釋這段腳本的每一個細節(jié)有點超出本文的范圍,而且用到了諸多第三方ngxin模塊(全都包含在OpenResty中了),重點的地方我都用注釋標(biāo)出來了,可以不用完全理解每一行的意義,只要大約知道這個配置完成了我們在原理一節(jié)提到的后端邏輯就可以了。

2.6 日志輪轉(zhuǎn)

真正的日志收集系統(tǒng)訪問日志會非常多,時間一長文件變得很大,而且日志放在一個文件不便于管理。所以通常要按時間段將日志切分,例如每天或每小時切分一個日志。我這里為了效果明顯,每一小時切分一個日志。我是通過crontab定時調(diào)用一個shell腳本實現(xiàn)的,shell腳本如下:

1
2
3
4
5
_prefix="/path/to/nginx"
time=`date +%Y%m%d%H`
  
mv ${_prefix}/logs/ma.log ${_prefix}/logs/ma/ma-${time}.log
kill -USR1 `cat ${_prefix}/logs/nginx.pid`

這個腳本將ma.log移動到指定文件夾并重命名為ma-{yyyymmddhh}.log,然后向nginx發(fā)送USR1信號令其重新打開日志文件。
然后再/etc/crontab里加入一行:

1
59  *  *  *  * root /path/to/directory/rotatelog.sh

在每個小時的59分啟動這個腳本進行日志輪轉(zhuǎn)操作。

2.7 測試

下面可以測試這個系統(tǒng)是否能正常運行了。我昨天就在我的博客中埋了相關(guān)的點,通過http抓包可以看到ma.js和1.gif已經(jīng)被正確請求:

圖6. http包分析ma.js和1.gif的請求

同時可以看一下1.gif的請求參數(shù):

圖7. 1.gif的請求參數(shù)

相關(guān)信息確實也放在了請求參數(shù)中。
然后我tail打開日志文件,然后刷新一下頁面,因為沒有設(shè)access log buffer, 我立即得到了一條新日志:

1
1351060731.360^A0.0.0.0^Awww.^Ahttp://www./^ACodingLabs^A^A1024^A1280^A24^Azh-CN^AMozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4^A4d612be64366768d32e623d594e82678^AU-1-1

注意實際上原日志中的^A是不可見的,這里我用可見的^A替換為方便閱讀,另外IP由于涉及隱私我替換為了0.0.0.0。
看一眼日志輪轉(zhuǎn)目錄,由于我之前已經(jīng)埋了點,所以已經(jīng)生成了很多輪轉(zhuǎn)文件:

圖8. 輪轉(zhuǎn)日志

3、日志統(tǒng)計分析

通過上面的分析和開發(fā)可以大致理解一個網(wǎng)站統(tǒng)計的日志收集系統(tǒng)是如何工作的。有了這些日志,就可以進行后續(xù)的分析了。本文只注重日志收集,所以不會寫太多關(guān)于分析的東西。
注意,原始日志最好盡量多的保留信息而不要做過多過濾和處理。例如上面的MyAnalytics保留了毫秒級時間戳而不是格式化后的時間,時間的格式化是后面的系統(tǒng)做的事而不是日志收集系統(tǒng)的責(zé)任。后面的系統(tǒng)根據(jù)原始日志可以分析出很多東西,例如通過IP庫可以定位訪問者的地域、user agent中可以得到訪問者的操作系統(tǒng)、瀏覽器等信息,再結(jié)合復(fù)雜的分析模型,就可以做流量、來源、訪客、地域、路徑等分析了。當(dāng)然,一般不會直接對原始日志分析,而是會將其清洗格式化后轉(zhuǎn)存到其它地方,如MySQL或HBase中再做分析。
分析部分的工作有很多開源的基礎(chǔ)設(shè)施可以使用,例如實時分析可以使用Storm,而離線分析可以使用Hadoop。當(dāng)然,在日志比較小的情況下,也可以通過shell命令做一些簡單的分析,例如,下面三條命令可以分別得出我的博客在今天上午8點到9點的訪問量(PV),訪客數(shù)(UV)和獨立IP數(shù)(IP):

1
2
3
awk -F^A '{print $1}' ma-2012102409.log | wc -l
awk -F^A '{print $12}' ma-2012102409.log | uniq wc -l
awk -F^A '{print $2}' ma-2012102409.log | uniq wc -l

其它好玩的東西朋友們可以慢慢挖掘。

4、Refer:

[1] GA的開發(fā)者文檔:

https://developers.google.com/analytics/devguides/collection/gajs/

[2] 一篇關(guān)于實現(xiàn)nginx收日志的文章:

http://blog./2011/11/%E4%BD%BF%E7%94%A8nginx%E8%AE%B0%E6%97%A5%E5%BF%97
[3] 關(guān)于Nginx可以參考:http://wiki./Main
[4] OpenResty的官方網(wǎng)站為:http://

[5] ngx_lua模塊可參考:https://github.com/chaoslawful/lua-nginx-module

[6] Google Analytics 網(wǎng)址的構(gòu)造:http://www./google-analytics-url-builder.html

[7] Beforeunload打點丟失原因分析及解決方案:http:///it/article/6804?f=wb

[8] beforeunload丟失率統(tǒng)計:

http://ued./blog/2012/11/beforeunload%E4%B8%A2%E5%A4%B1%E7%8E%87%E7%BB%9F%E8%AE%A1/

[9] 網(wǎng)站分析度量、意義以及不為人所知的(2)

http://www./metrics-and-its-back-story-2/

[10] Google Analytics(分析)數(shù)據(jù)收集 官方文檔

https://developers.google.com/analytics/devguides/collection/

[11] 網(wǎng)站分析——我們的數(shù)據(jù)準(zhǔn)確嗎?

http://www./%E7%BD%91%E7%AB%99%E5%88%86%E6%9E%90%E6%88%91%E4%BB%AC%E7%9A%84%E6%95%B0%E6%8D%AE%E5%87%86%E7%A1%AE%E5%90%97%EF%BC%9F/

[12] 為什么兩個監(jiān)測工具報告中的數(shù)據(jù)不同

http://www./%E4%B8%BA%E4%BB%80%E4%B9%88%E4%B8%A4%E4%B8%AA%E7%9B%91%E6%B5%8B%E5%B7%A5%E5%85%B7%E6%8A%A5%E5%91%8A%E4%B8%AD%E7%9A%84%E6%95%B0%E6%8D%AE%E4%B8%8D%E5%90%8C/

[13] Google Analytics 使用教程

http://wenku.baidu.com/view/390c59200722192e4536f626.html

[14] 站長統(tǒng)計、百度統(tǒng)計、騰訊統(tǒng)計、Google Analytics 哪一統(tǒng)計的數(shù)據(jù)相對準(zhǔn)確些?

http://www.zhihu.com/question/19955915

[15] 使用nginx記日志

http:///it/article/4861?f=wb#original

[16] 記錄一下互聯(lián)網(wǎng)日志實時收集和實時計算的簡單方案

http:///2gq4dp

[17] 南游記:WOT 2015“互聯(lián)網(wǎng)+”時代大數(shù)據(jù)技術(shù)峰會

http:///2015/11/29/south-trip/

[18] JSTracker 之前端異常數(shù)據(jù)采集

http:///blog/2015/10/28/jstracker-how-to-collect-data/

[19] JSTracker 之異常數(shù)據(jù)處理

http:///blog/2015/11/06/jstracker-data-processing/

[20] try catch 對代碼運行的性能影響

http:///blog/2015/10/28/try-catch-runing-problem/

注:本文http抓包使用Chrome瀏覽器開發(fā)者工具,繪制思維導(dǎo)圖使用Xmind,流程和結(jié)構(gòu)圖使用Tikz PGF

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多

    欧美精品日韩精品一区| 中文字幕乱码一区二区三区四区| 东京热男人的天堂社区| 国产精品成人又粗又长又爽| 亚洲天堂国产精品久久精品| 好吊妞视频免费在线观看| 99久久精品视频一区二区| 亚洲av专区在线观看| 麻豆剧果冻传媒一二三区| 日韩日韩欧美国产精品| 欧美日韩国内一区二区| 欧美偷拍一区二区三区四区 | 91偷拍裸体一区二区三区| 日本和亚洲的香蕉视频| 亚洲视频在线观看免费中文字幕| 亚洲欧美日本成人在线| 亚洲精品日韩欧美精品| 日韩黄色大片免费在线| 五月天丁香婷婷狠狠爱| 国产精品久久精品毛片| 99久久国产精品亚洲| 国产主播精品福利午夜二区| 日韩国产亚洲欧美另类| 高潮少妇高潮久久精品99| 亚洲免费视频中文字幕在线观看 | 免费亚洲黄色在线观看| 日本欧美一区二区三区高清| 久久精品国产亚洲av麻豆| 日本高清不卡一二三区| 精品欧美国产一二三区| 国产三级黄片在线免费看| 国产精品一区二区有码| 有坂深雪中文字幕亚洲中文| 午夜福利网午夜福利网| 久久偷拍视频免费观看| 日韩一区二区三区免费av| 国产一区二区三区口爆在线| 欧美区一区二区在线观看| 欧美国产日本免费不卡| 精品al亚洲麻豆一区| 99久久国产精品免费|