フクチ@プログラミングと釣り好き大学生のブログ

プログラミングと釣りと、ときどき日常生活

〜第三回模擬isuconを終えて〜

こんにちは!

先週、第三回模擬isuconをやりました!
ブログには書いてないのですが、1,2回目も実はやっていました。
先輩達が書いてくれています
一回目(pixivのprivate-isucon)
http://masa-world.hateblo.jp/entry/2017/07/06/233357
http://matsuda-juri.hatenablog.com/entry/2017/06/27/142352

2回目(isucon5)
http://masa-world.hateblo.jp/entry/2017/07/06/233357
http://matsuda-juri.hatenablog.com/entry/2017/08/01/174159

さて、今回3回目模擬isuocnでは
isucon6(ややこしい)をやる予定。。。。

だったのですが、

まさかの
サーバ起動後のプロビジョン(課題のwebapp)が立ち上がらず、アレヤコレヤしたのですが
時間もないので諦めて、復習を兼ねて前回やったisucon5をやってみようということになりました。

あと、
上の先輩方の記事を見たらわかるのですが、
3人で八時間やって最終スコア0点でした。。。
(ちなみに初期スコアが300くらいww 初期スコアより低いw)


前回の反省とコーチの助言を踏まえてやろうと試みたこととして
mysqlのmy.cnfとnginxのnginx.confをチューニング(前回、コーチがmy.cnfいじって約2万点上がった。)
②N+1問題解決する

でした。


①my.cnfとnginx.conf
そもそも、なんで設定ファイルいじるのかというと
今回のネックとして、②のN+1問題もあったのですが、
前回コーチがそこを解決してもスコアが600くらいしか伸びなかった。そのあとにhtop使って見てみると
DB側に適切にメモリが割り当てられないことがわかりmy.cnfをチューニングすると約二万点に上がった。

nginxは先輩が担当、僕がmy,cnf担当だったので
catasuyさんのmy.cnfを参考に(てか、ほぼパクリ)していじってみると
スコア:300 → 600
あれ?あんまり上がっていない。
前にコーチがいじった時、二万点くらい上がったのに。。
しかも追加した設定もほとんど変わっていないのに。。

そして、
先輩がnginx.confいじり、そしてデータにindex貼ったりするが
スコア:600→1000
あれ?
確かに前回よりもスコア上がっているし、試みたこともできたから嬉しい。
けど、なんか全然スコア上がってなさすぎて嬉しさ半減。

と、とりあえず、気を取り直して②にGO

②N + 1問題
今回、もっともボトルネックなのがこのN +1問題。
ログインユーザーのフレンドかどうかを判断する際に無駄なクエリが発行されている。
ということで、そこのクエリ文を直せば良いことにチームメンバー全員が気づいた。

お、すごく順調じゃん!

となるが


なおせねぇ

というか、誰もクエリ文の直し方とか書き方マスターしてる人がいねぇ。。

チューニングする場所がわかっているのに直せない辛さ。。。
(*うまくいけば 1200クエリ→ 16クエリくらいに減るらしい。)

ググリまくって、書き方を調べて試してみるも
うまくいかず。スコアが下がるどころかエラーが出た。

さらに、rack-mini-profilerとかrack-line-profilerを入れたり
アレヤコレヤやってるうちに時間がすぎて行き
結局、最終スコア 940点でしゅーりょー。

今回の振りかえり
・設定ファイルをいじったとしても、肝心の無駄なクエリが解決していないのでDB側が無駄な動きをしっぱなしで、あまり点数に繋がらなかった。
ボトルネックがわかっても、改善する腕がなければ、意味ない(当たり前)

ただ、よかった点として
・自分達が詰まったところを書き込んで復習できるようにした。
・設定ファイルチューニングがある程度できるようになった。

そして
そもそものコーディング力ってまじで大事!!ってことがわかった
当たり前でしょ?って感じだけど、こうやって模擬isuconをやっての実感値は全然違うなと思いました。

あと、個人的な問題は
コードを読んでこのメソッドがどういう働きをしているのかだったりコードからサービス全体像の把握がまだできていないなと思いました。
圧倒的に読んでる量と書いてる量が足りてない問題。。


