ネットワーク ゲームにおけるTCPとUDPの使い分け2017年10月27日、モノビットエンジン勉強会inサイバーコネクトツーにて、中嶋謙互が講演しました「ネットワークゲームにおける TCPとUDPの使い分け」のスライドになります。ネットワークゲームを製作する際にご参考頂けますと幸いです。 登壇者： 株式会社モノビット 取締役 CTO 中嶋謙互Read less
GoogleのQUICプロトコル：TCPからUDPへWebを移行する | POSTD
QUIC（Quick UDP Internet Connections）プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 （冗談で） TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastのcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの本当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ （ネットワークパケットの往復） が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 （出典： UDPを介
Google’s QUIC protocol: moving the web from TCP to UDP
Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached. We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today! The QUIC protocol (Quick UDP Internet
User Datagram Protocol - Wikipedia
User Datagram Protocol（ユーザ データグラム プロトコル、UDP）はIPネットワーク上のアプリケーション間データグラム送信を実現する通信プロトコルである[1]。 UDPはインターネットを始めとしたInternet Protocolネットワーク上で利用される通信プロトコルである[2]。ホスト間通信を担うIP上でアプリケーション間通信を可能にする[3]。通信はデータグラム方式、すなわち到達保証・流量制御・順序制御をせず、データグラムをステートレス・コネクションレスに相手側へと送信する。またブロードキャストとマルチキャストをサポートしている[4]。 デイヴィッド・P・リード（英語版）が1980年に設計し、RFC 768 で定義した（STD番号: 6）。非常にシンプルに設計されており公式仕様のRFC 768はわずか3ページである。インターネット・プロトコル・スイートの観点では
RFC 768: User Datagram Protocol
RFC 768 J. Postel ISI 28 August 1980 User Datagram Protocol ---------------------- Introduction ------------ This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) [1] is used as the underlying protocol. This proto
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
Experimenting with QUIC
$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
Reliable User Datagram Protocol - Wikipedia
Reliable User Datagram Protocol（RUDP）は、Plan 9のためにベル研究所で設計されたトランスポート層のプロトコルである。 保証されたパケット送出をするためには、UDPではあまりに原始的だが、TCPでは、プロトコル上のオーバヘッドが大きすぎる。そこで、RUDPは、UDPに以下のような機能をTCPより少ないオーバーヘッドで拡張したものである。 受信パケットの確認応答 ウィンドーイングとフロー制御 欠損パケットの再送 リアルタイムストリーミングより速いオーバーバッファリング RUDPは現在、正式な規格ではないが、1999年にIETFのインターネットドラフトで記述された。標準化のための提案はされていない。
通信高速化に関する考察 - exception think
自メモ＞ ここらへんの話、異機種間のソケット通信プログラム等を メンテしてたりするわけなんですけど 「Androidが通信遅い＝＞IOS版は安定してるのに＝＞IOS版に悪い評判が立つ」 って論調でなんとかならんかなーと調べてたりしてる状態*1 たしかにIOSだとスムーズに通信 ＝＞Androidだと 通信抜けしたり ディレイしたり な感じは確かに感じるんだよなorz 下手にスレッド使ってるからかもしれない。 自分がメンテしているコードだと Androidは遅い ボタン操作もとりあえず別スレッドに先送りするイメージ ExecutorService Handler な方針だったりする。体感速くしたいという気持ちはわかるんだけどな。。（汗 まずソケット通信プログラムで Android側のクライアント側で頑張る話のメモは SocketChannelが閉じれないことがある話 と 暫定対策 - exc
node.js で UDP な簡易チャット的ななにか | TECH BLOG
ちょっと色々あって、 node.js で UDP 調べてるうちにこんなん出来ました。 node.js 0.10.x 以降が必要かも。 /** * talk.js * chat on udp */ // コレはテキトーに変えて OK var PORT = 22222; // これは指定されてる broadcast address に合わせる var ADDRESS = '192.168.1.255'; var dgram = require('dgram') , ifaces = require('os').networkInterfaces() , omitAddresses = [] , stdin = process.stdin , stdout = process.stdout; // 自分の IP を除外リストに突っ込む Object.keys(ifaces).forEach(f
UDPホールパンチング - Wikipedia
UDPホールパンチングによる NAT traversal とは、NAT を使ったプライベートネットワーク内にあるホスト同士がインターネット経由で双方向のUDPコネクションを確立する手法である。NAT には様々なものがあって動作仕様が標準化されていないため、あらゆる NAT で機能するわけではない。 NATの背後にある各ホストは、典型的には STUN や ICE を用いて通信相手との間に存在するNATの公開アドレスを取得する。この過程では、公開のアドレス空間にある第3の既知のサーバに一旦接続することでUDPポートマッピングと相手方のUDP状態を確立し、以後はパケットが違うホストから来ていても NATデバイスが状態を維持するだろうと期待して、直接的な通信に切り換える。通常、UDP状態は数十秒～数分以内に失効してクローズされてしまうので、UDPホールパンチングでは定期的な keep-alive
UDPホールパンチング、その１
ともあれJavaでちょこっと作ってみました。 https://github.com/taktod/udptest コメントもかかずにパパッとつくっただけなので、わかりにくいと思いますが、次の動作をします。 実行可能jarファイルをserver.jarとclient.jarつくって １：サーバーを立ち上げる。 ２：クライアントを実行するとサーバーに接続し、testという文字列を送信する。(ダミーデータ) ３：サーバーはtestを受け取るとそこから接続してきたユーザーのIPアドレスと利用中のポートを取得してMapにいれて保持しておく。 ４：サーバーから接続中のクライアントには、新しいクライアントの情報を送る。 ５：サーバーから新しいクライアントには、接続中のクライアントの情報を送る。 ６：クライアント情報を受け取ったクライアントはinitという文字列を情報の宛先に送信する。(ダミー) ６の時点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
