NICからの割り込みを適切なCPUに振り分けるための、IPヘッダオプション - ASnoKaze blog
NICからの割り込みを適切なCPUに振り分けられるようなHintをIPヘッダオプションとして定義する「Multiple Core Performance Hint Option」という提案が提出されています。（特許としても申請中とのこと） ざっくり眺めて見ようかと思います。ここらへん詳しいわけではないので、間違いがあればご指摘ください。 背景 10Gbpsなどのトラフィックを処理する場合、NICからの割り込みを一つのCPUコアで処理しきれないことがあります。 NICからの割り込みを複数のCPUコアで分散する仕組みとして、Linuxでは「Receive Side Scaling (RSS)」、「Receive Packet Steering (RPS)」、「Receive Flow Steering (RFS)」などの仕組みがあります。 このとき、同じ通信フローの処理は同じコアで処理するのが
会社のテックブログに記事を書きました: ペパボ トラブルシュート伝 - TCP: out of memory -- consider tuning tcp_mem の dmesg から辿る 詳解 Linux net.ipv4.tcp_mem - hibomaの日記
以下の記事です。 tech.pepabo.com TCP our of memory memory pressure モード net.ipv4.tcp_mem 以上の三つの詳細を扱ったエントリです。TCP で大規模なトラフィックを扱っているサーバを扱われている場合、問題がないかどうかを確かめてみるとよいかと思います。 本文長いです。何に気をつけたらいいんでしょう? プラクティカルな話だけをまとめると、以下の4行です。 memory pressure モードに入ってしまうと warning です TCP out of memory が出てしまうと critical です 監視は /proc/ 以下のファイルを見ましょう チューニングは net.ipv4.tcp_mem で行いましょう LVS はどうなの? LVS でロードバランシングしている場合は、TCP スタックを通らないため TCP o
TCP Proxyを書いてMySQLの通信を覗いてみる - Copy/Cut/Paste/Hatena
お、MySQLの通信も見えそうだぞ？ pic.twitter.com/GVxBXqHEgA— k1LoW (@k1LoW) 2018年7月25日 "TCP Proxyを書いてPostgreSQLの通信を覗いてみる - Copy/Cut/Paste/Hatena" の続編です。 MySQLの通信を覗いてみる また簡単なクエリだけを対象にします（プリペアードステートメントなどは含みません）。 MySQLもしっかりとしたドキュメントがありクエリのプロトコルの説明もありました。 MySQL :: MySQL Internals Manual :: 14.6.4 COM_QUERY しかし、とみたまさひろさん の資料のほうが断然わかりやすかったです。 slide.rabbit-shocker.org というわけで今回も tcprxy に実装を追加していきます。 mysqlコマンドでクエリを実行してみ
TCP Proxyを書いてPostgreSQLの通信を覗いてみる - Copy/Cut/Paste/Hatena
なんとなく興味がでてきたのでインターネット情報を参考にTCP Proxyを書いてPostgreSQLの通信覗いてみた。クエリの取得まではできた。 HTTP/1.1の世界で生きていたので、プログラムでバイナリ？を触ったの久しぶり過ぎるし（TokyoTyrantのPHPクライアント書いたときぶり？）やっぱり全然慣れない— k1LoW (@k1LoW) 2018年7月15日 覗いてみました。 ただ見るだけなら tcpdump などを活用すれば良さそうなのですが、せっかくならプロトコルを解析した結果を出力してみたかったので、取得結果をイジれるようにTCP Proxyを書くところからはじめてみました。 TCP Proxyってどうやって書けば？というのは基本的にインターネットの情報を参考にしました。特に以下のツールのコードを参考にしました。 github.com で、書いたのが tcprxy です。
GitHub - Eplox/TCP-Starvation
Update: From comments throughout different communities, I've seen links to different articles describing the same issue as I do here. I understand this vulnerability that has existed for quite some time already (10y+), and by no means trying to take credit for them. Perhaps I used wrong search terms when looking for related articles, or just that they was located at page 42 on google. Either way,
#OCJP-135: SSH TCP ポートフォワーディング経由でのSMTP(とHTTP)ハッキング事件について
昨日、「MalwareMustDie」のブログで昨年10月からの SSH での TCP フォワーディングを使うハッキングの仕組みを 報告しました。 SSHでのTCPポートフォワーディングとは日本語では「SSHでのポートフォワーディング」ですね。ようは、確立している SSH 接続をトンネルとして利用し、任意の通信をトンネルを経由させて転送することで、転送先ネットワークやサーバとは、透過的な通信が可能となります。 報告内容の中にSSHでのポートフォワーディングの上でSMTP経由のハッキングの動きがあり、回数も多く、2016年10月24日から2017年2月27日の段階では 8,000件以上 の SMTP 不正なアクセスの動きを発見しました。 スクリーンショットは下記となります↓ ↑その中に74件は国内のメールサーバのＩＰを発見致しました。 報告しましたSSHでのポートフォワーディング経由SMTP
tcpdumpの使い方 - Qiita
最新版は、以下に記載しています。 tcpdumpの使い方（基本編） tcpdumpの使い方（パケットファイルの切り替え方法） tcpdumpのフックポイント、Netfilterのチェイン、Qdiscのカーネル内の場所 tsharkコマンドの使い方 mergecapコマンドの使い方 iptablesについても理解しておくとtcpdumpコマンドの実験に役立ちます。 iptablesコマンドの使い方 iptables-extensionsの使い方 iptablesコマンドの使い方（ターゲットの使い方） firewall-cmdの使い方 Wiresharkの使い方（RTTの表示方法） Wiresharkの使い方(IPアドレスやMACアドレスを名前で表示する方法) ネットワークのトラブルシューティングのときに使うコマンド #1 tcpdumpとは? ネットワークを流れるパケットをキャプチャするため
【3分で把握】ポート番号とは？と代表的なポート番号まとめ
ポートとは、ネットワークでデータを通信するための扉のようなものだと思うとわかりやすいだろう。ポート番号はその扉の番号だ。 それぞれプログラムの種類によって、使うポート（扉）が違う。例えば、メールを送るにはこの扉、メールを受け取るにはこの扉、Webページを見てもらうのはこの扉、などと決まっているわけだ。 このページではポートとポート番号について初心者向けにわかりやすくご紹介しよう。 そもそもポートとは？ 実際TCPやUDPで通信を行うときは、コンピュータ一台という単位ではなく「プログラム単位」つまり「プロセスやスレッド単位」で通信が行われる。そのためプロセス同士、正しく受け渡しをする必要がある。 このとき通信しているプロセスには「ポート番号」というものが割り振られる。プロセスやスレッドはこのポート番号を目印にして、どのアプリケーションとどのアプリケーションが通信をとっているのかを判別すること
New – HTTP/2 Support for Amazon CloudFront | Amazon Web Services
AWS News Blog New – HTTP/2 Support for Amazon CloudFront When I interview a candidate for a technical position, I often ask them to explain what happens when they see a interesting link and decide to click on it. I encourage them to go in to as much detail as they would like. The answers let me know how well they understand and can explain a complex concept. Some candidates will sum up the entire
nginxによるTCPロードバランサー | メルカリエンジニアリング
SREチームの@cubicdaiyaです。今回はnginxによるTCPレイヤーでのロードバランスについて解説します。 ロードバランサーとしてのnginx nginxはHTTPやTCP、UDP等の複数のレイヤーでロードバランサーとして稼働させることができます。（TCPロードバランサーは1.9.0以降、UDPロードバランサーは1.9.13以降で利用可能です） また、ngx_http_ssl_module や ngx_stream_ssl_module を利用することでそれぞれのレイヤーでTLSを有効化することも可能です。 TCPロードバランサー用のモジュールを有効にする HTTPレイヤーでロードバランスするためのモジュールはデフォルトで組み込まれますが、TCP(とUDP)レイヤーでロードバランスするにはnginxのconfigureスクリプトに--with-stream(あるいは --with
512バイトを超える DNSパケット | harasou.github.io
glibc の脆弱性 CVE-2015-7547 でも話題になった 512バイトを超える DNS パケットについてのメモ。 DNS では、TCP が使われたり、512 バイト超えるデータが扱われることは知っていたが、詳しい仕組みなど知らなかったので、備忘録のためにまとめておく。 そもそもなぜ 512 バイト？ 調べてみると、 インターネットで使われている IP(IPv4)の仕様では 一度に受信可能なデータグラム(ヘッダーを含むパケッ ト)として、 576 バイトを保証しなければならないと定められています。この値は、64バイトのヘッダーと 512バイトの データブロックを格納可能な大きさとして選択されたものです refs: https://jprs.jp/related-info/guide/008.pdf とのこと。 インターネットで使われている IP の仕様では、かならず「1パケットで
wrkでunix domain socketなHTTPサーバをベンチマーク - blog.nomadscafe.jp
wrkに無理矢理なpatchをあてて、unix domain socket経由でHTTPサーバをベンチマークできるようにしてみました。 kazeburo/wrk at unixdomain pullreqはしてない。 GazelleやRhebokといったアプリケーションサーバを作っていますが、TCP経由のベンチマークではEphemeral Portの枯渇やTIME WAITの上限にあたってしまい、ベンチマークがしづらいという問題があります。 そこでnginxをreverse proxyとして設置し、nginxとアプリケーションサーバ間をunix domain socketで繋いでベンチマークをとっていましたが、nginxがボトルネックになりやすく、直接アクセスしたいなと考えていたので、やってみました。 これを使ってRhebokとUnicornの “Hello World” ベンチマークを行
tinyssh
Introduction TinySSH is a minimalistic SSH server which implements only a subset of SSHv2 features. Twitter: @tinyssh Github: https://github.com/janmojzis/tinyssh Features easy auditable - TinySSH has less than 100000 words of code no dynamic memory allocation - TinySSH has all memory statically allocated (less than 1MB) simple configuration - TinySSH can’t be misconfigured reusing code - TinySSH
Apacheでマトリョーシカを作ってみる - ろば電子が詰まつてゐる
以前から、「Apache1000本ノック」という単語だけ頭に明滅していたのですが、時間が取れたのでそれに近いものを作ってみました。 が、実際にやってみるとノックというよりはマトリョーシカに近いな……と思ったので、ここでは「Apacheマトリョーシカ」として紹介します。あるいはドミノ倒しというイメージも近いかもしれません。 なお、本稿の実用性はゼロです。お遊びです。 環境の概要 環境 VirtualBox 4.3.10 OS CentOS 6.5(64bit) Apache Ver. 2.2.27 Apacheマトリョーシカとは何か コンセプトとしては、Apacheのproxy_httpを使ってポートフォワードを多段接続してみよう! ということです。 イメージはこんな感じ。 WebブラウザでHigh Portに接続すると、そこから内部でひたすらポートフォワードしまくって、一番奥底にある80/
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
セッション監視に特化した軽量ネットワークモニター「TCP Monitor Plus (Type-S)」NOT SUPPORTED