HTTP 분석

HTTP 개요와 역사

• HTTP(HyperText Transfer Protocol): 클라이언트와 서버 간 데이터를 전송하기 위한 핵심 프로토콜로, 클라이언트-서버 구조와 무상태 프로토콜로 설계되었습니다.
• 역사적 발전
  • HTTP/0.9 (1991년): GET 메서드만 지원, HTTP 헤더 없음.
  • HTTP/1.0 (1996년): 메서드와 헤더 추가.
  • HTTP/1.1 (1997년): 지속 연결 등 개선.
  • HTTP/2 (2015년): 성능 개선을 위한 멀티플렉싱 지원.
  • HTTP/3: TCP 대신 UDP 사용으로 성능 향상.

인터넷 네트워크 및 OSI 7계층 모델

• 개요 : 인터넷 네트워크는 다양한 프로토콜과 기술을 사용하여 데이터를 전송합니다.
• OSI 7계층 모델 : 물리 계층에서 응용 계층까지 데이터 통신의 흐름을 단계별로 설명하며, 각 계층은 특정한 역할을 수행하여 데이터가 목적지에 정확하고 안전하게 도달하도록 합니다.

URI와 웹 브라우저 요청 흐름

• URI(Uniform Resource Identifier) : 인터넷에서 자원을 식별하는 통일된 방법으로, URL(위치 식별)과 URN(이름 식별)으로 구분됩니다.
• 웹 브라우저 요청 흐름
  1. 사용자가 브라우저에 URI를 입력합니다.
  2. 브라우저는 DNS 서버를 통해 IP 주소를 조회합니다.
  3. HTTP 요청이 생성되고 서버로 전송됩니다.
  4. 서버는 요청을 처리하고, HTTP 응답 메시지를 반환합니다.
  5. 브라우저는 응답을 렌더링하여 웹 페이지를 사용자에게 표시합니다.

HTTP 메서드와 그 활용

• 주요 HTTP 메서드
  • GET: 리소스를 조회.
  • POST: 새로운 리소스를 생성하거나 특정 작업 수행.
  • PUT: 리소스를 대체하거나 새로 생성.
  • PATCH: 리소스의 일부 수정.
  • DELETE: 리소스를 삭제.
• 메서드 속성
  • 안전성(Safe Methods): 메서드 호출이 리소스를 변경하지 않음 (예: GET).
  • 멱등성(Idempotent Methods): 여러 번 호출해도 결과가 동일 (예: PUT, DELETE).
  • 캐시 가능성(Cacheable Methods): 응답 결과를 캐시할 수 있는지 여부 (예: GET, HEAD).

HTTP 상태 코드

• 상태 코드 분류
  • 1xx (Informational) : 요청 수신 및 처리 중.
  • 2xx (Successful) : 요청이 성공적으로 처리됨.
    • 200 OK : 요청 성공.
    • 201 Created : 새로운 리소스가 생성됨.
    • 204 No Content : 응답 본문이 없음.
  • 3xx (Redirection) : 추가 조치 필요.
    • 301 Moved Permanently : 리소스가 영구적으로 이동됨.
    • 302 Found : 리소스가 임시로 이동됨.
    • 304 Not Modified : 리소스가 변경되지 않음.
  • 4xx (Client Error) : 클라이언트 오류로 인해 서버가 요청을 수행할 수 없음.
    • 400 Bad Request : 잘못된 요청.
    • 401 Unauthorized : 인증이 필요함.
    • 404 Not Found : 요청한 리소스를 찾을 수 없음.
  • 5xx (Server Error) : 서버 측 문제로 요청이 처리되지 못함.
    • 500 Internal Server Error : 서버 내부 오류.
    • 503 Service Unavailable : 과부하 또는 유지보수로 인해 요청 처리 불가.

HTTP 메시지 구조

• 요청 메시지 : 메서드, URI, HTTP 버전, 헤더, 본문으로 구성.
• 응답 메시지 : 상태 코드, 헤더, 본문으로 구성.
• 헤더 : 메시지 전송에 필요한 다양한 부가 정보를 포함.

HTTP 헤더와 캐시

• 주요 헤더
  • Content-Type : 데이터의 형식.
  • Content-Encoding : 데이터의 압축 방식.
  • Content-Language : 데이터의 언어.
  • Content-Length : 데이터의 길이.
• 캐시 제어
  • Cache-Control : 캐시 동작 제어 (예: max-age, no-cache, no-store).
  • Expires : 캐시 만료일 지정.
  • ETag : 데이터의 고유 식별자, 변경 여부 확인.
  • 304 Not Modified : 데이터가 변경되지 않았음을 나타냄, 캐시된 데이터 사용 가능.

HTTP API 설계와 데이터 전송

• API 설계
  • URI를 통한 리소스 식별 : 예) /members에서 회원 목록 조회.
  • HTTP 메서드를 통한 작업 수행 : 예) POST /members로 회원 등록.
• 데이터 전송 방법
  • 쿼리 파라미터 사용 : 주로 GET 요청에 사용.
  • 메시지 본문 사용 : POST, PUT, PATCH 요청에 사용.

결론

• HTTP의 역할 : 웹 상의 모든 통신을 담당하는 핵심 프로토콜로, 클라이언트-서버 구조와 다양한 메서드를 통해 데이터를 주고받습니다.
• RESTful API 설계 : HTTP를 사용하여 RESTful API를 설계할 수 있으며, 상태 코드와 URI를 통해 웹의 자원과 그 행동을 명확히 정의할 수 있습니다.
• HTTP의 발전 : 단순함과 확장성 덕분에 웹이 발전할 수 있었으며, HTTP는 지속적인 버전 업데이트를 통해 더욱 효율적이고 안전한 통신을 가능하게 하고 있습니다.
• 결론적 중요성 : HTTP는 인터넷과 웹의 근간을 이루는 프로토콜로, 현대의 웹 기술과 서비스가 원활하게 작동할 수 있도록 하는 필수 요소입니다.