トップ > IT企業で働くための最低限の知識(後半戦)

IT企業で働くための最低限の知識(後半戦)

前回はクックパッドの新人研修用のスライドを見て、内容を書き出しながら理解を深めてった。その続編となる今回。より詳しくクライアントとサーバのやりとりを見ていく。

  • 目次
    • コンピュータ
    • クライアント
    • サーバー
    • エンジニア
    • リクエストとレスポンス ⇦ここから
    • ネットワーク
    • セキュリティ

リクエストとレスポンス

  • ざっくりの流れ

    クライアントがネットワークを介してサーバにリクエストを投げる。

    サーバはネットワークを介してクライアントにレスポンスを返す。

何をやりとりしているのか

  • リクエストの中身

    URLなど

  • レスポンス

    ブラウザ: HTML CSS Javascript 画像など

    アプリ: JSON 画像など

リクエスト

URL

ブラウザの上の方に表示されているやつ

http://github.com/

subaru-helloのGitHubが見たい

https://github.com/subaru-hello/Genba_3

URLでは実現できないこと

・URLは「何をリクエストしているか」は指定されている一方で、「誰がリクエストしている」かはわからない。

・誰からのリクエストかわからないと、

・ユーザ毎に違う情報を出し分けられない。

・そのページを提供していいかどうかわからない。

識別・認証・認可

・識別

誰なのか明らかにする

例）ログインID（メールアドレス）を確認する

・認証

本当にその人なのか確認する

例）パスワードを確認する

・認可

・その人がアクセスしていいものなのか判断する

例）許可証のようなものを発行して、アクセスがあったときに検証する

それぞれの一連の流れ

 

１）クライアント

 私は○○です。これが証拠のパスワードです（ログインIDとPWを送る）

２）サーバ

  識別・認証・認可の発行

３）サーバ 

「たしかにあなたは○○さんのようですね。次回からこのデータを一緒に送ってくだされば、あなたからのリクエストだと認めます。」（許可証のようなものを送る）

４）クライアント

 このページが見たいです。（さっき指定された許可証のようなものを一緒に送る）

５）サーバ  

認可の検証

６）サーバ 

「たしかにページを見る権限がありますね。こちらがそのページになります。」

 

認証と認可の注意点

 

・パスワードや許可証のようなものはサーバが「誰からのリクエストなのか」「何にアクセスしていいのか」を判断するための重要な情報

・もし何らかのクラッキングによって情報が漏れてしまった場合、その人に成りすましてリクエストを送ることが可能になる。

SessionとCookie

概要

例)ショッピングサイト

「このユーザーは誰か」→セッションIDで識別することが可能

「なにを買ったか」→セッション変数にデータをセット セッションが持続する間保持できる

  • ショッピングサイトを移動する間は、サーバーに保存されているセッション情報を逐次取り出して、表示、更新する。
  • 商品を追加したときにはセッション変数に追加、カートから削除したときにはセッション変数から削除。
  • セッションに保存された内容は、Webサーバーにファイルとして保存されている。
  • ユーザーのWebブラウザにはセッションID(無作為な英数字)がCookieに記録される。
  • セッションIDとWebサーバー上のファイルが照合されてセッション内容を取り出す。

ここが脆弱だと、セッションハイジャックに遭う

セッションハイジャック

何らかの方法で取得したセッションIDを利用して正規のユーザーのセッションを乗っ取る攻撃。

レスポンス

何を返しているか

HTMLよりもシンプルでプログラムを扱うのに便利モバイルアプリやブラウザで動くJavascriptはこのJSONで返すことが多い。

例）

```

{ "name"   : "John Smith",
  "sku"    : "20223",
  "price"  : 23.95,
  "shipTo" : { "name" : "Jane Smith",
               "address" : "123 Maple Street",
               "city" : "Pretendville",
               "state" : "NY",
               "zip"   : "12345" },
  "billTo" : { "name" : "John Smith",
               "address" : "123 Maple Street",
               "city" : "Pretendville",
               "state" : "NY",
               "zip"   : "12345" }
}
```

ブラウザとアプリの違い

ブラウザ

・HTML,CSS,Javascript,画像等

画面表示する仕組み

・HTMLに書かれた構造の見た目をCSSで整えて、Javascriptで動かす。

