[ComputerNetwork_TransportLayer-2]

3.4 신뢰적인 데이터 전송의 원리

신뢰적인 데이터 전송을 구현하는 문제가 트랜스포트 계층뿐만 아니라 링크 계층과 애플리케이션 계층에서도 발생할 수 있는 문제이다.

신뢰적인 전송 프로토콜의 ‘아래에 있는’ 계층이 신뢰적이지 않을 수 있어서 어려워진다.

그 예로 TCP는 비신뢰적인 종단 간에 네트워크 계층 (IP) 의 바로 상위에 구현된 신뢰적인 데이터 전송 프로토콜이다.

신뢰적으로 통신하는 두 종단점 바로 아래에 있느 계층은 단일 물리적 링크( 링크 레벨 데이터 전송 프로토콜의 경우처럼) 이거나 전 세계 인터넷 네트워크(트랜스포트 레벨 프로토콜의 경우처럼)로 구성되어있을 수 있다.

 

rdt : reliable data transfer () 신뢰적인 데이터 전송 프로토콜을 나타낸다.

데이터 전송 프로토콜의 송신측은 rdt_send() 호출로 위쪽으로부터 호출될 것이다.

수신 측에서는 상위 계층으로 전달될 데이터를 넘길 것이다.

_send는 rdt의 송신측이 호출되고 있음을 나타낸다.

수신 측에서 rdt_rcv()는 패킷이 채널의 수신 측으로부터 도착했을 때 호출된다.

 

 

3.4.1 신뢰적인 데이터 전송 프로토콜의 구축

<완벽하게 신뢰적인 채널상에서 신뢰적인 데이터 전송 : rdt1.0>

먼저, 하위 채널이 완전히 신뢰적인 가장 간단한 경우를 고려한다.

rdt 1.0 송신자와 수신자에 대한 유한상태 머신 (finite-state machine, FSM)

• rdt의 송신 측은 rdt_send(data) 이벤트에 의해 상위 계층으로부터 데이터를 받아들이고 데이터를 포함한 패킷을 생성한다 (make_packet)에 의해그러고 난 후 패킷을 채널로 송신한다. 실제로 rdt_send(data)는 상위 계층 애플리케이션의 프로시저 호출에 의해 발생한다.

⇒ 요약 1) 데이터 받아들임 2) 데이터 포함한 패킷 생성 3) 패킷을 채널로 송신

• 수신 측에서 rdt는 rdt_rcv(packet) 이벤트에 의해 하위의 채널로부터 패킷을 수신하고, 패킷으로부터 (extract(packet, data))에 의해 데이터를 추출한 후 데이터를 상위 계층으로 전달한다. (delivery_data (data)), rdt_rcv(packet)이벤트는 하위 계층 프로토콜로부터의 프로시저 호출에 의해 발생한다.

⇒ 요약 1) 하위 채널로부터 패킷 수신 2) 패킷에서 데이터 추출 3) 데이터를 상위 계층으로 전달

 

<비트 오류가 있는 채널상에서의 신뢰적 데이터 전송 : rdt 2.0>

하위 채널의 더 실질 모델은 패킷 안의 비트들이 하위 채널에서 손상되는 모델이다.

그러한 비트 오류는 패킷이 전송 또는 전파되거나 버퍼링 될 때 네트워크의 물리적 구성요소에서 일반적으로 발생한다.

전송된 모든 패킷이 송신된 순서대로(비록 패킷의 비트가 손상된다 하더라도) 수신된다고 계속 가정한다.

긍정 확인응답 (positive acknowledgement) / 부정 확인응답 (negative acknowledgement)

→ 컴퓨터 네트워크 설정에서, 잘못 수신되었는지, 정확하게 수신이 되었는지를 수신자가 송신자에게 알려주는 것을) 전송프로콜은 자동 재전송 요구 ARQ (Automatic Repeat ReQuset) 프로토콜로 알려져있다.

오류 검출. 수신자 피드백. 재전송

rdt2.0 의 송신 측은 2개의 상태를 갖는다. 가장 왼쪽 상태에서 송신 측 프로토콜은 상위 계층으로부터 데이터가 전달되기를 기다린다. rdt_send(data) 이벤트가 발생하면, 송신자는 패킷 체크섬과 함께 전송될 데이터를 포함하는 패킷(sndpkt)을 생성하고, 그 패킷을 send(sndpkt) 동작을 통해 전송할 것이다.

가장 오른쪽 상태에서 송신자 프로토콜은 수신자로부터의 ACK또는 NAK패킷을 기다린다.

만약 ACK 패킷이 수신된다면, 송신자는 가장 최근에 전송된 패킷을 정확하게 수신되었음을 알게 된다.

그래서 프로토콜은 상위 계층으로부터 데이터를 기다리는 상태로 돌아간다.

