泳げないたいやきの日記

メモとして残していきます。誤字脱字や、誤った記事などがあればご教授いただますと幸いです。

OSI参照モデルとTCP/IPについて

プロトコル TCP/IP OSI参照モデル

初めに 

　ネットワーク関係について学んでいる時にOSI参照モデルとTCP/IPとで、混乱することがあるので、本を読みまとめてみました。

ネットワークアーキテクチャの種類

今日、私達が使用しているコンピュータネットワークの通信機能を説明する際に用いられるネットワークアーキテクチャは、

  1. OSI参照モデル
  2. TCP/IP(インターネットプロトコルセット)
  3. DECnet
  4. SNA
  5. AppleTalk
  6. XNS
  7. IPX/SPX

の7種類が種類が挙げられる。

　このようにいくつかのネットワークアーキテクチャが存在するのは、コンピュータ同士がネットワークを利用して通信するために必要とされるプロトコルという約束ごとを設定するために様々な団体や、企業が開発を行ったからである。

　ここでは、先述した7種類のネットワークアーキテクチャの中から代表的に使われている「OSI参照モデル」と「TCP/IP」の2つの差異の特徴を調査し、その結果を提示する。

 

 「OSI参照モデル」と「TCP/IP」の導入までの流れ

　コンピュータの通信が始まった当初に、各コンピューターメーカーが、各々に独自のネットワーク製品を開発し、コンピュータ通信を実現していたが、コンピュータ通信が普及していくにつれ、各メーカーのネットワーク製品の互換性の問題が拡大していき、開発を行う生産者とネットワーク通信を使いたい利用者の両方が不便を感じ始めるという問題が起きていた。

　その問題を解決し、ネットワークの「オープン化」と「マルチベンダ化」にする為に、1978年頃に「国際標準化機構（ISO）」と「国際電信電話諮問委員会（CCITT）」の2つの団体がおよそ６年間共同作業を行い、1984年に導入されたネットワークアーキテクチャが「OSI参照モデル」である。OSI参照モデルは、問題を机上の理論で解決する為に作られたモデルなので、プロトコルの設計や勉強をする時のガイドラインとして使われている。

　「TCP/IP」は、1960年代に「アメリカ国防総省（DoD）」が中心となり、新しい通信技術の研究から始まり、1969年にパケット交換技術の実用性を試験する為のネットワークが構築され、そのネットワークが一般の人々にも使われるようになり「ARPANET」と呼ばれるインターネットの起源が誕生し、ARPANET内の研究グループにより、1970年代前半に「TCP/IP」が開発された。

 　

「OSI参照モデル」と「TCP/IP」の普及率

　OSI参照モデルは、TCP/IPが開発された後の10年後に導入が行われたが、現在使用されているネットワークアーキテクチャはTCP/IPが主流とされている。

OSI参照モデルの開発の方向性を決める指針
  • ネットワークの「オープン化」
  • ネットワークの「マルチベンダ化」
TCP/IPが開発される際の指針
  • ネットワークの「オープン化」
  • 「標準化するプロトコルが実際に使えるプロトコルであるかどうかを重視する」

　

　TCP/IPは指針の通りに、「仕様を考えるよりも先にプログラムが開発された」や、「プログラムを作った後に仕様書を書く」などと言われるほど、実装を重視に開発が行われていた。さらに、TCP/IPのプロトコルの仕様を決定する際には、そのプロトコルが実装されている装置が存在し、限定された形であるにせよ実際に通信ができることが可能な状態になっている必要があるとされている。

　このようなことから、TCP/IPに比べて、OSI参照モデルが普及しなかったのは、動作するプロトコルを開発することと、急速な技術革新に対応できるようなプロトコルの決定や改良を行える仕組みがなかったことが原因の1つとされている。

　さらに、TCP/IPは先に述べた理由以外にも、広く普及した理由がある。

　それは、1980年前後の大学や研究所などのコンピュータのOSとして、米国カリフォルニア大学バークレー校で開発され、無料で配布された「BSD UNIX」が広い範囲で利用され、このOSの内部にTCP/IPが実装さていた事である。これにより、限られた世界の中でしか使用されていなかったTCP/IPは、世界中のコンピューターネットワークに普及した。

 

