김영한의 HTTP

인터넷 네트워크

IP(인터넷 프로토콜)

출발, 목적에 각각 IP가 주어지고 Hello, world!를 보낸다. 그러면 각 노드에서 목적 IP를 찾아서 던지고 목적지까지 찾아간다.

IP 프로토콜의 한계

비연결성

• 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
  
  

비신뢰성

• 중간에 패킷이 사라지면?
  

• 패킷이 순서대로 안오면?
  

프로그램 구분

• 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면?

---

TCP 특징

인터넷 프로토콜 스택의 4계층

프로토콜 계층

IP 패킷 정보

IP 패킷정보에는 출발지 IP, 목적지 IP, 기타 정보가 담겨져 있다.

TCP 특징

전송 제어 프로토콜(Transmission Control Protocol)

• 연결지향 - TCP 3 way handshake(가상 연결)
  

• 데이터 전달 보증
  

• 순서 보장
  

패킷이 1, 2, 3 이렇게 와야는데 1, 3, 2 이렇게 오면 다 버리고 2번부터 다시보내라고 하는 것

• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

UDP 특징

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

• 하얀 도화지에 비유(기능이 거의 없음)
• 연결지향 - TCP 3 way handshake X
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름

정리

• IP와 거의 같다. +PORT + 체크섬 정도만 추가
• 애플리케이션에서 추가 작업 필요

TCP는 건들 수 없지만 더 최적화할 수 있다면 UDP로 해야 합니다. 최근에는 UDP가 뜨고 있다. 더 최적화해서 사용하기 위해서 UDP를 사용하는 겁니다.

---

PORT

---

DNS

도메인 네임 시스템(Domain Name System)

• 전화번호부
• 도메인 명을 IP 주소로 변환

DNS 사용

인터넷 네트워크 정리

• 인터넷 통신
• IP(Internet Protocol)
• TCP, UDP
• PORT
• DNS

---

URI(Uniform Resource Identifier)

URI 단어 뜻

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

URL, URN

• URL - Locator : 리소스가 있는 위치를 지정
• URN - Name : 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
• urn:isbn:8960777331 (어떤 책의 isbn URN)
• URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음
• 앞으로 URI를 URL과 같은 의미로 이야기하겠음

URL 전체 문법

• 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)

URL 전체 문법

• 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)

URL scheme

• 주로 프로토콜 사용
• 프로토콜: 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
• 예) http, https, ftp 등등
• http는 80 포트, https는 443 포트를 주로 사용, 포트는 생략 가능
• https는 http에 보안 추가 (HTTP Secure)

URL userinfo

• URL에 사용자정보를 포함해서 인증
• 거의 사용하지 않음

URL host

• 호스트명
• 도메인명 또는 IP 주소를 직접 사용가능

URL PORT

• 포트(PORT)
• 접속 포트
• 일반적으로 생략, 생략시 http는 80, https는 443

URL path

• 리소스 경로(path), 계층적 구조
• 예)

• /home/file1.jpg
• /members
• /members/100, /items/iphone12

URL query

• key=value 형태
• ?로 시작, &로 추가 가능 ?keyA=valueA&keyB=valueB
• query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태

URL fragment

• fragment
• html 내부 북마크 등에 사용
• 서버에 전송하는 정보 아님

---

웹 브라우저 요청 흐름

---

HTTP

HTTP 메시지에 모든 것을 전송

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

HTTP 역사

• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년: 메서드, 헤더 추가
• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전

• RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)

• HTTP/2 2015년: 성능 개선
• HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용

• HTTP/2, HTTP/3 도 점점 증가

HTTP 특징

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

클라이언트 서버 구조

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

무상태 프로토콜

스테이스리스(Stateless)

• 서버가 클라이언트의 상태를 보존x
• 장점 : 서버 확장성 높음(스케일 아웃)
• 단점 : 클라이언트가 추가 데이터 전송
  

이렇게 하면 서버와 클라이언트가 독립적으로 진화를 할 수 있어서 좋다.

무상태 프로토콜

스테이스리스(Stateless)

• 서버가 클라이언트이 상태 보존 x
  장점 : 서버 확장성 높음(스케일 아웃)
  단점 : 클라이언트가 추가 데이터 전송

상태 유지 - Stateful

무상태 - Stateless

실무 한계

• 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.

무상태
예) 로그인이 필요 없는 단순한 서비스 소개 화면

상태 유지
예) 로그인

• 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
• 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
• 상태 유지는 최소한만 사용

HTTP 응답의 핵심 구성 요소는 무엇입니까?

HTTP 응답에는 다음과 같은 네 가지 주요 구성 요소가 있습니다.

• 응답 상태 코드 : 리소스 요청에 대한 응답으로 서버의 상태 코드를 표시합니다. 예를들어, 클라이언트 측 오류는 400으로 표시되는 반면 성공적인 응답은 200으로 표시됩니다.

• HTTP 버전 : HTTP 프로토콜 버전은 HTTP 버전으로 표시됩니다.

