【イラスト図解式 この一冊で全部わかる Web技術の基本】 「3-11.HTTPSのやりとり」を読んで
0.はじめに
このブログをWordPressで運営するために、現在移行作業中です!
想定より時間がかかりそうなので、移行作業が終わるまではこちらで更新します。
移行が正式に完了しましたら、またお知らせします。
【イラスト図解式 この一冊で全部わかる Web技術の基本】
「3-11.HTTPSのやりとり」を読んで
「イラスト図解式 この一冊で全部わかる Web技術の基本」の第3章11節についての要点、自分なりの知識の整理の2点を述べていきます。
1.要点
HTTPSによって、Webサイトを閲覧するうえで危険になる盗聴、改ざん、なりすましを防げる
HTTPSで通信するときの流れをSSL/TLSハンドシェイクという
2.知識の整理
昨日の内容と重複しますが、再掲します!
<SSL/TLSハンドシェイクが成立するまでの流れ>
①SSL通信リクエストの送信(ブラウザ→サーバー)
②SSL証明書の送付(サーバー→ブラウザ)
③電子署名の検証により「SSL証明書に記載されたドメイン」と「通信先のドメイン」が同じであることを確認する(ブラウザ)
④SSL通信を行うために共通鍵を交換する(ブラウザ、サーバー)
⑤共通鍵を用いて送受信するデータを暗号化・復号化してSSL通信成立(ブラウザ、サーバー)
※SSL証明書とは、SSL通信をするときに使うサーバーの身元を保証する電子保証書。実印のようなもの。
※復号化とは、暗号をもとの状態に戻すこと
えっ、、昨日とまったく同じ内容じゃないか〜〜〜〜
わかりやすくもう少し簡単に、自分の言葉で置き換えてまとめてみます。
①どんな暗号にするか決める(ブラウザ→サーバー)
②サーバーの情報を教える(サーバー→ブラウザ)
③受け取った②の情報を確認する(ブラウザ)
(※ここでOKであれば④へ、NGであればブラウザに警告表示が出る)
④暗号化したやりとりを行うために必要な「共通鍵」をお互い交換する(ブラウザ、サーバー)
⑤暗号化通信を行う
こうやって自分の言葉でまとめると、理解度も高まる気がします。
ただ、わかりやすさを重視するあまり、表現によって意味まで変わることも起こるので、そこは気をつけたいですね。
あくまでも、「正確に」理解することが前提ということを忘れずにまとめていきます。
(この分野はやはり少し難しくてまだまだ理解不足な印象です。)
次回はステートフルとステートレスについてまとめます!
ご意見やご指摘、感想などコメントでお待ちしています!
最後まで読んでいただき、ありがとうございました!
【出典】
イラスト図解式 この一冊で全部わかるWeb技術の基本
SSL-MDN Web Docs
TLS-MDN Web Docs
【図解】SSL/TLSとは何か?その違いや仕組み・導入方法についてわかりやすく解説します
【イラスト図解式 この一冊で全部わかる Web技術の基本】 「3-10.HTTPSの仕組み」を読んで
0.はじめに
このブログをWordPressで運営するために、現在移行作業中です!
想定より時間がかかりそうなので、移行作業が終わるまではこちらで更新します。
移行が正式に完了しましたら、またお知らせします。
【イラスト図解式 この一冊で全部わかる Web技術の基本】
「3-10.HTTPSの仕組み」を読んで
「イラスト図解式 この一冊で全部わかる Web技術の基本」の第3章10節についての要点、自分なりの知識の整理の2点を述べていきます。
1.要点
HTTPSとは
盗聴や改ざん、なりすましを防ぐためのしくみがHTTPS
HTTP over SSL/TLSの略 (※SSL/TLSの「/」はorの意)
SSL(Secure Sockets Layer)とTLS(Transport Layer Security)は暗号化方式のプロトコルのこと
2.知識の整理
- 2つの暗号化方式について深掘り(なんで2つあるの?2つの違いはある?)
<気になった理由>
SSLとTLSの暗号化方式の違いについて知りたかったため
【結論】
両者の機能のはっきりとした違いはない(名称変更くらい)
元々はSSLだったが置き換えられ、現在はTLSの機能メイン
(SSLの後継者がTLS)
IETF(インターネット技術の標準化を推進する任意団体)にRFC2246として標準化される際に、SSLから名称を変更してTLSと呼ばれるようになりました。
ただ、現在でも「SSL/TLS」と呼称されたり「SSLサーバ証明書」などのように「TLS」を省いて呼称されたりすることもあります。
SSLについて
SSLとは
・1994年に開発
・送受信するデータを暗号化する通信プロトコル
・ブラウザのURLが「https〜」から始まるもの、ブラウザの入力欄の横に鍵マークがついているものはSSL化されている
<SSL通信が成立するまでの流れ>
①SSL通信リクエストの送信(ブラウザ→サーバー)
②SSL証明書の送付(サーバー→ブラウザ)
③電子署名の検証により「SSL証明書に記載されたドメイン」と「通信先のドメイン」が同じであることを確認する(ブラウザ)
④SSL通信を行うために共通鍵を交換する(ブラウザ、サーバー)
⑤共通鍵を用いて送受信するデータを暗号化・復号化してSSL通信成立(ブラウザ、サーバー)
※SSL証明書とは、SSL通信をするときに使うサーバーの身元を保証する電子保証書。実印のようなもの。
※復号化とは、暗号をもとの状態に戻すこと
このようにして、サーバーとブラウザでは安全にやりとりがなされています。
個人的にですが、コロナ禍でネットで買い物をして、クレジットカードや住所などの個人情報を入力する機会がすごく増えたので、しくみを知ることは勉強になりました。
明日はHTTPSのやりとりについてもう少し深掘りします!
ご意見やご指摘、感想などコメントでお待ちしています!
最後まで読んでいただき、ありがとうございました!
【出典】
イラスト図解式 この一冊で全部わかるWeb技術の基本
SSL-MDN Web Docs
TLS-MDN Web Docs
【図解】SSL/TLSとは何か?その違いや仕組み・導入方法についてわかりやすく解説します
SSLって何?意味や仕組みをわかりやすく解説!
【イラスト図解式 この一冊で全部わかる Web技術の基本】 「3-9.HTTP/2の改良点」を読んで
【イラスト図解式 この一冊で全部わかる Web技術の基本】
「3-9.HTTP/2の改良点」を読んで
「イラスト図解式 この一冊で全部わかる Web技術の基本」の第3章9節についての要点、自分なりの知識の整理の2点を述べていきます。
1.要点
○バイナリ形式の利用
HTTPリクエストとHTTPレスポンスのやりとりの形式が変わった
【HTTP/1.1以前】
テキスト形式
(バイナリ形式→テキスト形式に変換されたもの)
【HTTP/2】
バイナリ形式(変換なし)
○ヘッダー圧縮
転送するファイルのデータに加え、ヘッダーの容量も軽くなった
【HTTP/1.1以前】
ファイルのデータ
【HTTP/2】
ファイルのデータ+ヘッダー
(重複する部分が多いので、差分のみ転送するHPACK形式を採用)
○サーバープッシュ
Webサーバーもファイルの転送の判断ができる
【HTTP/1.1以前】
ブラウザ側からのリクエストがなければWebサーバーはレスポンスを送らない
【HTTP/2】
リクエストを受け、Webサーバーが必要なファイルを判断して事前にブラウザに送る
2.知識の整理
- HTTP/2の課題
- HTTP/3について
<気になった理由>
・HTTP/2の課題と新しいHTTP/3がどういうものか気になったから
・本書は2017年に出版されたもので、最新の情報が知りたかったため
<HTTP/2の課題>
【ざっくり】
使用されているTCPは順番通りに届く信頼性が保たれているが、データ容量が大きく、通信速度が遅くなるトラブルも多い
細かく見ていくと、
※パケットロス…小分けにした通信内容の一部または全てが通信先に正常に届かず、消滅してしまうこと。
主な原因は、ネットワーク上で処理可能な量を上回るパケットが流れていること、ネットワークの混雑、通信途中や通信先のトラブル、がある。
これらの課題を解消するために、以下のようにHTTP/3では改良されました。
<HTTP/3について>
新しいプロトコルである「QUIC」を開発
<QUICとは>
・開発を始めたのはGoogle
・IETF(Internet Engineering Task Force、インターネット技術の標準化を推進する任意団体)が標準化を進めている
全体的にUDPをもとにして、TCPのような信頼性を持った、より高速な通信をしていく
<QUICの特徴>
すでにGoogle Chromeを利用する25%以上でHTTP/3が自動的に使われているそうです。
先月、QUICの標準化が正式に承認されたため、HTTP/3が標準化されるのももうすぐではないでしょうか。わくわく!
明日はHTTPSの仕組みについてまとめます!
ご意見やご指摘、感想などコメントでお待ちしています!
最後まで読んでいただき、ありがとうございました!
【出典】
イラスト図解式 この一冊で全部わかるWeb技術の基本
HTTP/3-MDN Web Docs
HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(前編)
HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(後編)
Google生まれの高速プロトコル「QUIC」、IETFが標準として承認。Webやビデオチャットの高速化が期待
HTTP/3が必要な理由
【イラスト図解式 この一冊で全部わかる Web技術の基本】 「3-8.HTTP/2のやりとり」を読んで
【イラスト図解式 この一冊で全部わかる Web技術の基本】
「3-8.HTTP/2のやりとり」を読んで
「イラスト図解式 この一冊で全部わかる Web技術の基本」の第3章8節についての要点、自分なりの知識の整理の2点を述べていきます。
1.要点
HTTP/2はGoogleが提案した通信の高速化を目的としたSPDY(スピーディー)というプロトコルを使用
ストリームによる多重化
※ストリームとは
HTTPリクエスト(以下リクエスト)からHTTPレスポンス(以下レスポンス)までの一連のやりとり
仮想的な通信経路
HTTP/2はひとつのTCPコネクションにストリームを複数形成して、リクエストとレスポンスをやりとりできる
→レスポンスの待ち時間がなくなり、通信がより高速化
2.知識の整理
- なぜHTTP/2に改良されたのか?
<気になった理由>
・HTTP/1.1の課題とHTTP/2のメリットがわかるから
・HTTP/1.1という16年も使ってきたバージョンを変えるとは、よほど何かすごいことがなされているのでは!?と思ったので…(好奇心)(ほかのバージョンは数年単位で変わっている)
【結論】基本的なしくみは従来と変わらないが、転送手段が新しくなった
HTTP/2は「より少ない通信量」「よりWebコンテンツの読み込みを高速化」がポイントになります。
HTTP/2について知る前に、本書で出てきたSPDYについて調べてみました。
SPDYとは
・Googleが開発したプロトコル
・目的はWebのコンテンツの読み込みの高速化
・最終的にHTTP/2が吸収
▽以下の課題をプロトコルレベルで解決
・1回のコネクションにつき1つのリクエストしか送れない
・リクエストがクライアント(ブラウザ)からしか開始できない
・リクエスト/レスポンスヘッダーが非圧縮のためヘッダーサイズが大きい
・ヘッダーが長い
・データ圧縮の使用が強制ではない
<なぜHTTP/2が必要だったのか>
上記の課題を解決したかったため
HTTP1.0では、1つのリクエストが完了するまで、次のリクエストを送ることができませんでした。
HTTP/1.1では、ブラウザが複数のリクエストを同時に送れるようになりました。
しかし、レスポンスはリクエストされた順番を忠実に守って送られます。
つまり、データの容量が大きいとき、読み込みが遅いファイルがあるとき、通信に時間がかかってしまう状況に陥ってしまうのです。(むずかしい)
HTTP/2の登場により、これらの課題が網羅的に解決されていきます。
ストリームの登場により、リクエスト処理の時間が短縮できるようになりました。
ストリーム単位でやりとりされるので、シンプルかつスピーディーな通信ができるようになるんですね。
HTTP/1.1で抱えていた課題が解決されました。(やったね)
明日はHTTP/2の改良点についてもう少し深掘りしてまとめます!
ご意見やご指摘、感想などコメントでお待ちしています!
最後まで読んでいただき、ありがとうございました!
【出典】
イラスト図解式 この一冊で全部わかるWeb技術の基本
HTTP/2-MDN Web Docs
普及が進む「HTTP/2」の仕組みとメリットとは
SPDY: An experimental protocol for a faster web- The Chromium Projects
「HTTP/2」がついに登場! 開発者が知っておきたい通信の仕組み・新機能・導入方法
【イラスト図解式 この一冊で全部わかる Web技術の基本】 「3-7.HTTP/1.1のやりとり」を読んで
【イラスト図解式 この一冊で全部わかる Web技術の基本】
「3-7.HTTP/1.1のやりとり」を読んで
「イラスト図解式 この一冊で全部わかる Web技術の基本」の第3章7節についての要点、自分なりの知識の整理の2点を述べていきます。
1.要点
HTTPはHTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2と変遷してきた
<HTTP/1.1からの特徴>
◯HTTPキープアライブ
【HTTP/1.0以前】
・ブラウザ→Webサーバーのリクエスト送信のたびにTCPコネクション(以下、コネクション)確立
・Webサーバー→ブラウザのレスポンス送信のたびにコネクション切断
【HTTP/1.1】
・コネクションの確立と切断は最初と最後だけ
◯HTTPパイプライン
【HTTP/1.0以前】
・次のリクエストは前のリクエストに対するレスポンスが返ってきた後じゃなければ送ることができない
【HTTP/1.1】
・レスポンスを待たずにリクエストを送れる
2.知識の整理
- HTTPのバージョンの変遷
<気になった理由>
・バージョンを更新するのには何かしらの理由(HTTP/1.0以前の課題)があると考えたから
・現在はバージョンアップしてHTTP/2が主流であることより、HTTP/1.1にも課題があると考えたから
<HTTPのバージョンの歴史>
1991年 HTTP/0.9
・GETメソッド方式
・HTMLファイルのみ転送
1996年 HTTP/1.0
・ブラウザでステータスコードの表示
・HTMLファイル+画像ファイルの転送
1999年 HTTP/1.1
・パイプラインにより通信の遅延を抑制
・バーチャルホストの搭載
・HTTPキープアライブ
2015年 HTTP/2
・複数のリクエストが同時に処理可能
・ヘッダーの圧縮
・転送コンテンツの優先度設定
2020年 HTTP/3(※標準化→実用段階のうち、現在は標準化段階)
・UDPでの通信(HTTP/2まではTCP)
・リクエストを再送中でも他のパケットが処理可能
名前も取り組みも異なりますが、一貫しているのはWebページのコンテンツが複雑化した状況に合わせて、表示速度の改善が行われていきました。
課題が見つかるとその都度改良し、バージョン更新を行っています。
3.おまけ
これからもっと変遷していくのでしょうが、発展していく想像がつきません!!!!(笑)
明日はHTTP/2のやりとりについてまとめます!
ご意見やご指摘、感想などコメントでお待ちしています!
最後まで読んでいただき、ありがとうございました!
【出典】
イラスト図解式 この一冊で全部わかるWeb技術の基本
HTTP の進化-MDN Web Docs
Keep-Alive -MDN Web Docs
【図解】HTTP/2って?HTTP/1.1との違いと導入メリット・課題まとめ
【イラスト図解式 この一冊で全部わかる Web技術の基本】 「3-6.TCPによるデータ通信」を読んで
【イラスト図解式 この一冊で全部わかる Web技術の基本】
「3-6.TCPによるデータ通信」を読んで
「イラスト図解式 この一冊で全部わかる Web技術の基本」の第3章6節についての要点、自分なりの知識の整理の2点を述べていきます。
1.要点
Webサイト閲覧の流れ(HTTPリクエストとHTTPレスポンス)でHTTPのデータのやりとりを行うのはTCP(Transmission Control Protocol)の役割
<TCPが行うこと>
ブラウザとWebサーバー間のコネクションを確立すること
→TCPが通信コネクションの接続を行うことで、Webサイトが閲覧できる
3ウェイハンドシェイクとは
コネクションが確立できるまでに3回やりとりが必要
<3ウェイハンドシェイク>
1.SYNパケット(ブラウザ→Webサーバー)
2.SYNパケット+ACKパケット(Webサーバー→ブラウザ)
3.ACKパケット(ブラウザ→Webサーバー)
2.知識の整理
- TCP設計の歴史
<気になった理由>
設計に至るまでの背景を知ることで、TCPが必要な理由がわかるから
TCPについては以前の記事でも扱っていました!
トランスポート層でTCP(or UDP)で通信方法を確立してから、アプリケーション層でデータのやりとりが行われるんでしたね。
○設計の背景
異なるネットワークどうしでも接続できるようにしたかった
TCPは、1970年代にDARPA研究者のヴィントン・サーフとボブ・カーンによって共同設計されたものです。
1969年に「ARPANET(アルパネット)」(TCPの前身)という通信ネットワークが開発されます。
これは、4つの拠点を電話回線を用いて、IMP(ルーターの前身)という機器を繋ぎ、ネットワーク通信を確立するものです。
これは、世界で初めて運用されたパケット通信コンピュータネットワークであり、インターネットの起源とも言われています。
しかし、のちのシステム故障をきっかけに、ARPANETは異なるネットワークどうしの通信ができないことが判明しました。
「ゲートウェイ」の登場
ARPANETは同じネットワーク同士の通信ということもあり、直接ホストにパケットを送っていました。
そこで、ボブ・カーンが「ゲートウェイ」にパケットを送ることを考えます。
<「ゲートウェイ」の役割>
①異なるネットワークの違いを吸収する
②送られてきたパケット(データを小分けにしたもの)を中継する
③相手のコンピューターに送信
これがTCPの原型になります。
- TCPの具体的な役割
<気になった理由>
本書を読んだ状態で、まだTCPの役割が理解できなかったため
①「セッション指向」のサービスの提供
セッション指向とは、あらかじめ2台のコンピューター間で通信回線を確立してから相互に通信する方式のことです。
電話のように、最初にダイヤルして相手に接続してから通信する形態のサービスです。
②「信頼性のある通信」
信頼性のある通信とは、送信したデータが正しく相手に届くことが保証され、何らかの理由で送信が失敗した場合には自動的に再送信するなどするように、確実に相手にデータを届ける通信のことです。
③フロー制御やウィンドウ制御などのサポート
通信経路が混んでいる場合は送信量を抑えたり、逆に空いている場合はまとめて送信して送信効率を上げたりする働きをします。
TCPのおかげで、現代では安定した通信が保証されていることがわかりました。
TCPさまさまですよね。
明日はHTTP/1.1のやりとりについてまとめます!
ご意見やご指摘、感想などコメントでお待ちしています!
最後まで読んでいただき、ありがとうございました!
【出典】
イラスト図解式 この一冊で全部わかるWeb技術の基本
TCP/IPをわかりやすく - 通信プロトコルの基礎知識を図解で学ぼう
TCP/IP を発明したビントン・サーフ氏の功績
第6回 TCP/IPの概要
TCP -MDN Web Docs
【イラスト図解式 この一冊で全部わかる Web技術の基本】 「3-5.メッセージヘッダー」を読んで
【イラスト図解式 この一冊で全部わかる Web技術の基本】
「3-5.メッセージヘッダー」を読んで
「イラスト図解式 この一冊で全部わかる Web技術の基本」の第3章5節についての要点、自分なりの知識の整理の2点を述べていきます。
1.要点
メッセージヘッダーとは
HTTPメッセージに関する詳細な情報
HTTPリクエストとHTTPレスポンスで利用
<主な種類>
・一般ヘッダーフィールド
HTTPリクエストとHTTPレスポンス両方に含まれる
例)Date(HTTPメッセージが作成された日付)
・リクエストヘッダーリクエスト(リクエストメッセージ)
HTTPリクエストのみ
例)User Agent(ブラウザの固有情報、バージョンやプロダクト名)
・レスポンスヘッダーリクエスト(レスポンスメッセージ)
HTTPレスポンスのみ
例)Server(Webサーバー機能を提供するプロダクト情報)
・エンティティヘッダーフィールド
HTTPリクエストとHTTPレスポンス両方
例)Content-Type(データの種類)
2.知識の整理
以下、気になったこと2点をまとめていきます!
- メッセージヘッダーの構造とそれぞれの役割
- 代表的なヘッダーフィールドリスト
- メッセージヘッダーの構造
HTTPリクエスト、HTTPレスポンスの構造はこのようになっています。
メッセージヘッダーの中に結構な量の情報が格納されているんですね。
ちなみに、以前こちらの記事で詳しく述べていました。
おさらいすると、
<HTTPリクエスト>
○メッセージヘッダー
ブラウザの種類、対応するデータの種類、データ圧縮方法、言語などの情報の記述
1.Request headers(リクエストヘッダーフィールド)
指定するとリクエストを変更するもの (Accept-languageなど)、状況を示すもの、条件を与えるもの
2.General headers(一般ヘッダーフィールド)
メッセージ全体に適用されるもの
3.Entity headers(エンティティヘッダーフィールド)
リクエスト本体に適用されるもの
<HTTPレスポンス>
○メッセージヘッダー
Webサーバーのソフトウェア情報、返信するデータの種類、データ圧縮方法などの情報の記述
1.Response headers(レスポンスヘッダーフィールド)
ステータス行で伝えられないサーバーの追加情報
2.General headers(一般ヘッダーフィールド)
メッセージ全体に適用されるもの
3.Entity headers(エンティティヘッダーフィールド)
レスポンス本体に適用されるもの
- 代表的なヘッダーフィールドリスト(□で囲んだところはよく使うもの)
実際のところどう映っているのかを知りたかったので、デベロッパーツールで調べてみました。
今まで「よくわからない文字の羅列」だったのが、全部とはいかないですが、調べながらだと解読できそうな気がしてきました。
明日はTCPによるデータ通信についてまとめます。
ご意見やご指摘、感想などコメントでお待ちしています!
最後まで読んでいただき、ありがとうございました!
【出典】
イラスト図解式 この一冊で全部わかるWeb技術の基本
HTTP ヘッダー-MDN Web Docs
「HTTP」の仕組みをおさらいしよう(その2)