プロトコルとは？通信の約束ごとをHTTP・DNS・TLSの実際の会話で解説

Web ページを1枚開くだけでも、裏では DNS・TCP・TLS・HTTP という複数のプロトコルが順番に使われています。この記事では、それぞれのプロトコルを自分で立てたサーバーと実際に「会話」させ、その原文を見ながら説明します。

flowchart TD
    U[URL を入力] --> D[DNS：名前を IP アドレスに<br>UDP 53番]
    D --> T[TCP：3ウェイハンドシェイク<br>443番へ接続]
    T --> S[TLS：暗号の方式と証明書を確かめる]
    S --> H[HTTP：GET / を送り 200 OK を受け取る]
    H --> R[ブラウザが画面に表示]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（カーネル 6.18）の上に、ip netns でサーバー用（t43s・10.43.0.2）とクライアント用（t43c・10.43.0.1）の2つのネットワーク名前空間を作り、veth でつなぎました。サーバー側には、DNS に dnsmasq 2.91、HTTP に Python 3.13.18 の http.server、HTTPS（HTTP/1.1 と HTTP/2）に Node.js 22.23.4 の http2 モジュール、SMTP に aiosmtpd 1.4.6（受け取ったメールを画面に出すだけで、外へは送らない設定）を立てています。証明書は OpenSSL 3.0.13 で作った自分用の認証局で発行しました。クライアント側からは nc（netcat-openbsd）・curl 8.5.0・dig 9.18.39・openssl s_client で話しかけ、tcpdump 4.99.4 でパケットを記録しました。通信はすべてこの2つの名前空間の中だけで、外部のサーバーには問い合わせていません。HTTP/3（QUIC）は手元で動かしておらず、RFC と MDN で確かめた範囲で書いています。各プロトコルの定義は RFC（IETF）、ポート番号は IANA の登録簿と Ubuntu の /etc/services、外交と医療の意味は外務省・厚生労働省の公開ページで確かめました。図は mermaid で描画を確かめています（確認日 2026年10月29日）。

プロトコルとは（意味をひと言で）

この節では、プロトコルという言葉の意味と、なぜ約束ごとが要るのかが分かります。

プロトコル（protocol）とは、コンピューター同士がデータをやり取りするための決まりの集まりです。 MDN は「コンピューター内部またはコンピューター間でデータを交換する方法を定めたルールの体系」と説明しています。日本語では「通信規約」「通信手順」とも呼びます。

人どうしの電話にたとえると分かりやすくなります。

• 電話をかけたら、出た側が「もしもし」と言い、かけた側が名乗る（順番）。
• お互いに日本語で話す（言葉と形式）。
• 聞き取れなければ「もう一度お願いします」と返す（エラーのときの扱い）。
• 話が終わったら「失礼します」と言って切る（終わり方）。

コンピューターは「だいたい分かる」ができないため、この約束を1文字・1バイト単位で細かく決めておきます。決まりが文書として公開されているので、メーカーが違うパソコン・スマホ・サーバーでも、同じプロトコルに従っていれば通信できます。後の節で、実際にサーバーが 220・250・200 OK のような決まった言葉で返事をする様子を見ます。

語源と、IT以外での意味

protocol の語源はギリシャ語の protokollon で、文書の最初に貼り付けて内容や日付を記した1枚目の紙を指していました。そこから「公式の記録」「決められた手順・儀礼」という意味に広がり、ITでは「通信の決まり」の意味で使われています。外交や医療での意味は、後の節「IT以外の『プロトコル』（外交・医療・研究）」で短く説明します。

「プロトコルスタック」とは

1つのプロトコルですべてをまかなうのではなく、役割の違うプロトコルを積み重ねて使います。この積み重ねをプロトコルスタック（またはプロトコルスイート）と呼びます。インターネットで使われている積み重ねの代表が TCP/IP です。TCP/IP は TCP と IP の2つだけを指すこともありますが、多くの場合、HTTP・DNS・UDP などを含めたプロトコルの一式を指します。

プロトコルが決めていること（4つの要素）

この節では、1つのプロトコルの中に、具体的に何が書かれているのかが分かります。

プロトコルの仕様書には、だいたい次の4つが書かれています。 後の節で動かす HTTP を例にしています。

誰が決めているのか（IETF と RFC）

