TCPのTail Loss Probeと再送周りについて少し - エンジニアですよ！
仕様は RFC にはないっぽくて(?) 2013年にgoogleの方々が出してるinternet draft で定義されている模様。 Tail Loss Probe は、一連の送信パケットの最後のパケットがロスした場合に、送信側が再送タイムアウトを待たずにロスを検知して回復することを目的としている。 パケットがロスした時、後続のパケットが次々と送られている場合はduplicate ackが返されるため、fast retransmitによってリカバリすることができる。 しかし、末尾のパケットや途中から末尾までウィンドウいっぱいのパケットがロスしてしまった場合などは、dup ackが届かないためfast retransmitはトリガーされないため再送タイムアウトまでリカバリできない。 再送タイムアウトを待つと時間がかかりすぎるし、タイムアウトが発生すると輻輳ウィンドウが小さくなってスロースター
NGINX open sources TCP load balancing | Hacker News
Many installations would go from haproxy->nginx to nginx->nginx. Having to support a single product will make many devops happy.In the same tense, haproxy is adding Lua support[1], which has been available in nginx - using openresty[2] - since 2011, and nginx core is doing the same with Javascript[2]. Interesting times aroung haproxy and nginx. [1] http://blog.haproxy.com/2015/03/12/haproxy-1-6-de
Characteristics of UDP Packet Loss: Effect of TCP Traffic
Hidenari Sawashima <hidena-s@is.aist-nara.ac.jp> Nara Institute of Science and Technology Japan Yoshiaki Hori <hori@kyushu-id.ac.jp> Kyushu Institute of Design Japan Hideki Sunahara <suna@wide.ad.jp> Yuji Oie <oie@itc.aist-nara.ac.jp> Nara Institute of Science and Technology Japan Abstract On wide area networks (WANs), UDP has likely been used for real-time applications, such as video and audio. U
ぜんぶTIME_WAITのせいだ！ - Qiita
課題 突然キャンペーンとかの高トラフィックが来る！とか言われると色々困ることはあるものの、今のご時世クラウドだからスペック上げときゃなんとかなるでしょ。ってとりあえずCPUとかメモリあげて見たものの、キャンペーンが始まったら意外と早くブラウザからつながらない！！とか言われたりする。 CPUもメモリもそんなに負荷は特に高くもない。調べてみたらTIME_WAITが大量にあった。 とりあえず何とかしたい TIME_WAIT数をコマンドで確認 $ netstat -anp|grep TIME_WAIT __(snip)__ tcp 0 0 192.168.1.1:80 192.97.67.192:56305 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.63.64.145:65274 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.39
Tshark パケットキャプチャ術で秘密もちょっぴりこぼれた？ － ＠IT
「-b」は、ファイルへの出力に関する条件を指定することができるオプションである。ここでは、条件に合致した場合に、現在保存しているファイルから次のファイルに出力するという制御が可能である。 例えば、ファイルサイズが1MB（1000KBとした場合）に達したら次のファイルに保存すると設定する場合は以下のように指定する。
相手がいないのに ESTABLISHED になってる TCP ポート - tmtms のメモ
最近 ParallelServer というライブラリを作ったのですが、その最中に奇妙な状態になってる TCP ポートを見つけたので、メモっておきます。 Ruby では TCP サーバーは次のような感じで作ることができます。お手軽ですね。 require 'socket' Socket.tcp_server_loop(12345) do |socket, client_addr| socket.puts "Your IP address: #{client_addr.ip_address}" name = socket.gets socket.puts "Hello, #{name}" socket.close end これは 12345 ポートでクライアントからの接続を待ち、接続されたらクライアントのIPアドレスとクライアントからの入力をクライアントに送信して切断するだけの簡単なプログラム
Proportional Rate Reduction for TCP
Proceedings of the 11th ACM SIGCOMM Conference on Internet Measurement 2011, Berlin, Germany - November 2-4, 2011 Packet losses increase latency for Web users. Fast recovery is a key mechanism for TCP to recover from packet losses. In this paper, we explore some of the weaknesses of the standard algorithm described in RFC 3517 and the non-standard algorithms implemented in Linux. We find that these
TCPDUMPの出力を見てみよう
いかがですか。結構めんどくさいですね。 理論だけでは頭がいたくなってきます（私もそうです）。 実は、私もTCPについてはほとんど覚えておらず、必要となったときに書籍を 参考にしながらパケットを追いかけるということをしています。では、 さっそく実例としてtcpdump の出力を追いかけてみましょう。例として、Windows NT にログインして Netscape Communicator を起動したときのパケットの流れを見てみます。 ちょっとその前に予備知識として、私が今使用している PC(Windows NT 4.0)でどんなコネクションが張られているかを、 netstatコマンドで見てみましょう。 C:\>netstat -a Active Connections Proto Local Address Foreign Address State TCP hotta:1030 0.0.0
SACSIS.TCP - HPCユーザが知っておきたいTCP/IPの話
HPC TCP/IP 2009 5 29 SACSIS2009 HPC TCP/IP 2 • • 1 Gbps RTT 100 • 240 Mbps ☹ • 940 Mbps ☺ (2) HPC TCP/IP • Ethernet PC • TCP/IP 2 10MB 3 0 200 400 600 800 1000 0 100 200 300 400 500 600 Bandwidth (Mbps) Time (msec) 160 0 200 400 600 800 1000 0 100 200 300 400 500 600 Bandwidth (Mbps) Time (msec) x3.5 (2) • TCP/IP • • MPI • TCP/IP TCP • TCP Reno [RFC2851] • TCP CUBIC Compound TCP 4 (3) • TCP/IP • T
Network Congestion and Web Browsing - Insouciant
Recently, there was discussion on the ietf-http-wg mailing list about the current HTTP/2.0 draft’s inclusion of a SPDY feature that allows the server to send its TCP congestion window (often abbreviated as cwnd) to the client, so it can echo it back to the server when opening a new connection. It’s a pretty interesting conversation so I figured I’d share the backstory of how we got to where we are
rtt_congestion.ps
Modeling Network Coded TCP Throughput: A Simple Model and its Validation MinJi Kim MIT Cambridge, MA 02139 minjikim@mit.edu Muriel Médard MIT Cambridge, MA 02139 medard@mit.edu João Barros University of Porto Porto, Portugal jbarros@fe.up.pt ABSTRACT We analyze the performance of TCP and TCP with net- work coding (TCP/NC) in lossy wireless networks. We build upon the simple framework introduced by
TCP高速化などを図ったLinuxカーネル3.6、リリース
TCP高速化などを図ったLinuxカーネル3.6、リリース：仮想環境でのI/O性能を改善するVFIOも Linuxカーネルの新バージョン、「Linux 3.6」が10月1日にリリースされた。Linus Torvalds氏はこのリリースについて、アーキテクチャやファイルシステムに大幅な変更はないとしながらも、「着実な進歩」だと表現している。 カーネル3.6では、まずネットワーク接続を高速化するため、TCP Small QueuesやTCP Fast Openといった機能が盛り込まれた。TCP Small Queuesは、1つのキューに含まれるパケットの数に上限を設けることでRTTなどを減らし、ひいてはバッファサイズに起因する遅延や輻輳といった問題（Bufferbloat）を解決することを狙ったもの。一方TCP Fast Openは、TCPコネクション確立時のプロセスを最適化することで、Web
)
The Cable Guy: TCP 受信ウィンドウ自動チューニング
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 The Cable GuyTCP 受信ウィンドウ自動チューニング Joseph Davies "TechNet Magazine"** の The Cable Guy の初回の記事へようこそ。TechNet Web サイトのコラムのファンである皆さんは、既にご存じのように、私たちはネットワークに関するあらゆる事柄を取り上げてきました。そしてこれからも毎月この伝統を守っていきます。もしあなたが新しい読者で、過去のコラムをお探しなら、Cable Guy サイトを参照してください。 では、最初のトピック、TCP 受信ウィンドウについて説明します。 TCP 接続を用いたスループットはアプリケーションの送受信、TCP
Google Research: Let's Make TCP Faster
Google is actively researching ways to improve TCP: Our research shows that the key to reducing latency is saving round trips. We’re experimenting with several improvements to TCP. Here’s a summary of some of our recommendations to make TCP faster: Increase TCP initial congestion window to 10 (IW10). The amount of data sent at the beginning of a TCP connection is currently 3 packets, implying 3 ro
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
Erlang: A Generalized TCP Server
In my last few articles about Erlang we've covered the basics of network programming with gen_tcp and Erlang/OTP's gen_server, or generic server, module. Let's combine the two. In most people's minds "server" means network server, but Erlang uses the terminology in the most abstract sense. gen_server is really a server that operates using Erlang's message passing as its base protocol. We can graft
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.is.ocha.ac.jp/~oguchi_lab/Publications/paper2012/dicomo2012_hiromi.pdf