インターネットトラフィックのアカウンティングは、おそらく最も簡単なトピックです。 ネットワークインターフェイスに着信したバイト数-そのような着信トラフィック。 どれくらいのバイトがかかったか-そのような発信。
異常なのは、おそらく、トラフィックが3番目（ネットワーク）レベルではなく、2番目（チャネル）レベルで考慮されることだけです。 レベルの選択には神聖な意味はありません。使用される技術において、最も正確で単純なアカウンティングは、チャネルレベルで送信されるバイト数によって正確に実行されます。 技術的な観点からは、VIF（マシンの仮想ネットワークインターフェイス）を介して転送されたバイトを考慮します。 唯一の不快な副作用は、発信ブロードキャスト、ARPなどのすべてのサービストラフィックです。 また考慮されます。 しかし、トラフィックのコスト（キロバイトあたり10 -6ルーブル）を考慮すると、少なくとも1ペニーの公式トラフィックをどのように巻き取ることができるか想像することはできません。
そして肯定的な側面（私たちにとって、そしてクライアントにとってある意味）は、クライアントが第2レベル（l2tp、PPPoE、ATAoE）で重いアプリケーションを持ち上げると、他のL3プロトコルと同じように計算されるということです。クライアントを「駆動」して、「IPによるカウント」モデルに適合しないアカウンティングには不便なプロトコルの使用を強制的に停止する必要はありません。
トラフィックがどのように考慮されるかについて、些細なことは何もないので、わかりません。より興味深い質問についてお話します-トラフィックと帯域のどちらが良いですか？
トラフィックのコストを見積もる際の一般的な誤解の1つは、帯域（たとえば、10メガビット）を取得し、それに720 * 3600を掛けることです。つまり、その帯域が最大になる量を計算します。
ただし、他のリソースと比較して、消費量の最大の不均一性を示すのはネットワークです（大きな障害を伴う巨大なピーク）。 100％でロードされたネットワークは、遅延のために望ましいサービス品質を提供しません。
多くの車では、夜間と昼間の交通量の差は20：1、さらには30：1になります。 この場合のレーンの予測は、貪欲と正義の間の永遠の闘争です。負荷の急激なピークのためにサイトが1日10分間遅れる場合、レーンを購入する必要がありますか？
クラウドでは、各ホスト（クラウドを構成するサーバー）は1 Gb / sの速度で接続され、多くのアップリンク（ピアリングをカウントしない）へのチャネルは10 Gb / s以上です。 また、当社の機器を考慮に入れて、必要なサイズに拡張する（および各ホストに10Gを搭載する）のに特に問題はありません。
さて、トラフィックに関連して発生する最後の質問。 「少なく」することは可能ですか？ 「速度を落とすが、あまり重要ではなかった」場合は、 はい、できます。 Linuxでは、着信/発信接続の速度を制限するのは非常に簡単です。 これは、仮想マシンのユーザーが実行できます。 どうして？ シェーパーはお金がかかる別個の機器だからです。 お金がかかり、ほとんどの顧客が必要としない場合、なぜ彼らはより高価なトラフィックでそれを支払う必要があります（そして、コストが高ければそれをより高価にしたでしょう）複数の顧客のためにryushek？
記事の冒頭で、非常に忙しいサイトの実際の毎日のスケジュール（夜はどこに、日はどこにあるかは自分で推測すると思います）。
そして、ここに別のグラフがあります-小さな学生サイトの小さなホームページ：
（グラフに関する注意：rx / txはクラウドの観点から考慮されます。つまり、クラウドのrxはクライアントの発信トラフィックであり、その逆も同様です）