インターネットで使うプロトコルの多くは、IETF（Internet Engineering Task Force） という標準化の団体が議論し、RFC という番号つきの文書として公開しています。誰でも無料で読めます。この記事で動かしたプロトコルの主な RFC は次のとおりです。

Ethernet や Wi-Fi のように、IETF ではなく IEEE などの別の団体が決めているプロトコルもあります。

主要なプロトコルとポート番号の早見表

この節では、よく出てくるプロトコルの名前・役割・ポート番号が一覧で分かります。

ポート番号は、1台のコンピューターの中で「どのサービスと話すか」を指す番号です。 決まった番号（ウェルノウンポート）は IANA が登録簿で管理しています。Ubuntu の /etc/services にも同じ対応が書かれていました（抜粋）。

$ grep -wE '^(ftp|ssh|smtp|domain|http|pop3|imap2|https|submission|imaps|pop3s|submissions|bootps)' /etc/services
ftp		21/tcp
ssh		22/tcp				# SSH Remote Login Protocol
smtp		25/tcp		mail
domain		53/tcp				# Domain Name Server
domain		53/udp
bootps		67/udp
http		80/tcp		www		# WorldWideWeb HTTP
pop3		110/tcp		pop-3		# POP version 3
imap2		143/tcp		imap		# Interim Mail Access P 2 and 4
https		443/tcp				# http protocol over TLS/SSL
https		443/udp				# HTTP/3
submissions	465/tcp		ssmtp smtps urd # Submission over TLS [RFC8314]
submission	587/tcp				# Submission [RFC4409]
imaps		993/tcp				# IMAP over SSL
pop3s		995/tcp				# POP-3 over SSL

TCP・UDP・ICMP のような「IP の上に乗るもの」には、ポートとは別にプロトコル番号が付いています。Ubuntu の /etc/protocols の内容です。この番号は、後で見るパケットの中身にも現れます。

$ grep -wE '^(icmp|tcp|udp|ipv6-icmp)' /etc/protocols
icmp	1	ICMP		# internet control message protocol
tcp	6	TCP		# transmission control protocol
udp	17	UDP		# user datagram protocol
ipv6-icmp 58	IPv6-ICMP	# ICMP for IPv6

ポート番号の全体と、使っているポートの確かめ方は、関連記事「ポート番号一覧【2026年版】well-knownポートと確認コマンドの早見表」で扱っています。

通信プロトコルの階層（OSI参照モデルとTCP/IPの4層）

この節では、プロトコルが階層に分かれている理由と、OSI参照モデル・TCP/IP の対応、実際のパケットの中で階層がどう重なっているかが分かります。

通信の仕事を「層」に分け、層ごとに別のプロトコルが担当します。 下の層は上の層の中身を気にせず運ぶだけなので、Wi-Fi を有線に変えても HTTP はそのまま使え、HTTP を SMTP に変えても TCP はそのまま使えます。

flowchart TD
    A[アプリケーション層<br>HTTP・DNS・SMTP・TLS] --> T[トランスポート層<br>TCP・UDP・QUIC]
    T --> I[インターネット層<br>IP・ICMP]
    I --> L[リンク層<br>Ethernet・Wi-Fi・ARP]

OSI参照モデルは ISO が決めた「考え方の枠組み」、TCP/IP はインターネットで実際に動いている仕組みです。 TCP/IP の4層は RFC 1122 の分け方で、TLS がどの層に入るかは説明によって分かれます（この記事ではアプリケーション層の中の、HTTP のすぐ下に置いています）。7層それぞれの詳しい説明は、関連記事「OSI参照モデルとは｜7層の早見表とTCP/IP対応・パケット実例」で扱っています。

実際のパケットで階層を見る（DNS の問い合わせ1つ）

後の節で送った DNS の問い合わせ1つを、tcpdump で16進数のまま表示しました。96バイトの中に、4つの層のヘッダーが順に重なっています。

$ tcpdump -n -r cap_dns.pcap -XX
IP 10.43.0.1.39048 > 10.43.0.2.53: 52301+ [1au] A? shop.t43.test. (54)
	0x0000:  d25b 31fb 8b89 6662 15a3 a0b3 0800 4500  .[1...fb......E.
	0x0010:  0052 1ce4 0000 4011 495f 0a2b 0001 0a2b  .R....@.I_.+...+
	0x0020:  0002 9888 0035 003e 14a8 cc4d 0120 0001  .....5.>...M....
	0x0030:  0000 0000 0001 0473 686f 7003 7434 3304  .......shop.t43.
	0x0040:  7465 7374 0000 0100 0100 0029 04d0 0000  test.......)....

