不安定なページの読み込みや通常のユーザーのサイトへのアクセス不能を分析する際のアクションのシーケンスを決定することを目的とする記事をご紹介します。 さらに、私の計画をhabrasocietyの一般的な精神で補完することを提案します。そのため、共同で「非システム管理者向けのメモ」を作成するために、投稿の下であなたのコメントを待っています。



それでは始めましょう。



そもそも、Wi-Fi接続の不足、インターネットプロバイダー側​​の問題、またはラップトップのソケットとバッテリーのケーブルの不足など、誤動作の可能性のリストから最も明白で診断しやすいものを除外する必要があります。



また、システム管理者の直接の介入を必要とするローカルインターネットまたはコンピューター自体の困難な問題と誤動作を省くことを提案します。 トロイの木馬ウイルス、ハードウェア、ブラウザまたはオペレーティングシステムの問題、ルーターのMTU、誤ったDNS設定またはDNS障害、および検出可能な一連の問題がありますが、この場合の記事は本になり、さらにはトレーニングコースで。



インターネットに問題はなく、サイトは正常に読み込まれていますが、サイトは断続的に利用できるか、まったく利用できないという事実について詳しく見てみましょう。

理由を見つける方法は？

1.インターネットは、サーバーからサーバーへとつながる膨大な数の高速道路であり、サーバーが機能し、他のサイトが表示される場合がありますが、ここから私たちからサイトへのパケットパスが壊れています。その後、プロバイダーのチャネルに不具合がありました。 もちろん、コンソールでは、 tracerouteコマンド（Windowsのtracert）は、サイトのサーバーにアクセスできるかどうか、サーバーのパケットが通過する場所、「停止」する場所を表示します。 tracerouteとpingがサーバーに到達せず、ホストネットワークに到達する場合は、この場合は自分で何かを行うのが難しいため、ホスティングまたはシステム管理者にテクニカルサポートに連絡する時が来ました。



Tracerouteとpingは単純なチームです。Wikipediaには、このトピックに関する非常にアクセスしやすい説明付きの記事があります。

https://ru.wikipedia.org/wiki/Traceroute

https://ru.wikipedia.org/wiki/Ping



tracerouteがサイトへの途中のトランクチャネルのどこかに「固執」する場合、プロバイダー/外部のグローバルネットワークの他のサーバー（コンピューター）からサーバー/サイトがどのように見えるかを必ず確認することをお勧めします。 それらは、高い確率で他の高速道路を使用し、tracerouteが他のチャネルを介してサーバーに正常に渡されることがよく見られます。 例えば

http://network-tools.com/default.asp?prog=express&host=www.reg.ru



すべてが正常である場合、プロバイダーまたはそのプロバイダーのいずれかがより高いレベルの問題を抱えていますが、サーバーの近くではなく、サーバー上ではありません。

これで、ローカルプロバイダーのテクニカルサポートに電話して、「主なチャネルは何ですか？」と尋ねることができます;）



2.インターネットチャネルの速度と安定性は、ユーザーからサーバーに向かう最速の通信チャネルと最悪の通信チャネルの速度と安定性です。 「途中で」パケット損失、 mtrユーティリティを使用して異なるプロバイダー間またはユーザーとプロバイダー間の大きなパケット遅延に問題があるかどうかを判断できます。ユーティリティの結果は、特に大きなパケットサイズとその可能なセグメンテーション（1500バイトなど）を示しています。



Mtrはping（パケットパスに沿って各サーバーをポーリングする）とtraceroute（パケットパス全体を決定する）のようなものですが、パケットの一定の流れにより、ユーティリティは大量のトラフィックを消費することに注意してください。



呼び出し例：

mtr -s 1500 --report .com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

yahoo.comの確認リクエスト：

 HOST: xxx.reg.ru Loss% Snt Last Avg Best Wrst StDev 1.|-- 31.31.xxx.xxx 0.0% 10 43.4 16.7 0.5 102.8 33.1 2.|-- bdi-799.sr7.msk1.ip.di-ne 0.0% 10 1.5 1.5 1.5 1.7 0.1 3.|-- vlan-793.br1.msk1.ip.di-n 0.0% 10 0.8 0.8 0.8 0.9 0.0 4.|-- 31.28.19.100 0.0% 10 0.9 4.5 0.9 36.8 11.3 5.|-- ae0-948-rt2.spb.cloud-ix. 90.0% 10 14.7 14.7 14.7 14.7 0.0 6.|-- ae0-59-rt1.frk.cloud-ix.n 10.0% 10 37.7 37.8 37.7 38.3 0.2 ... 15.|-- po-15.bas2-7-prd.gq1.yaho 10.0% 10 204.7 207.0 204.5 211.1 2.8 16.|-- ir1.fp.vip.gq1.yahoo.com 10.0% 10 204.7 227.4 204.7 281.4 32.1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リストに表示される最終サーバーのパケット損失率（Loss％）の値が表示されます。 中間サーバーでの損失は、最終サーバーに影響を与えない場合、おそらくそれらへのテストパケット数（ICMPトラフィック）の制限によるものです。



