HTTPプロトコルの概要

HTTPハイパーテキスト転送プロトコル（HTTP-ハイパーテキスト転送プロトコル）、オブジェクト指向のアプリケーション層プロトコルの一部、分散ハイパーメディア情報システムのための装置の単純なので、高速な方法。それが1990年に提案され、使用および開発の数年後、継続的に改善され、拡張されました。これは、ルールは、ブラウザとWebサーバー間の相互通信の詳細であるインターネットを経由してワールド・ワイド・ウェブの、ファイル転送データ伝送プロトコルを

コンテンツ配信クライアントとサーバ間の通信パケット

HTTPは、クライアントがサーバ・メッセージ・フォーマットに送信指定する通信ルールですが、また、クライアントのメッセージ・フォーマットにサーバーを提供します。
クライアントが呼び出されたサーバーに送信する要求パケット
サーバからクライアントに送信されると呼ばれる応答パケット

HTTPプロトコルの開発プロセス

以前は、ハイパーテキスト転送プロトコルとして知られ、1960年代に提案されているザナドゥ（ザナドゥ）プロジェクト、ハイパーテキストの概念がある泰德纳尔森（テッド・ネルソン）があります。彼は、プロジェクトの研究とハイパーテキストプロトコルにコミットされていますが、情報は以前に発表されたことがありません。
1989年、ティム・バーナーズ=リー（ティム・バーナーズ=リー）CERNでのソフトウェア・コンサルタント（CERN =欧州原子核研究機構）の時間として、一連の手順を開発し、ワールド・ワイド・ウェブ（WWW =ワールド・ワイド・ウェブを築きました）基礎。
1990年12月、CERNで初めてのオンラインハイパーテキストのために。
Telnetなどのプロトコルを、以下の1991年の夏には、ハイパーテキスト転送プロトコルは、多くのインターネット・プロトコルの一部となります

その時点で、Telnetプロトコルは、1台のコンピュータと他のコンピュータとの間の制御型の通信の要件に対処します。
メール合意はスタッフに少量の情報の送信元の通信要件を解決します。
コンピュータを解決するためのファイル転送プロトコルは、別のコンピュータバッチからファイルの通信要件を取得しますが、いくつかの処理のファイル関数にファイルまたはファイルを取得しながら、それは側面を持っていません。
ニュース転送プロトコルは、多くのニュース放送の通信要件を解決します。
通信要件を解決するためにハイパーテキストは、テキスト、データ、画像、単一のコンピュータ上のファイルの他のタイプの複数のコンピュータに格納されて取得して表示するステップと、それは2つの部分から構成：ハイパーテキスト転送プロトコルとハイパーテキストマークアップ言語（HTML）。
HTTP、HTML生まれ、インターネットのブラウザの人気は飛躍にもたらしました

HTTPプロトコルのセッション

ブラウザとサーバ間の通信プロセスを経るする4つのステップ

ここに画像を挿入説明

Webブラウザとサーバ接続処理は短く、各ハンドルつのみ接続要求および応答。各ページへのアクセスは、ブラウザとWebサーバが別々の接続を確立する必要があります
WEBサーバへのブラウザとの間のすべての通信は、要求に対する応答から完全に独立し、別個です

HTTP1.0とHTTP1.1差

HTTP1.0のバージョンでは、ブラウザは画像、ダウンロード絵とサーバの間に新しい接続をオープンする予定でWebページを要求し
ますがHTTP1.1のバージョンでは、ブラウザが対応する要求の中で、現在の全てを取得することができます資源その後、切断し、効率を改善

ここに画像を挿入説明

HTTP1.1は、現在最も広く使用されているバージョンですが、最新版は、オープンインターネットHTTP2.0上のHTTP / 2としても知られ、HTTP2.0でHTTPSのみ使用されます。つまり、SSL（セキュア、// URL HTTPS。 HTTPソケット層、セキュア・ソケット・レイヤ）上層の上、実際には、HTTP通信SSL / TLS接続

注：SSLはもともとNetscapeが開発された、そして、IETF（インターネット技術タスクフォース、インターネットエンジニアリングタスクフォース）によって引き継がれ、それがTLSに名前を変更（トランスポート層セキュリティ、トランスポート層セキュリティ）

パケット

メッセージ形式

ここに画像を挿入説明

Requestパケット

メッセージ形式

リクエストライン
リクエストヘッダ
空行
リクエストボディ

GETリクエスト

