結論 tcp_syncookies = 0 の場合 tcp_max_syn_backlog の 75% を超える half openなコネクション要求が来た場合、dropされる(TCP: drop open request from [IP]/[PORT]) somaxconn と tcp_max_syn_backlogの小さいほうの値を、付近の2の累乗の値に切り上げた数値を超えると、drop (TCP: Possible SYN flooding on port [PORT]. Dropping request.) tcp_syncookies = 1 の場合 somaxconn と tcp_max_syn_backlogの小さいほうの値を、付近の2の累乗の値に切り上げた数値を超えると、cookie送信 (TCP: Possible SYN flooding on port [PORT]
WEBコンテンツ配信にLinuxを使うのは一般的になりましたが、CentOSやUbuntuをはじめ、大抵のディストリビューションが低スペックなマシンでも動くような初期設定になっています。 トラフィックの上限でもない CPUリソースの枯渇でもない HDDのIOが遅い問題でもない コンテンツが重くなる(接続できない) というケースで、見落としがちなLinuxのネットワーク周りのチューニングについてです。 iptables関連 iptablesを使用している場合、下記のパラメータを注意して下さい。 /proc/sys/net/ipv4/ip_conntrack_max ip_conntrackに記録できる最大値です。65536あたりが初期設定になっているかと思います。これだとパケットの取りこぼしがすぐに起きてしまいます。1コネクションあたり約350バイト消費するので、実装されているメモリに応じて
tcp(7) - Linux man page Name tcp - TCP protocol Synopsis #include <sys/socket.h> #include <netinet/in.h> #include <netinet/tcp.h> tcp_socket = socket(AF_INET, SOCK_STREAM, 0); Description This is an implementation of the TCP protocol defined in RFC 793, RFC 1122 and RFC 2001 with the NewReno and SACK extensions. It provides a reliable, stream-oriented, full-duplex connection between two sockets on
tcpdumpやwiresharkでARPのオペレーションや、ICMPのタイプとコードを指定してパケットを収集する方法を忘れることが多いのでメモ。 ARP(RARP) ARP Request "arp[6:2]=0x0001" ARP Reply "arp[6:2]=0x0002" RARP Request "arp[6:2]=0x0003" RARP Reply "arp[6:2]=0x0004" Address Resolution Protocol (ARP) Parameters(www.iana.org) ICMP Echo Request (Type:8,Code:0) "icmp[0:2]=0x0800" Echo Reply (Type:0,Code:0) "icmp[0:2]=0x0000" Time to Live exceeded in Transit (Type:1
tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法を忘れることが多いのでメモ。 SYNフラグが設定されたパケットの収集 "tcp[13] & 2 != 0" SYNフラグが設定されていないパケットの収集 "tcp[13] & 2 == 0" SYNフラグのみ設定されたパケットの収集 "tcp[13] & 255 == 2" ACKフラグが設定されたパケットの収集 "tcp[13] & 16 != 0" ACKフラグが設定されていないパケットの収集 "tcp[13] & 16 == 0" ACKフラグのみ設定されたパケットの収集 "tcp[13] & 255 == 16" ACKフラグとSYNフラグが設定されたパケットの収集 "tcp[13] & 18 == 18" ACKフラグとSYNフラグのみ設定されたパケットの収集 "tcp[13] & 255 ==
第14回 信頼性のある通信を実現するTCPプロトコル(その1):基礎から学ぶWindowsネットワーク(3/3 ページ) 前ページでは、TCPにおけるウィンドウ制御の基本的な概念について解説した。そこでは何パケットかまとめてTCPデータを送信し、まとめてACKを返すことにより、効率よく(帯域幅ほぼいっぱいまで)回線を利用することができる例を示した。 だが実際のTCPにおけるウィドウ制御では、ウィンドウ・サイズはパケット数ではなく(何パケットまとめて送信できるかではなく)、バイト数で数えることになっている。パケットのサイズは実際の物理的なネットワーク媒体によって異なるが、IP層によってそれらは仮想化されているので、パケットの数で扱うことはできないし、その必要もない。以下では、物理的なパケットの構造から離れて、バイト・データに基づいたウィンドウ制御の詳細について解説する。 シーケンス番号 TC
TCPヘッダの構造 TCPでは信頼性の高い通信を実現するために、受信確認やスライディング・ウィンドウ制御、そしてさまざまな付加機能などを用意している。そのためUDPよりも複雑なヘッダ情報を持っている。「チェックサム」はIPヘッダなどと同様に、1の補数で計算する。 連載第7回「データグラム通信を実現するUDPプロトコル―2.UDPパケットの構造」で示したUDPパケットの構造と比べると、非常に複雑になっている。UDPでは、通信に先立ってコネクションを確立する必要のないデータグラム型通信モデルを使用しているため、送信される各UDPパケットは完全に独立していた。そのため、UDPパケットごとにあて先のポート番号(送信元を区別するための送信元ポート番号)さえあれば、相手にパケットを届けることができる。 だがTCPでは、通信に先立ってコネクションを開設し、さらに通信中にも、前回解説したシーケンス番号に基
》 間もなく始まる“オプトイン規制”、改正迷惑メール法が12月に施行 IAjapan迷惑メール対策委員長の木村孝氏に聞く (Internet Watch, 10/29) 》 著作権保護期間とフェアユースについて討論、think Cシンポジウム (Internet Watch, 10/31) 東京大学名誉教授の中山信弘氏は、「提言は非常に結構なものだと思う。提言の中では、保護期間の延長については、少なくとも今年度はないと思われる。フェアユースについては、ぜひ次の通常国会で立法化してほしいと強く言ってきたが、それは難しいかなという感じになっている。少しがっかりしているが、仮に次の通常国会がダメでも、その次の通常国会がある。めげずに頑張っていきたい」とコメントした。 (中略) フェアユースについては、中山氏が「現在ネット関連の新しいビジネスを行おうと思えば、多くは著作権侵害にぶつかってしまう。ネ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、1セッション1スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを1スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く