読書研修ーWebを支える技術　第６章HTTPの基本

## HTTPの重要性
HTTP はRFC2616で規定されたプロトコルです。
コンピュータで扱えるデータであれば何でも転送できます。
>HTTPはRESTの重要な特徵である統一インタフエース、ステートレスサーバ、キャッシュなどを実現している、Webの基盤となるプロトコルです。

## TCP/IPとは何か
TCP(Transmission Control Protocol)とIP(Internet Protocol)は、インターネットの基盤（ベース）を構成する重要なネットワークプロトコルです。
#### 階層型プロトコル
| 層 |担当 | プロトコル |
|:-:|:-:|:-:|
|  アプリケーション層| 具体的なインターネットアプリケーション、たとえばメールそしてHTTPを実現 ①| HTTP、NTP、SSH、SMTP、DNS  |
| トランスポート層  | IPが保証しなかったデータの転送を保証する  |  UDP、TCP ①|
|  インターネット層 | ネットワークでデータを実際にやりとりする部分  |  IP ②|
| ネットワークインタフェース層  |  物理的なケ-プルやネットワークアダプタに相当する部分 | イーサネツト  |

①TCPでプログラムを作るときは、ソケット(Socket)と呼ばれるライプラリを使って、ソケットはネットワークでのデータのやりとりを抽象化したAPIで、接続、送信、受信、切断などの基本的な機能を備える。

②IPではデータの基本的な通信単位を「パケット」(Packet)と呼びます。指定したIPアドレスを送り先として、パケット単位でデータをやりとりして通信



## HTTPのバ-ジョン
|バージョン| 特徴 |具体＆変更|
|:-:|:-:|:--|
| HTTP 0.9  | HTTPの誕生  |URLで特定されるHTMLを取得するだけ|
| HTTP 1.0| HTTP最初の標準化  |HTTP1.1につなかる基本的な要素か盛り込まれ へッダの導入、GET以外のメソッドの追加なと|
|  HTTP1.1 |  HTTPの完成 |HTTP1.0の機能に加え,チャンク転送、Acceptへッダによるコンテントネゴシエ-ション、複雑なキャツシュコントロール、持続的接続などの機能を追加|
|HTTP/2| 2015年 |テキストベースからバイナリベースへ、ストリームを使ったデータ送受信、サーバープッシュ、ヘッダの圧縮|
|HTTP/3| 2018年 |QUICと呼ばれるUDPソケットを用いたプロトコルの上で動作するなど|
	
## クライアントとサーバ
>クライアント(Webブラウザ)が情報を提供するサーバ(Webサーバ)に接続し、各種のリクエスト(Request、要求)を出してレスポンス(Response、返答)を受け取ります。
## リクエストとレスポンス
#### リクエストノレスポンス型(Request-Response Style)のプロトコル
HTTPではクライアントが出したリクエストをサーバで処理してレスポンスを返します。HTTPが同期型(Synchronous)のプロトコルであるため、サーバでの処理に時間がかかる場合でも、リクエストを出したクライアントはレスポンスが返るまで待機する。
#### クライアントで行われること
1つのリクエストを送信しレスポンスを受信する際に
①リクエストメッセージの構築
②リクエストメッセージの送信
③(レスポンスが返るまで待機)
④レスポンスメッセージの受信
⑤レスポンスメッセージの解析

#### サーバで行われること
クライアントからリクエストを受けたサーバは

①(リクエストの待機)
②リクエストメッセージの受信
③リクエストメッセージの解析
④適切なアプリケーションプログラムへの処理の委譲
⑤アプリケーションプログラムから結果を取得
⑥レスポンスメッセージの構築
⑦レスボンスメッセージの送信（クライアントへ返信）

## HTTPメッセージ	
#### HTTPメッセージの構成要素
| HTTPメッセージの構造|
|:-:|
|スタートライン   |
| へツダ  |
| 空行  |
| ポディ  |
### リクエストメッセージ
```
<メソッド><空白><URL><空白><HTTPバージョン>    ……①
<フィールド名>:<フィールド値>  ……②
……
<空白行>
<ボディ>  ……③
```
#### ①リクエストライン
リクエストメッセージ１行目で、メゾット（GETなど)、リクエストURI（相対URI・絶対URIもok)、プロトコルバージョン（HTTP/3など）
#### ②へッダ
２行目以降：メッセージのメタデータです、複数OK
「名前：値」という構成
#### ③ボディ
そのメッセージを表す本質的な情報が入る

### レスポンスメッセージ
```
<HTTPバージョン><空白><ステータスコード><空白><レスポンスフレーズ>   ……①
<フィールド名>:<フィールド値>②
……
<空白行>
<ボディ>   ……③
```

#### ①ステータスライン
Status Line:
プロトコルバージョン（HTTP/1.1など）
ステータスコード（200は成功）
レスポンスフレーズ(OKなど）
#### ②へッダ
２行目以降：メッセージのメタデータです、複数OK
「名前：値」という構成
リクエストメッセージのヘッダと同じく
#### ③ボディ
空行でヘッダと区切り
htmlとかの情報

## HTTPのステートレス性
| | やりとり | 具体 |
|:-:|:-:|:-:|
|  ステートフル |  簡潔 |  サーバがクライアントのそれまでの注文を覚えている|
|  ステートレス | 冗長  | クライアントは毎回すべての注文を繰り返している  |


### アプリケーション状態
<strong> セッション</strong>：システムにログインしてからログアウトするまでの一連の操作をまとめてること
<strong> アプリケーション状態（セッション状態）</strong>：この一連の操作の間の状態
ステートフルなプロトコルの代表例：<strong> FTP</strong>
>FTPではクライアントがFTPサーバにログインしてからログアウトするまで、そのクライアントがどのディレクトリにいるかといったアプリケーション状態をサーバが管理します。そのためクライアントは、ディレクトリの移動などで相対パスを指定できます。</dd>

| | 利点 | 欠点 |
|:-:|:--|:--|
|  ステートフル |  やりとり簡潔 | クライアントの数が増えた場合にスケールアウトさせにくくなる①|
|  ステートレス | クライアントが増えてきたら、単純にサーバを増設すればよい ②| <strong>パフオーマンスの低下</strong><br>・送信するデータ量が多くなる<br>・認証など、サーバに負荷がかかる処理を繰り返す <br> <strong>通信エラーへの対処</strong><br> ネットワークトラブルが起きたとき、そのリクエストが処理されたかどうかわからない|

①1つのサーバが同時に相手をできるクライアントの数には上限があるので、複数のサーバ間でアプリケーション状態を同期して、どのサーバでも同じアプリケ-ション状態を扱えるようにしなければなりません。しかし、もし多くのサーバと増えていくと、データを同期するオーバーへッドが無視できない。

②サーバがクライアントのアプリケーション状態を覚える代わりに、クライアントが自らのアプリケーション状態を覚え、すべてのリクエストを自己記述的メッセージで送信するので、単純にサーバを増設すればよい




## シンプルなプロトコルの強み
１．HTTPのシンプルさのかけで、ブラウザはPC、スマホなど様々なデバイス上でも実装される。
２．WebサービスとWebAPIが同じプロトコルで実現できる。