成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

優雅的讀取http請求或響應的數據

作者：戚銀
網絡 通信技術
從http.Request.Body或http.Response.Body中讀取數據方法或許很多，標準庫中大多數使用ioutil.ReadAll方法一次讀取所有數據，如果是json格式的數據還可以使用json.NewDecoder從io.Reader創建一個解析器，假使使用pprof來分析程序總是會發現bytes.makeSlice分配了大量內存，且總是排行第一，今天就來說下如何高效優雅的讀取http中的數據。

從 http.Request.Body 或 http.Response.Body 中讀取數據方法或許很多，標準庫中大多數使用 ioutil.ReadAll 方法一次讀取所有數據，如果是 json 格式的數據還可以使用 json.NewDecoder 從 io.Reader 創建一個解析器，假使使用 pprof 來分析程序總是會發現 bytes.makeSlice 分配了大量內存，且總是排行***，今天就這個問題來說一下如何高效優雅的讀取 http 中的數據。

[[256407]]

背景介紹

我們有許多 api 服務，全部采用 json 數據格式，請求體就是整個 json 字符串，當一個請求到服務端會經過一些業務處理，然后再請求后面更多的服務，所有的服務之間都用 http 協議來通信(啊， 為啥不用 RPC，因為所有的服務都會對第三方開放，http + json 更好對接)，大多數請求數據大小在 1K~4K，響應的數據在 1K~8K，早期所有的服務都使用 ioutil.ReadAll 來讀取數據，隨著流量增加使用 pprof 來分析發現 bytes.makeSlice 總是排在***，并且占用了整個程序 1/10 的內存分配，我決定針對這個問題進行優化，下面是整個優化過程的記錄。

pprof 分析

這里使用 https://github.com/thinkeridea/go-extend/blob/master/exnet/exhttp/expprof/pprof.go 中的 API 來實現生產環境的 /debug/pprof 監測接口，沒有使用標準庫的 net/http/pprof 包因為會自動注冊路由，且長期開放 API，這個包可以設定 API 是否開放，并在規定時間后自動關閉接口，避免存在工具嗅探。

服務部署上線穩定后(大約過了一天半)，通過 curl 下載 allocs 數據，然后使用下面的命令查看分析。

  1. $ go tool pprof allocs 
  2. File: xxx 
  3. Type: alloc_space 
  4. Time: Jan 25, 2019 at 3:02pm (CST) 
  5. Entering interactive mode (type "help" for commands, "o" for options) 
  6. (pprof) top 
  7. Showing nodes accounting for 604.62GB, 44.50% of 1358.61GB total 
  8. Dropped 776 nodes (cum <= 6.79GB) 
  9. Showing top 10 nodes out of 155 
  10.       flat  flat%   sum%        cum   cum% 
  11.   111.40GB  8.20%  8.20%   111.40GB  8.20%  bytes.makeSlice 
  12.   107.72GB  7.93% 16.13%   107.72GB  7.93%  github.com/sirupsen/logrus.(*Entry).WithFields 
  13.    65.94GB  4.85% 20.98%    65.94GB  4.85%  strings.Replace 
  14.    54.10GB  3.98% 24.96%    56.03GB  4.12%  github.com/json-iterator/go.(*frozenConfig).Marshal 
  15.    47.54GB  3.50% 28.46%    47.54GB  3.50%  net/url.unescape 
  16.    47.11GB  3.47% 31.93%    48.16GB  3.55%  github.com/json-iterator/go.(*Iterator).readStringSlowPath 
  17.    46.63GB  3.43% 35.36%   103.04GB  7.58%  handlers.(*AdserviceHandler).returnAd 
  18.    42.43GB  3.12% 38.49%    84.62GB  6.23%  models.LogItemsToBytes 
  19.    42.22GB  3.11% 41.59%    42.22GB  3.11%  strings.Join 
  20.    39.52GB  2.91% 44.50%    87.06GB  6.41%  net/url.parseQuery 

從結果中可以看出采集期間一共分配了 1358.61GB top 10 占用了 44.50% 其中 bytes.makeSlice 占了接近 1/10，那么看看都是誰在調用 bytes.makeSlice 吧。

  1. (pprof) web bytes.makeSlice 

 

優雅的讀取http請求或響應的數據

