100년 뒤 개발자 한승규입니다.

• 읽기 전용 볼륨

바인드 마운트는 로컬의 특정 위치로 연결이 된다.

그럴 때 런타임 중에 해당 파일들을 변경할 수 없도록 해야 하는 경우가 있을 것이다.

그런 경우에 사용하는 바인드 마운트를 읽기 전용 볼륨으로 전환하는 방법을 알아보자.

docker run -v "{로컬의 위치:도커의 위치:ro}" {image ID || image Name}

그럴 때는 -v 옵션을 사용하면서 :ro read-only 옵션을 넣어준다.

• Docker 볼륨 관리하기

우선 현재 도커에서 관리하고 있는 볼륨들을 먼저 확인해보자.

docker volume ls

현재는 익명 볼륨 2개와 이름 볼륨 1개를 사용하고 있는 것을 볼 수 있다.

당연히 바인드 마운트는 도커에 의해 관리되는 것이 아니기 때문에 여기에서 확인할 수 없다.

구체적으로 볼륨을 만들 수도 있다.

docker volume create {볼륨 이름}

많이 사용할 거 같지는 않다.

docker volume inspect {볼륨 이름}

inspect를 사용해서 해당 볼륨의 자세한 정보를 확인해볼 수 있다.

docker volume rm {볼륨 이름}

rm을 사용해서 볼륨을 제거할 수 있다.

물론 해당 볼륨을 사용하고 있는 컨테이너가 없을 때만 사용이 가능하다.

• dockerignore 사용하기

COPY를 할 때 보통 모든 파일들을 복사해가지만, 복사하면 안되는 파일도 있을 것이다.

그럴 때는 .dockerignore을 사용해서 복사를 막는다.

.dockerignore에 명시한 파일, 폴더 등은 복사가 되지 않으며 사용방법은 .gitignore와 비슷하다.

• Docker로 환경변수 작업하기

Dockerfile에 다음과 같이 작성하면 된다.

run 할 때 -e key=value로도 명시할 수 있다.

이렇게 환경변수를 사용하면 애플리케이션에서 해당 환경변수를 사용해 하드코딩할 필요 없이 유연하게 작성할 수 있다는 장점이 있다.

환경변수가 지정된 파일을 --env-file로 지정할 수 있다.

이렇게 key=value값이 지정되어 있는 파일을 

이렇게 docker run 할 때 지정해주면 된다.

• Docker에서의 데이터 종류

Docker에서의 데이터는 크게 3가지로 나눌 수 있다.

우리가 이미지를 만들고 컨테이너를 실행하는 데 필요한 데이터와 런타임 중에 임시로 생성되는 데이터, 그리고 런타임 중에 생성이 되며 영구적으로 저장해야 하는 데이터가 있다.

스프링부트를 사용하면 사용자로부터 파일 업로드를 받을 때가 있는 데, 이때 영구적인 데이터로 저장을 하는 것 같다.

이미지는 읽기 전용이기 때문에, 이 부분에 데이터를 추가할 수는 없다.

이 때는 volume을 사용해야 한다고 한다.

• 기존의 방법으로 컨테이너에 데이터 저장

기존의 방식으로 런타임 도중에 파일을 저장해보도록 하자.

run 할 때 --rm 의 옵션을 추가했다.

이 앱을 이용해서 해당 파일을 저장한다.

이렇게 저장된 파일에 접속이 가능한 것을 볼 수 있다.

과연 해당 파일은 컨테이너를 재실행하더라도 접속이 가능할까?

재실행하고 접속을 해보았지만

접속이 불가능한 것을 확인할 수 있다.

컨테이너가 삭제되고 재실행되었기 때문에 해당 파일도 삭제되어서 그런 것임을 알 수 있다.

--rm을 제거하여 컨테이너를 삭제하지 않고 재실행만 해보자.

stop 후 start로 재실행하니 해당 데이터는 삭제되지 않아 다시 접속이 가능한 것을 볼 수 있다.

하지만 여기서 한 가지 문제를 찾을 수 있다.

해당 데이터가 컨테이너 내부에 저장이 되기 때문에 컨테이너가 제거되면 데이터도 제거가 된다.

동일한 이미지를 사용하더라도 말이다.

