4分TCPのサーバ側プログラムを改修する機会があった。時々ではあるが、アプリケーション起動時に、サーバ側プログラムで2分ほどの待ちが発生するとのこと。TCPの知識はほとんどなかったため、この機会に勉強をした。以下のサイトが分かりやすかった。http://www.ne.jp/asahi/hishidama/home/tech/socket/tcp.htmlこのサイトは、以前JavaやScalaの学習をした際にもお世話になっている。サイトの作者は相当熱心な勉強家であることがうかがえる。技術者として尊敬している。そちらに下記のように書かれている。一定時間(2~4分?OSによって異なる)経つとCLOSED状態になる。一定時間(2~4分?OSによって異なる)経つとCLOSED状態になる。たしかに今回サーバー側から先に切断しており、サーバー側がアクティブクローズ側になっている。利用しているポートがTIME_WAIT状態になっていた。TIME_WAIT状態にならずにいきなりCLOSED状態になる。このとき、(ライブラリによっては?)RSTを送信するみたいだ。何も送ってこないようにして、待機状態を回避するんだろう。TIME_WAIT状態になるべきだろう。1234567また、アクティブクローズ側がSO_LINGERオプションで時間0をセットしている場合、TIME_WAIT状態にならずにいきなりCLOSED状態になる。このとき、(ライブラリによっては?)RSTを送信するみたいだ。これにより相手にソケットがクローズされたことを知らせて何も送ってこないようにして、待機状態を回避するんだろう。TIME_WAIT状態になるべきだろう。SO_LINGERオプションにより、強制的にclose状態にできるようだ。筆者も書いている通り、あまりよい方法とは言えないようだ。本来あるべき姿は、クライアント側から切断するようなアーキテクチャにすることとのこと。今回は、とりあえずSO_LINGERオプションを使ってみることにした。下記のサイトを参考に実装。https://www.ibm.com/support/knowledgecenter/ja/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/setopt.htmその際に、LINGERを以下のように設定した。0;SO_LINGERをONにして、タイムアウトを0にした。その結果、確かにTIME_WAIT状態に遷移しなくなりました!!!!副作用がないのか心配ですが、とりあえずSO_LINGERオプションをONにして様子をみたいと思います。最近WireSharkを使用することが多くなってきた。地図情報が送られてきているかの確認に使用することが多い。WireSharkとはWireSharkは高機能なパケット取得・プロトコル解析ソフトで、ネットワークに流れるパケット情報をリアルタイムで調査することが可能だ。ネットワークエンジニアには必須のツールであるといえる。※最も私はネットワークエンジニアではないがWireSharkは以下からインストールすることができる。https://www.wireshark.org/download.htmlインストール時に特に困ることはなかった(と思う)。起動すると、キャプチャしたいインタフェースを聞かれるので、ダブルクリックして起動する。キャプチャを開始すると、メイン画面に次々とパケットが表示される。フィルタリングたくさんのパケットが次から次へ流れてくるため、フィルタしないと見づらい。そこで、下記の表示フィルタに検索条件を入力して絞り込む。IPを指定して検索たいてい、確認したいパケットのSourceのIPやDestinationのIPが分かっていると思うので、それらを指定して検索。192.168.1.122ポートを指定して検索これもかなり使う。指定したポートで通信できているかを確認するときに使う。地味に使うことが多い。tcp.flags.ack==1以上です。