httpプロトコルを使用してサーバーから1バイトを取得し、すべてを最小化したいとします。ヘッダーはありません。http://myserver.com/bここでbは1文字のテキストファイルです、またはより良いまだbは1つの文字（それが可能かどうか確信していません）です。 Apacheでこれを行う方法はありますか？完全なhttpや完全なhttpsトランザクションに必要な最小限のデータ量は？あるいは、より効率的なデータであれば、ヘッドリクエストだけでトランザクションを実行することもできます。できるだけ小さいhttpとhttpsのデータ要求
正確に達成しようとしているのは、これは一種の生き物ですか？
HTTP/1.0が使用されていることを意味する "GET /"を実行できますが、バーチャルホストなどのようなものからあなたをロックします。 "/"をCGIスクリプトにマップすることはできますが、あなたが達成しようとしているものに応じて、実際のファイルになります。基本的に "Content-Type：text/plain"（または、別の短いMIMEタイプ、場合によってはカスタムMIMEタイプ、例えば "Content-Type：a/b"）である最小のヘッダーセットだけを返すようにApacheを設定できます。 Content-Length：0 "となり、レスポンス本体はまったく返されません。
最低のニブルでフラグビットのバイトをチェックしたいと思います。300万人のユーザーが、できるだけデータ転送を最小限に抑えたいと思っています。 – alphablender
@alphablender多分あなたはHTTP以外の何かを使うべきです。次のようなTCPプロトコルを簡単に書くことができます：（1）クライアントの接続、（2）最小限のペイロードの即時送信、（3）切断。それは、それが得るほどのスパルタンとしてです。 –
私はChrisに同意します。独自のサーバー/プロトコルを実装すると、データトラフィックを最小限に抑えることができます。 HTTPはここでは最善の選択ではありません。 –
HTTP/1.1を使用する予定がある場合（仮想ホストになる場合は多かれ少なかれ必要です）、GETリクエストには、Hostヘッダーまたは絶対URIとしてのホスト名が必要です（RFC 2616 section 5.1.2を参照）。
お客様の回答にはContent-Lengthまたはtransfer encoding headers and delimitersも必要です。
HEADリクエストを使用してHTTPを「中断する」場合は、HTTPがプロトコルの最良の選択肢ではないように思えます。カスタムヘッダーで何かを返すこともできるかもしれませんが、それはきれいなやり方ではありません。
独自のプロトコルを実装しても、リモートパーティからの読み取りをいつ停止するかを決定できるようにするには、Content-Lengthまたはチャンクエンコーディングと同様のメカニズムを実装する必要があります（そうでなければ、ひどく閉じた接続を検出することはできません）。
編集：ここでは
は簡単な例で、これは（HTTP 1.1を仮定して）自分のホスト名によって異なります。あなたは代わりにOPTIONSを使うことができると思います。それはあなたがHTTPを破るために喜んでいるどのくらいに依存...
要求：
GET/HTTP/1.1
Host: www.example.com
14 + 2 + 21 + 2 + 2 = 41バイト（CRLFのための2）
です応答：15 + 2 + 17 + 2 + 24 + 2 + 2 + 1 = 65バイト
HTTPSについては、そこbのウィルの
HTTP/1.1 200 OK
Content-Length: 1
Content-Type: text/plain
a
SSL/TLSチャネル自体には小さなオーバーヘッドがありますが、その大部分はハンドシェークに取り込まれます。特に、サーバー証明書（クライアント証明書認証を使用していないことを前提としています）が最大のものです。証明書のサイズ（DER形式）を確認してください。
だから、転送されるオーバーヘッドの実際の最小バイト数は、httpプロトコルと同様にhttpsプロトコルを使用している可能性がありますか？言及された人が実際には30人ですか、それとももっと大きい/小さいですか？ – alphablender
これは古い質問ですが、だれかが役に立つと思うかもしれません。誰もその質問のHTTPS部分に答えていないからです。
これは、信頼できない他のプロキシをトンネル経由で接続するプロキシでHTTPS通信を簡単に検証するために必要でした。
このサイトは明らかにそれを説明する：記事からhttp://netsekure.org/2010/03/tls-overhead/
引用：
一つを計算に影響を与える心に留めておくべき事は、メッセージのほとんどの可変サイズです。可変性の性質は正確な値を計算することを許さないが、可変フィールドのためのいくつかの合理的な平均値を取ると、オーバーヘッドの良好な近似を得ることができる。さて、それぞれのメッセージを見て、それらのサイズを考えてみましょう。
- ClientHello - 最初のクライアントhelloの平均サイズは約160〜170バイトです。これは、クライアントから送信された暗号スイートの数、およびTLS ClientHello拡張の数に応じて異なります。セッションの再開が使用される場合は、セッションIDフィールドに別の32バイトを追加する必要があります。
- ServerHello - このメッセージは、ClientHelloよりも静的ですが、TLS拡張のために可変サイズです。平均サイズは70〜75バイトです。 - 証明書 - このメッセージは、異なるサーバー間でサイズが最も異なるメッセージです。このメッセージには、サーバーの証明書と、証明書チェーン内のすべての中間発行者証明書（ルート証明書を除いたもの）が含まれています。証明書のサイズは、使用するパラメータとキーによってかなり異なるため、証明書あたり平均1500バイトを使用します（自己署名証明書は800バイトまで小さくすることができます）。もう1つの変動要因は、ルート証明書までの証明書チェーンの長さです。 Web上にあるもののより控えめな側にいるために、チェーン内に4つの証明書があるとしましょう。全体的に、このメッセージは約6kです。
- ClientKeyExchange - 最も広く使用されているケース - RSAサーバー証明書を再度想定します。これは、このメッセージのサイズが130バイトに相当します。
- ChangeCipherSpec - 固定サイズ1（技術的にはハンドシェイクメッセージではない）
- 終了 - SSLv3が使用されているかTLSであるかに応じて、サイズはそれぞれ36バイトと12バイトに大きく異なります。ほとんどの実装では、これらの日は、少なくともTLSv1.0をサポートする、ようさんは、TLSが使用されますので、サイズはそう最小として大きな（または小さな）することができ
12バイトになりますと仮定してみましょう：
20 + 28 + 170 + 75 + 800 + 130 + 2*1 + 2*12 ≈ 1249
この記事によると平均は約6449バイトです。
また、TLSセッションを再開できることを知っておくことが重要です。そのため、最初の接続だけがこのオーバーヘッドを持ちます。他のすべてのメッセージには、約330バイトが加算されます。
ヘッダーなしでHTTPリクエストを行うことはできません。 –
HEADリクエストのみを行う場合、最小のデータ量は何ですか？サーバー側のヘッダー量を最小限に減らすことはできますか。 – alphablender
@Chris、はいできます。 [spec]（http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html）によると、 'Request-Line'（例えば' GET/'）は厳密にヘッダではありません。 –