컴퓨터 네트워크 3 : transport layer 1
1. Transport-layer services
1. Transport services and protocols
- logical communication : 각기 다른 host에 존재하는 application이 서로 연결된 것처럼 보이게 하는 것
- segments : transport 계층에서 packet을 부르는 말
- TCP, UDP : network application에서 사용 가능한 하나 이상의 transport layer protocol
2. Transport vs. network services and protocols
- network layer : hosts 사이의 logical communication
- transport layer : process 사이의 logical communication
- 편지 배달로 비유하기
- application message : 봉투안의 편지
- process : 형제들
- host : 집
- transport protocol : '앤', '빌'
- network protocol : 우편 서비스
3. Transport Layer Actions
- cf) 각 layer 별 packet 이름
- application : message
- transport : segment
- network : datagram, packet
- link : frame
- sender
- application layer로 부터 message 받음
- segment header 결정
- segment를 IP(network layer)로 보낸다.
- receiver
- IP로부터 segment 받음
- header를 체크해서 application layer message 추출
- demultiplex message
4. Two principal Internet transport protocols
- TCP (Trnasmission Control Protocol)
- reliable, in-order : 안정적이며(packet 손실x), 순서대로
- congestion control 수행
- 신뢰적, 연결지향
- UDP (User Datagram Protocol)
- unreliabel, unordered
- 비신뢰, 비연결성
- TCP와 UDP 모두 보장하지 못하는 것
- delay guarantee
- bandwidth guarante
2. Multiplexing and Demultiplexing
1. Introduction
- demultiplexing
- transport layer로 도착한 data(segment)를 올바른 socket(application layer의 process)로 전달하는 역할
- multiplexing
- sender의 host에서 segment를 생성하기 위해 transport header 정보로 캡슐화 하여 network 계층으로 보내는 작업
2. How Demultiplexing works
- IP address(host에 대한 정보)와 port number(process에 대한 정보) 를 이용해서 segment를 올바른 socket으로 보낼수 있다.
3. Connectionless demultiplexing (UDP)
- source IP주소나 port #이 다른 UDP segment의 경우 dest IP와 port #가 같다면 같은 도착지로 source가 이동한다.
- 식별자로 source port #와 dest port #을 가진다.
4. Connection-oriented demultiplexing (TCP)
- UDP 소켓과의 차이점은 TCP는 source IP, port #, dest IP, port # 네개의 식별자를 가진다는 점
- demux : 수신자는 4개의 모든 식별자를 사용해서 적합한 socket 찾는다.
- segment의 식별자에 source의 port#이 다르고 도착지 port #이 같은 경우라면 다른 dest socket으로 들어간다. (UDP와의 차이점)
3. Connectionless transport : UDP
1. UDP : User Datagram Protocol
- UDP는 최소한의 기능만을 가지는 가벼운 transport protocol이다.
- 특징
- best effort <-> guaranteed
- connectionless
- no handshaking -> no RTT incurred
- handled independently
- 왜 UDP 쓸까
- simple, small header size, fast
- 사용분야
- Streaming multimedia apps
- DNS
- SNMP
- HTTP/3
2. UDP : Transport Layer Actions
- sender
- message 보내기
- UDP segment header 결정, segment 만들기
- IP에게 segment 보내기
- receiver
- IP로부터 segment 받기
- UDP checksum header 체크
- message 추출
- demultiplexing
4. UDP checksum
- 목표 : detect errors in transmitted segment
- 시나리오
- sender 입장에서 checksum에 3,4,7,5의 합인 19를 가지고 있다.
- receiver 입장에서 3,4 8(달라진 숫자),5 라면 checksum이 20이 되므로 sender가 보낸 것과 다른 값이 들어왔음을 통해 error를 detect 할 수 있다.
5. Internet checksum
4. Principles of reliable data transfer
1. RDT (reliable data transfer)
- 추상화
- sender는 receiver의 상태를 모른 상태로 정보를 주고받아야 한다.
2. RDT: interfaces
3. RDT: getting started
- unidirectional data transfer 만 고려
- FSM (finite state machine) 로 sender와 receiver 나타냄
- actionsevent 형태
4. rdt 1.0: reliable transfer over a reliable channel
- 아래의 계층은 안정적이라는 것을 가정
- no bit error
- no loss of packets
- sender와 receiver를 분리 (손실없이 안정적인 상황)
5. rdt 2.0: channel with bit errors
- 아래의 계층에서 packet의 bit flip이 일어날 수 있다.
- 그렇다면 어떻게 해결할 것인가?
- data가 깨졌는지 확인 -> 다시 보내달라고 요청하기
- sender가 data 보내고 stop
- wait 해서 ACK or NAK 체크 후 다시 동작
- error를 recover하는 방법!
- acknowledgements(ACKs)
- 제대로 신호를 받은 경우 sender에게 알려주기
- negative acknowledgements(NAKs)
- 데이터가 깨진 경우 다시 보내달라는 신호 주기
6. rdt 2.0: FSM specifications
- receiver의 상태는 모른다..
7. rdt 2.0: operation with no errors
8. rdt2.0 has hatal flaw
- ACK과 NAK이 깨질 때
- sender는 receiver에서 무슨일이 일어났는지 모른다
- 재전송을 한다면 복제되는 문제 발생
- handling dulplicate (복제 문제 해결책) -> rdt2.1
- ACK/NAK corrupt 되면 sender는 현재의 pkt 다시 전송 이때 sequence number를 pkt에 추가하여 보내기!!!
- receiver는 복제된 pkt 삭제
9. rdt2.1 sender
10. rdt2.1 receiver
11. rdt2.2: a NAK-free protocol
- rdt2.1이랑 기능은 같지만 NAK이 없다!
- 대신 ACK이 seq #를 가지고 있다.
- TCP가 쓰는 방식
12. rdt3.0: channels with errors and loss
- lose packet 한 경우 고려하기
- timeout을 통해 해결
- sender는 ACK을 기다리는 시간의 최대점을 두고 이 시간을 넘어서도 ACK이 오지 않는다면 loss된 것으로 생각
13. rdt3.0 sender
14. rdt3.0 sender (specific view)
15. rdt3.0 in action
- Utilization vs Throughput
- Utilization : 전체중에서 몇 %를 일했는가
- Throughput : 단위 시간중 유용한 일을 한 시간! (packet 전송을 성공한 경우만 생각)
- Utilization of sender(사실은 throughput)계산 예시
- Dtrans=RL=109bits/sec8000bits=8μsec
- utilization=15ms+15ms+8μsec8μsec
17. rdt3.0: stop-and-wait operation
- rdt3.0 protocol의 performance는 매우 좋지 않다.
- 이유는 packet을 하나 보내고 그에 대한 확인이 올때까지 다른 일을 안하기 때문에
- packet을 여러개 한번에 보내서 해결한다.
18. rdt3.0 pipelined protocol operation
- pipelining : receiver의 확인 없이 packet을 계속 보내는 방식
- stop and wait 방식은 성능이 좋지 않아서 아래의 두가지 방식 쓴다
- Go-back-N
- Selective repeat
19. Go-Back-N: sender
- 최대 N개의 window size를 가지고 packet을 받아오기
- cumulative ACK
- ACK(n)은 n번까지의 packet을 잘 받았다는 의미
- window size도 n만큼 뒤로 밀어주기!
- timeout(n) : timeout이 발생한 경우 window size 내의 모든 packet을 재전송 한다.
20. Go-Back-N: receiver
- ACK only : 순서대로 ACK 전송한다.
- IF) 순서가 달라진 경우.... 폐기하거나 버퍼에 저장한다.(이것은 구현을 어떻게 하느냐에 따라 다르다)
21. Go-Back-N in action
- sender가 보낸 것이 loss된 경우 receiver는 올바른 순서가 오기 전까지 discard하고 제대로 동작한 마지막 ACK을 보낸다
- sender 입장에서 올바른 ACK이 오지 않아서(duplicate ACK만 온다) timeout 발생 -> window size안에있는 모든 packet 다시 재전송
- loss된 경우 packet을 discard하는것이 낭비이다 -> selective repeat으로 해결
22. Selective Repeat
- sender
- send_base를 가지고 있어서 ACK을 받지 못한 가장 오래된 packet에 대한 정보를 가진다.
- timeout(n) : packet n을 다시 보낸다. (timer 초기화)
- ACK(n) in [sendbase, sendbase+N]
- window size 범위안에 있는 것에 대한 ACK 받음
- n이 ACK이 오지 않은 가장 작은 packet이라면 window size를 ACK이 오지 않은 가장 작은 다음 packet까지 옮긴다.
- receiver
- rcv_base를 통해 예상되지만 아직 받지 못한 곳을 알려준다.
- packet n in [rcvbase, rcvbase+N-1]
- send ACK(n)
- 순서 바뀐 경우 : buffering
- 순서 맞은 경우 : 전달
- packet n in [rcvbase-N, rcvbase-1]
- otherwise
23. Selective Repeat in action
- go back n과 달리 individual ack을 사용한다.
24. Selective repeat's dilema
- seq #에 따라 이전까지 모두 잘 보내져서 새로운 패킷이 들어오는 것인지 아니면 모든 패킷이 다 loss되서 이전 패킷이 들어오는지 구별 못하는 문제 발생할 수 있다.
- 해결 : seq#의 크기 >= 2*window_size