HTTP通信の基本をイメージできなければバックエンド実装は何もできない

  • 11 December 2021
Post image

 WEBのフロント実装やスマホアプリ開発、デスクトップアプリ開発など、目に見えるフロント開発やそのUI処理の実装はイメージしやすい。だっていじって表示や動きを確認、またいじって確認という感じで、わかりやすいから。実際にはフロント開発は奥が深くて難しいと思うけど、サーバーサイド(バックエンド)実装やインフラ開発より、初心者にとっては「イメージ」しやすいはずだ。

 ただ、バックエンド、インフラも初めにイメージさえしっかりつかめたら、いろんなシステムを簡単に実装できてしまう。個人的にはフロント系の開発よりバックエンドの方が簡単だと思っている。なぜなら環境差が少ないし、処理すべきことが明確だからね。
 とにかくイメージをまず持つこと。それなくして何も始めるな。C#,php,ruby,python,Java全部後でいい。SQLやAWSなども後でいい。まずはイメージ。何回も言ってるけどこれらは全部"手段"ですよ。今回はHTTP通信に関する超基本的かつ最低限の知識の確認。


インターネット通信

 初めから完全に正しい知識はいらない。ざっくりした知識でイメージを持ってそれから詳しく知っていけばいいからね。以下の用語の意味もイメージも知っている人の方が多いと思う。知っている人は飛ばしてください。

クライアントとサーバー

 バックエンドというからには「通信」という考えが絶対必要だ。フロントエンドはブラウザだったりアプリケーションだったりする。またフロントの端末はPCやスマホ、タブレット、専用端末などさまざまであり、これらはよくクライアントと呼ばれる。一方バックエンドの方はつまりサーバーと呼ばれるものがあって、これがどこかの遠隔地にあると考えて欲しい。たとえばAWSでサーバーを構築したというと、日本のどこかにあるサーバー機が集まるAmazonのデータセンターに構築するってこと。そしてこのクライアントとサーバーは通信によってやり取りするわけだ。(当然知ってるわな)


IPアドレス

 で、クライアントもサーバーもネットワークによる通信を行うということは一般的にIPアドレスという住所が存在する。
32bitの値で、123.123.123.123みたいなやつ。このページを閲覧できているということは、今あなたの家や職場もIPアドレスが存在していて、また、今見ているページが存在するサーバーにもIPアドレスが存在する。


 さらに理解しておくべき知識として、グローバルIPと動的・固定IPアドレスがある。


グローバルIPアドレス

 グローバルIPアドレスは上記のイメージままのみんなに知らせる住所だ。世界中に存在する端末にインターネット経由で接続するためのアドレスのことだ。反対の意味のものとしてはプライベートIPアドレスってのがあるけど、これは簡単にいうと開かれたインターネットと接続されていない環境のアドレス。例えば、あなたの家やオフィス内のみで通信するときに使われるアドレスである。今回はプライベートIPは一旦無視する。とにかくグローバルIPアドレスというインターネット経由でサーバーに接続するためのアドレスが存在するというイメージでよい。

動的・静的IPアドレス

 次に動的・静的IPアドレス。上記の通りグローバルIPアドレスってのは32bitの値(123.123.123.123みたいな)で全部で43億通りくらいになる。現在の世界人口は70~80億人?全員がスマホ持ってたら半分くらいの人がネットに接続できないわけ。しかも多分だけど、この記事を見ているあなたは家の光回線のネット契約と1台以上の携帯の契約をしていてグローバルIPアドレスを2つ以上使っていると思う。つまりグローバルIPが全然足りてないんだよね。(現在は足りるようにipV6という128bitのアドレスが生み出されているが未だ完全に主流になっているとは言い難い)
 んじゃあ何すか?もしかして早い者勝ちで枯渇しているIPアドレスを奪い合っているのか?てか、初めにIPアドレスの設計したやつ出てこい!なんで43億通りしかないような値にしたんだよ、と小一時間説教したくなる。そしてこのIPアドレスの枯渇を回避するために動的IPアドレスってのが存在するわけ。
 例えばソフトバンクはグローバルIPアドレスを10,000個所有していて、10万人の契約者のスマホに割り当てているとする。契約者のうち1万人の全員に固定IPアドレスを割り当てていると当然9万人が使えない。しかし1つのIPアドレスを使いまわして(動的に変更して)それぞれに割り振ると10万人全員にインターネット接続してもらえるかもしれない。全員が同時に常にインターネットに接続しているわけではないから、今から使うよって人に動的にアドレスを割り当てれば、みんな使えるって感じ。こういう簡単なイメージでOK。
 細かい話は、「グローバルIP プライベートIP」とか「DHCP 動的静的」とかでググるとたくさんわかりやすい情報が出てくるのでチェックしてみて。


