HTTPとは?


いよいよhttpです.Web通信で最も重要なhttpについて説明しましょう.

HTTPとは?


1.1 HTTPの定義


HTTPは、HTMLドキュメントを交換するために作成されたプロトコルです.HTTPを用いて通信する場合は,一方がクライアント,一方がサーバである必要がある.通常、クライアントはフロントエンド、サーバはバックエンドと呼ばれます.
以前はHTML文書を転送するプロトコルとして作成されていたが、現在ではHTML、一般的なTEXT、IMAGE、音声、ビデオ、ファイル、JSON、XMLなど、ほとんどの形式のデータを転送するために使用されている.サーバ間でデータを交換する場合でも、ほとんどが使用されます.
🔥 今はHTTP時代でも過言ではありません!!
つまり,HTTPはクライアントとサーバの役割を明確に区別することができ,ブラウザとサーバがどのようにデータを交換するかに関する通信規則である.

1.2 HTTP履歴

  • HTTP/0.91991年:GETメソッドのみをサポートし、HTTPヘッダはありません.
  • HTTP/1.01996年:メソッド、ヘッダー
  • を追加
  • HTTP/1.1 1997年:使用量が最も大きく、私たちにとって最も重要なのは
  • です.
  • HTTP/2015年:性能改善
  • HTTP/3は現在進行中:TCPの代わりにUDPを使用し、性能向上
  • 1.2.1基本契約

  • TCP : HTTP/1.1, HTTP/2
  • UDP : HTTP/3
  • 現在主にHTTP/1.1
  • を使用している
    HTTP/1.1にはかなりの機能が追加されており、2,3は性能向上に重点を置いている

    1.3 HTTPの成立要求


    HTTPリクエストとHTTPレスポンスの交換

    HTTPプロトコルを用いてデータ交換を行うためには,要求と応答が必要である.
    すなわち,クライアントから要求がない場合にはコールバックが受信され,サーバ側から要求がない場合にはコールバックが発生する.

    1.4 HTTPメッセージの構成


    1.4.1 HTTP Request Message


    まず、リクエストメッセージの例を見てみましょう.
    GET/index.html HTTP/1.1
    Host: www.navxx.com
    「GET」は、要求方法を表し、次いで、index.htmlは、要求されたリソースを表す.要求URIとも呼ばれる.
    HTTP/1.1は、HTTPのバージョン情報を表す.
    簡単に言えば、サーバ上の/indexです.これはhtmlリソースを要求する情報です.
    要求メッセージは、メソッド、URI、プロトコルバージョン、オプションの要求ヘッダフィールド、およびエンティティから構成されます.
    応答メッセージは、プロトコルバージョン、ステータスコード、ステータスコードの説明、応答ヘッダフィールド、およびマスターから構成されます.
    [Request Message]
    POST /form/entry HTTP/1.1
    HOST: hackr.jp
    Connection : keep-alive
    Content-Type : application/x-www-form-urlencoded
    Content-Length : 16
    
    name=ueno&age=37
    Request Header+空白行+Request Body
  • Header
  • 行目
  • 要求方法+要求URI+HTTPプロトコルバージョン
  • 2 2行目
  • ヘッダ情報(ヘッダ名:ヘッダ価値)
  • 空白行
  • リクエストを送信したすべてのメタデータ情報を通知します.
  • Body
  • POSTは、PUTのみが
  • 存在する.
  • リクエスト(ex.HTMLフォームラベル)
  • 1.4.2 HTTP Response Message


    [Response Message]
    HTTP /1.1 200 Ok
    Date : Tue, 10 Jul 2012 06:50:15 GMT
    Content-Length: 362
    Content-Type: text/html
    
    <html>
    ...
    応答Header+空行+応答Body
  • Header
  • 行目
  • HTTPプロトコル+レスポンスコード+レスポンスメッセージ
  • 2 2行目
  • Header情報(「Header Name:Header Value」)
  • 日付、Webサーバ名、Webサーババージョン、コンテンツタイプ、コンテンツ長、キャッシュ制御
  • 空白行(空白行)
  • リクエストを送信したすべてのメタデータ情報を通知します.
  • Body
  • 実際応答リソースデータ
  • 201、204などのステータスコードを有する応答は、通常bodyが存在しない.
  • 2.HTTPプロトコルの特徴


    2.1 stateless


    HTTPプロトコルは無状態プロトコル向け
    HTTPプロトコルは無状態プロトコルと呼ばれ、これは各データ要求が互いに独立していることを意味する.前のデータ要求は、次のデータ要求が覚えていないことを示します.
    例を挙げる.お客様がノートパソコンを購入する方法です.
    Stateful
    고객 : 이 노트북 얼마인가요?
    점원A : 100만원 입니다.
    
    고객 : 2개 구매할게요.
    점원B : 200만원 입니다. 신용카드, 현금 어떤 걸로 구매하시겠어요?
    
    고객 : 신용카드로 구매할게요.
    점원C : 200만원 결제 완료되었습니다.
    Stateful-店員が変わったら?故障状況
    고객 : 이 노트북 얼마인가요?
    점원A : 100만원 입니다.
    
    고객 : 2개 구매할게요.
    점원B : ? 무엇을 2개 구매하신다는거에요?
    
    고객 : 신용카드로 구매할게요.
    점원C : 무슨 제품을 몇개 신용카드로 구매하시겠어요?
    고객 : 이 노트북 얼마인가요?
    점원 : 100만원 입니다.(노트북 상태 유지)
    
    고객 : 2개 구매할게요.
    점원 : 200만원 입니다. 신용카드, 현금 어떤 걸로 구매하시겠어요?(노트북, 2개 상태 유지)
    
    고객 : 신용카드로 구매할게요.
    점원 : 200만원 결제 완료되었습니다.(노트북,2개, 신용카드 상태유지)
    Stateless
    고객 : 이 노트북 얼마인가요?
    점원 : 100만원 입니다.
    
    고객 : 노트북 2개 구매할게요.
    점원 : 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매하시겠어요?
    
    고객 : 노트북 2개를 신용카드로 구매하겠습니다.
    점원 : 200만원 결제 완료되었습니다.
    無状態でノートパソコンを購入しようとすると、店員が交換しても全ての情報が提供されるので問題ありませんが、店員が交換した場合、状態のあるノートパソコンが故障することは間違いありません
    片付けてください.

  • 維持状態:途中で他の店員を交換することはできません.(途中で他の店員に変更する場合は、事前に他の店員に状態情報を伝えておきます.)

  • 無状態:途中で他の店員に交換できます.
    急にお客様が増えても、店員さんを大挙投入することができます.
  • クライアント要求が突然増加しても、大量のサーバを投入することができます.
  • ステータスなしで応答サーバを簡単に変更できます->無限に拡張可能なサーバ

    図に示すように、常に同じ応答が返されるため、1つのサーバに障害が発生した場合、別のサーバにリクエストを送信することもできます.
    🚨 しかし、必ずしもメリットだけではありません.
    たとえば、ログインを必要としない簡単なサービス紹介画面では、無状態にしか設計できません.
    ログインが必要な場合は、ステータスを維持することが重要です.
    それ以外にも、データの送信が多すぎるというデメリットもあります
    時代の変化とともに無状態の特性で扱いにくいことが起こり、それを解決するために現れたのがCookieである.

    2.2非接続性


    HTTPは基本的に接続を保持しないモデルである.
  • 1時間以内に、数千人がサービスを利用しても、実際のサーバで同時に処理されるリクエストは数十個未満です.
  • 例)Webブラウザで検索ボタンを連続してクリックしない.
  • サーバリソースは、非常に効率的に使用できます.
  • この非接続性にも欠点がある.
  • TCP/IP接続(3回握手)
  • を再確立する必要がある
  • Webブラウザを使用してサイトを要求すると、HTML、JavaScript、css、画像など、多くのリソースが同時にダウンロードされます.
  • は現在、HTTP持続接続によって問題を解決しています.


  • 3.HTTP方法

  • GET:リソースを取得し、存在する特定のリソースの表示を要求し、データを受信する機能のみを有する.
  • POST:POSTメソッドは、特定のリソースにエンティティをコミットするために使用される.
  • PUT:宛先リソースの現在のすべての表示を要求負荷に変更します.
  • HEAD:HEADメソッドはGETメソッドの要求機能と同じですが、応答本文は含まれません.
  • DELETE:ファイルを削除します.
  • OPTIONS:目的のリソースを設定するための通信.
  • TRACE:TRACEメソッドは、宛先リソースのパスに基づいてメッセージループバックテストを行う.ウェブサイトをまたいで追跡するような攻撃なので、あまり使いにくいです.
  • 相互接続:主にトンネル暗号化、例えばSSLとTLSなどのプロトコルに用いられる.
  • 🕶 GET VS POST


    GETとPOSTの両方は、応答受信リソースとして機能することができる共通点を有する.しかし、通常は、リソースを受信する際にGETメソッドを使用し、リソースにエンティティをコミットする際にPOSTメソッドを使用する.理由は何ですか.
    原因を知る前に、べき乗などという言葉を理解しておきましょう.
    べき乗等則またはべき乗等性は数学または電算学における演算の1つの性質であり、演算を複数回適用しても結果は変わらない性質を意味する.
    GETはIdempotentとして設計されている.これは、同じリクエストをサーバに複数回送信しても、同じ応答を返さなければならないことを意味します.したがって,GETは設計原則に従ってサーバ上のデータや状態を変更すべきではないため,主にクエリーに用いられる.
    逆に、POSTはNon-idempotentであるため、サーバに同じ要求を複数回送信しても、応答は常に異なる場合がある.したがって、POSTは、サーバの状態またはデータを変更するために使用される.POSTによって要求されると、サーバ上のいくつかのコンテンツが変更に使用されます.
    🕶 似ているように見えますが、大きな違いがあるので、HTTP/1.1規格RFC 2616のSection 9.3の設計原則に従って、適切な用途を達成するために適切な方法を使用すべきである.🕶
    金ヨンファンの講義。をもとに書かれた文章です.