IP ヘッダーの 11（10進数で17）が /etc/protocols の udp 17、UDP ヘッダーの 0035（10進数で53）が /etc/services の domain 53 と一致しています。 外側の層が「中身は何のプロトコルか」を番号で示し、受け取った側はその番号を見て次の層へ渡します。

実験の準備（ip netns に自分のサーバーを立てる）

以降の節は、次の手順で作った環境で動かしています。外部のサーバーには何も送っていません。

$ ip netns exec t43s ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
udp   UNCONN 0      0          10.43.0.2:53        0.0.0.0:*    users:(("dnsmasq",pid=1524,fd=4))
tcp   LISTEN 0      5          10.43.0.2:80        0.0.0.0:*    users:(("python3",pid=1522,fd=3))
tcp   LISTEN 0      32         10.43.0.2:53        0.0.0.0:*    users:(("dnsmasq",pid=1524,fd=5))
tcp   LISTEN 0      100        10.43.0.2:25        0.0.0.0:*    users:(("python",pid=1525,fd=6))
tcp   LISTEN 0      511        10.43.0.2:443       0.0.0.0:*    users:(("node",pid=1523,fd=21))

DNS だけが UDP と TCP の両方で待ち受けていて、ほかは TCP だけです。どのプロトコルを、どのポートで話すかは、サーバーのプログラムが決めています。

DNSプロトコルを話させる（digの原文）

この節では、名前から IP アドレスを調べる DNS が、どんな質問と答えをやり取りしているかが分かります。

DNS は「shop.t43.test の IP アドレスは？」という質問に、DNS サーバーが「10.43.0.2」と答えるプロトコルです。 ブラウザは、URL の名前を最初に DNS で IP アドレスに変えてから接続します。dig で自分の DNS サーバー（10.43.0.2）に直接聞きました。

$ dig @10.43.0.2 shop.t43.test A
; <<>> DiG 9.18.39-0ubuntu0.24.04.8-Ubuntu <<>> @10.43.0.2 shop.t43.test A
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52301
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;shop.t43.test.			IN	A

;; ANSWER SECTION:
shop.t43.test.		0	IN	A	10.43.0.2

;; Query time: 0 msec
;; SERVER: 10.43.0.2#53(10.43.0.2) (UDP)
;; MSG SIZE  rcvd: 58

同じ時間に tcpdump で記録したパケットは、ARP の2つを除くと質問1つと答え1つの2パケットだけでした。接続の準備をしない UDP で送っているためです。

21:48:05.700790 ARP, Request who-has 10.43.0.2 tell 10.43.0.1, length 28
21:48:05.700802 ARP, Reply 10.43.0.2 is-at d2:5b:31:fb:8b:89, length 28
21:48:05.700804 IP 10.43.0.1.39048 > 10.43.0.2.53: 52301+ [1au] A? shop.t43.test. (54)
21:48:05.700958 IP 10.43.0.2.53 > 10.43.0.1.39048: 52301* 1/0/1 A 10.43.0.2 (58)

• 質問と答えの 52301 は同じ番号です。 DNS は問い合わせに番号（ID）を付け、答えにも同じ番号を付けて返す決まりになっています。dig の id: 52301 とも一致しています。
• 最初の2行の ARP は、リンク層のプロトコルです。「10.43.0.2 の MAC アドレスは？」と聞き、答えを得てから DNS のパケットを送っています。
• ほかの種類の質問もできます。MX（メールの宛先）と TXT（文字列）を聞いた結果です。

$ dig @10.43.0.2 t43.test MX +noall +answer
t43.test.		0	IN	MX	10 mail.t43.test.
$ dig @10.43.0.2 t43.test TXT +short
"hello from t43"
$ dig @10.43.0.2 shop.t43.test +tcp +noall +answer +stats
shop.t43.test.		0	IN	A	10.43.0.2
;; SERVER: 10.43.0.2#53(10.43.0.2) (TCP)

DNS は普段は UDP ですが、TCP でも同じ質問ができます。 答えが大きいときなどに TCP を使います。dnsmasq のログには、受け取った質問がそのまま残っていました。

dnsmasq[1524]: query[A] shop.t43.test from 10.43.0.1
dnsmasq[1524]: config shop.t43.test is 10.43.0.2

