サーバー・インフラ

🚀 はじめに この記事でわかること 「証明書（SSL/TLS証明書）とは何か？」の基礎 ブラウザが「このサイトは本物だ」と判断する仕組み 証明書がないと何が危険なのか HTTPS の理解につながる最初の一歩 ✅ 概要解説 証明書とは何か？ 一言でいうと、 「このサイト（通信相手）は本物ですよ！」と証明する身分証明書のようなもの です。 ブラウザ（Chrome、Safari、Edge など）は、Web サイトにアクセスするときに必ず 「本当にそのサイトと通信しても大丈夫？」 と確認します。 そのとき使われるのが SSL/TLS 証明書 です。 何のためにあるのか？ 証明書には主に 2つの役割があります。 相手の正体（サイトの運営者）を確認する → 「このサイトは“本物の example.com” だよ」と証明 通信を暗号化するための“鍵”を安全に交換する → 誰にも見られないように、暗号化の準備をする つまり証明書は “信頼の証” と “暗号化の鍵の受け渡し” を同時に行う仕組み と言えます。 証明書がないとどうなる？ ブラウザのアドレスバーに ⚠️「保護されていない通信」 と出る パスワードや住所などの入力情報が 盗まれやすくなる サイトを装った偽物（フィッシング）に騙される可能性が上がる とくに Wi‑Fi（カフェ・学校など）では 盗み見リスクが大幅に増える どんな場面で使われている？ 実はあなたがスマホを使っているほぼ全ての場面で活躍しています。 ネットショッピング SNS（X、Instagram、TikTok） Gmail や Outlook などのメール オンライン授業、Web 会議 銀行や政府系サイト いまや Web サイトの 90％以上は HTTPS（証明書あり）で通信 しています。 ※HTTPS = 証明書を使った暗号化通信の仕組み ...

🚀 はじめに この記事でわかること TLS/SSL（ティーエルエス／エスエスエル）がどんな役割をしているのか https がなぜ「安全」と言われるのか 初心者でも理解しやすい身近なたとえで“暗号化”のイメージがつく ✅ 概要解説 TLS/SSLとは何か 一言で言うと、 あなた（ユーザー）とサイトの間でやり取りする情報に「鍵をかける」仕組み です。 インターネットでは、文字や画像などのデータが世界中のネットワークを通って移動します。その途中で、悪い人が盗み見ようとする可能性があります。 TLS/SSL は、その情報を暗号化（第三者が読めなくなる状態） にし、改ざんされていないかもチェックします。 「https://」から始まるサイトは、この TLS/SSL が使われている安全な通信です。 何のためにあるのか TLS/SSL には主に 3 つの役割があります。 盗み見防止（暗号化） メッセージを「暗号文」に変えて送るため、途中で盗み見られても読めません。 なりすまし防止（証明書） 本物のサイトかどうかを証明する「Web サイトの身分証明書」が使われます。 改ざん防止 途中でデータが書き換えられていないかチェックできます。 TLS/SSL がないとどうなるのか もし TLS/SSL が無いと… あなたの入力したパスワードが丸見え クレジットカード番号も盗まれるリスク 偽サイトに誘導されても気付きにくい 途中でデータを書き換えられても気付けない つまり、安心してネットを使えなくなってしまうのです。 どんな場面で使われる？ ログインページ（ID / パスワード入力） ネットショッピング（クレジットカード情報） お問い合わせフォーム メールサービス Web API・アプリ間通信 など 今では、ほぼすべての Web サイトで TLS/SSL が標準です。 💡 小話・豆知識・逸話 1) SSL は“古い名前”、いまは TLS が正式 「SSL」という言葉は昔の規格の名前ですが、世の中には今も「SSL 証明書」という言葉が残っています。 実は、技術的には「TLS」が現在の正式名称です。 でも「SSL のほうが聞き覚えがある」ため、いまだに広く使われています。 2) 暗号化は「鍵付きの手紙」 手紙を例えると… ...

