2020-11-23 에 겪었던 나의 시행착오

다른곳에 저장해두었던 내용을 블로그에 옮겨본다.

 

-v 옵션을 처음 봤을 당시, 보고 문득 혼자 상상의 나래를 펼치며 망상을 했었다...

공부하다가 이해가 안가는 부분을 여기저기 물어보다 깨닫게 되곤한다.

게다가 물어보면 정말 검증 방법까지 알려주시는 감사한 현업자 선배님들...

 

 

Docker Container Volume

필요한 이유

  • container가 run 명령에 의해 시작될 때는 read-only image로부터 시작되어 container의 filesystem은 read-only layer 위에 read-write layer로 만들어진 virtual filesystem 이다.
  • 실제 Container를 시작한 후 만들어진 파일은 persistent filesystem에 저장된 것처럼 느껴지지만, 실제로는 디스크에 쓰여지는 것이 아니라 in-memory file system 에 쓰이는 것이므로, container가 종료되면 사라진다.
  • 동일한 image로부터 container를 다시 만들면, 저장한 데이터는 사라지게 된다.
  • 만약 DB를 사용하는 앱이라면, DB에 record 를 저장하였으나, container 가 종료되면 DB 테이블이 사라지게 된다.

⇒ 이러한 문제를 해결하기 위해 Container Volume을 제공

  • -v 옵션을 사용해 docker run할 때 이미지만 변경하고 같은 볼륨을 마운트 하는 식으로 사용한다.

Docker Volume 설명

  • -v <host path> : <mounting point path in container>
  • volume 을 mount 하여 실제 디스크에 영구적으로 데이터를 저장하여, container가 종료되어도 영구적으로 데이터를 저장할 수 있다
  • but, 단점도 있다.
  • container의 장점 중의 하나는 container들 사이에 filesystem을 통한 간섭이 없어서 보안이 뛰어나다는 것인데 volume 기능은 잘못된 코딩 또는 바이러스에 의해 이러한 장점이 훼손될 수 있다.

Docker Volume 3가지 type

  1. Host volume
    • docker run -v /home/mount/data:/var/lib/mysql/data
    • 정확하게 mount할 경로를 지정
  2. named volume
    • docker run -v name:/var/lib/mysql/data
    • data 참조를 쉽게 하기 위해 이름으로 설정
  3. Anonymous volume
    • docker run -v /var/lib/mysql/data

 

 

 

 

 

동아리 현업 선배님들한테 항상 많은 도움을 받는다..

'Tech-Talk' 카테고리의 다른 글

TCP connection 과 Streaming + QUIC 에 대한 고찰  (0) 2021.08.29

같이 스터디하는 분들끼리 TCP connection에 대해 의견이 분분해서 토론이 시작되었고, 추가로 느꼈던 의문과 고민, 그 답을 찾아가는 과정을 남겨놓았습니다.

 

토론의 시작 질문

핸드폰으로 유튜브를 보던 중에 핸드폰의 IP가 변하면 TCP 연결이 끊어지나요?

 

상황 설명

  1. 와이파이에 연결되어 있다가 와이파이를 끊어서 Public IP가 바뀐다던가.
  2. 핸드폰을 들고 이동해서 IP가 바뀐다던가.

 

내 시나리오

TCP 연결이 끊어진다

 

서버사이드(유튜브)랑 클라이언트(핸드폰) 사이드로 나눠서 보면

  1. 둘이 TCP 연결되어있다가 클라이언트 IP가 변경되면 서버에서는 그걸 모른다.
  2. 따라서 서버에서는 계속해서 클라이언트에게 응답 패킷을 보낸다
  3. 근데 클라이언트는 그걸 못받는다. 왜? 기존 연결되어있던 IP가 바뀌었으므로
  4. 클라이언트는 바뀐 새 source ip로 TCP 연결되어있듯이 계속 서버에게 요청을 보낸다
  5. 서버는 TIME_OUT으로 기존 ip(라우터)와 연결이 끊긴다.
  6. 클라이언트도 계속해서 요청을 보냈는데 서버의 응답을 못 받아서 TIME_OUT으로 연결이 끊긴다.
  7. 연결이 끊겼으니 클라이언트가 TCP 연결을 다시 시도한다.
  8. 새로운 TCP 연결이 생긴다.

 

다른 분 시나리오

TCP 연결이 끊어 지지 않는다.
  1. 계층화의 개념으로 생각해보면 TCP 연결은 port만으로 연결이 되기 때문에 IP는 상관이 없다.
  2. Transport(전송) 계층 패킷의 헤더를 생각해보면 Source Port, Destination Port 만 있지 않은가?
  3. TCP는 전송계층 프로토콜 이므로, IP가 바뀌어도 TCP 연결이 끊기지는 않는다.

 

첫 번째 결론

일단 토론 끝에 내린 결론은

  • TCP 연결하는 통신에서도 패킷의 <소스 IP, 소스 port, 타깃 IP, 타깃 port>를 TCP control block으로 사용하기 때문에, 소스 IP가 변경되면 재 연결된다.