WAS에서는 업로드 한 데이터들을 삭제하면 안되는 경우가 생길 수도 있기 해당 데이터를 가지고 있어야 한다.

그렇기 때문에 Docker의 volume을 사용하여 데이터를 유지할 수 있도록 해야 한다.

• volume이란?

volume은 호스트 머신의 폴더이다. 컨테이너나 이미지에 있는 것이 아니다.

volume은 도커가 인식하는 호스트 머신에 있는 폴더로서 도커 컨테이너 내부의 폴더에 매핑된다.

그리고 두 폴더의 변경 사항은 다른 폴더에 반영이 된다.

호스트 머신에 파일을 추가하면, 컨테이너 내부에서 액세스 할 수 있다.

컨테이너가 매핑된 경로에 파일을 추가하면, 호스트 머신에서도 사용할 수 있다.

이렇게 volume을 통해 데이터를 유지할 수 있다.

해당 volume은 컨테이너가 종료되더라도 유지되기 때문이다.

Docker의 volume에는 2가지 종류가 있다.

익명 volume과 명명된 volume이다.

익명 volume은 진짜 호스트 머신의 어딘가로 연결이 되며, 보통은 그 경로를 모를 것이다.

신경 쓸 필요가 없어 편하지만, 해당 익명 volume은 컨테이너가 종료된 경우에 삭제가 된다.

그렇기 때문에 이런 경우에는 Named volume을 사용해야 한다.

Named volume을 사용하는 방법은 run 할 때 -v 옵션을 사용하는 것이다.

docker run -v {volume 이름:컨테이너 내부 path} {image ID || image Name}

이렇게 실행을 하면 --rm 옵션으로 컨테이너를 삭제하더라도 데이터가 보존되는 것을 볼 수 있다.

• 바인드 마운트

개발하는 과정에서 스프링부트의 코드가 조금이라도 변경이 된다면, 이미지를 새로 만들고 해당 이미지로 컨테이너를 만들어야 했다.

해당 과정은 시간이 굉장히 오래 걸리고, 이미지가 쌓인다는 문제가 있었다.

바인드 마운트는 volume과는 다르게 해당 위치를 개발자가 알 수 있으며, 호스트 머신 상에 매핑될 컨테이너의 경로를 설정한다.

COPY로 소스코드를 복사하는 것이 아니라, 해당 마운트의 파일을 최신버전으로 유지하면서 배포할 수 있다는 장점이 있다.

바인드 마운트도 -v를 사용한다.

volume과는 거꾸로 {복사하고 싶은 디렉터리 : 컨테이너 디렉터로}로 실행할 수 있다.

docker run -v {바인드 마운트 할 경로:컨테이너 내부 path} {image ID || image Name}

하지만 이 과정에서 덮어쓰기 때문에 필요한 종속성들이 날아갈 수 있다.

그렇기 때문에 종속성이 있는 폴더는 익명 volume으로 유지하면서 run을 하면 종속성을 유지한 채로 최신 버전으로 실행이 가능하다.

• 컨테이너에서 데이터 관리하는 방법들 간의 비교

• 이미지를 공유하는 방법

이미지를 공유하는 방법에는 2가지가 있다.

1. Dockerfile을 공유한다.

2. 빌드된 이미지를 공유한다.

1번의 방법을 사용하면 받아온 후에 빌드를 해야하지만, 2번을 사용하면 빌드된 이미지를 공유하기 때문에 빌드를 할 필요도 없다.

• DockerHub에 이미지를 push하기

 도커허브에 업로드 하는 방법과 개인 저장소에 업로드 하는 방법이 있지만, 우선은 도커허브에 업로드하는 방법을 사용해보도록 하자.

DockerHub에 계정을 만들고 리포지토리도 생성한다.

그리고는 로컬에 와서 push 해주도록 한다.

깃과 마찬가지로

docker push {이미지 이름}

이렇게 사용하지만, {레포지토리 이름/이미지 이름:태그}의 이름으로 이미지가 생성되어 있어야 한다.

물론 이것이 개인 계정이기 때문에 docker login을 해야 할 수도 있다.

docker login

해당 명령어를 이용하여 계정과 비밀번호를 입력해주면 로그인이 완료된다.

이렇게 새로운 이미지가 올라간 것을 볼 수 있다.

• DockerHub에서 이미지를 pull하기

