HTTP/HTTPS
HTTP(HyperText Transfer Protocol)는 클라이언트와 서버가 데이터를 주고받는 규약입니다. 메서드(GET, POST, PUT, DELETE)로 의도를 표현하고, 상태 코드(200, 404, 500)로 결과를 전달합니다. HTTPS는 HTTP에 TLS 암호화를 더한 보안 버전입니다.
▶아키텍처 다이어그램
🔄 프로세스 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
TCP가 서버까지 바이트를 안전하게 전달해 준다고 해서 곧바로 웹 서비스가 되는 것은 아닙니다. 브라우저는 문서를 요청하고 싶고, API 클라이언트는 데이터를 저장하거나 조회하고 싶고, 서버는 결과가 성공인지 실패인지 의미 있게 돌려줘야 합니다. 요청의 의도, 대상 자원, 인증 정보, 캐시 정책, 응답 결과를 표현하는 공통 규약이 없으면 서로 같은 바이트를 주고받아도 해석이 달라집니다. '연결이 됐다'와 '대화가 된다'는 전혀 다른 문제입니다. HTTP는 이 간극을 메우기 위해 웹에서 요청과 응답의 의미를 정리한 공용 언어입니다.
처음의 웹은 문서 몇 장을 연결해 보여주는 단순한 하이퍼텍스트 환경이었습니다. 1991년 HTTP 0.9는 GET 메서드 하나로 HTML 문서 하나를 받아 오는 게 전부였습니다. 시간이 지나며 웹은 로그인, 결제, 파일 업로드, API 호출, 대규모 프런트엔드 애플리케이션까지 떠안게 됐습니다. 그러자 성능, 보안, 캐시, 연결 재사용 문제를 감당하기 어려워졌고 HTTP는 계속 진화했습니다. HTTP/1.1은 연결 재사용을 도입했고, HTTP/2는 하나의 연결 위에서 여러 요청을 병렬로 처리했습니다. HTTP가 여러 버전을 거쳐 온 것은 웹 자체가 더 복잡해졌기 때문이지, 기존 개념이 틀렸기 때문은 아닙니다.
HTTP 요청은 메서드, URL, 헤더, 바디로 구성됩니다. 메서드는 조회인지 생성인지 같은 의도를 드러내고, URL은 어떤 자원에 대한 요청인지를 가리키며, 헤더는 인증 정보나 콘텐츠 형식, 캐시 정책 같은 부가 조건을 전달합니다. 서버는 상태 코드, 헤더, 바디를 담은 응답으로 결과를 돌려주고, 클라이언트는 이 조합을 해석해 다음 동작을 결정합니다. 200이면 성공이고, 404면 자원이 없고, 503이면 서버가 일시적으로 응답 불가입니다. 이 구조가 중요한 이유는 단순히 문법이 있기 때문이 아니라, 서로 다른 브라우저와 서버와 API가 동일한 의미 체계 안에서 상호 운용될 수 있기 때문입니다.
HTTP와 TCP는 둘 다 웹 통신에 필요하지만 역할이 다릅니다. TCP는 바이트가 순서대로 도착하도록 보장하는 전송 계층이고, HTTP는 그 위에서 요청의 의미와 결과를 정의하는 애플리케이션 계층입니다. TCP가 없으면 HTTP는 안정적으로 오갈 수 없고, TCP만으로는 메서드, 헤더, 상태 코드처럼 웹의 의미를 표현할 수 없습니다. HTTP와 WebSocket도 둘 다 TCP 위에서 동작하지만 통신 모델이 다릅니다. HTTP는 클라이언트가 요청해야 서버가 응답하는 구조라 서버가 먼저 상태 변화를 보내기 어렵습니다. 반면 WebSocket은 한 번 연결한 뒤 양쪽이 언제든 메시지를 보낼 수 있어, 실시간 채팅이나 알림처럼 서버 쪽 변화가 곧바로 전달돼야 하는 상황에 맞습니다.
HTTP는 웹 페이지 로딩, 브라우저와 API 서버 통신, 서비스 간 호출, 파일 다운로드, 웹훅처럼 요청과 응답이 명확한 인터넷 상호작용에 잘 맞습니다. 자원 중심 모델, 캐시 활용, 프록시와 게이트웨이 통과 같은 웹 인프라의 이점을 그대로 누릴 수 있다는 점도 큽니다. 다만 연결을 오래 붙잡고 수십 밀리초 단위로 상태를 계속 교환해야 하는 실시간 상호작용에서는 HTTP의 요청-응답 틀이 답답해질 수 있습니다. 그런 경우에는 HTTP를 중심으로 둔 설계가 어디까지 자연스럽고 어디부터 다른 통신 모델이 필요한지 판단해야 합니다. HTTP는 '웹에서 가장 흔한 규약'이라서 쓰는 것이 아니라, 요청의 의미와 결과를 명료하게 표현해야 하는 상황에 특히 잘 맞기 때문에 오래 살아남았습니다.