誰もがTCPを知っているはずだ
作者:Julia Evens原文リンク:Why you should understand(a little)about TCP
あなたの仕事はTCPを手のひらで知る必要がないかもしれませんが、具体的なTCP/IPインスタンスを理解する必要はありません.基本的なTCPの知識も知っておくべきで、本文はあなたになぜかを教えます.
私は以前Recurse Centerで働いていたとき、PythonでTCPスタックを書いたことがあります(PythonでTCPスタックを実現することで何を学ぶことができるかというブログも書きました).これはとても面白い授業で、基本的に私はTCPのすべてを理解しました.
1年後,仕事で困難にぶつかった.ある同僚はSlackで「ねえ、NSQにメッセージを押すといつも40 msの遅延があるのに、なぜか分からない」と聞いた.この問題はいろいろ考えてみたが,1週間が過ぎたが,まだ何の見当もつかない.
ここで説明すると、NSQはメッセージを送信するためのキューである.送信方式はlocalhostにHTTPリクエストを送信するものであり,この動作に40 msを費やすことは不可能であり,間違いに違いない.しかしNSQはCPU優先度が高くなく、メモリも大量に消費されていないため、問題はゴミ回収側ではない.
その後、1週間前に読んだ文章を思い出しました.POSTリクエストごとに200 msを節約する方法を思い出しました(In search of performance-how we shaved 200 ms off every POST request).この文章は、最初はPOSTごとに200 msも多く使う理由を議論していますが、多少奇妙です.次はこの文章の内容です.
ACK遅延とTCP_NODELAY
RubyのBet::HTTPはPOST要求を2つのTCPパケット--1つのヘッダ、1つのbodyに分ける.curlは、それに比べて1つに組み合わせるのが適切です.さらに悪いことに、Net:HTTPはTCP_を開いていません.NODELAYなので、1つ目のパケットを送信した後、確認するまで2つ目を送信します.結局、これはNagleアルゴリズムによるものです.
接続の反対側で、HAProxyはこの2つのパッケージをどのように確認するかを選択します.1.4.18(正式に使用されているバージョン)では、TCP遅延確認が使用され、遅延確認はNagleアルゴリズムで悪化し、タイムアウトまでリクエストがこの場所で一時停止した.
この話をまとめてみましょう. TCPは、送信するデータをパッケージ化するアルゴリズム です.彼らのHTTPは2つのパケットでPOST要求 を送信する必要がある.
プロセス全体は次のようになります.
アプリケーション:ハイ!最初のバッグをあげるHAProxy:嘘......私たちは2番目のバッグを待つHAProxy:そうだ、私たちは彼に確認しなければなりませんが、大したことはありません.アプリケーション:嘘......私たちは最初のバッグの確認を待ってから2番目に送ります.ネットが渋滞しているかもしれません.もう少し待ってください.HAProxy:うんざりしています.最初のパッケージの確認を送りましょうアプリケーション:確認を受け取り、2番目のパッケージを送りましょう!!!HAProxy:やった!
この間、HAProxyとアプリケーションは200 msを超えるまで消極的に待っていた.アプリケーション待ちはNagleアルゴリズム,HAProxy待ちはACK遅延のためである.
私の知る限りでは、遅延ACKはすべてのLinuxシステムでデフォルトで開かれています.だからこれは特例ではありません.あなたが送ったデータが1つ以上のTCPパッケージであれば、あなたもこのようなことに遭遇します.
やっと問題が解決した
この文章を読んで、もう何も起きられないと思った.しかし、私たちの神秘的な40 msで長い間もがいていたので、この文章を思い出しました.
これは私の問題かもしれませんか?可能ですか?可能ですか?!私はチームに「気が狂ったのかもしれないが、TCPの問題かもしれない」とメールを送った.
そこで私は
すべての40 msの遅延はすべて消えて、この世界は完璧です.私は本当に天才ですね.
ACK遅延は完全に閉じるべきですか?
エピソードを言うと、HNでこのコメントを見ました.
本当の問題はACK遅延にある.200 msの遅延設定は悪い考えで、1985年にバークレーでBSDをやった人たちは、この問題を全く理解していない.ACK遅延は,賭博アプリケーション層が必ず200 ms以内に返信を受け取ることである.ほぼ毎回負けますが、ACK遅延は依然として使用されています.
彼はコメントの中でACKがコストが低いことを議論し、このやり方による問題はそれが解決した問題よりずっと深刻である.
TCPが分からないと、この問題は分かりません.
以前はTCPはかなり下位のものだと思っていましたが、私は永遠にそれを理解する必要はありません.それほど差はありませんが、実際の生活では、TCPアルゴリズムに関連するBugに出会う可能性があります.このとき、TCPの知識を知ることが重要です.△本稿では、システム呼び出し、オペレーティングシステムなどが重要であり、この理屈は多くのものに適用されると引用することもできる.
ACK遅延/TCP_NODELAYは大変です.HTTPリクエストコードを書く人に影響を与える可能性があります.しかし、あなたはシステムのプログラミングの天才になる必要はありません.TCPを少し知って私にこの問題を解決してくれました.この問題が発生しても私にも責任があることに気づきました.私もstraceを使っています.strace万歳!
翻訳者:頼信涛、Pythonに注目して、プログラミングと電子ゲームが好きで、個人ブログ:http://www.kawabangga.com/
あなたの仕事はTCPを手のひらで知る必要がないかもしれませんが、具体的なTCP/IPインスタンスを理解する必要はありません.基本的なTCPの知識も知っておくべきで、本文はあなたになぜかを教えます.
私は以前Recurse Centerで働いていたとき、PythonでTCPスタックを書いたことがあります(PythonでTCPスタックを実現することで何を学ぶことができるかというブログも書きました).これはとても面白い授業で、基本的に私はTCPのすべてを理解しました.
1年後,仕事で困難にぶつかった.ある同僚はSlackで「ねえ、NSQにメッセージを押すといつも40 msの遅延があるのに、なぜか分からない」と聞いた.この問題はいろいろ考えてみたが,1週間が過ぎたが,まだ何の見当もつかない.
ここで説明すると、NSQはメッセージを送信するためのキューである.送信方式はlocalhostにHTTPリクエストを送信するものであり,この動作に40 msを費やすことは不可能であり,間違いに違いない.しかしNSQはCPU優先度が高くなく、メモリも大量に消費されていないため、問題はゴミ回収側ではない.
その後、1週間前に読んだ文章を思い出しました.POSTリクエストごとに200 msを節約する方法を思い出しました(In search of performance-how we shaved 200 ms off every POST request).この文章は、最初はPOSTごとに200 msも多く使う理由を議論していますが、多少奇妙です.次はこの文章の内容です.
ACK遅延とTCP_NODELAY
RubyのBet::HTTPはPOST要求を2つのTCPパケット--1つのヘッダ、1つのbodyに分ける.curlは、それに比べて1つに組み合わせるのが適切です.さらに悪いことに、Net:HTTPはTCP_を開いていません.NODELAYなので、1つ目のパケットを送信した後、確認するまで2つ目を送信します.結局、これはNagleアルゴリズムによるものです.
接続の反対側で、HAProxyはこの2つのパッケージをどのように確認するかを選択します.1.4.18(正式に使用されているバージョン)では、TCP遅延確認が使用され、遅延確認はNagleアルゴリズムで悪化し、タイムアウトまでリクエストがこの場所で一時停止した.
この話をまとめてみましょう.
プロセス全体は次のようになります.
アプリケーション:ハイ!最初のバッグをあげるHAProxy:嘘......私たちは2番目のバッグを待つHAProxy:そうだ、私たちは彼に確認しなければなりませんが、大したことはありません.アプリケーション:嘘......私たちは最初のバッグの確認を待ってから2番目に送ります.ネットが渋滞しているかもしれません.もう少し待ってください.HAProxy:うんざりしています.最初のパッケージの確認を送りましょうアプリケーション:確認を受け取り、2番目のパッケージを送りましょう!!!HAProxy:やった!
この間、HAProxyとアプリケーションは200 msを超えるまで消極的に待っていた.アプリケーション待ちはNagleアルゴリズム,HAProxy待ちはACK遅延のためである.
私の知る限りでは、遅延ACKはすべてのLinuxシステムでデフォルトで開かれています.だからこれは特例ではありません.あなたが送ったデータが1つ以上のTCPパッケージであれば、あなたもこのようなことに遭遇します.
やっと問題が解決した
この文章を読んで、もう何も起きられないと思った.しかし、私たちの神秘的な40 msで長い間もがいていたので、この文章を思い出しました.
これは私の問題かもしれませんか?可能ですか?可能ですか?!私はチームに「気が狂ったのかもしれないが、TCPの問題かもしれない」とメールを送った.
そこで私は
TCP_NODELAYを開けて、それから--BOOM!すべての40 msの遅延はすべて消えて、この世界は完璧です.私は本当に天才ですね.
ACK遅延は完全に閉じるべきですか?
エピソードを言うと、HNでこのコメントを見ました.
本当の問題はACK遅延にある.200 msの遅延設定は悪い考えで、1985年にバークレーでBSDをやった人たちは、この問題を全く理解していない.ACK遅延は,賭博アプリケーション層が必ず200 ms以内に返信を受け取ることである.ほぼ毎回負けますが、ACK遅延は依然として使用されています.
彼はコメントの中でACKがコストが低いことを議論し、このやり方による問題はそれが解決した問題よりずっと深刻である.
TCPが分からないと、この問題は分かりません.
以前はTCPはかなり下位のものだと思っていましたが、私は永遠にそれを理解する必要はありません.それほど差はありませんが、実際の生活では、TCPアルゴリズムに関連するBugに出会う可能性があります.このとき、TCPの知識を知ることが重要です.△本稿では、システム呼び出し、オペレーティングシステムなどが重要であり、この理屈は多くのものに適用されると引用することもできる.
ACK遅延/TCP_NODELAYは大変です.HTTPリクエストコードを書く人に影響を与える可能性があります.しかし、あなたはシステムのプログラミングの天才になる必要はありません.TCPを少し知って私にこの問題を解決してくれました.この問題が発生しても私にも責任があることに気づきました.私もstraceを使っています.strace万歳!
翻訳者:頼信涛、Pythonに注目して、プログラミングと電子ゲームが好きで、個人ブログ:http://www.kawabangga.com/