CEDEC 2025 『ゲームにおけるリアルタイム通信への QUIC導入事例の紹介』

ゲームにおけるリアルタイム通信への
QUIC導入事例の紹介
株式会社セガ竹原涼
松崎大
藤村隆史

➢ 撮影・SNS投稿OK
➢ 後日CEDILで資料を公開
➢ 質疑はAsk The Speakerにて
• 資料に記載されている会社名、システム名、製品名、サービス名は各社の登録商標または商標です

➢ TCPやUDP等の従来のプロトコルを改善
➢ UDPベース
➢ 2021年5月27日にRFC 9000として策定
➢ 最新のHTTPバージョンのHTTP/3でも採用
QUICの概要
HTTP/3
QUIC
UDP

➢ Head of Line Blocking (HoLB)
➢ IP アドレス変更時等ハンドシェイクやり直し
➢ パケットロス検出の仕組みがイマドキではない
ゲームにおける問題点(TCP, HTTP)
例 : HTTP の Head of Line Blocking

➢ 順序保証や暗号化の拡張を行う場合は自前
➢ 標準プロトコルが無い
➢ 多くの場合TCPを併用になり実装が煩雑になる
➢ 輻輳制御の仕組みがない
ゲームにおける問題点(UDP)

1. QUICの仕様やユースケースの共有
2. Sonic Rumbleの事例紹介
3. “SPHINGO” およびその採用タイトル事例紹介
4. 社内の取り組みの紹介
目次

自己紹介
技術本部開発技術部
竹原涼
【登壇歴】
CEDEC 2023 「CRI ADXプロファイラー活用によるサウンドQAの自
動化・可視化に関する取り組みの紹介」
CEDEC 2021 「ダウンロード時間を大幅減！～大量のアセットをさば
く高速な実装と運用事例の共有～」
CEDEC 2021 「Android iOS 実機上での自動テストをより楽に有意義
にする為に～端末管理・イメージ転送・動画記録等の周辺情報のノウ
ハウ共有～」
リアルタイムプロトコル趣味勢

「ゲームならでは」の視点に
フォーカスした
QUICの仕様やユースケースの共有

QUICのゲームに適した仕様

➢ Connection Migration
➢ ストリームレイヤーのHoLBの克服
➢ パケロス耐性の向上
➢ TCPベースの機能を搭載
➢ ユーザランドでの実装
➢ TLSを統合
ゲームに適した仕様
HTTP/3
QUIC
UDP
TLS 1.3

➢ コネクションをIDベースで管理
➢ IPアドレス・ポート変更時に維持可能
➢ パス検証 (切り替え時のネットワークの検証)
➢ パスが有効か
➢ セキュリティ検証
Connection Migration (概要) 家庭用
スマホ

スマホや携帯機のネットワーク切り替わり時にも
そのままゲーム可能
➢ Wi-Fiからキャリア(4G,5G)
➢ 4G ← → 5G
Connection Migration (影響) 家庭用
スマホ
Wi-Fi
4G
5G
帰宅/フリースポット
等で切り替わる
移動中等に不安定に
なることがある

事例紹介は
“SPHINGO” およびその採用タイトル事例紹介
にて実施
Connection Migration (事例) 家庭用
スマホ

QUICのゲームに適した拡張

➢ QUIC Datagram
➢ QMux (QUIC On Stream)
➢ WebTransport
➢ Media over QUIC Transport (draft)
➢ WebSocket over HTTP/3
QUICのゲームに適した拡張

An Unreliable Datagram Extension to QUIC
➢ QUICの到達保証(再送)を無くす拡張
➢ ACKは返る
➢ UDPに近い運用が可能になる
QUIC Datagram (概要) 家庭用
スマホ
クライアント
サーバ
ACK ACK
④ (③は再送しない)
Datagram
① ② ③

➢ リアルタイム性が特に高いものにも採用可能に
➢ 到達保証が必要な場合にもQUICで実装を一本化
➢ TCPやRUDP等と併用実装しないでよくなる
➢ RFC発行済み (9221)
QUIC Datagram (影響) 家庭用
スマホ

事例紹介は後段の
Sonic Rumbleの事例紹介
にて実施
QUIC Datagram (事例) スマホ
家庭用