push와 반대로 올라간 이미지를 pull 할 수 있다.

docker pull {리포지토리 이름/이미지 이름:태그}

해당 명령어로 가져오면 된다.

이렇게 pull을 하면 새로운 이미지가 생성되어 있는 것을 볼 수 있다.

• 컨테이너의 중지와 재시작

docker ps

docker ps를 입력하면 현재 실행 중인 도커 컨테이너들을 확인할 수 있다.

만약 현재 실행 중인 컨테이너 외에도 중지된 컨테이너까지 확인하기 위해서는 다음 명령어를 사용하면 된다.

docker ps -a

이러면 현재 종료되어 있는 컨테이너도 확인할 수 있다.

이 종료되어 있는 컨테이너를 다시 재시작할 수도 있다.

docker run은 이미지를 기반으로 새 컨테이너를 만들지만, 변경사항이 없어서 컨테이너를 재실행하고 싶다면 docker ps -a로 컨테이너를 검색한 후

docker start {container ID || container name}

이렇게 종료된 컨테이너를 재실행한 것을 볼 수 있다.

• Attached, Detached

방금 해보았던 docker start로 컨테이너를 실행하면, 외부에서 docker ps로 상태만 확인할 수 있었고 내부에서 작업은 하지 않았었다.

분명히 실행 중인데도 말이다.

이 전의 docker run으로 컨테이너를 실행하면, 해당 터미널에서 컨테이너가 실행되고 다른 터미널에서 상태를 확인할 수 있었다.

이제 여기서 자유롭게 attached, detached를 설정하여 작업해 보도록 하자.

우선 docker start는 detached 모드가 디폴트이며, docker run은 attached 모드가 디폴트이다.

docker run을 확인해보자.

이렇게 콘솔에 컨테이너의 결과가 출력되는 것을 볼 수 있다.

이 컨테이너를 콘솔과 연결되지 않는 detached 모드로 실행하기 위해서는, -d 옵션을 넣어주면 된다.

이렇게 -d 옵션을 넣어주면, 이전과는 다르게 바로 컨테이너가 실행되었다고 나오고 터미널과는 분리되는 것을 볼 수 있다.

분리된 컨테이너와 터미널을 다시 연결하고 싶다면, attach 명령어를 사용하면 된다.

docker attach {container ID || container name}

이렇게 다시 연결되어 결과가 출력되는 것을 볼 수 있다.

터미널과 연결시키지 않고 로그만 가져오고 싶다면, logs 명령어를 사용하면 된다.

이렇게 바로 출력의 결과만 가져오는 것을 볼 수 있다.

• 인터렉티브 모드로 작업하기

웹서버뿐만 아니라 짠 코드를 직접 실행시킬 수도 있다.

작성한 파이썬 코드를 실행해보도록 하겠다.

Dockerfile은 다음과 같이 작성했다.

FROM python

WORKDIR /python

COPY . /python

CMD ["python", "rng.py"]

해당 Dockerfile을 바탕으로 이미지를 생성하고, 컨테이너를 실행한다.

그리고는 run -it를 사용하여, 인터렉티브하게 컨테이너를 실행한다.

docker run -it {image ID || image name}

이러면 해당 컨테이너와 상호작용하며 실행할 수 있다.

run이 아닌 start의 상황에서는 -ai 옵션을 사용하여 인터렉티브하게 재실행한다.

• 이미지와 컨테이너 삭제하기

그 동안 생성했던 많은 이미지와 컨테이너들을 삭제해보도록 하자.

컨테이너를 제거할 때는 rm 명령어를 사용한다.

docker rm {container ID || container name}

당연히 실행 중인 컨테이너는 삭제할 수 없고, 현재 종료된 컨테이너만 제거가 가능하다.

이번에는 이미지를 삭제해보자.

이미지를 삭제할 때는 rmi 명령어를 사용한다.

docker rmi {image ID || image name}

이렇게 이미지가 삭제되는 것을 볼 수 있다.

여기서도 이미지는 해당 이미지를 사용하여 실행 중인 컨테이너가 존재하지 않을 때만 삭제가 가능하다.

해당 명령어를 사용하면, 삭제 가능한 모든 이미를 삭제한다.

docker image prune

만약 컨테이너를 종료 후 해당 컨테이너를 자동으로 제거하고 싶다면, run을 하면서 --rm 옵션을 넣어주면 된다.

