[컴퓨터 네트워크] 컴퓨터 네트워크와 인터넷

재오·2023년 7월 25일
4

CS

목록 보기
32/35
post-thumbnail

아래 내용은 '컴퓨터 네트워킹 하향식 접근 제8판'을 참고하여 작성되었습니다.

프로토콜이란 무엇인가?

컴퓨터 네트워크 프로토콜 개념은 사람의 의사소통과 비교하면 쉽게 이해할 수 있다.

사람 프로토콜에서는 상대방과 의사소통을 하기 위해 먼저 인사를 한다. 처음 인사를 건넨 사람은 상대방의 응답을 통해 상대방이 자신과 대화할 의사가 있는지를 확인해서 질문을 이어간다. 명확하게 송수신된 메시지와 이러한 메시지가 송수신될 때나 다른 상황이 발생했을 때 취하는 행동 등이 바로 사람 프로토콜의 중심 역할을 한다.

네트워크도 이와 마찬가지이다. 어떤 일을 수행하려면 둘 이상의 통신 개체가 함께 인식하는 프로토콜이 필요하다. 이 프로토콜이 모든 활동을 제어한다. 앞에서 사람이 의사소통을 하는 것처럼 메시지 교환과 메시지를 송수신할 때 취한 행동은 프로토콜의 요소를 정의하는 주요인들이다.

인터넷과 일반 컴퓨터 네트워크는 많은 프로토콜을 이용하는데, 다양한 프로토콜이 여러 가지 통신 목적으로 사용된다. 컴퓨터 네트워킹 분야의 전문가가 된다는 것은 네트워킹 프로토콜이 무엇이고 왜 필요하며 어떻게 운영되는지 잘 이해한다는 것과 같다.

네트워크의 가장자리

인터넷에 연결되는 컴퓨터와 그 밖의 장치를 컴퓨터 네트워크 용어로는 종단 시스템 이라고 부른다. 그 이유는 인터넷의 가장자리를 차지하고 있기 때문이다. 인터넷의 종단 시스템은 데스크톱 컴퓨터, 서버, 이동 컴퓨터 등이 포함된다. 종단 시스템을 호스트 라고도 부른다. 또한 호스트는 클라이언트서버 로 구분된다.

네트워크 코어

네트워크 애플리케이션에서 종단 시스템들은 서로 메시지를 교환한다. 출발지 조단 시스템에서 목적지 종단 시스템으로 메시지를 보내기 위해 송신 시스템은 긴 메시지를 패킷 이라고 하는 작은 데이터 덩어리로 분할한다. 송신 측과 수신 측 사이에서 각 패킷은 통신 링크와 패킷 스위치와 링크 계층 스위치의 두가지를 거치게 된다.

저장 후 전달
대부분의 패킷 스위치는 저장-후-전달 전송 방식을 이용한다. 저장-후-전달 은 스위치가 출력 링크로 패킷의 첫 비트를 전송하기 전에 전체 패킷을 받아야 함을 의미한다. 이를 좀더 쉽게 이해하기 위해서 하나의 라우터로 연결되고 2개의 종단 시스템으로 구성된 간단한 네트워크를 고려해보자. 라우터는 보통 여러 개의 링크를 갖는데 그 이유는 라우터의 기능이 입력되는 패킷을 출력 링크로 교환하는 것이기 때문이다.

위 예시에서 출발지는 목적지로 전송할 3개의 패킷을 갖고 있으며 각각은 L비트로 구성된다. 위 그림에서 출발지는 패킷 1의 일부분을 전송했고 패킷 1의 앞쪽은 이미 라우터에 도착했다. 라우터가 이 순간에 저장-후-전달을 채택하고 있기 때문에 라우터는 수신한 비트를 전송할 수 없다. 대신에 그 패킷의 비트를 먼저 저장한 후, 라우터가 패킷의 모든 비트를 수신한 후에만 출력 링크로 그 패킷을 전송하기 시작한다.

