並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 1641件

新着順 人気順

UDPの検索結果81 - 120 件 / 1641件

  • 今、Unityでネットワークマルチプレイ作るのに何を使えばいいのか

    前置き Unityエンジニアは最近、圧を受けている人が多いと思います。 近頃はバトルロイヤルゲームが流行ってますが、100人マルチプレイを実現しているPUBGやFortniteはUE4製ですから、会社の偉い人が「こういうの作れないの?」と仰っても、「UE4じゃないとUnityじゃこういうの無理ですよ」と言って誤魔化せていました。 そんな中、Unityで作られた60人マルチプレイのFallGuysが登場してしまいました。こうなるとUnityエンジニアは会社の偉い人から「Unityでもこういうの作れるやんけ!」と詰められてしまいますが、返す言葉もないといったところでしょう。 Unityテクノロジーズもブログ記事とかで「Unityでもこんなすごいネットマルチプレイゲームが作れます!」と積極的に喧伝してます。 Fall Guys が試練を乗り越えて、グローバルに展開できた理由 正直言ってUnity

      今、Unityでネットワークマルチプレイ作るのに何を使えばいいのか
    • 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(アンビ)
      • パケットは落としていいんだよ

        NUROでパケロスが酷いっていうのは問題だし対処してほしいけど 「パケットを破棄するなんて許せない」とか言ってるアホはインターネットを最初から勉強し直してこい 「UDPのパケットを落としてるのは問題」とか言ってるアホもL4の勉強やり直してこい TCPが遅いだのなんだの文句付けてUDPでネットワークリソースを消費しておいて いざUDPが輻輳したらNUROに文句言うとかお門違いにもほどがある 文句を言う先は任天堂だし任天堂はまともなネットワークエンジニアを雇えよ 今時のゲームはUDPで冗長に送るのがデフォだし輻輳制御とか全然考えてないから絞られて文句言う方がおかしいわ ゲームじゃなくて仕事で使ってる人からすれば「そんなクソUDPパケットはバカバカ落としてしまっていい」っていう感じだし TCPみたいなフェアネス考えてないパケットはもうガッツリブロックしていいんだよ 文句言う先間違えんな アホども

          パケットは落としていいんだよ
        • スプラトゥーン3で学ぶ最新通信技術

          任天堂が2022年9月9日に発売した「スプラトゥーン3」は国内での販売数が500万本以上という超人気ゲームです。このスプラトゥーン3の通信をパケットキャプチャーで調べることで、オンラインゲームなどに必要な最新の通信技術を学びます。 スプラトゥーン3をパケットキャプチャーで解析、最新の通信技術を学ぼう この特集は、人気のスプラトゥーン3を通して、最新の通信技術の基本を学んでしまおうというものです。今回は、実際にスプラトゥーン3のパケットをキャプチャーして、それらの通信技術が実際にどのように使われるのかを見ていきます。 2022.11.22 スプラトゥーン3の通信に欠かせない、UDPとNAT越えを理解しよう この特集は、人気のスプラトゥーン3を通して、最新の通信技術の基本を学んでしまおうというものです。前半の今回はスプラトゥーン3を含むオンラインゲームの通信技術を解説します。 2022.11.

            スプラトゥーン3で学ぶ最新通信技術
          • クラウドでのネットワーク レイテンシの測定 | Google Cloud 公式ブログ

            ※この投稿は米国時間 2020 年 6 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。 クラウド アーキテクトによく寄せられる質問の一つに、「2 つのエンドポイント間でリクエストとレスポンスをどの程度まで迅速に交換できるのですか?」というのがあります。ネットワークのラウンドトリップ レイテンシを測定するツールには ping、iperf、netperf などがありますが、すべてが同じように実装、構成されるわけではないため、ツールによって結果が異なる場合があります。ほとんどの場合、この質問に対する代表的な回答が得られるツールは、netperf であると考えられます。これからその詳細について説明していきます。 Google は、レイテンシ ベンチマークに関する実践的な経験を重ねてきました。このブログでは、Google とサザン メソジスト大学の AT&T Cen

              クラウドでのネットワーク レイテンシの測定 | Google Cloud 公式ブログ
            • ブラウザから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
              • WebSocketの次の技術!?WebTransportについての解説とチュートリアル - Qiita

                概要 こんにちは。NTTコミュニケーションズのyuki uchidaです。普段はSkyWayというWebRTCプラットフォームの開発やWebRTCリサーチャー(見習い)をしています。 この記事は NTTコミュニケーションズ Advent Calendar 2020 の3日目の記事です。 昨日はMasaki Shimuraさんの記事、 「Threat Intelligenceの活用を促進するMISPの紹介」でした。 この記事は、WebSocketの次の技術ではないかと噂される、WebTransportの概要や双方向通信の歴史をまとめつつ、WebTransportのdatagram形式でデータを送信してみるチュートリアル記事です。 対象読者 WebTransportっていう技術を初めて聞いた人 WebSocketを使ったことがあり、不満がある人 双方向通信・リアルタイム通信について興味がある人

                  WebSocketの次の技術!?WebTransportについての解説とチュートリアル - Qiita
                • 最近観測されている DNS トンネリングのトラフィック

                  By Ruian Duan and Daiping Liu October 16, 2023 at 1:38 AM Category: Malware Tags: Advanced URL Filtering, Cobalt Strike, Cortex XDR, Decoy Dog malware, DNS security, dns tunneling, DNSTT, FinCounter, next-generation firewall, VPN This post is also available in: English (英語) 概要 本稿は、DNS (ドメイン ネーム システム) のトンネリング技術が野生で (in the wild) どのような理由と方法で利用されているのかに関する研究をご紹介します。またこの研究結果に基づいて、トンネリング ドメインをツールやキャンペーン

                    最近観測されている DNS トンネリングのトラフィック
                  • インフラエンジニアなら気になる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のロードバランサ (方式編)
                    • Time on Unix

                      Sections What is time Representing time Where do we usually find time on Unix System time, hardware time, internal timers Syncing time with external sources What depends on time Human perception of time What is time Time is relative Measuring time and standards Coordinating time Time zones DST Time, a word that is entangled in everything in our lives, something we’re intimately familiar with. Keep

                        Time on Unix
                      • 追悼 Bram Moolenaar ~Vimへの情熱と貢献を振り返る | gihyo.jp

                        Bram Moolenaar the Creator of Vim 2023年8月5日、悲しい知らせが入ってきました。長年、多くのエンジニアに愛され今もなお使われ続けているテキストエディタVimの作者Bram Moolenaar氏が同月3日に亡くなったという知らせです。ショックでしばらく信じることができませんでした。 筆者は長年Vimを使い、Vimに多くのコントリビュートを行ったり、その都度Bram氏と対話したり議論したりしてきました。そのBram氏が突然、この世界からいなくなってしまったことをしばらく受け入れられなかったからです。 本記事では追悼の意味を込め、Bram氏がどのようにVimの開発を始め、Vimがどのように広まっていったのか、また長年Vimを追い続けてきた筆者から見たBram氏の人物像を筆者の思いを交えて解説していきます。 Vimの歴史 Bram氏についてお話しする前に、まず

                          追悼 Bram Moolenaar ~Vimへの情熱と貢献を振り返る | gihyo.jp
                        • N予備校 「プログラミング入門 Webアプリ」を修了した. - JUNのブログ

                          タイトルにもあるとおり, N予備校の 「プログラミング入門 Webアプリコース」を修了しましたので, 完走した感想を書きたいと思います. プログラミング入門 Webアプリコース とは まずはじめに, 今回終了したN予備校の「プログラミング入門 Webアプリコース」(長いので以下 入門コース と略します) がどんなコースなのかというのは, N予備校公式サイトから引用すると, 完全な未経験者向けのプログラミング入門講座です。 JavaScriptというプログラミング言語でセキュリティ上の問題のないWebサービスが開発できるようになります。他にも数値集計プログラム、Slackのボットなどを作成しながら、エディタやLinuxの開発環境などの基礎知識を身につけます。なお学習にはPCが必要です。 www.nnn.ed.nico とのことらしいです. 他にも 「大規模Webアプリコース」 や 「スマート

                            N予備校 「プログラミング入門 Webアプリ」を修了した. - JUNのブログ
                          • QUICやHTTP/3で利用を避けるべき送信元ポートの議論についての考察 - show log @yuyarin

                            https://www.slideshare.net/yuyarin/quicnat 最近QUICとNATについての話をJANOGで紹介するぐらいQUICという新しいプロトコルに既存のネットワークインフラがどう適応していくかを考えています。 id:asnokaze さんの記事で紹介されているように、QUICやHTTP3/3で送信元UDPポートとして利用を避けるべきポートの議論が行われています。これはUDPのリフレクション攻撃のへの対応としてインフラストラクチャ側で特定のUDPポートのトラフィックをブロックしているケースがあるからです。実際に私もこのブロックの設定を行ったことがあります。 これはUDPというプロトコルの特性に起因する問題であり、QUIC, HTTP/3に限らずUDPを使うプロトコルに広くある問題です。 asnokaze.hatenablog.com QUICクライアント側で送

                              QUICやHTTP/3で利用を避けるべき送信元ポートの議論についての考察 - show log @yuyarin
                            • HTTP/3: the past, the present, and the future

                              HTTP/3: the past, the present, and the future09/26/2019 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
                              • KeyTrap (CVE-2023-50387)を検証してみた - knqyf263's blog

                                DNSは趣味でやっているだけですし有識者のレビューを経ているわけでもないので誤りを含むかもしれませんが、DNS界隈には優しい人しかいないのできっと丁寧に指摘してくれるはずです。 追記:めちゃくちゃ丁寧にレビューしていただいたので修正いたしました。森下さんほどの方に細かく見ていただいて恐れ多いです...(学生時代に某幅広合宿で森下さんの発表を見てDNSセキュリティに興味を持った) 4万文字を超える大作、おつかれさまです。わかりやすく書けていると思いました。 ざっと読んで、コメントしてみました。ご参考まで。https://t.co/bVj5WeFHQr https://t.co/ku5NOx6ua8— Yasuhiro Morishita (@OrangeMorishita) 2024年2月19日 要約 背景 詳細 DNSSECとは? DNSSECの可用性 鍵タグの衝突 攻撃内容 SigJam

                                  KeyTrap (CVE-2023-50387)を検証してみた - knqyf263's blog
                                • IETFによるHTTP/3の標準化プロセスが完了、「RFC 9114」に

                                  IETFのQUICワーキンググループはHTTP/3の標準化プロセスを完了し、「RFC 9114」として発表しました。 HTTP/3 has been published as an RFC. https://t.co/jdsUHy9FKD — IETF QUIC WG (@quicwg) June 6, 2022 HTTPはWorld Wide Webを開発したティム・バーナーズ=リーによって1990年に最初のバージョンが作られました。 その後、1996年にHTTP/1.0がIETFによってRFC化され、1999年にHTTP/1.1へアップデート。2015年2月には初めてのメジャーバージョンアップとなるHTTP/2がRFCとなりました。HTTP/3は7年ぶりのメジャーアップデートと言えます。 HTTP/3では高速な通信を実現するために、HTTPのトランスポート層を従来のTCPからQUICに

                                    IETFによるHTTP/3の標準化プロセスが完了、「RFC 9114」に
                                  • QUICとHTTP/3がIETFのラストコール。RFCによる標準化が間近に

                                    IETFのQUICワーキンググループで標準化作業が進められてきたQUICとHTTP/3が、6月のQUICワーキンググループにおけるラストコールを経て、IETFのステアリンググループであるIESGのラストコールとして10月21日に受諾されました。 ラストコールとしてIESGが受諾したドキュメントは、QUICとHTTP/3の標準化に関わる以下の6つのドキュメントです。 QUIC: A UDP-Based Multiplexed and Secure Transport QUIC Loss Detection and Congestion Control Using TLS to Secure QUIC Version-Independent Properties of QUIC Hypertext Transfer Protocol Version 3 (HTTP/3) QPACK: Head

                                      QUICとHTTP/3がIETFのラストコール。RFCによる標準化が間近に
                                    • QUICとNATと – JANOG48 Meeting

                                      場所 OHGAKI(完全リモート) 日時 Day3 2021年7月16日(金) 14:45~15:15(05分) 概要 RFC9000で標準化が完了したQUICはUDP443番ポートを使うプロトコルです。それが故にIPv4のNATルータとの間で起こる問題について考察したいと思います。 発表者 川上 雄也(NTTコミュニケーションズ株式会社) 公開資料 公開資料

                                      • QUICはTCPの代替ではない

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

                                        • Cloudflare Zero Trustを導入してみた - POC環境構築編 - メモのページ - チラシの裏メモ 3枚目

                                          ゼロトラスト ネットワーク(ZTN)の学習用環境として、Cloudflare Zero Trustを自宅に導入してみた。 今回はCloudflare Zero Trust導入手順のメモ。 2023/7/8追記 ポリシーの設定やOktaとの連携等の記事は、当記事内下部の「Cloudflare Zero Trust関連の記事」のリンク先を参照。 Cloudflare Zero Trustとは CDN事業者として知られているClaudflare社が提供するゼロトラスト セキュリティソリューションである。 SWG(Secure Web Gateway)と呼ばれるクラウド型のプロキシサービス、IPアドレスの匿名化、アンチウイルス・アンチマルウェア、URLフィルタリング、アプリケーションフィルター等のサービスを提供する。 Cloudflare Zero Trustと競合する主なゼロトラストネットワーク

                                            Cloudflare Zero Trustを導入してみた - POC環境構築編 - メモのページ - チラシの裏メモ 3枚目
                                          • QUICむけにAES-GCM実装を最適化した話 (1/2)

                                            4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC

                                            • MagicDNS is generally available

                                              Tailscale automatically assigns IP addresses for every unique device in your network, giving each device an IP address no matter where it is located. We further improved on this with MagicDNS, which automatically registers a human-readable, easy-to-remember DNS name for each device —  so you don’t need to use an IP address to access your devices. This means you can access the device monitoring, ev

                                                MagicDNS is generally available
                                              • 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で始めるネットワークプログラミング」を出版しました。 - 電気ひつじ牧場
                                                  • 自宅ルータの脆弱性検知システムの開発 - Sansan Tech Blog

                                                    Sansan 技術本部 情報セキュリティ部 CSIRT グループの川口です。 2023年4月からセキュリティエンジニアで新卒として、Sansan に入社しました。 現在は ログ基盤(SIEM)のログの取り込み部分の機能修正、問い合わせ対応、インシデント対応などの業務に取り組んでいます。 今回は内定者インターンシップで開発した、自宅ルータの脆弱性検知システムについて紹介します。 目次は以下の通りとなります。 開発に至った経緯 作成したシステム 技術的な話 EDR ポートスキャン チケットシステムへの起票 SOAR まとめと今後の課題 開発に至った経緯 新型コロナウイルスの流行に伴い、リモートワークという言葉をよく耳にするようになったと思います。 弊社でも緊急事態宣言下においては、原則リモートワークとなり、現在はオンライン・オフラインを併用した働き方をしています。 ここで問題となってくるのが自

                                                      自宅ルータの脆弱性検知システムの開発 - Sansan Tech Blog
                                                    • 「VPNプロトコル」5種の違い あの定番から“高速VPN”の新技術まで

                                                      関連キーワード VPN | ネットワーク・セキュリティ | 在宅勤務 エンドユーザーはインターネットを利用する際、VPN(仮想プライベートネットワーク)を用いることでその接続の安全性を保てる。企業のネットワークチームは、従業員がリモートアクセスをするための手段としてVPNを重宝している。 VPNにはさまざまな選択肢がある。中には暗号化方式が古く、安全でないものもある。主要な5つのVPNを解説する。 主要な5つのVPNの特徴とは 1.L2TP/IPsec 併せて読みたいお薦め記事 連載:VPN徹底解説 前編:いまさら聞けない「VPN」の基礎知識 暗号化が必要になった理由は? VPNの新しい姿とは 「無料VPN」を好むZ世代はクールじゃない? 有料VPN世代との違い アラブ諸国で「VPN」が使い倒されていた“意外な理由” 「L2TP/IPsec」は、「Layer 2 Tunneling Pro

                                                        「VPNプロトコル」5種の違い あの定番から“高速VPN”の新技術まで
                                                      • DNS パケット欠落のケース: Google Cloud サポート ストーリー

                                                        ※この投稿は米国時間 2020 年 5 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。 編集者注: Google Cloud テクニカル ソリューション エンジニア(TSE)がサポートケースにどのように取り組んでいるか気になったことはありますか?TSE はお客様から報告された問題の技術的な根本原因のトラブルシューティングと特定を担当するサポート エンジニアです。かなりシンプルな問題もありますが、数名の専任エンジニアによるトラブルシューティングを必要とするサポート チケットがたまに送信されることがあります。このブログ投稿では、Google Cloud テクニカル ソリューション エンジニアから聞いた、最近解決した特に厄介なサポートケース(DNS パケットが欠落する問題)についてご紹介します。トラブルシューティングの過程で収集した情報と、どのように方法を推論し

                                                          DNS パケット欠落のケース: Google Cloud サポート ストーリー
                                                        • dig の全てのコマンドラインオプションを一覧にしたシートを作成しました - Qiita

                                                          概要 筆者は DNS Summer Day 2023 で「あたらしい dig」というテーマで発表を行いました(資料はこちら)。 DNS のテストツールである dig コマンドは、ネットワークエンジニアのみなさんが日常的に利用していると思います。 一方で、dig を用いているとたまに想定とは異なる結果が得られ、戸惑うことがあります。 原因としては、dig の送信するリクエストメッセージに関するデフォルト値が一般的な感覚と異なるために起きることが多いようです。 発表ではこれらの具体的な例を挙げつつ、もし dig のいくつかのコマンドラインオプションの存在やそのデフォルト値の知識があったならば、それらはすぐに解決したであろうことを示しました。 dig には非常に多くのコマンドラインオプションがあります。しかし、man ページや -h オプションで表示される簡易ヘルプではコマンドラインオプションが

                                                            dig の全てのコマンドラインオプションを一覧にしたシートを作成しました - Qiita
                                                          • 「1.1.1.1 は一部の多段 CNAME を解決してくれない」改め「makeshop.jp は 1.1.1.1 をブロックしている」

                                                            2023/09/20 追記 以下で有識者からコメントをいただきました。 makeshop.jp は 1.1.1.1 を遮断しているらしく、本記事はまさに makeshop.jp で制作したページが見れないことに起因した話題であったため、多段 CNAME は無関係でした。 コメント頂いた皆様、ありがとうございました! 1.1.1.1 をブロックしている SaaS があると思わずに首を傾げていた頃の記事 disclaimer Dig Web Interface を用いて振る舞いを観測した結果、 1.1.1.1 のみ異なる結果を返したことから本記事のようなタイトルを付けていますが、 1.1.1.1 の振る舞いが正しい可能性もあります。 ことのはじまり とある SaaS でカスタムドメインを利用するため、 CNAME を以下のように設定したところ、 1.1.1.1 もしくは 1.0.0.1 をネー

                                                              「1.1.1.1 は一部の多段 CNAME を解決してくれない」改め「makeshop.jp は 1.1.1.1 をブロックしている」
                                                            • The state of HTTP in 2022

                                                              This post is also available in 简体中文, 繁體中文, 日本語, 한국어, Deutsch, Français, Español and Português. At over thirty years old, HTTP is still the foundation of the web and one of the Internet’s most popular protocols—not just for browsing, watching videos and listening to music, but also for apps, machine-to-machine communication, and even as a basis for building other protocols, forming what some refer

                                                                The state of HTTP in 2022
                                                              • 時雨堂クラウドサービスを支える技術

                                                                自社パッケージ製品のクラウド版 を開発していて、色々やりたい放題やってるのでメモ。 方針 遠回り駆動開発 やりたい放題やる 王道は無視して「じぶんのかんがえたさいきょうの」をでいく 可能な限り OSS 開発元が提供しているクラウドサービスを利用する ベアメタルサーバーを使う 三大クラウドサービス (AWS, GCP, Azure) を使わない なぜ利用している技術を公開するのか 自社で使って良かった OSS やサービスはより多くの人に知って欲しいと考えています。 また、特に隠す理由がないというのもあります、むしろ大きな声で Tailscale や TimescaleDB 、 VictoriaMetrics 、Cloudflare 、DataPacket など、ほんとうに素晴らしい使わせて頂いていると言っていきたい。 我々が利用させて頂いている製品の企業や開発者の方へ とても素晴らしい製品を

                                                                  時雨堂クラウドサービスを支える技術
                                                                • SAD DNSのICMP rate limitを用いたサイドチャネル攻撃について - knqyf263's blog

                                                                  脆弱性ネタは人気がないことが過去の傾向から明らかですが、自分が震えるほど感動したので忘れないためにも気合い入れて大作を書きました。 要約 背景 SAD DNSの解説 全体像 UDPのソースポートについて ICMP rate limit per-IP rate limit global rate limit Public-Facing Source Portのスキャン Private Source Portのスキャン 攻撃Windowの拡張 サイドチャネル攻撃でUDPソースポートを推測してみる 対策 攻撃実現性 まとめ 要約 ちゃんと理解するの結構難しいという話があったので、先に要約しておきます。雰囲気だけでも掴んでもらえると嬉しいです。 DNSキャッシュポイズニングの新しい手法としてSAD DNSが発表された キャッシュポイズニングのためには権威DNSサーバ正規の応答を返すより先に攻撃者が

                                                                    SAD DNSのICMP rate limitを用いたサイドチャネル攻撃について - knqyf263's blog
                                                                  • 新Linuxカーネル解読室 - ソケットインターフェース(データ構造と概要編) - VA Linux エンジニアブログ

                                                                    「Linuxカーネル2.6解読室」(以降、旧版)出版後、Linuxには多くの機能が追加され、エンタープライズ領域をはじめとする様々な場所で使われるようになりました。 それに伴いコードが肥大かつ複雑化し、多くのエンジニアにとって解読不能なブラックボックスとなっています。 世界中のトップエンジニア達の傑作であるLinuxカーネルにメスを入れ、ブラックボックスをこじ開けて、時に好奇心の赴くままにカーネルの世界を解読する「新Linuxカーネル解読室」プロジェクト。 本稿では、旧版第21章で解説されていたソケットインターフェースについて、カーネルv6.8のコードをベースに主にデータ構造を中心に解説します。 はじめに ソケットの実体と概要 ソケット操作関数の実装 ファイル操作関数によるソケット操作の実装 次回予告: ソケット生成編 執筆者 : 須田 哲志、稲葉 貴昭 ※ 「新Linuxカーネル解読室」

                                                                      新Linuxカーネル解読室 - ソケットインターフェース(データ構造と概要編) - VA Linux エンジニアブログ
                                                                    • 複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする | DevelopersIO

                                                                      中山(順)です 先日に東京リージョンで比較的規模の大きな障害が発生いたしました。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 障害の影響は特定のAZに限られていたことは上記の公式メッセージで説明されているとおりです。 また、障害発生の早い段階で単一のAvailability Zoneで問題が発生していることがService Health Dashboardでアナウンスされていました。 しかし、Design for Failureの原則に基づいてリソースを複数のAvailability Zoneで冗長化してるケースでも何らかの影響を受けたというケースもあったようです。(以下、その一例です) 8月23日のAWSの大規模障害でMultiAZでも突然ALB(ELB)が特定条件で500エラーを返しはじめたという話 これは、

                                                                        複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする | DevelopersIO
                                                                      • GitHub - fujiapple852/trippy: A network diagnostic tool

                                                                        Trace using multiple protocols: ICMP, UDP & TCP IPv4 & IPv6 Customizable tracing options: packet size & payload pattern start and maximum time-to-live (TTL) minimum and maximum round duration round end grace period & maximum number of unknown hops source & destination port (TCP & UDP) source address and source interface TOS (aka DSCP + ECN) Support for classic, paris and dublin Equal Cost Multi-pa

                                                                          GitHub - fujiapple852/trippy: A network diagnostic tool
                                                                        • Let’s Encryptでワイルドカード証明書を取得する話 | IIJ Engineers Blog

                                                                          はじめに SoftwareDesign 8月号のDNS特集にて記事を書かせていただきました。みんな買ってね。 で、実は最初に書いてた原稿はもっと長かったんですけど、紙幅の都合で一部の内容については掲載を見送りました。せっかく書いたのに捨てるのはもったいないので、先日おこなわれたDNS Summer Day 2022で発表しようかと準備してたんですが、途中で気が変わって違う内容になりました。そんなわけで、最終的にエンジニアブログにて供養します。加筆修正しまくっているので元の原稿の気配はもはや残り香程度に漂うだけですが。 ACMEでdns-01チャレンジ サーバ証明書を無料かつ自動で取得できるサービスとして有名なものにLet’s Encryptがありますが、Let’s Encryptの仕組みはLet’s Encrypt独自のものではありません。ACME (RFC8555)として標準化されていて

                                                                            Let’s Encryptでワイルドカード証明書を取得する話 | IIJ Engineers Blog
                                                                          • クラウドネイティブなVPNを構築して運用している話 - Mirrativ Tech Blog

                                                                            インフラストリーミングチームの近藤(@udzura)です。 今日は、ミラティブ社内向けツールの話をします。ミラティブではVPNの仕組みをクラウドをフル活用して自前で構築し、1年ほど運用しています。運用中にいろいろ課題はありつつ、現在かなり安定して動作してます。 今回の記事は、そのVPNの仕組みを紹介します。 既存VPNの課題 災害時に稼働できないリスクを避けたい どこに誰がアクセスできるか楽に管理したい 新しいVPNをハッカソンで開発した話 新VPNの設計思想 災害時でも稼働できる どこに誰がアクセスできるか管理できる 攻撃時の影響を限定する 12時間でインスタンスを停止する クラウドネイティブなVPNである アーキテクチャと技術の説明 WireGuard Google Cloud VPCの各機能 Cloud Functions + Pub/Sub + Slack App API Slac

                                                                              クラウドネイティブなVPNを構築して運用している話 - Mirrativ Tech Blog
                                                                            • Clubhouseを支えている技術とアーキテクチャ、セキュリティについて - LayerX Research

                                                                              #LayerX_Newsletter 2021-02-19 TL;DR Clubhouseは極めてシンプルなアーキテクチャ 音声データはAgoraを、リアルタイム性の高い情報の扱い(ルームの中など)はPubNubを利用 音声データが暗号化されていないなどセキュリティ面での課題も多い Clubhouseは招待制の音声配信SNSで、2020年Aplha Exploration社が開発したこのサービスは、つながりがある人同士でラジオ放送のように自由に会話を楽しんだり、興味ある人はその会話を傍聴、さらには会話に飛び入り参加もできる特徴がある。2021年に入り世代・国籍・性別を問わず爆発的人気となっており、日本では2021年1月からスタートアップ界隈を中心に一気に話題が広がっている。また、テスラの創業者や有名人・著名人などが利用しはじめたことで大きな注目を浴びた。今回はClubhouseはどのような

                                                                                Clubhouseを支えている技術とアーキテクチャ、セキュリティについて - LayerX Research
                                                                              • WebTransport と WebCodecs そして Web はどこまで "ゲーム化" するか | blog.jxck.io

                                                                                Alternatives 結局 WebSocket が TCP に縛られていなければ良いのではという点に注目すると、 WebSocket over HTTP/3 が実現できれば HoLB などの問題は解決しそうだ。 しかし、仮にそこに複数のストリームを束ねようとしても、 WS の特徴上ストリームごとに 1RTT のハンドシェイクが必要となる。また、サーバから Stream を開始することができない(本当にそれが必要なのかは疑問だが)という問題があげられている。 また、 WebRTC の文脈で進んでいる RTCQuicTransport が、非常にというかあるケースではほぼ同じことを提供することになる点が指摘される。(策定者も同じ) これもやはり、 WebRTC が P2P 前提の仕様でスタートした点と Client-Server ユースケースとの乖離をベースに説明されており、すでに RTC

                                                                                  WebTransport と WebCodecs そして Web はどこまで "ゲーム化" するか | blog.jxck.io
                                                                                • 安全なKubernetesクラスタのつくりかた 〜ポリシー編〜 - Cybozu Inside Out | サイボウズエンジニアのブログ

                                                                                  こんにちは、Necoプロジェクトの池添(@zoetro)です。 今回は、安全なKubernetesクラスタを構築するために、我々がどのようなポリシーを適用しているのかを紹介したいと思います。 Kubernetesクラスタのセキュリティ対策 安全なKubernetesクラスタを構築するためには、非常にたくさんの項目について検討しなければなりません。 ざっと挙げてみただけでも以下のような項目があります。(詳細は Kubernetesの公式ガイド を参照) Role-Based Access Control (RBAC) ネットワークアクセスの制御(Network Policy) コンテナの権限(Pod Security Policy) 通信の暗号化 Secretの暗号化 信頼できるコンテナイメージの利用 安全なコンテナランタイムの利用 ユーザー/グループの管理 API ServerのAudit

                                                                                    安全なKubernetesクラスタのつくりかた 〜ポリシー編〜 - Cybozu Inside Out | サイボウズエンジニアのブログ