하이퍼 텍스트를 빠르게 교환하기 위한 프로토콜의 일종으로, 서버와 클라이언트의 사이에서 어떻게 메시지를 교환할지 정해 놓은 규칙이다. Request, Response 로 구성되어 있고 80번 포트를 사용합니다.
조사하면서 알게된 충격적 사실인데, // 부분은 고안당시 멋으로 추가한 것이라고 한다.
HTTPS로 연결하면 전송 내용이 암호화되어 전달됩니다. 요즘에는 보안을 이유로 거의 왠만한 사이트가 HTTPS로 구현되어있습니다.
HTTPS가 사용되지 않으면 비밀번호나 신용카드 번호 등의 정보가 도용될 수 있다고 합니다.
HTTP는 클라이언트가 Request를 하면, 서버가 Response하는 구조로 되어 있다.

FTP나 Telnet과 다르게 비연결식이다. FTP나 Telnet은 클라이언트가 서버에 정보를 요청해도 서버가 클라이언트와 연결을 끊지 않지만, HTTP는 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료한다.
1.1 버전에서는 Connection Header의 Keep-Alive 옵션을 통해 TCP 연결을 일정 시간 유지할 수도 있다.

HTTP에서 지원하는 요청 메시지는 다음과 같다.(일부분)
HTTP가 인터넷 연결 위로 전송된 텍스트 라인들에 기초하고 있기 때문에 리눅스 Telnet 프로그램을 사용해서 인터넷 상의 모든 웹 서버와 트랜잭션을 실행할 수 있습니다.
Telnet 프로그램은 연결을 통해서 텍스트 라인으로 클라이언트와 대화하는 서버를 디버그 하는데 매우 간편합니다.
Telnet은 텍스트를 입력하고 엔터키를 누를 때마다 텍스트를 읽고 carriage return(\r)과 line feed(\n) 문자들을 추가하여 서버로 보냅니다.(echo서버 코드 분석 포스팅 참고)
특정 조건에 따라 종료 여부를 정합니다. 예를 들어, 매 텍스트 라인이 carriage return(\r), line feed(\n) 쌍으로 종료될 것을 요구합니다. 이후에 트랜잭션을 개시하기 위해 HTTP 요청을 입력하고 서버는 HTTP 응답으로 회신하며 연결을 닫습니다.
클라이언트가 서버에 무언가를 요청할 때 보내는 메시지입니다.
<요청 라인>
<헤더 필드들>
<빈 줄>
<본문 (POST 등에서 사용)>
요청 메시지는 일반적으로 다음과 같은 세 가지 주요 부분으로 구성됩니다.
GET /index.html HTTP/1.1Host: www.example.comGET 요청에는 거의 사용되지 않으며, POST나 PUT에서는 데이터를 포함할 수 있습니다.GET /index.html HTTP/1.1
Host: [www.example.com](http://www.example.com/)
User-Agent: Mozilla/5.0
Accept: text/html
서버가 클라이언트의 요청에 대해 보내는 메시지입니다.
<상태 라인>
<헤더 필드들>
<빈 줄>
<본문 (HTML, JSON 등)>
응답 메시지 역시 세 가지 주요 부분으로 구성됩니다.
HTTP/1.1 200 OKContent-Type: text/htmlHTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
<html>
<body>Hello, world!</body>
</html>
| 상태 코드 | 의미 |
|---|---|
200 OK | 정상 처리 |
301 Moved Permanently | 리다이렉트 |
400 Bad Request | 요청 오류 |
403 Forbidden | 권한 없음 |
404 Not Found | 리소스 없음 |
500 Internal Server Error | 서버 오류 |
위의 요청들을 다루면서 멱등성이라는 개념이 있습니다.
멱등성이란 같은 요청을 여러 번 반복해서 보내더라도 결과가 같아야 함을 의미합니다.
HTTP에서…
한 요청을 여러 번 수행해도 서버 상태나 결과가 변하지 않아야 합니다.
| 메서드 | 멱등성 여부 | 설명 |
|---|---|---|
GET | O | 데이터를 조회만 하므로 상태 변화 없음 |
PUT | O | 같은 자원에 동일한 값을 덮어씀 → 결과는 같음 |
DELETE | O | 이미 삭제된 자원을 또 삭제해도 변화 없음 |
HEAD | O | 헤더만 가져오므로 서버 상태에 영향 없음 |
OPTIONS | O | 서버가 지원하는 메서드만 물어봄 |
POST | X | 호출할 때마다 새로운 리소스를 만들 수 있음 (예: 게시물 작성 등) |
위와 같이 메서드에 따라 멱등성 여부는 다르지만, 일부 매서드에 대해 일정한 결과를 내보내야 합니다. RESTful API 설계 시에 해당 개념이 매우 중요합니다.
그럼 왜 중요할까요?
→ 이럴때, 멱등한 매서드만(PUT, DELET 등) 자동 재시도하는 것이 안전합니다.
POST 요청도 안전하게 처리하려면 클라이언트에서 중복 방지 토큰을 사용하는 것도 방법입니다.
중복 요청 방지를 위한 서버 측 캐싱이나 트랜잭션 처리도 중요합니다.