青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

3d Game Walkman

3d圖形渲染,網絡引擎 — tonykee's Blog
隨筆 - 45, 文章 - 0, 評論 - 309, 引用 - 0
數據加載中……

返璞歸真,網絡傳輸——結構體還是序列化?

雖然,網絡編程里面的數據傳送推薦用序列化,但我不用,還是選擇結構體(返璞歸真),有以下幾點理由:
1.跨平臺問題:
  序列化確實可以很好的跨語言平臺,可大多數網絡游戲不需要跨語言平臺

2.別以為有了序列化就不需要結構體
  表面上序列化代碼量小,按順序讀和寫char int short LPCSTR ... 就好,邏輯對象寫不寫都無所謂,那就是大錯而特錯了
  待序列化的對象發送前的結構還是不可省略的序列化的過程就是 object->(按一定順序拆分)write->bytes->(按拆分順序組裝)read->object的過程
 其實object還是不能省略,很多人寫網絡程序不注重邏輯對象結構,收到的一堆bytes按一定順序讀和寫就完事了,這樣雖然靈活,但缺乏結構,容易造成混亂,調試起來是災難
   所以結構體(或類)還是省略不了的,所以:別以為有了序列化,就不需要結構體了。

3.結構體存在內存對齊和CPU不兼容的問題,可以避免
  的確結構體是有內存對齊的問題,存在兼容性問題,我可以選擇pack(1)把內存對齊給關閉掉,避免兼容性問題,既然選擇了iocp就不打算跨平臺了,可以避免結構體平臺兼容的問題

4.結構體調試起來方便很多,減少內存拷貝,效率高
  不用序列化可write和read的過程就不需要過多考慮(少寫太多代碼了),read write 就好像現代社會每個人每天都要穿衣服和脫衣服一樣,原始社會需要嗎?其實人類進化到原始裸奔狀態才是最爽快的:)
  但還是要說句公道話:有人說序列化編碼解碼read write 需要耗費資源, 誠然這個過程基本等于賦值和內存拷貝,那點效率損失主要還在內存拷貝上,這點效率損失很小,不能作為序列化的缺點,當然如果涉及到數據加密那將是另外一個話題

5.結構體貌似呆板,發送數據限制多,發送變長數據就不方便,數據組織起來也不靈活
  我想這是很多人拋棄結構體,選擇用序列化方式發送和接受數據的一個很重要的原因
  但:其實對于變長結構(子結構也是變長)的問題,用結構體來實現的確很麻煩,但并不代表不能實現
  我已經實現了,而且讀和寫變長子結構體嵌套任意多層都不成問題,可以存儲復雜變長的數據結構,
  數據就如同能自動序列化一樣方便,這個應該是技術難點,但細心去做是可以實現的

6.關于結構體指針
  游戲里面要發送的數據內存事先分配好的,不存在指針,深度復制更不用考慮,所以內存拷貝不會出錯
  如果用到指針即使用序列化來實現也會面臨同樣的問題也占不了多少便宜,由于C++這們語言的特點,
  不象java那樣有個標準實現,對于序列化本身沒有一個統一的標準,所以可想而知,有人說:boost有它的序列化的實現
  其實那個實現不見得就合適你自己,如果真要做序列化,編碼和解碼的仿照那個過程自己寫才最為牢靠,
  哪些指針對應的內存需要序列化那些不需要序列化,是個邏輯結構,需要自己說了算才好(好像扯遠了點)
  說回游戲數據,既然不用需要他用到指針,結構體用來發送數據也沒問題的

7 平臺擴充問題
  退一萬步的說:換了語言就基本上換了客戶端,客戶端的數據組織形式都要重寫
  實在不行還可以考慮用xml json 編碼等等一些跨平臺的解決方案,現在所寫的結構體是可以用來做數據接收的,只是發送的不再是結構體而已

