2020-07-12

webサーバーとアプリケーションサーバー

webサーバーとかアプリケーションサーバーとか構成とか、

わかってるようで全然わかってなかったので（自分の口で説明できないので）、

色々調べてみた。

web三層構造

まずはwebの構造について。

現在はこの三層構造が主流になっている。

（昔はwebサーバーとDBサーバーの２層だった）

webサーバー　⇆　アプリケーションサーバー　⇆　DBサーバー

このような構成になっており、

役割としては下記になる。　　　　　　　　　　

HTTPリクエスト処理　⇆　ビジネスロジック処理　⇆　データ管理

webサーバー

・HTTPに則り、Webブラウザからのリクエストに応じて静的コンテンツ（HTMLや画像）を表示する働きをするサービスプログラム及び、そのサービスが動作するサーバコンピュータのこと。

・HTTPリクエストの最初の窓口

・静的コンテンツがリクエストされたらそのままここでレスポンスを返す。

・動的なリクエストの場合は、アプリケーションサーバーへ処理を依頼し、その結果を受け取ってクライアントにレスポンスを返す。

・apacheやnginxがこれに該当する。

アプリケーションサーバー

・ビジネスロジックなどを実装したアプリケーションソフトウェアを実行するサーバ。

・アプリケーションの実行を管理補助するミドルウェア。

・動的コンテンツを扱う。（webサーバーからリクエストがくる）

・tomact, GlassFish, Unicorn, Pumaなどがこれに該当する。

ちなみに、

静的コンテンツは要求内容、要求する人に関係なく同じ結果を返すもの

動的コンテンツは要求内容、要求する人によって返す結果が異なるもの

ブログとかは誰がみても同じ（静的コンテンツ）だけど、amazonとかの買い物リストは人によって違う（動的コンテンツ）。

DBサーバー（データベースサーバー）

・データを記録・保持するサーバー

・クエリによってデータの操作ができる。

・基本、アプリケーションサーバーからアクセスする

・Mysql, Postgresql, Oracleとかが該当する。

なぜ3層構造なのか

・パフォーマンスの観点

2層の時は全てwebサーバーが処理していたが負荷が大きいため、webサーバーとアプリケーションサーバーに分けることで大量の処理が可能となった。

・メンテナンス・管理の観点

動的処理部分を改修する際、影響範囲はアプリケーションサーバーだけ、という感じに切り分けができたり、何か不具合があった場合にその層だけを切り話して考えることができる。

もしこれらが１つのサーバー内で動いていたとしたら問題の切り分けや影響範囲の特定が難しくなる。

・セキュリティの観点

３層にわけることで、クライアントからDBまでの間にwebサーバーやアプリケーションサーバー、その他セキュリティツールなどを挟むことができ、安全性が高くなる。

逆にもし一つのサーバーに内包されていた場合、クライアントから直接DB（が存在するサーバー）にアクセスしうるかもしれないので安全性は低くなる。

最後に

今までapacheとかtomcatとかなんかごっちゃになってたので、今回で明確に違いがわかった。これをしっかり理解することで、対応の速度もかわってくると思う。

apacheってみんながよくいうのが、Apache HTTP Serverで、

tomcatってみんながよくいうのが、Apache Tomcat になる。ややこしい。

今度はapacheとnginxについても調べる。

2020-06-26

PATHを通す

~メモ~

パスを通す

環境変数（$PATH）の記述を変えて、コマンド検索パスを追加すること。

コマンド検索パスとはshell（ターミナル）がコマンドを検索するためのパス。

lsとかpwdなどのコマンドは実行ファイル、でそれを読み込んでいるだけ。

※Linuxでは、データもコマンドも全て“ファイル”

$ printenv PATH

/Users/XXX/.rbenv/shims:/Users/XXX/.rbenv/shims:/Users/XXX/.rbenv/shims:/Users/XXX/anaconda3/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

並べると

/Users/XXX/.rbenv/shims

/Users/XXX/anaconda3/bin

/usr/local/bin

/usr/bin

/bin

/usr/sbin

/sbin

になる（同じのが３つあるのは一旦無視。。。）

そして例えばlsコマンドの場所を探してみると

$which ls

/bin/ls

となるので、/bin上にあり、/binがPATHとして登録されているためlsと打つだけでlsを実行できる。もちろん/bin/lsと入力しても同じ結果になる。

(printenvは/usr/binだった)

2020-06-26

URLを入力してwebサイトが表示されるまでの流れ

~メモ~

(2020/07/14更新)

※間違っている箇所、新たにわかった箇所等があった場合は随時更新していく

検索窓にURLを入れて、サイトが表示されるまでの流れがよくわかってなかったので、自分なりに言語化した。

https://hogehoge.comにアクセス

↓

IPアドレスを特定するためにDNSサーバー通信が行き、URLに対応したIPアドレスを取得（名前解決）

↓

IPアドレスはいわばweb上の住所なので、IPアドレスを用いてその任意のサーバーにアクセス

↓

サーバーを特定したらTCP接続を確立（3wayハンドシェイク）

↓

TLSセッション開始（暗号化）

↓

HTTPS通信（サーバーへリクエスト）

↓

静的ページのリクエストの場合、webサーバー（tomcat等）がhtmlをレスポンスとして返却

↓

動的ページのリクエストの場合（クエリ等が含まれてる場合）、webサーバーがAPサーバーを処理を依頼

↓

APサーバー内の実装されたロジックでごにょごにょしてレスポンスを返却

↓

サーバーからレスポンスが返ってきてクライアント(ブラウザ)に表示

雑だけど、こんな感じだと思う。

おわり