TCP/IPの仕組みと改良点。サイバー攻撃

質問

わたしは素人ですが、今のインターネットではサイバー攻撃と言って、ひとつのサーバーに多数がアクセスしてサーバーをダウンさせるということが行われています。
なぜこんなことが可能なのか、改善することは出来ないのかを素人ながら考えたので、詳しい方は是非ご意見をお聞かせください。

たとえば、Ｐ、Ｑ二人のユーザーがサーバーＳからデータを取っていたとします。
途中にはＡ、Ｂ、Ｃ、Ｄのルーターを経由してデータが送られるとします。
データのパスは、

Ｐ<-Ｃ<-Ｂ<-Ａ<-Ｓ
Ｑ<-Ｄ<-Ｂ<-Ａ<-Ｓ

と流れるとします。つまり、サーバーＳから、ルーターＡ，Ｂまでは同じパスを通りますが、Ｂからはデータは分岐して、ＰへはＣ経由、ＱへはＤ経由とします。

Ｐ，Ｑが全く同じデータをサーバーから取ってくる場合は、にもかかわらず、サーバーは２回アクセスされて、Ａ，Ｂには全く同じデータが２回通ることになるのですよね。だから、ユーザー数が同時に何万とかになるとパンクすると認識しています。
ですが、Ｐが最初にサーバーにアクセスして、そのデータがルーターＡ，Ｂに残っていたら、ＱはデータをＳまで取っていかずに、ルーターＢに残っているデータを取ってきたらいいのではないですか。

中継ルーターに残る残存時間はサーバーＳのデータを作る際に指定します。ＨＰを作る際に指定します。
このデータはほとんど変更しないので６０秒にしよう、とか、このデータはリアルタイムに変更されるから、０．１秒ごとの更新にしようとか。

で、中継ルーターにはこのルーター残存時間も送られるので、この時間内であれば中継ルーターにはこのデータは残っているので、ほかの人がアクセスした場合はサーバーＳまでいかずに、中継ルーターからデータをとってきたらいい。

こうなっていると、多量にサーバーを攻撃しようとしても、中継ルーターでデータが返されるので攻撃できませんよね。

また、大阪の人１０００人が東京のネットテレビを見ようとすると、東京ー大阪間のネットに１０００人分の全く同じデータが流れますが、上記のようになっていると、東京ー大阪間にもデータが１人分づつしか流れないのでネットの使用効率が劇的に向上すると思うのですが、現在はそうはなっていないのですか。

ミラーサイトというのがあるのは知っていますが、これはリアルタイムに自動的にされるものではなく意図的に作られるものなので、これはちょっとはずして考えています。

回答No.7

山田 太郎（@testman199） · ベストアンサー

１．全ての映像配信プログラムはL3/L4を直接制御するように書き換えるの？
２．1000人が同じ番組と書いているけど、6Mbpsの番組としても全部で6Gbpsだよね数百Gbpsのルータにとってどれだけありがたいの？
３．L3と同じようにハードウェア処理と書いているけど、IPv4で50万ルートくらいでしょ(IPv6は知らないけどかなり省略できるはずなのでそれほど多くない)
　　一方、安めのルータだって1秒に1000万パケットは処理できて、60秒間同じパケットがあるかマッチングしたら、1パケットあたり6億回の比較だよね。しかも、キャッシュヒットの比較もあるので倍。50万回比較が12億回比較に増えたらつらいよね。
４．誰が儲けるの？ルータを持っているのはキャリアだけど、通信料が減ったら収入も減るよね。機器代が減るって考えもあるけど、普及が怪しい仕組みに投資はしないでしょうね。
５．そうそう、映像要求のパケットからどうやっても目的の映像と判断するの？
　　IPがわかったとしても、クライアントは次の映像のLUTはわからないから要求できないし、ルータもLUTからじゃ次に渡すパケットがわからないよね。

お礼

