HTTP 기본지식

김광훈·2022년 1월 26일

개요

본 내용은 인프런 김영한님의 '모든 개발자를 위한 HTTP 웹 기본 지식'강의를 수강하고 작성한 글로 기억이 휘발되기 전에 글로써 남기기 위해 작성되는 글입니다. 남은 기억을 더듬어 작성하는 글인만큼 잘못된 내용이 많을 수 있으므로 자세한 내용은 해당 강의를 찾아보시는 것을 추천드립니다.

내용

Session

인터넷 네트워크
URI
HTTP
HTTP 메서드
HTTP 상태코드
HTTP 헤더

인터넷 네트워크

IP(인터넷 프로토콜)의 역할
지정한 IP 주소에 패킷(Packet)이라는 통신 단위로 데이터를 전달한다.
IP 프로토콜의 한계
- 비연결성 :패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
- 비신뢰성 : 중간에 패킷이 사라지거나 순서대로 안올때 문제 발생
- 프로그램 구분 : 같은 IP를 사용하는 서버에 통신하는 어플이 둘 이상일 때 문제 발생
TCP, UDP
이를 해결하기 위해 IP 패킷을 만들기 전에, TCP 또는 UDP를 통해 전송 정보를 담은 패킷을 만든다.
- TCP(전송 제어 프로토콜) 특징
  - 연결지향 - TCP 3 way handshake(가상 연결)
    클라이언트와 서버가 SYN과 ACK을 주고 받으면서 서로 논리적 연결 상태를 구성하는 것을 의미한다.
  - 데이터 전달 보증
    클라이언트에서 데이터를 전송하면 서버에서 데이터를 잘 받았다고 응답을 한다.
  - 순서 보장
    패킷의 순서가 잘못된 부분부터 패킷 재요청을 하여 순서를 보장한다.
- UDP(사용자 데이터그램 프로토콜) 특징
  - 기능이 거의 없음
  - 연결지향, 데이터 전달보증, 순서 보장 전부 안됨
  - 대신 단순하고 빠르다.
  - IP + PORT + 체크섬 정도의 기능만을 갖고 있다.
  - 애플리케이션에서 추가 작업을 진행해야한다.
PORT
한 서버에 두개 이상의 어플리케이션에 연결하기 위해 PORT를 이용한다.
TCP또는 UDP에서 PORT정보를 담아 보내게 된다.
- 0 ~ 65535 : 할당 가능
- 0 ~ 1023 : 이미 할당된 포트
  - FTP - 20, 21
  - TELNET - 23
  - HTTP - 80
  - HTTPS -443
DNS
도메인 네임 시스템으로 클라이언트가 서버에 요청을 할 때, DNS 서버에 우선 접근해 도메인과 매칭되는 IP를 찾아 접속한다.
인터넷 프로토콜 스택
대부분의 인터넷 프로토콜 스택은 TCP/IP를 따르고 있다.

전송 계층에서 TCP 패킹과 언패킹을 맡고있다. 이런 동작을 통해 IP 프로토콜의 한계를 극복할 수 있다.

URI

URI(Uniform Resource Identifier)는 URL, URN 모두를 아우르는 말로서 자원을 식별할 수 있는 모든 정보를 의미한다.

URL(Resource Locator)
- locator: 리소스가 있는 위치를 지정
- scheme://[userinfo@]host[:port][/path][?query][#fragment]
- https://www.google.com:443/search?q=hello&hl=ko
  - 프로토콜(https)
  - 호스트명(www.google.com)
  - 포트번호(443)
  - 패스(/search)
  - 쿼리 파라미터(q=hello&hl=ko)
URN(Resource Name)
- name: 리소스에 이름을 부여
- URN은 일반적으로 보편화가 되어 있지 않다.

HTTP

HTTP 특징
- 클라이언트 서버 구조
  Request Response구조로 클라이언트는 서버에 요청을 보내고 응답을 대기하면 서버가 요청에 대한 결과를 만들어서 응답한다.
- 무상태 프로토콜(스테이스리스), 비연결성
  서버가 클라이언트의 상태를 보존하지 않는다. 이런 특징 덕분에 Scale Out과 같이 서버 증설에 도움이 된다.
  - 비 연결성 한계와 극복
    HTTP 초기에 수 많은 자원을 받기위해 매번 3 way handshake를 실행했지만 HTTP 지속 연결(Persistent Connections)로 1번의 3 way handshake 동안 수 많은 자원을 모두 다운 받는 방식으로 문제를 극복했다.
- HTTP 메시지
  HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML 거의 모든 형태의 데이터 전송 가능하다.
  - HTTP 메시지 구조
    
    START-LINE 시작 라인
    - request-line = method request-target HTTP-version
    - status-line = HTTP-version status-code reason-phrase
    HEADER 헤더
    - field-name : field-value 로 구성되어 있다.
    EMPTY LINE 공백 라인
    MESSAGE BODY
    - 실제 전송할 데이터가 담긴다.

HTTP 메서드

API URI 설계 방법
1. 가능한한 리소스만 사용해서 PATH를 작성한다.
  예) /members/find -> /members
2. 계층 구조상 상위를 컬렉션으로 보고 복수단어를 사용한다.
  예) /member -> /members
GET : 리소스 조회
POST : 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체, 해당 리소스가 없으면 생성한다.(기존의 있던 데이터는 덮어씌운다.)
PATCH : 리소스 부분 변경(요청 데이터가 없으면 변경하지 않는다.)
DELETE : 리소스 삭제
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
메서드 속성
- 안전(Safe Methods) : GET
  호출해도 리소스를 변경하지 않는다.
