본문으로 이동

인터넷 프로토콜

한울위키, 우리 모두의 백과사전.
파일:InternetProtocolStack.png

인터넷 프로토콜(IP, Internet Protocol)은 인터넷 프로토콜 스위트에서 네트워크 계층통신 프로토콜로, 네트워크 경계를 넘어 데이터그램을 릴레이한다. 라우팅 기능은 인터네트워킹을 가능하게 하며, 본질적으로 인터넷을 구축한다.

IP는 IP 주소에만 기반하여 소스 호스트에서 목적지 호스트로 패킷을 전달하는 작업을 수행한다. 이를 위해 IP는 전달될 데이터를 캡슐화하는 패킷 구조를 정의한다. 또한 데이터그램에 소스 및 목적지 정보를 레이블링하는 데 사용되는 주소 지정 방법도 정의한다. IP는 1974년 빈트 서프밥 칸이 도입한 원래의 전송 제어 프로그램에서 무연결형 데이터그램 서비스였으며, 전송 제어 프로토콜(TCP)의 기반이 된 연결 지향 서비스로 보완되었다. 따라서 인터넷 프로토콜 스위트는 종종 TCP/IP라고 불린다.

IP의 첫 번째 주요 버전인 인터넷 프로토콜 버전 4(IPv4)는 인터넷의 지배적인 프로토콜이다. 후속 버전은 인터넷 프로토콜 버전 6(IPv6)으로, 2006년경부터 공용 인터넷에서 점차 도입되고 있다.[1]

기능

파일:UDP encapsulation.svg
UDP가 전달하는 애플리케이션 데이터를 링크 프로토콜 프레임으로 캡슐화

인터넷 프로토콜은 호스트 인터페이스 주소 지정, 데이터를 데이터그램으로 캡슐화(단편화 및 재조립 포함) 및 하나 이상의 IP 네트워크를 통해 소스 호스트 인터페이스에서 목적지 호스트 인터페이스로 데이터그램을 라우팅하는 역할을 한다.[2] 이러한 목적을 위해 인터넷 프로토콜은 패킷 형식을 정의하고 주소 지정 시스템을 제공한다.

각 데이터그램에는 헤더페이로드의 두 가지 구성 요소가 있다. IP 헤더에는 소스 IP 주소, 목적지 IP 주소 및 데이터그램을 라우팅하고 전달하는 데 필요한 기타 메타데이터가 포함된다. 페이로드는 전송되는 데이터이다. 헤더가 있는 패킷에 데이터 페이로드를 중첩하는 이 방법을 캡슐화라고 한다.

IP 주소 지정에는 호스트 인터페이스에 IP 주소 및 관련 매개변수를 할당하는 것이 포함된다. 주소 공간은 네트워크 접두사 지정을 포함하는 서브넷으로 나뉜다. IP 라우팅은 모든 호스트와 라우터에 의해 수행되며, 라우터의 주요 기능은 네트워크 경계를 넘어 패킷을 전송하는 것이다. 라우터는 네트워크 토폴로지에 따라 내부 게이트웨이 프로토콜 또는 외부 게이트웨이 프로토콜과 같은 특별히 설계된 라우팅 프로토콜을 통해 서로 통신한다.[3]

주소 지정 방법

라우팅 스킴

파일:Cast.svg

유니캐스트

파일:Unicast.svg

브로드캐스트

파일:Broadcast.svg

멀티캐스트

파일:Multicast.svg

애니캐스트

파일:Anycast.svg

지오캐스트

파일:Geocast.svg

v  d  e  h

