TCP/IP 4계층을 공부하며 정리하는 공간입니다.
잘못된 정보나 예시가 있다면 언제든지 말씀해주세요.
다들 들어봤을 법한 TCP와 UDP가 있다.
여기서 P에 주목해보자.
P는 Protocol(규약, 방식)이다.
규약과 방식이 뭘 의미하는 걸까?
예를 들어 한 커플 A, B가 통화로 대화를 한다고 생각해보자.
A, B의 통화 내용을 저녁 약속을 잡는 상황이라 생각해보자.
대화 내용은 어떨까? 전화 걸자마자 "저녁에 밥 같이 먹을래?"라고 말할까? 일상생활에서 통화로 중요한 내용을 전달할 때는 앞의 부가적인 요소가 붙는다.
A: 어 자기야 뭐해? 일 언제끝나?
B: 어 자기야 나 오늘 칼퇴 각~~
A: 오 그래? 일이 빨리 끝나서 다행이네~
B: 응 근데 왜 전화 했어?
A: 어 오늘 "저녁에 밥 같이 먹을래?"
B: 어 "좋아"
A: 그래 그럼 저녁에 보자
이런식으로 밥먹자는 말을 바로 물어보지 않고 안부를 먼저 묻고 시작한다.
즉, 정말 중요한 메세지를 주고 받기 위한 서로간의 준비동작이 필요하다.
여기서 또 중요한 점은 "서로 같은 언어"로 대화를 해야한다는 것이다.
결국에는 프로토콜의 합이 맞아야 통신이 가능해진다.
즉 프로토콜(Protocol)이 필요한 이유는, 서로 다른 객체들 간의 소통이 필요한데 어떤 방식으로 얘기할건지 미리 약속해야 하기 때문에 필요하다.
그럼 전체적인 네트워크가 어떻게 구성되어 있는지 살펴보자.
여기서 Core는 라우터로 이뤄져있다. 지금 라우터는 데이터를 보내주는 역할이라고만 알고있자.(자세하게는 와이파이 맥 프레임, 이더넷 맥 프레임)
데이터는 각 라우터에서 라우터로 전달되며 최종 목적지에 도달한다.
네트워크 코어는 회선 교환과 패킷 교환 방식으로 데이터를 전달한다.
대표적인 예로 전화망을 사용하는 옛날 음성전화가 있다.
이는 회선의 경로를 미리 지정한 크기만큼 확보하여 사용하게 만드는 방법이다.
즉, 서로간 1:1 연결을 하게 되어 이 연결에 어떤 누구도 침범할 수 없다. 그래서 데이터를 안전하게 보낼 수는 있다는 장점이 있다.
그렇다면 단점은 뭘까?
여러개의 단계를 거치는 과정에서 정해진 루트대로 움직이는 방식이다. 즉, 하나의 루트를 특정 유저가 독점하는 상황이 발생하기 때문에 딱 처음에 정한 수만큼만큼만 사용할 수 있어 네트워크를 효율적으로 사용하긴 힘들다.
FDM 방식과 TDM 방식이 있는데, 추후에 다시 알아보자.
이제 우리가 인터넷을 쓰는 상황을 생각해보자.
예를 들어 네이버 뉴스 채널의 기사를 읽는 상황이라면
네이버 홈페이지 접속 - 뉴스 채널 카테고리 클릭 - 보고싶은 뉴스 기사 클릭 - 기사를 읽음
기사를 읽는 동안 우리는 네트워크에 아무 요청도 하지 않기 때문에 Data를 사용하는 시간이 매우 짧다.
아까 회선 교환 방식을 적용한다면, 우리가 사용하는 동안 독점하고 있기 때문에 다른 유저가 사용하기엔 제약이 있다.
하지만 패킷 교환 방식을 사용하면 데이터를 사용하지 않는 시간에 다른 유저가 네트워크 통신을 할 수 있게 된다.
즉, 회선 교환 방식을 적용했을 때보다 유동적으로 더 많은 사람이 사용할 수 있다.
따라서 대부분 네트워크 통신은 패킷 교환 방식을 채용한다.
하지만 패킷 교환 방식을 적용한다고 해서 단점이 없는 건 아니다.
앞서 패킷 교환은 여러명이 사용할 수 있다고 했다.
하지만 여러명이 동시에 몰릴 경우는 어떨까?
패킷 교환을 사용하면 대표적으로 4가지 딜레이가 발생하는데 어떤게 있는지 살펴보자.
우선 전송할 데이터의 단위는 패킷이라는 게 있다는 걸 알아두자.
자, 데이터를 보낸다. 그럼 받는 쪽에선 어떻게 해야할까?
고속도로 톨게이트를 생각해보자.
자동차라는 패킷이 지나갈 때 톨게이트에선 해당 자동차가 어디서 왔는지 표를 검사해서 요금을 부과한다.
이처럼 패킷 교환을 할 때 받는 쪽에서는 패킷을 검사 해야한다.
검사를 하면? 당연히 딜레이가 발생하게 된다.
이를 Processing Delay라고 한다.
Processing Delay를 해결하려면 어떡할까?
검표를 빨리 진행해야한다.
그럼 검표소를 하이패스로 바꾸면 된다.
즉, 검사하는 라우터의 기능을 개선하면 된다.
만약 고속도로에 자동차가 많다면 어떻게 될까?
당연히 차가 막힌다.
왜 막힐까?
일반적인 상황을 생각해 보면, 고속도로에 들어오는 차량이 나가는 차량보다 더 많기 때문이다.(병목현상)
패킷 교환도 마찬가지다. 여러명의 사용자가 언제든 사용할 수 있지만, 사용자가 몰리게 되면 느려진다.
즉, 톨게이트라는 Outgoing Edge로 데이터를 뿜어내야 하는데, 들어오는 속도가 더 빠르기 때문에 차량 이동이 느려지게 된다.
패킷을 받는 라우터에선 임시 저장소 즉, 임시 Buffer(Queue)가 있다.
들어오는 속도가 나가는 속도보다 빨라서 처리하지 못할 경우 임시로 담아두는 공간이다.
근데 이 버퍼에 패킷을 저장하다가 버퍼 사이즈를 초과하게 되면 어떻게 될까?
이는 데이터 유실로 연결된다.
TCP는 신뢰성 전달이라고 알고 있을텐데, 어떻게 유실된 데이터를 보낸 그대로 전달하는지는 전송 계층 때 알아보자.
Queing Delay는 전체 패킷 유실(Packet Loss) 원인의 약 90% 정도를 차지할 정도로 골치아픈 문제다.
왜냐면 우리가 인터넷을 사용하는 만큼 몰리기 때문이다.
명절에 사람이 많이 몰려 고속도로가 정체되는 상황처럼, Queueing Delay는 인터넷을 사용하는 사람이 많을 수록 딜레이가 더 커지게 된다.
앞서 데이터가 많아지면 Queue에 쌓인다고 했다.
Queue에 쌓이고 가져올 때 당연히 딜레이가 발생한다.
패킷은 Bit로 구성되는데(그래서 패킷 전송 속도는 BPS, Bit Per Second다) 만약 1패킷이 1~100Bit로 구성된다면, 1~100Bit 모두 Queue에서 파이프로 나가는데 소요되는 시간을 Transmission Delay라고 한다.
그럼 이 딜레이를 해결하려면 어떻게 해야할까?
다시 자동차를 예로 들면, 1차선 도로에서 4차선 도로로 바꾸면 해결된다.
즉, 데이터가 지나가는 파이프의 Band Width를 넓히면 한 번에 더 많이 내보낼 수 있게 되어 딜레이가 감소하게 될 것이다.
A 도시 톨게이트에서 B 도시 톨게이트까지 도달하는데 걸리는 시간이다.
즉, 패킷의 마지막 비트가 다음 목적지(수신) 라우터까지 도달하는데 걸리는 시간이다.
데이터는 매체를 타고 이동하는데 여기서 매체는 전화선, 이더넷 선(UTP) 등 다양한 종류의 광케이블을 말한다.
또한 나중에 언급한 무선 네트워크(Wi-Fi, LTE 등)에는 Air라는 매체를 사용한다.
이는 거리와 관련된 딜레이로, 패킷의 사이즈와는 관련이 없다.
패킷은 빛의 속도로 이동하기 때문에 제어하기 힘들다.
단, 유선 통신의 경우 매체의 재질에 따라 속도가 달라지게 되는데 구리선(Cooper)이나 일반적으로 사용하는 UTP 선의 경우 빛의 속도의 67%정도다. 빛의 속도는 약 300만[m/s]니까, 약 200만[m/s]가 된다.
광케이블은 light를 사용하는데, 빛이기는 하지만 역시 Air나 진공상태에서의 빛의 속도에 비해 2/3정도다. 마찬가지로 속도는 약 200만[m/s]다.
Air를 매체로 사용하는 경우 공기중에서 전파되므로 속도는 빛의 속도와 같다.
자, Propagation Delay를 계산해보자. 관심 없는 독자는 뛰어넘어도 좋다.
현재 위치 - 구글 데이터 센터까지 위치가 약 5,000km 라고 가정하고, 광케이블로 연결되었다면 Propagaion Delay는?
현재 위치 - 구글 데이터 센터 Propagation Delay = 50,000,00m / 200,000,000(m/s) = 25,000us
즉, 25ms(미리세컨즈)가 걸린다.
만약 ping 테스트를 해본다면?
지금은 설명을 안했지만 RTT가 약 45~49 ms가 걸린다.
RTT(Round Trip Time)은 전송측에서 패킷의 마지막 Bit를 보내고 수신측으로부터 제대로 받았다는 피드백 신호(ACK)를 받는데 소요되는 시간이다.
즉, 패킷 왕복 시간이라고 이해하면 되겠다.
거리가 멀어지니 생각보다 큰 딜레이가 발생한다. ping test를 통해 나온 시간은 앞서 설명한 Processing Delay, Queueing Delay, Transmission Delay, Propagation Delay를 모두 합친 시간이다.
여기서 TTL, ICMP_SEQ는 나중에 따로 포스팅 하겠지만, 간단하게 설명하자면
TTL은 네트워크에 떠다니는 패킷이 영원히 살아있게 된다면 네트워크 오버헤드가 발생하므로(패킷의 무한루프 방지)
라우터를 한개씩 건너뛸 때마다 1씩 감소하여 0이 된다면 해당 패킷을 없애버린다(드랍).
ICMP Sequence는 Internet Control Message Protocol로
패킷이 라우터를 통해 지나간 뒤, 해당 Destination Port에 도달하지 못하는 경우(즉, 해당 포트가 닫혀 있는 경우 or TTL이 0이 되는 경우) 해당 패킷은 드랍되는데, 이 때 네트워크에서 일어나는 이벤트를 송신측(Source측)에게 보고해줄 필요가 있다.
이는 사용자 메세지가 아니라 컨트롤 메세지를 운반하기 위해서 사용하게 된다.
다음 시간부터는 애플리케이션 계층을 살짝 맛보고, 전송 계층부터 시작하겠습니다~