docker run --rm {image ID || image name}

이렇게 종료하자마자 자동으로 삭제되는 것을 볼 수 있다.

• 컨테이너에서의 파일 복사

실행 중인 컨테이너로 또는 실행 중인 컨테이너 밖으로 파일 또는 폴더를 복사할 수 있다.

해당 과정에서는 cp 명령어를 사용한다.

docker cp {복사하려는 파일 혹은 폴더} {container name}:{복사하려는 경로}

당연히 반대로 컨테이너에서 가져올 수도 있다.

cp 명령어를 사용하여 경로의 순서를 바꾸면 된다.

docker cp {container name}:{복사하려는 경로} {복사하려는 파일 혹은 폴더}

• 컨테이너와 이미지에 이름 혹은 태그 지정하기

지금까지는 자동으로 도커에서 생성된 이름만을 사용했다.

당연히 이런 이름들도 우리가 직접 지정할 수 있다.

직접 지정하는 방법을 알아보도록 하자.

--name 옵션에 이름을 지정해주면 된다.

docker run --name {container name} {image ID || image name}

myapp이라는 이름이 지정된 것을 볼 수 있다.

이번에는 이미지에 이름을 지정해보자.

이미지의 이름을 태그라고 하며 2개로 구분할 수 있다.

이미지의 리포지토리 : 이미지의 태그 이렇게 구성이 되어 있는 데, 이렇게 만든 이유는 여러개의 특정화된 이미지 그룹을 만들 수 있기 때문이다.

이미지를 가져올 때도 태그를 지정할 수 있으며, 보통은 특정 버전의 이미지를 가져올 때 사용한다.

이미지의 이름을 생성할 때는 -t 옵션을 사용한다.

docker build -t {이미지의 이름}:{이미지의 태그} .

• 이미지와 컨테이너는 무엇인가?

저번에 다루어 봤듯이 컨테이너는 애플리케이션, 애플리케이션을 실행하는 전체 환경 등등 무엇이든 포함하는 작은 패키지이다.

컨테이너에는 소프트웨어 실행 유닛이 존재하며, 우리는 그 유닛을 실행하는 것이다.

이미지는 템플릿, 컨테이너의 블루프린트이다.

이미지는 실제로 코드와 코드를 실행하는데 필요한 도구를 포함한다.

하나의 이미지는 하나의 컨테이너만 실행하는 것이 아니라

이미지를 기반으로 여러 컨테이너를 만들 수 있다.

이미지는 모든 설정과 코드가 포함된 공유 가능한 패키지이며, 컨테이너는 그런 이미지의 구체적인 실행 인스턴스이다.

• 외부에서 이미지를 가져와 사용하기

이미지는 우리가 직접 만드는 것이 아닌, 가져와서 사용하는 방법도 존재한다.

일반적이어서 미리 구축이 되어 있는 공식 이미지들이 많이 있으며, 해당 이미지를 가져오는 것도 좋은 방법이다.

보통은 DockerHub에서 많이 찾아볼 수 있다.

https://hub.docker.com/

docker run node 명령어를 실행해 보았는 데, 아래처럼 나오는 것을 볼 수 있다.

우선 local에서 node image를 찾고, 없기 때문에 원격으로 이미지를 가져오는 것을 볼 수 있다.

• 이미지를 이용하여 빌드하기

커스텀 이미지를 만들기 위해서는 Dockerfile을 만들고 작성해야 한다.

우선 다음과 같이 작성한다.

FROM node

WORKDIR /app

COPY . /app

RUN npm install

EXPOSE 80

CMD ["node", "server.js"]

FROM은 다른 베이스 이미지 위에 현재 이미지를 생성한다는 의미이다.

물론 처음부터 만들 수는 있지만, 언제나 코드에 필요한 도구 같은 레이어가 필요하기에 보통은 추가한다.

WORKDIR은 도커 내부에서 해당 컨테이너를 작업할 경로를 명시한다.

/app 폴더 밑에서 작업한다는 의미이다.

COPY는 Dockerfile과 같은 디렉토리디렉터리 내에서 작업 디렉터리로 복사해 가져갈 파일들을 적어놓는 것이며, . 을 사용하면 현재 디렉터리에서 Dockerfile을 제외한 모든 파일을 복사한다는 의미이며, 도커 내부의 /app 폴더로 복사해 간다는 것이다.

