Lucian Log

homepage

Contact

Copyright © 2024 | Yankos
Contents

Home > Computer Science > Network > HTTP 기본 구조

HTTP 기본 구조
Computer Science 2024-02-20 - -
Network HTTP

기본 용어

  • IP (Internet Protocol)
    • 패킷(Packet)을 단위로 특정 주소(IP Address)에 데이터를 전달할 수 있는 프로토콜
    • IP 패킷 (보내려는 메시지 + 출발지 IP, 도착지 IP…)
    • 한계
      • 비연결성
        • 패킷을 받을 대상이 없거나 상대 서버가 불능 상태여도 전송
      • 비신뢰성
        • 중간에 패킷이 누락되거나 순서대로 오지 않는 경우 존재
      • 프로그램 구분
        • 같은 IP인데 통신하는 애플리케이션이 2개 이상인 경우 구분 불가
  • 전송계층(Transport Layer)
    • 네트워크 4계층에서 TCP 혹은 UDP 추가 정보로 IP 패킷을 보완하는 단계
  • TCP (Transmission Control Protocol)
    • 앞선 IP의 문제점을 해결 (전송제어 정보를 패킷에 추가)
    • TCP/IP 패킷 (IP 패킷 + 출발지 PORT, 목적지 PORT, 전송제어, 순서, 검증정보…)
    • 특징
      • 연결지향 (3 way handshake)
        • SYN, SYN+ACK, ACK 3단계로 연결을 확인하고 그 후 데이터를 보냄
        • 최근엔 최적화되어 세 번째 단계 ACK에서 데이터를 함께 보내는 것이 가능
      • 데이터 전달 보증
        • 서버는 데이터를 잘 받았다는 응답을 클라이언트에게 줌
      • 순서 보장
        • 기본적으로는 패킷 1, 3, 2 순서로 왔다면 2부터 다시 보낼 것을 클라이언트에 요청
        • 서버 최적화에 따라 다시 보내달라는 요청 없이 내부적으로 처리하기도 할 것
  • UDP (User Datagram Protocol)
    • IP와 비슷할 정도로 기능이 거의 없음 (하얀 도화지)
      • PORT, 체크섬 정도만 추가
      • TCP의 연결지향, 데이터 전달 보증, 순서 보장 등이 없다.
    • 덕분에 단순하고 빠름
      • TCP는 3 way handshake와 패킷의 추가정보들로 인해 데이터가 크고 속도가 느림
      • 따라서, 속도 최적화는 UDP 이용
      • HTTP3 스펙에서도 UDP를 활용하며 최근 각광
  • PORT
    • 같은 IP(내 서버) 내에 여러 프로세스가 통신 중일 때, 응답 패킷이 어느 애플리케이션의 패킷인지 구분
    • IP가 아파트면 PORT는 동호수를 표현
    • 0~65535 할당 가능
    • 0~1023은 잘 알려진 포트로 사용하지 않는 것이 좋음
      • HTTP - 80
      • HTTPS - 443
  • DNS (Domain Name System)
    • 전화번호부 같은 서버를 제공하여 도메인명을 IP 주소로 변환하는 역할 수행
    • IP는 기억하기 어렵고 가변적이어서 DNS가 이를 해결
  • URI (Uniform Resource Identifier)
    • 자원을 식별하는 방법을 총칭
    • URL(Uniform Resource Locator) + URN(Uniform Resource Name)
      • URL: https://www.inflearn.com/course/lecture
      • URN: urn:isbn:01270712
    • URN은 보편화 되지 않아서 URI = URL로 생각해도 무방하다.

URL 문법

  • Syntax: scheme://[userinfo@]host[:port][/path][?query][#fragment]
  • 예시: https://www.google.com:443/search?q=hello&hl=ko
  • scheme
    • 주로 프로토콜 사용 (어떤 방식으로 자원에 접근할 것인가에 대한 약속)
    • http, https, ftp
  • port
    • http 80 포트, https 443 포트 등 보편적인 경우 생략 가능
  • userinfo
    • URL에 사용자 정보를 포함해서 인증하는 경우 사용하지만 거의 쓰이지 않음
  • host
    • 도메인명 또는 IP 주소를 직접 사용 가능
  • path
    • 계층적 구조의 리소스 경로
  • query
    • key-value 형태
    • ?로 시작, &로 추가
    • 서버로 요청시 모두 문자로 넘어감
    • = query parameter = query string
  • fragment
    • html 내부 북마크에 사용
    • 서버 전송 정보가 아님

