TCP/IP, DNS

Jong-Ho Jeong Sep 12, 2016

TCP/IP, DNS 기초

오늘도 여느때처럼 이리저리 구글링을 하다가 개발자의 면접에 관한 글을 봤다. 한 시니어개발자분이 본인의 회사에서 경험한걸 바탕으로 interviewer와 interviewee에게 참고할만한 경험을 공유하는 글이었다.

구인자로서 직접 면접을 볼 때 물어본 질문들의 예를 들어주셨는데 특히 웹 포지션의 질문중 url을 입력하고 나서 서버에서 응답이 오기까지에 대해 가능한 길게 설명하라는것이 있었다. 나는 이 과정이 클라이언트가 서버에 request를 보내고 response를 받아서 받아온 xml을 웹브라우저가 렌더링해준다는 사실을 알고 있다. 이 주제는 일반적으로 웹에대해 공부하고 있는 사람이라면 가장 먼저 알게 되는 것중 하나이고 나 역시 웹에 대해 공부하려고 마음먹은 후 처음 공부한 내용이기도 하다.

그런데 그 글을 읽으면서 드는 생각은 이정도면 되나? 라는 것이었다. 내가 면접에서 그런 질문을 받았다고 하면 아무리 길게 대답한다고 해도
몇분안에 대답이 끝날 것 같다. 왜냐하면 지금 존재하는 유수의 프레임워크들을 사용하면 이렇게 간단한 내용만 이해하고 있어도 브라우저에 hello world를 띄울 수 있기 때문이다.
하지만 이에 대한 주제는 네트워크 엔지니어 수준까지는 아니더라도 좀 더 자세히 알아야할 필요가 있다고 생각한다.

시작

우리는 웹브라우저를 사용하는데 익숙하다. 원하는 페이지를 띄우기 위해 주소표시줄에 주소를 입력하거나 어떤 페이지의 링크를 클릭하면 해당 위치의 웹페이지로 이동한다.

예를 들면 http://www.google.co.kr을 주소표시줄에 입력하면 개발자들의 신앙인 구글신님의 존안이 뜬다.
그렇다면 http://www.google.co.kr가 구글 서버라는 것을 어떻게 아는것일까?

google

IP(Internet Protocol)

network

거미줄같은 웹에 널부러져있는 리소스들에게 접근하기 위해서는 해당하는 리소스가 어디있는지 알아야한다. 클라이언트가 인터넷에 연결된 기기를 식별하기 위해 기기들이 가지고 있는 유일한 번호를 IP 주소라고 한다.

그런데 고유한 주소를 제대로 찾아가기 위해서는 체계가 필요하다. 예를 들어 대한민국 경기도 고양시 덕양구 행신동은 국, 도, 시, 구, 동으로 구분되는 주소체계이다. 이것처럼 IP주소에도 체계가 있다.

현재 대중적으로 사용되고 있는 것은 IPv4 주소체계이다. 8bit씩 네부분으로, 총 32bit이며 10진법으론 12개의 숫자로 이루어진다. 의미적으로는 네트워크주소와 호스트주소로 나뉜다. 네트워크 주소는 네트워크와 또 다른 네트워크를 구분하는데 사용하고 호스트주소는 같은 네트워크 속에서 기기를 식별하는데 사용된다.

network

이러면 네트워크속의 모든 기기는 구분되어지고 식별될 수 있다. 네트워크주소와 호스트주소를 구분하는 것은 주소의 클래스별 구분과 서브넷마스크를 통해서 할 수 있다. 구체적인 구분방법은 링크로 대체한다. 참고 페이지

보통 네트워크는 라우터라는 장치를 통해서 형성되는데, 라우터는 목적에 맞는 데이터의 이동경로를 적당히 결정해 준다. 따라서 다른 네트워크로 통하기 위해서는 반드시 거쳐야하는 장치이다.
우리가 IP주소를 설정할 때 게이트웨이를 지정해 줘야 하는데 일반적으로 라우터의 주소가 게이트웨이의 주소이다. 위키피디아의 비유를 빌리자면 해외여행을 가기위해 반드시 들려야 하는 공항이 게이트웨이가 된다.

IP setting

일반적으로 x.y.z.1는 게이트웨이의 주소, x.y.z.255는 브로드캐스팅(모든 네트워크안의 기기에 신호를 보냄)주소로 사용한다.

IPv4체계는 약 43억개의 IP를 할당할 수 있는데, 2011년 2월에 IP가 모두 소진되면서 IPv6체계를 도입했다. 8bit씩 네부분의 32bit, 10진수로 표현하던 기존의 체계에서 16bit씩 8부분의 128bit, 16진수표현으로 바뀌면서 할당할 수 있는 IP주소의 수가 크게 늘어났다.

DNS (Domain Name Server)

IP는 위에서 설명한것처럼 12개의 숫자로 이루어져 있다. 하지만 사용자들은 의미도 없는 12개의 숫자를 항상 외우고 다니지 않는다. 그저 google, facebook 처럼 그들에게 익숙한 단어를 머릿속에 기억할 뿐이다. 따라서 특정 단어와 실제 IP 주소를 매핑시켜주는 시스템이 필요하고 그것이 DNS이다.

