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! Image by Sergiodc2 CC BY SA 3.0 In our code, we wanted to make sure we don't hold connections to dead hosts. In our early code we naively thought enabling TCP keepalives wo
本書は、Pythonによる実装を前提として、ソケットプログラミングに必要な知識をわかりやすく解説する入門書です。TCP/IPやソケットの原理を説明したのち、Pythonでソケットを実装する基礎的方法を示していきます。さらに、Python固有の機能を用いたプログラミング例（モジュールを利用したサーバ実装など）を紹介します。 ダウンロードできるサンプルプログラムが多数掲載されているので、実際に試しながら読み進めて、知識と技術を身につけてください。 【本書の基本環境】 本書は、Windows・Annaconda・Python3の使用を基本としています。 しかし、使用しているモジュールはごく標準的であるため、それ以外の環境でも、本書で使用しているプログラムは問題なく動作すると考えられます。 【本書内で使用するPythonモジュール】 socket sys datetime threading os
本部長や副本部長もプログラミングを（たまに）することで有名なサイボウズの運用本部長、山本泰宇です。 有名じゃないかもしれませんが、ブログに書いたので有名になるということでご了承ください。 今回は、先日発生した yrmcds に起因する障害の原因と対策を解説します。 yrmcds というのは、サイボウズが開発している memcached 互換のキーバリューストレージです。 問題の理解のため、まず TCP 通信で、通信先の相手の障害にどう対応するか解説します。 データの送信中に相手が落ちるケース このケースはさらに二つに分かれます。 相手の OS は生きているが、通信しているプログラムが落ちるケース 相手の OS ごと（あるいはネットワークごと）落ちるケース 1 と 2 の違いは、前者の場合 RST パケットが返ってくるのに対して、後者ではなにも返ってこない点です。後者の場合、ack されない
connect(2) のエラー TCP において connect(2) 呼出し時に発生する可能性のあるエラーは以下の通りです。 タイムアウト RST 受信 EHOSTUNREACH また ENETUNREACH シグナル受信 その他 まず、connect(2) 時の正常な流れをしっかり覚えておいてください。 (connect(2) を呼んで) SYN を送る SYN+ACK が返ってくる (ここで connect(2) から戻る) ACK を送る タイムアウト もし仮に、SYN を送ったものの、相手側から SYN+ACK が返ってこない場合は、 (ローカルの TCP スタックが) しつこく SYN を再送します。何度 SYN を送っても SYN+ACK が返ってこない場合はあきらめてタイムアウトします。 「SYN+ACK が返ってこない」というのは、例えば以下のようなケースが考えられます。
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() からは(
TCPソケット サーバータイプとクライアントタイプの両方のアプリケーションを作らないといけないなら、サーバータイプから作るべきだろう。 （クライアントタイプだけ先に作っても動かせないから。まぁサーバータイプだけ動かしても、待ってるだけであまり意味無いけど(苦笑)） でも仕組みはクライアントタイプの方が簡単。 TCPを使う場合は、通信の最初にコネクションの確立を行う必要がある。 サーバーでlisten・accept、クライアントでconnectが成功すればコネクションが確立したことになる。 どのポート番号を使うかについては、サーバー側はアプリケーションの作成者が決める必要がある。[/2007-06-16] クライアント側のポート番号は、ソケットライブラリがそのマシンで使っていない番号を自動的に割り振ってくれるので、気にしなくてよい。 IANAの基準では、1～1023は「よく知られたポート（w
片方が他方に対して何らかの電文を送ると、相手は受け取ったという印にACKを返す。 ACKが来なければ相手が受け取っていないということなので、その場合はある程度待ってから再送する。 ACKは他の電文と一緒に送ってもよい。 コネクションは、【相手先IPアドレス・相手先ポート・自分のポート】の組で一意に表される。 コネクションは現在どういう状態にあるかを示すステータスを持っており、イベントに応じて遷移していく。netstatコマンドで表示されるのは、これ。 TCP/IPとソケットの関係 ソケット関数を呼び出すと、ソケットライブラリ（プロトコルスタック？OS？）がTCP/IPの規約に従って通信を行う。 listen（受付開始） サーバー側で接続の受付待ちを開始する。 コネクション（通信相手はいないので、相手先IPアドレス・ポートは無し、自分のポート番号だけ有り）はLISTEN状態になる。 conn
TCPヘッダの構造 TCPでは信頼性の高い通信を実現するために、受信確認やスライディング・ウィンドウ制御、そしてさまざまな付加機能などを用意している。そのためUDPよりも複雑なヘッダ情報を持っている。「チェックサム」はIPヘッダなどと同様に、1の補数で計算する。 連載第7回「データグラム通信を実現するUDPプロトコル―2．UDPパケットの構造」で示したUDPパケットの構造と比べると、非常に複雑になっている。UDPでは、通信に先立ってコネクションを確立する必要のないデータグラム型通信モデルを使用しているため、送信される各UDPパケットは完全に独立していた。そのため、UDPパケットごとにあて先のポート番号（送信元を区別するための送信元ポート番号）さえあれば、相手にパケットを届けることができる。 だがTCPでは、通信に先立ってコネクションを開設し、さらに通信中にも、前回解説したシーケンス番号に基
In May 1974, Vint Cerf and Bob Kahn described an internetworking protocol for sharing resources using packet switching among network nodes.[2] The authors had been working with Gérard Le Lann to incorporate concepts from the French CYCLADES project into the new network.[3] The specification of the resulting protocol, RFC 675 (Specification of Internet Transmission Control Program), was written by
7.4. TCPコネクションここからのセクションでは、基本的プロトコルである TCP, UDP, ICMP それぞれについて、ステートと、それがどのように処理されるかをつぶさに見ていくことにする。さらに、デフォルト つまり、これら 3 つのプロトコルに類別されない場合どうなるのかについても掘り下げる。まずは TCP プロトコルから始めることにした。というのも、 TCP はそれ自体ステートフルなプロトコルであるし、 iptables のステート機構に関わる興味深い特性がたくさんあるからだ。 TCP コネクションは常に 3 ウェイハンドシェークによって開始される。このハンドシェークによって、その先実際のデータを乗せることになるコネクションを確立およびネゴシエート (交渉) する。セッションは、まず SYN パケット、次に SYN/ACK パケットが続き、最後に、セッション確立を承認する ACK
というわけで調べてみた。設定方法については後述する。文中にリンクがあります。 とりあえずぐぐると出てくるのは下記 http://support.microsoft.com/kb/328890/ja 概要 TcpAckFrequency は、未解決の TCP 受信確認 (ACK) 数がいくつになったら遅延 ACK タイマを無視するかを決定する、 「TCP」はネットワーク通信時の方法であり、ACKはその手続きのひとつ。ACK(アック）は機械制御なんかだと良く出る単語でありOKサインだと思って良い。未解決のTCP受信確認数とは、ACKを返す状況であるけどまだACKを返してない、滞留しているのがいくつあるかということ。 もうちょいおおざっぱに言えば、Windows自体が意図的に0.2秒ラグらせる機構を持っているということ。 下記からTCP通信シーケンスの図を拝借すると http://www.nin
受信したパケットに対して即座に ACK を返すのではなく，新しいパケットが届くか，一定時間待ってそれでもパケットが届かなかった(遅延ACKタイマが expire した)場合だけ ACK を返す． 遅延ACKの有効化＝ACK数の減少なので，遅延ACKを有効にするとウィンドウサイズの増加が遅くなる．そこで Linux ではスロースタートフェーズでは遅延ACKを無効化する QuickACK を導入している． デフォルトで有効なわけじゃなくて，setsockopt(TCP_QUICKACK) しないと activate されない？ Linux の実装． データ構造 include/linux/tcp.h: struct tcp_opt { : /* Delayed ACK control data */ struct { __u8 pending; /* ACK is pending */ __u
TCP のチューニング・パラメータ 接続確立関係のチューニング・パラメータ TCP のチューニング・パラメータ TCP のチューニング・パラメータは、以下のコマンドで取得できます。 なお、以下は Linux のものです。 >cat /proc/sys/net/ipv4/tcp_retrans_collapse 1 >cat /proc/sys/net/ipv4/tcp_keepalive_probes 9 >cat /proc/sys/net/ipv4/tcp_keepalive_time 10800 >cat /proc/sys/net/ipv4/tcp_syn_retries 10 >cat /proc/sys/net/ipv4/tcp_sack 1 >cat /proc/sys/net/ipv4/tcp_timestamps 1 >cat /proc/sys/net/ipv4/tcp
11.24. TCPMSSターゲットTCPMSS ターゲットを使うと、ファイヤーウォールに接触する TCP SYN パケットの MSS (Maximum Segment Size) 値を変更することができる。 MSS 値は、各々のコネクションの中で使用するパケットの最大サイズをコントロールするために用いられる。通常この値は、 MTU から 40バイトを引いた値だ。このターゲットは、パケットのフラグメンテーションが必要だということを伝える ICMP をブロックしてしまう ISP やサーバへの対策として利用することが多い。そうした状態でよく見られるのは、ファイヤーウォールやルータは完璧に機能しているはずなのに、大きなパケットになるとファイヤーウォール内側のローカルマシンは遣り取りができない、といった奇妙な現象だ。具体的に言えば、メールサーバが、小さなメールなら送れるがサイズの大きなメールが送れ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
