이전 포스팅에서 IPv4는 네트워크 주소와 호스트 주소로 나뉜다고 설명드렸습니다. 이를 나누는 기준이 고정돼있지 않은 것은 호스트 IP 주소가 얼마나 필요한지에 따라 네트워크 크기를 다르게 할당하기 위함입니다. 이 개념을 클래스(Class)라고 합니다.

클래스(Class)

A 클래스는 첫 번째 옥탯은 고정된 네트워크 주소를 갖고 있고 나머지 호스트 주소 번호는 자유롭게 설정이 가능합니다. B는 두 번째 옥탯까지 고정된 네트워크 주소를 갖고 있으며, C는 세 번째 옥탯까지 입니다. 이렇게 설정된 클래스는 다음과 같은 개수의 주소를 가질 수 있습니다. (이러한 구분을 서브넷 마스크로도 표현이 가능합니다. 이는 다음 포스팅에서 다뤄보도록 하겠습니다.)

• A 클래스: 약 1600만개
• B 클래스: 약 6.5만개
• C 클래스: 약 250개

클래스 구분

A 클래스는 맨 앞 옥텟 주소가 0~127 범위입니다. 즉, 2진수로 풀었을 때 맨 앞 자리가 0인 주소가 A 클래스입니다. 하지만 0은 네트워크 ID로 사용되고, 127은 자신을 의미하는 루프백(Loopback) 주소로 사용되므로 제외됩니다. 때문에 실제로 사용가능한 주소는 1.0.0.0 ~ 126.255.255.255 입니다.

B와 C 클래스도 이처럼 나타낼 수 있습니다. B 클래스는 첫 옥탯을 이진수로 나타냈을 때 10 000000 ~ 10 111111까지이며 이는 128~191까지를 나타냅니다. C 클래스는 110 00000 ~ 110 11111로 192~223까지 입니다.

이렇게 나눠진 클래스는 첫 옥탯만을 확인해도 클래스를 구분할 수 있습니다.

클래스풀, 클래스리스

이렇게 구분된 클래스 기반 IP 주소 체계를 클래스풀(Classful)이라고 부릅니다. IP 주소 체계를 처음 만들었을 때는 클래스 개념을 도입한 것이 확장성이 높고 주소 낭비가 적은 좋은 선택이었습니다. 하지만 인터넷이 상용화되면서 인터넷에 연결되는 호스트 숫자가 폭발적으로 증가헀습니다. 기존 클래스풀 기반 주소 체계는 이를 감당하기 힘들어지기 시작했습니다.

뿐만 아니라 A 클래스를 할당 받은 여러 회사에서 실제로 이 클래스의 IP 주소(약 1600만개)를 효율 적으로 사용하지 못하고 낭비 중이라는 사실이 드러났습니다. 그리고 이렇게 낭비되고 있는 주소를 다른 기관이 사용하도록 할 수도 없었습니다. 이러한 문제를 해결하기 위해 클래스 개념 자체를 버린 클래스리스(Classless) 주소 체계가 등장했습니다. 이를 CIDR(Classless Inter-Domain Routing) 기반 주소 체계입니다. 이외에도 NAT와 사설 IP를 함께 사용하는 방법, IPv6 사용하는 방법이 등장했습니다. 이에 따라 자연스럽게 클래스풀 주소 체계는 현재 사용하지 않게 됐습니다.

클래스리스 방법에 대해서는 다음 포스팅에서 하나씩 알아보도록 하겠습니다.

안녕하세요! 23년 초부터 IT 업계로 전향해 공부를 시작했습니다. 새로운 분야에 대해 학습하다 보니 너무 어렵고, 이해가 안돼서 저처럼 이해가 힘드신 분들을 위해 쉽게 설명하는 블로그를 작성하고 있습니다. 주로 제가 지금 배우고 있는 내용, 필요한 내용을 공부하며 글을 올리고 있습니다.