從上圖可以看出調用 bytes.makeSlice 的最終方法是 ioutil.ReadAll, (受篇幅影響就沒有截取 ioutil.ReadAll 上面的方法了)，而 90% 都是 ioutil.ReadAll 讀取 http 數據調用，找到地方先別急想優化方案，先看看為啥 ioutil.ReadAll 會導致這么多內存分配。

  1. func readAll(r io.Reader, capacity int64) (b []byte, err error) { 
  2.     var buf bytes.Buffer 
  3.     // If the buffer overflows, we will get bytes.ErrTooLarge. 
  4.     // Return that as an error. Any other panic remains. 
  5.     defer func() { 
  6.         e := recover() 
  7.         if e == nil { 
  8.             return 
  9.         } 
  10.         if panicErr, ok := e.(error); ok && panicErr == bytes.ErrTooLarge { 
  11.             err = panicErr 
  12.         } else { 
  13.             panic(e) 
  14.         } 
  15.     }() 
  16.     if int64(int(capacity)) == capacity { 
  17.         buf.Grow(int(capacity)) 
  18.     } 
  19.     _, err = buf.ReadFrom(r) 
  20.     return buf.Bytes(), err 
  21. } 
  22.  
  23. func ReadAll(r io.Reader) ([]byte, error) { 
  24.     return readAll(r, bytes.MinRead) 
  25. } 

以上是標準庫 ioutil.ReadAll 的代碼，每次會創建一個 var buf bytes.Buffer 并且初始化 buf.Grow(int(capacity)) 的大小為 bytes.MinRead, 這個值呢就是 512，按這個 buffer 的大小讀取一次數據需要分配 2~16 次內存，天啊簡直不能忍，我自己創建一個 buffer 好不好。

看一下火焰圖🔥吧，其中紅框標記的就是 ioutil.ReadAll 的部分，顏色比較鮮艷。

優雅的讀取http請求或響應的數據

優化讀取方法

自己創建足夠大的 buffer 減少因為容量不夠導致的多次擴容問題。

  1. buffer := bytes.NewBuffer(make([]byte, 4096)) 
  2. _, err := io.Copy(buffer, request.Body) 
  3. if err !=nil{ 
  4.     return nil, err 
  5. } 

恩恩這樣應該差不多了，為啥是初始化 4096 的大小，這是個均值，即使比 4096 大基本也就多分配一次內存即可，而且大多數數據都是比 4096 小的。

但是這樣真的就算好了嗎，當然不能這樣，這個 buffer 個每請求都要創建一次，是不是應該考慮一下復用呢，使用 sync.Pool 建立一個緩沖池效果就更好了。

以下是優化讀取請求的簡化代碼：

  1. package adapter 
  2.  
  3. import ( 
  4.     "bytes" 
  5.     "io" 
  6.     "net/http" 
  7.     "sync" 
  8.  
  9.     "github.com/json-iterator/go" 
  10.     "github.com/sirupsen/logrus" 
  11.     "github.com/thinkeridea/go-extend/exbytes" 
  12. ) 
  13.  
  14. type Adapter struct { 
  15.     pool sync.Pool 
  16. } 
  17.  
  18. func New() *Adapter { 
  19.     return &Adapter{ 
  20.         pool: sync.Pool{ 
  21.             New: func() interface{} { 
  22.                 return bytes.NewBuffer(make([]byte, 4096)) 
  23.             }, 
  24.         }, 
  25.     } 
  26. } 
  27.  
  28. func (api *Adapter) GetRequest(r *http.Request) (*Request, error) { 
  29.     buffer := api.pool.Get().(*bytes.Buffer) 
  30.     buffer.Reset() 
  31.     defer func() { 
  32.         if buffer != nil { 
  33.             api.pool.Put(buffer) 
  34.             buffer = nil 
  35.         } 
  36.     }() 
  37.  
  38.     _, err := io.Copy(buffer, r.Body) 
  39.     if err != nil { 
  40.         return nil, err 
  41.     } 
  42.  
  43.     request := &Request{} 
  44.     if err = jsoniter.Unmarshal(buffer.Bytes(), request); err != nil { 
  45.         logrus.WithFields(logrus.Fields{ 
  46.             "json": exbytes.ToString(buffer.Bytes()), 
  47.         }).Errorf("jsoniter.UnmarshalJSON fail. error:%v", err) 
  48.         return nil, err 
  49.     } 
  50.     api.pool.Put(buffer) 
  51.     buffer = nil 
  52.  
  53.     // .... 
  54.      
  55.     return request, nil 
  56. } 

