TCP接続の追跡による簡略化したネットワーク依存関係グラフの可視化基盤 - ゆううきブログ
著者: 坪内佑樹(*1), 古川雅大(*1) 所属: (*1) 株式会社はてな 研究会: Web System Architecture研究会#3 はじめに ウェブシステムは，一般的に，分散したホスト上で動作するソフトウェアが互いにネットワーク通信することにより構成される． 相互にネットワーク通信するシステムにおいて，システム管理者があるネットワーク内のノードに変更を加えた結果，ノードと通信している他のノードに変更の影響がでることがある． ネットワーク接続数が多いまたはノードが提供するサービスの種類が多くなるほど，システム管理者が個々の通信の依存関係を記憶することは難しくなる． さらに，常時接続しておらず必要なタイミングで一時的に通信するケースでは，あるタイミングの通信状況を記録するだけでは通信の依存関係を把握できない． その結果，システムを変更するときの影響範囲がわからず，変更のたびに依
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 は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
A reworked TCP zero-copy receive API [LWN.net]
LWN.net needs you!Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing In April, LWN looked at the new API for zero-copy reception of TCP data that had been merged into the net-next tree for the 4.18 development cycle. After that article was written, a couple of issues came to the fore that required some changes to the AP
TIME_WAITに関する話
3. 自己紹介 - まぁまぁ MySQL でご飯食べてます - 一時期は Resource Monitoring や KVS にも 力入れてました - ネットワーク的には素人です - Linuxとハードウェアは嗜む程度 - disk I/O にはむかしから興味あります - その他 slideshare はこちら - http://www.slideshare.net/takanorisejima/ 4. 本日のお題 - kernel 新しくしたりすると、TCP的に意識したほ うが良い変化が見つかるので - 今日は、Webアプリケーションサーバの観点か ら、 connect(2) する際に気になる TIME_WAIT について、書いてみようかと思います - 有識者からのマサカリを、強く歓迎いたします 5. 最初に参考資料 - この二つの記事を読んでいただけば、それで概 ね良いと思うんですが
Go言語でTCPやソケット通信を多重化，高速化するsmux(ソケットマルチプレクサ)をつくった · THINKING MEGANE
サーバ間で分散処理を行う際の相互通信におけるボトルネックを解消するため，smux(Socket multiplexer)を開発している． サーバ間の相互通信におけるボトルネックとその解決策 一対のサーバ間で多数のリクエストとレスポンスが送受信され，信頼性の高い通信としてTCPを利用する場合，コネクション確立のオーバーヘッドを排除するために接続の再利用が行われる．しかしながら，クライアントは送信に対する受信を待つ必要があるため，レスポンスまでに幾許かの処理時間を要する状況では送信のキューがたまってしまう．そこで複数の接続を利用することでこれを解消する方法が取られるが，追加の接続はリソース使用に関するオーバーヘッドを発生させてしまう．なにより各接続におけるレスポンス待ち時間は依然として解決しておらず，接続の利用面から見て非効率である．そこで，単一の接続において，仮想的に並行送受信を行う方法が提
ソースコードで体感するネットワークの仕組み ～手を動かしながら基礎からTCP/IPの実装までがわかる
2018年5月15日紙版発売 2018年5月9日電子版発売 小俣光之 著 A5判／272ページ 定価2,728円（本体2,480円＋税10%） ISBN 978-4-7741-9744-9 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 普段あたりまえのようにネットワークを使っていますが，「IPアドレスを持っている」とはどういったことか，本当に理解できているでしょうか。本書では，IPやUDP，TCPを自作し，ネットワークの仕組みを体験。pingのやりとりを行うプログラムを，DHCPクライアント機能の実装，TCPの送受信と切断を行うものへと拡張していくことで，RFCを
Debugging TCP socket leak in a Kubernetes cluster
Parts of Hasura's infrastructure runs on Google Kubernetes Engine (GKE). This includes around microservices which power the Hasura website among other internal services. Last month, we started noticing delayed API responses and connection refused errors. The errors were more significant if the response body size is larger. For e.g. downloading a file became extremely slow, as slow as ~5kbps, and s
BBR: Congestion-Based Congestion Control とは
最近 TCP BBR congestion control comes to GCP – your Internet just got faster が話題になっていた．しかし，この記事を読んだ時点での自分の BBR についての知識は，「既存のものよりいい感じにしてくれる輻輳制御」ぐらいだった．これではまずいということで，BBR とはなんなのかについて，既存の輻輳制御にも触れながら，元の論文1 をメインにまとめた．自分が理解するための文書であるが，一応としての想定読者は，TCP が輻輳制御を行っていることを知っているぐらいの人である．TCP については，拙著の TCP/IP とパフォーマンス に短くまとめてあるので参照できる． 免責事項: TCP を深く研究しているわけではなく，間違いを記述している可能性があります．コメントで教えていただけると助かります． 概要BBR (Bottlenec
コラム - グーグルのクラウドを支えるテクノロジー | 第22回 パケットロスに基づかない新しい輻輳制御の仕組み ― BBR（前編）｜CTC教育サービス 研修/トレーニング
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第22回 パケットロスに基づかない新しい輻輳制御の仕組み ― BBR（前編） (中井悦司) 2017年8月 はじめに 今回は、2016年に公開された学術記事「BBR: Congestion-Based Congestion Control」をもとにして、Googleが開発した、ネットワーク通信における新しい輻輳制御の仕組みを解説します。TCP/IPネットワークで伝統的に用いられてきた輻輳制御では、ネットワーク上でのパケットロスを検知した際にパケットの送出頻度をおさえるという仕組みが利用されています。しかしながら、この仕組みには、現代の高性能なネットワーク機器には最適化されていないという課題がありました。ネットワークの帯域を十分に活用しながら、パ
BBR: Congestion-Based Congestion Control - ACM Queue
December 1, 2016 Volume 14, issue 5 PDF BBR: Congestion-Based Congestion Control Measuring bottleneck bandwidth and round-trip propagation time Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, Soheil Hassas Yeganeh, Van Jacobson By all accounts, today's Internet is not moving data as well as it should. Most of the world's cellular users experience delays of seconds to minutes; public Wi-Fi in airpor
TCP BBR congestion control comes to GCP – your Internet just got faster | Google Cloud Blog
We're excited to announce that Google Cloud Platform (GCP) now features a cutting-edge new congestion control algorithm, TCP BBR, which achieves higher bandwidths and lower latencies for internet traffic. This is the same BBR that powers TCP traffic from google.com and that improved YouTube network throughput by 4 percent on average globally — and by more than 14 percent in some countries. BBR all
LinuxサーバをGoogleのTCP BBRで高速化する方法
もし新しい技術を好み、かつ、Linuxサーバの高速通信に興味があるなら、Googleが内部で開発を進めてきたとされてる新しいTCP輻輳制御アルゴリズムのBBRは試してみる価値があるかもしれない。7月21日(米国時間)、Nixcraftに掲載された記事「Increase your Linux server Internet speed with TCP BBR congestion control - nixCraft」が最近のLinuxカーネルでTCP BBRを有効にする方法を伝えた。 Googleは7月21日、公式ブログにおいて、 Google Cloud PlatformでTCP BBRが利用できるようになったことを伝えている。ブログの記事では、google.comにTCP BBRを導入して、利用前と利用後のネットワークのスループットを表すグラフを紹介している。YouTubeに関しては
TIME_WAITに関する話 | GREE Engineering
こんにちわ。せじまです。 先日ポチった C302CA が届いたんですが、（話が長くなるのですごい雑にいうと）Chromebook の、いろいろ削ぎ落として最適化するという方向性には、とても学ぶところがありました。 昨年末、 MySQLのサーバ集約に取り組んでいるという話をさせていただきましたが、「DB集約できてきたので、Webアプリケーションサーバも集約するかー」ということで、最近はWebサーバの集約にも取り組んでいます。 ただ、PHPゴリゴリ書いてるのではなく、集約していく上で Linux や TCP 的な観点からチューニングしたほうが良いところを見てまして、そのへんについてあるていどまとまったので、次のスライドを書かせていただきました。
TCP Fast Openの闇と、Kernelの緩和コミット - ASnoKaze blog
TCP Fast Open TCP Fast Openと呼ばれる技術があり、RFC 7413として標準化されている。 このTCP Fast Openを使うと、一度コネクションを貼った相手とは、TCPの3ウェイハンドシェイク中にデータを送受信できるようになる。クライアントからSYNとともにデータを送信することで、実際にデータを送受信開始するまでの待ち時間が短縮できる。 Linuxではすでにクライアント/サーバ両方でTCP Fast Openを使用できる。 TCP Fast Openの闇 しかし、数年前よりこのTCP Fast Openには一部のネットワークで奇妙な振る舞いをすることが知られている。Appleの人が実際にデプロイした時に見つけたもので、IETFやNANOGにて報告されており、その時の資料は下記のとおりである Deploying TCP Fast Open in the wild
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
google/netstack: IPv4 and IPv6 userland network stack
https://www.kernel.org/doc/Documentation/networking/proc_net_tcp.txt
TCP輻輳制御技術動向
ネットワーク ゲームにおけるTCPとUDPの使い分け
TIME_WAITに関する話
tcp_bbr: add BBR congestion control · torvalds/linux@0f8782e