Cloudflare、こんなに無料でいいんだろうか ― 「クラウド」の定義が書き換わったことに気づかない人々へ 全世界で数百万人が同時にアクセスするようなサービスを設計し、AWSに毎月、数十万から数百万円という「血の滲むようなコスト」を支払い続けてきた立場から言わせてもらえば、今のCloudflareが提示している世界観は、もはや「CDN」なんていう可愛い言葉で呼べるものではない。かつて私たちがオンプレミスからAWSへ移行した時に感じたあのパラダイムシフトが、今、Cloudflareという「Supercloud」によって、さらに残酷な形で繰り返されている。 あえて、いま提供されているサービスを地べたから天井まで並べてみるとこんな感じだ。Cloudflare DNS, CDN, WAF, DDoS Protection, Bot Management, SSL/TLS, Zero Trust

東京支部 CommunityBuilders Night #2 / Jr.Championsコラボ

tl;dr foobarhogehoge.invalidは絶対にリクエストが飛ばないのでおすすめ あらすじ 書いていたコードは、とあるミドルウェア向けに内部利用するURLを環境変数で受け取るようになっていた。普段は実際の内部のURLが書かれているのだが、テスト時には以下のようにダミーを設定していた: FOOBAR_EXTERNAL_URL="https://example.com/foobardummy" テストではこのURLを利用しないのだが、内部で環境変数のバリデーションを行っている都合上、とりあえず適当なURLを指定しなければ起動してくれないから、こうなっていた。重ねて言うが、実際はこの環境変数を利用していないのでこれでいい。 しかしこれだと、うっかり内部の様子がおかしくなったりエンジニアが狂ってしまった場合に、example.comに本当にアクセスしてしまう。なおかつ、セキュリティ

物理的な接続に関する知識 ネットワークエンジニアは、以下のような物理的な設備についても理解している必要があります。 局舎：キャリアの設備がある建物で、ここから各ビルへ回線が引き込まれる MDF（主配線盤）：建物内の主配線盤で、キャリア回線の引き込み点となる 責任分界点：キャリアと利用者の責任境界。障害時の切り分けで重要 引き込み経路：局舎から建物までの物理経路。工事可否の判断に必要 必要な調整業務 キャリアとの調整では、技術的な知識だけでなく、プロジェクト管理能力も求められます。 工事日程：キャリア側と利用者側の調整が必要。双方の作業員の手配も含む 仕様確認：インターフェース規格、VLAN設定、ルーティング情報などの技術仕様のすり合わせ 障害切り分け：障害発生時にどちらの責任範囲かを明確にし、迅速な復旧を行う これらの知識は、サーバーエンジニアやクラウドエンジニアには通常求められない、ネッ

はじめに こんにちは、ばーやんです！突然ですがネットワークの遅延ってなにからきているかわかりますか？ pingで遅延などを測定していることはあってもそれが何から来ているかふわっとしている方も多いのではないでしょうか？ 今回は遅延の解像度をあげるべく記事を執筆しました！ おすすめの読者 ネットワークエンジニア、インフラエンジニア 遅延が重要な技術開発をしている方(ライブ配信、ゲーム、HPC等) 通信遅延の解像度を上げたい方 参考文献 通信遅延の分類の方法はいくつかあります。今回はCiscoのホワイトペーパー「パケット音声ネットワークでの遅延について」を参考にまとめていきます。気になったら読んでみてください。 遅延の全体像 全体像から見ていきましょう。 通信遅延の全体像です（元の記事が音声のみで特殊だったので少し抽象化しています。） 遅延が発生する順番は以下のような形 コード遅延：データをパケ

こんにちは、CSIG 所属の市川です。普段は FutureVuls という脆弱性管理サービスの開発・カスタマーサポートをしています。 「ん？そういえば、HTTPS 通信 (HTTP over SSL/TLS) では実際どのようにセキュアな通信が確立されているんだろう？」 と、ふと気になってしまうこと、ありませんか？私はありました。 というわけで、SSL/TLS について書籍などで学んでみたのですが… アルゴリズムが沢山出てきて頭がこんがらがる…。結局どのフェーズでどのアルゴリズムが使われているんだろう？ TLS ハンドシェイクの中では、実際どういった通信が行われているのだろうか。ハンドシェイク確立後はちゃんと暗号化されているのだろうか。 …というモヤモヤが残りました。 本記事 (理論編) と、続編の実践編で、この2点の疑問を解決していきます。 本記事でやりたいこと本記事 (理論編) では、