使用 sync.Pool 的方式是不是有點怪，主要是 defer 和 api.pool.Put(buffer);buffer = nil 這里解釋一下，為了提高 buufer 的復用率會在不使用時盡快把 buffer 放回到緩沖池中，defer 之所以會判斷 buffer != nil 主要是在業務邏輯出現錯誤時，但是 buffer 還沒有放回緩沖池時把 buffer 放回到緩沖池，因為在每個錯誤處理之后都寫 api.pool.Put(buffer) 不是一個好的方法，而且容易忘記，但是如果在確定不再使用時 api.pool.Put(buffer);buffer = nil 就可以盡早把 buffer 放回到緩沖池中，提高復用率，減少新建 buffer。

這樣就好了嗎，別急，之前說服務里面還會構建請求，看看構建請求如何優化吧。

  1. package adapter 
  2.  
  3. import ( 
  4.     "bytes" 
  5.     "fmt" 
  6.     "io" 
  7.     "io/ioutil" 
  8.     "net/http" 
  9.     "sync" 
  10.  
  11.     "github.com/json-iterator/go" 
  12.     "github.com/sirupsen/logrus" 
  13.     "github.com/thinkeridea/go-extend/exbytes" 
  14. ) 
  15.  
  16. type Adapter struct { 
  17.     pool sync.Pool 
  18. } 
  19.  
  20. func New() *Adapter { 
  21.     return &Adapter{ 
  22.         pool: sync.Pool{ 
  23.             New: func() interface{} { 
  24.                 return bytes.NewBuffer(make([]byte, 4096)) 
  25.             }, 
  26.         }, 
  27.     } 
  28. } 
  29.  
  30. func (api *Adapter) Request(r *Request) (*Response, error) { 
  31.     var err error 
  32.     buffer := api.pool.Get().(*bytes.Buffer) 
  33.     buffer.Reset() 
  34.     defer func() { 
  35.         if buffer != nil { 
  36.             api.pool.Put(buffer) 
  37.             buffer = nil 
  38.         } 
  39.     }() 
  40.  
  41.     e := jsoniter.NewEncoder(buffer) 
  42.     err = e.Encode(r) 
  43.     if err != nil { 
  44.         logrus.WithFields(logrus.Fields{ 
  45.             "request": r, 
  46.         }).Errorf("jsoniter.Marshal failure: %v", err) 
  47.         return nil, fmt.Errorf("jsoniter.Marshal failure: %v", err) 
  48.     } 
  49.  
  50.     data := buffer.Bytes() 
  51.     req, err := http.NewRequest("POST", "http://xxx.com", buffer) 
  52.     if err != nil { 
  53.         logrus.WithFields(logrus.Fields{ 
  54.             "data": exbytes.ToString(data), 
  55.         }).Errorf("http.NewRequest failed: %v", err) 
  56.         return nil, fmt.Errorf("http.NewRequest failed: %v", err) 
  57.     } 
  58.  
  59.     req.Header.Set("User-Agent", "xxx") 
  60.  
  61.     httpResponse, err := http.DefaultClient.Do(req) 
  62.     if httpResponse != nil { 
  63.         defer func() { 
  64.             io.Copy(ioutil.Discard, httpResponse.Body) 
  65.             httpResponse.Body.Close() 
  66.         }() 
  67.     } 
  68.  
  69.     if err != nil { 
  70.         logrus.WithFields(logrus.Fields{ 
  71.             "url": "http://xxx.com", 
  72.         }).Errorf("query service failed %v", err) 
  73.         return nil, fmt.Errorf("query service failed %v", err) 
  74.     } 
  75.  
  76.     if httpResponse.StatusCode != 200 { 
  77.         logrus.WithFields(logrus.Fields{ 
  78.             "url":         "http://xxx.com", 
  79.             "status":      httpResponse.Status, 
  80.             "status_code": httpResponse.StatusCode, 
  81.         }).Errorf("invalid http status code") 
  82.         return nil, fmt.Errorf("invalid http status code") 
  83.     } 
  84.  
  85.     buffer.Reset() 
  86.     _, err = io.Copy(buffer, httpResponse.Body) 
  87.     if err != nil { 
  88.         return nil, fmt.Errorf("adapter io.copy failure error:%v", err) 
  89.     } 
  90.  
  91.     respData := buffer.Bytes() 
  92.     logrus.WithFields(logrus.Fields{ 
  93.         "response_json": exbytes.ToString(respData), 
  94.     }).Debug("response json") 
  95.  
  96.     res := &Response{} 
  97.     err = jsoniter.Unmarshal(respData, res) 
  98.     if err != nil { 
  99.         logrus.WithFields(logrus.Fields{ 
  100.             "data": exbytes.ToString(respData), 
  101.             "url":  "http://xxx.com", 
  102.         }).Errorf("adapter jsoniter.Unmarshal failed, error:%v", err) 
  103.         return nil, fmt.Errorf("adapter jsoniter.Unmarshal failed, error:%v", err) 
  104.     } 
  105.      
  106.     api.pool.Put(buffer) 
  107.     buffer = nil 
  108.  
  109.     // ... 
  110.     return res, nil 
  111. } 