8.綜上所述
  如果需要跨語言平臺,不用序列化(二進制流或xml, json文本等等)根本無法實現
  序列化的優點還是非常多的.如果主要是跨平臺和語言自定義讀寫規則,根據需要讀寫對象的某一部分數據,
  空間浪費少,不存在內存對齊問題等諸多優點,缺點就是拐彎抹角,代碼量大,調試不方便


權衡了良久
  數據如果能組織的合理,而且沒有跨語言平臺的要求,用結構體也未嘗不可,畢竟數據發送直來直去還是方便些,減少內存拷貝,效率也高了很多
  特別是調試起來容易太多了,衡量利弊我還是放棄了序列化,選擇了原始的結構體,只是難在數據的組織(好在基本已經克服了)

我知道:序列化很好很強大,很多網絡程序高手根本不屑于直接發一個邏輯結構體,用這種方式就好象是旁門左道,狗肉上不了大雅之堂一樣,狗肉還是很多人喜歡吃的嘛,:)。

我還是返璞歸真選擇了結構體

一句話:物盡其用,用的恰當,夠用就好。

如果有什么不對,敬請拍磚,莫要客氣

posted on 2008-02-17 12:53 李侃 閱讀(8294) 評論(30)  編輯 收藏 引用 所屬分類: 網絡模塊

評論

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

缺點就是拐彎抹角,代碼量大?
我的結論恰恰相反, 使用序列化的最大好處是簡化編程, 以及將來的可擴展性,
至于調試, 對于這種網絡程序,如果再加上多線程,是很難調試的,而這種你所說的結構體簡直是bug的溫床, 所以為了保證可靠性,一般都是用命令錄制回放來進行測試的.
2008-02-17 13:48 | eXile

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

只要封裝的好,怎么會是BUG的溫床呢?
我的結構體測試過了,作為容器,內部嵌套子容器,再套N個變長結構體或子結構體都沒問題,比序列化方便多了。

因為有了這個實現,我才有這個底氣寫這篇文的,要不然我早用傳統方式了
2008-02-17 14:38 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

呵呵, 那就具體探討一下, 比如發送一個用戶名列表, 這是一個字符串的容器, 用序列化大致實現起來就是以下樣子:
std::vector<std::string> user_names;
archive ar;
if (ar.serialize(user_names)) socket.send(ar.data(), ar.size());

不知道你是怎么實現的, 歡迎探討.
2008-02-17 15:52 | eXile

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

CollectionPack collection;

StringPack p1;
strcpy(p.buffer, "jack");

StringPack p2;
strcpy(p2.buffer, "cat");

collection.appendPack(p1);
collection.appendPack(p2);

socket.send(collection, collection.size());

遍歷collection代碼大致如下:

void visttest(CollectionPack * c)
{
BasePack *p = 0;
while(c->next(&p))
{
if(p->type==ROLESIMPLEINFO_PACK)
{
RoleInfoSimplePack * aaa = (RoleInfoSimplePack *) p;
printf("%s \r\n", aaa->username);
} else if(p->type==LOGIN_PACK)
{
LoginPack * aaa = (LoginPack *) p;
printf("%s \r\n", aaa->username);
} else if(p->type == STRING_PACK)
{
StringPack *aaa = (StringPack *) p;
printf("%s \r\n", aaa->buffer);
}
else if(p->type == COLLECTION_PACK) //帶嵌套的COLLECTION_PACK
{
CollectionPack *t=(CollectionPack *)p;
visttest(t); //遞歸方式
// return;
}
}
}
2008-02-17 17:14 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?[未登錄]  回復  更多評論   

扯什么蛋
序列化局部上還是結構體。
有什么區別。
2008-02-17 17:23 | 小白

# re: 返璞歸真,網絡傳輸——結構體還是序列化?[未登錄]  回復  更多評論   

我覺得沒事干的話,最好寫一些有技術含量的東西。。。。
2008-02-17 17:24 | 小白

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   


object->(按一定順序拆分)write->bytes->(按拆分順序組裝)read->object

這才是序列化,和結構體直接發送的區別你都不知道?

