モスクワの公共ビデオ監視カメラを見続けています

それは夕方でした、何もすることはありませんでした。 その理由は、 コメントで公開リソースへのリンクを提供したユーザーライダーのアクティビティでした。 video.dit.mos.ru/window







画像



このリソースの注目すべき点は、内蔵プレーヤーを介してビデオ監視カメラへのパブリックアクセスを提供することです



画像



この記事では、「塩」、砂糖、健康なものはありません 食べ物 ストーブから直接リンク。



プレーヤーがそのリソースで使用するリンクのリスト:



 http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.1.186_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.0.50_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.41.134_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.23:2033/rtsp___10.194.23.9_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.24:2033/rtsp___10.208.14.78_axis_media_media.amp_camera_4/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.33:2033/rtsp___10.208.14.117_axis_media_media.amp_camera_2/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.121_live_h264/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.1_live_h264/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.153:2033/rtsp___10.232.0.113_live_h264/live
      
      





プログラマーのロジックを「 緩め! 」オンにします。





作業リンク:



壊れたリンク:





検索の自動化



理論:



次に、_camera_4など。 「10.200.30.24:2033/rtsp___10.208.14.7 8 _axis_media_media.amp_camera _4 / live」があり、「10.200.30.24:2033/rtsp ___ 10.208.14.7 7 _axis_media_media.amp_camera _3 / live」がないため、考慮されません。しかし、ロジックに従って、 "_ axis_media_media.amp / live"が存在する必要があります-これが私たちが探しているものです。



キャッシングサーバーのIPリスト



理想的には、範囲として10.200.21.1--10.200.30.254を選択します。



カメラのIPアドレスのリスト:



範囲(再び完璧)として、 10.200を除く10.194.0.1〜10.2.232.255.254のアドレスを使用します。*。* 、私のロジックでは(私がしたように)これらはキャッシュサーバーです。



結果として、クエリのテンプレートは次のとおりです。







50億のアドレスとリクエスト...実際には、リクエストの数ははるかに少なく、10〜15秒のスクリプトダウンタイムで903kのリクエストを保存することもできます...(詳細は以下を参照)。



成功:



失敗:



解析時間を最小限に抑えるために、接続タイムアウトを10000ミリ秒に設定し、リクエストの前とリクエストの後に(サーバーが応答したとき、またはクライアントでタイムアウトが働いたとき)、時間値を保存します。 次に、2番目から1番目を減算し、9500ミリ秒以上が経過すると、1 IP高くなります(キャッシュサーバーの場合)。これにより、 903,224リクエストまたは上記の10秒間の104日間の待機が節約されます。



また、カメラリンクは円で実行されることを理解する必要があり、前の記事で述べたように、約140,000台のカメラがあります。 サーバーは毎秒10件のリクエストを落ち着いて送信するため、すでに140,000台のカメラが見つかった場合、今後それらを検索する必要はありません。



しかし、非常に多くのアドレスの解析には永遠に時間がかかり、私たちはまだマトリックスにいません!





練習する



検索を減らす:



プロキシはスレッドごとに10個のリクエストを冷静に処理します... 8スレッド、16スレッド... 16で十分です1秒あたり合計160個のリンクと2〜3メガビットのレベルのストリームで、ネットワークに負荷をかけません。



サーバーからの応答:



video / x-flv-サーバーを介してカメラからストリームを受信した場合、text / html-エラーメッセージの場合 プログラムでは、x-flvを見つけるのではなく、テキストがないという条件を作成する必要があります。 カメラが横たわっている場合、サーバーはただdrれているだけで、何も得られませんが、カメラはあります。



その結果、 608台のカメラが見つかりました。

IP .21.23 .21.22 .21.21 .26.150 .26.151 .30.21 .26.152 .30.24 .26.153 .30.23 .30.25 .21.24 .30.22
193 176 171 31 10 7 4 4 3 3 3 2 1








通知:



「ニュース」:



この公開後、 videoproxy2のチェックを導入して、「window」プロジェクトのカメラのみを配布することを希望します。 他のカメラ/すべてのカメラの場合、 blablaproxy2を上げることができます 。これはどこにも輝きませんしhttps経由で動作します



関連リンク:



プレイヤーのページ || mysql形式のダンプ (コメント内のフィールドの説明)。



All Articles