手元の dnsmasq は外に問い合わせない設定にしたため、知らない名前（nothing.t43.test）には status: REFUSED を返しました。インターネットにつながった一般の DNS サーバーなら、存在しない名前には NXDOMAIN を返します。レコードの種類ごとの意味は、関連記事「DNSレコードの種類一覧｜digの実出力で役割と設定ミスを確認」で扱っています。

TCPプロトコルの3ウェイハンドシェイク（tcpdumpの原文）

この節では、TCP が「接続」を作ってから終わるまでに、どんなパケットを交わしているかが分かります。

TCP は、データを送る前に3つのパケットで接続を作ります（3ウェイハンドシェイク）。 次の節で HTTP を送ったときの tcpdump の記録から、TCP の部分を抜き出しました（オプションの欄を省いています）。

10.43.0.1.46606 > 10.43.0.2.80: Flags [S],  seq 4281022964, win 64240, length 0
10.43.0.2.80 > 10.43.0.1.46606: Flags [S.], seq 3175756454, ack 4281022965, win 65160, length 0
10.43.0.1.46606 > 10.43.0.2.80: Flags [.],  ack 1, win 63, length 0
10.43.0.1.46606 > 10.43.0.2.80: Flags [P.], seq 1:59, ack 1, length 58: HTTP: GET / HTTP/1.1
10.43.0.2.80 > 10.43.0.1.46606: Flags [.],  ack 59, length 0
  ...（応答の送信）...
10.43.0.2.80 > 10.43.0.1.46606: Flags [F.], seq 206, ack 60, length 0
10.43.0.1.46606 > 10.43.0.2.80: Flags [.],  ack 207, length 0

• seq（順番の番号）と ack（どこまで受け取ったか）で、抜けや順番の入れ替わりに気づき、送り直します。サーバーの ack 59 は「58バイト目まで受け取った、次は59バイト目から」という意味です。
• HTTP の58バイトを送るのに、接続の準備と片付けを含めて12パケット・1,071バイトが流れました。確実に届ける代わりに、やり取りが増えます。

TCP の再送やタイムアウトで起きやすい問題は、関連記事「TCPの落とし穴8選｜TIME_WAIT・40ms遅延の正体」で扱っています。UDP で「届かない・順番が変わる」様子は「UDPとは｜TCPとの違い・ICMPとの関係を『届かない』実物で解説」で扱っています。

HTTPプロトコルを手で話す（ncとcurl -v）

この節では、Web の HTTP が、ただの文字のやり取りであることを、手でリクエストを打った結果で確かめられます。

HTTP/1.1 は人が読める文字で書かれたプロトコルです。 nc（netcat）で TCP の接続だけを作り、決まりどおりの文字を送ると、Web サーバーは答えを返します。

$ printf "GET / HTTP/1.1\r\nHost: shop.t43.test\r\nConnection: close\r\n\r\n" | nc -q 2 10.43.0.2 80
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.13.18
Date: Thu, 29 Oct 2026 12:48:11 GMT
Content-type: text/html
Content-Length: 19
Last-Modified: Thu, 29 Oct 2026 12:47:37 GMT

<h1>hello t43</h1>

1.1 で聞いたのに 1.0 で答えています。 Python の http.server は、既定で HTTP/1.0 で応答する作りです（公式ドキュメントの protocol_version の既定値）。クライアントとサーバーは、お互いが話せる版に合わせて会話を続けます。版の合わせ方まで決めておくのも、プロトコルの役目です。

同じことを curl の -v で行うと、送った行（>）と受け取った行（<）が分けて見えます。

$ curl -v --noproxy '*' --resolve shop.t43.test:80:10.43.0.2 http://shop.t43.test/
*   Trying 10.43.0.2:80...
* Connected to shop.t43.test (10.43.0.2) port 80
> GET / HTTP/1.1
> Host: shop.t43.test
> User-Agent: curl/8.5.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.13.18
< Content-type: text/html
< Content-Length: 19
<
<h1>hello t43</h1>

curl は相手が 1.0 で答えたのを見て「本文の後で接続を閉じる」と判断しています（assume close after body）。--resolve は、DNS に聞く代わりに名前と IP アドレスの対応を curl に直接教えるオプションです。ブラウザは前の節の DNS と、この節の HTTP を続けて行っています。