WORKDIR에 의해 도커 내부의 경로는 상대주소를 가질 수 있지만, 보통 명확하게 하기 위해 절대경로로 하는 것을 추천한다.

RUN은 이미지에서 실행할 명령을 작성하는 것이다. 여기서에선 npm install을 사용해 필요한 종속성들을 설치해 주었다.

EXPOSE는 노출하고 싶은 포트의 주소를 명시한다.

없어도 되지만 그래도 명시하도록 하자.

CMD는 이미지가 빌드 될 때 실행되는 명령이 아닌, 컨테이너를 실행할 때 사용하는 명령어를 적어두면 된다.

이제 해당 이미지를 바탕으로 빌드해보자.

docker build .

해당 명령어를 사용하면 현재 디렉토리에 있는 Dockerfile을 사용해 이미지를 빌드한다.

Dockerfile에 있는 명령어들이 실행 된 것을 볼 수 있다.

해당 이미지를 바탕으로 컨테이너를 실행해본다.

docker run -p 80:80 {이미지 ID}

이렇게 접속이 되는 것을 볼 수 있다.

도커의 실행 상태를 보고 싶다면

docker ps 명령어를 사용하여 현재 실행 중인 컨테이너들을 볼 수 있다.

• 이미지의 변경사항

이미지는 단순히 읽기를 위해서 작성한 코드이다.

무슨 말인지를 직접 보여주도록 하겠다.

이렇게 html 중간의 내용을 변경하였다.

이렇게 변경을 하고 도커의 컨테이너를 재실행해도

이렇게 이전 그대로 나오게 된다.

이는 이전에 COPY 한 내용을 바탕으로 실행이 되기 때문에 해당 COPY에서는 변경사항이 적용되지 않아 생기는 문제이다.

그렇기 위해 이미지로 빌드를 다시 해서 COPY를 다시 해야 해당 변경사항이 적용 될 것이다.

이미지를 다시 빌드하고 컨테이너를 실행해보니

이렇게 제대로 적용이 된 것을 볼 수 있다.

• 이미지의 레이어

Docker에서 이미지를 만들 때

이렇게 CACHED라고 나오는 경우를 볼 수 있을 것이다.

도커는 명령어를 다시 실행했을 때의 결과가 동일하다고 판단되면, Cache를 사용한다.

모든 명령의 결과를 캐시하고, 그 캐시를 사용하는 것이다.

이것을 레이어 기반 구조라고 한다.

Dockerfile의 모든 명령어는 레이어를 나타낸다.

이렇게 이미지 레이어를 기반으로 컨테이너가 실행되게 된다.

해당 레이어에서 아무것도 변경되지 않으면, 캐시를 사용하지만

만약 코드가 변경이 된다면 캐시의 일부만 사용하고 해당 변경내용을 다시 실행하게 된다.

이렇게 만약 코드가 변경이 되었다면, 해당 파일을 다시 COPY하며 캐시를 사용하지 않는 것을 볼 수 있다.

그리고 그 아래의 레이어들도 모두 재실행되는 것을 볼 수 있다.

• 도커란?

도커는 컨테이너 기술입니다.

컨테이너를 생성하고 관리하기 위한 도구입니다.

이렇게 말하면 쉽게 이해가 되지 않으며, 왜 써야 하는 지도 잘 모르겠다.

우선 소프트웨어 개발에서 컨테이너는 표준화된 소프트웨어 유닛입니다.

아래는 구글 클라우드에서 말하는 컨테이란?입니다.

https://cloud.google.com/learn/what-are-containers?hl=ko

컨터이너는 스프링부트를 사용해 봐서 알겠지만, 해당 코드와 종속성, 코드들이 포함되어 있다.

도커는 결국 이러한 컨테이너의 생성 및 관리 프로세스를 도와주는 도구이다.

결국 도커로 이 컨테이너를 만들고 관리하는 것이 목표가 될 것이다.

• 컨테이너가 필요한 이유

왜 이렇게 개발에서 독립적인 표준화된 애플리케이션 패키지를 원하는 것일까?

이렇게 직접 작업한 로컬의 환경과 배포에서의 환경이 다른 경우가 생긴다.

