본문 바로가기
카테고리 없음

HTTP 웹 기본 지식 - 1

migi111 2026. 2. 15. 23:11
토이 프로젝트 제작과 더불어 인터넷 통신의 이론적인 부분을 학습하고
간단한 예제로 감을 잡고 가면 내 작업도 훨씬 수월할 거 같다고 생각하여 이번 강의를 수강하고 정리하였다.

 

인터넷 네트워크

  • IP(인터넷 프로토콜)
    • 지정한 IP 주소에 데이터를 전달한다.
    • 특정 패킷이라는 것을 가지고 전달한다, 일종의 형식이라고 생각하자
      • IP패킷: 출발지 IP, 도착지 IP,,,
    • 전달
      • 클라이언트 -> 서버
      • 서버 -> 클라이언트
    • 한계
      • 비연결성
        • 만약 받는 사람 인터넷이 꺼져있다면?
      • 비신뢰성
        • 패킷이 전달 도중에 사라진다면?
        • 패킷의 전달 순서가 달라진다면?
      • 프로그램 구분
        • 같은 컴퓨터에서 게임도 하고 음악도 듣고 하는데 어떻게 구분하지?
  • TCP (Transmission Control Protocol)
    • IP에 TCP를 덧붙여서 IP 패킷을 전송한다고 보면 된다.
    • TCP에는 출발지 port, 도착지 port, 전송 제어, 순서, 검증 정보,,
      • 연결지향 3 way handshake
        • 클라이언트 -> 서버: syn (접속 요청)
        • 서버 -> 클라이언트: syn + ack(요청 수락)
        • 클라이언트 -> 서버: ack   /'신 신액 액' 으로 생각해보자
          요즘은 3번 ack에서 데이터를 함께 전송 가능하다.
        • 따라서 신뢰할 수 있는 프로토콜이지만, 이는 논리적, 개념적으로 연결 되었다는 것을 알아두자.
          실제 물리적인 연결은 여러 서버들을 거쳐서 도달한다!
      • 데이터 전달 보증
        • 서버가 데이터를 전달 받으면 확인 데이터를 보내준다.
      • 순서 보장
        • TCP에는 패킷 순서를 보장하는 것이 들어있다.
    • UDP (User Datagram Protocol)
      • 하얀 도화지 / 기능이 거의 없다
      • IP 기능 + PORT + 체크섬 기능 => 요즘 각광받고 있다.
  • PORT => 같은 IP 내에서 여러 작업을 수행하는 경우 구분이 가능하게 한다.
    • IP는 목적지 IP를 가지고, PORT는 같은 IP내에서 프로세스를 구분한다
    • TCP/IP 패킷: 출발지 IP, PORT / 목적지 IP, PORT / 전송 데이터 이런 둘이 합쳐진 정보들
    • 0 ~ 65535: 할당 가능
    • 0 ~ 1023: 사용하지 않는 것이 좋다
      • HTTP 80 포트: 웹 브라우저
      • HTTPS 443 포트: 보안이 추가된 웹
  • DNS (Domain Name System)
    • IP가 변경될 수 있다.
    • 도메인 명을 IP주소로 변환해서 제공하는 일종의 IP 전화번호부

URI

uniform: 식별할 수 있는 통일된 방식
resource: URI로 식별할 수 있는 모든 것 (실시간 정보, 날씨,,제한이 없음)
identifier: 다른 항목과 구분되는데 필요한 정보

 

URI > URL, URN

 

 

🔎 hello: Google 검색

 

www.google.com

  • scheme://[userinfo@]host[:port][/path][?query][#fragment]  이런 형태의 문법을 가진다.
    • scheme 프로토콜: 어떤 방식으로 접근할 지
      • http 는 80이 붙고, https 는 443 (요즘은 거의 다 443, http에 강력한 보안이 포함된 것)
    • userinfo: URL에 사용자 정보 포함해서 인증
      거의 사용안함
    • host: 호스트명, 도메인명이나 IP주소를 직접 사용할 수도 있다.
    • PORT: 일반적으로 생략, 생략 시 http - 80 / https - 443
    • path: 리소스 경로 (/members, /members/100,,,)
    • query: key=value 형태, 웹 서버에 제공하는 파라미터

웹 브라우저 요청 흐름

<클라이언트>

  1. DNS 조회
  2. 웹 브라우저가 HTTP요청 메시지 생성
  3. socket통해서 TCP/IP 연결
  4. OS 계층에서 TCP/IP 패킷 생성, 메시지 포함

<서버>

  1. 응답 메시지 생성
  2. 응답 패킷 전달 (위와 같은 방법으로)
  3. 클라이언트가 메시지를 렌더링해서 띄운다.

 

HTTP 통신

HyperText Transfer Protocol

 

