ネットワーク の 品質 が 向上 すると 接続。 Wi

ネットワーク構築講座|ワークグループネットワーク構築編

ネットワーク の 品質 が 向上 すると 接続

ネットワークのトラブルシュートなどをする時にtcpdumpやといったツールを使ってキャプチャデータを取得し、正常ではない通信を特定するなど分析します。 その時にIPアドレスやポート番号といったことは当然確認すると思いますが、本記事ではそれ以外に分析に利用できそうな小技をいくつか紹介したいと思います。 お題は以下のとおりです。 MACアドレスからNICのベンダーが分かる• IPヘッダからおおよそのホップ数が推測できる• TCPの3-way-handshakeからネットワークの遅延を測れる• TCPの再送状況からネットワーク品質の変化を見れる• TLSのclient helloから接続先のホスト名がわかる 【注意事項】• 本職のネットワークエンジニアの方にとっては当たり前すぎる内容なので読む価値無しと思われます。 むしろ自分が本職のネットワークエンジニアではないので、仕様の間違いのご指摘など歓迎です。 ここで紹介する小技はネットワークキャプチャ以外の能動的なパケット送信ができない、あるいはしにくい状況を想定しており、能動的なパケット送信によっておおむね同じような情報を取得できる方法はあります• ネットワークキャプチャはあくまで自分の管理権限がある箇所のみで実施してください。 不用意なネットワークキャプチャは法に触れる可能性もありますのでご注意ください。 MACアドレスからNICのベンダーが分かる 無線にしろ有線にしろLAN(正しくはEthernet)に接続する場合はNIC(ネットワークインターフェースカード)にIPアドレスを割り当てて通信します。 IPアドレスは時と場合によって変化しますが、NICに割り当てられているMACアドレスは基本的に変更されることはありません。 MACアドレスは6バイトで構成されていますが、先頭3バイトはOUI(Organizationally Unique Identifier)と呼ばれるベンダー固有のIDとなっており、IEEEのサイトで確認できます。 自分で探すこともできますが、Wiresharkを使うと勝手にベンダー名を表示してくれます。 これを使うことで、トラブルシュート時に対象になっているIPアドレスがどのベンダのNICを使っているかがわかり、対象ホストの絞込が(多少)容易になります。 IPヘッダからおおよそのホップ数が推測できる IPヘッダにはパケットのループを防ぐためにTTL(Time To Live、パケット生存時間)という値が設定されており、これがルータを経由するたびに1ずつ減少して、0になるとパケットが破棄されます。 このTTLは最大値が255とは決まっていますが、送信時にいくつに設定しなければいけないとは決まっていません。 しかしOSごとにデフォルト値がきまっており、今日日よく使われているOSはだいたい2のn乗(32, 64, 128など)になっています。 4 は64になっていました。 よって、例えば観測されたパケットのTTLが 56 だったとしたら、それよりも大きい2のn乗の値である 64 がもともとのパケットのTTLであり、その送信元ホストは8ホップ先にいるのかな、ということをおおよそ推定することができます。 ただし、当然ながらデフォルトのTTL値は変更できるため、あくまでtracerouteなどのツールで正確なホップ数を計測できない時に推量するための方法になります。 代表的なものとしてというツールがあります。 例えば capture. pcap というファイルにキャプチャデータが入っていた場合、以下のように利用できます。 pcap -o p0f. log これによってp0f. logに結果が出力され、以下のように表示されます。 これによってトラブルシュートの対象のホストがどのようなOSを利用しているかを推定し、対象ホストの絞込などに活用できます。 この方法はパケットを送信することなく利用できるので、システムに影響を及ぼさない良い方法に思えますが、一方で推定に使える情報が限られているので概ね精度はあまり高くないという点に注意してください。 TCPの3-way-handshakeからネットワークの遅延を測れる 通常、ネットワークの往復応答時間(Round Trip Time, RTT)を測るためにはpingコマンドなどを用いたICMP echoを用いることが多いですが、能動的にpingをうつのがはばかられる場合や、ネットワーク監視で観測された宛先全体に対しての応答時間を調べたい場合などがあります(例えばあるサーバだけが遅いのか、上流で全体が詰まっているのかどうかの調査など) そこでネットワークキャプチャだけでこれを調べる方法としてTCPの3-way-handshakeを利用する方法が考えられます。 TCPは通信の開始時にSYNパケット、SYN-ACKパケット、ACKパケットをクライアント、サーバ間で相互に投げ合い、通信を確立します。 これを利用して「SYNパケットが観測されてからACKパケットが観測されるまでの時間」を見ることでおおよそのクライアント・サーバ間のRTTを知ることができます。 図にすると以下のような感じです。 現実には監視ポイントはクライアント、あるいはサーバ側に極めて近いポイントであると考えられるため、SYNパケットとSYN-ACKパケットの差分時間、あるいはSYN-ACKパケットとACKパケットの差分時間でほとんどRTTに近い値が取れると思われます。 TCPの再送状況からネットワーク品質の変化を見れる ブロードバンド環境の普及に伴い、一般の我々が使うネットワークの品質も大きく向上しましたが、手元のルータの不調や上流の回線・ISPの問題でパケットロスが発生することもままあります。 これも通常は短い間隔で連続してICMP echo requestなどを送信しパケットロス率などを調査することがありますが、TCPの再送処理をみることでパケットロスが発生しているのかしていないのかをおおよそ把握することができます。 ストリーム型の通信を提供するTCPは送信したデータに対して受け手がACK(受領確認)を送信することで、正しくデータが届いたかどうかを送信側が確認しながら通信を続けます。 そのため、再送処理が発生している=どこかでパケットロスなどが発生したと考えることができます。 Wiresharkのデフォルトの設定ではTCPの再送処理などに関連するパケットは黒色の行で表示されます。 上記の図では複数回黒い行が発生していますが、これはサーバから送信されたパケットが1つ欠損したのに対し、速く欠けたパケットを送れとクライアントが急かしているために送っているACKパケットも黒く表示されているだけで、パケットロス率が多くなっているわけではありません。 このように黒い行の数だけパケットロスが起こっているわけではないのですが、Wiresharkの画面で見るとすれば、この黒い行が継続して発生している場合はネットワークの品質が悪くなっている=パケットロスが継続的に発生していると考えることができます。 それを知るための大きな手がかりとして対象ホストのホスト名が挙げられます。 DHCP: Dynamic Host Configuration Protocol, 主に動的なIPアドレス割り当てに利用されるプロトコル、UDP port 67, 68• mDNS: multicast DNS, AppleのBonjourで使われている名前解決プロトコル, UDP port 5353• LLMNR: Link Local Multicast Name Resolution, Windows用の名前解決プロトコルでVista以降に実装, UDP port 5355• NBNS: NetBIOS Name Service, NetBIOSでホスト名を解決するプロトコル, UDP port 137 mDNS, LLMNR, NBNSはそれぞれ名前解決のためのプロトコルなので、その中にホスト名が含まれているのはある意味当然ですが、DHCPでもホスト名のやり取りがあります。 ホストがネットワークに接続して最初にDHCPサーバを探索するDHCP discoverメッセージの中のオプションにHost Name Optionというものが含まれています。 なおmDNSやLLMNRはホストがネットワークに接続している状態であれば能動的に名前を問い合わせることもできます。 (本来そういう目的のプロトコルなので) TLSのclient helloから接続先のホスト名がわかる 近年HTTP通信を全てTLS化(HTTPS化)するという流れがあり、クライアント側からするとセキュリティ向上のためにはとても良いことなのですが、一方でネットワーク管理・トラブルシュートする側からすると問題を起こしているTCPセッションがどれなのかを特定するのが難しくなるという悩みがあります。 特に同じIPアドレスに対して複数のドメイン名をホストしている場合だと、HTTPの中身は全く見えないためTCPセッションの区別が極めて難しくなります。 そこでTLSのServer Name Indication拡張のフィールドを見ることによって、どのホスト名(FQDN)に接続しようとしていたのかを知ることができます。 TLSはその上に乗るHTTPのデータなどは完全に暗号化していますが、クライアント・サーバ同士のやりとりでは平文で最初のハンドシェイクなどをしており、その中にあるServer Name Indication拡張ヘッダの中に接続しようとしているホスト名が記述されています。 ちなみに、監視している通信のサーバに管理権限がある場合、TLSのサーバ証明書、秘密鍵・公開鍵を使って無理やりTLSの暗号化部分を解読することも技術的には可能です。 Wiresharkにもその機能が実装されているので、詳しくは以下のページを参照してください。

