HTTP 총정리

 

인터넷 네트워크

 

IP

• 인터넷 프로토콜
• 클라이언트와 서버는 IP 주소를 부여받는다.
• IP 주소를 통해 데이터를 전달한다.
• 패킷(Packet)이라는 통신 단위로 데이터를 전달한다.
  • 인터넷 망에 있는 각 노드들은 IP를 따르고 있기 때문에,
    IP 패킷의 정보를 토대로 목적지 IP까지의 경로를 찾아 데이터를 전달한다.

IP 패킷 정보

 

IP의 한계

• 비연결성
  • 패킷을 받을 대상이 없거나 서비스 불능 상태에서도 패킷이 전송된다.(편지의 우편 발송처럼)
• 비신뢰성
  • 중간에 패킷이 사라질 수 있다.
  • 패킷이 순서대로 전송되지 않을 수 있다.
• 프로그램 구분
  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 때 구분할 수 없다.

 

TCP/IP

• IP의 한계를 극복하기 위해 TCP를 같이 사용한다.
• 데이터의 흐름이나 정확성을 확인하는 것은 TCP가 담당한다.
• 목적지까지의 데이터 전송은 IP가 담당한다.

 

인터넷 프로토콜 스택의 4계층(TCP/IP 4 계층)

• 애플리케이션 계층 : HTTP, FTP
• 전송 계층 - TCP, UDP
• 인터넷 계층 - IP
• 네트워크 인터페이스 계층 - LAN 카드

 

TCP/IP 4 계층 동작 과정 예시

1. 채팅 프로그램에서 메시지를 작성한다.
2. 작성된 메시지는 SOCKET 라이브러리를 통해 OS 계층으로 이동한다.
   cf) OS 계층은 인터넷 계층의 IP와 전송 계층의 TCP/UDP를 포함하는 계층
   cf) SOCKET 라이브러리는 애플리케이션 계층에 존재한다.
3. OS 계층에서 메시지는 TCP 정보(TCP 세그먼트)를 생성한다.
4. 이후 IP 패킷을 생성한다.
5. 네트워크 인터페이스 계층에서 데이터가 실제로 전송된다.

최종적으로 만들어진 TCP/IP 패킷 정보

 

TCP

 

TCP 특징

• Transmission Control Protocol의 약자
• 전송 제어 프로토콜
• 연결 지향 - TCP 3 way handshake(가상 연결)
• 데이터 전달 보증 - 데이터 손실 유무 판단
• 순서 보장 - 패킷 전송 순서 보장
• TCP는 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

 

TCP 3 way handshake

• TCP 3 way handshake 과정
  1. 클라이언트에서 서버로 SYN(접속 요청) 메시지를 보낸다.
  2. 서버는 SYN 메시지를 받으면 클라이언트에게 SYN+ACK(요청 수락) 메시지를 보낸다.
  3. 메시지를 받은 클라이언트는 다시 서버에 ACK 메시지를 보낸다.
  4. 1~3 과정이 완료된 후에 데이터를 전송한다.
• TCP 3 way handshake의 특징
  • 실제로 물리적인 연결을 의미하는 것은 아니다.
  • TCP 3 way handshake는 가상적인 연결로 논리적인 연결을 의미한다.

 

순서 보장

• TCP는 패킷이 순서대로 전송되지 않았을 경우 잘못된 순서부터 다시 보내게 한다.
• 이러한 과정을 통해 패킷의 전송 순서를 보장한다.

 

 

UDP

 

UDP 특징

• 사용자 데이터그램 프로토콜(User Datagram Protocol)
• UDP는 하얀 도화지에 비유된다.(기능이 거의 없기 때문)
• 연결을 지향하지 않고, 데이터 전달을 보장하지 않고, 순서를 보장하지 않는다.
• 하지만 TCP에 비해 단순하고 빠르다.
• 정리
  • IP와 거의 같다.
  • IP에 포트나 체크섬 정도만 추가된다.
  • 애플리케이션에서 추가 작업이 필요하다.
    • UDP는 하얀 도화지 같이 기능이 거의 없기 때문에 사용자 필요에 따라
      새로운 기능을 정의하여 사용하는 것이 가능하다.
    • TCP는 기능이 이미 다 정의되어 있기 때문에 새로운 기능을 정의하지 않는다.

 

PORT

• IP만 가지고 패킷을 구성할 경우 하나의 서버에 여러 IP 패킷 정보가 오게 되면
  어떤 패킷이 어떤 정보를 가진 패킷인지 알 수 없다.
• 즉, 포트는 같은 IP내에서 프로세스를 구분할 때 사용한다.
• 포트 번호
  • 0 ~ 65535 할당 가능
  • 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋다.
    • FTP - 20, 21
    • TELNET - 23
    • HTTP - 80
    • HTTPS - 443
• TCP/IP 패킷 정보를 사용할 겨우 IP에 더해 출발지/목적지의 포트 정보를 패킷에 담을 수 있다.
• 따라서 하나의 클라이언트에 여러 패킷이 도달해도 포트 정보로 패킷을 구분할 수 있다.
• 서버에서 응답할 때 클라이언트의 포트를 아는 이유는?
  • 패킷을 전송할 때 출발지의 포트 정보를 담아서 보내기 때문에

 

