14

http post メソッドを使用して、リクエストを Http サーバー URL に送信しています。

リクエストとレスポンスの時間差は約 60 秒ですが、サーバー チームによると、リクエストが最後に到達してから 7 秒以内にレスポンスを送信しています。

ネットワークがサーバー側でパケットに到達するのに残りの 53 秒の時間がかかっているとは思わないので、何が問題になる可能性がありますか。

このアプリケーションでは、クライアントとサーバーの間で同期通信を使用しています。以下の詳細も教えてください。

  1. サーバーが処理できる速度よりも速い速度でサーバーがリクエストを送信しているためですか。この場合、多くの場合、クライアントは 3 秒間隔でリクエストを取得しますが、サーバーはこれを処理するのに 7 秒かかります。
  2. ネットワークバッファとは。ネットワーク レベルに 2 つのバッファがあるかどうか。1 つはクライアントの場所、もう 1 つはサーバーの場所にあります。
  3. サーバーが同じ速度でリクエストを処理できない場合、クライアントが送信するのはすべてのリクエストがクライアント バッファにバッファリングされ、そのバッファの最大サイズよりも多くのリクエストが処理待ちになっている場合にどうなるかです。
  4. クライアント側にいてサーバーを制御できない場合、パフォーマンスを向上させる代替方法は何ですか

編集:ネットワークでwiresharkを使用してネットワークログをキャプチャすると、実際にアプリケーションがサーバーに送信されてから20秒後にwiresharkに表示されることがわかりました。この遅延の背後にある理由は何ですか。リクエストが実際に送信されてから20秒遅れてネットワークに表示される理由として考えられるのは何ですか。

4

6 に答える 6

33

あなたの編集に関して、あなたが理解するのを助けるために。ネットワーキングは、Open Source Intercommunication (OSI)と呼ばれるモデルに従います。このモデルは 7 つの異なるレイヤーに分割され、すべてが機能を備えています。

これらのレイヤーは次のとおりです。

OSI モデル

Wireshark は、レイヤー 3 にあるパケットを検出します。これはRouterによって処理されます。ネットワーク インターフェイス カード (NIC)は、割り当てられたデータを取得し、それをパケットに変換してネットワーク経由で送信します。

Wireshark は、NICがパケットをルーターが処理するパケットに変換するまで、パケットを検出しません。

パケットに変換されると、次の情報が含まれていることがわかります。

  • バージョン (IPV4 または IPV6) を含む 4 ビット
  • インターネット ヘッダーを含む 4 ビット。
  • サービスの種類またはサービスの品質と優先度を含む 8 ビット。
  • パケットの長さをバイト単位で含む 16 ビット。
  • Fragments からパケットを再構築するのに役立つ識別タグを含む 16 ビット。
  • 3 ビット。最初はゼロで、その後にフラグメントを許可するか許可しないかを示すフラグが続きます。そして量。
  • Fragment オフセットを含む 13 ビット。元の位置を識別するためのフィールド。
  • Time To Live (TTL)とHops across Routersを含む 8 ビット。
  • プロトコル (TCP、UDP、ICMP など) を含む 8 ビット
  • ヘッダー チェックサムを含む 16 ビット
  • ソース IP アドレスを含む 32 ビット
  • 宛先 IP アドレスを含む 32 ビット

これらは、そのようなパケットを作成するときに作成されるキーの 160 ビットです。

これは何を意味するのでしょうか？

Wiresharkがパケットを検出するのに 20 秒かかることはご存知でしょう。したがって、すぐに、アプリケーションが実際にこのパケットを構築するのに 20 秒かかったことがわかります。

サーバーがデータを処理し、場合によってはリクエストを送信できるように、このパケットを再構築する必要があることもわかっています。

また、ルーターが交通警官のように機能し、インターネットまたはローカル ネットワークを介してデータを送信していることもわかっています。

さて、それはかなりの推論を追加しますか? しかし、どこに行けばいいですか？

次のユーティリティがあります：tracert

平均して、ルート要求が 5 ～ 6 フィートのケーブルを通過するのに 1 ～ 2 ミリ秒かかるため、最初のホップが 1 ～ 2 ミリ秒で生成され、2 番目のホップが 230 ミリ秒でトリガーされる場合、単純な式を使用できます。 :

