CS

컴퓨터 네트워크 개론 (3) - Transport Layer 1/2

Transport Layer(111)
  • 수업목표
    • Tansport layer services에 대한 원리 이해
      • multiplexing, demultiplexing
      • reliable data transfer
      • flow control
      • congestion control
    • Internet transport layer protocol
      • UDP: connectionless transport
      • TCP: connection-oriented reliable transport
      • TCP congestion control

 

Transport-layer services

  • Transport services and protocols
    • 서로 다른 host에서 실행중인 Application process 사이의 논리적 통신 제공
    • transport protocols는 end-system에서만 사용됨
      • sender: application message를 segments로 쪼갬, network layer로 보냄
      • receiver: sements를 재조립해서 messages로 만듦, application layer로 보냄
  • Transport vs Network layer services and protocols
    • Network layer: hosts 간의 논리적인 통신
    • Transport layer: Processes 간의 논리적인 통신→ network layer services에 의존

 

  • Transport layer actions
    • Sender
      • App-layer message를 전달받음
      • segment 헤더 filds 값을 결정함
      • segment 생성
      • segment를 IP로 보냄
    • Receiver
      • IP로부터 segment를 받음
      • header values를 확인
      • application-layer message 추출
      • socket을 통해 message를 app으로 demultiplex

 

  • Two principal Internet transport protocols
    • TCP: Transmission Control Protocol
      • reliable, in-order delivery → error 발생시 recovery 실시
      • Connection-oriented(Connection setup)
      • Flow control
        • 송신 측에서 보내는 속도를 조절 → 수신측 큐가 넘치지 않도록 관리
        • 수신측에서 송신측에서 보내는 데이터를 받아 상위 계층으로 보낼 때 자신이 받은 데이터를 queue를 통해 관리하게 되는데 이 큐보다 많은 양의 데이터가 들어오는 것을 막아 loss 발생을 방지하는 것
      • Congestion control
        • 송신 측에서 보내는 속도를 조절 → 네트워크 상에서 buffer overflow가 발생하지 않도록 관리하는 것을 의미
        • network 상에는 sender가 보내는 것을 임시 저장하는 buffer가 존재하고 그 buffer가 가득차게 되면 다음에 오는 것들이 loss가 일어나 reliable하지 않게 됨. 이를 막기 위해 congestion control이 필요
    • UDP: User Datagram Protocol
      • unreliable, unordered delivery
      • no-frills(장식이 없는, 불필요한 서비스가 없는) extension of ‘best-effort’ IP
    • TCP와 UDP 모두 delay & bandwidth guarantee를 보장하지는 않음

 

