[Network] Top Down Approach 3장: Transport Layer
CS/Network

[Network] Top Down Approach 3장: Transport Layer

Transport Layer

Transport Layer는 Application layer와 Network layer 사이에 존재하는 layer로 서로 다른 host에서 동작하는 application 프로세스들 간의 논리적 통신을 제공함


Transport-layer services

  • 특징
    • Transport protocol은 host에서만 존재한다.
    • Send side: 보내는 App messages를 segment로 나눠서 network layer로 전달함
    • Receive side: segment를 다시 message로 재구성해서 app layer로 전달함
    • 하나 이상의 transport protocol이 app에 존재함 ex) Internet: TCP, UDP
  • Transport vs Network layer
    • Transport protocol은 서로 다른 호스트에서 동작하는 프로세스 사이의 통신을 제공
    • Network protocol은 호스트들 사이의 논리적 통신을 제공
  • Internet transport layer protocols
    • 앞장에서 언급한 TCP/IP 네트워크는 어플리케이션 계층에게 두가지 구별되는 transport layer protocols를 제공 -> UDP, TCP
    • TCP: 신뢰적이고 순서가 있음, integerity(무결성)만 보장
    • UDP: 비신뢰적이고 비연결형 서비스 제공, 무결성 타이밍 처리량 보안 중 아무것도 보장 안함

Multiplexing and demultiplexing

  • 다중화와 역다중화라고 한다.
  • 우선, application layer와 transport layer 사이에 존재하는 socket은 네트워크에서 프로세스로 데이터를 전달하고 프로세스에서 네트워크로 데이터를 전달하는 출입구 역할을 한다. 이 부분이 다중화, 역다중화의 역할과 매우 비슷함
  • 비유하자면, 1번 집에 사람 a,b,c가 있고 2번 집에 사람 d,e,f가 있을 때 1번 집에서 c가 a,b의 편지를 모아서 우편배달부에게 전달하는 작업을 '다중화'라고 하고 반대로 2번 집에서 d가 우편 배달부에게 편지를 받아서 e,f에게 나눠주는 것을 '역다중화'라고 함
  • Multiplexing: Application layer에서 받은 데이터를 조각내서 segment로 만들고 각 segment에 Header 정보를 넣어 캡슐화하고, 그 segment들을 network layer로 전달하게 되는데 여기서 '캡슐화해서 network layer로 전달하는 과정'을 다중화라고 함
  • Demultiplexing: 받은 host 쪽에서 segment 내부의 IP address & port number를 확인해서 segment를 적절한 socket으로 전달하는데, 이 과정을 '역다중화'라고 함

UDP 소켓을 이용한 다중화, 역다중화

  • 위 그림은 서버에 6428포트, 클라이언트 각각에 대해 9157, 5775 포트 번호를 적용해 소켓을 생성한 그림임
  • 서로 다른 출발지, datagram이 들어오는데도 불구하고 UDP에서는 목적지 IP 주소와 목적지 포트 번호가 같으면 2개의 segment(Datagram 내부의)들은 같은 목적지 소켓을 통해 동일한 프로세스로 향하게 됨

TCP 소켓을 이용한 다중화, 역다중화

  • TCP 소켓과 UDP 소켓의 차이점: TCP 소켓은 4개 요소들의 튜플에 의해서 식별
    1. 출발지 IP 주소
    2. 출발지 port number
    3. 목적지 IP 주소
    4. 목적지 port number
  • 즉, 역다중화를 할 때 해당되는 socket으로 segment 전달하기 위해 4개의 값을 모두 사용함

Connectionless transport: UDP

  • 비연결형 프로토콜로 handshaking 과정도 필요없고 각각의 UDP segment는 독립적으로 처리됨
  • UDP Segment Header
    • length: UDP segment의 길이. 2^16 = 약 65535 바이트 = 64KB가 UDP 세그먼트가 보낼 수 있는 크기
    • checksum: 에러를 판별하기 위한 부분. 즉, segment가 출발지-목적지로 이동했을 때 비트에 변경사항이 있는지 검사하는 부분

Principles of reliable data transfer

기본 지식

  • Application, trnasport, link layers에서 중요한 부분이다.
  • 기본 함수
    • rdt_send(): 송신측이 호출되고 있다는 것. 보낼 준비
    • rdt_rcv(): 패킷이 수신측으로 도착했을 때 호출
    • deliver_data(): 상위계층으로 데이터를 전달하려고 할 때
    • udt_send(): 이제 패킷을 보낼건데, 신뢰적이지 않은 채널을 통해 보내겠다는 것
  • 기본 그림
    • 위 이미지는 FSM(유한 상태 머신)이며 화살표는 단방향으로 동작함
    • FSM의 3가지 요소
      • state: 동그라미(노드) 안의 글자. 다음 이벤트를 결정하는 요소
      • event: 전송이 일으키는 사건
      • actions: 이벤트 발생시 취하는 행동
  • 가정: 패킷들이 순서대로 전달된다는 것

