切断とは何か
ストリーミング API への接続とは、非常に長時間の HTTPS リクエストを行い、レスポンスを逐次的にパースすることを意味します。ストリーミングエンドポイントに接続する際は、HTTPS リクエストを構築し、実用的な限り長い間、その結果のストリームを消費してください。 X サーバーは、以下の場合を除き、接続を無期限に保持します。- サーバー側のエラー
- 過度なクライアント側の遅延
- ネットワークの問題
- 定期的なサーバーメンテナンス
- 重複ログイン
切断の理由
切断の考えられる理由:よくある切断エラー
Operational disconnect
Too many connections
切断の検出
ストリーミングエンドポイントは、20 秒ごとに keep-alive heartbeat（改行文字）を送信します。このシグナルを使用して切断を検出します。- コードは、新しいコンテンツと heartbeat の受信が停止したことを検出する必要があります
- 20 秒間データを受信しない場合、再接続ロジックを開始します
- 一部の HTTP クライアントでは読み取りタイムアウトを指定できます。これを 20 秒に設定してください
再接続戦略
確立された接続が切断されたら、すぐに再接続を試みてください。再接続に失敗した場合は、エラーの種類に応じたバックオフ戦略を使用します。TCP/IP ネットワークエラー
線形 にバックオフしてください。これらの問題は一般に一時的です。- 試行ごとに 250ms ずつ遅延を増やす
- 最大遅延: 16 秒
HTTP エラー
再接続が適切な HTTP エラーには 指数関数的 にバックオフしてください。- 5 秒待機から開始
- 試行ごとに倍増
- 最大遅延: 320 秒
レート制限エラー（HTTP 429）
より長い初期待機時間で 指数関数的 にバックオフしてください。- 1 分待機から開始
- 試行ごとに倍増
- 429 を受け取るたびに、レート制限が解除されるまでの待機時間が増加
Rate limit と使用状況
ストリーミング接続レスポンスは、制限を理解するのに役立つ 3 つのヘッダーを返します。
どれだけの Post が配信されたかを追跡するために、消費を測定でき、必要に応じて一時停止できるように、クライアント側でメータリングロジックを実装してください。
再接続のベストプラクティス
FIFO キューアーキテクチャを使用する
ストリームクライアントは、着信 Post を FIFO キューまたは同様のメモリ構造に挿入する必要があります。別のプロセス/スレッドがそのキューから Post を消費して、パースと保存を行います。この設計は、Post ボリュームが劇的に変化するときに効率的にスケールします。バックオフ戦略のテスト
無効な認証情報を使用してバックオフ実装をテストし、再接続の試行を検証してください。良い実装では 429 レスポンスを受け取らないはずです。複数回の再接続でアラートを発行する
再接続間の時間の上限に達した場合、接続の問題を分類できるように通知を送信してください。DNS の変更に対応する
クライアントプロセスが DNS Time To Live（TTL）を尊重するようにしてください。一部のスタックは、プロセスの継続時間だけ解決したアドレスをキャッシュし、TTL 内の DNS 変更を検知しません。攻撃的なキャッシュは、X が IP アドレス間で負荷を移動させる際にサービス中断を招きます。User-Agent ヘッダーを設定する
クライアントのバージョンをUser-Agent HTTP ヘッダーに含めてください。これは X 側での問題診断に不可欠です。環境で User-Agent を設定できない場合は、代わりに x-user-agent ヘッダーを使用してください。
次のステップ
復旧と冗長化
切断後の欠落データを復旧
ストリーミングデータの利用
堅牢なストリーミングクライアントを構築
大容量キャパシティ
高スループットのストリームを処理