1

デバイスに Web ベースの UI を提供することになっている組み込みプロジェクト用の小さな Web サーバーを作成しました。PC ブラウザーを使用するとすべて正常に動作しますが、モバイル ブラウザーは、ページに関連付けられているすべてのリソース (css / js / 画像など) をロードできません。

私のサーバーは、リクエストのパイプラインなしの永続的な接続をサポートしています。現在、並列接続の最大数を 1 に減らしているため、一度に 1 つの要求のみが応答されます。

私のデバッグ観察では、クライアントは、最初に *.html ファイルを要求し、次にスタイル シートを要求した後、head にリストされているそれ以上のリソースの要求を停止します。クライアントは切断されません。

PC ブラウザでは許容され、モバイル ブラウザでは許容されない、どのような間違いを犯す可能性があるかについて、何か考えがありますか?

ほとんどのモバイル ブラウザーが実際にパイプラインを実装して使用していることをオンラインで読みました。さらに考えてみると、現在の実装では、パイプライン化されたリクエストに対処する際に問題がある可能性があることがわかりました。STM32 のメモリ不足を考慮して、受信バッファを送信バッファとして再利用します。すぐに確認します...

...いいえ、>>>ここで<<<と言われているにもかかわらず、Android標準ブラウザのDolphinまたはAndroid用Firefoxが実際に「キープアライブ」接続でリクエストをパイプライン処理することを確認できません。

もう 1 つ... Android SDK からエミュレーターを実行すると、完全に正常に動作します (少なくとも Android 4.2.2 の場合)。

必要な追加情報についてコメントしてください。

4

2 に答える 2

0

理由は接続制限！

この回答のクレジットの一部は、最高の予感を持っていた Eun に与えられます。Chrome for Android で生成され、デスクトップ Chrome で表示できる接続ログを調べていると、答えが浮かびました。

ロードに失敗するすべてのリソースは、サーバー側で接続が拒否されたことが原因であることがわかりました。つまり、サーバー側のリセットが原因で失敗した接続のためにキューに入れられた要求ジョブは、他の接続が有効で "Connection: keep-alive" ヘッダー フィールドがあるにもかかわらず、別の接続のために再スケジュールされません。また、chrome がリクエスト パイプラインを使用していないことも確認できます。それがWiFiに接続されている場合。

デスクトップ ブラウザは、失敗したリクエスト ジョブを再スケジュールするため、それらで動作します。現在、この問題を解決する回避策があります。ただし、携帯性についてはよくわかりません。「ロード」イベントをリッスンして、必要なリソースを連続して追加する Web ページで Java スクリプトを使用します。

スクリプト、CSS、イメージ、または私の望ましい動作を生成するより一般的なリソース ローダーに関して、別の質問をします。

于 2013-07-28T08:31:07.177 に答える