DNS

 

IP의 단점

• IP는 기억하기 어렵다.
• IP는 변경될 수 있다.

 

DNS(Domain Name System)

• 전화번호부 같은 역할을 한다.
• 도메인 명을 IP 주소로 변환해준다.
• 예)
  • 도메인 명 : google.com
  • IP 주소 : 200.200.200.2

 

 

 

URI와 웹 브라우저 요청 흐름

 

URI란?

• Uniform Resource Identifier의 약자
• URI는 URL과 URN을 포함하는 개념이다.
  • URL(Uniform Resource Locator) : 리소스가 있는 위치를 지정
  • URN(Uniform Resource Name) : 리소스에 이름을 부여
• Uniform : 리소스를 식별하는 통일된 방식
• Resource : 자원, URI로 식별할 수 있는 모든 것
• Identifier : 다른 항목과 구분하는데 필요한 정보

 

URI 전체 문법

• 구조 : scheme://[userinfo@]host[:port][/path][?query][#fragment]
• 예시 : https://www.google.com:443/search?q=hello&hl=ko
• Scheme
  • 주로 프로토콜을 사용
  • 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
    • 예) http, https 등
  • http는 80 포트, https는 443 포트를 주로 사용(포트는 생략할 수 있다.)
• Userinfo
  • URL에 사용자 정보를 포함해서 인증
  • 거의 사용하지 않는다.
• Host
  • 호스트명
  • 도메인명 또는 IP 주소를 직접 사용할 수 있다.
• Port
  • 포트번호
  • 일반적으로 생략한다.
• Path
  • 리소스 경로를 의미한다.
• Query
  • key=value의 형태
  • ?로 시작, &로 추가할 수 있다.
  • 예) ?keyA=valueB&keyB=valueB
  • query parameter, query string 등으로 불린다.
  • 웹 서버에 제공하는 파라미터로 문자 형태이다.

 

 

웹 브라우저 요청 흐름

• 예) 'https://www.google.com/search?q=hello&hl=ko'라는 요청이 왔을 때
  
  • DNS를 조회하여 IP 주소를 얻는다.
  • 프로토콜을 통해 PORT 정보를 얻는다.
  • HTTP 요청 메시지 생성

 

HTTP 요청 메시지

• 예)

HTTP 요청 메시지

• HTTP 메시지 전송 과정
  1. 웹 브라우저가 HTTP 메시지를 생성
  2. SOCKET 라이브러리를 통해 HTTP 메시지를 OS 계층에 전달
     • TCP/IP 연결(IP, PORT)
     • 데이터 전달
  3. TCP/IP 패킷 생성, HTTP 메시지 포함
     

     

     HTTP 메시지 전송

• 생성되는 패킷 예)

생성되는 패킷 예시

 

• 서버의 응답
  • 요청 패킷이 도착하면 TCP/IP 패킷을 확인하고 HTTP 메시지를 확인한다.
  • HTTP 메시지를 해석한다.
  • HTTP 응답 메시지를 만든다.
  • 응답 메시지 예)
    

    

    HTTP 응답 메시지 예시

  • 응답 메시지를 토대로 응답 패킷을 클라이언트에게 전달

 

 

 

HTTP

 

클라이언트 서버 구조

• 클라이언트는 서버에 HTTP 메시지로 요청을 보낸다.
• 서버는 요청을 기다린다.
• 서버는 요청이 오면 요청에 대한 결과를 만들어 응답한다.
• 이런 구조를 Request Response 구조라고 한다.
• 클라이언트 서버 구조의 장점
  • 클라이언트와 서버의 역할을 분리하여 개발한다.
  • 서버는 중요 데이터나 비즈니스 로직을 담을 수 있게 개발
  • 클라이언트는 UI를 그리는 것 등에 집중하여 개발
  • 역할을 분리하여 개발하면 서버와 클라이언트가 독립적으로 성장할 수 있다.

 

무상태 프로토콜

• Stateless를 말한다.
• 서버가 클라이언트의 상태를 보존하지 않는다.
• Stateful은 서버가 클라이언트의 상태를 보존한다.
• 장점
  • 필요한 정보를 그때그때 모두 넘긴다.
  • 때문에 갑자기 클라이언트 요청이 증가해도 서버를 대거 증설할 수 있다.
  • 즉 무상태는 응답 서버를 쉽게 바꿀 수 있다.(응답 서버를 무한하게 증설할 수 있다.)
• 단점
  • 모든 것은 stateless 하게 설계하는 것이 힘들다.
  • 로그인을 하는 경우 로그인을 했다는 상태를 서버에 유지해야 한다.
    • 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해 상태를 유지한다.
    • 상태 유지는 최소한으로 사용해야 한다.

 

비연결성

• 서버와 클라이언트가 계속해서 연결되어 있다면?
  • 서버는 연결을 계속 유지해야 하기 때문에 서버 자원을 많이 소모한다.
  • 연결된 클라이언트가 많을수록 서버에 부담이 증가한다.