次の

【必見】知らないと損をする、Skype for Business の音声品質を改善する方法とは?

ネットワーク の 品質 が 向上 すると 接続

こんにちは!コラム担当です。 コールセンターは、顧客対応の最前線にあり、顧客満足を向上させ、企業イメージをアップさせるのに大事な役割を担っています。 顧客満足の向上という目標を達成するためには、コールセンター全体の品質を維持することが欠かせません。 今回はコールセンターの応対品質管理について、その方法や改善方法についてご紹介します。 応対品質管理とは コールセンターの品質は、大きく接続品質と応対品質の2つに分けられます。 接続品質は、お問い合わせの電話がつながりやすいと「よい」と判断されます。 回線の数とオペレーターの人数、またオペレーター1人あたりの通話時間などが関係します。 応対品質とは、顧客への電話対応の適切さです。 「応対中の受け答えは迅速か」「言葉づかいは丁寧か」「マナーは守られているか」「顧客の問い合わせの意図を正確に読み取れているか」といったポイントから判断されます。 そしてこの応対品質を管理する施策を「応対品質管理」と言います。 応対品質管理は、応対をモニタリングすることが基本となります。 モニタリングによって、一人ひとりのオペレーターが十分な知識を持っているか、ビジネスマナーを備えているかなど、実践的なスキルを計測します。 具体的な施策内容としては、オペレーターが顧客応対を行っている様子をモニタリングして、チェックし、評価とフィードバックを繰り返します。 モニタリングとフィードバックを繰り返すことで、コールセンター内で求められている応対レベルの維持管理が可能となります。 もちろんモニタリングはオペレーター全員に対して行い、コールセンター全体の品質を確認します。 このことから、応対品質管理は応対スキルを向上させるためには欠かせない施策だと言われています。 応対品質管理はなにをするべきか 応対品質管理として、現場ではどのようなことが行われているのでしょうか。 各コールセンターの状況によって方法はさまざまですが、管理者が応対中の音声をネットワーク越しにモニタリングする方法や、過去の記録から任意に取り出した対応音声を確認するといった方法が一般的です。 また、端末操作の状況がわかるように管理者が物理的にオペレーターのそばに座り、音声と同時に端末操作手順をモニタリングする場合もあります。 モニタリング結果は、その時点でのコールセンター全体の状況を把握するためにも役立ちますし、各オペレーターにフィードバックを行って改善を促すための資料にもなります。 応対品質の測り方 応対状況のモニタリングにおいて確認するポイントは「礼儀正しいか」「応対に必要な知識を備えているか」「対応は正確か」「顧客との情報のすり合わせができているか」などが重要なポイントと考えられています。 なお、ポイントの確認を伴うモニタリング作業は、スーパーバイザーや応対品質管理の専門スタッフ、役職者が行うケースのほか、応対品質管理を専門とする外部業者に委託する場合があります。 また、より数値的な指標としてATT(Average Talk Time)と呼ばれる1件あたりの平均通話時間やACW(After Call Work)平均後処理時間を基準にすることもあります。 ただし、この2つの時間が短すぎる場合、ATTなら顧客満足が低下し、ACWはミスを誘発する場合もあるので、注意が必要です。 応対品質をよりよくしていくためには とはいえ、モニタリングをして評価とフィードバックさえ行っていれば、対応品質が管理されるわけではありません。 モニタリングの結果を人事評価に利用している企業もありますが、対応品質管理はオペレーターのモチベーションや意識の向上にも役立てることが大切です。 結果をふまえた具体的なフィードバックとアドバイス、さらには全体に向けたマニュアル作成や情報共有がオペレーターのモチベーションの維持にもつながります。 さらに、対応品質の向上には応対品質管理自体にKPIを設けることが欠かせません。 たとえば、モニタリングの頻度も重要です。 人事評価のタイミングのみで行っているならば、回数が少ないと言えます。 対応品質管理は、対象者全員に対するモニタリングが定めた期間で行われていること、モニタリング結果のフィードバックが定めた期限内に行われていることが必要です。 くわえて、合格率と合格した人数などのKPIを設定し、全体的な傾向とその変化を繰り返し確認し、改善施策につなげていく必要があります。 まとめ コールセンターの品質管理が重要なのは、企業や商品・サービスのイメージに対してのリスクヘッジや、リピーターのような優良顧客の獲得による利益増大という両側面でのアプローチをコールセンターが担っているためです。 対応品質管理においてKPIの設定が重要視されているのは、この施策が非常に労力がかかる内容だということも要因のひとつでしょう。 その労力のかかる対応品質管理を行う目的はなにか、そもそも自社のコールセンターはどのような体制や品質のもとで応対を行うべきなのかをしっかりと議論することが、よりよいコールセンター運営につながります。

