サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
パリ五輪
zi-kuwai.blog.ss-blog.jp
久々のTCPネタ。 TCPのRSTについてこの記事でも簡単に触れた。 このRSTがどのようなタイミングで送信されるかというと、OSのソケットバッファに 受信データがまだ残っているにもかかわらず、アプリがcloseを実行したときに送信される(Linuxのお話)。 つまり、まだ受け取るべきデータが残っているにもかかわらず、有無を言わさずアプリが closeを実行してきたので、これは異常な状態だ、ということでRSTを送信し、 その受け取るべきデータを送ってきた送信者側に、「もうデータは送らないでくれ」と伝えたいのである。 さて、これを踏まえて考えると、実は下記のようなケースで問題が発生する。 マシンA(HTTPクライアント)はHTTP POSTのヘッダ(仮に1024バイトとする)とHTTP POSTのボディ(仮に8192バイトとする)をマシンB(HTTPサーバ)に送信した。 マシンBのOSは、9
技術系、非技術系のネタを書き散らしてます。ちなみに、じーくゎいとは子供が赤ん坊の頃によく叫んでいた謎の言葉です。 TCP の世界で、Nagle アルゴリズムと Delayed Ack が組み合わさった時の 問題は結構有名な話。 ネットワークソフトウェアエンジニアのバイブル UNIXネットワークプログラミング〈Vol.1〉 にもしっかりと載っている。 簡単に説明しておくと、 Nagleアルゴリズム 送信データ(セグメント)をOSが溜め込む。溜め込んだデータを送信するタイミングは下記の通り。 OS(TCP)の気持ちも書いておく。 * すでに送信しているデータのAckが返るまで。 → お、さっき送ったデータのAckを受け取ったぞ。 じゃあ次のデータを相手に送ってやらなきゃ。 * 溜め込んでいるデータ量がMSSを超えるまで。 → やべ、データをたくさん(量的に)溜め込みすぎた。 * タイムアウトを
このページを最初にブックマークしてみませんか?
『zi-kuwai.blog.ss-blog.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く