とりあえず、
次回までにクエリ文を習得しようと思います。

ではでは〜

デフォルトrubyの罠 〜mac sierra〜

こんばんは!!

 

f:id:Yuki-F:20170717201300p:plain

今日はrailsのお話です。

 

最初のrails入れるのにだいぶ苦労していた僕ですが
先日友人に「railsをpcに入れようとしたらエラーが色々でて、困っている」との連絡

が、、、


実際に会ってみて見ると、
僕も最初ruby入れる際にハマった罠だったので今回、記事にすることに決めました。

 

端的にいうと
.rbenv配下に入れたrubyをpcが読み取ってくれず、rails入れる時にエラーが出てしまう。

 

そして、その原因として
macにはデフォルトでrubyが入っていて、そこをbashが読み取りにいっている。

さらに、ぶつかったものとして

OS X El capitan以降からデフォルトrubyのアンインストールをしようとするとoperation not permittedが出る。

 

結論としては、

bash_profieの中でPATH設定を加えたら上手くいきました。

*ただ根本的な解決になっているのかは怪しいです。。。

 

ちなみに結論に行くまでにやっていたこととして

・usr/bin/ruby をアンインストールしようとするが、できない。→chmodしても

permission error。

・rbenv global でrubyのversionを指定していた。→rbenv versionでも切り替わっているのが確認済み

 

 

Macにはデフォルトでrubyが入っている。

おぉそれならデフォルトのruby使えば良いじゃん!ってなると思うのですが問題が。。。

versionが古い!

そうなんです。デフォルトのrubyのversionは今回 2.0.0だったんですが

最新は2.4.1でなかなかversionが古い。

そして、デフォルトrubyを使わない理由(今の僕の理解範囲)として

・古いので公式のサポートがない。バグとかセキリュティの面で不安。

・最新versionはメソッドが増えていたり便利

などなど、、

そして、それを解決するためにrubyのversion管理ツールであるrbenvを使って最新versionにしていきます。

 

今回のエラー

rbenvで最新のrubyをインストールするまでは上手く行ったのですが、gem install bundlerをしたときに permision errorが出ました。。。

 

これはmacデフォルトruby(usr/bin/rubyがある)を読みにいっているかつ、OS El Capitan以降、セキリュティが強化されて、/usr以下のルートディレクトリは sudo使わないとインストールできないみたいです。

 

ここで一回強行で、sudo gem install bundlerをすると上手くいきましたが 

またまた、問題が!!

sudo gem install rails を打つと

ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory.

 ありゃ?

bundlerはsudoでできたけど、railsはできない。。

 ここで which rubyをすると

usr/bin/ruby を読み取っている。

 

....おい! もっと前に気づけよ、俺笑

急いでいたため、rbenv  versionsで見て、ruby -v の確認コマンド打っていなった僕。

ってことで、デフォルトrubyを潰す作業に入るが最初の冒頭 に書いたようにできず。。

 ならば 読み取るpath変えて、usr/bin/rubyではなく/.rbenv配下のrubyを読み取れるようにしそこに入れるようにしました

 

~/.bash_profileをホームディレクトリの配下に作りました

解決策として、

ホームディレクトリの中に .bash_profileを作って、その中に 

eval "$(rbenv init -)"

 と打ち

$ source ~/.bash_profile

で反映させて、bashを再度起動(これ忘れがち)させ

ruby -v を打つと

 

ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16]

 

できてる!!

 

which ruby を打つと

/Users/user_name/.rbenv/shims/ruby

 

できてる!!

 

ということで一旦落着。

 

別の解決策の可能性として

