Httpプロトコルのコンテンツ長

クズども · 2019年9月24日 16:43:20に投稿

前書き

HTTPプロトコルはインターネット上で最も重要なプロトコルの一つですが、一見シンプルに見えますが、実際にはしばしば問題に直面しており、私たちは何度も同様の問題に直面しています。長い接続やパケット解析があります。 HTTPプロトコルについては何も知ってはいけません。しっかり理解しなければなりません。そこで、このシリーズを書きました。HTTPプロトコルの問題点や経験を共有するためです。

HTTPプロトコルはリクエストパケットとリリシングパケットの両方にヘッダーとボディを持ち、ボディはHTMLページやjpeg画像などの取得したいリソースであり、ヘッダーは特定の慣習を設定するために使われます。例えば、クライアントとサーバーがある送信フォーマットで合意し、クライアントはまずヘッダーを受け取り、フォーマット情報を把握し、その後本文の読み込みを始めます。

クライアント:Accept-Encoding:gzip(私の場合は圧縮してください。トラフィックを使っています。まずダウンロードしてからゆっくり解凍します)

サーバー1:コンテンツエンコーディング:null(コンテンツエンコーディングヘッダーなし) 圧縮はしませんし、CPUは無料ではありません。欲しいですか?

サーバー2:Content-Encoding:gzip(トラフィックを節約し、圧縮)

クライアント:接続:keep-alive(ビッグブラザー、ついにTCP接続を構築しました。次回は使います)

サーバー1:接続:継続使用(簡単ではありませんが継続使用)

サーバー2:接続:終了(引き続き使用している方は、TCPは一度きりで、次に見つけたら再接続する必要があります)

HTTPプロトコルには3回のハンドシェイクがなく、クライアントがサーバーにリソースを要求した場合、サーバー側が優先されます。また、交渉プロセスがなくてもサーバーがクライアントに直接指示するヘッダーもあります。例えば、上記のContent-Lengthはサーバーがクライアントにボディの大きさを伝えるものです。だがしかし！サーバーが事前にボディの正確な大きさを教えてくれるとは限りません。サーバーはまずヘッダーを書き、その後ボディを書く必要があります。ヘッダーにボディケースを書きたい場合は、事前にボディサイズを知っておく必要があります。ボディが動的に生成されている場合、サーバーはヘッダーの書き込みを終えてから書き込みを始めます。これにより多くの追加オーバーヘッドが必要になるため、ヘッダーにコンテンツ長が記載されていない可能性があります。

では、クライアントはどうやって体の大きさを知るのでしょうか? サーバーは三つの方法で教えてくれます。

1. サーバーはすでにリソースサイズを知っており、content-lengthヘッダーを通じて教えてくれます。

Content-Length:1076(body的大小是1076B，你读取1076B就可以完成任务了）

Transfer-Encoding: null

2. サーバーはリソースのサイズを事前に知ることができないか、事前にリソースを割くためにリソースを費やしたくないため、httpの返信メッセージに「Transfer-Encoding:chunked」というヘッダー(ブロック転送)を追加します。各ブロックは固定された形式で、前方にブロックのサイズ、その背後にデータ、そして最後に0のブロックが位置します。このようにして、クライアントが解析を行う際には、不要なフィールドを除去することに注意を払う必要があります。

Content-Length:null

Transfer-Encoding:chunked (接下来的body我要一块一块的传，每一块开始是这一块的大小，等我传到大小为0的块时，就没了）

3. サーバーはリソースのサイズを知らず、チャンク送信モードをサポートしていないため、コンテンツ長ヘッダーも転送エンコーディングヘッダーも存在しません。この時点で、サーバーから返されるヘッダーは近い必要があります。

Content-Length:null

Transfer-Encoding:null

Connection:close(我不知道大小，我也用不了chunked，啥时候我关了tcp连接，就说明传输结束了）

大丈夫です · 2019年9月24日 17:16:57に投稿

ありがとうございます、大家さん

Httpプロトコルのコンテンツ長

関連記事

閲覧したセクション