➢ 非UDPのQUIC互換レイヤーを用意する提案
➢ TCP等との並行実装が不要になる可能性
➢ まだ提案段階なのでこれから
➢ interim-2025-quic-01資料
QMux (QUIC On Stream) 家庭用
スマホ
Application protocols (e.g. MoQ)
UDP
QUIC QMux
Any reliable stream transport
QUIC stream semantics

➢ HTTP/3
➢ HTTP/1.x,2をHTTP/3へアップグレード
➢ HTTPをAPIに採用しているゲームは多い
API通信への利用家庭用
スマホ
HTTP/3
QUIC
UDP

➢ WebSocket over HTTP/3
➢ RFC 9220で仕様策定済み
➢ RPC over HTTP/3
➢ gRPCにも適用されている実装がある
API通信への利用家庭用
スマホ
HTTP/3
QUIC
UDP
WebSocket RPC

➢ UDPの代替
➢ 輻輳制御等のUDPに無い仕様の獲得
➢ QUIC Datagramで近い動きが可能
➢ RUDPの代替
➢ 独自実装を標準仕様に置換できるのは大きなメリット
➢ 時世的に暗号化無しは許容できなくなりつつある
リアルタイム通信への利用家庭用
スマホ

➢ DTLSの代替
➢ DTLSは2022/4にRFC9147にてついに標準化
➢ 長らく各自で独自実装する形だった
➢ OpenSSL 3.0等主要なOSSが対応済み
➢ (資料公開後追記)上記誤りがあったので次ページにて訂正してあります
➢ RUDPへの適用については引き続き独自実装
リアルタイム通信への利用家庭用
スマホ

➢ DTLS自体は2006/4にRFC4347にて標準化済み
➢ RFC 4347: Datagram Transport Layer Security
➢ 2022/4にRFC9147で標準化されたのはDTLS 1.3
➢ RFC 9147: The Datagram Transport Layer Security (DTLS) Protocol
Version 1.3
➢ DTLS 1.2 : RFC 6347: Datagram Transport Layer Security Version 1.2
➢ 実装状況
➢ OpenSSL : DTLS 1.2までの対応で1.3は実装中
➢ BoringSSL : DTLS1_3_VERSION の定義があるので1.3まで対応してそう
➢ WolfSSL : 1.3まで対応済み
DTLS現状(補足)資料家庭用
スマホ

➢ HTTP/3
➢ HTTP/2同様の多重化を用いたダウンロードが可能
➢ HTTP/3のメリットも享受
➢ アプリケーションレイヤーの実装変更は不要
データダウンロードへの利用スマホ

UnityでQUIC・リアルタイム通信でQUIC
Sonic Rumbleの事例
株式会社セガ松崎大

松崎大 / Dai Matsuzaki
株式会社セガ
第２事業本部第４事業部
• 1998年セガ・エンタープライゼス入社。AM2に配属
• 2002年くらいからサーバ・通信関連の業務多めに
• Google Certified Professional Cloud Developer
自己紹介

• Sonic Rumble
• UnityでQUIC
• リアルタイム通信でQUIC
• まとめ
目次

• 最大32人対戦
• 開発はUnity
• PC・モバイル向け
• グローバル展開
• サーバ・クライアント型
Sonic Rumble
©SEGA

• 改めてQUICとは？
• TCPに比べ低遅延な通信を実現
• 到達保証・順番保証があるUDPベースのプロトコル
• 各プロトコルとの比較
Sonic RumbleはQUICを使っています
RUDPの代替としてQUICを採用
I
S
P
P
P
P
P
P
P

1. QUICをUnityで使うことができるか？
2. QUICはリアルタイム通信のプロトコルになり得るのか？
3. QUICはリアルタイム通信のプロトコルになり得たのか？
QUIC検証のプロセス

内製通信ライブラリ「Nemofiller」
• C#（netstandard2.1準拠）で記述
• Unity・NetCoreで動作
• S/C、S/C + P2P
• Replication（オブジェクト同期）
• RPC
• dotnetのソケットを使用
• Unityインテグレート
• UnityEditor拡張
• Unityコンポーネント
• 使用OSS
• Agones-sdk
• cloudflare-quiche
Sonic Rumbleは内製通信ライブラリを使用しています
Unity ＋ Nemofiller
GameServer
GameClient

