タグ

tcpipに関するt_moriのブックマーク (41)

  • TCPとQUICの比較

    ジェフ・ヒューストンのブログより。 QUICトランスポート・プロトコル(RFC 9000)は、オリジナルのTCPトランスポート・プロトコルを改良したものに過ぎないという一般的な見解があります[1][2]。私は、この意見に同意し難く、私にとってQUICは、通信のプライバシー、セッション制御の完全性、柔軟性の面で、アプリケーションが利用できるトランスポート機能における重要な変化を象徴しています。QUICは、より多くの形式のアプリケーションの動作に質的に役立つ、異なる通信モデルを体現しています。そうです。TCPよりも高速です。私の意見では、公衆インターネットは、いずれQUICがTCPに取って代わると思っています。ですから、私にとってQUICは、TCPに少し手を加えただけのものではありません。ここでは、TCPとQUICの両方について説明し、QUICがトランスポート・テーブルに加えた変更について見

    TCPとQUICの比較
    t_mori
    t_mori 2022/11/14
  • メモ: 『Linuxで動かしながら学ぶTCP/IPネットワーク入門』

    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

    メモ: 『Linuxで動かしながら学ぶTCP/IPネットワーク入門』
    t_mori
    t_mori 2022/07/14
  • 40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog

    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が

    40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
    t_mori
    t_mori 2022/04/12
  • ソケットプログラミングのTips

    概要 ソケットプログラミングに関するTipsをメモレベルで記載する。 切断検知と経路切断 TCPコネクションの切断検出 対向がclose()、shuttdown()、プログラム終了等をしたときの切断検出について。 OSをシャットダウンさせた場合も通常はアプリケーションの終了処理が走り、正常な切断が動く。 受信側の切断検出は、recv()がlength==0で返ってきたとき、または、errno==ECONNRESETとなる。(ECONNRESETはRSTによって切断された場合) 送信側の切断検出は、切断された後2回目のsend()がエラーとなる。 ※相手がclose()→こちらがsend()→相手にパケットが飛ぶが待ち受けプログラムがいないためRST応答が来る→もう1度send()→エラー ※send()自体はカーネルの送信バッファにデータコピーするだけなので、TCPレベルの応答(送信完了)

    ソケットプログラミングのTips
  • GoogleはTCPをCookieで高速化

    現在提案されているTFO(TCP Fast Open)という方式では、Cookieを利用して2回目以降のコネクション確立時に3ウェイハンドシェークを行わない。これにより、コネクション確立にかかる時間を省いて効率化を図る。 通常の3ウェイハンドシェークでは前述のように、(1)クライアント側からの接続要求、(2)その接続要求に対するサーバーの確認応答とサーバー側の接続要求、(3)クライアント側からの確認応答――という方法でコネクションを確立している。そのため、コネクション確立のたびにクライアントとサーバーの間で3回のやり取りが発生してしまう。 TFOでは、Cookieを使って確認応答のやり取りを減らしつつ、接続時の確認を実施する。Cookieとは、クライアントが以前に接続したかどうかサーバーが確認するために使うデータのこと。HTTPでよく使われるが、TFOもそれと同様の使い方をする▼。 最初の

    GoogleはTCPをCookieで高速化
    t_mori
    t_mori 2017/04/15
  • GoogleのQUICプロトコル:TCPからUDPへWebを移行する | POSTD

    QUIC(Quick UDP Internet Connections)プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 (冗談で) TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ (ネットワークパケットの往復) が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 (出典: UDPを介

    GoogleのQUICプロトコル:TCPからUDPへWebを移行する | POSTD
    t_mori
    t_mori 2016/08/27
  • TCPを(少しは)理解しておくべきその理由 | POSTD

    この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 (訳注:日語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 )を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました( またPythonでTCPスタックを書いたらどうなるかについても書きました )。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ

    TCPを(少しは)理解しておくべきその理由 | POSTD
    t_mori
    t_mori 2015/12/30
  • 革命の日々! Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味? の件について

    なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。 きっかけは先月帰国したときに 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

    革命の日々! Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味? の件について
    t_mori
    t_mori 2015/09/11
  • Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記

    まずは免責事項。 1.Disclaimer ブログの記載内容は、筆者が独自に QUIC に関する Chromium のソースを分析し、検証した結果です。 QUICに関するGoogle からの公式な技術資料は現状公開されていません。 今後、QUICの技術仕様の公表でブログの記述内容が不十分だったり、誤っている可能性があります。ご理解の上お読みください。 (注: 2013年6月27日に Google は正式に QUIC 仕様を公開しました。「Experimenting with QUIC 」 ブログの内容は大筋では間違っていませんが、当時の解析漏れやその後の開発等により、細かいところで異なっていたり、説明が大きく不足している部分もあります。お読みになる際はご注意ください。) 2. はじめに、 Googleがまたまた新しいプロトコルの実装を始めました。Web表示の高速化を目指した SPDY

    Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記
    t_mori
    t_mori 2013/02/28
  • 富士通研究所、ソフトウェアだけで通信性能を大幅に改善する新技術 

    t_mori
    t_mori 2013/01/29
  • ファイルをTCPの30倍で転送――独自プロトコルによる高速通信「クラウド コネクト」

    TCPと比較して約20~30倍の速度でグローバル間ファイル転送を行えるという高速通信サービス「クラウド コネクト」をデータホテルが開始。「Winny」開発者の金子勇氏が設立したSkeedが共同開発した。 NHN Japan子会社のデータホテルとSkeedは6月12日、グローバル間のデータ転送を高速化させるクラウドサービス「データホテル クラウド コネクト」を発表した。Skeedが独自開発した通信プロトコル「Skeed Silver Bullet Protocol」(SSBP)の採用で、標準プロトコルのTCPと比較して約20~30倍の速度でグローバル間ファイル転送を行えるという。同日からβ提供を開始し、今夏に正式サービスとしてリリースする予定。 データホテル クラウド コネクトは、米国、ブラジル、アイルランド、韓国、オーストラリア、日の6カ国10カ所に設置されたデータホテルの通信拠点を仮想

    ファイルをTCPの30倍で転送――独自プロトコルによる高速通信「クラウド コネクト」
    t_mori
    t_mori 2012/06/12
  • プロセスが行う外部との通信を一覧表示できるネットワーク監視ソフト「TCPEye」NOT SUPPORTED

  • IT news, careers, business technology, reviews

    Tech spending shifts to meet AI demand, forces a 'reshuffling of skills' for workers

    IT news, careers, business technology, reviews
  • Amazon.co.jp: Linuxネットワークプログラミングバイブル: 光之,小俣, 元樹,種田: 本

    Amazon.co.jp: Linuxネットワークプログラミングバイブル: 光之,小俣, 元樹,種田: 本
  • ネットワークエンジニアを目指して -ネットワーク技術の解説とネットワーク関連書籍の紹介-

    ネットワークエンジニア仕事って? ネットワークを学びたいけど何から学べばよいか分からない!! TCP/IPって何?ルーティングって何なのよ? Ciscoの資格、CCNAを取りたい!! 当サイトではそんなネットワークエンジニアを目指している方に向けて、ネットワークに関する情報を幅広く紹介し、そんな初心者ネットワークエンジニアのスキルの向上を目指しています。 トラブルにも動じないネットワークスキルを身につけよう! ネットワークに携わるエンジニア職に就きたいとお考えの学生の方や、ネットワークエンジニア仕事に興味があって転職を考えているという方など、これからネットワークの技術を身につけていきたいとお考えのネットワークエンジニア予備軍に役に立つ情報を提供していきます。 ネットワークエンジニアのためのネットワークの基礎 イロハを学び始めて間もない方は、まず基礎をしっかり学ぶことから始めましょう。

  • 日本ネットワークインフォメーションセンター - JPNIC

    2024年のトピックス 2024-07-04 インターネットガバナンス トピックスIGF 2023に向けた国内IGF活動活発化チーム第51回会合開催のご案内 2024-07-02 Web更新ICANN通常理事会(2024年6月8日開催)決議概要を掲載 2024-07-02 Blog記事JANOG54 ブース出展とBoF開催のお知らせ 2024-07-01 トピックスJPNICトークラウンジ第16回ライブ配信「クロサカタツヤさんに聞く、インターネットに『自律と尊厳』は必要ですか?」及び第15回アーカイブ公開のご案内 2024-07-01 トピックスJANOG54ミーティングでJPNICがブースを出展します ~ 電子証明書を使わないポータルサイト「レジ・ポータル」展示! ~ 2024-07-01 メルマガvol.2087:【臨時号】第69回ICANN報告会レポート 2024-07-01 トピッ

  • Windows XP/2003のTCP同時接続数制限とその回避:鵜飼裕司のSecurity from KAGURAZAKA:ITpro

    Windows XP SP2とWindows Server 2003 SP1のTCP/IPスタックでは、不完全な外向きのTCP同時接続数を10接続に制限しています。接続数が10に達した場合、接続要求はキューイングされ、ある一定間隔で処理されるようになります。 この制限は、ホストがワームに感染した際、他のホストへの影響を最小限にするため、Windows XP SP2とServer 2003 SP1で新たに実装されました。しかしこの制限は、不完全な外向きのTCP接続を大量かつ同時に張るアプリケーションにおいては、大きなパフォーマンス低下を招く可能性があります。例えば、P2Pシステムや脆弱性スキャナなどが挙げられます。特に脆弱性スキャナは業務で利用するケースが多いと思いますので、パフォーマンス低下は非常に致命的です。 これを回避する選択肢の一つとして、TCP同時接続数制限の無いプラットフォームを

    Windows XP/2003のTCP同時接続数制限とその回避:鵜飼裕司のSecurity from KAGURAZAKA:ITpro
  • ネットワーク入門 PartⅠ | 演習で学ぶネットワーク

    サイトに掲載されている文章、イラスト、ロゴ、写真、動画、演習ファイル、その他のすべての情報は、サイトまたは第三者が著作権を有しております。サイトの内容を研修等で利用する場合は、インストラクターと受講者がサイトにアクセスして閲覧するようお願い致します。 サイト、および関連ページの情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。細心の注意を払ってサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。予告なしに、サイトに掲載されている情報を変更することがあります。

    ネットワーク入門 PartⅠ | 演習で学ぶネットワーク
  • SOI 講義案内

    WIDE 大学 School of Internet の開講中の授業および過去の授業・講義ライブラリ一覧が掲載されています。自分の研究目標、研究計画に合わせて授業を選択して下さい。 なお、開講中の授業を履修・聴講するためには必ず入学・履修登録をしてください。 現在は実験中のためどなたでも授業をみれるようになっていますが、履修申告をしないと、レポートの提出などはできません。また単位を目的に履修されない方も、アンケートにご協力いただく意味で、入学・履修申告を行っていただきますようお願いいたします。 現在開講中の授業以外については履修登録する必要はありません。参考資料としてご利用ください。

  • PINGコマンド/MTU値の調整

    ■Pingコマンド それでは、ついにネットワークコマンドの実践について解説していきます。ここで紹介しているネットワークコマンドはいずれもごく基的なものなのでしっかりと理解しておきましょう。まず、最初にICMPプロトコルを利用したコマンドである「Pingコマンド」について解説します。「Pingコマンド」とはコンピュータ同士の通信確認を行うための最も基的なネットワークコマンドで、実装形態こそ違えど、ほとんど全てのOSに標準で実装されています。仮に、特定のコンピュータと通信をとりたい場合にこのコマンドを実行することで「ICMPエコー要求」を送出し、その宛先のコンピュータにICMPエコー要求が届いた場合に今度は反対に、「ICMPエコー応答」が返ってきます。その結果として双方間での通信確認が実現できる仕組みになっているのです(参考:「ICMPとは?」)。 ネットワークコマンドに共通することですが