InfoQ: HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
拙著「Linuxネットワークプログラミング」:Geekなぺーじ
「Linuxネットワークプログラミング」という本を書きました。 LinuxでCを利用してネットワークプログラミングを行うための解説書で、私にとって初の書籍執筆です。 昨年２月にソフトバンククリエイティブさんから書籍執筆のオファーを頂き、開始から約一年後の発売となります。 今回、C言語によるLinuxのネットワークプログラミング解説書籍を執筆する機会を頂けたのですが、書籍の大きな方向性として以下の点が挙げられます。 可能な限り、ソースコード全文を掲載する。断片的なソースコードだと手元で即座に試しにくい メインはIPv4を意識しながら書く ただし、getaddrinfo()を前提とし、IPv6が存在することを前提に書く IPv6移行がメインの書籍ではない。インターネットの世界がIPv4/IPv6デュアルスタックで運用されることになるという前提でネットワークプログラミング解説書を書いているだけ
C++と Pthreads でミニマルなHTTPサーバを書く - いやなブログ
C++と Pthreads でミニマルなHTTPサーバを書く 『UNIXネットワークプログラミング』を読んでいると、自分でも何かネットワーク系の小さなプログラムを書いてみたくなりました。そこで、ミニマルなHTTPサーバを C++と Pthreads で書いてみました。 同じ著者の「詳解UNIXプログラミング」もそうだったように、今回の本もほとんどすべてのページに、重要なことが書かれています（最後のほうのXTIの部分は例外かもしれませんが）。 たとえば、27章ではネットワークサーバの実装として、次の設計方針がそれぞれ検討され、実際のコード付きで解説されています。 クライアントごとに fork 事前に fork - 各プロセスで accept 事前に fork - ファイルロックで accept を保護 事前に fork - Mutex ロックで accept を保護 (PTHREAD_PRO
ミニマルなHTTPサーバ - かそくそうち
http://0xcc.net/blog/archives/000178.html このコードには長時間動作させる上で明らかにマズい点が二つあります。 (22:58追記: 問題のコードは既に修正されています。高林さん、すばやい対応ありがとうございます。) 「UNIXネットワークプログラミング」の別の節に解説はありますが、コードだけコピペした人が困らないよう指摘しておきます。 一つ目はSIGPIPEシグナルの発生に備えていない点です。 サーバーがレスポンスを返す前にクライアントがソケットを閉じてしまうと、write()がSIGPIPEシグナルを生成することがあります。 SIGPIPEの既定の動作はプロセスの終了なので、この状況が発生しただけでサーバーは勝手に(coreを残さず)終了してしまいます。 通常は次のような関数でSIGPIPEを無視します。 #include <cstring> #i
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
「QoS」の しくみ---目次
すべてのパケットを“早い者勝ち”に扱うIPネットワーク。しかし最近，Webアクセスや電子メールより優先して送る必要のあるIP電話のようなアプリケーションが出てきた。こうした通信を使うには，IPネットでも，急ぎの通信を優先させたり，必要な帯域を確保する技術が必要となる。これがQoS機能だ。今回はQoS機能に焦点を当てて，そのしくみと効果をじっくり探っていく。 ■プロローグ IP電話の通信を守れ ■パート1 送信順を変える優先制御 パケットの列を分けるのがミソ ■パート2 帯域制御は「待たせて捨てる」 捨て方にテクニックあり ■パート3 パケットを正確に識別 4種類の情報で見分ける ■エピローグ QoSって意外に簡単
YANO's digital garage - パケット受信タイムスタンプ
Linuxでパケット受信契機のタイムスタンプ採取方法。 ユーザーアプリからはsetsockoptでSO_TIMESTAMPを設定しておき、recvmsgで受信する都度せっせとCMSG_DATA(cmsg)経由で取得する形での仕組みが用意されている。具体的なコーディングサンプルだと char inbuf[BUFSIZ]; char cmsgbuf[CMSG_SPACE(sizeof(struct timeval))]; struct cmsghdr *cmsg; struct msghdr msghdr; struct iovec msg_iov; struct timeval *pTime, tv; const int on = 1; setsockopt(sock, SOL_SOCKET, SO_TIMESTAMP, &on, sizeof(on)); msg_
Manpage of CMSG
Section: Linux Programmer's Manual (3) Updated: 1998-10-02 Index JM Home Page roff page 名前 CMSG_ALIGN, CMSG_SPACE, CMSG_NXTHDR, CMSG_FIRSTHDR - 補助データにアクセスする。 書式 #include <sys/socket.h> struct cmsghdr *CMSG_FIRSTHDR(struct msghdr *msgh); struct cmsghdr *CMSG_NXTHDR(struct msghdr *msgh, struct cmsghdr *cmsg); size_t CMSG_ALIGN(size_t length); size_t CMSG_SPACE(size_t length); size_t CMSG_LEN(size_t
Manpage of RTNETLINK
Section: Linux Programmer's Manual (7) Updated: 2008-08-08 Index JM Home Page roff page 名前 rtnetlink, NETLINK_ROUTE - Linux IPv4 ルーティングソケット 書式 #include <asm/types.h> #include <linux/netlink.h> #include <linux/rtnetlink.h> #include <sys/socket.h> rtnetlink_socket = socket(AF_NETLINK, int socket_type, NETLINK_ROUTE); 説明 rtnetlink はカーネルのルーティングテーブルを読んだり変更したり するためのものである。これはカーネルが内部のサブシステムと 通信するためにも用いられて
Manpage of NETLINK
Section: Linux Programmer's Manual (7) Updated: 2008-08-08 Index JM Home Page roff page 名前 netlink - カーネルとユーザー空間の通信 (AF_NETLINK) 書式 #include <asm/types.h> #include <sys/socket.h> #include <linux/netlink.h> netlink_socket = socket(AF_NETLINK, socket_type, netlink_family); 説明 netlink はカーネルモジュールとユーザー空間のプロセス間で 情報をやりとりするために用いられる。 netlink は、ユーザープロセスに対しては 標準的なソケットベースのインターフェースを、 カーネルモジュールにはカーネルの内部 API を提供
Linux の identd が遅い理由 〜 debian の pidentd はひと味違う? : DSAS開発者の部屋
identd というのは，いわゆる ident プロトコル(RFC 1413)を実装したデーモンの総称です．最近は使われる場面も減ってきたかもしれませんが，DSAS では一部この identd の返答結果に基づいてアクセスの可否を決定しているサービスが存在します(※1)．そのため，identd の返答速度は重要になります． ※1 ident プロトコルは，クライアントからサーバ側への TCP 接続に関して，サーバ側がクライアント側に，その TCP 接続を所有しているユーザは誰であるかを問い合わせるためのものです．問い合わせた結果を何に用いるかはサーバ次第ですが，その仕組み上，問い合わせるサーバ側は問い合わせ先となるクライアント側の identd が自分が期待した回答を返してくれるものと信頼していることが前提となります．つまり，インターネット上のクライアントの identd の返答に基づいて
DeleGate version 9.9 リファレンスマニュアル の日本語訳
DeleGate reference manual version 9.9
RFC1928(SOCKS Protocol Version 5)
トップページ - 翻訳ドキュメント - RFC 1928 原文：ftp://ftp.rfc-editor.org/in-notes/rfc1928.txt 原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。 M. Leech Bell-Northern Research Ltd M. Ganis International Business Machines Y. Lee NEC Systems Laboratory R. Kuris Unify Corporation D. Koblas Independent Consultant L. Jones Hewlett-Packard Company March 1996 Status of This Me
ProxyChains - TCP and DNS through proxy server. HTTP and SOCKS
Download the latest source (version 3.1) ProxyChains HowTo (README) Public Forum ProxyChains project page at SourceForge Ezine articles about proxy servers (kind of humor) Proxy server search (try 1080 or 8080) About proxychains tool: * It's a proxifier. * Latest version: 3.1 * Dedicated OS: Linux and other Unices. * Allows TCP and DNS tunneling through proxies. * Supports HTTP, SOCKS4 and SOCKS5
tcpdumpとiptablesの関係 - （ひ）メモ
追記 2009-04-03 まったくもってブコメでいただいた指摘の通りです＞＜ h2onda linux, tcpdump tcpdump(というかlibpcap)は、データリンク層(OSI layer2)レベルでパケットを取得する packet プロトコルを使ってるので、そうなります。参照: man packet(7) 2009/04/02 はてなブックマーク - h2ondaのブックマーク / 2009年4月2日 tt_clown network 細かいけど，図は逆（NIC が下）のが良いかなと思った．/ "ip"tables と言う位だから，IP層でパケットをフィルタしてるて事だろうな．tcpdumpはEthernet Frameも見えるので，後は分かるな？・・・てとこか． 2009/04/02 はてなブックマーク - tt_clownのブックマーク / 2009年4月2日 pack
ファイル記述子をUnixドメインソケット経由で渡す - bkブログ
ファイル記述子をUnixドメインソケット経由で渡す Unix 系の多くの OSには、ファイル記述子を別のプロセスに Unix ドメインソケット経由で渡す機能があります。一見、何のために使うのかよくわからない機能ですが、 glibc の nscd はこれをうまく使っています。 nscd (name service caching daemon) は glibc 内で行われる名前関連の問い合わせをキャッシュするサーバです。NIS や LDAP などを用いてネットワークベースでユーザ管理を行っている場合、 getpwuid() などの関数はユーザ名の取得にネットワークアクセスを必要としますが、 nscd を立ち上げておけば、二度目からの同じ問い合わせはキャッシュから得られます。 nscd を立ち上げている GNU/Linux システムでは、キャッシュファイルが /var/db/nscd 以下に作
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Manpage of NETLINK
Linux netfilter Hacking HOWTO