NW屋的日常徒然日記

ネットワークを専門にする元社内SEの日常とITネタ諸々を綴って行きます。

【超直前】医療情報技師検定試験(情報処理分野)向けにOSI参照モデルについて少々(2)

 こんばんは。今回は先日の続きになります。(1)はこちらですね。

 

karasuma-kitaoji.hatenablog.com

 ちょうど20日に医療情報技師検定試験があります。ギリギリで申し訳ありませんが、試験に向けた軽い読み物ぐらいの気持ちで目を通していただければ幸いです。

 前回はL1(物理層)に関する話を書きました。L2(データリンク層)についての説明をどうしようかとしばし悩んでました。昔の話になりますが、ブリッジを10BASE-5の間に挟んでいました。ブリッジに端末のMACアドレスを記憶していて、テーブルに載っているMACアドレスかどうかで通す/通さないの判断をして、コリジョンドメインを限定するというような機能があります。

 と言っても、現在はまず使われていませんので、この例はあまり宜しくないですね。今だと、スイッチングハブでしょうか。配下の端末のMACアドレスを学習していて、直接接続されている端末であれば、その端末が接続されているポートに対してフレーム(パケット)を投げるといった感じでしょうか。

 L3(ネットワーク層)ですが、こちらは現状では事実上IPのみと考えてもらって結構です。L2ではMACアドレスを使って端末同士の通信を行います。ですから、同じネットワーク内(同一サブネット内)の端末同士の通信に限定されます。

 しかし、IPの場合は他のネットワークに対して通信する場合に使われます。(同一ネットワーク内でも使いますが)自ネットワーク内端末であれば、直接当該端末のIPアドレスに対して通信します。(MACアドレスと組み合わせて通信しますが、このへんは改めて。<(_ _)>)

 自ネットワーク外のネットワークに所属する端末(サーバやネットワーク機器も含む)と通信する場合は、デフォルトゲートウェイと呼ばれる機器(多くの場合はルータだったりします)に対してパケットを送信します。パケットを受け取った機器は、自分の持っているルーティングテーブルに宛先IPアドレスがあれば、その機器に向かって投げます。もしなければ、受け取った機器に設定されているデフォルトゲートウェイに投げる…という形で、目的の端末に転送します。

 L4(トランスポート層)ですが、これはデータ転送時の信頼性を担保する/しないという点に関わってきます。TCP(Transport Control Protocol)とUDP(User Datagram Protocol)の2種類があります。前者が信頼性を確保するためのプロトコルで、後者は信頼性よりもリアルタイム性を重視したプロトコルであるとも言えます。

 前者は3ウェイハンドシェイクと呼ばれるやり取りの手法を使います。通信する際に通信相手と正しく通信出来ているかを確認します。エラー訂正も行います。

 これに対して、後者はエラー訂正を行いません。その代わり、スループットは上がります。リアルタイム性を要求する音声通信やストリーミングなどに向いています。他にはNTP(時刻同期のためのプロトコル)やDNS(ホスト名とIPアドレスの参照・問い合わせなどのプロトコル)のように、少量のデータをやり取りするプロトコルにも使われます。

 L5~L7(L5:セッション層、L6:プレゼンテーション層、L7:アプリケーション層)については、個々に分けずに一括りにした方が捉えやすいと思います。例外的になりますが、通信経路の暗号化に用いられるTLSがL5に該当するということぐらいでしょうか。

 ここはざっくりと「アプリケーション層(L7)」と考えてしまっていいと思います。SMTPやHTTPやPOP3IMAPDNSなどを指します。

 ですので、それぞれの階層に分かれていることで上下の層の仕事内容を意識することなく、カプセル化されたデータを要求に沿って処理して、真下or真上の階層に投げるというようなことが行われるという風に理解していただければ結構かと思います。

(詳しい方にとっては、いろいろツッコミ入れたくなる部分も多々あるかとは思いますが、その点は何卒御容赦下さいませ。)

【夏休み特別進行】京阪特急プレミアムカーにAC電源コンセント+Wi-Fi整備が嬉しい

 こんばんは。【夏休み特別進行】ということで、ITネタというよりも鉄道ネタ色の方が色濃くなりそうです。

 先日、京阪特急プレミアムカー試乗会があったそうです。毎日新聞からの記事です。

mainichi.jp

 かなりの人気だったそうですね。かなりの倍率だったようです。11日にあったそうですね。

 で、今回このネタを取り上げるのも理由がありまして、プレミアムカー各座席にAC電源コンセントが整備されていて、車内にWi-Fi完備というあたりがツボだったりします。

 こちらウォーカープラスからの記事です。