브라우저 요청 흐름

  1. 클라이언트
    • 애플리케이션 계층
      • 웹 브라우저에 요청: https://www.google.com:443/search?q=hello&hl=ko
      • 웹 브라우저가 DNS 조회 및 PORT 정보 파악
      • 웹 브라우저가 HTTP 요청 메시지 생성
      • SOCKET 라이브러리
        • 파악한 IP 및 PORT 정보로 구글 서버와 3 way handshake로 연결 맺기
        • OS로 데이터 전달
    • OS 계층 (TCP/UDP & IP 계층)
      • TCP/IP 패킷 생성 (HTTP 메시지 포함)
    • 네트워크 인터페이스
      • 패킷에 이더넷 프레임을 씌워 인터넷망으로 던짐
  2. 인터넷 망
    • 수많은 인터넷 노드를 거쳐 목적지 구글 서버에 패킷 전달
  3. 구글 서버
    • 구글 서버는 반대 과정으로 tcp/ip 패킷을 까서 http 메시지를 해석
    • 구글 서버는 요청에 맞는 http 응답 메시지를 생성하고 TCP/IP 패킷을 씌워 클라이언트에 다시 보냄
  4. 인터넷 망
    • 수많은 인터넷 노드를 거쳐 클라이언트 웹브라우저에 응답 패킷 전달
  5. 클라이언트
    • 클라이언트는 응답 패킷을 까서 http 메시지를 해석
    • 메시지 내 데이터를 웹 브라우저가 렌더링하여 화면에 출력

HTTP (HyperText Transfer Protocol)

  • 모든 형태의 데이터를 HTTP 메시지로 전송 가능
    • 처음엔 HTML 같은 HyperText 문서 전송 용도로 시작
  • HTTP/1.1 (1997)
    • 가장 많이 사용되는 중요한 버전
    • 주요 기능이 이미 모두 포함됨
    • RFC7230~7235(2014)이 최신 개정판
    • HTTP/2, HTTP/3은 성능 개선에 초점
    • TCP 이용
      • HTTP/1.1, HTTP/2
    • UDP 이용
      • HTTP/3
  • 특징
    • 클라이언트-서버 구조
      • 클라이언트(UI, 사용성) & 서버(비즈니스 로직, 데이터) 분리로 각각이 독립적 진화 가능
    • 무상태 프로토콜(Stateless)
      • 서버가 클라이언트의 상태를 보존하지 않음
      • 서버 Scale Out(수평 확장)에 유리
        • 무상태는 응답 서버를 쉽게 바꿀 수 있으므로 무한한 서버 증설 가능
        • 갑자기 클라이언트 요청(고객)이 증가해도 서버(점원)를 대거 투입할 수 있음
      • 한계
        • 무상태로 설계할 수 없는 경우도 있음
          • 쿠키 세션 로그인
        • 요청 데이터가 많음
      • 최대한 무상태로 설계하고 어쩔 수 없는 경우에만 상태 유지
        • 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 감당을 위한 필수 설계
        • 선착순 1000명 이벤트는 수만명 동시 요청 발생
        • 첫 페이지에 로그인도 필요 없는 정적 페이지 하나를 두면 조금 분산이 됨
    • 비연결성(Connectionless)
      • 요청 및 응답할 때만 연결하고 바로 끊음
      • 서버의 자원을 매우 효율적으로 사용할 수 있음
        • HTTP는 초 단위 이하의 빠른 속도로 응답
        • 1시간 동안 수천명이 서비스를 이용해도 서버에서 실제 동시에 처리하는 요청은 수십개 이하로 작음 (1초에 몇 명 되지도 않을 것)
      • HTTP 지속 연결(Persistent Connections) 기본으로 사용해 연결 시간을 어느정도 최적화
        • TCP/IP 연결(3 way handshake) 시간이 사용자에게 매번 추가되는 상황이 비효율적
          • js파일, html 파일, css 파일을 각각 다운 받을 때마다 연결을 맺음 (0.9초)
        • HTTP 지속 연결로 해결
          • HTML 페이지 하나가 전부 다운 받아질 때까지 TCP 연결을 유지하고 해제함 (0.5초)

HTTP 메시지 구조

