목차
- Transport Layer 소개
- UDP
- TCP
- Multiplexing / Demultiplexing
- Simple TCP
- TCP 기능(flow control, fast retransmit, congestion control
Transport Layer 소개
서로 다른 호스트에 있는 응용 프로세스 간의 논리적인 통신을 제공합니다.
Transport protocol은 end systems에서 적용된다는데, 종단간 통신(서로 네트워크상에 각 끝부분) 통신으로 msg를 일정한 크기로 잘라 segment로 만들고 source → destination까지 전송합니다.
현재는 TCP, UDP 2개의 프로토콜을 주로 사용합니다.
UDP(User Data Program)
UDP는 신뢰성을 일정부분 포기하고 속도를 중요시하는 심플한 프로토콜입니다.
connection state, sender, receiver, congestion control(혼잡도 제어) 등을 모두 안하며 그만큼 작은 헤더를 가지고 있어 cost가 적고 속도가 빠릅니다. 대신 데이터 유실될 수 있고 순서가 보장되지 않고 신뢰성이 떨어지는 프로토콜입니다.
그래서 UDP는 신뢰성이 중요한 분야보다 실시간으로 송/수신이 계속 되야 하는 분야에 적합합니다.
게임과 같이 실시간으로 계속 정보가 주어져야 하는 분야에서 중요하지 않은 데이터의 경우 UDP로 빠르게 주고받거나, 방송이나 전화 같은 경우가 있다고 합니다. 또 UDP는 TCP와 달리 보낼 패킷의 크기와 상관없이 통째로 보냅니다.(최대 크기 제한되어있어 초과시에는 나누어 전송해야합니다)
TCP(Transmission Control Protocol)
TCP는 신뢰성 있는 프로토콜로 데이터와 패킷이 순서대로 손실 없이 보내는 것을 보장합니다.
- 신뢰성 있는 전달(reliable transport) : 패킷 손실이 없음을 보장합니다.
- 흐름 제어(flow control) : 송신/수신에 균형을 이뤄 수신버퍼가 오버플로우 하는 것을 방지합니다.
- 혼잡도 제어(Congestion Control) : 네트워크에 너무 많은 데이터가 전송되고 있어서 혼잡할 때 송신을 제어하는 기능입니다.
- 연결을 위해 할당되는 논리적 경로가 있으며 전송 순서를 보장합니다. TCP는 패킷을 잘라서 보냅니다.
Multiplexing / Demultiplexing
Multiplexing : Application에 msg를 Transport Layer로 보낼 때, 여러 소캣의 내용을 캡슐화해서 Network Layer로 보냅니다.
Demultiplexing : Segment 헤더에서 정보를 써서 올바른 소캣으로 가지게 합니다. Port번호를 사용합니다.
Connecionless Demultiplexing (UDP)
* Socket을 만들 때 host-local port를 명시합니다.
* segment를 UDP Socket으로 보낼 때, IP주소, Port를 명시하고, segment를 받으면 같은 Socket에 전송합니다. 즉 port 넘버만 알면 식별 가능합니다.
Connection-oriented Demultiplexing(TCP)
* Source/Destination + IP/Port Number = 총 4개 튜플로 알맞은 소캣에 보내줍니다.
* 서버는 각각의 요청에 서로 다른 소캣을 이용합니다.
* 서버에 보내는건 모두 같은 IP, Port로 보내고, 서버는 이를 위 4개 튜플로 demultiplexed 합니다.
* TCP는 Socket marriage, Socket끼리 연결되면 끊기 전까지 둘이서만 통신합니다.
Simple TCP
reliable data transfer - 신뢰할 수 있는 데이터 전송
네트워크는 기본적으로 unreliable 합니다. 이를 신뢰성 있게 보내기 위해서는 수를 세면서 체크를 하여 에러를 없앨 수 있습니다.
1. 채널에 에러가 있는 경우
a. 피드백(Ack, NegativeAck)을 줍니다. Sender가 패킷을 전송한 후 receiver의 response를 대기합니다. error가 답변된 경우 재전송하는데, receiver가 재전송인 것을 알 수 있게 sequence number를 올려서 재전송 합니다.
b. NAK - free protocol : 피드백에 NAck을 빼고, Ack에다 Sequence Number를 추가해서 전송합니다. Protocol 디자인은 헤더 크기를 줄이는게 목적인 만큼 Sequence Number는 1bit로 on/off하여 보내는 방법을 씁니다.
2. 채널에 에러와 손실이 있는 경우
에러에 추가로 손실이 있는 경우, Timer를 둬서 피드백이 올 때 까지 대기하고, 일정 시간이 지나도 피드백이 안오면 손실로 취급하고 다시 보낼 수 있습니다. Send가 손실된 경우 다시 보내고, 피드백이 손실된 경우 Sequence Number를 조작하고 다시 보냅니다.
기본적으로 receiver는 passive로 무조건 받으면 Ack하고, Sender는 Acitve합니다.
TCP 기능 설명
TCP flow control
* 3 way handshake
TCP 첫 통신 시 정확한 전송을 위해 연결을 성립하는 과정입니다. 첫 TCP Syn(synchronize sequence numbers)는 데이터 없이 통신을 위해 송신되고, 서버에서 Syn + Ack(acknowledgment)을 받은 후 데이터 통신을 시작하는 Ack을 하는 3번의 송수신 과정을 뜻합니다.
* flow control
송/수신을 제어하여 버퍼가 오버플로우하지 않도록 조절합니다.
host, server모두 Send, Receive 버퍼가 있고, 버퍼는 윈도우라는 범위가 정해져있어서 윈도우 범위 내에 있는 데이터들을 전송합니다. 이 윈도우는 움직이며 계속 범위 내에 있는 데이터들을 보내고 앞에 데이터가 전송 못됐으면 더 이상 움직이지 못합니다. 이런 움직이는 과정을 슬라이딩 윈도우 알고리즘이라 합니다. 1가지 다른 점은 알고리즘 풀이에서 슬라이딩 윈도우는 일반적으로 고정된 사이즈인데, 네트워크에서는 크기가 계속 늘어날 수 있습니다.
결국 flow control은 receive window filed +@등 값을 통해 적절히 receive window를 조절합니다.
rwnd(ReceiveWindow) = Receive Buffer 여유 공간 크기
TCP Fast Retransmit
패킷이 손실되었다는 것을 Timer를 통해 알 수 있지만 단점으로 Timer가 끝날 때 까지 기다리는 시간이 길다는 점입니다.
그걸 완화하는 방법이 빠른 재전송입니다.
segment를 보낸 경우 receiver는 다음은 무엇을 받아야한다는 답변을 하는데, 만약 1~3번 segment가 송신되던 중 2번 segment가 손실된 경우, receiver는 sender에게 2번 segment를 받아야한다고 답변을 합니다.
여기서 sender는 순차적으로 4, 5, 6... 을 계속 보내는데 각 segement를 receiver가 받을 때마다 아직 못받은 2번을 받아야 한다고 ack합니다. 이 답변이 3번 반복되었을 때, sender는 2번이 손실되었다고 판단하고 2번을 다시 보냅니다.
TCP Congestion Control
네트워크가 감당하기에 너무 많은 데이터가 전송되며 혼잡한 상태를 위한 기능입니다.
네트워크가 혼잡한 경우 라우터에서 버퍼가 오버플로우해 패킷이 손실되거나, 지연시간이 생길 수 있습니다.
Congestion Window 방식
* AIMD(Additvie Increase Multiplicative Decrease)
Additive Increase = loss 전까지 매 RTT(Round Trip Time. 왕복시간) cwnd(Congestion Window)를 1 MSS(Maximum Segment Size)씩 증가합니다.
Multiplicative Decrese = loss가 발생하면 cwnd 사이즈를 절반으로 감소시킵니다.
이 방식을 따르면 다음과 같은 윈도우 사이즈 변화 형태를 띕니다.
* Slow Start
시작 윈도우 크기는 1MSS이고, 매 RTT마다 윈도우 크기를 2배로 증가하는 방식입니다.
Congestion Control 정책
*Time Out : 답신 대기하다 시간초과가 발생하는 경우
* 3 duplicate Acks : 중간 패킷을 3번 못받았다는 답장이 왔을 때 loss로 판단하고 다시 보내는 방법(fast retransmit)
*ssthresh : slow start threshold(임계점)
TCP Tahoe: Timeout과 3 dup Acks을 구분하지 않는 정책
위와 같이 slow start 임계점까지 slow start로 지수적으로 윈도우 크기를 늘린 후, 그 후부터는 AIMD로 +1씩 증가하는 방식입니다. 이때 만약 패킷 손실(Time out, 3 dup acks)가 발생한 경우 slow start 임계점을 현재 윈도우 사이즈의 절반으로 세팅한 후, 윈도우 사이즈를 1로 초기화합니다.
TCP Reno : Timeout과 3 dup acks을 구분하는 정책
만약 3 dup acks가 발생한 경우 slow start 임계점과 윈도우 사이즈 모두 윈도우 사이즈의 절반으로 세팅합니다. 이를 제외한 나머지는 동일합니다.
* 윈도우 사이즈가 크면 좋은 이유
패킷을 다 따로따로 보내는게 아니라 실제로 윈도우 사이즈만큼 한꺼번에 보내기 때문에 뭉텅이로 모은 후 헤더를 1개만 넣어도 되기 때문에 효율적입니다. 그렇기에 만약 앞에 부분에서 아직 보내지 못해 윈도우를 움직이지 못하더라도 윈도우 크기를 계속 증가시켜 효율을 올릴려고 합니다.
즉, 혼잡도 제어는 윈도우에 움직이는 속도(Sliding Speed)와 윈도우 크기 증가 속도(increase wide speed) 2개로 조절됩니다.
'강의 > 컴퓨터네트워크' 카테고리의 다른 글
Link Layer (1) | 2023.12.29 |
---|---|
Network Layer (0) | 2023.12.28 |
컴퓨터네트워크 - Application Layer (0) | 2023.06.28 |
Transport Layer - 요약 (0) | 2023.05.03 |
Application Layer - 시험 요약 정리 (0) | 2023.04.20 |