큐잉 지연과 패킷 손실
각 패킷 스위치는 접속된 여러 개의 링크를 갖고 있다. 각 링크에 대해 패킷 스위치는 출력 버퍼를 갖고 있으며 그 링크로 송신하려고 하는 패킷을 저장하고 있다. 출력 버퍼는 패킷 교환에서 중요한 역할을 한다. 도착하는 패킷이 한 링크로 전송되어야 하는데 그 링크가 다른 패킷을 전송하고 있다면 도착하는 패킷은 출력 버퍼에서 대기해야 한다. 따라서 출력 버퍼에서 큐잉 지연을 겪게 된다. 버퍼 공간의 크기가 유한하기 때문에 도착하는 패킷은 버퍼가 전송을 위해 대기 중인 다른 패킷들로 꽉 차 있는 경우가 발생하는데 이때 패킷 손실이 발생한다(이미 큐에 대기 중인 패킷을 폐기한다).

포워딩 테이블과 라우팅 프로토콜
라우터는 접속된 통신 링크 중 하나로 도착하는 패킷을 받아서 접속된 통신 링크 중 다른 링크로 그 패킷을 전달한다고 했는데 그렇다면 라우터는 어떻게 그 패킷을 어느 링크로 전달해야 하는지를 결정할까?

인터넷에서 모든 종단 시스템은 IP 주소를 갖는다. 출발지 종단 시스템이 패킷을 목적지 종단 시스템으로 보내자고 할 때, 출발지는 패킷의 헤더에 목적지의 IP 주소를 포함한다. 이 주소는 계층적 구조를 갖는데 패킷이 네트워크 한 라우터에 도착하면 라우터는 패킷의 목적지 주소의 일부를 조사하고 그 패킷을 이웃 라우터로 전달한다. 한마디로 라우터는 목적지 주소를 라우터의 출력 링크로 매핑하는 포워딩 테이블을 갖고 있다. 라우터에 패킷이 도착하면 라우터는 목적지 주소를 이용하여 포워딩 테이블을 검색하고 그 패킷을 출력 링크로 보낸다.

여기서 이용되는 것이 라우팅 프로토콜 인데 라우팅 프로토콜은 각 라우터로부터 각 목적지까지의 최단 경로를 결정하고 라우터에 포워딩 테이블 을 설정하는 데 이 최단 경로 결과를 이용한다.

회선 교환
우리가 앞에서 링크와 스위치의 네트워크를 통해 데이터를 이동시키는 방식으로 패킷 교환 을 봤다. 이제는 회선 교환 에 대해서 확인해보자.

회선 교환 네트워크에서 종단 시스템 간에 통신을 제공하기 위해 경로상에 필요한 자원은 통신 세션 동안에 확보 또는 예약된다. 회선 교환 네트워크의 예로 전화망이 있다. 송신자가 정보를 보내기 전에 네트워크는 송신자와 수신자 간의 연결을 설정해야 한다.그 연결이 이루어지는 동안 네트워크 링크에 일정한 전송률을 예약한다. 주어진 전송률이 송신자-수신자 연결을 위해 예약되므로 송신자는 수신자에게 보장된 일정 전송률로 데이터를 보낼 수 있다.

패킷 교환 네트워크에서의 지연

패킷이 한 호스트에서 시작하고 일련의 라우터들을 통과하며 다른 호스트에서 여행을 마치는 것으로 기억하면 편하다. 패킷이 경로를 따라 한 노드에서 다음 노드로 전달되므로 그 패킷은 경로상의 각 노드에서 다양한 지연을 겪게 된다. 중요한 지연으로는 노드 처리 지연, 큐잉 지연, 전송 지연, 전파 지연 을 들 수 있으며 이러한 지연들이 쌓여서 전체 노드 지연 이 발생한다.

노드 처리 지연
패킷 헤더를 조사하고 그 패킷을 어디로 보낼 지를 결정하는 시간은 처리 지연 에 해당한다.

큐잉 지연
패킷은 큐에서 링크로 전송되기를 기다리면서 큐잉 지연 을 겪는다. 큐잉 지연은 큐에 저장되어 있는 패킷의 수에 의해 결정된다.

