2004年
それは、50万人強の人々が住んでいるN-skの都市についてです。 アクセスの組織の基本的な部分については詳しく説明しません。すべてが標準でした。大学に入学した後、お金を稼ぎ、管理の経験を得たいと思いました。 約150人の地元の家のネットワークに接続しました。 私はすでに自宅にADSLを持ち、衛星放送受信アンテナを設置し、必要な機器を購入し、衛星プロバイダー（PlanetSky）からの交通料金に接続していました。 彼はLinuxに精通していたため、サーバーはDebianの下で組織されていました。 課金ソリューションとして無料のソリューションを使用しました-Neon Internet Billing System。
2005年
家のネットワークが成長し、さらに2、3の近くのネットワークが接続されました。 したがって、サブスクライバーの数が増加しました-私は課金を改善しなければなりませんでした。 交通料金の代わりに、衛星オペレーターが数メガビット（SatGate）の条件付き無制限を採用する方が収益性が高くなりました。 最終消費者の場合、価格は時刻に応じて30コペックからルーブルまででした（比較のために、地元のプロバイダーは3から7ルーブルを提供しました）。 支払いの受諾は、金銭を伴うという原則に従って行われました-アカウントに入れます。
2006年
ホームネットワークは成長を続けました。 また、複数のネットワークが無線で接続されました。 衛星プロバイダで最も高価な条件付き無制限は対処することをやめました-それは専用バンドを購入することに決めました。 最も手頃な価格のRuSatが選択されました。 このため、ADSL +アンテナ+サーバーセットを市内の他のリモートネットワークにインストールする絶好の機会がありました。そのポイントは同じ専用帯域に「フロップ」されています。 そのため、さらにいくつかのネットワークが接続されました。 さらに多くのサブスクライバ、接続ポイントもあります。 以前のスキームによると、支払いを受け入れることは不可能でした。 私は請求を確定しました-アクセスカードを生成する自動化されたプロセスが組織されました。 カードをカラーレーザープリンターで厚紙に印刷し、ラミネートし、シートをカットし、角を丸めました。 パスワードの代わりに、スクラッチパネルが添付されました。 彼らはこのように見えました（写真はE-ten M600コミュニケーターでそれらの年に撮影されたため、品質は適切です）：
2007年
加入者ベースはさらに大きくなりました。 衛星通信事業者にはチャネル拡張が必要でした。 RuSatは、衛星の帯域全体を既に割り当てていたため、拒否しました。 衛星プロバイダーに頼らずに、データセンターにサーバーを設置し、テレポートとの契約を締結することを決定しました-衛星で独自のバンドを取得します。 これにより、すでにロシア全土の顧客を接続できました。 すぐに言ってやった。 最初の接続は行われましたが、この状況ではカードが間違っていました。 2、3か月後、テレビの男性は衛星に来てみんなを追い払いました。 さらに、地元のプロバイダーは、最初の無制限の起動を開始しました-1000ルーブルで128 kbit / sの無制限の無制限。 サテライトのpingや価格と競合することはありません。
ローカルフェデラルイーサネットプロバイダーの1つは、1つのアドレスについて複数の契約を締結することを許可し、別のアドレスからのログインでPPPoEセッションを「上げる」ことも許可しました。 私の頭の中の絵は急速に発展しました。 10人の契約を締結するために30人の友人を送りました。 その結果、それぞれ128 kbpsの速度で300のPPPoE接続を取得しました。 どういうわけか、それらを1つの大きなチャネルに結合することが残っています。
モスクワのデータセンターに物理サーバーをレンタルし、tun / tapに基づいてLinuxカーネル用のモジュールを作成しました。これにより、システムに仮想ネットワークインターフェイスが追加されました。 そのようなインターフェイスの1つは私のサーバー上にあり、もう1つはモスクワのサーバー上にあり、すべてのクライアントトラフィックはそれらに向けられました。 このインターフェイスに入った最初のネットワークパケットはすべて、あるサーバーから別のサーバーへの最初のPPPoE接続を介して送信され、2番目のパケットは2番目のPPPoE接続を介して周期的に送信されました。 したがって、30 Mbpsを超える無制限のチャネルを取得しました（オーバーヘッドトンネルを考慮に入れて）。
途中で、3つの大きな問題に遭遇しました。
1つはパケットシャッフルです。 つまり、モスクワのサーバーからのパケットは1、2、3、4、5、6の順序で送信され、ローカルプロバイダーのシーパーのためにサーバー上で異なる時間に到着し、その順序は次のようになります：3,2,5,1 、6.4 ...結果として、Windows TCPスタックはこのようなシーケンスを消化しないため、多くのユーザーがダウンロード時に同じ128 kbpsを受信しました。 カーネル用のモジュールにパケットソーターが書き込まれ、パケットから小さなバッファーが蓄積され、希望する順序でクライアントに送信されました。
2番目の問題は、多数の静的ルール、大量のトラフィック、および大きな帯域重複（ルールは800 Mbpsで追加され、チャネルは30 Mbpsのみ）を備えた標準のLinuxシェーパーが誤ってシェーピングを開始したことです。 ネットワークインターフェイスでのアクティビティに応じて、モスクワサーバーのシェーパーでルールを動的に追加/削除するLinux tc用のモジュールを作成する必要がありました。
3番目の問題は、モスクワサーバーでの毎月の発信/着信トラフィックの比率でした-その時点では1から3が必要でした。この比率から下方に逸脱するには、超過ギガバイトごとに30ルーブルの追加料金が必要で、そこのトラフィックはテラバイトで測定されました。 サーバーは単なるゲートウェイであるため、トラフィックの比率は1対1でした。トレントは単純なソリューションであることが判明しました。 人気のあるコンテンツがサーバーにアップロードされ、コンソールトレントクライアントで配信されました。 人気のカントリートラッカーでテラバイトの並列トラフィックが提供されました。
その結果、エンドユーザーには素晴らしい価格を手に入れることができました。それぞれ500ルーブルと700ルーブルに対して256と512 kbpsの正直無制限です。 この観点から、地元のオペレーターからの1000ルーブルの平均128 kbit / sは魅力的ではないように見えました。 また、交通量と条件付き無制限の関税もありました。
2008年
市内では、地元のプロバイダーと真剣に競争しました-当局を通じて積極的な攻撃を開始しました。 さらに、私の仕事の1年間で、私のチャンネルが働いていたプロバイダーは、そのクライアントの中に数十人の契約を結んでいる数十人の人々がいることに気付き始め、各契約は24時間体制で可能な限り最大のボリュームをポンプで送り、トラフィックのかなりの部分を占めています。 同時に、市内の無制限の価格が大幅に低下しました。 これらすべての状況により、活動を停止せざるを得ませんでした。
UPD：一般的な需要により、近い将来、詳細な情報、写真、グラフ、チャートで記事が補足されます。 フィードバックをありがとう！