TIME_WAITに関する話
3. 自己紹介 - まぁまぁ MySQL でご飯食べてます - 一時期は Resource Monitoring や KVS にも 力入れてました - ネットワーク的には素人です - Linuxとハードウェアは嗜む程度 - disk I/O にはむかしから興味あります - その他 slideshare はこちら - http://www.slideshare.net/takanorisejima/ 4. 本日のお題 - kernel 新しくしたりすると、TCP的に意識したほ うが良い変化が見つかるので - 今日は、Webアプリケーションサーバの観点か ら、 connect(2) する際に気になる TIME_WAIT について、書いてみようかと思います - 有識者からのマサカリを、強く歓迎いたします 5. 最初に参考資料 - この二つの記事を読んでいただけば、それで概 ね良いと思うんですが
高速にリモートホストのポートがListenしているかを調べる - 人間とウェブの未来
hb.matsumoto-r.jp 以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。 とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。 そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい） そこで一旦、最低限socket()システムコールとconnect()システムコールで接続する時のパケットをtcpdumpで眺
TCP small queues [LWN.net]
Please consider subscribing to LWNSubscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net. The "bufferbloat" problem is the result of excessive buffering in the network stack; it leads to long latencies and poor reliabili
TCP Keepalive HOWTO
This document describes the TCP keepalive implementation in the linux kernel, introduces the overall concept and points to both system configuration and software development. Table of Contents1. Introduction1.1. Copyright and License1.2. Disclaimer1.3. Credits / Contributors1.4. Feedback1.5. Translations2. TCP keepalive overview2.1. What is TCP keepalive?2.2. Why use TCP keepalive?2.3. Checking fo
redir(1): redirect tcp connections - Linux man page
redir(1) - Linux man page Name redir - redirect tcp connections Synopsis redir [--laddr=incoming.ip.address] [--caddr=host] [--debug] [--syslog [--name=str] [--timeout=n] [--bind_addr=my.other.ip.address] [--ftp=type] [--transproxy] [--connect=host:port] --lport=port --cport=port [--bufsize=n] [--max_bandwidth=n] [--random_wait=n] [--wait_in_out=n] redir --inetd [--caddr=host] [--debug] [--syslog]
How TCP backlog works in Linux
When an application puts a socket into LISTEN state using the listen syscall, it needs to specify a backlog for that socket. The backlog is usually described as the limit for the queue of incoming connections. Because of the 3-way handshake used by TCP, an incoming connection goes through an intermediate state SYN RECEIVED before it reaches the ESTABLISHED state and can be returned by the accept s
tcptrackでトラフィックや通信状況をリアルタイム把握 | Pocketstudio.jp log3
◆tcptrackは、いわゆるsnifferの１つ。 「もしかして Dos 攻撃を食らってる？」という時、みなさんどうされています？ Linux サーバの TCP 通信状況を把握するのに、接続元・接続先の把握であれば、netstat を使うのが一般的。より細かな通信状況であれば tcpdump を使うでしょう。ですが、通信状況だけでなく、”転送量”を知りたい場合や、今どこのホストとの通信がサーバの負担になっているかを把握する事は、そうそう単純ではありません。 そんなとき tcptrack を使うのが便利です。tcptrack は、”top” コマンドのように、秒単位で刻々と通信状況を表示することができます。どのホスト間で、どのような通信状態で、アイドル状態の秒数、転送レートを表示することができます。 ◆インストール方法 バイナリまたはソースコードからインストールできます。現行バージョン
TCP keepalive設定でハーフコネクションを解消
２台のサーバ間がTCPハーフコネクション状態になる事象が発生した。 TCP keepalive(キープアライブ)の設定でその状態を解消するための手段をメモしておく。 ◆ 構成 サーバAとサーバB ◆ アプリケーション仕様 サーバAがサーバB上のファイルを定期的に取得する。 両サーバ間はTCPコネクションを張り続けている。通信ごとに接続する仕様ではない。 ◆ トラブル サーバBに障害が発生し、サーバBが突然ダウンした。 そのためサーバBからサーバAへのTCPのクローズ処理が行われず、 サーバAだけにTCPの状態がESTABLISHEDで残るハーフコネクションとなってしまった。 LANケーブルが抜けた場合なども同じ状態になるだろうか。 ハーフコネクションの有無は、サーバA、サーバBでそれぞれ "lsof -n"、"netstat -an" などのコマンドを打ち、状態がESTABLISHEDにな
conntrack がロードされたサーバで LVS-DR を構成する場合の注意点 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。インフラ開発チームの深谷です。 Linux の conntrack モジュールがロードされたサーバーで、レイヤー4 (L4) ロードバランサを LVS-DR で構成したところ、 パケットフィルタが正常に働かず、通信はできるものの、一部のパケットは落ちるという挙動に悩まされました。 今回はこの問題について詳細に解析し、原因と対策がわかったのでご紹介いたします。 発生した問題 今回の問題は、Ubuntu を使って L4 ロードバランサを実装している時に遭遇しました。 構築したロードバランサには、セキュリティ対策のため iptables のラッパーである UFW を使って、 パケットフィルタをかけていました。 ロードバランサの実装には、Linux カーネルに実装されている LVS を使いました。 LVS ではいくつかのパケット転送方式をサポートしており、今回はパフォーマンスに優れる
The SO_REUSEPORT socket option [LWN.net]
This article brought to you by LWN subscribersSubscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible. One of the features merged in the 3.9 development cycle was TCP and UDP support for the SO_REUSEPORT socket option; that support was implemented in a series of patch
Linuxにおけるsyncookiesの実装 - yuya_prestoの古い日記（はてなダイアリーから移行）
あまりにも忙しいので、とりあえず。この記事は後で修正する！ サーバに大量のSYNを送りつけることで、サーバ側で接続待ち状態のコネクションを保持するキューをあふれ返させる（つまりそれ以降の接続要求は破棄される）ことで、接続をしにくくするのが、SYN Flood攻撃。 SYN cookiesとは、この「SYN Flood」攻撃への対策のための仕組みです。 というわけで以下、Linuxでのこの実装に関してコアな感じ。 syncookiesは、初期シーケンス番号や、MSS等をエンコードし、一方向ハッシュ関数でセキュリティを高めて、接続要求元に返すSYN/ACKパケットのシーケンス番号部分につっこんで、接続待ちキューを消費しなくて済むようにする仕組み。 syn queueがいっぱいになった場合， syncookiesが無効であればdropしてしまうところを， syn cookieつきのSYNACKを
Programming UNIX Sockets in C - Frequently Asked Questions: クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問
Previous Next Table of Contents 2. クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問 2.1 相手側のソケットが閉じられたことをどうやって知ることができますか? Andrew Gierth 氏 ( andrew@erlenstar.demon.co.uk) より: 私の知る限り… 相手側が (SO_LINGER を使ったややこしいことをしないで) close() するか終了したとすると、こちらの read() の呼び 出しは 0 を返すはずです。同じ場合で、write() 呼び出しで何が 起こるかは、もうちょっとわかりづらいです。直後の呼び出し時ではな く、その次の呼び出し時にEPIPE が返るでしょう。 もし相手が再起動するか l_onoff = 1, l_linger = 0 を設定して から閉じたとすると、read() からは(
mTCP使ってみた
mTCP enables high-performance userspace TCP/IP stacks by bypassing the kernel and reducing system call overhead. It was shown to achieve up to 25x higher throughput than Linux for short flows. The document discusses porting the iperf benchmark to use mTCP, which required only minor changes. Performance tests found that mTCP-ified iperf achieved similar throughput as Linux iperf for different packe
Linux ftrace TCP Retransmit Tracing
Recent posts: 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netflix End of Series 1 09 Apr 2022 » TensorFlow Library Performance 19 Mar 2022 » Why Don't You Use ... 26 Sep 2021 » The Speed of Time 06 Sep 2021 »
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jp
TCP_DEFER_ACCEPTは、LinuxでサポートされているTCPのオプションで、サーバ側で使用した場合にはaccept(2)からのブロック解除をTCP接続が完了したタイミングではなく最初のデータが到着したタイミングで行ってくれるオプションです。 Webサーバ・アプリケーションサーバではリクエストが到着してからaccept(2)のブロックを解除するので、リクエストの到着をWebサーバ・アプリケーションサーバで待つ必要がなくなり、特にprefork型のサーバでは効率的にプロセスを使えるようになるという利点があります。PerlではStarletがこの機能を有効にしています ところが、某サービスでTCP_DEFER_ACCEPTが有効にも関わらず、accept後のreadでデータが読めず、最悪の場合、デフォルトのtimeoutである5分間プロセスがストールすることがありました。strace
LinuxでTCP_DEFER_ACCEPTが有効でもaccept後readできない理由
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jpという記事の中で、listen backlog があふれた後に accept(2) すると、その後の read(2) が EAGAIN を返したり、接続が不安定になるという事象が説明されていました。気になったので調べてみたことをまとめます。 結論から言うとこれはLinuxの仕様です。manのtcp(7)を見ると、 TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of
「net.ipv4.tcp_tw_recycle」を有効にするのは（場合によっては）やめた方がいい - pullphone's blog
そもそも「tcp_tw_recycle」ってなに？ TIME_WAIT状態のソケット*1を高速に再利用するためのLinuxカーネル特有の仕組みらしい。 「/etc/sysctl.conf」でこいつ（net.ipv4.tcp_tw_recycle）を1にしてやって「sysctl -p」するだけで有効になります。 「TIME_WAITのソケットを少なくしてくれるんでしょ？いいじゃん！」という感じで設定してしまいそうになりますが・・・ なんでダメなの？ 結論から言うと、こいつを有効にしたとき、同じグローバルIPのクライアントからの接続でかつTCPパケットにタイムスタンプ情報が入っている場合で、ほぼ同時にパケットを送ると、古いタイムスタンプの方のパケットを勝手にドロップしちゃいます。 どういうことなの・・・ 「tcp_tw_recycle」は、「同一IPからのパケットが到着したとき、使っていたソケ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tcp_bbr: add BBR congestion control · torvalds/linux@0f8782e
91精品一区_国产一级强 片在线观看AV_亚洲精品无码午夜福利中文字幕_久久久久精品国产免费
https://github.com/hiboma/hiboma/blob/master/kernel/net/net-backlog.md
