対象OS：Windows XP／Windows Vista／Windows 7／Windows 8／Windows 8.1／Windows Server 2003／Windows Server 2008／Windows Server 2008 R2／Windows Server 2012／Windows Server 2012 R2 解説 ●IPアドレスとサブネットマスク、デフォルトゲートウェイ Windowsシステムに装着したネットワークインターフェースに対してTCP/IPの設定を行う場合、IPアドレスやサブネットマスクなどの他に、「デフォルト ゲートウェイ」情報も設定する必要がある。デフォルトゲートウェイとは、ネットワークパケットのデフォルトの宛先として指定するルーター（のIPアドレス）のことだ。スタンドアロンのLAN環境でない限り、必ず指定する必要があるだろう。 TCP/IPのプロパ
間違いだらけのWEBサーバ Keep-Alive - 新・浅く広くをモットーに - WEBプログラマ メモ
14:30 | Keep-Alive on / off に関する文献の多くが曖昧であることが気になっていたので、まとめてみました。Apacheのドキュメントから、Keep-Aliveの説明を拝借しますと、HTTP/1.0 の Keep-Alive 拡張と HTTP/1.1 の持続的接続の機能は、複数のリクエストが同じTCPの接続で送られる、長時間持続する HTTP セッションを提供します。つまり、Keep-Aliveは、『TCP 3ウェイハンドシェイクの節約』であるという点を理解しなければなりません。たいていの文献は『画像やCSSが多いサイトでは、接続を使い回すことにより無駄遣いをなくす』という説明をしていますが、この接続を使い回すという表現も曖昧な気がします。何となく分かった気になってしまう人も多いのではないでしょうか。それでは、まずは以下のようなhttpd.confで、Apacheの動
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform Windows 365 開発者
(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー
LinuxカーネルのTCPスタックとシステムコールの組み合わせによる手法よりも高速にポートのListenチェックを行う - 人間とウェブの未来
まずは前回の記事で盛大な誤認をしていたことを訂正しなければなりません。 hb.matsumoto-r.jp 前回の記事では、高速にリモートホストのポートチェックを3パケットで実現する実装を行うために、RAWソケットとユーザランドの簡易TCPスタックを実装してパケットを放出しましたが、カーネルのTCPスタックによって自動的にRSTパケットが返されるため、RSTパケットが返されるよりもはやくrecvfromしないとSYN+ACKを受け取れないと述べました。 しかし、以下のようにご指摘を頂き、 @matsumotory LinuxのSOCK_RAW+IPPROTO_TCPの場合、カーネルがRSTを送出したとしても同マシン上の既存raw socketに対するrecvfrom()が0を返すことはないと思うのですが、検証されているカーネルのバージョンはいくつでしょうか？— Hiroki Sato (@
お払い箱に、なりました。 | LAC WATCH
システムアセスメント部の山崎です。 長い間お世話になりました。 今までありがとうございました。m(_ _)m ・・・といっても、私本人が居なくなる話ではなく、私が作ったツールの１つがとうとうお払い箱になった！という話です。誰がこんな話を読んで喜ぶのかとも思いますが、書き始めてしまったので続けます。 この話のキッカケは、2ヶ月前、突然おそってきました。 後輩社員からの無慈悲なる一撃「お前はもう不要だ！」 後輩社員からの、山崎のツール「バナー取り君」は不安定なのでもう使いたくない！という告発です。動かないことがあったなら、その時に呼んでくれれば直せただろうに。私にとっては寝耳に水。コミュニケーション取れてない感がスゴい。そもそも壊れたらすぐ捨てるというあたり、最近の若いものは・・ぶつぶつ・・（←老害。だから言ってくれなくなるのだ） （注）Banapippi.pyは、ラックの独自診断ツールから「
もう半年くらいフルDockerでmicroservicesなサービスを運用してるんですが、イマイチパフォーマンスを出し切れていないなという面がありまして、今回DockerホストのTCPカーネルパラメータを抜本的に見直しました。 そしたら劇的に症状が改善して、インスタンス数も削減できた上に安定してメシウマ状態になったので紹介します。実際効果があったのでチューニングポイントとしてはある程度正解であったと考えていますが、もちろん扱ってるアプリケーションの特性にもよるはずなので一つのケーススタディであることをご了承頂ければと。 前提 まずは今回のお話の前提を。こんな環境です。 EC2 c3.xlarge ホストはUbuntu（EC2 Optimized AMIは未使用） Docker 1.11.2 MySQL（HAProxy経由）やRedisへのデータストアの通信、各microservicesへの
Post navigation ← Previous Home > Web関連 > 開発 > Linux > Linuxカーネルチューニングのメモ Linuxカーネルチューニングのメモ サーバー向けにLinuxカーネルのチューニングを行った際のメモです。 設定内容 今回行った /etc/sysctl.conf の設定内容は書きの通りです。 各パラメータの説明はコメントとして残しておきます。 # 共有メモリの最大サイズ。サーバーの搭載メモリ(1GB)に合わせて変更 kernel.shmmax = 1073741824 # システム全体の共有メモリ・ページの最大数 kernel.shmall = 262144 # システム全体のプロセス数の上限 kernel.threads-max = 1060863 # システム全体のファイルディスクリプタの上限 fs.file-max = 5242880
UNIX domain socket 通信は同一マシン上のプロセス間通信にしか使えないというデメリットがありますが，tcp 通信よりも圧倒的にパフォーマンスが良いので要求仕様的に使わなければならない局面は多いと思います 今回はフロントに Nginx で proxy して同一マシン上の別プロセスで動いているアプリケーションサーバーに対して UNIX domain socket 通信を行う構成で実際のアプリケーションサーバーに流れている通信を見たい時にどうするか書きます 実際にトラブルが起こった時に実際にどのような通信が流れているのかは tcp 通信なら tcpdump をすれば見れますが，UNIX domain socket 通信の場合は容易に見ることが出来ないので実際のアプリケーションサーバーにどのような通信が流れているのか分かりません しかしアプリケーションサーバーにどのような通信が流れ
QUICの標準化動向を日本語で解説。HTTP/2勉強会発表資料(2017/08/23) https://http2study.connpass.com/event/63998/
はじめに サーバーレス開発部@大阪の岩田です。 先日接続元IPアドレスをクラスメソッドのGIPに制限した検証環境を利用してAPIのテストを行なっていたところ、リモートワーク中のメンバーが検証環境に接続できないという状況が発生しました。 下記の記事で紹介されているように、クラスメソッドではSOCKSサーバーが構築されているので、VPN経由で社内NWに接続し、SOCKSサーバーをプロキシとして利用すれば本来リモート環境からでも検証環境が利用できるはずです。 VPN利用者のためにdelegateでSOCKSサーバーを立ててみました 最初はcurlコマンドのオプションに--proxyを付けてプロキシサーバーを指定するようお願いしたのですが、--proxy http://proxy.example.com:xxxxのような指定を行なっていたようで、問題が解決しませんでした。 結局--proxy so
LINEやcommの通話の仕組みを解析―実践編
前回、Android端末上でのパケット収集、Wiresharkを使ったパケット解析の方法について説明しました。今回はパケット解析の結果から、実際に「LINE」や「comm」の通信がどのようなやりとりをしているのかを調査していきます。なお、接続先サーバーのIPアドレスは実際には判明していますが、記事や図ではサーバーを「LINE01」などと表しています。また各図ではTCPセッションの確立/解放手順は省略しています。なお、今回はLTE回線上を流れるパケットをキャプチャした内容を解析していきます。 LINEの解析－ログイン時 最初にLINEのログイン時のシーケンスを見ていきましょう。図1のようなやりとりがされていました。
最近知ったんだけど、かなり便利くね？もしかして常識？ http://ngrep.sourceforge.net/ http://www.atmarkit.co.jp/fsecurity/rensai/securitytips/027ngrep.html installにはlibpcapがいる。 http://downloads.sourceforge.net/libpcap/ もしくはepelリポジトリからyumでinstallする。 # yum install -y --enablerepo=epel ngrep 追記 今更知ったけど、ASCIIで表示するだけならtcpdump -s0 -A だけで良いので(ngrep -W byline とほぼ同じ?)、grep 的なことしないならtcpdump で十分な気がする。 man tcpdump -A Print each packet (m
今回は、Golangのgolang.org/x/crypto/sshパッケージを使って、SSHサーバを構築してみました。 かなりミニマムな実装ですが、リモートからSSH接続して、対話的にコマンドが実行できるところまで実装しました。 コード github.com package main import ( "golang.org/x/crypto/ssh" "log" "net" "io/ioutil" "fmt" "os/exec" "github.com/kr/pty" "sync" "io" ) func main() { serverConfig := &ssh.ServerConfig{ NoClientAuth: true, } privateKeyBytes, err := ioutil.ReadFile("id_rsa") if err != nil { log.Fatal(
Video: http://joyent.com/blog/linux-performance-analysis-and-tools-brendan-gregg-s-talk-at-scale-11x ; This talk for SCaLE11x covers system performance analysis methodologies and the Linux tools to support them, so that you can get the most out of your systems and solve performance issues quickly. This includes a wide variety of tools, including basics like top(1), advanced tools like perf, and ne
恭喜，站点创建成功！
恭喜, 站点创建成功！ 这是默认index.html，本页面由系统自动生成 本页面在FTP根目录下的index.html 您可以修改、删除或覆盖本页面 FTP相关信息，请到“面板系统后台 > FTP” 查看
Eclipse Jetty provides a highly scalable and memory-efficient web server and servlet container, supporting many protocols such as HTTP/3,2,1 and WebSocket. Furthermore, the project offers integrations with many other technologies, such as OSGi, JMX, JNDI, JAAS, etc. These components are open source and are freely available for commercial use and distribution under both the EPL2 and Apache2 license
DNSメッセージといえばUDPの53番というイメージの方々も非常に多いと思いますが、1987年に発行されたRFC 1035の時点でDNSメッセージのトランスポートとして利用できるのはUDPとTCPであると記述されています。 しかし、これまでDNSにとってはUDPが基本でした(ゾーン転送を除く)。「RFC 1123: Requirements for Internet Hosts」には、以下のようにあります。 DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. Specifically, a DNS resolver or server that is sending a non-zone-transfer
検索 言語メニュー 言語を選択... English（English） Spanish（Español） French（Français） German（Deutsch） Italian（Italiano） Portuguese（Português） Russian（Русский） Japanese（日本語） Chinese（中文） 製品・サービス Quantum Quantum Maestro Quantum セキュリティ ゲートウェイ Quantum Spark Quantum Scalable Chassis Quantum Edge Quantum IoT Protect Quantum VPN Quantum Smart-1 Quantum Smart-1 Cloud CloudGuard GloudGuard Network CloudGuard ポスチャー管理 CloudG
ssコマンドのちょっといい所見てみたい。のでネットワーク統計情報がどの程度見られるか試してみた。 - 256bitの殺人メニュー
netstatさんが時代遅れだって！？ netstat使ってるのは小学生までだよねー。 キャハハｋ（ｒｙ 、、、というのは冗談ですが、これからはssコマンドらしいって聞いたので、どんな感じで使えるか使ってみた。 ssコマンド netstatの代替コマンドらしく、現在の通信状況の確認に使えるコマンドです。 メリットはsocketのrawでのsocketの扱いができる点かなと。 と、ipv6に強いところのようです。 でもあんまりipv6環境ってないですし、普段使いで代替になるかなーと思って見てみました。 基本的な使い方 netstatと似た感じっすよ。これ。 netstat # netstat -naot (snip) tcp 0 0 192.168.100111:50271 192.168.10131:27218 ESTABLISHED keepalive (215.43/0/0) tcp
どうやってIPからMACアドレスを解決するか - ARPの挙動を調べた - $shibayu36->blog;はデータリンク層、tracerouteの仕組みをtcpdumpとwiresharkで理解する - $shibayu36->blog;はネットワーク層について実践してみたので、続いてトランスポート層について実践してみたい。そこで今回はcurl http://www.example.com/したときのTCPパケットの様子を観察し、理解してみることにした。ネットワーク初心者であるので、正しいかは不明。また、概要をつかみたいだけなので、詳細はあまり立ち入らないことにする。 まずパケットキャプチャ。dig www.example.comすると、IPは93.184.216.34ということが分かるので、以下のコマンドでキャプチャしておく。 tcpdump -w dump.cap -n -i en
謎の伝送制御プロトコルRUDPの詳細について解説します これは2018年11月10日に行われた Kernel/VM/探検隊@北陸 part 4 での発表資料です サンプルコード: https://github.com/Fadis/rudp
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
このページは、TWSNMPマネージャの旧版(v4.x)のダウンロードのために残しているものです。 TWSNMPマネージャの旧版(v4.x)は�2021年時点でも 多くの人に利用されているようですがメンテナンスは2011年で終了しました。 そのまま利用されてもよいですが、 新しい技術を使ったコンテナ対応版の開発を2021年1月から開始しました。 2021年9月時点でv1.4.0を公開しています。 詳しくは、noteの記事をみてください。 最新版のダウンロードは、GITHUBから可能です。 Docker版は、Docker HUBにあります。 復刻版の開発を2019年9月から開始しましたが、現在は中止してコンテナ対応版に注力しています。 TWSNMPマネージャの旧版(v4.x)のメンテナンスが必要な方は、ソースコードを公開していますので、自力でお願いします。 ソースコードは、NET-SNMPと同
TCP serverをSSL/TLS化するのに nginx の stream_ssl_module/stream_proxy_module が便利 - たごもりすメモ
最近 Fluentd の通信プロトコルまわりをアップデートするためにあれこれいじっている*1んだけど、これはおおむね fluent-plugin-secure-forward がサポートしていた内容を Fluentd 組込みの forward plugin でもサポートしますよ、というものになる。 んで問題なのが secure-forward は SSL/TLS での接続のみしかサポートしてなかったんだけど forward では生の TCP で通信する*2ので、本当に secure-forward と forward それぞれの実装間で互換性が保たれているのか、直接的には確認する手段がない、ということになってしまう。 TCP server の SSL/TLS 化 一方世の中には SSL/TLS ターミネータという機能があって、たとえばロードバランサなんかがこの機能を持っている。何をやるかと
最近 ParallelServer というライブラリを作ったのですが、その最中に奇妙な状態になってる TCP ポートを見つけたので、メモっておきます。 Ruby では TCP サーバーは次のような感じで作ることができます。お手軽ですね。 require 'socket' Socket.tcp_server_loop(12345) do |socket, client_addr| socket.puts "Your IP address: #{client_addr.ip_address}" name = socket.gets socket.puts "Hello, #{name}" socket.close end これは 12345 ポートでクライアントからの接続を待ち、接続されたらクライアントのIPアドレスとクライアントからの入力をクライアントに送信して切断するだけの簡単なプログラム
オープンソースの高速Webサーバー「TUX」の実力
図5●プラットフォームの違いによる，コネクション確立の所要時間の差異<BR>TCPコネクションが確立するまでの時間を調べた。TUX 3.2はチューニング前後の数値にそれほど大きな違いはなく，比較的安定している。一方でApacheは標準設定時に扱えるプロセス/スレッド数が小さいため，Fedora Core 2.0とApache 2.0の組み合わせにおいてコネクション確立に要した最大時間が3009ミリ秒に達した。チューニングによって扱えるコネクション数を増やしたApacheでは，コネクション確立までの平均時間と最大時間が，いずれもTUX 3.2の性能をしのいでいる カーネル・モードで高速に動作するオープンソースのWebサーバー「TUX Web Server」（以下，TUX）の性能を，現在主流の「Apache」と比較した。静的コンテンツに大量のアクセスが集まる用途で，TUX 3.2はApache
This article was first published on Cloudflare blog: When TCP sockets refuse to die Accompanying scripts While working on our Spectrum server, we noticed something weird: the TCP sockets which we thought should have been closed were lingering around. We realized we don't really understand when TCP sockets are supposed to time out! In our code, we wanted to make sure we don't hold connections to de
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Windows OSのデフォルトゲートウェイは1つのみ有効
マイクロソフト - PressPass ホーム - 製品画像ダウンロード
カオステストでHTTP/2の問題を見つけ出す | POSTD
Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング
Linuxカーネルチューニングのメモ - 電子書籍と趣味の部屋
UNIXドメインソケット通信の内容を見たい - Qiita
QUIC標準化動向 〜2017/7
SOCKSプロキシとHTTPプロキシの違いについて勉強してみた | DevelopersIO
ngrepでパケットをキャプチャしてgrep (ngrepの使い方) - うまいぼうぶろぐ
Golangで軽量なSSHサーバを実装する - Fire Engine
Linux Performance Analysis and Tools
The Eclipse Jetty Project :: Eclipse Jetty
TCPだけでDNSサーバにqueryできるようになってた:Geekなぺーじ
CloudGuard Cloud Security | チェック・ポイント・ソフトウェア・テクノロジーズ
HTTP GETしたときのTCPパケットの様子を理解する - $shibayu36->blog;
詳解 Reliable UDP - Speaker Deck
TWSNMPマネージャ Twise Labo, Inc.
相手がいないのに ESTABLISHED になってる TCP ポート - tmtms のメモ
When TCP sockets refuse to die — Idea of the day
高負荷を捌くDBチューニングノウハウを公開！PHPとMySQLの TCP TIME-WAIT チューニング(後編) | さくらのナレッジ