メリットはすでに書きましたが、極端な話、読み出し専用のサーバーの場合、サーバーと最初のルーター間は一人分のデータ転送で済みますよね。そのルータから１００台のルーターにつながり、さらに１００人づつに繋がっていれば、１万人が同時にアクセスしてもサーバーからは１人分のデータが出てくるだけです。
なので、ユーザーが増えてもサーバーをさほど増強しなくても済むし、トラフィックも劇的に減るし、ルーターを通るデータ量も減って負荷が軽減されるし、これらは大きなメリットだとは思いませんか。
1000人が動画で6MBpsっていうのもそれだけではなく、ほかの読み取りリクエストすべてが圧縮されるでしょう。
ユーザーも貧弱なサーバーをアクセスしてもネットを重く感じることはなくなります。

わたしのシステムを簡単に言うと、宛先のＩＰアドレスとオプション番号でサーバーへリクエストします。
サーバーはＬＵＴを見て、それぞれのオプション番号にあった処理をしますが、データをサーバーから読み出す（送出）、サーバーに書き込む、それ以外の処理、に分かれます。
サーバーから読み出す処理にはどこのデータを読み出すかが書いてあります。ルータの残存時間はこの場合のみ設定し、他の場合はゼロで素通りになります。

動画のリアル配信の場合は、たとえばオプション番号１にして読み出し専用にしてサーバーは１秒ごとにサーバー上の取り出すデータ領域を書き換えていって、中継ルーターの残存時間を１秒にしてやる。ユーザーのブラウザからは１秒ごとにデータを読みに行く。すると、ルーター内のデータも１秒経てば消えるので、次に最初にアクセスした人がサーバーから次のデータを中継ルータにバッファしてくれて最新のものになってるし、ブラウザでバッファリングして表示してやれば問題ないのではないですか。
送出するデータには通し番号をつけたりこの辺はいくらでも方法は考えられると思いますよ。

マッチングですが、今のルーターでも専用LSIチップを使って入ってきたＩＰアドレスを、１クロックでテーブル上の数万のＩＰアドレスとの一致チェックってしてるのでしょ。それにカウンタをつけて、単純にトラフィックモニタみたいにすればいいだけじゃないですか。
１秒にもこだわる必要はありません。単位時間あたりに通る多いものから選択するハードウエア上のアルゴリズムはいくつか考えられます。この場合は、ＩＰアドレス＋オプション番号分のビットを一致チェックすることになります。

回答No.9

山田 太郎（@testman199）

>ここでは、既存のIPv4とかで実際に実装可能かとかの話をしているのではありません。
>こうなっていたらこんなメリットがあるのでは、という仮定、架空の話をしているだけですので念のため。
実装の可否とか、帯域削減の量的評価とか無しの仮想アイディアだったら何でもいいじゃん。
いつでもどこでも、機械なんか必要なしで脳内に映像が届く仕組みで。

ちなみにNo7でいっぱい書いてもらった方法も実現できませんよ。ちゃんと読んでないですが

お礼

おや、まあ。
もっといろんな人と議論してみたいですね。

回答No.8

Fushino

L3のIPパケットだと送信元と宛先のIPアドレスしか判断材料がないと思いますが、何を送信しているのか（どのファイルへのリクエストなのか、そもそもHTTPのリクエストなのかすら）もわからないQ→SのIPパケットに対してキャッシュしているやはり何かもわからないS→PのIPパケットを無条件に返信しようということなのでしょうか。

そんなものに意味があるとは思えませんから、お考えの事を行うにはL7での対応が必要となるでしょう。

しかし、サーバもクライアントも意識しない単なる中継機器が勝手にアプリケーションレベルの応答を返すシステムなんてプライバシーやセキュリティ面でも疑問ですし、トラブルシューティングも難しくなる可能性が高くなるように思います。

お礼

ここでは、既存のIPv4とかで実際に実装可能かとかの話をしているのではありません。
こうなっていたらこんなメリットがあるのでは、という仮定、架空の話をしているだけですので念のため。
No4,7さんへの回答を見てみてください。

