인터넷 프로토콜 스위트

IP스택 **인터넷 프로토콜 스위트**(Internet protocol suite) 또는 **TCP/IP**는 인터넷 및 유사한 컴퓨터 망에서 사용되는 통신 프로토콜을 기능적 기준에 따라 조직하기 위한 프레임워크이다. 이 스위트의 기본 프로토콜은 전송 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP) 및 인터넷 프로토콜(IP)이다. 이 네트워킹 모델의 초기 버전은 미국 국방부의 방위고등연구계획국(DARPA)이 연구 개발 자금을 지원했기 때문에 **국방부** (**DoD**) **인터넷 아키텍처 모델**로 알려졌다. 인터넷 프로토콜 스위트는 데이터가 어떻게 패킷화되고, 주소 지정되고, 전송되고, 라우팅되고, 수신되어야 하는지를 명시하는 엔드 투 엔드 데이터 통신을 제공한다. 이 기능은 네 가지 추상화 계층으로 구성되어 있으며, 각 프로토콜의 네트워킹 범위에 따라 모든 관련 프로토콜을 분류한다.11221123 특정 애플리케이션에 대한 계층의 구현은 프로토콜 스택을 형성한다. 가장 낮은 계층부터 가장 높은 계층까지는 단일 네트워크 세그먼트(링크) 내에 남아 있는 데이터의 통신 방법을 포함하는 링크 계층, 독립 네트워크 간의 인터네트워킹을 제공하는 인터넷 계층, 호스트 간 통신을 처리하는 전송 계층, 그리고 애플리케이션을 위한 프로세스 간 데이터 교환을 제공하는 응용 계층이다. 인터넷 프로토콜 스위트 및 그 구성 프로토콜의 기술 표준은 국제 인터넷 표준화 기구(IETF)가 유지 관리한다. 인터넷 프로토콜 스위트는 일반 네트워킹 시스템을 위한 더 포괄적인 참조 프레임워크인 OSI 모형보다 앞서 있다.
# 역사
인터넷의 역사
## 초기 연구
최초의 인터네트워킹 연결 다이어그램 최초의 3자 인터네트워킹 전송에 사용된 [[SRI 인터내셔널 패킷 라디오 밴]] 인터넷 프로토콜 스위트는 1960년대 후반 방위고등연구계획국(DARPA)이 후원한 컴퓨터 망 연구 개발에 뿌리를 두고 있다. DARPA가 1969년 선구적인 아파넷을 시작한 후, 스티브 크로커는 호스트-호스트 프로토콜인 네트워크 제어 프로그램(NCP)을 개발하는 "네트워크 워킹 그룹"을 설립했다.1000 1970년대 초, DARPA는 모바일 패킷 라디오, 패킷 위성 서비스, 근거리 통신망, 그리고 공공 및 사설 영역의 다른 데이터 네트워크를 포함한 여러 다른 데이터 전송 기술에 대한 작업을 시작했다. 1972년, 밥 칸은 DARPA 정보 처리 기술 사무실에 합류하여 위성 패킷 네트워크와 지상 라디오 패킷 네트워크 모두에서 작업했으며, 둘 다를 통해 통신할 수 있는 가치를 인식했다. 1973년 봄, 스탠퍼드 대학교의 빈트 서프는 인터네트워킹을 가능하게 하는 아파넷의 다음 프로토콜 세대를 설계하는 목표를 가지고 칸과 협력하기 시작했다.page=263url-status=live 그들은 서프가 의장을 맡고 아파넷 커뮤니티, 제록스 PARC, 영국 및 프랑스의 연구원들이 포함된 국제 네트워크 워킹 그룹(INWG)을 통해 국제 연구 커뮤니티의 경험을 활용했다.p=3 "The manager of the ARPANET project, Lawrence Roberts, assembled a large team of computer scientists ... and he drew on the ideas of network experimenters in the United States and the United Kingdom. Cerf and Kahn also enlisted the help of computer scientists from England, France and the United States"isbn=978-1-4767-0869-0 1973년 여름, 칸과 서프는 근본적인 재구성 작업을 수행했다. 여기서 로컬 네트워크 프로토콜 간의 차이점은 공통 인터네트워킹 프로토콜을 사용하여 숨겨졌고, 기존 아파넷 프로토콜에서 네트워크가 안정성을 담당하는 대신 이 기능은 호스트에 위임되었다.isbn=978-1-4767-0869-0 서프와 칸은 1974년 5월에 발표된 이 설계에 중요한 영향을 미친 INWG의 여러 회원들에게 공을 돌린다.url-status=live 이 전송 제어 프로그램의 첫 번째 사양은 1974년 12월 서프, 요겐 달랄 및 스탠퍼드 대학교의 칼 선샤인에 의해 작성되었다.675 DARPA는 BBN 테크놀로지스, 스탠퍼드 대학교, 그리고 유니버시티 칼리지 런던과 계약하여 1975년에 여러 하드웨어 플랫폼에서 프로토콜의 운영 버전을 개발하기 시작했다.quote=We began doing concurrent implementations at Stanford, BBN, and University College London. So effort at developing the Internet protocols was international from the beginning. 인터넷 실험 노트(IEN) 시리즈를 통한 논의를 통해 여러 버전이 개발되었다. 처음에는 후속 프로토콜 스위트의 전신인 전송 제어 프로그램이 데이터그램이 아닌 신뢰할 수 있는 바이트 스트림 서비스만 제공했다.url-status=live 프로토콜에 대한 경험이 쌓이면서, 협력자들은 데이터그램 서비스에 직접 액세스할 수 있도록 기능을 별도의 프로토콜 계층으로 분할할 것을 권고했다. 옹호자로는 밥 메트칼프, 요겐 달랄, 제록스 PARC의 존 쇼크가 있었다.url-status=liveurl-status=livewebsite=www.nethistory.info 대니 코헨 (컴퓨터 과학자)는 자신의 패킷 음성 작업에 필요로 했고, 남부 캘리포니아 대학교의 정보과학연구소의 존 포스텔은 인터넷 개발을 문서화하고 촉매하는 기술 및 전략 문서 시리즈인 RFC를 편집했다.Internet Hall of Fame 포스텔은 "우리는 계층화 원칙을 위반함으로써 인터넷 프로토콜 설계를 망치고 있다"고 말했다. 서로 다른 메커니즘의 캡슐화는 상위 계층이 하위 계층에서 필요한 것만 액세스할 수 있는 환경을 조성하기 위한 것이었다. 단일 설계는 유연하지 않고 확장성 문제로 이어질 것이다. 1978년에 작성된 버전 4에서 포스텔은 전송 제어 프로그램을 두 개의 개별 프로토콜로 분리했다. 즉, 비연결 계층으로서의 인터넷 프로토콜(IP)과 신뢰할 수 있는 연결 지향 서비스로서의 전송 제어 프로토콜(TCP)이다.Abbate, Inventing the Internet, 129–30.authorlink=Vint Cerfurl-status=liveTCP/IP 분할로 이어진 논의 기록은 Internet Experiment Notes 인덱스의 Internet Experiment Notes 시리즈를 참조한다. 네트워크 설계에는 최종 노드 간에 트래픽을 효율적으로 전송하고 라우팅하는 기능만 제공해야 하며, 다른 모든 인텔리전스는 네트워크 가장자리, 즉 최종 노드에 위치해야 한다는 인식이 포함되었다. 이 엔드 투 엔드 원칙은 도널드 데이비스 (컴퓨터 과학자)의 아이디어를 기반으로 CYCLADES 네트워크에서 루이 푸진과 휴버트 짐머만에 의해 개척되었다.url-status=livepages=7, 11url-status=deadquote=all users of the network will provide themselves with some kind of error control 이 설계를 사용하여 다른 로컬 특성과 관계없이 동일한 원칙을 사용하는 다른 네트워크를 아파넷에 연결할 수 있게 되었고, 이로써 칸의 초기 인터네트워킹 문제가 해결되었다. 인터넷 프로토콜 버전 4(IPv4)는 1983년 아파넷에 설치되어 인터넷에서 사용되는 네트워크 계층 프로토콜을 형성했다. 처음에는 DOD 인터넷 아키텍처 모델로 불렸으며,pages=307–318 전송 제어 프로토콜과 함께 일반적으로 TCP/IP로 알려지게 되었다.
## 초기 구현
1975년, 스탠퍼드와 유니버시티 칼리지 런던 간에 두 네트워크 IP 통신 테스트가 수행되었다. 1977년 11월, 미국, 영국, 노르웨이의 사이트 간에 3개 네트워크 IP 테스트가 수행되었다. 1978년에서 1983년 사이에 여러 연구 센터에서 다른 IP 프로토타입이 개발되었다.url=https://www.rfc-editor.org/ien/ien151.txt 라우터라는 컴퓨터는 각 네트워크에 인터페이스를 제공한다. 라우터는 그들 사이에서 네트워크 패킷을 앞뒤로 전달한다.1812 원래 라우터는 게이트웨이라고 불렸지만, 다른 유형의 게이트웨이와의 혼동을 피하기 위해 용어가 변경되었다.page=99
## 도입
1982년 3월, 미국 국방부는 TCP/IP를 모든 군사 컴퓨터 네트워킹의 표준으로 선언했다.publisher=TCP Digest (UUCP)ien=207ien=152 같은 해, 노르웨이(NORSAR 및 노르웨이 국방 연구소)와 피터 T. 커스틴의 유니버시티 칼리지 런던 연구 그룹은 이 프로토콜을 채택했다.quote=Mar '82 – Norway leaves the ARPANET and become an Internet connection via TCP/IP over SATNET. Nov '82 – UCL leaves the ARPANET and becomes an Internet connection. 네트워크 제어 프로토콜에서 TCP/IP로의 아파넷 마이그레이션은 새로운 프로토콜이 영구적으로 활성화된 플래그 데이 1983년 1월 1일에 공식적으로 완료되었다.archive-date=1 January 2018 1985년에 인터넷 자문 위원회(인터넷 아키텍처 위원회의 전신)는 컴퓨터 산업을 위한 3일간의 TCP/IP 워크숍을 개최했으며, 250명의 벤더 대표들이 참석하여 프로토콜을 홍보하고 상업적 사용을 증가시키는 계기가 되었다. 1985년에 최초의 인터롭 회의는 TCP/IP의 광범위한 채택을 통한 네트워크 상호 운용성에 중점을 두었다. 이 회의는 초기 인터넷 활동가인 댄 린치에 의해 설립되었다. 처음부터 IBM과 DEC와 같은 대기업이 회의에 참석했다.language=en IBM, AT&T;, DEC는 경쟁하는 사유 프로토콜을 가지고 있었음에도 불구하고 TCP/IP를 채택한 최초의 주요 기업이었다. IBM에서는 1984년부터 배리 애플먼의 그룹이 TCP/IP 개발을 담당했다. 그들은 기업 내부 정치를 헤쳐나가 MVS, VM, OS/2를 포함한 다양한 IBM 시스템을 위한 TCP/IP 제품 라인을 확보했다. 동시에 FTP 소프트웨어 및 울런공 그룹과 같은 여러 소규모 회사들이 도스 및 마이크로소프트 윈도우용 TCP/IP 스택을 제공하기 시작했다.url-status=dead 최초의 VM/CMS TCP/IP 스택은 위스콘신 대학교에서 나왔다.url-status=dead 일부 프로그래머는 초기 TCP/IP 스택 구현으로 유명하다. IBM 리서치의 제이 엘린스키와 올레그 비슈네폴스키는 각각 VM/CMS와 OS/2용 소프트웨어를 작성했다.url=https://kirils.org/skype/stuff/pdf/2012/An_Introduction_to_Computer_Networksweek_one.pdf 1984년에 매사추세츠 공과대학교의 도널드 길리스는 1983-84년에 MIT의 존 롬키가 관리한 IP/패킷드라이버 계층 위에 실행되는 ntcp 다중 연결 TCP를 작성했다. 롬키는 1986년 FTP 소프트웨어가 설립되었을 때 이 TCP를 활용했다.url-status= deadurl-status=live 1985년부터 필 칸은 아마추어 무선 시스템용 다중 연결 TCP 애플리케이션(KA9Q TCP)을 만들었다.Phil Karn, KA9Q TCP Download Website TCP/IP의 확산은 1989년 6월, 캘리포니아 대학교 버클리가 BSD UNIX용으로 개발된 TCP/IP 코드를 공공 도메인에 공개하기로 동의하면서 더욱 가속화되었다. IBM을 포함한 다양한 기업 벤더들은 이 코드를 상업용 TCP/IP 소프트웨어 릴리스에 포함시켰다. 1990년대 전반기에 소비자들 사이에서 지배적인 PC 운영 체제였던 Windows 3.1의 경우, 피터 태텀의 트럼펫 윈속 TCP/IP 스택 출시는 가정 사용자에게 인터넷을 제공하는 데 핵심적인 역할을 했다. 트럼펫 윈속은 직렬 연결(직렬 회선 인터넷 프로토콜 또는 점대점 프로토콜)을 통한 TCP/IP 작동을 허용했다. 당시 일반적인 가정용 PC는 RS-232 포트를 통해 8250 또는 16550 UART와 연결된 외부 Hayes 호환 모뎀을 가지고 있었으며, 이러한 유형의 스택이 필요했다. 나중에 마이크로소프트는 윈도우 포 워크그룹 3.11용 TCP/IP 추가 스택과 Windows 95에 내장 스택을 출시했다. 이러한 사건들은 IBM의 시스템 네트워크 아키텍처(SNA) 및 디지털 이큅먼트 코퍼레이션의 DECnet, 개방형 시스템 간 상호 접속(OSI), 제록스 네트워크 시스템즈(XNS)와 같은 다른 플랫폼을 포함한 마이크로소프트 기반 네트워크에서 TCP/IP의 지배력을 확고히 하는 데 도움이 되었다. 그럼에도 불구하고 1980년대 후반부터 1990년대 초반까지 엔지니어, 조직, 국가들은 어떤 표준, 즉 OSI 모델 또는 인터넷 프로토콜 스위트가 가장 좋고 견고한 컴퓨터 네트워크를 만들 것인지에 대한 문제로 극심하게 분열되었다.url-status=livearchive-date=2019-11-17url-status=live
## 공식 사양 및 표준
인터넷 프로토콜 스위트 및 그 구성 프로토콜의 기술 표준은 국제 인터넷 표준화 기구(IETF)에 위임되었다.language=enarxiv=2003.10279 인터넷 프로토콜 스위트의 특징적인 아키텍처는 핵심 기능을 구성하는 프로토콜의 작동 범위에 대한 광범위한 분할이다. 스위트의 정의 사양은 RFC 1122와 1123이며, 이들은 대략적으로 4개의 추상화 계층 (및 관련 프로토콜)을 설명한다. 즉, 링크 계층, IP 계층, 전송 계층 및 응용 계층, 그리고 지원 프로토콜이다. IETF가 이 구조를 변경한 적이 없기 때문에 이들은 시간의 시험을 견뎌냈다. 이러한 네트워킹 모델로서 인터넷 프로토콜 스위트는 일반 네트워킹 시스템을 위한 더 포괄적인 참조 프레임워크인 OSI 모형보다 앞선다. IPv4 주소 고갈과 같은 문제를 해결하기 위해 후속 인터넷 프로토콜 버전 6(IPv6)이 개발되었다.6214
# 주요 아키텍처 원칙
두 호스트(A와 B)가 각각의 라우터 간 링크로 연결된 간단한 네트워크 토폴로지에서 개념적 데이터 흐름. 각 호스트의 응용 프로그램은 마치 프로세스가 어떤 종류의 데이터 파이프로 서로 직접 연결된 것처럼 읽기 및 쓰기 작업을 실행한다. 이 파이프가 설정된 후에는 통신의 대부분의 세부 사항이 각 프로세스에 숨겨지는데, 통신의 기본 원칙이 하위 프로토콜 계층에 구현되기 때문이다. 비유적으로, 전송 계층에서는 응용 프로그램 데이터 구조와 연결 라우터에 대한 지식 없이 호스트 간 통신으로 나타나고, 인터네트워킹 계층에서는 각 라우터에서 개별 네트워크 경계가 통과된다. RFC 1122에 설명된 계층을 통해 하강하는 응용 프로그램 데이터의 캡슐화 엔드 투 엔드 원칙은 시간이 지남에 따라 발전했다. 원래의 표현은 상태 유지 및 전반적인 인텔리전스를 가장자리에 두었고, 가장자리를 연결하는 인터넷은 상태를 유지하지 않고 속도와 단순성에 집중한다고 가정했다. 방화벽, 네트워크 주소 변환기, 웹 콘텐츠 캐시 등과 같은 실제 요구 사항으로 인해 이 원칙에 변화가 생겼다.url-status=live 견고함의 원칙은 다음과 같이 명시한다. "일반적으로 구현은 전송 동작에 보수적이어야 하며, 수신 동작에 자유로워야 한다. 즉, 잘 구성된 데이터그램을 전송하는 데 주의해야 하지만, 해석할 수 있는 모든 데이터그램을 허용해야 한다(예: 의미가 여전히 명확한 기술적 오류에 대해 이의를 제기하지 않아야 한다)."rp=23 "이 원칙의 두 번째 부분도 거의 마찬가지로 중요하다. 다른 호스트의 소프트웨어에는 합법적이지만 모호한 프로토콜 기능을 악용하는 것이 현명하지 않도록 하는 결함이 포함될 수 있다."rp=13 캡슐화는 프로토콜 및 서비스의 추상화를 제공하는 데 사용된다. 캡슐화는 일반적으로 프로토콜 스위트의 일반 기능 계층으로의 분할과 일치한다. 일반적으로 응용 프로그램(모델의 가장 높은 수준)은 일련의 프로토콜을 사용하여 데이터를 계층 아래로 보낸다. 데이터는 각 수준에서 추가로 캡슐화된다. 초기 아키텍처 문서인 1122와 plainlink=yes, "인터넷 호스트 요구 사항"은 계층화보다 아키텍처 원칙을 강조한다.1958 RFC 1122/23은 계층을 참조하는 섹션으로 구성되지만, 문서들은 다른 많은 아키텍처 원칙을 참조하며 계층화를 강조하지 않는다. 이들은 대략적으로 4계층 모델을 정의하며, 계층들은 숫자 대신 이름으로 다음과 같다.11221123 * 응용 계층은 응용 프로그램 또는 프로세스가 사용자 데이터를 생성하고 이 데이터를 다른 호스트 또는 동일한 호스트의 다른 응용 프로그램과 통신하는 범위이다. 응용 프로그램은 하위 계층에서 제공하는 서비스, 특히 다른 프로세스에 신뢰할 수 있거나 신뢰할 수 없는 파이프를 제공하는 전송 계층의 서비스를 사용한다. 통신 파트너는 클라이언트 서버 모델 및 P2P 네트워킹과 같은 응용 프로그램 아키텍처에 의해 특성화된다. 이 계층은 SMTP, FTP, SSH, HTTP와 같은 모든 응용 프로그램 프로토콜이 작동하는 계층이다. 프로세스는 본질적으로 서비스를 나타내는 포트를 통해 주소 지정된다. * 전송 계층은 로컬 네트워크 또는 라우터로 분리된 원격 네트워크에서 호스트 간 통신을 수행한다.isbn=9781449390785 응용 프로그램의 통신 요구 사항을 위한 채널을 제공한다. 사용자 데이터그램 프로토콜(UDP)은 가장 기본적인 전송 계층 프로토콜로, 신뢰할 수 없는 비연결 데이터그램 서비스를 제공한다. 전송 제어 프로토콜(TCP)은 흐름 제어, 연결 설정 및 데이터의 신뢰할 수 있는 전송을 제공한다. * 인터넷 계층은 네트워크 경계를 넘어 데이터그램을 교환한다. 이는 기본 네트워크 연결의 실제 토폴로지(레이아웃)를 숨기는 균일한 네트워킹 인터페이스를 제공한다. 따라서 인터네트워킹을 설정하는 계층이기도 하다. 실제로 이 계층은 인터넷을 정의하고 설정한다. 이 계층은 TCP/IP 프로토콜 스위트에 사용되는 주소 지정 및 라우팅 구조를 정의한다. 이 범위의 주요 프로토콜은 IP 주소를 정의하는 인터넷 프로토콜이다.url-access=subscriptionurl-access=subscription 라우팅에서의 기능은 데이터의 최종 목적지에 더 가까운 네트워크에 연결성을 가진 다음 홉 라우터 역할을 하는 IP 라우터로 데이터그램을 전송하는 것이다. * 링크 계층은 중간 라우터 없이 호스트가 통신하는 로컬 네트워크 링크 범위 내의 네트워킹 방법을 정의한다. 이 계층은 로컬 네트워크 토폴로지와 다음 이웃 호스트로 인터넷 계층 데이터그램 전송을 수행하는 데 필요한 인터페이스를 설명하는 데 사용되는 프로토콜을 포함한다.url-access=subscription
# 링크 계층
링크 계층의 프로토콜은 호스트가 연결된 로컬 네트워크 연결 범위 내에서 작동한다. 이 체계는 TCP/IP 용어로 링크라고 불리며 스위트의 가장 낮은 구성 요소 계층이다. 링크에는 라우터를 거치지 않고 액세스할 수 있는 모든 호스트가 포함된다. 따라서 링크의 크기는 네트워킹 하드웨어 설계에 따라 결정된다. 원칙적으로 TCP/IP는 하드웨어 독립적으로 설계되었으며 거의 모든 링크 계층 기술 위에 구현될 수 있다. 여기에는 하드웨어 구현뿐만 아니라 가상사설망 및 네트워킹 터널과 같은 가상 링크 계층도 포함된다. 링크 계층은 동일한 링크에 있는 두 개의 다른 호스트의 인터넷 계층 인터페이스 간에 패킷을 이동하는 데 사용된다. 링크에서 패킷을 전송하고 수신하는 프로세스는 네트워크 카드용 장치 드라이버뿐만 아니라 펌웨어 또는 특수 칩셋에 의해 제어될 수 있다. 이들은 프레이밍과 같은 기능을 수행하여 인터넷 계층 패킷을 전송 준비하고, 최종적으로 프레임을 물리 계층 및 매질을 통해 전송한다. TCP/IP 모델에는 인터넷 프로토콜에 사용되는 네트워크 주소 지정 방법을 매체 접근 제어(MAC) 주소와 같은 링크 계층 주소로 변환하기 위한 사양이 포함되어 있다. 그러나 그 수준 아래의 다른 모든 측면은 암시적으로 존재한다고 가정하며 TCP/IP 모델에서 명시적으로 정의되지 않는다. TCP/IP 모델의 링크 계층은 OSI 모델의 2계층에 해당하는 기능을 가지고 있다.
# 인터넷 계층
인터네트워킹은 원본 네트워크에서 대상 네트워크로 데이터를 보내는 것을 필요로 한다. 이 프로세스는 라우팅이라고 불리며, 계층적 IP 주소 지정 시스템을 사용하여 호스트 주소 지정 및 식별에 의해 지원된다. 인터넷 계층은 데이터그램을 적절한 다음 홉 라우터로 전달하여 대상에 추가로 중계함으로써 잠재적으로 다른 IP 네트워크에 위치한 호스트 간에 신뢰할 수 없는 데이터그램 전송 기능을 제공한다. 인터넷 계층은 잠재적으로 여러 네트워크를 가로질러 패킷을 보내는 책임을 진다. 이 기능을 통해 인터넷 계층은 인터네트워킹, 즉 서로 다른 IP 네트워크의 상호 작용을 가능하게 하며, 본질적으로 인터넷을 구축한다. 인터넷 계층은 다양한 전송 계층 프로토콜을 구별하지 않는다. IP는 다양한 상위 계층 프로토콜에 대한 데이터를 전달한다. 이러한 프로토콜은 각각 고유한 프로토콜 번호로 식별된다. 예를 들어, 인터넷 제어 메시지 프로토콜(ICMP)과 인터넷 그룹 관리 프로토콜(IGMP)은 각각 프로토콜 1과 2이다. 인터넷 프로토콜은 인터넷 계층의 주요 구성 요소이며, 네트워크 호스트를 식별하고 네트워크에서 이들을 찾는 두 가지 주소 지정 시스템을 정의한다. 아파넷과 그 후속 인터넷의 원래 주소 시스템은 인터넷 프로토콜 버전 4(IPv4)이다. 이는 32비트 IP 주소를 사용하며 따라서 약 40억 개의 호스트를 식별할 수 있다. 이 제한은 1998년 128비트 주소를 사용하는 인터넷 프로토콜 버전 6(IPv6)의 표준화로 제거되었다. IPv6 생산 구현은 2006년경에 나타났다.
# 전송 계층
전송 계층은 응용 프로그램이 작업별 데이터 교환에 사용하는 데이터 채널을 설정한다. 이 계층은 기본 네트워크와 사용자 데이터 구조 및 정보 교환의 논리와 독립적인 엔드 투 엔드 메시지 전송 서비스 형태로 호스트 간 연결을 설정한다. 전송 계층에서의 연결은 TCP에 구현된 연결 지향 또는 UDP에 구현된 비연결로 분류될 수 있다. 이 계층의 프로토콜은 오류 제어, 세분화, 흐름 제어, 네트워크 혼잡 제어 및 응용 프로그램 주소 지정(포트 번호)을 제공할 수 있다. 응용 프로그램에 대한 프로세스별 전송 채널을 제공하기 위해 이 계층은 네트워크 포트의 개념을 설정한다. 이것은 응용 프로그램이 필요로 하는 각 통신 채널에 대해 특별히 할당된 번호가 매겨진 논리적 구성이다. 많은 유형의 서비스에 대해 이러한 포트 번호는 표준화되어 있으므로 서비스 검색 또는 디렉토리 서비스의 개입 없이 클라이언트 컴퓨터가 서버 컴퓨터의 특정 서비스를 주소 지정할 수 있다. IP는 최선형 전달만 제공하기 때문에 일부 전송 계층 프로토콜은 신뢰성을 제공한다. TCP는 신뢰할 수 있는 바이트 스트림을 제공하는 데 있어서 수많은 신뢰성 문제를 해결하는 연결 지향 프로토콜이다. * 데이터는 순서대로 도착한다. * 데이터는 최소한의 오류를 가지고 있다(즉, 정확성). * 중복 데이터는 폐기된다. * 손실되거나 폐기된 패킷은 재전송된다. * 트래픽 혼잡 제어를 포함한다. 새로운 스트림 제어 전송 프로토콜(SCTP) 또한 신뢰할 수 있고 연결 지향적인 전송 메커니즘이다. TCP와 달리 바이트 스트림 지향이 아닌 메시지 스트림 지향이며, 단일 연결을 통해 다중 스트림을 다중화한다. 또한 멀티호밍을 지원하여 연결 끝이 여러 IP 주소(여러 물리적 인터페이스를 나타냄)로 표현될 수 있어, 하나가 실패하더라도 연결이 중단되지 않는다. 이 프로토콜은 원래 전화 통신 애플리케이션용(IP를 통해 신호 시스템 7을 전송하기 위해)으로 개발되었다. 신뢰성은 고급 데이터 연결 제어(HDLC)와 같은 신뢰할 수 있는 데이터 링크 프로토콜을 통해 IP를 실행함으로써 달성할 수도 있다. 사용자 데이터그램 프로토콜(UDP)은 비연결 데이터그램 프로토콜이다. IP와 마찬가지로 최선형, 비신뢰성 프로토콜이다. 신뢰성은 체크섬 알고리즘을 사용한 오류 검출을 통해 해결된다. UDP는 일반적으로 스트리밍 미디어(오디오, 비디오, 음성 인터넷 프로토콜 등)와 같이 실시간 도착이 신뢰성보다 더 중요하거나, 신뢰할 수 있는 연결을 설정하는 오버헤드가 불균형적으로 큰 도메인 네임 시스템 조회와 같은 간단한 질의/응답 응용 프로그램에 사용된다. 실시간 전송 프로토콜(RTP)은 UDP 위에 사용되는 데이터그램 프로토콜로, 스트리밍과 같은 실시간 데이터를 위해 설계되었다. 주어진 네트워크 주소의 응용 프로그램은 TCP 또는 UDP 포트에 의해 구별된다. 관례적으로 특정 잘 알려진 포트는 특정 응용 프로그램과 연결된다. TCP/IP 모델의 전송 또는 호스트-호스트 계층은 OSI 모델의 4계층, 즉 전송 계층과 대략적으로 일치한다. QUIC은 대안적인 전송 프로토콜로 빠르게 부상하고 있다. QUIC은 기술적으로 UDP 패킷을 통해 전송되지만 TCP에 비해 향상된 전송 연결성을 제공하고자 한다. HTTP/3은 QUIC을 통해서만 작동한다.
# 응용 계층
응용 계층은 하위 프로토콜에 의해 설정된 네트워크 연결을 통해 사용자 서비스를 제공하거나 응용 프로그램 데이터를 교환하기 위해 대부분의 응용 프로그램에서 사용되는 프로토콜을 포함한다. 여기에는 라우팅 프로토콜 및 호스트 구성과 같은 일부 기본 네트워크 지원 서비스가 포함될 수 있다. 응용 계층 프로토콜의 예로는 HTTP(HTTP), 파일 전송 프로토콜(FTP), 간이 우편 전송 프로토콜(SMTP) 및 동적 호스트 구성 프로토콜(DHCP)이 있다.url-status=live 응용 계층 프로토콜에 따라 코딩된 데이터는 전송 계층 프로토콜 단위(예: TCP 스트림 또는 UDP 데이터그램)로 캡슐화되며, 이는 다시 하위 계층 프로토콜을 사용하여 실제 데이터 전송을 수행한다. TCP/IP 모델은 데이터의 포맷 및 표현의 세부 사항을 고려하지 않으며 OSI 모델(프레젠테이션 및 세션 계층)에서와 같이 응용 프로그램과 전송 계층 사이에 추가 계층을 정의하지 않는다. TCP/IP 모델에 따르면 이러한 기능은 라이브러리 및 응용 프로그래밍 인터페이스의 영역이다. TCP/IP 모델의 응용 계층은 종종 OSI 모델의 5계층(세션), 6계층(프레젠테이션), 7계층(응용)의 조합과 비교된다. 응용 계층 프로토콜은 종종 특정 클라이언트-서버 응용 프로그램과 연관되며, 일반적인 서비스에는 IANA에서 예약한 잘 알려진 포트 번호가 있다. 예를 들어, HTTP는 서버 포트 80을 사용하고 텔넷은 서버 포트 23을 사용한다. 서비스에 연결하는 클라이언트는 일반적으로 임시 포트, 즉 트랜잭션 기간 동안에만 무작위로 또는 응용 프로그램에 구성된 특정 범위에서 할당되는 포트 번호를 사용한다. 응용 계층에서 TCP/IP 모델은 사용자 프로토콜과 지원 프로토콜을 구별한다.rsection=1.1.3 지원 프로토콜은 네트워크 인프라 시스템에 서비스를 제공한다. 사용자 프로토콜은 실제 사용자 응용 프로그램에 사용된다. 예를 들어, FTP는 사용자 프로토콜이고 DNS는 지원 프로토콜이다. 응용 프로그램은 일반적으로 엔드포인트 IP 주소 및 포트 번호와 같은 전송 계층 연결의 주요 품질을 인식하지만, 응용 계층 프로토콜은 일반적으로 전송 계층(및 하위) 프로토콜을 통신을 위한 안정적인 네트워크 연결을 제공하는 블랙박스로 취급한다. 전송 계층 및 하위 계층은 응용 계층 프로토콜의 세부 사항에 관심이 없다. 라우터와 네트워크 스위치는 일반적으로 캡슐화된 트래픽을 검사하지 않고 단순히 통로를 제공한다. 그러나 일부 방화벽 및 대역폭 제한 응용 프로그램은 심층 패킷 검사를 사용하여 응용 프로그램 데이터를 해석한다. 한 가지 예로는 자원 예약 프로토콜(RSVP)이 있다.language=en 네트워크 주소 변환#NAT에 영향을 받는 응용 프로그램에 영향을 받는 응용 프로그램이 응용 프로그램 페이로드를 고려해야 하는 경우도 있다.
# 문헌에서의 계층화 진화 및 표현
인터넷 프로토콜 스위트는 일정 기간 동안 자금 지원을 받은 연구 개발을 통해 발전했다. 이 과정에서 프로토콜 구성 요소 및 계층화의 세부 사항이 변경되었다. 또한 업계 협회의 병렬 연구 및 상업적 이해 관계가 설계 기능과 경쟁했다. 특히 국제 표준화 기구의 노력은 유사한 목표를 이끌었지만, 일반 네트워킹의 더 넓은 범위에서 이루어졌다. 표면적으로는 유사하지만 세부 사항에서 크게 다른 두 가지 주요 계층화 학파를 통합하려는 노력은 독립적인 교재 저자들이 약식 교육 도구를 만들도록 이끌었다. 다음 표는 다양한 네트워킹 모델을 보여준다. 계층 수는 3개에서 7개까지 다양하다. {| class="wikitable" |- ! | 아파넷 참조 모델
(RFC 871) ! | 인터넷 표준
(RFC 1122) ! | 인터넷 모델
(시스코 아카데미via=Google Books) ! | TCP/IP 5계층 참조 모델
(코지어록,via=Google Books 코머via=Google Books) ! | TCP/IP 5계층 참조 모델
(앤드루 타넨바움via=Internet Archive) ! | TCP/IP 프로토콜 스위트 또는 5계층 인터넷 모델
(포루잔,via=Google Books 쿠로세url-status=live) ! | TCP/IP 모델
(스탈링스via=Google Books) ! | OSI 모델
(ISO/IEC 7498-1:1994title=ISO/IEC 7498-1:1994 Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model) |- | | 3계층 | | 4계층 | | 4계층 | | 4+1계층 | | 5계층 | | 5계층 | | 5계층 | | 7계층 |- | rowspan="3" | 응용/ 프로세스 | rowspan="3" | 응용 | rowspan="3" | 응용 | rowspan="3" | 응용 | rowspan="3" | 응용 | rowspan="3" | 응용 | rowspan="3" | 응용 | 응용 |- | 표현 |- | 세션 |- | rowspan="2" | 호스트-호스트 | 전송 | 전송 | 전송 | 전송 | 전송 | 호스트-호스트 또는 전송 | 전송 |- | 인터넷 | 인터넷 | 인터넷 | 인터넷 | 네트워크 | 인터넷 | 네트워크 |- || 네트워크 인터페이스 || 링크 || 네트워크 인터페이스 | 데이터 링크 (네트워크 인터페이스) || 데이터 링크 | 데이터 링크 | 네트워크 액세스 | 데이터 링크 |- |빈칸 |빈칸 |빈칸 | (하드웨어) | 물리 | 물리 | 물리 | 물리 |} 일부 네트워킹 모델은 교재에서 가져온 것으로, RFC 1122 및 기타 IETF의 1차 자료의 의도와 충돌할 수 있는 2차 자료이다.3439
# TCP/IP 및 OSI 계층화 비교
OSI 모델의 최상위 3개 계층, 즉 응용 계층, 표현 계층, 세션 계층은 전송 계층 위에 응용 계층만 있는 TCP/IP 모델에서는 별도로 구분되지 않는다. X.400과 같은 일부 순수 OSI 프로토콜 응용 프로그램도 이들을 결합했지만, TCP/IP 프로토콜 스택이 전송 계층 위에 단일 아키텍처를 강요해야 할 필요는 없다. 예를 들어, NFS 응용 프로토콜은 외부 데이터 표현(XDR) 표현 프로토콜 위에서 실행되며, 이는 다시 원격 프로시저 호출(RPC)이라는 프로토콜 위에서 실행된다. RPC는 신뢰할 수 있는 레코드 전송을 제공하므로 최선형 UDP 전송을 안전하게 사용할 수 있다. 다양한 저자들은 TCP/IP 모델을 다르게 해석했으며, 링크 계층 또는 TCP/IP 모델의 어떤 측면이 OSI 계층 1(물리 계층) 문제를 다루는지, 아니면 TCP/IP가 링크 계층 아래에 하드웨어 계층이 존재한다고 가정하는지에 대해 의견이 일치하지 않는다. 여러 저자들은 현대 표준(예: IEEE 및 ITU)에서 일반적으로 언급되기 때문에 OSI 모델의 1계층과 2계층을 TCP/IP 모델에 통합하려고 시도했다. 이는 종종 5계층 모델로 이어지며, 여기서 링크 계층 또는 네트워크 액세스 계층은 OSI 모델의 1계층과 2계층으로 분할된다.language=en-US IETF 프로토콜 개발 노력은 엄격한 계층화에 관심이 없다. 일부 프로토콜은 OSI 모델에 깔끔하게 들어맞지 않을 수 있지만, RFC는 때때로 OSI 모델을 참조하고 종종 오래된 OSI 계층 번호를 사용한다. IETF는 인터넷 프로토콜 및 아키텍처 개발이 OSI 준수를 의도한 것이 아니라고 여러 번 진술했다. 인터넷 아키텍처를 참조하는 RFC 3439에는 "계층화는 해롭다"라는 제목의 섹션이 포함되어 있다.3439 예를 들어, OSI 스위트의 세션 및 프레젠테이션 계층은 TCP/IP 스위트의 응용 계층에 포함되는 것으로 간주된다. 세션 계층의 기능은 HTTP 및 SMTP와 같은 프로토콜에서 찾을 수 있으며, 텔넷 및 세션 개시 프로토콜(SIP)과 같은 프로토콜에서 더 분명하게 나타난다. 세션 계층 기능은 TCP/IP 스위트의 전송 계층에 포함된 TCP 및 UDP 프로토콜의 포트 번호로도 구현된다. 프레젠테이션 계층의 기능은 데이터 교환에서 MIME 표준을 사용하는 TCP/IP 응용 프로그램에서 구현된다. 또 다른 차이점은 라우팅 프로토콜의 처리 방식에 있다. OSI 라우팅 프로토콜 IS-IS는 네트워크 계층에 속하며, 라우터 간 패킷 전송을 위해 CLNS에 의존하지 않고 자체 3계층 캡슐화를 정의한다. 이와 대조적으로, OSPF, RIP, BGP 및 IETF가 정의한 다른 라우팅 프로토콜은 IP를 통해 전송되며, 라우팅 프로토콜 패킷을 송수신하는 목적상 라우터는 호스트 역할을 한다. 결과적으로 라우팅 프로토콜은 응용 계층에 포함된다.1812 컴퓨터 네트워크의 앤드루 타넨바움과 같은 일부 저자는 라우팅 프로토콜이 라우터의 포워딩 프로세스에서 이루어지는 결정에 정보를 제공한다는 이유로 IP와 동일한 계층으로 라우팅 프로토콜을 설명한다. IETF 프로토콜은 일반 라우팅 캡슐화(GRE)와 같은 터널링 프로토콜에서 시연된 것처럼 재귀적으로 캡슐화될 수 있다. GRE는 OSI가 네트워크 계층에서 터널링에 사용하는 것과 동일한 메커니즘을 사용한다.
# 구현
인터넷 프로토콜 스위트는 일반적으로 특정 하드웨어 또는 소프트웨어 환경에 독립적이다. 컴퓨터 네트워크에서 패킷을 송수신할 수 있는 하드웨어와 소프트웨어 계층이 존재해야만 한다. 결과적으로 이 스위트는 본질적으로 모든 컴퓨팅 플랫폼에 구현되었다. TCP/IP의 최소 구현에는 다음이 포함된다. 인터넷 프로토콜(IP), 주소 결정 프로토콜(ARP), 인터넷 제어 메시지 프로토콜(ICMP), 전송 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP), 인터넷 그룹 관리 프로토콜(IGMP).year = 1989 IP, ICMP, TCP, UDP 외에도 인터넷 프로토콜 버전 6는 이웃 탐색 프로토콜(NDP), ICMPv6, 멀티캐스트 리스너 디스커버리(MLD)를 필요로 하며 종종 통합 IPsec 보안 계층이 동반된다.