• 서버와 클라이언트가 연결을 유지하지 않는 것이 좋다.
• TCP/IP 연결을 하고 요청과 응답이 완료된 후에 TCP/IP 연결을 바로 끊어버리는 방식을 말한다.
• 서버의 자원 유지를 효과적으로 할 수 있다.
• HTTP는 기본적으로 비연결이다.
• 비연결성의 한계
  • TCP/IP 연결을 새로 해야 한다.
    • 즉 3 way handshake 시간이 추가된다.
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 추가 이미지 등
    수많은 자원이 함께 다운로드된다.
  • 이러한 자원을 받을 때마다 연결과 종료가 반복된다.
• 비연결성의 한계 극복 방법
  • HTTP 지속 연결
    • 비연결성에서는 자원 하나하나 요청 건에 대하여 3 way handshake을 시도
    • HTML, CSS, 자바스크립트 각 요청에 대해 연결이 생성되었다가 종료되었다가를 반복
    • 지속 연결을 사용하면 자원을 요청했을 때 이와 관련된 모든 자원을 요청하기 위해
      연결이 지속적으로 유지된다.
    • 즉 비연결성과 달리 모든 자원에 대해 연결과 종료가 반복되는 것이 아니라
      최초 연결 후 모든 자원을 다운로드하기 전까지 연결이 유지되고 모든 자원이 다운로드 된 후에
      연결을 종료

 

HTTP 메시지

• HTTP 메시지 구조 예시

HTTP 메시지 구조 예시

• 요청 메시지
  • start-line : 시작 라인, request line
  • 시작 라인 구조 : 메서드 (공백) request-target (공백) HTTP 버전
    • HTTP 메서드 : GET, POST 등
    • request-target : 요청 대상
    • request-target은 절대 경로로 시작(/)
• HTTP 헤더
  • HTTP 전송에 필요한 모든 부가 정보
• HTTP 메시지 바디
  • 실제 전송할 데이터
  • HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있다.

 

HTTP API

• REST API와 거의 동일한 의미로 사용
• HTTP를 사용해서 정해둔 스펙으로 데이터를 주고받으며 통신하는 것

 

리소스란?

• '회원 등록', '회원 수정', '회원 조회'에서 리소스란 무엇일까?
  • 리소스는 '회원'이다.
  • 등록, 수정, 조회는 리소스가 아니다.
• API URI는 리소스를 식별하여 설계하는 것이 좋다.
  • 예시)
    회원 목록 조회 /members
    회원 조회 /members/{id}
    회원 등록 /members/{id}
    회원 수정 /members/{id}
    회원 삭제 /members/{id}
  • 그렇다면 각 URI가 조회인지 등록인지 수정인지 삭제인지 어떻게 구분하는가?
    • 메서드를 통해 구분

 

HTTP 메서드

• GET : 리소스 조회
  • 서버에 전달하고 싶은 데이터(예) 검색 내용)는 쿼리 파라미터를 통해 전달
  • 메시지 바디를 사용해서 데이터를 전달할 수도 있지만, 지원하지 않는 곳이 많아
    권장하지 않는다.
• POST : 요청 데이터 처리, 주로 등록에 사용
  
  • 메시지 바디를 통해 서버로 요청 데이터를 전달
  • 서버는 요청 데이터를 처리한다.
  • POST 사용 예시
    • HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
      예) HTML 폼에 입력한 정보로 회원 가입, 주문 등
    • 게시판, 뉴스 그룹, 메일링 리스트 등 그룹에 메시지 게시
      예) 게시판 글쓰기, 댓글 쓰기
    • 서버가 아직 식별하지 않은 새 리소스 생성
      예) 신규 주문 생성
    • 기존 자원에 데이터 추가
      예) 문서의 끝에 데이터 추가
  • 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
  • 기존 리소스가 있으면 대체한다.
  • 기존 리소스가 없으면 생성한다.
  • 클라이언트가 리소스 위치를 알고 URI를 지정한다.
  • 이것이 POST와 차이점
• PATCH : 리소스 부분 변경
  • PUT의 경우 모든 필드가 대체되지만 PATCH는 부분 대체된다.
  • PATCH도 PUT처럼 리소스 위치를 알고 URI를 지정한다.
  • PATCH가 지원되지 않는 경우 POST로 대체한다.
• DELETE : 리소스 삭제
• 기타 메서드
  • HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환(바디 빼고)
  • OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명

 

HTTP 메서드의 속성

 

안전(Safe Methods)

• 호출해도 리소스를 변경하지 않는다.
  • 예) GET은 단순히 조회만 하기 때문에 안전한다.(HEAD도)
• POST, PATCH, DELETE는 리소스를 변경 -> 안전하지 않다.
• 안전은 해당 리소스의 변경 여부만 고려한다.

 

멱등(Idempotent)

