著者: 坪内佑樹(*1), 古川雅大(*1) 所属: (*1) 株式会社はてな 研究会: Web System Architecture研究会#3 はじめに ウェブシステムは，一般的に，分散したホスト上で動作するソフトウェアが互いにネットワーク通信することにより構成される． 相互にネットワーク通信するシステムにおいて，システム管理者があるネットワーク内のノードに変更を加えた結果，ノードと通信している他のノードに変更の影響がでることがある． ネットワーク接続数が多いまたはノードが提供するサービスの種類が多くなるほど，システム管理者が個々の通信の依存関係を記憶することは難しくなる． さらに，常時接続しておらず必要なタイミングで一時的に通信するケースでは，あるタイミングの通信状況を記録するだけでは通信の依存関係を把握できない． その結果，システムを変更するときの影響範囲がわからず，変更のたびに依
Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
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 API for this feature. Those changes have been made and merged; read on for the details. This API is intended to make it possible to read data from a T
サーバ間で分散処理を行う際の相互通信におけるボトルネックを解消するため，smux(Socket multiplexer)を開発している． サーバ間の相互通信におけるボトルネックとその解決策 一対のサーバ間で多数のリクエストとレスポンスが送受信され，信頼性の高い通信としてTCPを利用する場合，コネクション確立のオーバーヘッドを排除するために接続の再利用が行われる．しかしながら，クライアントは送信に対する受信を待つ必要があるため，レスポンスまでに幾許かの処理時間を要する状況では送信のキューがたまってしまう．そこで複数の接続を利用することでこれを解消する方法が取られるが，追加の接続はリソース使用に関するオーバーヘッドを発生させてしまう．なにより各接続におけるレスポンス待ち時間は依然として解決しておらず，接続の利用面から見て非効率である．そこで，単一の接続において，仮想的に並行送受信を行う方法が提
概要 普段あたりまえのようにネットワークを使っていますが、「IPアドレスを持っている」とはどういったことか、本当に理解できているでしょうか。本書では、IPやUDP、TCPを自作し、ネットワークの仕組みを体験。pingのやりとりを行うプログラムを、DHCPクライアント機能の実装、TCPの送受信と切断を行うものへと拡張していくことで、RFCを眺めるだけでは見えにくいプロトコルの全体の流れをつかめます。ソケットライブラリに頼っていては得られない、問題の切り分けや問題発生の予防に役立つ力も身につきます。 著者の一言 誰もが、PCにネットワークケーブルを挿して、スイッチングHUBに接続、あるいは、スマートフォンをWi-Fi接続するとインターネットが使えるようになるのは「あたりまえ」だと感じていると思います。しかし、インターネットでの通信の基本である「IPアドレスを持っていること」とはどういう状態なの
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
最近 TCP BBR congestion control comes to GCP – your Internet just got faster が話題になっていた．しかし，この記事を読んだ時点での自分の BBR についての知識は，「既存のものよりいい感じにしてくれる輻輳制御」ぐらいだった．これではまずいということで，BBR とはなんなのかについて，既存の輻輳制御にも触れながら，元の論文1 をメインにまとめた．自分が理解するための文書であるが，一応としての想定読者は，TCP が輻輳制御を行っていることを知っているぐらいの人である．TCP については，拙著の TCP/IP とパフォーマンス に短くまとめてあるので参照できる． 免責事項: TCP を深く研究しているわけではなく，間違いを記述している可能性があります．コメントで教えていただけると助かります． 概要 BBR (Bottlene
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第22回 パケットロスに基づかない新しい輻輳制御の仕組み ― BBR（前編） (中井悦司) 2017年8月 はじめに 今回は、2016年に公開された学術記事「BBR: Congestion-Based Congestion Control」をもとにして、Googleが開発した、ネットワーク通信における新しい輻輳制御の仕組みを解説します。TCP/IPネットワークで伝統的に用いられてきた輻輳制御では、ネットワーク上でのパケットロスを検知した際にパケットの送出頻度をおさえるという仕組みが利用されています。しかしながら、この仕組みには、現代の高性能なネットワーク機器には最適化されていないという課題がありました。ネットワークの帯域を十分に活用しながら、パ
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
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は試してみる価値があるかもしれない。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に関しては
こんにちわ。せじまです。 先日ポチった C302CA が届いたんですが、（話が長くなるのですごい雑にいうと）Chromebook の、いろいろ削ぎ落として最適化するという方向性には、とても学ぶところがありました。 昨年末、 MySQLのサーバ集約に取り組んでいるという話をさせていただきましたが、「DB集約できてきたので、Webアプリケーションサーバも集約するかー」ということで、最近はWebサーバの集約にも取り組んでいます。 ただ、PHPゴリゴリ書いてるのではなく、集約していく上で Linux や TCP 的な観点からチューニングしたほうが良いところを見てまして、そのへんについてあるていどまとまったので、次のスライドを書かせていただきました。
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
ネットワークのトラブルシュートなどをする時にtcpdumpやwiresharkといったツールを使ってキャプチャデータを取得し、正常ではない通信を特定するなど分析します。その時にIPアドレスやポート番号といったことは当然確認すると思いますが、本記事ではそれ以外に分析に利用できそうな小技をいくつか紹介したいと思います。お題は以下のとおりです。 MACアドレスからNICのベンダーが分かる IPヘッダからおおよそのホップ数が推測できる TCP/IPヘッダからOSを推定できる TCPの3-way-handshakeからネットワークの遅延を測れる TCPの再送状況からネットワーク品質の変化を見れる DHCP/mDNS/NBNS/LLMNR から同一ネットワーク内のホスト名がわかる TLSのclient helloから接続先のホスト名がわかる 【注意事項】 本職のネットワークエンジニアの方にとっては当た
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
