Networks Admin

이 장에서는 TCP/IP 구조의 하위층에서 트랜스포트층까지의 프로토콜들에 관하여 알아본다.

그림.3.1에서는 OSI 참조 모델안에서의 이 층들이 나타나있다. 이 구조에 있어서 가장 중심적인 프로토콜인 IP(Internet Protocol)부터 시작한다. 여기서부터 우리는 시스템에서 IP와 함께 하며 전송 매체에 무관한 트랜스포트 프로토콜인 TCP(Transmission Control Protocol), UDP(User Datagram Protocol)까지 한 층씩 올라간다. 마지막으로 ICMP(Internet Control Message Protocol)에 작은 양을 할당하겠다. 필요한 도구들을 갖추었으므로 UNIX 시스템에서 가장 흔하게 사용되는 전송 매체와 그와 관련된 프로토콜에 대해 알아보겠다.

프로토콜의 속성에 대하여 언급함에 있어서 우리는 프로토콜의 헤더(header)의 생성을 기술하고 서로 다른 층에서의 주소 지정에 관하여 기술할 것이다. 그후 실행의 효율을 높이기 위해 사용되는 몇가지 알고리즘들을 고려해 보겠다.

일반적인 내용의 명세

모든 컴퓨터가 동일한 방법으로 데이타를 코드화하는 것은 아니다. 따라서 상이한 코드화 방법을 사용하는 시스템사이에 프로토콜 데이타 항목을 담고 있는 패킷을 교환하는데 있어서 이러한 항목들을 코드화하는데 정규적인 형식을 사용하여야 할 필요성이 있다. 이것은 사용자 데이타 항목에도 역시 마찬가지이다. 이러한 문제는 ONC 프로토콜들에 관한 장에서 XDR 프로토콜을 통하여 자세히 기술할 것이다(⇨9장). 당분간은 다음과 같은 상황에 한하여 생각하기로 하겠다.

TCP/IP 프로토콜의 필드들은 단일 비트들과 정수값들을 포함하며 이들 비트와 바이트의 순서는 big-endian에 따라 정의된다.

여러 바이트들로 이루어진 정수값의 경우 빠른 순서의 바이트들부터 전송된다(그림.3.2).

Internet Protocol

IP(Internet Protocol)은 TCP/IP 구조의 초석이며 RFC 791과 MIL-STD 1777로 명세되어있다. 인터넷 상의 모든 컴퓨터는 IP를 이해한다. IP의 주된 작업들은 스테이션들의 주소를 지정과 패킷의 단편화이다. IP는 종점간의 신뢰성 있는 메세지 전달이나 흐름제어를 위한 기능은 가지고 있지 않다. IP는 이웃 목적 노드로의 전송에 '최선의 시도'를 수행하지만 이것이 반드시 보장되는 것은 아니다. 프로토콜 헤더에 대하여 언급하기 앞서 IP의 주요 속성들을 간단히 정리해 보겠다.

비연결 프로토콜이다.필요시 패킷을 분할, 단편화한다.

32비트의 Internet address를 이용하여 주소를 지정한다.

8비트의 트랜스포트 프로토콜의 주소를 사용한다.

최대 패킷의 크기는 65,535바이트이다.

헤더에 대한 checksum만 가지며 데이타에 관한 checksum은 없다.

항상 필요한 프로토콜 항목 필드가 아닌 경우 선택적으로 사용 가능하다.

유한한 패킷 수명을 가진다.최선의 시도로 전송한다.

프로토콜 헤더의 항목들(그림.3.3)은 다음과 같은 의미를 가진다.

Version number

4비트 크기의 필드로 IP의 버전 번호를 담는다. 현재의 버전은 4이다.

Length

이것은 IP 헤더의 길이를 표시한다. 가장 짧은 길이는 5개의 워드로 구성되며 보통의 경우 대부분의 IP 패킷은 45₍₁₆₎로 시작한다. 선택사항인 항목들이 추가됨에 따라 프로토콜의 헤더의 길이는 증가하며 헤더를 해석하기 위해서는 정확한 길이를 알아야 한다.

Type of service

이 항목은 고정된 규칙에 따라 메세지를 처리하도록 하기위한, IP 프로토콜 장치에 대한 입력을 담고 있다. 그림.3.4에 자세한 이 항목의 자세한 구조를 보였다. 실제로 두 컴퓨터간에는 질적으로 차이가 나는 서로 다른 경로가 존재하는 경우가 거의 없기 때문에 값 0은 거의 항상 사용된다. 게다가 알려진 바에 의하면 어떠한 UNIX IP 구현들도 이 항목을 검토하도록 하지 않는다(이것은 아마도 이 항목을 채워넣을 프로그램 인터페이스가 없기 때문일 것이다).

Packet length

이 항목은 프로토콜 헤더를 포함한 패킷의 길이를 담고 있다. 이 항목은 데이타의 길이를 결정하고 후에 트랜스포트 프로토콜로 건네어진다. 16비트 크기의 항목이므로 IP 패킷은 최대 길이가 65,535(2¹⁶-1)바이트가 된다. IP 명세서는 모든 호스트 컴퓨터는 512 바이트의 데이타와 프로토콜 헤더를 첨가한, 576바이트의 패킷들을 수신하여 재결합할 수 있을 것을 요구한다. 일반적으로 컴퓨터들은 이 보다 더 큰 패킷들을 처리할 수 있는데 최소한 그들이 연결되어 있는 네트워크에서의 최대 크기의 패킷을 처리할 수 있다.

Identification

이것은 송신 호스트에 의하여 생성되는 유일한 식별자이다. 이 항목은 단편들을 재합성하는데 있어 단편들의 연결 조각을 식별하기 위해 사용된다.

Flags

