ネットワーク図の書き方 - Akio's Log
先月から出稼ぎで東京に来てます。毎年、プロジェクトの特性上、３〜４月に空きが出てしまうので、仕方のないことなんですが。 で、最近ネットワーク図を書く仕事をしているのですが、ちゃんとしたネットワーク図を仕事で書くのは初めてのことでしたので、「コツ」をつかむまでだいぶ時間がかかってしまいました。 その過程で、いろいろと参考にしたサイトをまとめてみます。 書籍 ネットワーク現場の教科書 改訂版 （マイコミムック） (MYCOMムック) 作者: IDG出版社/メーカー: 毎日コミュニケーションズ発売日: 2011/03/31メディア: ムック購入: 1人 クリック: 9回この商品を含むブログ (2件) を見るこれはネットワークの教科書 改訂版 （マイコミムック） (MYCOMムック)の実践編的な内容ですが、本当に役に立ちました。ネットワーク図を書く際には、物理構成図と論理構成図をきちんと分けて書か
自宅サーバのインフラ設計書を公開します - @int128
自宅サーバのインフラ設計書を公開します。 Design paper of the home server（抜粋） 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発（SI）の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
