Macで無線LANが遅い問題を解消する方法 | ミネルヴァの梟は黄昏とともに飛び始める（山下 大介 公式ブログ）
はてぶの人気エントリー入りしたようで、補足。 私自身、こんなんで速くなるわけねーよ！と思っていたのでデータ取りしていませんでしたが、私の記事を読んでデータ取りしてくれた人がいました。結果は劇的に改善されたようです。Twitterを見ると多くの環境で効果があったようです。 あと、はてぶを見ていると１名遅くなったという人がいらっしゃいましたが、ネットワークに関するパケットサイズなどをチューニングしている人や無線LAN専用の圧縮ソフトを導入されている方は設定が消えることで遅くなる可能性があると思います。普段は初心者がまぎれ込むようなブログではないので、注意書きをしていませんでしたが、PCの設定は自己責任でお願いします。 最近、無線LAN経由でインターネットをすると遅くておかしいなと思って色々調べてみました。 すごく嘘くさいけど、ネットワーク設定を作り直すだけで速くなるとネットに書かれていたので試
『モバイル等のナローバンドとTCP/IPコネクション接続時間』
もと東大生もと社長の自由奔放ブログ Just do it now! もと東大生、もと社長の経歴をもつもとくんの自由奔放な生き方を 自由奔放に綴ったブログです。 樹海の中を真っ直ぐ進むもとの楽しい生き様をお楽しみください。 前回、Firefox高速化～TCP/IPを理解して、さらに速くなったfirefoxを高速化！にて TCP/IPを一通り理解したつもりでした。 その時、ふと疑問が…。 モバイルの接続って、もしかして大量のTCP/IPのコネクションを生み出す の原因になり得る？ 通信速度が遅いと、TCP/IPのコネクション接続時間が長くなる？ 途中で通信が切れると再送信される？ でもプロキシがあるし・・・？？？ その場では放置しましたが、きちんと調べてみました。 静的コンテンツに関しては、各キャリアのプロキシサーバが この問題のクッションになるようです。 ところがところが、動的コンテンツの場
『Firefox高速化～TCP/IPを理解して、さらに速くなったfirefoxを高速化！』
もと東大生もと社長の自由奔放ブログ Just do it now! もと東大生、もと社長の経歴をもつもとくんの自由奔放な生き方を 自由奔放に綴ったブログです。 樹海の中を真っ直ぐ進むもとの楽しい生き様をお楽しみください。 [Webシステム] ブログ村キーワード 前回の、Firefox高速化～早くなったFirefoxをさらに高速化してみるの続きです。 これまでの記事 Firefoxの仕組みを理解して重いブラウザをスピードアップ！ Firefox高速化～早くなったFirefoxをさらに高速化してみる TCP/IPについて httpやTCP/IPについて、一通り理解しているつもりでいましたが、 実はよく分かってないことが分かりました。 というわけで、ネットワークについて1からお勉強。 あれ？これって、さらにfirefox速くできる？ と密かな期待を抱きつつ。 中途半端な知識はよくないです。 今回
Geekなぺーじ : IPv4アドレス枯渇。その意味と恐らくこれから起きること
今のインターネットはIPバージョン4で動作していますが、そのIPv4で各機器を識別するためのIPv4アドレスが遂に事実上枯渇しました(参考)。 長年「枯渇する」と言われ続けていましたが、それが遂に現実の物となりました。 ここでは、IPv4アドレス枯渇とは何かと、それによって何が起きるのかを紹介します。 IPv4アドレス枯渇に関して、アナログ放送の停波と地デジへの移行や、原油枯渇と似たようなものであるような認識が多く見られますが、個人的にはIPv4アドレス枯渇後のIPv4アドレスのアナロジー(類比)としては相撲の親方株の方が近い気がしています。 まず、アナログ放送の停波と地デジへの移行ですが、アナログ放送は2011年7月に一斉に停止します。 しかし、IPv4アドレスの場合は、ある日突然IPv4が使えなくなるわけではなく、今まで使っているIPv4アドレスはそのまま使い続けられるという意味でアナ
TCP勉強会始めました | GREE Engineering
こんにちは、グリーで運用に携わっているhiromi.kaiと申します。よろしくお願い致します。 最近、私たちのチームではTCPの勉強会を始めました。講師は本ブログにも記事を書かれているebisawa先生です！ そもそもなぜTCPの勉強会？と思われる方もいらっしゃると思いますが、グリーのサービスを運用している際に直面するトラブルには、TCPプロトコルに関する詳細や実装がわかっていないと対応できない、難易度の高いものもあるからです。そのような難しいトラブルにも、対応できる人員を増やそう、ということで、勉強会を開く運びになりました。 第1回サマリ 第1回はTCPのプロトコルの説明で、主にTCPの信頼性確保の仕組みや、ヘッダの解説などがありました。 簡単にサマライズすると、以下のような内容です。 イーサネットやIPヘッダにも誤り検出の仕組みがあるのに、なぜTCPヘッダにもチェックサムがあるのか？
＠IT：Snortでつくる不正侵入検知システム 第1回
※ご注意 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 「IDS」という言葉をご存じだろうか。IDSとは「Intrusion Detection System」の略で、日本語では「侵入検知システム」と訳される。この連載ではフリーのIDSであるSnortを題材に、IDSのインストールから運用までを解説していきたいと思う。 IDSとは何か 「IDSとは一体何なのか」。そう疑問に思った方は少なくないであろう。簡単にいえば、「ネットワークを流れるパケットに対してあるパターンに合致しているか否かを判定し、合致している場合はあらかじめ定められた処理を行う」ものである。 「あらかじめ定められた処理」とは具体的にどのような処理なのかというと、
Poundで作るロードバランサとSSLラッパ（1/4） ― ＠IT
Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。（編集部） Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの
＠IT：パケットフローから負荷分散の基本を理解する
サーバ負荷分散の基本構成と動作 負荷分散装置（ロードバランサ）のニーズは現在も高まる一方です。従来はWebサーバのみを主な対象としていましたが、現在ではルータ#1／アプリケーションサーバ／メールサーバ／SIPサーバ／ファイアウォール／VPNゲートウェイ／ウイルスゲートウェイ／IDSなど、多種多様の機器やプロトコルが負荷分散の対象となっています。それに応じてロードバランサも現在では非常に多機能となっていますが、本連載では、全3回に渡ってアプリケーションベースではなく、ネットワークベースの技術、基本となるパケットフローやサーバヘルスチェック、接続維持などの動作について紹介します。また、パフォーマンス測定についてもお話ししましょう。 #1 ルータはレイヤ3でインターネット回線のマルチホーミングとして機能する（＝複数のWAN回線を接続して、同時に通信させることで負荷分散し、必要な帯域を確保するし、
Windows 7ネットワーク事始め
Windowsネットワークは、その使いやすさが最大の特徴である。ネットワークにつないで、メニューやアイコンを順にたどっていけば、ネットワーク上のファイルやプリンタを簡単に利用できる。自分のパソコンのファイルやフォルダを、他のユーザーに公開することも簡単だ。 従来環境との互換性を確保しながら通信する このWindowsネットワークの使いやすさは、最新OSのWindows 7を含めて、どのWindowsを使っていても変わらない。これらのWindows 7と、その前のWindows Vista、さらにはWindows XPなどのパソコンを同じネットワーク上に混在させても、そうしたOSの違いを意識せずに同じように利用できる。たとえば、それまではWindows XPしか使っていなかったようなネットワークに、Windows 7を参加させてもほかのパソコンからは今までのXPパソコンと同じように見える（図
Big Sky :: select(2)の第一引数にディスクリプタの最大値を渡すのは間違い？
追記 POSIX では明確にソケットの最大値とはうたってはいないものの、Linux の実装を見ても最大値と扱う方が良い様です。また Winsock では select(2) の第一引数は無視されるようです。 C言語でソケットを使うプログラミングを行う際、ソケットディスクリプタがシグナル状態かを調べる方法としてselect(2)があります。 使い方は int r; fd_set rfds; FD_ZERO(&rfds); FD_SET(sock, &rfds); r = select(1, &rfds, NULL, NULL, NULL); といった感じ。ここでselect(2)の第一引数に渡している値は、ディスクリプタ集合rfdsの内、いくつ検証するかを指す値。つまりrfdsに対してFD_ZERO/FD_CLRしてからFD_SETした回数となります。 ちなみに戻り値は、ディスクリプタ集合の
Socket FAQ
【質問】 たまに、受信したレコードの最後が途中で切れていることがあります。どうしてでしょうか？ 【回答】 SNA であればフレーム単位の伝送なのでこのようなことは起こりませんが、TCPIP はバイト単位で伝送を行います。 そのため、伝送中にレコードが複数のパケットに分割され、受信したバッファーにレコードの途中までしか入っていない事が あります。 つまり、400 バイトのレコードを send() し、400 バイトの Buffer 長を指定して recv() を行ったとしても、１回の recv() で、400 バイト全てのデータがとれる保証はありません。 800 バイトの Buffer 長を指定して recv() を行うと、２回分のレコードが１回の recv() で受信できるかもしれません。 固定長データの送受信ならば、受信したあとに足りないバイト数分の recv() を再度実行するようにコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