這個示例和之前差不多，只是不僅用來讀取 http.Response.Body 還用來創建一個 jsoniter.NewEncoder 用來把請求壓縮成 json 字符串，并且作為 http.NewRequest 的 body 參數， 如果直接用 jsoniter.Marshal 同樣會創建很多次內存，jsoniter 也使用 buffer 做為緩沖區，并且默認大小為 512, 代碼如下：

  1. func (cfg Config) Froze() API { 
  2.     api := &frozenConfig{ 
  3.         sortMapKeys:                   cfg.SortMapKeys, 
  4.         indentionStep:                 cfg.IndentionStep, 
  5.         objectFieldMustBeSimpleString: cfg.ObjectFieldMustBeSimpleString, 
  6.         onlyTaggedField:               cfg.OnlyTaggedField, 
  7.         disallowUnknownFields:         cfg.DisallowUnknownFields, 
  8.     } 
  9.     api.streamPool = &sync.Pool{ 
  10.         New: func() interface{} { 
  11.             return NewStream(api, nil, 512) 
  12.         }, 
  13.     } 
  14.     // ..... 
  15.     return api 
  16. } 

而且序列化之后會進行一次數據拷貝：

  1. func (cfg *frozenConfig) Marshal(v interface{}) ([]byte, error) { 
  2.     stream := cfg.BorrowStream(nil) 
  3.     defer cfg.ReturnStream(stream) 
  4.     stream.WriteVal(v) 
  5.     if stream.Error != nil { 
  6.         return nil, stream.Error 
  7.     } 
  8.     result := stream.Buffer() 
  9.     copied := make([]byte, len(result)) 
  10.     copy(copied, result) 
  11.     return copied, nil 
  12. } 

既然要用 buffer 那就一起吧^_^，這樣可以減少多次內存分配，下讀取 http.Response.Body 之前一定要記得 buffer.Reset()， 這樣基本就已經完成了 http.Request.Body 和 http.Response.Body 的數據讀取優化了，具體效果等上線跑一段時間穩定之后來查看吧。

效果分析

上線跑了一天，來看看效果吧。

  1. $ go tool pprof allocs2 
  2. File: connect_server 
  3. Type: alloc_space 
  4. Time: Jan 26, 2019 at 10:27am (CST) 
  5. Entering interactive mode (type "help" for commands, "o" for options) 
  6. (pprof) top 
  7. Showing nodes accounting for 295.40GB, 40.62% of 727.32GB total 
  8. Dropped 738 nodes (cum <= 3.64GB) 
  9. Showing top 10 nodes out of 174 
  10.       flat  flat%   sum%        cum   cum% 
  11.    73.52GB 10.11% 10.11%    73.52GB 10.11%  git.tvblack.com/tvblack/connect_server/vendor/github.com/sirupsen/logrus.(*Entry).WithFields 
  12.    31.70GB  4.36% 14.47%    31.70GB  4.36%  net/url.unescape 
  13.    27.49GB  3.78% 18.25%    54.87GB  7.54%  git.tvblack.com/tvblack/connect_server/models.LogItemsToBytes 
  14.    27.41GB  3.77% 22.01%    27.41GB  3.77%  strings.Join 
  15.    25.04GB  3.44% 25.46%    25.04GB  3.44%  bufio.NewWriterSize 
  16.    24.81GB  3.41% 28.87%    24.81GB  3.41%  bufio.NewReaderSize 
  17.    23.91GB  3.29% 32.15%    23.91GB  3.29%  regexp.(*bitState).reset 
  18.    23.06GB  3.17% 35.32%    23.06GB  3.17%  math/big.nat.make 
  19.    19.90GB  2.74% 38.06%    20.35GB  2.80%  git.tvblack.com/tvblack/connect_server/vendor/github.com/json-iterator/go.(*Iterator).readStringSlowPath 
  20.    18.58GB  2.56% 40.62%    19.12GB  2.63%  net/textproto.(*Reader).ReadMIMEHeader 

