Linux の TCP/IP チューニング・パラメータ
TCP のチューニング・パラメータ 接続確立関係のチューニング・パラメータ TCP のチューニング・パラメータ TCP のチューニング・パラメータは、以下のコマンドで取得できます。 なお、以下は Linux のものです。 >cat /proc/sys/net/ipv4/tcp_retrans_collapse 1 >cat /proc/sys/net/ipv4/tcp_keepalive_probes 9 >cat /proc/sys/net/ipv4/tcp_keepalive_time 10800 >cat /proc/sys/net/ipv4/tcp_syn_retries 10 >cat /proc/sys/net/ipv4/tcp_sack 1 >cat /proc/sys/net/ipv4/tcp_timestamps 1 >cat /proc/sys/net/ipv4/tcp
Linux：OSのtcpタイムアウトのデフォルト値について - HiiHahWIKI - making some notes for... -
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を送信するリトライ回数みたいで、以下のロジックでリト
TCPコネクションの確立＆切断 - いろいろ解析日記
TCPコネクションの確立＆切断は、３ウェイハンドシェイク(３つのパケットのやり取り)で行われます。なお、実際のデータ送信はコネクションが確立された後に行われます。 目次 コネクション確立成功 コネクション確立失敗 コネクション切断 ■コネクション確立成功 相手ホストの準備ができている場合、３ウェイハンドシェイクが行われてコネクションが確立されます。 (1)SYNパケット 最初に、フラグが「SYN」のパケットを送信します。 (2)SYN・ACKパケット 次に、相手ホストからフラグが「SYN・ACK」のパケットが返信されます。 (3)ACKパケット 最後に、フラグが「ACK」のパケットを送信します。 ■コネクション確立失敗 相手ホストの準備ができていない場合、RES・ACKパケットが返されてコネクション確立は失敗します。 (1)SYNパケット 最初に、フラグが「SYN」のパケットを送信します。
TCP Tune
Enabling High Performance Data Transfers System Specific Notes for System Administrators (and Privileged Users) These notes are intended to help users and system administrators maximize TCP/IP performance on their computer systems. They summarize all of the end-system (computer system) network tuning issues including a tutorial on TCP tuning and easy configuration checks for non-experts. Introduct
高負荷マシンのネットワークチューニング — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
第2回 TCP/IP高速化：大量データをまとめて送信
高速化技術を理解するには，基本となるもともとのTCP/IP技術を押さえておく必要がある。TCP/IPのスループットは理論上，「1パケットで受信できるデータ量（RWIN）÷1パケットの受信が完了するまでの遅延時間（RTT）」で求められる。LinuxやWindows 2000 SP3以降の主要なOSは，TCP仕様の最大値64Kバイト（512kビット）をRWINとして設定する。RTTが20ミリ秒だとすると，スループットは最大約25Mビット/秒となる。 この環境で100Mビット/秒の帯域を占有できるとすれば，約25Mビット/秒では遅い。つまり，もともとのTCP/IPでは力不足というわけだ。その最大の理由は，TCP通信の「フロー制御」と「輻輳制御」の仕組みにある。 大量データをまとめて送信 フロー制御から説明しよう。これは確実にデータを送信する機構のことで，TCP通信の基本である。TCPは，送信デー
【レポート】TCP/IPスタックをユーザランドで動かすNetBSD Rump - AsiaBSDCon 2009 | エンタープライズ | マイコミジャーナル
2009年3月12日から15日までの4日間、東京において「AsiaBSDCon 2009」が開催された。本誌では、同カンファレンスの中から特に興味深いセッションをピックアップしてお伝えする。 TCP/IPネットワークスタックをユーザランドへ サブシステムをどこまでカーネルランドに置くか、どこからはユーザランドに置くかというのはバランス感覚を要求される部分だ。カーネルランドとユーザランドにはそれぞれ特徴がある。実際に特権モードでの動作が要求されるのは一部の限られた処理でしかないのだが、大抵の場合はそれ以外の関連部分もカーネルランドに取り込まれる。しかしカーネルランドに依存させすぎると開発が困難になるという弊害もある。このあたりはトレードオフの関係にある。 Antti Kantee氏 - The NetBSD Project *BSDではネットワークスタックはカーネルランドに置かれていることが
Winsock Programmer's FAQ: Winsock初心者のための情報
2.1 - ネット上で入手できるサンプルプログラムはありますか? はい。情報源のページにいくつか、ま た、FAQ の サンプルプログラムの章にもさ らにいくつかリストアップされています。まだ Winsock を始めたばかりであれば、 特に こちらの例が有用でしょう。 2.2 - WSAStartup 呼び出しの前に WSAData 構造体を初期化する必要はあるのですか? いいえ、WSAStartup() 自身が必要なデータを埋めてくれます。 2.3 - Winsock プログラムをコンパイルしようとするとリンクエラーが出ちゃいました。何が悪いんでしょう? おそらく、正しい Winsock インポートライブラリをリンクしていないのでしょ う。16bit の Windows システムでは、winsock.lib が正しいライブラリです。 32bit Windows システムで Winsock
artima - Comparing Two High-Performance I/O Design Patterns
This article investigates and compares different design patterns of high performance TCP-based servers. In addition to existing approaches, it proposes a scalable single-codebase, multi-platform solution (with code examples) and describes its fine-tuning on different platforms. It also compares performance of Java, C# and C++ implementations of proposed and existing solutions. System I/O can be bl
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
Re はやいTCPサーバの書き方 - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ について、いくつか気になった点があったので。 Nagleアルゴリズムは、相手側のACK送信をまとめてくれるものです。これは、下記の様にアプリケーション側でパケットを意識した処理を行っている場合、邪魔になることがあります。 違うと思います。自分の理解では、Nagle アルゴリズムは、ACK を受信していないデータがある場合に、次のパケットを送信しない、というものです。RFC896 から引用すると、 The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unackn
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
第14回 TCPとUDP
前回は，現在のネットワークの基盤をなすネットワーク・プロトコルであるIP（Internet Protocol）と，LinuxカーネルのIPプロトコル・スタックについて解説しました。 IPというプロトコルでは，2点間のデータ通信の方法しか定義していません。例えば，送信元が送ったデータが送信先に届いていなくてもIPでは関知しません。あくまで，このホストからこのホストにデータを送るにはこうすればいい，ということだけ規定してあるのです。つまり，細かい通信の制御や信頼性確保などは別のレイヤー（トランスポート層）で実施することになります。 IPネットワークで利用される代表的なトランスポート層プロトコルが，「TCP」（Transmission Control Protocol）と「UDP」（User Datagram Protorol）です＊1。 UDPは，IPをほとんどそのまま利用するだけのプロトコル
Daytime.1 - A synchronous TCP daytime client - 1.36.0
Boost C++ Libraries ...one of the most highly regarded and expertly designed C++ library projects in the world. — Herb Sutter and Andrei Alexandrescu, C++ Coding Standards This tutorial program shows how to use asio to implement a client application with TCP. We start by including the necessary header files. #include <iostream> #include <boost/array.hpp> #include <boost/asio.hpp> The purpose of th
Netzwerkprogrammierung
ネットワークプログラミングの超基礎 とある科目のレポートで、基本を理解せずにサンプルプログラムをいじくっている 学生があまりに多いのを見てしまい、見るに見かねてこんな文書を書いてみました。 「超基礎」なので本当に基本の基本しか扱いません。 stream (TCP) のみを扱います。 間違ってるところとか見つけたら教えて下さい。 まえがき ネットワークプログラミングでハマりやすいのは、たぶん、 下準備が多く、何をやっているか分からない (そもそもどこが下準備なのかも分からない) 結局のところ、どこが本質なのか分かりにくい といったあたりにあるのではないでしょうか。 ということで、まずその辺をはっきりさせるために、 通信を行うための必要最小限のプログラムで、その骨格を見てみることにしましょう。 Inhalt (Table of Contents) 簡単なクライアントプログラム 簡単なサーバプロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
404 Not Found - 云顶集团_云顶国际娱乐4008_【www.4008.com】
http://irc.nyaxtstep.com/lowhacks/2009.01.16.txt
IBM Developer
hpフォーラム HP-UX>システム管理
「TCPの再送処理について」（1） Master of IP Network － ＠IT