전송 후 대기 프로토콜 (stop and wait) 로 알려져있다.

sender sends one packet, then waits for receiver response

송신자는 수신자가 현재의 패킷을 정확하게 수신했음을 확신하기 전까지 새로운 데이터를 전달하지 않을 것이다.

rdt2.0에 대한 수신자 측 FSM 측은 아직 단일 상태를 갖는다.

패킷이 도착했을 때, 수신자는 수신된 패킷이 손상되었는지 아닌지에 따라서 ACK 또는 NAK로 응답한다.

프로토콜 rdt2.0은 잘 동작하는 것 같지만, 실제로는 치명적인 결함이 있다.

최소한 그러한 오류를 검출하기 위해 ACK와 NAK 패킷에 대한 체크섬 비트를 추가할 필요가 있다.

 

손상된 ACK또는 NAK을 처리하기 위한 세 가지 가능성

1. 사람이 메세지 받아쓰기 시나리오에서 무엇을 할 수 있는지를 생각해보자. 왜곡된 문장이 명령의 일부인지 아니면 마지막 응답을 반복하기 위한 요청인지를 모르는 수신자는 "아까 뭐라고 하셨죠?" 라는 응답을 할 것이다.
2. 송신자가 검출뿐만 아니라 비트 오류로부터 회복할 수 있도록 충분한 체크섬 비트들을 추가하는 것이다. 이 방식은 패킷이 손상될 순 있으나 손실되지는 않는 채널의 경우에는 즉각적으로 문제를 해결할 수 있다
3. 송신자가 왜곡된 ACK 또는 NAK 패킷을 수신할 때 현재 데이터 패킷을 단순히 다시 송신하는 것이다. 이 방식은 송신자에서 수신자 간의 채널로 중복 패킷(duplicate pakcet)을 전송한다. 중복 패킷의 가장 근본적으로 어려운 점은 마지막으로 전송된 ACK또는 NAK가 송신자에게 정확하게 수신 되었는지를 알 수 없다는 것이다. 그러므로 도착하는 패킷이 새로운 데이터를 포함하고 있는 것인지 아니면 재전송인지를 사전에 알 수 없다.

⇒ 해결책으로는 데이터 패킷에 새로운 필드를 추가하고 이 필드 안에 순서 번호 (sequence number)을 삽입하는 방식으로 데이터 패킷에 송신자가 번호를 붙이는 것이다. 수신자는 수신된 패킷이 재전송인지를 결정할 대는 이 순서 번호만 확인하면 된다.

 

rdt2.1은 rdt2.0의 수정된 버전인 FSM을 나타내고 있다.

rdt2.1 송신자와 수신자 FSM은 전보다 두 배 많은 상태를 갖고 있다. 이는 프로토콜 상태가 현재(송신자에 의해) 전송되고 있거나, 아니면(수신자가) 기다리고 있는 패킷이 순서 번호 0 또는 1을 가져야 하는지를 반영해야 하기 때문이다. 0번 패킷이 송신되고 있거나 기다리고 있는 상태에서의 동작은 1번 패킷이 송신되고 있거나 기다리는 상태의 미러 이미지이다.

 

rdt2.1은 수신자로부터 송신자까지의 긍정 확인응답과 부정 확인응답을 모두 포함한다. 순서가 바귄 패킷이 수신되면, 수신자는 이미 전에 수신한 패킷에 대한 긍정확인 응답을 전송한다. 손상된 패킷이 수신되면, 수신자는 부정 확인응답을 전송한다. NAK를 송신한 것과 같은 효과를 얻을 수 있다. 같은 패킷에 대해 2개의 ACK를 송신함으로써 NAK를 송신한 것과 같은 효과를 낼 수 있다.

 

같은 패킷에 대해 2개의 ACK를 수신한 (즉, 중복된 ACK을 수신) 송신자는 수신자가 두 번 ACK한 패킷의 다음 패킷을 정확하게 수신하지 못했다는 것을 안다. 비트 오류를 갖는 채널을 위한 NAK 없는 신뢰적인 데이터 전송 프로토콜은, rdt2.2이다.

