이론/백엔드 개념정리

HTTP의 CRUD

블스뜸 2025. 5. 3. 20:10

HTTP (Hypertext Transfer Protocol)

HTTP는 다양한 형태의 데이터(TEXT, IMAGE, FILE, HTML, JSON 등)를 웹 상에서 주고받기 위한 통신 규약이다.

  • HTTP 버전은 다양하며, 현재는 **HTTP/1.1 (TCP)**이 가장 널리 사용된다.
  • 최근 **HTTP/2, HTTP/3 (UDP)**의 사용량이 빠르게 증가하고 있다.
  • 본 내용은 주로 사용되는 HTTP/1.1 버전에 대한 것이다.

동작 순서

  1. **클라이언트 (Client)**는 서버에 **Request (요청)**을 전송하고 응답을 기다린다.
  2. **서버 (Server)**는 수신된 요청을 처리한 후 **Response (응답)**을 클라이언트에게 전송한다.

클라이언트와 서버 구조

  • 초기에는 클라이언트와 서버의 역할 구분이 명확하지 않았으나, 점차 분리되었다.
  • 클라이언트는 주로 **UI (User Interface)**를 담당하도록 개발된다.
  • 서버는 데이터 저장 및 관리, 비즈니스 로직 처리를 담당하도록 개발된다.
  • 이러한 분리를 통해 클라이언트와 서버는 각자 독립적으로 발전할 수 있게 되었다.

무상태 (Stateless)

  • HTTP는 서버가 클라이언트의 상태를 보존하지 않는 Stateless 특성을 갖는다.

장점

  • Scale Out (수평 확장) 용이: 요청량 증가 시 서버를 쉽게 증설하여 처리 능력을 확장할 수 있다.

단점

  • 클라이언트가 매 요청마다 필요한 데이터를 추가적으로 전송해야 한다.

한계점 및 해결 방안

  • 로그인과 같이 상태 유지가 필수적인 경우, Cookie, Session, Token 등의 기술을 활용하여 Stateless 환경의 한계를 극복한다.

비연결 (Connectionless)

  • HTTP는 클라이언트와 서버 간에 연결을 지속적으로 유지하지 않는 Connectionless 모델이다.

장점

  • 불필요한 연결 유지를 하지 않으므로 서버 자원을 효율적으로 사용할 수 있다.

단점

  • 새로운 요청마다 연결 설정 (3-way handshake) 과정을 거쳐야 하므로 응답 시간이 증가할 수 있다.
  • 웹 페이지의 HTML, CSS, JS, 이미지 등 정적 자원을 매번 다시 다운로드해야 한다. (→ 캐시, 브라우저 캐싱을 통해 해결)

HTTP 지속 연결 (Persistent Connections)

  • Connectionless 방식의 단점을 보완하기 위해 현재는 HTTP 지속 연결 방식을 주로 사용한다.
  • 하나의 요청에 필요한 모든 하위 요청(HTML, CSS, JS, 이미지 등)이 완료될 때까지 연결을 유지한다.
  • 연결 설정 및 해제 횟수를 줄여 Connectionless 방식보다 응답 속도가 향상된다.
  • 예시: HTML 요청 후 연결을 유지하여 CSS, JS, 이미지 요청을 처리한다.

HTTP Message 구조

HTTP 메시지는 다음과 같은 구조로 이루어져 있다.

  1. Start Line (시작줄)
  2. Header (헤더)
  3. Empty Line (빈 줄)
  4. Message Body (메시지 본문)

HTTP 요청 메시지 (Request Message) 예시

GET /event HTTP/1.1
Host: spartacodingclub.kr
  1. Start Line
    • HTTP Method: 요청의 목적 (GET, POST, PUT, PATCH, DELETE 등)
      • GET: 리소스 조회
      • POST: 리소스 생성
      • PUT: 리소스 전체 업데이트 (클라이언트가 리소스 URI를 지정)
      • PATCH: 리소스 부분 업데이트
      • DELETE: 리소스 삭제
    • Request Target: 요청 대상
      • path: 절대 경로 (/event)
      • Query String (Query Parameter) 포함 가능 (/search?keyword=sparta)
    • HTTP Version: HTTP 프로토콜 버전 (HTTP/1.1)
  2. Header
    • Host: spartacodingclub.kr (필수 헤더)
    • field-name: field-value 형태로 구성 (대소문자 구분 없음)
    • 요청에 대한 추가 정보 포함 (Message Body 내용, 크기, 인증, 브라우저 정보 등)
    • 임의의 헤더 추가 가능 (서버가 이해할 수 있는 경우)
  3. Empty Line: 헤더와 메시지 본문을 구분하는 빈 줄 (필수)
  4. Message Body: 실제 전송 데이터 (HTML, 이미지, JSON 등). GET 요청 시에는 일반적으로 사용하지 않음.

HTTP 응답 메시지 (Response Message) 예시

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

<html><body>내용</body></html>
  1. Start Line
    • HTTP Version: HTTP 프로토콜 버전 (HTTP/1.1)
    • Status Code: 요청 처리 결과 상태 코드 (200 OK - 성공)
    • Status Text: 상태 코드에 대한 설명 메시지 (OK)
  2. Header
    • 응답에 대한 추가 정보 포함 (Content-Type, Content-Length 등)
    • 응답에만 사용되는 특정 헤더 존재
  3. Empty Line: 헤더와 메시지 본문을 구분하는 빈 줄 (필수)
  4. Message Body: 실제 응답 데이터 (HTML, 이미지, JSON 등). 전송할 데이터가 없으면 빈 상태로 존재할 수 있음.

주요 Method

  • POST: 서버에 리소스 생성을 요청하거나, 폼 데이터 전송 등 다양한 목적으로 사용. 요청 데이터는 Message Body를 통해 전달.
  • GET: 서버로부터 특정 리소스를 조회하는 데 사용. 데이터 전달 시 Query String을 활용하며, Message Body 사용은 권장되지 않음.
  • PUT: 클라이언트가 리소스의 URI를 지정하여 해당 리소스를 전체적으로 덮어쓰는 데 사용.
  • PATCH: 기존 리소스의 일부분만 수정하는 데 사용.
  • DELETE: 서버의 특정 리소스를 삭제하는 데 사용.

기타 Method

  • HEAD: GET 요청과 동일하지만, Message Body 없이 헤더 정보만 반환받음.
  • OPTIONS: 서버가 지원하는 통신 Method를 확인하는 데 사용.
  • CONNECT: 프록시 서버와 통신하기 위한 터널을 설정하는 데 사용 (일반적으로 잘 사용되지 않음).
  • TRACE: 요청 메시지가 서버에 도달하는 경로를 추적하는 데 사용 (일반적으로 잘 사용되지 않음).
저작자표시 (새창열림)