http로 모든 것을 전송한다. 모든 형태의 데이터

 

  • 기반 프로토콜
    • HTTP/1.1 이나 HTTP/2 는 TCP 기반
    • HTTP/3 은 UDP 기반
    • 현재는 1.1을 주로 사용하지만, 2나 3도 점점 증가하고 있다.
  • 특징
    • 클라이언트 서버 구조
    • 무상태 프로토콜
    • HTTP 메시지
    • 단순함
  1. 클라이언트와 서버 구조
    1. 클라이언트는 서버에 요청을 보내고, 응답을 대기
    2. 서버가 요청에 대한 결과를 만들어서 응답
    3. 클라이언트와 서버가 각각 독립적으로 진화
      클라이언트는 UI에 집중 / 서버는 로직, 데이터에 집중
  2. 무상태 프로토콜 stateless (제일 중요!) - 항상 무상태로 설계하자
    1. 서버가 클라이언트의 상태를 보존하지 않는다.
    2. 예시: 점원 교체
      1. 상태 유지: 중간에 점원이 바뀌면 상태 정보를 다른 점원에게 미리 알려줘야 함
      2. 무상태: 중간에 점원이 바뀌어도 된다.
    3. 스케일 아웃 - 수평 확장에 유리하다: 트래픽이 많아지면 서버를 대폭 늘릴 수 있다.
    4. 모든 것을 무상태로 설계할 수 있는 경우와 없는 경우가 있다.
  3. 비연결성
    1. HTTP는 연결을 유지하지 않는 모델, 초 단위의 빠른 속도로 응답
    2. 동시에 처리하는 요청은 수십 개 이하로 매우 작다.
    3. 서버 자원을 효율적으로 사용할 수 있다!
      1. 단점
        TCP/IP 연결을 새로 맺어야 한다
        HTML 뿐만 아니라 새로운 자원이 함께 다운로드된다
        현재는 HTTP2, 3에서 더 많은 최적화가 되었다
        지금은 지속 연결으로 해결!

 

  • HTTP 메시지 => 요청 메시지 / 응답 메시지
    • 시작 라인
      • HTTP 요청 메시지에서는 request-line 이라고 한다
        • HTTP 메서드: Get, Post,,
        • 요청 대상: 절대경로 "/"로 시작
        • HTTP 버전
        • 위 3가지가 들어간다.
      • HTTP 응답 메시지에서는 status-line 이라고 한다.
        • HTTP 버전
        • HTTP 상태 코드: 요청 성공, 실패를 나타낸다
        • 이유 문구: 사람이 읽을 수 있는 짧은 문구
        • 2가지가 들어간다.
    • 헤더
      • field-name과 value가 있다.
      • field-name은 대소문자 구분이 없다
      • 용도
        • HTTP 전송에 필요한 모든 부가정보
        • 필요시 임의의 헤더를 추가할 수 있다.
    • 메시지 바디
      • 실제 전송할 데이터
      • byte로 표현할 수 있는 모든 데이터 (사진, JSON, HTML ,,,,)

HTTP는 단순하고 확장 가능하다.

메세지에 모든 것을 전송할 수 있다.

김영한 강사님: '바야흐로 지금은 HTTP 시대입니다'

 

 HTTP 메서드

  • 요구사항
    • 회원 목록 조회: read
    • 회원 조회: read
    • 회원 등록: create
    • 회원 수정: update
    • 회원 삭제: delete
  • URI 설계
    • 리소스 식별을 기준으로 설계해야 한다!
    • 요구사항에서는 '회원'이 리소스 / '조회', '등록' 등은 메서드이다.
    • 리소스와 행위를 분리해야 한다.
    • 행위: 조회, 등록, 삭제, 변경
      • 리소스는 명사 / 행위는 동사
  • HTTP 메서드 - 행위
    • 클라이언트가 서버에 요청할 때 기대하는 것
      • GET: 리소스 조회
      • POST: 요청 데이터 처리, 주로 등록에 사용
      • PUT: 리소스를 대체
      • PACTH: 리소스 부분 변경
      • DELETE: 리소스 삭제
    • GET
      • 서버에 전달하고 싶은 데이터는 query를 통해서 전달
      • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 많이 사용하지 않는다.
    • POST
      • 메시지 바디를 통해 서버로 요청 데이터를 전달
      • 서버는 요청 데이터를 처리
        • 데이터를 처리하는 모든 기능을 다 수행한다.
        • 변경을 넘어서서 프로세스를 처리해야 하는 경우
        • 새로운 리소스가 생성이 안될 수도 있다.
        • POST/orders/{orderId}/start-delivery (컨트롤 URI에도 사용된다.)
      • 새 리소스를 생성하거나 등록하는데 사용한다.
      • 다른 메서드로 처리하기 애매한 경우
        • JSON으로 조회 데이터를 넘겨야 하는데, GET메서드를 사용하기 어려운 경우
      • 애매하면 POST
    • PUT
      • 리소스를 대체
        • 리소스가 있으면 대체
          • 리소스를 완전히 대체한다
          • 기존 리소스를 삭제하고 덮어만든다고 생각하기!
        • 리소스가 없으면 생성
        • 덮어버린다고 생각하자!
      • 클라이언트가 리소스 식별
        • 클라이언트가 리소스 위치를 알고 지정
          • PUT/members/100 HTTP/1.1 이런 식
    • PATCH
      • 리소스 부분 변경 PUT과 다르다!
    • DELETE
      • 리소스 제거

 

  • HTTP 메서드의 속성
    • 안전: 여러 번 호출해도 리소스를 변경하지 않는다.
      • 해당 리소스가 변하는지 여부에 대해서만 고려
    • 멱등 Idempotent: 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
      멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.
      GET => 중간에 PUT으로 바꾸고 => GET 멱등하지 않다고 판단
      • GET: 한 번 조회든 두 번 조회든 같은 결과가 조회
      • PUT: 결과를 대체, 같은 요청을 여러 번 해도 최종 결과 같음
      • DELETE: 결과를 삭제, 여러 번 요청해도 삭제된 결과는 똑같다.
      • POST: 멱등이 아니다! 중복 결제 등
      • 자동 복구 매커니즘에 활용한다. 
        <서버가 TIMEOUT 등으로 정상 응답을 못주었을 때,
        클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단 근거>
    • 캐시 가능
      • 응답 결과 리소스를 캐시
      • GET, HEAD, POST, PATCH 캐시 가능
      • 실제로는 GET, HEAD 정도만 캐시로 사용

 