• 한 번 호출하든 두 번 호출하든 같은 결과를 내는 것을 의미한다.
• 멱등 메서드
  • GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
  • PUT : 똑같은 데이터를 계속해서 PUT을 해도 횟수와 관계없이 항상 똑같은 결과를 반환한다.
  • DELETE : DELETE는 삭제이기 때문에 여러 번 삭제해도 결과는 같다.
  • POST : 멱등이 아니다.
    • 예) 문서 끝에 추가 문서를 추가한다고 했을 때, POST 요청을 여러 번 하면
      요청 횟수만큼 문서가 추가된다.
• 멱등의 활용
  • 자동 복구 메커니즘
  • 서버가 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는지에 대한 판단 근거를 제공
  • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.

 

 

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

1. 쿼리 파라미터를 통한 데이터 전송
   
   • GET
   • 주로 정렬 필터(검색어)
2. 메시지 바디를 통한 데이터 전송
   • POST, PUT, PATCH

 

클라이언트에서 서버로 데이터 전송하는 4가지 상황

• 정적 데이터 조회
  • 이미지, 정적 텍스트 문서
  • 정적 데이터의 조회에는 GET을 사용
  • 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회
• 동적 데이터 조회
  • 주로 검색, 게시판 목록에서 정렬 필터(검색어)
  • 동적 데이터의 조회에는 GET을 사용
  • 쿼리 파라미터를 사용해서 데이터를 전달
• HTML Form을 통한 데이터 전송
  • 회원 가입, 상품 주문 등
  • 기본적으로 POST를 사용
  • GET 방식으로 전송도 가능하다.
    • GET 방식 : 쿼리 스트링으로 데이터가 전송
    • POST 방식 : 바디 부분에 데이터가 들어감
  • CONTENT TYPE
    • application/x-www-form-urlencoded 사용
      • 전송 데이터를 URL 인코딩 처리한다.(한글 같은 데이터를 위해서)
      • form의 내용을 메시지 바디를 통해서 전송한다.(쿼리 파라미터 형식과 비슷)
    • multipart/form-data
      • 파일 업로드 같은 바이너리 데이터 전송 시 사용한다.
      • 다른 종류의 여러 파일과 폼의 내용을 함께 전송할 수 있다.
• HTTP API를 통한 데이터 전송
  • 회원 가입, 상품 주문 등
  • 서버 TO 서버, 앱 클라이언트, 웹 클라이언트(Ajax)

 

HTTP API 설계 예시

• HTTP API - 컬렉션
  • POST 기반 등록
  • POST 기반 등록 특징
    • 클라이언트는 등록될 리소스의 URI를 모른다.
    • 서버가 새로 등록된 리소스의 URI를 생성해준다.
    • 컬렉션
      • 서버가 관리하는 리소스 디렉터리
      • 서버가 리소스의 URI를 생성하고 관리
• HTTP API - 스토어
  • PUT 기반 등록
  • PUT 기반 등록 특징
    • 클라이언트가 리소스 URI를 알고 있어야 한다.
    • 클라이언트가 직접 리소스의 URI를 지정한다.
    • 스토어
      • 클라이언트가 관리하는 리소스 저장소
      • 클라이언트가 리소스의 URI를 알고 관리한다.
• HTML FORM 사용
  • 웹 페이지 회원 관리
  • GET, POST만 지원함
  • HTML FORM은 GET과 POST만 지원하므로 제약이 있다.
  • 이러한 제약을 해결하는 방법은? -> 컨트롤 URI
    
    • 동사로 된 리소스 경로를 사용
    • HTTP 메서드로 해결하기 애매한 경우 사용한다.

 

HTTP 상태 코드

 

상태 코드

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
• 2xx : 요청 정상 처리
  • 200 OK : 요청 성공
  • 201 Created
    • 요청 성공으로 새로운 리소스가 생성
    • 생성된 리소스는 응답의 Location 헤더 필드로 식별할 수 있다.
      

      

      201 Created

  • 202 Accepted
    • 요청이 접수되었으나 처리가 완료되지 않음
    • 배치 처리 같은 곳에서 사용
    • 예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함
  • 204 No Content
    • 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
    • 페이로드 = 메시지 본문
• 3xx : 요청을 완료하려면 추가 행동 필요
  • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
  • 리다이렉션
    • 영구 리다이렉션 : 특정 리소스의 URI로 영구적으로 이동
    • 일시 리다이렉션 : 일시적인 변경
      
      • 예) 주문 완료 후 주문 내역 화면으로 이동
      • PRG : POST/REDIRECT/GET
    • 특수 리다이렉션 : 결과 대신 캐시를 사용
  • 영구 리다이렉션 : 301, 308
    • 원래의 URI를 사용할 수 없다.
    • 검색 엔진 등에서도 URI의 변경을 인지한다.
    • 301 Moved Permanently
      • 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
    • 308 Permanent Redirect
      • 301과 기능은 같음
      • 리다이렉트 시 요청 메서드와 본문을 유지한다.
  • 일시적 리다이렉션 : 302, 307, 303
    • 302 Found
      • 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.
    • 307 Temporary Redirect
      • 302와 기능은 같음
      • 리다이렉트 시 요청 메서드와 본문을 유지
      • 요청 메서드를 변경하면 안 된다.
    • 303 See Other
      • 302와 기능은 같음
      • 리다이렉트 시 요청 메서드가 GET으로 변경
    • 302와 307, 303
      • 302는 GET으로 변할 수 있고, 본문이 제거될 수 있다는 가능성의 영역
      • 이러한 모호함을 대체하기 위해 307과 303이 쓰인다.
    • PRG(POST Redirection GET)
      • 예시) POST로 주문 후에 웹 브라우저를 새로고침하면?
        • 새로고침은 다시 요청을 진행한다.
        • 따라서 주문이 중복으로 들어갈 수 있다.
      • 해결 방법
        • POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트한다.
        • 새로고침해도 결과 화면을 GET으로 조회하기 때문에 중복 주문이 방지된다.
    • 기타 리다이렉션
      • 304 Not Modified
        • 캐시를 목적으로 사용
        • 클라이언트에게 리소스가 수정되지 않았음을 알려준다.
        • 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다.(캐시로 리다이렉트)
        • 304 응답은 응답에 메시지 바디를 포함하면 안된다.(로컬 캐시를 사용하기 때문에)
        • 조건 부 GET, HEAD 요청 시 사용한다.
