並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 213件

新着順 人気順

TCPの検索結果41 - 80 件 / 213件

  • iptablesの後に来るものは何か?: nftables - 赤帽エンジニアブログ

    この記事はRed Hat DeveloperのWhat comes after ‘iptables’? Its successor, of course: nftablesを、許可をうけて翻訳したものです。 ::: By Florian Westphal October 28, 2016 ::: パフォーマンス: ユーザビリティ: nftablesとは何ですか? 何が置き換えられますか? なぜiptablesを置き換えるのか? nftablesでの高水準な機能 判断マップ(ジャンプテーブル) flow文 inetファミリー はじめる チェーンの追加 NAT 既知の制限 関連記事 nftablesは、既存のiptables、ip6tables、arptables、ebtablesを置き換えることを目指した、新たなパケット分類フレームワークです。これは、長く使われてきた ip/ip6table

      iptablesの後に来るものは何か?: nftables - 赤帽エンジニアブログ
    • 「Linuxで動かしながら学ぶTCP/IPネットワーク入門」という本を書きました - CUBE SUGAR CONTAINER

      表題のとおり TCP/IP に関する本を書きました。 今回は、そのご紹介です! Linuxで動かしながら学ぶTCP/IPネットワーク入門 作者:もみじあめAmazon どんな本なの? Linux を使って実際にネットワークを組んで動かしながら TCP/IP について学べる本です。 実際に手を動かすことで、より実践的で風化しにくい知識と技術を身につけることが本の目的です。 こんな人にオススメ 次のいずれかに当てはまるような方には、この本が参考になると思います。 ネットワークが専門ではない IT エンジニア、またはそれを志す学生さん 他の TCP/IP に関する本を読んだことはあるけど、身についている実感が少ない インターネットやインフラの技術についてよく知らないけど興味はある ネットワークを気軽に組んで実験できる環境の作り方に興味がある そして、この本を読んで試した後には、次のような効果が見

        「Linuxで動かしながら学ぶTCP/IPネットワーク入門」という本を書きました - CUBE SUGAR CONTAINER
      • golangで作るTCPIPプロトコル

        はじめに とりあえずIT業界に入ったら読んでおけという名著はいろいろありますが、その中の1冊がマスタリングTCP/IP入門編でしょう。 僕も買ってはいたものの読むのを途中で挫折していたので、今回しっかり読んでTCP/IPを再勉強してみたいと思います。 マスタリングTCP/IPを読みながらその他わからんことはググりつつ、golangでTCPIPプロトコルそのものを自作してみます。 方針は以下のようにします。 ethernetから作る データのやり取りにnetパッケージは一切使わない (訂正、PCのIPやMacアドレスを取るのにだけ使用しますた) データのやり取りに使うのはsyscallのsendtoとrecvfromだけ socketはRAW_SOCKETを使う golangやネットワークについても初心者の駆け出しですので間違えや実装ミス、変なコードがあるかもですが、生暖かい目でよろしゅうお

          golangで作るTCPIPプロトコル
        • HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか? 現代のプロトコル設計とインターネットの課題|ハイクラス転職・求人情報サイト AMBI(アンビ)

          ハイクラス求人TOPIT記事一覧HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか? 現代のプロトコル設計とインターネットの課題 HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか? 現代のプロトコル設計とインターネットの課題 IETFで標準化が進められているWebの新しい通信プロトコルQUICとHTTP/3について、現在のインターネットが抱える課題やプロトコル設計での議論を中心に、ASnoKaze blogの後藤ゆき(@flano_yuki)さんに執筆いただきました。 2021年、Webに新しい通信プロトコルが登場しました。RFC 9000として標準化されたQUICと、その上で動作するHTTP/3です。HTTP/3はまだドラフト版ですが出版準備段階となっており、すでに実際のWeb通信でも広く使われています この2つのプロトコルは、現在のWebやイン

            HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか? 現代のプロトコル設計とインターネットの課題|ハイクラス転職・求人情報サイト AMBI(アンビ)
          • 実務で役立つTCPクライアントの作り方

            Go Conference 2021 Spring (A9-S) のセッションで使用した資料です。 - セッションの詳細: https://gocon.jp/sessions/session-a9-s/ - 発表者: https://twitter.com/d_tutuz 資料に誤りがあればtwitterでご連絡ください。

              実務で役立つTCPクライアントの作り方
            • NLB + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象を解消した話 - Repro Tech Blog

              Repro インフラチーム (SRE + 分析基盤) の伊豆です。今回は、Repro のデータ収集基盤で私たちが遭遇した問題を紹介したいと思います。 具体的には、AWS Network Load Balancer(NLB) + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象に遭遇したので、その問題の調査記録と解決策を共有します。また、この問題を解消するにあたり Fluentd に PR を送ったのでそれの紹介もします。 https://github.com/fluent/fluentd/pull/2352 データ収集基盤の構成 Repro のデータ収集基盤はFlunetd High Availability Configをもとに構成され、大まかに次のようになっています。 SDK からアップロードされたデータは、転送用 Fluentd(log forwarders)を経由し

                NLB + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象を解消した話 - Repro Tech Blog
              • Go言語で実装するプラグイン機構

                ソフトウェアに拡張性を持たせる時にプラグイン機構を持たせる事は一般的ですが、それを実現する方法は結構バラバラなのかなと思います。例えば、 C言語等の.so/.dllを読み込む方法 Nodejsのような言語での単なるimport TCPやUnixソケットを利用してRPC通信を行う方法 などが有るのかなと思います。1番目・2番目は、関数の呼び出し速度等のオーバーヘッドが少なく高速ですが、言語等の制約が大きくなる・メモリを共有することによるセキュリティリスクが発生します。そこで、提供するインターフェースを制約出来る場合は、3番目の手法が多く使われるようです。 Go言語で開発されている、hashicorp/terraform cloudfoundry/cli は共に3番目のRPC通信でプラグイン機構を実装しています。その中でもterraformで使用されているプラグイン機構は、言語への依存が低いと

                  Go言語で実装するプラグイン機構
                • https://twitter.com/s5ml/status/1625061820422840321

                    https://twitter.com/s5ml/status/1625061820422840321
                  • ブラウザからTCP, UDPソケットを操作するDirect Sockets API - ASnoKaze blog

                    2020/01/14: 実際に動くのを確認しました asnokaze.hatenablog.com (2020/09/17 注釈: Raw SocketsからDirect Socketsに名称が変更されました) ブラウザでTCP, DUPソケットを操作可能にする「Direct Sockets API」という仕様がW3CのWICGで議論されている。 また、blink-devでも「Intent to Prototype: Raw Sockets API」とプロトタイプの議論が行われている。 多くの方がセキュリティ上の懸念を抱くと思うが、ドキュメントでも慎重に検討すると書かれている。GithubでIssueを立てることも可能なので、思うことがある方は、まだまだ議論は始まったばかりでもあるので是非フィードバックされると良いと思う。(割と普通に聞いてもらえます) なお、Raw Socketsという名

                      ブラウザからTCP, UDPソケットを操作するDirect Sockets API - ASnoKaze blog
                    • Oracle Cloudの無料枠でKubernetesクラスタを構築する(完全版) - blog.potproject.net

                      前回の記事はこちらです。この記事は前回の記事のリマスターみたいなものとなっております。 読む必要はありませんが、この記事よりも詳しく用語の説明をしている部分もあるため、読んだ方が問題が解消できるかもしれません。 Oracle Cloudの無料枠だけでKubernetes(k3s)クラスタを構築する この記事にて、Kubernetesクラスタを作成してから1年と半年ほど・・・ 1年くらいはノーメンテで動作していることを確認していました。 しかし・・・1年を超えたくらいで動作しなくなってしまいまして、やはりスペック に関しては非常に厳しいものがあったようです。 kubectl打ってタイムアウトになってしまうこともしばしばあり、当然ながら実用的にアプリケーションを動作させるのは無理だな、ということでそのまま放置しちゃっていました。 そして時が過ぎて、いきなりすごいニュースが自分のTLに流れてきま

                        Oracle Cloudの無料枠でKubernetesクラスタを構築する(完全版) - blog.potproject.net
                      • インフラエンジニアなら気になるQUICのロードバランサ (方式編)

                        図1: QUICコネクションを振り分けるロードバランサはじめに本記事では、バックエンドのWebサーバへリクエストを振り分ける装置の意味でのロードバランサ(図1)について、QUIC対応の議論状況を紹介します。方式編と実装編にわけて二編を予定しており、本稿は方式についての解説です。 IETFでは、F5 Networksとマイクロソフトから提案されたロードバランシング方式が議論されています。本稿では下記のインターネットドラフトをQUIC-LBと表記します。 QUIC-LB: Generating Routable QUIC Connection IDs https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers 執筆時点の -07 をベースとしますが、ドラフトですので今後の議論次第で改版が続きます。あらかじめご承知おき

                          インフラエンジニアなら気になるQUICのロードバランサ (方式編)
                        • 堅牢なTCPサーバを作るために - katsubushiの知見から/kamakura.go#5

                          kamakura.go #5

                            堅牢なTCPサーバを作るために - katsubushiの知見から/kamakura.go#5
                          • HTTP/3: the past, the present, and the future

                            HTTP/3: the past, the present, and the future Loading... This post is also available in 简体中文, 日本語, 한국어, Français, Español. During last year’s Birthday Week we announced preliminary support for QUIC and HTTP/3 (or “HTTP over QUIC” as it was known back then), the new standard for the web, enabling faster, more reliable, and more secure connections to web endpoints like websites and APIs. We also let

                              HTTP/3: the past, the present, and the future
                            • https://tech.pepabo.com/2020/06/26/kernel-dive-tcp_mem/

                                https://tech.pepabo.com/2020/06/26/kernel-dive-tcp_mem/
                              • QUICはTCPの代替ではない

                                ブルース・デイヴィーのブログより。 TCPの新しい決定的な仕様(RFC 9293)の公開は、私たちの世界ではとても大きな出来事で、このトピックに関する2回目の投稿をせずにはいられませんでした。特に、QUICとTCPを比較した議論に興味をそそられ、今週のニュースレターを書くきっかけとなりました。 TCPの過去と未来に関する前回の投稿では、QUICがTCPを置き換え始めるかも知れないという可能性について触れました。今週は、QUICは実際にはTCPが解決する問題とは異なる問題を解決しているので、TCPの置き換えとは別のものとして見るべきであると主張したいと思います。一部の(あるいはほとんどの)アプリケーションでは、QUICがデフォルトのトランスポートになるかも知れませんが、それはTCPが本来意図されていなかった役割に押しやられたからだと思います。なぜ私がそのような主張をするのか、一歩下がって考え

                                • HTTP/3が正式に勧告、脱TCP時代の幕開けか

                                  インターネット関連技術の標準化を手掛けるIETF(Internet Engineering Task Force)は2022年6月6日(米国時間)、通信プロトコル「HTTP/3(HyperText Transport Protocol/3)」を「RFC 9114」として勧告した。HTTP/3はインターネット通信の多くを占めるWebにおける通信プロトコルの最新版である。 最大の特徴は、トランスポートのプロトコルに「QUIC(Quick UDP Internet Connections)」を採用した点。QUICは2021年にIETFで「RFC 9000」として勧告された。その名前が示すように、TCP(Transmission Control Protocol)ではなく、UDP(User Datagram Protocol)に基づくプロトコルだ。TCPが備えていた再送制御の仕組みや、TLS(Tr

                                    HTTP/3が正式に勧告、脱TCP時代の幕開けか
                                  • 「Rustで始めるネットワークプログラミング」を出版しました。 - 電気ひつじ牧場

                                    書籍をkindleとBOOTHで販売開始したので、内容の紹介と出版について書き連ねていきます。 内容紹介 出版したもの サンプル 対象読者について 各章について 1章「ようこそソケット通信の世界へ」 2章「通信を監視する」 3章「手づくりパケットでポートスキャン」 4章「ノンブロッキングなWEBサーバ」 5章「RFCから作るDHCPサーバ」 執筆あれこれ 執筆期間について 執筆ツールについて 表紙について 価格について プラットフォームについて 終わりに 内容紹介 出版したもの 「Rustで始めるネットワークプログラミング」をkindle(https://t.co/Mf98l0YgKS)とBOOTH(https://t.co/ilHIt1UEbi)で販売開始しました。 全101ページ/5章構成で、価格は¥500です。無料サンプル(https://t.co/NilMo1QAhL)もあります。

                                      「Rustで始めるネットワークプログラミング」を出版しました。 - 電気ひつじ牧場
                                    • 図解!ネットワークの7層を実務に当てはめてみた - Qiita

                                      ランサーズ Advent Calendar 2019 19日目担当の@manamin0521mです! サーバーサイド力を上げていくぞ💪という機運なのと、ネットワークがわからなくて詰んだことが立て続けにあったので、最近はマスタリングTCP/IP 入門編 第5版を読んでいます。そこで今回はこちらの本を読んで学んだネットワークについて紹介します。 ネットワークの勉強をする上で躓くのは以下の3点ではないでしょうか? ①知識がどう役立つのかよくわからない ②何に使われているのかわからない ③用語が難しくて覚えるのが大変 そこで今回の記事ではそれらのギャップを埋められればと思います。初学者の方対象です。 ネットワークの知識がなくて困ったとき ・AWSの構成図がいまいち読めない ・ポートとIPアドレスの違いがいまいち説明できない ・IPアドレスを固有のものだと思いこんでいて認識がズレる ・雰囲気でdo

                                        図解!ネットワークの7層を実務に当てはめてみた - Qiita
                                      • HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(後編)

                                        HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(後編) Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。(本記事は「HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(前編)」の続きです) サーバプッシュの

                                          HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(後編)
                                        • When TCP sockets refuse to die — Idea of the day

                                          This article was first published on Cloudflare blog: When TCP sockets refuse to die Accompanying scripts While working on our Spectrum server, we noticed something weird: the TCP sockets which we thought should have been closed were lingering around. We realized we don't really understand when TCP sockets are supposed to time out! In our code, we wanted to make sure we don't hold connections to de

                                          • HttpClientをusingで囲わないでください - Qiita

                                            using (var client = new HttpClient()) { var response = await client.GetAsync(url); .... } これは間違いです。HttpClientオブジェクトは dispose してはいけません! Stackoverflowにも沢山この間違いがあります。 (追記: 正確に言うとdisposeしてはいけないわけではなく、生成と破壊を繰り返すのが誤りです) 正しい使い方はAPIの公式ドキュメントに書いてある通りです。 public class GoodController : ApiController { private static readonly HttpClient HttpClient; static GoodController() { HttpClient = new HttpClient(); } } 上

                                              HttpClientをusingで囲わないでください - Qiita
                                            • GitHub - mehrdadrad/tcpprobe: Modern TCP tool and service for network performance observability.

                                              You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                GitHub - mehrdadrad/tcpprobe: Modern TCP tool and service for network performance observability.
                                              • ルーター、エレベーターなど 2 億台のデバイスに影響を及ぼす脆弱性「URGENT/11」

                                                Armis Labs の研究チームが、Wind River の VxWorks リアルタイム OS(RTOS)に影響を与える可能性のある重大なセキュリティ上の欠陥を 11 件発見しました。VxWorks は同社が「有名ではないが、最も広く使用されているオペレーティングシステム」と呼ぶ OS です。 Armis Labs がまとめて「Urgent/11」と命名したこれらの脆弱性は、2006 年以降のバージョンの VxWorks で稼働するルーター、モデム、ファイアウォール、プリンター、VoIP 電話、SCADA システム、IoT、さらには MRI やエレベーターなど、約 2 億台のデバイスに影響を及ぼします。 デバイスの種類も台数も多いため、パッチの適用は容易な作業ではありません。なぜなら、特にデバイスが何年も前のものである場合など、デバイス所有者が VxWorks を使用していることに気付

                                                  ルーター、エレベーターなど 2 億台のデバイスに影響を及ぼす脆弱性「URGENT/11」
                                                • WindowsのTCP/IP実装に複数の重大な脆弱性、今月のセキュリティパッチはかならず適用を/ブルースクリーンが引き起こされるサービス拒否(DoS)脆弱性はすぐに攻撃が出回る可能性

                                                    WindowsのTCP/IP実装に複数の重大な脆弱性、今月のセキュリティパッチはかならず適用を/ブルースクリーンが引き起こされるサービス拒否(DoS)脆弱性はすぐに攻撃が出回る可能性
                                                  • 第1回 TCPの輻輳制御とは何か | gihyo.jp

                                                    本連載の背景と目的 近年、LTEなどの高速なネットワークの展開とスマートフォンや様々なクラウドサービスの普及により、インターネットを流れるデータ量は急激に増大しています。今後も、新たなスマートデバイスやIoTサービスの普及、5Gサービスの商用展開などに従い、私たちの生活においてインターネットへの接続は不可欠なものとなっていくと考えられます。そのインターネットにおいて広く利用されているプロトコルがTCP/IPです。TCP/IPは1980年頃にその基本形が完成して以来、インターネットの普及とともに広まり、発展を続けてきました。 本連載では、TCP/IPの中でも初学者にとって難しいプロトコルであるTCPに着目します。TCPは通信の信頼性を担保するための様々な機能を備えています。特に、ネットワークの状況に応じて効率的にデータを転送するための輻輳制御アルゴリズムは、今日にいたるまで様々な手法が提案、

                                                      第1回 TCPの輻輳制御とは何か | gihyo.jp
                                                    • GitHub - DeNA/PacketProxy: A local proxy written in Java

                                                      You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

                                                        GitHub - DeNA/PacketProxy: A local proxy written in Java
                                                      • Introducing a Technology Preview of NGINX Support for QUIC and HTTP/3 - NGINX

                                                        Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better

                                                          Introducing a Technology Preview of NGINX Support for QUIC and HTTP/3 - NGINX
                                                        • QUICをゆっくり解説(3):QUICパケットの構造 | IIJ Engineers Blog

                                                          Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回の説明では、「Initial パケット」や「Version Negotiation パケット」といった用語を未定義で使いました。今回は、こういった「パケット」や「フレーム」が、どのような構造を持っているかについて説明します。 古典的なパケット IP、UDP、およびTCPでデータをやり取りする基本単位は、すべて「ヘッダ+ペイロード」という構造を持っています。このヘッダ+ペイロードという単位は、それぞれ以下のように呼ぶのが慣習です。 IP – パケット UDP – データグラム TCP – セグメント すべてパケットと呼んでも間違いではありません。UDPの場合、IPペイロードが「UDPデータグラム(UDPヘッダ+UDPペイロード)」に

                                                            QUICをゆっくり解説(3):QUICパケットの構造 | IIJ Engineers Blog
                                                          • LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                                            LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 サービス開始から10年近くがたったLINEでは、次の10年のため技術的な負債を解消・改善する取り組みをプロジェクトで行っています。 通信プロトコルをSPDYからHTTP/2に移行 抽象化レイヤーを設置してプロトコル移行のリスクを低減 Long PollingをPushへと切り替えて通信量を最適化 アプリの利用状況に応じて最適なデータ同期の方法を アーキテクチャの改善でアプリの信頼性や拡張性が向上 長い歴史を持つアプリには「技術的負債をどのように解消するか」という課題が常につきまといます。2011年にサービスを開始したコミュニケーションアプリ「LINE」においても同様で、多機能化や、開発・運用の長期化に伴い、いくつもの負債が発生していました。 この課題を解決するため、LINE株式会社では「『

                                                              LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                                            • WEBサーバのTCPコネクション数に上限はあるのか? - Qiita

                                                              はじめに アクセス数がすごい環境は大抵高負荷環境でもあるので対策としてApacheの設定やサーバ構成のセオリーをすぐ見つけられて実際試しても目に見えて良くなります。 アクセス数の多さで起こる問題は実際に負荷をかけてみないと表面化しません。 問題が分かったら設定やパラメータを調整して現状がましになるようにするだけです。 ですが限りあるリソースの中でTCPセッションを十分にコントロールしようとするとすぐ手詰まりです。 WEBサーバがしているやりとりの基礎が足りていないそんな気がしていたのでTCPに目を向けてみました。 行き着いた結果は 待ち受け側とリクエスト側ではボトルネックが違う リクエスト時はTCPのエフェメラルポートが上限 待ち受け時はTCPよりもファイルディスクリプタが上限 になりやすい という良く見かける設定を見直すということになりましたが、どうやってそうなっているのかが今回の成果だ

                                                                WEBサーバのTCPコネクション数に上限はあるのか? - Qiita
                                                              • Linux perf Examples

                                                                Recent posts: 24 Mar 2024 » Linux Crisis Tools 17 Mar 2024 » The Return of the Frame Pointers 10 Mar 2024 » eBPF Documentary 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netflix End of Series 1 09 Apr 2022 » Te

                                                                • ICANN、プライベートネットワークで使うための公式トップレベルドメイン「.INTERNAL」を提案

                                                                  インターネット上のIPアドレスやドメイン名などの管理や調整を行っているICANN(Internet Corporation for Assigned Names and Numbers)は、プライベートネットワークやホームネットワークのためのトップレベルドメインとして「.INTERNAL」を予約語として割り当てるという提案を1月24日付で公開しました。 プライベートネットワークには、「192.168.xx.xx」などの専用のIPアドレス空間が公式に割り当てられており、このIPアドレス空間はインターネット上のIPアドレスと衝突しないことが約束されています。 しかし、このIPアドレス空間で管理されているプライベートネットワークのために公式に割り当てられたドメイン名の名前空間は、現時点ではありません。 そのため、プライベートネットワークの運用者がプライベートネットワーク内で何らかのドメイン名を運

                                                                    ICANN、プライベートネットワークで使うための公式トップレベルドメイン「.INTERNAL」を提案
                                                                  • GitHub - karanpratapsingh/system-design: Learn how to design systems at scale and prepare for system design interviews

                                                                    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                      GitHub - karanpratapsingh/system-design: Learn how to design systems at scale and prepare for system design interviews
                                                                    • 【MPTCP】ライブ配信の通信安定化に向けて MultiPath TCP を試験導入している話 - Mirrativ Tech Blog

                                                                      こんにちは ハタ です。 今回は Mirrativ の本番サーバの一部に試験導入している MultiPath TCP (MPTCP) について紹介させていただきたいなと思います。 MultiPath TCP といえば、iOSの Siri で利用していることなどで一時有名になりました 今回紹介するMPTCPも同じ技術を使っており、通信の安定化に向けて取り組んでいる事項の紹介になります MPTCP の概要と各OSの実装について MPTCPのイメージ MultiPath TCP (以降 MPTCP)は、複数の経路を通じて同じホストに対して通信が行えるTCP拡張です。 従来のTCP通信では、単一の通信パスしか使えなかったものが、複数の通信パスを利用できるようになります。 例えばスマートフォンでは 4G 回線と WiFi ネットワークが用意されているため、それぞれから同一のコネクション張り、どちらか

                                                                        【MPTCP】ライブ配信の通信安定化に向けて MultiPath TCP を試験導入している話 - Mirrativ Tech Blog
                                                                      • golangで作るTLS1.2プロトコル

                                                                        はじめに 前回自作でTCPIP+HTTPを実装して動作を確認することができました。 しかしご覧頂いた方はおわかりのように、通信はHTTP=平文でやり取りされておりパスワードなど機密情報が用意に見れてしまう状態です。 普段我々がブラウザに安心してパスワードを入力しているのは通信がTLSで暗号化されているからです。ではそのTLSの仕組みはどうなっているのでしょう? 恥ずかしい限りですが僕はわかりません。😇😇😇 ということで以下を読みながらTLSプロトコルを自作してみてその仕組みを学ぶことにします。 マスタリングTCP/IP情報セキュリティ編 RFC5246 プロフェッショナルSSL/TLS 今回の実装方針です。 TLS1.2プロトコルを自作する 暗号化などの処理はcryptパッケージの関数を適時利用する tcp接続にはconnectを使う 鍵交換はまずRSAで作成する TLS_RSA_W

                                                                          golangで作るTLS1.2プロトコル
                                                                        • TCP-BPF: Linuxはマイクロカーネルの夢を見るか|oraccha

                                                                          eBPFでcommit logを調べてみるといろいろと面白そうなものが出てくるな。例えば、TCP-BPF [netdev 2.2]。TCPコネクションのパラメータをBPFで操作できる。さらに最近(バージョン5.5以降)では、輻輳制御もeBPFで実装できるようになっているようだ。eBPFによりカーネルからどんどん機能を追い出してLinuxはマイクロカーネル化するのだという鼻息荒い発表も見かけるが(「eBPF - Rethinking the Linux Kernel」[QCon2020])、正直これが正しい方向性なのかよくわからない。面白いけど。 eBPFを使っているわけではないが、輻輳制御をユーザレベルで実装するという研究はいくつかある(「Restructuring Endpoint Congestion Control」 [SIGCOMM2018]、「Deploying Safe Use

                                                                            TCP-BPF: Linuxはマイクロカーネルの夢を見るか|oraccha
                                                                          • ポートが閉じてることを外部から監視するポートスキャナー(slack通知付き) - Code Day's Night

                                                                            IP制限しているTCP 22(sshd)や3306(MySQL)のようなポートが空いていないかチェックするツールを作りました。 たとえば設定ミスで22番ポートがすべてのIPを許可している状態になってしまっていたというケースがありそうで、サーバ台数が数百台になってくるといちいち気にしているのが面倒なのでチェックする簡易ポートスキャナーを作りました。 github.com 外部監視ツールだとポートが空いてるか、任意の文字列が返るかなどのチェックはできますが、ポートが閉じられてることというのを簡単に管理するのが意外と手間だと感じたのがきっかけです。 Go言語で作ってるのでバイナリにして実行もできます。 使い方 goが動く環境を用意して、 echo "example.com\nexample.net" | go run aite9 -tcp 22,3306 のようにすると次のように一気にポートをス

                                                                              ポートが閉じてることを外部から監視するポートスキャナー(slack通知付き) - Code Day's Night
                                                                            • 続々 WiresharkのDissectorを使った独自プロトコル解析(TCP,UDP分割パケットの場合)

                                                                              本稿では、初めて実際に独自プロトコルのDissectorを作る人が最初にぶつかるであろう壁を乗り越える方法を紹介します。 Dissectorって何?という人は、先に↓こちらを読んでください。 WiresharkのDissectorを使った独自プロトコル解析をやさしく解説してみました - DARK MATTER 本稿では、基本的なDissectorの作り方と、Dissectorを活用したパケット解析方法を紹介します。WiresharkのDissectorをご存知でしょうか?DissectorはWireshar ... できるようになること 複数のパケットに分割されたパケットのDissectorの作成 TCPのパケット分割について(いちおう書いておきます) TCPはストリーム型の通信であり、送信サイズや通信環境によりTCPの仕組みでパケットが分割されて送信される場合があります。このため一般に公

                                                                                続々 WiresharkのDissectorを使った独自プロトコル解析(TCP,UDP分割パケットの場合)
                                                                              • TCP/UDP接続を行っているプロセスを一覧できるユーティリティ「ProcessTCPSummary」/プロセスのネットワーク通信状況を把握・調査するのに役立つ【レビュー】

                                                                                  TCP/UDP接続を行っているプロセスを一覧できるユーティリティ「ProcessTCPSummary」/プロセスのネットワーク通信状況を把握・調査するのに役立つ【レビュー】
                                                                                • Linuxの各種仮想ネットワークデバイスにおけるSegmentation Offloadの振る舞い

                                                                                  LinuxにおけるSegmentation OffloadとはTCPなどのトランスポートレイヤのプロトコルが送信するデータをMTUに収まるように分割する処理(Segmentation)をNICのレイヤにオフロードすることによってスループットを向上させる技術です. Segmentation Offloadを使った場合, トランスポートレイヤのプロトコルはIPレイヤで許容される最大のサイズ(64KB程度)までのデータを1つのIPパケットで送信することができます. 受信側は逆にネットワークから入ってきたSegmentation済みのパケットをNICのレイヤで1つの大きなIPパケットに集約した上でプロトコルスタックの処理にかけます. これによってプロトコルスタックで処理されるパケットの個数を減らすことができるため, スループットが上がるという仕組みです. Linuxには仮想ネットワークデバイスとい

                                                                                    Linuxの各種仮想ネットワークデバイスにおけるSegmentation Offloadの振る舞い