news.walkerplus.com

 「座席指定なので、疲れていて確実に座りたいときに使いたい」「車内設備が豪華なので乗ってみたい!」というような声も多いかと思いますが、NW屋的日常徒然日記的には、上述のように「AC電源コンセントとWi-Fi」を前面に押し出してみたいと思います。

 余談になりますが、以前こんな記事を書きました。名古屋に行った際に感じたことでした。

karasuma-kitaoji.hatenablog.com

 このネタが京阪特急プレミアムカーで現実のものとなろうとしています。京阪電車さんありがとうございます。<(_ _)>

 話を元に戻します。通勤通学で大阪ー京都間を利用されている方々も多いと思います。推測ですが、一番多いのはJRではないでしょうか。新快速ですと、大阪ー京都間が29分です。阪急や京阪に比べると明らかに速いです。路線上の問題もありますが、最も時間がかかるのが京阪です。淀屋橋出町柳間で55分前後かかるようです。目的地がどこか、最寄駅がどこかという要素にも左右されますが、JR新快速を選ぶ傾向にあるのかもしれませんね。特に土日祝日だと昼得きっぷがあるので、チケットショップでバラ売りされた切符を使うということも普通にあるようです。

 しかし、スマホタブレットの普及でバッテリー切れによる充電対策も必要になります。モバイルバッテリーを持参していればいいのですが、うっかり充電し忘れで役に立たなかったりとか、AC充電器を持ち歩いているものの、AC電源コンセントが使えるカフェがないとかいうようなことはありませんか?

 特に電車内で使っていて、バッテリー残量がヤバくなった経験はありませんか?移動中は頻繁に基地局切替が行われますので、そのためにバッテリーを消耗します。

 そう考えると、車内で充電出来るメリットは大きいかと思いました。関西では南海電車の特急サザンの一部車両(サザンプレミアム)のみ対応なので、運任せになってしまいます。(^^;;

 残念ながら、現時点では近鉄特急はAC電源コンセント非対応なので、特に大阪難波ー名古屋間のアーバンライナーだと「名古屋(難波)までバッテリーが持つのだろうか?」という不安と闘いながら乗車することがあります。そういう点では新幹線はありがたいですね。(一部座席に限定されますが)

 Wi-Fiについて詳しいことは現在提供されている情報からは推測出来ませんが、スマホVPNアプリがちゃんと使えるかどうかが気になります。

 20日から運行開始とのことですが、一度どんなものか試してみようかなという気にはなります。1時間近く(あるいはそれ以上の時間)乗車している電車には指定席料金払ってでもいいから、AC電源コンセント整備車両に乗りたいと思う昨今であります。

中国製Webカメラだけでなく気になるネタが…

 こんばんは。中国製webカメラのセキュリティ面的問題について取り上げておられたブログが気になりました。黒林檎さんのブログ記事です。

r00tapple.hatenablog.com

 ファームウェア脆弱性でアカウント資格情報ダダ漏れというのが怖いです。黒林檎さんもおっしゃっているように、中国メーカー製機器ということで、セキュリティ関連国内機関が手出し出来ない状況に陥る危険性があります。(消費者として出来ることは国内メーカー機器を選択するしかないのだろうなと思います)

 ここ最近気になるネタが複数出てきてます

 数日前に中国製USB接続充電器にSIMが挿せるようになっていて、これで通信出来るようになっていて、盗聴器として働くようになっているというツイートを見かけました。

 他にも8月5日に書いた記事ですが、アメリカの携帯電話機器メーカーが販売している一部の機種で、スマホ内に保存されている連絡先やメッセージなどの情報を中国にあるサーバに送り、保存しているとの報道がありました。

karasuma-kitaoji.hatenablog.com

 上記記事でも書きましたが、「標準的機能なので問題はない。他のメーカーでもやっていること」とのメーカー側の見解ですが、勝手に情報を収集されて断りもなく、国外のサーバにアップロードされているとなると、あまり気分のいいものではありません。(収集された情報がどのように利用されているかを知る手段がないですしね)

 ここで中国政府側がVPN規制に乗り出しました

 以下はブルームバーグの記事です。7月から中国当局の規制が厳しくなり、中国国内業者が軒並みVPN接続サービスを停止するという状況に陥っています。

www.bloomberg.co.jp

 そして、Appleも御多分に漏れず、AppStore上のVPNアプリを削除しているという報道もありました。これらの情報が一連の流れとしてつながってくるのか、あるいは全く別物なのかは現時点では判断出来ません。ただ、こう矢継ぎ早にいろいろ出てくると、「???」と思わざるを得ません。

 これらの動きに関して、引き続きウォッチして行きます。

【超直前】医療情報技師検定試験(情報処理分野)向けにOSI参照モデルについて少々(1)

 こんばんは。20日の医療情報技師検定試験まで1週間を切っていますが、直前に頭の片隅に入れておいていただくと、もしかすると少しは役立つかもしれないネタを少々。

 タイトルにもありますように、ネットワーク関係では基礎知識になる「OSI参照モデル」についてですので、「そんなことは十分知ってるわ!」とおっしゃる方はさらっと読み流していただければと思います。

 医療情報技師やITパスポート/基本情報受験者の方向けに書けないかと

 この記事を書こうとしたきっかけは、Twitterでのフォロワーさんのツイートがきっかけになりました。「フォロワーさん(ですので、この場合の当事者はフォロワーさんのフォロワーさんということになりますw)が自宅のインターネット接続環境で有線も無線も接続出来ない。DNS関連の問題もあるのかな?」(意訳)といった内容でした。そこで、「LANケーブルがちゃんと刺さっているかとか、断線してないかとか、リンクランプが点灯しているかなどの物理層から確認して行って、順番に上位レイヤを確認して行くと問題の切り分けが出来ると思います。」とリプしました。

 この後、「「〇〇層」という表現がピンと来ない。「第〇層」という表現も分かりにくくて混乱してる。」(意訳)といったようなリプをいただきました。

 OSI参照モデルの階層を記述してみました

 そこで、定番化してはいますが、OSI参照モデルを医療情報技師やITパスポート・基本情報受験者向けに説明してみようかと思い立ちました。

 以下のような階層になります。

【第7層:アプリケーション層】

【第6層:プレゼンテーション層】

【第5層:セッション層】

【第4層:トランスポート層

【第3層:ネットワーク層

【第2層:データリンク層

【第1層:物理層

 郵便配達に例えられることが多いので沿ってみます

 複数階層に分かれていて、それぞれ分業体制になっています。OSI参照モデルを説明するのに使われる例えですが、郵便配達の流れですね。手紙や小包を郵便局窓口に持って行って、相手に届けてもらうようにお金を払うイメージですね。

 徹底した分業体制

 郵便物を窓口に持って行く人にとって重要なことは、相手に(出来るだけ早く)確実に届けてもらうことですよね。窓口に郵便物を渡した後にどのような交通手段で集配するのか、どのように仕分けをするのか、相手に届ける際に自転車で配達するのか、あるいはバイクなのかなどということは別にどっちでもいいことですよね。「確実に届く」ということが重要なのであって、届くまでに使うツールやプロセスには興味を持たないですよね。

 逆に配送に関わる人にとっては、自分の責任範囲外のことにはノータッチですよね。受付郵便局から集配郵便局に運ぶ人にとっては、集配郵便局から先の配送ルートについて知らなくても問題はありません。集配郵便局間を配送する人にとっては、無事に配送先の集配郵便局に到着すればいいわけで、トラックに積んだ個々の郵便物の宛先までは気にする必要はありません。集配郵便局に届いた郵便物を配送する人は、宛先に的確に届けることに注力すればいいことになります。それまでがどうだったかを意識する必要はありません。

 インターネットの仕組みも分業体制

 郵便配達と同じイメージで考えてもらうと良いかと思います。例えば物理層の場合だと、通信する物理媒体が有線か無線かが問題になって、有線の場合は何を使ってどうやってつなぐか、無線の場合は何を使ってどうつなぐのかという話になります。有線だったらLANケーブルなのか、光ファイバーなのか、同軸ケーブルなのかetc…。無線だったら、Wi-Fiなのか、Bluetoothなのか、3G/LTEなのかetc…というように媒体の違いに関係なく「物理的につなぐ」ことを目的とします。あくまで「どのような手段でつなぐのか?」が物理層では問題なのであって、その上にある「どこ(宛先IPアドレス)に送るのか?」「どのプロトコル(TCPUDP?)で送るのか?」「どんなプロトコル(http?smtpIMAP?)」などということは気にする必要はありません。これらに関してはカプセル化(パッケージ化されている)されているので、物理層では意識する必要はありません。ちょうど、集配郵便局間を配送する人が積み荷の個々の宛先や、書留なのか速達なのか、普通の郵便物か小包なのかなどは気にせず目的地に届けることに専念すればいいことと同じです。

 インターネットの場合も同様です。物理層で受け持つのは機器と機器を物理的(無線の場合も含む)につなぐことに専念し、「どこに送り届けるか」や、「どういうアプリケーションを使うのか」や、「どのようなデータを送るのか」や、「どうやって確実に送り届けるか」ということは上位層に丸投げします。

 長くなりましたので、第2層(L2)より上の話は(試験に間に合うように)明日以降にしたいと思います。<(_ _)>

2週間程度の予定で【夏休み特別進行】で行きます<(_ _)>

 こんばんは。世間は11日からお盆休みモード突入といった感じですね。当ブログも2週間ほど夏休み特別進行モードに突入します。

 GW・お盆・年末年始期間は広義のIT関連ネタ以外も取り上げて行くことがあります。そして、1日複数本記事アップということがあります。

 上記のような形で、従来の「原則1日1本IT関連ネタ」というお約束が崩れますが、お付き合いのほど宜しくお願いいたします。<(_ _)>

 

2020年までに電子カルテ一元管理をという政府の無謀な挑戦(1)

 こんばんは。10日の日経朝刊記事で電子カルテ一元化の記事が載ってました。記事の内容はこちらです。

www.nikkei.com

 詳細は電子版読者でないと読めないようです。10日の記事(紙媒体)を読んだのですが、多くのハードルが存在します。

 果たして本当に3年で実現するのか???

 個人的には「現場を知らないから、こんなことが言えるんじゃないか?」というのが初見の率直な感想です。1つの病院の電子カルテ導入or更新でも2~3年はかかってしまうというのが相場ですしね。「ではA社の電子カルテにしましょう」という風に簡単には行きません。文房具を購入するようには行きません。何と言っても、数億~数十億オーダーの買い物になります。導入後、しばらくは借金としてのしかかってきますので、おいそれと判断出来ません。

 となると、現時点で電子カルテ更新or導入予定のない医療機関は様子見になってしまうでしょう。

 やっかいなことにベンダごとの電子カルテの互換性が低いという点

 大病院でそれなりのシェアを押さえているベンダというと、富士通NECIBMの3社が浮かびます。「電子カルテを乗り換える」と言っても、各社間での互換性はあまり期待出来ません。その上、業務にシステムを合わせるために、多くのカスタマイズを施してしまうことがあります。ただでさえ、乗り換えが簡単ではないという現状で、カスタマイズしてしまうと身動きが取れなくなってしまいます。

 医療情報交換・共有のための規約としてSS-MIX2が策定されたわけですが、これが必ずしも万能というわけでもないために、そう単純には事が進まないのではないかと個人的には思っています。

 昔の話で恐縮ですが、大手パソコン通信事業者のことを思い出しました。ここで言う大手とは、NIFTY-Serve(当時)とPC-VAN(当時)を指します。電子メール機能は提供されていたのですが、事業者を跨ってのメール送受信は出来ませんでした。不便さを解消すべく、両者間のメール送受信に対応するようになりました。

 しかし、Windows95発売によるインターネット利用が普及したことにより、SMTPによるメール送受信が一般化して、パソコン通信そのものが廃れて行きました。

 同様に電子カルテの一元管理が実現するにもかなりの時間を要するのではないかという風に考えられそうです。

 SS-MIX2ベースで一元管理を実現しようという試みがありました 

「正直厳しいんじゃないか?」と思っていて、念のため調べてみましたら、1年ほど前の@ITの記事がヒットしました。

www.atmarkit.co.jp

 これを読むと、SS-MIX2を用いて最大公約数のデータ交換・共有を行おうとしているように思えます。さすがに一足飛びに電子カルテ一元管理までは無理だろうなという印象です。それでも、これをきっかけに少しでも前進するのであればいいのかなとは思います。

 ただ、「何が何でもマイナンバー(とマイナンバーカード)の利用普及をさせたい」と考える総務省の方針には諸手を挙げて賛成とは行きませんが。

 

パスワードは複雑さ<文字数の多さではないかというお話

 こんばんは。今回は遅かったので、ショートバージョンになります。<(_ _)>

 パスワードに関するお話です。ウォールストリートジャーナルの記事からです。

jp.wsj.com

 パスワードというと、「大文字と小文字も入れて、数字と特殊記号も混ぜろ」という風に言われて久しかったです。で、定期的に変更しましょうねという風にも言われてきてました。

 でも、その「常識」が覆りつつあります。パスワードの定期変更に関しては、「意味が無い」という意見が多数を占めつつあります。弱いパスワードを定期的に変更するよりは、変更せずに長い文字列のパスワードを設定する方が安全だというのが定説になりつうつあります。

 昔はマシンリソースやOS上の制約などにより、8文字以内のパスワードを設定させられた記憶があります。短い文字列となると、ランダムにして大文字・小文字・数字・特殊記号などを組み合わせて…という発想に陥ると思います。

 昔の制約のイメージから抜け出せない人が意外に多いのではないでしょうか。今はリソースがふんだんにありますから、もっと長い文字列でも問題ないはずなんですよね。

 

 ということで、遅くなりましたので、続きは明日以降にお願いいたします。

<ひとまずつづく>