Network
Network
HTTPのGETとPOSTの比較
両方ともHTTPプロトコルを使用して、サーバーに何かをリクエストする場合に使用する方法です。ただし、それぞれの特徴を正しく理解して、適切な目的に応じた方法を使用する必要があります。
GET
まず、GETメソッドは、要求するデータがHTTPリクエストメッセージのヘッダー部分にURLが含まれているため、送信されます。そのため、URLには「？」の後ろにデータが付加され、リクエストが送信されます。この方法では、URLにデータが詰め込まれているため、送信できるデータのサイズに制限があります。また、セキュリティが必要なデータについては、データがURLにそのまま表示されるため、GETメソッドは適切ではありません（例：パスワード）
POST
POSTメソッドのリクエストは、HTTPリクエストメッセージのボディ部分にデータが含まれ、送信されます。したがって、バイナリデータを要求する場合などは、POSTメソッドで送信する必要があります。GETメソッドよりもデータ量が大きく、安全面では優れています。(ただし、安全性の面では、暗号化しない限りは十分ではありません。)
それでは、このような特性を理解した後、どこに適用されるのかを知る必要があります。まず、GETは取得することです。サーバーから何らかのデータを取得して表示するために使用されるか、サーバーの値や状態などを変更しません。SELECT的な性質を持っていると見ることができます。一方、POSTは、サーバーの値や状態を変更または追加するために使用されます。
付随する違いをもう少し調べてみると、GETメソッドの要求はブラウザでキャッシュされる可能性があります。したがって、送信するデータのサイズが小さく、安全上の問題がないため、POSTメソッドで要求する必要がある場合でも、キャッシュされたデータが応答される可能性があります。そのため、目的に応じた技術を使用する必要があります。
TCP 3-way Handshake
TCP 3-way Handshakeとは、TCP/IPプロトコルを使った通信において、クライアントとサーバー間でコネクションを確立するための手順のことです。この手順は、以下の3つのステップで構成されています。
- クライアントがサーバーにSYNパケットを送信する。
- サーバーがSYNパケットを受信し、クライアントに対してSYN+ACKパケットを返信する。
- クライアントがSYN+ACKパケットを受信し、サーバーに対してACKパケットを返信することで、コネクションの確立が完了する。
このように、TCP 3-way Handshakeによって、クライアントとサーバー間で確実に通信が行われることが保証されます。
TCPとUDPの比較
UDP
UDP(User Datagram Protocol)は、非接続型プロトコルである。IPデータグラムをカプセル化して送信する方法や、接続設定を行わずに送信する方法を提供する。UDPはフロー制御、エラー制御、または破損したセグメントの受信に対する再送信を行わない。これらはすべて、ユーザープロセスの責任である。UDPが行うことは、ポートを使用してIPプロトコルにインターフェースを提供することである。
クライアントはしばしば、サーバーに短い要求を送信し、短い応答を期待する。もし要求または応答が失われた場合、クライアントはタイムアウトされ、再試行することができる。コードは簡単であり、TCPのように初期設定から要求されるプロトコルよりも少ないメッセージが要求される。
UDPを使用したものには、DNSがある。あるホスト名のIPアドレスを見つける必要があるプログラムは、DNSサーバーにホスト名を含むUDPパケットを送信する。このサーバーは、ホストのIPアドレスを含むUDPパケットで応答する。事前の設定は必要なく、その後の解除も必要ない。
TCP
ほとんどのインターネットアプリケーションは、信頼性と順序性が必要です。 UDPではこれを満たすことができないため、別のプロトコルが必要になり、それが TCP (Transmission Control Protocol、トランスミッション制御プロトコル)です。 TCPは、信頼性のないインターネットを介して、エンドツーエンドの信頼性のある バイトストリームを送信するために特別に設計されています。 TCPサービスは、ソケットと呼ばれるエンドポイントを生成することによって、送信者と受信者の両方によって実行されます。 TCPでは、 3ウェイハンドシェイクを使用して接続設定が行われます。
すべてのTCP接続は、フルデュプレックス（full-duplex）、ポイントツーポイント（point to point）方式です。フルデュプレックスは、送信が双方向で同時に行われることを意味し、ポイントツーポイントは、各接続が正確に2つのエンドポイントを持っていることを意味します。 TCPは、マルチキャストやブロードキャストをサポートしていません。
HTTPとHTTPS
HTTPの問題点
- HTTPは平文通信であるため、傍受が可能である。
- 通信相手を確認しないため、なりすましが可能である。
- 完全性を証明できないため、改ざんが可能である。
上記3つは、暗号化されていない他のプロトコルでも共通する問題点である。
TCP/IPは傍受が可能なネットワークである。
TCP/IP構造の通信は、通信経路上で全て傍受可能である。パケットを収集するだけで傍受が可能である。平文で通信する場合、メッセージの意味を理解できるため、暗号化して通信する必要がある。
-
対策方法
- 通信自体を暗号化することができる。
SSL(Secure Socket Layer)やTLS(Transport Layer Security)といった別のプロトコルを組み合わせることで、HTTPの通信内容を暗号化することができる。SSLを組み合わせたHTTPをHTTPS(HTTP Secure)またはHTTP over SSLと呼ぶ。 - コンテンツを暗号化することができる。つまり、HTTPを使用して輸送されるコンテンツ、すなわちHTTPメッセージに含まれるコンテンツのみを暗号化することができる。暗号化して送信すると、受信側ではその暗号を解読して出力する処理が必要になる。
- 通信自体を暗号化することができる。
通信相手を確認しないため偽装が可能である
HTTPによる通信では、相手が誰であるかを確認する処理はないため、誰でもリクエストを送信できます。IPアドレスやポートなどから、そのWebサーバにアクセス制限がない場合、リクエストが来たら相手が誰でも何らかのレスポンスを返します。このような特性は、多くの問題を引き起こします。
- リクエストを送ったWebサーバが、本来意図したレスポンスを返すべきWebサーバであるかを確認できません。
- レスポンスを返したクライアントが、本来意図したリクエストを送信したクライアントであるかを確認できません。
- 通信している相手が、アクセスが許可された相手であるかを確認できません。
- どこから誰がリクエストしたかを確認できません。
- 意味のないリクエストも受信します。 –> DoS攻撃を防止できません。
補完方法
上記の暗号化方式では、「SSL」を使用して相手を確認することができます。SSLは、証明書を提供することで相手を確認する手段を提供しています。証明書は、信頼できる第三者機関によって発行されるものであるため、サーバーやクライアントが実在することを証明します。この証明書を使用することで、通信相手が自分が通信しようとしているサーバーであることを示し、ユーザーは個人情報漏洩などの危険性が減少します。さらに、クライアントはこの証明書を使用して自己確認を行い、ウェブサイト認証にも利用できます。
完全性を証明できないため、改ざんが可能である。
一方、完全性を証明できないため、改ざんが可能です。ここでいう完全性とは、情報の正確性を意味します。受信したサーバーまたはクライアントの内容が送信側から送信された内容と一致することを保証できないため、リクエストまたはレスポンスが送信された後、相手によって改ざんされる可能性があります。このように、攻撃者が途中でリクエストまたはレスポンスを盗み、改ざんする攻撃を中間者攻撃（Man-in-the-Middle）と呼びます。
補完方法
MD5やSHA-1などのハッシュ値を確認する方法や、ファイルのデジタル署名を確認する方法は存在しますが、確実に防止するにはHTTPSを使用する必要があります。 SSLには認証や暗号化、ダイジェスト機能があります。
HTTPS
暗号化、認証、完全性保護をHTTPに追加したHTTPS
HTTPSは、HTTP에 SSLの殻を被せたものと言えます。つまり、HTTPSは新しいアプリケーション層のプロトコルではなく、HTTP通信するソケット部分をSSL (Secure Socket Layer)またはTLS (Transport Layer Security)というプロトコルに置き換えるだけです。HTTPは元々TCPと直接通信していましたが、HTTPSではHTTPはSSLと通信し、SSLがTCPと通信するようになります。SSLを使用したHTTPSは、暗号化、証明書、安全性保護を利用できるようになります。
HTTPSのSSLでは、共通鍵暗号化方式と公開鍵暗号化方式を混合したハイブリッド暗号システムを使用しています。共通鍵を公開鍵暗号化方式で交換した後、次からの通信は共通鍵暗号を使用する方式です。
すべてのWebページでHTTPSを使用してもよいでしょうか？
平文通信に比べて暗号化通信は、CPUやメモリなどのリソースをより多く必要とします。通信するたびに暗号化をすると、追加のリソースを消費するため、サーバー1台あたり処理できるリクエストの数が相対的に減少することになります。
しかし、最近ではハードウェアの進歩により、HTTPSを使用していても、ほとんどスピードの低下がなく、新しい標準であるHTTP 2.0を併用することで、むしろHTTPSがHTTPよりも高速に動作することがあります。そのため、Webは過去に機密情報を扱う場合にのみHTTPSによる暗号化通信を使用する方式から、現在はすべてのWebページでHTTPSを適用する方向に変わっています。
DNSラウンドロビン方式
DNSラウンドロビン方式の問題点
- サーバーの数だけ公開IPアドレスが必要 負荷分散のため、サーバーの数を増やすためには、その数だけ公開IPアドレスが必要です。
- 均等に分散されない モバイルサイトなどでは問題が発生することがあります。スマートフォンの接続は、キャリアゲートウェイと呼ばれるプロキシサーバーを経由します。プロキシサーバーでは、名前解決結果が一定期間キャッシュされるため、同じプロキシサーバーを経由する接続は常に同じサーバーに接続されます。また、PC用のWebブラウザもDNSクエリ結果をキャッシュするため、均等に負荷を分散することはできません。 DNSレコードのTTL値を短く設定することである程度解消されますが、TTLに従ってキャッシュを解除するわけではないため、十分に注意が必要です。
- サーバーがダウンしても確認できない DNSサーバーは、Webサーバーの負荷や接続数などの状況によってクエリ結果を制御することはできません。Webサーバーの負荷が高く、応答が遅れたり、接続数が一杯で接続を処理できない状況であるかを全く検知することができないため、どのような原因でダウンしても、それを検出せずにユーザーに提供します。これにより、ユーザーがダウンしたサーバーに接続することがあるため、DNSラウンドロビンは負荷分散のための方法に過ぎず、他のS/Wと組み合わせて管理する必要があります。
ラウンドロビン方式を基盤とする問題点を解消するDNSスケジューリングアルゴリズムが存在します。（一部のみ紹介）
Weighted round robin (WRR)
各ウェブサーバーに重みを付けて分散比率を変更します。もちろん、重量の大きいサーバーほど頻繁に選択されるため、処理能力の高いサーバーは重みを高く設定することが望ましいです。
Least connection
接続クライアント数が最も少ないサーバーを選択します。ロードバランサーは、接続数をリアルタイムで管理するか、各サーバーが定期的に報告する必要があります。
ウェブ通信の流れ
Chromeを起動してアドレスバーに特定のURLを入力すると、何が起こるのでしょうか？
ブラウザ内
- URLに入力された値をブラウザ内部で決定されたルールに従って解析します。
- 解析された意味に従ってHTTPリクエストメッセージを作成します。
- 作成されたメッセージをWebサーバーに送信します。
このとき、作成されたメッセージの送信は、ブラウザが直接行うわけではありません。ブラウザはネットワークにメッセージを送信する機能がないため、OSにメッセージの送信を依頼します。私たちが宅配便を送るとき、直接送るのではなく既にサービスが提供されている宅配便システム（宅配便会社）を利用して送るのと同じです。ただし、送信をOSに依頼する際には、ドメイン名ではなくIPアドレスでメッセージを受信する相手を指定する必要があります。このプロセスでDNSサーバーを検索する必要があります。
in プロトコルスタック、LANアダプター
- プロトコルスタック（オペレーティングシステムに内蔵されたネットワーク制御用ソフトウェア）は、ブラウザからメッセージを受け取ります。
- ブラウザから受信したメッセージをパケットに保存します。
- そして、受信先アドレスなどの制御情報を付加します。
- その後、パケットをLANアダプターに渡します。
- LANアダプターは次のHopのMACアドレスを付加したフレームを電気信号に変換します。
- 信号をLANケーブルに送信します。
プロトコルスタックは、通信中にエラーが発生した場合、この制御情報を使用して修正して送信するか、各種の状況を調整するなど、さまざまな役割を担います。ネットワークの世界では、私たちが秘書に荷物を渡すように、秘書が宛先や注意事項を書いてくれるように、プロトコルスタックが秘書の役割を担っていると見なすことができます。
in ハブ、スイッチ、ルーター
- LANアダプターが送信したフレームは、スイッチングハブを経由してインターネット接続用ルーターに到達します。
- ルーターはパケットをプロバイダ（通信会社）に転送します。
- インターネットに入ります。
in アクセス回線, プロバイダー
- パケットは、インターネットの入り口にあるアクセス回線(通信回線)によってPOP(Point Of Presence, 通信事業者用ルータ)まで運ばれる。
- POPを経由して、インターネットの中核部に入ることになる。
- 数多くの高速ルーターの間をパケットが目的地に向かって流れていく。
in ファイアウォール、キャッシュサーバー
- パケットはインターネットの中核部を通過して、Webサーバー側のLANに到着する。
- 待ち構えていたファイアウォールが到着したパケットを検査する。
- パケットがWebサーバーまで行く必要があるか、行かなくても良いかを判断するキャッシュサーバーが存在する。
必要ない場合は除外される。アクセスしたページのデータがキャッシュサーバーにある場合、Webサーバーに依頼することなく、直接その値を読むことができる。ページのデータの中で再利用できるものがあれば、キャッシュサーバーに保存される。
in Webサーバー
- パケットが物理的なWebサーバーに到着すると、Webサーバーのプロトコルスタックはパケットを抽出してメッセージを復元し、Webサーバーアプリケーションに渡す。
- メッセージを受け取ったWebサーバーアプリケーションは、要求メッセージに応じたデータを応答メッセージに入れて、クライアントに返送する。
- 元の方法で、応答メッセージがクライアントに転送される。
Comments