🚀 はじめに この記事でわかること DNS（Domain Name System）がどんな役割を持つのか ドメイン名 → IPアドレスの変換がどう行われているか DNS がないとインターネットはどう不便になるのか DNS を理解すると Webがどう見えやすくなるか ✅ 概要解説 DNSとは何か？ DNSは“インターネットの住所録（電話帳）”のような仕組みです。 Google → google.com YouTube → youtube.com 私たちは普段、こうした文字の名前（ドメイン名） を入力してサイトにアクセスしますよね。 しかし、コンピュータが通信できるのは 192.0.2.1 のような数字（IPアドレス） だけ。 そこで必要なのが… DNS：ドメイン名 ⇔ IPアドレス の変換係 あなたが文字で書いた住所（ドメイン）を、 実際の家の場所（IPアドレス）に案内する役目です。 何のためにあるのか？ DNSがあることで、次のメリットが生まれます： 覚えやすい文字の名前でアクセスできる → 「2404:6800:4004:81a::200e」を覚えずに済む Webサイトの引っ越しが簡単 → サーバーが変わっても“住所録”を書き換えるだけ 世界共通のルールで案内できる DNSがないとどうなるの？ DNSがなければ、インターネットはとても不便になります。 毎回 数字のIPアドレスを丸暗記しないとアクセスできない サイトが移転するたびに 新しい数字を覚え直す必要がある そもそも URLを共有するのが難しい よく考えると、DNSがあるからこそ 「google.com を開いて」と言えるわけです。 どんな場面で使われているのか？ DNSは見えないところで、実はほぼ毎日働いています。 Webブラウザでサイトを開くとき スマホアプリがサーバーと通信するとき メールを送受信するとき 家庭のWi-Fiルータが通信先を調べるとき つまり、 インターネットが動く＝ほぼ確実にDNSが働いている というくらい重要な存在です。 💡 小話・豆知識・逸話 ① DNSは「階層」でできている DNSの仕組みは“町 → 市 → 都道府県 → 国”のような階層構造。 トップには 「.com」「.jp」「.net」などのトップレベルドメイン（TLD） がいます。 ...

🚀 はじめに この記事でわかること Terraformの設計の全体像（フォルダの切り方・モジュールの作り方・環境（dev/stg/prod）の分け方・ステート管理） なぜ設計が大事か、そしてよくあるつまずきポイントを先回りで回避する考え方 すぐ試せる最小サンプルと、次に学ぶと良い道しるべ ✅ 概要解説 Terraformの“設計”とは何か ざっくり言うと、レゴの設計図のことです。 どんな箱（フォルダ） に、どの部品（モジュール） を入れて、街（環境） ごとにどう並べ替えるか。 さらに、完成写真（状態＝ステート） をどこに保管するかを決めるのが設計です。 フォルダ構成… 作る物（ネットワーク・DBなど）と、使う場所（dev/stg/prod）をどう分けるか モジュール設計… レゴの「何度も使える下ごしらえ」パーツ化 ステート管理… いまの完成形（状態）を安全に記録・共有する 運用フロー… 変更はどうレビューして、どう適用（apply）するか ポイント：設計がきれいだと、「増築」「引っ越し」「片付け」がラクになります。 何のためにあるのか（設計が大事な理由） 事故を防ぐ（削除ミス・上書きミス・人によるバラつき） 再利用が効く（同じ作りを別環境で素早く展開） レビューしやすい（どこが変わるか差分が読みやすい） チームで回せる（誰が触っても同じルールで動く） 設計がないとどうなるの？ ぐちゃぐちゃに成長して壊すのが怖い（どこに何があるか不明） 環境ごとの差が増え、“本番だけ違う”地雷が生まれる ステートが人のPCにだけある → 事故・紛失・衝突（同時更新） レビューが困難 → ミスが見抜けず「動いたらOK」文化に逆戻り どんな場面で役立つ？ 個人の学習〜小さなチーム：まずはフォルダとモジュールを整えるだけで運用が楽に 複数クラウド・複数環境：再利用とステートの分離で安全にスケール 長期運用：CI/CD、Lint、セキュリティチェックを足して “壊れにくい仕組み” に 🧱 設計の基本パターン（フォルダ構成） A. “live + modules” 方式（いちばん読みやすい定番） repo-root/ ├─ modules/ # 再利用する部品置き場（レゴのパーツ箱） │ ├─ storage-bucket/ # 例: S3バケットを作るモジュール │ │ ├─ main.tf │ │ ├─ variables.tf │ │ └─ outputs.tf │ └─ ... # 他にも vpc/, rds/, dns/ など増やす └─ live/ # 実際に使う“現場”の設計図（街ごと） ├─ dev/ │ └─ app/ # サブシステム単位で分けてもOK │ ├─ main.tf │ └─ terraform.tfvars ├─ stg/ │ └─ app/ └─ prod/ └─ app/ modules/：何度も使える部品（バケット、VPCなど） live/：実際の環境（dev / stg / prod）側の呼び出し メリット：見通しが良く、レビューしやすい。環境を複製するのも簡単。 ...