• QUICのOSSに求める機能
• ソケットが別
• 単なるQUIC変換装置
• QUICのOSSに求める必須機能
• C#、C/C++
• 対応プラットフォーム
• Win/Mac/Linux/iOS/Android
QUIC変換装置が欲しい
UserBytes
QUIC変換装置
QuicBytes
dotnet-socket

• QUICのOSSに求める機能
• ソケットが別
• 単なるQUIC変換装置
• QUICのOSSに求める必須機能
• C#、C/C++
• 対応プラットフォーム
• Win/Mac/Linux/iOS/Android
Cloudflare-quiche
cloudflare-quiche
• 特徴
• RUSTで書かれたQUIC実装
• ソケットは別に用意
• C/C++用quiche関数（ffi）
• 機能
• QUIC-STREAM（multi-stream）
• QUIC-DATAGRAM
• マルチプラットフォーム対応
• Win/Linux/Android/iOS
※Mac向けにもビルドできました

Cloudflare-quicheをC#で使う
UserBytes
QUIC変換装置
QuicBytes
dotnet-socket
Rust
Cloudflare-quiche
C#
quic_wrapper.so
C/C++
libquiche.so
C++実装

Cloudflare-quicheをC++で組み込み実装
quiche.h を見ると結構な数の関数
https://github.com/cloudflare/quiche/blob/master/quiche/include/quiche.h
サンプルを見ると結構な組込み実装が必要
https://github.com/cloudflare/quiche/blob/master/quiche/examples/server.c
https://github.com/cloudflare/quiche/blob/master/quiche/examples/client.c
• C#<->C++の行き来は少ない方が良いのでは…
• サンプルを見る限りC#よりもC++で書いた方が楽そう…
quiche関数の組み込み実装はC++で
Rust
Cloudflare-quiche
C#
quic_wrapper.so
C/C++
libquiche.so
C++実装

Cloudflare-quicheをC++で組み込み実装
組込み関数
I 変換装置
つのアとく
理を実装
つのを管理
理を実装
数のを管理
S

• 動作確認プラットフォーム
• Win（x86-64）
• Mac（Apple Silicon）
• Linux（x86-64）
• iOS
• Android
• UnityEditor（Win/Mac）
• 気になること
• マルチプラットフォーム対応時のビルド・動作チェックが大変
• netstandard2.1準拠で書かれたQUIC実装が欲しい…
UnityでQUIC（Cloudflare-quiche）

TCP vs UDP vs QUIC
QUICはリアルタイム通信のプロトコルになり得るのか？

• 計測のスペック
• 100msec毎にメッセージを送信＆サーバはエコーバック。クライアント側で
RTT値を計測
• 送信メッセージサイズは128byteと1024byte
• 各プロトコルで計測。TCP / UDP / QUIC-STREAM / QUIC-DATAGRAM
• サーバのスペック
• EKS（with Agones）
• eu-west-3(paris) / us-west-1(oregon) / ap-northeast-1(tokyo)
• c6i.large
• NemofillerのRtcServer（リアルタイムサーバ）
• クライアントのスペック
• 自宅（有線, auひかり10G, 東京）
• ThinkPad P1 Gen5（i7-12800H）
• NemofillerのRtcClient（リアルタイムクライアント）
TCP vs UDP vs QUIC：計測スペック

TCP vs UDP vs QUIC：計測結果(128byte)
QUICとUDPのRTT値はニアリー
TCPは大きく乖離

TCPもニアリー

QUICとUDPのRTT値はping値とニアリー
RTT平均値とping計測値の比較
P
P
I S
I G

TCP以外は128byte時の結果とほとんど同じ

TCP以外は128byte時の結果とほとんど同じ
RTT平均値とping計測値の比較
P
P
I S
I G

• QUICは距離に応じた適切な通信速度が担保されやすい
• QUICは通信データサイズの影響を受けにくい
• QUICはUDPよりも高機能かつ同等の通信速度
QUICはリアルタイム通信のプロトコルになり得る
QUIC-STREAMはTCPやRUDPの代替になり得る
TCP vs UDP vs QUIC：まとめ

Sonic Rumbleでの実測値を検証
QUICはリアルタイム通信のプロトコルになり得たのか？

