HttpURLConnectionの不思議な特性？この記事に触発された疑問を解決するべく、ポート番号の共有マークポイントを調べてみました。
[0回]
まずは、やってみたことのポイント整理です。
●テスト１
サーバ側をServerSocketで自作。下記の電文を10秒後に返す。
HTTP/1.1 200 OK
Content-Length:3
AB
クライアント側でスレッドを２つ立ち上げ、HTTPURLConnectionを
new URLから開始して繋げにいく。
＜結果＞
確認したいことは、これでポート番号を共有されては大変ということで
当然ポート番号が共有されることはありませんでした。
また、リクエストが送られるタイミングはopenConnectionではなく、
getInputStreamであることが分かりました。
下記の電文がサーバに送られました。
GET / HTTP/1.1
User-Agent: Java/1.6.0_32
Host: pc001:8081
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
このケースの正確な計測結果がネット上にはなく不安でしたが
結果がmixされないということは喜ばしいことですね！
●テスト２
テスト１のクライアントスレッドを２回のループに変更する。
＜結果＞
テスト１と同じく、ポート番号は共有されません。
●テスト３
サーバ側のレスポンスにもkeep-aliveをつけてみる。
HTTP/1.1 200 OK
Content-Length:3
Connection: keep-alive
AB
＜結果＞
ポート番号が共有されました～。やっほーい。
ということで分かるようにHTTPURLConnectionは安心して使えます。
きちんとサーバのレスポンスを確認してからkeep aliveするということは
レスポンスが不本意にmixされることはありません。
めでたし、めでたし・・・
なわけではなく！
最終チェックポイントに進める状態になりました。
次のテストこそが一番確認したかったことです。
●テスト４
2xx 以降ではなく、ログイン認証開始の1xxのレスならどうなるの？
HTTP/1.1 100 OK
Content-Length:3
Connection: keep-alive
AB
＜結果＞
ポートは共有されてしまいました。
しかし、ダイアログは管理されているようです。
２回目のgetInputStreamでGETリクエストが飛ばなかったのです！
そのままハングしてしまいました。（１回目でハングしてたため保留！）うーん、微妙な感じです。
ダイアログ中にInputStreamが閉じられたら、ダイアログを終了しポートを共有しない。という動作を期待していたのですが・・・
※InputStreamにデータが残っている間に閉じると共有されません。
ということで、きちんと戻り値を確認してダイアログの終了(2xx以降)を
見届けた上でInputStreamを閉じる限りは安全ということかなぁ。テスト４で1xxをログイン云々は間違いかも、HTTPは違うっぽい。
（補足）
ネットワークに関して、エキスパートでもないので当記事には誤りがあるかもしれません。
その時はツッコミ歓迎。
PR