ネットワークの経路

 IPアドレスがネットワークの住所だとして、どのようにして通信が目的のIPアドレスを持つサーバーまでたどり着いているのかも知っておいて損はない。IPアドレス「123.123.123.123」にデータをリクエストするという場合、通常、「123.123.123.123」が実際にどこのサーバーなのかわからない。もしかしたらアフリカのどこかの国のサーバーかもしれないし、千葉県のデータセンターのIPかもしれない。
 有名な話なんだけど、ネットワークの経路は"バケツリレー“とよく例えられる。自分のルーターを出発したリクエストは他のルーターに到達して「123.123.123.123を知っているか?」と聞いて、知っている場合はそのサーバーまで到達、知らなければ、次のルーターに案内される。そしてその次のルーターでも同じように「123.123.123.123を知っているか?」と聞くことを繰り返すことで、いずれ「123.123.123.123」の所在を突き止めることができるというわけだ。


ドメインとDNS

 IPアドレスによって目的のサーバーまでリクエストはたどり着けるんだけど、多くの場合、ドメイン(例:i-407.com) を使って名前解決したIPに対してネットワークのバケツリレーが行われる。つまり、ドメインにIPアドレスが設定されている場合、ドメイン「i-407.com」からIPアドレス「123.123.123.123」がわかり、サーバーと通信を行えるということだ。WEBサイトのほぼすべてにURLってのがあるよね?このURLでWEBサイトが表示されるのは名前解決がなされているおかげである。
 DNSサーバーという名前解決のためのサーバーが世の中にたくさんあり、IPアドレスによるネットワークの経路と同じように、"バケツリレー“によってドメインとIPアドレスの対応関係を解決する。ちなみにものすごくよく出てくる言葉だけど、ドメインとIPアドレスの対応関係を設定するレコードをAレコードという。


リクエスト・レスポンス

 これらの言葉は、そのままの意味だけどWEBの世界では何度もでてくる。
リクエスト:送信先IPアドレスの到達点に対してデータを送信する
レスポンス:送信先IPアドレスからデータを受信する


ヘッダー・ボディ

 (httpの)リクエストもレスポンスも通信データにheaderとbodyという領域が存在する。Chromeのインスペクターを開いたら簡単にheaderやbodyの中身を見ることができる

 つまり、headerはキーバリュー型のデータで、例えばCookieを送受信したりするのに使われる領域。bodyは本文的なもので、WEBサイトでいうと、例えばページのHTML情報がどっさり入っているデータ領域と言っていい。


これまで掴んだらググれるレベルだ

 まとめると以下のようになる。(WEBページを開くときのHTTP通信の例)

ブラウザの検索ウィンドウに「https://i-407.com/」と入力してエンターを押す。

i-407.comのIPアドレスを認識するためにDNSサーバーをバケツリレーで問い合わせる。

解決したIPアドレスに対してリクエスト(ヘッダーとボディからなるデータ)を送信。

インターネット上のルータにバケツリレーを繰り返し、対象のサーバーに到達

サーバーはリクエストデータを受信して、何らかのレスポンス(ヘッダーとボディからなるデータ)を返す。

同様の手順でクライアントにレスポンスデータが返ってくる。

ブラウザがレスポンスボディのHTMLを解析してWEBページを表示する。

 このレベルでいいから知識とイメージは持っておかなければいけない。本当はもっと多くの知識が介在するんだけど、そのような専門的な知識を検索するための知識はこの記事で上げた知識で十分だろう。つまり他の関連情報をググるための最低限の知識だということ。そして何度もいうが、完全で網羅した正確な知識は必要ない。ざっくりかつ本質を付いた知識をもっておけばいいのだ。
 ちなみにこの記事のように人に説明できるようになってこそ「イメージ」できているってこと。言葉を暗記するんじゃなくて、イメージを理解するってことね。
 これからバックエンドとかインフラの記事を書いていくけど、念のため今回は超大前提知識をまとめておいた。

You May Also Like

CentOSサーバ上DockerコンテナでDNS解決されない時は

CentOSサーバ上DockerコンテナでDNS解決されない時は

dockerコンテナ内でDNS名前解決されない  本番サーバーを以下の環境で構築する場合。 CentOS7 Docker  Dockerコンテナ内から外部のエンドポイントにアクセスするとき、DNS名前解決できず困ったことがある。 以下の2つのうちどちらかの方法でコンテナにDNSを指定することで解 …

WindowsでもMacのUS配列キーボードが最強なわけ

WindowsでもMacのUS配列キーボードが最強なわけ

 コードを書く人間なら、キーボードにこだわりたくなるものだ。ノートPCをメインにしている場合はキーボードを変えることは難しいが、それでもJIS配列かUS配列など一度は考えたことがあるはずだ。 このサイトで何度も書いている通り、プログラミングのほとんどは試行錯誤の繰り返しで作り上げてい …