「OSI参照モデル」と「TCP/IP」のプロトコルの階層化の違い

　OSI参照モデルは、通信に必要な機能を7つの階層に分け、機能を分割し、複雑になりそうなネットワークプロトコルを単純化する為のモデルとされている。

　これらの層は、ハードウェアに近い下位層から、特定のサービスを受け、ソフトウェアよりの上位層に特定のサービスを提供する役割をもっている。これは、TCP/IPも同様である。

　この７階層のOSI参照モデルは、ハードウェアに近い一番下の層から順に、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層となっている。

　各階層の機能は、階層間のインターフェースが一貫性を持っていることを前提として、各階層の機能を分割することにより、特定の場所の機能を変更しても、モデル全体の動作には支障がないように設計されている。

OSI参照モデルの各階層 

  1.  　物理層では、データのビット列の０や１を電圧の高低や、光の点滅に変換したり、逆に、電圧の高低や、光の点滅をビット列に変換を行うことで、物理的な通信媒体に流し込んでいる。このようにして、接続の両端にある2つのデータリンク層の実体の間に、目に見えない通信パスが提供する役割を持つ。
  2. 　データリンク層では、0と１の数字の列を意味のあるフレームに分けて、複数のシステムを経由した先にある宛先のシステムまでのパスのうちの隣接するシステムとの間の情報の流れを制御を行なったり、簡単なエラー検出機器を提供することにより、データが失われたり、破損したりすることを防ぐ役割を持っている。また、OSI参照モデルの設計が行われたのが、LANが普及する以前だったこともあり、LANに含まれる多様な技術を利用できるようにする為に、データリンク層に、メディアアクセス制御層（MAC）と論理リンク制御層（LLC）の2つの副層に分割されている。
  3. 　ネットワーク層では、ネットワーク層が提供する手段により、システム間のコネクションが確立できるようになっており、宛先までデータを届ける役割を持つ。そのため、相手が異なるネットワーク上に存在しても、どの経路を使うかなどの経路選択も行う。
  4. 　トランスポート層では、宛先のアプリケーションにデータを確実に届ける役割を持つ。そして、データを確実に届けることの信頼性を保証するために、送り出すデータを識別する印などの情報を含むヘッダがデータに付加される。
  5. 　セッション層では、データの流れる論理的な通信路の確立や、切断、転送するデータの分割場所の設定などのデータ転送に関する処理を行う役割を持つ。例えば、どのようにデータを送信すれば効率良くやりとりできるかや、データの送信方法はどうするかなどのことを考えてくれる。
  6. 　プレゼンテーション層では、転送される情報を通信に適したデータ形式にしたり、下位層からきたデータを上位層が処理できるデータ形式にするなどの、データ形式に関する役割を持つ。この役割のおかげで、データを共通な表現形式に変換してやりとりを行うことにより、異なるメーカーの各ネットワーク製品でもデータの表現形式の整合性をとることが可能になる。
  7. 　アプリケーション層では、利用されるアプリケーションの中で通信に関係する部分を定めている。このアプリケーションのサービスの中には、ファイル転送サービスや、電子メール、遠隔ログインなどが含まれている。メールの送受信のエラーメッセージなどの、アプリケーション固有のエラー処理も、アプリケーション層が担っている。

  

　これらの7つの階層を学ぶことにより、通信機能の全体の中における、そのプロトコルの位置付けや、おおまかな役割を理解することが可能となる。

（TCP/IPについては後ほどまとめます。）

 

参考文献

  • 竹下 隆史・村山 公保・荒井 透・苅田 幸雄共著（2019）「マスタリングTCP/IP 　入門編」、株式会社オーム社
  • Philip Miller著　苅田 幸雄監訳（2016）「マスタリングTCP/IP 　応用編」、株式会社オーム社

 

 

 

DNSについて

DNS

DNSについての本を読み、簡単にまとめてみました。

※内容に誤りがある箇所がありましたら、ご教授いただけましたら幸いです。

 

DNS

