HTTP/2
| 抜 | 草 | 感 | 不 | 胸 | 萎 |
|---|---|---|---|---|---|
| 0 | 3 | 0 | 0 | 0 | 0 |
エロジンをTLS化、HTTP/2化、デザインとシステム設計を見直しました。AMPに統一
AMPアクセラレータモバイルページはGoogleが推奨する、WEBページを高速表示させるための技術で、コンテンツ（HTMLファイル、画像ファイル）のキャッシュを補ってくれることもあります。以前エロジンでは通常版とAMP版の双方を兼ねそろえてましたが、二つ同じページがあるのは不愉快だったのと、HTMLデザインを変更する際に二度手間がかかること、もともと静的HTMLファイルしか無いのでAMP化するのは容易だったこと、などの観点からAMPだけにしました。HTTPS化について
通常人間は通信端末を利用して、アプリ[ブラウザ]からインターネットに接続します。「ブラウザ」にはさまざまなセキュリティ性能が当たり前のように備わっていますが古いバージョンでWEBサイトを閲覧することは大変危険です。最新のスマートフォンであれば最新のウェブブラウザ（Chrome, Safari)が標準装備されているので安心ですが、PS3やWii,3DS, Android2.X、液晶テレビなどのブラウザやパソコンでもIE7,8でWEBに接続するのは大変危険でおこがましいことです。ましてや大型テレビの大画面で付属のブラウザで迫力のあるXvideosを見ようなどとあやまちを犯してはいけません。
最新のブラウザには最新の暗号通信が使用できる仕組みになっています。
AmazonLinuxからMongoDBとファイルシステムXSF
NodeJS利用にはMongoDBが相性が良いということでMySQLから移転しました。
[mongodb-org-3.4]
name=MongoDB Repository
baseurl=/ />gpgcheck=1
enabled=1
gpgkey=/ />
インストールして稼働させて問題がないかチェックします。
chkconfig mongod on
service mongod start
cat /var/log/mongodb/mongod.log
問題が見つかりました。
Directory /data/db Not Foundと書いてある通り、/data/dbというディレクトリは存在しませんでした。通常インストールすれば勝手に作られるものですが、バージョンやら何らかの理由で作られなかった模様です。
sudo yum install -y xfsprogs
mysqldumpでSQLとしてCSVフォーマットで出力し、MongoDBにInsertします。HTTPS、すなわちTLS/SSL通信とは元々パスワードなど他人に知られてはいけない文書を暗号化し、ログイン画面などの傍受を防ぐ役割を果たしていただけなのですが、最近ではログインページだけでなく全ページを暗号通信させたほうが安全になってきました（広告やクッキーなどから侵入を試みることができるため）。SSLはSSL1.0、SSL2.0などバージョンアップを重ねTLS1.0(SSL3.0)として進化してきました。現在最新はTLSv1.3で、SSLは古いので危険です。2014年10月にSSL 3.0の仕様上の脆弱性（POODLE攻撃）が発見されたため、SSL 3.0への対応を打ち切り、TLS 1.0以降のみ対応への移行が望まれている。2015年6月、RFC 7568 によってSSL3.0の使用は禁止された。
エロジンに限ってはログイン画面なんてありませんし暗号通信する必要性はありませんがHTTP/2化するための手段として取り組みました。
HTTP/2
めもりーくりーなーやHDDデフラグなど、物心ついたときから「最適化」に好意を抱いしました。実感は湧かないけど、なんかこう早くなった気がするだけで心は満たされます。成功する人は大抵「結果が全て」と仰りますが、私は失敗者なので逆で、結果がどうであれ苦労してできた達成感がすこです。
まずエロジンを開設前にサーバをどうするか悩み、一番速かったライブドアブログをチョイスしました。ライブドアブログで無修正外人マンコは禁止していたので即刻アカウントを閉鎖されてしまいました。erozine.jpのドメインは別で管理していたので、とっさにWordPressで作り直しました。WordPressはPHPと無駄な機能のせいで高額なハイスペックサーバでないとエロジンの高トラフィックを支えられません。初心者の方が初めてWordPressでサイトを作ったと時、大して重く感じ無いかもしれませんが、アクセス数が増えるとどんどん重くなって動かなくなります。自分のブラウザではキャッシュやらが残っているのでそれでも重いと感じないかもしれません、ネカフェにいって閲覧してみると重いと実感できることもあります。
WordPressでは、データベースに貯蔵されている記事をPHPを使って１アクセスごと（動的）に取得しHTMLとして表示しています。１アクセスごとにプログラミングが作動しているということです。サイトトップページには新着で記事がずらっと表示され、それぞれにリンクされています。リンクされたURLをPHPがプログラミングで解釈してデータベースを検索し一致した記事を表示させています。データベースには１行ごとに記事の情報が入っており、タイトル、URL、投稿日時、記事本文、カテゴリ、公開・非公開・下書き、サムネイル画像という具合に１記事１行入っています。トップページに投稿日時の新しい順にソートして表示させています。
我々は記事をいちいち動的に表示する必要性が無いと判断し、あらかじめデータベースに貯蔵された記事を一気に全てHTMLファイルに出力しました。新しく記事を更新した時にだけ全てのファイルを書き直すというものです。（トップページの順番や、PV数、Good,BADなどが変わるため）
現在に至ってはその独自のシステムを採用していましたし、閲覧するにはなんの問題はありません。しかし更新するたびに膨大な量の同じようなファイルを同期するのは転送量が勿体無い気がして来ました。そこでアクセス数の多い記事ページとトップページのみをHTMLファイルに出力し、カテゴリ別やタグ別、ページ別など量が多い割にアクセスが少ないページをNodeJSを使って動的制御することにしました。
NodeJS Express
JavaScriptをPHPのようにサーバで実行するプログラムをNodeJSと言います。ChromeのV8 JavaScriptエンジンで動作する JavaScript環境で、レシプロエンジンのシリンダー配列形式の一つ、直列4シリンダー2組がV字様に配置されている形式ではありません。
慣れ親しんで来たPHPではなく新しいNodeJSを採用するのに理由はありません。とにかく新しいものを使っていきたいという好きな気持ちがそうさせました。嫌いな食べ物は苦いから嫌いだの、嫌いには理由が存在しますが、好きなものに限っては好きな理由は存在しません。
NodeJSはWEBサーバとして動作するのでNginxが不要になるのですが、TLS通信が面倒だったので既にTLS通信できるNginxを介してNodeJSサーバにバックエンドさせることにしました。
おまけ：【https化】TLS/SSL証明書取得の「www」ありなしの注意事項
HTTPS とは
HTTPS（Hypertext Transfer Protocol Secure）は、ユーザーのパソコンとサイトの間で送受信されるデータの完全性と機密性を確保できるインターネット接続プロトコルです。ユーザーはウェブサイトにアクセスするとき、安全でプライベートにオンラインを利用していると考えています。サイトのコンテンツに関係なく、ユーザーによるウェブサイトへの接続を保護するために、HTTPS を採用することをおすすめします。
HTTPS で送信されたデータは、トランスポート レイヤ セキュリティ（TLS）プロトコルで保護されます。このプロトコルでは主に 3 つの保護レイヤを提供します。
暗号化 - 通信データの暗号化によって、盗聴から保護されます。つまり、ユーザーがウェブサイトを閲覧している間、誰かがそのやり取りを「聞き取る」こと、複数ページにわたるユーザーの操作を追跡すること、情報を盗むことはいずれも阻止されます。
データの完全性 - データの転送中に、意図的かどうかを問わず、データの改ざんや破壊が検出されずに行われることはありません。
認証 - ユーザーが意図したウェブサイトと通信していることが保証されます。中間者攻撃から保護され、ユーザーの信頼を得て、ビジネス上の他の利益につなげることができます。
ということは裏を返せば、HTTPS化されていない/ />
暗号化されない - 通信データの暗号化されず、盗聴されます。つまり、ユーザーがウェブサイトを閲覧している間、誰かがそのやり取りを「聞き取る」こと、複数ページにわたるユーザーの操作を追跡すること、情報を盗むことが予想されます。
データの不完全性 - データの転送中に、意図的かどうかを問わず、データの改ざんや破壊が検出されます。
認証されない - ユーザーが意図したウェブサイトと通信していることが保証されず中間者攻撃され、ユーザーの信頼を得ず、ビジネス上の他の不利益につなげることになります。
という解釈に至ります。ここ最近普及が進んでいて、XvideosやXhamsterなどErozineの姉妹サイトもHTTPS化されました。
WEBサイトを立ち上げた庶民が最初にすることは、Analytics、TLS化、HTTP/2化、SearchConsole、リッチスニペットと言ったところでしょうか。「www」のありなしなんて後から気付いたりします。正直不要かとも思うんですがSearchConsoleに登録する際にこう書かれています。
Search Console アカウントを設定する
1. ウェブサイトの全バージョンを追加する
サイトの「www」を含むバージョンと「www」を含まないバージョンの両方を追加します。HTTPS プロトコルを使用している場合はそのバージョンも追加してください。
項目1の「www」を両方追加する。つまりexample.comというドメインをとったら/>
改めて教訓を得た知識
CSSは重い
豊富なデザインを注ぎ足していくとCSSの行数がポンポン太ってきます。それは当然ですが、CSSの書き方によってブラウザに負荷がかかることはご存知でしょうか。
例えばよく見る* { margin:0;padding:0;}全ての属性に余白を消すという便利なやり方。初期状態ではbodyやli、form全般には最初からMarginなどがブラウザキットに装備されていて、一つ一つ消していくと行数が増えてしまうので、一気に全部消す方法があります。しかし全てのタグを一度に読み取って実装していくのでブラウザは負担がかかっています。jQueryをよく使う型ならよくわかると思います、なるべくクラス属性を使わずID属性でと。また他にも画像を使わずCSSだけで三角形を作ったり、丸めたり、ストライプにしたりするのもできますが、それも非推奨されています。特にFilterなんかは、パフォーマンスに関する問題があるためブラックリストに登録されています。Nginxのadd_headerは各ブロックに書き込むと親のadd_headerが消える
もともとWEBサーバはセキュリティ観点からクロスオリジン（画像の直リン等）を拒否しています。しかし開発が進むにつれて、サーバAからサーバBのコンテンツを引っ張りたい時期が来ます。そこでサーバBだけ許可することをadd_header Access-control- allow-originを使って実現できます。
server { listen 443 ssl http2;add_header Strict-Transport-Security "max-age=31536000;includeSubdomains";add_header X-Frame-Options SAMEORIGIN;add_header X-XSS-Protection "1;mode=block";add_header Access-Control-Allow-Origin '*.nosub.tv';location / { root /var/www/html/erozine;index index.html;location ~ ^/image/.*(:?jpe?g|gif|png)${add_header Access-Control-Allow-Origin 'erozineimage.jp';} }}上記の書きかたでは、/image/パスの画像にアクセスした際、親に書いた4つのadd_headerは消えてしまいますので、また4つコピペしなくてはなりません。headerは一度ディレクティブに書くと下に書いたものは初期化されてしまうのです。完