인터넷 프로토콜에는 네 가지 주요 주소 지정 방법이 있다:

  • 유니캐스트는 발신자와 수신자 간의 일대일 연결을 사용하여 단일 특정 노드에 메시지를 전달한다. 각 목적지 주소는 단일 수신자 엔드포인트를 고유하게 식별한다.
  • 브로드캐스트는 일대다 연결을 사용하여 네트워크의 모든 노드에 메시지를 전달한다. 한 발신자로부터의 단일 데이터그램 (또는 패킷)은 브로드캐스트 주소와 연결된 모든 잠재적 다중 엔드포인트로 라우팅된다. 네트워크는 브로드캐스트 범위(일반적으로 전체 네트워크 서브넷) 내의 모든 수신자에게 도달하는 데 필요한 만큼 데이터그램을 자동으로 복제한다.
  • 멀티캐스트는 메시지 수신에 관심을 표명한 노드 그룹에 일대다 또는 다대다 연결을 사용하여 메시지를 전달한다. 데이터그램은 단일 전송으로 여러 수신자에게 동시에 라우팅된다. 멀티캐스트는 목적지 주소가 접근 가능한 노드 전체가 아닌 하위 집합을 지정한다는 점에서 브로드캐스트와 다르다.
  • 애니캐스트는 노드 그룹 중 하나, 일반적으로 소스에 가장 가까운 노드에 메시지를 전달한다. 이는 일대일-다수[4] 연결을 사용하며, 데이터그램은 모두 동일한 목적지 주소로 식별되는 잠재적 수신자 그룹의 단일 구성원에게 라우팅된다. 라우팅 알고리즘은 특정 거리 또는 비용 측정에 따라 가장 가까운 것을 기준으로 그룹에서 단일 수신자를 선택한다.

버전 역사

파일:TCP and IP protocols development timeline-en.svg
전송 제어 프로토콜 TCP 및 인터넷 프로토콜 IP 개발 타임라인
파일:First Internet Demonstration, 1977.jpg
1977년 11월 22일 아파넷, PRNET, SATNET을 연결한 첫 번째 인터넷 시연

1974년 5월, 전기전자공학자협회(IEEE)는 "패킷 네트워크 상호 통신을 위한 프로토콜(A Protocol for Packet Network Intercommunication)"이라는 제목의 논문을 발표했다.[5] 이 논문의 저자인 빈트 서프밥 칸네트워크 노드 간의 패킷 교환을 사용하여 자원을 공유하기 위한 인터네트워킹 프로토콜을 설명했다. 이 모델의 중앙 제어 구성 요소는 호스트 간의 연결 지향 링크 및 데이터그램 서비스를 모두 통합한 전송 제어 프로그램이었다. 모놀리식 전송 제어 프로그램은 나중에 전송 계층전송 제어 프로토콜사용자 데이터그램 프로토콜, 그리고 인터넷 계층의 인터넷 프로토콜로 구성된 모듈식 아키텍처로 분할되었다. 이 모델은 국방부(DoD) 인터넷 모델 및 인터넷 프로토콜 스위트로 알려졌고, 비공식적으로는 TCP/IP로 불렸다.

다음 인터넷 실험 노트(IEN) 문서는 인터넷 프로토콜이 현대 버전인 IPv4로 진화하는 과정을 설명한다:[6]

  • IEN 2 Comments on Internet Protocol and TCP (1977년 8월)은 TCP와 인터넷 프로토콜 기능(이전에는 결합되어 있었음)을 분리할 필요성을 설명한다. 이는 버전 필드에 0을 사용하는 IP 헤더의 첫 번째 버전을 제안한다.
  • IEN 26 A Proposed New Internet Header Format (1978년 2월)은 1비트 버전 필드를 사용하는 IP 헤더의 버전을 설명한다.
  • IEN 28 Draft Internetwork Protocol Description Version 2 (1978년 2월)는 IPv2를 설명한다.
  • IEN 41 Internetwork Protocol Specification Version 4 (1978년 6월)는 IPv4라고 불리는 첫 번째 프로토콜을 설명한다. 이 IP 헤더는 현대의 IPv4 헤더와는 다르다.
  • IEN 44 Latest Header Formats (1978년 6월)는 또 다른 IPv4 버전을 설명하며, 이 또한 현대의 IPv4 헤더와 다르다.
  • IEN 54 Internetwork Protocol Specification Version 4 (1978년 9월)는 1980년에 RFC 760으로 표준화될 헤더를 사용하는 IPv4의 첫 번째 설명이다.
  • IEN 80
  • IEN 111
  • IEN 123
  • IEN 128/RFC 760 (1980)

