A reworked TCP zero-copy receive API [LWN.net]
LWN.net needs you!Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing In April, LWN looked at the new API for zero-copy reception of TCP data that had been merged into the net-next tree for the 4.18 development cycle. After that article was written, a couple of issues came to the fore that required some changes to the AP
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. 最初に参考資料 - この二つの記事を読んでいただけば、それで概 ね良いと思うんですが
Why do we use the Linux kernel's TCP stack?
I’m at PolyConf in Poland today, and I watched this super interesting talk by Leandro Pereira about Lwan, an ~8000 line of code web server. He talked about a bunch of the optimizations they’d done (improve CPU cache performance! be really careful about locking!). You can read more about the performance on the website & the links there. It’s a super cool project because it started out as a hobby pr
TCP small queues [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. The "bufferbloat" problem is the result of excessive buffering in the network stack; it leads to long latencies and poor reliability in the network as a whole. Fixin
Userspace networking
Seven years ago at LCA, Van Jacobsen introduced the concept of net channels but since then the concept of user mode networking has not hit the mainstream. There are several different user mode networking environments: Intel DPDK, BSD netmap, and Solarflare OpenOnload. Each of these provides higher performance than standard Linux kernel networking; but also creates new problems. This talk will expl
Why protocol stacks should be in user-space?
Why protocol stacks should be in user-space? Michio Honda (NEC Europe), JoaoTaveira Araujo (UCL), Luigi Rizzo (Universitea de Pisa), Costin Raiciu (Universitea Buchalest) Felipe Huici (NEC Europe) IETF87 MPTCP WG July 30, 2013 Berlin Motivation • Extending layer 4 functionality addresses a lot of problems – Increased performance • MPTCP, WindowScale, FastOpen,TLP, PRR – Ubiquitous encryption • Tcp
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
tcp/dccp: lockless listener [LWN.net]
netdev <netdev@vger.kernel.org>, Eric Dumazet <edumazet@google.com>, Ying Cai <ycai@google.com>, Willem de Bruijn <willemb@google.com>, Eric Dumazet <eric.dumazet@gmail.com> TCP listener refactoring : this is becoming interesting ! This patch series takes the steps to use normal TCP/DCCP ehash table to store SYN_RECV requests, instead of the private per-listener hash table we had until now. SYNACK
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
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]
Benefits for LWN subscribersThe primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today! 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 seri
mTCP使ってみた
Grafana LokiではじめるKubernetesロギングハンズオン（NTT Tech Conference #4 ハンズオン資料）
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からのパケットが到着したとき、使っていたソケ
LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.kernel.org/doc/Documentation/networking/proc_net_tcp.txt
User-space Network Processing
https://github.com/hiboma/hiboma/blob/master/kernel/net/net-backlog.md