Java 11에서는 사용하지 못하는 코드들이 있다면 문제가 될 것이다.

이러한 문제가 있기에 같은 개발 환경을 갖는 것은 상당히 중요한 문제이다.

이것을 도커의 컨테이너로 해결하는 것이다.

특정 버전을 도커 컨테이너에 Lock 할 수 있으므로, 코드가 항상 정확한 버전으로 실행되도록 할 수 있다.

애플리케이션이 자체적으로 필요한 버전을 제공하는 컨테이너에서 실행되게 된다.

또한 팀에서 작업을 하게 된다면

팀원 간에 작업 환경이 다르게 될 수도 있다.

그런 경우에도 문제가 생기지 않도록 같은 환경에서 실행될 수 있도록 한다.

또한, 혼자 작업을 하는 경우에도 문제가 될 수 있다.

이렇게 가지고 있는 프로젝트마다 버전이 다른 경우이다.

이런 상황에서도 컨테이너에 모든 환경이 속해있기 때문에 컨테이너만 바꾸면 문제없이 동작할 수 있게 된다.

• 가상 머신 VS 도커

옛날에 가상머신으로 네트워크 공부했던 거 처럼, 그냥 가상머신에 각각의 환경을 만들어서 배포를 해도 독립된 환경을 만들어 줄 수 있기는 하다.

하지만 보통은 도커를 사용하게 되는 데, 이유에 대해 알아보자.

리눅스의 가상머신을 이용한다고 해보자.

이렇게 각 App마다 VM을 사용하게 되고, 이 Virtual OS는 메모리, CPU등의 사용량이 높다.

때문에 VM을 많이 사용할 수록 큰 오버헤드가 발생하게 된다.

도커를 사용할 때를 보자.

이 컨테이너에는 중요한 도구, 런타임이 추가되어 있지만 오버헤드가 큰 운영체제 등은 들어가 있지 않다.

컨테이너 내부에 작은 레이어가 포함되어 있을 수는 있지만, VM을 설치하는 것과는 비교도 안되게 가벼울 것이다.

또한 도커를 사용하면 이미지를 만들어 다른 사람과 공유하며, 모든 사람이 자신의 시스템에서 사용한 것과 같은 환경을 제공해 줄 수 있다.

이번엔 캐시에 대해서 더 자세히 배운다.

저번 시간에 캐시에 대해 대충은 공부를 했을 것이다.

캐시가 없을 때는 헤더와 바디에 해당하는 내용을 몇번이고 다시 전송해야 한다.

인터넷 네트워크가 메모리와 디스크에 비해 느리기 때문에 사용자가 기다리는 시간이 길어진다.

여기에 캐시를 추가해보자.

이렇게 캐시를 추가하면 캐시가 유효한 60초 동안은 HTTP 바디에 해당하는 부분은 전송할 필요가 없다.

그렇게 되면 사용자가 기다리는 시간이 훨씬 줄어들게 된다.

근데 만약 60초의 시간이 지나간 후에는 어떻게 될까?

당연히 서버에서 데이터를 다시 조회하고 캐시를 갱신해야 할 것 같다.

하지만 서버에서도 데이터가 변하지 않았다면 굳이 캐시를 갱신해야할까?

• 캐시 시간 초과

캐시 만료후에도 서버에서 데이터를 변경하지 않았다면, 저장해두었던 캐시를 재사용 할 수 있을 것이다.

하지만 서버에서 데이터가 변하지 않았다고 확인을 받아야 할 것이다.

그 방법에 대해 살펴보자.

이렇게 HTTP 헤더에 그 데이터가 마지막으로 수정된 시각을 포함해서 보낸다.

그리고 그 다음에 GET으로 조회를 한다면 요청에 마지막 수정된 시각을 포함해서 확인을 받는다.

만약 서버에서 확인을 한 후 변동이 없다면 304로 데이터가 수정되지 않았음을 알리고 해당 캐시데이터를 재사용한다.

이렇게 하면 데이터가 상대적으로 작은 헤더끼리만 보내도 데이터를 사용할 수 있어 매우 실용적인 해결책이다.

이 방법도 굉장히 좋지만 여기에 추가로, 같은 데이터를 수정해서 데이터는 같지만 수정된 날짜만 다른 경우도 생각을 해보자.

