ネットワーク ゲームにおけるTCPとUDPの使い分け2017年10月27日、モノビットエンジン勉強会inサイバーコネクトツーにて、中嶋謙互が講演しました「ネットワークゲームにおける TCPとUDPの使い分け」のスライドになります。ネットワークゲームを製作する際にご参考頂けますと幸いです。 登壇者： 株式会社モノビット 取締役 CTO 中嶋謙互Read less
How web bloat impacts users with slow connections
A couple years ago, I took a road trip from Wisconsin to Washington and mostly stayed in rural hotels on the way. I expected the internet in rural areas too sparse to have cable internet to be slow, but I was still surprised that a large fraction of the web was inaccessible. Some blogs with lightweight styling were readable, as were pages by academics who hadn’t updated the styling on their websit
楽しい！ 欲しい！ やっと出た！ ネットワークエンジニアから見た「ウイルスバスター for Home Network」 - はてなニュース
トレンドマイクロが発表した「ウイルスバスター for Home Network」は、ルーターに挿し、管理用のスマホにアプリを入れるだけで“家族を守る”という、ちょっと変わった、そして現実的な解だ。ホームネットワーク内の機器を毎日スキャンし、簡易なパスワードがあれば管理者に連絡する。さらに、パケットのアプリケーション層までチェックするDPI（ディープ・パケット・インスペクション）機能に、ホームネットワークのWebレピュテーション機能。企業の話ではなく、これを「自宅」で実現するデバイスが登場したのだ。 今回、新たな守り方を1つのデバイスで実現したトレンドマイクロの開発者と、はてなのネットワークを管理して守ってきたエンジニアがざっくばらんにその思いを語った。「ウイルスバスター for Home Network」はあえて技術面の詳細を隠し、シンプルさを売りとして掲げる製品だが、エンジニアとしての視
ネットワークでなぜ遅延が生じるのか
5. プロセス遅延 (Processing Delay) パケット 出⼒先決定 ヘッダ書き換え フィルタリング QoS 統計情報取得 カプセル化 筐体内転送 • 伝送装置 • メディアコンバータ • スイッチ • ルータ • NAT装置 • 仮想化装置, IPsec, etc • 通信機器の⼊⼒インターフェイスで受信して 出⼒インターフェイスのキューへ送るまでにかかる時間 出⼒ キュー パケット ルータの例 暗号化 6. キューイング遅延 (Queueing Delay) • 通信機器の出⼒インターフェイスキューに⼊ってから 出⼒処理を⾏なうまでにかかる時間 出⼒キュー • 出⼒処理より速いペースでパケットが届くとキュー待ちが増える • 広帯域回線から狭帯域回線への転送、⼀時的な輻輳 (バーストト ラフィック) などへの対応 優先制御 キューイング スケジューリング 7. シリアル化遅延
第1章 会場でネットがつながりにくくなる理由―参加者自身の行動も原因の一端に！ | gihyo.jp
IT系のカンファレンスに足を運んだことがある方であれば、その会場でインターネットへの接続をしたことがあるでしょう。もし会場で無線LAN接続が提供されていたら、ぜひそれを利用してください。自前のWi-Fiルータやスマホのテザリングで十分？ いえいえ、それこそがネットにつながりにくくなる原因かもしれないのです。 カンファレンスネットワークとは 昨今はITに関連した勉強会がたくさん開催されるようになりました。勉強会の多くは参加者が数十～100名程度ですが、人気のあるものは大きなイベント会場を1日～数日間使用するITイベントとして開催されます。たとえばYAPCやLL Diverなどの言語系やWeb開発者が多数参加するカンファレンスの場合、その参加者は数百～1,000人以上になることがあります。カンファレンス参加者はセッションに参加しながら、手元のPCやスマートフォンなどからSNSや調べものをするた
LinuxのARPとL2スイッチのお話 - masayoshiの日記
この記事は、はてなエンジニアアドベントカレンダー2016の12月19日の記事です。 developer.hatenastaff.com 昨日はid:taketo957くんの 10ms以下のレスポンスタイムを支える継続的負荷テスト - taketo957の日記 でした！ Webオペレーションエンジニアのid:masayoshiです。 2016年に入社後、基盤チームとして仮想化、ネットワーク周りを中心に見ています。 さて、この記事ではLinuxのARPの挙動とその挙動から起こった問題を紹介しようと思います。 長々と記事を読みたくない人向けに結論をまとめるとLinuxのARPはTCP通信で使われ続ける限りキャッシュが飛ばないという挙動になるので、複数のL2スイッチにまたがったセグメントや非対称ルーティングをしている場合は気をつけましょうという話が書かれています。 今回紹介する事例自体は別に新規性
Linuxカーネルの新機能 XDP (eXpress Data Path) を触ってみる - yunazuno.log
先日netdev 1.2に参加してみたところ，XDP(eXpress Data Path)の話題で持ち切りといった感じだった． というわけで，XDPについて一通り調べつつ，実際に触ってみた． XDPとは何か？ 誤解を恐れずに一言で言うと，「Intel DPDKのような高速パケット処理基盤をLinuxカーネル自身が用意したもの」であると理解している．このスライドでは A programmable, high performance, specialized application, packet processor in the Linux networking data path と言っている． DPDKはユーザランドアプリケーションがNICを直接叩く(=カーネルのネットワークスタックをバイパスする)ことで高速処理を実現している．一方XDPは，カーネル内の最もNICドライバに近い場所でフッ
Linux Networking Explained
Linux offers an extensive selection of programmable and configurable networking components from traditional bridges, encryption, to container optimized layer 2/3 devices, link aggregation, tunneling, several classification and filtering languages all the way up to full SDN components. This talk will provide an overview of many Linux networking components covering the Linux bridge, IPVLAN, MACVLAN,
「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版 | blog.jxck.io
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく
Programming TCP for responsiveness
The document discusses optimizations to TCP and HTTP/2 to improve responsiveness on the web. It describes how TCP slow start works and the delays introduced in standard HTTP/2 usage from TCP/TLS handshakes. The author proposes adjusting the TCP send buffer polling threshold to allow switching between responses more quickly based on TCP congestion window state. Benchmark results show this can reduc
みんな大好き、dig コマンドの使い方(dnsを調べるあれこれ - それマグで！
みんな dig ってますか？ http でファイルが開けない時、真っ先に見るべきは iptable でも、ifconfig でもなくて dig です。 まず、dig を確認するよね。 dig の使い方 dig は名前解決を試みるコマンドです。 名前解決とは何か、、DNSの仕組みについては触れません。コマンドを使っていけばわかると思うし。 dig で 名前解決する dig t.co ドメインから、IPアドレスを探す。 dig で逆引きする。 dig -x 8.8.8.8 逆引きすると、IPアドレスからそのIPの持ち主がだいたい分かることが多い MXレコードを指定する dig yahoo.co.jp mx ns レコードを探す dig yahoo.co.jp ns txt レコードを探す dig yahoo.co.jp txt 表示をシンプルにする 結果だけ欲しい時に使う、プログラムと組わせて
Google、最新海底ケーブル「FASTER」を計画中の東京リージョンに接続。Google Cloud PlatformやGoogle Appsで活用すると明らかに
Google、最新海底ケーブル「FASTER」を計画中の東京リージョンに接続。Google Cloud PlatformやGoogle Appsで活用すると明らかに 6月30日に稼働を開始したばかりの、太平洋を横断して日米間をつなぐ最新の海底ケーブル「FASTER」はトータルで毎秒60テラビットもの帯域を実現し、三重県と千葉県の2カ所で国内ネットワークと接続することで災害などによる障害に対する冗長化も果たしています。 このFASTERはGoogle、KDDI、Singtel、中国移動、中国電信など6社のコンソーシアムによるもので、Googleは6分の1である毎秒10テラビットを利用可能。 Googleはこの新しい帯域を、Google AppsとGoogle Cloud Platformのユーザーをサポートするために利用すると、ブログ「Google Cloud Platform Blog:
tc コマンドでネットワーク遅延やパケットロスを疑似的に発生させるメモ - ようへいの日々精進XP
ども、初老丸です。 tl;dr Linux において tc コマンド（Traffic Control）使ってネットワーク遅延やパケットロスを疑似的に発生させることが出来るとのこと。今まで tc コマンドの存在すら知らなかったペーペーで恐縮だが、参考サイトをまねて遅延やパケットロスを発生させてみたい。 メモ 参考 http://linux-biyori.sakura.ne.jp/setting/st_netem.php http://labs.gree.jp/blog/2014/10/11266/ man tc 以下の環境で試す。 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS" ひとまず
User-space Network Processing
This document discusses optimizations for TCP/IP networking performance on multicore systems. It describes several inefficiencies in the Linux kernel TCP/IP stack related to shared resources between cores, broken data locality, and per-packet processing overhead. It then introduces mTCP, a user-level TCP/IP stack that addresses these issues through a thread model with pairwise threading, batch pac
『ネットワーク初心者の新卒がDockerでネットワークの勉強をしてみた』
こんにちは！サイバーエジェント アドテクスタジオ新卒の黒崎 (@kuro_m88) と申します。 Dynalystというチームに配属され、一人前のサーバサイドエンジニアになるべく修行をしています(｀・ω・´)最近はScalaを書くことが多くて、Sparkで大量のログを集計するバッチの開発をしています。ほぼ100%AWSで構成されているプロダクトなので業務でネットワークの運用もしませんし、構成の事を意識する事はあまりありません。 そんな中でネットワークの事が知りたくなったのは、広告の配信に関わる開発をしてみて、広告の配信の仕組み自体も技術的にめちゃくちゃ面白いんですが、それと同時に自分たちのサーバから広告が表示される端末までの間がどうなってるのか気になってしまったのがきっかけです。学んでいくにはやはり手を動かすのが一番ですよねo(((^^)))o
EthernetやCPUなどの話 | GREE Engineering
こんにちわ。せじまです。今年に入ってからアクティビティトラッカーを二回壊しまして、新しい分野の製品って設計いろいろ難しいんだなと、しみじみ思う今日このごろです。 先日、社内勉強会で Ethernet や CPU などの話をしました。前回のCPUに関する話に続き、今回のスライドも幅広い方に読んでいただけそうな内容かと思いましたので、公開させていただくことにしました。前回のスライドを読んでない方は、できればそちらを読んでいただいてからの方が、より理解が深まるのではないかと思います。 忙しい人のために三行でまとめると 2020年代には、サーバのネットワークインターフェースが 40Gbps 超えてそうな予感 もし Ethernet でそれだけ大量のパケットをさばくなら、（標準化されてないけれど） Jumbo Frame 使わないと厳しいかも 2020年代には、NICやブロックデバイス等、CPUを取
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DMM inside
GitHub - GoogleChromeLabs/cronet-sample: A sample for the Cronet library
Nmapの真実
公衆無線LANのセキュリティ問題