🚀 はじめに この記事でわかること Terraform と Ansible の役割の違い（何を自動化するツール？） ないと何が大変？あると何が楽？ の具体例 超シンプルな実践チュートリアル（ローカルで安全に“雰囲気”を体験） 次に学ぶと良い関連テーマ ✅ 概要解説 Terraform・Ansibleとは何か 一言でいうと： Terraform = 「家（インフラ）を建てるための設計図と職人の指示書」 Ansible = 「建った家の中（サーバーの中身）を整える家事代行・内装業者」 Terraform（テラフォーム） クラウド（AWS/Azure/GCPなど）にサーバー、ネットワーク、ストレージといった “土台”を作る ツール。 “コード（HCL） でインフラを宣言”すると、そのとおりに作る／壊す／差分更新してくれます。 ＝ IaC（Infrastructure as Code） の代表選手。 Ansible（アンシブル） できあがったサーバーにソフトを入れる・設定を変える・ファイルを置くなどの “中身の整備”を自動化。 “プレイブック（YAML）”に手順を書くと、複数台に一気に同じ状態をつくってくれます。 ＝ 構成管理ツール の代表選手。 何のためにあるのか 人手の作業ミスを減らし、同じ結果を何度でも作れるようにするため 構築・設定のスピードアップ（環境差やメモ忘れをなくす） 設計や履歴がコードとして残るので、引き継ぎや再現が簡単に ないとどうなるの？ 手作業のクリックやコマンドが増え、うっかり設定漏れが発生 何が違って不具合なのか、“差”が追えない（再現が難しい） 人依存になりやすく、忙しい時ほど時間が溶ける どんな場面で使えるの？ Terraform： AWSで「EC2（サーバー）1台＋セキュリティ設定」を毎回安全に作る Azure/GCPでネットワーク＋VM＋ストレージの組み合わせを使い回したい 検証環境を作って壊すを何度も繰り返す Ansible： サーバーにNginxやApacheをインストールして同じ設定にする ユーザー追加・ログ設定・アプリ配布などの日常運用を自動化 10台・100台のサーバーに一気に同じ変更を適用 まとめ：Terraformは“外観と土台”、Ansibleは“内装と日々の暮らし” を整える役割と考えるとスッキリします。 💡 小話・豆知識・逸話 “宣言的”と“手続き的” Terraformは宣言的：「最終的にこうなっていてほしい」を書きます。 Ansibleも基本は宣言的ですが、タスクを順番に並べる手続き的な側面もわかりやすいです。 ⇒ “最終形を宣言”して、必要な操作はツールが計算してくれるのが気持ちよさの源。 手で作る→壊せない問題 人がクリックで作ったリソースは、どこで作ったか忘れがち。 Terraformで作れば terraform destroy で綺麗にお片付けできます。 ...

