午後問5(ネットワーク)についての投稿を受け付けるスレッドです。

すごく自信ないのでどなたか解答教えてください

1(1)エ(2)ファイルごとに異なるポートで受信する
2ウキオエ
3ウ
4(1)サーバにファイルを要求する時間
(2)128

にしました、、、

なんでオにしたんだ、、

1(1)イ？  (2)？？？
2ウキクエ
3ウ
4(1)1ファイルずつファイル要求する時間
(2)128

自信はありません…。

設問1
(1)ウ
(2)スレッドを利用してファイル受信を行うこと

設問2
b.ウ  c.キ  d.ク  e.エ

設問3
ウ

設問4
(1)写真の一覧ページの表示が早くなる
(2)48

ポートじゃないんですね、、

ポートの枯渇ではないでしょうか？
プロセスの枯渇、ソケットの枯渇
て用語は聞いたことがなく、、、
ポートは443ですが、
内部の論理ポートが枯渇しているイメージになると考えますが
如何でしょうか？

１
エ
４多重でファイル受信する手法w
2
ウ、キ、ク、エ
3
ウ
4
ファイルが表示されるまでの時間
256

問４はさっぱりわかりませんでした…

4ポートを使うためTCPポートが枯渇している

私もポートの枯渇だと思います。
過去問にもポートの枯渇に関する問題ありましたし。

ソケットにしました。だめだなあ
記述の問題も  全部  間違っていると思う。

問五 設問1 1 エ
2 ファイルを4つごとに分けて並列で受信する手法
設問2 b ウ
c エ
d キ
e カ
設問3 ウ
設問4 1 ファイルの送信が終わるのを待つ時間
2 128

ぼろぼろ

ほぼ一緒です。
2 
ポートアクセスが重ならないように通信する

4
ファイル要求してから受け取るまでの待ち時間

設問1 (1) イ(ソケット)

HTTPパイプライン機能は、複数ソケットに対しリクエストを行うことで並行してリクエスト/レスポンスを行います。

サーバは、特定のポート(問題では443/tcp)をlistenerに設定し待ち受けます。
クライアントからリクエストを受けると、マルチスレッドでプロセスを生成し、個別の処理を行います。

ちなみに、サーバのHTTPS待ち受けポート(443/tcp)は枯渇しません。
過去問にあったのは、WebサーバとDBサーバのやり取りの中で複数の応答を管理するためにWebサーバが複数のポートを利用していた問題ですね。

複数の応答を管理していると思ったのですが違ったのですね。

ポートの枯渇だと思いこんでましたけど違うっぽい感じですかね…
短命ポートの枯渇だと思ったのと単純にソケットの枯渇という表現を見たことが無かったのでエにしちゃいました
今のwindowsだと短命ポートはデフォルトで16000くらいあるので設定値が128ってとこでちょっと引っかかりはしたんですけど…

あー…そうかポートじゃなくてソケットか。

サーバ側で ulimit -n(でしょうか？)を上げておかないと新規ファイルディスクリプタが枯渇して新規にソケットが作れなくなるんですかね。

URL貼れないようなので、「ソケット  枯渇  ulimit」とかでググっていただければ。

L3-L4の話だけじゃなくて内部プロセスについてもおべんきょしないとだめですね。。。

まとめてみました！

・HTTPパイプラインは一つのTCPコネクション上で並行リクエストを行う機能

→ 本問ではブラウザ側でこの機能はオフとある
→ 実際、ログのシーケンス図でも1ファイルずつリクエストしている

・なんとか並行リクエストするためにTCPコネクションを1表示あたり複数(最大4？)張っているように見える

→ クライアント側エフェメラルポートを4つ消費するイメージ？
→ サーバ側は443だけなのでポート枯渇は無さそう？

・TCPコネクションの数だけサーバ側ではソケットを生成するので、ファイルディスクリプタ上限に達すると新規ソケットが作れなくなる

→ つまりTCPコネクションが確立できない
→ 単純に考えてクライアント数x4のソケットが必要

・そこでHTTP/2のストリームを用いて一つのTCPコネクション上で並行リクエストできるようにした

→ 複数コネクションを張る必要が無くなる(つまり1ソケットだけで済む？)
→ 1ファイルずつではなく並行でリクエストできる(逐次受信に必要な待ち時間を無くせる？)

というように考えました！添削お願いいたします(；ω；)

令和最初のNW難しすぎます・・・悔しかったので一晩中考えました。
設問１（２）文章中の下線①、ブラウザが採用する複数のファイルを並行して受信するための手法、
ですが、

HTTP/1.1なので「バーチャルホスト」で実現、一つのIPを複数のドメインで共有、

ではないか？と考えましたが皆様のご意見を伺いたいです。
「a」は自分は「ポート」にしたのですが（全く自信なし）、最大数が「１２８」、
バーチャルホスト数を「４」として割るとホストひとつの最大数は「３２」、
同時アクセス数が「３２」を超えると「アクセスエラーが発生」はこれで説明できるかと？

でも、まったく自信ありません。1.1で TLSを通すとその都度TLSハンドシェイクが発生するので
ポートにしろソケットにしろ、スループットが落ち、エラーとなる。かな？

追記します。
「HTTPパイプライン機能」（たぶんSPDY）は確かに一本のTLSパイプの中で、複数のリクエスト・レスポンスを並列でやりとりする機能ですが、確かHTTP/2 からの機能だった気がします（自信なし）。
1.1 はTLSだとひとつひとつセッションを生成し、オーバーヘッドが酷いのに対し、/2 は圧倒的に速くなる。
HTTP/3になると更に速いみたいです。

いや、これ作ってる最中難易度高すぎたって気付けよカンニングしても解けないレベルやんけ

ネスペ午後 Ⅰ に出題されてもおかしくないレベルですよね？
（読み進めている内に頭を抱えてしまった）
現在、クラウドで動画だろうがゲームだろうがガンガンストリーム配信されて速さに慣れている世代には想像もつかない苦労が /1.1時代にはあった、というわけで・・。しかし、/ 1.1 しか使えない環境もまだまだあるし、クラウドがダウンした場合、災害などで古いブラウザで手作業で繋ぎ直す緊急事態が起きた時、こういうことが起きるよ、と知っておかねばならない、と出題者の意図を憶測してみました。
平成２８年秋午前問７に「Web Socket によって実現できるのはどれか」と過去問があるので、これついて掘り下げて勉強していないと解けない、「超」難問。
当然、自分は全く解けませんでした！もう泣くしかない。

確かにいくつか難しいのはあるけど全体的に見れば
設問2と3が抑えられてて後記述がいくつか取れてればいいような
6割安牌としては優秀な問題だった

ネットワークっていつもこんな感じで満点取ろうとするときついけど
悪い点にもならないみたいなイメージ

IPAのサイトに「HTTP/1.1においてTLSにupgradeする」RFC:2817
ipa.go.jp/security/rfc/RFC2817JA.html
↑ 探してみたらありました。よろしければどうぞ。