전송 지연
패킷이 선입선출 방식으로 전송된다고 가정하면 인터넷에서 일반적인 것처럼 패킷은 앞서 도착한 다른 모든 패킷이 전송된 다음에 전송된다. 이것은 패킷의 모든 비트를 링크로 밀어는데 필요한 시간이다.

전파 지연
일단 비트가 링크에 전해지면 라우터 끝까지 전파되어야 한다. 링크의 처음부터 라우터 끝까지 전파에 필요한 시간이 전파 지연 이다.

전송지연과 전파지연에 대해서 헷갈리는 포인트가 있지만 전송 지연 은 라우터가 패킷을 내보내는 데 필요한 시간이다. 반면 전파 지연 은 비트가 한 라우터에서 다음 라우터로 전파되는 데 걸리는 시간이다.

Traceroute
컴퓨터 네트워크에서의 지연을 느끼기 위해 Traceroute라는 진단 프로그램을 이용할 수 있다.사용자가 목적지 호스트 이름을 제시하면 출발지 호스트에 있는 프로그램은 목적지를 향해 여러 개의 특별한 패킷을 보낸다. 이 패킷들은 목적지로 전진하면서 여러 개의 라우터를 통과한다. 한 라우터가 이 특별한 페킷 중 하나를 받으면 출발지로 짧은 메시지를 보낸다. 이 메시지에는 그 라우터의 이름과 주소가 포함되어 있다.

출발지는 한 패킷을 보내고 그에 해당하는 응답 메시지를 받을 때까지 셩과 시간을 기록한다. 또한 메시지를 보내온 라우터의 이름과 주소도 기록한다. 이 방식은 출발지부터 목적지까지 패킷이 흘러간 경로를 재구성할 수 있으며 출발지는 모든 중간에 있는 라우터까지의 왕복 지연을 결정할 수 있다.

프로토콜 계층과 서비스 모델

프로토콜 계층화
네트워크 프로토콜의 설계 구조를 제공하기 위해, 네트워크 설계자는 프로토콜을 계층으로 조직한다. 프로토콜 계층은 소프트웨어, 하드웨어 또는 둘의 통합으로 구현할 수 있다. HTTP와 같은 애플리케이션 계층 프로토콜은 대부분 종단 시스템의 소프트웨어로 구현되며 트랜스포트 계층 프로토콜도 마찬가지이다. 물리 계층과 데이터 링크 계층은 특정 링크상에 통신을 다루는 책임이 있으므로 네트워크 인터페이스로 구현된다. 네트워크 계층 은 종종 하드웨어와 소프트웨어로 혼합 구현된다. 이렇게 계층화한 것은 시스템 ㅅ구성요소에 대해 논의하기 위한 구조화된 방법을 제공한다.

다양한 계층의 프로토콜을 모두 합하여 프로토콜 스택이라고 한다. 인터넷 프로토콜 스택은 5개 계층으로 구성된다. 물리, 링크, 네트워크, 트랜스포트, 어플리케이션 계층이다.

애플리케이션 계층
애플리케이션 계층은 네트워크 애플리케이션과 애플리케이션 계층 프로토콜이 있는 곳이다. 애플리케이션 계층 프로토콜은 여러 종단 시스템에 분산되어 있어서 한 종단 시스템에 있는 애플리케이션이 다른 종단 시스템에 있는 애플리케이션과 정보 패킷을 교환하는 데 이 프로토콜을 사용한다. 애플리케이션 계층에서의 이 정보 패킷을 메시지 라고 부른다.

트랜스포트 계층
트랜스포트 계층은 클라이언트와 서버 간에 애플리케이션 계층 메시지를 전송하는 서비스를 제공한다. 인터넷에는 TCPUDP 라는 두 가지 트랜스포트 프로토콜이 있으며 이들은 애플리케이션 계층 메시지를 전달한다. 트랜스포트 계층 패킷을 세그먼트 라고 한다.