哇塞 bytes.makeSlice 終于從前十中消失了，真的太棒了，還是看看 bytes.makeSlice 的其它調用情況吧。

  1. (pprof) web bytes.makeSlice 

 

優雅的讀取http請求或響應的數據

從圖中可以發現 bytes.makeSlice 的分配已經很小了， 且大多數是 http.Request.ParseForm 讀取 http.Request.Body 使用 ioutil.ReadAll 原因，這次優化的效果非常的好。

看一下更直觀的火焰圖吧，和優化前對比一下很明顯 ioutil.ReadAll 看不到了。

優雅的讀取http請求或響應的數據

優化期間遇到的問題

比較慚愧在優化的過程出現了一個過失，導致生產環境2分鐘故障，通過自動部署立即回滾才得以快速恢復，之后分析代碼解決之后上線才***優化，下面總結一下出現的問題吧。

在構建 http 請求時我分了兩個部分優化，序列化 json 和讀取 http.Response.Body 數據，保持一個觀點就是盡早把 buffer 放回到緩沖池，因為 http.DefaultClient.Do(req) 是網絡請求會相對耗時，在這個之前我把 buffer 放回到緩沖池中，之后讀取 http.Response.Body 時在重新獲取一個 buffer，大概代碼如下：

  1. package adapter 
  2.  
  3. import ( 
  4.     "bytes" 
  5.     "fmt" 
  6.     "io" 
  7.     "io/ioutil" 
  8.     "net/http" 
  9.     "sync" 
  10.  
  11.     "github.com/json-iterator/go" 
  12.     "github.com/sirupsen/logrus" 
  13.     "github.com/thinkeridea/go-extend/exbytes" 
  14. ) 
  15.  
  16. type Adapter struct { 
  17.     pool sync.Pool 
  18. } 
  19.  
  20. func New() *Adapter { 
  21.     return &Adapter{ 
  22.         pool: sync.Pool{ 
  23.             New: func() interface{} { 
  24.                 return bytes.NewBuffer(make([]byte, 4096)) 
  25.             }, 
  26.         }, 
  27.     } 
  28. } 
  29.  
  30. func (api *Adapter) Request(r *Request) (*Response, error) { 
  31.     var err error 
  32.     buffer := api.pool.Get().(*bytes.Buffer) 
  33.     buffer.Reset() 
  34.     defer func() { 
  35.         if buffer != nil { 
  36.             api.pool.Put(buffer) 
  37.             buffer = nil 
  38.         } 
  39.     }() 
  40.  
  41.     e := jsoniter.NewEncoder(buffer) 
  42.     err = e.Encode(r) 
  43.     if err != nil { 
  44.         return nil, fmt.Errorf("jsoniter.Marshal failure: %v", err) 
  45.     } 
  46.  
  47.     data := buffer.Bytes() 
  48.     req, err := http.NewRequest("POST", "http://xxx.com", buffer) 
  49.     if err != nil { 
  50.         return nil, fmt.Errorf("http.NewRequest failed: %v", err) 
  51.     } 
  52.  
  53.     req.Header.Set("User-Agent", "xxx") 
  54.  
  55.     api.pool.Put(buffer) 
  56.     buffer = nil 
  57.      
  58.     httpResponse, err := http.DefaultClient.Do(req) 
  59.      
  60.      
  61.     // .... 
  62.  
  63.     buffer = api.pool.Get().(*bytes.Buffer) 
  64.     buffer.Reset() 
  65.     defer func() { 
  66.         if buffer != nil { 
  67.             api.pool.Put(buffer) 
  68.             buffer = nil 
  69.         } 
  70.     }() 
  71.     _, err = io.Copy(buffer, httpResponse.Body) 
  72.     if err != nil { 
  73.         return nil, fmt.Errorf("adapter io.copy failure error:%v", err) 
  74.     } 
  75.  
  76.     // .... 
  77.      
  78.     api.pool.Put(buffer) 
  79.     buffer = nil 
  80.  
  81.     // ... 
  82.     return res, nil 
  83. } 