클라이언트에서 서버로 전송

  • 쿼리 파라미터를 통한 데이터 전송
    • GET에서 주로 사용한다.
    • 정렬 필터(검색어)에 주로 활용한다.
  • 메시지 바디를 통한 데이터 전송
    • POST, PUT, PATCH를 주로 사용
    • 회원 가입, 상품 주문, 리소스 등록 변경 등에 주로 사용한다.

 

<여러 가지 상황>

  1. 정적 데이터 조회
    1. GET 사 
    2. 이미지, 정적 텍스트 문서
    3. 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가 가능하다.
  2. 동적 데이터 조회
    1. 검색, 게시판 목록에서 검색
    2. 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
    3. GET은 쿼리 파리미터 사용해서 데이터를 전달
  3. HTML FORM 데이터 전송
    1. POST 전송 (key - value 방식으로 서버에 전송)
      1. 웹 브라우저가 요청 HTTP 메시지를 생성한다.
      2. content-type 이라는 것이 있다.
        Content-Type: application/x-www-form-urlencoded
        이것이 form의 내용을 메시지 바디를 통해 전송하게 해준다. / url encoding 처리
    2. GET 전송
      1. 조회하는 기능에 사용하여 데이터를 전송한다.
    3. multipart/form-data
      1. 이름, 나이, 이미지를 같이 보낼 때 사용한다. => 여러 종류의 파일과 폼의 내용을 함께 전송 가능하다.
        1. content-type 이 multipart/form-data 가 되면서 웹 브라우저가 영역을 나누어서
          요청 HTTP 메시지를 생성한다.
    4. HTML FORM 전송은 POST / GET 만 사용 가능!!
  4. HTTP API 전송
    1. 서버끼리 통신할 때 많이 사용한다.
    2. 앱 클라이언트에서 전송할 때 사용
    3. 웹 클라이언트 통신
      1. HTML FORM 전송 대신 자바 스크립트를 통한 통신에 사용 (AJAX)
        리액트, 뷰 같은 것들
    4. POST, PUT, PATCH: 메시지 바디로 데이터 전송
    5. GET 조회 : 쿼리 파라미터로 데이터 전달!
    6. Content-type: application/json 을 주로 사용

 

HTTP API 설계

  • HTTP API - 컬렉션 => 대부분 이것을 사용한다!
    • 회원 관리 시스템 (POST 기반 등록)
    • 클라이언트가 리소스 URI 를 알지 못한다.
    • 서버가 URI를 생성하여 관리한다.
  • HTTP API - 스토어
    • 파일 관리 시스템 (PUT 기반 등록)
    • 클라이언트가 리소스를 지정한다.
    • 클라이언트가 리소스를 직접 관리한다.
  • HTML FORM 사용 (순수 HTML 폼 가정)
    • GET, POST 만 지원
    • 컨트롤 URI 사용 -> POST 기반 등록에서도 사용한다!
      • GET, POST만 지원되기 때문에 제약이 있다.
      • 동사로 된 리소스 경로를 사용한다.
      • /edit, /delete 등
      • /members/{id}/edit 이런 식

 

이론으로 살펴보았고 HTTP API 설계 부분은 토이 프로젝트로 직접 설계하며 복습할 예정이다.
다음은 상태코드와 헤더의 기능에 대해 학습할 예정이다!

티스토리툴바