Clever Geek Handbook

アセンブリ言語でウェブサイトを書くことは便利で楽しいです

もちろん、多くの人はこれはノーだと言うでしょう、そしてあなたはPHPのためだけに、あるいはPython、Ruby、Node.jsなどの現代言語の1つでウェブのために書く必要があります。







しかし、実際には、アセンブラーでサイトを書くことは非常に便利であり、適切なツールを使用して-簡単で楽しいです。







実際、この声明は仮説にすぎません。 それを証明または拒否するために、この春、アセンブラーでフォーラムを書き始めました。







以前は、アセンブリ言語のWebアプリケーション（小規模サイト用のCMS）がありました。 「1回の書き込み、多くの読み取り」のモードでのみ機能します。 さらに、CGIインターフェースを使用するため、「多く」を同時に読み取ることもできません。







参照条件



そして、私は次の目的でWebアプリケーションを作成することにしました。







  1. 「たくさん読む-たくさん書く」という原則。
  2. 非常に高速に動作し、サーバーをロードしませんでした。
  3. サーバーをロードしないために、非常に少ないメモリを使用しました。
  4. 安価な共有ホスティングに取り組んだ。


これらすべての条件を満たしているのは、まさにWebフォーラムです。 したがって、選択は彼に決着しました。 タスクは次のようになります。







以下のWebフォーラムを作成します。







  1. FastCGIインターフェイスを使用して、CGIよりも高速にアプリケーションを提供し、サーバー上で同時に実行されるプロセスの数に制限がないようにします（私のホスティングプランには、 60 30プロセス）。
  2. トランザクションデータベースを使用して、情報を1か所に保存し、複数の訪問者が同時に書き込むことを許可します。
  3. この機能は、ユーザーとのコミュニケーションのために実際に製品を使用するのに十分でなければなりません。
  4. フォーラムのビューは、構成から完全に変更できます。 スキンは私たちのすべてです。 また、すべての人がアセンブラコードを編集できるわけではありません。


FastCGIに加えて、SCGIを使用することもできます。SCGIは実装が多少簡単に見えます。 ホスティング会社がFastCGIのみをサポートしていることがわかりました。







しかし、後悔する必要はありませんでした。 仕様の複雑さにもかかわらず、FastCGIはアセンブラーでの実装に非常に適していることが判明しました。 したがって、コードはシンプルで簡単です。







データベースにSQLiteが選択されました。 まず、私はそれを非常によく知っており、しばしばアセンブラーと組み合わせて使用​​します。 第二に、共有ホスティングを使用して、データベースを含むアプリケーション全体をサイトのディレクトリに配置したかった。 第三に、SQLiteには「全文検索-FTS」機能があります。これは高速であり、フォーラムの検索に役立ちます。







しかし、問題がありました。 32ビットサーバーと64ビットサーバーの両方で動作するように、x86用の32ビットアセンブラーでフォーラムを作成することにしました。 しかし、実際には、64ビットサーバーは原則として32ビットライブラリを提供していません。 これはアセンブラにとって重要ではありませんが、SQLiteには32ビットも必要であり、標準Cライブラリが必要ですが、glibc（GNU Cライブラリ）を静的にビルドすることはできません。







しかし、解決策が見つかりました-代替ライブラリC-動的リンカーを使用するMUSLを使用して、アプリケーションディレクトリに配置できます。 追加の利点は、ライブラリが非常に小さいことです。







FastCGIインターフェースの実装は、他のプロジェクトで使用できるように作成されました。







フォーラムの投稿をマークアップするために、マークダウンと同様のマークアップを使用することが決定されました。これは、私がすでにCMS用に作成したものです。







そして、結局、何が起こったのでしょうか？



暇なときに書きました。 時々職場で、時には自宅で。 もちろん、コードは公開されています。 配布ライセンス： EUPL 。 2016年3月6日に保存された最初のバージョン。 公式バージョンは1.0で、2016年4月7日に保存されました 。







これにはすべて53回のコミットが必要でした。