サーバーが返した200以外の番号の意味は、関連記事「HTTPステータスコード 一覧｜全コードの原因と対処・curl実例つき」で扱っています。

TLS（HTTPS）のプロトコルで何が隠れるか（openssl s_client）

この節では、HTTPS の S にあたる TLS が何をしていて、暗号化で何が外から見えなくなるのかが分かります。

HTTPS は、HTTP の会話を TLS というプロトコルで包んだものです。 TLS は、暗号の方式をそろえ、証明書で相手が本物か確かめてから、その後のデータを暗号化します。openssl s_client で自分の HTTPS サーバー（443番）に接続し、HTTP のリクエストを流しました。

$ printf 'GET / HTTP/1.1\r\nHost: shop.t43.test\r\nConnection: close\r\n\r\n' \
  | openssl s_client -connect 10.43.0.2:443 -servername shop.t43.test -CAfile ca.crt -alpn http/1.1 -brief -quiet
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = shop.t43.test
Hash used: SHA256
Signature type: ECDSA
Verification: OK
Server Temp Key: X25519, 253 bits
HTTP/1.1 200 OK
content-type: text/plain; charset=utf-8
Connection: close
Content-Length: 26

hello over HTTP/1.1 + TLS

上半分が TLS の取り決めの結果、下半分は前の節と同じ HTTP です。TLS の上では、HTTP はまったく同じ文字の会話をしています。 curl の -v では、TLS のハンドシェイクの段階が1つずつ表示されます。

$ curl -v --http1.1 --cacert ca.crt --resolve shop.t43.test:443:10.43.0.2 https://shop.t43.test/
* Connected to shop.t43.test (10.43.0.2) port 443
* ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=shop.t43.test
*  subjectAltName: host "shop.t43.test" matched cert's "shop.t43.test"
*  issuer: CN=t43 Test CA
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: shop.t43.test
...
< HTTP/1.1 200 OK
hello over HTTP/1.1 + TLS

1. 1Client hello（クライアント→サーバー）使える暗号の方式・接続したい名前（SNI）・使いたい上のプロトコル（ALPN）を伝える
2. 2Server hello〜Finished（サーバー→クライアント）方式を決め、証明書と署名を送る。ここから先は暗号化される
3. 3証明書の確認（クライアントの中）信頼する認証局が発行したか・名前が合っているか・期限内か
4. 4Finished（クライアント→サーバー）取り決めが終わり、HTTP のリクエストを暗号化して送る

TLS 1.3（RFC 8446）では、クライアントが1回送り、サーバーが1回返すだけで取り決めが終わります。

パケットの記録で比べた HTTP と HTTPS

同じ「GET / を送って答えをもらう」を、暗号化なし（80番）と HTTPS（443番）で tcpdump に記録して比べました。

$ tcpdump -n -r cap_http.pcap -A | grep -E 'GET /|Host:|hello t43'
... length 58: HTTP: GET / HTTP/1.1
Host: shop.t43.test
<h1>hello t43</h1>

$ tcpdump -n -r cap_tls.pcap -A | grep -c 'GET /'
0
$ tcpdump -n -r cap_tls.pcap -A | grep -o 'shop.t43.test' | head -1
shop.t43.test

証明書の作り方や、openssl のほかの使い方は、関連記事「opensslコマンドの使い方｜目的別一覧と実行結果・エラー対処【3系】」で扱っています。

SMTPプロトコルでメールを送る会話（ncの原文）

この節では、メールを送る SMTP が、サーバーと交互に短い言葉をやり取りするプロトコルであることが分かります。

SMTP は、サーバーが先にあいさつし、クライアントが1行ずつ命令を送り、サーバーが3桁の数字で答えるプロトコルです。 自分の SMTP サーバー（受け取ったメールを画面に出すだけ）に nc で接続し、命令を1行ずつ送りました。>> の行がこちらから送った命令です（見やすいように並べ直しています）。

$ nc 10.43.0.2 25
220 localhost Python SMTP 1.4.6
>> EHLO client.t43.test
250-localhost
250-8BITMIME
250 HELP
>> MAIL FROM:<alice@t43.test>
250 OK
>> RCPT TO:<bob@t43.test>
250 OK
>> DATA
354 End data with <CR><LF>.<CR><LF>
>> From: alice@t43.test
>> To: bob@t43.test
>> Subject: protocol test
>>
>> Hello Bob.
>> .
250 OK
>> QUIT
221 Bye