0.自己紹介 村田 亜弥（alichan） 仕事：AWSを用いた公共サービスやメディアサービスの基盤刷新やPoC開発で アプリケーションエンジニア/クラウドエンジニアとして仕事しています。 好きなこと：個人でAWSを用いた個人開発や技術記事執筆/登壇、イベントの 開催等を行なっています。AWSとプログラミングが好きです！ 個人ではalichanという名前で活動しています。 資格：Solutions Architect - Professional ：https://github.com/alichan-69 ：https://zenn.dev/alichan ：https://x.com/alichan0609 This presentation makes reference to marks owned by third parties. Unless otherwise noted,

地方拠点の一つ、九州支社に所属しています。サーバ・ストレージを中心としたSI業務に携わってましたが、現在は技術探索・深堀業務を経て、ローカルLLMを中心としたAIソリューションを主軸に対応しています。 2018年に難病を患ったことにより、定期的に入退院を繰り返しつつ、2023年には男性更年期障害の発症をきっかけに、性的違和の治療に一歩足を踏み出しています。 かなり久しぶりの技術ネタ投稿かもしれません こんばんわ。九州支社で働く二等兵こととみーです。 技術探索に注力し始めてはや1年を越え、実案件の技術支援もしつつ今日も「言葉しか知らないこと」の中身を知るべく取り組んでいる日々を過ごしています。技術に近いネタをこのブログに書くのは実に2年ぶりぐらいですかね？珍しくそれっぽいことを書いてみることにしました。 私はちょうど10年前、家庭の事情により関東のIT企業を離れて九州のこの地にUターンしまし

AWSとオンプレミスと繋ぐときに知っておきたいルーティングの基礎知識。 JAWS DAYS 2021の発表資料です。

面白そうだったのでHTTPS通信パケットを復号してみました。HTTPS通信パケットを復号するにあたり、まずはHTTPSの暗号化方式について調べてみたのでまとめます。 HTTPSの暗号化方式 HTTPS通信の暗号化には公開鍵暗号方式と共通鍵暗号方式の両方を利用したハイブリッド方式により暗号化が行われます。それぞれの暗号化方式についての説明です。 共通鍵暗号方式では、サーバー側もクライアント側も、データの暗号化と復号に同じ鍵を使用します。この方式のメリットは処理時間が短いことです。一方でデメリットとしてサーバーとクライアントで鍵を交換する際に、鍵を盗まれる危険性があります。下の図はすでに鍵交換を終えて、データをやり取りしている状態の図です。どうやって鍵を交換するかまでは、この暗号方式では特に決まっていません。 公開鍵暗号方式は、送受信データの暗号化と復号に異なる鍵(公開鍵と秘密鍵)を使用します

Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを

「アプリケーションエンジニアが知るべきDNSの基本」というタイトルで、builderscon tokyo 2018 で登壇するスライドです

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に対応したHTTPサーバ「H2O」の開発を行うだけでなく、IETFでHTTP/3の標準策定にも関わるなど、日本においてもっともHTTP/3に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで

はじめに 今作業しているマシンが、インターネットへ通信するときに、送信元IPアドレスが何になるか知りたいときはないでしょうか。 そんなときに私が使っているのが、https://ifconfig.io/ というサービスです。 以下の特徴があります。 curl ifconfig.io で単純に IPアドレスだけ返ってくる JSON に対応 IPv6 に対応 http / https 両対応 個人的に覚えやすいアドレス（主にこの理由で使っています） 使い方 ブラウザで https://ifconfig.io を開くと大体の使い方が分かります。 サクッと curl ifconfig.io 単純に IP アドレスだけ知りたときは curl ifconfig.io を実行します。一番良く使います。 $ curl ifconfig.io 203.0.113.1 IPv6 での通信の場合は、IPv6 アド

(誤解されるのも嫌なので補足しておきますが、カテゴリ7や8という規格がゴミなのではなく、市販品のカテゴリ7や8が規格不適合のゴミという意味です) カテゴリ7Aとか8もありますが、7同様に買ってはいけないゴミなので今回は7とまとめて説明します。 カテゴリ5はやめよう そもそも売ってないと思いますが、カテゴリ5のケーブルは規格上100Mbpsまでなので買わないようにしましょう。 5e以上が安く手に入る今の時代にわざわざ買う必要はありません。 むしろ家の中に余ってるなら混在防止のために捨てて良いレベル。 1Gbpsなら5eでも十分 1Gbpsまでであればカテゴリ5eのケーブルでも問題ありません。 「帯域に余裕があるからカテゴリ6以上がおすすめ」という意見もあったりしますが、2.5倍の帯域があるからって1Gbpsが2.5Gbpsになったりする訳じゃない。(それどころか、2.5GBASE-Tも5eで