Rootlessを解除してデフォルトrubyを潰す。(参照:http://gabekore.org/emacs-auto-install-err-443)

とか、他にも解決策ありそうな予感。

 

 

今回参考にさせていただた記事です。

インストール手順参考

https://design4b.co.jp/blog/rails5_1-install-mac-2017

 

〜〜エラー参考〜〜

・rbenvでのversion切り替え:http://qiita.com/akatsuki174/items/c0384b9903b4b5cbbdaf

bash_profile内コマンド:https://github.com/rbenv/rbenv/issues/938

・初期ruby罠について:http://gabekore.org/mac-default-ruby-problem

・gem install 権限について:http://qiita.com/tokimari/items/feda1ed61f2d8b5b317c

 

〜〜今後詳しく調べること〜〜

・中盤で書いた、railsがsudoを使ってもインストールできなかった理由は何か

bash_profile, bashrc とか設定ファイルがあるけど、その読み込みの優先順位と仕組み

・rbenv/shims  のshimsの必要性 

・そもそもappleはなぜmacにデフォルトでruby入れてるの

5時間の苦労が10分で終わった話

 

こんばんは!

 

先ほど、メンターのさぼさんのRubyMineとzshの講座を受けて、作業効率がレベルアップした福地です。

 

 

さてさて、

以前からチーム、個人個人で「line」っぽいものを作ろう活動をしているのですが

先輩は大方完成させています。

同じチームのまさよしさんの「line」(完成度がすごい)↓↓

http://masa-world.hateblo.jp/entry/2017/05/27/172439

 

こんなやつ、俺も早く作りてぇ!

 

と意気込みながら

 

コードを書いて、実行してをしてを繰り返し

よし、Activerecordを使ってmysqlに接続してみようと

http://qiita.com/u1_fukui/items/88c10d4d530ec6fbaaa1

のサイトを見ながら実行してみると....

 

f:id:Yuki-F:20170603022500p:plain

"database configuration does not specify adapter (ActiveRecord::AdapterNotSpecified)"

........

なんかアダプターが特定されていないと怒られました。

エラーが出たのはこの部分。

f:id:Yuki-F:20170603024005p:plain

むむ。

 

そっからほんと地獄が始まりました。

 

入力ミスを探したり

ディレクトリのパスを変えたり

そもそもの書き方探したりしたけど

 

なぜかできない。

それで、以前同じようなことでミスってる人いないかと思って探したりしていると

まさかの同じチームのまさよしさんがブログで書いていたwww

http://masa-world.hateblo.jp/entry/2017/05/15/125249

 

とその中で,

まさよしさんは

database.ymlの adapter :mysql2をmysqlとん入力していたことが原因だと書かれていたので見てみると

f:id:Yuki-F:20170603023524p:plain

 

あれ、ちゃんとmysql2にしている。

気になってgemfileも見てみると、ちゃんと'gem mysql2'にしてました

 

こんなエラーとにらめっこすること総計 5h近く。

さすがに思考も固まりかけていたので

同じ大学だったエンジニアの先輩に助けを求めると,

なんとですね

 

...10分足らずで解決しました。

 

まさに、「まじかよ」って感じですね。

 

原因は 

①developmentをクオーテーションで囲っていること

 そこを'development' →:development  にする

ActiveRecord::Base.establish_connection(:development)
 

②database.ymlの中でインデントをちゃんとしなかったこと

 development以下のコードをインデントしてあげる

development:
adapter: mysql2
database: line_app
host: 127.0.0.1
username: root
password: kuro@0000
encoding: utf8

 

実行してみると.........

サーバが立ち上がりうまくいきました!!!!!!!!!!

 

いやー5時間かけたやつが人に聞くと10分で解決するとは。。

恐ろしや。

 

てか、そもそもこんな基本的なところで間違うということはそこまでちゃんと意味を理解していないんだろうなとも思い、勉強不足を痛感しました。

 

色々ともう一回復習しまくります!

 

では、また

 

Gut に感動 ②

GIt Hub

 

こんばんは!

先日はGitについて、書いたのですが、

今日はGitをもっと有効的に活用したGit Hubについて

  • Git Hubとは?? Gitとの違い
  • Git hubを使ってのアップロードの流れ
  • おまけ:branchとGit Hub desktop

で書いていきます。

 

 Git Hubとは?? ~Gitとの違い~

前回お話したように Gitはファイル変更の履歴などを各変更ごとにリポジトリに記録するシステムでした。

では、Git hubは一体なんでしょうか。

Git hubは簡単に言えば、Gitの機能を拡張させたもので、

Gitは個人のpc(ローカル)のリポジトリに記録するのに対し、

Git Hubはクラウド上(リモート)のリポジトリに記録します。

 

Git Hubのリポジトリにうつすことによって、

そこから、ソースコードを引っ張てきたり、アップロードしたりして他の人との共同開発ができるようになります。

 

 Git Hubの「hub」は「中心、中継」という意味があるので、本当にそのままの意味ですね!

 

Git hubを使っての作業の流れ

 

リモートリポジトリで使う主なコマンドは以下の通り。

 

------------リモートリポジトリへアップロード系コマンド一覧

git remote add (使用するリモート先の) url :アップロードするリモートリポジトリを指定します

・git push リポジトリの名前 master  :リモートリポジトリにアップロードします。

 

------------リモートリポジトリからダウンロード系コマンド一覧

git pull リポジトリの名前  : リモートリポジトリのmasterからのソースコード変更の反映

git clone リポジトリの名前  : リモートリポジトリからローカルリポジトリにクローン

 

------------実際に開発する際に使うコマンド

git branch + ブランチ名  :ブランチをつくれる

git checkout + ブランチ名  :ブランチへ移動 

git branch -d + ブランチ名   :ブランチを削除

 

こんな感じですかね。

 

ってことで

前回のtestフォルダをGit Hub上にあげてみようと思います!

(前回でローカルリポジトリにCommitしてる状態から開始です)

 

①Git Hub上でリポジトリを作る

Git Hubの最初のページの右下にNew repositoryがあるのでそこをクリックしたら

レポジトリ作成ぺージがあるのでそこでテキトーに名前つけて作成。

f:id:Yuki-F:20170518232004p:plain

 

②ローカルにリモート先を登録

今度はターミナルを開いて、リモート先へ

$ git remote add origin https://github.com/(ここは各々変わる)

を入力します。 

 

③リモートにファイルをアップロード

$ git push origin master

f:id:Yuki-F:20170518232635p:plain

 

これで完了しました!!

 

Git Hub上でみて見ると。。。

 

f:id:Yuki-F:20170518233053p:plain

 

できてますね!

 

よかった!

 

しかしめっちゃシンプルすぎ!!

ほんと現代の技術に感動。。

 

おまけ:branchとGit Hub desktop

 

branchとは

何気なーく出てきたbranchですが、Git Hub上ではすごく重要な仕組みです。

 

----ブランチとは、履歴の流れを分岐して記録していくためのものです。分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。       参照:サルでも分かるGit入門

 

複数のリリース版の開発や機能追加、バグ修正などを複数のメンバーが平行して開発していくためにはbranchが必須なのです。

 

Git Hub desktopとは

 Gitで共同開発をしていく上で、commitするタイミングとしては バグ修正や機能追加など各変更点でcommitしていくそう。

 

しかし、commitを忘れて修正や機能追加をたくさんしてしまった場合、一度のメッセージでは伝えられないことがあります。

そんな時にGit Hub desktop の出番です!!

これを使えば、ソースコードの変更点ごとにわけてcommitができます。

...............便利すぎる!!

 

僕の先輩が実際に試したやつをブログで書いています↓↓

http://masa-world.hateblo.jp/entry/2017/05/17/223014

 

 

まだまだ奥が深いGit Hub。

実際にこれから開発で使っていくのが楽しみです♪

 

 

Git に感動 ①

Git

 

こんばんは!

 

前々から予約していた星野源のMV集が届いてご満悦な福地です。

 

今回はweb本とは離れて 「Git」について書いていきます!

というのも先日、我らがチームのメンター、さぼさんが3時間以上かけて僕らに「git」と「Github」について教えていただきました。(マジ感謝です。)

 

ってことで

・Gitとは? 

・Gitの3つの段階

・gitのコマンド

の3つで書いていきます。

 

Gitとは? 

 

まずはGitの意味から

Git:プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである---参照 wikipedia

 

。。。。分散型バージョン管理システムとはなんぞや。

 

こういう時は分解して見るのが良き

 

分散型:分散して機能を持たせること

バージョン管理システム:ファイルの作成日時、変更日時、変更点などの履歴を保管するシステム(ここで言うバージョンはファイルの状態のこと。 ex.ファイル1の内容更新してファイル2にして保存するとファイル1のバージョンがファイル2に変わった的なやつ)

 

なるほど。 

 要はGitはソースコードなどの変更履歴を記録・追跡するために(各バージョンごとに)分けて履歴を保管するシステムのこと」ということ。

 

ちなみに他のサイトでは

Gitとは、コンピュータ上のファイルなどの変更を記録し、その変更履歴を管理するためのバージョン管理ツールです。同時に、複数の作業者が同時に変更を行ったり、その履歴を管理するための機能を併せ持っています。 ---参照  Gitとは? 3分で分かる、Gitの「超」入門知識まとめ

 

なるほどなるほど。何となく理解してきました。 

 

さてさて実際にやってみようと思いますが、事前準備として

brew installコマンド で git と tig(何かは後ほど説明)をインストールします。

あとはgitの中にフォルダを作ったら準備完了です。

 

Gitの3つの段階

 

Gitとは何か、がわかりました。実際にソースコードなど変更を行い履歴を リポジトリ(履歴の保管場所)に記録していくにはどうしたらよいのでしょうか。

 

そのためには Gitの3つの段階を理解していく必要があります!

 

①ファイル内容修正が反映されていない段階 ---untracked 

リポジトリに記録する準備 ---staged

リポジトリに記録 ---commited       

の3つの流れで変更状態がリポジトリに記録されていきます.

 

①ファイル内容修正が反映されていない段階  ---untracked 

百聞は一見に如かずと言うことで実際に見てみましょう!

 

まず、 Gitに移動した後に$ git initで初期化します。

f:id:Yuki-F:20170518003150p:plain

その後に今回はgitの中にtestというフォルダを作成してその中にtest.txtを作ります。

下のような感じでエディタ上でファイル作成の後にテキトーに文字を入れて保存します。

f:id:Yuki-F:20170518002457p:plain

 

そして $ git status (gitの状態を見るコマンド)を打つと

f:id:Yuki-F:20170518004524p:plain

untracked filesの中に test.txtがあります。これはまだstagedの段階に上がってないという意味。

 

 

リポジトリに記録する準備 ---staged

次にtest.txtをリポジトリに記録する準備(=stagedにする )をします。

 $ git add test.txt  を打って再び statusをみてみると

f:id:Yuki-F:20170518005403p:plain

なんか色が変わってる!!!!!

これが stagedになった瞬間です!!

git add (ファイル名)でstagedに上がれます いやーシンプルですね。

 

ちなみに

今回は新規ファイル作成で new fileと表示されたのですが、内容を変更したりすると

modified : ファイル名   となります。 

 

 

リポジトリにファイル状態を記録 ---commited 

さて、早速リポジトリに記録していきましょう!!

 

git commit -m 'メッセージ'でリポジトリにうつすコマンドです。

* ' 'の中身として、実際にはソースコードの変更・修正内容を書きます。

 

$ git commit -m 'file作成' を打つと

f:id:Yuki-F:20170518005841p:plain

これで、完了のはずですが,

 

わかりづらい!!

 

ここで tigが出てきます! tigは実際にcommitされたか確認するツール的なやつです。(今回はgitのお話なので詳しいtigの説明は省略します。) 

 

$ tig を打つと 画面が変わり、上の方に出てきます。

f:id:Yuki-F:20170518010415p:plain

これでリポジトリの中にファイルの状態が記録されました。

 

 これがGit を使ったリポジトリに記録するまでの流れです。

 

主なGitコマンドについて

 

今回使った コマンド + よく使われるコマンドをまとめました。

  • git init :  gitディレクトリが作成される
  • git status :  そのディレクトリ内のファイルがどのような状態にあるか分かる
  • git add :  untrackedのファイルや変更したファイルをgitに取り込む
  • git commit (-m '' ) :  ローカルリポジトリ に記録する
  • git checkout :  前回のcommitの状態に戻る
  • git reset : ステージにうつしたファイルの取り消しができる 
  • git rm :  untrackedにする (ファイルも消える)
  • git rm --cached :  commitしたファイルをuntrackedに戻す 

 参照 ----まさ@ブログ書き込み中

--------------

次はこれを git hubについて書いていきたいと思います 。

では、また明日〜!

 

 

 

 

 

プロになるためのweb技術を読んで 3

Cookieとsessionについて

 

こんにちは!

Mosバーガーの美味しいシェイクを食べながらカタカタしている福地です。

 

今日書いていくのは、Webアプリケーションの重要でかつ基本的な仕組みであるCookieとsessionについて

・HTTPの問題点

Cookieとは

・sessionについて

という流れで書いていきます。

 

HTTPの問題点

HTMLを閲覧できる仕組みであるHTTPですが、何かと問題点があります。その一つとして「状態の維持」です。

これだけでわからないので、例としてアマゾンを考えて見ましょう。

 

アマゾンでの買い物の大まかな流れとして

① IDとパスワードを入れてログイン

②好きな商品を探してカートに入れる

③商品を注文・購入

④購入した商品を確認

⑤ログアウト   になると思います。

ただし、ログインの状態を保ってないと③はできないと思います。

ここがポイントです!!

 

HTTPが行うリクエスト処理はそれぞれ独立しており、ログイン後にしか閲覧できないものもURLさえ知っておけばログインしなくて閲覧できるようになります。ログインページとログイン後のページが独立しているのです。これは大変な問題ですよね。

ここで、それを解決するCookieが出てきます。

 

Cookieとは

Cookieは一言でいうと、甘くて美味しい子供達が喜ぶ食べ物です!

 

終わり。

 

 

...........とはいきません。

 

 現実世界で喜ばれるCookieですが、webの世界では通信上、重要な役割を果たしています。

その役割として 「ログイン状態の受け渡し」があります。

アマゾンの例でいくと、

 ログインページでIDとパスワードを入力したリクエストした後に、webサーバから商品一覧ページのレスポンスのついでに

IDとパスワードの情報が入ったCookieを返されます。

クライアント側からまた次のページのリクエストをする際にCookieを格納して送り返すことで、ログイン状態を保ちながら買い物ができます。そしてログアウトするとその Cookieが削除されます。

 

こうすることで、いきなり商品購入ページのURLを入力したとしてもログインをしていないと、Cookieが発行されていないためページの閲覧ができなくなります。

 

いやー便利ですね!

 

Sessionについて

さてこんな便利なCookieですが、弱点があり、それはログイン時に入力したIDとパスワードの情報がそのままCookieに入るということです。

 

これは何が問題かというと、Cookieを利用した情報のやり取りはHTTPのリクエスト・レスポンスへッダを利用して行われていますが、

第三者がちょっとしたツールを使ったらそれをのぞけてしまうのです。要はIDとパスワードが見れてしまいます。

 

そこで出てくるのがsessionです。

sessionのイメージとして銀行での手続きを想像して欲しいのですが、銀行で手続きをする際には、窓口に行き、受付をして受付番号をもらうと思うのですが、その番号自体では個人を特定することは不可能ですよね??

sessionはそれと同じ考えです!

 

クライアント側がログインした後、webサーバ上ではクライアントのログインIDとパスワードを保管してそれを入れる代わりにsession IDと呼ばれる意味のない番号をCookieに入れます。

 

これで他の人に情報のやり取りを見られたとしても意味ない番号ですから分からないですよね。

 

先ほどの銀行の手続きを

手続きをしたい人=クライアント、銀行 = webサーバ、受付番号 = session IDにするとわかりやすいですね!

 

こんな流れのWebアプリケーション上での仕組みがあります。

 

プロになるためのweb技術入門を読んで 2-1

 HTTPのお話

さて、久しぶりの投稿になりましたが、

今回はHTMLのやり取りに使われる HTTPについて二回に分けて書いていきます。

 

1回目は

の流れで書いていきます。

 

っとその前に、そもそもHTTPってなんだっけ?

HTTPはWWWの世界でHTMLのやり取りをするために定められた通信プロトコルの一つです。通信プロトコルはやり取りする。情報の「伝達手段」と「意味付けの役割」を果たします。

 

よしよし、ではいきましょう。

 

IPアドレスTCP/IP

 

まずはIPアドレス! 二言で言うならば、「コンピュータに割り当てられるインターネット上の住所」です。 (一言では難しかった。)

 

例として、前回の記事より、http://www.pizaya.jp/special_menu/index.htmlをあげます。これでインターネット上のコンテンツを指定します。しかしスキームやホスト名やパス名で構成されているこのURLは人間には何が書いているのかわかりますが、コンピュータはそうはいきません。そこでコンピュータにもわかりやすくするために出てきたのがIPアドレスです。

実際に見てみると、こんな感じ→193.234.0.1。 うん。何を意味してるのかわからない。コンピュータすごいなおい。これでコンピュータを識別しています。

 

IPアドレスの種類で「グローバルIPアドレス」と「プライベート IPアドレス」があります。簡単に言うと

  グローバルIPアドレス:世界目線でのインターネット上の唯一のアドレス

  プライベートIPアドレス:オフェスや家庭内など一定の範囲で使われるアドレス

前者は「固定電話」後者は「内線」で例えると分かりやすいです。

固定電話は知っての通り、国別(日本は03-)番号から始まり、都道府県や市町村ごとに振られていて被る事はないですよね!グローバルIPアドレスも同じような考えです。

一方で内線1番や2番などはどこの会社でも意味は違うけど同じ番号が使われています。プライベートアドレスも重複しても良いアドレスの事です。

 

IPアドレスの内容と種類をお話しましたが、実際にこの IPアドレスを運ぶ運び屋が

 TCP/IPです。現実世界で言う「郵便屋さん」です。僕らが宛先(コンピュータ上で言うならIPアドレス)を指定して相手に手紙(コンピュータ上の情報)を届ける際の届け役ですね。TCP/IPはブラウザから受け取ったHTTPリクエストを小さな単位に分割してwebサーバにたどり着いた後に再構築します。

 

DNSサーバとポート

 

 DNSサーバ---通訳的な存在

IPアドレスはわかったけど、実際のURLを入力するアドレスバーにはIPアドレス使ってないじゃんと思いましたが、なんと裏で中継してくれる奴がいるんです。

それがDNSサーバです!

DNSサーバがURL→IPアドレスに変換してクライアントにに届けてくれます。それをクライアントはwebサーバに届けて私たちはインターネットを利用できています。

ここまでで、宛先のコンピュータを探し出す流れは掴めました。

 

ポートとは---情報の待ち受け桟橋的な存在

インターネットの世界ではHTTP以外でも様々なプロトコルで情報がやり取りさています。ex.電子メールやwebサイトの更新など

TCP/IPではその中でどの情報をどこのホスト内で処理していいのかわからないままです。そこでコンピュータの中で各アプリケーションが情報を待っていいます。イメージは港町のたくさんのそれぞれの桟橋の上に職人(アプリケーション)が立っている感じです。

これで各職人さんが情報を処理してくれます。

ちなみにHTTPのプロトコル番号は80で、普段はホスト名の中で省略されています。

 

 POSTとGET

 

今までで、大体のHTTP通信からwebページの表示までの流れでしたが、webアプリケーションへ私たちが情報を流すにはまだ足りません。そこで出てくるのがPOSTとGETメソッドです。これでクライアントがパラメータ(入力した値のようなもの)をwebサーバが受け取る際に使うメソッドです。POSTと GETは渡し方の違いです。実際に見て見ましょう。

 

GETメソッドでの例:

https://www.kakezan.jp/webtext/do_calc_get.php?num1=50&num2=20

(ちなみに下線部がパラメータ=値)

 

POSTメソッドでの例:

https://www.kakezan.jp/webtext/do_calc_post.php

 

 

この二つ、何か違いますね。…..そうです。パラメータが見れるか見れないかの違いですね!

これでわかると思いますが、

GETメソッド=パラメータが見える=セキュリティ弱

POSTメソッド=パラメータが見えない=セキリュティ 比較的 強

 

ん?なら全部POSTメソッド使えばいいじゃんってなると思いますがGETも POST良いところと悪いところがあります。

 

  GETメソッド POSTメソッド
セキュリティ 低い 比較的高い
パラメータの長さ ソフトウェアによっては255文字以内 制限なし
パラメータの保存・再現 しやすい しにくい
副作用が発生しない 期待される 期待されない

 

って感じです。

同じ処理を繰り返す場合はGETが良さそうで、使い分けが必要ですね。

 

てことで HTTPのセクションは以上です!!

次から本読む時は重要な点を付箋紙で抑えてそこをまとめると楽になりそう。