GETリクエストは、リクエストボディではありません、POSTはリクエストボディを要求します
HTTP GET /Hello/index.jsp / 1.1：GETリクエスト、リクエストサーバパス/Hello/index.jsp、契約1.1
ホスト：localhostをホスト名localhost要求
ユーザーエージェント：Mozillaの/ 4.0（互換; MSIE 8.0 ...）ブラウザとOSの情報に関連付けられています。いくつかのサイトでは、ユーザーのブラウザのバージョンと、システムのバージョン情報が表示されます、これはのUser-Agentヘッダから情報を取得しています
受け入れ：* / * * / *受信できるものを表し、現在のクライアントのためのドキュメントタイプを受け取ることができ、サーバーに伝えます
ZH-CN：言語を受け入れ、ブラウザのツールをすることができ、現在のクライアントのサポート言語- >言語のオプションに関する情報を見つけます
受け入れエンコード：gzipで、デフレートサポートされている圧縮形式を。データがネットワークを介して送信されると、サーバーは、データ圧縮意志を送ることができ
接続：キープアライブクライアントがサポートするリンク、一定の期間を接続すると、デフォルトでは3000msです
クッキー：= 369766FDF6220F7803433C0B2DE36D98 JSESSIONIDそれがこのアドレスの最初の訪問ではありませんので、それは過去に送信された要求で一緒にクッキーが送信した要求に応じて、最後のサーバーになります

POSTリクエストの
POSTリクエストメソッドは、タグのポストを形成するためのプロパティが必要です

リファラーます。http：// localhost：8080 /こんにちは/ index.jspを要求ページは、から例えば、あなたはここにBaiduの上のリンクをクリックして、リファラー：http://www.baidu.comあなたは、ブラウザのアドレスである場合アドレスバーの直接入力、これのないリファラーリクエストヘッダが存在しません
コンテンツタイプ：アプリケーション/ X- WWW-form-urlencodedでフォームデータ・タイプ、符号化データのURLの形式を用いて説明するが、URLエンコードデータは、2進数が続く、「％」の接頭辞である、例えば"コード％E7％以下のBC "UTF-8エンコーディングを使用してURL単語がある" ％96％ E7の％A0％81 "
コンテンツ長：13リクエスト長さは、これは13バイトであります
キーワード=ハローリクエストボディのコンテンツ！ハローデータをフォームに入力され、キーワードは、フォームフィールドの名前です。

Webサーバ

package main

import (
	"fmt"
	"net/http"
)

//创建处理器函数
func handler(w http.ResponseWriter, r *http.Request)  {
	fmt.Fprintln(w, "测试http协议！")
}
func main() {
	//调用处理器处理请求
	http.HandleFunc("/http", handler)
	//路由
	http.ListenAndServe(":8080", nil)
}

テストページ

<html>
    <head>
        <meta charset="UTF-8" />
    </head>
    <body>
        <form action="http://localhost:8080/http" method="POST">
            用户名: <input type="text" name="username" /><br/>
            密码: <input type="password" name="password" /><br/>
            <input type="submit" />
        </form>
    </body>
</html>

応答メッセージ

メッセージ形式

応答ライン
レスポンスヘッダ
空行
レスポンスボディ

応答メッセージの解析

HTTP / 1.1 200 OK要求を示すHTTP1.1プロトコルに応じて、ステータスコード200は、成功しました
サーバー：Apacheの-コヨーテ/ 1.1バージョン情報サーバー
コンテンツタイプ：text / htmlの;のcharset = UTF-8 、UTF-8を使用して応答部材のエンコーディング
コンテンツの長さ：274体274バイトに応答して、
日付：火曜、2015年4月7日10時08分26秒 GMTの応答時間は8時間のタイムゾーンの違いに由来してもよいです

応答ステータスコード

ステータスコードがHTTPクライアントに通知し、HTTPサーバの結果が応答HTTP / 1.1プロトコルのステータスコードは5、3桁のステータスコード、最初に定義された応答カテゴリクラスが定義されて予想しました

1XXは、情報を表す-正常に受信された要求は、処理を継続することを示します
2XXの成功は-受け入れ、理解し、要求が正常に受信されたことを示します
3XXのリダイレクト-要求は、さらなる処理のために完了しなければなりません
4XXクライアントエラー-リクエストに構文エラーがありますか、要求が達成できません
5XXサーバー側のエラー-サーバーは、正当な要求を達成するために失敗しました

応答コードは、結果に応じて、ブラウザに指示ブラウザのために重要である、一般的なステータスコードは次のとおりです。

200成功した要求は、ブラウザコンテンツ本体は、（通常はHTML）対応ブラウザで表示されます
404要求されたリソースは、クライアントが存在しないリソース・エラーを要求していることを示す、発見されません
500要求されたリソースが発見されたが、内部サーバーエラーが発生しました
302リダイレクト応答コードURLアドレスは、サーバが再送信要求にブラウザを必要とする、サーバは、応答ヘッダ場所を送ることを示し、302である場合、それは新たな要求が割り当てられています

wuxingge

公開された116元の記事・ウォン称賛27 ・ビュー10000 +

プライベートの手紙の懸念

GoWeb HTTPプロトコル

HTTPプロトコルの概要

HTTPプロトコルの開発プロセス

HTTPプロトコルのセッション

HTTP1.0とHTTP1.1差

パケット

メッセージ形式

Requestパケット

応答メッセージ

応答ステータスコード

おすすめ