回答No.6

saijyo_739

No5です。

私の書き方が悪かったのかも知れませんが、例えばクッキーはそれぞれのアクセスにつけるもので受信者全て同じ内容ではありませんよね。
認証という言葉のみを受け取られた様ですが、認証も一例で『送られてくる情報に違いの全くない/送られてくる情報の内容が全く同一』事は非常に少ないと書いたわけです。

また、アクセス状況はサイト運営者の知りたい情報でもあるわけですから、パケットが途中のルータで帰ってしまうような方法が導入されても回避するための手段を講じられる可能性も高いです。(利用者の動向のみならず、例えばどれ位のアクセスが行なわれているという情報も広告効果をアピールするために必要だったりしますし)

アクセス解析を行い、利用者の趣向も考えて提供する情報を変えていくのは普通に行なわれている事ですし。
アクセス数を材料に広告効果をアピールする事は普通に行なわれている事ですし。

> ＨＰが人気化してサーバへのアクセスが増えてくるとサーバーを増強なんて当た
> り前にしていますよね。これって単位時間あたりのアクセス数が増えるからでは
> ないのですか。確かに多くの人が全く別々のデータを取るのであれば、このシス
> テムは意味はありませんが、実際はそうではないと思っているのですが。

そういうサイト(それなりにアクセスの多い)でクッキー使って利用者の動向を全く追ってないサイトは非常に少ないと思いますが。

返答にでてきたYahooもログインしてない状態でもクッキー送ってきてますし。
※返事見て確認しました。利用者からyahoo側の送信データもyahooから利用者側への受信データも全く同じではありませんでした。gooは下記ながらログアウトして試して書き直したりするのは面倒そうに思い試してません。でも、送ってそうな気はします。

httpヘッダなどを見てみられるとわかると思いますよ。

お礼

クッキーですかあ。なるほど、それは全く考えていませんでしたね。確かにそうですね。
チェックした商品、とか、最近見た物、とかですか。
確かに同じＨＰをアクセスしても、ユーザーごとにレイアウトが全く違ったり表示が違うと問題ですね。
でも、ブラウザにはキャッシュもあるし、一度、ユーザー固有の情報を取ってきたらこれをパソコン側に置いといて、あとは共通のデータをとってきてブラウザ側でパソコン内の固有データと合成して表示とか工夫できませんかね。ここは考えないといけませんね。ユーザー固有の情報は頻繁に変わるものではないでしょう。
ご指摘のように、もちろん、毎回異なるデータをアクセスして全く異なる表示をするような場合は、この方法は無力です。

それとカウンタですが、これがこの方法では使えないのがデメリットです。
ですが、たとえばカウンタ部はアプレット等で実装して、リロードしたり押したりするたびにサーバーに最低限のアックのみを要求するようにして、ここでは残存時間をゼロにしておけば、強引ですが対処はできますね。こればっかりは必ずサーバーにいかないといけませんね。対処方法はあると思います。

回答No.5

saijyo_739

> Ｐ，Ｑが全く同じデータをサーバーから取ってくる場合は、にもかかわらず、サーバーは２回アクセスされて、Ａ，Ｂには全く同じデータが２回通ることになるのですよね。
> だから、ユーザー数が同時に何万とかになるとパンクすると認識しています。

全く同じデータという場合がそんなに多いのでしょうか。
それなりの規模なサイトではほぼ接続ごとに違う認証系のデータも送ってますので、P,Qが全く同じデータを受け取ってくるわけではないですよね。

同じコンテンツを取得していても、2者の受け取るデータは全く同じわけではないのが普通だと思います。(取得するコンテンツは全く同じでも、送られてくるパケットの内容は全く同じでない)

> 大阪の人１０００人が東京のネットテレビを見ようとすると、東京ー大阪間のネットに１０００人分の全く同じデータが流れますが、上記のようになっていると、東京ー大阪間にもデータが１人分づつしか流れないのでネットの使用効率が劇的に向上すると思うのですが、現在はそうはなっていないのですか。