6 * 20

トレーサートからの現在の速度に基づいて、所要時間を見積もることができます。これは非常に一般的なアプローチですが、正確な精度を得るためにツールが存在します。ただし、ホップ数が多いほど、目的地に到達するまでの時間が長くなります。また、あなたはより多くを掛けます。

クライアントからサーバーまでの間はどうですか？

  • ローカル エリア ネットワーク (LAN) : ネットワークの内部効率は、各ネットワーク プロトコル、機器、および物理メディアンの最適化によるものです。ネットワーク管理者は、速度で信頼性を測定する必要があります。ネットワークによって生成されたすべてのトラフィックと同様に。したがって、機器のスループットと物理的な中央値が重要です。1 車線のトンネルに 10 台の車が合流すると、ネットワークと同じようにボトルネックが発生する可能性があります。

  • ワイド エリア ネットワーク (WAN) : これは基本的に、インターネット (クラウド) への接続です。次のように考えてください。コンピュータは LAN 上にあり、ルーターは WAN に接続されています。次に、ISP には LAN があり、その WAN がより大きな配布施設に開放されている可能性があります。それは、インターネットに到達するまでずっと働き続けます。

でもどうすればいいですか？

間に何があるか分かりますが、私に何ができますか?

さて、サービスを生成するとき、コードが無駄がなく非常に効率的であることを確認したいのは明らかです。効率は速度において非常に重要です。そのため、バッファ サイズや転送速度などを変更すると、アプリケーションを大幅に改善できます。

明らかに、適切なコード プラクティスが役に立ちます。

私のコードはしっかりしていますか？

この時点でコードに問題がないと思われる場合、またはサービスをホストおよび作成する方法に問題がないと思われる場合は、次の要因が原因である可能性があります。

  • ローカル マシンが過剰なチャタリングを生成している可能性があるため、かなり時間がかかります。
  • ローカル ネットワークは、過度のチャタリングまたは非効率的/低スループットを生成しています。
  • あなたのリクエストは長距離を移動しているため、時間が遅れています。
  • インターネット サービス プロバイダーには、これらのパケットをスキャンするハードウェア ファイアウォール、プロキシなどがある場合があります。
  • サーバーに過剰なリクエストがあるか、ホスト メソッドが効率的でない可能性があります。

これらは、より大きな変数のチャンクです。試すことができるのは、サービスをリファクタリングし、サーバーが可能な限り最も効率的な方法でそれをホストしていることを確認することだけです. それ以外の場合は、情報技術チームを関与させる必要があります。これは非常に重要です。

ただし、このサービスに接続している別のクライアントよりも、エクスペリエンスが良くなったり悪くなったりする可能性があることに注意してください.

私は、あなたが 1 つの場所に展開されており、サーバーからいくつかの州が離れている可能性があるという仮定の下で話しています。

ツール:

コマンドライン：

  • ピン
  • トレーサート

ネットワークおよびプロトコル アナライザー:

  • Fiddler (HTTP/HTTPS) : Fiddler がトラブルシューティング用の HTTP ステータス コードを表示するかどうかを確認します。
  • Wireshark : 所要時間に役立つネットワーク トラフィックを分析します。

Googleの「ネットワークツール」だけで、他の場所でもネットワーク速度を実際に軽減およびテストするために利用できる他のユーティリティがあります。フルークにはいくつかあります。

これで、Wireshark がネットワーク上にパケットを表示するのに 20 秒もかかる理由がわかると思います。

それが役立つことを願っています。

于 2013-03-21T18:02:12.797 に答える
8

Wiresharkを使用して、ネットワーク上で60秒間隔で要求と応答をキャプチャし、サーバーチームに送信します。彼らは、彼らの側で7秒近くの要求と応答を示すキャプチャで応答するかもしれません。それは素晴らしいことです！両方をネットワークチームに送信します。

一方、トレースは、遅延がコードにあることを示している可能性があります。リクエストがかなりの時間プロセスを離れることを妨げる、ある種のスロットルまたは遅延があなたの側にある可能性があります。Wiresharkのトレースからもそれがわかります。

