マイクロソフト、より高速な「TCP Fast Open」など採用へ、Windows 10の大型アップデートとWindows Server 2016で
マイクロソフト、より高速な「TCP Fast Open」など採用へ、Windows 10の大型アップデートとWindows Server 2016で マイクロソフトは8月に行われるWindows 10の大型アップデートWindows 10 Anniversary Updateと、9月に正式リリースが予定されているWindows Server 2016で、「TCP Fast Open」の採用やTCPの初期ウィンドウサイズ（Initial Congestion Window）を10にするなど、より高速な通信を実現するTCPの新機能を明らかにしました。 Announcing: New Transport Advancements in the Anniversary Update for Windows 10 and Windows Server 2016 | Networking Blog 新
TCP/IP - TCP 3ウェイハンドシェイク
◆ TCP - コネクションの確立と切断 TCPはコネクション型プロトコル（通信相手の応答があってはじめて通信を開始する）であることから、 データ転送を行う前にコネクションの確立を行います。このTCPにおいて使用されるコネクションの確立 のことを3ウェイハンドシェイクといいます。以下の手順の通り “3回のやりとり" によって確立されます。 ① ホストAからホストBにコネクション確立の要求をします。つまり、TCPヘッダの中にあるSYNビットは 「1」でありACKビットが「0」であると分かります。シーケンス番号は最初だけはランダムな値が割り当て られます。今回は例として「0」とします。確認応答番号(いわゆるACK番号）は通信の開始にはありません。 ② ホストBはホストAのコネクション要求に応えます。そしてホストBからもコネクション確立を要求します。 つまりSYNは「1」ACKは「1」であること
TCPを（少しは）理解しておくべきその理由 | POSTD
この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 （訳注：日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 ）を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました（ またPythonでTCPスタックを書いたらどうなるかについても書きました ）。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ
相手がいないのに 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アドレスとクライアントからの入力をクライアントに送信して切断するだけの簡単なプログラム
syncookiesとListenバックログとパケットロスト
たまにはLinuxネタを。 Listenバックログは、伝統的なUNIXの実装だと、SYN_RCVDとESTABLISHEDの両方のソケット数を数えますが、LinuxのそれはESTABLISHEDな状態の数だけを数えるようになっています(manを見よ)。 これは何でかというと、いわゆるSYN Flooding攻撃への対応として、Linuxはsyncookieを実装したことの副作用なのだと思います。syncookieを実装していると、SYNに対してSYN_ACK(COOKIE)を返すコストがほぼゼロ（メモリコストとしては）になるので、来たSYNにすべてSYN+ACKを返すことが可能です。 したがって、SYN_RCVDの数は数えても意味がなくなったので、それはListenバックログの数としてカウントしないようにした、ということのようです（厳密に言うと、tcp_max_syn_backlog個まで
LinuxでTCP_DEFER_ACCEPTが有効でもaccept後readできない理由
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jpという記事の中で、listen backlog があふれた後に accept(2) すると、その後の read(2) が EAGAIN を返したり、接続が不安定になるという事象が説明されていました。気になったので調べてみたことをまとめます。 結論から言うとこれはLinuxの仕様です。manのtcp(7)を見ると、 TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
Multipath TCPについて
Multipath TCPとは、複数の経路を扱うためのTCP拡張である。実は、以前、本の虫: MultiPath TCPのLinuxカーネル実装という記事で、その実装デモを紹介している。 従来のTCPは、IPとの分離ができない。TCPヘッダーの中には、ひとつのIPアドレスとポートがある。経路ごとにIPアドレスが割り振られるので、経路を変えるには、別のTCPコネクションを貼り直さなければならない。 しかし、複数の通信経路を持つという環境は、もはや珍しいものでも何でもなくなっている。たとえば、多くのラップトップにはEthernetとWiFiの二つの経路があるし、スマートフォンにも、WiFiと3G/4Gという複数の経路がある。特にスマートフォンの場合、経路が使えるかどうかが頻繁に切り替わる。 過去に、TCPで複数のIPアドレスを扱う拡張はいくつも出されたが、いずれも、IPアドレスを隠すという点で
TCP Fast Openを試してみる - milieuの日記
kernel3.8がリリースされてついにTCP Fast Openがクライアント、サーバサイド共に実装さた。カーネルのソースを見てみるとやはり結構な変更でpatchで2000行レベルらしく、これ仕事で実装したくないなーというかバグを出す自信があるというのが正直な感想だが、とりあえず動作概要ぐらいは知っておかないとまずいので遊んでみた。TCP Fast Openの認証？部分でAESを使うらしくSandy BridgeならAES-NIを使えばCPU負荷的に問題ないかとか調べたかったが、家で使用しているPCはCPUが残念ながらWestmereなのでそれは諦めた。動かすにあたりFedora18を用意しないと！と思いたちVM環境にインストール。そういえばFedora18がリリースされた当初はVMwareにインストールを試みたが失敗したという苦い記憶が蘇えったが、今回はVirtualboxだったおかげ
iOS 7でMPTCPがサポートされた話
iOS 7でMPTCP(Multipath TCP)がサポートされた。 ((Apple iOS 7 surprises as first with new multipath TCP connections)) 唐突 ((しかし実はIETF87で、anonymous OSが実装しているという話もあり、iOS 7がそれだったのかと納得した訳だが))なのだが僕の博士課程における研究テーマであり、先のIETFで大人たちにメッタメタにされたのも悔しいのでMPTCPについて説明して、何が出来るようになるかを書きたいと思う。 MPTCPとは簡単にいうとTCPストリームを複数の経路で転送することにより、ストリームの多重化・耐障害性の向上を図るプロトコルである。 このタイミングでなぜこうしたプロトコルが必要か簡単に説明したい。 僕らが使うアプリケーションは大抵TCPを用いて通信をしている。それは長いインタ
[001387]さくらのVPSで「CentOS」を利用していますが、回線速度が遅くアクセスに時間がかかります。 | FAQ Search - さくらインターネット
完全一致 さくらのVPSにおいて、不特定のVPS収容ホストとクライアント環境(プロバイダ等)の組み合わせ により、さくらのVPSからのダウンロード方向の通信に遅延が発生する場合があります。 ・http,ftp,scp等でのファイルのダウンロード速度が極端に遅い。 ・ファイルをダウンロード中に通信が切断される。 ・ホームページの静的なコンテンツ表示に異常に時間がかかる。 上記のような現象が確認された場合、設定変更を行うことで回避できる場合があります。 ■設定方法 ※以下の手順は root として操作する必要があります。 1. ethtool コマンドの実行 ethtool コマンドにて tcp segmentation offload を off に設定します。 # ethtool -K eth0 tso off 上記設定は再起動を行うと無効になります。 2. 設定の確認 下記のコマン
[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority
前回の続き。 パケット自体を零さずに処理に入った後にSYNを落とすのは以下3パターン。 syncookie無効時にsynのbacklog(tcp_max_syn_backlog)が溢れている listenのbacklogが溢れている(3way-handshake完了後のaccept待ち接続) net.ipv4.tcp_tw_recycleの制限に抵触 で、今回問題になっていたのは最後のtcp_tw_recycleへの抵触だった。 現象として発生しうるのは、以下の条件をすべて満たす場合 サーバ側でnet.ipv4.tcp_tw_recycleが有効 TCPタイムスタンプオプションを使用 同一IPからの接続でセッションを跨ぐとセットされるTCPタイムスタンプの値が戻る場合がある 最後の条件が微妙だが、TCPタイムスタンプの値としてセットされる値は起動時を 起算時にしていたりと実装によって初期値
![[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority](https://cdn-ak-scissors.b.st-hatena.com/image/square/264702d4cb37ced3c2fd5dda6a1368c235356862/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127119925553%2F17680117127119930188%2F1557218483)
Iperfの使い方 - TECHNERD::INIT
ネットワークの帯域を計測する場合、非常に便利なツールです。 UNIX系ではnetperfが有名かと思いますが、UDPの計測に関してはIperfの方が使いやすいと思います。 WindowsやLinuxなど各種OSで使用できます。 ダウンロード NLANR/DAST : Iperf - The TCP/UDP Bandwidth Measurement Tool http://sourceforge.net/projects/iperf 使い方 下記に、コマンドの使い方を記しておきます。 ユニキャストモード TCPの場合 サーバー $ iperf -s クライアント $ iperf -c <受信側ホスト名> または <受信側IPアドレス> 例1)TCP通信での最大レートを測定する。Netperfでの測定とほぼ同様。 $ iperf -c 192.168.1.100 例2)100Mbyteのデー
ホストのネットワーク接続は正しく行われているか？
連載：ネットワーク・コマンドでトラブル解決（5） ホストのネット接続は正しく行われているか？ ～netstatによるネットワーク設定の確認～ 加地眞也 2002/1/30 ■接続の管理とアプリケーション ～TCP／UDPとIPの関係 一般に、IPネットワークにおいては、IPというプロトコルはあくまでホスト間のネットワーク接続（正確には一方向のデータ送信）を実現しているにすぎない。これだけでは、通常のアプリケーションがネットワークを利用できるとはいえない。両ホスト上のアプリケーション同士を結び付ける仕組みが必要になる。これがTCPやUDPの役割だ。 普通「ネットワーク接続」といった場合には、実際にはTCPやUDPレベルにおける「アプリケーション間接続＊1」を意味している。単に、どのホストと通信しているかというIPレベルのみならず、アプリケーションが別のどのホストのアプリケーションと接続を維持
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
