EP11. HTTP 트랜잭션 개요

---

HTTP 트랜잭션

 

일반적으로 “트랜잭션”이라는 단어는 쪼갤 수 없는 하나의 작업 묶음을 의미하는 경우가 많다.

예를 들어 데이터베이스에서는 여러 작업이 모두 성공하거나 모두 실패해야 할 때 트랜잭션이라는 개념을 사용한다.

그래서 처음 HTTP 트랜잭션이라는 말을 들으면, 이것도 비슷하게 “원자적으로 보장되는 작업”이라고 오해할 수 있다.

하지만 HTTP에서 말하는 트랜잭션은 그런 의미가 아니다.

 

HTTP 트랜잭션은 하나의 HTTP 요청과 그에 대한 하나의 HTTP 응답을 묶어서 부르는 표현이다.

즉, 브라우저가 서버에 요청을 보내고, 서버가 그 요청에 대한 응답을 반환하는 한 번의 왕복 과정을

하나의 HTTP 트랜잭션이라고 보면 된다.

 

예를 들어 사용자가 브라우저에서 어떤 URL에 접속하면 브라우저는 서버에 HTTP 요청을 보낸다.

서버는 이 요청을 해석해서 HTML 문서나 JSON 데이터 같은 응답을 돌려준다.

이 요청과 응답을 하나로 본 것이 바로 HTTP 트랜잭션이다.

 

결국 웹에서 서버와 클라이언트가 대화할 때, 가장 기본적인 단위가 HTTP 트랜잭션이라고 이해하면 된다.

 

---

HTTP 트랜잭션의 요소

 

웹 개발을 공부하거나 디버깅할 때 가장 자주 보게 되는 도구 중 하나가 크롬 개발자도구의 Network 탭이다.

여기서는 브라우저와 서버 사이에서 오간 HTTP 요청과 응답, 즉 HTTP 트랜잭션을 자세히 확인할 수 있다.

 

단순히 “요청이 갔다” 정도만 보는 것이 아니라,

그 안에 어떤 정보가 담겨 있었는지까지 세부적으로 분석할 수 있기 때문에

백엔드와 프론트엔드를 공부할 때 모두 매우 중요하다.

 

먼저 Headers 탭은 HTTP 헤더 정보를 볼 수 있는 공간이다.

여기에는 요청 헤더와 응답 헤더가 모두 들어 있을 수 있다.

예를 들어 브라우저가 어떤 주소로 요청을 보냈는지, 어떤 메서드를 사용했는지, 어떤 콘텐츠 타입을 기대하는지,

서버가 어떤 상태 코드로 응답했는지 같은 정보가 여기에 담긴다.

헤더는 요청과 응답에 대한 부가 설명서 같은 역할을 한다고 생각하면 이해하기 쉽다.

 

다음으로 Payload 탭은 요청을 보낼 때 바디(body)에 실려 간 데이터를 보여준다.

예를 들어 POST 요청으로 로그인 정보나 회원가입 정보, JSON 데이터를 서버에 보냈다면

그 내용이 이 탭에 나타난다.

즉, Payload는 “내가 서버에 무엇을 보냈는가”를 확인하는 탭이라고 볼 수 있다.

 

Preview 탭은 서버가 응답한 바디 데이터를 사람이 보기 쉽게 정리해서 보여준다.

예를 들어 JSON 응답이라면 계층 구조를 보기 좋게 펼쳐서 보여주고,

HTML 응답이라면 렌더링된 결과를 일부 더 쉽게 파악할 수 있게 도와준다.

즉, Preview는 응답 데이터를 “읽기 좋은 형태”로 보여주는 탭이다.

 

반면 Response 탭은 꾸미지 않은 원본 응답 데이터를 보여준다.

Preview처럼 보기 좋게 가공된 형태가 아니라, 서버가 실제로 보낸 날것 그대로의 데이터를 확인할 수 있다.

그래서 응답 내용이 정확히 어떻게 왔는지를 보고 싶을 때 유용하다.

 

---

HTTP란?

 

 

HTTP는 HyperText Transfer Protocol의 약자다.

여기서 중요한 단어는 하이퍼텍스트와 프로토콜이다.

 

먼저 하이퍼텍스트는 단순한 텍스트가 아니라,

다른 문서나 자원으로 연결될 수 있는 구조를 가진 텍스트를 의미한다.

우리가 웹서핑을 하면서 링크를 클릭해 다른 페이지로 이동하는 경험을 떠올리면 이해하기 쉽다.

즉, 하이퍼텍스트는 문서 안에 또 다른 문서로 연결되는 길이 포함된 텍스트라고 볼 수 있다.

 

그리고 프로토콜은 쉽게 말하면 통신을 위한 약속된 규칙이다.

서로 다른 시스템이 데이터를 주고받으려면, 어떤 형식으로 요청할지, 어떻게 응답할지,

어떤 순서로 통신할지에 대한 약속이 필요하다.

 

결론적으로 HTTP는 바로 웹 환경에서 이런 하이퍼텍스트와 관련된 자원을 주고받기 위한 대표적인 통신 규약이다.

 

물론 오늘날 HTTP는 단순히 HTML 문서만 전송하는 데 쓰이지 않는다.

JSON, 이미지, CSS, JavaScript 파일 등 다양한 데이터를 주고받는 데 사용된다.

 