🚀 はじめに この記事でわかること 共有責任モデル（Shared Responsibility Model）が何か クラウドで 「どこまでがクラウド事業者」「どこからが自分の責任」 なのか もし誤解するとどうなるか、そして実際に何を気をつければよいか ✅ 概要解説 共有責任モデル（Shared Responsibility Model）とは何か クラウドを「マンション暮らし」にたとえるとわかりやすいです。 管理会社（クラウド事業者）は、建物そのもの（土台・エレベーター・廊下・防犯カメラ）を安全に保つ責任があります。 住人（あなた／あなたの会社）は、自分の部屋の鍵・窓・貴重品管理・家のルールを守る責任があります。 クラウドも同じで、土台のハードや電源、建物の入り口の警備（＝クラウド基盤） は事業者が守ります。でも、部屋の鍵（パスワード）、窓締め（設定）、貴重品の置き方（データの扱い） はあなたの責任です。 この分担ルールを、業界では 「共有責任モデル」 と呼びます（AWS・Azure・Google Cloud など大手はすべて採用）。 何のためにあるのか 誤解を防ぐため： 「クラウドに置けば全部安全でしょ？」というよくある誤解をなくし、誰が何を守るのかを明確にするため。 責任の分担を決めるため： セキュリティ事故が起きたとき、どの範囲を誰が対処するかをはっきりさせて、再発防止まで辿りやすくするため。 共有責任モデルがないとどうなるの？ 「誰の仕事？」があいまいになり、パスワード管理やアクセス制御の穴が放置されやすい 設定ミス（例：ストレージの公開設定ミス） による情報漏えいが増える 事故後に 「想定外だった」「聞いてない」 で対立し、復旧や改善が遅れる 実際、クラウドの事件で多いのは “土台の故障”ではなく、利用者側の設定ミスや認証管理の不備です。 共有責任モデルは、こうした “もったいない事故” を減らします。 どんな場面で使えるのか（サービス別のイメージ） クラウドの種類が変わると、分担の境界も少しずつ変わります。 IaaS（仮想サーバー等 / 例：Amazon EC2、Azure VM） 事業者：物理設備・ネットワーク・ハイパーバイザーなどの土台 あなた：OS設定・パッチ・ミドルウェア・アプリ・データ・ユーザー管理 PaaS（アプリ基盤 / 例：Azure App Service、Cloud Run） 事業者：OS〜ランタイムまで面倒を見る あなた：アプリ設定・コード・データ・ID/権限 SaaS（完成アプリ / 例：Google Workspace、Microsoft 365） 事業者：アプリ本体・基盤 あなた：利用者アカウント・多要素認証・共有設定・データ分類 まとめ：基盤に近いほど（IaaS）あなたの守備範囲は広く、完成品に近いほど（SaaS）狭くなります。 💡 小話・豆知識・逸話 「クラウドは“安全”だが“無敵”ではない」 大手クラウドは世界有数のセキュリティ投資をしています。ただし、それは土台の品質が高いという話。 パスワードの使い回しや公開設定ミスは、借り手（利用者）側の問題で、ここが事故の主因になりがちです。 ...

