HTTP とは？ Web リクエストを支えるプロトコル

HTTP（Hypertext Transfer Protocol）は、ブラウザ、API、CI パイプラインがサーバーにデータを要求し、応答を受け取るために使うリクエスト・レスポンス型の言語です。

パイプラインがパッケージをダウンロードしたり、デプロイ API を呼び出したり、ヘルスチェックに ping を送ったりするたびに、それは HTTP を話しています。このプロトコルは、クライアントがどのようにリクエストを表現し、サーバーがどのように応答し、各メッセージの status、ヘッダー、body が何を意味するかを定義します。CI におけるネットワークエラーのほとんどは HTTP レスポンスとして現れるため、HTTP を理解するとパイプラインの障害がはるかに読み取りやすくなります。

リクエストとレスポンスの構造

HTTP リクエストには、メソッド（GET、POST、PUT、DELETE）、path、一連のヘッダー、そしてオプションの body があります。サーバーは status code、レスポンスヘッダー、そして通常は body で応答します。このリクエスト・レスポンスのペアが、ほぼすべての Web 通信の単位です。

HTTP メソッド

• GET はサーバーの状態を変更せずにデータを取得します。
• POST はデータを作成または送信します。
• PUT と PATCH は既存のリソースを更新します。
• DELETE はリソースを削除します。

設計上ステートレス

HTTP はステートレスです。各リクエストは独立しており、cookie やトークンを追加しない限り、サーバーは以前のリクエストを記憶しません。CI での API 呼び出しが、一度ログインするのではなく、すべてのリクエストで認証情報を送信しなければならないのはこのためです。

HTTP のバージョン

HTTP/1.1 はリクエストストリームごとに接続を開き、HTTP/2 は 1 つの接続で複数のリクエストを多重化し、HTTP/3 は低レイテンシのために QUIC 上で動作します。ほとんどの CI ツールは最適なバージョンを自動的にネゴシエートしますが、不一致が時折わかりにくいハングを引き起こすことがあります。

CI/CD で HTTP が登場する場面

パッケージのインストール、コンテナ registry の pull、artifact のアップロード、webhook の配信、デプロイ API の呼び出しは、すべて内部的には HTTP です。いずれかが失敗したとき、HTTP status code が最初の手がかりになります。4xx はリクエスト側を、5xx はサーバー側を、接続エラーはネットワークを指し示します。

パイプラインでの一時的な HTTP 障害

一瞬の不具合がリクエストの途中で接続を切断し、きれいな status code ではなく timeout や reset を生じさせることがあります。こうした一時的な HTTP 障害は通常、リトライしても安全です。Latchkey のマネージド runner では、一般的なエンドポイントへの短時間のネットワーク不具合は自動的にリトライされるため、1 回のリクエスト切断で job 全体が失敗することはありません。

重要なポイント

• HTTP は、ほぼすべての Web および API トラフィックを支える、ステートレスなリクエスト・レスポンス型プロトコルです。
• メソッドは意図を表し、status code は各リクエストの結果を表します。
• CI では、ネットワーク操作のほとんどが HTTP であるため、status code が最初のデバッグの手がかりになります。

関連ガイド