HTTP

HTTP (HyperText Transfer Protocol)

すべてのコンテンツをHTTPメッセージに送信

HTML, TEXT

画像、音声、ビデオ、ファイル

JSON, XML(API)

は、ほぼ任意の形態のデータ

を伝送することができる.

サーバ間でデータ交換を行う場合、ほとんどがHTTP

を使用する.

HTTP履歴

HTTP/0.91991年:GETメソッドのみサポート、HTTPヘッダX

HTTP/1.01996年:メソッド、ヘッダー

を追加

HTTP/1.1 1997年:使用量が最大で、私たちにとって最も重要なバージョンです.

RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)

HTTP/2015年:性能改善

HTTP/3は現在進行中:TCPの代わりにUDPを使用し、性能向上

ベース・プロトコル

TCP : HTTP/1.1, HTTP/2

UDP : HTTP/3

現在の傾向はHTTP/1.1を使用することである.HTTP/2 HTTP/3も徐々に増加しています

HTTP特性

1.クライアントサーバ構造

リクエスト応答構造を有する.

クライアントは、要求をサーバに送信し、応答を待つ.

サーバは、要求の結果を生成し、応答する.

意味「いみ」
クライアントサーバ構造では、サーバはビジネスロジックとデータを別々に管理し、クライアントはUIと可用性を向上させるタスクを別々に管理します.サーバとクライアントとは独立した管理の利点があり、各ターゲットの機能のみがアップグレードされます.

2.ステータス・プロトコルなし

ステータスなし
サーバがクライアントのステータスを保持しないフィーチャーを指します.サーバの拡張性(横方向の拡張性)は高い利点がありますが、クライアントが追加のデータを転送する必要があるという欠点があります.

🤔静的差異

ステータス保持の例

고객 : 이 노트북 얼마인가요?
점원 : 100만원 입니다. (노트북 상태 유지)
고객 : 2개 구매하겠습니다.
점원 : 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? (노트북, 2개 상태유지)
고객 : 신용카드로 구매하겠습니다.
점원 : 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태유지)

ステータス保持(Stateful)-店員が途中で変わったら?

고객 : 이 노트북 얼마인가요?
점원A : 100만원 입니다.
고객 : 2개 구매하겠습니다.
점원B : ??? 무엇을 2개 구매하시는건가요?
고객 : 신용카드로 구매하겠습니다.
점원C : ???무슨 제품을 몇개, 신용카드로 구매하시는건가요?

ステータス例なし

고객 : 이 노트북 얼마인가요?
점원 : 100만원 입니다.
고객 : 노트북 2개 구매하겠습니다
점원 : 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매하시겠어요?
고객 : 노크북 2개를 신용카드로 구매하겠습니다.
점원 : 200만원 결제 완료되었습니다.

ステータスレス(Stateless)-店員が途中で変わったら?

고객 : 이 노트북 얼마인가요?
점원A : 100만원 입니다.
고객 : 노트북 2개 구매하겠습니다
점원B : 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매하시겠어요?
고객 : 노크북 2개를 신용카드로 구매하겠습니다.
점원C : 200만원 결제 완료되었습니다.

≪ステータスなし|No Status|emdw≫:中間は他のサーバに変更できます.クライアント要求が突然増加しても、サーバを増設できます.
ステータスなしで応答サーバを簡単に変更できます->無限に増加するサーバ
また、サーバ1に障害が発生しても、サービスを提供することができる.


無状態限界

すべてのものを無状態に設計できる場合もあれば、ない場合もあります.
ex)ログイン不要の簡易サービスログイン画面

ログインユーザは、サーバ上でログイン状態を保持する必要がある

.

は、通常、ブラウザCookieやサーバセッションなどを使用して

を維持する.
最低使用

状態

無状態の特性は、クライアントが送信する必要があるデータがますます多くなることである.

3.非接続性

特長

HTTPは

のデフォルト非接続機種です

は、一般に、秒未満の速度で

に応答する.

1時間以内に数千人がサービスを利用しても、実際のサーバが同時に処理する要求は数十個を超えず、小さく、ex)Webブラウザで検索ボタンを連続的に押すことはありません.

サーバリソースが非常に効率的
欠点

TCP/IP接続を再確立する必要がある-3ウェイの握手時間

を増やす

Webブラウザを使用してサイトを要求すると、HTML、JavaScript、CSS、その他の画像など、多くのリソースが同時にダウンロードされます.

現在、HTTP永続接続により問題を解決する

HTTP/2、HTTP/3でさらに最適化

接続を保持するモデル
クライアント2と3の欠点は、遊んでいても接続を維持することです.

接続を保持しないモデル
リクエストとレスポンスが終了すると接続が終了します.最小限のリソースを保持

🙋‍♀️スティーブンを覚えて

サーバ開発者の課題

が実際に同じ時間に発生する高容量流量

ex)前後順に活動し、祝日KTX予約、学部登録

4.HTTPメッセージ

開始行とヘッダ後空行(CRLF)後にHTMLコンテンツがBodyに入る

📑要求メッセージのフォーマット

start-line = request-line/status-line
request-line=メソッドSP(空白)request-target SP(空白)HTTPバージョンCRLF(エンタープライズ)
方法(HTTP要求方法)

サーバが実行すべき動作

を指定する.

タイプ:GET(リソース照会)、POST(リクエスト履歴処理)、PUT、DELETE...

リクエストターゲット

absolute-path ?query

絶対パス="/"先頭のゴン儒

HTTPバージョン(HTTPバージョン)

HTTP Version

📑レスポンスメッセージの形式

start-line = request-line/status-line
status-line=HTTPバージョンSP(空白)status-code SP(空白)原因-フレーズCRLF(企業)
HTTPバージョン(HTTPバージョン)

HTTP Version

status-コード(ステータスコード)

要求成功、表示失敗

200:成功

400:クライアント要求エラー

500:サーバ内部エラー

理由フレーズ

人が理解できる短いステータスコード説明文

HTTPヘッダ

header-field-field-name":"OWS field-value OWS(OWS:書き込み可能)
field-nameには大文字と小文字の構文がありません
タイトルの用途

HTTP伝送に必要な全ての付加情報

ex)メッセージ本体の内容、メッセージ本体のサイズ、圧縮、検証、要求クライアント(ブラウザ)情報、サーバアプリケーション情報、キャッシュ管理情報...

ヘッダーが多すぎる

必要に応じて任意のヘッダー

を追加することができる.

HTTPメッセージ本体

実際に転送するデータ
HTMLドキュメント、画像、ビデオJSONなど、バイトで表示できるすべてのデータ.

🎫整理する

HTTPは簡単です.specを読んでもいいです...

HTTPメッセージも非常に簡単です

標準技術

は大きな成功を収めたが、技術は高度に拡張可能である.