공부 시작을 클라우드 엔지니어 관련 지식으로 시작하다보니 현재 CS, AWS, Kubernetes처럼 인프라에 대한 기본 지식에 대해 다루고 있습니다. 이와 함께 준비 중인 것으로 JAVA 기반 백엔드, 프레임워크, DBMS까지 추가로 다뤄보기 위해 준비중에 있습니다.

점차 방문객이 많아지는 만큼 쉽고, 좋은 정보를 제공할 수 있도록 노력하겠습니다. 혹시 궁금한 사항이 있거나, 글 내용에 문제가 있으면 바로 댓글로 남겨주세요! 최대한 빨리 피드백 드리도록 하겠습니다.

그냥 지나칠 수 있는 이러한 글조차 봐주셔서 감사합니다. 늘 행복하세요 ♥

IPv4

우리가 인터넷 연결 관련한 문제를 접했을 때 IP에 대해 처음 접할 것입니다. 우리가 흔히 봤던 다음과 같은 설정에서 사용되는 IP는 IPv4 버전의 체계가 사용됩니다.

IP는 32 비트인 IPv4와 128 비트인 IPv6로 나뉩니다. IPv4 주소를 표기할 때는 4개의 옥텟(Octet)이라고 불리는 8비트 단위로 나누고 각 옥텟은 "."으로 구분합니다. 이 때 v4의 IP 주소는 10진법으로 표기되므로 자리마다 0~255 값을 쓸 수 있습니다.

이러한 IPv4는 네트워크 주소와 호스트 주소로 나뉘게 됩니다. 하지만 이 둘을 구분하는 경계점이 고정돼 있지 않은 것이 특징입니다. IP 주소 체계는 필요한 호스트 IP 개수에 따라 네트워크의 크기를 다르게 할당할 수 있는 클래스(Class)라는 개념을 도입하게 됐습니다. 이는 다음 포스팅에서 알아보겠습니다.

• 네트워크 주소: 호스트들을 모은 네트워크를 지칭하는 주소로 네트워크 주소가 동일한 네트워크를 로컬 네트워크라고 합니다.
• 호스트 주소: 하나의 네트워크 내에 존재하는 호스트를 구분하기 위한 주소입니다.

IPv6

IPv6는 32 비트 주소 체계를 갖고 있는 IPv4의 주소 고갈 문제를 해결하기 위해 개발됐습니다. 128 비트 체계인 IPv6는 32 비트 체계의 IPv4보다 약 340경 배나 더 많은 주소를 제공할 수 있게 됐습니다.

IPv6의 주소는 16 비트를 16진수로 표현해 8자리로 나타냅니다. 하지만 대부분 0의 숫자를 갖게 되므로, 이를 축약해 '0000'을 '0' 하나로 표현하거나 연속되는 0 그룹을 ':' 만을 남겨 표시하기도 합니다. 때문에 다음 IPv6는 모두 같은 주소를 나타내게 됩니다.

IPv6는 점점 상용화되고 있지만 간단하게 여기까지 알아보고 IPv4를 집중해서 포스팅하겠습니다.

우리가 통신을 진행하기 위해서 IP 주소를 먼저 따라가게 됩니다. 하지만 부여된 IP를 숫자로만 암기하기에는 무리가 있습니다. 접속하고자 하는 사이트에 대한 연관성은 없다시피 하고, IP는 쉽게 변경될 수 있기 때문입니다. 수시로 바뀌는 IP를 매번 외우고 있을 수는 없기 때문에 등장한 체계가 있습니다.

DNS(Domain Name System)

이름에서 유츄할 수 있듯 IP에 도메인 이름을 부여해 도메인을 입력하면 해당하는 IP로 이동하게 해주는 기능입니다. 우리가 구글에 접근하기 위해서는 "https://google.com/"이나 "142.250.196.100"를 입력해 접속하게 됩니다. 단순하게 보더라도 무작위 숫자를 암기하기 보다 구글을 뜻하는 도메인을 활용하는 것이 더 수월할 것입니다. 따라서 특별한 경우가 아니라면 대부분 도메인 주소를 사용해 IP 주소로 변환하는 DNS 서버를 사용하고 있는 것입니다.