テレビの放送は視聴者全員が同じ時刻にみます。
今回のご提案はその1000人は0.1秒単位で同じ時刻に同時にアクセスした場合にしか良くなりそうに思えないのですが。
テレビの様に同時に見れば可能ですが、そういう事をお書きになっている様にも見えません。

> 現在はそうはなっていないのですか。

http://e-words.jp/w/IPE3839EE383ABE38381E382ADE383A3E382B9E38388E694BEE98081.html

ユニキャストとマルチキャストってご存知ですか。

お礼

ログインしたり毎回暗号化するようなサイトならそうかもしれませんが、普通の企業のＨＰとかってそんな認証とかってあるのですか。
たとえば、ＹＡＨＯＯやgooのＨＰにログインせずに入るときにも、そんな認証とかしているのですか。それはなんのために必要なのですか。
わたしは、たとえばテレビを見て、これ面白いな、と思って関連するＨＰを見るとアクセスが集中していてなかなか見れないとか、しょっちゅうありますよ。夜になるとみんながネットを使いはじめるのでネットが重くなるなんてよくある話だと思いますが。認証があるＨＰとは全く思っていませんでしたよ。
具体的にはどういうサイトなのでしょうか。

マルチキャストは知っていますよ。でもそれってＨＰを作る人は誰でも自由に使えるのですか。わたしはそういうのは認可制とかにしないと使えないものだと勝手に思っていたのですが。

ＨＰが人気化してサーバへのアクセスが増えてくるとサーバーを増強なんて当たり前にしていますよね。これって単位時間あたりのアクセス数が増えるからではないのですか。確かに多くの人が全く別々のデータを取るのであれば、このシステムは意味はありませんが、実際はそうではないと思っているのですが。
わたしのシステムではＨＰを見る人が増えても、サーバの増強はそんなに必要のないシステムです。
アクセスする人が増えても時間的に分散していれば、サーバーは増強する必要はないですよね。
ですが、同じ時間帯にアクセスが集中するからサーバーを増強すると思っていますが、６０秒というのはその辺に兼ね合いから適当にこんなもんで、と出した数字です。６０秒以上の間隔でアクセスするものをまとめる必要はないでしょう。
そのときはサーバーを増強する必要もないと思います。

それとサイバー攻撃対策にもなります。一度に大量にアクセスするタイプです。もちろんサイバー攻撃は巧妙でそう単純ではないとは思いますが、簡単に言えば、読み出すだけのサイトなら、攻撃できなくなりますね。
書き込みなどのあるサイトであれば、全くダメですが、そのときには書き込み禁止にして読み出し専用のサイトにしてしまえば、すぐに攻撃は無効化されて普通のユーザーも普通にサイトを閲覧できるようになりますよね。

回答No.4

山田 太郎（@testman199）

まとめるほどのことでもないので殴り書きしますけど

>なので、もしルーターの負荷が増えてくれば、最悪ルーター側で強制的にこの時間をゼロにしてやれば現行のものとかわらないので、ルーターがパンクする、ということは考えていません。
>というか、今のルーターでも許容量を越えればパンクしたような状況になるのでは。
１．
ciscoのcrsのバックプレーンが300Tbpsほどでその稼働率を10%としても3TByte/secほどデータが通るのですよね。
当然HDDなんかには書き込めず、DDR3メモリが20GByte/sec以下ですから、150枚並列で動かさないと駄目ですね。でもこれでも書き込みに精一杯で読み出しはできない。
容量を見ても60秒で180TByteか。。キャリアクラスで1GBを5万円としても90億円か

２．
キャリアクラスのルータはハードウェア処理でL3までしか見ていませんからCPUの負荷が上がりません。
一方CPUを使ってL7を解析してキャッシュするなんて。。。ああ恐ろしい

て、わけでデータを止めて解析するくらいなら10,000倍位の量のデータ流したほうが安上がりな世の中なんです。

