Computer Networking Memo

2.1.2 Processec Communication

  • What communicate with in systems between endpoints are processes, not systems itself. 
  • 'Socket' is used to communicate with two processes and is the Interface between Application Layer and the Transport Layer in OSI 5 Model. 

Recall that a scoket is the interface between the application process and the transport-layer protocol. p.82 

2.1.4  Wath Services Does an Application Need?

  • Many network provides not only one protocol.  
  • We have to choose the protocol in transportation-layer from several protocols when we develop Application-layer services. 
  • In chooseing transport-layer protocol, what services are needed by developping application must be considerated.
  • Application requirements are classfied as data loss, bandwith, and timing.
Data loss ( Reliable Data Transfer,  in other words)

 Applications whose purpose is transfer date requires Relieable Data Transfer.

In contrast, applications such as multimedia application does not require so sensitibly Releiable Data Transfer. The applications like this are called as loss-tolerant application.

Bandwith

 

 

 

 

 

パケットキャプチャ

arpのパケット解析の続き。今日はこれしかやっていない。

対話時間うんぬんはよくわからないのでとりあえず後回しにした。今日は、宛先ホスト・送信元ホストの一覧を出力した(作業的には昨日よりはるかに簡単)。わかったことは以下。

  1. 宛先には同じサブネットのものと違うサブネットのものが存在する。
  2. 宛先ホストの一覧から、このドメイン内で接続されているはずのホストの範囲(arpの対象となっている範囲)。解釈はまだ。

　１について。同じサブネットのものは現状のarpの理解と一致しているのでわかりやすい。違うサブネットからのarpパケットには、プライベートアドレスとグローバルアドレスからのものが観測されていた。プライベートアドレスは理解できる。これは、研究室内のLAN(WiFi)にアクセスしたものを観測したのだろう。となるとこのパケットをキャプチャしたのはWiFiを管理しているサーバーか？あとでネットワークの構成図を見てみよう。グローバルアドレスからの接続はよくわからない。思いつく仮説は、パケットキャプチャしたノードが外部との境界に設置されたノードであったことくらいか。この仮説は、グローバルアドレスとパケットをやり取りしているホストをみればすぐわかるはず。次回に。

　２について、これは興味深かったが、興味深いだけ。次回の解析の際に予備知識としてもっておくと少し便利なくらいか。存在しないホストに対するarpのリクエストはどのくらいの頻度でおこるのか、またなぜおこるのかとか考察できるかもしれない。なぜについてはブロードキャストで送られたからでほとんど間違いないだろうが(これが正しいとするとブロードキャストのパケットは結局各ノードを宛先にしたパケットがサブネット内のノードの数だけ作成されるということになる。昨日の疑問は解決。新たな疑問：ブロードキャストのパケットを作成しているのは誰か？)。また、「宛先になっているが送信元になっていない」＝「存在しない」が真かどうかもよく考える(調べる)必要がある。これについて、「存在しないと考えられる」ノードへのリクエストの回数を調べてみるとおもしろそう。

 

追記：ブロードキャストの宛先アドレスは実際のdestination nodeとなるのはわかったが、なんでWiresharkはそのパケットがBroadcastだとわかったのだろうか。

ソケットプログラミング

昨日の疑問と推測は正しかった。リスニングソケットと接続済みソケットは別プロセスで動いており、別プロセスで同一ポートを利用することは可能であるようである。本当にforkしているかはまた後程確認しようと思う。

ソケットプログラミングはCで書いた方がいいという助言をいただいた。ネットワークプロトコルなどはほとんどCで書かれているそうだ。確かに、Cならばforkしているかどうかを確かめることが可能であるようにも思う。

また、SDN(OpenFlow)について勉強しないかというアドバイスをいただいた。これはまだほとんど見ていないので、後日。forkなどについて詳しく理解していないので、明日は貸していただいたLinuxの仕組みの本を読もうと思う。

ハニーポットには、Hajimeとみられるマルウェアからの接続が十数件あった。Hajime, Mirai ともに日本由来の名前である。これについても明日調べてみようと思う。特に攻撃コマンドで用いられていたbusyboxについて。

今日の課題であったarp解析は全くうまくいかない。そもそもarpとは返答待ちの前に連続で出すものなのか、要求ー返答の一対一になっているのか？明日調べる。これは調べればすぐわかるだろうが、ブロードキャストのパケットの宛先は実際にはドメイン内の各IPアドレスになっているのだろうか。arpパケットを解析していたところ、255.255.255.255宛のパケットは観測されなかった。しかしWiresharkで確認するとBroadcastとなっていたので疑問を感じた。

ソケットプログラミング

ソケットプログラミングにおいて、おおまかなサーバ・クライアント双方の状態遷移及びその契機となる操作が何かについて理解できた。

サーバー側の挙動で、listen, acceptの部分がよくわからない。リスニングソケットに対して、カーネル側で「確率済みキュー(ESTABLISHED)」と「確率待ちコネクションキュー(SYN_RCVD)」の二つのキューが作られるというところはわかった。キューへのエントリの合計数は、listen(backlog)で指定するbacklogより小さくなるというところもわかった。

では、このキューとは何なのか？これがわからない。ソケットが格納されているというイメージでいるが(参考書の書き方的にもそう解釈できそう)、その場合、リスニングソケットと(acceptによって確率済みキューの先頭から取り出された)接続済みソケットは同じポートを利用していることになる(リスニングソケットと接続済みソケットは同じポートを使っていることは実験により確認済み)。このことが可能かどうかがわからない。

書いてたら別に問題ないような気がしてきた。リスニングソケットはSYNが届いたらSYN_RCVD状態のソケットを生成して、3WHSが成立したらESTABLISHED状態に変化させるということを行って、かつリスニングソケットの持つキューに生成したソケットを順番に格納しているということか？ちょっと納得できないのは、複数のソケットが同じポートを利用しているというところか。クライアント側で複数のソケットで同じポートをバインドしてみるか実験してみるか。

実験したところ、少なくともbindではAddress already in use エラーが発生することがわかった。これは調べたい。

調べたところ、forkして子プロセスに処理を移譲しているようだ。同一プロセスでは同一のポートは使用できず、異なるプロセスならば可能ということだろうか。子プロセスを作成したら同じアドレスをbindできるのか？マルチプロセス(スレッド？そこも曖昧…)はなあなあで済ませてきたらそこから勉強せねば…

2月

2月はフロントエンドの言語をprog8にて学んだ。

HTML, CSS, SCSS, JavaScript, Ruby, Ruby on Rails, Java, Python など。

全て触りだけだが。HTML&CSSはためになった。他の言語はとりあえず触っただけという感触。

何を作ろうという目的もない場合はこういうサービスはとても便利でよい。

3月は、有名な人のポートフォリオサイトをコピーしてみるのと自分の理解したことをまとめるサイトを作りたいなとも思う。それと同時にCTFと競プロにも挑戦してみようかなあ。