DNS

위 이미지에선 google.co.kr로 ping을 날렸더니 74.125.23.94에서 응답했다는 것을 볼 수 있다.

DNS가 동작하는 과정은 다음과 같다.

일단 로컬에 있는 DNS서버에 캐싱해둔걸 먼저 살핀다.
없다면 최상위 도메인에서부터 차례로 트리를 탐색한다.
일치하는 도메인을 찾았다면 IP주소를 반환한다. (Recursive Query)

예를 들어 google.co.kr의 경우 먼저 루트 네임서버(전 세계에 13개뿐) 에 요청을 보낸다.루트네임서버는 자세한 내용을 모르기 때문에 .kr 도메인을 관리하는 서버를 알려준다. .kr을 관리하는 서버에 요청을하면 이 서버 또한 구체적인걸 모르기 때문에 .co를 관리하는 도메인서버를 알려주고, 결국 google.co.kr을 알고있는 서버까지 도달하게 되어서 이 도메인에 해당하는 IP주소를 반환한다.

TCP

도메인에 따라 다른 서버에 연결시키거나 같은도메인에 여러 서버를 연결해 놓고 순서를 바꿔주는 식으로 트래픽을 분산 시킬 수 있다.

TCP (Transmission Control Protocol)

다른 부분도 마찬가지겠지만 특히 TCP에 대한 내용은 매우 방대해서 관련 주제로만 책 한권이 나올 정도이다. 여기서는 기본적인 내용들을 간단히 요약한다.

어디서 출발하는지, 어디로 향하는 지에대해 최적의 경로를 선택하는것이 IP를 통해서 이루어진다면 그 전에 어떻게 데이터를 전송할 것인가에 대한 규약이 필요하다. 어떻게 패킷을 분할하고 조합할 것인가에 대한 규약중 가장 자주 사용되는 것이 TCP이다.

네트워크에서 전달하는 데이터의 최소단위를 패킷이라고 하는데 이 패킷은 이쪽 네트워크에서 저쪽 네트워크로 날로 던지지 않는다. 패킷이 전달되기 위해서는 포장하는 과정을 거쳐야하는데 TCP는 패킷을 어떻게 포장할것인가에 대한 약속이다. 패킷은 일련의 순서로 포장되어 보내지고, 받을 때는 반대로 해석된다.

packet

다음은 TCP헤더의 구조이다.

TCP

Source Port, Destination Port
- 데이터를 생성한 곳의 포트와 목적지의 포트를 나타낸다.
Sequence Number
- 데이터가 뒤죽박죽의 순서로 도착할 수 도 있기 때문에 이 필드를 이용해서 올바른 순서로 배치한다.
Acknowledgement Number
- 다음에 받기를 기대하는 데이터의 번호를 나타낸다.
Offset, Reserved, TCP Flags, Window
- 헤더가 어디까지인 알려주고 플래그를 포함하는등 데이터에 관한 내용을 나타낸다.
Checksum
- 내용을 검증하고 잘 전달이 됬는지 검사한다.
Urgent
- 데이터의 마지막 위치를 나타낸다.
Options
- TCP 처리과정에서의 기타 옵션

Handshaking

TCP는 신뢰도가 높은 프로토콜이다. 통신을 하기전에 서로 잘 연결이 되었음을 확인하고 종료할때 잘 종료가 되었음을 확인하기 위해 handshaking절차를 통해 서로간에 세션을 수립한다.

TCP

클라이언트는 서버에게 통신을 시작한다는 것을 알린다.
서버는 클라이언트에게 응답함과 동시에 클라이언트에게 통신을 시작함을 알린다.
클라이언트는 서버에게 응답한다.

이런 일련의 과정을 3-way handshaking 이라고 한다.

TCP

클라이언트는 서버에게 통신을 종료한다는 것을 알린다.
서버는 클라이언트에게 응답하고 남은 처리가 끝날때까지 기다린다.
서버는 클라이언트에게 통신을 종료한다는 것을 알린다.
클라이언트는 서버에게 응답한다.

이런 일련의 과정을 4-way handshaking 이라고 한다.

100메가 인터넷
우리는 통신사에서 제공하는 인터넷을 많이 사용하고 있다. 데이터 전송속도는 Throughput이라고 하는데 여러가지 이유로 오버헤드가 발생한다. TCP 가 한번에 처리할 수 있는 데이터의 양(TCP windows size), 네트워크간의 물리적인 거리를 왕복하는데 걸리는시간 (RTT, Round Trip Time), 네트워크간에 bottle neck이 발생한 경우 등의 이유로 보통 광고하는 속도를 기대하기 힘들다. 예를 들어 TCP window size=64Kbytes, RTT=20ms라고 가정하면 64 * 1024 * 8 / 0.02 = 26214400, 약 26Mbps가 이론상 기대할 수 있는 최대 속도, Max Throughput이다.