HTTP(Hyper Text Transfer Protocol)

하이퍼 텍스트를 빠르게 교환하기 위한 프로토콜의 일종으로, 서버와 클라이언트의 사이에서 어떻게 메시지를 교환할지 정해 놓은 규칙이다. Request, Response 로 구성되어 있고 80번 포트를 사용합니다.

조사하면서 알게된 충격적 사실인데, // 부분은 고안당시 멋으로 추가한 것이라고 한다.

보안 연결 HTTPS

HTTPS로 연결하면 전송 내용이 암호화되어 전달됩니다. 요즘에는 보안을 이유로 거의 왠만한 사이트가 HTTPS로 구현되어있습니다.
HTTPS가 사용되지 않으면 비밀번호나 신용카드 번호 등의 정보가 도용될 수 있다고 합니다.

구조

HTTP는 클라이언트가 Request를 하면, 서버가 Response하는 구조로 되어 있다.

FTP나 Telnet과 다르게 비연결식이다. FTP나 Telnet은 클라이언트가 서버에 정보를 요청해도 서버가 클라이언트와 연결을 끊지 않지만, HTTP는 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료한다.

절차적으로 보기

접속시 클라이언트는 GET 명령을 서버에 전송한다.
GET 요청을 받은 서버는 응답 코드와 메시지를 전송한다.
브라우저가 해당 코드와 메시지를 받아 화면에 뿌려준다.

1.1 버전에서는 Connection Header의 Keep-Alive 옵션을 통해 TCP 연결을 일정 시간 유지할 수도 있다.

요청 종류

HTTP에서 지원하는 요청 메시지는 다음과 같다.(일부분)

GET: 클라이언트가 서버에게 URL에 해당하는 자료의 전송을 요청한다.
HEAD: GET 요청으로 반환될 데이터 중 헤더 부분에 해당하는 데이터만 요청한다.
POST: 클라이언트가 서버에서 처리할 수 있는 자료를 보낸다. 예를 들어, 게시판에 글을 쓸 때 클라이언트의 문서가 서버로 전송되어야 한다. 멱등성을 보장하지 않는다.
PATCH: 클라이언트가 서버에게 지정한 URL의 데이터를 부분적으로 수정할 것을 요청한다.
PUT: 클라이언트가 서버에게 지정한 URL에 지정한 데이터를 저장할 것을 요청한다.
DELETE: 클라이언트가 서버에게 지정한 URL의 정보를 제거할 것을 요청한다.

HTTP 트랜잭션

HTTP가 인터넷 연결 위로 전송된 텍스트 라인들에 기초하고 있기 때문에 리눅스 Telnet 프로그램을 사용해서 인터넷 상의 모든 웹 서버와 트랜잭션을 실행할 수 있습니다.
Telnet 프로그램은 연결을 통해서 텍스트 라인으로 클라이언트와 대화하는 서버를 디버그 하는데 매우 간편합니다.

Telnet은 텍스트를 입력하고 엔터키를 누를 때마다 텍스트를 읽고 carriage return(\r)과 line feed(\n) 문자들을 추가하여 서버로 보냅니다.(echo서버 코드 분석 포스팅 참고)
특정 조건에 따라 종료 여부를 정합니다. 예를 들어, 매 텍스트 라인이 carriage return(\r), line feed(\n) 쌍으로 종료될 것을 요구합니다. 이후에 트랜잭션을 개시하기 위해 HTTP 요청을 입력하고 서버는 HTTP 응답으로 회신하며 연결을 닫습니다.

HTTP 요청(Request)

클라이언트가 서버에 무언가를 요청할 때 보내는 메시지입니다.

구조

<요청 라인>
<헤더 필드들>
<빈 줄>
<본문 (POST 등에서 사용)>

요청 메시지는 일반적으로 다음과 같은 세 가지 주요 부분으로 구성됩니다.

요청 라인 (Request Line): 메서드(GET, POST 등), 요청 대상(URL), 그리고 HTTP 버전이 포함됩니다.
- 예시: GET /index.html HTTP/1.1
헤더들 (Headers): 클라이언트 정보, 요청 세부사항 등을 포함하는 키-값 쌍입니다.
- 예시: Host: www.example.com
엔터티 바디(Entity Body) (옵션)
GET 요청에는 거의 사용되지 않으며, POST나 PUT에서는 데이터를 포함할 수 있습니다.

예시 (GET /index.html HTTP/1.1 요청)

GET /index.html HTTP/1.1
Host: [www.example.com](http://www.example.com/)
User-Agent: Mozilla/5.0
Accept: text/html

HTTP 응답(Response)

서버가 클라이언트의 요청에 대해 보내는 메시지입니다.

구조

<상태 라인>
<헤더 필드들>
<빈 줄>
<본문 (HTML, JSON 등)>

응답 메시지 역시 세 가지 주요 부분으로 구성됩니다.

상태 라인 (Status Line): HTTP 버전, 상태 코드(예: 200, 404 등), 상태 메시지로 구성됩니다.
- 예시: HTTP/1.1 200 OK
헤더들 (Headers): 서버 정보, 콘텐츠 유형, 길이 등의 메타 정보를 포함합니다.
- 예시: Content-Type: text/html
본문 (Body): 실제 리소스 데이터(예: HTML 페이지, 이미지, JSON)가 포함됩니다.

예시 (HTTP/1.1 200 OK 응답)

HTTP/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 설계 시에 해당 개념이 매우 중요합니다.

그럼 왜 중요할까요?

네트워크 오류로 요청이 중복 전송될 수 있습니다.
POST 같은 경우 자동 재시도 로직과 충돌할 수 있습니다.
서버 측 데이터와 불일치 할 수 있습니다.(예측 불가능한 결과 생김)

→ 이럴때, 멱등한 매서드만(PUT, DELET 등) 자동 재시도하는 것이 안전합니다.
POST 요청도 안전하게 처리하려면 클라이언트에서 중복 방지 토큰을 사용하는 것도 방법입니다.
중복 요청 방지를 위한 서버 측 캐싱이나 트랜잭션 처리도 중요합니다.

728x90