🚉「TCPとUDP、どっちで通ってる？」
🚉 1駅目：通信の“ルールブック”＝プロトコル
- パソコンやスマホがデータを送受信するには、決まった手順＝通信プロトコルが必要です。
- HTTPもSSHもDNSも、みんな“使ってるルール”が違います。
💡 プロトコルが合っていないと、通信が成立しません。
🚉 2駅目：TCPとUDP、どう違う？
インターネットの主な通信プロトコルは2つ：
| 項目 | TCP | UDP |
|---|---|---|
| 接続の仕組み | あり（3-way handshake） | なし（即送信） |
| 信頼性 | 高い（再送・順序保証） | 低い（確認なし） |
| 速度 | やや遅い（手順が多い） | 速い（軽量） |
| 代表的な用途 | Web（HTTP/S）、メール、SSH | DNS、NTP、動画配信、VoIP |
📌 TCP＝信頼第一、UDP＝スピード勝負
🚉 3駅目：実務での使い分けと確認方法
🔹 TCPでよく使うコマンド
telnet [IP] [port]→ ポート疎通確認（TCPのみ）curl http://...→ HTTPなどアプリレベルでも確認可能
🔹 UDPの確認はちょっと難しい
pingのように“返事がある”ことを前提にしていない- DNS（UDP53）やNTP（UDP123）は、アプリの応答でしか判断できないことも
🔹 よくあるミス
- UDPサービスなのにtelnetで確認して「つながらない！」と勘違い
- FWでUDPだけ閉じていて気づけない → “通信できない”原因に
🧳 降車前メモ（まとめ）
- 通信は「プロトコル」というルールに従って行われている
- TCP＝接続と信頼を重視、UDP＝即時性と軽さを重視
- 確認方法も違うので、“何で通ってるか”を意識することが重要
🚉 次回予告：
4日目「pingって、何が見えてるの？」
通信確認といえばping。でもただ返ってくればOKじゃない？
実は“反応時間”や“パケットロス”からトラブルのヒントが隠れています！
コメント