タグ

TCPとLinuxに関するclavierのブックマーク (32)

  • 【TCP】linuxで取れるtcpのメトリクスを理解していく記事 - 地方エンジニアの学習日記

    /proc/net/netstatを頑張って理解していく。ドキュメントないものをどうやって調べていくかはちょっと悩む... netstat グラフに出てくる項目 概要 TcpExtSyncookiesSent tcp.syncookies.sent 送信されるSYNクッキーの数 TcpExtSyncookiesRecv tcp.syncookies.recv TCPスタックが受信するSYNCookieの応答パケットの数 TcpExtSyncookiesFailed tcp.syncookies.failed SYNCookieからデコードされたMSSが無効 TcpExtEmbryonicRsts tcp.misc_errors.embryonic_rsts SYN_RECV状態の接続に対して受信された無効なパケット TcpExtPruneCalled tcp.misc_errors.pru

    【TCP】linuxで取れるtcpのメトリクスを理解していく記事 - 地方エンジニアの学習日記
  • Socket migration for SO_REUSEPORT (Part 1) - Kuniyuki Iwashima

    TCP ソケットと `SO_REUSEPORT` オプションに関する問題を解決するために Linux カーネル v5.14 から取り込まれる予定のパッチセットについて 2 回に分けて解説します。 - https://lore.kernel.org/bpf/20210612123224.12525-1-kuniyu@amazon.co.jp/ - https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=1f26622b791b6a1b346d1dfd9d04450e20af0f41 Part 1 では `SO_REUSEPORT` オプション、カーネルの挙動と問題点、パッチセットの効果について解説し、 Part 2 ではカーネルの実装と修正方法、追加した eBPF の機能について解説します。 ##

    Socket migration for SO_REUSEPORT (Part 1) - Kuniyuki Iwashima
  • あなたのネットワークスタック正しく設定されていますか? - Qiita

    はじめに Linux Advent Calendar 10 日目の記事です。 運用や研究開発の現場では、ソフトウェアの実験、または機器のテストや選定などのために、ベンチマークツールや自前のアプリケーションでコンピュータ間の通信速度を計測する機会が多々あると思います。一方で10Gbpsや40Gbpsといった昨今の高速ネットワークにおいては、これらの計測結果はアプリケーションの通信API部分の実装、カーネルパラメータまたはコンパイルオプションによって大きく変わってしまうため、正確な計測を行うためにはこれらを正しく設定/理解する必要があります。この記事では、ネットワーク周りのカーネルとアプリケーションの動作の概要と、その中の重要なポイントを理解することを目的にします。 ネットワークプログラミングのおさらい まず最初に、TCPを使う今時のサーバプログラムがどのようにできているか簡単におさらいします

    あなたのネットワークスタック正しく設定されていますか? - Qiita
  • netstatコマンドを高速化する - Qiita

    はじめに Linuxカーネルとnetstatコマンドをちょこっとだけ改造したらnetstatコマンドが早くなった、というお話です。 概要 netstatコマンドは、TCPセッションについての情報をカーネルから取得する際には/proc/net/tcpという特殊なファイル1を参照している IPv4では/proc/net/tcp、IPv6については/proc/net/tcp6と別のファイルに分かれているが、都度併記するとややこしいので以降は/proc/net/tcpと表記する procfsは内部でseqファイルシステムという仕組みを利用している seqファイルシステムについてはこちらにまとめられている seqファイルシステムについて - Qiita seqファイルシステムを利用した特殊なファイルに対してreadシステムコールを実行した際、通常はカーネル側で確保されたPAGE_SIZE(多くの環境

    netstatコマンドを高速化する - Qiita
  • net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita

    Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 文中で Linux のコード/ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう(というかできません)。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ

    net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
  • IPVS のセッション同期パケットを作って送ろう - Qiita

    IPVS について LVS Project には IPVS 以外にも KTCPVS などのソフトウェアがありますが、現在では LVS (Linux Virtual Server) と言うとほぼ IPVS のことを指しているように思います。 IPVS は Linux でロードバランサを構築するためソフトウェアで、Linux kernel 内部に実装されています。 基的に L4 まで の情報を見てパケットをリアルサーバに転送するものです。 (FTP や SIP など、一部アプリケーションは上位レイヤの処理もできます) ipvsadm コマンドで設定を変更することもできますが、番環境で利用する場合はヘルスチェックや HA などを求めて keepalived から IPVS を使うことが多いと思います。 ここでは IPVS におけるセッション同期の話題を主とします。 LVS (IPVS) 自体

    IPVS のセッション同期パケットを作って送ろう - Qiita
  • Linux Kernel 3.0以降について調べてみた - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 長いので太字で要点 絞るためにGPU、仮想関係は省いてます。 NWが長くなったので分割 http://qiita.com/bringer1092/items/b6cd96a7f7db7121e8a7 I/Oが長くなったので分割 http://qiita.com/bringer1092/items/4a62ec6ab62b896ab611 #ハードウェアサポート ##4.6 USB 3.1 SuperSpeedPlus (10 Gbps) support USB3.1のサポート SuperSpeedPlus (10 Gbps)サポート #

    Linux Kernel 3.0以降について調べてみた - Qiita
  • サーバーに接続できない->TIME_WAITが大量にポートを食い尽くしてる

    B! 27 0 0 0 ちょっと使ってるサーバー側で プログラムが暴走して外からソケット通信出来ない、 みたいなエラーが出てた時にやったことのメモ。 ソケット通信が出来ない原因の犯人はTIME_WAIT ソケット通信が出来ない原因の犯人はTIME_WAIT とあるサーバーにアプリを使ってアクセスしようとしたら ソケットが開けない、と言ったエラーが出ました。 ざっと見サーバー側もおかしなことが起こってないような感じでしたが、 $ netstat -anp としてみると、大量の tcp 0 0 192.0.2.0:50000 192.0.2.0:39210 TIME_WAIT みたいなTIME_WAITな物が出てました。 ここで、50000が実際サーバー側で使ってるTCPサーバーなプログラムが 使ってるポートです。 なんか暴走して沢山開こうとしているみたい。 プログラムを再起動してみると、最初

    サーバーに接続できない->TIME_WAITが大量にポートを食い尽くしてる
  • TCPとタイムアウトと私 - Cybozu Inside Out | サイボウズエンジニアのブログ

    部長や副部長もプログラミングを(たまに)することで有名なサイボウズの運用部長、山泰宇です。 有名じゃないかもしれませんが、ブログに書いたので有名になるということでご了承ください。 今回は、先日発生した yrmcds に起因する障害の原因と対策を解説します。 yrmcds というのは、サイボウズが開発している memcached 互換のキーバリューストレージです。 問題の理解のため、まず TCP 通信で、通信先の相手の障害にどう対応するか解説します。 データの送信中に相手が落ちるケース このケースはさらに二つに分かれます。 相手の OS は生きているが、通信しているプログラムが落ちるケース 相手の OS ごと(あるいはネットワークごと)落ちるケース 1 と 2 の違いは、前者の場合 RST パケットが返ってくるのに対して、後者ではなにも返ってこない点です。後者の場合、ack されない

    TCPとタイムアウトと私 - Cybozu Inside Out | サイボウズエンジニアのブログ
  • 5分で出来るお手軽メール転送サーバ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    5分で出来るお手軽メール転送サーバ - Qiita
  • TCP Slow Start と MSS, initcwnd などのメモ

    現実的な値と根拠など Slow Start などの例に良く出てくる数字の論拠と、個々の単位がどこで決まってくるかを主に取り扱う。というメモ。苦手科目だ。_:(´ཀ`」 ∠): Max Segment Size (MSS) の決定 この MSS がウインドウサイズ(一度に転送するデータサイズ)の単位として扱われる。(後述) TCP コネクションが 3-way handshake によって確立される際、ノード間で下記のような MSS に関するやり取りが発生する。 各ノードは Maximum Transmission Unit (MTU) から TCPヘッダ20バイト、IPヘッダ20バイトの計40バイトを引いた値を MSS として提示する 各ノードの希望 MSS のうち低い方を、そのコネクションにおける MSS とする たとえばイーサネットでは最大1,500バイト(オクテット)がIP通信に利用で

    TCP Slow Start と MSS, initcwnd などのメモ
  • mTCP使ってみた

    May 15, 201458 likes15,901 viewsAI-enhanced description 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 achiev

    mTCP使ってみた
  • Pythonのsocketでプロセス間通信をして価格データ等を送信する

    どうも、お久しぶりです。キリンです。 取り敢えず1ヶ月ほど、連続でブログの更新を続けてみたのですが、それ以降更新が途絶えてしまっていました。業(FXの運用)のほうが今鳴かず飛ばずなので、なんとか盛り返そうと頑張ってます。 その中で、どうしてもプロセス間通信(IPC, Inter Process Communication)をしなければならない事案に遭遇してしまったので、忘備録も兼ねてPythonでSocketを使ったプロセス間通信の方法を調べる際に学習したことと、実際に作成したプログラムをご紹介します。きちんとTCP/IPの通信について勉強したわけではないので、間違った理解、解釈があるかと思います。その際はご指導いただけると助かります。 プロセス間通信がしたい Linux上でしか動かないPythonライブラリ Linux上でしか動かないPythonのライブラリをどうしても使いたいという事

    Pythonのsocketでプロセス間通信をして価格データ等を送信する
  • ぜんぶTIME_WAITのせいだ! - Qiita

    課題 突然キャンペーンとかの高トラフィックが来る!とか言われると色々困ることはあるものの、今のご時世クラウドだからスペック上げときゃなんとかなるでしょ。ってとりあえずCPUとかメモリあげて見たものの、キャンペーンが始まったら意外と早くブラウザからつながらない!!とか言われたりする。 CPUもメモリもそんなに負荷は特に高くもない。調べてみたらTIME_WAITが大量にあった。 とりあえず何とかしたい TIME_WAIT数をコマンドで確認 $ netstat -anp|grep TIME_WAIT __(snip)__ tcp 0 0 192.168.1.1:80 192.97.67.192:56305 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.63.64.145:65274 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.39

    ぜんぶTIME_WAITのせいだ! - Qiita
  • Ethernetの受信処理

    Video: https://www.youtube.com/watch?v=JRFNIKUROPE . Talk for linux.conf.au 2017 (LCA2017) by Brendan Gregg, about Linux enhanced BPF (eBPF). Abstract: A world of new capabilities is emerging for the Linux 4.x series, thanks to enhancements that have been included in Linux for to Berkeley Packet Filter (BPF): an in-kernel virtual machine that can execute user space-defined programs. It is finding

    Ethernetの受信処理
  • 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

  • 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

  • Coping with the TCP TIME-WAIT state on busy Linux servers | Vincent Bernat

    TL;DR Do not enable net.ipv4.tcp_tw_recycle—it doesn’t even exist anymore since Linux 4.12. Most of the time, TIME-WAIT sockets are harmless. Otherwise, jump to the summary for the recommended solutions. The Linux kernel documentation is not very helpful about what net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse do. This lack of documentation opens the path to numerous tuning guides advising to

  • Multipath TCPについて

    Multipath TCPとは、複数の経路を扱うためのTCP拡張である。実は、以前、の虫: MultiPath TCPのLinuxカーネル実装という記事で、その実装デモを紹介している。 従来のTCPは、IPとの分離ができない。TCPヘッダーの中には、ひとつのIPアドレスとポートがある。経路ごとにIPアドレスが割り振られるので、経路を変えるには、別のTCPコネクションを貼り直さなければならない。 しかし、複数の通信経路を持つという環境は、もはや珍しいものでも何でもなくなっている。たとえば、多くのラップトップにはEthernetとWiFiの二つの経路があるし、スマートフォンにも、WiFiと3G/4Gという複数の経路がある。特にスマートフォンの場合、経路が使えるかどうかが頻繁に切り替わる。 過去に、TCPで複数のIPアドレスを扱う拡張はいくつも出されたが、いずれも、IPアドレスを隠すという点で

  • TCP Fast Openを試してみる - milieuの日記

    kernel3.8がリリースされてついにTCP Fast Openがクライアント、サーバサイド共に実装さた。カーネルのソースを見てみるとやはり結構な変更でpatchで2000行レベルらしく、これ仕事で実装したくないなーというかバグを出す自信があるというのが正直な感想だが、とりあえず動作概要ぐらいは知っておかないとまずいので遊んでみた。TCP Fast Openの認証?部分でAESを使うらしくSandy BridgeならAES-NIを使えばCPU負荷的に問題ないかとか調べたかったが、家で使用しているPCCPUが残念ながらWestmereなのでそれは諦めた。動かすにあたりFedora18を用意しないと!と思いたちVM環境にインストール。そういえばFedora18がリリースされた当初はVMwareにインストールを試みたが失敗したという苦い記憶が蘇えったが、今回はVirtualboxだったおかげ