ソケット通信 possible SYN flooding on port 443. Sending cookies. がログに出てきた - Qiita
ソケット通信 possible SYN flooding on port 443. Sending cookies. がログに出てきたLinux はじめに インターネットに公開しているホームページが突然閲覧できなくなりました。サーバではロードアベレージも低く、負荷はかかっていないようでした。今回の記事ではこの状況下でのボトルネックの確認＆対応方法について簡単にまとめてみました。 環境 CentOS6 Apache 参考 https://qastack.jp/server/294209/possible-syn-flooding-in-log-despite-low-number-of-syn-recv-connections https://github.com/hiboma/hiboma/blob/master/kernel/net/net-backlog.md https://qiit
TCP における確認応答と再送制御 -- Key：雑学事典
TCP の透過性 最終更新2004-12-26T00:00:00+09:00 この記事のURI参照https://www.7key.jp/nw/tcpip/tcp/tcp2.html#transp TCPのトランスポート層としての役割として大切なのは通信の信頼性を確保することです。今回はコネクションの中で、その信頼性を確保するためのかなめとなる部分について説明を行います。このかなめとなる機能は大きく分けて確認応答と再送制御の二つから成り立ちます。確認応答は「データをここまで受け取りましたよ」とあいづちをうつ機能のことを言い、再送制御は相手にデータが届かなかったことを検知し、速やかに届かなかったデータを相手に再送する機能のことを言います。これらの機能により、ローカルのアプリケーション通しが通信しているのと変わらない環境をネットワーク経由でも実現することができるのです。こうしたコネクションの性
TCPとタイムアウトと私 - Cybozu Inside Out | サイボウズエンジニアのブログ
本部長や副本部長もプログラミングを（たまに）することで有名なサイボウズの運用本部長、山本泰宇です。 有名じゃないかもしれませんが、ブログに書いたので有名になるということでご了承ください。 今回は、先日発生した yrmcds に起因する障害の原因と対策を解説します。 yrmcds というのは、サイボウズが開発している memcached 互換のキーバリューストレージです。 問題の理解のため、まず TCP 通信で、通信先の相手の障害にどう対応するか解説します。 データの送信中に相手が落ちるケース このケースはさらに二つに分かれます。 相手の OS は生きているが、通信しているプログラムが落ちるケース 相手の OS ごと（あるいはネットワークごと）落ちるケース 1 と 2 の違いは、前者の場合 RST パケットが返ってくるのに対して、後者ではなにも返ってこない点です。後者の場合、ack されない
Geekなぺーじ : TCP vs RTP：何故RTPが必要なのか？
インターネットを流れるトラフィックのほとんどがTCP(Trasmission Control Protocol)によるものです。 TCPは、全てのデータが正しく相手に伝わることを保証するため品質の高いデータ通信が実現できます。 また、どのパケットが受け取れなくて、どれが受け取れたかなどをわざわざ考えなくても良いので、プログラムを書くのも簡単です。 では、何故、わざわざRTPというものが必要だったのでしょうか？ ここでは、まず最初に何故RTPはTCPではなく、UDPの上に存在しているのかを説明したいと思います。 （もちろん、TCPの上に作ることはRTPの規約上は可能ですが、現実的にはUDPの上でしか実装がないと思います。） その後、何故、UDPの上に共通のRTPというものを構築したのかを説明したいと思います。 RTPは、名前にもある通り、「リアルタイム」なデータを転送するためのプロトコルです
Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング
もう半年くらいフルDockerでmicroservicesなサービスを運用してるんですが、イマイチパフォーマンスを出し切れていないなという面がありまして、今回DockerホストのTCPカーネルパラメータを抜本的に見直しました。 そしたら劇的に症状が改善して、インスタンス数も削減できた上に安定してメシウマ状態になったので紹介します。実際効果があったのでチューニングポイントとしてはある程度正解であったと考えていますが、もちろん扱ってるアプリケーションの特性にもよるはずなので一つのケーススタディであることをご了承頂ければと。 前提 まずは今回のお話の前提を。こんな環境です。 EC2 c3.xlarge ホストはUbuntu（EC2 Optimized AMIは未使用） Docker 1.11.2 MySQL（HAProxy経由）やRedisへのデータストアの通信、各microservicesへの
[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority
前回の続き。 パケット自体を零さずに処理に入った後にSYNを落とすのは以下3パターン。 syncookie無効時にsynのbacklog(tcp_max_syn_backlog)が溢れている listenのbacklogが溢れている(3way-handshake完了後のaccept待ち接続) net.ipv4.tcp_tw_recycleの制限に抵触 で、今回問題になっていたのは最後のtcp_tw_recycleへの抵触だった。 現象として発生しうるのは、以下の条件をすべて満たす場合 サーバ側でnet.ipv4.tcp_tw_recycleが有効 TCPタイムスタンプオプションを使用 同一IPからの接続でセッションを跨ぐとセットされるTCPタイムスタンプの値が戻る場合がある 最後の条件が微妙だが、TCPタイムスタンプの値としてセットされる値は起動時を 起算時にしていたりと実装によって初期値
![[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority](https://cdn-ak-scissors.b.st-hatena.com/image/square/264702d4cb37ced3c2fd5dda6a1368c235356862/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127119925553%2F17680117127119930188%2F1557218483)
GoでたたくTCPソケット（前編）
このうち、アプリケーションを作るために気にする必要があるのはトランスポート層よりも上のレイヤーだけです。 実際のインターネット通信では、ケーブルや無線を通してIPパケットの形でデータがやり取りされますが、 アプリケーションで直接IPパケットを作ったりするわけではありません。 HTTPやTCPのレベルで決められているルールに従って通信をすれば、それより下のレイヤーで必要になる詳細を気にすることなく、 ネットワークの向こう側にあるアプリケーションとやり取りができるわけです。 Go言語では、HTTP、TCP、UDPについて組み込みの機能が提供されています1。 実用的なアプリケーションでは、それらの機能を使って、自分のアプリケーションに必要なプロトコルを実装していくことになります。 HTTPとその上のプロトコルたち 今回の記事の目標は、ネットワークを扱うプログラムにとって低レベルなソケットをGo言
GoogleのQUICプロトコル：TCPからUDPへWebを移行する | POSTD
QUIC（Quick UDP Internet Connections）プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 （冗談で） TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastのcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの本当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ （ネットワークパケットの往復） が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 （出典： UDPを介
Linux の TCP/IP チューニング・パラメータ
TCP のチューニング・パラメータ 接続確立関係のチューニング・パラメータ TCP のチューニング・パラメータ TCP のチューニング・パラメータは、以下のコマンドで取得できます。 なお、以下は Linux のものです。 >cat /proc/sys/net/ipv4/tcp_retrans_collapse 1 >cat /proc/sys/net/ipv4/tcp_keepalive_probes 9 >cat /proc/sys/net/ipv4/tcp_keepalive_time 10800 >cat /proc/sys/net/ipv4/tcp_syn_retries 10 >cat /proc/sys/net/ipv4/tcp_sack 1 >cat /proc/sys/net/ipv4/tcp_timestamps 1 >cat /proc/sys/net/ipv4/tcp
＠IT：/procによるLinuxチューニング ［後編］（2/4）
/procによるLinuxチューニング ［後編］ ～ /proc/sysの主要パラメータ群総解説 ～ 遠田 耕平 2002/12/17 /proc/sys/fsディレクトリ /proc/sys/fsには、ファイルシステム関連のチューニングパラメータが集められています。 file-max システム中のオープンファイル管理データの最大数を指定できます。 file-nr file-nr内のパラメータはそれぞれ、オープンされているファイル数、空きファイル管理データの数、システム中のオープンファイル管理データの最大数（file-maxと同じ）を示します。 ファイルのクローズ時には、使っていたファイル管理データを即座に解放するのではなく、いったん（次の機会に使えるように）取り置きます。この取り置かれている管理データの数が、2番目の数値となります。 inode-state、inode-nr inode-
バックログの指定 - 揮発性のメモ２
listenのバックログが指定できない - 揮発性のメモの続き http://www.linux.or.jp/JM/html/LDP_man-pages/man2/listen.2.html int listen(int sockfd, int backlog); backlogでバックログの数＝accept()待ちの接続のキューの数を指定できる。 ということになっているけど、実際はキューの数をあまり制限できないっぽい。 カーネル側の設定を # cat /proc/sys/net/ipv4/tcp_syncookies 0 # cat /proc/sys/net/ipv4/tcp_max_syn_backlog 1プログラム側を result = listen( sd, 1 );として制限かけていても、実際にはセッションが確立してしまう。 tcp 0 0 172.16.1.4:5000 1
Webクライアントからの接続数とリクエスト処理スレッド数の制御
ここでは，Webクライアントからの接続数の制御と，リクエスト処理スレッド数の制御について説明します。 インプロセスHTTPサーバでは，一度に接続できるWebクライアントの数を設定することで，インプロセスHTTPサーバで作成するリクエスト処理スレッド数を制御できます。また，処理を実行していないリクエスト処理スレッドを予備スレッドとして一定数プールしておくことで，リクエスト処理スレッドの追加・削除に掛かる処理を最小限に抑えられます。 このように，Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。 Webクライアントからの接続数の制御とリクエスト処理スレッド数の制御について説明します。 ＜この項の構成＞ (1) Webクライアントからの接続数の制御 (2)
何か決めなきゃ駄目ですか。 Linuxのbacklogについて
少しだけ突っ込んだ話。 （曖昧さは人間の脳内補完に委ねるとして･･･。） LinuxにはTCPの3Wayハンドシェイク（即ち、SYN,SYN/SCK,ACK）状態保持に関連して、 次のようなパラメータを持っている。 net.ipv4.tcp_max_syn_backlog=1024 何それ？って人は # sysctl -a | grep tcp 等のコマンドで探します。 # sysctl -a | grep backlog？それじゃノイズが無さすぎて面白くｎ(ry これは、「LinuxがSYNを受信し、SYN/ACKで応答した状態をいくつ保持するか」というもの。 閾値を超えると、Linuxは新規に接続しようとするホストのリクエスト（SYN）を無視する。 最近のLinuxを、最近のハードウェアにとりあえずインストールすると、 初期値は上記のような1024とか言う数値になっていると思う。 利用
A.53 ListenBacklog
Interstage Application Server Webサーバ運用ガイド (Interstage HTTP Server編) 名前 ListenBacklog 形式 ListenBacklog 接続待ちキューの最大数 ListenBacklog 接続待ちキューの加算数 機能概要 接続待ちキューの最大数を設定します。最大数には、1から2147483647までを指定できます。 本ディレクティブの設定値は、MaxClientsディレクティブで設定したクライアントの同時接続数よりも多くのアクセス要求があった場合に、Solaris OEシステム内にキューイングされる数として有効となります。 ただし、本ディレクティブの設定値がSolaris OEシステムに設定されている待機中TCPコネクションの最大値（tcp_conn_req_max_q）よりも大きい場合は、待機中TCPコネクションの最大値
kernelチューニング
linuxサーバのOS全体に効くカーネルパラメータのチューニング箇所と その設定値、またその理由をまとめておく。 あくまで自分の環境ではこうした、というだけであり、 提供するサービスごとに検討が必要である。 どこをどう変更するのか、または変えないのか、その判断材料にはなるだろう。 ※ユーザ単位でシステムリソースに制限をかける場合をこちらを参照してほしい。 以下は/etc/sysctl.conf で設定するものとする。 ● 大規模サイト用チューニング kernel.pid_max 動作：pidの最大数 設定値：131072 理由：pidを枯渇させない vm.max_map_count 動作：mmapやmalloc時にメモリを仮想空間にマッピングできる最大ページ数 設定値：300000 理由：マッピングできなくなる事態を防ぐ net.core.somaxconn 動作：接続(ソケット)キューの
LinuxのTCP/IPの実装について調べてみた - nyantのブログ
結論 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]
net.core.somaxconnについて調べてみた - 祈れ、そして働け ～ Ora et labora
概要 ↓ memcachedのtcp_backlogのデフォルト値は1024で、stats settingsにも1024と表示されているのですが、 stats settings ... STAT tcp_backlog 1024 ... END↓ net.core.somaxconnがデフォルト値のままだと128に切り詰められてしまい、 # cat /proc/sys/net/core/somaxconn 128負荷が高いサーバーでは接続要求を取りこぼしてしまうことがあるそうです。 このnet.core.somaxconn、MemcacheやMySQLなど、高負荷時に多くの接続要求を受け付けるサーバーではチューニングが必要なカーネルパラメータのようです。いったいどういう値なのか、調べてみました。 net.core.somaxconnとは TCPソケットはlisten()関数の第二引数 ba
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC 9293: Transmission Control Protocol (TCP)
【図解】MTUとMSS, パケット分割の考え方 ~IPフラグメンテーションとTCPセグメンテーション~
CloudFrontをかますとキャッシュなしのAPIコールでも速くなるようだ : sonots:blog
