iphone(iOS 11)でMultiPath TCPを使う - ASnoKaze blog
すでにアナウンスされているとおり、iOS11よりMultipathTCP (MPTCP)のAPIがサードパーティデベロッパーに公開されます。 実はiPhoneをお使いの人はすでに、iOS7からsiriでMPTCPが使われていたので裏ではすでに使われておりましたが、実際にみんなが試せるような状況になってきました。 MultiPathTCP (MPTCP)とは MultipathTCPは複数のインターフェースを用いてTCPコネクションをはる事のできる、TCP拡張の一つです。例えばスマートフォンであればLTEとWi-Fiといった2つのインターフェースを用いてコネクションをはり、両方の経路それぞれを併用してデータ通信をします。 大きなメリットとしては、使える帯域が増えるということだけではなくアプリケーション側からは1つのTCPコネクションに見えており仮に片方のコネクションが切れたとしてもTCPコネ
LinuxカーネルのTCPスタックとシステムコールの組み合わせによる手法よりも高速にポートのListenチェックを行う - 人間とウェブの未来
まずは前回の記事で盛大な誤認をしていたことを訂正しなければなりません。 hb.matsumoto-r.jp 前回の記事では、高速にリモートホストのポートチェックを3パケットで実現する実装を行うために、RAWソケットとユーザランドの簡易TCPスタックを実装してパケットを放出しましたが、カーネルのTCPスタックによって自動的にRSTパケットが返されるため、RSTパケットが返されるよりもはやくrecvfromしないとSYN+ACKを受け取れないと述べました。 しかし、以下のようにご指摘を頂き、 @matsumotory LinuxのSOCK_RAW+IPPROTO_TCPの場合、カーネルがRSTを送出したとしても同マシン上の既存raw socketに対するrecvfrom()が0を返すことはないと思うのですが、検証されているカーネルのバージョンはいくつでしょうか？— Hiroki Sato (@
TCPを（少しは）理解しておくべきその理由 | POSTD
この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 （訳注：日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 ）を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました（ またPythonでTCPスタックを書いたらどうなるかについても書きました ）。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ
ngx_mrubyのTCPロードバランシングを使ってFluentdのTCP通信とグラフ画像へのHTTP通信を動的に集約する - 人間とウェブの未来
昨日、ngx_mrubyのTCPロードバランシング機能に対応した記事を書きました。 hb.matsumoto-r.jp というのも、実は以下に説明するようなFluetnd+Norika+GrowthForecastを利用したスケールアウト型のシステムを簡単に作りたかったからです。 ということで、まずはプロトタイプ設計みたいなものをフワっと考えてみました。 実現したい事 まずやりたいこととして、 1000台以上のサーバ群からのFluentdによるTCPデータをそれぞれの転送元サーバに紐づく任意のバックエンドサーバに振り分けたい 転送元サーバ群はそれほど増減しない バックエンドサーバをスケールアウト型に増やす場合に、転送元サーバの設定は変更したくない 転送されたログは転送先サーバ内でグラフ化されるので、任意のHTTPクライアントによって取得したい転送元サーバのグラフ画像を適切なバックエンド（F
PythonでTCPスタックを記述するとどうなる？ | POSTD
Hacker School在籍中、ネットワーキングの理解をより深めたいと思い、小規模なTCPスタックを書いてみようと思い立ちました。個人的には、C言語よりもPythonの方になじみがありましたし、その頃ちょうど、パケット送信を 非常に簡単に する scapy ネットワーキングライブラリも見つけたところでした。 そんなわけで、 teeceepee を書き始めました。 基本的な構想は次のとおりです。 TCPパケットを送信可能にするRaw socketを開く google.comを取得するためにHTTP要求を送る 応答を取得しパースする 成功を祝う 適切なエラー処理などについてはさほどの注意も払わず、ただただウェブページを取得し、勝利を宣言しようと思っていました(^_^) ステップ1：TCPハンドシェイク 手始めは、GoogleとのTCPハンドシェイクです（以下は必ずしも正しく動作しませんが、原
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
TCP Fast Open を試してみる - nigakyのブログ
Linux カーネル 3.6 では TCP Fast Open (TFO) という機能がマージされたそうです。詳しくは以下の URL に記載がありますが、一度接続したクライアントは TCP の 3way-handshake を簡略化してコネクションをオープンできる（SYN にデータを載せられる）という機能のようです。 TCP Fast Open: expediting web services [LWN.net] 面白そうな機能なので実際に使ってみて、使い方をまとめてみました。 準備 カーネル kernel 3.6 ではまだクライアント側の機能しかマージされていないので、さらに新しいカーネルを使います（3.7 でサーバ側の機能もマージされるようです）。今回は git で取ってきた最新 (12250d843e8489ee00b5b7726da855e51694e792) をビルドして使いまし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
