Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法を忘れることが多いのでメモ。 SYNフラグが設定されたパケットの収集 "tcp[13] & 2 != 0" SYNフラグが設定されていないパケットの収集 "tcp[13] & 2 == 0" SYNフラグのみ設定されたパケットの収集 "tcp[13] & 255 == 2" ACKフラグが設定されたパケットの収集 "tcp[13] & 16 != 0" ACKフラグが設定されていないパケットの収集 "tcp[13] & 16 == 0" ACKフラグのみ設定されたパケットの収集 "tcp[13] & 255 == 16" ACKフラグとSYNフラグが設定されたパケットの収集 "tcp[13] & 18 == 18" ACKフラグとSYNフラグのみ設定されたパケットの収集 "tcp[13] & 255 ==
Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
TL;DR 平文のTCP/IPの通信では送信したデータの完全性は期待できないので、経路にはSSL/TLSを使いましょう TCP/IPはUDPと違い、信頼性のある通信を実現するためのプロトコルという説明がよくされる。なのでTCP/IPでやり取りしたデータは1bitの狂いもなく転送先に届くと思われがちだ。TCP/IPが信頼性のある通信を確保してると言われているのは下記の理由による。 1. データが届かなかった場合の再送処理がプロトコルに入っている 2. TCPパケットにペイロードのチェックサムがあり、不具合が検知されると修正もしくは再送される(ただし16bit) 3. IP層の更に下の層にチェックサムがあり、不具合が検知されると修正もしくは再送される(イーサの場合32bit) しかしチェックサムはそれぞれ16/32bitのため、昨今の超大量データを取り扱うにはかなり心もとない。 1. ざっくり
1. ゆずり合うこと TCPはネットワーク帯域を他のTCPセッションと譲り合います。 TCPには、ネットワークが混雑(輻輳:ふくそう)してくると、送信されるパケット量を減らす仕組みがあります。 この譲り合いがあるからこそ、現在のインターネットは多数の人間が同時に使えています。 同様に、現実世界においても無理な競い合いを行うよりも譲り合いを行った方がスケーラビリティが上昇します。 2. 信頼はきめ細やかな確認応答で実現されること TCPでは、信頼性を確保するためにAck(Acknowledgement、確認応答)を送信してデータの到着を伝えます。 TCPのセッションが確立している間は、Ackが細かく送受信され続けます。 このきめ細かな確認応答が信頼の根幹であると言っても過言ではありません。 現実世界においても、きめ細かく応答を行う事が重要です。 メールなどを受け取っても、全く返事をしない相手
Tcpreplay は、あらかじめキャプチャしたネットワークトラフィックを 書き換えたり再送信したりするためのフリーのオープンソースユーティリティ群です。 もともとは IPS/IDS に対して悪意あるトラフィックパターンを再送信するために 設計されたものですが、Web サーバに再送信する機能など多くの進化を遂げました。 Version 4.0.0 では、スイッチ、ルータ、IP Flow/NetFlow アプライアンスを サポートするための機能やパフォーマンス向上がなされました。 実行例 - 10GigE to IP Flow Appliance: root@pw29:~# tcpreplay -i eth7 -tK --loop 5000 --unique-ip smallFlows.pcap File Cache is enabled Actual: 71305000 packets (
時折、ポートなどの疎通確認のため、相手先のポートがちゃんと開いているかを確認したい時がある。 そんな時は、基本的にポートの疎通確認用のコマンドを利用するのだが、地味にBashからでも疎通確認を行うことができる。 exec 3<> /dev/tcp/相手先ホスト名/ポート番号 # TCP通信の場合 exec 3<> /dev/udp/相手先ホスト名/ポート番号 # UDP通信の場合 準備ができたら、以下のコマンドで対象のポートに通信を行える。 echo -e "メッセージ" >&3 cat <&3 root@BS-PHY-PROX-01:~# exec 3<> /dev/tcp/orebibou.com/80 root@BS-PHY-PROX-01:~# echo -e "GET $2 HTTP/1.0\n\n" >&3 root@BS-PHY-PROX-01:~# cat <&3 <!DO
13:25 Invited Speaker 最速ウェブサーバの作り方 近年、ウェブの体感速度は、ネットワークのバンド幅ではなくレイテンシによって律速される傾向が強まってきています。また、それに伴い、TCP Fast Open、HTTP/2、TLS 1.3といった、レイテンシの影響を削減／隠蔽する技術の標準化が進んでいます。本セッションでは、HTTP/2サーバ「H2O」の主開発者が、レイテンシの影響削減を主目的とするサーバのプログラミング技法や、HTTP/2の更なる高速化を実現する手法として標準化提案中の「Cache Digest」等を紹介し、それらをrubyから制御する手法を検討します。 必要となる知識 TCP/IPとUnixのソケットプログラミングに関する基礎的な知識があると、分かりやすいかと思います。 奥一穂 株式会社ディー・エヌ・エー MIT TR100、日本OSS貢献者賞受賞、未踏
TCP_DEFER_ACCEPTは、LinuxでサポートされているTCPのオプションで、サーバ側で使用した場合にはaccept(2)からのブロック解除をTCP接続が完了したタイミングではなく最初のデータが到着したタイミングで行ってくれるオプションです。 Webサーバ・アプリケーションサーバではリクエストが到着してからaccept(2)のブロックを解除するので、リクエストの到着をWebサーバ・アプリケーションサーバで待つ必要がなくなり、特にprefork型のサーバでは効率的にプロセスを使えるようになるという利点があります。PerlではStarletがこの機能を有効にしています ところが、某サービスでTCP_DEFER_ACCEPTが有効にも関わらず、accept後のreadでデータが読めず、最悪の場合、デフォルトのtimeoutである5分間プロセスがストールすることがありました。strace
以前 (2.6.31 まで?) は以下の挙動*1。 最初のペイロードを受信するまで SYN_RECV ステート クライアントの ACK (TCP ハンドシェイクの最後のパケット) を受信していたとしても、SYN-ACK を送り続ける 190 秒たったら、サーバ側は TCP 接続確立失敗と認識 クライアントは SYN-ACK を送ってるから接続できてるつもり TCP の仕様的にどうなの、って話はわかる。ただ、IP 層はパケットロスの可能性があるわけで、インターネットを使っていて、この挙動で問題があるとしたら、それはアプリケーションのバグだと思うけど。一方で、 LAN 上でパケットロスが (ほぼ) 起こらない前提で作ってたら困ることがあるのかなー。Ubuntu の BTS で話が出てるのは、そういうケース (特定のハードウェアロードバランサと TCP_DEFER_ACCEPT を使う Apac
このドキュメントの内容は、以下の通りです。 Accept Filterとは 3-way handshake TCP_DEFER_ACCEPTとは リスニングソケットの場合 必ずしもデータが到達するわけではない TCP_DEFER_ACCEPT を使用する コーディングレベルでの利用例 Accept Filterとは Accept Filterとは、カーネル内でネットワークのリクエストをバッファリングすることにより、OSとアプリケーションのスイッチングを減らしたり、アプリケーションがデータ待ちで止まってしまうことを避けたりすることができます。 http://kaworu.jpn.org/freebsd/Accept_Filter Linuxには、Accept FilterでいうAccept httpがありませんが、accept data という意味で TCP_DEFER_ACCEPT が利用
2013/10/22 追記した． Starletのコード読んでてlistening socketにTCP_DEFER_ACCEPTとかいうオプション渡してたので、これ何だって思って調べた． TCPに特に詳しいわけではないので理解に誤りがあるかもしれない． package Starlet::Server; ... # set defer accept if ($^O eq 'linux') { setsockopt($self->{listen_sock}, IPPROTO_TCP, 9, 1) # 9がTCP_DEFER_ACCEPTを表す and $self->{_using_defer_accept} = 1; } ... TCP_DEFER_ACCEPTはLinux 2.4から導入されている． Linux 2.6.32から挙動が若干変わっているらしい． (linux の TCP_DE
はじめに サーバソフトウェアの設定ファイル等でよく見かける項目であるBacklogってどういう意味なんだろうと、少し調べたのでメモを残します。 Backlog apacheやnginx、memchachedなどのサーバ系ソフトウェアの設定ファイルの中で設定することが多い、このBacklogとは何なのかをここでは言及する。 サーバアプリケーションがlistenしているソケットがacceptしていない、確立済TCPセッションを何個までOS側で保持するかを定義したもの。 例えば、下記のようなサーバーアプリケーションがあるとする。 server.py import evenlet server_sock = eventlet.listen(('0.0.0.0', 6001),backlog = 1) new_sock, address = server_sock.accept() new_sock
September 6, 2014 $ss -ltと$ss -ltpは使える。 -iは面白いけど本当に確認するならngrepかtcpdumpだろうな セッションを開いているホスト名を名前解決しない(デフォルト) $ss -n セッションを開いているホスト名を名前解決する $ss -r TCPのセッションのみ表示 $ss -t $ss -A tcp UDPのセッションのみ表示 $ss -u $ss -A udp TCPとUDPのセッションのみ表示 $ss -tu $ss -A tcp,udp UNIX Domainのセッションのみ表示 $ss -x $ss -A unix 特定のセッションの状態のものを抽出 $ss -t state fin-wait-2 TCPでLISTENしているポートを表示 $ss -lt TCPでLISTENしているポートのプロセス名を表示 $ss -ltp コマンド
モバイル(ワイヤレス)ネットワークとLinuxのTCP再送アルゴリズムの相性の悪さをまとめた社内勉強会用資料Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
