ジェフ・ヒューストンのブログより。 QUICトランスポート・プロトコル(RFC 9000)は、オリジナルのTCPトランスポート・プロトコルを改良したものに過ぎないという一般的な見解があります[1][2]。私は、この意見に同意し難く、私にとってQUICは、通信のプライバシー、セッション制御の完全性、柔軟性の面で、アプリケーションが利用できるトランスポート機能における重要な変化を象徴しています。QUICは、より多くの形式のアプリケーションの動作に本質的に役立つ、異なる通信モデルを体現しています。そうです。TCPよりも高速です。私の意見では、公衆インターネットは、いずれQUICがTCPに取って代わると思っています。ですから、私にとってQUICは、TCPに少し手を加えただけのものではありません。ここでは、TCPとQUICの両方について説明し、QUICがトランスポート・テーブルに加えた変更について見
3章 Network Namespace - 1 helloworld ip netns コマンドでNetworkNamespaceの作成や操作が可能になる 作成したNetworkNamespace内で独自のネットワークを構築できる $ ip netns add helloworld $ ip netns list helloworld $ ip netns exec helloworld ip addr show 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 $ ip netns delete helloworld # NSを作成 $ ip netns add ns1 $ ip n
2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が
概要 ソケットプログラミングに関するTipsをメモレベルで記載する。 切断検知と経路切断 TCPコネクションの切断検出 対向がclose()、shuttdown()、プログラム終了等をしたときの切断検出について。 OSをシャットダウンさせた場合も通常はアプリケーションの終了処理が走り、正常な切断が動く。 受信側の切断検出は、recv()がlength==0で返ってきたとき、または、errno==ECONNRESETとなる。（ECONNRESETはRSTによって切断された場合） 送信側の切断検出は、切断された後2回目のsend()がエラーとなる。 ※相手がclose()→こちらがsend()→相手にパケットが飛ぶが待ち受けプログラムがいないためRST応答が来る→もう1度send()→エラー ※send()自体はカーネルの送信バッファにデータコピーするだけなので、TCPレベルの応答（送信完了）
現在提案されているTFO（TCP Fast Open）という方式では、Cookieを利用して2回目以降のコネクション確立時に3ウェイハンドシェークを行わない。これにより、コネクション確立にかかる時間を省いて効率化を図る。 通常の3ウェイハンドシェークでは前述のように、（1）クライアント側からの接続要求、（2）その接続要求に対するサーバーの確認応答とサーバー側の接続要求、（3）クライアント側からの確認応答――という方法でコネクションを確立している。そのため、コネクション確立のたびにクライアントとサーバーの間で3回のやり取りが発生してしまう。 TFOでは、Cookieを使って確認応答のやり取りを減らしつつ、接続時の確認を実施する。Cookieとは、クライアントが以前に接続したかどうかサーバーが確認するために使うデータのこと。HTTPでよく使われるが、TFOもそれと同様の使い方をする▼。 最初の
QUIC（Quick UDP Internet Connections）プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 （冗談で） TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastのcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの本当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ （ネットワークパケットの往復） が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 （出典： UDPを介
この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 （訳注：日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 ）を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました（ またPythonでTCPスタックを書いたらどうなるかについても書きました ）。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ
なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。 きっかけは先月帰国したときに sonots がDeNAをはじめとして、Web企業では広く TCP_TIMEWAIT_LEN を変更してカーネルをリコンパイルして使っているという話を聞いたというもの。以下の様な議論を twitterで行い Togetter: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？: http://togetter.com/li/871768 以下のように、スラドに転載されてしまったわけだ。 スラド： Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？： http://linux.srad.jp/story/15/09/09/0648258/ いつものように、スラド民は元のスレッドなんかまるで読んでいないので、結論だけ書く。 tcp_tw_inter
まずは免責事項。 1.Disclaimer 本ブログの記載内容は、筆者が独自に QUIC に関する Chromium のソースを分析し、検証した結果です。 QUICに関するGoogle からの公式な技術資料は現状公開されていません。 今後、QUICの技術仕様の公表で本ブログの記述内容が不十分だったり、誤っている可能性があります。ご理解の上お読みください。 (注： 2013年6月27日に Google は正式に QUIC 仕様を公開しました。「Experimenting with QUIC 」 本ブログの内容は大筋では間違っていませんが、当時の解析漏れやその後の開発等により、細かいところで異なっていたり、説明が大きく不足している部分もあります。お読みになる際はご注意ください。) 2. はじめに、 Googleがまたまた新しいプロトコルの実装を始めました。Web表示の高速化を目指した SPDY
NHN Japan子会社のデータホテルとSkeedは6月12日、グローバル間のデータ転送を高速化させるクラウドサービス「データホテル クラウド コネクト」を発表した。Skeedが独自開発した通信プロトコル「Skeed Silver Bullet Protocol」（SSBP）の採用で、標準プロトコルのTCPと比較して約20～30倍の速度でグローバル間ファイル転送を行えるという。同日からβ提供を開始し、今夏に正式サービスとしてリリースする予定。 データホテル クラウド コネクトは、米国、ブラジル、アイルランド、韓国、オーストラリア、日本の6カ国10カ所に設置されたデータホテルの通信拠点を仮想ネットワークで結び、国をまたいだ2点間の通信スピードを高速化させるというサービス。例えば日本からアイルランド・ダブリンに1Gバイトのデータを送信する場合に、従来のFTP通信で90分かかっていたのを3分に短
ネットワークエンジニアの仕事って？ ネットワークを学びたいけど何から学べばよいか分からない！！ TCP/IPって何？ルーティングって何なのよ？ Ciscoの資格、CCNAを取りたい！！ 当サイトではそんなネットワークエンジニアを目指している方に向けて、ネットワークに関する情報を幅広く紹介し、そんな初心者ネットワークエンジニアのスキルの向上を目指しています。 トラブルにも動じないネットワークスキルを身につけよう！ ネットワークに携わるエンジニア職に就きたいとお考えの学生の方や、ネットワークエンジニアの仕事に興味があって転職を考えているという方など、これからネットワークの技術を身につけていきたいとお考えのネットワークエンジニア予備軍に役に立つ情報を提供していきます。 ネットワークエンジニアのためのネットワークの基礎 イロハを学び始めて間もない方は、まず基礎をしっかり学ぶことから始めましょう。
2024年のトピックス 2024-12-20 Blog記事Internet Week 2024 フォトレポート 2024-12-20 Web更新gTLDの登録数を更新 2024年8月分を追加 2024-12-20 Web更新ccTLDの登録数を更新 2024年10月分を追加 2024-12-18 トピックスAPRICOT 2025参加支援プログラムへのご協賛のお願い 2024-12-18 トピックスAPRICOT 2025 参加支援プログラム応募受付開始のお知らせ ～若手技術者・研究者の国際会議参加費用等を支援します～ 2024-12-17 Web更新第161回理事会資料を公開 2024-12-16 メルマガvol.2127:【定期号】特集：「Internet Week 2024 つなげて、広げて、楽しもう」開催報告 2024-12-16 メルマガvol.2126:【トピックス号】先週のト
Windows XP SP2とWindows Server 2003 SP1のTCP/IPスタックでは、不完全な外向きのTCP同時接続数を10接続に制限しています。接続数が10に達した場合、接続要求はキューイングされ、ある一定間隔で処理されるようになります。 この制限は、ホストがワームに感染した際、他のホストへの影響を最小限にするため、Windows XP SP2とServer 2003 SP1で新たに実装されました。しかしこの制限は、不完全な外向きのTCP接続を大量かつ同時に張るアプリケーションにおいては、大きなパフォーマンス低下を招く可能性があります。例えば、P2Pシステムや脆弱性スキャナなどが挙げられます。特に脆弱性スキャナは業務で利用するケースが多いと思いますので、パフォーマンス低下は非常に致命的です。 これを回避する選択肢の一つとして、TCP同時接続数制限の無いプラットフォームを
WIDE 大学 School of Internet の開講中の授業および過去の授業・講義ライブラリ一覧が掲載されています。自分の研究目標、研究計画に合わせて授業を選択して下さい。 なお、開講中の授業を履修・聴講するためには必ず入学・履修登録をしてください。 現在は実験中のためどなたでも授業をみれるようになっていますが、履修申告をしないと、レポートの提出などはできません。また単位を目的に履修されない方も、アンケートにご協力いただく意味で、入学・履修申告を行っていただきますようお願いいたします。 現在開講中の授業以外については履修登録する必要はありません。参考資料としてご利用ください。
■Pingコマンド それでは、ついにネットワークコマンドの実践について解説していきます。ここで紹介しているネットワークコマンドはいずれもごく基本的なものなのでしっかりと理解しておきましょう。まず、最初にICMPプロトコルを利用したコマンドである「Pingコマンド」について解説します。「Pingコマンド」とはコンピュータ同士の通信確認を行うための最も基本的なネットワークコマンドで、実装形態こそ違えど、ほとんど全てのOSに標準で実装されています。仮に、特定のコンピュータと通信をとりたい場合にこのコマンドを実行することで「ICMPエコー要求」を送出し、その宛先のコンピュータにICMPエコー要求が届いた場合に今度は反対に、「ICMPエコー応答」が返ってきます。その結果として双方間での通信確認が実現できる仕組みになっているのです（参考：「ICMPとは？」）。 ネットワークコマンドに共通することですが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く