🚀 はじめに この記事でわかること サーバーレスとFaaS（Function as a Service） の意味と違い AWS Lambda / Google Cloud Functions / Azure Functions などの役割と使いどころ コストの考え方（使った分だけ課金）、コールドスタート、トリガーなどの基本用語 まず触ってみるための超ミニ手順・サンプルと、次に学ぶテーマ ✅ 概要解説 サーバーレス / FaaSとは何か 例えると、「必要なときだけ呼べる出前のシェフ」。 キッチン（サーバー）を自分で準備・片付けせず、料理（処理）を注文した瞬間だけ来て、終わったら帰るイメージです。 サーバーレス（Serverless） サーバーが「ない」わけではなく、サーバーの面倒（用意・更新・故障対応・伸縮）をクラウド側が隠してくれる考え方。 Web/API、データベース、認証、ストレージなど “組み合わせて作る”設計を指すことが多い広い言葉。 FaaS（Function as a Service） サーバーレスの中でも 「関数（小さなプログラム）」単位で実行する仕組み。 代表例：AWS Lambda / Google Cloud Functions / Azure Functions。 イベントが起きた瞬間だけコードが起動し、使った分だけ課金されます。 かんたんな全体像 [イベント] ──▶ [関数(コード)] ──▶ [結果/保存/通知] │ │ ├ HTTP リクエスト(API Gateway等) ├ スケジュール(毎日9時 etc.) ├ ストレージの更新(画像アップ時) └ キュー/メッセージ(非同期処理) ・常時サーバー起動なし（クラウドが必要時に起動） ・終わったら停止（課金も止まる） 何のためにあるのか（うれしいポイント） 運用がラク：OS更新、サーバー台数の増減、セキュリティパッチなど面倒ごとを任せられる コスト最適：使った分だけ課金（リクエスト数・実行時間・メモリ量で計算） 自動スケール：アクセス急増時も自動で並列実行が増える 小さく始めやすい：1ファイルの関数からすぐ動く。PoCや試作に最適 サーバーレス / FaaSが「ない」とどうなる？ 24時間サーバーを自前で運転：電源・監視・更新・バックアップ・伸縮など全部自分事 コストが固定化しがち：使わなくてもサーバー費が発生 急なアクセスに弱い：スケール設計ミスで落ちやすい（手動で増強は間に合わない） どんな場面で使える？ 画像の自動処理：アップロードされた写真を自動でリサイズ/サムネ生成 通知・連携ボット：フォーム送信→Slack/Teams通知、カレンダー連携 スケジュール作業：毎朝9時にレポート集計、夜間のデータ整理 APIの裏側：問い合わせフォーム→メール送信＋DB保存 イベント駆動の業務フロー：受注→在庫引き当て→請求書発行→メール 💡 小話・豆知識・逸話 「サーバーがない」わけじゃない サーバーレスは “サーバーの存在を意識しないで良い” という意味。実際はクラウド側の大量のサーバーが裏で動いています。 ...

🚀 はじめに この記事でわかること IaaS / PaaS / SaaS の意味と違いが、専門用語なしでスッと理解できます それぞれをいつ使うと便利か、使わないと何が困るかがイメージできます 初めての人でも、自分の用途に合う選び方のヒントが得られます ✅ 概要解説 クラウドとは何か インターネット越しに「必要なときだけ、必要な分だけ」コンピュータの力（サーバー・ソフト）を場所を選ばず使える仕組みです。 自分でサーバーを買って部屋で動かすのではなく、世界のどこかにある大規模な設備をオンラインで“貸し借り” します。 使った分だけお金を払う電気・水道のような料金が基本。 すぐに増やしたり（スケール）減らしたりできる柔軟さが魅力です。 IaaS / PaaS / SaaS の違い（ひとことで） IaaS（あいあーす）：サーバーそのものを借りる（建物の“骨組み”） PaaS（ぱーす）：アプリが動く土台を借りる（“キッチン付き賃貸”） SaaS（さーす）：完成したアプリをそのまま使う（“レストランで食べる”） 生活のたとえ（持ち家・賃貸・ホテル） 持ち家（オンプレミス）：土地から全部自分で用意・管理 賃貸（IaaS）：建物は用意済み、内装や家具（OS・アプリ）は自分で用意 家具付き賃貸（PaaS）：料理できるキッチンや家電（ランタイム／DB）までセット ホテル（SaaS）：入ったらすぐ使える（アカウント作成だけ） 何のためにあるのか 速く始められる：物理機器の準備が不要。思い立ったら即スタート ムダが少ない：使った分だけ支払い。余りや不足を減らしやすい 運用がラク：ハード故障対応、停電対策、冗長化など重い作業はクラウド側が担当 世界展開しやすい：世界中の拠点から近い場所で提供できる クラウドがないとどうなる？ 初期費用が大きい：サーバー・ネットワーク機器を最初に一括で購入 使わない時も維持費がかかる：電気・スペース・保守契約など 急なアクセス増に弱い：必要になってから機器を増やすのは時間もコストも重い 障害対応が大変：停電・故障・災害対策を自前で担う必要 どんな場面で使える？ IaaS：OSやミドルウェアを自由にカスタマイズしたい、既存システムをなるべくそのまま移したい 例）Amazon EC2 / Azure Virtual Machines / Google Compute Engine PaaS：アプリ開発に集中したい、サーバー管理やパッチ適用を減らしたい 例）Azure App Service / Google App Engine / AWS Elastic Beanstalk / Heroku ...

