並び順

ブックマーク数

期間指定

  • から
  • まで

361 - 400 件 / 1912件

新着順 人気順

tcpの検索結果361 - 400 件 / 1912件

  • クラウドネイティブなハニーポットをAWS上に作ってみた話 - ある研究者の手記

    TL;DR AWSのマネージドサービスを活用して低インタラクション型のハニーポット環境を作った コストも月々約$15で運用可能 コマンド3回ぐらいで誰でもデプロイできるようになっているので興味があれば使ってみてくれよな 背景 AWSに置く低インタラクション型ハニーポット(synに対してsynackだけ返して後は送られてくる通信を監視するやつ)、今ならシャキッとスパッと実装できるんだろうなあああと過去のクソ実装を思い出して悶絶してる— Masayoshi MIZUTANI (@m_mizutani) 2019年2月1日 という感じで昔クラウド上で運用していたハニーポットのことをふと思い出したのですが、仕事で多少AWSのサービスを理解した今だったらもうちょっとまともに実装できそうだよなぁ、実装するならインスタンスで完結するんじゃなくてクラウドのマネージドサービスちゃんと使って消耗しない作りにし

      クラウドネイティブなハニーポットをAWS上に作ってみた話 - ある研究者の手記
    • HAProxy で graceful restart する方法 - 酒日記 はてな支店

      haproxy には起動後に設定ファイルを読み込み直したりする機能がないので、バランス先を追加するなどの変更が無停止ではできない、と思い込んでいたのだけど実は違った、というお話。 実際、同一プロセスで読み込み直すことはできないのだけども、以下のような手法で graceful に再起動することができる。man はちゃんと読みましょう。 # haproxy -f /path/to/haproxy.conf -sf [既に動いているhaproxyのpid]として -sf オプションに pid を渡して起動すると…… haproxy[2] : 起動 haproxy[2] : 既に動いている haproxy[1] に SIGTTOU を送信 haproxy[1] : SIGTTOU を受けると Listen をやめる 新規接続は受け付けない 既に確立している接続はそのまま維持 haproxy[2]

        HAProxy で graceful restart する方法 - 酒日記 はてな支店
      • 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パケットで

          512バイトを超える DNSパケット | harasou.github.io
        • tcpflow: httpレスポンスボディをリアルタイムで見たいとき | Ore no homepage

          tcpdumpの表示では見にくいし、pcapをいちいちwiresharkに食わせてfollow tcp streamするのは面倒。そんなときに使えるツール。 (1) tcpflow tcpflow(最新はgithubかな) http://www.circlemud.org/jelson/software/tcpflow/ https://github.com/simsong/tcpflow (2) インストール 自分のメモをペッと貼付けただけなので、バージョンやダウンロード先は適当に読みかえてください。 yum install libpcap-devel wget http://www.circlemud.org/pub/jelson/tcpflow/tcpflow-0.21.tar.gz tar xvfz tcpflow-0.21.tar.gz cd tcpflow-0.21 ./con

          • Multipath TCPについて

            Multipath TCPとは、複数の経路を扱うためのTCP拡張である。実は、以前、本の虫: MultiPath TCPのLinuxカーネル実装という記事で、その実装デモを紹介している。 従来のTCPは、IPとの分離ができない。TCPヘッダーの中には、ひとつのIPアドレスとポートがある。経路ごとにIPアドレスが割り振られるので、経路を変えるには、別のTCPコネクションを貼り直さなければならない。 しかし、複数の通信経路を持つという環境は、もはや珍しいものでも何でもなくなっている。たとえば、多くのラップトップにはEthernetとWiFiの二つの経路があるし、スマートフォンにも、WiFiと3G/4Gという複数の経路がある。特にスマートフォンの場合、経路が使えるかどうかが頻繁に切り替わる。 過去に、TCPで複数のIPアドレスを扱う拡張はいくつも出されたが、いずれも、IPアドレスを隠すという点で

            • Isucon用Webサーバーrecaro : DSAS開発者の部屋

              11/3に開催された #isucon2 に、隣の席の @pandax381 と一緒に、チーム双龍として参加してきました。 結果は惨敗だったのですが、そのレポートを書く前に、 #isucon2 で使う予定だった秘密兵器 recaro について紹介します。 recaro とは recaro はカーネル空間で動く httpd + memcached サーバーです。 httpd サーバーは @pandax381 が作成した tkhttpd で、 memcached は kmemcached というプロジェクトが 未完成のまま放置されていたのを見つけて、私がデバッグ&高性能化したものです。 (KLab/kmemcached) 通常のnginx+memcachedだと ネットワーク <- TCP/IP ]-> nginx <-[ TCP/IP ]-> Memcached ([] はシステムコール) と

                Isucon用Webサーバーrecaro : DSAS開発者の部屋
              • listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jp

                TCP_DEFER_ACCEPTは、LinuxでサポートされているTCPのオプションで、サーバ側で使用した場合にはaccept(2)からのブロック解除をTCP接続が完了したタイミングではなく最初のデータが到着したタイミングで行ってくれるオプションです。 Webサーバ・アプリケーションサーバではリクエストが到着してからaccept(2)のブロックを解除するので、リクエストの到着をWebサーバ・アプリケーションサーバで待つ必要がなくなり、特にprefork型のサーバでは効率的にプロセスを使えるようになるという利点があります。PerlではStarletがこの機能を有効にしています ところが、某サービスでTCP_DEFER_ACCEPTが有効にも関わらず、accept後のreadでデータが読めず、最悪の場合、デフォルトのtimeoutである5分間プロセスがストールすることがありました。strace

                • Stray Penguin - Linux Memo (Iptables tutorial)

                  このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。

                  • TCP localhostとUnix Domain Socketはどちらが速いのか? - Qiita

                    きっかけ 双方向のプロセス間通信をする必要が出てきたのですが、TCPのlocalhost接続とUNIX Domain Socketと、どっちの方がパフォーマンスがいいのか、実測してみました 検証内容 接続するとランダムな文字列を返すだけのサーバを作成 以下の接続方法について、10,000リクエストを同時接続 1/5/10 と条件を変えて計測 TCP localhost Unix Domain Socket / Filesystem Namespace Unix Domain Socket / Abstract Namespace 結論 UNIX Domain Socketの方が速い 当環境においては19倍の違いが計測された また、UNIX Domain Socketの名前空間の比較においては、極めて若干だがAbstract名前空間の方が速い プロセス間通信においては、サーバプロセス終了時の

                      TCP localhostとUnix Domain Socketはどちらが速いのか? - Qiita
                    • 【初心者向け】各OSのTCP通信チェックコマンド入門(2018年 更新版) | DevelopersIO

                      こんにちはコカコーラ好きのカジです。 EC2では色々なOSが構築できますよね。構築後の通信確認はどのように実施してますか? 各OSで他のインスタンスへTCP通信確認のために、ツールをインストールしたり、ICMPなどの別なプロトコルで確認するためにSecurity Groupを一時解放していませんか? 構築直後の状態で、簡単にTCPポート疎通確認可能なコマンドをご紹介します。自分も忘れやすいのでまとめてみました。 以前の記事から、3年が経過し、OSが追加されましたので、更新版です。更新概要はAmazon Linux2、ubuntu16.04、Windows Server 2016の追加、WindowsのPowershellでの調査方法を追記しました。 どなたかのお役に立てれば幸いです。 今回紹介するOSは以下となります。 Amazon Linux,Amazon Linux 2 Windows

                        【初心者向け】各OSのTCP通信チェックコマンド入門(2018年 更新版) | DevelopersIO
                      • DNSのUDPメッセージサイズが512バイト以下に制限された背景とは - INTERNET Watch

                        • 「NETSTAT」をGUIにすると、見えないものが見えてくるかも……

                          「NETSTAT」をGUIにすると、見えないものが見えてくるかも……:ITプロ必携の超便利システム管理ツール集(4) Sysinternalsには60以上のツールがあります。中には、直感的に使えるものから、何に使うかよく分からないものまでさまざまです。今回は、極めて直感的に使える「TCPView」を紹介します。

                            「NETSTAT」をGUIにすると、見えないものが見えてくるかも……
                          • ITmedia エンタープライズ:インターネットの父いわく「NGNは実のない議論」

                            TCP/IPの共同開発者にして「インターネットの父」の一人に数えられるビント・サーフ氏が来日し、インターネットのこれまでとこれからを語った。 TCP/IPの共同開発者にして「インターネットの父」の一人に数えられるビント・サーフ氏が来日した。同氏は2005年10月にMCIを辞し、Googleのチーフインターネットエバンジェリストに就任している。 サーフ氏は9月12日、報道関係者向けにインターネットの特質について語った。 「郵便はがきはいったん投函すれば、それがどんな経路で配送されるかについて気にする必要ない。また、そこにどんな言葉が書かれていようと郵便局は気にしない。インターネットも同じだ。媒体がツイストペアか光ファイバか、あるいは無線かといった事柄は気にする必要はないし、アプリケーションのことも関知しない。テキストだろうが何だろうがただの『ビット』として扱う」(サーフ氏) テレビや電話とい

                              ITmedia エンタープライズ:インターネットの父いわく「NGNは実のない議論」
                            • 実践 パケット解析 第2版

                              ベストセラー書の改訂第2版。前半はWiresharkのリファレンスです。Wiresharkのさまざまな機能や活用テクニックについて解説します。後半はパケット解析の実践的な教科書です。TCP/IPの主要なプロトコルを解析する方法や、ネットワーク遅延をはじめとしたさまざまなトラブルの解決方法を、実際に取得したパケット情報の実例を使って詳しく解説します。日本語版ではTCP/IP以外のパケット解析、具体的にはUSBポートを流れるデータのパケット解析についての解説と、pcap-ng形式 ←→ pcap形式のデータ変換についての解説を巻末付録として追加しました。Wireshark 1.8対応。 目次 監訳者まえがき 賞賛の声 まえがき 1章 パケット解析とネットワークの基礎 1.1 パケット解析とパケットキャプチャツール 1.1.1 パケットキャプチャツールの評価 1.1.2 パケットキャプチャツール

                                実践 パケット解析 第2版
                              • Tuning NGINX for Performance - NGINX

                                Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better

                                  Tuning NGINX for Performance - NGINX
                                • ICANN、プライベートネットワークで使うための公式トップレベルドメイン「.INTERNAL」を提案

                                  インターネット上のIPアドレスやドメイン名などの管理や調整を行っているICANN(Internet Corporation for Assigned Names and Numbers)は、プライベートネットワークやホームネットワークのためのトップレベルドメインとして「.INTERNAL」を予約語として割り当てるという提案を1月24日付で公開しました。 プライベートネットワークには、「192.168.xx.xx」などの専用のIPアドレス空間が公式に割り当てられており、このIPアドレス空間はインターネット上のIPアドレスと衝突しないことが約束されています。 しかし、このIPアドレス空間で管理されているプライベートネットワークのために公式に割り当てられたドメイン名の名前空間は、現時点ではありません。 そのため、プライベートネットワークの運用者がプライベートネットワーク内で何らかのドメイン名を運

                                    ICANN、プライベートネットワークで使うための公式トップレベルドメイン「.INTERNAL」を提案
                                  • はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場

                                    はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を1回のシステムコールにまとめてもいいかど

                                      はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
                                    • ツリー表示が見やすいパケットキャプチャ「TCP Explorer」 | 教えて君.net

                                      公開されたばかりの国産ツール「TCP Explorer」は、自分のマシンと他マシンとの間での通信内容を解析するパケットキャプチャなのだが、プロトコル別/通信相手別/ツール別のツリー表示が特徴的だ。キャプチャ後に目的の通信内容を探しやすい。 パケットキャプチャとは何なのか、そしてどのような目的で利用するのか……という話は、以前紹介した「軽量で使いやすいパケットキャプチャ「SocketSniff」 :教えて君.net」を参照して欲しいが、一般論、「パケットキャプチャ」というものは、何らかの、特定の通信を覗くために利用するものだ。例えば、ツールによる情報漏洩の検証であれば、その「漏洩されている情報」を確認するという、それが「パケットキャプチャを使ってやりたいこと」だ。 ……何を言いたいかというと、自分のマシンや特定ツール(例えばブラウザ)は、通常、多数の相手と、大量の通信を行っている。その中から

                                      • 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

                                          TCP Fast Openの闇と、Kernelの緩和コミット - ASnoKaze blog
                                        • Socket.IO or WebSocket を AmazonELB でバランスする検証 - Block Rockin’ Codes

                                          追記 12/2/29 検証コードと環境は後にしてとりあえず結果だけ書く 12/3/5 Socket.IO の RedisStore を使えばスケール可能なことがわかったので追加 12/3/11 検証コード追加 caution この検証は 東京Node学園 4時限目 - connpass でやった結果です。しかしその時の環境やソースが手元に無いので今再現ソースと環境を作っています。 2/28 現在分かってる結論だけ先に出しておきます。ソースは後で追って掲載します。その時点でもし結論が変わったりした場合は追記します。 また、この検証内容については一切責任は取りませんので、プロダクション等で使う場合はきちんと検証して下さい。 特に ELB の仕様が変わったら結果が変わると思います。結果が変わったことに気がついた方は教えて頂けると助かります。 code 検証コードを公開しました。 https://

                                            Socket.IO or WebSocket を AmazonELB でバランスする検証 - Block Rockin’ Codes
                                          • 仮想ネットワーク実装でTCP/IPを学ぼう ― TCP/IPの基礎と勘所

                                            いまや業務システムではネットワーク環境が当たり前になっており、開発者であってもネットワークプロトコルの知識を知らないでは済まされません。しかし、巷に出版されている専門書は、ネットワーク管理本やプロトコルを図解したもの、または非常に高度な前提知識を求められるものがほとんどです。そこで本連載では、プログラマが実際に手を動かして身に付けられるような形で、TCP/IPについて学んでいきます。 はじめに エンドユーザーの要求は複雑化の一途を辿り、それに伴って開発者にも多くの知識が求められるようになりました。その一例がネットワークプロトコルの知識です。 昔はネットワーク管理者が知っていればよい知識でしたが、いまや業務システムではネットワーク環境が当たり前なので、知らないでは済まされません。それに加え、業務システムには様々な問題がつきものです。ですからトラブルが起こった時、障害がどこで発生しているのか素

                                              仮想ネットワーク実装でTCP/IPを学ぼう ― TCP/IPの基礎と勘所
                                            • Amazon.co.jp: ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識: 戸根勤 (著), 日経NETWORK (読み手): 本

                                                Amazon.co.jp: ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識: 戸根勤 (著), 日経NETWORK (読み手): 本
                                              • A tcpdump Tutorial with Examples

                                                A tcpdump Tutorial with Examples 50 ways to isolate traffic for cybersecurity, network administration, and other technical roles Introduction Overview of tcpdump Basics of traffic isolation Getting Started with tcpdump Viewing traffic on an interface Viewing HTTPS traffic Limiting packets Information Security Examples Capturing credentials Monitoring suspicious domain traffic SMB Traffic Capturing

                                                  A tcpdump Tutorial with Examples
                                                • mixiのサーバOS移行のお話 - ビルド&Kernel編 - mixi engineer blog

                                                  こんにちは。年末と年度末になるとブログを書きたくなる運用部アプリ運用グループの清水です。 気づけば前回の記事から3ヶ月が経過してしまいました… 今回は、ビルド&Kernel編と題して、Fedora 17向けにおこなったパッケージのビルドや、KernelのConfig、TCP周りの変更点について紹介したいと思います。 パッケージのビルド OSが大幅にバージョンアップすると、依存しているライブラリに大きな変更が入ったり、RPMの仕様変更もあるため、Fedora 8時代のパッケージのリビルドなど、多くのRPMパッケージを作りなおさなければなりません。 mixiでは、Fedora標準パッケージとは別に150個以上のパッケージを、 configureなどビルドオプションを変える Fedoraで提供されないパッケージを作る ディストリビューションに依存しない構成のパッケージを作る(あとで紹介するPer

                                                    mixiのサーバOS移行のお話 - ビルド&Kernel編 - mixi engineer blog
                                                  • 高負荷マシンのネットワークチューニング — ありえるえりあ

                                                    Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ

                                                    • Amazon Linux 2017.03で新しいTCP輻輳制御アルゴリズムBBRを試してみた | DevelopersIO

                                                      ども、大瀧です。 AWSが提供するLinuxディストリビューション Amazon Linuxの最新版であるAmazon Linux 2017.03がリリースされました。このリリースで採用しているLinuxカーネル バージョン4.9では、新しいTCP輻輳制御アルゴリズムBBRのサポートが追加されています。 しかしながらAmazon Linux 2017.03.0のカーネルパッケージではBBRモジュールが無効なため、今回はカーネルを再ビルドして試す手順をご紹介してみたいと思います。 お断り : 一般的にカーネルを再ビルドして利用することはディストリビュータのサポート範囲外になります。自己責任の元、検証用途にとどめ本番環境への適用はビルド済みカーネルパッケージのリリースを待ちましょう。 ビルド環境の準備 まずは、カーネルを再ビルドするための環境を整えましょう。一般的にカーネルの再ビルドにはローカ

                                                        Amazon Linux 2017.03で新しいTCP輻輳制御アルゴリズムBBRを試してみた | DevelopersIO
                                                      • DMM inside

                                                        日本アニメ初の快挙!海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏

                                                          DMM inside
                                                        • GitHub - karanpratapsingh/system-design: Learn how to design systems at scale and prepare for system design interviews

                                                          You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                            GitHub - karanpratapsingh/system-design: Learn how to design systems at scale and prepare for system design interviews
                                                          • 【MPTCP】ライブ配信の通信安定化に向けて MultiPath TCP を試験導入している話 - Mirrativ Tech Blog

                                                            こんにちは ハタ です。 今回は Mirrativ の本番サーバの一部に試験導入している MultiPath TCP (MPTCP) について紹介させていただきたいなと思います。 MultiPath TCP といえば、iOSの Siri で利用していることなどで一時有名になりました 今回紹介するMPTCPも同じ技術を使っており、通信の安定化に向けて取り組んでいる事項の紹介になります MPTCP の概要と各OSの実装について MPTCPのイメージ MultiPath TCP (以降 MPTCP)は、複数の経路を通じて同じホストに対して通信が行えるTCP拡張です。 従来のTCP通信では、単一の通信パスしか使えなかったものが、複数の通信パスを利用できるようになります。 例えばスマートフォンでは 4G 回線と WiFi ネットワークが用意されているため、それぞれから同一のコネクション張り、どちらか

                                                              【MPTCP】ライブ配信の通信安定化に向けて MultiPath TCP を試験導入している話 - Mirrativ Tech Blog
                                                            • NGINX 1.9が汎用TCPサーバとして使えるようになっていた件 - Qiita

                                                              はじめに 一年程前にリリースされた Nginx v1.9.0で、Streamモジュールが追加されました。 Streamモジュールを使うと、任意のポートでNginxがTCPの接続を待ち受けるよう設定できます。 この機能は、例えばNginxをTCPロードバランサとして構成する時に威力を発揮するようです。 nginx Blog - TCP Load Balancing with NGINX 1.9.0 and NGINX Plus R6 強力そうな機能ですが、個人的にNginxをTCPロードバランサとして使っていなかったため、特に機能を活用する場もなくスルーしていました。 ところで、つい先日公開されたNginxのモジュール、stream-lua-nginx-module、及び、stream-echo-nginx-moduleを組み合わせれば、任意のポートで待ち受けるTCPサーバをLuaで記述でき

                                                                NGINX 1.9が汎用TCPサーバとして使えるようになっていた件 - Qiita
                                                              • Google、高速プロトコル「QUIC」を今後はインターネット標準としてIETFに提案へ

                                                                  Google、高速プロトコル「QUIC」を今後はインターネット標準としてIETFに提案へ 
                                                                • 最速TCPサーバーの条件 〜逆襲の Erlang と Haskell の挑戦〜 : DSAS開発者の部屋

                                                                  釣った反響に応えて echo サーバーを改良していて PyCon JP の発表資料作成が進みません。 自業自得です。 methane です。 Erlangとは何だったのか でのベンチマーク結果では Erlang のスコアが奮わなかったのですが、 github で 性能改善する pull request をいただきました。 性能が悪かった原因ですが、実は backlog がデフォルトだと 5 で、ベンチマーク開始時の 大量の接続要求を捌ききれていないという状況でした。 高負荷サイトのボトルネックを見つけるには で紹介されている事例と同じ現象ですが、こちらのほうが backlog が小さく、 しかもベンチマーク用クライアントはほぼ同時に大量に接続をしてくるという条件で よりシビアに現象が発生してしまいました。 この問題が修正された Erlang は、 Go を超えて一気にランキング上位に踊り出

                                                                    最速TCPサーバーの条件 〜逆襲の Erlang と Haskell の挑戦〜 : DSAS開発者の部屋
                                                                  • tcptrackでトラフィックや通信状況をリアルタイム把握 | Pocketstudio.jp log3

                                                                    ◆tcptrackは、いわゆるsnifferの1つ。 「もしかして Dos 攻撃を食らってる?」という時、みなさんどうされています? Linux サーバの TCP  通信状況を把握するのに、接続元・接続先の把握であれば、netstat を使うのが一般的。より細かな通信状況であれば tcpdump を使うでしょう。ですが、通信状況だけでなく、”転送量”を知りたい場合や、今どこのホストとの通信がサーバの負担になっているかを把握する事は、そうそう単純ではありません。 そんなとき tcptrack を使うのが便利です。tcptrack は、”top” コマンドのように、秒単位で刻々と通信状況を表示することができます。どのホスト間で、どのような通信状態で、アイドル状態の秒数、転送レートを表示することができます。 ◆インストール方法 バイナリまたはソースコードからインストールできます。現行バージョン

                                                                    • Ethereal - This Ultra Rare Brand Concept is Available for Purchase.

                                                                      This domain not actively for sale, but will consider reasonable offers

                                                                        Ethereal - This Ultra Rare Brand Concept is Available for Purchase.
                                                                      • Programming UNIX Sockets in C - Frequently Asked Questions: クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問

                                                                        Previous Next Table of Contents 2. クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問 2.1 相手側のソケットが閉じられたことをどうやって知ることができますか? Andrew Gierth 氏 ( andrew@erlenstar.demon.co.uk) より: 私の知る限り… 相手側が (SO_LINGER を使ったややこしいことをしないで) close() するか終了したとすると、こちらの read() の呼び 出しは 0 を返すはずです。同じ場合で、write() 呼び出しで何が 起こるかは、もうちょっとわかりづらいです。直後の呼び出し時ではな く、その次の呼び出し時にEPIPE が返るでしょう。 もし相手が再起動するか l_onoff = 1, l_linger = 0 を設定して から閉じたとすると、read() からは(

                                                                        • PHPでTCPサーバを作ってみる - 覇王色を求めて

                                                                          この記事はPHP Advent Calender 2012の2日目の記事になります、詳細は以下をどうぞ。 PHP Advent Calender 2012 フレームワークやCMS的な記事が多いので、あまり参考例のないTIPSを書きたいと思います。 PHPでTCPサーバを立ててみる PHPでTCPなサーバを作るとなると、socket関数やfsockopenなどを使った例を多く見かけます。 PHPというよりかはLinuxなネタになってしまいますが、ここではxinetdを使った例を書いてみたいと思います。 xinetdとは? 今回は、スーパーサーバーと呼ばれる xinetd の設定方法について説明していきます。スーパーサーバーとは、ポート監視用のデーモンプログラムで、あるポートに対してアクセスがあると、設定ファイル (/etc/xinetd.d/ 等) を元にポートに対応したサービス (ftp

                                                                            PHPでTCPサーバを作ってみる - 覇王色を求めて
                                                                          • IBM Developer

                                                                            IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

                                                                              IBM Developer
                                                                            • ソフトバンク回線のパケットロスがほんとーーにひどいのかTCPでも確かめてみた | [ bROOM.LOG ! ]

                                                                              ニコニコPodder iPhone/iPod/iPad対応ニコニコ動画簡単インポートツール aggregateGithubCommits GitHubレポジトリでのコミット数をAuthor/期間別に集計します probeCOCOATek 新型コロナ接触確認アプリCOCOAが配布するTEKを表示・集計 前回記事に対して、「ICMP(ping)のパケットの優先度を落としているだけでは」という意見も幾つかあったようだ。 本文でも書いているとおり、僕自身はパケットロス率に注目したのではなく、それに伴うラウンドトリップタイム(RTT)の時間帯での差異から(ICMP/TCPあるいはUDP関わらず)バックボーンを守るための何らかのパケット制限がかけられているのではないか、という見解だ。 ただ70-90%という値があまりにセンセーショナルだったため数字が一人歩きしたか、エントリー全文が読まれていないという

                                                                              • 高負荷環境でDBが直面する問題とは?PHPとMySQLの TCP TIME-WAIT チューニング(前編) | さくらのナレッジ

                                                                                サンプルサーバーのパケットフィルタは最初は以下の内容で設定し、セキュリティを確保しています。 tcp 22 はプライベートLANからの受信のみ許可 tcp 3306 は 153.127.195.113 のappサーバーだけに公開 tcp 80 は公開 tcp, udp の 32768-61000 はアウトバウンド通信の戻りパケット用に許可 ストリーミングのフラグメントパケットは公開 ip は基本拒否 また IP アドレスを打たずにホスト名でアクセス出来るように /etc/hosts に以下のエントリを追加しました。 153.127.195.113 app 153.127.203.176 db MySQLクライアントで接続して TCP の状態を観察 ここから実際にサーバーを動かして、その挙動を観察していきます。db サーバーに db1 データベースを作成し、アクセスユーザー user1 を追

                                                                                  高負荷環境でDBが直面する問題とは?PHPとMySQLの TCP TIME-WAIT チューニング(前編) | さくらのナレッジ
                                                                                • golangで作るTLS1.2プロトコル

                                                                                  はじめに 前回自作でTCPIP+HTTPを実装して動作を確認することができました。 しかしご覧頂いた方はおわかりのように、通信はHTTP=平文でやり取りされておりパスワードなど機密情報が用意に見れてしまう状態です。 普段我々がブラウザに安心してパスワードを入力しているのは通信がTLSで暗号化されているからです。ではそのTLSの仕組みはどうなっているのでしょう? 恥ずかしい限りですが僕はわかりません。😇😇😇 ということで以下を読みながらTLSプロトコルを自作してみてその仕組みを学ぶことにします。 マスタリングTCP/IP情報セキュリティ編 RFC5246 プロフェッショナルSSL/TLS 今回の実装方針です。 TLS1.2プロトコルを自作する 暗号化などの処理はcryptパッケージの関数を適時利用する tcp接続にはconnectを使う 鍵交換はまずRSAで作成する TLS_RSA_W

                                                                                    golangで作るTLS1.2プロトコル