web-dev-qa-db-ja.com

Chromeのみの超低速プリフライトオプション

私は最近、Chromeでのみ発生する非常に奇妙な問題に苦しんでいます。私のAPI(NodeJS)は別のサブドメインにあるため、フロントエンド(EmberJS)から到達するにはCORSを使用する必要があります。

それはかなりうまく機能していますが、私は非常に頻繁に(95%の時間)非常に遅いOPTIONSクエリを実行し、API呼び出しを約3秒遅らせます。

2 requests, OPTIONS takes 3 seconds

この時間のほとんどは、空のコンテンツのダウンロードに費やされます。

Downloading an empty content takes 3 seconds

同様のアーキテクチャを使用して作成した別のWebサイトでこれを試していると、まったく同じ問題が発生し、さらに奇妙になります。

私が試した他のいくつかのこと:

  • FirefoxとSafariでこれを試しましたが、遅延はありませんでした。
  • 私はこれをローカルまたは本番環境で試し、同じ遅延を試しました。
  • シークレットモード(拡張機能なし)でこれを試しましたが、まったく同じ問題が発生します。

バックエンドNodeJSで CORSパッケージ を使用しています。

さて、問題がChrome 60、NodeJS、CORSパッケージ、またはEmberJS + jQueryのいずれかにあるのかわかりません。

誰もこれを経験しましたか?

25
Benjamin Netter

注として:chromeバグのようです

一意のドメインのサービスを使用して、2つのDNS名を持つサーバーを使用して問題を再現しました

https://domain1.com  --> https://domain1.com (No CORS, no delay)
https://domain2.com  --> https://domain1.com (CORS, delay)

chrome cors

2つの名前に応答するのはまったく同じサービスなので、まったく同じリクエスト、クライアント、サーバーコードをテストしています(DNS名は交換可能です)

でテスト済み

  • Chrome 61.0.3163.100(Windows)-> DELAY
  • Chrome 62.0.3202.84(Android)-> DELAY
  • Chrome 62.0.3202.84(iOS-Ipad)-> OK !!!
  • Firefox-> OK
  • エッジ-> OK

回避策(私の場合)。ホストにプロキシを作成して、同じオリジンDNSに応答し、CORSを回避します

5
pedrofb

私はこれをデバッグしようとしていますが、同じ問題が発生していたため、chromeバグのようです。

参考までに、ここでクロムにバグレポートを提出しました: CORSのプリフライトとその後のリクエストはChromeでのみ非常に遅いです

これをここに追加して、開発者が半日かけて調査するのを防ぐのに役立てます;)Chromiumからさらにここに来ると更新されます。

バグレポートの概要は次のとおりです。

UserAgent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

問題を再現する手順:

  1. App.domain.comを持っている
  2. リストアイテム
  3. Api.domain.comを持っている
  4. APIでCORSを有効にして、アクセスを有効にします
  5. DevToolsで応答を確認してください。オプションを参照してください。GETリクエストには最大300ミリ秒以上かかります。

予想される動作は何ですか?

応答のタイミングは正確でなければなりません。

何が悪かったのですか?

Goマイクロサービスを使用していて、ブラウザー間でかかる時間に大きな違いがあることに気づきました-chromeは、100倍まで最も遅いです。

バックエンドからタイミングを確認したところ、応答には最大10ミリ秒かかり、ほとんどが1ミリ秒未満です。 devtoolsでタイミングを確認すると、同じ応答が〜100ms〜1sで受信されていました。

これは以前に機能しましたか?

該当なし

Chromeバージョン:63.0.3239.132チャネル:安定したOSバージョン:10.0 Flashバージョン:

Firefox(およびその他のブラウザ)では、まったく同じリクエストが予想どおり1〜20ミリ秒で返されます。

さらに診断を試みる際に、TelerikのFiddlerを使用して実際のネットワーク応答時間を確認し、予想されるタイミング内にChromeによって送受信されていることを確認しました。唯一の結論はChromeの内部にある何かが、これらのリクエストの処理を遅くしていること。

chrome://flags#out-of-blink-corschrome://flags#enable-site-per-processのすべての順列を試しました。これらは、漠然と関連しているように見える2つのオプションです。何も役に立たなかったようです。

また、Chromeバグであることに言及している、同様の問題に関するStack Overflowの記事を多数見つけましたが、ここで報告されているものを見つけることができませんでした:

MacOSでChromeをテストしましたが、問題はないようです。そのため、Windowsに限定される可能性があります。

Chrome: optionsChromegetChrome

縁: - optionsEdgegetEdge

Firefox: optionsFirefoxgetFirefox

3
Trancendence

私は自分のケースの解決策を見つけました。ここでそれを共有します。

私はWindowsを使用しており、Chromeバージョン70を使用して、同じサーバー上でrestifyを使用してnodeJSバックエンドでAngularJSフロントエンドを実行しています。フィドラーを使用してリクエストを監視しています。OPTIONSリクエストは1秒の場合もあれば、5ミリ秒未満の場合もあります。フィラーの使用を停止すると、最大時間が300ミリ秒になりますが、それでも長いと見なされます。この遅延はChromeで発生しますが、Firefoxでは発生しません。他のブラウザはテストしていません。

Chromeネットワークタイムラインを見て、Fiddlerが存在する場合は1秒待機(TTFB)遅延があり、Fiddlerがオンでない場合は、 DNAルックアップと初期接続の間の300ミリ秒のギャップ。

私はついにこれを見つけました DNSルックアップと初期接続の間のAJAXクエリの奇妙な遅延ChromeしかしFFではありません、それは何ですか?

バックエンド接続URLをlocalhostから127.0.0.1に変更し、それは私の問題を完全に解決しました。

0
Haijin