タグ

TCPに関するf99aqのブックマーク (6)

  • カオステストでHTTP/2の問題を見つけ出す | POSTD

    (注:2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー

    カオステストでHTTP/2の問題を見つけ出す | POSTD
  • net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita

    Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 文中で Linux のコード/ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう(というかできません)。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ

    net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
  • 相手がいないのに 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アドレスとクライアントからの入力をクライアントに送信して切断するだけの簡単なプログラム

    相手がいないのに ESTABLISHED になってる TCP ポート - tmtms のメモ
  • Big Sky :: libuvを使ってみた。

    node.jsのスライドを見てて、プラットフォームの違いを吸収するnode.jsの核でもある非同期通信ライブラリuvを今日知ったので試してみた。 joyent/libuv - GitHub platform layer for node.js https://github.com/joyent/libuv libev/libeventをwindowsでもちゃんと使いたいという所から出てきたライブラリ。 #include <iostream> #include <uv/uv.h> int main() { int r; uv_tcp_t tcp; struct sockaddr_in server_addr; server_addr = uv_ip4_addr("127.0.0.1", 80); r = uv_tcp_init(uv_default_loop(), &tcp); uv_con

    Big Sky :: libuvを使ってみた。
  • 受け取ったUDPパケットのデスティネーションアドレスを知る方法

    マルチホームホストなどで複数のアドレスが振られている場合に、受け取ったパケットがどのアドレス宛てのものなのかを知りたい場合がある。 ソケットAPIのrecvfrom(2)では、パケットを送出した側のソースアドレスを知ることはできても、相手がどのアドレスに送ってきたのかを知ることはできない。 TCPならばaccept()後にgetsockname()で調べることができるけれども、はて、UDPではどうしたらいいのか(おまけ:TCPでもaccept前に知りたい場合があるよね)、というお話。

    受け取ったUDPパケットのデスティネーションアドレスを知る方法
  • グーグルがWebを高速化するために何をしているか

    のページをめくるように、どんなWebページも素早く表示できるようにする。グーグルは以前からWebの高速化に取り組んできました。 6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」では、グーグルのUrs Hölzle氏がWebの高速化技術について「Speed Matters」(スピードの重要性)というセッションで紹介ています。 Webを高速化するためにどのような技術があり、あるいはどのような技術が検討されているのか、このセッションの内容を紹介しましょう。 スピードは重要だ 私が話そうとしているのは、「Speed matters」(スピードの重要性)についてだ。Webは空飛ぶジャガイモより速くなれるだろうか? どのくらい速くなれるだろうか? (参考:オペラがやってくれた! グーグルの空飛ぶジャガイモに対抗)

    グーグルがWebを高速化するために何をしているか
  • 1