rdt 1.0 - 완전하게 신뢰적인 채널에서의 프로토콜

  • 가장 이상적인 프로토콜로 단순하며 따로 예외 처리도 필요없음 -> 실제로 존재하지는 않음
  • Sender 과정
    1. state: 위에서부터 호출을 기다림
    2. event: rdt_send(data)로 상위 계층으로부터 데이터를 받아들임
    3. actions: make_pkt(data) 데이터를 포함한 패킷을 생성
    4. event: udt_send(packet) 패킷을 채널로 송신
  • Receiver 과정
    1. event: rdt_rcv(packet) 하위의 채널로부터 패킷을 수신
    2. extract(packet, data) 데이터를 추출
    3. deliver_data(data) 데이터를 상위 계층으로 전달
  • 장점
    • 오류가 생길 수 없어 수신 측이 피드백을 제공할 필요가 없음
    • 패킷 손실이 일어나지 않음

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

  • 비트 오류에 대한 해결책으로 재전송(retransmission)을 제시
  • 재전송을 하려면 수신자가 잘 받았는지 못 받았는지 말을 해줘야 알 수 있는데 rdt 2.0에서는 수신 측의 피드백을 통해 이를 처리
    • ACK: 긍정 확인 응답, NAK: 부정 확인 응답
  • 과정
    1. 보내는 측에서 데이터 보냄 rdt_send(data) -> 체크섬을 포함 시켜서 보냄 -> ACK or NAK를 기다리는 상태로 변경됨
    2. 받는 측에선 checksum을 이용해 데이터 오류가 났는지 확인 후 오류면 NAK, 오류 아니면 ACK을 송신측에 보냄
    3. 다시 보내는 측에서는 NAK가 오면 재전송을 하고 ACK가 오면 아무것도 안하고 다시 위에서부터 데이터 보내길 기다리는 상태로 바뀜

rdt 2.1 - receiver's FSM

송신자
수신자

  • rdt 2.0의 수정된 버전
  • 위의 rdt 2.0의 과정에서 보내는 측에서 보낸 ACK, NAK가 손상되면? -> 데이터 패킷에 sequence number를 삽입 = rdt 2.1
  • 송신자
    • 이미지에서 보면 패킷에 0을 추가하는게 있는데 이게 sequence number 다.
    • 먼저 패킷(0)을 보내고 ACK or NAK 0을 기다리는 상태로 변경됨
    • 만약 패킷이 손상되거나 NAK가 오면 다시 보냄
    • 만약 패킷이 손상되지 않고 ACK가 오면 아무것도 안함 -> 그리고 다음 상태로 넘어감
    • 다음 상태는 위에서 데이터 1을기다리는 상태
    • 먼저 패킷(1)을 보내고 ACK or NAK 1을 기다리는 상태로 변경됨
    • 만약 패킷이 손상되거나 NAK가 오면 다시 보냄
    • 만약 패킷이 손상되지 않고 ACK가 오면 아무것도 안함 -> 그리고 다음 상태로 넘어감
  • 수신자
    • 먼저 0 패킷이 오길 기다림
    • 이때 패킷이 손상되면 NAK을 보냄
    • 패킷이 손상되지 않았지만 받은 패킷의 sequence number = 1이면 ACK을 보내고 다시 0 패킷이 올때까지 기다림
    • 제대로 왔다면(패킷 손상x, 0인 패킷 왔을 때) 추출하고 위로 보내고 ACK을 보냄
    • 비슷하기 1에서도 작동
  • rdt2.1은 순서가 바뀐 패킷이 수신되면 수신자는 ACK을 보냄. 즉, 0을 요청했는데 1을 받아도 ACK를 보냄
  • rdt2.1이 복잡하기 때문에 NAK를 ACK로 대체하는 방법이 나옴 -> rdt 2.2

rdt 2.2 - a NAK-free protocol

  • rdt 2.1 버전에서 NAK을 사용하지 않은 프로토콜
  • ACK가 제대로 와야 다음으로 진행하는 것을 볼 수 있음
  • NAK 역할을 잘못된 sequence number를 지닌 ACK가 대체하게 됨

rdt 3.0 - channels with errors and loss

sender

  • 이전에는 bit error에 대한 오류만 처리했는데 rdt 3.0에서는 패킷이 유실되는 경우에 대한 처리가 추가됨
  • 타임 아웃: 패킷이 손실되지 않고 제대로 갔는지 타이머를 통해 확인
  • 과정
    • 0 패킷을 보낼 때 타이머를 작동시키고 ACK 0이 오길 기다린다.
    • 근데 ACK 0 이 제시간에 안오면(time out) 다시 보내고 다시 타이머를 작동시킨다.
    • 제대로 올 경우 타이머를 멈춘다(stop_timer)
    • 1인 경우도 동일하다.
    • 받는 것은 rdt 2.2와 같다.

