URGENT/11
UPDATE (December 15, 2020) 97% of URGENT/11 and 80% of CDPwn Vulnerable Devices Remain Unpatched Putting Thousands of Organizations at Risk of Attack Armis has continued to track the exposures from the URGENT/11 and CDPwn exploits discoveries over the past 18 months. Based on that research, we have identified that 97% of the OT devices impacted by URGENT/11 have not been patched; and 80% of those
TCP Fast Openの闇と、Kernelの緩和コミット - ASnoKaze blog
TCP Fast Open TCP Fast Openと呼ばれる技術があり、RFC 7413として標準化されている。 このTCP Fast Openを使うと、一度コネクションを貼った相手とは、TCPの3ウェイハンドシェイク中にデータを送受信できるようになる。クライアントからSYNとともにデータを送信することで、実際にデータを送受信開始するまでの待ち時間が短縮できる。 Linuxではすでにクライアント/サーバ両方でTCP Fast Openを使用できる。 TCP Fast Openの闇 しかし、数年前よりこのTCP Fast Openには一部のネットワークで奇妙な振る舞いをすることが知られている。Appleの人が実際にデプロイした時に見つけたもので、IETFやNANOGにて報告されており、その時の資料は下記のとおりである Deploying TCP Fast Open in the wild
NAT環境下では net.ipv4.tcp_timestamps = 0 する - かみぽわーる
NAT環境下に複数ホストがいてそいつらがクライアントのときに、WAN側のサーバに接続が切られるときは net.ipv4.tcp_timestamps = 0 すればいいというのを教えてもらいました！ 【緩募】SYN に SYN+ACK じゃないレスポンス受け取って RST しちゃう問題の解決方法 2011-04-01 19:06:11 via YoruFukurou @kamipo それポートが足りないとかネットワーク的に問題あるとかそういうなんじゃなくて？ 2011-04-01 19:09:18 via Echofon to @kamipo @kamipo 防火壁かなんかで弾いてません？ 2011-04-01 19:13:09 via TwitVim to @kamipo @mattn_jp iptablesでIPマスカレードしてるLinuxルータをgatewayにしてる環境なんですが、
tcp_tw_なんとかの違い - Qiita
自分用の覚書です。CentOS5とか6とかでの経験。 実際高負荷だとか負荷試験ツールで出ただとかのTIME_WAITを減らしたいというときに、 syctlで、tcp_なんとかを調整するというのは今ではよくあると思います。 （わたしはむかし運用していた某無料サイトで負荷に悩んだのが切欠で知りました。無料というだけで会員数激増的な風潮だったのと素行の悪い某国のクローラーとかrewriteのループとかの色々な芸の肥やし的な機会がというか夜中に起こされて眠りを妨げられたくなかったので色々調べたりしていました。） いっぱい接続したいの - (ひ)メモ Linux - ぜんぶTIME_WAITのせいだ！ - Qiita ・TCPの終了待ちタイムアウト秒数を設定（default60sec) net.ipv4.tcp_fin_timeout = 10 ソケットを強制的にクローズする前に、最後のFINパケッ
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013 Webをより速くしようと、HTTPよりも優れたプロトコルとして提案されたSPDY（スピーディ）。しかしそのSPDYによって、下位レイヤであるTCPの制限が顕著に見えるようになってしまい、そのことでTCP以外のプロトコルとしてQUICをGoogleが提案しています。 Webの進化は、インターネットのプロトコルにまで影響を与えようとしている、という非常に興味深い話が、HTML5のコミュニティ「html5j」主催のイベント「HTML Conference 2013」で行われた小松健作氏のセッション「最新Webプロトコル、傾向と対策」で行われました。 その内容をダイジェストで紹介しましょう。 最新Webプロトコル、傾向と対策 小松です。所属はNTTコミュニケーションズでHTML5の研究
ISP は深刻な性能問題を隠してきた? | スラド
ちょっと軽い感じで解説してみる。間違えてたら訂正よろしく。 Internet (パケットネットワーク)の仕組としてバースト時のパケットロスをなくすためにキューにバッファリングする仕組みがある。バンド幅の向上に合わせてこのキューもどんどん大きくなって来ているが、単にそれだけではなく、パケットロスは少なければ少ないほど良いと勘違いしたものか、大は小を兼ると思い込んだのか無闇やたらバッファーがでかくなる症状が流行っている。 ところがキューを大きくすると確かにパケットロスは減るが、大きくすればするほどパケットの遅延が酷いことになる。パケット遅延は別にリアルタイムゲーム等でのみで必要な要素ではなく、混雑時のデータ転送速度に大きな影響を与える。単に帯域幅が広いだけじゃ駄目なのである。 特にTCP通信においては致命的。TCP通信には輻輳回避機構があってパケットロスを検知して、最適な通信速度を探す仕組みが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluentdでログが欠損する可能性を考える : sonots:blog