HTTP (Hypertext Transfer Protocol)

HTTP(Hypertext Transfer Protocol)는 클라이언트가 요청을 보내고 서버가 응답을 돌려주는 방식과 메시지의 의미를 정하는 응용 계층 통신 규약입니다. 웹페이지뿐 아니라 이미지와 API 데이터 등을 주고받는 데 쓰입니다. 주소와 요청 메서드, 헤더, 응답 상태를 함께 읽어야 어떤 자원에 무슨 처리를 요청했고 결과가 무엇인지 알 수 있습니다.

요청과 응답의 구성

HTTP 의미 명세 RFC 9110은 HTTP의 공통 의미와 요청·응답 규칙을 정의합니다. 클라이언트는 요청 대상과 메서드, 필요한 헤더와 내용을 보냅니다. 서버는 상태 코드와 헤더, 필요한 응답 내용을 돌려줍니다. 같은 주소라도 조회를 요청했는지 데이터를 제출했는지에 따라 처리 의미가 달라집니다.

MDN의 HTTP 개요는 브라우저가 HTML을 받은 뒤 이미지와 스크립트 등 필요한 자원을 추가로 요청하는 흐름을 설명합니다. 화면 하나를 여는 일이 요청 하나로 끝나지 않을 수 있습니다. 첫 페이지의 응답이 성공해도 이후 API나 자원 요청이 실패하면 화면의 일부 기능이 작동하지 않을 수 있습니다.

GET과 POST 같은 메서드는 서버에 요청하는 동작의 의미를 전달합니다. 헤더는 내용 유형이나 인증 정보, 캐시 조건 같은 추가 정보를 담을 수 있습니다. 응답 본문을 JSON으로 읽으려면 실제로 어떤 형식이 왔는지 확인해야 합니다. HTTP를 사용한다는 사실만으로 모든 응답이 같은 데이터 구조를 갖거나 같은 인증 방식으로 호출된다고 보지는 않습니다.

상태 없음과 연결 상태의 구분

HTTP는 각 요청의 의미를 독립적으로 해석할 수 있는 상태 없는 규약으로 설명됩니다. 그렇다고 웹서비스가 로그인 상태나 장바구니를 기억할 수 없다는 뜻은 아닙니다. 애플리케이션은 쿠키와 서버의 세션 정보 같은 수단을 이용해 여러 요청을 같은 이용자와 연결합니다. 통신 규약의 성질과 서비스가 관리하는 업무 상태는 서로 다른 범위입니다.

HTTP의 요청·응답 관계와 실제 네트워크 연결도 일대일로 고정되지 않습니다. 하나의 연결을 재사용하거나 중간 프록시와 캐시를 거쳐 응답을 받을 수 있습니다. 이용자의 요청이 어느 구간을 거치는지에 따라 관찰되는 지연과 헤더가 달라집니다. 오류를 조사할 때는 클라이언트, 중간 서버, 원본 서버의 기록을 같은 요청으로 연결해 보는 것이 도움이 됩니다.

HTTPS는 HTTP 통신을 암호화하고 서버 인증 등을 제공하는 보안 전송 방식과 연결됩니다. 통신 경로에서 데이터를 보호하는 것과 서버의 응용 프로그램이 올바르게 동작하는 것은 별개의 문제입니다. HTTPS 주소로 접속됐어도 권한 검사가 빠지거나 서버에 잘못된 데이터가 저장되는 문제는 남을 수 있습니다. 연결 보호와 앱의 기능·접근 제어는 따로 검증합니다.

버전과 실제 통신 결과

MDN의 HTTP 발전 과정은 HTTP/1.1, HTTP/2, HTTP/3의 전송 방식 차이를 설명합니다. HTTP/2는 메시지를 바이너리 프레임으로 다루고 여러 흐름을 처리하며, HTTP/3는 QUIC을 사용합니다. 이런 차이가 있어도 메서드와 상태 코드 같은 공통 의미를 기준으로 요청과 응답을 이해할 수 있습니다.

새 버전을 지원한다는 것과 모든 접속이 그 버전을 사용한다는 것은 다릅니다. 클라이언트와 서버, 중간 네트워크의 지원 조건에 따라 실제 연결이 달라질 수 있습니다. 속도가 좋아졌다고 주장하려면 버전 이름뿐 아니라 같은 요청 조건에서 측정한 결과가 필요합니다. 응답 내용이 캐시에서 왔는지와 연결을 새로 만들었는지도 시간 해석에 영향을 줍니다.

API를 확인할 때는 요청 주소와 메서드, 상태 코드, 헤더, 실제 본문을 함께 남깁니다. 정상 응답을 받았어도 기대한 문서나 필드가 있는지 확인하고, 오류 응답이면 어느 단계가 실패했는지 좁힙니다. 스트리밍에서는 응답을 시작한 뒤 중간에 전송이 끊어질 수도 있습니다. 처음 받은 상태와 필요한 내용을 끝까지 수신한 결과를 구분하면 통신 성공을 과장하지 않게 됩니다.