並び順

ブックマーク数

期間指定

  • から
  • まで

241 - 280 件 / 308件

新着順 人気順

TCPの検索結果241 - 280 件 / 308件

  • Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?

    小崎 資広 (KOSAKI Motohiro) @kosaki55tea . @sonots から日本のWeb界隈ではTCP_TIMEWAIT_LEN を変更してカーネルリコンパイルがデファクトという話を聞いて軽くぐぐってみたところ、たしかに大量にそのようなページがヒットする。しかもどれ一つとして理由が書いてない。そして日本特有の現象 2015-09-09 00:03:14 小崎 資広 (KOSAKI Motohiro) @kosaki55tea 軽くソースを見た感じだと、tcp_tw_reuse をセットすると1秒で TIME_WAITのsocketは再利用が始まるので、いまひとつリコンパイルの必要性が分からず。これ、ソース呼んで妥当性チェックした人がいるノウハウなのかなあ 2015-09-09 00:04:39

      Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?
    • SEIL/SMF コミュニティサイト リニューアル

      SEIL/SMF コミュニティサイトはリニューアルしました。 SEIL/SMF コミュニティサイトで提供されていた、サポートフォーラム、SEIL/x86 Fujiダウンロードページ、ブログは、以下のリンク先をご利用ください。

      • あなたのネットワークスタック正しく設定されていますか? - Qiita

        はじめに Linux Advent Calendar 10 日目の記事です。 運用や研究開発の現場では、ソフトウェアの実験、または機器のテストや選定などのために、ベンチマークツールや自前のアプリケーションでコンピュータ間の通信速度を計測する機会が多々あると思います。一方で10Gbpsや40Gbpsといった昨今の高速ネットワークにおいては、これらの計測結果はアプリケーションの通信API部分の実装、カーネルパラメータまたはコンパイルオプションによって大きく変わってしまうため、正確な計測を行うためにはこれらを正しく設定/理解する必要があります。この記事では、ネットワーク周りのカーネルとアプリケーションの動作の概要と、その中の重要なポイントを理解することを目的にします。 ネットワークプログラミングのおさらい まず最初に、TCPを使う今時のサーバプログラムがどのようにできているか簡単におさらいします

          あなたのネットワークスタック正しく設定されていますか? - Qiita
        • WELL KNOWN PORT NUMBERS

          Last Updated 2024-04-19 Expert(s) TCP/UDP: Joe Touch; Eliot Lear, Kumiko Ono, Wes Eddy, Brian Trammell, Jana Iyengar, and Michael Scharf SCTP: Michael Tuexen DCCP: Eddie Kohler and Yoshifumi Nishida Reference [RFC6335] Note Service names and port numbers are used to distinguish between different services that run over transport protocols such as TCP, UDP, DCCP, and SCTP. Service names are assigned

          • Red Hat Enterprise Linux 7.1でもssコマンドは腐っているので使い物にならない - ろば電子が詰まつてゐる

            以前、CentOS 7 (7.0.1406)およびRed Hat Enterprise Linux 7のssコマンドが腐っていたことにビックリして、「ssコマンドはバグと地雷の塊なのでnetstatの代わりにならない」という記事を書きました。 これはどういうお話かと言うと: RHEL 7からはnetstatコマンドなどが収録されているnet-toolsパッケージが非推奨となり、デフォルトではインストールすらされなくなりました。 しかしnetstatコマンドの代替であるssコマンドはかなり雑な感じで、UDPポートを「tcp」と表示するひどいバグがあります というお話でした。 このssコマンドのバグは、2014年2月にRed Hat Bugzillaにも上がっていました。 https://bugzilla.redhat.com/show_bug.cgi?id=1063927 というわけで、さす

              Red Hat Enterprise Linux 7.1でもssコマンドは腐っているので使い物にならない - ろば電子が詰まつてゐる
            • 現在の無線通信速度を10倍以上向上させる新技術が登場。しかも、ただ通信の仕方を少し変えるだけ

              現在の無線通信速度を10倍以上向上させる新技術が登場。しかも、ただ通信の仕方を少し変えるだけ2012.10.29 19:00 Wi-Fiでは10倍以上、新幹線のような高速で移動中では約27倍に速度が向上! 驚きです! 先日、MITやハーバード大学などの合同研究チームが、基地局を新たに作る事や送信電力の増加やインフラの整備など、これらすべて行わなかった場合でも通信速度が劇的に速くなる技術を開発したそうです。 私達が普段使っている携帯等の無線ネットワーク通信のパケットは全パケットの約3%が、高速で移動する電車のような乗り物に乗車している時には5%もパケットロスが発生しています。たかだか3%や5%のロスなんてそんなものあまり通信速度に影響はないと思ってしまいそうですが、今回の報道によるとそのごくわずかな3〜5%のパケットロスを改善する技術を使った結果、通常のW-Fiネットワークでは1Mbpsが1

              • Googleの新プロトコルQUICを試す - ぼちぼち日記

                1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち(来週?)には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか? 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte

                  Googleの新プロトコルQUICを試す - ぼちぼち日記
                • Go 言語のプロファイル機能とネットワークコネクションにまつわるトラブルシューティング

                  ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog インフラエンジニア見習いの森本です。これまで数年ほどサーバーサイドエンジニアとして開発ばかりをしてきた人が最近インフラエンジニアになりました。 3月末に開催された Go Conference 2017 Spring で開発チームの後藤から弊社で開発・運用している AWS S3 互換の分散オブジェクトストレージ Dragon についての発表がありました。 Goでヤフーの分散オブジェクトストレージを作った話 私は Dragon の運用を担うチームに所属しており、本稿ではその業務の中で発生したトラブルシューティングについて紹介したいと思います。 分散オブジェクトストレージ Dragon で発生していた課題 Dragon で gorout

                    Go 言語のプロファイル機能とネットワークコネクションにまつわるトラブルシューティング
                  • [PDF] On the Duality of Operating System Structures

                    Hållbar omställning och konkurrenskraft på vetenskaplig grund

                      [PDF] On the Duality of Operating System Structures
                    • HTTP and 5G partial draft

                      The document discusses computational fluid dynamics (CFD) simulations of flow around a void or empty space using MATLAB. It describes governing equations for fluid momentum and energy that are solved using finite difference methods. The analysis involves simultaneous solution of the unsteady equations over time. Sample MATLAB code is shown that loads data, defines parameters, iterates the calculat

                        HTTP and 5G partial draft
                      • TCP/IPでネットワークが繋がるわけ「で・ね・と」

                        qpstudy 2015.06 での、OSI L2〜L4 および TCP/IP の説明資料です。 This slide is about the OSI and TCP/IP.

                          TCP/IPでネットワークが繋がるわけ「で・ね・と」
                        • heartbleedをiptablesで止めることについて - yasulib memo

                          前書き OpenSSLの脆弱性(CVE-2014-0160)が公開されました。 詳細はpiyokangoさんの素晴らしいまとめを参照してください。 OpenSSLの脆弱性(CVE-2014-0160)関連の情報をまとめてみた - piyolog エフセキュアブログにて、トーマツの岩井さんが書いた興味深い記事がありました。 エフセキュアブログ : Openssl Heartbleed 攻撃の検知について #根本的な対策ではなく、あくまで攻撃検知という意味で。 iptables log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" iptables block rules i

                            heartbleedをiptablesで止めることについて - yasulib memo
                          • 各種ネットワーク通信量をリアルタイムにグラフ化するフリーソフト「Yale」

                            HTTP・HTTPS・DNS・UDP・UPnP・POP3・FTP・HTTPProxy・Terminal Services・DHCP・IGMPといったネットワーク通信量とパソコンのCPU負荷率・ディスク動作を計測してリアルタイムにグラフ化できるのが「Yale」です。特定のネットワーク通信量だけを表示する設定も可能となっています。ダウンロードから操作方法までは以下から。 Yale::See network adapter usage - The SZ http://thesz.diecru.eu/content/yale.php ◆ダウンロード 上記サイトの「Download Yale.zip」をクリック。 ダウンロードしたZIPファイルをExplzhなどで解凍して、「Yale.exe」を起動。 ◆操作方法 起動後、画面右下に「Yale」が表示されます。 CPU負荷率・Disk動作・ネットワー

                              各種ネットワーク通信量をリアルタイムにグラフ化するフリーソフト「Yale」
                            • Unix Domain Socket において keep-alive が性能に与える影響 (Gazelle vs Meinheld) - methaneのブログ

                              id:kazeburo さんが Gazelle という高速な Perl 用の Web アプリケーションサーバーを公開されました。 Gazelle - Plack Handler for performance freaks #yokohamapm from Masahiro Nagano Gazelle の特徴のうち幾つかは、 id:mopemope 作の Meinheld と同じです。 IO周りは全てCで書かれている accept4 や writev などの Linux 独自のシステムコールを利用している 一方で異なる点もあります。 Meinheld は HTTP/1.1 に対応していて、 keep-alive が利用できる。 Meinheld は greenlet というコルーチンを利用して、 long polling や SSE に対応している。 Meinheld が http-pa

                                Unix Domain Socket において keep-alive が性能に与える影響 (Gazelle vs Meinheld) - methaneのブログ
                              • HTTP2 のフロー制御 - Qiita

                                この記事は HTTP2 Advent Calendar の 1 日目の記事です。 初回は、執筆時点での最新ドラフトである HTTP2-draft16 のフロー制御(Flow Control) について解説します。 余談ですが, 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です. 更新 @kazu_yamamoto さんに指摘頂いた点を反映しました。 @kiri__n さんに指摘頂いた点を反映しました。 詳細については 更新履歴 をご覧下さい。 HTTP2 では、同じホストへの複数のリクエストを、同一の TCP コネクション上にストリームという単位で多重化することができるようになりました。 フロー制御とは、例えばひとつのストリームがリソースを占有してしまうことで、他のストリームがブロックしてしまうことを防ぐ、といった目的で行われます。

                                  HTTP2 のフロー制御 - Qiita
                                • https://tech.pepabo.com/2020/06/26/kernel-dive-tcp_mem/

                                    https://tech.pepabo.com/2020/06/26/kernel-dive-tcp_mem/
                                  • DELLのサーバでCentOS6でLVS+keepalivedなロードバランサを構築したらハマったりした話

                                    みなさんどうもこんにちは。CTOの馬場です。 最近DELLのサーバ(R410)で、CentOS6.3を使ってLVS+keepalivedなロードバランサを構築したら 見事にハマったりしたので記念ポスト。 ちょっと長いので、一番のドハマリだけ見たい方は最後の「通信速度が著しく遅い件」だけでも見ていただけるとよろしいかと思います。かしこ。 eth0、eth1がない件 いやー。びびった。まじでびびった。 インターフェース名がem1、em2になってます。きもい。 このあたりを参考に対応します。 Getting back to using eth0 in Fedora 15 /boot/grub/grub.conf に biosdevname=0 追記 /etc/udev/rules.d/70-persistent-net.rules の NAME を変更 /etc/sysconfig/networ

                                    • ネットワ―クの基本設定などを確認(Linux版)

                                      ネットワークの設定,変更などをどこで設定するか. 何を確認するか. (大抵の場合,設定は /etc/init.d, /etc/rc.d などにあるスクリプトなどで行っている.) 関連ファイル /etc/modules.conf : module の設定 ネットワーク設定(IPアドレスなど) /etc/network/interfaces : (Debian) /etc/rc.d/rc.inet1 : (Plamo) /etc/sysconfig/network-scripts など : (RedHat, Vine) /etc/init.d/* 又は /etc/rc.d/init.d/* : 初期設定スクリプト ホスト名参照 /etc/hostname : 自ホスト名(Debian) /etc/sysconfig/network: 自ホスト名(RedHat) /etc/HOSTNAME :

                                      • QUICはTCPの代替ではない

                                        ブルース・デイヴィーのブログより。 TCPの新しい決定的な仕様(RFC 9293)の公開は、私たちの世界ではとても大きな出来事で、このトピックに関する2回目の投稿をせずにはいられませんでした。特に、QUICとTCPを比較した議論に興味をそそられ、今週のニュースレターを書くきっかけとなりました。 TCPの過去と未来に関する前回の投稿では、QUICがTCPを置き換え始めるかも知れないという可能性について触れました。今週は、QUICは実際にはTCPが解決する問題とは異なる問題を解決しているので、TCPの置き換えとは別のものとして見るべきであると主張したいと思います。一部の(あるいはほとんどの)アプリケーションでは、QUICがデフォルトのトランスポートになるかも知れませんが、それはTCPが本来意図されていなかった役割に押しやられたからだと思います。なぜ私がそのような主張をするのか、一歩下がって考え

                                        • アンターネット。蟻は何百万年も前からインターネットのアルゴリズムを駆使していた

                                          アンターネット。蟻は何百万年も前からインターネットのアルゴリズムを駆使していた2012.09.10 17:00 satomi 人類がインターネットを発明する遥か前からアリは餌探しでTCPと同じアルゴリズムを使っていたことがスタンフォード大の調べで明らかになり、早速「アンターネット」という世にもラブリーな名前がつきましたよ。 発見したのは、アリんこ研究歴20余年のデボラ・ゴードン(Deborah Gordon)生物学教授とバラジュ・プラバカー(Balaji Prabhakar)コンピュータサイエンス教授。 TCPは最初のパケットで帯域が小さいと判断するとデータ転送量を絞って調整しますけど、収穫アリも最初の食料探し隊の帰りがあまりにも遅いと「食料があんまりない山だな」と判断し、次に送る兵の数を絞っていたんですね。 スタンフォード・ニュースはこう伝えています。 収穫アリ(単独行動で種を探し回る)

                                            アンターネット。蟻は何百万年も前からインターネットのアルゴリズムを駆使していた
                                          • How TCP backlog works in Linux

                                            When an application puts a socket into LISTEN state using the listen syscall, it needs to specify a backlog for that socket. The backlog is usually described as the limit for the queue of incoming connections. Because of the 3-way handshake used by TCP, an incoming connection goes through an intermediate state SYN RECEIVED before it reaches the ESTABLISHED state and can be returned by the accept s

                                              How TCP backlog works in Linux
                                            • 並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント : DSAS開発者の部屋

                                              並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント こんにちは、takada-at です。 Rubyのイベント駆動型ネットワークプログラミングフレームワーク Rev と EventMachine で HTTPクライアントを動かしてみました。 イベント駆動型ネットワークプログラミングフレームワークとは何か説明しだすと難しいですが、一言で言うと、以下のようになります。 # ふつうのフロー駆動型プログラム Net::HTTP.start(host, port){|http| res = http.get(path) #この処理が終わってから } puts "done" #この次の処理が実行される # イベント駆動型プログラム client = Rev::HttpClient::connect(host, port

                                                並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント : DSAS開発者の部屋
                                              • QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉

                                                先週スウェーデンのKistaで開催された第5回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化(つまり正当なパケットと攻撃との区別がつかない)、黄は未認証の暗号化(通

                                                  QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
                                                • マイIPはどこでも固定IP環境を実現します | インターリンク【公式】

                                                  このような方におすすめ 固定IPアドレスが提供されないプロバイダーを利用している方 ワイモバイル(旧イーモバイル・Pocket WiFi)やUQ WiMAXなどのモバイル通信で固定IPアドレスを利用したい方 au・SoftBank・docomoのLTE(4G)通信やテザリングで固定IPアドレスを利用したい方 出張先、旅行先のホテル、出先のカフェなどから、固定IPアドレスを利用したい方 iPhone、iPad、Androidなどのモバイル端末やスマートフォンから、固定IPアドレスを利用したい方(※マイIPのみ対応) サーバーの整備・メンテナンス・保守管理やFTP接続などで、一時的に固定IPアドレスが必要な方 盗聴される危険性の高い無料Wi-Fiスポット等で、安全にインターネットしたい方 固定IPアドレスを使ったインターネットEDI・流通BMSを構築したい方 接続イメージ インターネットに接続

                                                  • TechCrunch | Startup and Technology News

                                                    Welcome back to TechCrunch’s Week in Review — TechCrunch’s newsletter recapping the week’s biggest news. Want it in your inbox every Saturday? Sign up here. Over the past eight years,…

                                                      TechCrunch | Startup and Technology News
                                                    • http://www.space-peace.com/ethereal/

                                                      • Developing the fastest HTTP/2 server

                                                        Presentation material for TokyoRubyKaigi11. Describes techniques used by H2O, including: techniques to optimize TCP for responsiveness, server-push and cache digests.

                                                          Developing the fastest HTTP/2 server
                                                        • HTTP/3が正式に勧告、脱TCP時代の幕開けか

                                                          インターネット関連技術の標準化を手掛けるIETF(Internet Engineering Task Force)は2022年6月6日(米国時間)、通信プロトコル「HTTP/3(HyperText Transport Protocol/3)」を「RFC 9114」として勧告した。HTTP/3はインターネット通信の多くを占めるWebにおける通信プロトコルの最新版である。 最大の特徴は、トランスポートのプロトコルに「QUIC(Quick UDP Internet Connections)」を採用した点。QUICは2021年にIETFで「RFC 9000」として勧告された。その名前が示すように、TCP(Transmission Control Protocol)ではなく、UDP(User Datagram Protocol)に基づくプロトコルだ。TCPが備えていた再送制御の仕組みや、TLS(Tr

                                                            HTTP/3が正式に勧告、脱TCP時代の幕開けか
                                                          • tcpdumpとtcpreplayとtcprewriteと他。

                                                            続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2Preferred Networks

                                                              tcpdumpとtcpreplayとtcprewriteと他。
                                                            • 「Rustで始めるネットワークプログラミング」を出版しました。 - 電気ひつじ牧場

                                                              書籍をkindleとBOOTHで販売開始したので、内容の紹介と出版について書き連ねていきます。 内容紹介 出版したもの サンプル 対象読者について 各章について 1章「ようこそソケット通信の世界へ」 2章「通信を監視する」 3章「手づくりパケットでポートスキャン」 4章「ノンブロッキングなWEBサーバ」 5章「RFCから作るDHCPサーバ」 執筆あれこれ 執筆期間について 執筆ツールについて 表紙について 価格について プラットフォームについて 終わりに 内容紹介 出版したもの 「Rustで始めるネットワークプログラミング」をkindle(https://t.co/Mf98l0YgKS)とBOOTH(https://t.co/ilHIt1UEbi)で販売開始しました。 全101ページ/5章構成で、価格は¥500です。無料サンプル(https://t.co/NilMo1QAhL)もあります。

                                                                「Rustで始めるネットワークプログラミング」を出版しました。 - 電気ひつじ牧場
                                                              • ElementHost クラス (System.Windows.Forms.Integration)

                                                                このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。

                                                                  ElementHost クラス (System.Windows.Forms.Integration)
                                                                • Windowsネットワーク 第16...@IT:連載 基礎から学ぶ

                                                                  第16回 信頼性のある通信を実現するTCPプロトコル(3):基礎から学ぶWindowsネットワーク(3/4 ページ) TCP技術を習得するうえで非常に重要な項目として、「TCPの状態遷移図」というものがある。これはTCPプロトコルの規格書であるRFC793(STD0007)に掲載されている、TCPプロトコルの内部ステートを表現した図である。すでに解説したように、TCPでは接続ごとに、それぞれシーケンス番号やACK番号、オープン/クローズなどの処理状態といった「ステート(状態)」を持っている。このようなプロトコルを「ステートフルな(stateful、状態を持つ)」プロトコルという。TCP接続のオープンやクローズ、確立などに伴う、状態の変化を表現した図を「状態遷移図」という。 以下は、RFC793に記載されているTCPの状態遷移図を簡略化したものである(完全な状態遷移図についてはRFC793を

                                                                    Windowsネットワーク 第16...@IT:連載 基礎から学ぶ
                                                                  • TCP-IPポート番号一覧

                                                                    Last update 2008.03.20 TCP/IP のポート番号一覧です。IANA提供の資料を抜粋&加工しましたしました。 TCP、UDPのポート番号は大きく3種類に分かれています。 1.よく知られているポート(WELL KNOWN PORT NUMBERS) 0-199 200-499 500-1023 2.予約済みポート(REGISTERED PORT NUMBERS) 1024-1499 1500-1699 1700-1999 2000-2499 2500-3299 3300-4999 5000-9999 10000-49151 3.動的/プライベートポート(DYNAMIC AND/OR PRIVATE PORTS) 49152〜65535 ☆サービス順にソートしてみました Reserved or Unassigned 数字-B C-C D-E F-

                                                                    • RabbitMQ と再送について

                                                                      概要 : AMQP のプロトコルを読むと、一瞥して送信はパケットを送るだけ、受信はソケットを読み込むだけのようにも見える。しかしながら、実際に書いてみると、再送処理を自前で実装する必要があるため、現実には大変に複雑な処理が必要だ。 そもそもなぜ RabbitMQ を使うのかという話、あるいはなぜ再送が必要かという話たんにコンポーネント同士が疎結合で通信したいのであればわざわざ MQ を使う必然性は皆無である。ごくあたりまえに TCP で通信すればそれでいい。暗号通信が必要なら当然 SSL でいいし、パケットエンティティに依存する複雑な L7 リバースプロキシを MQ を使って実現することも、不可能ではないが、普通そういうのは varnish とかでやるだろう。 MQ において優れているのはデータの durability だ。つまり、一旦キューにためておけば、その両側のコンポーネントは好き勝

                                                                        RabbitMQ と再送について
                                                                      • Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由(& サーバのベンチマーク手法の話)

                                                                        TCP通信をするプログラムを書く際に「データの送信はまとめて1回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ(1回のwrite(2)で書き込むサイズ)の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ(=パケット数の逆数)による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生

                                                                        • Linux Performance Analysis in 60,000 Milliseconds

                                                                          You log in to a Linux server with a performance issue: what do you check in the first minute? At Netflix we have a massive EC2 Linux cloud, and numerous performance analysis tools to monitor and investigate its performance. These include Atlas for cloud-wide monitoring, and Vector for on-demand instance analysis. While those tools help us solve most issues, we sometimes need to login to an instanc

                                                                          • WebSocket(RFC 6455)上で使用するプロトコル設計についての備忘録 - kazuhoのメモ置き場

                                                                            一般論として、全二重の通信プロトコルを実装するにあたっては、いくつか注意すべき点があって、具体的には、到達確認と切断シーケンスについて定めておかないと、送達されたはずのメッセージがロストしていたり、切断タイミングによってエラーが発生*1したりする。 具体例をあげると、たとえばTCP/IPにおいてshutdown(2)を用いずに、いきなりclose(2)を呼んでいると、read(2)やwrite(2)がエラー(ECONNRESET)を返す場合がある。 翻って、WebSocket (RFC6455)の場合はどうなってるか? だいたい以下のような感じっぽい。 ws.close()が呼び出されるとWebSocketをCLOSING状態に変更し、Closeフレームを送信する ws.onmessageはWebCosketがCLOSING状態にある間も呼ばれるかもしれない*2 相手からCloseフレーム

                                                                              WebSocket(RFC 6455)上で使用するプロトコル設計についての備忘録 - kazuhoのメモ置き場
                                                                            • TCP接続の追跡による簡略化したネットワーク依存関係グラフの可視化基盤 - ゆううきブログ

                                                                              著者: 坪内佑樹(*1), 古川雅大(*1) 所属: (*1) 株式会社はてな 研究会: Web System Architecture研究会#3 はじめに ウェブシステムは,一般的に,分散したホスト上で動作するソフトウェアが互いにネットワーク通信することにより構成される. 相互にネットワーク通信するシステムにおいて,システム管理者があるネットワーク内のノードに変更を加えた結果,ノードと通信している他のノードに変更の影響がでることがある. ネットワーク接続数が多いまたはノードが提供するサービスの種類が多くなるほど,システム管理者が個々の通信の依存関係を記憶することは難しくなる. さらに,常時接続しておらず必要なタイミングで一時的に通信するケースでは,あるタイミングの通信状況を記録するだけでは通信の依存関係を把握できない. その結果,システムを変更するときの影響範囲がわからず,変更のたびに依

                                                                                TCP接続の追跡による簡略化したネットワーク依存関係グラフの可視化基盤 - ゆううきブログ
                                                                              • http://blog.quall.net/linuxserver/182/

                                                                                • Windows OSのデフォルトゲートウェイは1つのみ有効

                                                                                  対象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のプロパ

                                                                                    Windows OSのデフォルトゲートウェイは1つのみ有効