DF(Don't Fragment)와 MF(More Fragment) 두 비트는 단편화의 경우 패킷의 처리를 제어한다. 만약 DF 비트가 세트되면 IP 패킷은 어떠한 상황에서도, 예를 들어 더 이상 전달되지 못하고 버려져야 하는 경우에도 단편화되지 않는다. MF 비트는 더 이상의 추가적인 서브 패킷이 있는 지를 나타낸다. 이 항목의 첫 비트는 사용되지 않는다. 단편화의 알고리즘은 이 장의 뒷부분에서 더 자세히 알아보겠다.

Fargment offset

MF 비트가 세트되었다면 이 항목은 패킷에 든 서브 메세지의 전체 메세지의 시작으로부터의 상대적인 위치를 나타낸다. 수신 호스트는 이 항목을 이용하여 원래의 패킷으로 올바르게 재합성할 수 있다. 위에서 언급한 플래그로 인하여 이 항목은 13비트의 크기를 가진다. 그래서 오프셋은 8바이트 단위로 계산되며 결국 IP 패킷의 최대 길이는 65,535(8*2¹³ - 1)이다.

Time to live

송신 호스트는 패킷이 버려지기까지 얼마나 오랫동안 네트워크상에 존재할 수 있는 지를 확정한다. RFC 791은 이 항목에서 사용되는 단위를 초로 명세하고 있으며 비록 처리 시간이 1초미만이라도 각각 노드는 이 값을 최소한 1 이상 감소할 것을 요구한다. 따라서 TTL은 일반적으로 패킷이 지나갈 수 있는 최대의 노드의 수와 같다. 만약 이 항목이 0의 값을 갖는다면 현재의 처리기에 의해서 이 패킷은 버려져야 한다. 이로서 패킷이 네트워크에서 무한정 회전하는 것을 막을 수 있다. 이 경우 송신 개체는 이 사건(수명이 다한 패킷의 폐기)에 대한 ICMP 메세지를 받게 된다. 대체로 UNIX 시스템은 이 값을 15(4.2BSD)에서 30(4.3BSD)사이의 값으로 설정한다. 4.2BSD에 기반한 오래된 IP 구현에서는 이 항목의 값을 5씩 감소시킨 반면 새로운 버전에서는 단지 1씩만 감소시킨다.

Transport protocol

이 항목은 패킷이 전송되어져야 할 트랜스포트 프로토콜의 ID를 담는다. 예를 들어 TCP인 경우 6을, UDP인 경우 17을, ICMP인 경우 1의 값을 갖는다. 이러한 값들은 NIC에 의하여 결정된다. 현재 대략 50개의 공식적인 상위 프로토콜들이 존재한다. 표.3.1에 현재 번호가 할당되어진 트랜스포토 프로토콜들의 예가 나와있다.

Header checksum

이 항목은 프로토콜 헤더에 대한 체크섬을 갖는다. 이것을 통하여 호스트는 노드들이 잘못된 데이타를 이용하여 작업하는 것을 막을 수 있다. 효율성을 위하여 사용자 데이타에 대한 검사는 하지 않는다. IP 패킷은 모든 노드에서 TTL 항목을 감소시키기 위하여 변경된다. 따라서 체크섬이 매우 효율적으로 생성되는 것이 매우 중요하다. TCP/IP 구조에서는 모든 프로토콜에 Internet checksum이라는 방법이 사용된다. 이것은 검사대상이 되는 데이타를 16비트의 크기의 워드로 나누어 합하고 이것의 결과인 16비트 크기의 값에 대하여 다시 1의 보수를 취하여 얻어진다.

이 알고리즘은 간단하고 빨르다. 이것은 노드들의 효율적인 작동을 위하여 필요한 것이다. 그러나 이 방벙의 에러 감지의 능력은 한정되어 있다. 단순히 덧셈으로만 이루어져 있으므로, 예를 들어 0으로만 이루어진 16비트 워드가 분실되는 경우 이것을 감지할 수 없다. TCP와 UDP의 체크섬은 데이타 항목뿐만 아니라 감지되지 않은 데이타의 분실을 실질적으로 제거하기 위해 다른 항목들(길이, 송신 개체, 수신 개체등등)까지 검사한다.

Source and destination address

32비트 크기의 Internet address가 이 부분에 들어간다.

Options and padding

특별한 작업(네트워크 관리, 보안)등을 위하여 IP 프로토콜의 헤더는 다음에 알아볼 추가사항들을 포함하도록 확장된다. IP 프로토콜 헤더의 크기는 4의 배수가 되도록 하기 위하여 필요한 경우 padding 문자들을 삽입한다.

IP 층에서의 주소 지정

통신에 개입하고 있는 응용 프로그램같은 개체들의 주소를 설정하기 위하여 처음의 4개의 프로토콜 층을 지날 때 4개의 서로 다른 주소가 필요하다.

하위 네트워크의 주소 a subnetwork address(예를 들어 Ethernet address)

인터네트 주소 Internet addss

트랜스포트 프로토콜 주소 Transport protocol address

포트 번호 port number

이들중 Internet address와 Transport protocol address는 IP 프로토콜의 헤더에 포함되어 있다. 이중 더 중요한 것은 Internet address이다. 모든 인터넷 상의 노드들은 하나 이상의 이러한 형태의 주소를 가지며 IP에 의해 제공되는 패킷 전송 서비스는 Internet address 항목을 사용하는 부분을 포함한다.

그림.3.5에 보인 바와 같이 서로 다른 길이의 네트워크와 호스트 식별자(network and host identifier)를 가진 3가지 형식의 주소가 있다. 네트워크 ID는 컴퓨터가 포함되어있는 네트워크를 정의하며, 호스트 ID는 이 네트워크내의 특정 컴퓨터를 지정한다. 모든 비트값이 0(또는 1)인 호스트 ID는 특별한 기능을 수행하기 위해 예약되어 있으며 이를 할당해서는 안된다.

왜 3가지 형식의 Internet address가 필요한가? 그 설명은 간단하다. ARPANET가 시작되었을 때는 단지 소수의 네트워크만을 가정하였기 때문에 class A만 있었다. 그러나 많은 기관에 LAN이 보급되면서 이러한 가정은 더 이상 타당하지 않게 되었고, class B, C의 2개의 다른 형식이 제안되었다(적은수의 호스트를 가진 소규모의 네트워크를 위한 class C, 중간 크기의 네트워크를 위한 class B). 몇 년 동안 class D의 주소를 가진 IP패킷이 동시에 여러 곳으로 배포되는 multicast address에 관한 실험이 이루어져 왔다. 다른 무엇보다도 이런 메커니즘은 어떤 호스트가 특정 그룹의 멤버인지를 확인할 추가적인 프로토콜이 필요하므로 단지 소수의 시스템에서만 제공되고 있다. 좀더 자세한 설명은 RFC 1112에 주어져있다. class E의 주소는 현재 연구 목적으로 예약되어 있다.

Internet address가 네트워크 주소와 호스트 주소로 이루어져 있는 것에는 장단점이 있다.

네트워크내의 호스트에 접근하는 모호하지 않은 기술 방법을 제공한다. 따라서 게이트웨이는 호스트와 네트워크간의 사상표를 관리할 필요가 없다. 결과적으로 주어진 Internet address에 의하여 호스트가 연결된 네트워크를 식별하기 위해 시간을 소비하지

않고 즉각적인 경로 결정이 가능하다.

호스트가 다른 네트워크에 연결된다면 그 Internet address는 달라진다.

호스트가 여러 네트워크에 연결되어 있다면(multi-homing host) 그것은 여러개의 Internet address와 여러개의 이름을 갖게 된다(그림.3.6).

여러개의 연결중에 하나가 고장이 나는 경우 비록 다른 연결들을 통하여 접속이 가능하더라도 고장이 난 Internet address를 통해서는 도달할 수 없다.

Subnetwork routing

커다란 서브네트워크(주: 인터네트워크에 직접 연결된 네트워크를 의미)에서의 경로 배정을 위한 방안이 RFC 950에 제시되어있다. Internet address의 호스트 ID부분은 서브네트워크 ID(주: 여기서 서브네트워크란 앞에서 말한 서브네트워크에 부속되었다는 뜻)와 스테이션 ID로 나누어진다. 서브네트워크 ID는 서브네트워크 내에서, 부속된 네트워크로 경로를 설정하는데 사용된다. 따라서 서브네크워크 밖에서 보았을 때 서브네트워크 전체는 하나의 단위처럼 보인다.

그림.3.7에 8비트의 서브네트워크 ID를 가진 class B의 주소의 예가 나와있다. 서브네트우크 ID의 크기와 위치는 정해져있지 않고 부속된 네트워크의 수와 각각의 부속 네트워크마다의 호스트 수에 의해 결정된다. 그러나 한 서브네트워크 내에서는 네트워크 관리자에 의해 그 크기와 위치가 모든 부속 네트워크들에 대하여 동일하게 결정되어야 한다. 대체로 UNIX 호스트(최소한 4.3BSD에 기초를 두고 TCP/IP를 구현한 경우)는 서브네트워크에서의 경로 배정을 지원한다. TCP/IP 시스템에서는 Internet address에서 어느 비트들이 네트워크 주소를 결정하는지를 알아야한다. 이것은 네트워크 마스크(mask)와 AND 논리 연산을 수행하고 원래 주소부분 중 남아있는 부분과 비교를 하는 작업을 수행하는 ifconfig 를 통하여 이루어진다. 예를 들어 그림.3.7과 같은 주소가 주어졌을 때 네트워크 마스크는 FF.FF.FF.00₍₁₆₎ 가 될 것이다. 만약 서브네트워크 주소가 없는 경우라면 FF.FF.00.00₍₁₆₎ 이 될 것이다.

<>

Internet address 의 실제

실질적으로 class A에서 C까지의 주소들만 사용되고 있다. 그림.3.8에 실제 네트워크에서 사용되는 다양한 형태의 주소가 나와있다. 네트워크 ID는 볼드 타입으로 나타내었다. 나머지 바이트들은 호스트 ID를 포함하고 있다.

호스트가 네트워크에 연결될 때 네트워크 ID와 호스트 ID가 반드시 부여되어야 한다. 만약 호스트가 기존의 네트워크에 연결 되어지는 경우 이 호스트를 위한 Internet address는 네트워크 관리자에 의하여 할당되어져야 하는데 이것은 다른 호스트들과 중복되는 것을 피하기 위한 것이다. 만약 새로운 네트워크를 형성하는 경우에는 인터넷 상의 다른 네트워크와 결합하여 사용되어질 수 있는지의 여부에 주의를 기울여야 한다. 이경우 사후에 주소를 변화시키는 것은 매우 큰 비용이 드는 작업이므로 그 당시 다른 네트워크와 충돌하지 않는 적당한 ID를 선택하는 것이 바람직하다. 이것을 위해 적당한 Internet address를 미리 할당받아 놓고 이를 할당하여 인터넷 연결 서비스를 제공하는 회사에 신청하여야 할 것이다.

네트워크 ID들은 외부적으로 규정되어지는 것들이 아니므로 class A에서 C까지 각각이 모두 사용될 수 있다. 여기서 주목해야할 점은 각 주소 유형별로 주소 지정가능한 호스트의 최대 수이다. Class A는 1600만인데 반해 class C는 255이다. 만일 매우 큰 규모의 네트워크를 계획한다면 부속된 네트워크들&#47000; 주소 지정이 가능한 유형이 선택되어야 할 것이다.

자신에게 Internet address를 할당하는 경우 다음과 같은 사항을 유의해야 한다.

0.0.0.0과 255.255.255.255는 다른 목적을 위하여 예약되었으므로 할당을 피해야 한다.

네트워크 ID 127은 내부의 루프백 네트워크를 위해 예약되어있다.(&#8680;6장)

호스트 ID 0 과 255는 예약되어있다.

단편화(Fragmentation)

어떠한 유형의 네트워크를 통해서라도 패킷을 전송할 수 있도록 하기 위해서 IP는 각각의 네트워크에서의 데이타그램의 크기를 조절할 수 있는 능력이 필요하다. 예를 들어 CCITT X.25에서 패킷은 128바이트보다 클 수가 없다. 하지만 Ethernet 패킷의 경우 1526바이트까지 가능하다. 서브네트워크에서의 데이타의 전송이 효율적이어야 할 조건은 두말할 필요도 없다.

이것은 TCP나 UDP와 같은 트랜스포트 프로토콜에서 작은 크기의 패킷을 생성할 수 있도록 하는 것만으로는 충분하지 않다. 어떤 경우에는 근원지에서 목적지로 향하는 패킷이 서로 다른 크기의 최대 패킷 크기를 요구하는 여러 네트워크를 통과하기도 해야 하며 게다기 동일한 TCP연결 내에서도 패킷마다 이 경로가 변화할 수 있기 때문에 좀 더 유연한 프로시져가 요구되는데 이것이 단편화이다.

단편화란 각 네트워크내의 각 노드의 IP가 수신한 패킷을 다음 노드나 호스트로 전송하기 위해 이 패킷을 분할할 수 있는 능력을 가지는 것을 말한다. 모든 목적지 IP는 단편화된 메세지들을 재합성할 수 있는 능력이 있어야 한다.

단편화 과정(Frgmentation process)

메세지의 단편들은 각각의 완벽한 IP프로토콜 헤더를 가지고 있으며 여기에는 한 메세지의 모든 단편들을 인식하기 위해 사용되는, 본래의 메세지에 대한 식별자를 포하하는 항목을 가지고 있다. 각각의 단편들은 그들의 목적지까지 서로 다른 경로를 따라 도달할 수도 있다.

단편화된 IP 패킷들은 그림.3.9와 같이 도식적으로 표현할 수 있다. 만약 수신 개체가 메세지의 단편을 재전송(진행)하여야하는 경우 각각의 단편들을 변경없이 진행시키거나 전체 메세지로 재합성할 수 있다(물론 두번째의 경우는 수신 개체가 종점간의 연결에서 처럼 모든 단편들이 수신되었다는 것을 확신할 수 있어야한다.) 따라서 어떤 경우에는 다음 네트워크에 더 적합한 크기의 패킷으로 변경가능하다. 만약 근원지의 처리기가, 목적지가 재결합 능력이 없다는 등의 이유로 패킷이 단편화되는 것을 방지하려는 경우에는 IP 프로토콜 헤더의 DF비트를 세트한다.

다음의 예는 단편화의 과정에서 생성되는 다양한 IP 프로토콜 헤더들을 보여준다. 단편의 오프셋의 크기는 8바이트 단위로 계산되는 것에 주의하라. 따라서 마지막 패킷을 제외한 모든 패킷들은 8의 배수 길이의 가진다(예의 경우는 104=8&#8275;13바이트). 20바이트 크기의 IP 프로토콜 헤더와 104바이트의 데이타를 합하여 총 124바이트가 된다.

초기 상태

네트워크 최대 패킷 길이 : 128 바이트

전송하려는 데이타의 바이트 수 : 300 바이트

패킷의 식별번호 : 2354

옵션 없음.

단편화 결과

단편 1 : 길이 124, 오프셋 0, MF = 1, ID = 2354

단편 2 : 길이 124, 오프셋 13, MF = 1, ID = 2354

단편 3 : 길이 112, 오프셋 26, MF = 0, ID = 2354

첫 단편이 목적지에 도달하는 경우 감시 타이머가 작동한다. 타이머가 다른 단편들이 도달하기 전에 종료하는 경우에는 완성되지 않은 메세지를 무시하게 된다. 이것은 단편들이 분실되었을 경우 완성되지 않는 메세지를 위해 불필요하게 버퍼 공간을 할당하는 것을 막기 위해서이다. 그러한 경우에도 송신 개체가 메세지를 전송하려고 하는 경우에는 일반적으로 얼마간의 시간이 지난 후 다시 반복하여 전송한다(에를 들어 TCP에서 억놀리지먼트 타이머가 종료하고 난후). UNIX 시스템의 IP의 재합성 타이머는 일반적으로 30초로 설정되어있다.

Options

IP의 데이타그램에서는 소위 IP 옵션(IP option) 들이 IP 프로토콜 헤더에 추가되어 전송된다. 이런 선택적인 확장은 이들이 거의 사용되지 않는 항목들이라 공간을 예약해 두어야 할 필요가 없기 때문이며 또 이렇게 함으로써 IP 프로토콜 헤터의 크기를 가능한 한도내에서 가장 작게 유지하기 위해서이다. 가능한 IP 옵션들은 다음과 같다.

Source route

IP 프로토콜 헤더 뒤에 데이타그램이 반드시 통과해야하는 Internet address들의 리스트를 덧붙인다. 따라서 특별한 경로를 미리 결정할 수 있다. 여기서 우리는 strict source and record route와 loose source and record route라는 두 형태를 구분하는데 앞의 경우에는 주어진 경로를 정확하게 따라야 하는 반면 뒤의 경우에는 어떤 중간 노드라도 경유할 수 있다.

Record route

데이타그램이 통과한 노드들에게 그들의 Internet address를 전달하도록 한다.

Time stamp

전송 구간에서의 지연을 측정하기 위해 노드를 통과한 시간을 전달하도록 한다.

Security

보안 요구에 맞추어 패킷을 다루기 위한 지시를 담고 있다. 이 옵션은 군사적 목적을 위해 IP에 포함되었으며, 상업적인 것들 중 이것을 지원하는 것은 소수에 지나지 않는다. 이 항목에 대한 보다 최근의 명세는 RFC 1038에서 볼수 있다.

Stream identifier

이것은 아주 오래전에 사용되던 것으로 지금은 무시되어진다.

End-of-option list

옵션 리스트의 끝을 나타낸다.

No operation

옵션 리스트의 길이를 맞추기 위해 사용된다.

옵션 항목들은 옵션 식별자인 단일 바이트로만 이루어지거나 식별자, 길이 데이타의 조합으로 구성되기도 한다. 옵션 항목에 들어가는 내용들은 중간 노드들에 의해 기록되어져야 하기때문에 송신 개체는 IP 프로토콜 헤터의 옵션 데이타를 위한 충분한 공간을 준비해야한다. 이렇게 하여야 IP 프로토콜 헤더가 늘어나거나 옵션 데이타를 기록할 공간을 위해 데이타들을 다른 부분으로 복사하도록 하는 일들이 발생하지 않는다. 이런 경우를 위해 포인터가 옵션 항목내에서 다음으로 이용 가능한 공간을 지시하도록 한다. 보다 자세한 내용은 RFC 791을 참조하시오.

일반적으로 UNIX상에서 구현된 프로토콜들은 위에서 보여준 것 중 security와 stream identifier 항목을 제외한 모든 내용을 지원한다.

RFC 1063에서는 경로상의 최대 전송 단위(Maximum Transfer Unit;MTU)의 하한을 구하기 위한 probe MTU 옵션을 제안하고 있다. 이 정보는 트랜스포트 프로토콜이 최적의 길이의 패킷을 생성하록 함으로써 추가적인 단편화를 방지한다. 이 옵션을 가진 IP 데이타그램이 전송된다고 가정하자. IP 패킷이 통과한 노드들은 다음의 서브 네트워크의 MTU를 이 목적으로 할당된 항목에 이미 기록되어있는 값과 비교하여 더 작은 값인 경우 이 값을 기록한다. 수신 개체는 응답 데이타그램을 생성하여 반환한다. 이 옵션은 앞으로 UNIX 시스템에서 지원될 것으로 보인다.

TCP(Transmission Control Protocol)

TCP는 트랜스포트 층의 프로토콜이다. 따라서 IP보다 상위에 있다. 이것의 주된 작업은 네트워크를 통한, 신뢰할 수 있는 데이타의 전송이다. TCP는 RFC 793와 MIL-STD 1778에 명세되어 있다. IP 프로토콜 헤더에서 TCP의 트랜스포트 주소는 6이다. TCP의 속성을 간략히 말하면

전이중의 양방향의 가상 회선을 제공한다.

사용자의 입장에서 볼 때 데이타는 블록이 아니라 데이타의 스트림의 전송된다.

다음과 같은 기법을 이용하여 신뢰할 수 있는 전송을 보장한다.

- 순선번호(sequence number),

- 수신 개체의 억놀리지먼트를 포함한 체크섬 형식

- 시간 할당에 의한 억놀리지먼트

- 시간 할당 억놀리지먼트후의 재전송.

효율성의 향상을 위한 sliding-window 원리

긴급 데이다(Urgent data)와 push function

깨끗한 연결 해제

TCP의 기능들은 블럭의 경계가 유지되지 않는다는 것을 제외하고는 다른 복잡한 트랜스포트 프로토콜과 그다지 많이 다르지 않다. 작업 방식에서의 이 차이는 TCP의 바이트 지향적인 특성에 기인한 것이다. 프로토콜에서 사용되는 거의 모든 항목들이 블럭이 아니라 바이트 단위로 계산된다. 이것은 블럭의 크기 결정을 유연하게 할 수 있도록 하여준다. 데이타는 블럭(TCP의 용어로는 세그먼트(segment))들의 형태로 전송된다. 네트워크에서의 세그먼트의 크기는 네트워크의 부하, 윈도우의 크기 또는 상대편의 자원과 같은 인자들에 의해 결정된다. 따라서 이러한 가변적인 크기의 세그먼트들에 있어서 처음 사용자에 의해 생성되었던 것처럼 블럭들을 유지하는 것은 비용이 많으드는 작업이 된다. 또한 트랜스포트 층에서 블럭의 경계를 유지해야할 절대적인 필요성이 없으며 이것은 다른 층의 기능에 의해서 수행되어질 수 있다는 것이 경험적으로 알려졌다(예를 들어 세션 층).

그림.3.10에 TCP 프로토콜 헤더의 구조를 보였다. 포함되어있는 항목들은 다음과 같은 필요성들을 가진다.

Source and destination port numbers

각각 16비트 크기의 이 두 항목은 가상 회선의 양끝의 종점을 지정한다. 포트 번호가 왜 중요한 지를 나중에 더 자세히 살펴보겠다.

Sequence and acknowledge numbers

각각 32비트 크기를 갖는 이 두항목은 각 데이타가 연결이 설정되어있는 동안 교환되는 데이타의 전체 흐름에서 어느 위치에 해당하는 지를 나타낸다. Sequence number는 송신 방향에서의 순서를 나타내고 acknowledge number 는 반대편에서 수신되는 바이트들의 순서에 적용된다. 일단 연결이 설정되면 TCP연결에 참여하는 양 종점 개체는 초기 순서번호(sequence number)를 생성하는데 이 값은 해당 패킷이 네트워크 상에 남아있는 동안(IP time to live)에는 반복되지 않는다. 이 값들은 연결 설정시 교환되며 승인된다. 데이타의 전송시 송신 개체는 순서 번호를 앞서 송신한 바이트의 수만큼 증가시킨다. Acknowledge number는 수신 개체가 얼마만큼의 데이타를 정확하게 수신하였는지를 표시한다. 2³²이라는 크기의 범위는 순서 번호가 다 사용되고 다시 0에서부터 사용되더라도 중복되지 않을 만큼 큰 범위를 제공할 수 있다.

Data offset

이 항목은 32비트 크기의 단위로 TCP 프로토콜 헤더의 크기를 나타내며 따라서 데이타 영역의 시작을 판단하는데 사용된다.

Flags

여기서 사용되는 비트들은 TCP에서의 특정 작업을 유발한다. 각 비트들이 1로 설정되었을 때의 의미가 표.3.2에 나타나있다.

Window size

이 항목은 수신 개체가 해당 연결에 할당된 버퍼로 받아들일 수 있는 데이타의 바이트 수를 담고 있다(receive window). 목적지 TCP는 데이타의 흐름을 제어하기 위해 이 항목을 사용한다. 예를 들어 윈도우의 크기를 0으로 설정함으로써 근원지 TCP를 효과적으로 정지시킬 수 있을 것이다. 윈도우의 크기를 단계적으로 증가시킴으로써 데이타의 흐름은 재개될 수 있다. 최대 윈도우 크기는 4.2BSD에서는 2048바이트, 4.3 BSD에서는 4096바이트이다. 데이타 전송중 최적의 윈도우 크기를 판단하는 것은 TCP를 구현하는 알고리즘들 중에서 가장 복잡한 것들 중 하나이다.

Checksum

체크섬은 프로토콜 헤더, 데이타, 그리고 가상 헤더(pseudo header)에 적용된다. 앞으로 언급할 다른 모든 프로토콜들처럼, IP 체크섬을 생성시키는 알고리즘이 여기서도 사용된다.

그림.3.11에 있는 가상 헤더처럼, IP 프로토콜 헤더의 몇개의 항목이 데이타 항목과 함께 트랜스포트 프로토콜에 전달된다. 이 항목들은 TCP 체크섬 계산에 포함된다. 이 가상 헤더는 포함된 항목의 정보를 제공할 뿐만아니라 IP에 의해 패킷이 잘못 전송되는 것을 방지하게 된다. 또한 패킷의 길이 항목을 이용하여 IP 체크섬에서 발견되지 않은 데이타의 분실도 검사할 수 있다.

송신 개체에서는 TCP 체크섬을 생성할 때 가상 헤더를 함께 생성하여 체크섬에 포함시킨다. 그러나 가상 헤더에 들어있는 데이타들은 TCP 세그먼트에 위와 같은 형태로 포함되어 전송되어지는 것은 아니다.

Urgent pointer

Sequence number와 함께 이것은 데이타의 위치에 대한 포인터이다. 이 포인터가 가리키는 데이타 바이트는, 이어지는 데이타가 중요한 것임이 식별된 상황에서, 그 긴급한 메세지의 마지막 바이트이다. 이러한 기능을 긴급 데이타(urgent data)라 부른다. 이러한 장치는 다소 생소하고 복잡한 것이기 때문에 이 기능의 자세한 내용과 응용에 관하여 이후에 따로이 언급할 것이다.

Options

TCP는 3개의 옵션만을 가지고 있다: End-of-Option List, No Operation and Maximum Segment Size. 마지막 옵션은 536바이트보다 큰 세그먼트들을 수신할 준비를 하도록 지시하기 위해 연결 설정시 보내어진다. 대체로 UNIX 시스템은 세그먼트의 크기를 1024바이트(4.2BSD)에서 최대 네트워크 패킷 길이(4.3BSD)까지의 값에서 정한다.

Port numbers

앞서 살펴본 바와 같이 포트 번호들은 트랜스포트 레벨에서의 주소지정을 위하여 사용된다. 포트 번호는 16비트의 크기를 가지기 때문에 한 호스트는 이론적으로 65,535 개의 서로 다른 TCP 연결을 동시에 가질 수 있다.

UDP도 포트 번호를 주소 지정을 위해 사용한다. 그러나 TCP와 UDP는 각각 자신의 주소 공간을 가지고 있다. 따라서 TCP에서의 511이라는 포트 번호는 UDP에서의 511이라는 포트 번호와 동일하지 않다. 유용한 포트 번호의 범위는 호스트에 따라 제한된다. 네트워크 ID, 호스트 ID와 함께 포트 번호를 통하여 전화 설비의 확장과 유사하게 (표.3.3) 통신의 양 종점(또는 socket)을 판단하게 된다.

TCP상에서의 연결의 설립은 전화시스템처럼 진행된다. 이쪽 또는 저쪽에 수동적인 개체(전화를 받는 사람)가 있으며 다른 편에는 능동적인 개체(전화를 거는 사람)이 존재한다. 두개의 프로그램이 서로 간에 통신을 시작하기 전에 양편은 통신의 양 종점을 초기화하는데 이때 주소들이 각 층들의 프로토콜 헤더들에 의해 사용된다. 그들이 서로 연결이 되어지기 위해서는 수동적인 개체의 주소가 능동적인 개체에게 알려져 있어야 한다. 따라서 양 개체는 연결을 설정하기 이전에 수동적인 개체(server)가 연결을 대기하는 포트 번호에 대하여 합의를 이루어야 한다. 능동적인 개체(client)의 포트 번호는 server가 client를 위한 특별한 포트 번호를 지정하지 않는한 아무런 관게가 없다.

TELNET이나 FTP와 같은 TCP/IP의 응용들은 잘 알려진 포트 번호에 의해 이용가능한 고정된 서비스로 여길 수 있다. TCP/IP의 세계에서 이러한 번호들은 소위 잘 알려진 포트 번호(well-known port number) 로 불린다. 그러면 우리는 모든 서비스는 자신의 고정된 포트 번호를 가져야 하며 client는 이 포트 번호에서 서비스를 제공하는 server의 주소를 지정하여야 한다고 말할 수 있을 것이다.

표.3.4에는 UNIX 시스템에서 이용가능한 서비스들의 예가 그들의 포트 번호와 해당 프로토콜과 함께 나와있다. 이들과 또 다른 자세한 서비스들은 /etc/services에서 볼 수 있다. 앞으로 살펴보겠지만 rlogin과 rwhod는 동일한 포트 번호를 사용한다. 그러나 하나는 TCP, 다른 하나는 UDP에서 수행되므로 그들은 서로 충돌없이 작업을 수행한다. 반면에 NFS portmap 프로그램의 경우에는 동일한 서비스가 양 프로트콜상에서 제공되며 단순화 시키기 위해 동일한 포트 번호가 사용된다. 다수의 프로토콜들에 대한 운용은 실제적으로 server 그 자체 내에서 구현되는데 이것은 server가 사용되어지는 각 프로토콜에 대한 통신의 종점을 열기 때문이다.

Sliding window

TCP는 sliding-window 원리에 따라 수행된다(그림.3.12): 연결상의 각 개체는 윈도우에 의해 설정된 수 만큼의 바이트를 상대편으로부터의 인가를 기다리지 않고 전송할 수 있다. 전송 도중에 상대편에 의해 수신된 데이타의 수신 acknowledgement가 동시에 수신될 수 있다. 이것은 송신 개체가 각 세그먼트에 대응하는 acknowledgement를 기다리지 않아도 됨을 의미한다.

윈도우 장치를 가지지 않은 간단한 프로토콜은 주어진 시간에 한 블록의 데이타를 전송하고 다른 블럭을 전송하기 앞서 acknowledgement를 기다린다. 이것은, 예를 들어 수초의 지연 시간을 갖는 위성 통신에서 만족할 만한 데이타 처리율을 제공하지 못한다는 것은 명백하다. 그리고 유용한 전송 대역이 낭비된다. 전송-승인 과정이 동시에 이루어질 수 있다면 큰 지연 시간을 가지는 서브 네트워크에서도 최적의 처리율을 이루는 병렬성을 얻을 수 있다.

Urgent data

ISO 트랜스포트 프로토콜들과 같은 다른 프로토콜들은 급송 데이타(expedited data)라는 특징적인 요소를 가지고 있다. 이것은 정상적인 데이타 흐름을 뛰어넘어('out-band') (일반적으로 제한된 길이를 가진) 긴급한 메세지를 반대편의 통신 개체에게 전달할 수 있는 가능성을 제공한다. 이러한 기능은 일반적으로 비정상적인 상태를 알리는데 사용된다(예를 들어 프로그램의 중단 등).

긴급 데이타(urgent data, 그림.3.13)는 이와 다른 장치이다. 그러나 종종 expedited data과 잘못 비교되기도 한다. Expedited data와 달리 이 경우에는 긴급한 메세지가 우선적으로 전송되지 않는다. 대신 TCP는 수신 응용 개체에게 즉시 읽어야 하는 중요한 데이타가 데이타 흐름의 어는 특정한 위치('in-band')에 있음을 알려준다. Urgent pointer는 이전 데이타의 마지막 바이트를 가리키며 이어지는 바이트가 긴급 메세지의 시작임을 알려준다. 그리고 수신하는 응용 개체는 urgent pointer 다음에 이어지는 데이타를 읽기 시작한다.

UNIX 시스템에서는 긴급한 데이타를 수신하였음을 응용 개체에게 알리는 신호(signal)가 보내어질 수 있다.

Urgent-data 장치는 특별히 TELNET를 위한 고안된 것이다. TELNET client는 synchc 메세지를 전송하기 위해 이것을 이용하는데, 이 메세지는 TELNET server로 하여금 큐에 들어있는 모든 데이타를 무시하고 TELNET 프로토콜 명령문을 찾도록 명령하는 것이다. 이러한 방법에 의해 비록 TELNET server가 긴급한 명령문 이전의 입력 데이타들을 모두 처리하지 않았더라도 명령문이 강제적으로 처리되어질 수 있다.

TCP scenarios

여기서는 TCP가 연결에 있어서 가장 중요한 단계들, 즉 연결의 확립, 데이타 교환, 연결의 종료에서 어떻게 프로토콜 헤더의 항목들을 이용하는지를 3단계로 나누어 알아보겠다. 그림에서 화살표는 세그먼트의 전송 방향을 나타내며 TCP 프로토콜 헤더의 항목들은 괄호로 묶어 표시하였다.

그림.3.14은 연결을 보여준다. 여기서는 소위 three-way handshake를 방법이 사용되는데, SYN 플래그애 의해 활성화된 각 개체는 상대편이 보낸 sequence number를 1 증가시킴으로써 반드시 승인을 하여야한다. TCP A의 sequence number (SEQ = 100)에 대한 응답으로 TCP B는 acknowledgement (ACK = 101)이 전송함을 알 수 있다. 그 반대방향도 마찬가지이다. ACK 플래그는 acknowledgement 항목이 유효함을 나타낸다.

그림.3.15는 두 방향에서 동시에 발생하는 데이타 교환을 보여준다. 목적지는 SEQ 항목(SEQ = 101)에 들어있는 값과 수신한 데이타의 바이트 수(DATA = 5)를 더한 결과를 ACK 항목에 넣어서(ACK = 106) 수신 결과를 알린다. 데이타는 acknowledgement와 함께 반대 방향으로 전송되며 동일한 방법에 의해 수신 결과를 통보받는다.

그림.3.16은 TCP A에서 FIN 플래그를 전송함으로써 연결이 종료되는 과정을 보였다. TCP B는 응답 세그먼트의 acknowledgement항목에 수신한 세그먼트의 sequence number를 1 증가한 값을 넣어 보냄으로써 FIN 플래그에 대하여 승인하게 된다. 이것은 그시점까지 TCP A에 의해 보내어진 모든 데이타가 수신되었음을 알리는 것이다. 그후 TCP A는 더 이상의 데이타를 보내지 않는다. 그러나 TCP B는 자신이 FIN 플래그를 전송할 &#39105;까지 데이타의 전송을 계속한다.

연결을 확립하는 동안에는 한쪽 개체는 능동적이고 다른 쪽은 수동적이지만 데이타 교환이나 연결의 종료시에는 양 개체가 동일한 권한을 가지게된다.

Timer

모든 프로토콜들에 있어서 프로토콜의 요소들뿐만 아니라 알고리즘과 이와 관련된 기능들도 주요한 관심거리이다. 따라서 모든 프로토콜들은 여러 상이한 기능들을 감시하기 위해 타이머를 사용한다. 여기서는 TCP에서의 이러한 타이머들의 기능에 대하여 자세히 알아보겠다.

Retransimission timeout

RTO(Retransmissiom Timeout)은 TCP 패킷의 전송 후, 그 승인 세그먼트의 수신까지 걸리는 시간이 미리 설정한 시간 간격을 초과하는지를 알아보기 위해 측정되어진다. 이 경우 패킷은 재전송되어야 한다. 실제에 있어서 이 시간 간격은 고정된 것이 아닌데, 고정된 시간 간격을 가지고서는 서로 다른 지연 시간을 갖는 네트워크들 사이에서 TCP가 작업을 할 수가 없기때문이다. 예를 들어 Ethernet와 다수의 게이트웨이를 가진 병렬 연결을 비교하면, 그 비율이 천단위의 값을 가진다. 따라서 TCP의 모든 패킷에 대하여 전송과 승인 세그먼트의 수신 사이의 시간(Round Trip Time, RTT)이 측정되어진다. 이 값은, 극값을 제거하고 증가하거나 감소한 지연시간에 단계적으로 대응하도록 조절하는 공식에 대입되어진다. 이 결과로 얻어지는 것이 세그먼트 교환에서 발생하는 지연시간의 평균인 SRTT(Smoothed Round Trip Time)이다. 이 시간값은 지연의 예측에 사용하기 위해 또 다시 일정 기준에 따라 변환된다.

그림.3.17은 RFC 793에 명세되어있는 두 공식을 보여준다. 재전송이후 재전송 타이머는 다시 측정을 개시하며 RTO는 대체로 12배까지 지수적으로 증가한다. 이러한 증가가 아무런 효과를 얻지 못하는 경우 연결이 훼손되었을 것이라고 추측되어진다.

Persistence timer

TCP상의 데이타의 교환에 있어서 이론적으로 수신 윈도우의 크기가 0이되고 윈도우를 재개 시키려는 세그먼트가 동시에 분실되는 것이 가능하다. 결과적으로 양 TCP개체는 무한대기 상태에 빠지게된다. 이러한 사태에 대한 대책이 persistence timer인데, 이것은 일정한 시간간격으로 상대편인 수신개체가 다시 준비상태가 되었는지를 검사하는 작은(1바이트) TCP 세그먼트를 전송한다. 앞서 말한 것처럼 윈도우의 크기가 0이고 음의 억놀리지먼트(acknowledgement)가 돌아오는 경우 또는 윈도우의 크기는 이보다 큰 값을 가지는 경우에는 양의 억놀리지먼트가 돌아온 이후에 새로운 데이타를 전송하기 시작한다.

Quiet timer

TCP의 설계자들은 매우 신중한 사람들로서 그들은 이미 사용되어진 TCP 세그먼트가 네트워크에 남아서 발생시킬 수 있는 연결상의 혼란을 방지하고자 하였다. 따라서 TCP 연결의 종료이후 MSL(Maximum Segment Lifetime)의 2배의 시간이 경과한 후에만 포트 번호가 사용가능해지도록 하였다. MSL은 IP에서 사용되는 TTL항목에 해당한다.

UNIX 사용자들은 연결의 종료직후 동일한 상대편(즉 동일한 포트 번호)과 연결을 재개하는 경우 이 대기 시간을 확인할 수 있다. 시스템은 사용자에게 포트 번호가 여전히 작업중임을 알려준다. 새로운 연결의 설정은 대략 30초 정도가 지나야 가능하다.

Keep-alive timer and idle timer

여기서는 우리는 원래의 TCP 명세에서는 볼 수 없었지만 UNIX 시스템에서 구현된 2개의 타이머에 대하여 알아보겠다. 이 두개의 타이머는 서로 연관이 되어있다. Keep-alive timer는 상대 TCP로의 연결이 여전히 존재하는지를 검사하기 위해 일정한 시간간격동안 빈 패킷을 전송한다. 상대 TCP가 응답하지 않는 경우 idle timer가 종료한 이후 연결을 제거한다. 응용 프로그램은 socket 인터페이스의 KEEP-ALIVE 옵션을 이용하여 이 타이머를 활성화시킨다.

타이머에 주어진 값들이 표.3.5에 나타나있다. 타이머의 지속 시간은 주어진 값으로 항상 설정되는 것이 아니라 개개의 TCP의 개체들에 따라 서로 다른 값을 가진다. 위에서 보여준 값들은 4.3BSD과 그 이전의 UNIX시스템의 TCP들의 구현에서 얻어진 것이다.

효율 향상을 위한 알고리즘

명세를 따르는 TCP의 구현과 UNIX 시스템들에서 볼 수 있는 매우 높은 수준의 최적화를 이룬 TCP 서브 시스템들은 매우 상이하다. UNIX의 TCP구현은 근래에 셀 수 없을 정도의 많은 개선을 이루었고 새로운 알고리즘들이 4.2BSD와 4.3BSD에 포함되어졌다.

Acknowledgement delay

이것은 이미 4.2BSD에 포함되어있던 오래된 유용한 기법이다. 일반적으로 목적지 TCP는 세그먼트를 수신한 이후 응답 세그먼트를 즉시 전송하는데 이 응답 세그먼트는 윈도우의 크기를 줄이고 수신한 데이타에 대한 억놀리지먼트를 담당한다. 수신 프로세스에 의해 데이타가 복사된 후 시스템의 데이타 버퍼는 재사용을 위해 반납되며 윈도우의 크기를 증가시키기 위한 세그먼트가 전송된다. 프로그램이 데이타를 처리하고 나면 대부분 잠시후 응답이 뒤따른다. 따라서 하나의 트랜잭션(transaction)은 세개의 세그먼트가 필요하다.

TELNET에서 처럼 많은 경우에 있어 억놀리지먼트 세그먼트를 10분의 2초정도 지연하는 것이 유익하다는 것이 알려져왔다. 이 짧은 시간후에 3개의 모든 정보(윈도우 크기, 억놀리지먼트, 응답)가 하나의 세그먼트에 담겨져 전송될 수 있다. 높은 처리율을 요구하는 데이타 전송의 속도를 늦추지 않기 위해서 윈도위의 크기가 최소 35%또는 2개의 최대 세그먼트 이상 변화하는 경우 이러한 지연은 생략할 수 있다.

Silly window syndrome avoidance

어떤 상황에서는 전송되는 수신 윈도우의 항목이 너무 작아서 네트워크와 컴퓨터가 많은 수의 억놀리지먼트에 의해 과부하 상태가 될 수 있다. 이것을 방지하기 위해 수신 윈도우는 충분한 공간이 사용가능한 경우(데이타 버퍼또는 최대 세그먼트의 4분의 1이상)에만 확장될 수 있도록한다. 반대로 전송하는 TCP 개체는 기존의 방법대로 작업하되 윈도위의 크기가 충분히 큰 경우에만 전송하도록한다.

Nagle algorithm or samll packet avoidance

개발자인 John Nagle의 이름을 딴 이 알고리즘은 작은 크기의 TCP 세그먼트의 전송을 방지하도록 시도한다. 이경우, 응용 프로그램으로부터 작은 크기의 단위로 TCP에 데이타가 전달될 때 어떻게 그 형태대로 전송되는 것을 막을 것인가가 문제이다. 첫 세그먼트는 즉시 전송되며 그 다음의 데이타는 최대 크기의 세그먼트를 전송할 수 있게 되거나 첫 세그먼트에 대한 억놀리지먼트가 도착할 때 까지 버퍼에 저장되어진다. 이러한 알고리즘은 응용 프로그램이 많은 수의 작은 크기의 메세지를 (예를 들어 X 윈도우 시스템) 응답의 수신과 상관없이 전송하는 경우 문제가 발생한다. 이런 경우에는 연결 의존적인 방법에 의해 Nagle 알고리즘을 비활성화시킬 수 있다.

Slow start with congestion avoidance

때때로 Jacobson 알고리즘이라고도 불리는, 이와 연관된 알고리즘들은 최근에 들어서야 알려지게 되었고 주로 낮은 속도의 네트워크와 게이트웨이를 가진 네트워크의 기능에 매우 증요한 역할을 한다.

최근 몇년 동안 부하가 증가함에 따라 인터넷은 점점 더 낮은 처리량율을 나타내게 되었고 다소 고장이 증가하게 되었음을 발견하였다. 처리 과정들을 좀 더 자세히 살펴 보면, 네트워크상의 패킷의 반 이상이 분실된 TCP 세그먼트에 대한 재전송 패킷임이 명확하게 들어났다. 네트워크 상의 경로(여기서 말하는 경로는 송신자의 데이타 버퍼로부터, 가능한 게이트웨이들 그리고 목저지까지를 말함)는 단지 유한한 양의 데이타를 전송할 수 있다. 게이트웨이나 호스트가 과부하상태일 때, 세그먼트를 넣어둘 충분한 버퍼 공간이 없을 수 도 있다. 이런 경우, 게이트웨이에 의해 세그먼트는 무시되고, 패킷의 송신자는 RTO만큼 지연된 후 재전송을 결정할 것이다. 그러면 결과적으로 전체 네트워크의 부하는 다시 불필요하게 증가하게되는 것이다. slow-start 알고리즘은 주어진 시간동안 얼마나 많은 데이타가 분실없이 목적지까지 전송되는가를 측정하도록 시도한다. 이것은 측정은 재전송 없이 동일한 데이타의 흐름을 가지는 시점까지 전송하는 데이타의 집합의 크기를 점차 증가시킴으로써 이루어진다. 앞에서 전송될 데이타의 집합에 의해 크기가 측정되었듯이, 소위 밀집 윈도우(congestion window)라 불리는 네트워크 경로상의 저장 용량도 측정대상이다. Congestion window는 항상 수신 윈도우보다 작거나 같다. Congetstion window가 일단 일정한 값을 가지게되면 재전송의 발생으로 네드워크의 부하가 증가되는 경우에만 변경된다. 이 경우 밀집 회피(congestion avoidance)알고리즘이 작업을 하게된다. 동시에 congestion window의 상수배의 잘 고려된 크기만큼 할당되어질 수 있는 어떠한 자원도 이용하려는 시도가 이루어진다. 이러한 조심스러운 작업 방식으로 처리율은 30%까지 증가될 수 있으며 재전송되는 세그먼트는 50%이상 감소될 수 있다.

이 두 알고리즘과 관련하여 retransmission timeout도 또한 향상되었다. 새로운 알고리즘은 round trip time에 있어서 더 신속한 변화를 얻을 수 있다. 따라서 추가적인 패킷의 재전송을 막을 수 있다.

User Datagram Protocol

UDP는 비연결성 트랜스포트 프로토콜이다. 이것은 RFC 768에 명세되어 있으며 트랜스포트 주소는 17이다. TCP와 달리 UDP는 매우 간단한 프로토콜로 다음과 같은 속성을 갖는다.

비연결성

포트 번호에 의해 주소 지정

데이타 체크섬

매우 간단

최선의 전송('best-effort' forwarding)

그림.3.18에 보인 UDP 프로토콜 헤더의 항목들은 아래와 같다.

Source and destination port number

TCP에서 처럼 포트 번호가 트랜스포트 프로토콜의 사용자의 참조를 위해 사용된다.

Length

이것은 프로토콜 헤더를 포함한 전체 데이타그램의 크기를 나타낸다.

Checksum

인터넷 체그섬은 데이타, 프로토콜 헤더 그리고 가상 헤더를 모두 포함한다. 만약 이 항목이 0의 값을 갖는다면 전송 개체가 체크섬을 기입하지 않은 것이고 따라서 수신 개체는 이 항목을 검사하지 않는다. 4.2BSD의 첫 버전에서는 UDP 코드가 잘못된 UDP 체크섬을 생성하는 에러를 가지고 있었다. (이 체크섬이 수신 개체에 의해 검사되지 않기 때문에 그 버그는 한동안 발견되지 않았었다.) 이 후의 버전에서 이 부분은 제거되었다. 공식적으로는 SunOS나 이를 바탕으로 한 시스템에서는 네트워크에서 데이타의 무결성을 보장한다는 전제를 가지고 있기때문에 UDP 체크섬이 개발되지 않았다. 체크섬은 운영 체제의 변수를 이용하여 전환이 가능하다.(udpcksum).

IP에 의해 수행되는 작업상에서, UDP는 단지 포트 번호와 체크섬만을 제공한다. TCP와 달리 이 경우에는 트랜스포트 억놀리지먼트가 없으며 또 네트워크에 신뢰성을 부여할 만한 다른 수단도 없다. 그러나 추가적인 기능들을 제외시킴으로써 UDP는 특별히 고속의 응용(예를 들어 분산 파일 시스템(NFS) 등등)에 대해 효율적이며 적합한데, 이러한 응용들은 로컬 에리어 네트워크(LAN)와 같은 빠르고 신뢰할 수 있는 전송 매체에 설치 하기에 적합한 것들이다.

Internet Control Message Protocol

모든 네트워크과 모든 노드들에서 때때로 오류가 발생한다. 이러한 사항들은 관련되어있거나 책임을 지고 있는 관련 개체들에게 통지되어야 한다. 이러한 통지의 역할을 담당하는 것이 ICMP이며 RFC 792에 명세되어있다. ICMP는 모든 IP 구현들 속의 한 구성 요소이며 트랜스포트 프로토콜로서의 유일한 기능은 오류를 전송하고 IP를 위해 데이타를 진단하는 것이다. IP 프로토콜 헤더에서의 트랜스포트 프로토콜 주소는 1이다.

ICMP는 다양한 정보를 전송하여야 아므로 프로토콜 헤더의 기본적인 골격만 고정되어 있으며 각 항목들의 의미는 변화가능하다.

그 구조가 그림.3.19에 나타나있는데 이것은 모든 ICMP 메세지에 공통적인 것이다.

Type

ICMP 메세지의 타입을 명세한다. 표.3.6에 타입들의 예가 나와있다.

Code

위에서 지정한 타입에 속하는 하위 기능들을 지시하는 추가적인 코드이다.

Checksum

완전한 ICMP 메세지를 위한 인터넷 체크섬을 담고 있다.

Miscellaneous

이것은 순서 번호나, 인터넷 주소등의 다양한 정보를 담기 위한 항목으로 32비트 길이이다.

IP protocol header

이 항목은 오류를 일으킨 IP 데이타그램의 IP 프로토콜 헤더와 그 안에 담겨있는 데이타의 첫 8바이트의 데이타를 담고 있다. 만약 TCP나 UDP의 메세지에 의해 ICMP메세지가 발생되었다면 TCP나 UDP 프로토콜 헤더의 첫 8바이트에 의해 응용 프로그램을 판별할 수 있고 에러 메세지를 전송할 수 있다(예를 들어 연결 요구 메세지에 명세된 포트 번호를 가진 서버는 목적지 프로세서에서 활성화되어있지 않는다.) 이 항목은 또한 검사 데이타를 담는 데 사용될 수 있다( 예를 들어 반향 요구(echo request)에서 ).

ICMP 메세지는 IP와 TCP또는 UDP 모두에 의해 초기화되고 내부적으로 처리될 수 있다. 그들은 다른 ICMP 메세지나 방송(broadcast)에 대한 응답으로 생성되어져서는 안된다. 그렇지 않은 경우 끝없는 루프가 생길 수 있다.

ICMP 패킷의 타입

아래와 같은 ICMP 패킷의 타입이 UNIX 시스템에서 구현되고 있으므로 그들을 좀 더 자세히 살펴 보겠다.

Destination unreachable

이것은 다음과 같은 오류를 보고하는 메세지를 운반한다.

네트워크, 호스트, 프로토콜 또는 포트를 찾을 수 없다.

사용자 프로그램은 해당되는 에러 메세지를 받는다.

단편화가 필요하나 DF비트가 설정되어있다.

근원지 경로 옵션이 불가능하다.(&#8680;IP options)

Source quench

게이트웨이가 메세지를 임시 저장할 용량을 가지고 있지 않은 경우 게이트웨이는 해당 호스트에 이 타입의 ICMP 메세지를 전송한다. 전송 호스트는 반드시 뒤에 이어지는 메세지들의 전송 속도를 낮추어야 한다. 4.3BSD에서부터 TCP는 이 메세지에 반응한다. 4.2BSD에서는 이 메세지는 간단히 무시되었다. 밀집 회피(congestion avoidance) 알고리즘을 가지고 있는 시스템에서는 congestion window가 감소된다. UDP도 이 메세지를 무시하는데 이경우 응용 프로그램에게 알려져야 한다.

Redirect

IP 패킷의 전송 경로상의 게이트웨이가 근원지 전송 개체와 다음번 게이트웨이간의 직접 전송이 가능하다는 것을 인지하는 경우(즉 불필요한 우회 전송이 발생하는 경우) 이 메세지를 전송한다. ICMP 메세지는 다음번 게이트웨이의 인터넷 주소를 담고 있으며 이것은 전송 개체의 경로표에 기록된다.

Echo reply and echo request

Echo request가 한 컴퓨터에 전송되면 결과로서 echo reply가 뒤따른다. Echo request와 echo reply는 지연 시간의 측정이나 작업 준비의 확인등의 유용한 기능들을 구현하는데 사용된다. 임의의 길의의 검사 데이타가 ICMP 메세지의 IP 프로토콜 헤더 항목에 담겨져 전송되고 이 데이타는 echo reply에 의해 돌아온다.

Time exceed

TTL이 종료됨에 따라 무시되어지는 메세지나 단편 재합성 타이머가 종료한 메세지를 전송하는 개체에게 전달되는 ICMP 메세지이다.

Parameter problem

잘못된 프로토콜 헤더 항목을 가진 IP 데이타그램의 전송 개체에게 그 패킷이 무시되어져야 했음을 알린다.

RFC 950에서는 Address Mask Request와 Address Mask Reply라는 서브네트워크 ID의 주소 마스크 측정을 위한 2개의 새로운 ICMP 패킷 타입이 제안되었다. 그들은 현재까지 알려진 UNIX 시스템에서는 구현되어지지 않았다.

Subnetworks

Ethernet와 IEEE 802.3

Ethernet는 1970년대 초 Xerox사에 의해 개발되었던 LAN기술이다. 현재 널리 사용되고 있는 버전 2는 1978년에 Xerox, Digital Equipment Corporation과 Intel에 의해 표준화되었다. 이것은 현재 로컬 에리어 네트워크를 위한 가장 널리 사용되고 있는 기술들 중 하나이다. 1980년대 초 다소 동일한 버전이 국제 표준으로 정의되어 IEEE 802.3으로 이름붙여졌다. LAN 토큰 링(IEEE 802.5)과 토큰 버스(IEEE 802.4) 기술을 위한 다른 IEEE 802 표준들도 존재한다.

연결 특성

Ethernet은 초당 천만비트의 전송율을 가지고 작동하는 동축 케이블 버스를 기초로한다. 케이블의 단위는 500미터까지 가능하며 200개까지의 연결 포인트(소위 트랜스버 transceiver)를 가질 수 있다. IEEE 802.3 표준안은 10base5로 알려져 있다. 각각의 트랜스버 사이에는 최소한 2.5미터이상의 거리가 있어야한다. 몇개의 Ethernet 케이블이 소위 리피터(repeater)라는 신호 증폭기에 의해 연결되어질 수 있는데 2개의 트랜시버사이에는 2개의 리피터까지만 사용가능하다. 따라서 모든 세그먼트의 길이의 최대값은 수 킬로미터로 제한된다. 현재는 다수의 포트를 가진 소위 MAC layer bridge라는 리피터를 이용하여 더 먼거리의 네트워크가 가능해졌다(&#8680;7장.) 또한 fan-out units라는 연결 다중기를 이용할 수 있으며 이것을 통하여 하나의 트랜시버에 여러 호스트를 동시에 연결할 수 있다.

Thin Ethernet (Cheapernet)은 Ethernet의 변형으로 단지 그 전기적 연결 특성만이 다르며 그 데이타 전송 프로토콜은 동일하다. 이 변형은 10base2로 알려져있다. 더 가늘고 유연한 케이블의 사용은 설치와 연결을 간편화하는데, 컴퓨터는 Ethernet 제어 카드에 집적된 트랜시버를 통하여 케이블과 직접연결된다. 따라서 트랜시버의 비용이 낮아진다. 최대 케이블 세그먼트 길이와 최대 연결 가능 스테이션의 수가 Ethernet의 절반에 못 미치지만 작은 규모의 네트워크에는 아무런 문제가 없다. 게다가 케이블의 구조적 특성때문에 Thin Ethernet은 비전문가에 의해서도 설치가 가능하다. Ethernet와 Cheapernet가 전송 속도와 프로토콜의 관점에서 볼 때 동일하기 때문에 두 형태의 네트워크들은 리피터에 의해 문제없이 적절히 연결될 수 있다.

2중 회선 회로에 바탕을 둔 Ethernet(Twisted-Pair Ethernet, 10baseT)는 점점더 인기를 얻어가고 있다. 연결된 스테이션과 접합점까지 최대 30미터의 거리를 트위스트 페어를 이용하여 연결할 수 있다. 스테이션들은 각 접합점 주위에 별 모양으로 배열된다.

동시에 멀티미디어 분야와 같이 분산 응용들의 증가하는 수요를 만족시키기 위해 전송 대역을 10 메가비트에서 100메가비트로 확해하려는 작업이 진행중이다. 하지만 상호 작동이 가능한 표준에 바탕을 둔 제품이 가능하기까지는 얼마간의 시간이 필요할 것 같다.

Protocol

Ethernet는 CSMA/CD(Carrier Sense Multiple Access with Collision Detect) 프로토콜을 사용한다. 간단히 설명하면: 스테이션이 패킷을 전송하기에 앞서 다른 스테이션이 벌써 활성화되었는가를 보기위해 검사한다(carrier sense). 만약 그렇다면 케이블이 사용가능할 때까지 기다린다. 그렇지 않다면 즉시 전송을 시작한다. 그들은 항상 보내진 데이타와 케이블상의 데이타를 비교하기 때문에 만약 2개이상의 스테이션이 우연히 동시에 전송을 시작한다면(collision) 그들은 이러한 상황을 인지하게 된다. 데이타가 훼손되는 경우 전송 프로시져는 즉시 인터럽트를 발생시키고 얼마간의 대기 시간 후 다시 반복한다. 대기 시간은 난수 생성기에의해 결정되는데 이 난수 생성기는 재전송시 지연시간을 지수적으로 증가시킨 값을 반환한다. 이것은 두개의 스테이션이 지속적으로 같은 지연시간을 갖는 것을 방지한다.

주소지정은 48비트 주소를 사용하는데 Ethernet 제어기의 하드웨어에 고정되어있다. IEEE가 Ethernet 제어기 생산자들에게 그 번호를 배분하기 때문에 세계의 모든 스테이션은 유일한 주소를 갖게된다.

Ethernet 패킷의 구성이 그림.3.20에 나와있다. 이 패킷안에서의 IP와 TCP 프로토콜 헤더의 위치가 그림으로 나와있다. 따라서 각각의 프로토콜 층들이 명확하게 식별될 것이다.

Ethernet 패킷의 preamble은 수신 스테이션을 동기화시키기 위한 특별한 비트 패턴이다. 그 뒤에 목적지와 근원지 주소가 따라온다. Ethernet 표준안에서는 패킷 타입 항목에 바로 위층의 프로토콜의 주소가 들어가도록 되어있다. 따라서 Ethernet위에 다양한 프로토콜들이 동시에 지원될 수 있다. IEEE 802.3 표준안에서는 패킷 타입 항목이 길이를 표시하는 항목으로 사용된다. 그리고 상위 층의 주소는 데이타 영역에 의해 운반된다. 최대 1500비트의 데이타 영역뒤에는 32비트 CRC 체크섬이 뒤따라온다. 전송과 관련된 기술적 이유로 하나의 패킷은 최소한 64바이트 이상되어야 한다. 이보다 적은 데이타가 전송되는 경우에는 운영체제안에 있는 Ethernet 드라이버에 의해 인위적으로 패킷을 이 크기로 만들어야한다.

각각의 스테이션은 케이블상의 패킷을 읽고 목적지 주소를 자신의 주소와 비교한다. 만약 두개의 주소가 일치하는 경우에는 그 스테이션이 목적지임을 뜻하므로 그 패킷을 전부 수신한다. 이러한 성질(네트워크의 모든 스테이션이 패킷을 읽는다) 때문에 한 메세지를 동시에 모든 스테이션에 전송하거나(broadcast) 일정한 그룹네 속하는 스테이션에 전송(multicast)할 수 있다.

충돌의 가능성 때문에 Ethernet은 종종 비판을 받기도한다. 그러나 고속의 전송율과 carrier sense 프로시져에 의해 실제로는 거의 발생하지 않는다. 실험에 의하면 이론적인 전송 대역의 40%수준의 부하량의 다양한 길이의 패킷을 사용하는 경우 충돌이 평균이상으로 증가하게된다.

네트워크 층의 주소 지정

네트워크층의 주소 지정을 위해서 Ethernet 프로토콜 헤더는 주소 항목을 가지고 있어야 한다. RFC 894는 IP 프로토콜을 위하여 Ethernet 패킷의 타입 항목에 800₍₁₆₎으로 명세하였다.

Ethernet 802 표준안은 802계열의 네트워크에서의 LLC(Logical Link Control)사용을 규약하고 있다. LLC 프로토콜 헤더는 바로 위층의 프로토콜의 주소를 담고 있다. 사실 LLC가 UNIX의 세계에 파고들지는 않았다. 현재의 모든 구현들은 RFC 894에 명세된 모드들을 사용하고 있다. 그러나 호스트가 ISO 프로토콜(에를 들어 LLC)과 TCP/IP를 동시에 사용하고자 한다면 시스템은 가지고 있는 패킷의 타입을 판별할 수 있어야한다. 다행히도 RFC에 명세되어있는 패킷 타입 번호는 Ethernet 패킷의 최대 길이보다 길다. 따라서 1500까지의 주소인 경우 LLC 패킷을 가지고 있다고 추측할 수 있다.

802계열의 네트워크를 위한 LLC의 확장판인 SNAP(Subnetwork Access Protocol)가 RFC 1042에서 제안되었다. 그러나 Ethernet와 IEEE 802.3 네트워크에서는 이전처럼 RFC 894가 사실상의 표준이다.

Serial line IP

4.3BSD는 SLIP(Serial Line Internet Protocol)의 구현을 포함하고 있다. SLIP는 두 컴퓨터간 에 병렬라인(예를 들어 V.24)을 이용한 연결을 가능하게한다. SLIP는 매우 간단한 프로토콜이고 RFC 1055에 명세되었다.

모든 SLIP 패킷은 EB₍₁₆₎이라는 값을 가지는 바이트로 시작하는데 프로토콜에서 이 값은 ESC를 의미한다. 데이타의 끝에는 C0₍₁₆₎(END)이라는 값이 따라온다. 만약 이러한 값들이 데이타에 나타나면 그들은 2바이트 열 ESC EC₍₁₆₎와 ESC ED₍₁₆₎으로 전송되며 수신측에서 END와 ESC로 재변환한다. 최대 패킷의 크기는 정해져 있지 않고 일반적으로 1006바이트의 상한을 가정한다.

SLIP는 주소나 다른 프로토콜 항목을 가지고 있지 않고 단지 데이타를 지점간 전송을 위한 패킷의 형태에 맞추어주는 기능만 수행한다. 어떤 UNIX 시스템도 대부분의 UNIX 구현들에서 제공되는 SLIP 드라이버와 병렬라인을 이용하여 게이트웨이로 쉽게 변환될 수 있다. 그러나 전송 효율이 기껏해야 19200보드(baud)로, Ethernet의 기능과 비교할 때 그 성능에 있어 큰 차이가 있으며, 병렬라인을 이용하므로써 생기는 UNIX 프로세서의 과부하 가능성도 있다.

이에 대한 대책으로 RFC 1144에서 TCP/IP 프로토콜 헤더를 압축함으로써 SLIP 링크에서의 패킷의 크기를 감소시키는 프로토콜이 제안되었다. 이 알고리즘은 TCP/IP 프로토콜 헤더의 항목들의 정보(예를 들어 인터넷 주소, 포트 번호 등등)의 대부분이 연결이 설정되어있는 동안 변화하지 않는다는 사실에 바탕을 두고 있다. 각각의 SLIP 연결 식별자를 이용하여 양쪽의 개체는 마지막 패킷의 교환이후 실제적으로 변한 항목만을 전송한다. 이로서 얻어지는 이득은 막대하다. 평균적인 TCP/IP 프로토콜은 대부분의 경우 40바이트에서 3바이트로 줄어든다. 네트워크에서 가장 많이 사용되는 응용 프로그램들은 원격 로그인와 TELNET으로 이들은 일반적으로 한번에 한 개의 문자만을 전송하는데 사용자 데이타와 프로토콜 데이타간의 비율이 압축을 통하여 10배이상 증가한다. 아직 표준화되지 않은 이런 프로토콜이 다양한 호스트에서 사용중이다. 그러나 그들은 UNIX 시스템에서 널리 이용되지는 않는다.

Point-to-point protocol

RFC 1331에 명세되어 있는 PPP(Point-to-Point Protocol)은 SLIP처럼 두 시스템을 병렬라인을 통하여 연결하는데 사용되는 프로토콜이다. PPP가 SLIP에 비해 다소 최근의 것이기 때문에 SLIP의 약점인 것들을 제거하기 위한 주의가 기울여졌다. 이들은 다음과 같은 핵심적인 사항들로 이루어져있다.

프로토콜 항목을 이용하여 네트워크 층의 다른 프로토콜들을 지원하는 기능.

데이타에 이어지는 체크섬의 포함

SLIP처럼 PPP도 패킷의 경계를 식별하기 위해 특수한 바이트 값 7E(16)을 사용한다. SLIP와 다른, X.25 프로토콜에 있는 소위 플래그 바이트가 데이타 전송이 없는 경우 항상 전송된다. (다시 말해서 프로토콜이 작업을 하지 않는 동안). 패킷의 시작은 플래그두이에 다른 바이트 값이 발견되는 즉시 감지된다. 플래그에 해당하는 바이트 값이 데이타 내부에 존재하는 경우 이탈 문자인 7D₍₁₆₎을 이 앞에 삽입되고 뒤따라오는 문자의 6번째 비트가 보수화된다. 동일한 과정이 XON/XOFF와 같은 ASCII 제어 문자를 제거하기 위해 사용되어지는데 이러한 값들은 어떤 상황에서는 문제를 유발할 수 있다.

PPP하에서 데이타의 교환이 있기 앞서 두 시스템사이의 연결이 LCP(Link Control Protocol)에 의해 설정되고 검사되어진다. LCP는 또한 연결이 종료되는 경우에도 사용된다. LCP는 PPP의 명세의 일부분이다. 여기에 덧붙여 NCP(Network Control Protocol)이라는 또 다른 프로토콜이 네트워크 층에서 사용되는 프로토콜을 위한 특별한 제어 정보를 교환하는데 사용된다. 각각의 네트워크 층 프로토콜은 자신의 NCP를 가지고 있다. IP를 위해 정의된 NCP는 IPCP(Internet Protocol Control Protocol)라 불린다.

X.25

최근에 WAN을 구성하기 위한 수단으로 X.25가 점점 더 인기를 끌고있다. X.25에대한 지원은 LAN상의 스테이션처럼 연결된 완비된 형태의 Internet router나 UNIX 시스템을 게이트웨이로 전환하는 네트워크 인터페이스 드라이버의 형태 2가지로 이루어진다. 두경우 모두 X.25 연결은 SLIP 프로토콜과 유산한 방법으로 두 시스템, 네트워크간의 직접 연결로 사용되어진다.

그러나 X.25의 연결은 대부분 정적으로 확립되어지지 않는다. 대신 X.25-게이트웨이 서브네트워크 인터페이스에 도달하는 패킷의 인터넷 주소에 따라 동적으로 생성된다. 만일 X.25 연결이 얼마간 사용되어지지 않는다면, 그것은 영향을 받지 않고 활성화 상태로 남아있는 어떠한 TCP 연결들과도 임시적으로 작업할 수 있다. RFC 877에 기술되어 있는 표준안은 X.25를 통하여 IP 데이타그램을 전송하는 방법을 명세하고 있다. RFC 877의 가장 흥미있는 면은 IP 데이타그램이 완벽한 패킷 순서로 전송되도록 명세하고 있다는 점이다. 다시 말해서 최대 크기의 X.25 패킷보다 큰 데이타그램은 IP에 의해 단편화되어서는 안되며, 대신 X.25 프로토콜 헤더의 M비트로 연결된 다수의 X.25 패킷으로 전송되어져야 한다는 것이다. 따라서 X.25 패킷마다의 추가적인 IP 프로토콜 헤더로 인한 낭비가 절약되는 것이다. IP 데이타그램의 단편화와 재합성은 X.25 인터페이스 드라이버에 의해 처리된다.

그 외의 서브네트워크들

데이타의 교환이 서서히 증가함에 따라 X.25 서비스에 의해 제공되는 대역폭이 많은 경우에 있어 충분하지 않게 되었다. 따라서 더 빠른 데이타 전송 기술들이 점점 더 확립되어가고 있다.

Integrated Services Digital Network(ISDN)

Asynchronous Transfer Mode(ATM)

frame relay

위에서 보인 서비스들은 메가바이트 영역의 전송 속도를 제공한다. X.25를 통한 네트워크의 연결의 경우처럼 이들은 일반적으로 브리지나 LAN에 설치된 라우터에 의해 활성화되는데 이들은 각각의 해당하는 서브네트워크의 프로토콜들을 수행한다.