IP 버전 1에서 3은 1973년부터 1978년 사이에 설계된 실험 버전이었다.[7] 버전 2와 3은 1에서 16옥텟(8에서 128비트) 범위의 가변 길이 주소를 지원했다.[8] 버전 4의 초기 초안은 최대 256옥텟(최대 2048비트)의 가변 길이 주소를 지원했지만[9] 나중에 IPv4의 최종 버전에서 고정 크기 32비트 주소로 대체되었다. 이는 인터넷 계층에서 사용되는 지배적인 인터네트워킹 프로토콜로 남아 있으며, 숫자 4는 모든 IP 데이터그램에 포함된 프로토콜 버전을 식별한다. IPv4는 RFC 791(1981년)에 정의되어 있다.

버전 번호 5는 인터넷 스트림 프로토콜에서 사용되었으며, 채택되지 않은 실험적인 스트리밍 프로토콜이다.[7]

IPv4의 후속 버전은 IPv6이다. IPv6는 TP/IX(RFC 1475), PIP(RFC 1621), TUBA(TCP and UDP with Bigger Addresses, RFC 1347)와 같은 다양한 프로토콜 모델이 제안되는 등 수년간의 실험과 대화의 결과물이다. 버전 4와의 가장 두드러진 차이점은 주소의 크기이다. IPv4는 주소 지정에 32비트를 사용하여 약 43억(4.3×109) 개의 주소를 생성하는 반면, IPv6는 128비트 주소를 사용하여 약 3.4×1038 개의 주소를 제공한다. IPv6 채택은 느리지만, 2023년 01월 기준 전 세계 대부분의 국가에서 상당한 IPv6 채택을 보이고 있으며,[10] 구글 트래픽의 41% 이상이 IPv6 연결을 통해 전달되고 있다.[11]

새로운 프로토콜을 IPv6로 할당하는 것은 이전에 IPv6가 사용되지 않았음을 확인하는 실사 작업이 이루어질 때까지 불확실했다.[12] 다른 인터넷 계층 프로토콜에는 7 (IP/TX), 8 및 9 (역사적)와 같은 버전 번호가 할당되었다.[13] 특히, 1994년 4월 1일, IETF는 IPv9에 대한 만우절 RFC를 발표했다.[14] IPv9는 또한 TUBA라는 대체 제안 주소 공간 확장에서 사용되었다.[15] 2004년 중국의 IPv9 프로토콜에 대한 제안은 이러한 것들과 무관한 것으로 보이며 IETF의 승인을 받지 못했다.

IP 버전 번호

버전 번호는 4비트 필드에 담겨 있으므로 0-15 사이의 숫자만 할당할 수 있다.

IP 버전 설명 년도 상태
0 인터넷 프로토콜, v4 이전 해당 없음 예약됨[16]
1 실험 버전 1973 구식
2 실험 버전 1977 구식
3 실험 버전 1978 구식
4 인터넷 프로토콜 버전 4 (IPv4)[17] 1981 활성
5 인터넷 스트림 프로토콜 (ST) 1979 구식; ST-II 또는 ST2로 대체됨
인터넷 스트림 프로토콜 (ST-II 또는 ST2)[18] 1987 구식; ST2+로 대체됨
인터넷 스트림 프로토콜 (ST2+) 1995 구식
6 간단한 인터넷 프로토콜 (SIP) 해당 없음 구식; 1995년에 IPv6에 통합됨[16]
인터넷 프로토콜 버전 6 (IPv6)[19] 1995 활성
7 TP/IX 다음 인터넷 (IPv7)[20] 1993 구식[21]
8 P 인터넷 프로토콜 (PIP)[22] 1994 구식; 1993년에 SIP에 통합됨
9 더 큰 주소를 가진 TCP 및 UDP (TUBA) 1992 구식[23]
IPv9 1994 만우절 농담[24]
중국 IPv9 2004 폐기됨
10–14 해당 없음 해당 없음 할당되지 않음
15 버전 필드 센티넬 값 해당 없음 예약됨

