なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
を探すことがたまにあるので、今まで遭遇した・調べて見つけたケースを書いておく [1]ListenしていないポートにSYNパケットが送信された場合、RSTパケットがSYNパケットの送信元に返される。 [2] Accept済みのソケットに対して、データを全て読み取っていない(EOFに達していない状態)でcloseを発行した場合にコネクションの相手側にRSTパケットが送られる。 [3] Linux限定だが、tcp_abort_on_overflowがonになっている状態で設定したバックログ以上の未Acceptのコネクションが張られた場合(http://linux.die.net/man/7/tcp) [4] tcp_max_orphans以上のorhanコネクションが張られた場合、orhanなコネクションに対してRSTパケットが送られる。 *orpahなコネクションってソケットがクローズされてる
Linux:OSのtcpタイムアウトのデフォルト値について † 例えば、curlを使用して、タイムアウト値を300秒に指定し、タイムアウトさせるよう無いことをしても、実際180秒を超えたくらいでタイムアウトする事象が発生していました。 これが、curlだけじゃなくて、例えばapacheのmod_proxy_balancerのバックエンドサーバへのタイムアウトについても、タイムアウト値を300秒とかでせっていしても、実際は180秒ちょいでタイムアウトしてしまっていました。 これについて、ちょっと調べたところどうもLinuxのOSとして持っているTCPのタイムアウト値が効いているようだ、ということがわかりました。 ここを見ると分かります。 #cat /proc/sys/net/ipv4/tcp_syn_retries 5 これはtcpのsynを送信するリトライ回数みたいで、以下のロジックでリト
13.2. あまり知られていない設定はい、変更できるパラメータはとてもたくさんあります。 ここではそれらすべてをリストしたいと考えています。 一部は Documentation/ip-sysctl.txt でも説明されています。 カーネルのコンパイル時に 'Configure as router and not host' に 'Yes' と答えていると、これらの設定のデフォルトが、 ここに示すものとは異なっているかもしれません。 Oskar Andreasson も、これらのフラグに関するページを公開しています。 ここのものより良いように思えますので、 彼のページ もチェックしてみてください。 訳注: この部分の訳出にあたっては、 2.2 カーネル付属文書 proc.txt の翻訳 を参考にさせていただきました。 13.2.1. ipv4 全体一般的な注意ですが、ほとんどの速度制限機能は
クラスタ構成のサーバでは、障害発生後にクライアントがすぐに復旧しない場合があります。サーバ側がフェイルオーバした後にクライアント側が再接続するまでの時間を短くする方法を紹介します。 クライアントからサーバに接続するとソケットはESTABLISHEDになります。もしESTABLISHEDになったソケットで正しくパケットが送信されなかった場合、OSは再送を試みます。再送に失敗してソケットをクローズするまでの時間はOSの設定によります。 OSがTCP接続の異常を検知してからクローズするまでの時間を短くするには3つの方法があります。 パケットの再送回数を少なくする。 TCPレイヤでKeep Aliveパケットを送信する。この方法はTCP Keep Aliveに対応しているアプリのみ可能。 アプリケーションレイヤでKeep Aliveパケットを送信する。この方法はNullパケットを投げる等に対応して
3. AS間の経路を“制御” しようということ http://www.flickr.com/photos/7687126@N06/2313399001/ 2012 (c) INTERNET MULTIFEED CO. 3 4. 完全に制御する ことはできない 4 http://www.flickr.com/photos/gnislew/1453056073 2012 (c) INTERNET MULTIFEED CO. 5. AS間経路制御 顧客 / peering partner / transit 提供者にも 彼らなりのpolicy がある 自分たちで制御できるものを “最大限” 制御する方法をご紹介します 2012 (c) INTERNET MULTIFEED CO. 5
ip_conntrackを設定する理由 パケットフィルタリングツールであるiptablesは、パケットを解析するときにip_conntrackというファイルにトラッキング情報を記録します。 ip_conntrackには、最大トラッキング数があり、それをオーバーすると新規セッションを弾いてしまって、ネットワークパフォーマンスの劣化を招きます。 /var/log/messageにこのようなメッセージが出ていたら、ip_conntrackが溢れている状態です。 大量のトラフィックを捌くロードバランサーやキャッシュなどの目的を持ったLinuxマシンで、iptablesを使っているときには、ip_conntrackの最大トラッキング数を忘れずに設定しておきましょう。 ここでは、手元のマシンCentOS 5と6で設定をしていきます。 検証環境 CentOS 6.3(64bit) CentOS 5.8(
Cisco icons are globally recognized and generally accepted as standard for network icon topologies. You may use them freely, but you may not alter them. Icons for printed collateral, Visio, video, and multimedia Use for Cisco corporate conceptual print-path icons. B/W: EPS (7.6 MB) | JPG (4 MB) PMS 3015: EPS (14 MB) | JPG (3 MB) Icons as Microsoft Visio stencils (.vss) Use in Microsoft Visio. PMS
前回は、大規模NATとユーザへの影響を紹介しました。今回は、大規模NATを利用するユーザが増えたときのサーバ運用者への影響例としてアクセスログの扱いの変化を紹介します。 なぜ、アクセスログの扱いが変わるのか? 大規模NATが非常に多くのISPで運用されるようになると、Webサーバ運用者もそれを前提とした運用が望まれるようになります。 まず、アクセスログの扱い方が変わると言われています。 ISPでIPv4大規模NATが運用され、Web閲覧を行うユーザのIPv4アドレスバリエーションが劇的に減ってしまいます。これは、ISPが運用する大規模NATによって、多くのユーザーが「同じIPv4アドレス」にまとめられてしまうためです。 アクセスログに記載される項目が変化する可能性があります 大規模NATが普及すると、多くの家庭が同じグローバルIPv4アドレスを利用して通信を行うようになるため、グローバルI
こっそりと。SEが書いてます。ActiveDirectoryとかWindows/Linuxとか中小規模のサーバー構築とか運用してます。誰かお仕事ください。 アクティブ-アクティブでの負荷分散はとても夢のようですよね。ロードバランサーとか、高価な機器を導入するのも大変ですし。 ということで、テストしてみました。 使用機器は RTX1000 です。 ■構成図 テスト環境なので、上記の通り行いました。ただし1台のルーターで行うことを前提としている技術のようなので、正式にはサポート対象外となりそうです。 PC(192.168.1.xx) から 10.0.0.2 に ping を飛ばします。このとき、LAN2 のケーブルを抜いても、相変わらず ping が届き続けるのです。 検証したところ、ping 1つ分ぐらいはロスします。 以下 config です。 ■上段ルーター ip route defau
100人繋いでも大丈夫!3000円で出来るサクサク社内ネットワーク構築法 こんにちは。弊社ネットワーク担当のshiromaです。 以前当ブログでも取り上げました通り、弊社は六月に新社屋へと引っ越しを行い、社屋の拡張と併せて人員の拡充を行ってきました。しかし、その人員の拡充に伴って内外の通信の量は肥大し続け、20人を過ぎた頃からNTT貸出のルータでは遅延がひどくなり、40人近くなった現在、社内基幹ルータの入れ換えが切実に必要という状況となりました。 かつてRTX1000を利用していた経験を活かせると考え、数万円の費用を払ってRTX1100を購入し、配備してみたのですが、一向に遅延は改善されません。更に調査を進めていくと、この遅延は弊社で標準利用していたSkypeが原因だという事が判明しました! 大人数でのSkype利用の問題 Skypeは非常に便利なコミュニケーションソフトであり、弊社でも内
さくらインターネット研究所の大久保です。 先日、株式会社ハートビーツさんが主催されている勉強会、hbstudy#27にて弊社クラウドサービスのネットワーク構成について発表を行いましたので、そのご報告です。 今年11月中旬に石狩データセンターの開所にあわせてクラウドサービス(さくらのクラウド)をリリース予定です。 そのネットワークの構築を私の方で担当しており、こちらの勉強会では、ネットワーク全体のアーキテクチャ、ネットワーク機器評価試験の際にはまりやすい(はまった)ポイント、今後の展開について説明をさせていただきました。 発表資料を以下にアップしておりますので、ご興味がありましたらご覧いただければと思います。 → 発表資料:「さくらのクラウド」を例に見るネットワーク仮想化の設計と実装
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
As promised in my netbooting post, here’s an annotated walkthrough of the Linux kernel tuning parameters that we use fairly constantly at Last.fm. Many of these parameters are documented in the files under Documentation/ in a Linux source tree, however it’s generally a pain to find parameters in that mess, so I will distill some of that here. I’ll update this as I learn more. Networking Tuning The
ITは、分かっているようで意外と説明できないことの集合体である。本連載では、IT業界に眠るそれらの謎を文字通り徹底的に調査していく。第1回は、ネットワークの代名詞的な技術といえる100BASE-TXが本当に100Mbpsの速度で通信するのかどうかを調査してみよう。 現在、ネットワークの代名詞的な技術といえば通信速度100Mbpsの100BASE-TXだろう。しかし、100Mbpsということは1秒間に1億ビットもの情報を送っているわけである。規格としてはそうでも、本当に100Mbpsの速度で通信はできているのだろうか? そこで、今回はネットワーク通信速度の鍵を握っているであろうスイッチをターゲットに据え、ネットワーク測定の専門家である東陽テクニカにその疑問を解決すべく調査を依頼した。 ネットワーク機器の性能指標を測れ! 皆さんは、ネットワーク機器といえば何を想像されるだろうか。PCやNAS*
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く