・HTML,CSS,Javascriptのすべてをリクエストして、レスポンスとして受け取る.

アプリ

・JSON,画像等

画面表示する仕組み

・JSON形式で受け取ったデータをアプリで見た目を整えたり動かしたりしている。

・JSONはリクエストしてレスポンスとして受け取るが、見た目を整えたり動きを加えたりする部分であるアプリはあらかじめインストールされている。

・アプリは各サービスの専門クライアントなので、そのサービスに特化した見た目や動きを作ることができる。

どのように通信しているのか

多種多様なハードウェア・OS・アプリケーションがある中で、お互いに通信するためには決まり（仕様）を作っておく必要がある。

プロトコル

・通信のための仕様をプロトコルという。

・URLに含まれている

「https://github.com/」の「https」の部分。

・通信する内容に応じた様々なプロトコルが存在する。

HTTP（Hyper Text Transfer Protocol）

最も使われているプロトコルの一つ

・HTTPというプロトコルに従ったリクエストとレスポンスをそれぞれ

「HTTPリクエスト」と「HTTPレスポンス」という。

・ブラウザやアプリはこのHTTPをつかって通信をしている。

HTTPリクエストを送って、HTTPレスポンスとしてHTML,CSS,Javascript,,JSON,画像を返している。

HTTPS

・基本的にはHTTPと同じ

・重要な違い：通信の内容が暗号化されていて安全

HTTPリクエスト

全部で9種類メソッドがある

代表例）

GETリクエスト

ページを取得するためのメソッド

「このページを送って。」

使用例

・ブラウザにURLを入力したとき

・リンク、ボタンをclickしたとき

POSTリクエスト

データを送信するメソッド

「このデータを受け取って」

使用例

・フォームに記入した内容を送るとき

HTTPレスポンス

ステータスコード

3桁の数字で表されるレスポンス内容の要約

200番台: リクエスト成功

300番台: リダイレクト（追加のリクエストが必要）

・POSTの結果などは通常300番台で返ってくるので、レスポンスで指定されたページをGETして

それを表示する。

400番台: リクエストが失敗した（原因はクライアント）

500番台: リクエストが失敗した（原因はサーバ）

HTTP以外のプロトコル

SMTP

・メール送信

POP、IMAP

・メール送信

FTP

・ファイル送信（最近はあまり使われない）

SSH

・サーバにログインして操作する

API(Application Programming Interface)

・ブラウザやアプリのためのリクエスト送信先

ブラウザとアプリは欲しいレスポンスが違う

プロトコルとしてHTTP(S)を使用してJSONを返す

ネットワークを詳しく

ネットワークを相互接続した巨大ネットワークが日本全国、そして世界とつながっている。

インターネットとWEB

インターネットで調べると普段使っている、このインターネットはWEBをさしている。

WEBを見るクライアントをWEBブラウザという。ChromeやSafari、Firefoxが該当する。

WEBとは

インターネットというネットワークを通じて

HTTPやHTTPSというプロトコルで

HTML,CSS,Javascript,画像などをやり取りする仕組み

インターネットは単なるネットワークに過ぎないため、データを届ける仕組みが必要になる

IP(Internet Protocol)

インターネットを使ってデータをやり取りするプロトコル。

・パケットという単位に分割して送信する。

・「HTTPというプロトコルに従って生成されたデータ」を「IPというプロトコルに従ってパケットに分割したうえで送信する」

パケットに分割するメリット

パケットに分解することで、一本のケーブルで複数のクライアントで共有することができる。

データの送信中に一部が壊れてしまっても、対象のデータだけ送りなおせて効率的

4つをドッドでつなげる

IPアドレス

インターネット上の住所のようなもの

0から255の数字をつなげて表記する

例）198.51.100.7

パケットにIPアドレスを指定することで、インターネット経由でパケットを届けられる。

・宛先と送信元二つのIPアドレスを指定する。

IPアドレスの種類

・パブリックIPアドレス（グローバルIPアドレス）

世界で重複しないように調整されている。

・プライベートIPアドレス

社内や家庭内などのネットワークを各自で管理している。

同じネットワークでは重複してはいけないが、別のネットワークとは重複しても問題ない。

ドメインとDNS

人間はIPアドレスのような数字を覚えることができない。

名前を付けて覚えられるようにした。

例)　http://subaru.com/