　DNSとは、私達一般ユーザが日常生活でインターネットにアクセスし、使いにくい数字の羅列であるIPアドレスを使用せずに、馴染みのあるローマ字などで欲しい情報を手に入れることが可能なのは、DNSというシステムが、TCP/IP階層モデルのアプリケーション層で実装されているからである。

　渡邉（2018）は、DNSについて次のように述べている。「DNSはドメイン名とIPアドレスの対応を管理し、利用者からの要求に応じてドメイン名に対応するIPアドレスを探し出します。これを「名前解決」と言います。DNSの基本は、それぞれの階層の管理者から必要な情報を入手してドメイン名の階層構造をたどり、最終的な答えであるIPアドレスを得るというものです。」

 

リゾルバーについて

　渡邉（2018）が述べているDNSは、「スタブリゾルバー」、「フルリゾルバー」、「権威サーバ」の3つの要素から成り立つ。

　リゾルバーとは、私達が何か物事を検索する際に、使用するwebブラウザや、メールを送受信する際のアプリといったソフトウェアの中で働くシステムである。

  1. 最初に、スタブリゾルバーとは、スタブリゾルバー自身では、名前解決を行わず、フルリゾルバーに「○○のIPアドレスを教えてほしい」という内容を、目的の情報のドメイン名とタイプを指定して名前解決要求を行い、一時待機をする。
  2. 次に、名前解決要求を受け取ったフルリゾルバーは、スタブリゾルバーの代わりに権威サーバの階層構造の頂点に位置するルートに「○○のIPアドレスを教えてほしい」と尋ねる。この動作を名前解決と呼ぶ。フルリゾルバーからルートに名前解決が行われると、ルートは、自身が保持している情報をフルリゾルバー宛に送信する。フルリゾルバーは、ルートに渡された情報を基に、目的の情報に近い権威サーバを探し、再び、名前解決を行う。このような動作を複数回繰り返すことで、最終的には探している情報を保持している権威サーバから目的の情報のIPアドレスを教えてもらう。教えてもらったIPアドレスを、再び、フルリゾルバーからスタブリゾルバーに送る。
  3. 最後に、一時待機していたスタブリゾルバーは、教えてもらったIPアドレスを使用し、目的の情報を手に入れることが可能となる。このような動作が、DNSの基本的な動きである。

　　

　スタブリゾルバーが、フルリゾルバーに「○○のIPアドレスを教えてほしい」と名前解決要求を送る際に、指定した「ドメイン名」や「タイプ」というものは、権威サーバが保持するリソースレコードに、そのゾーンの設定として含まれる。リソースレコードと、指定した「ドメイン名」や「タイプ」を参照することで、権威サーバは自身が保持している情報を探すことが可能となる。

 

リソースレコードについて

　リソースレコードは、「オーナー」、「タイプ」、「クラス」、「TTL」、「RDATA」と５つのクラスから構成されている。

  • 「オーナー」：問合せ時に指定したドメイン名を記述するクラスである。

 

  • 「タイプ」　：スタブリゾルバーを使用している者が知りたい情報の種類を指定するクラスである。タイプの種類は、約16種類ある。

 

  • 「クラス」　：プロトコルファミリーや、ネットワークの種類といったものを指定する。

 

  • 「TTL」　　：Time to Liveのイニシャルを取ったもので、パケットの寿命を表している。みやた（2018）では、TTLを次のように述べている。「IPの世界では、パケットの寿命を経由するルータの数で表しています。経由するルータの数のことを「ホップ数」といいます。TTLの数はルータを経由するたび、つまりネットワークを経由するたびにひとつずつ減算されて、値が「0」になると破棄されます。」このように、TTLが設定されているおかげで、ネットワークトラフィックの混雑を避けるような仕組みとなっている。

 

  • 「RDATA」　：タイプとクラスにより異なるリソースレコードのデータで、実際のリソースの指定を行う。

　