サーバー側は、受け取ったメールを次のように表示しました。外へは送っていません。

---------- MESSAGE FOLLOWS ----------
From: alice@t43.test
To: bob@t43.test
Subject: protocol test
X-Peer: ('10.43.0.1', 38016)

Hello Bob.
------------ END MESSAGE ------------

• 2で始まる数字は成功、3は「続きを送って」、4は一時的な失敗、5は失敗という分け方は、SMTP（RFC 5321）の決まりです。HTTP の 2xx・4xx・5xx と考え方が似ています。
• 封筒（MAIL FROM・RCPT TO）と、中の手紙（From:・To: のヘッダー）は別物です。 実際に配達先を決めているのは RCPT TO の方です。
• メールを読む側のプロトコル（IMAP・POP3）は、送る SMTP とは別のプロトコルです。違いとポートは「IMAPとは｜POP3・SMTPとの違いとポート・設定をコマンド原文で」で扱っています。

実際のメールサーバーは、ここに STARTTLS（途中から TLS に切り替える命令）や認証（AUTH）が加わります。手元のサーバーは TLS を設定していないため、STARTTLS には 454 TLS not available と答えました。

HTTP/1.1・HTTP/2・HTTP/3の違い（プロトコルの版）

この節では、同じ HTTP でも版によって何が違うのかと、版の違いが通信の量にどう表れるのかが分かります。

HTTP の「意味」（GET・200・ヘッダー）は版が変わっても同じで、運び方が変わっています。 RFC 9110 が共通の意味を決め、運び方を RFC 9112（1.1）・9113（2）・9114（3）が決めています。

手元の HTTPS サーバーは HTTP/1.1 と HTTP/2 の両方を話せます。curl に --http2 を付けると、TLS の ALPN で h2 が選ばれ、ヘッダーの送り方が変わりました。

$ curl -v --http2 --cacert ca.crt --resolve shop.t43.test:443:10.43.0.2 https://shop.t43.test/
* ALPN: curl offers h2,http/1.1
* ALPN: server accepted h2
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://shop.t43.test/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: shop.t43.test]
* [HTTP/2] [1] [:path: /]
< HTTP/2 200
< content-type: text/plain; charset=utf-8
hello over HTTP/2.0 + TLS

HTTP/2 では、1行目の GET / HTTP/1.1 が :method・:path などの「疑似ヘッダー」に分かれ、Host は :authority になります。[1] はストリーム（1本の接続の中の通り道）の番号です。

6つのファイルを同時に取ったときの接続数

6つの URL を curl の --parallel で同時に取り、tcpdump で接続の数（SYN の数）とパケットの数を数えました。

HTTP/1.1 は6本の接続を作り、それぞれで TCP と TLS の準備をしました。HTTP/2 は1本の接続の中に6つのリクエストを並べ、パケットは約3分の1でした。 同じ内容を取っても、プロトコルの版で通信の形がここまで変わります。

HTTP/3 は、TCP の代わりに QUIC（RFC 9000）という UDP の上のプロトコルを使います。手元の curl 8.5.0（Ubuntu の版）は HTTP/3 に対応しておらず、HTTP/3 は RFC と MDN で確かめた範囲で書いています。/etc/services に https 443/udp # HTTP/3 とあるのは、この使い方を表しています。

プロトコルが合わないと何が起きるか（よくあるエラー原文）

この節では、プロトコルやポートを間違えたときに出るエラーの文言と、その意味が分かります。

「相手と話しているプロトコルが違う」ことは、エラーの文言から読み取れます。 手元でわざと間違えて出した原文です。

HTTP のサーバーに TLS で話しかけたとき、サーバー側のログには次の行が残りました。

10.43.0.1 - - [29/Oct/2026 21:48:52] code 400, message Bad request version ("KR\\x1b#\\x11;...")
10.43.0.1 - - [29/Oct/2026 21:48:52] "\x16\x03\x01\x02\x00\x01\x00\x01ü\x03\x03..." 400 -

先頭の \x16\x03\x01 は TLS の Client hello の始まり（16進数の16は TLS の「ハンドシェイク」の種類）です。HTTP のサーバーは、それを「GET の行」として読もうとして、読めずに400を返しました。お互いが自分のプロトコルの決まりで相手の言葉を読もうとしている様子が、そのまま残っています。

