第2回 TCP/IP高速化：大量データをまとめて送信
高速化技術を理解するには，基本となるもともとのTCP/IP技術を押さえておく必要がある。TCP/IPのスループットは理論上，「1パケットで受信できるデータ量（RWIN）÷1パケットの受信が完了するまでの遅延時間（RTT）」で求められる。LinuxやWindows 2000 SP3以降の主要なOSは，TCP仕様の最大値64Kバイト（512kビット）をRWINとして設定する。RTTが20ミリ秒だとすると，スループットは最大約25Mビット/秒となる。 この環境で100Mビット/秒の帯域を占有できるとすれば，約25Mビット/秒では遅い。つまり，もともとのTCP/IPでは力不足というわけだ。その最大の理由は，TCP通信の「フロー制御」と「輻輳制御」の仕組みにある。 大量データをまとめて送信 フロー制御から説明しよう。これは確実にデータを送信する機構のことで，TCP通信の基本である。TCPは，送信デー
TCP/IPと送受信側のバッファの働きについて - TCP/IPの通信を行う、送信・受信装置があった場合、送信側のバッファの挙動について分... - Yahoo!知恵袋
TCP/IPと送受信側のバッファの働きについて TCP/IPの通信を行う、送信・受信装置があった場合、送信側のバッファの挙動について分からない ことがあります。 受信側（サーバ側）は自身の受信バッファの状況に応じて送信側に対して、ウィンドウ制御を行うと思います。 受信側のバッファリソースが少なく、送信側に切り出すデータ単位を小さく働きかけるウィンドウ制御を行った 場合、送信側のバッファが溢れることになるのでは（もしくは、必要情報が上書き）と考えています。 具体的には： 受信側がすでに他のデータ受信により受信できるデータ量が少ないという条件で、送信側が高いスループットで 送ろうとした場合に、送信側がデータを出そう出そうとはするものの、受信側からウィンドウ制御を強く受けて送信側 の送信バッファへの書き込みができなくなったり、本位ではないものの上書きをしてしまったりすることがないのか気になりまし
データ転送速度が劇的に改善されるマジック - Cube Lilac
改造Firefoxで日米間6.5GbpsのWebアクセス。東大が世界最速達成 -BB Watch より。私は 1Gbps 以上の世界は完全に未知の世界なので、今回の記事は「どうやって 6.5Gbps ものデータ転送速度を達成するか」ではなく「何故、改善前は（そんな高速ネットワーク環境下で） 6Mbps 程度のデータ転送速度しか出せないのか」と言うお話です。 TCP のデータ転送（ダウンロード）では、ソケットバッファの値を弄っただけで劇的にデータ転送速度が改善される場合があります。 ソケットバッファとは？ あるサーバ/クライアント間でデータ通信をする際、パケットが、受信ホストに到着するタイミングと（受信ホストの）アプリケーションが、到着したパケットを読み込むタイミングは非同期です。そのため、パケット（データ）は到着したのだけれどアプリケーションがまだ読み込みに来てくれないと言う場合に、そのデ
Hypermail
Re: HAProxy + Heartbeat From: Willy Tarreau <w#1wt.eu> Date: Thu, 25 Mar 2010 22:38:43 +0100 Hi Daniel, On Tue, Mar 23, 2010 at 10:06:35PM +0100, Daniel Storjordet wrote: > Hi! > > HaProxy is great! > > We have 2 servers running VMWare ESXi, each having a CentOS with HaProxy > and Windows 2008 virtual machines. The 2nd innstallasjon of CentOS with > HaProxy has been lying dormant for awhile but no
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
3 Minutes Networking No.38
Log in with Atlassian account