네트워크 계층
네트워크 계층은 한 호스트에서 다른 호스트로 데이터그램 을 하우팅하는 책임을 진다. 메일 서비스를 이용하기 위해 목적지 주소가 적힌 편지를 전달하는 것처럼, 출발지 호스트에서 인터넷 트랜스포트 계층 프로토콜은 트랜스포트 계층 세그먼트와 목적지 주소를 네트워크 계층으로 전달한다. 그런 다음 네트워크 계층은 목적지 호스트의 트랜스포트 계층으로 세그먼트를 운반하는 서비스를 제공한다. 가장 중요한 점은 네트워크 계층은 IP 데이터그램의 필드를 정의하며 종단 시스템과 라우터가 이 필드에 어떻게 동작하는지를 정의하는 프로토콜을 갖고 있다. 이 프로토콜이 그 유명한 IP 프로토콜 이다.

링크 계층
네트워크 계층은 데이터그램을 아래 링크 계층으로 보내고 링크 계층은 그 데이터그램을 경로상의 다음 노드에 전달한다. 다음 노드에서 링크 계층은 그 데이터그램을 상위 네트워크 계층으로 보낸다. 링크 계층에서 제공하는 서비스는 그 링크에서 채용된 특정 링크 계층 프로토콜에 의해 결정된다. 네트워크 계층은 각기 다른 링크 계층 프로토콜로부터 다른 서비스를 제공받을 것이다. 링크 계층 패킷을 프레임 이라고 한다.

물리 계층
링크 계층의 기능이 전체 프레임을 한 네트워크 요소에서 이웃 네트워크 요소로 이동하는 것이라면 물리 계층의 기능은 프레임 내부의 각 비트를 한 노드에서 다음 노드로 이동하는 것이다.

캡슐화

위 그림은 송신 종단 시스템의 프로토콜 스택 아래로 데이터를 보내며 중간의 링크 계층 스위치와 라우터의 프로토콜 스택을 위아래로 거치고 수신하는 종단 시스템의 프로토콜 스택 상위로 보내는 물리적 경로를 보여준다.

링크 게층 스위치는 1,2계층을 구현하고 라우터는 1~3계층을 구현한다. 예를 들면 인터넷 라우터들이 IP프로토콜을 구현할 수 있지만 링크 계층 스위치는 그럴 수 없다는 의미이다.

그리고 위 그림은 캡슐화 개념의 중요성을 보여준다. 송신 호스트에서 애플리케이션 계층 메시지는 트랜스포트 계층으로 보내진다. 가장 간단한 경우에 트랜스포트 계층은 메시지에 수신 측 트랜스포트 계층에서 사용될 추가 정보를 더한다. 애플리케이션 계층 메시지와 트랜스포트 계층 헤더 정보는 모두 트랜스포트 계층 세그먼트를 구성한다. 트랜스포트 계층 세그먼트는 애플리케이션 계층 메시지를 캡슐화한다. 다음으로 트랜스포트 계층은 세그먼트를 네트워크 계층으로 보내며 네트워크 계층은 출발지와 목적지 종단 시스템 주소와 동일한 헤더 정보를 추가하여 네트워크 계층 데이터그램 을 만든다. 이 데이터그램은 링크 계층으로 전달되고 링크계층도 자신의 헤더 정보를 추가하고 링크 계층 프레임 을 만든다.

이 내용을 좀더 쉽게 설명하자면 메모를 우편으로 보내고자 할 때, 메모애플리케이션 계층 메시지 와 유사하다. 메모를 밥의 이름과 부서번호가 적힌 봉투에 넣을 때 이 봉투트랜스포트 계층 세그먼트 와 유사하다. 헤더 정보(밥의 이름과 부서번호)를 포함하고 메모를 캡슐화한다. 이것을 또 수신지부의 우편주소가 적힌 우편봉투 에 넣게 되는데 우편 봉투는 데이터그램 과 유사하다. 이 우편봉투를 수신 지부 메일룸에 전달하는데 여기서부터는 캡슐화의 반대 과정이 시작된다.

profile
블로그 이전했습니다

0개의 댓글