- 멱등(Idempotent Methods) : GET, PUT, DELETE
  한번 호출하든 두 번 호출하든 결과가 똑같다.
- 캐시가능(Cacheable Methods) : GET, POST, PATCH(POST, PATCH는 구현이 쉽지 않음)
  응답 결과 리소스를 캐시해서 사용해도 되는가?

HTTP 상태코드

1xx(Informational) : 요청이 수신되어 처리중
2xx(Successful) : 요청 정상 처리
3xx(Redirection) : 요청을 완료하려면 추가 행동이 필요
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
- 영구 리다이렉션 : 특정 리소스 URI가 영구적으로 이동
  - 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
- 일시 리다이렉션 : 리소스의 URI가 일시적인 변경
  - 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
  - PRG(Post / Redirect / GET) : POST로 동작 후에 새로 고침으로 인해 POST가 다시 한번 요청되는 것을 방지하기 위해 GET 메서드로 리다이렉트하는 것을 말한다. 주로 결제와 같은 부분에 많이 사용된다.
- 특수 리다이렉션 : 결과 대신 캐시를 사용
4xx(Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
- 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요함
- 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
- 404 Not Found : 요청 리소스를 찾을 수 없음
5xx(Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함

HTTP 헤더

표현
- Content-Type : 표현 데이터의 형식
  - 미디어 타입, 문자 인코딩
  - 예)
    - text/html; charset=utf-8
    - application/json
- Content-Encoding : 표현 데이터의 압축 방식
  - 표현 데이터를 압축하기 위해 사용
  - 데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가한다.
  - 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제한다.
  - 예)
    - gzip
    - identity
- Content-Language : 표현 데이터의 자연 언어
  - 표현 데이터의 자연 언어를 표현한다.
  - 예)
    - ko
    - en
    - en-US
- Content-Length : 표현 데이터의 길이
  - 바이트 단위

협상(콘텐츠 네고시에이션) : 클라이언트가 선호하는 표현 요청
- Accept: 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset: 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
- Accept-Language: 클라이언트가 선호하는 자연 언어
일반 정보
- From : 유저 에이전트의 이메일 정보
- Referer : 이전 웹 페이지 주소
- User-Agent : 유저 에이전트 애플리케이션 정보
- Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
- Date : 메시지가 발생한 날짜와 시간
특별한 정보
- Host : 요청한 호스트 정보(도메인)
- Location : 페이지 리다이렉션
- Allow : 허용 가능한 HTTP 메서드
- Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
인증
- Authorization: 클라이언트 인증 정보를 서버에 전달
- WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의
쿠키
- Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
- Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
- 쿠키 - 도메인
  - 예) domain = example.org
  - 명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함
- 쿠키 - 경로
  - 예) path=/home
  - 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
  - 일반적으로 path=/ 루트로 지정
- 쿠키 - 보안
  - Secure : 명시할 경우 https인 경우에만 전송
  - HttpOnly : 명시할 경우 XSS 공격 방지(자바스크립트에서 접근 불가능하다)
  - SameSite : XSRF 공격을 방지(요청 도메인과 쿠키에 설정된 도메인이 같을 경우만 쿠키를 전송한다.)
캐시 기본 동작
- 캐시가 없으면 데이터가 변경되지 않아도 계속해서 데이터를 다운받아야 한다.
- 캐시가 있다면(캐시 만료x), 캐시 저장소에서 해당 데이터를 가져온다.
- 캐시가 있다면(캐시 만료o), 서버를 통해 다시 조회하고 캐시를 갱신한다.
검증 헤더와 조건부 요청
캐시가 만료됬지만, 서버에서 데이터가 수정되지 않았을 경우가 있을 수 있다. 이를 해결하기 위한 방안이다.
- Last-Modified에 데이터가 마지막 수정된 시간이 있다.
- 캐시가 만료됬을 때, if-modified-since을 기록해서 요청하고 최종 수정일과 동일하다면 304 Not Modified라고 응답한다.(HTTP Body가 없음)
- 단점
  - 1초 미만 단위로 캐시 조정이 불가능
  - 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
ETag, If-None-Match
- ETag(Entity Tag)
- 캐시용 데이터에 임의의 고유한 버전이름을 달아두고 데이터가 변경되면 이 이름을 바꿔서 변경한다.
- 이름이 다르면 데이터가 변경됬다고 판단하고, 이름이 같으면 데이터가 동일하다고 판단하고 304를 내려준다.
- 예) 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신
캐시 제어 헤더
- Cache-Controle : 캐시 지시어
  - max-age : 캐시 유효시간. 초단위
  - no-cache : 데이터는 캐시해도 되지만, 항상 원(orgin) 서버에 검증하고 사용
  - no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
  - public : 응답이 public 캐시에 저장되어도 됨
  - private : 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
  - s-maxage : 프록시 캐시에만 적용되는 max-age
  - Age: 60(HTTP 헤더) : 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
  - must-revalidate : 캐시 만료 후 최조 조회시 원 서버에 검증해야함, 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
프록시 캐시
- 한국 -> 미국에 있는 원 서버 : 오래 걸린다.
- 한국 -> 프록시 캐시 서버(한국 어딘가) -> 미국에 있는 원 서버 : 빠르다.
캐시 무효화
예민한 정보는 캐시를 사용해서는 안되는데 확실한 캐시 무효화 응답을 위해서는 아래에 있는 것을 모두 명시해줘야한다.
- Cache-Control: no-cache, no-store, must-revalidate
- Pragma: no-cache
만약 프록시 캐시와 원서버 네트워크가 단절된다면, no-cahce의 경우 오류 보다는 오래된 데이터라도 보여주자라는 설정이 있을 수 있다고 한다. 그렇기 때문에, must-revalidate를 추가해준다.