🚀 はじめに この記事でわかること ファイアウォールが何をする“守りの装置” なのか（基本の役割と種類） 使うと何が良くなるか（不正アクセスの防止、事故の予防）と、ないと起きがちなリスク 家庭・学校・会社・クラウドなど、どんな場面で役に立つかの具体例 ✅ 概要解説 ファイアウォールとは何か 家（あなたの端末やネットワーク）の“玄関ドア＋番犬＋名簿チェック” のような存在です。 インターネットでは、たくさんの“通信（手紙や荷物）”が行き来しています。 ファイアウォール（Firewall）は、その通信が入っていいか／出ていいかをルールに従ってチェックし、怪しいものを止める仕組みです。 パケットフィルタ（最も基本） 住所（IPアドレス）や部屋番号（ポート番号）を見て、通す／止めるを決めます。 ステートフル型（やや賢い） 「いま会話中の相手か？」といった通信の流れ（状態） を見て判断します。 プロキシ型（仲介役） 代理で受け取り・中継し、中身を詳しくチェックしてから渡します。 次世代型（NGFW） アプリ名（例：YouTube、Teams）など “中身の種類” まで見分け、侵入防止（IPS）やアプリ制御もできます。 ひとことで：「どこから・どこへ・何（どのアプリ）が・どのように通信するか」を見て、許可/拒否を決める“ネットの門番”。 何のためにあるのか 不正アクセスの防止：見知らぬ相手からの勝手な侵入をブロック 事故の予防：うっかり公開してはいけない扉（ポート） を閉める 被害の最小化：万一入られても広がりを抑える（セグメント分離） 記録（ログ）：何が通って何が止められたかを残し、原因調査に役立つ ファイアウォールがないとどうなるのか “玄関開けっ放し”状態になり、知らない人（不審な通信）が勝手に家に入れる ポートスキャン（扉チェック）や脆弱性のつつきに無防備 もし感染した端末があっても、社内や家庭内で横に広がりやすい（横感染） たとえば「リモート操作の扉（RDP:3389）」を外に開けっぱなしにしていると、世界中から自動的に試され続けることがよくあります。 “使わない扉は閉じる” が鉄則です。 どんな場面で使えるのか 家庭用ルーター：外からの着信は基本的に拒否（NATと併用） パソコンの内蔵ファイアウォール： Windows Defender Firewall（Windows） Application Firewall（macOS） アプリごと・ネットワークごと（自宅/職場/公衆）に細かく許可/拒否できます。 会社や学校の境界ファイアウォール： 社内ネットワークとインターネットの境界で出入りを一括管理。不審な通信を遮断。 クラウドの“仮想ファイアウォール”： AWSのセキュリティグループやネットワークACLなど、クラウドでも同じ考え方で設定します。 💡 小話・豆知識・逸話 名前の由来は「延焼防止の防火壁」 “Firewall”はもともと建物の防火壁の意味。火（攻撃）が広がらないように区切るところから来ています。 「Pingが通らない＝壊れてる」じゃない 会社やサイトがPing（ICMP）をわざと遮断していることは普通にあります。安全のための設定かもしれません。 “ステートフル”のいいところ 自分から話しかけた相手の返事だけ通す、という発想。会話の流れを見るので、余計な着信を自然と減らせます。 NATとファイアウォールは“相性がいい” 家庭用ルーターはNAT（部屋番号の付け替え）で外から直接見えにくくし、ファイアウォールでさらに扉を制御します。 いわゆる 「ポート開放」 は壁に穴をあける行為。必要最小限＋期間限定で！ “強すぎる設定”は正しい人も止める まずは記録（ログ）だけを取り、様子を見てからブロックに切り替えるのが現場の鉄則。 セキュリティと使いやすさのバランスがポイントです。 次世代ファイアウォール（NGFW）は“中身の種類”まで見られる アプリ識別や侵入防止（IPS）でより細かい制御が可能。 ただし万能ではないので、OSの更新・ウイルス対策・多要素認証など “重ね着の守り” と組み合わせます。 ...

