IP
인터넷 프로토콜은 TCP, UDP등의 전송 계층 프로토콜에 기존적인 전달 서비스를 제공한다. IP는 목적 호스트와 네트워크에 데이터를 전달하는 역할을 수행하지만, 신뢰성을 보장하지 않으므로 실패하는 경우도 있다.
각 계층이 저마다 중요한 기능을 제공하지만, 인터넷이 작동하는 전 과정에서 가장 중요한 것은 뭐니뭐니 해도 IP이다. 한 호스트에서 다른 호스트로 데이터 전달을 책임지는 것이 바로 IP이기 때문이다.
IP 데이터그램이 여러 네트워크들을 거쳐 최종 목적지에 전달되도록 중계 및 전달 과정에서 필요한 결정을 내리는 것이 IP의 기능이다.
"송신 시스템은 목적지 시스템으로 전달되는 방식을 고려하지 않고, 그 시점에서 가능한 최선의 경로를 설정하면 된다." 중계 시스템으로 데이터그램을 전송해야 되는 경우,
"중계 시스템들은 현재의 네트워크 환경에 따라 경로를 설정하고, 데이터가 데이터그램 헤더에 명시된 목적지 시스템에 전달될 때까지 이를 전달한다."
IP표준
IP는 RFC791에서 정의되었으며, 이문서는 STP5로 재발행 되었다. RFC791에는 불분명한 점이 남아있었는데 RFC1122(호스트 네트워크의 요구 사항)에 이르러 그런 점들이 해결되었다.
RFC791은 다음과 같이 시작된다.
"인터넷 프로토콜은 상호 연결된 패킷 스위칭 컴퓨터 통신 네트워크에서 사용하려고 설계되었다. 인터넷 프로토콜은 데이터그램이라는 데이터 블록을 출발지 에서 목적지로 전송한다. 또 작은 패킷으로 전송할 것을 요구하는 네트워크를 통해 큰 데이터그램을 보내는 경우, 분열과 재배열 기능을 제공한다"
이어서,
"인터넷 프로토콜의 활용 범위는 상호 연결된 네트워크들을 통해 비트(인터넷 데이터그램)를 출발지에서 목적지 까지 전달하는데 필요한 기능을 제공하는 것으로 제한되어 있다. 따라서 종단간(end-to-end)데이터의 신뢰성 향상, 흐름 제어, 순서 제어 및 기타 호스트(host-to-host) 프로토콜의 보편적인 기능을 제공할 메커니즘은 갖추지 않았다."
RFC791은 대략 다음과 같이 요약할 수 있다.
출발지 시스템은 목적지 시스템이 로컬 네트워크 내에 있을경우 "직접" 데이터그램을 전송한다.
로컬 네트워크 내에 있지 않을 경우에는 로컬 네트워크 내의 "다른 시스템을 거쳐" 목적지 시스템에 데이터그램을 전송한다.
송/수신 시스템을 연결하는 물리적 매체의 수용 능력이 충분하면 IP는 모든 데이터를 한꺼번에 전송한다. 하지만 그렇지 못할 경우 네트워크의 물리적 매체가 처리할 수 있는 크기로 데이터를 조각(fragment) 내어 전송한다.
일단 데이터그램을 전송하고 나면 그에 대해서는 잊어버리고, 다음 데이터그램의 처리로 넘어간다. IP는 오류 수정, 흐름 제어 및 관리 기능을 제공하지 않는다는 얘기이다. "단지 한번에 한 네트워크에 대해, 한 호스트에서 다른 호스트로 데이터그램을 전송할 뿐이다."
IP데이터그램과 IP패킷의 관계
IP네트워크에 연결된 호스트들은 IP데이터그램을 이용하여 정보를 교환한다. 이런IP데이터그램은 정보를 포함한 데이터 부분과 그 정보를 설명 하는 헤더 필드로 구성된다.
어떤 장비가 IP네트워크를 통해 다른 시스템에 데이터를 전송하려면 항상 IP데이터그램을 만들어 보내게 된다. 물론 이 과정에서 만들어진것은 IP가 실제로 보내는 데이터그램은 아니지만 그대신 IP데이터그램은 IP패킷으로 전송된다. 목적지 시스템까지 IP데이터그램을 한번에 한 단계씩 중계하는 데 실제로 사용되는 것은 IP 데이터그램이 아니라 IP패킷이다. IP데이터그램과 IP패킷은 완전히 일치하지만, 둘은 개념적으로 엄연히 다르다.
IP데이터그램에는 (물론 IP헤더도 함께) 전송하려는 데이터는 무엇이든 포함되며 IP패킷은 그 데이터그램을 IP헤더가 지정하는 목적지 시스템으로 전송하는 데 사용된다. IP패킷은 로컬 네트워크 매체의 프레임 분리기법에 따라 전송되며, 분열 또는 분실 등 네트워크에서 발생하는 각종 사건에 영향을 받는다. 그러나 데이터그램을 중계하는 패킷에 어떠한 사건이 발생하더라도 데이터그램 자체는 항상 송신자가 전송한 원본 그대로 보존된다.
예를들어 A가 B에게 4킬로바이트 데이터그램을 전송할때, 데이터 그램이 이더넷 네트워크에서 한 프레임으로 전송되기에는 너무 크기 때문에, 먼저 IP패킷 4개로 분열되고, 나눠진 IP패킷은 개별 이더넷 프레임으로 전송된다.
목적지 시스템이 IP패킷 4개를 모두 수신하면 이들은 원래의 데이터그램으로 재배열되어 처리된다.
이런 모델은 IP가 인터넷을 구성하는 다양한 종류의 물리적 네트워크에 가상 네트워크를 제공하려 할 때 필요하다.
IP는 네트워크마다 각각(주소 체계와 프레임 크기 등) 특성이 다르므로 다양한 네트워크를 통해, 데이터그램을 깨끗하고 안정적으로 전달할 수 있는 메커니즘을 제공해야 한다. IP데이터그램은 호스트가 전송하려는 모든 데이터를 전송할 수 있도록 해주는 반면, IP패킷은 중계 네트워크들의 특성에 따라 그 네트워크들을 통해 데이터 그램이 목적지까지 실질적으로 전송될 수 있도록 해준다.
로컬 배달과 원격 배달
- 로컬배달
IP 헤더는 출발지와 목적지 시스템의 IP 주소 모두를 저장한다. 목적지 시스템이 송신시스템과 같은 물리적 네트워크에 있으면 송신 시스템이 목적지 시스템에 "직접" 데이터그램을 전송한다. 이런 경우 송신 시스템은 목적지 시스템이 같은 로컬 네트워크에 있다는 것을 알고 있으므로, 네트워크 매체에 적합한 하위 레벨 프로토콜을 사용하여 목적지 시스템에 직접 데이터를 전송한다.
-원격배달
반면 두 시스템이 같은 네트워크에 연결되어 있지 않으면, 송신 시스템은 로컬 네트워크 내에서 IP데이터그램을 최종 목적지까지 중계 할 수 있는 노드(node)를 찾아야 한다. 이 경우 중계 시스템은 최종 목적지에 직접 접근할 수 있으면 데이터그램을 전달하고, 그렇지 않으면 또 다른 중계 시스템에 데이터 그램을 전송한다. 이런 과정이 반복되면서 데이터 그램은 최종 목적지 시스템에 전달된다.
송신시스템은 목적지 시스템이 원격 네트워크에 존재한다는 사실을 알고, 최종 목적지로 데이터를 전달할 중게 시스템의 위치를 파악한다. 중계 시스템의 하드웨어 주소를 파악한 다음 네트워크 매체에 적합한 하위 레벨 프로토콜을 사용하여 중계 시스템으로 데이터를 전송한다. 중계 시스템은 데이터그램의 목적지 IP주소를 살핀다음, 출그 인터페이스를 선택하고, 그 네트워크에 적합한 하위레벨 프로토콜을 사용하여 최종 목적지 시스템에 데이터를 전달한다.
위의 예시들은 사내네트워크에서 찾아 볼 수 있는 트래픽 패턴이며 비교적 간단한 것이다.
그러나 데이터그램이 인터넷을 통해 전송되기 시작하면 매우 복잡해진다.
통과하는 라우터의 수도 한두 개에서 몇십 개로 증가한다. 그러나 IP는 복잡한 네트워크도 단순한 네트워크처럼 다룬다. 즉 한 번에 한 단계씩 이동하여 결국 데이터그램을 전달한다.
IP가 원격 호스트와 네트워크를 찾는 방법
모든 IP 장비는 기능과 상관없이 연결된 모든 네트워크에 대해 IP주소를 갖고 있어야 한다. 대부분의 시스템은 하나의 네트워크에 연결되어 있으므로, 하나의 IP주소만 갖는다. 그러나 라우터 또는 부하가 심한 파일 서버처럼 다양한 네트워크 인터페이스를 갖춘 장비는 연결된 네트워크마다 전용 IP주소를 할당받고 있어야 한다.
IP프로토콜이 메모리에 적재되면서, 시스템에서 사용할 수 있는 인터페이스 목록과 시스템이 연결되어 있는 네트워크를 나타내는 맵이 생성된다. 이 맵을 '라우팅 테이블' 이라고 부른다. 라우팅 테이블에는 시스템이 연결되어 있는 네트워크와 네트워크 인터페이스의 IP주소 등의 정보가 저장된다.
하나의 인터페이스를 갖고 있는 장비는 라우팅 테이블에 장비의 네트워크 인터페이스 IP주소와 그 IP주소로 연결되어있는 로컬 네트워크를 나타내는 하나의 엔트리만 등록 된다. 그러나 장비가 여러 네트워크에 연결되어 있으면 (또는 같은 네트워크에 여러 차례 연결되면), 라우팅 테이블에는 둘 이상의 엔트리가 등록된다.
+ 거의 모든 IP장비는 디버깅을 목적으로 하는 '루프백' 네트워크를 갖고 있다. 루프백 네트워크는 항상 127.0.0.0으로 번호가 매겨져있고, 루프백 인터페이스는 항상 127.0.0.1이라는 주소를 갖는다. 따라서 일반적으로 라우팅 테이블에는 적어도 두 개 이상의 엔트리(물리적으로 연결되어 있는 네트워크와 루프백 네트워크)가 존재한다.
한 시스템이 다른 시스템으로 데이터그램을 전송할 때면 언제나 라우팅 테이블을 참조하여 외부로 내보낼 트래픽을 전송할 네트워크 인터페이스를 찾는다.
아래의 예시를 살펴보자.
라우터는 두개의 네트워크에 연결되어 있다. 즉 IP주소 192.168.10.3으로 이더넷에 연결되어 있으며 IP 주소 192.168.100.1 로 시리얼에 연결되어 있다.(오래된 책이라서 그런지 모뎀이랑 연결을 예로 들고 있다 ㅠ ㅠ) 이 라우터가 데이터를 192.168.10.10으로 전송하면 이더넷 인터페이스를(192.168.10.3을 통하여), 192.168.100.100에 데이터 그램을 전송하면 시리얼 인터페이스(192.168.100.1 를 통해)를 각각 사용한다. 이런 정보를 바탕으로 작성된 이 라우터의 라우팅 테이블은 아래와 같다.
그러나 이 라우팅 테이블은 172.16.100.2에 대해서는 정보가 없다. 이 라우터에서 172.16.100.2로 IP데이터그램을 전송하려면 라우팅 테이블에 172.16.100.2네트워크에 대한 엔트리가 등록되어 있어야 한다.
이때 시스템은 라우팅 테이블에 엔트리가 추가되면서 이런 정보를 통지받는다.
대부분의TCP/IP패키지는 특정 네트워크와 호스트에 대한 엔트리를 사용자가 수동으로 생성하고 삭제할 수 있는 툴을 제공한다. 사용자는 이런 툴을 이용하여 라우터에 목적지가 172.16.100.0인 패킷은 192.168.100.100인터페이스를 태우면 전송 할 수 있다는 사실을 알려준다. static으로 넣어주자.
172.16.100.2로 전송되는 모든 데이터그램을 192.168.100.100으로 전송 할 수 있다.
로컬 라우팅 테이블에 모든 네트워크 세그먼트를 추가함으로써, 모든 로컬 장비에서 원격 네트워크 세그먼트로 데이터그램을 전달할 수 있다.
하지만 모든 것이 제대로 동작하려면 사용자가 모든 네트워크 세그먼트에 대한 엔트리를 네트워크의 모든 장비에 추가해야 한다. 모든 네트워크와 원격 라우터에 대한 정보를 포함한 맵을 모든 라우터에 설정해주야 하므로 상당한 노력이 들 뿐만 아니라, 그 과정에서 설정하는 사람이 실수할 여지도 많다.
여기까지 왔으면 갑자기 의문이 든다. 만약 목적지가 tistory인 패킷을 전송하려면? 또다시 사용자가 임의로 routing table에 엔트리를 추가해야 하는걸까? google에 접속하면 routing table에 google에 대한 엔트리가 추가되어야 하는거고?!?! (DNS 질의 과정은 살짝 모른척 하자.)
걱정할 필요는 없다. 사람 대신 네트워크 맵을 생성하여 모든 시스템에 배포하는 데 사용 할 수 있는 다양한 애플리케이션 프로토콜이 있다. 그중 가장 널리쓰이는것이 RIP(Rest In peace가 아니다. Routing Information Protocol이다.)이다. RIP는 UDP 브로드캐스트를 사용하여 모든 시스템에 30초마다 라우팅 테이블을 배포한다. 또한 OSPF(Open Shortest Path First) 또한 RIP못지않게 유명하다. OSPF는 RIP가 지닌 기본 기능은 몰론, 그보다 더 많은 정보를 제공하면서도 오버헤드는 적어 널리 사용되는 프로토콜이다.
그러나 두 프로토콜 모두가 외부 네트워크에 대해서는 많은 수의 네트워크를 지원할 정도로 완벽하게 작동하지는 못한다. 그러한 환경에서는 일반적으로 BGP(Border Gateway Protocol)와 같은 다른 프로토콜을 사용한다.
이런 동적 라우팅 프로토콜은 모두 CPU사이클과 메모리 및 네트워크 대역폭을 많이 소비하기 때문에 대부분의 네트워크 관리자는 이러한 작업을 자신의 라우터에서만 실행시킨다. 그런 다음 호스트가 연결되어 있는 로컬 네트워크의 라우터를 호스트의 'Default 경로'로 설정한다. 이 방식을 사용하면 클라이언트의 라우팅 테이블에는 오직 1개의 엔트리만 등록하고 전체 네트워크 토폴로지는 라우터에만 기억시키면 된다.
==> client에 모든 routing table을 등록 할 수 없으니가 default path로 라우터를 설정하고.. 라우팅테이블에 엔트리가 없는 목적지로 패킷이 들어오면 무조건 default path로 보내는 것인가..?
기본 라우터는 IP 소프트웨어와 함께 제공된 툴을 사용하여 수동으로 설정하거나, 시스템을 부팅할 때 BOOTP 또는 DHCP등의 프로토콜을 사용하여 자동으로 설정할 수 있다. 그밖에 라우터 디스커버리 프로토콜은 네트워크 토폴로지의 변화에 따라서 네트워크 장비에 기본 경로에 대한 정보를 동적으로 제공하고, 장비의 라우팅 테이블을 갱신한다.
경로의 결합
경로를 결합할 수 있는 새로운 주소 할당 체계가 전개되고 있다.
이제 사용자가 인터넷 주소를 ISP(인터넷서비스회사)에 요청하면, ISP는 기존에 자신이 할당받은 주소 범위 내에서 새로운 주소를 할당한다. 이런 주소 지정 체계는 라우팅을 더 높은 레벨에서 이를 수 있다.
즉 ISP는 수천개의 네트워크 경로를 추적하고 알리는 대신 며개의 상위경로만 알리면 된다.
ISP는 자신의 모든 네트워크를 계속해서 추적해야 하지만, 이를 다른 ISP에게 알릴 필요는 없다. 이런 특성을 이용함으로써 어떠한 기능도 잃지 않으면서 백본라우터를 갱신하는 트래픽 양을 크게 줄일 수 있다.
한편 지역을 기준으로 경로를 결합하는 결합 체계도 보급되고 있다. 예를 들어 194로 시작되는 모든 네트워크가 유럽 내에 위치한다고 가정할때, 인터넷에 연결된 주요 라우터가 194-로 시작되는 모든 네트워크에 대한 트래픽을 단순히 유럽의 백본 라우터에 전달할 수 있게 한다.
이 백본 라우터는 해당 지역 ISP에 데이터그램을 전달하며, ISP는 그 데이터그램을 최종 목적지까지 중계한다.
이 과정은 전화회사가 지역번호와 국번을 이용하여 전화의 경로를 설정하는 것과 개념적으로 유사하다!
전화 교환기는 지역 번호만 살펴보고 시외 전화인지 아닌지를 판별한다. 해당 지역의 주요 교환기는 국번을 살펴본 다음, 전화를 해당 전화구긍로 연결하며, 발신자가 전화번호의 마지막 네자리를 누른느 순간 전화는 99% 연결된다.
데이터 독립성
앞에서 라우터가 목적지 IP주소를 통해 데이터그램을 최종 목적지까지 신속하게 전달하는 과정을 전화 번호로 예를 들어 설명하였다. 그러나 IP패킷의 전달방식이 전화 연결과 완전히 같은 것은 아니다.
- 전화망에서는 발신자와 수신자를 지점간으로 연결하는 데 '회선' 개념을 이용한다.
- 반면, IP네트워크는 각각의 IP데이터그램을 고유 개체로 취급하고, 매 순간마다 가장 적합한 경로로 자유롭게 이동한다.
예를들어 사용자가 원격 웹 서버에 담겨있는 문서를 검색해서 읽는 경우, 서버는 요구된 자료를 전송하기 위해 IP다이어그램을 생성한다. 각각의 데이터그램은 전송된 순서와 무관하게 서료 다른 고유의 개체로 간주된다.
각 데이터그램은 전달하는 라우터가 가장 적합하다고 판단한 경로를 따라 이동된다. 이말은 동일한 문서를 분할하여 생성한 데이터그램이라 할지라도 전혀다른 경로로 전달 될 수 있음을 뜻한다! 각 데이터 그램은 전달하는 라우터가 가장 적합하다고 판단한 경로를 따라 이동하기 때문이다.
이런 경로 설정은 출발지와 목적지 시스템 사이에 있는 라우터에 의해 이루어진다.
데이터 그램은 독립적인 특성을 갖고 있기 때문에 전송하는 네트워크의 속도에 따라 원래의 순서에 어긋나게 목적지에 전달될 수 있다. 또 데이터그램이 중복되어 목적지에 복수 개의 동일한 패킷이 전달되는 경우가 발생할 수도 있다.
그러나 IP는 데이터그램이 순서에 어긋나게 전달되거나, 전송중에 분실되거나, 중복해서 전달되어도 전혀 개의치 않는다. 왜냐하면 IP는 데이터그램을 추적하기 위해서가 아니라 전송하기 위한 프로토콜 이기 때문이다.
"따라서 이런 사건들로 초래되는 모든 문제는 상위레벨의 프로토콜이 처리해야 한다."
또한 네트워크는 모든 데이터그램을 개별적인 개체로 취급함으로써 모든 연결경로를 추적해야 하는 책임을 질 필요가 없다. 즉 네트워크에 연결된 장비는 웹 브라우저의 모든 세션의 시작과 끝을 감시할 필요 없이 데이터그램을 전송하는것에만 초점을 맞추면 된다. CPU와 메모리의 사용을 최소화하여 하드웨어가 허용하는 최대 수준까지 전체적인 네트워크 성능을 향상시킬 수 있는 것도 바로 이런 특징 때문이다.
유지관리
패킷을 수신한 모든 시스템은, 최종 목적지이든 중계 라우터이든 상관하지 않고 패킷을 검사한다. 만약 패킷이 손상되었거나 다른 종류의 일시적인 오류가 있었다는 사실이 발견되면 그 시스템에서 소멸된다. 데이터그램은 이런 일시적인 오류가 발생할 때마다 전달되지 않고 소멸된다.
반면에 문제가 반영구적인 경우, 예를들어 현재 장비의 라우팅 테이블에 목적지 네트워크의 엔트리가 없거나, 패킷이 다음 단계의 네트워크로 전달될 수 있는 조건을 충족하지 못할때에는 IP가 ICMP를호출하여 송신자에게 실패했다는 에러 메시지를 전송한다.
데이터그램이 마지막 단계의 장비에서 소멸되었더라도 그 장비는 송신 시스템에 문제를 통보하여 송신 시스템이 실패한 원인을 수정할 수 있도록 해준다.
일시적인 오류와 반영구적인 오류를 구별하는 것이 중요하다.
일시적인 오류
- 활성화 시간 만료, 체크섬 잘못계산 => 송신시스템의 잘못 없이 일어남
반영구적인 오류
- 그 경로로 전송할 수 없는 패킷이나 네트워크의 문제 때문에 발생한다. => 이 경우에는 송신 시스템 또는 송신 애플리케이션에 문제점을 통보하는 것이 최선의 해결책이며, 그 기능을 맡는 것이 바로 ICMP다!
헤더 체크섬
데이터그램의 무결성을 검사하는 기능중 하나는 IP데이터그램 헤더(데이터가 아니다)에 대한 체크섬 기법을 적용하여 이루어진다. 즉 IP데이터그램을 수신한 모든 장비가 IP헤더 정보와 체크섬 값을 비교하여 이 값들이 일치하지 않은 경웅는 데이터그램을 손상된 것으로 취급하여 즉시 없애버린다.
IP데이터그램의 데이터를 검사하지 않는 이유는 세가지이다.
- 데이터그램 전체를 살펴봐야 하므로 CPU처리 시간이 늘어나서 비효율적임
- IP데이터그램의 데이터부분은 항상 TCP나 UDP등이 생성한 상위 레벨의 데이터를 포함한다. 이 프로토콜에서 자체적으로 오류를 검사하기 때문에 수신 시스템은 어차피 검사를 수행하게 되는 것이다.
- 특정 어플리케이션 프로토콜에서는 데이터그램 데이터가 손상됐을지라도 작업을 진행할 수 있다. 따라서 데이터에 대한 체크섬 값들이 일치하지 않는다는 이유로 데이터그램을 소멸하는 것이 오히려 좋지 않다.
활성화 시간
IP는 또한 데이터그램헤더의 Time-to-live필드를 통해 유효 기간을 검사한다. 패킷을 전달하는 모든 시스템은 패킷을 전송하기 전에 활성화 시간 필드의 값을 하나씩 감소시킨다. 만약 데이터그램이 최종 목적지에 전달되기 전에 활성화 시간의 값이 0에 도달하면, 송신시스템에 ICMP 실패 통보 메시지가 전달되고 패킷은 소멸된다.
Time-to-Live 필드의 목적은 데이터그램이 전달될 수 없는 루프에 빠졌을 때, 계속해서 네트워크 자원을 소비하는 것을 방지하는 것이다.
분열과 재배열
모든 네트워크는 사용하는 매체에 따라서 특성이 다르다. 그 중에서 가장 중요한 것이 바로 네트워크가 하나의 프레임에 담아 운반할 수 있는 데이터의 최대 용량, 즉'최대 전송 단위 (MTC)다.
- 이더넷 : 1,500 byte /per frame
- 16Mb/s 토큰링 : 17,914 byte /per frame
IP데이터그램은 사용 가능한 어떤 경로로도 전달될 수 있기 때문에, 전달 장비에 의해 생성되는 모든 IP패킷은 중계 네트워크에 사용되는 매체의 MTU에 맞춰져야 한다. 송신시스템의 로컬 MTU보다 데이터그램이 크면, 해당 라우터에 의해 다시 분열된다.
따로 격리된 네트워크 에서는 모든 시스템에 동일한 MTU를 공유하므로 데이터그램의 크기는 별로 문제가 되지 않는다. 그러나 여러 가지 네트워크 매체가 같이 사용되는 경우에는 MTU가 아주 중요해진다.
예를들어 웹서버는 4,464바이트 패킷을 사용하는 토큰링 네트워크에 있고 클라이언트는 1,500바이트 패킷을 사용하는 별도의 이더넷 세그먼트에 있다고 가정하다.
웹서버의 TCP/IP 소프트웨어는 4,464바이트 IP데이터그램을 생성하지만, 이 IP데이터그램이 클라이언트로 전달되려면 두 세그먼트 사이에 있는 라우터를 이더넷 네트워크에서 전송될 수 있도록 더 작은 패킷들로 분열되어야 한다.
분열과정에서 라우터는 여러가지 작업을 한다
- 원래 패킷에 저장된 데이터의 크기를 계산한 다음, 데이터가 더 작은 세그먼트에서 전송될 수 있도록 필요한 만큼 조각을 만든다.
- 각각의 IP패킷의 헤더에 출발지, 목적지 IP주소, 활성화시간, 서비스 종류 플래그 등 원래의 패킷의 헤더정보를 각가 붙여준다.
이들 필드중 특히 분열과 관련하여 가장 중요한 것은, 각각의 조각이 원래의 동일한 IP 데이터그램에 속한다는 것을 나타내는 Fragmantation Identifier필드다. 이 필드의 성격은 실질적으로 Datagram Identifier필드에 가까우며, 송신시스템이 데이터그램을 생성할 때마다 16비트로 이뤄진 일련 번호를 부여받는다. 패킷이 분열되면서 만들어진 모든 조각은 원래 데이터그램의 Fragmentation Identifier를 사용하며, 목적지 시스템에서는 이 정보를 이용하여 모든 조각을 모아 원래의 형태로 데이터그램을 재배열한다.
- Fragmentation Offset
데이터그램조각이 저장하고 있는 데이터가 원래의 데이터그램 내에서 위치했었던 범위를 나타낸다. 바이트 범위의 시작점만 제공한다.
Fragmentation Offset 식별자는 목적지 시스템이 모든 조각을 수신하여 이들을 원래 순서대로 재배열 할 수 있게 한다.
- Fragment Flags
현재의 분열 상태에 대한 단서를 제공한다. 총 3비트로 되어있다.
1) 향후 사용할 목적으로 사용 0비트로 설정
2) 분열이 허용되는지 여부를 나타낸다. (허용되면 0 안되면 1)
3) 현재의 데이터그램조각이 마지막인지(0), 아니면 뒤에 데이터그램조각이 더 있는지 (1)를 나타낸다.
새롭게 만들어진 IP패킷의 Total Packet Length 필드도 기존의 데이터그램 크기가 아니라 새롭게 만들어진 데이터그램조각의 크기로 설정되어야 한다.
이렇게 만들어진 IP패킷들은 각각이 독립적인 패킷처럼 개별적인 개체로 인터넷을 통해 전송된다. 또한 최종 목적지 시스템에 전달되기 전에는 재배열 되지 않는다. 각 조각들이 최종 목적지에 전달되면 목적지 시스템의 IP소프트웨어가 원래의 데이터그램 형태로 재배열한다.
IP조각이 어떻게 생성되는가에 대한 법칙
- 분열은 패킷의 데이터부분에서만 일어난다.
- 패킷의 헤더는 분열과정에 포함되지 않는다.
- 새롭게 생성되는 조각들은 각자 IP헤더를 가진 새로운 패킷으로 만들어진다. "IP패킷의 헤더는 최소한 20바이트" 이다. MTU는 최대 전송 단위임. 이더넷에서는 한 프레임에 1,500바이트까지 전송할 수 있으므로 따라서 "데이터그램 데이터"의 최대 사이즈는 1,480 인것을 우리는 지난 뻘짓에서 알 수 있었다.
- 분열은 8바이트 단위로 일어난다. 만약 데이터그램이 256바이트의 데이터를 포함하고, 한 조각에 250바이트만 채울 수 있다면, 첫번째 조각에는 248바이트의 데이터만 저장된다. 나머지 2byte는 다음 조각으로 전송된다.
- Fragmentation Offset 필드는 각 조각이 원래 데이터그램의 어느 부분에 해당하는지를 800바이트 단위의 바이트 개수로 나타낸다. 예를들어 Fragmentation Offset필드는 조각에 저장된 데이터의 시작점을 '248 바이트'가 아닌 '31 블록'으로 나타낸다. 여기서 블록은 1이 아닌 0부터 시작한다.
-각 조각은 동일한 데이터그램에 속하므로, Fragmentation Identifier 필드에 동일한 '일련 번호'를 공유한다.
-분열과정에서 새롭게 만들어진 IP패킷의 Total Packet Length 필드에 원래의 데이터그램의 크기가 아닌 새로운 IP패킷의 크기를 저장한다.
목적지 시스템에서 데이터그램을 재배열ㄹ하려면, 각 조각들을 수신하면서 동시에 분열과 관련된 헤더를 읽어들여, 이들을 알맞은 순서로 배열해야 한다. 네트워크 상태에 따라서 각 조각을 순서에 어긋나게 수신할 수도 있으므로, 모든 조각드을 수신하고 재배열 하여 처리하기 전까지는 수신한 조각들을 메모리에 저장해야 한다.
모든 조각들을 수신하면, 시스템은 이들의 헤더를 살펴보아 Fragmentation Offset이 0인 조각을 찾는다. IP소프트웨어는 그 조각이 포함하고 있는 IP패킷의 데이터 부분을 일어들이고 8바이트 블록의 수를 기록한다. 그리고 데이터를 계속해서 읽어들이기 위해 필요한 Fragment Offset을 가진 조각을 찾아, 조각의 데이터를 메모리에 읽어들인다. 이 과정은 모든 패킷 들로부터 모든 데이터가 읽어들여질 때까지 계속된다.
'Today I learned' 카테고리의 다른 글
| [Chrome extension ] 크롬에서 vim 커맨드 사용하기 - vimium (0) | 2020.01.02 |
|---|---|
| [네트워크 프로토콜] 연말행사, 함께떠나요 네트워크 프로토콜 파티 3일차 ICMP (0) | 2020.01.01 |
| [네트워크 프로토콜] 연말행사, 함께떠나요 네트워크 프로토콜 파티 1일차 (2) IGMP (0) | 2019.12.30 |
| [네트워크 프로토콜] 연말행사, 함께떠나요 네트워크 프로토콜 파티 1일차(1) ARP (0) | 2019.12.30 |
| ECMAScript 6 정리 (0) | 2019.12.29 |
댓글