于 2013-03-15T00:37:17.777 に答える
6

TCP/IP ストリームは、懸念事項のほとんどを制御します。

「サーバーが処理できないよりも速くリクエストを送信しています」

いいえ、TCP セッションを使用する場合に受信できるよりも速くサーバーに何かを送信することは決してありません。送信フローはガイドされており、サーバーが処理できるよりも速く送信することはできません。

「ネットワークバッファとは」

TCP/IP 通信には、送信バッファーと受信バッファーの 2 つのキュー バッファーがあります。

呼び出しを行うsend()と、実際には何も送信されず、送信バッファーにデータがキューに入れられ、送信しようとしていたバイトのうち実際に送信のためにキューに入れられたバイト数が返されます。送信しようとしていたよりも少ない数が返される場合は、バッファがいっぱいであるため、残りを送信する前に待機する必要があることを意味します。

これは、トラフィックを制御する方法です。送信速度が速すぎるかどうかを知る手がかりです。送信するデータがある限り、バッファをいっぱいに保つようにしてください。ただし、すべてがバッファに収まるわけではなく、後で再試行する必要があるという事実を無視しないでください。

recv()には独自のバッファもあります。このコマンドは実際には何も受信するためのものではありません。データは既に受信recv()されており、受信バッファから読み取るだけです。ブロッキング ソケット (デフォルト) を使用しているrecv()場合、バッファが空の場合はハングし、新しいデータが到着するのを待ちます。recv()接続が終了した場合、または非ブロッキングソケットで使用しようとした場合にのみ 0 を返します。

忘れてrecv()受信バッファがいっぱいになっても大丈夫です。ピアは 0 を返し始めるため、送信を続けることができなくなりsend()ますが、戻り値に注意を払う限りsend()、いつでもデータが失われることはありません。

私の知る限り、バッファ サイズはデフォルトですべてのシステムで送信または受信の両方で 64KB です。このバッファ サイズを調整するコマンドはありますが、いじるのは面白くありません。より大きなバッファが必要な場合は、アプリケーションで作成してください。

「クライアント側でサーバーを制御できない場合、パフォーマンスを向上させる代替方法は何ですか」

それは正確には有効な質問ではありません。それはできません。特に POST リクエストを行っていることを考えると、HTTP リクエストで間違いを犯している可能性があると思います。

POST 要求を実行すると、HTTP ヘッダーには、通常はサーバーの HTTP 応答ヘッダーでのみ見られる 2 つのヘッダー (Content-Type と Content-Length) が含まれます。これらは POST を実行する際に非常に重要です。そのうちの 1 つが欠落しているか間違っていると、HTTP セッションが数秒間ハングするか、まったく成功しなくなる可能性があります。

HTTP のもう 1 つの重要な側面は、HTTP 1.0 と HTTP 1.1 の最も本質的な違いです。HTTP 1.0 はKeep-Aliveをサポートしていません。初心者が HTTP 1.0 を扱うのは簡単です。HTTP 1.0 を使用すると、接続してリクエストを送信し、サーバーが応答して接続が終了するため、サーバー応答のダウンロードが完了します。HTTP 1.1 では、デフォルトでは発生しません。接続は、タイムアウトするまで開いたままになります。サーバーが要求したものの送信を終了したかどうかを知るために、HTTP 応答ヘッダーの Content-Length と count バイトに注意を払う必要があります。

すべてのサーバーが HTTP 1.0 をサポートしているわけではないことに注意することも重要です。HTTP 1.0 リクエストを行うこともできますが、とにかく 1.1 で応答し、Keep-Alive や予期しないすべてのものを返します。完璧な世界では起こるべきではありませんが、起こります。

あなたの間違いはこの辺りにあるかもしれません。リクエストに正確に 60 秒かかるとおっしゃっていたので、タイムアウトが原因だと思います。必要なものはすべて既に受け取っている可能性がありますが、アプリケーションはそれを適切に処理しておらず、サーバーによって接続が終了されるまでハングします。

于 2013-03-24T00:26:11.637 に答える
2

ポイント番号1：