樓上的正如你的名字“小白”一個
2008-02-17 17:29 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

其實你的設計就是最簡單的序列化實現.
不過用較好的序列化庫對于接收時就簡單多了:

std::vector<std::string> user_names;
in_archive ar(received_data, received_size);
if (ar.serialize(user_names)) visit(user_names);

在serialize函數里包含了各種異常情況處理, 比如錯誤的數據, 字符串長度異常,而像你的要完全自己處理, 那太復雜了, 這正是我所說的容易產生bug的地方.
2008-02-17 18:16 | eXile

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

結構體還是序列化
不是一個概念.
2008-02-17 18:19 | WXX

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

@WXX
其實lz所說的結構體指的把網絡數據看作是POD數據類型來處理, 這樣來簡化處理過程(當然在我看來, 這只能把處理過程搞得更復雜), 而序列化把網絡數據看作二進制流或文本流. 從這個角度來談論這個問題的.
2008-02-17 18:51 | eXile

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

我得要把標題改一下才好。

網絡數據,以結構體的方式直接傳送還是轉化成特定字節順序形式來傳送。
我當然知道傳統方式是采用樓上的方法。我只是想打破常規。

我的出發點是想自定義一個容器,相當于一個SmartStruct能裝下各種各樣的東西,其實這本身就相當于在序列化了,只是和復雜的序列化過程還是有些的差異而已
說來說去就是數據的字節組織形式是按原樣收發,還是變個特定順序收發
真不好意思,這篇文章確實是有些小小的混淆概念。



至于eXile 所說,數據驗證這些目前還沒有去考慮
2008-02-17 19:09 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

最好的方法還是模擬rpc的解決方案,利用idl解析器自動生成序列化,只是這需要用lex/yacc方面的咚咚,
tao,ice等都有原代碼可借鑒。
2008-02-18 17:32 | 游客

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

簡單的結構是可以,如果結構中有指針呢?或者有帶虛函數的object呢?
2008-02-18 18:00 | giscn

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

游戲里面發送的數據,并不需要包含指針和虛函數的vtable,所以我才敢這樣去做,僅僅是針對游戲數據通訊的需求而已。

不過這幾天,再三思量,看來不能圖一時痛快,太早這樣斷言
我的做法,前人應該也用過,目前可能夠用,將來也未必如此。

為了擴展性和高質量的代碼,我現在試試用自定義序列化的方式來做。
這兩天認真閱讀了看了前人寫的一些服務器端的代碼,感受頗多

只是覺得最大的問題是為了要提高效率還得要盡可能減少內存拷貝和動態內存的創建和銷毀這也是個挑戰。如果搞的不好,看似強大的序列化過程在負載嚴重的服務器上就沒效率可言了。

我之前面的做法雖然不優雅,但讀數據就是對象,少了解碼就不存在內存拷貝的過程了,也無需額外再去創建一個對象,效率方面應該是很高的

所以...,還是想再好好想想一個折中的方案,結合各自的優點。

2008-02-19 08:41 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

如果沒有指針和vtable, 兩者的差別也不是特別大了,傳結構體是可行的,你后面所說的如何減少動態創建和銷毀開銷確實是要點,也有辦法解決。

折中的辦法已經有啊:用序列化的語義,內部直接傳內存塊
2008-02-19 10:05 | giscn

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

跨機器傳object始終都要用一種序列化的方式,直接傳內存塊只是實現細節,方法之一。你說的SmartStruct應該是一種OO的思路,基本的Object 就可作為SmartStruct,但這樣做避免不了new delete, 如果將smartStruct 設計成union, 很顯然局限性很大。傳統的C語言的做法最直接,只要將繁瑣的switch去掉即可
2008-02-19 10:21 | giscn

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

用序列化的語義,內部直接傳內存塊?

是不是:接收數據的時候,省略掉重新組裝成對象這一步?這也是個思路

效率是高了,只是缺少了最終接收的對象,以字節的方式處理字節塊的語意的邏輯就不很直觀了,也是件繁瑣的事情。
2008-02-20 23:32 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