• QUIC-STREAMを使ってRTT値を計測している
• 定期的な生存確認通信にてRTT値を計測
• 次回生存確認通信にて計測値をサーバに送信
• サーバ側でログに出力
• ゲームプレイ中に計測
• ゲーム内のメッセージと同じストリームを使用
• ゲームサーバクラスタは北米西海岸に設置して運用
• アプリ配信地域はアジア・南米・欧州・中東・カナダ
Sonic Rumbleでの実測

Sonic Rumbleでの実測：任意プレイヤのRTT値
揺らぎはあるものの、割と安定したRTT値

Sonic Rumbleでの実測：任意プレイヤのRTT値
理論値とニアリーなRTT値
実測値と理論値の比較
トルコ
ブラジル
ーストラリア
アリ
S
スー
ラス
値実値
～
～
～
～
～
～
～
値理論値

Sonic Rumbleでの実測：RTT値の国別分布
距離に応じたRTT値になっている

多人数接続・高頻度通信下において以下を確認
• 揺らぎはあるものの、割と安定したRTT値
• 理論値と乖離が少ないRTT値
• 距離に応じたRTT値
QUICはリアルタイム通信のプロトコルになり得た
Sonic Rumbleでの実測：まとめ

• 内製通信ライブラリ
• マルチプロトコル
• サーバ・クライアントともに３ソケット
• QUIC・TCP・UDPを使用可能
• Sonic Rumble
• RELIABLE-MSGをQUIC-STREAM
• UNRELIABLE-MSGをQUIC-DATAGRAM
とある事情でTCP・UDPを使う事例が出てきた
Sonic Rumbleはマルチプロトコル
UNRELIABLE-MSG
RELIABLE-MSG
QUIC-STRM
QUIC-DGRM UDP
TCP

• Sonic Rumbleでの懸念
• UDPが通り難い地域があるとの噂
• グローバル展開だから心配との声
• 対応
• QUICで接続失敗後はTCPへフォールバック
• 結果
• フォールバック発生率は平均0.014%
• 発生地域は日によってバラバラ
• UDPが通り難い云々は地域依存ではなく施設依存な印象
懸念は杞憂だった。
TCPへのォールバックは将来的に廃止しても良いかも
QUICからTCPへのフォールバック

• Sonic Rumbleでの問題
• Sonic Rumbleでは切断判定に至るケースが一定割合で存在していた
• 調査して分かったこと
• 地域・時間・端末スペック・OSには非依存だった
• 該当ユーザーは再送やジッタが発生、その後切断判定に至る
• Sonic Rumbleは、非効率なメッセージ送信になっていた
• まとめ理が効きらい送信
• 通信量の割にパケット数が多い
パケット数の多さに起因した通信経路上の機器でのパケットドロップと予想
QUIC-DATAGRAMからUDPに暫定変更

• 方針
• ゲーム中のメッセージをなるべくまとめる
• ゲームの体感を変えたくない
• 対応
• QUIC-DATAGRAMからUDPに変更し、ACKの分をまるっとカット
• 結果
• 切断判定の件数が減少
• その後体感を変えない範囲でメッセージをまとめ、切断判定の件数は更に減少
パケット数の多さが原因だった。
QUIC-DATAGRAMに戻すことを検討中
QUIC-DATAGRAMからUDPに暫定変更

• QUICはリアルタイム通信のプロトコルになり得る
• QUIC-STREAMをTCP・RUDPの代替として使うのはあり
• QUIC-DATAGRAMにはACKが存在する
• UDPと同じ感覚で投げるとパケット数が増える点は留意
• ACKのON-OFF機能や頻度制御機能などが欲しい
• draft-ietf-quic-ack-frequency-11 - QUIC Acknowledgment Frequency
• Unity + QUIC、非C#なOSSを使ったことで保守が結構ツライ
• マルチプラットフォーム対応はそれなりに大変
• netstandard2.1で書かれたQUIC実装がとても欲しい
まとめ

社内製リアルタイムネットワークライブラリ
SPHINGO 及びその採用タイトルの事例
株式会社セガ藤村隆史

株式会社セガ
技術本部開発技術部
藤村隆史
1994年セガ・エンタープライゼス入社
第二AM研究開発部で業務用ゲーム開発
2000年頃 DC 用インターネット通信対戦ゲーム作成
その後業務用ゲーム基板用システムやドライバ開発業務も並行
2008年頃よりネットワーク系ライブラリ開発、サポート系業務に軸足を移し今
に至る
自己紹介

