[B! TCP] tztのブックマーク

tzt id:tzt

TCPに関するtztのブックマーク (12)

tcpdumpとiptablesの関係 - （ひ）メモ
追記 2009-04-03 まったくもってブコメでいただいた指摘の通りです＞＜ h2onda linux, tcpdump tcpdump(というかlibpcap)は、データリンク層(OSI layer2)レベルでパケットを取得する packet プロトコルを使ってるので、そうなります。参照: man packet(7) 2009/04/02 はてなブックマーク - h2ondaのブックマーク / 2009年4月2日 tt_clown network 細かいけど，図は逆︵NIC が下︶のが良いかなと思った．/ "ip"tablesと言う位だから，IP層でパケットをフィルタしてるて事だろうな．tcpdumpはEthernet Frameも見えるので，後は分かるな？・・・てとこか． 2009/04/02 はてなブックマーク - tt_clownのブックマーク / 2009年4月2日 pack
tzt 2009/04/02
programming

linux

network

TCP

iptables
リンク
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログで id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、接続のタイムアウト処理ログの出力メモリの確保や解放をやらないあたりにも気を配る必要がある、と思います。接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
tzt 2009/01/09
network

programming

TCP

c10k

socket
リンク
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う他に山ほど解説ページがあるので略大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。これっ
tzt 2009/01/09
network

programming

TCP

c10k

socket
リンク
TCP/IP エラー処理 connect 編
connect(2) のエラー TCP において connect(2) 呼出し時に発生する可能性のあるエラーは以下の通りです。タイムアウト RST 受信 EHOSTUNREACH また ENETUNREACH シグナル受信その他まず、connect(2) 時の正常な流れをしっかり覚えておいてください。 (connect(2) を呼んで) SYN を送る SYN+ACK が返ってくる (ここで connect(2) から戻る) ACK を送るタイムアウトもし仮に、SYN を送ったものの、相手側から SYN+ACK が返ってこない場合は、 (ローカルの TCP スタックが) しつこく SYN を再送します。何度 SYN を送っても SYN+ACK が返ってこない場合はあきらめてタイムアウトします。「SYN+ACK が返ってこない」というのは、例えば以下のようなケースが考えられます。
tzt 2008/11/25
programming

socket

tcp
リンク
Geekなぺーじ : 人生の全てはTCP/IPに学んだ
1. ゆずり合うこと TCPはネットワーク帯域を他のTCPセッションと譲り合います。 TCPには、ネットワークが混雑(輻輳:ふくそう)してくると、送信されるパケット量を減らす仕組みがあります。この譲り合いがあるからこそ、現在のインターネットは多数の人間が同時に使えています。同様に、現実世界においても無理な競い合いを行うよりも譲り合いを行った方がスケーラビリティが上昇します。 2. 信頼はきめ細やかな確認応答で実現されること TCPでは、信頼性を確保するためにAck(Acknowledgement、確認応答)を送信してデータの到着を伝えます。 TCPのセッションが確立している間は、Ackが細かく送受信され続けます。このきめ細かな確認応答が信頼の根幹であると言っても過言ではありません。現実世界においても、きめ細かく応答を行う事が重要です。メールなどを受け取っても、全く返事をしない相手
tzt 2008/04/16
TCP
リンク
Microsoft Corporation
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカルサポートを利用できます。
tzt 2008/03/30
TCP

windows
リンク
Omicron SACK
SACK TCP/輻輳制御から分家． Selective ACK/選択的応答確認 SACK Reno の高速リカバリが失敗したり，NewReno の高速リカバリがややまどろっこしいのは，TCP が累積確認応答(cumulative acknowledgments)をベースにしたスライディングウィンドウプロトコルだからである． Reno では重複 ACK でわかるのは，最初のパケットロスだけである．ウィンドウ内に複数のパケットロスが起きた場合，最初のパケットロスに対する再送を行っても，次のパケットロス箇所がわかるのは，その再送に対する ACK が戻った後になるので，1 RTT に一つのパケットロスしか知ることができない．そこで選択的に確認応答を可能にする SACK が提案され，使われ始めている(少なくとも Linux や Solaris ではデフォルトで有効)． SACK RFC:2018
tzt 2008/03/30
TCP
リンク
TCP/Tahoe、TCP/Reno、TCP/Vegas、TCP/SACKの４つの特徴がわかる日本語サイトを教えてください。…
TCP/Tahoe、TCP/Reno、TCP/Vegas、TCP/SACKの４つの特徴がわかる日本語サイトを教えてください。できたら比較してるサイトなら最良。
tzt 2008/03/29
TCP
リンク
WIDE University
[ English / Japanese ] SOI Asia Project
tzt 2008/03/28
TCP
リンク
untitled
tzt 2008/02/29
TCP over TCPの性能評価

TCP

カプセル化
リンク
untitled
tzt 2008/02/29
TCP over TCP の性能評価

TCP

カプセル化
リンク
なぜTCP Over TCPは悪いアイデアか
This document is a translation of `Why TCP Over TCP Is A Bad Idea', which was written by Olaf Titz. この文書は、Olaf Titz氏による `Why TCP Over TCP Is A Bad Idea'の翻訳です。 IPトンネリングアプリケーションにしばしば用いられるアイデアは、IPパケットを(モデムラインのような)ストリーム転送に適したフォーマットにカプセル化する、PPPのようなプロトコルをTCPベースの接続上で実行することです。これは、すでにいくつかの推奨 (Linux HOWTOや、私自身のウェブサイトや、もちろん他にもいくつか)がある、PPP over SSHの実行により、容易なソリューションとなるでしょう。それは、データグラムベースの圧縮が効率的な制約で困難となる一方
tzt 2008/02/29
TCP

カプセル化
リンク
1