これをドメイン名と呼ぶ。

パブリックIPアドレス同様、重複しないように管理されている。

すでに使われているアドレスは使用不可能

ドメイン名をIPアドレスに変換することを、「名前解決」と呼ぶ。

名前解決の仕組みを**DNS（Domain Name System）**という。

HTTP、インターネット知識を一貫して書いてみると下記の通りになる。

ブラウザがリクエストを送るとき

・リクエストを送る先のURLが入力される。

リンクをクリック、アドレスバーにURLを入力など。

・URLに含まれているドメイン名をDNSによって名前解決してIPアドレスに変換する。

・HTTPというプロトコルに従ってHTTPリクエストを作る。

・HTTPリクエストをIPというプロトコルに従ってパケットに分割する

・パケットに宛先と送信元のIPアドレスを指定する。

・インターネットに向けてパケットを送り出す。

サーバがリクエストを受け取ったとき

・インターネット経由でパケットが届く

・届いたパケットをくっつけてHTTPリクエストを復元する。

・HTTPリクエストに書かれた内容を読み取って処理する

・HTTPというプロトコルに従ってHTTPレスポンスを作る。

・HTTPレスポンスをIPというプロトコルに従ってパケットに分割する

・パケットに宛先と送信元のIPアドレスを指定する。

・インターネットに向けてパケットを送り出す。

セキュリティ

暗号文と復号

・暗号

そのままでは内容がわからないようなデータ

・平文

見ればわかるデータ

・暗号と平文の変換

暗号化　平文から暗号への変換

復号　　暗号から平文への変換

暗号化したデータを送信して、受信してから復号すればのぞき見されても大丈夫。

暗号化するうえでの問題

クライアントとサーバで共通のカギを保有しておく必要がある。

・これを共通鍵という

どのようにしてのぞき見されないで鍵を共有することができるか。

通信相手が正しい相手かどうかを判別しないと、個人情報が悪意のある第三者にわたってしまう可能性がある。

そこで、通信相手の認証に使う技術が存在している。

・公開鍵暗号

・デジタル署名

・公開鍵証明書

公開鍵暗号

暗号化するための鍵と復号させるための鍵が別々の暗号

秘密鍵と公開鍵がセットになっている

・秘密鍵　秘密にしなければならない

・公開鍵　誰に見られても大丈夫

デジタル署名

データの送り主を認証するための仕組み

・あらかじめ公開鍵暗号のキーペアを作成して、世界中に公開しておく。

・送信者は送信データを秘密鍵で暗号化して送る

・受信者は受信データを公開鍵で復号する

・公開鍵暗号の性質により、正常に復号できれば、その公開鍵に対応する秘密鍵で暗号化されたことが分かる。

・秘密鍵は秘密にされているので、データの送り主は公開鍵に対応する秘密鍵を持っている人だとわかる。

公開鍵証明書

デジタル署名はデータの送り主が公開鍵に対応する秘密鍵を持っているということを保証する。

しかし、キーペアごと差し替えられて、偽物の公開鍵と秘密鍵を使って通信させられる可能性が残っている。

キーペアの差し替えを防ぐために、ある公開鍵が誰のものであるかを管理している認証局というものがある。

公開鍵と一緒に公開鍵証明書を受け取って、公開鍵証明書が正しいかどうか検証する。

公開鍵証明書は、認証局によって署名されている。

TLS(Transport Layer Security)

・安全な通信を実現させるためのプロトコル

・鍵交換アルゴリズムやデジタル署名を利用している

昔はSSLと呼ばれていた。（今でも呼ばれることがある）

主な機能

・通信内容の暗号化: 通信内容がのぞき見されないように

・通信相手の認証: 偽物のサイトにつないでいないか

・改ざんの検出: 通信途中で内容が書き換えられていないか

HTTPS

HTTP + TLS

TLSがHTTPに付加している機能

通信内容の暗号化、通信相手の認証、改ざんの検出

HTTPのやり取りは依然と同じ動作をするが、TLSが付加された分安全性が増している

ちなみにGoogleはHTTPS対応サイトを検索順位で優遇

 

Ruby on Rails Associations and Basic Rails Project

技術基礎研修「クックパッドを支える仕組み」 / Introduction to the Internet

How Browsers Work: Behind the scenes of modern web browsers - HTML5 Rocks