這兩天,我把序列化的庫重新寫了一遍,已經能支持基本數據類型,字符串和Stl的list vector set map 等等了...方便是方便,但想想,還是存在上面的問題,最終接收成對象的時候,少不了分配內存(創建對象) -> 數據拷貝->處理對象->釋放對象 (我想這是個可能會成為將來的一個性能瓶頸),對此我真的是耿耿于懷

如果直接去處理語意的內存塊,真的又很是麻煩。
2008-02-20 23:38 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

數據拷貝是不可避免的,而且一般對效率影響不大,主要還是內存管理上作一些優化,比如使用內存池。
2008-02-20 23:38 | eXile

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

恩,也是,最重要的是要找到重大的性能的瓶頸在哪里,也許我想太多了。
明天我再從群里找幾個人來幫我看看這個帖,希望能多些經驗方面的交流
2008-02-20 23:54 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

按需編程
結構體,簡單快速
序列化,需要寫序列化代碼, 效率也不差
還有另外一種, 就是簡單重新計算一下長度,
對于只有最后一個變長的包, 這樣又快又簡單

簡單寫個例子:
pk1
{
int a;
}

pk2
{
int a;
int b_len;
char b[10000];
}

pk3
{
AA a; //AA是復雜的變長因素類
}

pk1適合于結構體傳送
pk2適合于改變一下包長度
pk3適合于序列化

那不如稍加改造
pk1
{
int a;
}

pk2
{
int a;
int b_len;
char b[10000];
int GetLength()
{
return sizeof(*this) - sizeof(b) + b_len;
}
}