通常、大きなパケットの30-50％の損失がある場合、接続の問題はすでに顕著になり（ページが「スティック」し、アイテムの負荷が低いために速度が低下します）、パーセンテージが高いほど、突破が困難になります。



たとえば、オフィスからプロバイダー（存在する場合）への次のWi-Fiリンクなど、中間ノードで問題が発生する可能性があります。 さらに、原因はプロバイダー間の通信およびパケットルーティングの問題である可能性があります。



チャネルの問題を診断するためのmtrの使用に関する詳細な記事（英語）は、 ここまたはWikipediaで見つけることができます。

Windows NTのmtrユーティリティのようなものがパスしています。



プロバイダー（または当社のサーバー）が完全に無効になっているか、これらのテストパケット（ICMPトラフィック）を渡す機能が制限されている場合があります。 この場合、そのようなテストは問題の特定に役立ちません。 もちろん、ここでは「各自の悪意のあるピノキオ」について覚えておくのが正しいでしょう。サーバーをチェックする機能を無効にすると、チェックできなくなります:-)。



3.上記のテストで問題が見つからなかった場合は、視覚的で便利なメインツールであるChrome開発者ツール （SafariのWebインスペクター、Firefox Develper Tools）を使用します。

https://developers.google.com/chrome-developer-tools/

https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/Introduction/Introduction.html

https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor



Chrome開発者ツール（メニュー-> [ツール]-> [開発者ツール]）を使用する場合、[ネットワーク]タブでサイトのページを更新し、サイト上のすべてのリソースのロード方法に関するレポートを取得します。











サイトページの読み込みが（ゆっくりではありますが）成功すると、ページのメインコンテンツが読み込まれ、表示用のフォームが開始されたとき、ページ要素との連携に関連するすべての埋め込みJavaスクリプトと、メインコードと必要なコードの完全なダウンロードの待機がサイトで開始されたときに表示されます未定義の追加のネストされた要素。 この瞬間は上の図にあります：青い縦線はDOMContentLoadedイベントで、赤い縦線はwindows.onLoadイベントの操作です（スクリプトが既に機能し、要素を含むページ全体が形成されている場合、画像の内容が読み込まれます）。



この情報ツールを使用して、ページのメインコンテンツとメインのhtmlコードをロードしても問題ないかどうかを確認できます。つまり、サーバーが完全に「ライブ」であり、メインサイトエンジンの速度が低下しないことを確認します。

これはリストの最初の項目です。 クリックすると、より詳細なサーバー応答時間を取得できます。











ここでわかるように、ブラウザーはサーバーからのデータを68ミリ秒待機し（サーバーは受信したリクエストでページを形成しました）、2ミリ秒受け入れられました（これは十分高速です）。



この情報から、サイトの読み込みが遅いことが問題であることがわかります。たとえば、これはミリ秒ではなく、メインページコードの30秒の形成です。 これは、サーバーまたはプロバイダーが要求で過負荷になっている場合、非効率的なコードが使用されている場合（特に、このページの要求が長い間機能している場合）、またはシステム管理者やエンジンのプログラマーが分析できるその他の理由がある場合に発生します。



以下のダウンロードグラフのリストでは、ページ上のどのリソースがより長くロードされるか、ページがブラウザに表示される前にページが待機するリソース、および表示をブロックするリソースが表示されます。



