忍者ブログ
  • 2017.09
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 2017.11
HttpUrlConnectionの謎
HttpURLConnectionの不思議な特性?

この記事に触発された疑問を解決するべく、ポート番号の共有マークポイントを調べてみました。


まずは、やってみたことのポイント整理です。

●テスト1
サーバ側をServerSocketで自作。下記の電文を10秒後に返す。

HTTP/1.1 200 OK
Content-Length:3

AB


クライアント側でスレッドを2つ立ち上げ、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されないということは喜ばしいことですね!

●テスト2
テスト1のクライアントスレッドを2回のループに変更する。

<結果>
テスト1と同じく、ポート番号は共有されません。

●テスト3
サーバ側のレスポンスにもkeep-aliveをつけてみる。

HTTP/1.1 200 OK
Content-Length:3
Connection: keep-alive

AB


<結果>
ポート番号が共有されました~。やっほーい。

ということで分かるようにHTTPURLConnectionは安心して使えます。

きちんとサーバのレスポンスを確認してからkeep aliveするということは
レスポンスが不本意にmixされることはありません。

めでたし、めでたし・・・

なわけではなく!
最終チェックポイントに進める状態になりました。
次のテストこそが一番確認したかったことです。

●テスト4
2xx 以降ではなく、ログイン認証開始の1xxのレスならどうなるの?

HTTP/1.1 100 OK
Content-Length:3
Connection: keep-alive

AB


<結果>
ポートは共有されてしまいました。
しかし、ダイアログは管理されているようです。
2回目のgetInputStreamでGETリクエストが飛ばなかったのです!
そのままハングしてしまいました。

(1回目でハングしてたため保留!)
うーん、微妙な感じです。

ダイアログ中にInputStreamが閉じられたら、ダイアログを終了しポートを共有しない。という動作を期待していたのですが・・・
※InputStreamにデータが残っている間に閉じると共有されません。

ということで、きちんと戻り値を確認してダイアログの終了(2xx以降)を
見届けた上でInputStreamを閉じる限りは安全ということかなぁ。


テスト4で1xxをログイン云々は間違いかも、HTTPは違うっぽい。

(補足)
ネットワークに関して、エキスパートでもないので当記事には誤りがあるかもしれません。
その時はツッコミ歓迎。
PR
【2012/10/27 08:34 】 | java | 有り難いご意見(0)
                                    
<<vbncを使ってemacsでコンパイル | ホーム | 構造化プログラミング>>
有り難いご意見
貴重なご意見の投稿














<<前ページ | ホーム | 次ページ>>