네트워크
ICMPv4 & IGMPv2
ta_chan
2023. 7. 22. 18:28
- 오류제어 프로토콜(TCP 흐름제어/혼잡제어/오류제어)
- 패킷이란?
- - 인터넷에서 데이터를 보내기 위한 경로 배정(라우팅)을 효율적으로 하기 위해 데이터를 여러개의 조각으로 나누어 전송하게 되는데, 이때의 조각을 패킷이라고 한다. - 패킷은 헤더, 데이터, 테일러로 구성되어있다. 헤더 : 수신처의 인터넷 주소와 순서 등 테일러 : 에러 정보
- TCP는 패킷을 어떻게 추적하고 관리하는가?
- - 데이터는 패킷 단위로 쪼개져 같은 목적지로 전송된다. 따라서 패킷에 각각 **번호를 부여**하여 패킷의 **분실 확인 처리를 하기위해 목적지에서 패킷을 재조립한다.** 이런식으로 패킷을 추적하며, 나누어 보내진 데이터를 목적지에서 받고 재조립할 수 있다.
<aside> 💡 흐름제어 :
</aside>
- 송신측과 수신측 사이에 데이터 처리 속도 차이(흐름)을 제어하기 위한 기법으로 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지한다
- 송신하는 곳에서 감당이 안되게 많은 데이터를 빠르게 보내 수신하는 곳에서 문제가 일어나는 것을 막는다.
- 만약, 송신측의 전송량 > 수신측의 수신량 일 경우 전송된 패킷은 수신측의 큐 를 넘어서 손실 될 수 있기 때문에 송신측의 패킷 전송량을 제어하게 된다.
- Stop and Wait(정지 - 대기)
- - 매번 전송한 패킷에 대한 **확인 응답**을 받아야 그 다음 패킷을 전송할 수 있다. 이러한 구조로 인해 비효율적이란느 단점이 있다.
- Sliding Window(슬라이딩 윈도우)
- - 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 기법이다. 따라서 송신측에서는 ACK 프레임을 수신하지 않더라도 여러 개의 프레임을 연속적으로 전송할 수 있다. - 송신측에서 0,1,2,3,4,5,6,을 보낼 수 있는 프레임을 가지고 있고 수신자가 설정한 윈도우의 크기가 2라고 가정할 때, 데이터 0,1을 전송하면 슬라이딩 윈도우 구조는 2,3,4,5,6 처럼 변한다. 이때 만약 수신측으로부터 `ACK`라는 프레임을 받게 된다면 송신측은 이전에 보낸 데이터 0,1을 수신측에서 정상적으로 받았음을 알게 되고 송신측의 슬라이딩 윈도우는 ACK 프레임의 수만큼 오른쪽으로 경계가 확장된다. - Stop and Wait의 비효율성을 개선했다. - 페이징과 비슷한 개념 → 데이터를 일정 수로 나누어서 보낸다.
<aside> 💡 오류제어
</aside>
- 오류 검출과 재전송을 포함한다. ‘테일’ 에 포함되어있다.
- ARQ(Automatic Repeat Request) 기법을 사용해 프레임이 손상되었거나 손실되었을 경우, 재전송을 통해 오류를 복구한다. ARQ 기법은 흐름 제어 기법과 연관되어있다.
- Stop and Wait ARQ
- - 송신 측에서 1개의 프레임을 송신하고, 수신측에서 수신된 프레임의 에러 유무에 따라 ACK 혹은 `NAK(Negative Acknowledgement)`를 보내는 방식 - 식별을 위해 데이터 프레임과 ACK 프레임은 각각 0,1 번호를 번갈아가며 부여한다. - 수신측에 데이터를 받지 못했을 경우 NAK를 보내고, NAK를 받은 송신측은 데이터를 재전송한다. - 만약, 데이터나 ACK가 분실되었을 경우 일정 간격의 시간을 두고 타임아웃이 되면 송신측은 데이터를 재전송한다.
- Go-Back-n ARQ
- - 전송된 프레임이 손상되거나 분실된 경우 그리고 ACK 패킷의 손실로 인한 TIME_OUT이 발생한 경우, 확인된 마지막 프레임 이후로 모든 프레임을 재전송한다. - 슬라이딩 윈도우는 연속적인 프레임 전송 기법으로 전송측은 전송된 프레임의 복사본을 가지고 있어야 하며, ACK와 NAK 모두 각각 구별해야 한다. - ACK : 다음 프레임을 전송 - NAK : 손상된 프레임 자체 번호를 반환 - **재전송 되는 경우** - 1. NAK 프레임을 받았을 경우 : 만약 수신측으로부터 0~5 까지의 데이터를 보냈다고 가정했을 때, 수신측에서 데이터를 받았음을 확인하는 데이터 오류 프레임 2를 발견하고 NAK2를 전송측에 보낸다고 해보자. NAK2 를 받은 전송측은 데이터 프레임 2가 잘못되었다는 것을 알고 데이터를 재전송한다. GBnARQ의 특징은 데이터를 재전송하는 부분이다. NAK(n)을 받아 데이터를 재전송한다. 2. 전송 데이터 프레임의 분실 : GBN ARQ의 특징은 확인된 데이터 이후의 모든 데이터 프레임 재전송과 수신측의 폐기이다. 수신측에서 데이터 1을 받고 다음 데이터로 3을 받게 된다면 데이터 2를 받지 못했으므로 수신측에서는 데이터 3을 폐기하고 데이터 2를 받지 못했다는 NAK2를 전송측에 보낸다. NAK을 받은 수신측은 기존에 받았던 데이터 중 NAK(n)으로 보냈던 대상 데이터 이후의 모든 데이터를 폐기하고 재전송받는다. .png>) 3. 지정된 타임 아웃 내의 ACK 프레임 분실 : 전송측은 분실된 ACK를 다루기 위해 타이머를 가지고 있다. 또한 전송측에서는 이 타이머의 타임 아웃 동안 수신측으로부터 ACK를 받지 못했을 경우, 마지막으로 ACK된 데이터 이후 부터 재전송한다. .png>) 즉, 이를 정리하자면 - 전송측은 NAK 프레임을 받았을 경우 NAK 프레임 번호부터 데이터를 재전송한다. - 수신측은 원하는 프레임이 아닐 경우, 데이터를 모두 폐기한다. - 타임아웃(ACK 분실)의 경우, 마지막 ACK된 데이터 이후 부터 재전송한다.
- SR(Selective-Reject) ARQ
- - GBn ARQ의 확인된 마지막 프레임 이후의 모든 프레임을 재전송하는 단점을 보완한 기법 - SR QRQ는 손상되거나 손실된 데이터 프레임만 재전송한다. - 그렇기 때문에 **별도의 데이터 재정렬을 수행해야 하며, 별도의 버퍼를 필요로 한다**. - **수신 측에 버퍼를 두어 받은 데이터의 정렬이 필요하다.**
<aside> 💡 혼잡제어
</aside>
- 송신측의 데이터 전달과 네트워크 데이터 처리 속도를 해결하기 위한 기법이다.
- 한 라우터에게 데이터가 몰려 모든 데이터를 처리할 수 없는 경우, 호스트들은 재전송을 하게 되고, 결국 혼잡을 가중시켜 오버플로우나 데이터 손실이 발생한다.
- 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송 속도를 제어하는것이 혼잡 제어의 개념이다**.**
- AIMD(Additive Increase Multicative Decrease)
- - 합 증가/곱 감소 알고리즘이라고 한다. - 처음에 패킷 하나를 보내는 것으로 시작하여 전송한 패킷이 문제없이 도착한다면 Window Size를 1씩 증가시키며 전송하는 방법이다. 만약 패킷 전송을 실패하거나 TIME_OUT이 발생하면 Window Size를 절반으로 감소시킨다. - 이 방식을 사용하는 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만 시간이 흐르면 평형 상태로 수렴하게 되는 특징이 있다. - 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉 , 네트워크가 혼잡해지고 나서야 대역폭을 줄이는(여기서는 Window Size의 크기를 줄이는) 방식이다. .png>)
- Slow Start
- ACK를 받을때마다 Window Size의 크기를 2배씩 늘려나가고, 이후에 혼잡이 감지되면 Window Size 크기를 1로 줄이고, 절반까지는 2배씩 늘리다가 이후부터는 AIMD 방식으로 1씩 천천히 올린다.
-
- AIMD가 네트워크 수용량 주변에서는 효울적으로 동작하지만, 처음 전송 속도를 올리는데 시간이 걸린다는 단점이 있다.
- Slow Start는 AIMD와 마찬가지로 패킷을 하나씩 보내는것부터 시작한다. 이 방식은 패킷이 문제 없이 동작하여 ACK 패킷마다 Window Size를 2배씩 늘린다.
- 혼잡 현상이 발생하면 Window Size를 1로 떨어뜨린다.
- 처음에는 네트워크 수용량을 예측할 수 있는 정보가 없지만 한번 혼잡 현상이 발생하였던 Window Size의 절반까지는 이전처럼 지수 함수 꼴로 Window Size를 증가시키고, 그 이후부터는 완만하게 1씩 증가시키는방식이다.
- 미리 정해진 임계값(threshhold)에 도착할 때 까지 윈도우의 크기를 2배 씩 증가시킨다.
- Slow Start라는 이름을 사용하지만, 매 전송마다 2배씩 증가하기 때문에 전송되어지는 데이터의 크기는 지수함수적으로 증가한다.
- 전송되는 데이터의 크기가 임계 값에 도달하면 혼잡 회피 단계로 넘어간다.<혼잡 회피(Congestion Avoidance)>
-
- 윈도우의 크기가 임계 값에 도달한 이후에는 데이터의 손실이 발생할 확률이 높다.
- 따라서 이를 회피하기 위해 윈도우 크기를 선형적으로 1씩 증가시키는 방법이다
- 수신측으로부터 일정 시간 동안까지 ACK를 수신하지 못하는 경우
- 타임 아웃의 발생 : 네트워크 혼잡이 발생했다고 인식
- 혼잡 상태로 인식 된 경우
- 윈도우의 크기 세그먼트 수를 1로 감소시킨다.
- 동시에 임계값을 패킷 손실이 발생했을 때의 윈도우 크기 절반으로 줄인다.
-
- 혼잡한 상태가 되면 Window Size를 1로 줄이지 않고 절반으로 줄이고 선형 증가시키는 방법이다.
- 빠른 회복 정책까지 적용하면 혼잡 상황을 한 번 겪고 나서는 순수한 AIMD 방식으로 동작하게 된다.
-
- 수신 측에서 패킷을 받을 때 먼저 도착해야 할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보낸다. 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷 순번을 ACK 패킷에 실어서 보낸다.따라서 중간에 패킷 하나가 손실되면 송신측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하게 되면 문제가 되는 패킷을 재전송 할 수 있다.
- 빠른 재전송은 중복된 순번의 패킷을 3개 (3 ACK)받으면 재전송한다. 그리고 이러한 현상이 일어나는 것은 약간의 혼잡이 발생한 것으로 간주하여 Window Size를 절반으로 줄인다.
-
- ICMPv4
- ICMP의 개념
- - IP망에서는 IP 패킷의 목적지만 확인 후 전달하므로 에러 발생 원인이나 네트워크 상태정보를 지원하지 않음 - ICMP는 목적지 호스트에 대한 오류진단을 수행할 때 사용하는 프로토콜 - ICMP는 IP패킷의 정보부에 포함되며 `Ping`과 `Traceroute`에 활용됨 
- 메시지 유형
- | 구분 | 설명 | | --- | --- | | 오류보고메시지 | - IP Datagram의 문제가 발생하였을 때 에러의 유형을 송신측에 전달 - ICMP 메시지 전달과정에서 발생한 오류메시지는 생성하지 않음 - 목적지 도달불가, 시간초과, 파라미터 문제 | | 질의/조회/정보성메시지 | - 네트워크 상태조사를 위한 질의응답 - 송수신간에 양방향으로 질의 응답 - 호스트가 라우터 존재 파악용 메시지 - ech request, echo reply, 라우터 광고 등 라우터 정보 요청 | 1. Destination Unreachable(목적지 도달 불가 메시지) - 해당 목적지에 도달할 수 없음 - 목적지 도달 불가 사유에 따라 다양한 Code로 구성되어 있음 2. Redirection(재지정 메시지) - 라우팅 경로가 잘못되어 새로운 경로를 이전 경유지 또는 호스트에게 알려주는 메시지 3. Neigbor Solicitation and Advertisement(이웃 요청광고 메시지) - IPv4의 ARP 역할 및 특정 호스트로의 전달 가능 여부 검사기능을 하는 메시지 4. Time Exceed(시간 초과) - 타임아웃이 발생하여 IP 패킷이 폐기되었음을 알리는 메시지 - 타임아웃 사유는 Code를 통해 알 수있다. - Code0(Time to Live Exceed in Trainsit) : ip 패킷이 최종 목적지에 도달하기 전에 TTL 값이 0이되어 해당 패킷이 폐기됨을 알리는 메시지 - Code1(Fragment reassembly time exceed) : IP 패킷 재조합과정에서 타임 아웃 발생. 해당 IP 데이터그램이 모두 폐기됨을 알리는 메시지 5. Echo Request(에코 요청 메시지) - Ping 테스트에 사용되는 메시지로 End 노드 간에 네트워크 및 호스트 상태진단을 목적을 ㅗ사용 - 별도의 Code는 없으며 이외의 쿼리 타입들은 거의 사용안함
- ICMPv4 :와 ICMPv6 설명
-  - ICMPv4 에서는 ICMP,IGMP(Internet Group Multicast Protocol), ARP, RARP 프로토콜이 각각 동작함 - ICMPv6 에서는 RARP 기능은 삭제되고 ARP, IGMP 프로토콜을 통합함 - 모든 IPv6패킷 제어 기능이 ICMPv6에 통합 수용됨
- IGMP
- 호스트가 멀티캐스트 그룹 구성원을 인접한 라우터에게 알리는 프로토콜
- IGMP는 TCP/IP 프로토콜 집합이 동적 멀티캐스팅을 수행하기 위해 사용하는 표준 프로토콜
- 이벤트 또는 변화를 알리는데 사용되는 프로토콜
- IGMP 동작
- 1. 그룹 멤버쉽 조사(monitoring) : 멤버쉽 질의 메시지를 보내서 응답을 기다림. 일정 횟수 이상 응답 없으면 라우터는 해당 호스트를 그룹에서 탈퇴시킴 2. 그룹 가입(Joining) : 그룹에 가입하고자 하는 요청을 라우터에 보고 3. 멤버쉽 연속(member continuation) : 계속해서 유지하기 원하는 보고 메시지 4. 그룹 탈퇴(Leaving) : 호스트가 해당 그룹의 멀티캐스트 트래픽을 원치 않으면 leave 메시지 전송
용어 정리
- 버퍼 오버플로우 : 일종의 일시적인 데이터 저장 영역이다. 데이터를 송신하는 측이 수신측에서 처리할 수 있는 속도보다 빠르게 데이터를 보낼 경우, 수신 측의 버퍼는 빠르게 가득차게 된다. 버퍼가 모두 찬 상태에서 추가적인 데이터가 도착하면, 이 데이터는 버퍼에서 넘쳐서 손실이 발생하는데, 이를 버퍼 오버플로우라고 한다.
- 큐 : 데이터를 임시로 저장하고 순서대로 처리하는 자료구조 네트워킹에서는 패킷이 도착하는 순서대로 처리하도록 큐에 저장된다. 큐가 가득 차있을 때 추가로 데이터가 들어오면 패킷 손실이 발생한다.
- 윈도우 : 송신, 수신 스테이션 양쪽에서 만들어진 버퍼의 크기
- ACK(Acknowledgement) : 수신확인
- NAK(Negative Acknowledgement) : 수신실패
- Ping : 다른 네트워크의 다른 호스트와의 연결 상태를 확인하기 위한 도구. Ping은 ICMP를 사용해 대상 호스트에게 Echo Request 메시지를 보낸다. 만약 대상 호스트가 정상적으로 동작한다면 Echo Reply 메시지를 반환한다. 이를 통해 호스트의 접근성과 네트워크 지연 시간을 측정할 수 있다.
- >ping www.google.com Ping www.google.com [172.217.25.164] 32바이트 데이터 사용: 172.217.25.164의 응답: 바이트=32 시간=33ms TTL=56 172.217.25.164의 응답: 바이트=32 시간=33ms TTL=56 172.217.25.164의 응답: 바이트=32 시간=33ms TTL=56 172.217.25.164의 응답: 바이트=32 시간=33ms TTL=56 * 여기서 TTL은 패킷이 라우터를 거칠 수 있는 횟수이다. 라우터를 지날때마다 1씩 감소되며, 0이 되면 패킷은 폐기된다. 172.217.25.164에 대한 Ping 통계: 패킷: 보냄 = 4, 받음 = 4, 손실 = 0 (0% 손실), 왕복 시간(밀리초): 최소 = 33ms, 최대 = 33ms, 평균 = 33ms
- Traceroute : 데이터 패킷이 네트워크를 통해 목적지까지 어떤 경로를 통해 이동하는지 추적하는 도구. ICMP를 사용하여 데이터 패킷이 이동하는 경로를 측정하고 각 점프 사이의 지연시간을 측정한다.
- >tracert www.google.com 최대 30홉 이상의 www.google.com [172.217.25.164](으)로 가는 경로 추적: 1 <1 ms <1 ms <1 ms 192.168.35.1 2 * * * 요청 시간이 만료되었습니다. 3 * * * 요청 시간이 만료되었습니다. 4 * * * 요청 시간이 만료되었습니다. 5 * * * 요청 시간이 만료되었습니다. 6 * * * 요청 시간이 만료되었습니다. 7 * * * 요청 시간이 만료되었습니다. 8 * * * 요청 시간이 만료되었습니다. 9 * * * 요청 시간이 만료되었습니다. 10 * * * 요청 시간이 만료되었습니다. 11 * * * 요청 시간이 만료되었습니다. 12 * * * 요청 시간이 만료되었습니다. 13 * * * 요청 시간이 만료되었습니다. 14 * * * 요청 시간이 만료되었습니다. 15 33 ms 33 ms 33 ms sin01s16-in-f4.1e100.net [172.217.25.164] 추적을 완료했습니다.
- 멀티캐스트 : 방송같이 하나의 소스가 여러 구성원들에게 동시에 송출 IGMP는 그 인원들을 관리하는 도구이다.
참고 자료