返信

こんばんわ。

仕様上，HTTP1.1は続けて複数のリクエストを送信できますけど，
実際のプログラミングはどうなっているのかしら？
私はプログラマを引退して久しく，その辺の事情に疎くなっているので，
匿名希望さんが書いたプログラムのイメージが正しいのかどうか，
判断しかねます。

というのは，普通に考えると，
リクエスト送信とレスポンスの受信はワンセットで考えるので，

---------------
socket
connect

write(htmlファイルの要求)
read(htmlファイルの受信)　(※）

(htmlファイルの解析)

write(画像ファイル１の要求)
read(画像ファイル１受信)
write(画像ファイル２の要求)
read(画像ファイル２の受信)
write(画像ファイル３の要求)
read(画像ファイル３の受信)

close
---------------

っていう感じにすることが多いんじゃないかと思うんですよ。
でも，これじゃ画像を一個ずつ順番に扱うことになるので，
性能面で問題になるかもしれません。
リクエスト送信とレスポンス受信をワンセットにして，
スレッドか何かで併行処理した方が速いですからね。

この点，HTTP1.0ならリクエスト送信とレスポンス受信毎に
コネクションが別々になりますから，
それぞれのコネクションのソケットをスレッドに渡せば
簡単に併行処理できます。
（コネクションが増えるとメモリ消費量も増えますけど）

HTTP1.1で一つのコネクションで複数のリクエストをやり取りする場合に，
性能面を考えると，どういうやり方が良いのかしら？
その辺の事情知っている方いたら，アドバイスいただけると助かります。　＞　皆様

> htmlファイルのread(※）は，何か別の情報で，
> 制御がアプリケーションに戻るのでしょうか？

readを実行するときに受信するバイト数を指定して，
そのバイト数のデータを受信したら制御がアプリケーションに戻る，
っていう格好でプログラミングするのが普通でしょう。
だから，1バイトずつreadするようにプログラムを作れば，
すぐにアプリケーションに制御が戻ってきます。

この辺のことは，細かな部分まで言葉で説明するのは難しいので，
言葉の説明より，論より何とかで，
実際にプログラムを作って試してみる方が良く分かります。