あなたのポイント番号1で、あなたは「1」と言うつもりだったと思います。それはクライアントの送信によるものですか....」および「この場合、クライアントは間隔を置いて何度も応答を取得しています....」.

ポイント番号3について：

  • サーバーマシンは通常、クライアントマシンよりも強力なコンピューターであるため、「サーバーがクライアントが送信するのと同じ速度で要求を処理できない場合」はほとんどありません。私の記憶が正しければ、HTTPサーバーは「先着順」で処理され、リクエストバッファと呼んでいるものはクライアントではなくサーバー側のキューになります。「すべてのリクエストがクライアントバッファにバッファリングされる」ということは聞いたことがありません。

  • 通常、サーバーが応答するまでの時間は短いですが、結果がクライアントに返されるまでの時間は、静的な html ファイルの取得のみであろうと、大きな画像の取得であろうと、元の要求が行っていることと関係があります。ドキュメント、またはDBサーバーで重いクエリを実行する必要があるなど。

  • HTTP 要求をサーバーに送信する唯一のクライアントですか? おそらくそうではありません。そのサーバー マシンは HTTP サーバーのみを収容していますか? サーバーが複数のクライアントからのリクエストを処理している、または処理する予定であることに注意してください。これは、サーバーが複数のリクエストを同時に処理できる場合でも、他のリクエストが何をしているかによっては、応答が遅れる別の要因になる可能性があります。複数のリクエストが原因で応答できない HTTP サーバーの極端な例は、サーバーが [分散型] サービス拒否攻撃を受けている場合です。

  • HTTP サーバーを保護する、または HTTP サーバーが存在するネットワークを保護するファイアウォールはありますか?? ファイアウォール ルールまたはネットワーク侵入検知システムがあると、要求/応答時間が遅くなる可能性があります。

  • 以下は、「リクエストが実際に送信されてから20秒遅れてネットワークに表示される理由として考えられること」の別の要因である可能性があります。これは「ネットワークの輻輳」と呼ばれ、通常はルーター レベルで発生します。

ポイント番号4について：

  • ポイント 3 に関連する要因を破棄または排除したら、次の方法でパフォーマンスを向上させることができます。

  • まず、他のすべてが遅延の[主要な]要因ではないため、予想される応答時間を把握してください。

  • 第二に、どのような条件/状況下で往復にかかる時間を合理的に正確に測定できるかを確認してください。HTTP サーバーのせいではないと思います。

  • 第 3 に、それでも遅延が発生する場合は、ルーターの構成、ファイアウォールの構成、および HTML ページ コード (ある場合) または Web アプリケーション (ある場合) を確認する必要があります。

編集：

HTTP サーバーに ping を実行して、ネットワークのラウンドトリップ時間を確認してください。

以下に例を示します。私はこのコマンドを提出しました：

ping www.yahoo.com

クライアント PC の MS-DOS ウィンドウから。

ここに画像の説明を入力

1) 往復に約 0.5 秒以下 (0.5 秒 = 500 ミリ秒) かかることに注意してください。私は米国東海岸にいますが、Yahoo.com は米国西部の料金になる可能性があります (よくわかりません)。

2) すべての往復が常に同じ長さであるとは限りませんが、変動は小さいことに注意してください。

3) 私のローカル PC から Yahoo.com のような世界クラスの露出したサーバーまで、いくつかの要求、ルーター、およびファイアウォールが間にあり、応答時間は 1 秒もありませんでした。これは、ネットワークとサーバーが適切に構成されていれば、遅延の原因となることはめったにないことを意味します。つまり、HTTP サーバーのせいにする前に、ページまたはアプリケーションを徹底的に調査/レビューする必要があります。

4) ブラウザからリクエストhttp://www.yahoo.comを送信すると、ページの読み込みに 0.5 秒強かかりました。ページ内のすべての html 要素と広告が原因だと思いますが、HTTP サーバーの応答はおそらく0.5秒。

于 2013-03-22T19:47:23.793 に答える
0

ポイント # 4 : 大量のデータの場合、ネットワークで費やされる時間はかなりの量になる可能性があります。サーバーがサポートしている場合は、コンテンツを送信する前に圧縮することをお勧めします。

于 2013-04-04T04:30:01.637 に答える