ネットワーク層

ネットワークプログラミング

以前ロードバランサ絡みの記述はしたが、今回要件定義フェーズの作業でハードウェア構成含めて提案しなければならなくなる可能性があるため、じゃあパフォーマンスの基準は何にするかという話が出た。
で、ハードを分散するときの一つの指針になるのが「最大同時セッション数」というものだと伝え聞いたので、セッションというのはなんのことぞと調べてもらっている。調べてもらいっぱなしではなんなので、久々にLinuxカーネル本（参考：amazon）を広げて、OSがやってくれてるTCP/IP7階層のプログラム処理について調べて見た。

TCP/IP7階層

いわゆるOSI参照モデルというやつのことを指している。下から順に物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層で構成されるものである。
で、Linuxカーネルでソケットを使ってTCP/IP通信をする場合、INETソケットというものを使用し、セッション層から先（TCP）、またはトランスポート層から先（UDP）をブラックボックス化して行う事が出来るわけで、通常この内部を意識する必要もないのだが、詳細は言えないが今回は意識する必要があったので調べた。
大雑把に言うとUDPではトランスポート層→ネットワーク層→データリンク層と流してそれぞれに必要なデータを書き込み、最終的にデータリンク層が物理層とのブリッジ的な役割をしつつNICに送信対象データを書き込むという流れになる。ARPなんかもこのデータリンク層が自動的にやっている。
あくまでもLinuxカーネルの本なので物理層に対する記述は貧弱だったが、わかったようなわからないような感じである。
とりあえずパフォーマンスの一つの基準であるセッションという概念は、TCPコネクション一つを表すのだというのが推測としては成り立ったのでよしとしよう。
やっぱりこういうのは一度全部物理層からアプリケーション層まで組んでみないと、完全理解は難しそうだ。

最大同時セッション数

については調査結果はまだ。わかったらまた別の日に記述しよう。
一応事前に得た情報をより詳細に記すと、「Linuxは最大同時セッションの制限が255とか、そんなんだったと思うけど調べておいて」という感じになる。
で、こんな制限ほんとにあるのかなというのが現状の認識だったりする。
TCPのAcceptで確立されたソケット、ならびにConnectで確立されたソケット合計数が255を越えるなんて、簡単なHTTPサーバを運用しただけでもすぐに発生する事態だろう。特にHTTP1.1以降でKeepAliveを有効にしているサーバなどだとよく発生しそう。
現実的に255の制限はないと考える方が無難な気もするのだが、どうなのだろう。

ちなみにルータ系は当然パケット処理をする過程でTCPとは違う定義のセッションは管理しているようで、家庭用なら4096とかそんなもんという情報も断片的に得た。
セッション数を目安にハードウェア構成を提案する場合、ルータ、ロードバランサ、OS、１セッション辺りの時間辺りを算出して、総合的に評価する必要がありそう。準備期間が短いので、かなり集中して勉強しないとまずい事態になりそうかなと少々焦り気味。

ということで

我ながらグダグダ感のある日記だが、現在やっている仕事のASULA関係ではない方はそれだけ不透明な状況という事が伝わればいいかなと。
さすがに4プロジェクトリリース直前＋割り込み1なのでちょっと忙しい。
本当は忙しいからといって何かに手を抜くなどやってはいけないのだが、まだそこまでの自己管理は正直出来てないということだろう。情けない限りです。