TCPパケットを解析して構造化ログでダンプするツール tcpdp を作った - Copy/Cut/Paste/Hatena
やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ
tcp_tw_なんとかの違い - Qiita
自分用の覚書です。CentOS5とか6とかでの経験。 実際高負荷だとか負荷試験ツールで出ただとかのTIME_WAITを減らしたいというときに、 syctlで、tcp_なんとかを調整するというのは今ではよくあると思います。 （わたしはむかし運用していた某無料サイトで負荷に悩んだのが切欠で知りました。無料というだけで会員数激増的な風潮だったのと素行の悪い某国のクローラーとかrewriteのループとかの色々な芸の肥やし的な機会がというか夜中に起こされて眠りを妨げられたくなかったので色々調べたりしていました。） いっぱい接続したいの - (ひ)メモ Linux - ぜんぶTIME_WAITのせいだ！ - Qiita ・TCPの終了待ちタイムアウト秒数を設定（default60sec) net.ipv4.tcp_fin_timeout = 10 ソケットを強制的にクローズする前に、最後のFINパケッ
Tips:ネットワークあたりのトピックス
MSS(MaximumSegmentSize：最大セグメントサイズ） MTU(MaximumTransmissionUnit) MSSはTCP/IPにおいて1セグメントで送信できる最大サイズ。IPヘッダ（20バイト）、TCPヘッダ（20バイト）は含まない。 MTUは1回の転送(1フレーム）で転送できる最大サイズ。 となる。ちなみにRWIN ( Receive Window Size ) は、ACKを待たずに送信できるサイズ。受信側のバッファサイズとなる。 Nagleアルゴリズム IPヘッダーやTCPヘッダーのオーバーヘッドを軽減することが目的。よくある例は、telnetのように1バイトずつ送信するような場合、実際にはこの1バイトにに対してIPヘッダー20バイト、TCPヘッダー20バイトが付き、計41バイト送付することになり、伝送効率が非常に悪くなる（「小さなパケット問題」）。 Nagleア
NagleアルゴリズムとDelayed Ack問題: じーくゎい
技術系、非技術系のネタを書き散らしてます。ちなみに、じーくゎいとは子供が赤ん坊の頃によく叫んでいた謎の言葉です。 TCP の世界で、Nagle アルゴリズムと Delayed Ack が組み合わさった時の 問題は結構有名な話。 ネットワークソフトウェアエンジニアのバイブル UNIXネットワークプログラミング〈Vol.1〉 にもしっかりと載っている。 簡単に説明しておくと、 Nagleアルゴリズム 送信データ（セグメント）をOSが溜め込む。溜め込んだデータを送信するタイミングは下記の通り。 OS（TCP）の気持ちも書いておく。 * すでに送信しているデータのAckが返るまで。 → お、さっき送ったデータのAckを受け取ったぞ。 じゃあ次のデータを相手に送ってやらなきゃ。 * 溜め込んでいるデータ量がMSSを超えるまで。 → やべ、データをたくさん（量的に）溜め込みすぎた。 * タイムアウトを
TCPIP/TIME_WAIT状態ソケットの強制終了 | Tipi
netstatで見たソケットの通信状態がESTABLISHEDではなくTIME_WAITで止まってしまっているような場合に、その通信を強制的に終了させるためのツール「killcx」がsourceforgeで公開されています。 Killcx : close a TCP connection (for Linux) wKillcx : close a TCP connection (for Windows) 原理は「偽の終了パケットを作ってやって、それを投げてやる」というものです。 Windows版もインストールせずに実行ファイルを置くだけで利用できます。 IPアドレスを指定することで、他のマシンのソケットを終了させることもできます。 ソケットの通信状態がTIME_WAITで止まってしまってる場合の例は下記のようなときです。 Apache+Tomcatで構築したサーブレットをクライアントからア
Windowsネットワーク 第16...＠IT：連載 基礎から学ぶ
第16回 信頼性のある通信を実現するTCPプロトコル（3）：基礎から学ぶWindowsネットワーク（3/4 ページ） TCP技術を習得するうえで非常に重要な項目として、「TCPの状態遷移図」というものがある。これはTCPプロトコルの規格書であるRFC793（STD0007）に掲載されている、TCPプロトコルの内部ステートを表現した図である。すでに解説したように、TCPでは接続ごとに、それぞれシーケンス番号やACK番号、オープン／クローズなどの処理状態といった「ステート（状態）」を持っている。このようなプロトコルを「ステートフルな（stateful、状態を持つ）」プロトコルという。TCP接続のオープンやクローズ、確立などに伴う、状態の変化を表現した図を「状態遷移図」という。 以下は、RFC793に記載されているTCPの状態遷移図を簡略化したものである（完全な状態遷移図についてはRFC793を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
