김영한의 스프링 완전 정복 로드맵
3. 모든 개발자를 위한 HTTP 웹 기본 지식 정리입니다.

섹션1. 인터넷 네트워크

IP(인터넷 프로토콜)

• 지정한 IP 주소(IP Address)에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달

IP 프로토콜의 한계

비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
비신뢰성 : 중간에 패킷사라지거나 순서대로 안올 경우
프로그램 구분 : 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일때 구분 한계

TCP, UDP

TCP 특징

전송 제어 프로토콜(Transmission Control Protocol)
• 연결지향 - TCP 3 way handshake (가상 연결)
• 데이터 전달 보증, 순서보장, 신회할수 있는 프로토콜

＊ 현재 대부분 TCP사용

UDP 특징

사용자 데이터그램 프로토콜(User Datagram Protocol)

• 기능이 거의 없음
• 데이터 전달 보증X, 순서 보장X 단순하고 빠름
• 애플리케이션에서 추가 작업 필요

PORT

같은 IP 내에서 프로세스 구분

DNS

도메인 네임 시스템(Domain Name System)
도메인 명을 IP 주소로 변환한다.

섹션2. URI와 웹 브라우저 요청 흐름

URI(Uniform Resource Identifier)

URI는 로케이터(locator), 이름(name) 또는 둘다 추가로 분류될 수 있다"
URI = URL + URN

• Uniform : 리소스 식별하는 통일된 방식
• Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음)
• Identifier : 다른 항목과 구분하는데 필요한 정보

URL - Locator: 리소스가 있는 위치를 지정
URN - Name: 리소스에 이름을 부여
위치는 변할 수 있지만, 이름은 변하지 않는다

URL 전체 문법

프로토콜(https)
• 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙

호스트명(www.google.com)
• 도메인명 또는 IP 주소를 직접 사용가능

포트 번호(443)
• 일반적으로 생략한다
• 생략시 http는 80, https는 443

패스(/search) :
• 리소스 경로(path), 계층적 구조

쿼리 파라미터(q=hello&hl=ko)
• key=value 형태
• ?로 시작 &로 추가 가능
• 웹서버에 제공하는 파라미터, 문자 형태

웹 브라우저 요청 흐름

HTTP 메시지 전송
1. 웹 브라우저가 HTTP 메시지 생성
2. SOCKET 라이브러리를 통해 전달
3. TCP/IP 패킷 생성, HTTP 메시지 포함

섹션3. HTTP 기본

모든 것이 HTTP

HTTP 메시지에 모든 것을 전송
• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

HTTP 특징
클라인언트 서버 구조, 무상태 프로토콜(스테이스리스), 비연결성
HTTP 메시지, 단순함, 확장 가능하다

클라이언트 서버 구조

Request Response 구조
클라이언트는 서버에 요청을 보내고 응답을 대기, 서버가 요청에 대한 결과를 만들어서 응답한다.

무상태 프로토콜 스테이스리스(Stateless)
서버가 클라이언트의 상태를 보존하지 않는다.
장점 : 서버 확장성 높음(스케일 아웃)
단점 : 클라리언트가 추가 데이터 전송

Stateful, Stateless

Stateful 상태유지

• 상태를 유지한다
• 항상 같은 서버가 유지되어야 한다.

Stateless 무상태

• 상태를 유지 하지 않는다.
• 갑자기 클라이언트 요처이 증가해도 서버를 대거 투입 할 수 있다. (스케일 아웃, 수평확장에 유리)
• 응답 서버를 쉽게 바꿀수 있다.(무한한 서버 증설 가능)
• 서버에 장애가 있더라도 다른 서버로 교체가 용이하다.

비 연결성(connectionless)

• HTTP는 기본적으로 연결을 유지하지 않는 모델이다.
• 일반적으로 초 단위의 이하의 빠른 속도로 응답
• 실제 동시 처리 요청은 매무 적다

한계와 극복

• TCP/IP 연결을 새로 맺어야 함(3 way handshake 시간 추가)
• HTML, 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드 됨
• 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결

HTTP 메시지

요청 메시지

• start-line = request-line / status-line
• request-line = method SP(공백) request-target SP HTTP-- version CRLF(엔터)
• HTTP method
  • GET, POST, PUT, DELETE..
  • 서버가 수행해야할 동작 지정
• request-target(요청 대상)
  • 절대경로= "/" 로 시작하는 경로
• HTTP Version
• Status-code: 요청 성공, 실패를 나타낸다
  • 200: 성공
  • 400: 클라이언트 요청 오류
  • 500: 서버 내부 오류