次の

スマホのWi

ネットワーク の 品質 が 向上 すると 接続

ネットワークのトラブルシュートなどをする時にtcpdumpやといったツールを使ってキャプチャデータを取得し、正常ではない通信を特定するなど分析します。 その時にIPアドレスやポート番号といったことは当然確認すると思いますが、本記事ではそれ以外に分析に利用できそうな小技をいくつか紹介したいと思います。 お題は以下のとおりです。 MACアドレスからNICのベンダーが分かる• IPヘッダからおおよそのホップ数が推測できる• TCPの3-way-handshakeからネットワークの遅延を測れる• TCPの再送状況からネットワーク品質の変化を見れる• TLSのclient helloから接続先のホスト名がわかる 【注意事項】• 本職のネットワークエンジニアの方にとっては当たり前すぎる内容なので読む価値無しと思われます。 むしろ自分が本職のネットワークエンジニアではないので、仕様の間違いのご指摘など歓迎です。 ここで紹介する小技はネットワークキャプチャ以外の能動的なパケット送信ができない、あるいはしにくい状況を想定しており、能動的なパケット送信によっておおむね同じような情報を取得できる方法はあります• ネットワークキャプチャはあくまで自分の管理権限がある箇所のみで実施してください。 不用意なネットワークキャプチャは法に触れる可能性もありますのでご注意ください。 MACアドレスからNICのベンダーが分かる 無線にしろ有線にしろLAN(正しくはEthernet)に接続する場合はNIC(ネットワークインターフェースカード)にIPアドレスを割り当てて通信します。 IPアドレスは時と場合によって変化しますが、NICに割り当てられているMACアドレスは基本的に変更されることはありません。 MACアドレスは6バイトで構成されていますが、先頭3バイトはOUI(Organizationally Unique Identifier)と呼ばれるベンダー固有のIDとなっており、IEEEのサイトで確認できます。 自分で探すこともできますが、Wiresharkを使うと勝手にベンダー名を表示してくれます。 これを使うことで、トラブルシュート時に対象になっているIPアドレスがどのベンダのNICを使っているかがわかり、対象ホストの絞込が(多少)容易になります。 IPヘッダからおおよそのホップ数が推測できる IPヘッダにはパケットのループを防ぐためにTTL(Time To Live、パケット生存時間)という値が設定されており、これがルータを経由するたびに1ずつ減少して、0になるとパケットが破棄されます。 このTTLは最大値が255とは決まっていますが、送信時にいくつに設定しなければいけないとは決まっていません。 しかしOSごとにデフォルト値がきまっており、今日日よく使われているOSはだいたい2のn乗(32, 64, 128など)になっています。 4 は64になっていました。 よって、例えば観測されたパケットのTTLが 56 だったとしたら、それよりも大きい2のn乗の値である 64 がもともとのパケットのTTLであり、その送信元ホストは8ホップ先にいるのかな、ということをおおよそ推定することができます。 ただし、当然ながらデフォルトのTTL値は変更できるため、あくまでtracerouteなどのツールで正確なホップ数を計測できない時に推量するための方法になります。 代表的なものとしてというツールがあります。 例えば capture. pcap というファイルにキャプチャデータが入っていた場合、以下のように利用できます。 pcap -o p0f. log これによってp0f. logに結果が出力され、以下のように表示されます。 これによってトラブルシュートの対象のホストがどのようなOSを利用しているかを推定し、対象ホストの絞込などに活用できます。 この方法はパケットを送信することなく利用できるので、システムに影響を及ぼさない良い方法に思えますが、一方で推定に使える情報が限られているので概ね精度はあまり高くないという点に注意してください。 TCPの3-way-handshakeからネットワークの遅延を測れる 通常、ネットワークの往復応答時間(Round Trip Time, RTT)を測るためにはpingコマンドなどを用いたICMP echoを用いることが多いですが、能動的にpingをうつのがはばかられる場合や、ネットワーク監視で観測された宛先全体に対しての応答時間を調べたい場合などがあります(例えばあるサーバだけが遅いのか、上流で全体が詰まっているのかどうかの調査など) そこでネットワークキャプチャだけでこれを調べる方法としてTCPの3-way-handshakeを利用する方法が考えられます。 TCPは通信の開始時にSYNパケット、SYN-ACKパケット、ACKパケットをクライアント、サーバ間で相互に投げ合い、通信を確立します。 これを利用して「SYNパケットが観測されてからACKパケットが観測されるまでの時間」を見ることでおおよそのクライアント・サーバ間のRTTを知ることができます。 図にすると以下のような感じです。 現実には監視ポイントはクライアント、あるいはサーバ側に極めて近いポイントであると考えられるため、SYNパケットとSYN-ACKパケットの差分時間、あるいはSYN-ACKパケットとACKパケットの差分時間でほとんどRTTに近い値が取れると思われます。 TCPの再送状況からネットワーク品質の変化を見れる ブロードバンド環境の普及に伴い、一般の我々が使うネットワークの品質も大きく向上しましたが、手元のルータの不調や上流の回線・ISPの問題でパケットロスが発生することもままあります。 これも通常は短い間隔で連続してICMP echo requestなどを送信しパケットロス率などを調査することがありますが、TCPの再送処理をみることでパケットロスが発生しているのかしていないのかをおおよそ把握することができます。 ストリーム型の通信を提供するTCPは送信したデータに対して受け手がACK(受領確認)を送信することで、正しくデータが届いたかどうかを送信側が確認しながら通信を続けます。 そのため、再送処理が発生している=どこかでパケットロスなどが発生したと考えることができます。 Wiresharkのデフォルトの設定ではTCPの再送処理などに関連するパケットは黒色の行で表示されます。 上記の図では複数回黒い行が発生していますが、これはサーバから送信されたパケットが1つ欠損したのに対し、速く欠けたパケットを送れとクライアントが急かしているために送っているACKパケットも黒く表示されているだけで、パケットロス率が多くなっているわけではありません。 このように黒い行の数だけパケットロスが起こっているわけではないのですが、Wiresharkの画面で見るとすれば、この黒い行が継続して発生している場合はネットワークの品質が悪くなっている=パケットロスが継続的に発生していると考えることができます。 それを知るための大きな手がかりとして対象ホストのホスト名が挙げられます。 DHCP: Dynamic Host Configuration Protocol, 主に動的なIPアドレス割り当てに利用されるプロトコル、UDP port 67, 68• mDNS: multicast DNS, AppleのBonjourで使われている名前解決プロトコル, UDP port 5353• LLMNR: Link Local Multicast Name Resolution, Windows用の名前解決プロトコルでVista以降に実装, UDP port 5355• NBNS: NetBIOS Name Service, NetBIOSでホスト名を解決するプロトコル, UDP port 137 mDNS, LLMNR, NBNSはそれぞれ名前解決のためのプロトコルなので、その中にホスト名が含まれているのはある意味当然ですが、DHCPでもホスト名のやり取りがあります。 ホストがネットワークに接続して最初にDHCPサーバを探索するDHCP discoverメッセージの中のオプションにHost Name Optionというものが含まれています。 なおmDNSやLLMNRはホストがネットワークに接続している状態であれば能動的に名前を問い合わせることもできます。 (本来そういう目的のプロトコルなので) TLSのclient helloから接続先のホスト名がわかる 近年HTTP通信を全てTLS化(HTTPS化)するという流れがあり、クライアント側からするとセキュリティ向上のためにはとても良いことなのですが、一方でネットワーク管理・トラブルシュートする側からすると問題を起こしているTCPセッションがどれなのかを特定するのが難しくなるという悩みがあります。 特に同じIPアドレスに対して複数のドメイン名をホストしている場合だと、HTTPの中身は全く見えないためTCPセッションの区別が極めて難しくなります。 そこでTLSのServer Name Indication拡張のフィールドを見ることによって、どのホスト名(FQDN)に接続しようとしていたのかを知ることができます。 TLSはその上に乗るHTTPのデータなどは完全に暗号化していますが、クライアント・サーバ同士のやりとりでは平文で最初のハンドシェイクなどをしており、その中にあるServer Name Indication拡張ヘッダの中に接続しようとしているホスト名が記述されています。 ちなみに、監視している通信のサーバに管理権限がある場合、TLSのサーバ証明書、秘密鍵・公開鍵を使って無理やりTLSの暗号化部分を解読することも技術的には可能です。 Wiresharkにもその機能が実装されているので、詳しくは以下のページを参照してください。

次の