HTTP message structure

  • 구조
    • 시작 라인(start-line)
      • 요청과 응답 기본 형태는 start-line만 다름
      • request-line (요청 메시지 경우)
        • (HTTP 메서드) (SP=공백) (request-target=absolute path) (SP) (HTTP version) (CRLF=엔터)
        • ex) GET /search?q=hello&hl=ko HTTP/1.1
        • status-line (응답 메시지 경우)
          • (HTTP version) (SP) (status-code) (SP) (reason-phrase) (CRLF)
          • ex) HTTP/1.1 200 OK
    • 헤더(header)
      • HTTP 전송에 필요한 모든 메타 정보 담김
      • 수많은 표준 헤더가 존재 & 임의의 헤더 추가 가능
      • 구조 (header-field)
        • (field-name) (:) (OWS=띄어쓰기 허용) (field-value) (OWS)
        • field-name은 대소문자 구분 X, field-value는 대소문자 구분 O
        • request example
          • Host: www.google.com
        • response example
          • Content-Type: text/html;charset=UTF-8
          • Content-Length: 3432
    • 공백 라인(empty line) - Required
    • 메시지 바디(message body) - Optional
      • 실제 전송할 데이터 담김
        • byte로 표현할 수 있는 모든 데이터 가능
        • HTML, 이미지, 영상, JSON etc…

HTTP 메서드

  • API URI 설계 표준
    • 리소스 식별 (명사)
      • 리소스: 회원
      • 계층 구조 상 상위 => 컬렉션 => 복수 명사(/members)
      • 계층 구조 상 하위 => 도큐먼트 => 식별자 구분 (/members/{id})
    • 행위는 HTTP 메서드로 분리 (동사)
      • 행위: 조회, 등록, 삭제, 변경
  • 주요 HTTP 메서드 종류
    • GET
      • 리소스 조회
      • 쿼리 파라미터로 데이터 전달
      • 최신 스펙에서 메시지 바디로 데이터 전달이 가능하지만, 지원하지 않는 곳이 있어 권장 X
    • POST
      • 요청 데이터 처리
      • 리소스마다 요청 데이터를 어떻게 처리할지 따로 정해야 함
        • 신규 리소스 등록
          • 회원가입, 게시판 글쓰기…
        • 프로세스 처리
          • 단순한 데이터 생성 및 변경을 넘어서 엮여있는 프로세스들을 처리해야 하는 경우
          • POST의 결과로 새 리소스가 생성되지 않을 수 있음
          • 주문에서 결제완료 -> 배달시작 -> 배달완료 같은 큰 작업들이 엮인 상태변경
          • POST /orders/{orderId}/start-delivery (보통 POST에서 컨트롤 URI 사용)
        • 다른 메서드로 처리하기 애매한 경우
          • JSON으로 조회 데이터 넘겨야 하는데, GET 메서드 사용하기 어려운 경우
          • 한 문서 끝에 내용 추가
      • 즉, 서버에서 큰 변화가 일어나는 것은 POST 사용
    • PUT
      • 리소스 대체 & 해당 리소스가 없을시 생성 (=덮어쓰기)
      • 요청에서 데이터가 누락되면 그대로 삭제됨 (위험성 존재)
      • 클라이언트가 리소스를 식별 (URI)
    • PATCH
      • 리소스 부분 변경
      • 실무 엔터티들은 데이터가 많기 때문에 변경에 주로 PATCH를 사용
      • PATCH를 못받아들이는 서버가 있다면 POST를 부분 변경에 사용한다.
    • DELETE
      • 리소스 삭제
  • HTTP 메서드의 속성
    http_method_attributes
    • 안전(Safe Methods)
      • 호출해도 리소스를 변경하지 않음
      • 안전한 메서드: GET
    • 멱등(Idempotent Methods)
      • 여러 번 호출해도 결과가 똑같음
      • 서버에 문제가 있을 때, 클라이언트가 같은 요청을 다시 해도 되는가의 판단 근거
      • 멱등하지 않은 메서드: POST, PATCH
    • 캐시가능(Cacheable Methods)
      • 응답 결과 리소스를 캐시해서 사용 가능
        • 큰 용량의 데이터를 로컬 PC 웹 브라우저 내부에 저장하고 있을 수 있는지 여부
      • 캐시 가능 메서드: GET, POST, PATCH
        • POST, PATCH는 메시지 바디까지 캐시 키로 고려해야 해서 구현이 어려움
        • 실제로 GET 정도만 캐시로 사용

Reference

모든 개발자를 위한 HTTP 웹 기본 지식