분산 환경의 처리는 일반적인 환경의 구성과 많이 다르며 분산시스템의 특이성에 대한 개념들이 있다.

특히나 자주 듣게 되는 단어 중 하나는 결과적 일관성(Eventual Consistency) 라는 개념으로, 분산 시스템(Distributed System) 을 운영하게 되면 흔치않게 접하게 된다.

이는 개념과 관련된 이론이 그만큼 중요한 내용임을 반증한다.

 

먼저 예로 들은 Eventual Consistency 에 대해 설명하자면 이는 분산 컴퓨팅(Distributed Computing) 에서 고가용성(High Availability)을 보장하기 위한 방법의 하나로

"주어진 데이터에 대한 변경이 없다면 해당 Element 에 대한 모든 Access 는 가장 최근에 변경된 내용을 가리킨다" 는 정의를 말한다.

분산 시스템에서 데이터를 조회할 때 모든 시스템이 동일한 데이터를 가질 수 있다고 보장할 수는 없으며 결과적 일관성은 어느 시점에는 데이터가 다를 수 있지만, 결국에는 모든 시스템이 최신의 데이터를 가질 수 있도록 보장된다는 내용이다.

 

분산 환경에서는 데이터에 대해 단지 "시간" 뿐 아니라 "공간(다른 시스템)" 도 고려의 대상이 된다.

 

이는 BASE 원칙의 일종으로 분류되기도 한다. BASE 원칙이란 다음의 원칙들이 포함된다.

- Basically Available : 일반적인 Read / Write 에 대한 동작이 "가능한만큼" 지원된다.

(여기서 가능한만큼 이라 함은, 동작이 가능하나 Consistency 에 대한 보장이 되지않는다는 점이다.)

- Soft state : Consistency 가 보장되지 않기 때문에 상태(State) 에 대해 Solid 하게 정의하지 못하다.

- Eventually consistent : 위에 언급된 Eventual Consistency 개념에 따라 충분한 시간이 흐르면 모든 시스템 환경 내에서 데이터는 최신의 데이터가 보장된다.

 

BASE 원칙은 전통의 트랜잭션 시스템을 위한 ACID 원칙에 반대된다. 이는 분산 환경에서 나타나는 특징이기 때문이다.

이러한 특징에 대해 CAP Theorem 은 다음 3가지 조건을 모두 만족하는 분산 시스템을 만드는 것이 불가능함을 정의한다.

 

- 일관성(Consistency) : 모든 시스템의 데이터는 어떤 순간에 항상 같은 데이터를 갖는다.

- 가용성(Availability) : 분산 시스템에 대한 모든 요청은 내용 혹은 성공/실패에 상관없이 응답을 반환할 수 있다.

- 내구성(Partition Tolerance) : 네트워크 장애 등 여러 상황에서도 시스템은 동작할 수 있다.

 

분산환경 특징 상 3가지 성질을 모두 만족할 수는 없고, 일반적으로 다음과 같이 선택된다.

 

- CP (Consistency & Partition Tolerance) : 어떤 상황에서도 안정적으로 시스템은 운영되지만 Consistency 가 보장되지 않는다면 Error 를 반환한다. (어떤 경우에도 데이터가 달라져서는 안된다.)

이는 매 순간 Read / Write 에 따른 정합성이 일치할 필요가 있는 경우 적합한 형태이다.

 

- AP (Availability & Partition Tolerance) : 어떤 상황에서도 안정적으로 시스템은 운영된다. 또한 데이터와 상관없이 안정적인 응답을 받을 수 있다. 다만 데이터의 정합성에 대한 보장은 불가능하다. (특정 시점에 Write 동기화 여부에 따라 데이터가 달라질 수 있다.)

이는 결과적으로는 일관성이 보장된다는 Eventual Consistency 를 보장할 수 있는 시스템에 알맞는 형태이다.

 

 

서버시스템 및 분산시스템에 있어서 핵심적인 개념이므로 잘 정리해두고 아키텍처를 고려할 때 항상 생각해두자

Context Switching 은 면접에서 지원자의 기본기를 검사할 목적으로 단골로 등장하는 질문이자, CS의 중요한 기본 지식이기도 하다.

 

