Guide to IP Layer Network Administration with Linux
Abstract This guide provides an overview of many of the tools available for IP network administration of the linux operating system, kernels in the 2.2 and 2.4 series. It covers Ethernet, ARP, IP routing, NAT, and other topics central to the management of IP networks. List of Examples 1.1. Sample ifconfig output1.2. Testing reachability of a locally connected host with ping1.3. Testing reachabilit
Tracing the path of network traffic in Kubernetes
Tracing the path of network traffic in KubernetesJanuary 2022 TL;DR: In this article, you will learn how packets flow inside and outside a Kubernetes cluster. Starting from the initial web request and down to the container hosting the application. Table of ContentsTable of ContentsKubernetes networking requirementsHow Linux network namespaces work in a podThe pause container creates the network na
LinuxサーバーのTCPネットワークのパフォーマンスを決定するカーネルパラメータ – 1編 | NHN Cloud Meetup
1.はじめに ネットワークのパフォーマンスを決定付ける最も重要な要素は、最終的にはアプリケーションにあるでしょう。ただ、ワークロードの特性によっては、デフォルト設定されたTCPカーネルパラメータが制約となり、パフォーマンスを発揮できないときもありますね。 非常にたくさんのカーネルパラメータがありますが、本文では、ネットワーク帯域幅（bandwidth）のカーネルパラメータ、ネットワーク容量（capacity）のカーネルパラメータを主に扱います。 2.準備 Linuxはsysctlコマンドで簡単にカーネルパラメータを実行時に変更できます。 次のようなコマンドを使用すると、現在のカーネルパラメータ設定値の全体を閲覧できます。 $ sysctl -a ここで取り上げるネットワークは、特にTCPのcapacityとbandwidthなどを調整（tuning）できるカーネルパラメータのごく一部を紹介
Winsock Programmer's FAQ: Articles: The Lame List
ザ・間違いリスト はじめに 「ザ・間違いリスト」(The Lame List)は、非常に有用なものであ るので、ここに再掲することにします。この文章は、Windows Sockets 2 アプリケーションプログラミングインターフェースバー ジョン 2.2.2 の付録C から直接カット&ペーストしたものです。このリ ストはもともと、Winsock スタックベンダ達が、お馬鹿なアプリケーショ ンの数々(名前を出すことは控えておきます)について文句を並べたもの が始まりです。にも関わらずこれらの内容は非常に有用なものです。と いうのは、新米の Winsock 屋さんは、やはり同じお馬鹿な間違いをし でかしてしまうからです。このリストに載っている内容を避けるように することが、あなたを Winsock の超プロに向かう長い道へと導くので す。 このリストのもともとのはしがき: このリストを始めた功
ソケットプログラミングのTips
概要 ソケットプログラミングに関するTipsをメモレベルで記載する。 切断検知と経路切断 TCPコネクションの切断検出 対向がclose()、shuttdown()、プログラム終了等をしたときの切断検出について。 OSをシャットダウンさせた場合も通常はアプリケーションの終了処理が走り、正常な切断が動く。 受信側の切断検出は、recv()がlength==0で返ってきたとき、または、errno==ECONNRESETとなる。（ECONNRESETはRSTによって切断された場合） 送信側の切断検出は、切断された後2回目のsend()がエラーとなる。 ※相手がclose()→こちらがsend()→相手にパケットが飛ぶが待ち受けプログラムがいないためRST応答が来る→もう1度send()→エラー ※send()自体はカーネルの送信バッファにデータコピーするだけなので、TCPレベルの応答（送信完了）
Reducing UDP latency
Hi! I’m one of Embox RTOS developers, and in this article I’ll tell you about one of the typical problems in the world of embedded systems and how we were solving it. Stating the problemControl and responsibility is a key point for a wide range of embedded systems. On the one hand, sensors and detectors must notify some other devices that some event occurred, on the other hand, other systems shoul
なぜインターネットの MTU は 1,500 バイトになったのか - らくがきちょう
Ben Cox の Blog は興味深い記事が多く掲載されています。 その中でも How 1500 bytes became the MTU of the internet という記事が面白かったので、Ben さんに許可頂き、日本語に翻訳してみました。 英語が苦手なので、ところどころ「どう、ニュアンスを訳して良いのか？」が分かりませんが、とりあえず自分の勉強を兼ねてメモしておきます。 Thanks for your great article, Ben! なぜインターネットの MTU は 1,500 バイトになったのか イーサネットは至るところで、何万ものハードウェアベンダーが通信に利用し、実装しています。 ですが、 ほぼ全てのイーサネットリンクに共通する、MTU というひとつの値があります。 $ ip l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 s
Dockerでデバッグ対象のコンテナにツールを入れずにtcpdump/straceなどを使うワンライナー - Qiita
はじめに Dockerであんなコンテナやこんなコンテナを動かしてると、なんかうまく動かなくて、デバッグのためにtcpdumpとかstraceなどのツールが使いたくなることが稀によくあります。 そんな時、デバッグ対象のコンテナ内にツールを一時的にインストールしちゃうというのが、まぁ簡単で分かりやすいんですが、デバッグ対象のコンテナを汚すのはできれば避けたいところです。 Dockerのコンテナの分離というのは、結局のところLinuxのリソースの名前空間の分離であるので、逆に同じ名前空間を共有すれば、デバッグ用に立てた隣のコンテナから、デバッグ対象のコンテナのネットワークやプロセスの状態を観察することも可能です。 また、docker buildはDockerfileを標準入力から受け取ることもできるので、ワンライナーにしてデバッグ用のコンテナをシュッと呼び出せるようにしてみました。 TL;DR
Accelerating UDP packet transmission for QUIC
This was originally published on Perf Planet's 2019 Web Performance Calendar. QUIC, the new Internet transport protocol designed to accelerate HTTP traffic, is delivered on top of UDP datagrams, to ease deployment and avoid interference from network appliances that drop packets from unknown protocols. This also allows QUIC implementations to live in user-space, so that, for example, browsers will
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
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() からは(
netfilterチューニング
gistfile1.txt ����yU 0�9�yU ip_conntrack: table full, dropping packet. この一行のログに悩まされた方は多いのではないでしょうか。 自分もその一人です。 多くのブログには echo '500000' > /proc/sys/net/ipv4/netfilter/ip_conntrack_max で解決。みたいなことが書いてあると思います。 では、この数字について根拠はなんでしょうか。そもそも何のためにconntrack tableというものがあるのか考えたことはありますか？ 闇雲に最大値をあげることにたいして抵抗がある方もいると思います。 このテキストは、転職後2日目にGWとして使っているLinux NAT BOXが爆発したことを起因とした、netfilterのチューニングについてまとめようと思います。 ある程度前提の知識
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
Microsoft PowerPoint - shudo-NAT-20080628.ppt [互換モード]
NAT 基礎講座 首藤一幸 第10回 SIProp 勉強会, 2008年6月27日(金) TCP/IP TCP/IP プロトコルスタック • ≠ TCP と IP の２つ • インターネットの 基本プロトコル集合 – IP (Internet Protocol) – TCP (Transmission Control Protocol) • connection-oriented / 接続指向 – UDP (User Datagram Protocol) • connectionless – ICMP (Internet Control Message Protocol) リンク層: Ethernet など IP TCP HTTP, SMTP, POP3, … ICMP UDP 第2層 第3層 第4層 OSI参照モデルと 対応づけるとしたら L2, L3 という語は ここから派生 SOAP
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき本 I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TIME_WAIT and its design implications for protocols and scalable client server systems - ServerFramework.com
Why do we need a 3-way handshake? Why not just 2-way?
Cloud gaming
TCP/UDP接続を行っているプロセスを一覧できるユーティリティ「ProcessTCPSummary」／プロセスのネットワーク通信状況を把握・調査するのに役立つ【レビュー】
分散システム内の関係性に着目したObservabilityツール - Speaker Deck