• 4xx : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
  • 클라이언트는 요청 내용을 다시 검토하고 보내야 한다.
  • 401 Unauthorized
    • 클라이언트가 해당 리소스에 대한 인증을 해야함
    • 401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
    • 참고
      • 인증(Authentication) : 본인이 누구인지 확인, 로그인 정도만 확인하는 것을 말함
      • 인가(Authorization) : 권한 부여, admin 계정처럼 특정 리소스에 접근할 수 있는 권한을 말함.
  • 403 Forbidden
    • 서버가 요청을 이해했지만 승인을 거부
    • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
  • 404 Not Found
    • 요청 리소스를 찾을 수 없음
    • 요청 리소스가 서버에 없음
    • 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 아예 숨기고 싶을 때
      • 403 Forbidden의 경우 해당 리소스가 존재하지만 권한이 부족하다는 것을 의미
• 5xx : 서버 오류, 서버가 정상 요청을 처리하지 못함
  • 503 Service Unavailable
    • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
    • Retry-After 헤더 필드로 얼마뒤에 복구되는지 나타낼 수 있음
• HTTP 상태 코드 추가로 알아보기

 

 

HTTP 표준

HTTP 헤더 예시

• 2014년 HTTP 표준인 RFC7230~7235 등장
• 표현 = 표현 메타데이터 + 표현 데이터를 의미한다.
• 표현은 요청이나 응답에서 전달할 실제 데이터를 의미한다.
  
  

 

HTTP 헤더

• HTP 전송에 필요한 모든 부가 정보
• 필요시 임의의 헤더를 추가할 수 있다.
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
  • 데이터 유형(html, json), 데이터 길이, 압축 정보 등등

 

HTTP 바디

• 메시지 본문을 통해 표현 데이터를 전달한다.
• 메시지 본문 = 페이로드(payload)라 한다.

 

 

표현 헤더

• Cotent-Type : 표현 데이터의 형식
  • 미디어 타입, 문자 인코딩
  • 예)
    • text/html; charset=utf-8
    • application/json
• Content-Encoding : 표현 데이터의 압축 방식
  • 표현 데이터를 압축하기 위해 사용
  • 데이터를 전달하는 곳에서 압축 후에 인코딩 헤더를 추가한다.
  • 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제한다.
• Content-Language : 표현 데이터의 자연 언어
  • 표현 데이터의 자연 언어를 표현(한국어, 영어 등)
• Content-Length : 표현 데이터의 길이
  • 표현 데이터는 byte 단위로 나타낸다.
  • Transfer-Encoding을 사용하면 Content-Length를 사용하면 안된다.
    • Transfer-Encoding은 분할 전송이기 때문에 Content-Length를 사용하지 않는다.
• 표현 헤더는 전송과 응답 모두 사용한다.

 

 

협상 헤더

• 클라이언트가 선호하는 표현으로 서버가 응답해주기를 요청하는 것을 말한다.
• Accept : 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어
• 협상 헤더는 요청에만 사용한다.

 

협상 헤더 사용 예시

• 다중 언어를 지원하는 서버에 정보를 요청할 때 기본 언어가 영어라면?
  • 협상 헤더를 사용하지 않는 경우 영어로 응답한다.
• 다중 언어를 지원하고 기본 언어가 영어인 서버에 협상 헤더를 사용하여 한국어를 요청한다면?
• 예) Accept-Language: ko;
  • 한국어로 응답한다.
• 다중 언어를 지원하는 서버에 한국어로 응답하기를 요청하고 한국어를 지원하지 않을 때,
  가급적이면 영어로 응답하기를 요청하려면?
  • Quality Values(q) 사용

 

협상의 우선순위

• Quality Values(q)
  • 0~1 사이의 값을 갖는다.
  • 수가 클수록 높은 우선순위를 갖는다.
  • 수를 생략하면 1이다.
  • 예) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
    1. ko-KR;q=1 (q를 생략해 값이 1)
    2. ko;q=0.9
    3. en-US;q=0.8
    4. en;q=0.7
