オンラインユーザーのhostname,ip,オペレーティングシステム,メーカーを取得
オンラインユーザーホスト名、ip、オペレーティングシステム、メーカーを取得
背景:最近クラウドACとドッキングする仕事をしています.オンラインユーザーの情報をサーバにアップロードする必要があります.については、オンラインユーザの無線レート、トラフィックなどは無線駆動で取得でき、ioctlで対応するデータを取得できる.しかし、オンラインユーザーのホスト名、ip、オペレーティングシステム、メーカーについては.ワイヤレスドライバでは取得できません.APはブリッジの役割を果たしているからです.だからAPのホスト名が分からないのは道理です.しかし、私たちの2.8ページにはこれらの機能があります.これはどうやってできたのでしょうか.
コードを見ると、APがこれらの情報を取得したのは、DHCP要求メッセージに基づいて取得されたものであることがわかります.そこで、DHCPメッセージとは何か、なぜこれらの情報を得ることができるのかを理解しましょう.
DHCPプロセス
ここで、私は簡単に私たちのユーザーがオンラインになる過程に従って分析します.DHCP要求は全部で4つのステップに分けられる:1.ユーザはまず、ブロードキャストパケットであるDHCP discoverパケットを送信する.(ipが必要ですが、どのDHCPがipを割り当てることができますか)2.ローカルエリアネットワーク内のDHCPサーバは、このブロードキャストパケットを受信すると、DHCP offerユニキャストパケットに返信します.複数のサーバがブロードキャストパケットを受信すると、複数のサーバがofferユニキャストパケットに返信します.(私はあなたにIPを割り当てることができて、IPは*)3.ユーザが複数のofferパケットを受信した場合、通常は最初のパケットのみが処理されます.offerパケットを受信すると,ユーザはIPを対応するIPに設定する.DHCP requestブロードキャストパッケージをもう1つ送信します.(こんにちは、私はこのIP*****を使っています.IP情報はoption 50の中にあります).ローカルエリアネットワーク内のDHCPサーバは、DHCPリクエストパケットを受信すると、中の情報に基づいて、自分が割り当てたIPを使用しているかどうかを確認し、もしそうであれば、記録し、そうでなければ構いません.ack確認メッセージを返します.
上記の手順では、最初のパケットと2番目のパケットがブロードキャストパケットであり、ローカルエリアネットワーク内のAPでも入手可能であることがわかります.だから方案の1:私達の前の方法は、APの設備の中で、1つのsocketを書いて、ずっとAPを受け取ったDHCPの包みを読み取って、それから分析を行います.まずDHCP requestパッケージを見つけます.次にoptionオプションでコンテンツを読み込みます.hostnameはoption 12にあります.ipはoption 50にあります.オペレーティングシステムはoption 55でメーカーはmacアドレスの最初の3バイトに基づいて計算したouiです.macアドレス対応メーカーのテーブルがあります.以上の方法は,我々の従来のAPがオンラインユーザ情報を取得する方法である.
oui
oui(組織一意識別子)は、いずれかのNIC(NIC)において登録された6バイトのMACアドレスにおいて、最初の3バイトは、NICの製造組織を示すOUIを表す.通常、識別子は一意です.
評価
これまでの実装方式によれば,このスキームには多くの不足点があることが明らかになった.1.携帯電話ごとにDHCP requestパッケージを送信するのではなく、hostnameオプションがあります.すなわち,hostnameを取得できないオンラインユーザがいる可能性が高い.2.オペレーティングシステムとメーカーは、対応するテーブルに基づいて計算します.これには限界がある.それは時間が経つにつれて、市場のモバイルクライアントの更新が変わり、このテーブルも更新する必要があるということです.更新ごとに、ソフトウェアを再詳細にします.型番が多くなったので,これではなおさら不適切に見える.(私は赤米4 Aの携帯電話をAPワイヤレスに接続しましたが、ページには私のオペレーティングシステムがwindonsであることが表示されています.コードは2015年なので、表が更新されていないので、エラーが発生しました)
HTTP
httpのパッケージをキャプチャしたとき、こんな情報があることに気づきました.
この業界の情報から、オペレーティングシステム、携帯電話のモデル、メーカーを得ることができます.これはhttpのパケットをキャプチャすることで,オンラインユーザのいくつかの情報を取得できることを示している.この方法の利点は、自分でテーブルをクエリーする必要がないことです.直接お大事に情報を得ることができます.具体的にはなぜhttpがこれらの情報を得ることができるのか、http-User-Agentの説明をネットで検索することができます.
1.実はこの案にも足りないところがあります.それは、オンラインのユーザーがhttpのパッケージを送らなければ、私はこれらの情報を得ることができません.ページに表示される情報は、同期しないはずです.2.user-agent文字列を具体的に理解すると、ブラウザによって取得されるデータも異なります.一般的に、取得できるのはオペレーティングシステム名です.
まとめ
以上の2つの方法で.私たちは知ることができます.シナリオ1:対応するテーブルを更新する必要があり、後期のメンテナンスに不便であるシナリオ2:対応する情報を正確に保証できない.同期しないことを示します.
今では多くの携帯電話が2回目の接続後にrequestから始まり、できなければdiscoverから始まります.
背景:最近クラウドACとドッキングする仕事をしています.オンラインユーザーの情報をサーバにアップロードする必要があります.については、オンラインユーザの無線レート、トラフィックなどは無線駆動で取得でき、ioctlで対応するデータを取得できる.しかし、オンラインユーザーのホスト名、ip、オペレーティングシステム、メーカーについては.ワイヤレスドライバでは取得できません.APはブリッジの役割を果たしているからです.だからAPのホスト名が分からないのは道理です.しかし、私たちの2.8ページにはこれらの機能があります.これはどうやってできたのでしょうか.
コードを見ると、APがこれらの情報を取得したのは、DHCP要求メッセージに基づいて取得されたものであることがわかります.そこで、DHCPメッセージとは何か、なぜこれらの情報を得ることができるのかを理解しましょう.
DHCPプロセス
ここで、私は簡単に私たちのユーザーがオンラインになる過程に従って分析します.DHCP要求は全部で4つのステップに分けられる:1.ユーザはまず、ブロードキャストパケットであるDHCP discoverパケットを送信する.(ipが必要ですが、どのDHCPがipを割り当てることができますか)2.ローカルエリアネットワーク内のDHCPサーバは、このブロードキャストパケットを受信すると、DHCP offerユニキャストパケットに返信します.複数のサーバがブロードキャストパケットを受信すると、複数のサーバがofferユニキャストパケットに返信します.(私はあなたにIPを割り当てることができて、IPは*)3.ユーザが複数のofferパケットを受信した場合、通常は最初のパケットのみが処理されます.offerパケットを受信すると,ユーザはIPを対応するIPに設定する.DHCP requestブロードキャストパッケージをもう1つ送信します.(こんにちは、私はこのIP*****を使っています.IP情報はoption 50の中にあります).ローカルエリアネットワーク内のDHCPサーバは、DHCPリクエストパケットを受信すると、中の情報に基づいて、自分が割り当てたIPを使用しているかどうかを確認し、もしそうであれば、記録し、そうでなければ構いません.ack確認メッセージを返します.
上記の手順では、最初のパケットと2番目のパケットがブロードキャストパケットであり、ローカルエリアネットワーク内のAPでも入手可能であることがわかります.だから方案の1:私達の前の方法は、APの設備の中で、1つのsocketを書いて、ずっとAPを受け取ったDHCPの包みを読み取って、それから分析を行います.まずDHCP requestパッケージを見つけます.次にoptionオプションでコンテンツを読み込みます.hostnameはoption 12にあります.ipはoption 50にあります.オペレーティングシステムはoption 55でメーカーはmacアドレスの最初の3バイトに基づいて計算したouiです.macアドレス対応メーカーのテーブルがあります.以上の方法は,我々の従来のAPがオンラインユーザ情報を取得する方法である.
oui
oui(組織一意識別子)は、いずれかのNIC(NIC)において登録された6バイトのMACアドレスにおいて、最初の3バイトは、NICの製造組織を示すOUIを表す.通常、識別子は一意です.
評価
これまでの実装方式によれば,このスキームには多くの不足点があることが明らかになった.1.携帯電話ごとにDHCP requestパッケージを送信するのではなく、hostnameオプションがあります.すなわち,hostnameを取得できないオンラインユーザがいる可能性が高い.2.オペレーティングシステムとメーカーは、対応するテーブルに基づいて計算します.これには限界がある.それは時間が経つにつれて、市場のモバイルクライアントの更新が変わり、このテーブルも更新する必要があるということです.更新ごとに、ソフトウェアを再詳細にします.型番が多くなったので,これではなおさら不適切に見える.(私は赤米4 Aの携帯電話をAPワイヤレスに接続しましたが、ページには私のオペレーティングシステムがwindonsであることが表示されています.コードは2015年なので、表が更新されていないので、エラーが発生しました)
HTTP
httpのパッケージをキャプチャしたとき、こんな情報があることに気づきました.
User-Agent: Mozilla/5.0 (Linux; U; Android 6.0.1; zh-cn; Redmi 4A Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/53.0.2785.146 Mobile Safari/537.36 XiaoMi/MiuiBrowser/9.2.8この業界の情報から、オペレーティングシステム、携帯電話のモデル、メーカーを得ることができます.これはhttpのパケットをキャプチャすることで,オンラインユーザのいくつかの情報を取得できることを示している.この方法の利点は、自分でテーブルをクエリーする必要がないことです.直接お大事に情報を得ることができます.具体的にはなぜhttpがこれらの情報を得ることができるのか、http-User-Agentの説明をネットで検索することができます.
1.実はこの案にも足りないところがあります.それは、オンラインのユーザーがhttpのパッケージを送らなければ、私はこれらの情報を得ることができません.ページに表示される情報は、同期しないはずです.2.user-agent文字列を具体的に理解すると、ブラウザによって取得されるデータも異なります.一般的に、取得できるのはオペレーティングシステム名です.
まとめ
以上の2つの方法で.私たちは知ることができます.シナリオ1:対応するテーブルを更新する必要があり、後期のメンテナンスに不便であるシナリオ2:対応する情報を正確に保証できない.同期しないことを示します.
今では多くの携帯電話が2回目の接続後にrequestから始まり、できなければdiscoverから始まります.