• 1URL の先頭（http:// か https://）とポートの組み合わせ80番は http、443番は https が基本。wrong version number と Empty reply はこの食い違い
• 2相手が本当にそのポートで待ち受けているかサーバー側で ss -tulpn。Connection refused は待ち受けが無い
• 3TCP か UDP かDNS・DHCP・HTTP/3 は UDP を使う。TCP だけ通す設定では届かない
• 4証明書の名前・認証局・期限curl (60) は TLS の確認の失敗。-k で確認を切って済ませない
• 5命令の順番SMTP の 503 のように、プロトコルには順番の決まりがある

どのプロトコルを使うか（用途別の判断表）

この節では、やりたいことから、使うプロトコルと確かめ方を引けます。

プロトコルは「何をしたいか」で決まります。 初めて触るときは、次の表の「確かめるコマンド」で実際の会話を見ると、決まりが早く身につきます。

FTP の会話と、暗号化の無いパスワードの扱いは「FTPとは｜仕組み・ポート・SFTPとの違いをtcpdumpの実物で」、DHCP の4つのやり取りは「DHCPとは｜仕組み・DORAの流れをtcpdumpの実物で解説」、telnet でポートに手で話しかける方法は「telnetコマンドの使い方｜ポート確認・終了方法・エラー原文と対処」で扱っています。

IT以外の「プロトコル」（外交・医療・研究）

この節では、IT 以外の分野で使われる「プロトコル」の意味が分かります。

どの分野でも「みんなが従う決まった手順」という芯は同じです。

外務省は、プロトコールを「国家間の儀礼上のルールで、外交を推進するための潤滑油の役割を果たすもの」と説明しています。国の大小に関係なく平等に扱い、誰もが納得するルールに従う、という考え方は、メーカーに関係なく同じ決まりで話す通信プロトコルとよく似ています。

よくある質問

Q. プロトコルとは、簡単に言うと何ですか？ A. 通信の約束ごとです。どんな形のデータを、どの順番で送り、失敗したら何を返すかを決めたもので、同じプロトコルに従えばメーカーや OS が違う機器同士でも通信できます。

Q. プロトコルにはどんな種類がありますか？ A. 役割ごとに、Web の HTTP・HTTPS、名前を調べる DNS、メールの SMTP・IMAP・POP3、ファイル転送の FTP・SFTP、遠隔ログインの SSH、IP アドレスを配る DHCP、運ぶ役の TCP・UDP・IP、暗号化の TLS などがあります。この記事の「主要なプロトコルとポート番号の早見表」にまとめています。

Q. プロトコルとポート番号は同じものですか？ A. 別のものです。プロトコルは「話し方の決まり」、ポート番号は「どのサービスに話しかけるか」を指す番号です。HTTP は普通80番を使いますが、8080番など別の番号でも HTTP は話せます。手元の SMTP サーバーに HTTP の GET を送ると、ポートは開いていても「command "GET" not recognized」と返されました。

Q. TCP/IP とは何ですか？ A. インターネットで使われているプロトコルの一式（プロトコルスタック）です。狭い意味では TCP と IP の2つですが、多くは HTTP・DNS・UDP などを含めた全体を指し、リンク層・インターネット層・トランスポート層・アプリケーション層の4層で説明します。

Q. OSI参照モデルは何の役に立ちますか？ A. 通信の仕事を7つの層に分けた考え方の枠組みで、「どの層で問題が起きているか」を話すときの共通の言葉になります。ケーブルが抜けている（1層）、IP アドレスが違う（3層）、ポートが閉じている（4層）、証明書が違う（TLS）、のように切り分けに使えます。

Q. HTTP と HTTPS のプロトコルの違いは何ですか？ A. HTTPS は、HTTP の会話を TLS で暗号化したものです。手元で記録したパケットでは、HTTP は「GET / HTTP/1.1」がそのまま読めましたが、HTTPS では0件でした。HTTPS でも接続先の IP アドレスと、Client hello の中の名前（SNI）は見えます。

Q. プロトコルは誰が決めているのですか？ A. インターネットのプロトコルの多くは IETF が議論し、RFC という文書で公開しています。Ethernet や Wi-Fi は IEEE、OSI参照モデルは ISO など、分野ごとに標準化の団体があります。RFC は誰でも無料で読めます。