Pipelined protocols

  • 송신자와 수신자 사이에 파이프를 연결하여, 송신자가 여러 개의 패킷을 마치 비행기를 타고 날아가는 것처럼 보내게 됨
  • 여러 개의 패킷을 동시에 보내기 때문에 sequence number를 0, 1뿐 아니라 여러개로 늘려야 하며 여러개의 패킷을 담을 수 있게 버퍼를 만들어 주어야 함 -> 하지만 전송시간이 매우 빠름
  • 형태
    1. Go-back-N (GBN) - N부터 반복
      • Sender가 확인 응답을 기다리지 않고 여러 패킷을 전송 -> 조건: 파이프라인에서 확인 응답이 안된 패킷의 최대 허용 수 N보다 크지 않아야 함
      • 특징
        • Sender는 확인응답이 되지 않은 N개의 패킷을 파이프라인 안에서 가질 수 있음
        • Receiver는 받은 패킷들에 대해서 마지막 패킷에 대해서만 ACK를 보냄
        • Sender는 가장 오래된 '전송되었지만 아직 확인 응답이 오지 않은 패킷'에 대한 타이머만 사용
        • 위 그림과 같은 직사각형의 윈도를 가짐 == 슬라이딩 윈도우
        • 만약 base패킷이 아닌 이후의 패킷에 대한 ack 응답이 먼저 왔다면, 그 이전의 패킷들은 모두 ACK처리
        • 만약 패킷 n+1이 먼저 도착했고, n이 수신되었는데 n이 손실되었다면(time-out 포함) n이상의 패킷들은 모두 재전송해야 함
    2. Selective repeat - 선택적 반복
      • GBN는 이전 패킷에 대한 손실이 발생하면 쓸데없이 다른 패킷들도 재전송한다는 불필요한 action이 있음
      • Selective repeat는 이 단점을 보완한 프로토콜로, 오류가 발생한 패킷만 sender가 다시 전송
      • 문제점: 위 이미지처럼 sequence number가 3가지로 이루어져 있고, 윈도우 크기가 3이면 전송 중에 같은 sequence number가 동시에 움직일 경우, 송수신자에게 혼란을 야기할 수 있음 -> 따라서 sequence number는 적어도 윈도우 크기 2배는 넘어야함

Connection-oriented transport: TCP

TCP 특징

  • point-to-point: 송신자, 수신자가 서로 1대 1로 데이터를 주고 받는다.
  • Connection-Oriented, Flow Control, Congestion Control 등을 통해 신뢰적인 데이터 전송이 가능하다.
  • Pipelining을 지원한다.
  • 데이터의 순서를 보장하며, Byte-Stream이다. 즉, Byte 단위로 데이터를 쪼개어 segment화 해서 보낸다.
  • 양방향 연결 서비스를 제공한다. A에서 B로 데이터를 전송할 때 동시에 B에서 A방향으로 데이터 전송이 가능하다.
  • 혼잡 제어, 흐름 제어 기능을 가지고 있다.
  • 3-way handshake를 사용해 연결 지향적이다.

TCP segment 구조

  • TCP segment는 크게 Header와 Payload로 나뉜다.
  • Header는 고정 파트와 가변 파트로 나뉘는데, 가변적인 길이 때문에 Header 길이에 대한 필드가 존재한다. UDP는 Header가 고정이라 segment 전체에 대한 길이 필드가 있다.
  • TCP Header: Sequence Number, ACK Number, Receive Window, Checksum, Flag
  • Sequence Number란 segment에 실은 데이터의 첫 번째 바이트의 번호이다.
  • Acknoledgements (ACKs)란 받기를 희망하는 다음 바이트의 sequence number이다. 이 번호는 해당 번호 이전까지의 데이터는 순서대로 잘 받았다는 의미를 내포하고 있다.

TCP round trip time, timeout

  • TCP에는 segment를 전달하고 특정 RTT만큼 기다렸으나 ACK 응답이 오지 않는다면 패킷을 다시 보내도록 설정하는 Timer 기능이 있다. 하지만 해당 RTT를 예측하는 것은 어렵다. 너무 작게 설정하면 데이터를 불필요하게 재전송할 것이고 너무 길면 segment 유실이 발생했을 대 반응이 너무 늦어진다.
  • 따라서 ACK응답이 올 때마다 샘플 RTT들을 뽑아서 평균 RTT를 계산한다.

Reliable Data Transfer

  •  

Principles of congestion control

TCP congestion control

 

 

참고

https://suhwanc.tistory.com/105?category=781986 

https://xlffm3.github.io/network/a-top-down-approach-chapter-3/

 

728x90
반응형