• 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글

응답 메시지

• start-line = request-line / status-line
• status-line = HTTP-version SP status-code SP reason-phrase CRLF

헤더

• header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
• field-name은 대소문자 구문 없음
• HTTP 전송에 필요한 모든 부가정보
  예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...
• 표준 헤더가 너무 많음
• 필요시 임의의 헤더 추가 가능이 있음

메시지 바디

실제 전송할 데이터, byte로 표현할 수 있는 모든 데이터 전송 가능

섹션4. HTTP 메서트

HTTP 메서드 종류

• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아 권장하지 않음.

POST

• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

PUT

• 리소스가 있으면 대체, 리소스가 없으면 생성
• 클라이언트가 리소스를 식별
• 클라이언트가 리소스 위치를 알고 URI 지정하는 것이 POST와 차이점

PATCH

• 리소스 부분 변경

DELETE

• 리소스 제거

HTTP 메서드의 속성

안전(Safe Methods)

• 호출해도 리소스를 변경하지 않는다.
• GET, HEAD(GET에서 body부분만 뺀 것)

멱등(Idempotent Methods)

• f(f(x)) = f(x)
• 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다
• GET, PUT, DELETE = O POST = X
  • GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
  • PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
  • DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
  • POST: 멱등X 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

캐시가능(Cacheable Methods)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD 정도만 캐시로 사용
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

섹션5. HTTP 메서드 활용

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

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

4가지 상황에 따른 데이터 전송

정적 데이터 조회

• 이미지, 정적 텍스트 문서
• 조회는 GET 사용
• 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

동적 데이터 조회

• 주로 검색, 게시판 목록에서 정렬 필터(검색어)
• 회원 가입, 상품 주문, 데이터 변경
• 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
• 조회는 GET 사용
• GET은 쿼리 파라미터 사용해서 데이터를 전달

HTML Form을 통한 데이터 전송

• HTML Form submit시 POST 전송(회원 가입, 상품 주문, 데이터 변경)
• Content-Type: multipart/form-data
  • 파일 업로드 같은 바이너리 데이터 전송시 사용
  • 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능ㄴ
• HTML Form 전송은 GET, POST만 지원

HTTP API를 통한 데이터 전송

• 회원 가입, 상품 주문, 데이터 변경
• 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)

HTTP API 설계 예시

컬렉션

• POST 기반 등록

스토어

• PUT 기반 등록

HTML FORM 사용

•웹 페이지 회원 관리
• GET, POST만 지원

섹션6. HTTP 상태코드

1xx (Informational)

• 요청이 수신되어 처리중
• 거의 사용하지 않으므로 생략

2xx (Successful)

• 클라이언트의 요청을 성공적으로 처리
200 OK : 요청 성공
201 Created : 요청 성공해서 새로운 리소스가 생성됨
202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음
204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

3xx (Redirection)

• 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

Redirection 이해

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다.
영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동
일시 리다이렉션 : 일시적인 변경
특수 리다이렉션 : 결과 대신 캐시를 사용

영구 리다이렉션 301, 308

• 리소스의 URI가 영구적으로 이동
• 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지

301 Moved Permanently

• 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
• 실무에선 주로 301을 사용

308 Permanent Redirect

• 301과 기능은 같음
• 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

일시적인 리다이렉션 302, 307, 303

• 리소스의 URI가 일시적으로 변경
• 따라서 검색 엔진 등에서 URL을 변경하면 안됨

302 Found

• 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

307 Temporary Redirect

• 302와 기능은 같음
• 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)

303 See Other

• 302와 기능은 같음
• 리다이렉트시 요청 메서드가 GET으로 변경

기타 리다이렉션

304 Not Modified

• 캐시를 목적으로 사용
• 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에
저장된 캐시를 재사용한다. (캐시로 리다이렉트 한다.)
• 304 응답은 응답에 메시지 바디를 포함하면 안된다.
• 조건부 GET, HEAD 요청시 사용

PRG 이후 리다이렉트

• URL이 이미 POST -> GET으로 리다이렉트 됨
• 새로 고침 해도 GET으로 결과 화면만 조회

4xx (Client Error)

•클라이언트 오류, 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 오류의 원인이 클라이언트에 있다

400 Bad Request

• 요청 구문 메시지 등등의 오류

401 Unauthorized

• 클라이언트가 해당 리소스에 대한 인증이 필요함

403 Forbidden

• 서버가 요청을 이해했지만 승인을 거부함

404 Not Found

• 요청 리소스를 찾을 수 없음

5xx (Server Error)

• 서버 문제로 오류 발생
• 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음(복구가 되거나 등등)