お礼

お返事ありがとうございます。
わたしもアプリケーション層での解析とかは全く想定していません。
あくまでもＬ３、ハードウエア処理です。
私が考えているのは、先方サーバーのＩＰアドレスと１６or３２ビットのオプション番号をヘッダー内に用意して、サーバー内にはルックアップテーブルを用意して、どこのサーバのどこのデータ（ＬＵＴから）を取ってくるのかをヘッダーだけから判断できるようにするものです。
ＩＰｖ６では１２８ビットのアドレスを想定しているのですから、これくらいのハードウエアマッチングはルータでも出来るでしょう。
サーバーに近いルーターはトラフィック量が１００分の１、１万分の１になれば、それだけ処理速度も遅くできますから、どうでしょうか。そんなに無謀なものでもないと思いますが。甘いですか。
ルーターのバッファにはすべてのデータを溜め込む必要はなく、単位時間あたりアクセス回数が多いものを溜めればいいと思っています。
cgi等の処理はサーバーアプリとアプレット等を使ってＬＵＴを書き換えたりしながらうまくやればある程度はできるのではと思っていますが、そもそも単位時間あたりに大量の同じデータを取り出さなければ、残存時間をゼロにしてしまってもいいかなとか。
今は、アクセス数が増えてくるとサーバーを増築して巨大サーバーにしなければ対応できませんが、この方法だと、サーバーのコストも相当減らせると思っているのですが。

回答No.3

Toshi0230

非常に面白い考えですが、現実的にはちょっと無理があります。
質問者さんの提唱する仕組みを作ろうとすると、ルータは流れるパケットの中身（コンテンツ）を全てチェックしなければなりません。
インターネットの基幹ルータは数Gbps～数十Gbps単位でトラフィックを捌いているので、はっきり言ってコンテンツデータまで見る余裕はないです。また、仮に見ようとした場合、基幹ルータの配下にあるサーバは何百何千何万台もあるわけで、そのデータを一時的とはいえ溜め込むだけでも大変だと思いませんか？
それに通信機器の機能を増やすと、構成が複雑になって値段が上がり、さらに故障も増えます。たぶん、今の料金でISPに繋ぐことはできなくなるでしょう。
また、ルータが応答を返す場合、大量のアクセスがあった際の負荷はサーバではなくルータにかかることになります。ルータの許容量を超えるアクセスが発生すると、サーバの前にルータが落ちることになります。こうなると影響範囲は現在の仕組みの時よりも大きくなってしまいます。これはまずいですよね？

質問者さんが提示された様になっていないのは、それなりに理由があるからなんです。今の仕組みが完璧というわけではありませんが、それなりに合理性を持たせた仕組みなのです。

質問者さんが提示したのと似た様な仕組みでは、既に回答がありますが「キャッシュサーバ」「マルチキャスト」の概念があります。
また、「一度データを取った人がサーバ機能（の一部）を代替する」という構造を突き詰めると、P2Pにつながっていきます。BitTorrentとかですね。

いろいろ調べてみて下さい。

お礼

丁寧なお返事ありがとうございました。
私のアイデアの核は一般的なキャッシュのようにずっと持っておくのではなく、１秒以下、長くても６０秒以下の短期間保持するものです。
なので、もしルーターの負荷が増えてくれば、最悪ルーター側で強制的にこの時間をゼロにしてやれば現行のものとかわらないので、ルーターがパンクする、ということは考えていません。
というか、今のルーターでも許容量を越えればパンクしたような状況になるのでは。

それとコンテンツを全てチェックする、ということは必要なのでしょうか。
ＨＰにコメントを書き込むなどサーバー側にデータを送る場合は全部サーバーまでアクセスする必要が出てきますが、サーバーからデータを取り出すだけ（多分これの方が多い）なら、どこのサーバーのどの内容というヘッダー情報のマッチングだけでいいと思っていたのですが。
ていうか、そのレベルのものを考えていましたが、それでは不十分ですか。