pk3
{
AA a; //AA是復雜的變長因素類
void Serialize(Stream& s);
bool DeSerialize((Stream& s);
}

那么發消息函數為
template<T>
SendMsg (T* pkt)
{
__if_exist(T::Serialize)
{
Stream a;
pkt->Serialize(&a);
Send(a->GetBuffer(), a->GetBufferLength());
}
__if_not_exist(T::Serialize)
{
__if_exist(T::CalcLength)
{
Send(Pkt,pkt->GetLength());
}
__if_not_exist(T::CalcLength)
{
Send(Pkt, sizeof(T));
}
}
}
接受的時候反序列化就不寫了, 類似的

這樣不是又快有簡單嗎?
2009-01-11 13:06 | llxisdsh

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

補充一下:
上面的
Stream a;
可以寫成靜態變量 或者 線程靜態變量, 這樣就沒有構建開銷了

2009-01-11 13:21 | llxisdsh

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

如何方便健壯就怎么寫,各有優缺,權衡不宜罷了.
2009-01-17 17:35 | timlly

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

這帖子快一年了,回頭看看,還真是感觸頗多啊
后來我還是自己寫了一套序列化的庫,完全支持stl + zlib字節壓縮的的序列化庫,最終還是沒有采用結構體的方式

自己寫的這套庫工作了很久了,也是我的IO和網絡流的底層,用起來還是很方便的,足夠了
2009-01-18 10:55 | 李侃

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

隨便搜索看到的這個文章,本意是想找個 Java CLIENT 和 C++服務端(使用結構體) 的 通信解決方案。

我都不明白,你們為什么在考慮 什么 效率??你們明白效率的 瓶頸在什么地方???難道你的效率 瓶頸不在 網卡處理能力,不在使用的網絡帶寬,反而在 內存上面???難道你的效率 是 SBB 的使用 單機完成的???高流量的應用,哪一個不是 分布式,冗余式??在 基礎編程 水平一致的情況下。。你損失的那么點內存效率。。算什么,性能能相差多少??

搞不懂,程序是 人寫的,是給人用的。不去講究 快速開發,不去講究 調試靈活,不去考慮設計是否能 迅速的在需求改變的時候 進行調整。不去考慮穩定性。偏偏非得考慮 雜七雜八的莫名其妙的因素。。

你可能有很好的編程水平。不過,你不是一個好的程序員。因為你考慮的方向錯誤了。而沒有正確思維方式去寫程序,充其量只是說是一個 高級碼工。
2009-11-25 12:00 | XXXMAN

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

我也認為使用結構體傳輸不錯。
2010-01-16 19:28 | KongQue

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

將數據包序列化后,怎么知道序列化后的長度。接收方有可能遇到粘包問題,怎么解決呢?是不是發送方在發送序列化數據之前還要在做些處理?
2010-06-13 22:04 | JustCodeIT

# re: 返璞歸真,網絡傳輸——結構體還是序列化?[未登錄]  回復  更多評論   

XXXMAN 就是一個2B
2010-07-14 16:35 | TH

# re: 返璞歸真,網絡傳輸——結構體還是序列化?  回復  更多評論   

小弟看了上面各位大蝦的評論,受益匪淺.但是我還是想不明白,如果按樓主說,只是為了效率,為什么在游戲中定義對像呢,直接用原始結構體+函數效率此不是很好,本人覺得效率是重要,但維護更重要的.
2010-10-10 22:45 | 傾風

# re: 返璞歸真,網絡傳輸——結構體還是序列化?[未登錄]  回復  更多評論   

誤人子弟。你不手動序列化但實現了ISerializible的對象在網絡傳輸時還是會自動序列化的。比如在使用webservices數據傳輸時,大數據量的數據在手動序列化后的傳輸效率要比自動序列化快很多。
2011-06-30 10:23 | yuan
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲国产精品一区二区久| 激情综合自拍| 午夜精彩视频在线观看不卡| 亚洲视频播放| 国产一区二区三区不卡在线观看| 久久精品国产精品亚洲| 久久久久五月天| 日韩一区二区精品| 中文网丁香综合网| 国产亚洲精品福利| 欧美成人午夜免费视在线看片| 欧美黑人多人双交| 亚洲欧美国产77777| 久久动漫亚洲| 91久久夜色精品国产九色| 亚洲乱码精品一二三四区日韩在线| 欧美激情影音先锋| 亚洲天堂免费观看| 激情一区二区三区| 99视频日韩| 激情久久中文字幕| 一本不卡影院| 在线精品视频一区二区三四| 亚洲精品日韩在线| 国内精品久久久久久久果冻传媒 | 欧美国产先锋| 国产精品扒开腿做爽爽爽软件| 久久综合久久美利坚合众国| 欧美亚一区二区| 欧美wwwwww| 国产目拍亚洲精品99久久精品| 欧美丰满高潮xxxx喷水动漫| 国产精品日韩电影| 亚洲日本电影在线| 狠狠狠色丁香婷婷综合久久五月| 99在线观看免费视频精品观看| 激情亚洲网站| 午夜视频精品| 亚洲小视频在线观看| 免费看成人av| 久久夜色精品亚洲噜噜国产mv| 国产精品s色| 亚洲激情视频在线| 亚洲电影免费| 欧美亚洲视频在线观看| 亚洲免费在线视频一区 二区| 免费一级欧美在线大片| 榴莲视频成人在线观看| 国产精品亚洲一区| 亚洲视频综合在线| 亚洲图片自拍偷拍| 欧美精品久久久久a| 亚洲第一精品福利| 亚洲国产日韩在线一区模特| 久久精品中文字幕免费mv| 久久精品视频免费| 国产视频在线观看一区二区| 亚洲欧美日韩精品一区二区 | 一区二区三区 在线观看视| 美女露胸一区二区三区| 免费不卡在线视频| 在线不卡中文字幕| 快播亚洲色图| 欧美高清在线视频| 91久久黄色| 欧美风情在线观看| 亚洲人成网站在线播| 一区二区三区欧美| 国产精品二区三区四区| 亚洲一区国产精品| 久久激情综合| 黑丝一区二区| 欧美大片免费| 99精品国产福利在线观看免费| 在线视频精品一| 国产精品亚洲а∨天堂免在线| 亚洲女ⅴideoshd黑人| 欧美激情片在线观看| 香蕉av777xxx色综合一区| 99综合在线| 国产精品女主播在线观看| 亚洲欧美激情在线视频| 久久深夜福利免费观看| 亚洲欧洲在线一区| 欧美午夜精品一区| 欧美一区免费| 欧美激情一二区| 亚洲欧美日韩精品久久久| 国模吧视频一区| 欧美国产日韩一区| 亚洲综合国产| 免费在线日韩av| 亚洲一区二区三区影院| 激情欧美亚洲| 欧美色123| 久久久一区二区| 一区二区三区视频在线| 免费精品99久久国产综合精品| 日韩一级黄色大片| 国产又爽又黄的激情精品视频| 欧美成人福利视频| 欧美一级欧美一级在线播放| 亚洲国产精品一区二区尤物区 | 在线日韩av永久免费观看| 欧美午夜美女看片| 久久亚洲一区二区| 亚洲女同精品视频| 亚洲国产三级| 久久婷婷一区| 亚洲欧美日韩国产一区| 亚洲国产欧美在线| 国产欧美丝祙| 欧美视频三区在线播放| 久久一区二区视频| 性久久久久久| 亚洲无线一线二线三线区别av| 欧美激情一区二区三区在线视频| 久久国产精品久久久久久| 9i看片成人免费高清| 在线看日韩欧美| 国产一区二区黄色| 国产精品入口福利| 欧美色道久久88综合亚洲精品| 久久青青草综合| 欧美在线999| 亚洲欧美一区二区激情| 亚洲香蕉网站| 正在播放亚洲| 亚洲网站视频| 中文有码久久| 亚洲视频一区二区免费在线观看| 亚洲国产精品传媒在线观看| 免费视频最近日韩| 美女啪啪无遮挡免费久久网站| 久久精品国产成人| 久久成人精品一区二区三区| 欧美一区1区三区3区公司| 亚洲一区二区在线看| 亚洲一二三四久久| 亚洲尤物在线| 在线综合亚洲欧美在线视频| 99www免费人成精品| 一本高清dvd不卡在线观看| 亚洲精品美女在线观看| 亚洲人成毛片在线播放| 亚洲美女黄色| 亚洲免费精彩视频| 一区二区毛片| 午夜国产精品视频免费体验区| 午夜视黄欧洲亚洲| 欧美在线视频免费观看| 久久精品国产2020观看福利| 久久久亚洲精品一区二区三区| 久热综合在线亚洲精品| 亚洲国产婷婷香蕉久久久久久99 | 欧美成人精品在线播放| 欧美国产日韩一二三区| 欧美日韩午夜视频在线观看| 欧美视频二区| 国产综合色在线视频区| 亚洲国产成人久久| 一本色道久久加勒比88综合| 亚洲男人第一av网站| 欧美综合第一页| 欧美高清视频免费观看| 一本色道久久综合亚洲精品高清| 亚洲永久免费av| 久久亚洲综合色| 欧美日韩视频在线观看一区二区三区| 国产精品家教| 在线播放一区| 亚洲欧美文学| 免费黄网站欧美| 一区二区三区免费网站| 久久精品亚洲精品| 欧美日韩国产免费观看| 国产一区在线看| aⅴ色国产欧美| 久久免费国产精品| 日韩特黄影片| 久久人人九九| 国产精品日韩精品欧美精品| 亚洲福利av| 久久成人免费视频| 亚洲免费观看视频| 葵司免费一区二区三区四区五区| 欧美视频四区| 亚洲精品婷婷| 久久伊人亚洲| 亚洲免费在线电影| 欧美日韩成人综合| 激情综合网激情| 欧美一区在线视频| 99视频+国产日韩欧美| 久久偷窥视频| 黄色成人小视频| 欧美在线影院在线视频| 一本色道久久88精品综合| 美女网站久久| 黑人一区二区三区四区五区|