500 Internal Server Error

• 서버 내부 문제로 오류 발생

503 Service Unavailable 서비스 이용 불가

• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음

섹션7. HTTP 헤더1 -일반 헤더

• HTTP 전송에 필요한 모든 부가정보
• 표준 헤더가 너무 많음
• 필요시 임의의 헤더 추가 가능하다.

HTTP 헤더의 분류

1. General 헤더 : 메시지 전체에 적용되는 정보
2. Request 헤더: 요청 정보
3. Response 헤더 : 응답 정보
4. Entity 헤더 : 엔티티 바디 정보

HTTP 바디

• 메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용된다.
• 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터.
• 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공.

표현 헤더

Content-Type : 표현 데이터의 형식
Content-Encoding : 표현 데이터의 압축 방식
Content-Language : 표현 데이터의 자연 언어
Content-Length : 표현 데이터의 길이

협상(콘텐츠 네고시에이션)

클라이언트가 선호하는 표현 요청, 요청시에만 사용한다.

Accept : 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset : 클라이언트가 선호하는 문자 인코딩
Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
Accept-Language : 클라이언트가 선호하는 자연 언어

전송 방식 설명

• 단순 전송
• 압축 전송
• 분할 전송
• 범위 전송

일반 정보

From : 유저 에이전트의 이메일 정보
Referer : 이전 웹 페이지 주소
User-Agent : 유저 에이전트 애플리케이션 정보
Server : 요청을 처리하는 오리진 서버의 소프트웨어 정보
Date : 메시지가 생성된 날짜

특별한 정보

Host : 요청한 호스트 정보(도메인)
Location : 페이지 리다이렉션
Allow : 허용 가능한 HTTP 메서드
Retry-After
• 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
• 503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음

인증

Authorization : 클라이언트 인증 정보를 서버에 전달
WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의

쿠키

Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

• 사용자 로그인 세션 관리, 광고 정보 트래킹

• 쿠키 정보는 항상 서버에 전송됨

  • 네트워크 트래픽 추가 유발
  • 최소한의 정보만 사용(세션 id, 인증 토큰)
  • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 참고

• 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)

생명주기

세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

도메인

명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
생략: 현재 문서 기준 도메인만 적용

경로

경로를 포함한 하위 경로 페이지만 쿠키 접근 가능

보안

Secure

• 쿠키는 http, https를 구분하지 않고 전송
• Secure를 적용하면 https인 경우에만 전송

HttpOnly

• XSS 공격 방지
• 자바스크립트에서 접근 불가(document.cookie)
• HTTP 전송에만 사용

SameSite

• XSRF 공격 방지
• 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

섹션8. HTTP 헤더1 -캐시와 조건부 요청

캐시 기본 동작

캐시가 없을 때는 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸다.

캐시 적용하면 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
비싼 네트워크 사용량을 줄일 수 있고 브라우저 로딩 속도가 매우 빠르다.

캐시 시간 초과

캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다

검증 헤더

Last-Modified

• 1초 미만단위로 캐시 조정이 불가능, 날짜 기반의 로직 사용한다.
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

ETag

• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 데이터가 변경되면 이 이름을 바꾸어서 변경함
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 단순히 이 값을 서버에 제공

캐시와 조건부 요청 헤더

Cache-Control: 캐시 제어

max-age : 캐시 유효 시간, 초 단위
no-cache : 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

Pragma: 캐시 제어(하위 호환)

• HTTP 1.0 하위 호환
• Pragma: no-cache

Expires: 캐시 유효 기간(하위 호환)

• HTTP 1.0 부터 사용
• 캐시 만료일을 정확한 날짜로 지정
• 지금은 더 유연한 Cache-Control: max-age 권장
• Cache-Control: max-age와 함께 사용하면 Expires는 무시

프록시 캐시

서버가 멀리 떨어져 있을 경우 시간이 오래 걸리기 때문에, 프록시 캐시를 어딘가에 만들고 거쳐서 오도록 기점의 서버를 사용하는 것이다.

캐시 지시어(directives) -기타

public : 응답이 public 캐시에 저장되어도 됨
private : 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
s-maxage : 프록시 캐시에만 적용되는 max-age
Age:60 (HTTP 헤더) : 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

캐시 무효화

no-cache : 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용

no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

must-revalidate :
-캐시 만료후 최초 조회시 원 서버에 검증해야함
-원 서버 접근 실패시 반드시 504오류가 발생해야함
-캐시 유효 시간이라면 캐시를 사용함

Pragma: no-cache : HTTP 1.0 하위 호환