Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
最新版は以下となります。 https://dev.classmethod.jp/etc/ec2-tcp-port-check-command-2018/ こんにちはコカコーラ好きの梶です。 EC2では色々なOSが構築できますよね。構築後の通信確認はどのように実施してますか？ 各OSで他のインスタンスへTCP通信確認のために、ツールをインストールしたり、ICMPなどの別なプロトコルで確認するためにSecurity Groupを一時解放していませんか？ 構築直後の状態で、簡単にTCPポート疎通確認可能なコマンドをご紹介します。 Amazon Linux,Ubuntu,Windows2012R2,CentOSについて自分も忘れやすいのでまとめてみました。 どなたかのお役に立てれば幸いです。 Amazon Linux 動作確認AMI:amzn-ami-hvm-2014.09.2.x86_64-eb
皆さん、こんにちは。 このコラムでは、ネットワークエンジニアとして活躍されている方を対象として、資格試験だけでは得られない実践的な技術テーマについて取り上げていきたいと思いますので、よろしくお願いします。 突然ですが、私の知人が以下のような現象に遭遇しました。なぜ、このようなことが起きるのか、わかりますか？ FTTHのインターネット接続サービスを使用しており、公衆FTPでスループット測定を行うと85Mbpsくらい出ている。 しかし、無線LANを使用すると20～30Mbps程度の速度しか出ていなかった。 そこで今回、新しく802.11n対応の無線LAN内蔵ルータを購入した まず、ルータにFTPサーバを直接接続し、無線LANを倍速設定にしてスループットを測定したところ、約100Mbpsくらいでており、「さすがイレブンエヌだぜ」と期待が高まる ところが、実際にインターネット（FTTH）に接続す
mTCP enables high-performance userspace TCP/IP stacks by bypassing the kernel and reducing system call overhead. It was shown to achieve up to 25x higher throughput than Linux for short flows. The document discusses porting the iperf benchmark to use mTCP, which required only minor changes. Performance tests found that mTCP-ified iperf achieved similar throughput as Linux iperf for different packe
年末が近づいてきて仕事が燃えさかっているので記事を書いて現実逃避しています。 さて、(なんかいきなり一年を振り返ってるみたいで唐突ですが)今年はDockerをはじめとしたコンテナ技術がついに一般的な世界に降りてきてみんなドッカードッカーといろんなことを試したりした年でした。 Dockerは個人的に一つ面倒な点があって、基本的にLinuxじゃないと動かないというのがあります。ホントは手元のMacでDockerしたいのですが、さすがにDockerのコンテナはMacでは動きません。で、それに対する一般的なソリューションは、VirtualBoxをインストールしてLinux(CoreOSとかboot2docker)を動かしてそこにつなごう! というものでした。 まーそれでもいいんですが、出来ればMacの上でVMは動かしたくないんですよねー。ぼくの場合は自宅サーバにたくさんVM立ててあるからVMはそっ
WindowsネットワークはNetBIOSと呼ばれる古い技術をベースにしている。そのため長いコンピューター名が使えないとか、ネットワーク上でユニークな名前が要求されるなどの制約がある。 連載目次 前回は、共有リソースを見つける「コンピューターブラウザー」と「ネットワーク探索」サービスについて解説した。今回からは、ネットワークプロトコルの内部について見ていく。今回は、Windowsネットワークと深い関係があるNetBIOSについて、その歴史を振り返りながら見ていこう。 NetBIOSとは？ 一般にTCP/IPネットワークでは、利用する機器にユニーク（一意）な「IPアドレス」を付けておけば、とりあえず問題なく相互に通信ができる。TCP/IPネットワークでは、IPアドレスさえあれば（「名前」がなくても）相互に通信できるからだ。だがWindows OSの場合は少し事情が異なる。Windowsネット
各位 JPCERT-AT-2014-0038 JPCERT/CC 2014-10-10 <<< JPCERT/CC Alert 2014-10-10 >>> TCP 10000番ポートへのスキャンの増加に関する注意喚起 https://www.jpcert.or.jp/at/2014/at140038.html I. 概要 JPCERT/CC では、TCP 10000番ポートへのスキャンが 2014年9月下旬より増加 していることを、インターネット定点観測システム (以下、TSUBAME) *1 にお いて確認しています。 TCP 10000番ポートは、ウェブベースのシステム管理ツールである Webmin の 標準ポートとして利用されることが多く、開発者によると Webmin は先日公開 された GNU bash の脆弱性の影響を受けるとのことです。 Changes since Webmi
2. rcu read lock receive_queue lock nf_hooks nf_iterate rcu read lock tcp_rcv_established tcp_v4_do_rcv nf_hook_slow nf_hook_thresh ___napi_schedule __napi_schedule e1000_intr handle_irq do_IRQ common_interrupt interrupt get_rps_cpu sock_queue_rcv_skb ip_queue_rcv_skb __udp_queue_rcv_skb udp_queue_rcv_skb __udp4_lib_rcv ip_local_deliver_finish NF_HOOK ip_defrag ip_rcv_finish NF_HOOK ip_rcv __netif
Hacker School在籍中、ネットワーキングの理解をより深めたいと思い、小規模なTCPスタックを書いてみようと思い立ちました。個人的には、C言語よりもPythonの方になじみがありましたし、その頃ちょうど、パケット送信を 非常に簡単に する scapy ネットワーキングライブラリも見つけたところでした。 そんなわけで、 teeceepee を書き始めました。 基本的な構想は次のとおりです。 TCPパケットを送信可能にするRaw socketを開く google.comを取得するためにHTTP要求を送る 応答を取得しパースする 成功を祝う 適切なエラー処理などについてはさほどの注意も払わず、ただただウェブページを取得し、勝利を宣言しようと思っていました(^_^) ステップ1：TCPハンドシェイク 手始めは、GoogleとのTCPハンドシェイクです（以下は必ずしも正しく動作しませんが、原
ベストセラー書の改訂第2版。前半はWiresharkのリファレンスです。Wiresharkのさまざまな機能や活用テクニックについて解説します。後半はパケット解析の実践的な教科書です。TCP/IPの主要なプロトコルを解析する方法や、ネットワーク遅延をはじめとしたさまざまなトラブルの解決方法を、実際に取得したパケット情報の実例を使って詳しく解説します。日本語版ではTCP/IP以外のパケット解析、具体的にはUSBポートを流れるデータのパケット解析についての解説と、pcap-ng形式 ←→ pcap形式のデータ変換についての解説を巻末付録として追加しました。Wireshark 1.8対応。 目次 監訳者まえがき 賞賛の声 まえがき 1章 パケット解析とネットワークの基礎 1.1 パケット解析とパケットキャプチャツール 1.1.1 パケットキャプチャツールの評価 1.1.2 パケットキャプチャツール
MQTTはトラフィック量はHTTPの1/10になると聞きましたが、実際に計測してみたところそれほどの差がないように見えました。 HTTPが接続・送信・切断を毎回行いますが、MQTTは一度の接続で何度も送信できます。MQTTは接続・切断を除いた送信部分のみで比較されているということでしょうか？ そうだとしても、10倍にはならないような気がしていますが・・・
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
一般論として、全二重の通信プロトコルを実装するにあたっては、いくつか注意すべき点があって、具体的には、到達確認と切断シーケンスについて定めておかないと、送達されたはずのメッセージがロストしていたり、切断タイミングによってエラーが発生*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フレーム
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 – Jxck HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。 GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します. Make the Web Faster: TCP Fast Open 3 Way Handshake TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013 Webをより速くしようと、HTTPよりも優れたプロトコルとして提案されたSPDY（スピーディ）。しかしそのSPDYによって、下位レイヤであるTCPの制限が顕著に見えるようになってしまい、そのことでTCP以外のプロトコルとしてQUICをGoogleが提案しています。 Webの進化は、インターネットのプロトコルにまで影響を与えようとしている、という非常に興味深い話が、HTML5のコミュニティ「html5j」主催のイベント「HTML Conference 2013」で行われた小松健作氏のセッション「最新Webプロトコル、傾向と対策」で行われました。 その内容をダイジェストで紹介しましょう。 最新Webプロトコル、傾向と対策 小松です。所属はNTTコミュニケーションズでHTML5の研究
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