신뢰성

인터넷 프로토콜 스위트의 설계는 CYCLADES 프로젝트에서 차용한 개념인 엔드 투 엔드 원칙을 따른다. 엔드 투 엔드 원칙에 따라 네트워크 인프라는 단일 네트워크 요소 또는 전송 매체에서 본질적으로 신뢰할 수 없는 것으로 간주되며 링크 및 노드의 가용성 측면에서 동적이다. 네트워크의 상태를 추적하거나 유지 관리하는 중앙 모니터링 또는 성능 측정 시설은 존재하지 않는다. 네트워크 복잡성을 줄이는 이점을 위해 네트워크의 지능은 종단 노드에 위치한다.

이 설계의 결과로 인터넷 프로토콜은 최선형 전달만을 제공하며 서비스는 신뢰할 수 없는 것으로 특징지어진다. 네트워크 아키텍처 용어로는 연결 지향 프로토콜과 달리 무연결형 프로토콜이다. 데이터 손상, 패킷 손실 및 중복과 같은 다양한 오류 조건이 발생할 수 있다. 라우팅은 동적이며, 즉 모든 패킷이 독립적으로 처리되고 네트워크가 이전 패킷 경로에 기반한 상태를 유지하지 않으므로, 다른 패킷이 다른 경로를 통해 동일한 목적지로 라우팅되어 수신자에게 순서가 뒤바뀌어 전달될 수 있다.

네트워크의 모든 오류 조건은 참여하는 종단 노드에 의해 감지되고 보상되어야 한다. 인터넷 프로토콜 스위트의 상위 계층 프로토콜은 신뢰성 문제를 해결하는 역할을 한다. 예를 들어, 호스트는 데이터가 애플리케이션에 전달되기 전에 올바른 순서를 보장하기 위해 네트워크 데이터를 버퍼링할 수 있다.

IPv4는 IP 패킷의 헤더가 오류가 없는지 확인하기 위한 안전 장치를 제공한다. 라우팅 노드는 헤더 체크섬 테스트에 실패한 패킷을 폐기한다. 인터넷 제어 메시지 프로토콜(ICMP)은 오류를 통지하지만, 라우팅 노드는 오류를 종단 노드에 통지할 의무가 없다. 반대로 IPv6는 현재 링크 계층 기술이 충분한 오류 감지를 제공한다고 가정하므로 헤더 체크섬 없이 작동한다.[25][26]

링크 용량 및 기능

인터넷의 동적 특성과 구성 요소의 다양성은 특정 경로가 요청된 데이터 전송을 실제로 수행할 수 있거나 적합하다는 보장을 제공하지 않는다. 기술적 제약 중 하나는 주어진 링크에서 가능한 데이터 패킷의 크기이다. 로컬 링크의 최대 전송 단위(MTU) 크기를 검사하는 기능이 있으며, 경로 MTU 탐색을 사용하여 목적지까지의 전체 의도된 경로에 사용할 수 있다.[27]

IPv4 인터네트워킹 계층은 링크 MTU를 초과할 때 데이터그램을 전송을 위해 더 작은 단위로 자동 단편화한다. IP는 순서가 뒤바뀌어 수신된 단편들을 재정렬하는 기능을 제공한다.[28] IPv6 네트워크는 네트워크 요소에서 단편화를 수행하지 않지만, 종단 호스트와 상위 계층 프로토콜이 경로 MTU를 초과하지 않도록 요구한다.[29]

전송 제어 프로토콜(TCP)은 세그먼트 크기를 MTU보다 작게 조정하는 프로토콜의 예이다. 사용자 데이터그램 프로토콜(UDP)과 ICMP는 MTU 크기를 무시하므로 IP가 초과된 데이터그램을 단편화하도록 강제한다.[30]

보안

