• はてなブックマーク
  • テクノロジー
  • QUICの実装はTCP並みの効率を実現できるか？ Fastly奥氏らがベンチマークを紹介
  • Twitterでシェア
  • Facebookでシェア

QUICの実装はTCP並みの効率を実現できるか？ Fastly奥氏らがベンチマークを紹介

テクノロジー カテゴリーの変更を依頼 記事元:www.publickey1.jp
適切な情報に変更
225 usersがブックマーク コメント25

    記事へのコメント25件

    • 注目コメント
    • 新着コメント
    kazuhooku
    kazuhooku publickeyでご紹介いただいた！ありがとうございます / ブコメにコメントしておくと、QUICのほうがロス耐性が強い（通信速度が速い）ことが前提にあって、弱点と懸念されていたCPUコストも問題ではない、という話です

    2020/05/11 リンク

    その他
    boxshiitake
    boxshiitake QUICの強みはパケロスが起きたときにある。TCPはロストした部分から後を全て再送しなくてはならないがQUICならロストした部分だけの再送で済む。モバイル回線は接続が途切れやすいので今の時代はQUICが向いている

    2020/05/11 リンク

    その他
    bootJP
    bootJP TCP並みなら微妙と言う反応あるけど、QUICはコネクションマイグレーションでIPが変わってもコネクションが切れないのである今後のモバイルネットワークで大事

    2020/05/11 リンク

    その他
    tyhe
    tyhe 捨てるほどの差が無いと言ってる人はTCPとUDPの違いを学ぶといいのよ。

    2020/05/11 リンク

    その他
    tmurakam
    tmurakam TCPにもSelective ACKはあるから、必要なフレームだけ再送できるよ

    2020/05/11 リンク

    その他
    YaSuYuKi
    YaSuYuKi 理想的なネットワーク条件で互角なら、より悪い条件(遅い転送速度、頻繁なパケットロス、輻輳など)への耐性次第で選択肢になりえる

    2020/05/11 リンク

    その他
    nakag0711
    nakag0711 わざわざtcpを捨てるほどの差ではないような…

    2020/05/11 リンク

    その他
    kuwayoshi
    kuwayoshi 書いた方のコメントの通り、長い年月をかけて最適化されて信頼のあるPC内のTCPスタックの処理速度に、新しいQUICの処理速度が案外検討、という記事。QUICは通信経路で強いのであって処理速度は同じくらいで十分でしょ。

    2020/05/11 リンク

    その他
    denqueue
    denqueue QUICは再送制御もTCPの反省を踏まえた設計になっている. SACK関係だとTCPのシーケンス番号による再送をやめたおかげで, スプリアス再送の検知やRTT計測の精度向上が期待される. https://tools.ietf.org/html/draft-ietf-quic-recovery-27

    2020/05/11 リンク

    その他
    camellow
    camellow 「TCO並みの効率を実現できるか？」ってレベルならわざわざQUIC使う必要なくね？少なくとも効率はいいから進めてるのかと思ってたが勘違いだったか。何のためにQUIC使いたいのかな/ブコメのみなさん解説ありがとう

    2020/05/11 リンク

    その他
    bonlife
    bonlife こないだReal World HTTPでも読んだな。QUICならTCPとTLSの二重のハンドシェイクが要らなくなるので初回接続が軽めで、TCPのHoLブロックもなくせる。以前はCPU負荷が2倍とか記事で読んだことあったけど、改善してるのね！

    2020/05/11 リンク

    その他
    nrtn
    nrtn HTTP/2によって多重化してるせいでHOLが致命的（特にモバイル環境で）なのでスループットが同等でもそれ以上に価値はあると思うけどなあ。

    2020/05/11 リンク

    その他
    kazuau
    kazuau ack待ちが問題になるんだったら(というか間違いなくそうだけど)ネットワークのlatencyがスループットに対して支配的だが、この記事では言及がないね。

    2020/05/11 リンク

    その他
    denqueue
    denqueue QUICは再送制御もTCPの反省を踏まえた設計になっている. SACK関係だとTCPのシーケンス番号による再送をやめたおかげで, スプリアス再送の検知やRTT計測の精度向上が期待される. https://tools.ietf.org/html/draft-ietf-quic-recovery-27

    2020/05/11 リンク

    その他
    aox
    aox 光速を超えるようなのは作れないんですかね

    2020/05/11 リンク

    その他
    tmurakam
    tmurakam TCPにもSelective ACKはあるから、必要なフレームだけ再送できるよ

    2020/05/11 リンク

    その他
    petitbang
    petitbang この程度じゃTCPから乗り換える意味あまりなくない？と思ったがパケットロスに強いのか。それならパケットロスが発生する条件下での速度比較も見たいところ。

    2020/05/11 リンク

    その他
    baronhorse
    baronhorse “QUIC仕様の推奨では、送信者、受信者ともに2パケットごとにAcknowledgementを返す” この条件だとどうなるのかな

    2020/05/11 リンク

    その他
    kuwayoshi
    kuwayoshi 書いた方のコメントの通り、長い年月をかけて最適化されて信頼のあるPC内のTCPスタックの処理速度に、新しいQUICの処理速度が案外検討、という記事。QUICは通信経路で強いのであって処理速度は同じくらいで十分でしょ。

    2020/05/11 リンク

    その他
    bootJP
    bootJP TCP並みなら微妙と言う反応あるけど、QUICはコネクションマイグレーションでIPが変わってもコネクションが切れないのである今後のモバイルネットワークで大事

    2020/05/11 リンク

    その他
    kkobayashi
    kkobayashi 「Ackを減らす、パケットをまとめる、パケットサイズを増やす」これ全部TCPでできるけど・・・／「ロストした部分だけの再送」ならSACKもあるし

    2020/05/11 リンク

    その他
    napsucks
    napsucks TCPはTSOなどハードウェアアクセラレーションも効くから容易に代替はできないと思うが、汎用のプロトコルなので特定用途でパフォーマンスをたたき出すにはUDPベースのほうがいいのかな。

    2020/05/11 リンク

    その他
    kazuhooku
    kazuhooku publickeyでご紹介いただいた！ありがとうございます / ブコメにコメントしておくと、QUICのほうがロス耐性が強い（通信速度が速い）ことが前提にあって、弱点と懸念されていたCPUコストも問題ではない、という話です

    2020/05/11 リンク

    その他
    surume000
    surume000 UDPの上位プロトコルということ？

    2020/05/11 リンク

    その他
    YaSuYuKi
    YaSuYuKi 理想的なネットワーク条件で互角なら、より悪い条件(遅い転送速度、頻繁なパケットロス、輻輳など)への耐性次第で選択肢になりえる

    2020/05/11 リンク

    その他
    kazema_tsu
    kazema_tsu TCPでいいじゃん！ってなってしまう・・・メリットを享受するのはまだまだ先ですか・・・

    2020/05/11 リンク

    その他
    boxshiitake
    boxshiitake QUICの強みはパケロスが起きたときにある。TCPはロストした部分から後を全て再送しなくてはならないがQUICならロストした部分だけの再送で済む。モバイル回線は接続が途切れやすいので今の時代はQUICが向いている

    2020/05/11 リンク

    その他
    knok
    knok クライアント側から見れば大した効果ないかもしれないけど、CDN業者側から見たらそれなりにうれしいのでは。ハードウェアの利用効率が上がるわけで

    2020/05/11 リンク

    その他
    mongrelP
    mongrelP 思ったより差がない…

    2020/05/11 リンク

    その他
    Shinwiki
    Shinwiki リアルタイム通信格闘ゲーム屋さんがすでにだいぶ知見を持ってると思うけど。RUDP的な

    2020/05/11 リンク

    その他
    camellow
    camellow 「TCO並みの効率を実現できるか？」ってレベルならわざわざQUIC使う必要なくね？少なくとも効率はいいから進めてるのかと思ってたが勘違いだったか。何のためにQUIC使いたいのかな/ブコメのみなさん解説ありがとう

    2020/05/11 リンク

    その他
    tyhe
    tyhe 捨てるほどの差が無いと言ってる人はTCPとUDPの違いを学ぶといいのよ。

    2020/05/11 リンク

    その他
    lirlia
    lirlia ドラマ、シリコンバレーのように、プロトコルの改善ではなくデータの超圧縮による転送データ量の削減をお願いします。

    2020/05/11 リンク

    その他
    nakag0711
    nakag0711 わざわざtcpを捨てるほどの差ではないような…

    2020/05/11 リンク

    その他
    gomer-pyle
    gomer-pyle 個人で使う分には体感出来なそうだけど、普及したら世界的な帯域はぐっと減ったりするのかな。

    2020/05/11 リンク

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック！
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    QUICの実装はTCP並みの効率を実現できるか？ Fastly奥氏らがベンチマークを紹介

    現在標準化が進められている次世代HTTPの「HTTP/3」は、トランスポートプロトコルとして「QUIC」と呼ば...

    ブックマークしたユーザー

    • vcc2022/06/16 vcc
    • quodius2021/04/23 quodius
    • thotentry_hatebu1972020/12/11 thotentry_hatebu197
    • dandelion2939492020/11/26 dandelion293949
    • bluescreen2020/07/09 bluescreen
    • igrep2020/06/17 igrep
    • ymm1x2020/05/22 ymm1x
    • nobusue2020/05/18 nobusue
    • kawasin732020/05/16 kawasin73
    • ogawa00712020/05/14 ogawa0071
    • makaya2020/05/14 makaya
    • zetta19852020/05/14 zetta1985
    • yyamano2020/05/14 yyamano
    • diveintounlimit2020/05/13 diveintounlimit
    • tanakaBox2020/05/13 tanakaBox
    • lEDfm4UE2020/05/13 lEDfm4UE
    • cubed-l2020/05/12 cubed-l
    • aishite7732020/05/12 aishite773
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事

    はてなブックマーク

    公式Twitter

    はてなのサービス

    • App Storeからダウンロード
    • Google Playで手に入れよう
    Copyright © 2005-2025 Hatena. All Rights Reserved.
    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy