Network
HTTP 요청/응답 구조 (프로토콜, 메서드)
by xogns93
2024. 9. 27.
HTTP는 클라이언트(주로 웹 브라우저)와 서버 간에 이루어지는 요청/응답(Request/Response) 기반의 통신 프로토콜입니다. HTTP 통신에서 요청(Request)과 응답(Response)은 각각 헤더(Header)와 바디(Body)로 구성됩니다.
HTTP 요청(Request) 구조
- 요청 라인(Request Line):
- HTTP 메서드, 요청할 URL, 사용된 HTTP 버전을 포함합니다.
- 예시:
GET /index.html HTTP/1.1
- 헤더(Header):
- 요청에 대한 메타데이터를 포함하며, 각 헤더는 이름과 값으로 이루어져 있습니다.
- 예시 헤더:
Host: 요청 대상 서버의 도메인 이름 (예: Host: www.example.com)User-Agent: 클라이언트의 정보 (브라우저, 운영체제 등)Accept: 클라이언트가 처리할 수 있는 MIME 타입 (예: Accept: text/html)
- 빈 줄(CRLF):
- 바디(Body):
- 클라이언트가 서버로 전송하는 실제 데이터가 담겨 있으며, 주로 POST, PUT, PATCH 요청에서 사용됩니다.
- GET 요청의 경우, 보통 바디는 없으며 데이터를 URL 쿼리 파라미터에 포함시킵니다.
HTTP 응답(Response) 구조
- 응답 라인(Status Line):
- 서버의 HTTP 버전, 상태 코드, 상태 메시지를 포함합니다.
- 예시:
HTTP/1.1 200 OK (200은 성공을 의미하는 상태 코드)
- 헤더(Header):
- 응답에 대한 메타데이터를 포함하며, 요청과 마찬가지로 이름과 값으로 이루어져 있습니다.
- 예시 헤더:
Content-Type: 응답 바디의 데이터 형식 (예: Content-Type: text/html)Content-Length: 응답 바디의 크기 (예: Content-Length: 3456)Set-Cookie: 클라이언트 측에서 저장할 쿠키 정보
- 빈 줄(CRLF):
- 바디(Body):
- 서버가 클라이언트에게 전송하는 실제 데이터가 포함됩니다. HTML, JSON, 이미지, 파일 등 다양한 형식으로 응답 데이터를 보낼 수 있습니다.
HTTP 요청과 응답의 예시
HTTP 요청 (GET 요청 예시):
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
HTTP 응답:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: text/html
Content-Length: 88
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
헤더와 바디의 역할
- 헤더(Header):
- 요청/응답에 대한 부가 정보를 담고 있으며, 클라이언트와 서버 간의 메타데이터 교환을 담당합니다.
- 예를 들어, 클라이언트가 어떤 브라우저를 사용하는지, 어떤 콘텐츠 유형을 수신할 준비가 되어 있는지, 서버가 응답하는 데이터의 형식이나 쿠키 정보 등이 포함됩니다.
- 바디(Body):
- 요청 또는 응답의 실제 데이터가 들어가는 부분입니다. 요청 바디에는 주로 폼 데이터, 파일 업로드, JSON 객체 등이 포함될 수 있으며, 응답 바디에는 HTML, 이미지, JSON 데이터 등이 포함됩니다.
요약
- HTTP는 클라이언트와 서버 사이에서 요청(Request)과 응답(Response)을 주고받는 프로토콜입니다.
- 요청과 응답은 헤더와 바디로 구성되며, 헤더는 요청/응답에 대한 메타데이터를, 바디는 실제 데이터를 포함합니다.
HTTP 메서드
1. GET
- 목적: 서버에서 리소스를 조회할 때 사용됩니다.
- 특징:
- 데이터를 조회하는 메서드로, 서버의 상태를 변경하지 않으므로 안전하고, 같은 요청을 여러 번 보내도 같은 결과를 반환하므로 멱등성이 있습니다.
- 요청 Body는 선택 사항이며, 일반적으로 사용되지 않고, 응답에는 Body가 포함됩니다.
- 캐시가 가능하므로, 브라우저는 GET 요청의 결과를 저장해두고 재사용할 수 있습니다.
2. HEAD
- 목적: GET 요청과 동일하지만, 응답 Body 없이 헤더만 반환받습니다.
- 특징:
- 리소스의 상태나 메타데이터만 확인하고자 할 때 사용되며, 안전하고 멱등성이 있습니다.
- 요청 Body는 선택 사항이며, 응답에는 Body가 포함되지 않습니다.
- 캐시가 가능합니다.
3. POST
- 목적: 서버에 데이터를 전송하여 새로운 리소스를 생성하거나 서버에서 작업을 처리할 때 사용됩니다.
- 특징:
- 요청 Body에 데이터를 담아 서버로 전송하며, 응답 Body에도 데이터가 포함될 수 있습니다.
- 서버의 상태를 변경하므로 안전하지 않으며, 같은 요청을 여러 번 보내면 중복 데이터가 생성될 수 있어 멱등성이 없습니다.
- 일부 경우 캐시가 가능하지만, 일반적으로 캐시되지 않습니다.
4. PUT
- 목적: 서버에 존재하는 리소스를 수정하거나 새로운 리소스를 생성할 때 사용됩니다.
- 특징:
- 요청 Body에 리소스 전체 정보를 포함하며, 해당 리소스를 완전히 덮어씁니다.
- 같은 요청을 여러 번 보내도 서버 상태가 변하지 않으므로 멱등성이 있습니다.
- 서버의 상태를 변경하므로 안전하지 않으며, 캐시되지 않습니다.
5. DELETE
- 목적: 서버에서 리소스를 삭제할 때 사용됩니다.
- 특징:
- 서버의 상태를 변경하므로 안전하지 않지만, 같은 요청을 여러 번 보내도 결과는 동일하므로 멱등성이 있습니다.
- 요청 Body는 선택 사항이며, 응답 Body가 포함될 수 있습니다.
- 캐시되지 않습니다.
6. CONNECT
- 목적: 프록시 서버를 통해 터널링을 설정할 때 사용됩니다.
- 특징:
- 주로 SSL을 통한 HTTPS 연결을 설정할 때 사용되며, 클라이언트와 프록시 서버 간의 터널을 만들어 연결을 유지합니다.
- 안전하지 않고 멱등성도 없습니다.
- 캐시되지 않습니다.
7. OPTIONS
- 목적: 서버가 지원하는 HTTP 메서드를 확인할 때 사용됩니다.
- 특징:
- 클라이언트가 서버에 대해 어떤 요청을 보낼 수 있는지 확인하는 데 사용됩니다.
- 서버의 상태를 변경하지 않으므로 안전하고 멱등성이 있습니다.
- 캐시되지 않습니다.
8. TRACE
- 목적: 클라이언트와 서버 간의 통신 경로를 추적할 때 사용됩니다.
- 특징:
- 클라이언트가 보낸 요청이 그대로 반환되며, 네트워크 디버깅 목적으로 사용됩니다.
- 서버의 상태를 변경하지 않으므로 안전하고 멱등성이 있습니다.
- 캐시되지 않습니다.
9. PATCH
- 목적: 서버에 존재하는 리소스를 부분적으로 수정할 때 사용됩니다.
- 특징:
- 요청 Body에 수정할 정보만 포함하며, 전체 리소스를 덮어쓰지 않고 부분적으로 변경합니다.
- 같은 요청을 여러 번 보내도 동일한 결과가 나오므로 멱등성이 있습니다.
- 서버의 상태를 변경하므로 안전하지 않으며, 캐시되지 않습니다.
요약:
- GET: 서버에서 데이터를 조회.
- POST: 서버에 데이터를 전송하여 새로운 리소스를 생성 또는 작업 처리.
- PUT: 서버에 있는 리소스를 완전히 덮어씌워 수정 또는 새로운 리소스 생성.
- DELETE: 서버에서 리소스를 삭제.
- HEAD: GET 요청과 유사하나, 응답 Body 없이 헤더만 반환.
- OPTIONS: 서버가 지원하는 메서드 확인.
- TRACE: 통신 경로를 추적.
- PATCH: 리소스를 부분적으로 수정.
- CONNECT: 프록시 서버와 터널링을 설정.