• クライアントサーバ型リアルタイムネットワーク通信ライブラリ
• 実装は C/C++
• ～数十プレイヤー間の信頼性あり・なし混在での疑似マルチキャス
ト同報通信、ユーザによるサーバ内理をサポート
• TCP および UDP上にSCTPベースの独自プロトコルを個別選択
• 約 20 年の歴史があり、社内外の多数タイトルで採用、現在も改良
やサポート継続中
“SPHINGO” の紹介

• ゲーム中通信のリアルタイム性能の要求度合い
– 最高対戦格闘等、基本は P2P
– 高アクション系ゲーム(～数10mS)
• 最大レイテンシ限界（～ 250mS 程度）
ここでの「リアルタイム」の定義
– 低さほどアクション性を要求しない
許容遅延時間

• Connection Migration を手軽に導入したい
– ある採用タイトルで、クライアントの接続回線が切り
替わった際における自動復旧のニーズ
• 独自プロトコルは維持管理工数がかかるため標準的なプ
ロトコルを選択肢に加えたい
⇒既存環境への導入のしやすさ、導入時期における機能
実装の比較結果として chromium-quiche を利用
QUIC 採用のきっかけ

機能互換レイ
ヤ実装および
テスト導入
JAIPA WG で
検証
マイグレー
ション性能の
向上
タイトルへの
導入
QUIC 導入までの流れ

• ESCTP/U
既存実装と QUIC の違い
• QUIC
ESCTP/U QUIC
信頼性のない通信マルチチャネル(独自拡張) DATAGRAM(RFC9221)(1つ)
信頼性のある通信メッセージ指向ストリーム指向
認証・暗号化部分的に有効(独自) 接続全体(TLS)
接続の管理
通信相手のアドレスおよび
ポート
Connection Id
コネクションマイグレーション
その他
独自実装
(RFC2960,3309を基に)
RFC9000(8999-9002等)
互換機能実装
とテスト導入

• 数チャネルへの対応
– もともと TCP を使う場合のためにあった
MUX/DEMUX 実装を応用
⇒ 但し信頼性が無い通信であるにも関わらず存在する
ACK が冗長、という部分は未解決
QUIC Datagram の扱い互換機能実装
とテスト導入

• リアルタイム通信ではバイトストリームより
シーケンスパケット的な通信が多い
出来ればパケット単位で不可分な通信をしたい
– QUIC の場合はミドルボックスでの操作可能性が低い
• 送信側実装の工夫でメッセージ指向っぽくできる
⇒ストリームの伝送効率とは相反
QUIC Stream の扱い互換機能実装
とテスト導入

• JAIPA「ゲーム・エンタメのネットワーク接続性
課題検討WG」
– ゲームやエンターテイメント等コンテンツのネット
ワーク疎通性の課題を業界横断的に検討するWG
– 2019 年から活動
– 2022 年に QUIC 通信でのルータセッションテーブル
枯渇の可能性検討から開催の QUIC 検証会に、この
実装のプロトタイプを持ち込み動作検証
JAIPA WG での接続性検証 JAIPA WG での
接続性検証

• [送信] DATAGRAM 30pps, STREAM 1pps, 300 bytes/packet
• [受信] DATAGRAM 90pps, STREAM 3pps, 300 bytes/packet (MAX)
JAIPA WG での接続性検証
クライアント
(/w Wi-Fi キャプチャ)
L2
Switch
Mirror Mirror
無線(/w有線)
LANルータ
LAN1
(Wi-Fi)
パケットキャプチャ
CPE
サーバ #1
#2
#3
#4
WAN
LAN2
(Wired)
JAIPA WG での
接続性検証

• 検証結果の概要(弊社分)
– 動作中のマイグレーションでは、必要以上に通信アド
レス、ポートの組み合わせを使用することは無かった
（実装にく）
– マイグレーションに成功した場合でも、マイグレー
ションにかかった時間が長いと送受信バッファ溢れ起
因での切断があった
JAIPA WG での接続性検証 JAIPA WG での
接続性検証

経路変更にかかった時間と通信継続について
JAIPA WG での接続性検証
⇒ この時の送受信バッファ量だと不通時間として 0.6 秒前後しか余裕がないことが判る
JAIPA WG での
接続性検証
クライアント
クライアント
クライアント
クライアント
続
時間
続
時間
続
時間
続
時間
無線有線
有線無線
無線有線
有線無線
無線有線
有線無線

