원래 혼자 공부했던 내용들로 커리큘럼을 짜서 포스팅을 진행할 계획이었으나, 진짜 너무 바빠서 포스팅을 엄두도 못 내고 있던 찰나..어차피 학교에서 네트워크 수업을 들으니 시험 공부 겸 정리해두면 될 것 같아 쓰게 되었다.
처음 예상했던 것과는 달리 순서가 좀 엉망진창이 될 수도 있지만 어쩔 수 없지 뭐.
목차 1. Basic Concept 1) What is Internet? 2) What is Protocol? 3) TCP/IP Protocol Model (Stack or Suite) 2. A Closer Look at Network Structure 1) Network Edge 2) Network Core 3) Circuit Switching VS Packet Switching 3. Packet Delay
Internet은 "Inter + Network"의 합성어로써 전 세계의 통신 장비를 연결한 Network의 Network라고 보면 되는데, 이게 처음에 무슨 소린가 싶을 것이다.
예를 하나 들어 보자.
내가 우리 학교의 어떤 동아리에 가입해서 인적 네트워크를 쌓겠다고 말할 때, 그게 전 세계의 사람들과 친분을 쌓는다는 의미가 아님을 알 수 있다.
'우리 학교' 내의 수 많은 동아리 중 '내가 가입한 동아리'의 사람들과의 커넥션을 맺고 네트워크를 형성했을 뿐이다.
그런데 다른 학교의 비슷한 활동을 하는 동아리 사람들과 교류를 하고 싶다면 어떻게 해야 할까?
우리 학교 내의 다른 동아리(네트워크)라면 교류하는 것이 그리 어렵지 않지만, 다른 학교 동아리 부원이라면 이야기가 조금 달라진다.
가장 효율적인 방법은 동아리 대표끼리 서로 만나서 커넥션을 이은 다음에, 타학교에 관심있는 부원에게 연락을 취할 수 있게끔 중간에서 조율해주는 것일 것이다.
그리고 또 다른 학교의 동아리와 커넥션이 맺어져 있다면, 그 또 다른 학교의 대표가 또 다른 학교의 대표들과 커넥션만 이어져 있다면 비슷한 원리로 모든 동아리와 연락이 가능하게 된다.
그리고 연락이 가능하려면 동아리 부원 별로 고유한 정보들을 가지고 있어야 한다.
예를 들어, (대면으로 만나는 경우가 아닌 상황에서) 전화번호나 이메일 주소 등이 있어야 지속적으로 대화가 가능하다는 의미다.
이것이 바로 '네트워크'와 '네트워크'를 연결하는 인터넷의 기본 베이스이다.
원래 인터넷은 핵전쟁이 일어나도 통신이 가능하도록 설계하는 것이 목적이었다고 한다.
이 말은 즉, 인터넷은 중앙 관리 체계가 아니라 전 세계의 네트워크들의 연대로 형성된 기술임을 명시한다.
수많은 네트워크의 장치들이 대화를 하려면 위에서 언급했 듯이 '전화번호' 같은 고유 주소들이 있어야 하는데, 이 역할을 'IP 주소'로 판단할 수 있다.
즉, 인터넷이란 IP Protocol을 기반으로 하는 범 지구적 네트워크 통신이다.
컴퓨터 네트워크의 구성요소는 다음과 같다.
HW
Hosts (== end systems) : 네트워크 통신의 최종 목적지 (ex. 사용자 PC, 서버)
Communication links : 실제 전기 신호 등을 보내 네트워크 통신이 가능하게 해주는 장치들 (ex. Fiber, copper, radio, satellite)
Inter connection devices : 전기 신호들을 올바른 목적지로 보내주도록 돕는 중간 관리자들 (ex. Router, Switch, Repeater)
SW
Operating software : 네트워크 연결이 가능하도록 돕는 OS(Operating System)등
Application programs : 네트워크 연결 후에 어떠한 동작을 할 지 명시하는 프로그램들 (ex. 웹 서버)
Protocols : 통신 규약 (네트워크 기기간 대화하기 위한 약속)
📌 What is Protocol?
Protocol을 쉽게 말해서 "통신 규약"인데, 네트워크를 공부하면 툭하면 나오는 용어다.
한국인이 프랑스 사람과 대화를 해야하는 상황에서, 서로 자기네 나라의 언어를 사용해서 대화를 한다면 정상적으로 의사 전달이 될 리가 만무하다.
사회적 약속이 없으면, 똑같은 한국말을 사용한다 하더라도 "오늘 기분 어때?"라는 질문에 "안녕"이라는 답변이 돌아오는 어처구니 없는 상황도 발생할 수 있다. (실상황에서 이런 상황이 발생하지 않는 것은 사회적으로 학습된 결과이기 때문이다.)
네트워크 기기란 결국 하드웨어의 집합이기 때문에 제조사 별로 다른 통신 방법을 사용한다면 전 세계의 모든 기기가 연결된다 하더라도 정상적인 대화가 성립할 수가 없다.
심지어 기기 내부의 OS가 Window, MacOS 등에 따라서 또 해석 방식이 다르다면 문제는 더 심각해질 수 있다.
따라서, "하나의 약속을 정해서 이 방식대로 대화하자"고 정한 것이 Protocol이다.
Protocol은 단순히 Client PC와 Server가 대화하는 약속 뿐만 아니라, Router와 Router 간의 약속까지 정말 수도 없이 사방에서 튀어나오는데 하나만 기억하면 된다.
"얘네 서로 딴 소리 안 하려고 이런 약속들을 정해놓은 거구나?"
프로토콜은 아래의 내용들을 정의한다.
Message format
Order of meesages sent and received among network entities
Actions taken on message transmission, receipt
📌 TCP/IP Protocol Model (Stack or Suite)
좀 더 정확한 TCP/IP Protocol Stack
TCP/IP Protocol Stack이란 건 "IP Protocol을 기반으로 하는 TCP 통신을 하기 위한 약속"이라고 이해하면 된다.
Internet Protocol Stack에서 TCP/IP를 사용해서 통신하겠다는 것을 명시한 것인데, 이 말은 TCP 말고도 다른 통신 방법인 UDP도 있다는 말이다.
둘의 차이는 분명히 존재하긴 하나, 요새는 케이블이 워낙 성능들이 좋아서 거의 다 TCP 통신을 사용하는 추세라고 한다.
(TCP 통신은 정확도 우선, UDP 통신은 속도 우선이라고 보면 된다.)
Protocol Stack에 대한 내용은 이전 포스팅에서 남겼기 때문에 자세한 내용은 생략한다.
2. A Closer Look at Network Structure
네트워크 구조를 좀 더 자세히 살펴보면 3가지 주요 요소들이 있다.
통신의 최종 목적지가 되어야 할 장치들과, 통신을 가능하게 해주는 중간 관리자들, 그리고 눈에는 보이지 않지만 이런 통신이 가능하도록 도와주는 수많은 약속과 SW들이 있을 것이다.
📌 Network Edge
자료 구조에서 트리의 마지막 노드들을 Edge라고 칭하듯이, 여기서도 최종 목적지들을 Network Edge라고 부른다. (어차피 네이밍 한 사람들이 죄다 공학도들이라 네이밍 센스가 거기서 거기다.)
End system(host)라고 부르는데, 가장 처음에 예시를 들었던 다른 동아리 사람과 커넥션을 맺고 싶은 '나'와 '상대'가 여기에 속한다. (그 커넥션을 이어주도록 도와주는 수많은 장치와 시스템들이 사이에 숨어있다.)
네트워크에서 host라는 건 요청을 보낸 PC가 아니라 '실행 중인 application programs'를 말하는데, 종종 그냥 PC 자체를 말하기도 한다.
Client란 보통 먼저 요청을 보내는 쪽을 말하고, Server는 요청에 대한 적절한 응답을 보내주는 end system을 말한다.
(서버가 클라이언트한테 데이터를 먼저 요청하지는 않으니까 상식이다.)
이러한 모델을 Client/Server model이라고 하며, 서버는 요청에 대한 적절한 응답을 돌려주기 위해 언제나 실행중이어야 한다.
✒️ Internet Services Models
위에서 언급한 TCP와 UDP의 차이점에 대한 이야기다. 둘의 특성을 분류하는 기준은 "친구한테 우편 보낼 때, 일반으로 보낼래 등기로 보낼래?" 이 차이다. 즉, 상대가 받았는지 확인을 지속적으로 할지(TCP), 아니면 굳이 확인하지 않고 답장 올 때까지 계속 보낼지(UDP)라고 간략하게 정의할 수 있다.
• TCP: Connection-oriented service ∘ TCP는 Packet의 흐름을 트랙킹함으로써 정확성을 보장한다. ∘ ACK로 Packet의 손실이 판단되면 재전송한다. ∘ Fragmentation된 다수의 Packet의 순서를 보장한다. ∘ Flow control: window field 정보를 이용해 Buffer control을 함으로써, 송신자는 수신자가 한 번에 받을 수 있는 데이터 양을 초과해서 보내지 않을 수 있다. ∘ Congestion control: 송신자는 네트워크가 혼잡하다고 판단되면, 송신 속도를 낮춘다. • UDP: Connectionless service ∘ 정확도 따윈 신경쓰지 않는다. 일단 일정 주기로 계속 데이터를 수신자에게 보낸다. ∘ 상대가 데이터를 돌려주었다면 데이터가 정상적으로 도착했다고 판단한다. (기적의 논리) ∘ No flow control, No congestion control ∘ IP 주소를 얻기 위해 DNS 서버를 뒤지거나, 속도가 중요한 영상 송·수신의 경우에 자주 사용한다. ∘ 다만, 최근에는 하드웨어가 다 커버해줘서 대부분 TCP 통신을 써버린다고 한다.
📌 Network Core
Host부터 가장 가까운 Router까지를 one-hop이라 하고, 이 라우터를 gateway-router라고 한다. (다른 네트워크와 대화하기 위한 출입구 정도로 보면 되는데, 처음의 예시에서 동아리 대표가 이 역할을 해주는 것이다.)
Router의 역할은 단순하다. 생성된 시점부터 소멸할 때까지 데이터를 전달하는 역할을 한다. 물론 이 과정에서 올바른 목적지로 최적의 경로를 판단하여 데이터를 보내는 기능또한 담겨져 있다. (사실 더 많다.)
Net을 통해 데이터가 전송되는 2가지 방법이 있는데 현재는 사용되지 않는 Circuit switching과 Packet switching이 있다.
✒️ Circuit Switching
경로 상의 리소스가 예악되어, 온전히 '나를 위한' 전용 소스가 존재하는 방식이다. 라우터 간에 데이터를 송수신할 때, FDMA로 band-width를 분리하여 하나의 경로를 사용자에게 제공하는 방식이다. 전송을 위한 사전 작업인 Call setup이 필요한데, 이 용어는 아직도 Call processing이란 용어로 사용되고 있다.
pros: 이 경로는 공유되지 않고, 온전히 나만을 위한 자원이기 때문에 성능이 보장되고, 전송 시간이 지연되지 않는다는 장점이 있다. cons: 사용자가 증가할 수록 하나의 사용자가 이용가능한 band-width는 줄어들고 속도도 감소한다.
아주 옛날에 쓰였던 기술이라고 하는데, 이론 자체만 들으면 굉장히 솔깃하다. 하지만 현재는 몇 십 억 대의 기기를 감당해야 하므로 이런 접근 방식은 상당히 위험하다.
👨 교수님: 이런 게 있었다고 설명은 할 건데, 더이상 뒤에서 언급 안 할 겁니다~
✒️ Packet Switching
전용 도로라는 개념이 없어지고, 해당 네트워크를 이용하는 사용자들이 자원을 공유한다. 이 과정에서 한정된 자원을 얻기 위해 자원 투쟁(Resource contention)을 하기도 하는데, 수강신청이나 티켓팅을 위해서 허용 가능한 트래픽을 초과하는 경우 발생할 수 있다. (여기서 buffer overflow로 인한 패킷 손실 발생할 수 있음.) 여튼 링크로 나가기 위해 경쟁하는 패킷들을 Buffer에 저장해두고(Packet Switching는 버퍼가 필수다. store&forward), 다음 라우터로 통계적 다중화로 패킷을 전송한다.
pros: 간단하고 Statistical Multiplexing 기술 적용 가능, No call setup cons: 전송 속도 예측이 불가능하다.
✒️ Statistical Multiplexing(통계적 다중화)
시분할(TDM) 방법의 일종으로 고정적으로 자원을 분할하지 않고, 요구에 따른 분할을 함으로써 자원 공유 효율성을 증가시킨다. 시간을 나누는 건 같은데, 비동기식 다중화란 차이점이 있다. 비동기식이 효율적인 이유는 네트워크 통신이 bursty pattern을 가지기 때문이다. Packet Switching은 무조건 통계적 다중화 방식으로 전송할 필요는 없으나(가장 효율적이라 보통 이거 쓴다), 통계적 다중화 방식을 사용하려면 반드시 Packet Switching이어야 한다. 자세히 알 필요는 없으니, 쉽게 설명하면 여러 노드로부터 받은 패킷이 링크에서 섞이면서 전달된다.
📌 Circute Switching VS Packet Switching
한 가지 의문이 들 수 있다.
패킷 스위칭은 서킷 스위칭에 비해 명확한 장점이 존재하질 않는데 왜 사용하는 걸까?
사실 이건 아주 현실적인 이유 때문이다.
Router가 link로 보낼 수 있는 허용 트래픽이 최대 1 Mbps이고, N명의 유저가 100kb/s의 패킷을 송신하고 있는 상황을 가정해보자.
서킷 스위칭은 '반드시' 1Mbps를 10개의 대역폭으로 분리하여 유저별로 전용 도로를 보장해주어야만 한다. 따라서, 한 번에 패킷을 처리할 수 있는 것은 N <= 10인 경우가 된다.
하지만 패킷 스위칭은 Resource를 따로 할당해놓지 않으므로 무한대의 수용성을 가진다고 볼 수 있다.
실제로 테스트 결과 N=35인 경우에도, N=10인 경우보다 예외적인 상황이 발생하는 경우가 0.0004%에 불과하다.
왜 이런 일이 발생할까?
Bursty Pattern
현실적으로 한 명의 사용자가 발생시키는 트래픽은 fix되어 있지 않다.
웹 페이지나 앱 스크린을 쉬지 않고 넘기는 사람은 없듯이, 보통은 한 번의 데이터를 요청하고 그 다음 데이터를 요청하는 데 있어서 인터벌이 존재한다. 그리고 그 인터벌은 또 사용자마다 모두 다르다는 특성이 있다.
그렇다면, 굳이 band-width를 분리하기 보다 넓은 band-width를 제공해서 빠르게 처리하는 것이 낫다는 말이 된다.
물론, 티켓팅처럼 트래픽이 몰리면 불리한 예외가 존재하나, 전체적으로 합리적인 판단이다.
다만, 그렇다고 해서 트래픽이 몰렸을 경우를 무시할 수는 없다.
이 경우 패킷 송수신이 지연되거나 손실될 수도 있는데, 이걸 어떻게 처리해주어야 할까?
3. Packet delay
한 가지 스포할 것이 있는데 패킷 지연은 라우터가 커버하더라도, 손실은 신경쓰지 않는다.
라우터가 아무리 할 일이 데이터 전송 뿐이라고는 하지만, 그 일만 하더라도 굉장히 바쁜 애들이라 패킷 손실까지 고려하고 있으면 오히려 비효율적이지 않겠는가.
이걸 해결하는 방법으로 Host끼리 TCP 통신을 하는 이유가 되고, 비록 지금 적을 내용은 아니지만 언급은 해두어야 할 거 같아서 써놨다. (대충 도착해야 할 시간 내에 응답 패킷이 안 오거나, 에러 패킷이 오면 중간에 일이 잘못 돌아가고 있다고 인지한다.)
Packet switching은 buffer가 핵심이다.
들어온 Packet을 buffer에 적재해두고 FIFO 혹은 다른 방식으로 처리해도 무관하다.
위에서 언급했듯이 패킷 손실은 Router의 허용 가능한 메모리를 초과하는 패킷이 들어올 때 발생한다. (Router가 책임지지 않는 사안)
우리가 집중해야 할 것은 delay만 알아보면 된다.
delay의 종류는 크게 4가지라고 보면 된다.
Nodal processing delay
Nodal == Router Node
bit error를 체크하고, output link를 결정하는데 지연되는 시간
개선방법: 라우터의 성능을 높이면 된다. (당신의 지갑. 충분하신가요?)
Queueing delay
output link로 전송하기까지 대기하는 시간
packet loss의 95% 원인이 할당해줄 메모리가 없을 때 생기는 QueueOverFlow에서 발생한다.
수많은 사용자(end-system)들이 만들어 내며, 언제·어디로 보낼지 예측이 불가능하여 변수가 너무 많다. 개선할 수는 있으나, 상당히 어렵다.
Transmission delay
어떤 식으로 신호를 변환할 것인지는 이미 결정되어 있다. IP에 따라 패킷의 크기가 고정되어 있기 때문에 값이 크게 달라지지 않는다.
time to send bits into link = L/R
R = link bandwidth (bps)
L = packet length (bits)
개선방법: link bandwidth를 넓히면 된다. (속도가 느려? 돈이 부족한 게 아닐까?)