Context Switching 이란 CPU가 한 개의 Task(Process / Thread) 를 실행하고 있는 상태에서 Interrupt 요청에 의해 다른 Task 로 실행이 전환되는 과정에서 기존의 Task 상태 및 Register 값들에 대한 정보 (Context)를 저장하고 새로운 Task 의 Context 정보로 교체하는 작업을 말한다.

 

여기서 Context란, CPU 가 다루는 Task(Procee / Thread) 에 대한 정보로 대부분의 정보는 Register 에 저장되며 PCB(Process Control Block) 으로 관리된다.

 

여기서 Process 와 Thread 를 처리하는 ContextSwitching 은 조금 다른데, PCB는 OS에 의해 스케줄링되는 Process Control Block이고, Thread 의 경우 Process 내의 TCB(Task Control Block) 라는 내부 구조를 통해 관리된다.

 

Task 의 PCB 정보는 Process Stack, Ready Queue 라는 자료구조로 관리가 되며, Context Switching 시 PCB 의 정보를 바탕으로 이전에 수행하던 작업 혹은 신규 작업의 수행이 가능하게 된다.

 

PCB는 주로 다음과 같은 정보들을 저장하게 된다.

 

(1) Process State : 프로세스 상태

(2) Program Counter : 다음에 실행할 명령어 Address

(3) Register : 프로세스 레지스터 정보

(4) Process number : 프로세스 번호

 

Context Switching 시, Context Switching 을 수행하는 CPU 는 Cache 를 초기화하고 Memory Mapping 을 초기화하는 작업을 거치는 등 아무 작업도 하지 못하므로 잦은 Context Switching 은 성능 저하를 가져온다. 

 

일반적으로 멀티 프로세스를 통해 PCB를 Context Switching 하는 것보다 멀티 쓰레드를 통해 TCB 를 Context Switching 하는 비용이 더 적다고 알려져있다.

 

주로 Context Switching 은 Interrupt 에 의해 발생되는데, Hardware 를 통한 I/O 요청이나, OS / Driver 레벨의 Timer 기반 Scheduling 에 의해 발생한다.

 

 

더 자세한 참조 링크 : 

https://stackoverflow.com/questions/7439608/steps-in-context-switching/7443719

 

Steps in Context Switching

I am asked to describe the steps involved in a context switch (1) between two different processes and (2) between two different threads in the same process. During a context switch, the kernel wil...

stackoverflow.com

https://nesoy.github.io/articles/2018-11/Context-Switching

 

Context Switching이란?

 

nesoy.github.io

 



컴퓨터는 CPU에서 tick 을 발생시키며 1970년 1월 1일부터 발생된 tick 의 수를 계산해서 시간을 측정한다.


이 시작점을 UNIX 계열에서는 POSIX time 혹은 Epoch time 이라 하며, 1970년 1월 1일 00:00:00 UTC 이고, 


이때부터 경과 시간을 초로 환산해서 사용한다.


이런 방식에는 몇가지 문제가 있는데, 먼저 윤초(예를 들어 1998년 12월 31일 23:59:60)는 표현할 수 없이 무시된다.


현재 32비트 운영체제에서 초 시간을 지정하는 time_t 자료형은 32비트 Integer 이기 때문에, 


2038년이 되면 overflow 문제가 발생한다.


이를 2038 Years Problem 이라 하며 2038년 1월 19일 03:14:07 UTC 가 되면 오버플로우가 발생해서 


32비트 유닉스 시스템의 시간은 음수가 되어버린다.


그렇기 때문에 현재 int32 를 int64 로 바꾸는 노력을 계속하고 있고, 지속적으로 수정이 진행되고 있다.





예전에 네트워크 수업 시간에 배운 내용 정리 겸, 가끔 인터넷에 잘못 알려진 내용들이 있어서 다시 복습정리해보았다.


TCP 의 통신 방식은 흔히 알고 있는 3-Way Handshake 방식이다.

즉, 요청을 위한 ACK, 응답을 위한 SYN+ACK, 응답에 대한 응답을 위한 ACK 패킷이 그것이다.


원칙적으로는 전송되는 모든 패킷에 대해 TCP는 3-Way Handshake 를 고안하게 되어있다.


여기서 TCP의 특징은 TCP는 신뢰성을 위해 어느정도의 비효율을 감소한다는 점이다.

가령, "Hello World" 라는 메시지를 전송해야한다고 가정하자.