DNS의 체계와 작동원리까지 다루기에 신입 개발자나 엔지니어에게 이정도까지 바라지는 않을 것 같아 나중에 네트워크 파트를 심도 있게 공부할 때 다뤄보도록 하겠습니다.

이전 포스팅에서 IP 체계를 다룰 때 단점 중 하나는 "하나의 IP를 가지고 있는 서버에서 두 개 이상의 애플리케이션을 다루고 있다면 이를 구분할 수 없다."라고 했습니다. 이를 해결하기 위한 방법이 바로 포트를 이용해 애플리케이션을 구분하는 방법입니다.

이와 같이 TCP 세그먼트에는 출발지 포트와 목적지 포트의 정보가 있어 하나의 IP만을 사용하더라도 애플리케이션을 구분할 수 있습니다. 예를 들면 다음과 같습니다.

서비스 플랫폼 IP로 접근한 후 영상을 이용하기 위해 클릭하면 11000번 포트에서 출발해 10000번 포트로 도착합니다. 이를 통해 영상 시청이 가능합니다. 이러한 원리로 여러 애플리케이션을 한 곳에서 운영할 수 있게 됩니다.

포트 번호

포트 번호는 0~65535까지 값을 가지고 있으며, 구성은 크게 다음과 같습니다.

• 0~1023: Well-known port
• 1024~40151: Registered port
• 40152~65535: Dynamic port

Well-known port는 직역하면 잘 알려진 포트를 뜻합니다. 일반적으로 잘 알려진 80번(HTTP), 443번(HTTPS)와 같은 포트를 뜻합니다. Registered port는 Well-known port처럼 많이 사용되지는 않지만 특정 소프트웨어나 애플리케이션이 필요로 할 때 사용되는 포트입니다. 나머지는 일반적으로 자주 사용되지 않기 때문에 임시로 사용하는 용도로 쓰이기도 합니다.

이렇게 구분하는 포트가 겹치게 되면 어느 서비스 포트로 데이터를 보내야할지 명확하지 않아 데이터 손실이 발생하기 때문입니다. IP도 마찬가지로 동일한 IP값이 할당되면 주소 충돌이 발생해 패킷이 올바르게 라우팅 되지 않습니다. 때문에 잘 알려진 포트인 0~1023번까지는 사용하지 않는 것이 좋습니다.

그렇다면 잘알려진 포트 중 우리가 알아둬야 할 중요한 포트들은 무엇이 있을까요?

굳이 다 암기할 필요는 없지만 알아두면 좋을 포트들을 정리했습니다. 앞으로 개발이나 클라우드 업계에서 공부하다 보면 자주 접하실 겁니다.

더 다양한 포트 목록은 wiki에 잘 정리돼 있으니 확인해 보셔도 좋을 것 같습니다!

이전 포스팅에서 OSI 7 계층의 구성 요소와 특징에 대해 살펴봤습니다. 그렇다면 이번에는 이 구조를 통해 어떻게 통신이 이루어지는지 간단하게 살펴보겠습니다.

인터넷 통신 방법

클라이언트가 서버에 A라는 명령을 요청한다고 가정해 봅시다. 그렇다면 다음 그림과 같은 형태를 띨 것입니다.

이렇게 서버와 클라이언트를 이어주는 인터넷 망이 이와 같이 단순하다면 편하겠지만 안타깝게도 저희가 사는 세상은 훨씬 복잡한 인터넷 망 체계를 가지고 있습니다.

그렇다면 이와 같은 상태에서는 어떻게 데이터를 주고 받을 수 있을까요?

1. IP(Internet Protocol)

첫 번째는 전송하고자 하는 데이터에 IP 패킷을 추가해 전달하는 방법입니다. 출발지 IP와 목적지 IP 등 정보를 데이터에 붙여 전달하는 방식입니다.