上線之后馬上發生了錯誤 http: ContentLength=2090 with Body length 0 發送請求的時候從 buffer 讀取數據發現數據不見了或者數據不夠了，我去這是什么鬼，馬上回滾恢復業務，然后分析 http.DefaultClient.Do(req) 和 http.NewRequest，在調用 http.NewRequest 是并沒有從 buffer 讀取數據，而只是創建了一個 req.GetBody 之后在 http.DefaultClient.Do 是才讀取數據，因為在 http.DefaultClient.Do 之前把 buffer 放回到緩沖池中，其它 goroutine 獲取到 buffer 并進行 Reset 就發生了數據爭用，當然會導致數據讀取不完整了，真實汗顏，對 http.Client 了解太少，爭取有空擼一遍源碼。

總結

使用合適大小的 buffer 來減少內存分配，sync.Pool 可以幫助復用 buffer， 一定要自己寫這些邏輯，避免使用三方包，三方包即使使用同樣的技巧為了避免數據爭用，在返回數據時候必然會拷貝一個新的數據返回，就像 jsoniter 雖然使用了 sync.Pool 和 buffer 但是返回數據時還需要拷貝，另外這種通用包并不能給一個非常貼合業務的初始 buffer 大小，過小會導致數據發生拷貝，過大會太過浪費內存。

程序中善用 buffer 和 sync.Pool 可以大大的改善程序的性能，并且這兩個組合在一起使用非常的簡單，并不會使代碼變的復雜。

 

責任編輯：未麗燕 來源： thinkeridea博客
數據HTTP服務
相關推薦

2023-11-08 09:49:19

Java實踐

2023-09-14 08:16:51

2019-11-18 15:50:11

AjaxJavascript前端

2023-12-28 08:22:33

響應數據轉換

2017-03-23 15:05:50

HTTP緩存Cookie

2017-03-23 14:51:21

HTTP緩存CDN緩存

2018-10-18 10:05:43

HTTP網絡協議TCP

2025-02-05 08:43:40

2024-04-15 16:11:33

C#HTTP請求.NET

2024-06-19 10:04:15

ifC#代碼

2009-06-04 10:41:52

Struts工作原理

2023-03-06 07:25:09

http響應頭ETag

2022-08-03 07:07:10

Spring數據封裝框架

2023-12-04 07:07:36

HTTP請求

2021-06-17 09:32:39

重復請求并發請求Java

2024-06-21 09:19:45

代碼接口重復請求開發

2021-07-27 14:50:15

axiosHTTP前端

2021-05-11 07:45:00

HTTPNode.jsCookie

2011-04-21 10:47:29

Webjavascript

2025-05-21 08:27:54

MCP模型上下文協議MCP服務器
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 欧美日韩国产高清视频 | ww 255hh 在线观看 | 97久久精品午夜一区二区 | 天天综合干 | 成人午夜毛片 | 国产小视频精品 | 精品国产18久久久久久二百 | 91毛片网| 亚洲国产成人精品女人 | 亚洲精品一区二区网址 | 国产97人人超碰caoprom | 精品欧美一区二区三区久久久 | 国产丝袜一区二区三区免费视频 | 国产福利资源在线 | 天天草草草 | 国产精品高潮呻吟久久 | 91在线播| 国产激情自拍视频 | 国产日韩一区二区三免费高清 | 视频二区| 日日骚av | 久久国产精品-国产精品 | 久久久做| 99免费| 久久不射电影网 | 亚洲网址在线观看 | 91精品久久久久久久久久 | 天天综合91 | 91中文字幕在线 | 在线a视频网站 | av手机免费在线观看 | а√中文在线8 | 欧美精品网 | 黄色三级免费网站 | 欧美日韩一 | 91免费版在线 | 一区二区三区亚洲 | av网站观看| 国产欧美一区二区三区免费 | 日韩视频在线一区二区 | 亚洲欧美日韩在线不卡 |