이런 경우 캐시를 사용하면 되지만, 서버에서는 용량이 상대적으로 큰 데이터를 전송해주게 될 것이다.

그렇기에 ETag라는 검증 헤더를 추가하게 된다.

ETag(Entity Tag)는 캐시용 데이터에 고유한 이름을 달아두고, 데이터가 변경될 때마다 이 이름을 바꾼다.

그냥 서버에서 ETag를 확인하고 현재 데이터의 ETag와 같으면 캐시를 사용하고, 다르면 HTTP 바디 내용을 재전송하는 간단한 방식이다.

위에 방법처럼 서버에서 응답할 때 ETag를 같이 캐시에 저장한 후

다시 클라이언트에서 요청할 경우 ETag를 같이 확인 받는 방법이다.

이렇게 캐시를 확인 받을 수 있다.

• 캐시와 조건부 요청 헤더

Cache-Control

- Cache-Control: max-age

캐시 유효 시간(초)

- Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 origin 서버에 검증한 후에 사용

- Cache-ControlL no-store

데이터를 저장하면 안됨

Validator(검증 헤더)

- ETag

위에 보았듯이 ETag를 확인

- Last-Modified

마지막 수정시간을 확인

조건부 요청 헤더

- If-Match, If-None-Match

ETag를 확인하여 조건부로 HTTP 메시지 바디까지 전송 요청

- If-Modified-Since, If-Unmodified-Since

Last-Modified를 확인하여 조건부로 HTTP 메시지 바디까지 전송 요청

• 캐시 무효화

Cache-Control: no-cache, no-store, must-revalidate를 사용한다.

- Cache-Control: no-cache

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

- Cache-Control: no-store

데이터를 저장하면 안됨

- Cache-Control: must-revalidate

Origin 서버 접근 실패시 반드시 오류가 발생

HTTP 헤더에 대해서 공부하자.

HTTP 헤더는 지금까지 나왔겠지만

해당 부분들을 말한다.

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담고 있다.

헤더는 데이터를 해석할 수 있는 정보를 제공하게 되었다. (데이터 유형, 데이터 길이...)

Content-Type

표현 데이터의 형식을 담고 있다.

예로는 text/html; charset=utf-8, application/json 등이 있다.

Content-Encoding

표현 데이터를 압축하기 위해 사용한다.

데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가한다.

예로는 gzip, deflate 등이 있다.

Content-Language

표현 데이터의 언어를 표현한다.

예로는 ko, en 등이 있다.

Content-Length

표현 데이터의 길이를 표현한다.

데이터는 바이트 단위로 표현한다.

• 콘텐츠 협상

클라이언트는 서버에 원하는 표현을 요청할 수 있다.

이 협상 헤더는 요청 시에만 사용할 수 있다.

Accept: 클라이언트가 선호하는 미디어 타입을 전달

Accept - Charset: 클라이언트가 선호하는 문자 인코딩을 전달

Accept - Encoding: 클라이언트가 선호하는 압축 인코딩을 전달

Accept - Language: 클라이언트가 선호하는 자연 언어를 전달

하나의 표현만 요청하는 것이 아니라 여러 개의 값들을 우선순위로 지정해 요청할 수 있다.

0 ~ 1의 값을 사용하며 클수록 높은 우선순위를 가진다. (생략하면 1)

GET /page
Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.8

이런 식으로 사용한다.

그리고 당연히 늘 그렇듯이 더 구체적인 코드를 우선한다.

GET /page
Accept: text/*, text/plain, */*

이렇게 되어 있다면

1. text/plain

2. text/*

3. */*

이 우선순위로 따라가게 된다.

• 전송 방식

전송 방식으로는 단순 전송, 압축 전송, 분할 전송, 범위 전송 4가지가 있다.

단순 전송

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3456

<html>
	<body>...</body>
</html>

그냥 단순하게 이런 코드를 전송하는 것이다.

Content-Length를 적어주어야 한다.

압축 전송

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Encoding: gzip
Content-Length: 521

asdfasdfgh42523yhshadsgaasdfds...

말 그대로 압축해서 보내는 것이다.

압축을 했기 때문에 Content-Encoding으로 어떻게 압축했는지 알려주어야 한다.

분할 전송

HTTP/1.1 200 OK
Content-Type: text
Transfer-Encoding: chunked

