新人エンジニアのための今度こそ理解するSSL/TLS超入門
はじめに Web開発やインフラに関わっていると、必ず目にするのがHTTPSです。 今や「HTTPではなくHTTPSが当たり前」という世界になっています。 一方で、こんな経験はありませんか？ 証明書エラーが出たけど、よく分からず無視した 「オレオレ証明書」と言われてもピンとこない HTTPSなのに「安全ではありません」と表示されて混乱した SSL/TLSは使うことは簡単ですが、何が起きているかを理解するのは意外と難しい技術です。 特に新人エンジニアのうちは、 「HTTPS ＝ 暗号化されていて安全」 というイメージだけで通り過ぎてしまいがちです。 しかし実際の SSL/TLS は、暗号化だけでなく「相手が本物かどうか」を確認する仕組みでもあります。 この記事で扱うこと・扱わないこと この記事では、SSL/TLS を 次の視点 から説明します。 TLSは何を守っているのか サーバーはどうやって
Azure の バックボーン や ネットワーク を図解してみる
こちらは Microsoft Azure Tech Advent Calendar 2025 1日目 の記事です。 はじめに Azure を支えるネットワークインフラ について、公式ドキュメント等にある情報をまとめつつ、図解しながら、その構造や通信の経路などを掘り下げてみます。特に バックボーン あたりをフォーカスして記載しています。また本記事とあわせ、本当に通信がインターネットに出てないか検証した記事も併せてご覧ください。 早速図解してみる - Azure ネットワークの概要 Azureのデータセンター内(左端) から オンプレミス拠点(右端) までのネットワーク概要 Azureのデータセンター内 個々のリソースまでのネットワーク概要 概ね全体像はこのようなイメージです。 Azure のリージョンを構成する複数のデータセンター同士は RNG (Regional Network Gatew
【第13回】Azureで社内システム再現（クラウド編）｜App Service と SQL の閉域接続を構築（VNet統合＋PE）
概要 これまでの「オンプレ編」では、Azure の仮想マシン（IaaS）を使って、社員番号から名前を検索できるシンプルな社内システムを構築してきました。Active Directory、SQL Server、ADFS などを組み合わせ、オンプレミスの構成を仮想的に再現しています。 ※全体構成の詳細は、【第0回】Azureで社内システム再現（オンプレ編）｜構成図と動作の流れ をご参照ください。 クラウド編では、これまでの構成をベースにしつつ、Azure のマネージドサービス（PaaS）を中心とした構成へ段階的に移行していきます。 ※クラウド移行全体の設計方針については、【第10.5回】Azureで社内システム再現（クラウド編）｜オンプレ構成をどうクラウドに移行するか？ にまとめています。 システム構成（今回の対象範囲） 今回のテーマは、Azure Web App から Azure SQL D
オンラインゲーム 10年の進化と同期方式の選び方 - きゅぶろぐ
オンラインゲームを作ろう！と思ったことがある方は、 こちらの講演記事を1度は見たことがあるのではないでしょうか。 www.4gamer.net こちらの講演は、具体例を交えながら非常に分かりやすくオンラインゲームの主な同期方式が説明してあり、 2024年現在でもオンラインゲームの基礎を学ぶ資料として真っ先に名前を上げる最高の資料です。 しかしながら講演は2010年のものであり、オンラインゲームはこの10年余りで進化しています。 この辺りの進化の話を簡単にまとめつつ、オンラインゲームの同期方式の選び方を紹介します。 （上記講演記事の知識/用語を前提としているため、先に上記記事をお読みください。） オンラインゲームの民主化について 技術の話をする前に。 近年、「マルチプレイヤーゲーム」と聞いてオフラインの画面分割ゲームを想像する人はいないと言って良いほど オンラインゲームは民主化されてきました
Webサーバーアーキテクチャ進化論2023
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
プロトコルスタックを写経してネットワークを完全に理解したかった日記
目次 1. プロトコルスタックのセットアップ Step 1: プロトコルスタックを初期化 Step 2: ネットワークデバイスをセットアップ Step 3: IPアドレスを登録 Step 4: プロトコルスタックを開始 2. Webサーバーの処理 Step 1: TCP OPEN Call ARP解決 コネクション確立 Step 2: TCP RECEIVE Call Step 3: TCP SEND Call Step 4: TCP CLOSE Call 3. プロトコルスタックの終了処理 おまけ：もう少し実用的なWebサーバーに改良してみた まとめ Webページはどうやって表示されるのでしょうか． 「ブラウザでアドレスバーにURLを入力してEnter押してからページが表示されるまでに何が起きているか説明してください」面接で使っていた質問が面白いと話題に 上記の質問には様々なレイヤーでの
QUICをゆっくり解説(17)：QUICビットとトランスポート・パラメータ | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 お久しぶりです。一家の引っ越しでバタバタしておりました。ようやく落ち着いてきましたので、「硬直化」をテーマとしてQUICに関して3つほど記事を書いてみようと思います。 硬直化 硬直化とは、中間装置が想定外の動作をすることによって、新しい機能の普及が困難になることです。硬直化の例としては、TCP Fast Openが完全に普及できないことが挙げられます。 TCPでは、コネクションを確立するために、いわゆる3WAYハンドシェイクが実行されます。通常は、クライアントがSYNパケットを送信し、サーバがSYN/ACKパケットを返し、その後クライアントがACKを返す際に初めてデータを送信できます。 もし最初のSYNパケットにデータを乗せることがで
シン・テレワークシステムは“グチャグチャグチャ”から生まれた 登大遊氏がやばい部屋で作った、インチキ自作システム | ログミーBusiness
未踏クリエータがもたらす新たな可能性を間近で体感できる場、「未踏会議」。未踏修了生たちが、未踏事業でのプロジェクトや、新たな技術への展望などについて話しました。【Special Discussion】では、村井純氏、登大遊氏が登壇。ファシリテータの田中邦裕氏を交えて、「世の中を動かす人たちの原動力」をテーマに語りました。全5回。2回目は、「シン・テレワークシステム」と「自治体テレワークシステム」を作った“グチャグチャグチャ”について。1回目はこちら。 “グチャグチャグチャ”から生まれた「シン・テレワークシステム」と「自治体テレワークシステム」田中邦裕氏（以下、田中）：登さんは、ソフトウェアで作ったものが使われてすごく普及してきたら、インフラ面までそれに合わせて作り変えていますよね。まずソフトウェアで作ることも重要だし、それを支えるインフラの部分も実は一体化して作らないといけない。そういうこ
「やはりインフラ作りは楽しくてしょうがない」 村井純×登大遊×田中邦裕が語る、日本のICTの課題と期待 | ログミーBusiness
未踏クリエータがもたらす新たな可能性を間近で体感できる場、「未踏会議」。未踏修了生たちが、未踏事業でのプロジェクトや、新たな技術への展望などについて話しました。【Special Discussion】では、村井純氏、登大遊氏が登壇。ファシリテータの田中邦裕氏を交えて、「世の中を動かす人たちの原動力」をテーマに語りました。全5回。1回目は、日本におけるICTの課題と、インフラ作りの楽しさについて。 インターネットの父、村井純氏田中邦裕氏（以下、田中）：よろしくお願いします。ここから60分間、登さんと村井先生という、濃いキャラを2人お迎えして、どのように進めていこうかと、悩ましいところですけれども、最大限お二人の魅力を引き出していきながら、けしからん話をしていければなと思っていますので、どうぞよろしくお願いします。 では、最初に自己紹介を軽くしていただければなと思います。お二人のことはみなさん
登大遊氏、日本は「超正統派」のICT人材を育成すべき。そのために、自由な試行錯誤を許容するインチキネットワークの普及に取り組む（前編）。JaSST'22 Tokyo
登大遊氏、日本は「超正統派」のICT人材を育成すべき。そのために、自由な試行錯誤を許容するインチキネットワークの普及に取り組む（前編）。JaSST'22 Tokyo 2022年3月10日と11日の2日間、ソフトウェア業界のテスト技術力の向上と普及を目指すイベント「ソフトウェアテストシンポジウム JaSST'22 Tokyo」がオンラインイベントとして開催されました。 イベントの最後には、招待講演として登大遊氏による講演「世界に普及可能な日本発の高品質サイバー技術の生産手段の確立」が行われています。 登氏は講演で、優れたICT技術を日本から生み出すためには「超正統派」なICT技術者を育てるべきであり、そのために登氏自身が中心となって登氏が「インチキネットワーク」と呼ぶ、固定IPアドレス取り放題でBGPで遊べる自由な試行錯誤を許容するネットワークとコンピューティングの環境を、IPA（独立行政法
QUICをゆっくり解説(14)：輻輳制御 | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 「フロー制御」の回で説明したように、輻輳制御とは途中のネットワークが溢れないようにするための仕組みです。QUICは、正確なRTT計測や、前回説明した簡潔なロス検知の機能を提供しています。このため輻輳制御としては、パケット欠落や遅延といったシグナルを使うアルゴリズムが利用可能です。RFC9002では、デフォルトの輻輳制御アルゴリズムとしてNewRenoを採用しています。 1990年に現れたRenoは、1995年に出されたアイディアに基づいて改良されNewRenoとなりました。2008年に提案されたCUBICや、2016年に現れたBBRに比べると、NewRenoは古い輻輳制御アルゴリズムです。QUICのデフォルトの輻輳制御に古いNewRe
QUICをゆっくり解説(10)：コネクションのマイグレーション | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 通信の途中で、クライアントのIPアドレスやポート番号が変更されることがあります。以下の2つが典型例です。 利用するネットワークが携帯網からWi-Fiに変わった (または、その逆) 中間のNATが、別のポート番号を割り当てた TCPでは、コネクションの識別子として両端のIPアドレスとポート番号を使っています。そのため、上記のような場面では、既存のコネクションは維持できなくなり、アプリケーションが通信を続けるには新たにコネクションを作成する必要があります。 一方QUICでは、コネクションの識別子としてコネクションIDを使います。コネクションIDは、IPアドレスやポート番号から独立した名前です。そこで、上記のような場面でもコネクションを継続
QUICをゆっくり解説(6)：増幅攻撃との戦い | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 増幅攻撃(amplification attack)とは、攻撃者が第三者の管理するサーバにデータの量を増幅させて標的に送りつけるDoS攻撃の一種です。 攻撃者は、小さなデータをサーバに送りつけます。このとき、IPパケットの始点アドレスに標的のIPアドレスを詐称して入れます。プロトコルによっては、サーバは大きな応答を返します。返答先は、標的のIPアドレスになります。 この攻撃にたくさんのサーバを利用すれば、攻撃者の回線には余裕があるが、標的の回線はパンクさせるという状況を実現できます。 攻撃者にとって、TCPには増幅効果を期待できません。攻撃者が送信するSYNのTCPセグメントと、サーバが返すSYN+ACKのTCPセグメントは大きさがほ
QUICをゆっくり解説(5)：2回目以降のハンドシェイクと0-RTT | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回はクライアントとサーバが初めてコネクションを確立する際に実行されるハンドシェイクについて説明しました。まだ、コネクションの切り方を説明してないので恐縮ですが、今回は1回目のコネクションが終了した後の2回目以降のハンドシェイクについてお話しします。 事前共有鍵 前回使ったQUICのハンドシェイク図を少し修正して以下に示します。 色の意味はこうでした。 薄い灰色：イニシャル鍵で暗号化されている 濃い灰色：ハンドシェイク鍵で暗号化されている 黒色：アプリケーションデータ鍵で暗号化されている イニシャル鍵は、クライアントが乱数的に作ったサーバのコネクションIDから生成されました。 ハンドシェイク鍵やアプリケーションデータ鍵は、鍵交換で共有
CDNは5時間で開発できる | POSTD
「CDN」（content delivery network）という言葉からは、Googleのような大企業がいくつもの巨大なハードウェアを管理し、1秒当たり何百ギガビットものデータを処理する様子が想像されます。しかし、CDNは単なるWebアプリケーションです。私たちのイメージとは違いますが、それが事実です。8年前に買ったノートパソコンを使って、コーヒーショップの席に座りながらでも、きちんと機能するCDNを構築できます。この記事では、これから5時間でCDNを開発しようとするときに、直面するかもしれないことを紹介します。 まずはCDNの機能を明らかにしておきましょう。CDNはセントラルリポジトリ（通称：オリジン）からファイルを吸い上げ、ユーザーに近い場所でコピーを保存します。初期のオリジンはCDNのFTPサーバーでした。現在、オリジンは単なるWebアプリとなり、CDNはプロキシサーバーとして機
QUICをゆっくり解説(4)：ハンドシェイク | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回は、QUICパケットとフレームの構造について説明しました。準備が整いましたので、今回はコネクションの確立時に実行されるハンドシェイクについて説明します。 トランスポート層を実装する場合、コネクションを確立する部分を作らないと何も通信できませんが、QUICはこのハンドシェイクの実装が結構難しく、実装者泣かせの仕様となっています。 TLS 1.3のハンドシェイク まずTCP上のTLS 1.3のハンドシェイクを以下の図を使って説明します。 最初にTCPのコネクションを張る必要があるので、お馴染みの TCP 3-way ハンドシェイクから始まります。 次にクライアントは、(楕円曲線)Diffie-Hellmanの系統を用いて、使い捨ての公
QUICをゆっくり解説(3)：QUICパケットの構造 | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回の説明では、「Initial パケット」や「Version Negotiation パケット」といった用語を未定義で使いました。今回は、こういった「パケット」や「フレーム」が、どのような構造を持っているかについて説明します。 古典的なパケット IP、UDP、およびTCPでデータをやり取りする基本単位は、すべて「ヘッダ＋ペイロード」という構造を持っています。このヘッダ＋ペイロードという単位は、それぞれ以下のように呼ぶのが慣習です。 IP – パケット UDP – データグラム TCP – セグメント すべてパケットと呼んでも間違いではありません。UDPの場合、IPペイロードが「UDPデータグラム(UDPヘッダ＋UDPペイロード)」に
QUICをゆっくり解説(2)：ネゴせよ | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 QUICへの誘導 前回のブログで、ブラウザが HTTP/3 (HTTP over QUIC) に対応したサーバにアクセスしたときに、最初は HTTP/2 を使い、2回目の通信からHTTP/3を使うようになると説明しました。今回は、この過程でクライアントとサーバが何を折衝しているか、以下の順で解説します。 TLSのバージョン HTTPのバージョン HTTP/2からHTTP/3への誘導 QUICのバージョン TLSのバージョン あるURLで指定されたサーバにクライアントがアクセスすることを考えます。URLは、httpsで始まっていたとしましょう。つまり、TLSの中でHTTPが使われます。現在推奨されているTLSのバージョンは、1.2と1.
QUICをゆっくり解説(1)：QUICが標準化されました | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを
ネットワークスペシャリスト - SE娘の剣 -
左門至峰の出るとこネスペ教科書 最短距離で合格できるネットワークスペシャリスト 増補改訂版左門 至峰日経BP2025-11-21 前回はネットワークスペシャリスト試験の令和5年までの内容でしたが、令和6年と令和7年の内容を反映しました。 ページ数は16ページ増えて、336ページになりました。この本は薄い本にしたかったので、増え過ぎないように注意しています。 それと、表に「分厚い本は読む気にならないあなたへ」とあるのに、前回の本は、紙の質を厚めにしてもらったらしく、意外に分厚かったです。 今回は、強い要望を出して、紙質をノーマルにしてもらいました。 左門至峰の出るとこネスペ教科書 最短距離で合格できるネットワークスペシャリスト (Usable Textbook) 左門 至峰 日経BP 2023-12-15 ★現在改定中なので、購入される方はご注意ください。 ネスペ教科書（改訂2版）ですが、前
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