• 응답 헤더 : 응답 메시지의 메타데이터가 이 섹션에 포함됩니다. 데이터는 콘텐츠 길이, 유형, 응답 날짜, 서버 유형 등과 같은 항목을 제공하는 데 사용할 수 있습니다.

• 응답 본문 : 서버가 실제로 반환한 리소스 또는 메시지는 응답 본문에 포함됩니다.

Content-Type은 응답의 미디어 타입을 의미한다.

HTTP 프로토콜과 CRUD의 관계

비연결성

• HTTP는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위의 이하의 빠른 속도로 응답
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적음

  예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.

• 서버 자원을 매우 효율적으로 사용할 수 있음

비연결성 한계와 극복

• TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바 스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드
• 지금은 HTTP 지속 연결(Persistent Connetions)로 문제 해결
• HTTP/2, HTTP/3에서 더 많은 최적화

---

HTTP 메시지

HTTP 메시지에 모든 것을 전송

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

시작 라인

요청 메시지

• start-line = request-line/status-line
• request-line=method SP(공백) request-target SP HTTP-version CRLF(엔터)
• HTTP 메서드 (GET: 조회)
• 요청 대상(/search?q=hello&hl=ko)
• HTTP Version

요청 메시지 - HTTP 메서드

• 종류 : GET, POST, PUT, DELETE ...
• 서버가 수행해야할 동작 지정

  • GET : 리소스 조회
  • POST : 요청 내역 처리

요청 메시지 - 요청 대상

• absolute-path?query
• 절대경로="/"로 시작하는 경로
• 참고 : *, http://...?x=y와 같이 다른 유형의 경로지정 방법도 있다.
  

요청 메시지 - HTTP 버전

• HTTP Version

응답 메시지

• start-line = request-line / status-line
• status-line= HTTP-version SP status-code SP reason-phrase CRLF
• HTTP 버전
• HTTP 상태 코드 : 요청 성공, 실패를 나타냄

  • 200 : 성공
  • 400 : 클라이얹트 요청 오류
  • 500 : 서버 내부 오류

• 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글
  

정리

• HTTP 메시지에 모든 것을 전송
• HTTP 역사 HTTP/1.1을 기준으로 학습
• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스)
• HTTP 메시지
• 단순함, 확장 가능
• 지금은 HTTP 시대

---

HTTP API를 만들어보자

API URI 설계

URI(Uniform Resource Identifier)

• 회원 목록 조회 /read-member-list
• 회원 조회 /read-member-by-id
• 회원 등록 /create-member
• 회원 수정 /update-member
• 회원 삭제 /delete-member

중요한 것은 리소스 식별

---

HTTP 메서드 -GET, POST

HTTP 메서드 종류

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

---

HTTP 메서드 - PUT, PATCH, DELETE

---

HTTP 메서드 속성

• 안전(Safe Methods)
• 멱등(Idempotent Methods)
• 캐시가능(Cacheable Methods)

안전(Safe)

• 호출해도 리소스를 변경하지 않는다.
• Q : 계속 호출해서 로그 같은게 쌓여서 장애가 발생하면?

  A : 안전은 해당 리소스만 고려한다. 그런 부분은 고려하지 않는다.

멱등(Idempotent)

• f(f(x)) = f(x)
• 한 번 호출하든 두번 호출하든 100번 호출하든 결과가 똑같다.
• 멱등 메서드

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

캐시가능(Cacheable)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시로 사용

  POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데 구현이 쉽지 않음

---

HTTP 상태 코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

HTTP Status Code (상태 코드)

HTTP Status code, 상태 코드는 HTTP 요청이 성공했는지 실패했는지를 서버에서 알려주는 코드다.

2xx 성공

4xx Client errors

4XX의 상태 코드들은 클라이언트의 요청이 유효하지 않아 서버가 해당 요청을 수행하지 않았다는 의미다.

5xx Server errors

5XX 상태 코드들은 서버 오류로 인해 요청을 수행할 수 없다는 의미다.

클라이언트의 요청은 유효하여 작업을 진행했는데 도중에 오류가 발생한 경우다. 404 오류와 마찬가지로 인터넷을 하다 보면 500, 502, 503 등의 오류를 만나봤을 거다. API 서버의 응답에서 5XX오류가 발생해서는 안된다. 보통 개발 과정에서 유효하지 않은 요청을 사전에 처리하지 않은 경우(400)에 많이 발생한다.

• 1xx (Informational) : 요청이 수신되어 처리중
• 2xx (Successful) : 요청 정상 처리
• 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함

---

HTTP 헤더1

표현

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

표현 헤더는 전송, 응답 둘다 사용

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

클라이언트가 선호하는 표현 요청

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

전송 방식

• Transfer-Encoding
• Range, Content-Range

전송 방식 설명

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

일반 정보

• From : 유저 에이전트의 이메일 정보

  • 일반적으로 잘 사용안함
  • 검색 엔진 같은 곳에서, 주로 사용
  • 요청에서 사용