Q. HTTP/2 や HTTP/3 にすると、何が変わりますか？ A. 意味（GET・200 など）は同じで、運び方が変わります。手元で6つのファイルを同時に取ると、HTTP/1.1 は6本の接続・92パケット、HTTP/2 は1本の接続・34パケットでした。HTTP/3 は UDP の上の QUIC を使い、TCP を使いません。

Q. 「プロトコル違反」「プロトコルエラー」とは何ですか？ A. 相手が決まりと違う形や順番でデータを送ってきたときのエラーです。手元では、SMTP で順番を守らないと「503 Error: send HELO first」、HTTP のサーバーに TLS で話しかけると「400 Bad request version」が返りました。外交の場で「プロトコール違反」と言うときは、儀礼のルールに反したという意味です。

Q. 初学者は、どの順番でプロトコルを学ぶとよいですか？ A. ふだん使っている順に、HTTP（curl -v で会話を見る）→DNS（dig で名前を調べる）→TCP と UDP（tcpdump で接続を見る）→TLS（証明書と暗号化）→IP アドレスとルーティング、と進めると、それぞれのプロトコルが「何のためにあるか」を実物で確かめながら覚えられます。

まとめ

• プロトコルとは通信の約束ごとで、データの形・やり取りの順番・相手の指定・エラーの返し方を決めている。IETF の RFC などで公開され、メーカーが違っても話が通じる。
• 役割の違うプロトコルを層に重ねて使う。TCP/IP は4層、OSI参照モデルは7層。手元の DNS のパケット96バイトの中に、Ethernet・IP・UDP・DNS のヘッダーが順に重なっていた。
• 自分のサーバーと話させると、DNS は質問と答えの2パケット、HTTP は文字の会話、SMTP は 220・250・354・221 の数字の返事、TLS は Client hello から始まる取り決めだった。
• HTTPS では「GET /」などの中身が記録から読めなくなる（0件）が、IP アドレスと SNI の名前は見える。HTTP/2 は6つのリクエストを1本の接続で運び、パケットは HTTP/1.1 の約3分の1だった。
• wrong version number・Empty reply・command not recognized は「プロトコルとポートの食い違い」、Connection refused は「待ち受けが無い」、curl (60) は「TLS の証明書の確認の失敗」。

参考・出典

確認日はいずれも 2026年10月29日です。

• MDN「プロトコル」（用語集）：https://developer.mozilla.org/ja/docs/Glossary/Protocol
• MDN「HTTP の進化」：https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Evolution_of_HTTP
• IETF「RFC 791 Internet Protocol」：https://www.rfc-editor.org/rfc/rfc791
• IETF「RFC 9293 Transmission Control Protocol (TCP)」：https://www.rfc-editor.org/rfc/rfc9293
• IETF「RFC 768 User Datagram Protocol」：https://www.rfc-editor.org/rfc/rfc768
• IETF「RFC 1035 Domain Names - Implementation and Specification」：https://www.rfc-editor.org/rfc/rfc1035
• IETF「RFC 1122 Requirements for Internet Hosts - Communication Layers」：https://www.rfc-editor.org/rfc/rfc1122
• IETF「RFC 9110 HTTP Semantics」：https://www.rfc-editor.org/rfc/rfc9110
• IETF「RFC 9112 HTTP/1.1」：https://www.rfc-editor.org/rfc/rfc9112
• IETF「RFC 9113 HTTP/2」：https://www.rfc-editor.org/rfc/rfc9113
• IETF「RFC 9114 HTTP/3」：https://www.rfc-editor.org/rfc/rfc9114
• IETF「RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport」：https://www.rfc-editor.org/rfc/rfc9000
• IETF「RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3」：https://www.rfc-editor.org/rfc/rfc8446
• IETF「RFC 5321 Simple Mail Transfer Protocol」：https://www.rfc-editor.org/rfc/rfc5321
• IANA「Service Name and Transport Protocol Port Number Registry」：https://www.iana.org/assignments/service-names-port-numbers/
• Python ドキュメント「http.server」（BaseHTTPRequestHandler.protocol_version）：https://docs.python.org/ja/3/library/http.server.html
• curl「SSL Certificate Verification」：https://curl.se/docs/sslcerts.html
• 外務省「グローカル外交ネット」（儀典官室における業務）：https://www.mofa.go.jp/mofaj/gaiko/local/page23_003218.html
• 厚生労働省「治験のルール『GCP』」：https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/fukyu2.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。