이와 같은 방법으로 데이터를 주고 받을 수 있게 됐지만 다음과 같은 한계가 있습니다.

1. 비연결성
   직접적으로 연결이 돼있지 않다보니 상대가 패킷을 받을 수 있는 상황인지 구분할 수 없습니다. 때문에 패킷을 받을 대상이 없거나, 서비스 불능 상태라고 하더라도 패킷을 전송하게 됩니다. 
   
   
2. 비신뢰성
   중간에 패킷이 소실되거나, 보낸 패킷의 순서가 바뀌어 전송될 경우 처리에 문제가 발생할 수 있습니다. 또한 한 서버에 애플리케이션이 2개가 동작하고 있다고 가정했을 때, 이를 구분할 방법이 없습니다.

2. TCP(Transmission Control Portocol)

IP의 한계를 극복하기 위해 트렌스포트(전송) 계층의 TCP를 사용하게 됐습니다. 우선 TCP/IP의 계층 구조는 다음과 같습니다.

TCP/IP 모델은 다음과 같이 데이터를 전송하게 됩니다.

TCP의 특징은 다음과 같습니다.

2-1. TCP 3-way handshake

TCP는 데이터 전송을 시작하기 전 다음 과정을 통해 두 시스템이 연결이 잘 됐는지 확인하는 작업을 진행합니다.

조금 쉽게 설명하자면 다음과 같이 설명할 수 있을 것 같습니다.

1. SYN 전송: 아 혹시 지금 연결 가능할까요?(SYN)
   - 클라이언트가 서버에 연결을 요청하는 패킷을 보냅니다.
2. SYN + ACK  전송: 네 요청(SYN) 잘 받았구요. 지금 연결 가능합니다(ACK).
   - 서버가 요청을 잘 받았고, 연결 요청을 수락한다는 신호를 함께 보냅니다.
3. ACK 전송: 연결됐습니다. 감사합니다.(ACK)
   - 클라이언트가 서버의 응답을 받고, 연결이 잘 이루어졌다고 알려줍니다.

이 과정을 통해 연결 상태를 확인하고, 데이터를 주고받으며 전달이 잘 되었는지 확인하게 됩니다. 이를 통해 전달받은 데이터가 신뢰성을 갖게 됩니다.

2-2 TCP 순서 보장

데이터가 전달되는 과정에서 여러 패킷으로 쪼개 전달하게 됩니다. 이 때 패킷에 순서가 부여됨으로 전송 중 순서가 뒤바뀌더라도 걱정할 필요가 없습니다.

3. UDP(User Datagram Protocol)

UDP는 TCP는 달리 신뢰성을 보장할만한 기능들이 전혀 없습니다. 데이터 전송은 신뢰성이 바탕이 돼야 하는 것이 핵심입니다. 때문에 UDP는 제한적인 용도로 사용됩니다.

음성 데이터나 실시간 스트리밍과 같이 시간에 민감한 프로토콜이나 애플리케이션을 사용하는 경우, 사내 방송아니 증권 시세 데이터 전송에 사용되는 멀티캐스트처럼 단방향으로 다수의 단말과 통신해 응답을 받기 어려운 환경에서 주로 사용됩니다.

이와 같은 경우 데이터 신뢰도 보다는 신속성에 민감한 경우입니다. 실시간 스트리밍을 예시로 들면 영상은 초당 30~120회의 정지된 사진이 빠르게 바뀌며 움직이는 듯한 영상처럼 보이는 원리를 이용합니다. 이때에는 패킷이 1~2개 소실된다고 하더라도 우리가 시청하는 데는 큰 영향이 없습니다.

하지만 이 수많은 패킷을 하나하나 확인하고 다듬게 되면 버퍼링이 걸리거나 멈칫 거리는 증상이 생길 것입니다. 사람들이 서비스를 평가할 때는 패킷이 1~2개 소실되는 것보다 버퍼링 걸리는 것을 더 안좋은 시선으로 보기 때문에 UDP를 사용하고 있습니다.