• 더 구체적인 것이 우선한다.
  • 예) Accept: text/*, text/plain, text/plain;format=flowed, */*
    1. text/plain;format=flowed
    2. text/plain
    3. text/*
    4. */*

 

 

전송 헤더

• 단순 전송
  • 콘텐츠의 길이를 알 때 사용한다.
  • Content-Length 값을 준다.
• 압축 전송
  • Content-Encoding을 추가해 압축 정보를 제공한다.
• 분할 전송
  • Transfer-Encoding을 사용한다.
  • 분할해서 전송하기 때문에 한 번에 전송되는 것보다 조금 더 빠르게 반응한다.
  • 분할 전송을 할 때는 Content-Length를 사용하지 않는다.
• 범위 전송
  • Content-Range를 사용한다.

 

 

일반 헤더

• From
  • 유저 에이전트의 이메일 정보
  • 일반적으로 잘 사용되지 않는다.
  • 요청에서 사용
• Referer
  • 현재 요청된 사이트의 이전 웹 사이트 주소의 정보
  • Referer를 사용해서 유입 경로를 분석할 수 있다.
  • 요청에서 사용
• User-Info
  • 클라이언트의 애플리케이션 정보(웹 브라우저 정보 등)
  • 요청에서 사용
• Server
  • HTTP 요청은 중간에 여러 프록시 서버를 거친다.
  • 이런 프록시 서버 정보가 아닌 실제로 응답을 하는 origin 서버의 소프트웨어 정보를 의미한다.
  • 응답에서 사용
• Date
  • 메시지가 발생한 날짜와 시간 정보
  • 응답에서 사용

 

 

특별 헤더

• Host
  • 요청한 호스트의 도메인 정보를 의미
  • 요청에서 사용
  • 특별 헤더이지만 필수적으로 사용해야 한다.
  • 하나의 서버가 여러 도메인을 처리해야 할 때 도메인을 구분하는 용도이다.
  • 예) Host 정보가 없을 때
    

    

    Host 정보가 없을 때

  • 예) Host 정보가 있을 때
    

    

    Host 정보가 있을 때

• Location
  • 웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 Location 위치로 자동 이동(리다이렉트)
  • 201에도 쓸 수 있는데, 이때 Location 값은 요청에 의해 생성된 리소스 URI를 나타낸다.
• Allow
  • 허용 가능한 HTTP 메서드를 나타낸다.
  • 405에서 응답에 포함해야 한다.
    • 405는 허용되지 않은 메서드를 의미한다.
    • 요청에 지정된 메서드를 사용할 수 없다는 것을 의미
• Retry-After
  • 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
  • 503 : 서비스가 언제까지 불능인지 알려줄 수 있다.

 

 

인증 헤더

• Authorization
  • 클라이언트 인증 정보를 서버에 전달한다.
• WWW-Authenticate 
  • 리소스 접근 시 필요한 인증 방법을 정의한다.
  • 401 Unauthorized 응답과 함께 사용한다.

 

 

쿠키 헤더

• Set-Cookie : 서버에서 클라이언트로 쿠키를 전달(응답)
• Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달
• 예) 쿠키를 사용하지 않고 로그인을 한다면?
  • HTTP는 무상태 프로토콜
  • 클라이언트와 서버는 서로 상태를 유지하지 않는다.(Stateless)
  • 따라서 로그인을 하나 하지 않으나 요청이 동일하기 때문에 서버는 로그인 유무를 알 수 없다.
  • 이러한 문제를 해결하기 위해 쿠키를 사용한다.
  • 쿠키를 사용해 서버가 로그인 유무를 파악할 수 있게 해 준다.
• 예) 쿠키를 사용하고 로그인을 한다면?
  • 서버는 Set-Cookie를 사용해서 로그인 정보를 쿠키로 저장하고 응답
  • 웹 브라우저 내부에는 쿠키 저장소가 있어서 Set-Cookie로 보낸 데이터를
    쿠키 저장소에 저장해둔다.
  • 웹 브라우저는 요청을 할 때마다 쿠키를 찾아서 쿠키 정보를 요청 정보에 자동으로 포함

 

쿠키

• 사용처
  • 사용자 로그인 세션 관리
  • 광고 정보 트래킹
• 쿠키 정보는 항상 서버에 전송
  • 네트워크 트래픽을 추가 유발한다.
  • 따라서 최소한의 정보만 사용(세션 id, 인증 토큰 등)
  • 서버에 전송하지 않고, 웹 브라우저 내부에만 데이터를 저장하고 싶으면 웹 스토리지 참고
• 보안에 민감한 데이터는 저장하면 안 된다.(주민번호, 신용카드 번호 등등)

 

 

쿠키의 생명주기

• Set-Cookie: expires=?
  • 만료일이 되면 쿠키를 삭제한다.
• Set-Cookie: max-age=?
  • 0이나 음수를 지정하면 쿠키를 삭제한다.
  • 입력한 수는 초 단위를 의미한다.
    • max-age=100 : 100초 뒤 쿠키 삭제
• 세션 쿠키
  • 만료 날짜를 생략하면 브라우저 종료 시까지 쿠키 유지