입니다!

 

 

추가 문제

TCP 연결이 끊어지느냐에 대한 것은 YES로 결론이 났다. 하지만 여기서 문제가 하나 더 있었으니,

유튜브는 스트리밍이므로 TCP 통신이 맞는가 UDP 통신이 맞는가?

우선 이론적으로 배운것을 바탕으로 시나리오를 작성해보고, 다른 개발자분들과 이야기를 나눠보며 새로 생긴 이슈들이다.

 

1. TCP는 신뢰성을 보장하기 위한 연결 지향 프로토콜이다 보니 흐름 제어나 혼잡 제어 등을 해서 속도가 느린 반면, UDP는 비연결성 프로토콜로 속도가 빨라서 보통 실시간 스트리밍 같은 곳에 많이 쓰인다.

 

2. 따라서 실시간 스트리밍 서비스는 UDP일 것이다.

 

3. 그러나, 유튜브 컨텐츠를 보는 것이 리얼타임 통신은 아니지 않은가?

 

4. 그렇다면 굳이 UDP를 쓸 이유도 없어진다.

 

5. 그럼 TCP인가?? 

 

6. 또한 HTTP 는 TCP/IP 기반 응용 프로토콜이다.

 

7. 브라우저는 UDP를 지원하는가..?

 

등의 끊이지 않는 의문이 생겼다.

 

이 의문들을 당장 해결하기 위해서, 바로 유튜브를 켜고, 개발자 도구를 열어서, 당장 Response Header를 살펴보았다.

유튜브 컨텐츠의 HTTP 헤더

그랬더니 예상과는 전혀 다른 quic라는 프로토콜이 튀어나오는 것이었다....!!

 

여기서 멈출 수는 없었다.

 

그렇게 quic 에 대해 알아보았다.

 

 

QUIC (Quick UDP Internet Connections)

QUIC 프로토콜은 Google에서 개발된 프로토콜로 현재 표준 등록을 진행 중이라고 한다.

우선 UDP 위에 QUIC 프로토콜은 얹고 HTTP를 얹은 게 눈에 띈다.

거기에 TCP-like 혼잡 제어 + loss recovery 라니...

 

간단하게,

UDP로 3-way-handshake 없애서 속도 올리고, QUIC로 TCP-like 신뢰성을 추가한다 라는 소리로 들린다.

 

즉, UDP의 속도적 장점 + TCP의 신뢰성 장점을 합친 것이 이 프로토콜의 목표인 것 같다.

 

 

TCP vs QUIC

 

시간적 이점이 왜 나타나는지를 조금 더 자세히 살펴보자.

 

TCP + TLS에서 동작하는 HTTP/2 프로토콜에는 HOL(head-of-line) 문제가 있었다.

  • HOL(head-of-line): HTTP/2에서 TCP 연결을 통해 패킷 전송이 일어날 때, 한 패킷에 문제가 생기면 다른 패킷 전송이 영향이 간다.

이에 QUIC는 독립 스트림을 여러 개 만들어 이 문제를 피하고자 하는 것이 핵심이다.

또한 hanshake 과정의 시간도 비교가 안된다.

 

 

 

결론

1. TCP 연결이 되어있다가 Client IP (Source IP)가 바뀌게되면 TCP control block으로 사용하는 패킷의 <소스 IP, 소스 port, 타깃 IP, 타깃 port>가 바뀌므로 TCP connection 이 끊기고 재연결된다.

 

2. 유튜브 스트리밍 서비스는 UDP 기반 QUIC 프로토콜을 이용한다.

 

여담

구글의 대부분의 제품에는 이미 quic 가 들어가 있지만, 아직 표준이 지정되지 않았고 UDP 기반의 프로토콜을 서버가 받아들이는 데 있어서 최적화나 검증되지 않은 부분이 많기 때문에 항상 속도가 더 빠르다고 장담할 수는 없다.

 

다만, 표준이 지정되고 시대가 HTTP/3로 넘어가게 되면 IE의 몰락처럼, TCP 기반이 아닌 UDP 기반의 QUIC를 당연히 사용하는 시대가 올 수 있지 않을까.

(기술은 늘 변하는 것이고, 문제를 해결하는 데 있어서 더 좋은 해결책이 나왔다면 자연스레 바뀌기 마련이라 생각한다..)

 

 

 

 

이 내용들은 제가 공부하며 느꼈던 의문과 고민, 그 답을 나름대로 찾아가는 내용입니다.

아직 많이 부족하니. 틀린 부분은 얼마든지 지적해주세요!

 

 

Reference

 

언제나 즐거운 질문과 답변에서 이어지는 티키타카

1. 개발자 커뮤니티에 질문


2. 같은 동아리 출신 개발자 분들께 질문

 

'Tech-Talk' 카테고리의 다른 글

Docker -v 옵션에 대한 혼돈과 깨달음  (2) 2021.08.29

+ Recent posts