ここでは、Rubyによるネットワークプログラミングの説明を行いたいと思います。 ここで対象としている読者は、ネットワークプログラミング初心者(もしくは入門者)です。 TCP 簡単なTCPサーバとクライアント TCPクライアント(エラー処理付き) 何度も受信できるTCPサーバ TCPサーバ(acceptした相手の確認) UDP UDPを使う UDPでブロードキャストを使う UDPでマルチキャストを使う(マルチキャストを送信する) UDPでマルチキャストを使う(マルチキャストを受信する) UDPでマルチキャストを使う(TTLを設定する) Web 簡単なHTTP GET(Net::HTTP) HTTP HEADと全てのHTTPヘッダの表示(Net::HTTP) HTTP POST(Net::HTTP) 簡単なRSSクライアント その他 IO::selectを使う IPアドレスからホスト名への変換
nixCraft → Howto → CentOS → Linux Tune Network Stack (Buffers Size) To Increase Networking Performance I‘ve two servers located in two different data center. Both server deals with a lot of concurrent large file transfers. But network performance is very poor for large files and performance degradation take place with a large files. How do I tune TCP under Linux to solve this problem? By default t
ご連絡:本日 25 日まで続けられた Ruby VM アドベントカレンダーは,世界の終了のため,保存していなかった部分が消えてしまいました.今後,随時復活させていきたいと思います.ご迷惑をおかけ致します. ご連絡:世界の終了によって失われた記憶を随時復旧させていますが,いくつかの記憶のかけらが宇宙的な何かのために欠落してしまっているようです.鋭意,そうさくしていきたいと思っております. 一覧: #1 RubyVM::InstructionSequence の拡張 #2 Kernel#caller_locations の紹介 #3 Kernel#caller_locations の性能 #4 vm_backtrace.c #5 メソッドディスパッチの高速化(RubyConf 2012 の紹介) #6 Thread.async_interrupt_timing の紹介 #7 Thread.as
ご連絡:本日 25 日まで続けられた Ruby VM アドベントカレンダーは,世界の終了のため,保存していなかった部分が消えてしまいました.今後,随時復活させていきたいと思います.ご迷惑をおかけ致します. ご連絡:世界の終了によって失われた記憶を随時復旧させていますが,いくつかの記憶のかけらが宇宙的な何かのために欠落してしまっているようです.鋭意,そうさくしていきたいと思っております. 一覧: #1 RubyVM::InstructionSequence の拡張 #2 Kernel#caller_locations の紹介 #3 Kernel#caller_locations の性能 #4 vm_backtrace.c #5 メソッドディスパッチの高速化(RubyConf 2012 の紹介) #6 Thread.async_interrupt_timing の紹介 #7 Thread.as
ファイルを編集する場合、主にTemplateリソースを使用する。しかし、一部の定義のみ入れ替えたい、ファイルを丸ごと入れ替えたくない、といった場合には、ruby_block+FileEditユーティリティが役立つ。 以下は、”net.core.somaxconn"(カーネルがキューイング可能なパケットの最大個数)が定義されていなかった場合、ファイルの最終行に定義を追加、最後にリロードするというもの。 ruby_block "Edit /etc/sysctl.conf" do block do rc = Chef::Util::FileEdit.new("/etc/sysctl.conf") rc.insert_line_if_no_match(/^net.core.somaxconn.*$/, "net.core.somaxconn = 1000" rc.write_file end no
linuxサーバのOS全体に効くカーネルパラメータのチューニング箇所と その設定値、またその理由をまとめておく。 あくまで自分の環境ではこうした、というだけであり、 提供するサービスごとに検討が必要である。 どこをどう変更するのか、または変えないのか、その判断材料にはなるだろう。 ※ユーザ単位でシステムリソースに制限をかける場合をこちらを参照してほしい。 以下は/etc/sysctl.conf で設定するものとする。 ● 大規模サイト用チューニング kernel.pid_max 動作:pidの最大数 設定値:131072 理由:pidを枯渇させない vm.max_map_count 動作:mmapやmalloc時にメモリを仮想空間にマッピングできる最大ページ数 設定値:300000 理由:マッピングできなくなる事態を防ぐ net.core.somaxconn 動作:接続(ソケット)キューの
菊池です。CCS Injection脆弱性(CVE-2014-0224)発見の経緯について紹介します。 バグの簡単な解説 OpenSSLがハンドシェーク中に不適切な状態でChangeCipherSpecを受理してしまうのが今回のバグです。 このバグはOpenSSLの最初のリリースから存在していました。 通常のハンドシェークでは、右の図のような順序でメッセージを交換します(RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 §7.3より作成)。 ChangeCipherSpecは必ずこの位置で行うことになっています。OpenSSLもChangeCipherSpecをこのタイミングで送信しますが、受信は他のタイミングでも行うようになっていました。これを悪用することで、攻撃者が通信を解読・改ざん可能です。 発見の困難さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く