参考文献

  • 株式会社日本レジストリサービス（JPRS）渡邉 結衣・佐藤 新太・藤原 和典著　株式会社日本レジストリサービス（JPRS）森下 泰宏監修（2018）「DNSがよくわかる教科書」、SBクリエイティブ株式会社、20、72–78

  • 竹下 隆史・村山 公保・荒井 透・苅田 幸雄共著（2019）「マスタリングTCP/IP 　入門編」、株式会社オーム社、184-188
  • みやた ひろし著（2018）「インフラ/ネットワークエンジニアのためのネットワーク技術＆設計入門」、SBクリエイティブ株式会社、96
  • Philip Miller著　苅田 幸雄監訳（2016）「マスタリングTCP/IP 　応用編」、株式会社オーム社、323-325

 

 

 

 

makeによるビルドができない。

makefile C言語 コンパイラ

はじめに

現在、Rui Ueyamaさんが公開していただいている『低レイヤを知りたい人のためのCコンパイラ入門』を読ませていただいております。

（※Rui Ueyamaさんの『低レイヤを知りたい人のためのCコンパイラ入門』は、書籍化されているのでしょうか？）

そこで読んでいる最中に、はまった事に対して備忘録代わりに記事として残して行こうと思いました。

 

問題

目次上の「電卓レベルの言語の作成」の「ステップ１：整数１個をコンパイラする言語の作成」の終盤の内容である「makeによるビルド」で、Makefileを作成したが、makeコマンドが使えなくて、はまってしまいました。

 

CentOS上のシェルでの出来事

”””

[hogehoge@localhost 9cc]$ make

cc -std=c11 -g -static 9cc.c -o 9cc

/usr/bin/ld : -lc が見つかりません

collect2 : エラー : ldはステータス１で終了しました

make : *** [9cc] エラー　１

”””

と表示され、makeコマンドを使用できませんでした。

（※この時、-lcが何を示すものか分かっていません。そして今も、十分には理解できていません。）

 

バージョン

解決策

エラーメッセージで、-lcが見つかりませんとなっていたので、

CentOSのシェル上で、

「yum install glibc-static.x86_64」とコマンドを打ち、glibc-static.x86_64をイントールを行ったところ、makeコマンドを使用する事が可能になった。

 

（glibc-static.x86_64以外にも、glibc-devel.x86_64、glibc-static.i686、glibc-utils.x86_64などがあったが、2020/7/20現在違いはわかっていません。これから調べます。。。）

 

現時点で不明な事や知りたい事

  • Rui Takyamaさんの記事の内容では、makefileの「-static」オプションを消すとリンカが自動でダイナミックリンクになり、ダイナミックリンクを行うには、ダイナミックリンクを行うためのアセンブルのコードが必要と記述されていたが、私の場合、「-static」を消す事でmakeコマンドが使用する事が可能となっていた。（glibc-static.x86_64のイントールを行う前の出来事です。）
  • -lcとは何なのか？少し調べてみたところ「よく使われるC言語関数」がライブラリになったものらしいです。(たなか　としひささんの記事を参照)

 

最後に

わからないことだらけで申し訳ありません。

これから先、書物や記事を読みながら調べていこうと思います。

 

参考資料

 

 

 

 

 

git pushができない.

Github Git

問題

CentOSのシェルで、git pushを行うと、Could not remote repositry?と返されpush操作が出来なかった。

 

バージョン

CentOS　Linux release 7.7.1908(Core)

 

原因

GithubとCentOSでのSSHの設定を行なっていなかった。

 

解決策

  1. CentOSのシェルで、「cd ~/.ssh」とコマンドを打つ。
  2. sshのディレクトリで、「ssh-keygen -t rsa」とコマンドを打ち、公開鍵を生成する。
  3. 「ls」コマンドを打つと、id_rsa  id_rsa.pubと表示されるかを確認する。
  4. 確認後、「cat id_rsa.pub」とコマンドを打ち、表示された公開鍵をコピーをする。
  5. GithubのSSHの設定項目に行き、コピーしたSSHのRSAの公開鍵を貼り付けて、登録を行う。

その後、git pushを行ったところ、無事にpushされていた。

 

今後について

上記の解決策から一応、SSHの接続をすることは可能となったが、調べてみるとこの方法では、鍵の強度の問題などが取り上げられていたので、後に詳しく調べてみようと思う。

 

参考文献