Multiplexing and demultiplexing

  • 많은 app들은 단일 transport layer protocol을 사용함
  • Multiplexing
    • sender 측에서 진행, 여러 socket에서 오는 데이터들에 transport header 추가하여 보냄
  • Demultiplexing
    • receiver 측에서 진행, segment에서의 header 정보를 이용해 적절한 socket으로 보냄

 

  • Demultiplexing
    • Host가 IP datagram을 받음
      • 각 datagram은 source IP 주소와 destination IP 주소를 가짐
      • 각 datagram은 하나의 transport-layer segment를 운반함
      • 각 segment는 source, destination port number를 가짐
    • host는 (IP 주소 + port 번호)를 바탕으로 적절한 socket에 보냄

 

  • UDP에서의 demultiplexing
    • socket을 만들 때 반드시 host-local 포트 번호를 명시해야 함
    • UDP socket에 넣을 datagram을 만들 때 목적지 IP 주소와 port # 을 명시해야 함
    • Host가 UDP segment를 받으면 segment의 destination port#을 확인함
    • UDP segment를 그 port #에 해당하는 socket으로 보냄
    • Source IP 주소나 port #이 다르더라도 destination port #이 같으면 송신 host의 같은 socket에 연결됨
    • 1대 다 통신이 가능(하나의 socket이 여러 개의 process와 연결 가능)

 

  • TCP에서의 demultiplexing
    • TCP socket은 4가지 tuple로 구분지어진다. (Source IP, port# / Dest IP, Port#)
    • demux: receiver는 segement를 올바른 socket에 연결시키기 위해 4가지 정보 모두 이용
    • 서버는 동시에 여러 TCP socket 연결을 지원할 수 있음
      • 각 socket은 저마다의 4 tuple로 구분됨
      • 각 socket은 서로 다른 client 하나씩과 연결됨
      • 각 socket은 1대1 통신만 가능
    • 세가지 segments는 모두 IP address: B, port#: 80으로 동일하지만 서로 다른 sockets으로 demuliplexed됨.
  • 요약
    • Multiplexing과 Demultiplexing은 segment, datagram의 헤더 파일 값을 기반으로 동작
    • UDP: Demultiplexing 시 port number만 사용
    • TCP: Demultiplexing 시 4-tuple 사용(Source, Dest/IP, Port#)
    • Multiplexing과 Demultiplexing은 모든 layer에서 발생함

 

 

UDP: Conntionless transport

  • UDP: User Datagram Protocol
    • A simple connectionless Internet transport protocol
      • Connection을 위한 핸드쉐이킹 과정이 필요없으며 각각의 UDP segment들은 독립적으로 관리가 됨.
    • No reliability
      • Segment가 loss되거나 순서가 박살나도 recovery 작업 안함(’best effort’)
      • Flow/Congestion Control 안함
      • Error Check: Checksum이용하는 것 외에는 안함
    • 장점
      • 구현상 간단함(header size가 작음)
      • Congestion control이 없기 때문에 sender는 빨리빨리 보낼 수 있음
      • no connection establishment → RTT delay 감소
      • Connection overhead가 발생하지 않음(Connectioneless의 장점)
      • 1대다 통신이 가능
    • Streaming Multimedia Service, DNS, HTTP/3에 사용됨
      • loss가 조금 발생해도 됨
      • 빠르게 보내는 것이 중요
    • Reliablity 혹은 Congestion control의 경우 UDP 자체에서는 불가능 → app layer에서 해결을 해주어야 함
  • UDP: Transport Layer Actions
    • UDP Sender:
      • app단 message 받음
      • UDP segment 헤더 파일 값들 결정
      • UDP segment 생성
      • IP로 segment를 넘김
    • UDP Receiver
      • IP로부터 segement를 받음
      • UDP checksum 헤더값 확인
      • App단 message 추출(Payload part)
      • socket을 통해 application으로 message를 demultiplexing함
  • UDP segement header
    • Source port #, dest port #, length, checksum 각각 16bits
    • 뒤에 application data(payload)가 옴

 

  • UDP checksum
    • Goal: 전송된 segment에서 flipped bits와 같은 error를 찾는 것
    • 데이터들을 모두 16bit 정수의 나열로 봄
    • data들을 모두 16-bit 1’s 보수 arithmetic을 이용하여 더하고 결과에 1의 보수를 취함
    • 더할 떄 carryout → result에 더해야 함
    • sender 측에서 checksum을 계산하여 보내고 그것을 이용하여 receiver 측은 모든 데이터에 checksum까지 더해서 error check 진행
    • 해당 결과가 모두 1이라면 에러가 없는 것이고 0이 포함된다면 에러가 존재함

 

  • UDP는 큰 데이터를 보낼 수 있지만 잘 안보냄. 큰 데이터를 보낼 떄 error handling이 안되서 비트 하나라도 잘못되면 전체를 다시 보내야 함. 사용자가 알아서 쪼개는 것을 추천.

 

Principles of reliable data transfer

 

  • 배경
    • 신뢰적 데이터 전송: 네트워킹에서 제일 중요한 개념
      • 하위 계층에서 상위 계층으로 데이터를 전송할 때 전송된 데이터가 손상되거나 손실되지 않게 보장하는 개념
      • 이러한 서비스 추상화를 구현하는 것은 신뢰적 데이터 전송 프로토콜의 의무임.
      • 아래에 있는 계층이 쌓이면 쌓일수록 아래에 있는 계층이 신뢰적이지 않을 가능성이 높아지기 때문에 어려워짐
    • Transport Layer에서는 신뢰성 있는 데이터 교환을 하고 싶어하지만 하위 레이어들에게서는 신뢰성을 보장할 수 없기 때문에 문제가 발생할 수 있음.
      • 이를 해결하기 위해 Transport Layer에서 RDT 프로토콜 사용
    • Unreliable channel
      • 신뢰성이 보장되지 않는 곳에서 두 가지 현상이 발생함
        • 패킷 error: 패킷/메시지에 에러가 생겨 기존과 다르게 변경됨(wrong data)
        • 패킷 loss: 패킷이 제대로 전달되지 않고 중간에 유실됨
      • 이 두가지 현상을 해결하면 네트워크 상에서는 reliable하다고 말함
    • 신뢰성을 보장하는 법
      • 정상적으로 패킷이 전달되었는지 확인하고, 제대로 전송되면 다음 패킷을 전송함
  • message를 통해 통신하지 않으면 송수신자 모두 상대방의 상태를 알 수가 없음. (message가 도달했는지조차)
  • Reliable data transfer protocol(rdt): interfaces
    • Unreliable channel에서의 양방향 통신
    • rdt_send(): 상단 layer에서 호출함. receiver의 상단 layer로 전달하고자 함
    • udt_send(): unreliable channel을 거쳐 receiver까지 packet을 전달하기 위해 rdt에서 호출
    • rdt_rcv(): packet이 receiver side에 도달했을 때 호출됨
    • deliver_data(): data를 상단 layer로 전달하기 위해 rdt에서 호출

 

 

  • RDT(Reliable Data Transfer)
    • RDT 프로토콜의 sender와 receiver를 점진적으로 develop 할 것임
    • 단방향 데이터 전송만 고려
      • control 정보는 양방향으로 흐름
    • FSM(유한 개의 상태를 가지고 주어지는 입력에 따라 어떤 상태에서 다른 상태로 전이되거나 또다른 출력 같은 것들이 일어나게 하는 장치를 나타낸 모델)을 사용

 

  • RDT 1.0: reliable transfer over a reliable channel
    • 하위 계층이 완벽하게 신뢰성 높도록 데이터를 전송할 때
      • no bit errors/loss of packets
    • Sender와 Receiver 각각 FSM을 분리
      • Sender는 하위 채널을 통해 data를 보냄
      • Receiver는 하위 채널을 통해 data를 읽음

 

 

  • RDT 2.0: Channel with bit errors
    • 하위 채널이 packet에서 일부 bits error 발생 가능
      • checksum으로 bit error 검출
    • Recover 하는 방법
      • ACKs(ACKnowledgements): 수신자가 송신자에게 그 ‘패킷 잘 받음’이라고 알려줌
      • NAKs(Negative AcKnowledgements): 수신자가 송신자에게 그 ‘패킷 에러가 있음’이라고 알려줌
      • 송신자는 NAK를 받으면 패킷을 재전송함
    • Stop and wait: 송신자가 하나의 패킷을 보내고, 수신자의 response를 기다림
    • 치명적인 결함: ACK와 NAK패킷 자체의 손상을 가정하지 않음!
      • 송신자는 수신자에게 무슨 일이 일어났는 지 모름!
      • 단순히 재전송 하면 안됨. 중복 발생 가능성.
      • ACK/NAK가 소실된 경우 무한히 기다릴 수도 잇음
    • 중복 처리
      • 송신자는 ACK/NAK이 손상되면 현재 패킷을 재전송함
      • 송신자는 각 패킷에 sequence number를 붙임
      • 수신자는 중복 패킷을 버림(=상단 계층에 deliver하지 않음)
    • Error 없이 작동할 때

    • Packet Error 발생

 

 

 

 

 

  • RDT 2.1: Sender, handling garbled ACK/NAKs
    • RDT 2.0에 시퀀스 넘버를 추가한 방식
      • Sequence 번호를 정함→ 해당 패킷이 새로운 데이터를 전송하는 것인지 NAK를 받아 재전송한 것인지를 구분하기 위한 것
      • ACK과 NAK에는 sequence number가 들어갈 필요가 없음
        • Stop and Wait방식을 사용하기 때문
    • 송신 FSM
      • 송신 측에서 0번 패킷을 보내고 ACK 0 혹은 NAK 0 신호를 기다린다.
      • 0번 패킷이 수신 측에서 에러가 발생했다면 NAK 0를 받을 것이고 수신 측으로 0번 패킷을 재전송할 것이다.
      • 0번 패킷이 정상적으로 전송되었다면 ACK 0를 받을 것이고 다음 패킷인 1번 패킷을 전송한다.
      • 마찬가지로 ACK 1 혹은 NAK 1 신호를 기다리고 위와 같은 과정을 모든 패킷을 보낼 때까지 반복한다.

      • 따라서 순서 번호는 0과 1이면 충분함. 순서 번호는 패킷의 중복 재전송을 막기 위해 부여하는 것이므로 중복인지 아닌지 판단하는 데에는 0과 1 이면 충분하기 때문.
      • 수신한 ACK/NAK가 손상되었는지 반드시 확인 필요
      • 두 배의 state가 필요(state가 예상 패킷이 seq 0인지 1인지를 기억해야 하기 때문)

    • 수신 FSM
      • 0번 패킷에 오류가 있다면 NAK 0 신호를 보내고 0번 패킷이 오길 기다린다.
      • 0번 패킷에 오류가 없다면 ACK 0 신호를 보내고 1번 패킷이 오길 기다린다.
      • 1번 패킷에 오류가 있다면 NAK 1 신호를 보내고 1번 패킷이 오길 기다린다.
      • 1번 패킷에 오류가 없다면 ACK 1 신호를 보내고 0번 패킷이 오길 기다린다.

      • 받은 패킷이 중복인지 확인해봐야함
        • state가 0또는 1이 예상했던 패킷 넘버인지를 나타내줌
        • 수신자는 자기가 보낸 마지막 ACK/NAK가 송신자에게 Recived OK 였는지 여부를 알 수 없음

 

  • RDT 2.2: NAK-free 프로토콜
    • 2.1과 같은 기능을 가짐
    • NAK대신 ACK만을 사용한다는 점이 다름
    • 중복되는 ACK 신호(⇒NAK랑 같은 역할)를 받으면 현재 패킷을 다시 재전송하면 된다.
    • 예를 들어 0번 패킷을 보내고 제대로 송신되어서 ACK 0를 받았다고 하자.
    • 이후 1번 패킷을 보냈는데 수신 측에서 오류를 탐지했다면, ACK 1이 아닌 가장 최근에 전송에 성공한 ACK 0를 보낸다.
    • 송신 측은 ACK 1을 기대했으나 ACK 0를 중복으로 받았으므로 오류가 발생했다는 사실을 알고 1번 패킷을 재전송한다.

 

 

  • RDT 3.0: Channels with erros and loss
    • dt 2.0/2.1/2.2는 패킷 에러에는 대응할 수 있으나 아직 큰 결함이 있음
      • 바로 ACK/NAK 혹은 패킷이 중간에 유실되는 경우에는 대응할 수 없다는 점임
      • 예를 들어 송신 측에서 ACK 신호를 기다리고 있으나 ACK 신호가 오지 않아 다음 패킷을 보내지 못할 수 있음
    • 그래서 rdt 3.0 은 다음과 같은 방법을 사용한다.
      • 송신 측에서 ACK 신호를 "합리적인(reasonable)" 시간 동안 기다리고, 만약 ACK 신호가 이 시간 동안 도착하지 않으면 패킷을 재전송함
      • 중복 데이터 패킷 문제는 2.2에서 sequence number로 이미 해결함
    • 타이머가 짧으면
      • 빠르게 유실 상황 복구 가능(빠르게 상황 파악 가능)
      • 네트워크에 중복된 패킷이 자주 전송될 수도 있음
      • 중복 패킷은 버려지긴 하지만, 필요 없는 데이터를 보내면서 네트워크에 대한 오버헤드가 많아짐
    • 타이머가 길면
      • 데이터 전송에 충분한 시간을 주기 때문에 중복된 패킷이 전송되는 일도 적어짐
      • 네트워크에 대한 오버헤드 예방 가능.
      • 유실 상황에 대한 반응이 느린 단점이 있음
    • RDT 3.0 송신 FSM

 

 

  • RDT3.0 in action
    • rdt 3.0의 가장 큰 문제점: ACK 신호가 지연된다면 (d)와 같이 전송이 꼬이는 문제가 발생
    • 또한 rdt 3.0은 데이터를 하나 보내고 ACK 신호를 기다리면서 다음 데이터를 보내지 않아 성능이 매우 좋지 않음!
  • Performace of RDT3.0 (Stop-and-wait)
    • Usender(sender의 활용률) = utilization - 송신자가 보내는 데 소요하는 시간의 비율
      Usender = 0.00027
    • 매우 비효율적임.
  • RDT3.0: Pipelined protocols operation
    • pipelined protocols에서 pipelining은 송신자가 다수의 패킷을 한 번에 보내는 것
    • ACK신호를 받을 때까지 기다리다 ACK신호를 받고 나서 다음 데이터를 보내는 stop and wait 방식과 다르게 송신자가 ACKs 신호를 받지 않아도 패킷 여러 개를 보내는 방식
    • 송신자와 수신자가 버퍼를 가져야 함
    • 대표적인 두 가지 프로토콜로 Go-Back-N과 Selective Repeat이 있다.
    • Seq number의 범위는 증가해야 함

 

  • Pipelining: increased utilization

 

 

 

  • Go-Back-N: Sender
    • Go-Back-N 방식은 송신 측에서 한번에 전송할 패킷의 개수(window size)를 정함
    • 버퍼에 그 개수만큼의 패킷을 저장하여 전송
    • 버퍼를 window, 버퍼의 사이즈를 window size라고 함
    • 버퍼의 시작점인 send_base, 다음에 보낼 패킷 번호인 next_seq_num을 가짐
    • 수신 측은 이번에 받을 패킷의 번호를 기억함
    • 이때 수신측은 누적 ACK(Cumulative ACK)을 사용
      • ACK(n): 수신자가 n번 패킷까지 모두 제대로 받았음을 알리는 피드백(누적 피드백)
      • ACK(n)을 받으면 → send_base가 n+1부터 시작하도록 window를 앞으로 옮김
    • 각 버퍼가 전송될 때 ACK를 받지 못한 가장 오래된 패킷의 Timer를 기준으로 Timeout이 발생
      • timeout(n): window에서 seq # n 이상인 모든 패킷 재전송

 

  • Go-Back-N: Receiver
    • ACK-only: 그 시점까지 제대로 받았던 패킷 중에 순서를 맞추어서 들어온 가장 높은 번호로 ACK 정보를 보냄
      • 중복 ACK 발생 가능
      • rcv_base만 기억하면 됨
    • out-of-order 패킷에 대한 대응
      • 버리거나 저장: 구현에 따라서 달라짐
  • Go-Back-N in action
    • Timeout 발생시 window에 있는 모든 패킷을 다시 보냄

 

  • Selective Repeat
    • 고백엔의 비효율성을 해결하기 위한 방식
    • 송신측은 각 패킷마다 timer를 설정하고 패킷이 유실되었을 때 timeout 된 패킷만 선별적으로 재전송함. (GBN처럼 버퍼 모두를 전송하지 않음)
    • Go-Back-N처럼 ACK를 누적(cumulative)방식으로 보내게 되면 어디까지 패킷이 전송되었는지 알 수 없음
    • Selective Repeat에서는 패킷을 받을 때마다 각각 ACK를 전송시켜줌
    • ACK(n): n까지 모두 받았다는 게 아니라 n번 패킷을 받았다는 의미
    • ACK(n)을 받으면 n번 패킷을 윈도우에서 해제시켜줌
    • 그러나 패킷이 순서대로 정렬되어야 하므로 패킷이 유실되었을 때 그 패킷이 도착할 떄까지 다음 순서의 패킷을 임시로 저장해 둘 필요가 있음
    • n번을 받지 못하고 n+1, n+2번 패킷을 받았을 때 이를 수신 측 recv 버퍼에 저장함
    • GBN보다 효율적으로 보이지만 모든 패킷에 timer가 있기 때문에 overhead가 큼
  • Selective repeat: sender, receiver windows
    • go-back-N과는 다르게 초록색(ACKed)의 패킷이 중간중간 차있음
    • 만약에 데이터 윈도우 바깥쪽에 있는 패킷이 왔다면 무시함
    • 자주색: 패킷을 받았지만 아직 순서에 안맞아서 buffer에 저장만 해두고 ACKed X
    • 회색: 패킷이 와야하는데 아직 안온상태이다.
    • 지금 receiver 쪽은 10번 패킷이 아직 안와서 ACK를 보내지 않은 상태이다.

 

 

  • Sender
    • Packet들에게 seq #를 붙여서 연속적으로 send_base+N-1까지 보낼 수 있음
    • ACK를 받지 못한 패킷에 한해서만 해당 패킷을 재전송함
    • timeout(n): packet n을 다시 보내고 timer 재시작
    • [sendbase, sendbase+N] 사이의 ACK(n)이 오면
      • 패킷 n을 받았다고 표시
      • n smallest unACKed 패킷 → window base를 next unACKed 시퀀스 #로 옮김
  • Receiver
    • Packet이 순서대로 오지 않더라도 receiver window 내의 데이터라면 받음
    • 각각의 packet에 대해 ACK를 보냄
    • Packet n이 [rcvbase, rcvbase+N-1] 사이에 있다면:
      • ACK(n)를 보냄
      • 순서 이상: buffer에 저장
      • 순서 맞음:
        • deliver(추가로 순서 맞는 Buffered packets(=자주색)까지 같이 보냄)
        • Window를 next not-yet-received 패킷으로 옮김
    • [rcvbase-N, rcvbase-1] 사이의 packet n:
      • ACK가 loss된 것임 → ACK(n)을 다시 보냄
    • 나머지: 무시함
  •  

 

  • Selective Repeat in action
  •  
  • Selective repeat: a dilemma
    • example:
      • seq #s: 0, 1, 2, 3(base 4)
      • window size = 3
      • receiver는 두 가지 시나리오를 구분 못함
      • (b)에서 중복 데이터 accept 발생
      • SR은 window size가 sequence number의 개수의 절반보다 이하여야한다. 
        • window size <= (sequence number)/2

Connected-oriented transport: TCP

  • TCP 개요
    • Point-to-Point: 하나의 송신 측과 하나의 수신 측이 통신하는 1:1 통신
    • Reliable, in-odred byte stream: 신뢰성 있는 데이터 전송 보장, sender가 보내는 byte 순서대로 받음
      • no ‘message boundaries’: TCP(=Byte stream), 한 Byte마다 Byte의 번호를 보냄
    • Full duplex data:
      • Bi-directional data flow in same coonection(상호 데이터를 주고 받을 수 있음)
      • MSS(Maximum Segment Size): 헤더를 제외한 부분(1460 = 1500 - TCP(20)-IP(20))
    • Cumulative ACKs
    • Pipelining(송신자가 다수의 패킷을 한번에 보내는 것)
      • TCP congestion and flow control → Window size를 얼마로 할 것인지가 중요
      • Window 안의 패킷들은 ACK를 받지 않고 한번에 보낼 수 있음
    • Connection-oriented 연결지향적
      • Handshaking(Control 메시지 교환)이 본격적인 데이터 교환 이전에 sender와 receiver의 상태를 업데이트함
    • Flow control
      • Sender는 Receiver가 받을 수 있는 수준으로 데이터를 보냄

 

  • TCP segment 구조(각 field의 목적만 알면 됨)
    • Length: TCP 헤더의 길이
    • TCP options: 있을 수도 있고 없을 수도 있음
    • Checksum: 오류 정정
    • Segment seq #: data into bytestream의 byte 숫자(segment가 아님)
    • Receive window: Flow control: # bytes receiver willing to accept
    • Application data: TCP socket으로 보내지는 데이터
    • Flag
      • ACK: Next expected byte의 seq 번호
      • C, E: Congestion notification
      • RST, SYN, FIN: 연결 관리
      • RST: 비정상적인 연결 끝날 때 1
      • SYN: 처음 연결 맺을 때 1
      • FIN: 연결 끝날 때 1

 

  • TCP sequence numbers, ACKs
    • Sequence numbers:
      • byte stream ‘number’ of first-byte segment’s data
    • Acknowledgements:
      • seq # of next byte expected from other side
      • cumulative ACK Acknowledgments
    • Receiver가 순서에 어긋난 segments를 다루는 방법
      • TCP가 직접 다루지는 않고 TCP Buffer 사용
      • up to implementor

 

  • TCP sequence numbers, ACKs
    • ACK: 이번에 받은 패킷의 바로 다음 번호를 보내줌. A flag
    • 1증가하는 이유: 데이터 길이가 1이라서
    • ACK:

 

  • TCP round trip time, timeout
    • 패킷 loss가 발생하면 timer를 설정해 놓고 재전송을 함. timeout을 얼마로 할 것인가?
    • TCP가 Timeout 값을 정하는 방법
      • RTT(Round trip time, 왕복 소요 시간)보단 길게. 하지만 RTT는 다양함
      • 너무 짧으면: 쓸모없는 재전송을 할 수도 있음
      • 너무 길면: segment loss에 대해 반응이 느림
    • RTT를 추정하는 방법
      • SampleRTT: segment 전송부터 ACK 받을 때까지 시간을 잼
        • SampleRTT는 다양함
        • estimated RTT: 최근 몇 개의 측정값의 평균을 냄
      • 재전송 패킷에 대해서는 RTT 고려 X
    • EstimatedRTT = (1-a)Estimated RTT + a*SampleRTT
      • EWMA(Exponential Weighted Moving Average) 지수가중이동평균
        • 데이터가 오고 갈 때마다 시간을 계산(보통 a = 0.125)

    • Timout 기간: EstimatedRTT + ‘safe margin’
      • EstimatedRTT가 편차가 크기 때문에 크고 안전한 margin이 필요
      • TimoutInterval = ETimeout
      • DevRTT: EstimateRTT와 실제 SampleRTT의 편차의 EWMA⇒ RTT의 변동폭을 알려주는 변수
      • DevRTT = (1-b)DevRTT + b|SampleRTT-EstimatedRTT|
      • b=0.25

 

  • TCP sender
    • Event: App으로부터 데이터를 받음
      • seq #로 segment를 만듦
      • seq #은 segment의 첫번째 데이터 byte의 byte-stream number임
      • timer를 시작(이미 동작중이지 않다면)
      • timer: oldest unACKed segment
      • 만료 기간: TimeOutInterval
    • Event: Timeout
      • timeout을 유발한 segment를 재전송
      • timer 재시작
    • ACK 받았을 때
      • 이전에 ACK되지 않은 segments일 경우
        • ACKed라고 업데이트
        • 여전히 unACKed segments가 있다면 timer start

 

  • TCP: 재전송 시나리오
  • Lost ACK 시나리오
    • Host A가 데이터를보내면 Timer 시작
    • HOST B는 데이터를 잘 받았고 ACK를 보냄(92+8=100)
    • ACK가 손실됨
    • Timer가 time out 되면 해당 데이터를 재전송
  • 늦은 ACK 시나리오
    • ACK가 오기 전에 time out되어 seq 92인 데이터를 재전송함
    • time out 시간을 너무 짧게 설정했기 때문에 발생.
    • 적절한 시간 설정이 중요
  • 하나만 손실
    • ACK 100만 손실
    • Host A는 ACK 100 신호가 오지 않았지만 ACK 120 신호를 수신했으므로 Seq120 데이터를 보냄
    • Seq92 데이터에 대한 timer가 timeout 되어도 데이터를 재전송하지 않음
    • ACK 120을 받은 것으로 보아 그 전 데이터도 문제없이 전송되었다는 것을 알 수 있음
    • Cumulative ACK 는 earlier lost ACK 커버 가능

 

  • TCP Fast Retransmit
    • Sender가 같은 데이터에 대해 3개의 추가 ACK를 받는다면(3중 중복), 가장 작은 seq #인 unACKed segment를 재전송함
      • unACKed segment가 lost했을 가능성이 높으므로 timeout을 기다리지 말고 바로 재전송

 

  • TCP flow control
    • application layer가 socket buffer에서 데이터를 처리하는 것보다 network layer가 더 빠르게 deliver한다면?
    • Path를 길게 거친 data를 drop하는 것은 짧게 거친 그것보다 자원소모가 더 큼
    • Header에 Receive window ⇒ flow control: 수신자가 받고자 하는 bytes 개수

 

  • Flow control
    • 수신자가 송신자를 control함 → 송신자는 지나치게 많이, 빠르게 보내는 것을 자제함 → 수신자의 buffer를 overflow하지 않을 것임
    • 수신자는 TCP헤더의 rwnd(ReceiveWiNDow)라는 필드로 버퍼 여유 공간을 알려줌
    • RcvBuffer size set via socket option(4096 bytes)
    • 많은 OS들은 자동으로 RcvBuffer 조절
  • 송신자는 받은 rwnd에 따라 unACKed(in-flight) data의 양을 조절
  • 송신 buffer가 overflow하지 않은 것이라는 것을 보장

 

 

  • TCP 연결 관리
    • 데이터 교환 이전에 송수신자는 ‘핸드세이크’를 함
      • 연결하는 데 서로 동의
      • Connection Parameter에 동의
  • 2-way 핸드쉐이크의 문제점
    • Half open conntion이나 중복 데이터 accepted 발생 가능
  • 3-way HandShake

 

  • Closing a TCP 연결
    • Clinet,server는 각각 연결을 종료(Fin bit = 1인 세그먼트를 보냄)
    • 받은 FIN에 대해 ACK로 응답

 

 

Transport_Layer_12.pdf
2.46MB

728x90

'CS' 카테고리의 다른 글

컴퓨터 네트워크 개론 (2) - Application Layer  (0) 2022.04.22
컴퓨터 네트워크 개론 (1) - Internet Overview  (0) 2022.04.22

    티스토리툴바