• 영속 쿠키
  • 만료 날짜를 입력하면 해당 날짜까지 쿠키 유지

 

쿠키의 도메인

• 쿠키는 도메인을 지정할 수 있다.
• domain=? 꼴로 도메인을 지정한다.
• 쿠키의 도메인 지정 방식 : 명시
  • 명시한 문서의 기준 도메인 + 서브 도메인 포함
  • 도메인을 지정해서 쿠키를 생성한다.
• 쿠키의 도메인 지정 방식 : 생략
  • 현재 문서 기준 도메인만 쿠키를 적용한다.

 

쿠키의 경로

• 쿠키는 경로를 지정할 수 있다.
• 쿠키가 지정한 경로를 포함한 하위 경로 페이지만 쿠키에 접근할 수 있도록 한다.
• path=? 꼴로 경로를 지정한다.
• 일반적으로 path=/루트로 루트 패스를 지정한다.

 

 

쿠키의 보안

• Secure
  • 쿠키는 http, https를 구분하지 않고 전송한다.
  • secure를 적용하면 https인 경우에만 전송한다.
• HttpOnly
  • XSS 공격을 방지한다.
  • 자바스크립트에서 쿠키에 접근하지 못하게 한다.
  • HTTP 전송에만 사용
• SameSite
  • XSRF 공격을 방지한다.
  • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송

 

 

캐시

 

캐시와 쿠키의 차이

• 쿠키는 서버의 필요에 의해 클라이언트에 저장하는 데이터
• 캐시는 클라이언트 자체에서 페이지 로드를 효율적으로 하기 위해 저장하는 데이터

 

캐시가 없다면?

• 이미지를 한 번 요청하고, 새로고침과 같은 경우에 의해 이미지를 다시 요청했을 때
  이미지(데이터)가 변경되지 않아도 요청 때마다 네트워크를 통해 데이터를 다시 다운받아야 한다.
• 인터넷 네트워크는 매우 느리고 비싸고 브라우저의 로딩 속도는 느리다.
• 따라서 캐시를 사용하지 않는다면 느린 사용자 경험을 겪는다.

 

캐시가 있다면?

• 브라우저에는 캐시 저장소가 있다.
• 이미지를 한 번 요청했을 때 브라우저의 캐시 저장소에 이미지를 저장해둘 수 있다.
• 캐시 저장소에 저장된 이미지는 만료되기 전까지 동일 요청이 있다면
  이미지를 캐시 저장소에서 로드할 수 있다.
• 이런 경우 캐시 사용 가능 시간 동안 네트워크를 사용하지 않아도 된다.
• 즉, 비싼 네트워크 사용량을 줄일 수 있고 브라우저 로딩 속도가 매우 빨라진다.
• 따라서 캐시를 사용한다면 빠른 사용자 경험을 겪는다.

 

캐시 가능 시간이 초과된다면?

• 캐시는 헤더에 cache-control: max-age=? 와 같은 형태로 캐시 유효 시간(초)을 정할 수 있다.
• 만약 캐시 가능 시간이 초과된 이후에 동일한 요청을 한다면?
  • 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
  • 이때 다시 네트워크 다운로드가 발생한다.
• 캐시 유효 시간이 초과해서 서버에 다시 요청할 경우 나타나는 두 가지 상황
  
  1. 서버에서 기존 데이터를 변경하지 않음
     • 캐시 만료 후에도 서버에서 데이터를 변경하지 않을 경우 데이터를 전송하는 대신
       저장해 두었던 캐시를 재사용할 수 있다.
     • 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다.
     • 이때 사용하는 것이 Last-Modified이다.
     • Last-Modified 헤더는 데이터가 마지막에 수정된 시간을 나타낸다.
     • 데이터에 대한 첫 번째 응답 때 서버는 Last-Modified 헤더를 사용해 데이터 최종 수정일을 알려준다.
     • 캐시 저장소에 Last-Modified 정보를 저장해둔다.
     • 두 번째 요청이 발생할 때 캐시 시간이 초과한 경우 캐시가 가지고 있는 Last-Modified 정보를
       If-Modified-Since를 이용해 클라이언트의 요청 헤더에 포함한다.
     • 서버는 If-Modified-Since 정보를 이용해 데이터 최종 수정일을 확인하고,
       동일한 데이터일 경우 304 Not Modified 상태 코드를 보낸다.
     • 이때 서버의 응답에는 HTTP 헤더(헤더 메타 정보)만 포함되고 HTTP Body는 전송하지 않는다.
     • 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다.
     • 클라이언트는 캐시에 저장되어 있던 데이터를 재활용한다.
     • 결과적으로 네트워크 다운로드는 발생하지만 용량이 적은 헤더 정보만 다운로드하면 된다.
  2. 서버에서 기존 데이터를 변경함
     • If-Modified-Since의 정보와 서버의 데이터 최종 수정일이 다른 경우는?
     • 서버는 200 OK 응답을 보낸다.
     • 따라서 모든 데이터를 전송한다.(HTTP 바디 포함)

 

 

검증 헤더와 조건부 요청(Last-Modified, If-Modified-Since)의 단점