이 때, 만약 어플리케이션이 몇가지 이슈로 인해 H, e, l, l, o, , W, o, r, l, d 와 같이 메시지를 끊어서 보내야한다고 할 때, 이는 TCP 통신에 있어서 커다란 비효율이 된다.

TCP 스러운 통신을 위해 모든 통신은 3-Way handshake 를 거쳐야 하며 그를 통해 신뢰성을 검증하게 된다.


이 상황은 상당히 빈번하게 발생할 수 있는데, 가령 통신 이슈가 생기거나 Host 간의 Window 크기에 있어서도 영향을 받는다.

(자세한 건 다음 내용을 참고하자.)

(http://jins-dev.tistory.com/entry/%ED%95%9C-%EB%88%88%EC%97%90-%EC%A0%95%EB%A6%AC%ED%95%98%EB%8A%94-TCP%EC%99%80-UDP-%EC%A0%95%EB%A6%AC-%EB%82%B4%EC%9A%A9?category=760148)


이 때 발생하는 주요 문제점은 단순한 메시지의 전달에 대해서도 네트워크 비용이 막대하게 발생한다는 점이다.


메시지 하나하나의 처리량과 반응속도는 높아질 지언정 전체 "Hello World" 메시지를 통신하기 위해서는 글자수만큼의 네트워크 비용을 소모한다.


더군다나 매 통신 시, 컴퓨터는 메시지에 별도의 헤더 등과 같은 추가 정보들을 추가하며 이는 동일한 정보더라도 한 패킷의 사이즈가 커지는 결과를 만들어낸다.

즉, 하나의 메시지 H 를 보내는데 메시지보다 헤더의 데이터가 더 큰 비효율이 발생할 수 있는 것이다.


Nagle's Document 에 따라 이러한 문제는 Small Packet Problem 으로 정의되며 Nagle 알고리즘은 이 문제를 해결하는 방법을 제시한다.


Nagle Algorithm 은 송신에 있어서 버퍼를 둔 뒤 상대방 Host 의 Window 사이즈를 고려한 후, 어느정도 길이만큼의 패킷을 한번에 전송하는 기술이다.

다음은 위키에서 발췌한 Nagle Algorithm 의 수도코드이다.


<출처 : https://en.wikipedia.org/wiki/Nagle%27s_algorithm>



당연히 이렇게 하면 통신 횟수가 적어져서 네트워크 비용은 절감되게 된다. 대신 패킷 하나당 처리량이 늘어나므로 반응속도는 조금 느려질 수 있다.

가령 Health Check ping 을 날리는 경우나, signal 을 전송하는 경우에는 오히려 Nagle Algorithm 을 적용하지 않음으로써 반응속도의 효율을 좋게 만들 수 있다.



잘 모르는 사람에게 설명할 일이 생긴 김에... 인터넷의 동작에 대한 기본 설명을 간략하게 정리해보았다.


인터넷은 Interconnected Network of computers 에서 파생된 단어로, 각 컴퓨터 간의 네트워크 연결이 인터넷의 출발점이 된다.


원격에 있는 컴퓨터에 접속하기 위하여 각 단말은 IP Address 라는 고유 주소를 가지며, IP Address 를 찾아가는 것이 곧 다른 컴퓨터로의 접속으로 이어진다.


참고로 인터넷은 단순히 IP Address 를 직접 사용하지 않고, 사용자가 읽을 수 있는 형태의 Domain Name 이라는 것을 사용한다.

DNS 주소를 통해 머신은 IP 주소를 직접찾는 것이 아니라 도메인 네임 서버에서 받아와서 해당 서버가 중계해주는 IP Address 를 전달받는 방식이다.


IP Address 를 찾아가는 방식은 단순하게 각 네트워크 주소를 방문하면서 해당 네트워크에 해당 주소가 있는지를 탐색하는 방식으로 시작된다.


여기서 네트워크라는 건, 작게는 LAN(Local Area Network), 크게는 WAN(Wide Area Network) 혹은 그 이상의 크기로 전산망을 연결한 것을 말한다.


모든 컴퓨터들은 다른 모든 컴퓨터들과 직접적으로 연결되어 있지 않으며, 계층적으로 망 내에 속하고, 이렇게 구성된 작은 망들이 서로 연결되어 인터넷망을 구성한다.


이때 출발지에서 목적지까지 이어지는 네트워크의 각 단계를 홉이라하며 홉들을 거치면서 거대한 인터넷 망에서도 올바르게 주소를 찾을 수 있게 된다.


각 라우터에서는 브로드캐스트가 일어나며, 내부망을 구성하는 머신들에게 출발지점에서부터 전달된 메시지가 뿌려진다. 이 메시지는 각 머신들에 연결되어 OSI 7계층을 통하는데, 목적지의 주소가 아니라면 중간에 필터링되게 된다. 


목적지에서는 마침내 통신이 이루어지고, 응답메시지가 다시 홉을 타고 출발지로 다시 전송되게 된다.




OSI 7 계층은 컴퓨터 네트워크를 이해하는 데 있어서 빼놓을 수 없는 개념이다.

면접에서 기본기 확인 용도로 많이 물어보기도 하는 개념으로 너무나 기본적으로 알고 있어야 하는 내용이다.


OSI 7계층이란 인터넷을 위한 네트워크 연결 표준으로 응용, 표현, 세션, 전송, 네트워크, 데이터링크, 물리 계층의 7계층으로 나뉘어져있다. 데이터를 전송할때마다 각각의 층에서 인식할 수 있는 헤더를 붙이게 되는데 이를 캡슐화라고 한다.


컴퓨터에서 소켓을 통해 인터넷으로 데이터를 전송할 때, 컴퓨터들 사이에서 이를 이해할 수 있는 공통의 포맷을 만들어두었다고 이해하면 쉽다. 다음 그림을 참고하자.


왼쪽과 오른쪽에는 Pack 과 Unpack 이라는 두개의 화살표가 있다. OSI 의 각 계층을 어떤식으로 통과하는지를 이해하기 쉽게 표현한 그림이다.

이해를 돕자면, 메시지를 네트워크로 전송할 때에는 왼쪽의 화살표 방향대로 OSI 의 각 계층을 따라 내려가면서 헤더를 추가한다.


그리고, 네트워크로부터 메시지를 전송받을 시에는 OSI의 아랫쪽 계층부터 위로 올라오면서 차례대로 Header 를 분석해서 최종적인 Message 를 받는다.

추가 설명 이전에 각 계층에 대해 먼저 알아보자.


- 7계층은 응용 계층(Application Layer)으로 HTTP, DNS, FTP 등의 프로토콜이 사용되며 사용자가 네트워크에 접근할 수 있도록 해주는 계층이다. 서비스를 제공한다.


- 6계층은 표현 계층(Presentation Layer)으로 데이터를 정해진 표현 형태로 변환한다. 확장자나 인코딩 등이 포함된다.


- 5계층은 세션 계층(Session Layer)으로 포트 연결이라고도 할 수 있다. 상호간의 세션이 유효한지 확인하고 설정하며, SSH, TLS 등의 프로토콜이 포함된다. 포트 번호를 기반으로 통신 세션을 구성한다.


- 4계층은 전송 계층(Transport Layer)으로 엔드포인트 간 제어와 에러를 관리한다. 여기서 붙은 헤더를 세그먼트(TCP의 경우, UDP의 경우 Datagram이라 한다.)라 하며 TCP, UDP 등의 프로토콜이 포함된다. 세그먼트에 Port 정보가 포함된다. 이 계층의 장비로는 게이트웨이가 있다.


- 3계층은 네트워크 계층(Network Layer)으로 이곳에서 붙는 헤더를 패킷이라 한다. 노드 대 노드 간 연결을 위해 존재하며 대표적 프로토콜은 IP이다. 이 계층의 장비로는 라우터가 있다.


- 2계층은 데이터 링크 계층(Data Link Layer)으로 이곳에서 붙는 헤더를 프레임이라 한다. MAC 어드레스간 주소 접근을 담당한다. 이 계층의 장비에는 브릿지, 스위치가 있다.


- 1계층은 물리 계층(Physical Layer)으로 bit 흐름을 전송하기 위한 기능을 조정하며 이더넷 프로토콜이 여기에 해당된다. 이 계층의 장비는 허브 또는 리피터라 한다.



 주목해서 보면 좋은 계층은 2~4 계층이다. 이 부분이 디바이스로 직접 연결을 담당하는 계층들이다.

IP, MAC Address, Port 정보가 모두 포함되기 때문에 방대한 인터넷 연결에 있어서 실제 상대방의 주소를 찾기 위한 헤더 정보는 전부 이 계층에 포함된다. 

바꿔말하면 들어온 패킷의 해당 정보들이 디바이스와 맞지 않다면 해당 계층에서 걸러진다. 좀 더 응용해보자면, 통신을 중계하기 위해서는 해당 계층들의 역할을 수행할 수 있는 장비가 필요하다.


그 위의 계층은 잘 알려진 TCP/SSH/HTTP 등의 프로토콜을 기술하고 맨 윗 계층에서 사용자는 실제 Application 을 통해 메시지를 받을 수 있다.





TCP/IP 전송제어 프로토콜은 신뢰성에 초점을 맞추고 데이터가 신뢰성있게 올바른 순서로 유실되지 않게 빨리 전송할 수 있도록 설계된 프로토콜이다.


TCP 의 기본적인 작동 원리는 다음과 같다.

<TCP hand shake >

<출처 : https://wiki.mikrotik.com/wiki/Manual:Connection_oriented_communication_(TCP/IP)>


TCP 는 통신을 위해 3 way handshake 란 방식을 이용한다. 먼저 통신이 가능한지 SYN 을 보내고, 통신이 가능하다는 SYN-ACK을 받는다. 이 과정에서 문제가 없으면 이제 통신하고자 하는 메시지를 보내고, 양방향 통신이 된다. 이 과정을 3-WAY Handshake 라 하며, 이 과정은 TCP 매 통신 시마다 적용이 되며, 통신이 끝날때에는 SYN 대신 FIN 을 보내서 서로 확인을 받는다. 이러한 과정을 통해 TCP 는 무조건 메시지가 잘 전달되었으며 잘 도착했다는 확인을 받게 되고, 신뢰성을 보장받게 된다. 이러한 특성으로 TCP는 주로 전화에 비견된다. 이러한 TCP 통신을 위한 헤더는 다음과 같다.



위의 헤더 정보에는 보내는 메시지의 목적지 주소와, 순서 보장을 위한 일련 번호(Sequence Number), 에러 체크를 위한 Checksum 정보 등이 포함된다.

그 외에 사용하는 TCP 알고리즘 별로 슬라이딩 윈도우 정보 등 다양한 정보가 포함될 수 있다.


 슬라이딩 윈도우는 패킷의 흐름을 제어하기 위한 메모리 버퍼(Window) 로, 다양한 경우에 대비해서 사용된다. 가령 3WAY Handshaking 중 네트워크 장애 발생이나, 받은 메시지가 중간에 누락이 된 경우 해당 패킷의 재전송이 필요하다. 다음 패킷의 전송을 멈추고 이전 패킷의 전송을 기다리는 Stop And Wait 방식 보다, 훨씬 효율적일 수 있다.


<슬라이딩 윈도우 송신 측>


 위의 그림 처럼 슬라이딩 윈도우는 이미 전송하고 확인이 완성된 부분, 전송했지만 확인되지 않은 부분, 보내지 않았지만 수신자가 수신 준비 된부분, 수신준비 되지 않았으며 송신하지 않은 부분으로 영역을 나누어 네트워크 상황에 따라 포인터를 관리한다.


<슬라이딩 윈도우 수신 측>


 위의 그림은 수신측이다. 받았고 승인한 버퍼를 갖고 있으며 ( 이 버퍼는 나중에 다른 패킷으로 덮어써진다.) 수신자가 아직 받지 못한 부분, 수신준비되지 않았으며 수신하지 않은 부분으로 나뉘며 전송 상태에 따라 포인터를 조정한다.

(관련 내용의 예시를 잘 정리한 블로그는 다음을 참조하기 바란다. http://blog.naver.com/donjobani/30110435544)



 위의 내용들을 바탕으로 한 TCP 의 특징을 정리하자면 다음과 같다.


(1) Connection Oriented : 2개의 endpoint간 연결을 먼저 맺고 데이터 통신을 한다.


(2) Bidirectional byte stream : 양방향 Data stream(Byte stream)


(3) In-order delivery : 송신자가 보낸 순서대로 수신하며 Segment의 데이터 순서 표시를 위한 32비트의 정수를 사용한다.


(4) Reliability through ACK : 송신자는 수신자가 ACK 보내는 것을 체크하고 보내지 않은 데이터를 보관한다.


(5) Flow control : 송신측과 수신측의 처리 속도 차이를 해결하기 위해(특히 수신측이 느린 경우) 지원하는 제어 방식으로 흐름 제어라 불린다. 속도 차이로 전송 누수가 생기는 것을 방지하기 위해서 수신자는 받을 수 있는 버퍼의 크기(Receive window)를 송신자에 전달하여 송신자가 보내는 양을 제어하게 한다.


(6) Congestion control : 통신시 한 Router에 데이터가 몰려 혼잡할 경우, 호스트 들이 데이터 유실 때문에 재전송을 하게 되고 결국 혼잡이 더 늘어나는 악순환이 생긴다. 이를 막기 위해 송신측에서는 Congestion window가 존재하여 허용하는 만큼만 전송하게 하여 혼잡을 제어한다. TCP Vegas, BIC, CUBIC 등의 알고리즘을 사용한다.



 반면 UDP는 이러한 Hand shaking 과정이 없다. UDP 의 통신과정은 단순하다. 단순히 명시받은 IP 주소와 포트로 메시지를 UDP 헤더를 담은 메시지를 보낸다. UDP 헤더가 담긴 메시지를 받으면, 어플리케이션은 해당 메시지를 해독해서 로직을 처리한다. UDP 헤더는 다음과 같다. TCP 헤더보다 많이 단순한 모양이다.


 하지만 TCP 와 다르게 UDP 는 응답값을 기대하면 안된다. 신뢰성이 보장되지 않기 때문에, 중간에 네트워크 이슈로 인해 데이터가 손실되더라도 이를 알아차릴 방법이 없다. 그렇게 때문에 UDP 는 편지에 비유되며, 상대방 IP 주소의 포트에 메시지를 놓고온다고 이해하면 쉽다.


 정리하자면, TCP의 경우 좀 더 시간이 오래 걸리는 무거운 프로토콜이지만 신뢰성이 보장되며 UDP 의 경우 가볍지만 신뢰성을 보장할 수는 없다. 이런 특징 때문에 신뢰성이 중요한 메시지 들은 TCP로, 몇몇 패킷이 누락되어도 상관없는, 가령 이미지나 실시간 스트리밍 들은 UDP 로 구현이 된다.

 물론 몇몇 서비스의 경우에는 비즈니스 로직에 따라 UDP 로 구현하되, 헤더를 커스터마이즈하여 특정 조건에서 신뢰성을 갖으면서 가볍고 빠른 자체 프로토콜을 만들어 서비스 품질을 높이는 경우가 많다.






 DHCP란 Dynamic Host Configuration Protocol 의 약자로, 호스트의 동적 설정을 위한 프로토콜이다.


 장치들이 동적으로 적절한 IP주소들을 찾을 수 있도록 고안된 프로토콜로 2014년 기준 IPv4 네트워크의 표준이 되었다고 한다.


 TCP/IP 통신을 실행하기 위한 설정 정보의 할당을 관리하며 그를 위해 네트워크 관리자들이 IP 주소를 중앙에서 관리하고 할당할 수 있게 제공한다.


 OSI 상위 계층의 프로토콜들은 DHCP를 통해 결정지어진 IP 주소를 기반으로 인터넷을 이용하게 된다.



 인터넷에 접근 시 DHCP를 사용하지 않는 경우에는 컴퓨터마다 IP가 수작업으로 입력되어야 하며 다른 네트워크로 편입 시 IP 주소를 새로 받아야 한다. DHCP는 이를 자동으로 할당하게 끔 해준다.


(1)  DHCP Discover : 단말이 DHCP 서버를 찾기 위해 동일 Subnet 상에 브로드캐스트.


(2)  DHCP Offer : DHCP 서버가 단말로 단말에 할당할 IP, Gateway IP 등 네트워크 정보를 송신


(3)  DHCP Request : 단말이 DHCP 들 중 자신이 사용할 DHCP 서버를 선택하고 해당 서버에 자신이 사용할 네트워크 정보를 요청


(4)  DHCP ACK : 선택된 DHCP 서버가 단말로 네트워크 정보를 송신 -> 인터넷 가능

 

 

본 내용은 위키에도 잘 정리되어있으니, 좀 더 공부하고자 한다면 참고하면 좋다.

(https://ko.wikipedia.org/wiki/%EB%8F%99%EC%A0%81_%ED%98%B8%EC%8A%A4%ED%8A%B8_%EA%B5%AC%EC%84%B1_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C)






IP 주소를 이해하는데 있어 중요한 개념이 서브넷 마스크의 개념이다.



많이 알려져있듯이 서브넷 마스크는 커다란 네트워크를 다루기 위해 서브넷으로 네트워크들을 분리하고 나누어진 네트워크를 지정(designated) 하는 데 사용된다. 


서브넷 마스크는 서브넷을 분리하기위한 기준으로 클래스별로 어디까지가 네트워크 부분이고 어디까지가 호스트부분인가를 나타낸다. 


서브넷 마스크는 다음과 같은 형태를 띈다.


Class A: 255.0.0.0


Class B: 255.255.0.0


Class C: 255.255.255.0


클래스 A가 명시하는 바는, IP주소의 첫 8개 비트가 네트워크 영역을, 나머지 24 비트가 호스트 영역을 나타낸 다는 것을 의미한다. 


여기서 기존의 IP 주소와 자신이 갖고 있는 서브넷 마스크를 AND 연산 하면 네트워크 주소를 얻을 수 있다.


AND 연산이 갖는 의미는 자신이 가진 IP 주소의 1만큼의 부분, 즉 AND 연산으로 살아남는 부분들은 네트워크의 주소라는 일종의 Masking 이 된다. 


그리고 나머지 네트워크 주소가 아닌 호스트의 주소가 의미하는 바는 해당 서브넷에서 호스트로 할당할 수 있는 IP 주소의 범위가 된다. 


이 때 얻어진 네트워크 주소에서 Subnet Mask 의 0으로 된 비트를 모두 1로 바꾸어주면, 즉 마지막 주소가 브로드캐스트 주소가 된다.




가령 위와 같은 IP 주소가 Class C 의 서브넷 마스크를 가질 때, 위의 AND 연산의 결과로 다음과 같은 주소를 알아낼 수 있다.

(AND 연산은 연산하고자 하는 두 비트가 모두 1이면 1을, 그렇지 않으면 0을 반환한다.)


- 네트워크 주소 : 10.9.32.0

- 브로드캐스팅 주소 : 10.9.32.255

- Gateway 주소 : 10.9.32.1 (끝자리만 다른형태로 일반적으로 1)


이렇게 서브넷 마스크를 이용해서 서브넷을 나누는 것을 서브넷팅 이라 한다.

위의 변환은 일반적인 Class 의 서브넷팅을 설명한 내용이고 서브넷 마스크의 기본적인 동작을 나타낸다. 위와 같이 기본 Class C 로 나눈 경우에 해당 서브넷에 할당된 주소는 256개가 된다. 만약 나누어야하는 지역의 IP 가 이보다 훨씬 수가 적다면 이렇게 나누는 것은 낭비가 될 수 있으므로, 그럴 때는 서브넷 마스크를 변경하여 호스트 수를 조절하는 방법도 가능하다. 그리고 이를 bit를 빌려온다(borrowed)라고 표현한다. (ex) 255.255.255.128


(*서브넷팅에 대한 좀더 발전된 사례는 클라우드 쪽 포스팅에서 다룰 수 있을 듯 하다.)



위와 같은 원리로 분리된 서브넷 들을 연결한다면 다양한 네트워크를 연결하여 거대한 네트워크를 구성하기에 효율적이며 관리적 측면에서도 용이하다.


이렇게 분리된 네트워크가 갖는 장점은 보다 기능적인 브로드 캐스팅 도메인을 구성할 수 있고, 


좀 더 큰 의미에서 보자면 IP 주소의 절약 및 효율적인 사용에도 도움이 되기 때문이다. 


라우터를 중간에 둔 상태에서 여러 개의 간섭받지 않는 서브넷을 둔다면 큰 네트워크는 단지 대표 주소 들에 대한 서브넷을 관리하여 계층적인 구조를 이룰 수 있기 때문이다. (자세한 내용은 라우터를 다루면서 한번 더 정리한다.)



일반적인 서브넷은 IP 네트워크 주소를 지역적으로 나누기 때문에, IP가 바뀌더라도 LAN은 동일한 서브넷으로 묶인다. 





+ Recent posts