iBetter Books
...
수정

요청과 응답

브라우저는 서버와 단순한 대화를 합니다. "이 파일을 줘." "알겠어, 여기 있어." 혹은 "그런 파일은 없어." 이 대화의 규칙을 HTTP(HyperText Transfer Protocol)라고 합니다. 1991년에 팀 버너스-리가 만들었고, 오늘날 인터넷 트래픽의 대부분이 이 프로토콜 위에서 흐릅니다.

텍스트 기반 프로토콜

HTTP는 텍스트 기반입니다. 사람이 읽을 수 있는 문자열로 요청과 응답을 주고받습니다. 바이너리가 아닙니다. 덕분에 어떤 요청이 오가는지 눈으로 직접 확인할 수 있습니다.

클라이언트가 서버에 보내는 HTTP 요청의 구조입니다.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

첫 줄은 요청 라인입니다. 메서드(GET), 경로(/index.html), HTTP 버전(HTTP/1.1)이 순서대로 나옵니다. 그 아래는 헤더들입니다. 빈 줄이 헤더의 끝을 알립니다. 요청 본문이 있다면 빈 줄 다음에 옵니다.

응답의 구조

서버가 돌려주는 응답입니다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256

<!DOCTYPE html>
<html>
...

첫 줄은 상태 라인입니다. HTTP 버전과 상태 코드, 그리고 상태 메시지가 옵니다. 200 OK는 요청이 성공했다는 뜻입니다. 그 아래 헤더, 빈 줄, 본문(HTML 내용)이 이어집니다.

비연결성과 무상태

HTTP는 기본적으로 비연결성(connectionless)입니다. 하나의 요청-응답이 끝나면 연결을 닫습니다. 그리고 무상태(stateless)입니다. 서버는 이전 요청을 기억하지 않습니다. 매 요청은 완전히 독립적입니다.

이 특성이 처음에는 단순하게 보이지만, 로그인 상태를 유지하려면 쿠키나 세션 같은 별도 메커니즘이 필요합니다. 서버 입장에서는 메모리를 아끼는 이점이 있지만, 애플리케이션 개발자 입장에서는 상태 관리가 어려워집니다.

HTTP/1.1부터는 Connection: keep-alive로 연결을 재사용하는 것이 기본값이 되었습니다. 같은 서버에 여러 요청을 보낼 때마다 TCP 연결을 새로 맺지 않아도 됩니다.

요청-응답 한 사이클

결국 HTTP는 클라이언트가 요청(request)을 보내면 서버가 응답(response)을 돌려주는 한 사이클입니다. 클라이언트 없이 서버가 먼저 데이터를 보낼 수 없습니다. 이 제약은 실시간 알림 같은 기능을 구현할 때 복잡성을 만들어 냅니다. WebSocket과 Server-Sent Events 같은 기술이 이 제약을 극복하기 위해 등장했지만, 그것은 이 교재의 범위를 벗어납니다.

다음 절에서는 메서드, 상태 코드, 헤더를 하나씩 살펴봅니다.

← 18장. HTTP와 HTTPS02. 메서드, 상태코드, 헤더 →