• 1초 미만 단위로 캐시를 조정할 수 없다.
• 날짜 기반의 로직을 사용한다.
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우를 파악할 수 없다.
  • 같은 데이터인 경우에도 전체 데이터를 다시 다운받아야 한다.
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

 

 

ETag, If-None-Match

• Last-Modified, If-Modified-Since의 단점을 극복할 수 있는 검증 헤더와 조건부 요청
• ETag = Entity Tag
• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다.
• 데이터가 변경되면 이 이름을 바꿔 변경한다.(Hash를 다시 생성)
• 서버는 첫 번째 요청 때 ETag 헤더를 포함하여 응답한다.
• 브라우저는 캐시 저장소에 ETag 정보를 저장해둔다.
• 캐시 시간이 초과되고 두 번째 요청을 하는 경우 클라이언트는 캐시에 저장된 ETag 정보를 이용한다.
• If-None-Match 헤더를 사용해 저장된 ETag 정보를 담아 서버에 보낸다.
• 서버의 ETag 정보와 일치하는 경우 데이터가 수정되지 않았기 때문에 캐시를 재사용한다.
• 이 경우 서버는 304 상태 코드를 보내며 HTTP 바디를 보내지 않는다.
• 이 방식은 캐시 제어 로직을 서버에서 완전히 관리한다.
• 클라이언트는 단순히 이 값을 서버에 제공할 뿐 캐시 메커니즘을 알 수 없다.
• 파일이 수정되어도 ETag를 동일하게 유지하는 경우 파일을 다시 받지 않는다.

 

캐시 제어 헤더

• Cache-Control : 캐시 제어
  • Cache-Control: max-age
    • 캐시 유효 시간, 초 단위
  • Cache-Control: no-chache
    • 데이터는 캐시
    • 캐시 데이터를 사용하기 전에 항상 원(origin) 서버에 검증하고 사용
  • Cache-Control: no-store
    • 데이터에 민감한 정보가 있으므로 저장하면 안 됨
• Pragma : 캐시 제어(하위 호환)
  • Pragma: no-cache
  • HTTP 1.0 하위 호환
• Expries : 캐시 유효 기간(하위 호환)
  • 캐시 만료일을 정확한 날짜로 지정
  • HTTP 1.0부터 사용
  • 지금은 더 유연한 Cache-Control: max-age를 권장한다.

 

검증 헤더와 조건부 요청 헤더

• 검증 헤더
  • ETag
  • Last-Modified
• 조건부 요청 헤더
  • If-Match, If-None-Match : ETag 값 사용
  • If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

 

프록시 캐시

• 멀리 떨어져 있는 원(origin) 서버에 접근하는 경우 소요 시간이 오래 걸린다.
• 이런 경우를 위해 중간에 프록시 캐시 서버를 두어 접근 속도를 줄이는 것을 말한다.
• 요청이 있을 경우 우선적으로 프록시 캐시 서버에 접근한다.
• 이때 사용자 브라우저의 캐시는 private 캐시이고, 프록시 캐시의 경우 public 캐시이다.

 

프록시 캐시와 관련된 캐시 지시어

• Cache-Control: public
  • 응답이 public 캐시에 저장돼도 된다.
  • 프록시 캐시 서버에 응답이 저장될 수 있다.
• Cache-Control: private
  • 응답이 해당 사용자만을 위한 것이다.
  • 응답이 프록시 캐시 서버에 저장되서는 안 된다.
• Cache-Control: s-maxage
  • 프록시 캐시에만 적용되는 max-age를 말한다.

 

 

캐시 무효화

• 확실한 캐시 무효화 응답
  • Cache-Control: no-cache, no-store, must-revalidate
    Pragma: no-cache 
• Cache-Control: must-revalidate
  • 캐시 만료 후 최초 조회 시 원 서버에 검증을 해야 한다.
  • 원 서버에 접근 실패 시 반드시 오류가 발생해야 한다. - 504 상태 코드 반환
  • must-revalidate는 캐시 유효 시간이라면 캐시를 사용한다.
• Pragma: no-cache 
  • HTTP 1.0 하위 호환을 위해 추가한다.

 

no-cache와 must-revalidate의 차이

• no-cache의 기본 동작 예시
  

  

  no-cache 기본 동작

• 만약 원 서버에 오류가 발생하는 등 원 서버에 접근할 수 없는 상황이라면?
  • 프록시 캐시 서버에서 대신 응답을 해줄 수도 있다.
  • 즉 프록시 캐시 서버에서 200 OK 상태 코드를 반환하거나 에러가 발생할 수 있다.
• must-revalidate를 사용하고 원 서버에 접근할 수 없는 상황이라면?
  • 원 서버에 접근할 수 없는 경우 항상 오류가 발생한다.
  • 프록시 캐시 서버는 504 Gateway Timeout 상태 코드를 반환한다.

 

 

---

출처

• 본 강의는 인프런의 김영한 님 강의를 토대로 정리한 내용입니다.
• 해당 강의는 '모든 개발자를 위한 HTTP 웹 기본 지식'을 참고해주세요.