🚀 はじめに この記事でわかること ポート番号が何のためにあるか（＝同じ住所の中の部屋番号のような役割） TCP と UDP の違い（配達の“受取サインあり/なし”の違い）と、それぞれが得意な場面 実生活のたとえ・図・簡単な表で、難しい数式なしに全体像をつかむ ✅ 概要解説 ポート番号とは何か 住所（IPアドレス）＋部屋番号（ポート）＋会話ルール（プロトコル） がそろって、はじめて正しいアプリへ届きます。 IPアドレス＝建物の住所 ポート番号＝建物の中の部屋番号（0〜65535の番号） プロトコル＝会話ルール（TCPかUDPが代表） 同じパソコン（同じ住所）でも、Webは「部屋 80/443」、メールは「部屋 25/587/993」など、アプリごとに部屋が違うから、迷子にならずに届きます。 TCP と UDP は何が違う？ 配達のイメージでいうと TCP＝“受取サイン付きの宅配便”（確実・順番通り・再送あり） UDP＝“ポスト投函のはがき”（速い・軽い・ただし届いた保証はない） 項目 TCP UDP 目的 確実に届ける・順番を保つ 速く軽く届ける（保証なし） 使いどころ Web（HTTP/HTTPS）、メール、ファイル転送 など 音声/動画通話、オンラインゲーム、DNS など 仕組み 通信前に握手（3ウェイハンドシェイク）して、欠けたら再送 握手しない。欠けても再送しないのが基本 体感 信頼性重視、多少遅くても正確 即応性重視、途切れに強い ポート番号は何のためにあるのか 同じPC（住所）で複数のサービス（部屋）を同時に動かすため ファイアウォールやNAT（ルーター） で、どの部屋に通すかを管理するため 世界共通の “よく使う部屋番号（ウェルノウンポート）” が決まっているため 例：80/tcp（HTTP）, 443/tcp（HTTPS）, 53/udp（DNS）, 25/tcp（SMTP） など もしポートとプロトコルがなかったら？ 配達先が曖昧：住所まで来てもどの部屋か分からず、正しいアプリに届かない 会話が通じない：違う言語（プロトコル）で話してしまい、理解不能 安全に振り分けられない：ファイアウォールも通す/止めるが判断できず、セキュリティが崩れる どんな場面で役立つ？ インターネットの不調の原因探し：「このアプリ、どのポートを使うんだっけ？」が分かる 自宅ルーターの“ポート開放”：オンラインゲームや自宅サーバー公開の基本のキ 会社のセキュリティ運用：特定ポートだけを許可して安全に業務アプリを通す 💡 小話・豆知識・逸話 どうして 0〜65535？ ポート番号は16ビット（2^16＝65536通り）。0〜1023は“ウェルノウンポート”と呼ばれ、代表的なサービスに割り当てられています。 代表的な“部屋番号”の一覧（よく出る） ...