Workersの同時接続制限の緩和

2026年4月9日

Workers

同時オープン接続の制限が緩和されました。

以前は、各Workerの呼び出しにおいて、レスポンスボディの読み取り中を含む接続の全ライフタイムにわたって、同時に6つのオープン接続に制限されていました。現在は、レスポンスヘッダーが到着するとすぐに接続が解放されるため、6接続制限は「ヘッダー待ち」の初期フェーズで同時に実行できる接続数のみを制約します。

変更前: 新しい接続は、以前の接続が完全に完了するまでブロックされる

変更後: レスポンスヘッダーが到着するとすぐに新しい接続を開始できる

これにより、初期レスポンスを待機している接続が6つを超えない限り、Workersはキューイングなしで同時により多くの接続を開くことができるようになりました。

この変更により、ランタイムがデッドロックを防ぐために停止した接続をキャンセルした際に発生していた「Response closed due to connection limit」例外が解消されます。

以前は、ランタイムは各オープン接続のI/Oアクティビティを監視するデッドロック回避アルゴリズムを使用していました。6つの接続すべてが一時的にでもアイドル状態に見える場合、ランタイムは新しいリクエストのためのスペースを作るために、最も最近使用されていない接続をキャンセルしていました。

実際には、このヒューリスティックは脆弱でした。例えば、レスポンスがContent-Encoding: gzipを使用している場合、ランタイムの内部解凍により読み取りと書き込み操作の間に短いギャップが生じます。これらのギャップの間、Workerによってアクティブに読み取られているにもかかわらず、接続は停止しているように見えました。複数の接続が同時にこれらのギャップに遭遇すると、ランタイムは正常に動作している接続を誤ってキャンセルする可能性がありました。

ヘッダー待ちフェーズでのみ接続をカウントすることで（この段階ではランタイムが完全に制御し、接続がアクティブかどうかについて曖昧さがない）、このクラスのバグは完全に排除されます。

変更前: 短い内部一時停止中に接続がキャンセルされる可能性があった

変更後: 内部一時停止に関係なく接続が正常に完了する