2
My
4
Name
2
is
2
sk

이렇게 하나의 데이터를 보낼 때마다 바이트 수와 분할해서 보내는 것이다.

처음부터 Content-Length로 바이트 수를 알려주면 안 된다.

범위 전송

클라이언트가 특정 범위를 요청할 때 보내는 방법으로

만약 클라이언트가

GET /page
Range: bytes=501-1000

이런 요청을 보냈다면 그 범위에 맞게

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Range: byes 501-1000/1000

adsfsdafasdfasdfahsdfn

해당 범위의 데이터만 응답으로 보내는 것이다.

• 일반 정보

그냥 일반 정보로는

Form: 유저의 이메일 정보

Referer: 이전 웹 페이지 주소

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

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

Date: 메시지가 생성된 날짜

가 있다.

From

요청에서 사용하며, 검색 엔진들이 주로 사용한다.

일반적으로는 많이 사용하지 않는다.

Referer

현재 요청된 페이지의 이전 웹 페이지 주소이며, 요청에서 사용한다.

Referer를 사용해서 유입 경로를 분석한다.

User-Agent

클라이언트의 애플리케이션 정보이며, 요청에서 사용한다.

어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능하다.

Server

서버의 소프트웨어 정보로, 응답에서 사용한다.

Date

메시지가 발생한 날짜와 시간으로, 응답에서 사용한다.

• 특별한 정보

Host: 요청한 호스트 정보

Location: 페이지 리다이렉션

Allow: 허용 가능한 HTTP 메서드

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

특별한 헤더로는 이렇게 있으며, 공통부분이 없으니 그냥 하나씩 바로 알아보자.

Host

요청한 호스트 정보를 적어주어야 해당 서버의 어떤 도메인으로 접근할 것인지를 알 수 있다.

Location

페이지 리다이렉션으로 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, 그 위치로 자동 이동한다.

Allow

허용 가능한 HTTP 메서드를 알려주며, 메서드 오류인 405(Method Not Allowed) 응답에 포함되어야 한다.

Retry-After

요청을 처리할 수 있는 시간을 알려주며, 503(Service Unavailable)에 포함한다.

Retry-After: Sat, 4 Dec 1999 10:12:56 GMT

• 쿠키

쿠키가 무엇인지는 저번 JSP 공부에서 배웠을 것이다.

만약 쿠키를 사용하지 않는다면 로그인 후 해당 도메인의 다른 페이지에 접근할 때 서버에서 유저를 기억하지 못할 것이다.

클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어지고, 서버는 이전 요청을 기억하지 못한다.

그렇다고 모든 GET에 사용자의 정보를 쿼리를 넘길 수도 없을 것이다.

그렇기 때문에 클라이언트에 쿠키를 남긴다.

이렇게 Set-Cookie로 쿠키를 저장하고 나면 쿠키 저장소에서 조회해가며 Cookie를 이용해 헤더에 추가한다.

쿠키는 네트워크 트래픽을 추가로 유발하기 때문에 최소한의 정보만 사용하는 것이 좋다.

보안에 민감한 데이터는 저장하면 안된다.

Expries, max-age로 쿠키의 생명 주기를 설정할 수 있다.

Set-Cookie: expires=Sat, 4-Dec-1999 10:19:21 GMT

만료일이 되면 쿠키를 삭제한다.

Set-Cookie: max-age=3600

0이나 음수를 지정하면 쿠키 삭제

도메인

쿠키의 도메인을 명시한다면 명시한 문서 기준 도메인 + 서브 도메인 포함하여 쿠키가 접근한다.

쿠키의 도메인을 명시하지 않는다면 현재 문서의 도메인만 적용하여 쿠키가 접근한다.

예를 들면 domain=seungkyu.com을 지정하면

seungkyu.com은 물론이고 ???.seungkyu.com에도 쿠키가 접근한다.

하지만 생략을 한다면 seungkyu.com에만 접근하게 된다.

그리고 지정한 경로의 하위 페이지에만 쿠키가 접근하게 된다.

완성된 Set-cookie의 예를 보자면

Set-Cookie: id=1232145; expires=Sat, 4-Dec-1999 12:04:11 GMT; path=/; domain=seungkyu.com;Secure

이런식으로 작성이 되게 된다.