構成が複雑になってコストがあがり、というのはそのとおりだと思いますが、一方でネット回線の容量に余裕が出て、そちらのメリットの方が大きいのでは、と思いました。
上記に書いたようなネットテレビやラジオのリアルタイム配信のような場合です。

それと、プロバイダの基幹ルーターが落ちれば大変なのはわかりますが、ネットの最大の特徴のひとつとして、中継ルーターが落ちても自動的に他の経路を探索してつながる、と思っていたのですが、実際には通りうるパスの経路数（通るルーターの個数ではない）って数個とか少なく、中継ルーターが落ちるとかなり甚大な被害が出るようなものなのでしょうか。
私が想定しているのはプロバイダの基幹ルーター（上記ではルーターＡ）ではなく、中継ルーター（Ｂ，Ｃ，Ｄ）なのですが。
もちろん大容量のものもあるでしょうが結構無数に分散してあると思っていました。

補足

もう少し言うと、同時にいろんなところから大量にアクセスされた場合ですが、
上記の
Ｐ<-Ｃ<-Ｂ<-Ａ<-Ｓ
Ｑ<-Ｄ<-Ｂ<-Ａ<-Ｓ
というパスで、
Ｂの下にＣ，Ｄだけでなく１００個くらい連なっているとしても、Ｂ<-Ａ間では、１回のやり取りでデータをＡからＢに持ってこれるので、Ｂ－Ａ間のトラフィック量は劇的に減ります。
また、Ａの下にＢだけでなく１００個とかたくさんあった場合も、Ａ<-Ｓ間のデータのやりとりは１回で済むので、Ａ－Ｓ間のトラフィック量も劇的に削減されます。

上記で、Ｂ，Ｃ，Ｄなどの中継ルータがこの機能を持つことによって、全体のトラフィック量が劇的に減り、ルーターＡ、サーバーＳの負担も劇的に減ることが最大のメリットです。

なので、プロバイダの基幹ルーターＡだけがキャッシュを持ってるとかそういう話ではありません。
Ｂ，Ｃ，Ｄなどの下流の中継ルーターがキャッシュを持っているというシステムです。

回答No.2

jtake00

キャッシュサーバーやマルチキャスト配信の分類ですね。

もうちょっとネットワークの勉強をされた方がいいと思います。

で、ルータでデータを保持するにしても
そのデータ量はどの程度の容量になるんでしょう。
プロバイダのルータなんて配下にあるサーバーの台数が何台あって
その容量は・・・
容量があったとしても大量のデータをキャッシュしてその管理に
必要なプロセッサパフォーマンスは・・・
膨大なルーティング情報やり取りするだけでも大変なのに。

過去、ネットワーク帯域が少なかった時に
プロバイダで同様の役目をするプロキシ（キャッシュ）サーバを
立てるのが流行りましたが今は廃止の方向ですね。
（データ量の増加と共にキャッシュのヒット率が・・）

お礼

お返事ありがとうございました。
こういう話を聞いていただける人がまわりにいないのでちょっと素朴な質問してみました。
素人ですいません。
Ｎｏ３さんのお返事にまとめてかいてあります。

回答No.1

山田 太郎（@testman199）

ルータにキャッシュサーバの機能を持たせただけでは？
http://e-words.jp/w/E382ADE383A3E38383E382B7E383A5E382B5E383BCE38390.html

普通にやっていることだと思いますけど

お礼

お返事ありがとうございます。
中継のキャッシュサーバですね。

ＨＰの中には何回アクセスされたか、アクセスカウンターがあるものがありますが、こういうキャッシュサーバーの向こうにカウンターつきのＨＰがある場合、このカウンターってどうなるのでしょうね。

よくわかりませんが、この手のキャッシュサーバは汎用的にどこにでも置くものではなく、特定のサーバーに対して人為的に置かれているものなのではないのでしょうか。

わたしのものも、アクセスカウンターは意味がなくなります。