RTTとは - IT用語辞典
概要 RTT（Round-Trip Time）とは、通信相手に信号やデータを発信してから、応答が帰ってくるまでにかかる時間。相手との物理的な距離や、経路上で中継・転送する装置などの数や処理時間に左右される。 電子回路や通信システムなどで、伝送にかかる時間を表す特性の一つとしてよく用いられる。双方向でやり取りを行うシステムの場合、回線などの時間あたりの伝送容量（帯域幅や通信速度）がいくら大きくても、RTTが大きければ送受信の度に大きな待ち時間が発生し、トータルの実効速度（スループット）や使用感は大きく損なわれる。 ラウンドトリップの削減 RTTそのものは物理的な信号の伝達などを伴うため削減するのは容易ではない。このため、通信システムの性能を向上させたい場合には伝送手順などを見直してやり取りの回数を減らす工夫が行われることがある。 インターネットで用いられるプロトコルには接続開始時にネゴシエー
TCPの再送タイムアウトを制御したい
TCPの再送タイムアウトで最近まで知らなかったことがあったのでメモ。 たとえば、APサーバとDBサーバがあるとする。 AP-DB間のDBCPで使うTCPコネクションは、DBサーバがノードダウンしたのであればさっさと再送リトライをあきらめて切れてほしいと思うのが普通だろう。 このTCPの再送リトライ処理は、何もいじらないと15分以上続くので、 できればTCPコネクション単位で細かく調整させてほしいと思うのは人情だと思う。 Linux の場合、昔はこの調整をしようと思うと、sysctl を使って /proc/sys/net/ipv4/tcp_retries2 の値を書き換えるしかなかった。 これは、リトライ回数でしか指定できず、そのリトライ間隔が回数ごとに変わっていく（長くなる）のでわかりにくい上に、そのOS上の全TCPコネクションで有効になってしまうという問題があった。つまり、このオプション
TCP 3-way handshakeのレイテンシ軽減のための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
socatを使ってみる | FUture REal LOcation
複数台のWebサーバ(Apache)が動作している環境で、 アクセスログを簡単に集約できないか調べていた。 アクセスログを、netcat(ncコマンド)を利用して、UDPパケットとしてブロードキャストに投げ、 それをログ収集サーバが受け取ることができないか調べていたが、CentOS付属のnetcatでは出来なかった。 ※詳しくは調べていないが、UDPで待ちうけるように設定した場合、一回通信が開始されると、その待受けポートがなくなってしまう模様。 代わりのものを調べていたら、socatというnetcatの高機能版のようなツールがあった。 TCP/UDPだけではなく、IP,SCTP,PTY,EXEC等多数のプロトコルを扱える。 EPELにsocatパッケージとして登録されている。 # yum install --enablerepo=epel socat ●利用方法 サーバ側は以下のようにして
Geekなぺーじ : TCP vs RTP：何故RTPが必要なのか？
インターネットを流れるトラフィックのほとんどがTCP(Trasmission Control Protocol)によるものです。 TCPは、全てのデータが正しく相手に伝わることを保証するため品質の高いデータ通信が実現できます。 また、どのパケットが受け取れなくて、どれが受け取れたかなどをわざわざ考えなくても良いので、プログラムを書くのも簡単です。 では、何故、わざわざRTPというものが必要だったのでしょうか？ ここでは、まず最初に何故RTPはTCPではなく、UDPの上に存在しているのかを説明したいと思います。 （もちろん、TCPの上に作ることはRTPの規約上は可能ですが、現実的にはUDPの上でしか実装がないと思います。） その後、何故、UDPの上に共通のRTPというものを構築したのかを説明したいと思います。 RTPは、名前にもある通り、「リアルタイム」なデータを転送するためのプロトコルです
第15回 信頼性のある通信を実現するTCPプロトコル（2）
TCPヘッダの構造 TCPでは信頼性の高い通信を実現するために、受信確認やスライディング・ウィンドウ制御、そしてさまざまな付加機能などを用意している。そのためUDPよりも複雑なヘッダ情報を持っている。「チェックサム」はIPヘッダなどと同様に、1の補数で計算する。 連載第7回「データグラム通信を実現するUDPプロトコル―2．UDPパケットの構造」で示したUDPパケットの構造と比べると、非常に複雑になっている。UDPでは、通信に先立ってコネクションを確立する必要のないデータグラム型通信モデルを使用しているため、送信される各UDPパケットは完全に独立していた。そのため、UDPパケットごとにあて先のポート番号（送信元を区別するための送信元ポート番号）さえあれば、相手にパケットを届けることができる。 だがTCPでは、通信に先立ってコネクションを開設し、さらに通信中にも、前回解説したシーケンス番号に基
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法 - Eiji James Yoshidaの記録
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 ==
JF: Linux Kernel 2.4 Documentation: ip-sysctl.txt
JF: Linux Kernel 2.4 Documentation: /usr/src/linux/Documentation/networking/ip-sysctl.txt networking/ip-sysctl.txt /proc/sys/net/ipv4/* の変数 [プレインテキスト版] 原著作者: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Andi Kleen <ak@muc.de> Pekka Savola <pekkas@netcore.fi> 翻訳者: 野本浩一 <hng@ps.ksky.ne.jp> バージョン: 2.4.5 翻訳日時: 2001/11/20 /proc/sys/net/ipv4/* の変数： ip_forward - 論理型 0 - 無効 (既定値) 0 以外 - 有効 パケットをインターフェース間でフォワー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TCP接続が切れるまで - こせきの技術日記
https://github.com/hiboma/hiboma/blob/master/%E5%90%84%E7%A8%AE%E3%83%84%E3%83%BC%E3%83%AB%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%A2%E3%82%A6%E3%83%88%E5%AE%9F%E8%A3%85%E3%81%BE%E3%81%A8%E3%82%81.md
TCP詳説 西田佳史
TCP/IPに係る 既知の脆弱性に関する 調査報告書 - 情報処理推進機構.pdf
IBM Developer