• QUIC は通信経路の切り替えに配慮のあるプロト
コル（というだけ）
– 実際にはプロトコルを用いた通信の具体的な
実装がポイント
想定はしていたものの結構面倒
マルチP/F対応マイグレー
ション改良

• 切断時や通信異常時に既に切り替え先が存在す
る場合の Write-Error 挙動等
– 主に Winsock 系実装と BSD Socket 由来の実装の差
異や、 BSD Socket 由来でもエラーの扱いには環境
によって差異がある
Socket I/F の異常時挙動の違いマイグレー
ション改良

• 統一したインタフェースが無い
• 「接続環境が変わった」という定義が一意では
ない
Ex) default_route が変わった? 新しい I/F が見つかっ
た? DNSが切り替わった? 外のアドレス宛ての通信成
功? キャプティブポータルは?
下層の接続環境の変化を知るマイグレー
ション改良

レスポンス良く知ることができる環境
– Windows, MacOS, iOS, Linux, Android, BSD系等
• カーネル通知をコールバックやイベント、ソケッ
ト等で知ることができる
但し方法はまちまちかつ不確実なのでいくつかの手法を
併用
ション改良

自分で変更をポーリングする必要がある環境
– 先ほど挙げていない環境の多く
• 自分で /etc 以下の各種システムファイル変更をイベント等
で知るかポーリング
• (POSIX には含まれていないが) getifaddrs(3) などをポー
リング
この環境の場合、低負荷低遅延で知る方法が無い
ション改良

• マルチパスベースの実装
– 新たな経路の発見と同時に疎通性検証
(有効な経路の個数の socket を同時に使う)
– 通信エラーが発生したら既に発見済みの他経路でパス
検証
– 一定時間切り替えができなければ切断
(問題点) 数経路に同時通信発生の可能性と、リ
ソースを必要以上に消費
逐次切り替えとマルチパスマイグレー
ション改良

• 逐次切り替え実装
– 通信エラーが発生したら OS からの有効な経路出現情
報を元に切り替え(socket 作り直し)
– パス検証
– 一定時間切り替えができなければ切断
(問題点) 切り替え毎にレスポンス低下
⇒こちらの実装を採用
逐次切り替えとマルチパスマイグレー
ション改良

• 一般的な接続環境
– 物理的には
• Wi-Fi / キャリア回線 / 有線 LAN
– 論理的には
• Server IPv4 で数の移行技術環境(DS-lite, MAP-E,
464XLAT, ...)
• Server IPv6 でも場合によって数の通信環境
これら間のマイグレーション動作確認は大変
⇒ 開発初期では Wi-Fi 同士や Wi-Fi⇔Wired 等に絞って実験
Connection-Migration のテストマイグレー
ション改良

• 30秒間隔で100クライアントを接続・切断した際の負荷比較
既存実装とのCPU 理負荷比較タイトル
への導入
時間
理サーバ

• 30秒間隔で100クライアントを接続・切断した際のメモリ比較
既存実装とのメモリ使用量比較タイトル
への導入
メ
リ
時間
メリサーバ

• Connection-Migration 件数 / 接続数 = 331 / 17561 (日)
マイグレーション件数事例タイトル
への導入
時
コネクションマイグレーション

• QUIC はリアルタイム通信でも既存実装に近い性能
• QUIC Stream をバイトストリームではない扱いをした
い場合は送信側実装で工夫
• Connection-Migration はゲームジャンルによっては使
えるがクライアント側の環境により異なる実装対応が必
要、またテスト環境の組み合わせ規模が課題
まとめ

社内の取り組みの紹介

• 専用のチャットルームを作成し情報交換
• QUICの社内勉強会等も実施
社内の取り組み

業界全体でも知見を共有していきましょう！
リアルタイム通信の情報をもっと知りたい……！！

ご清聴ありがとうございました
質疑はAsk The Speakerにて

CEDEC 2025 『ゲームにおけるリアルタイム通信への QUIC導入事例の紹介』

More Related Content

Similar to CEDEC 2025 『ゲームにおけるリアルタイム通信への QUIC導入事例の紹介』

More from SEGADevTech