ブロックの一般的な理由は、（DOMContentLoadedイベントにバインドする前に）ページのコンテンツを変更/形成するスクリプトの作業の開始時点が、外部の統計収集サービス、広告エンジン、またはリンク交換ページに依存していることです。 通常、これらは「別の」外部スクリプトを挿入するスクリプトの一部です。

 <script> document.write('<scr'+'ipt type="text/javascript"'+' src="http://jsc.dt00.net .... </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのシステムは他の人のサーバーにあり、多くの場合、システム管理者がアクセスできないため、次のように動作できます。











つまり、<script ...>ブロックがロードされて実行され、それが外部リソースを参照するまで、ブラウザーは多くの場合ページコンテンツを表示したり、誤って表示したりすることなく、そこから結果を期待しますが、最新のブラウザーエンジンは先を行く可能性があります。



そのため、上記のスクリーンショットでは、admobi.ru（admobi.js）からの広告スクリプトの読み込みにより、ページ上のスクリプトの作業が135ミリ秒の遅延で開始されました。 広告コードと統計を配信するサーバーが利用できる場合がありますが、応答が遅いため、ブラウザは接続に成功して数十秒間応答を待つことができます。



4. traceroute（p。1）と同様に、開発者ツール（p。3）を介したページの読み込みに関する情報は、同様の外部アナライザーサービスを使用して、「サーバーの奇妙な外観」で確認できます。

http://www.uptrends.com/aspx/free-html-site-page-load-check-tool.aspx



それはどのように見えますか：

















およびhttp://tools.pingdom.com/fpt/



一時的な結果を伴う最初のサービスのファイナルテーブルに注意してください。 また、2番目の表の冒頭には、「他のネットワークサイトと比較して速度でサイトがどのように利用できるか」のランキング、およびリクエスト（要素）の数、すべてのページ情報の読み込みのボリュームと時間が示されています。











このようなレポートとブラウザーのダウンロードタイムラインとの比較は、プロバイダーを介したサイトのダウンロードがこれら2つのサービスのダウンロードとは異なり、最大の遅延が発生する場所を示します。 たとえば、HTTPSハンドシェイクでも、証明書プロバイダーのサーバー上でユーザーからの証明書をチェックする際に顕著な遅延が発生する可能性があります。



これら2つのサービスのもう1つの「トリック」は、テストリクエストの送信元サーバーを選択する機能です。つまり、ベルリン、ニューヨーク、またはモスクワのサーバーからページを読み込む方法をシミュレートします。



5.奇妙で頻繁な「固着」はありません。

時々、予測できない頻度で、ページスティックが発生します。 たとえば、1日に1回。 初めて-長い休憩の後、または偶然でも。 そのような場合はキャッチするのがより困難です。

このような問題の可能性のあるオプションを使用して、共通の精神を強調し、補足することを提案します。

• プラグインの操作に関する問題。これは、最新のブラウザーでは膨大な量です。
  
  
  • すべてを取り外して比較します。
  • またはその逆に、adblockおよびghosteryプラグインを有効にします（探してください！）。
  
  
  
• 休憩後のサーバーとの最初の接触。
  
  ブラウザのセキュアなSSLセッションの開始は、通常、最初のキー交換と証明書検証のために遅くなります。 これは、ブレークまたはキャッシュ/キーのクリア後にサイトに入るときに発生します。
  
  
• 統計コレクター、広告ネットワーク、バナー交換など、表示をブロックできる他の人の（外部）スクリプトおよびページ要素を読み込むときに、証明書またはキーを取得してログに記録します。
• サーバーとの接続が良好な場合、前の段落で言及したすべての要素が、この埋め込み要素を提供するサーバーではそれが悪いか、オーバーロードされています。
  
  上記の段落のいずれかで述べたように、スクリプトがロードされるまで、ページはレンダリングに「固執」することがあり、OnDom / OnLoadは遅延して処理されます。 多くの場合、他のページを表示するときに、この要素は既にキャッシュされており、すべてが正常に配置されています。 ここで、hostsファイル内でしばらくの間hostsファイルにリクエストを追加することにより、これらの外部サーバーへのリクエストを除外しようとすることができます（Developer Toolsにブレーキが表示されます）。
  
  
  • 統計収集server.ru 127.0.0.1;
  • ad-server.com 127.0.0.1;
  • その他のサーバー、ページで呼び出されるスクリプト。
  
  
  ネットワーク内のインターネット上のサーバーの代わりに「ラップトップに直接」（localhost、127.0.0.1に）リクエストをリダイレクトする場合、上記の例のように2番目の遅延が発生する可能性があることに注意してくださいポートはタイムアウトまでに応答しません。
  
  
• 負荷分散中にページが1つではなく複数のサーバーを順番に返す場合、数回後に何らかの「タイトな」サーバーに到達し、再び高速なサーバーに到達することがあります。
  
  ここでは、負荷が分散されるサーバー名とは別のサーバー名があるかどうかを確認し、直接作業できます。
• 静的アップロードサーバーが別のサーバーによって発行された場合の問題。 ここでは、すべての統計には有効期限の顕著なマージンがあるため、その後のダウンロードは頻繁に行われます。したがって、一度ダウンロードが遅くなると、ページは正常にロードされます。 開発者ツールは、キャッシュをクリアまたは無効にするオプションでこれを明確に確認するのに役立ちます。
• サイトのページを編集するときに「ブレーキ」が観察された場合は、ページから外部広告と統計の要素とブロックを除外し、更新して問題を特定します。

もちろん、多くの問題が考えられます。完全なリストを作成するには、ブレインストーミングセッションを手配する必要があります。 たとえば、かつてはブラウザの新技術の遅れがあり、svgによるベータ版やSPDYなどの新しいプロトコルの不具合がありました。 しかし、これはあなたがどのようにさらに考えることができるかの例に過ぎず、ここでは、システム管理者の直感、経験、そして最も重要なことに、そのタンバリンのサイズと品質はすでに重要です。