HTTPサービス紹介


HTTP(Hyper Text Transfer Protocol)は、ハイパーテキスト転送プロトコルであり、要求/応答モデルを採用しており、現在インターネットで最も広く使われているネットワークプロトコルである.主なプロセス:クライアントはサーバに要求を送信し、要求の要求ヘッダは要求の方法、URI、プロトコルバージョン、要求修飾子、クライアント情報、および要求の内容などの情報を含む.サーバは、メッセージプロトコルのバージョン、成功またはエラー符号化、サーバ情報、エンティティ要素情報、およびエンティティコンテンツを含む状態ラインで応答する.httpサービスのデフォルトポートは80で、httpsデフォルトポートは443です.HTTPサービスの簡単な処理図です.
HTTP服务介绍_第1张图片
実用主義に基づいて、本稿はhttp契約の原理に対して多すぎる説明をしないで、ただChromeを使ってhttpサービスを調整した経験を分かち合うだけで、同業者の指導を得たいです.httpサービスを開発する過程で、もしサービスエンドを編纂するならば、いつもインターフェースがなくて効果を見ることができるので、いくつかの小さいツールを通じて(通って)サービスを起動することしかできなくて、戻りの結果を調べます.すべてがうまくいけば、もちろんですが、何か変なエラーがあったら、サービス側にデバックできなくなります.http要求とレスポンスを追跡して、クライアントの要求方式、伝達の種類、どのようなデータ、そしてサービス側の応答の結果などを知る必要があります.この一連のパラメータでサービスの健康状態を診断し、エラーチェックを行います.Chromeをよく使うので、ここではChromeを使ってデバッグするだけです.他のブラウザ、例えばFirefox、IEなども同様の機能があります.皆さんは自分の熟知しているものを自由に選んでください.
HTTP服务介绍_第2张图片
上の図はChromeブラウザで開発者ツール(ツール->開発者ツール、またはF 12で起動)です.図の前半は現在のページの各要求のtime lineであり、各要求の要求時間が適時に長くなり、要求時間が長すぎる要求を最適化するために確認することができる.下半分の左側は要求リストです.左側の要求リストをクリックすることで、現在要求されている各パラメータを右側で確認することができます.Headers、Preview、Resonse、Cookier、Timingのいくつかのタブが要求されるたびに、以下に紹介されます.
Headers
ここではいわゆる要求ヘッドとして、GEneral header、request header、reponse header、entity headerのいくつかの部分があります.
General
  • Request URL:クライアントの要求アドレス、サービス端末のサービス
  • に対応しています.
  • Request Method:要求タイプは、主にget、post、put、deleteなどの一連があります.一番よく使われているのはget、post
  • です.
  • Stuts Code:応答状態コードは、ここから一般的な応答状態コードおよび対応解釈
  • を見ることができる.
  • Remote Address:ドメイン名に対応するipおよびポートは、現在の要求が要求されているipのサービスであることを直接に示しており、異常サービスの位置を特定するのに有用である
  • .
    Resonse Headers
  • cache-control:要求と応答が従うキャッシュメカニズムは、現在要求されているCache-Coontrolが他の要求のキャッシュ処理に影響を与えない.prvate(デフォルト)、no-cache、must-revalidate、max-age.
  • content-encoding:サーバ応答結果の符号化タイプ(主に圧縮タイプ)identity、gzip、copress
  • content-type:サーバ応答結果フォーマット/タイプ、例えばtext/html;charset=utf-8
  • content-langage:応答体の言語
  • content-length:応答体の長さ
  • date:メッセージ発信時間(GMT)
  • expires:応答期限切れ時間
  • status:httpレスポンスコード
  • vary:キャッシュ応答を使用するか、それとも元のサーバから要求されるか、すなわちキャッシュに期限切れのない応答が存在する場合、後続の要求によって服用できるか、Accept-Encocding、User-Agent.もしvaryの値の中でUser-Agentに戻ったら、同じページを別のブラウザで開くとサーバに再要求します.Vary中にUser-Agentが戻っていない場合、クライアントキャッシュは同じページと見なし、同じ要求をユーザーに直接キャッシュの内容に戻す.戻ってきた値がAcceept Enccodingであれば、要求ヘッダ情報の中のAccept-encodingフィールドの値(gzipなど)をキャッシュのkeyとする.バリーの値が*の場合はキャッシュは判断されません.
  • transfer-encoding:ファイル転送コードchunkedは、送信コンテンツの長さが不確定であることを識別し、gzip方式で出力する場合は、大きなバイト配列を申請する必要はなく、一ブロックずつ出力することができ、より科学的で、より少ないリソースを占有します.
  • Request Headers
  • Cache-Coontrol:要求と応答が従うキャッシュメカニズムは、現在要求されているCache-Coontrolが他の要求のキャッシュ処理に影響を与えない.prvate(デフォルト)、no-cache、must-revalidate、max-age.
  • Accept:クライアント/送信側で受信できるデータタイプは、text/html、appication/xhtl+xml、appication/xmlなどの
  • を含む.
  • Acceept Enccoding:ブラウザからサーバに送信されたステートメントがサポートできる符号化タイプ(主に圧縮タイプ)identity、gzip、copress
  • Acceept-Language:ブラウザで受信できる言語は、国内ではほとんどzh-CSN、zhであるべきです.q=0.8
  • Connection:サーバとのtcpの接続を維持しますか?keep-alive(デフォルト)、close.keep-alive代表サービスは現在の接続期間を保留します.他の要求によって繰り返し使用されます.closeは要求を代表して接続をクローズします.
  • Referer:現在の要求のソース
  • Upgrade-Innsecure-requests:1
  • Host:要求されたサーバ名
  • User-Agent:Mozila/5.0(X 11;Linux 86_64)ApppleWebKit/537.36(KHTML、like Gecko)Ubuntu Chromium/49.0.2623.18 Chrome/49.0.23.18 Safari/537.247962626262626262626262626262626262626262627979727272720;
    Query String Parameter
    このモジュールはget要求です.要求パラメータです.例えば、
    soc-app:162
    cid:0
    soc-platform:1
    ozv:es_oz_20160428.15_p0
    f.sid:132385467
    _reqid:142769
    rt:j
    Form Data
    このモジュールはフォームを提出する時に現れます.例えば、
    f.req:%5B%5B%22OGB%22%2C%5B7%2C%22en%22%5D%5D%2C%5B%5B%5D%2C%5B1%5D%2C%5B3%5D%2C100%2C%22OGB%22%5D%2C%5B1%5D%5D
    at:AObGSAhUe1EYP164z9Z6L0cy8oPPAm_ezw%3A1462071694241
    :
    Prevew
    要求応答後のプレビューを表示します.
    Resonse
    応答の具体的な内容を表示します.
    Cookie
    クライアントのすべてのCookie情報をkey-value形式で示す.
    Timing
    要求から応答終了までのプロセスの各段階において経験される時間または時間がかかることを示す.
    最後に書く
    Chromeを使って大多数のhttpサービスをデバッグすることができますが、時々post、put、deleteなどの方式の要求をデバッグする時、またインターフェイスがなく、プラグインやツールを使って実現することができます.Chromeでは、PostmanまたはDHCを使用してこれらの機能を実現することができ、とても使いやすいです.下図はPostmanのスクリーンショットです.
    HTTP服务介绍_第3张图片
    ブログ:HTTPサービス紹介ホームページ:http://www.howardliu.cn/