rdt2.1 과 rdt2.2의 미묘한 차이는 수신자가 반드시 ACK메세지에 의해 확인 응답되는 패킷의 순서 번호를 포함해야한다는 점이다. (이것은 수신자 FSM의 make_pkt()에 ACK,0 또는 ACK,1 인 인수를 넣어서 수행한다. ) 그리고 송신자는 수신된 ACK 메시지에 의해 확인응답된 패킷의 순서 번호를 반드시 검사해야만 한다. (이것은 송신자 FSM의 isACK() 에 0 또는 1인 인수를 넣어서 수행한다.

 

 

<비트 오류와 손실 있는 채널상에서의 신뢰적인 데이터 전송 rdt3.0>

송신자가 어떤 패킷을 손실했다는 것을 확신하기 위해 얼마나 오랫동안 기다려야할까?

송신자는 적어도 송신자와 수신자 사이의 왕복 시간 지연 (중간 라우터에서의 버퍼링을 포함) 에 수신 측에서 패킷을 처리하는 데 필요한 시간을 더한 만큼 기다린다.

실제 상황에서 채택한 접근 방식은 송신자가 패킷 손실이 일어났다는 보장은 없지만 손실이 일어났을 만한 그런 시간을 현명하게 선택하는 것이다.

만일 ACK이 시간 안에 수신되지 않는다면 패킷은 재전송된다. 만일 패킷이 큰 지연을 갖는다면, 송신자는 비록 데이터 패킷이나 그패킷에 대한 ACK 패킷이 손실되지는 않았다 하더라도 패킷을 재전송 할 수 있다. 이것은 송신자 대 수신자 채널에서 중복 데이터 패킷 (duplicate data packet)의 가능성을 포함한다.

다행히 프로토콜 rdt2.2에는 이미 패킷이 중복되었을 경우를 처리하기 위한 충분한 기능(순서번호)이 있다.

시간 기반의 재전송 매커니즘을 구현하기 위해, 주어진 시간이 지난 후에 송신자를 인터럽트 (중단) 할 수 있는 카운트다운 타이머가 필요하다. 그러므로 송신자는 다음처럼 동작해야한다.

1. 매 패킷( 첫번째 또는 재전송 패킷) 이 송신된 시간에 타이머를 시작함
2. 타이머 인터럽트에 반응함(적당한 행동을 취함)
3. 타이머를 멈춤

시간은 다이어그램의 위로부터 아래로 움직인다. 즉 패킷에 대한 수신 시간은 전송 지연과 전파 지연 때문에 패킷 전송 시간보다 더 늦다. 그림에서 송신 측 꺾쇠는 타이머가 설정된 후에 타임아웃된 시간을 가리킨다.

패킷의 순서 번호가 0과 1이 번갈아 일어나므로, 프로토콜 rdt3.0은 때때로 얼터네이팅 비트 프로토콜 (alternating bit protocol)이라고 부른다.

 

3.4.2 파이프라이닝된 신뢰적인 데이터 전송 프로토콜

프로토콜 rdt3.0은 기능적으로는 정확한 프로토콜이다. 하지만 핵심적인 성능 문제는 rdt3.0이 전송 후 대기 (Stop and wait) 프로토콜이라는 점이다.

광속 왕복 전파 지연 (RTT)

1. 무손실 동작
2. 패킷 손실
3. ACK 손실
4. 조급한 타임아웃

전송 후 대기 프로토콜과 파이프라이닝된 프로토콜의 비교

확인응답을 기다리지 않고 여러 패킷을 전송하도록 허용하는 방식을 파이프라이닝이라고 부른다. 파이프 라이닝 방식은 신뢰적인 데이터 전송 프로토콜에서 다음과 같은 중요성을 지니고 있다.

1. 순서 번호의 크기가 커져야 한다. 왜냐하면 각각의 전송 중인 패킷은 유일한 순서 번호를 가져야하고 전송 중인 확인응답이 안된 패킷이 여럿 있을지도 모르기 대문이다.
2. 프로토콜의 송신 측과 수신 측은 패킷 하나 이상을 버퍼링 해야한다. 최소한 송신자는 전송되었으나 확인응답되지 않은 패킷을 버퍼링 해야한다. 정확하게 수신된 패킷의 버퍼링은 수신자에게서도 필요하다
3. 필요한 순서 번호의 범위와 버퍼링 조건은 데이터 전송 프로토콜이 손실 패킷과 손상 패킷 그리고 상당히 지연된 패킷들에 대해 응답하는 방식에 달려있다. 파이프 라인 오류 회복의 두가지 기본적인 접근방법으로는 GBN (Go Back N ,N부터 반복) 과 SR (Selective Repeat, 선택적 반복) 등이 있다.

3.4.3. GBN

GBN (Go Back N ,N부터 반복) 프로토콜에서 송신자는 확인응답을 기다리지 않고 여러 패킷을 전송(가능할 때) 할 수 있다. 그러나 파이프 라인에서 확인응답이 안 된 패킷의 최대 허용 수 N보다 크지 말아야한다.

 

34페이지 

송신자 관점의 순서 번호 범위를 보여준다. 확인 응답이 안 된 가장 오래된 패킷의 순서 번호를 base로 정의하고 사용되지 않은 가장 작은 순서 번호를 Nextseqnum (전송될 다음 패킷의 순서 번호) 으로 정의한다면, 순서 번호의 범위에서 4개의 간격을 인식할 수 있다.

• Sender Behavior in GBN:
  • The window slides forward over the sequence number space, making N the window size.
  • N is referred to as the window size, and GBN is considered a sliding-window protocol.
  • Flow control and congestion control are some of the reasons for limiting the number of unacknowledged packets to N.

N을 윈도크기 (window size)라고 부르며, GBN 프로토콜은 슬라이딩 윈도 프로토콜 (sliding window protocol)이라고 부른다.

실제로 패킷의 순서 번호는 패킷 헤더 안의 고정된 길이 필드에 포함된다. 만약 k가 패킷 순서 번호 필드의 비트 수라면, 순서 번호의 범위는 [ 0,2^k-1] 이 된다. TCP가 32비트 순서 번호 필드를 갖게 된다.

GBN송신자는 세 가지 타입의 이벤트에 반응해야한다.

1. 상위로부터의 호출 : rdt_send()가 위로부터 호출되면, 송신자는 우선 윈도가 가득 찼는지, 즉 N개의 아직 확인응답되지 않은 패킷이 있는지를 확인한다. 만약 윈도가 가득 차 있지 않다면 패킷이 생성되고 송신된다. 그리고 변수들이 적절하게 갱신된다. 만약 윈도가 가득 차 있다면, 송신자는 윈도가 가득 차 있음을 가리키는 함축적인 의미로 단지 데이터를 상위 계층으로 반환된다.
2. ACK의 수신 : GBN 프로토콜에서 순서 번호n을 가진 패킷에 대한 확인 응답은 누적 확인 응답 (cumulative acknowledgement)으로 인식된다. 이 누적 확인응답은 수신 측에서 올바르게 수신된 n을 포함하여, n개의 순서 번호를 가진 모든 패킷에 대한 확인 응답이다.
3. 타임아웃 이벤트 : 타이머는 손실된 데이터 또는 손실된 확인응답 패킷으로부터 회복하는 데 사용된다. 만약 타임아웃이 발생한다면, 송신자는 이전에 전송되었지만 아직 확인응답되지 않은 모든 패킷을 다시 송신한다.

GBN 프로토콜에서는 수신자는 순서가 잘못된 패킷들을 버린다.

수신자가 상위 계층에 데이터를 전달해야한다는것을 기억하자.

윈도 크기의 제한때문에, 송신자는 윈도우 사이즈만큼 송신한다. 그러나 송신을 계속 하기 전에 하나 이상의 패킷이 긍정 확인 응답되는 것을 기다려야한다. 각각의 성공적인 ACK가 수신되었을 때, 윈도는 앞으로 이동하고 송신자는 하나의 새로운 패킷을 전송한다. 수신 측에서는 패킷이 손실되었으므로, 다음 패킷의 순서가 잘못된 패킷으로 발견되어 제거된다.

 

3.4.4 SR Selective Repeat (SR)

수신자에서 오류 (손실되거나 변조된) 가 발생한 패킷을 수신했다고 의심되는 패킷만을 송신자가 다시 전송하므로 불필요한 재전송을 피한다. 필요에 따라 각각의 개별적인 재전송은 수신자가 올바르게 수신된 패킷에 대한 개별적인 확인응답을 요구할 것이다.

SR 수신자는 패킷의 순서와는 무관하게 손상 없이 수신된 패킷에 대한 확인응답을 할 것이다. 순서가 바뀐 패킷은 바진 패킷(아직 도착하지 않은 더 낮은 순서 번호를 가진 패킷)이 수신될 때까지 버퍼에 저장하고, 빠진 패킷이 수신된 시점에서 일련의 패킷을 순서대로 상위 계층에 전달할 수 잇다.

너무 큰 윈도를 가진 SR 수신자의 고민 : 새 패킷인가, 아니면 재전송 된 패킷인가?

3.5 연결지향형 트랜스포트 : TCP  TCP (Transmission Control Protocol)

3.5.1 TCP 연결

TCP는 애플리케이션 프로세스가 데이터를 다른 프로세스에게 보내기 전에, 두 프로세스가 서로 “핸드셰이크” 를 먼저 해야함으로, 연결지향형 (connection-oriented)이다. 즉 데이터 전송을 보장하는 파라미터들을 각자 설정하기 위한 어떤 사전 세그먼트들을 보내야한다. TCP 연결 설정의 일부로서, TCP 연겨로가 연관된 많은 TCP 상태 변수를 초기화한다.

TCP프로토콜은 오직 종단 시스템에서만 존재하고 중간의 네트워크 요소(라우터와 링크 계층 스위치)에서는 동작하지 않으므로, 중간의 네트워크 요소들은 TCP연결 상태를 유지하지 않는다.

TCP 연결은 전이중 서비스 (full-duplex service)를 제공한다. 두 호스트 사이에 3개의 세그먼트가 보내지므로, TCP 연결 설정 절차는 세 방향 핸드셰이크 (three-way-handshake) 라 부른다.

일단 TCP연결 설정이 되면, 두 애플리케이션 프로세스는 서로 데이터를 보낼 수 있다.

TCP는 초기 세 방향 핸드셰이크 동안 준비된 버퍼에서 데이터 묶음을 만들어선 네트워크로 보낸다. 세그먼트로 모아 담을 수 있는 최대 데이터의 양은 최대 세그먼트 크기 (maximum segment size,MSS)로 제한된다. MSS는 일반적으로 로컬 송신 호스트에 의해 전송될 수 있는 가장 큰 링크계층 프레임의 길이 (최대 전송 단위 maximum transmission unit, MTU)에 의해 결정된다.

TCP는 TCP 헤더와 클라이언트 데이터를 하나로 짝지어 TCP 세그먼트를 구성한다. 세그먼트는 네트워크 계층에 전달되며, 네트워크 계층 IP 데이터그램 안에 각각 캡슐화된다.

3.5.2 TCP 세그먼트 구조

TCP 세그먼트는 헤더 필드와 데이터 필드로 구성되어 있다.

데이터 필드는 애플리케이션 데이터의 일정량을 돕는다.

UDP 처럼 헤더는 상위 계층 애플리케이션으로부터 다중화와 역다중화를 하는 데 사용하는 출발지와 목적지 포트 번호를 포함한다. 또한 UDP 처럼 헤더는 체크섬 필드를 포함한다. 또한 다음과 같은 필드를 포함한다.

• 32비트 순서 번호 필드와 32비트 확인응답 번호 필드
• 16비트 수신 윈도 (receive window) 필드는 흐름제어에 사용된다.
• 4비트 헤더 길이 필드 (header length filed) 는 32비트 워드 단위로 TCP 헤더의 길이를 나타낸다.
• 선택적이고 가변적인 길이의 옵션 필드 (option filed) 는 송시낮와 수신자가 최대 세그먼트 크기를 협상하거나 고속 네트워크에서 사용하기 위한 윈도 확장 요소로 이용된다.
• 플래그 필드는 6비트를 포함한다. ACK 비트는 확인응답 필드에 있는 값이 유용함을 가리키는 데 사용된다.

순서 번호와 확인응답 번호

TCP는 데이터를 구조화되어 있지 않고 단지 순서대로 정렬되어 있는 바이트 스트림으로 본다. TCP의 순서 번호 사용은 순서 번호가 일련의 전송된 세그먼트에 대해서가 아니라, 전송된 바이트의 스트림에 대해서라는 관점을 반영한 것이다. 세그먼트에 대한 순서 번호는 세그먼트에 있는 첫 번째 바이트의 바이트 스트림 번호다.

3.5.3 왕복 시간(RTT) 예측과 타임아웃

타임아웃은 세그먼트가 전송된 시간부터 긍정 확인응답 될 때까지의 시간인 연결의 왕복시간인 (RTT)보다 좀 커야한다. 그렇지 않으면, 불필요한 재전송이 발생할 것이다.

왕복시간 예측

SampleRTT라고 표시되는 세그먼트에 대한 RTT 샘플은 세그먼트가 송신된 시간, 즉 IP에게 넘겨진 시간으로부터 그 세그먼트에 대한 긍정응답이 도착한 시간가지의 시간 길이이다.

모든 전송된 세그먼트에 대해 SampleRTT를 측정하는 대신, 대부분의 TCP는 한 번에 하나의 SampleRTT 측정만을 시행한다. 즉 어떤 시점에서 SampleRTT는 전송되었지만 현재까지 확인응답이 없는 세그먼트 중 하나에 대해서만 측정되어 이는 대략 왕복 시간마다 SampleRTT의 새로운 값을 얻게한다.

3.5.4 신뢰적인 데이터 전송

인터넷의 네트워크 계층 (IP서비스) 은 비신뢰적이다. 인터넷 프로토콜은 데이터그램 전달을 보장하지 않고, 데이터그램이 순서대로 전달된다는 것을 보장하지 않는다. 또한 데이터그램에 포함된 데이터의 무결성을 보장하지 않는다. IP 서비스에서 데이터

TCP의 데이터 전송/재전송에 관련된 세가지 주요 이벤트가 있음을 볼 수 있는데,

1. 상위 애플리케이션으로부터 수신된 데이터
2. 타이머 타임 아웃
3. ACK 수신

그림 3.36 자료

누적 확인응답은 첫 번째 세그먼트의 재전송을 방지한다.

빠른 재전송

타임아웃이 유발하는 재전송의 한 가지 문제는 타임아웃의 주기가 때때로 비교적 길다는 점이다. 세그먼트를 잃었을 때, 긴 타임 아웃 주기는 잃어버린 패킷을 다시 보내기 전에 송신자를 오랫동안 기다리게해서 종단 간의 지연을 증가시킨다.

GBN인가? SR인가? TCP 확인응답은 누적되고 올바르게 수신되지만, 순서가 잘못된 세그먼트는 수신자가 개별적으로 ACK를 받지 않는다는 점을 기억하기를 바란다. GBN 형태의 프로토콜과 매우 비슷해보인다.TCP에서 수정 제안된 선택적 확인응답은 TCP 수신자가 마지막으로 올바로 수신된 ‘순서가 맞는’ 세그먼트에 대해 누적확인응답을 하기보다는 ‘순서가 틀린’ 세그먼트에 대해 선택적으로 확인응답을 하게 된다.

선택적 재전송과 결합했을 경우(이미 수신자가 선택적 확인응답을 한 세그먼트의 재전송은 제외), TCP는 원래의 SR 프로토콜과 매우 유사하다.

TCP의 오류 복구 메커니즘은 GBN과 SR 프로토콜의 혼합으로 분류하는 게 맞다.

 

3.5.5 흐름제어

TCP에서는 송신자가 수신자의 버퍼를 오버플로우 시키는 것을 방지하기 위해 애플리케이션에게 흐름제어서비스를 제공한다. 이와 같이 흐름제어는 속도를 일치시키는서비스다. 수신하는 애플리케이션이 읽는 속도와 송신자가 전송하는 속도를 같게한다.

TCP는 손신자가 수신윈도 (receive window)라는 변수를 유지하여 흐름 제어를 제공한다. 수신 윈도는 수신 측에서 가용된 버퍼 공간이 얼마나 되는지를 송신자에게 알려주는 데 사용된다.

TCP는 전이중 이므로 연결의 각 측의송신자는 별개의수신 윈도를 유지한다. TCP는 할당된 버퍼의 오버플로를 허용하지 않으므로 다음 수식이 가능하다.

rwnd는 시간에 따라 여유 공간은 변함으로 동적이다.

TCP 연결 관리

데이터를 교환하기 전에, 송신자와 수신자는 핸드쉐이크를 한다.

연결 설정에 동의하기

송신자 관점의 순서 번호 범위를 보여준다. 확인 응답이 안 된 가장 오래된 패킷의 순서 번호를 base로 정의하고 사용되지 않은 가장 작은 순서 번호를 Nextseqnum (전송될 다음 패킷의 순서 번호) 으로 정의한다면, 순서 번호의 범위에서 4개의 간격을 인식할 수 있다.

• Sender Behavior in GBN:
  • The window slides forward over the sequence number space, making N the window size.
  • N is referred to as the window size, and GBN is considered a sliding-window protocol.
  • Flow control and congestion control are some of the reasons for limiting the number of unacknowledged packets to N.

N을 윈도크기 (window size)라고 부르며, GBN 프로토콜은 슬라이딩 윈도 프로토콜 (sliding window protocol)이라고 부른다.

실제로 패킷의 순서 번호는 패킷 헤더 안의 고정된 길이 필드에 포함된다. 만약 k가 패킷 순서 번호 필드의 비트 수라면, 순서 번호의 범위는 [ 0,2^k-1] 이 된다. TCP가 32비트 순서 번호 필드를 갖게 된다.

GBN송신자는 세 가지 타입의 이벤트에 반응해야한다.

1. 상위로부터의 호출 : rdt_send()가 위로부터 호출되면, 송신자는 우선 윈도가 가득 찼는지, 즉 N개의 아직 확인응답되지 않은 패킷이 있는지를 확인한다. 만약 윈도가 가득 차 있지 않다면 패킷이 생성되고 송신된다. 그리고 변수들이 적절하게 갱신된다. 만약 윈도가 가득 차 있다면, 송신자는 윈도가 가득 차 있음을 가리키는 함축적인 의미로 단지 데이터를 상위 계층으로 반환된다.
2. ACK의 수신 : GBN 프로토콜에서 순서 번호n을 가진 패킷에 대한 확인 응답은 누적 확인 응답 (cumulative acknowledgement)으로 인식된다. 이 누적 확인응답은 수신 측에서 올바르게 수신된 n을 포함하여, n개의 순서 번호를 가진 모든 패킷에 대한 확인 응답이다.
3. 타임아웃 이벤트 : 타이머는 손실된 데이터 또는 손실된 확인응답 패킷으로부터 회복하는 데 사용된다. 만약 타임아웃이 발생한다면, 송신자는 이전에 전송되었지만 아직 확인응답되지 않은 모든 패킷을 다시 송신한다.

GBN 프로토콜에서는 수신자는 순서가 잘못된 패킷들을 버린다.

수신자가 상위 계층에 데이터를 전달해야한다는것을 기억하자.

윈도 크기의 제한때문에, 송신자는 윈도우 사이즈만큼 송신한다. 그러나 송신을 계속 하기 전에 하나 이상의 패킷이 긍정 확인 응답되는 것을 기다려야한다. 각각의 성공적인 ACK가 수신되었을 때, 윈도는 앞으로 이동하고 송신자는 하나의 새로운 패킷을 전송한다. 수신 측에서는 패킷이 손실되었으므로, 다음 패킷의 순서가 잘못된 패킷으로 발견되어 제거된다.

3.4.4 SR Selective Repeat (SR)

수신자에서 오류 (손실되거나 변조된) 가 발생한 패킷을 수신했다고 의심되는 패킷만을 송신자가 다시 전송하므로 불필요한 재전송을 피한다. 필요에 따라 각각의 개별적인 재전송은 수신자가 올바르게 수신된 패킷에 대한 개별적인 확인응답을 요구할 것이다.

SR 수신자는 패킷의 순서와는 무관하게 손상 없이 수신된 패킷에 대한 확인응답을 할 것이다. 순서가 바뀐 패킷은 바진 패킷(아직 도착하지 않은 더 낮은 순서 번호를 가진 패킷)이 수신될 때까지 버퍼에 저장하고, 빠진 패킷이 수신된 시점에서 일련의 패킷을 순서대로 상위 계층에 전달할 수 잇다.

너무 큰 윈도를 가진 SR 수신자의 고민 : 새 패킷인가, 아니면 재전송 된 패킷인가?

 

3.5 연결지향형 트랜스포트 : TCP  TCP (Transmission Control Protocol)

3.5.1 TCP 연결

TCP는 애플리케이션 프로세스가 데이터를 다른 프로세스에게 보내기 전에, 두 프로세스가 서로 “핸드셰이크” 를 먼저 해야함으로, 연결지향형 (connection-oriented)이다. 즉 데이터 전송을 보장하는 파라미터들을 각자 설정하기 위한 어떤 사전 세그먼트들을 보내야한다. TCP 연결 설정의 일부로서, TCP 연겨로가 연관된 많은 TCP 상태 변수를 초기화한다.

TCP프로토콜은 오직 종단 시스템에서만 존재하고 중간의 네트워크 요소(라우터와 링크 계층 스위치)에서는 동작하지 않으므로, 중간의 네트워크 요소들은 TCP연결 상태를 유지하지 않는다.

TCP 연결은 전이중 서비스 (full-duplex service)를 제공한다. 두 호스트 사이에 3개의 세그먼트가 보내지므로, TCP 연결 설정 절차는 세 방향 핸드셰이크 (three-way-handshake) 라 부른다.

일단 TCP연결 설정이 되면, 두 애플리케이션 프로세스는 서로 데이터를 보낼 수 있다.

TCP는 초기 세 방향 핸드셰이크 동안 준비된 버퍼에서 데이터 묶음을 만들어선 네트워크로 보낸다. 세그먼트로 모아 담을 수 있는 최대 데이터의 양은 최대 세그먼트 크기 (maximum segment size,MSS)로 제한된다. MSS는 일반적으로 로컬 송신 호스트에 의해 전송될 수 있는 가장 큰 링크계층 프레임의 길이 (최대 전송 단위 maximum transmission unit, MTU)에 의해 결정된다.

TCP는 TCP 헤더와 클라이언트 데이터를 하나로 짝지어 TCP 세그먼트를 구성한다. 세그먼트는 네트워크 계층에 전달되며, 네트워크 계층 IP 데이터그램 안에 각각 캡슐화된다.

3.5.2 TCP 세그먼트 구조

TCP 세그먼트는 헤더 필드와 데이터 필드로 구성되어 있다.

데이터 필드는 애플리케이션 데이터의 일정량을 돕는다.

UDP 처럼 헤더는 상위 계층 애플리케이션으로부터 다중화와 역다중화를 하는 데 사용하는 출발지와 목적지 포트 번호를 포함한다. 또한 UDP 처럼 헤더는 체크섬 필드를 포함한다. 또한 다음과 같은 필드를 포함한다.

• 32비트 순서 번호 필드와 32비트 확인응답 번호 필드
• 16비트 수신 윈도 (receive window) 필드는 흐름제어에 사용된다.
• 4비트 헤더 길이 필드 (header length filed) 는 32비트 워드 단위로 TCP 헤더의 길이를 나타낸다.
• 선택적이고 가변적인 길이의 옵션 필드 (option filed) 는 송시낮와 수신자가 최대 세그먼트 크기를 협상하거나 고속 네트워크에서 사용하기 위한 윈도 확장 요소로 이용된다.
• 플래그 필드는 6비트를 포함한다. ACK 비트는 확인응답 필드에 있는 값이 유용함을 가리키는 데 사용된다.

순서 번호와 확인응답 번호

TCP는 데이터를 구조화되어 있지 않고 단지 순서대로 정렬되어 있는 바이트 스트림으로 본다. TCP의 순서 번호 사용은 순서 번호가 일련의 전송된 세그먼트에 대해서가 아니라, 전송된 바이트의 스트림에 대해서라는 관점을 반영한 것이다. 세그먼트에 대한 순서 번호는 세그먼트에 있는 첫 번째 바이트의 바이트 스트림 번호다.

 

3.5.3 왕복 시간(RTT) 예측과 타임아웃

타임아웃은 세그먼트가 전송된 시간부터 긍정 확인응답 될 때까지의 시간인 연결의 왕복시간인 (RTT)보다 좀 커야한다. 그렇지 않으면, 불필요한 재전송이 발생할 것이다.

왕복시간 예측

SampleRTT라고 표시되는 세그먼트에 대한 RTT 샘플은 세그먼트가 송신된 시간, 즉 IP에게 넘겨진 시간으로부터 그 세그먼트에 대한 긍정응답이 도착한 시간가지의 시간 길이이다.

모든 전송된 세그먼트에 대해 SampleRTT를 측정하는 대신, 대부분의 TCP는 한 번에 하나의 SampleRTT 측정만을 시행한다. 즉 어떤 시점에서 SampleRTT는 전송되었지만 현재까지 확인응답이 없는 세그먼트 중 하나에 대해서만 측정되어 이는 대략 왕복 시간마다 SampleRTT의 새로운 값을 얻게한다.

3.5.4 신뢰적인 데이터 전송

인터넷의 네트워크 계층 (IP서비스) 은 비신뢰적이다. 인터넷 프로토콜은 데이터그램 전달을 보장하지 않고, 데이터그램이 순서대로 전달된다는 것을 보장하지 않는다. 또한 데이터그램에 포함된 데이터의 무결성을 보장하지 않는다. IP 서비스에서 데이터

TCP의 데이터 전송/재전송에 관련된 세가지 주요 이벤트가 있음을 볼 수 있는데,

1. 상위 애플리케이션으로부터 수신된 데이터
2. 타이머 타임 아웃
3. ACK 수신

그림 3.36 자료

누적 확인응답은 첫 번째 세그먼트의 재전송을 방지한다.

빠른 재전송

타임아웃이 유발하는 재전송의 한 가지 문제는 타임아웃의 주기가 때때로 비교적 길다는 점이다. 세그먼트를 잃었을 때, 긴 타임 아웃 주기는 잃어버린 패킷을 다시 보내기 전에 송신자를 오랫동안 기다리게해서 종단 간의 지연을 증가시킨다.

GBN인가? SR인가? TCP 확인응답은 누적되고 올바르게 수신되지만, 순서가 잘못된 세그먼트는 수신자가 개별적으로 ACK를 받지 않는다는 점을 기억하기를 바란다. GBN 형태의 프로토콜과 매우 비슷해보인다.TCP에서 수정 제안된 선택적 확인응답은 TCP 수신자가 마지막으로 올바로 수신된 ‘순서가 맞는’ 세그먼트에 대해 누적확인응답을 하기보다는 ‘순서가 틀린’ 세그먼트에 대해 선택적으로 확인응답을 하게 된다.

선택적 재전송과 결합했을 경우(이미 수신자가 선택적 확인응답을 한 세그먼트의 재전송은 제외), TCP는 원래의 SR 프로토콜과 매우 유사하다.

TCP의 오류 복구 메커니즘은 GBN과 SR 프로토콜의 혼합으로 분류하는 게 맞다.

3.5.5 흐름제어

TCP에서는 송신자가 수신자의 버퍼를 오버플로우 시키는 것을 방지하기 위해 애플리케이션에게 흐름제어서비스를 제공한다. 이와 같이 흐름제어는 속도를 일치시키는서비스다. 수신하는 애플리케이션이 읽는 속도와 송신자가 전송하는 속도를 같게한다.

TCP는 손신자가 수신윈도 (receive window)라는 변수를 유지하여 흐름 제어를 제공한다. 수신 윈도는 수신 측에서 가용된 버퍼 공간이 얼마나 되는지를 송신자에게 알려주는 데 사용된다.

TCP는 전이중 이므로 연결의 각 측의송신자는 별개의수신 윈도를 유지한다. TCP는 할당된 버퍼의 오버플로를 허용하지 않으므로 다음 수식이 가능하다.

rwnd는 시간에 따라 여유 공간은 변함으로 동적이다.

TCP 연결 관리

데이터를 교환하기 전에, 송신자와 수신자는 핸드쉐이크를 한다. 연결 설정에 동의하기