즉, HTTP는 단순히 “웹에서 쓰는 통신 방식”이라고만 외우기보다,

링크를 따라 문서와 자원을 이동하고 전달하는 웹의 핵심 약속이라고 이해하면 더 자연스럽다.

 

---

HTTP/1.1

 

HTTP에는 여러 버전이 있지만, 기본기를 설명할 때 가장 먼저 이해해야 할 버전은 보통 HTTP/1.1이다.

이 버전은 오랫동안 널리 사용되었고, 웹의 기본적인 요청-응답 모델을 이해하는 데 중요한 기준이 된다.

현대에는 HTTP/2나 HTTP/3도 많이 사용되지만,

여전히 HTTP/1.1의 특징을 알고 있어야 그 차이점도 잘 보이게 된다.

 

HTTP/1.1의 특징은 다음과 같다. 

 

① HTTP 클라이언트의 요청으로 트랜잭션이 시작된다

 

기본적으로는 서버가 먼저 말을 거는 구조가 아니라, 클라이언트가 요청을 보내야 서버가 응답할 수 있다.

브라우저가 어떤 페이지를 요청하거나, 자바스크립트가 AJAX 요청을 보내거나, form을 제출할 때 모두 이 흐름으로 동작한다.

 

② 무상태성(statelessness)

 

무상태성이라는 것은 각각의 HTTP 트랜잭션이 서로 독립적이라는 뜻이다.

서버는 이전 요청과 현재 요청을 자동으로 이어서 기억하지 않는다.

예를 들어 같은 사용자가 몇 초 전에 요청을 보냈더라도,

그다음 요청이 왔을 때 서버는 기본적으로 그 둘을 별개의 요청으로 본다.

그래서 로그인 상태 유지나 사용자 식별이 필요할 때는

HTTP 자체가 아니라 쿠키, 세션, 토큰 같은 별도의 수단을 사용하게 된다.

 

③ 비연결성(connectionless)

 

네트워크에서 데이터를 주고받으려면 기본적으로 연결 과정이 필요하다.

HTTP도 요청과 응답을 위해 연결을 맺고 데이터를 주고받지만,

트랜잭션이 끝나면 연결을 끊는 것이 기본적인 모델이었다.

이렇게 하면 서버 입장에서는 연결을 계속 유지하지 않아도 되므로 자원을 더 효율적으로 사용할 수 있다.

반면 단점은 요청이 일어날 때마다 연결을 맺고 끊는 과정이 반복될 수 있다는 것이다.

 

④ 사람이 읽기 쉬운 프로토콜이다. 

 

많은 통신 프로토콜은 바이너리 형식이라 사람이 바로 이해하기 어렵다.

하지만 HTTP/1.1은 헤더와 메시지 구조가 비교적 텍스트 기반이어서 개발자가 직접 읽고 이해하기가 쉽다.

 

---

HTTP/2

 

HTTP/1.1은 안정적이고 널리 사용되었지만, 시간이 지나면서 성능상 한계도 드러났다.

특히 웹페이지가 점점 복잡해지고, 한 번 페이지를 띄울 때 불러와야 하는 리소스가 많아지면서

더 효율적인 전송 방식이 필요해졌다.

이런 배경에서 등장한 것이 HTTP/2다.

 

HTTP/2의 대표적인 특징 중 하나는 하나의 커넥션에서 여러 개의 요청을 동시에 처리할 수 있다는 점이다.

HTTP/1.1에서는 요청과 응답의 흐름이 상대적으로 비효율적일 수 있었는데,

HTTP/2는 하나의 연결을 더 적극적으로 활용해 여러 요청을 병렬적으로 처리할 수 있도록 개선되었다.

 

또한 HTTP/2는 헤더를 압축한다. 웹 요청과 응답에는 헤더가 계속 포함되는데,

이 정보가 반복되면 불필요한 전송 비용이 생길 수 있다.

HTTP/2는 헤더 압축을 통해 이런 중복 비용을 줄이고 더 효율적으로 통신할 수 있게 했다.

 

그리고 HTTP/2는 서버 푸시(server push) 기능도 지원했다.

이는 서버가 클라이언트가 곧 필요로 할 것 같은 자원을 미리 보내주는 개념이다.

예를 들어 HTML 문서를 보낸 뒤, 그 문서가 필요로 할 CSS나 JavaScript 파일도

클라이언트가 요청하기 전에 미리 전송하는 식이다.

 

---

HTTP/3

 

HTTP/3는 HTTP/2 이후에 등장한 더 최신의 버전으로,

가장 큰 변화 중 하나는 기존의 TCP 대신 UDP 기반으로 동작한다는 점이다.

 

기존의 TCP는 신뢰성 있는 데이터 전송을 보장하지만, 연결을 맺고 끊는 과정에서 비용이 발생하고,

지연 상황에서 성능 손해가 커질 수 있다.

 

HTTP/3는 이런 문제를 줄이기 위해 UDP를 기반으로 하면서도,

웹 통신에 필요한 안정성과 순서 보장 등을 별도로 처리하는 접근을 택했다.

이를 통해 연결 설정 지연을 줄이고, 네트워크 환경이 좋지 않을 때도 더 효율적으로 데이터를 주고받을 수 있도록 개선했다.