아파넷 설계 단계와 초기 인터넷에서 공공 국제 네트워크의 보안 측면과 필요성이 충분히 예상되지 않았다. 결과적으로 많은 인터넷 프로토콜이 네트워크 공격과 나중의 보안 평가에서 드러난 취약점을 보였다. 2008년에는 철저한 보안 평가와 문제 해결 제안이 발표되었다.[31] IETF는 추가 연구를 진행 중이다.[32]

같이 보기

각주

  1. The Economics of Transition to Internet Protocol version 6 (IPv6) (영어) (보고서). OECD Digital Economy Papers. OECD. 2014년 11월 6일. doi:10.1787/5jxt46d07bhc-en. 2021년 3월 7일에 원본 문서에서 보존된 문서. 2020년 12월 4일에 확인함. 
  2. Charles M. Kozierok, 《The TCP/IP Guide》, 2019년 6월 20일에 원본 문서에서 보존된 문서, 2017년 7월 22일에 확인함 
  3. “IP Technologies and Migration — EITC”. 《www.eitc.org》. 2021년 1월 5일에 원본 문서에서 보존된 문서. 2020년 12월 4일에 확인함. 
  4. Goścień, Róża; Walkowiak, Krzysztof; Klinkowski, Mirosław (2015년 3월 14일). 《Tabu search algorithm for routing, modulation and spectrum allocation in elastic optical network with anycast and unicast traffic》 (영어). 《Computer Networks》 79. 148–165쪽. doi:10.1016/j.comnet.2014.12.004. ISSN 1389-1286. 
  5. Cerf, V.; Kahn, R. (1974). 《A Protocol for Packet Network Intercommunication》 (PDF). 《IEEE Transactions on Communications》 22. 637–648쪽. doi:10.1109/TCOM.1974.1092259. ISSN 1558-0857. 2017년 1월 6일에 원본 문서 (PDF)에서 보존된 문서. 2020년 4월 6일에 확인함. The authors wish to thank a number of colleagues for helpful comments during early discussions of international network protocols, especially R. Metcalfe, R. Scantlebury, D. Walden, and H. Zimmerman; D. Davies and L. Pouzin who constructively commented on the fragmentation and accounting issues; and S. Crocker who commented on the creation and destruction of associations. 
  6. “Internet Experiment Note Index”. 《www.rfc-editor.org》. 2024년 1월 21일에 확인함. 
  7. Stephen Coty (2011년 2월 11일). “Where is IPv1, 2, 3, and 5?”. 2020년 8월 2일에 원본 문서에서 보존된 문서. 2020년 3월 25일에 확인함. 
  8. Postel, Jonathan B. (February 1978). Draft Internetwork Protocol Specification Version 2. IEN 28. https://www.rfc-editor.org/ien/ien28.pdf. Retrieved 6 October 2022.  보관됨 16 5월 2019 - 웨이백 머신
  9. Postel, Jonathan B. (June 1978). Internetwork Protocol Specification Version 4. IEN 41. https://www.rfc-editor.org/ien/ien41.pdf. Retrieved 11 February 2024.  보관됨 16 5월 2019 - 웨이백 머신
  10. Strowes, Stephen (2021년 6월 4일). “IPv6 Adoption in 2021” (미국 영어). 《RIPE Labs》. 2021년 9월 20일에 원본 문서에서 보존된 문서. 2021년 9월 20일에 확인함. 
  11. “IPv6”. 《Google》. 2020년 7월 14일에 원본 문서에서 보존된 문서. 2023년 5월 19일에 확인함. 
  12. Mulligan, Geoff. “It was almost IPv7”. 《O'Reilly》. 2015년 7월 5일에 원본 문서에서 보존된 문서. 2015년 7월 4일에 확인함. 
  13. “IP Version Numbers”. 《Internet Assigned Numbers Authority》. 2019년 1월 18일에 원본 문서에서 보존된 문서. 2019년 7월 25일에 확인함. 
  14. RFC 1606: A Historical Perspective On The Usage Of IP Version 9. April 1, 1994.
  15. Ross Callon (June 1992). TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing. RFC 1347. https://tools.ietf.org/html/rfc1347. 
  16. Jeff Doyle; Jennifer Carroll (2006). 《Routing TCP/IP》 2판 1. Cisco Press. 8쪽. ISBN 978-1-58705-202-6. 
  17. {{#section:Template:Ref RFC/db/7|rfc791ref}} {{#section:Template:Ref RFC/db/7|rfc791status}}. {{#section:Template:Ref RFC/db/7|rfc791notes}}
  18. {{#section:Template:Ref RFC/db/18|rfc1819ref}} {{#section:Template:Ref RFC/db/18|rfc1819status}}. {{#section:Template:Ref RFC/db/18|rfc1819notes}}
  19. {{#section:Template:Ref RFC/db/82|rfc8200ref}} {{#section:Template:Ref RFC/db/82|rfc8200status}}. {{#section:Template:Ref RFC/db/82|rfc8200notes}}
  20. {{#section:Template:Ref RFC/db/14|rfc1475ref}} {{#section:Template:Ref RFC/db/14|rfc1475status}}. {{#section:Template:Ref RFC/db/14|rfc1475notes}}
  21. {{#section:Template:Ref RFC/db/68|rfc6814ref}} {{#section:Template:Ref RFC/db/68|rfc6814status}}. {{#section:Template:Ref RFC/db/68|rfc6814notes}}
  22. {{#section:Template:Ref RFC/db/16|rfc1621ref}} {{#section:Template:Ref RFC/db/16|rfc1621status}}. {{#section:Template:Ref RFC/db/16|rfc1621notes}}
  23. {{#section:Template:Ref RFC/db/13|rfc1347ref}} {{#section:Template:Ref RFC/db/13|rfc1347status}}. {{#section:Template:Ref RFC/db/13|rfc1347notes}}
  24. {{#section:Template:Ref RFC/db/16|rfc1606ref}} {{#section:Template:Ref RFC/db/16|rfc1606status}}. {{#section:Template:Ref RFC/db/16|rfc1606notes}}
  25. RFC 1726 section 6.2
  26. RFC 2460
  27. Rishabh, Anand (2012). 《Wireless Communication》 (영어). S. Chand Publishing. ISBN 978-81-219-4055-9. 2024년 6월 12일에 원본 문서에서 보존된 문서. 2020년 12월 11일에 확인함. 
  28. Siyan, Karanjit. Inside TCP/IP, New Riders Publishing, 1997. ISBN 1-56205-714-6
  29. Bill Cerveny (2011년 7월 25일). “IPv6 Fragmentation”. Arbor Networks. 2016년 9월 16일에 원본 문서에서 보존된 문서. 2016년 9월 10일에 확인함. 
  30. Parker, Don (2010년 11월 2일). “Basic Journey of a Packet”. 《시만텍》. 시만텍. 2022년 1월 20일에 원본 문서에서 보존된 문서. 2014년 5월 4일에 확인함. 
  31. Fernando Gont (July 2008), 《Security Assessment of the Internet Protocol》 (PDF), CPNI, 2010년 2월 11일에 원본 문서 (PDF)에서 보존된 문서 
  32. F. Gont (July 2011). Security Assessment of the Internet Protocol version 4. RFC 6274. https://tools.ietf.org/html/rfc6274. 

외부 링크

  • 자기 IP 주소 보기
  • Manfred Lindner. “IP Technology” (PDF). 2018년 2월 11일에 확인함. 
  • Manfred Lindner. “IP Routing” (PDF). 2018년 2월 11일에 확인함. 
  • 파일:Commons-logo.svg 위키미디어 공용에 [{{fullurl:Commons:모듈:WikidataIB 508번째 줄에서 Lua 오류: attempt to index field 'wikibase' (a nil value).|uselang=ko}} 인터넷 프로토콜] 관련 미디어 분류가 있습니다.

모듈:Authority_control 159번째 줄에서 Lua 오류: attempt to index field 'wikibase' (a nil value).