私はアセンブラーを知っているので、操作中の最も困難なことはWebプロトコルの無知が原因でした。 SMTPとFastCGIに関するRFCドキュメントを読む必要がありました。







私のWebデザイナーのスキルも抜群ではないので、結果は明らかになりました。 ただし、設計全体が構成ファイルに移動されているため、置換は簡単です。エンジンコードを変更する必要はありません。







また、最初は、XSS攻撃やWebセキュリティの他の側面についてはまったく知りませんでした。 最終的に、すべてが多かれ少なかれ明確になりました。 特に、ブルガリアのフォーラムの一部の同志が実施したテスト中。 その結果、ボットに対する保護と、15,000件の投稿があったトピックがありました。







アプリケーションは非常に小さいことが判明しました。 ディストリビューション内のすべてのファイルは1.8MBで、そのうち992KB SQLiteおよび622KB MUSLライブラリです。 アセンブラアプリケーション自体は、サイズが68.5KB（v1.2）の単一ファイル「エンジン」で構成されています。 それ以外はすべてテンプレートと写真です。







インストールは非常に簡単です-アーカイブはサイトディレクトリに解凍され、「。httaccess」ファイルが設定されます。 まあ、または「lighttpd.conf」。 サイトがブラウザで開き、管理者ユーザーが作成されます。







実行時に、アプリケーションは、実行中のプロセスでサーバー上の約2MBのRAMを使用します。 負荷に応じて、Apacheサーバーは複数のプロセスインスタンスを実行できます。







残念ながら、他のフォーラムと比較することはできません。人気のあるフォーラムのメモリ消費に関するデータは公開されていないためです（まあ、または見つかりませんでした）。







フォーラムのデモインストールは、訪問とテストに利用できます。







デモが置かれているホスティングプラン（私が取ることができる最も安いもの）、仮想（共有）。 制限は次のとおりです（仕様による）。







  1. シングルコアCPU
  2. 1GB RAM
  3. 1日あたり30分のCPU時間。
  4. 作業プロセスの最大数は60です。


スラッシュドット効果テスト。



8月に、誤ってリアルモードの負荷でシステムをテストしました。 誰か（誰が理解していないか）がTwitterにコードリポジトリへのリンクを投稿しました。 わずか数ダースがリンクを再投稿し、それをredditおよびおそらく他のソーシャルネットワークで公開しました。







残念ながら、リンクはコードリポジトリへでした。 そして、CGI（化石）で動作し、負荷を完全に保持しません。







日中、フォーラムは数千人の訪問者によって訪問されました-約8,000人のコードリポジトリで、幸いにも倒れて起きました（プロセスの制限を超えたため）。







しかし、特定の数の訪問者（約3,000人）がまだフォーラムにアクセスし、30,000を超えるエントリを作成しました。







フォーラムは、負荷をまったく感じず、アプリケーションを遅くしたり失ったりすることなく、常に適切に機能していました。 この日は、約7分のプロセッサー時間を使用しました。







仮説評決



これらすべてにより、私の話の冒頭で定式化された仮説が証明されたと信じています。







アセンブラーのWebプログラミングはおそらくそれほど難しくなく、結果は非常に優れています。 その結果、このような作業により開発者の文化全体が大幅に向上し、インターネットプロトコルとすべてが実際にどのように機能するかを深く理解することができます。







アセンブリ言語でWebプログラムを使用すると、ホスティングを節約でき、他の人が専用サーバーや他の高価なソリューションを使用する安価な共有ホスティングを使用できます。







おわりに



まあ、それだけです。 誰もがそれを好きなら、健康にそれを使用してください。 脆弱性とパフォーマンスのテストは大歓迎です。 新しいコードとバグ修正が受け入れられます。 新しい良いスキンも非常に必要です。







そして最後に、いくつかのリンク：







» プロジェクトコードリポジトリ

» デモのインストール

» ダウンロードおよびインストール方法

» メールなしで登録する方法







More articles:


All Articles