/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 ソケットと `SO_REUSEPORT` オプションに関する問題を解決するために Linux カーネル v5.14 から取り込まれる予定のパッチセットについて 2 回に分けて解説します。 - https://lore.kernel.org/bpf/[email protected]/ - https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=1f26622b791b6a1b346d1dfd9d04450e20af0f41 Part 1 では `SO_REUSEPORT` オプション、カーネルの挙動と問題点、パッチセットの効果について解説し、 Part 2 ではカーネルの実装と修正方法、追加した eBPF の機能について解説します。 ## SO_REUSEPORT とは 従来、 Linu
最近Golangを書いていると、自分でTCPをListenしたり、Acceptしたりする処理を書くことがよくあるのですが、何をやっているのか全くイメージが沸いてなかったので、「Working with TCP Sockets」を読んで勉強しました。 Working With TCP Socketswww.jstorimer.com だいたいこの手のソケットプログラミング関連の本は、C言語で解説されていることが多いと思うのですが、本書はサンプルコードが全てRubyなので、非常に読みやすいです。残念ながら英語版しかありません。 以下、私がポイントだと思ったことだけをまとめた読書ノートです。 読書ノート 前半はソケットとは？から始まり、ソケットプログラミング自体の入門的な内容で、そのあたりの理解が曖昧だった私にはとても勉強になりました。 後半は、ソケットプログラミングを使った実用的なアーキテクチ
This article was first published on Cloudflare blog: When TCP sockets refuse to die Accompanying scripts While working on our Spectrum server, we noticed something weird: the TCP sockets which we thought should have been closed were lingering around. We realized we don't really understand when TCP sockets are supposed to time out! In our code, we wanted to make sure we don't hold connections to de
KLab Expert Camp というイベントを8/26～29の4日間で開催しました。 KLab Expert Camp とは KLab Expert Camp は、技術的に深いテーマに取り組んでいる学生の発掘・育成を目的とした KLab の新しい取り組みです。 記念すべき第1回のテーマは「TCP/IPプロトコルスタック自作開発」で、以下のような触れ込みで開催しました。 「OSを作ってみたい」「コンパイラを作ってみたい」と思う人が多いように「プロトコルスタックを作ってみたい」と思う人も多いのではないでしょうか。今回の KLab Expert Camp のテーマは、そんな皆さんにピッタリの「TCP/IPプロトコルスタック自作開発」です。担当講師が開発している教育用のプロトコルスタック（https://github.com/pandax381/microps）を教材に、Ethernetフレー
TCP/QUICのポートフォワードツールを書いた。 概要 IETFで標準化が進められているトランスポートプロトコルQUIC。 UDPを利用しており、エンドポイントのIPアドレスが変わってもコネクションが切れなかったり、より良い再送制御が行えたりと長所は多くある。しかし、QUICをサポートしているアプリケーションプロトコル、実装が現状多くはない。 QUICの恩恵に預かるために、TCPとQUICを相互変換するポートフォワードツール 「t2q2t」 を書いた。(実態としてはただのProxy) github.com ただし、ハンドシェイク回数が増えるのでコネクション確立時のオーバーヘッドは高い 利用例 ユースケースとしては例えば: クライアントとサーバそれぞれでt2q2tを実行する。 クライアント: TCPで0.0.0.0:2022でリッスンし、QUICで192.168.0.1:22に転送する サ
Good evening I have a TCP server clients can connect to. Pretty straightforward. But the problem is, all my clients use mobile network and are constantly on the move. Losing connection without notifying the server via FIN or RST is a common situation. So the server has this lingering connection and thinks a client is online when in reality it is not. My first solution was to wait for a while; if a
はじめに Linux Advent Calendar 10 日目の記事です。 運用や研究開発の現場では、ソフトウェアの実験、または機器のテストや選定などのために、ベンチマークツールや自前のアプリケーションでコンピュータ間の通信速度を計測する機会が多々あると思います。一方で10Gbpsや40Gbpsといった昨今の高速ネットワークにおいては、これらの計測結果はアプリケーションの通信API部分の実装、カーネルパラメータまたはコンパイルオプションによって大きく変わってしまうため、正確な計測を行うためにはこれらを正しく設定/理解する必要があります。この記事では、ネットワーク周りのカーネルとアプリケーションの動作の概要と、その中の重要なポイントを理解することを目的にします。 ネットワークプログラミングのおさらい まず最初に、TCPを使う今時のサーバプログラムがどのようにできているか簡単におさらいします
Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
このエントリは KLab Advent Calendar 2017 の最終日の記事です。 こんにちは。インフラ担当 高橋です。 このエントリでは、つい先日、少し変わった仕組みの外部向け HTTP 通信の 3way ハンドシェイクの再送検知ツールを作りましたのでご紹介します。 きっかけ このツールを作ったのは、DSAS の外部で発生するネットワーク障害を検知できるようにするためです。 例えばこのような障害がありました。 DSAS は複数のデータセンタで稼働しているのですが、ある日、特定データセンタの Web サーバから外部 API への接続が重くなる事象が発生しました。 原因は外部ネットワークからの DDoS 攻撃により、データセンタのネットワークの一部区間が飽和状態になったことによるものでした。 またある日は、特定のデータセンタの Web サーバから外部の特定 API に接続ができなくなり
Writing your own TCP/IP stack may seem like a daunting task. Indeed, TCP has accumulated many specifications over its lifetime of more than thirty years. The core specification, however, is seemingly compact1 - the important parts being TCP header parsing, the state machine, congestion control and retransmission timeout computation. The most common layer 2 and layer 3 protocols, Ethernet and IP re
本部長や副本部長もプログラミングを（たまに）することで有名なサイボウズの運用本部長、山本泰宇です。 有名じゃないかもしれませんが、ブログに書いたので有名になるということでご了承ください。 今回は、先日発生した yrmcds に起因する障害の原因と対策を解説します。 yrmcds というのは、サイボウズが開発している memcached 互換のキーバリューストレージです。 問題の理解のため、まず TCP 通信で、通信先の相手の障害にどう対応するか解説します。 データの送信中に相手が落ちるケース このケースはさらに二つに分かれます。 相手の OS は生きているが、通信しているプログラムが落ちるケース 相手の OS ごと（あるいはネットワークごと）落ちるケース 1 と 2 の違いは、前者の場合 RST パケットが返ってくるのに対して、後者ではなにも返ってこない点です。後者の場合、ack されない
The world was a simpler place when the TCP/IP network protocol suite was first designed. The net was slow and primitive and it was often a triumph to get a connection to a far-away host at all. The machines at either end of a TCP session normally did not have to concern themselves with how that connection was made; such details were left to routers. As a result, TCP is built around the notion of a
Incast is a many-to-one communication pattern commonly found in cloud data centers implementing scale out distributed storage and computing frameworks such as Hadoop, MapReduce, HDFS, Cassandra, etc. – powering applications such as web search, maps, social networks, data warehousing and analytics. Incast can also more specifically be referred to as TCP Incast, as the cloud applications creating th
はじめに インターネット通信の高速化については個人的に結構前から興味があって、確か2012年か2013年時点でGoogleがQUICに取り組んでいたことはなんとなく覚えているのだけれど、インフラの話も絡んでくることもあり、なんとなく誰にでも検討できるものでもないんだろうなという印象を当時持った気がする。 (NoTCPという名前から連想される)NoSQLのように、現在当たり前に使用しているインフラを疑ってみるというのは発想として面白いと思うが、ネットワークのような全世界共通のインフラに対して何ができるかという点(例えばTCPの輻輳制御における公平性の議論など)に関しては検討が必要な点も多いと思う。いずれにしろ興味深い分野なので引き続きウォッチしたい。 なお、本文書の原文はThe NoTCP Manifestoであり、ライセンスはCreative Commons Attribution-Sha
現実的な値と根拠など 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通信に利用で
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