• Referer : 이전 웹 페이지 주소

  • 현재 요청된 페이지의 이전 웹 페이지 주소
  • A → B로 이동하는 경우 B를 요청할 때 Referer : A를 포함해서 요청
  • Referer를 사용해서 유입 경로 분석 가능
  • 요청에서 사용

• User-Agent : 유저 에이전트 애플리케이션 정보

  • 
  • 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등)
  • 통계 정보
  • 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
  • 요청에서 사용

• Server : 요청을 처리하는 오리진 서버의 소프트웨어 정보

  • Server : Apache/2.2.22(Debian)
  • server : nginx
  • 응답에서 사용

• Date : 메시지가 생성된 날짜

  • Date : Tue, 15 Nov 1994 08:12:31 GMT
  • 응답에서 사용

특별한 정보

• Host : 요청한 호스트 정보(도메인)

  

  

  

  

• Location : 페지이 리다이렉션

  • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
  • 응답코드 3xx에서 설명
  • 201(Created) : Location 값은 요청에 의해 생성된 리소스 URI
  • 3xx(Redirection) : Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

• Allow : 허용 가능한 HTTP 메서드

  • 405(Method Not Allowed)에서 응답에 포함해야함
  • Allow : GET, HEAD, PUT

• Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

  • 503(Service Unavailable) : 서비스가 언제까지 불능인지 알려줄 수 있음
  • Retry-After : Fri, 31 Dec 1999 23:59:59 GMT(날짜 표기)
  • Retry-After: 120(초단위 표기)

• 인증

  • Authorization : 클라이언트 인증 정보를 서버에 전달
    

• WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의
  

---

쿠키

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

Stateless

• HTTP는 무상태(Stateless) 프로토콜이다.
• 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.
• 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
• 클라이언트와 서버는 서로 상태를 유지하지 않는다.

백과 프론트가 나뉘어 작업하는 경우 , 인증은 보통 JWT를 사용합니다. 쿠키와 세션을 사용하지 않는다는건 인증에 한한 이야기 일 수 있습니다. 쿠키는 여전히 임시 데이터를 저장하는데 유효합니다. 즉, REST 방식이라고 쿠키와 세션을 사용하지 못하는 것은 아닙니다.

---

HTTP 헤더2

케시와 조건부 요청

케시 기본 동작

캐시가 없을 때

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
• 인터넷 네트워크는 매우 느리고 비싸다.
• 브라우저 로딩 속도가 느리다.
• 느린 사용자 경험

캐시 적용

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

캐시 시간 초과

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

---

검증 헤더와 조건부 요청1

캐시 시간 초과

• 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두가지 상황이 나타낸다.

1. 서버에서 기존 데이터를 변경함
2. 서버에서 기존 데이터를 변경하지 않음

• 캐시 만료후에도 서버에서 데이터를 변경하지 않음
• 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 있다면 데이터를 저장해 두었던 캐시를 재사용할 수 있다.

정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드

---

검증 헤더와 조건부 요청2

• 검증 헤더

  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  • Last-Modified, ETag

• 조건부 요청 헤더

  • 검증 헤더로 조건에 따른 분기
  • If-Modified-Since : Last_Modified 사용
  • IF-None-Match : ETag 사용

• 조건이 만족하면 200 OK

• 조건이 만족하지 않으면 Not Modified

예시

• If-Modified-Since : 이후에 데이터가 수정되었으면?

  • 데이터 미변경 예시

    • 캐시 : 2020sus 11월 10일 10:00:00 vs 서버 : 2020년 11월 10일 10:00:00
    • 304 Not Modified, 헤더 데이터만 전송(BODY 미포함)
    • 전송 용량 0.1M(헤더 0.1M, 바디1.0M)

  • 데이터 변경 예시

    • 캐시 : 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
    • 200 OK, 모든 데이터 전송(BODY 포함)
    • 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)

Last-Modified, If-Modified-Since 단점

• 1초 미만(0.x초) 단위로 캐시 조정이 불가능
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

  • 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

ETag, If-None-Match

• ETag(Entity Tag)
• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠

  예) ETag: "v1.0", ETag: "a2jiodwjekjl3"

• 데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)

  예) ETag: "aaaaa" -> ETag: "bbbbb"

• 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기

ETag, If-None-Match 정리

• 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기!
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)

  예)

  • 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
  • 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

캐시 제어 헤더

• Cache-Control: 캐시 제어
• Pragma: 캐시 제어(하위 호환)
• Expires: 캐시 유효 기간(하위 호환)

Cache-Control

캐시 지시어(directives)

• Cache-Control: max-age

  캐시 유효 시간, 초 단위

• Cache-Control : no-cache

  데이터는 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용

• Cache-Control : no-store

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

Pragma

캐시 제어(하위 호환)

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

Expires

캐시 만료일 지정(하위 호환)

• expires : Mon, 01 Jan 1990 00:00:00 GMT

• 캐시 만료일을 정확한 날짜로 지정

• HTTP 1.0 부터 사용

• 지금은 더 유연한 Cache-Control : max-age 권장

• Cache-Control : max-age와 함께 사용하면 Expires는 무시

---

프록시 캐시

---

캐시 무효화