📕 사용자 데이터그램 프로토콜(UDP/IP)

UDP가 무엇인지 설명해주세요

UDP는 사용자 데이터그램 프로토콜의 약자로서, 비디오 재생 또는 DNS 조회와 같이 시간에 민감한 전송을 위해 인터넷을 통해 사용이 됩니다. 빨라질 수 있는 이유는 데이터가 전송되기 전에 공식적으로 연결이 설정되지 않으므로 통신 속도가 빨라질 수 있습니다.

UDP의 작동 원리

여타 다른 네트워크 프로토콜과 같이 UDP는 네트워크 상에서 두 컴퓨터 간에 데이터를 전송하기 위한 표준화된 방법입니다. 기본적으로 UDP는 데이터를 전달할 때 말고 아무것도 하지 않습니다. 가령, 다른 프로토콜과 비교하여 UDP는 먼저 연결을 설정하거나, 해당 패킷의 순서를 표시하거나 의도한 대로 도착했는지 여부를 확인하지 않고 패킷을 직접 보내는 방식으로 프로세스를 수행합니다.

UDP의 용도

대표적으로 UDP의 용도는 크게 세가지가 있습니다.

• 실시간 데이터를 전송할 때
• 여러 상대에게 같은 내용의 데이터를 전송할 때
• 데이터 전송 시 신뢰성이 필요하지 않는 소량의 데이터를 전송할 때

1. 실시간 데이터 전송은 VoIp(Voice Over IP)를 예시로 들 수 있습니다. VoIp는 네트워크상에서 음성을 IP 패킷으로 주고 받는 기술입니다. 이렇게 IP 패킷으로 빠르게 주고 받아야 하는 기술이기 때문에 지연시간이 생기는 것은 큰 문제가 될 수 있습니다. 그렇기 때문에 TCP와 같은 연결의 성립이 확인 응답 시스템은 단순 오버헤드를 발생시키는 것이기에 신뢰성이 낮더라도 전송을 우선으로 하는 UDP를 사용합니다.

2. 두번째 용도에서 여러 상대에게 같은 내용의 데이터를 전송할때, Broad Cast, Multi Cast 통신 방식을 사용합니다. 하지만, 이러한 통신 방법은 TCP에서는 사용할 수 없기 때문에(TCP는 1:1 통신만 가능한 유니캐스트 통신을 사용하고 있습니다.) 실시간 영상을 제공하는 Zoom과 같은 애플리케이션을 사용하기 위해서 UDP를 이용하는 것 입니다.

3. 마지막으로, 소량의 데이터를 주고 받을 때 주로 들 수 있는 예시는 DNS Domain name transfering 입니다. 물론 몇 메가 바이트 이상의 파일을 전송하는 경우에는 TCP를 통한 신뢰성 확인이 필요합니다. 왜냐하면 이렇게 큰 사이즈의 데이터는 패킷의 형태로 쪼개져 들어와 합쳐지는 방식인데 하나라도 유실되면 해당 파일이 정상 동작할 수 없기 때문입니다. 반면에, 아주 작은 데이터를 주고 받는 경우에는 오히려 오버헤드를 발생시켜 통신 효율만 낮추기 떄문에 UDP를 사용하는 것 입니다.

UDP의 장단점이 무엇인지 설명해주세요

UDP의 장점은 TCP와는 다르게 연결 설정 과정이 없어 데이터 전송이 빠르고, 패킷 교환 네트워크에서 각각의 패킷을 독립적으로 처리합니다. 이러한 특징에 의해서 실시간 서비스, 비디오 혹은 오디오 스트리밍 등에 주로 사용이 됩니다.

하지만, 데이터를 연결 설정 및 보안 등의 과정을 크게 거치지 않기 때문에 데이터의 전달을 보장하지 않아 데이터 손실의 위험이 크고, 데이터의 패킷이 전송되는 속도에 따라 데이터의 순서가 바뀔 수 있습니다. 위 처럼 특별하게 데이터의 상대적 순서 등을 재확인 하는 프로세스가 따로 없기 때문에 오류가 발생한 패킷은 버려지며, 이를 위한 별도의 처리 과정이 없어 다시 데이터를 복구하는데 있어 어려움이 있을 수 있습니다. 그렇기 때문에 의미있는 서버를 구축하기 위해서는 일일이 패킷을 관리를 해주는 시스템을 구축해야 합니다.

UDP DDos Attack
UDP는 빠르게 데이터를 실시간으로 전송할 수 있다는 그런 특징들이 있습니다. 그래서, 패킷 손실과 같은 위험은 심각한 문제가 아니나, 이러한 UDP의 특징에 의해서 악의적으로 사용될 수 있습니다.

이렇게 UDP 폭주 공격은 많은 개수의 데이터그램을 대상 컴퓨터의 임의 포트로 보냅니다. 그에 따라 대상이 똑같이 많은 개수의 ICMP 패킷으로 응답하게 되며, 이는 해당 포트에 연결할 수 없음을 나타냅니다. 이렇게 폭주 공격에 방어하기 위해서 ICMP 패킷의 응답 속도를 제한하거나, 분산된 여러 데이터 센터의 중간 네트워크를 통해 UDP 트래픽을 수신하고 응답하여 단일 원본 서버가 사기성 요청으로 압도되는 것을 방지 합니다.

ICMP(Internet Control Message Protocol)
ICMP는 네트워크 장치에서 네트워크 통신 문제를 진단하는 데 사용하는 네트워크 계층 프로토콜 입니다. 주로, 데이터가 의도한 대상에 적시에 도달하는지 여부를 확인하는 데 사용됩니다. 장치는 라우터와 같은 장치에 사용됩니다. ICMP는 DDos 공격에도 사용될 수 있습니다.

UDP의 체크섬에 대해서 설명해주세요

TCP와 UDP는 우리가 보내는 데이터의 정보를 헤더라는 봉지에 담아서 보내는 데이터에 대한 설명과 해당 데이터의 목적지 등을 전달하게 됩니다.

위의 Table에서 볼 수 있는 것 처럼 TCP/UDP는 공통적으로 포트 번호를 이용하여 주소를 지정하고 데이터 오류 검사를 위한 체크섬이 존재합니다. (UDP의 헤더와 실제 UDP 데이터를 합친 것을 데이터그램이라고 합니다. 이를 TCP 에서는 TCP Segment라고 명명하고 있습니다.) 체크섬을 통해서 UDP에서 데이터의 무결성을 확인하며 이러한 계산 결과를 패킷을 전송하기 전에 마쳐 놓고, 해당 데이터를 패킷에 포함하여 전송합니다.

체크섬의 패킷 계산 방식

1. 송신측에서 전송할 데이터를 16비트 단위로 나눕니다. 만약 데잍터의 길이가 16비트로 나누어 떨어지지 않는다면, 패딩 비트를 추가하여 16비트 단위로 만듭니다.
2. 나눈 각 16비트 단위의 데이터를 모두 더합니다. 이때, 덧셈의 결과가 16비트를 초과하면, 초과된 비트를 다시 더합니다. 이렇게 얻은 결과를 1의 보수로 변환하여 체크섬으로 사용합니다.
3. 이 체크섬을 데이터 패킷에 포함하여 수신자에게 전송합니다.

이렇게 받은 체크섬을 수신자 측에서는 패킷의 체크섬을 제외한 부분을 16비트로 나누어 더하고, 이렇게 더한 결과에 체크섬을 더합니다. 결과가 0이 아닐 경우에는 데이터에 오류가 발생한 것으로 판단합니다.

📗 신뢰적 데이터 전송의 원리

전송 후 대기 프로토콜이 뭔지 설명해주세요

전송 후 대기 프로토콜이라고 함은 Stop and Wait Protocol이라고 쓰고, 가장 간단한 형태의 오류 제어 프로토콜 중 하나라고 할 수 있습니다. 간략하게는 데이터를 전송한 후 수신자로부터 ACK를 받을 때 까지 대기하는 방식입니다. 간단한 방법으로 데이터의 손실이나 오류를 확인 할 수 있지만, 이렇게 기다리기만 하는 방식을 효율적이지 않기 때문에 Go-Back-N과 Selective Repeat 같은 오류 제어 프로토콜이 더 널리 사용되며, 높은 효율성을 제공합니다.

동작 방식

1. 송신자가 데이터 프레임을 수신자에게 전송합니다.
2. 수신자는 데이터 프레임을 정상적으로 받으면 ACK(Positive Acknowledgement)를 송신자에게 보냅니다.
3. 송신자는 ACK를 받을 때 까지 기다립니다.
4. 만약 송신자가 일정 시간 동안 ACK를 받지 못한다면, 데이터 프레임을 재전송합니다.

위의 효율성이 떨어지는 이유는 세가지가 있을 수 있습니다.
1. 데이터 자체의 오류로 인한 손실 -> 데이터 자체가 가지 않으므로 ACK 신호 또한 보내지 않기 때문에 무한정 대기
2. 손실된 확인 신호의 누락 -> 한번 누락이 되면 이전 패킷의 확인이 수신될때 까지 계속해서 대기
3. 지연된 데이터 또는 확인 신호 -> 확인 신호는 송신차 측의 시간초과(timeout) 기간 후에 수신됩니다. 그렇기에 확인 응답이 지연되어 수신되므로 자칫 다른 데이터 패킷의 응답으로 잘못 간주 될 가능성이 있습니다.

파이프라인 프로토콜이 뭔지 설명해주세요

Pipe Line Protocol은 데이터 처리와 전송을 효율적으로 수행하기 위한 기술적인 개념으로 사용됩니다. Pipe line은 일련의 작업이 연속적으로 실행되는 것을 의미합니다. 여기서 각 작업은 다음 작업으로의 입력이 되어 연결되어 있는 형태입니다. 네트워크나 데이터 처리를 함에 있어 파이프라인은 데이터를 여러개로 나눠 병렬적으로 처리하여 효율성을 극대화 하는 방식입니다.

이러한 파이프라인 프로토콜에는 GO-Back-N, Selective Repeat ARQ가 있습니다. 각각에 대해서 자세하게 설명드리겠습니다.

Go-Back-N ARQ

Go-Back-N은 신뢰성 있는 데이터 전송을 위해 사용되는 오류 제어 프로토콜 중 하나로, 전송자와 수신자 간의 데이터 흐름을 관리하여 데이터의 손실이나 손상을 감지하고 복구하는 기술입니다. 해당 기술은 데이터를 연속적으로 전송하는 방식으로 동작합니다.

연속적으로 패킷을 전송하여 슬라이딩 윈도우 프로토콜이라고도 불리며, 0~7까지의 데이터를 전송할때 각각이 전송되기 시작하면서 또한 별도의 타이머가 동작하게 됩니다. 타이머에 설정한 시간 내에 ACK를 받지 못하면 해당 패킷부터 윈도우 크기만큼의 모든 패킷을 재전송합니다. 즉, 만약 0~5까지 패킷을 전송을 했지만, Receiver 측에서 5를 온전히 받지 못했다면, 계속 ACK는 1234444---를 보내게 됩니다. 이렇게 제대로 전송되지 않은 데이터를 온전히 다시 보냄으로써 무결성을 지키게 됩니다. 그리고 타이머가 만료되기 전에 ACK가 오게 되면 그 다음 ACK가 되지 않은 가장 최신의 패킷에 대한 타이머를 계산합니다.

Selective Repeat ARQ

위에서 봤던 GBN protocol은 한 윈도우 사이즈 즉 보내려고 하는 패킷의 크기에 따라 타이머의 설정을 달리하여, 그 시간내에 패킷이 들어오게 될 경우 윈도우 사이즈를 증가시켜 그 다음 데이터를 순차적으로 보내는 방식이었습니다.

그에 반해 SR protocol은 타이머가 각각의 패킷에 대해서 설정이 되기 때문에 ACK 또한 보낸 순서대로 입력을 받는 것이 아닌 ACK가 온전히 들어온 순서대로 받게 됩니다. 이렇게 ACK 혹은 패킷이 제대로 전달되지 않은 경우에는 일단 따로 버퍼를 형성하여 보관을 했다가 그 해당 패킷을 제외한 나머지가 처리가 되었을 경우에 한번에 처리를 하고 다음으로 넘어가게 됩니다.

이렇게 GBN과 SR을 살펴보았을 때 각각의 단점이 보이게 됩니다. GBN 같은 경우에는 오류가 감지 되었을 때, 해당 윈도우의 크기 만큼의 모든 패킷 재전송 하기 때문에 불필요한 재전송이 발생할 수 있고, SR 프로토콜은 구현이 복잡하고, 수신자 측에서 기본적으로 패킷의 순서를 제어해야 하기 떄문에 추가적인 매커니즘이 필요하고 오류가 난 패킷에 대하여 버퍼를 또 생성해야하는 단점이 있기 때문에 네트워크의 요구 사항에 따라 적절한 프로토콜을 선정해 사용해야 합니다.

📘 Transmission Control Protocol

TCP에 대해서 설명해주세요

TCP는 OSI 7 Layers를 공부할 때 많이 들어볼 수 있는 프로토콜의 하나로, 장비들 간의 통신 과정에서 정보를 안정적으로, 순서대로, 에러없이 교환할 수 있도록 하는 것에 목적을 둔 프로토콜 입니다. 일상적으로 응용계층보다 낮은 레이어의 프로토콜을 접할 기회는 흔하지 않습니다. 왜냐하면, 일련의 작업들을 거의 OS의 선에서 처리를 하고 프로그래밍을 하는 개발자는 응용계층의 일에서 작업을 하고 관리를 하기 때문입니다.

이런 것이 레이어 모델이 등장한 이유입니다. 각 계층간의 역할 분담을 통해 어떤 작업을 할 때 신경써야하는 범위를 좁혀 수많은 기술의 집약체인 네트워크를 한명 한명 개발자가 모두 이해하는 것이 아닌 필요에 따라 응용하고 사용할 수 있게 만든것입니다.

과거의 냉전과 세계 대전 당시 데이터의 필요성에 따라 패킷 교환 방식이라는 것입니다.

이 같은 방식으로 데이터를 교환할 경우, 하나가 손실이 되어도 모든 것이 사라지지 않는 다는 의미에서 나온 아이디어 입니다. 하지만, 패킷이 알게 모르게 사라지는 경우, 송신 측에서 패킷을 쪼갠 순서를 모르는 경우,수신 측의 처리 속도보다 빠르게 패킷을 보내 버리는 경우 등의 문제를 ARQ를 만들어 오류난 해당 패킷만 따로 보내고, 시퀸스 번호를 만들어 재조합을 위한 순서 번호를 같이 보내고 수신 측이 처리할 수 있는 양을 송신 측에 알려주기 위한 개념인 슬라이딩 윈도우가 이때 탄생하게 되었습니다.

TCP의 헤더

그리고 TCP의 특징에 대해서 말씀드리자면 대표적으로 Connection Oriented, 즉 연결 지향적이라는 것 입니다. 여기서 연결이라는 의미는 물리적 연결도 동반하는 여러 개의 연결이 이뤄져 통하는 연결을 의미합니다.

이렇게 연결을 지향하는것은 연속적인 데이터 전송의 신뢰성을 갖추기 위함입니다. 위에서 설명 드린 것 처럼 TCP 는 패킷 전송 방식을 사용하기 때문에, 일정 단위로 묶어 스트림 처럼 상대방에게 보내게 되는 것 입니다. 즉 이렇게 신뢰성을 갖추기 위해, 각 연결된 기기 간의 연결 상태를 따로 구분하고 상대방과 연결 상태를 만들거나 해제하기 위해 거치는 과정을 HandShake라고 합니다.

3-way handshake

말 처럼 3번의 Handshake, 즉 3번의 통신 과정을 거칩니다. 이 과정을 거치면서 통신을 하는 양 종단은 어느 누구와 통신을 하고 있는지, 받아야 할 남은 시퀸스 번호는 몇번인지 등의 정보를 주고 받게 됩니다.

• Closed : 아직 연결 요청을 하지 않았기에 아무런 연결도 없는 상황
• Listen : 수신자(Receiver)가 요청자(Initiator)의 연결 요청을 기다리는 상태, Initiator가 요청을 보내기 전까지는 계속 Receiver는 Listen의 상태로 대기를 하게 됩니다. 이러한 상태를 Passive Open이라고 하고, 이렇게 개방하게 하는 Initiator는 Passive Opener라고도 합니다.
• SYN_SENT : Initiator가 연결 요청을 하면서 랜덤한 숫자인 시퀸스 번호를 생성해서 SYN Packet에 담아 보낸 상대를 말합니다. 해당 Sequence Number를 사용하여 Initiator 와 Receiver는 계속 새로운 값을 만들고 서로 확인하며 연결 상태와 패킷의 순서를 확인합니다. 이러한 상황을 Active Open그리고 Initiator를 Active Opener라고 합니다.
• SYN_RECV : Initiator가 보낸 SYN Packet을 제대로 받은 상태를 말합니다. 이후 Receiver는 Acknowledgement 값을 다시 만들어서 Initiator에게 다시 돌려줘야 합니다. 이때 ACK는 Squence Number + 1의 형태로 구성이 됩니다. 그리고 다시 돌려줄 때는 상대방이 보낸 시퀸스 번호 + 상대방이 보낸 데이터의 Byte를 합쳐서 ACK를 만들어 보냅니다. 하지만, 초기 과정에서는 아무런 데이터를 주고 받지 않기 때문에 단순하게 구별을 위해 +1을 하게 됩니다.
• ESTABLISHED(Initiator) : Initiator는 자신이 맨 처음에 보냈던 Sequence Number와 Receiver가 응답으로 보내준 ACK(SN + 1)를 사용하여 연결이 제대로 성립되었는지 확인할 수 있습니다. 이후 제대로 연결 되었음을 확인 했을 경우 다시 Sequence Number + 1을 한 ACK를 Receiver에게 보냅니다.
• ESTABLISHED(Receiver) : 1을 받게 될 경우 제대로 연결이 되었음을 확인하고 ESTABLISHED 상태로 들어가 안전하고 신뢰성있는 연결이 생성되었다고 판단하고 통신을 시작할 수 있습니다.

4-way Handshake

연결을 생성할 때와 같이 연결을 종료할 때도 특정한 과정을 거쳐서 연결을 종료해야 합니다. 그냥 연결을 끊어 버리게 되면 연결의 지속 여부를 다른 한쪽에서는 알 수 있는 방법이 없기 때문에 이와 같은 과정을 거치게 됩니다.

개발자들은 4-way handshake, 즉 연결이 끊어 질때를 더 주의 깊게 봐야합니다. 왜냐하면, 순차적으로 신호를 주고 받는 방식이 아닌 상대방이 응답을 줄때까지 대기 하는 과정이 포함되어 있기 때문에 중간에 하나라도 어긋나면 바로 DEADLOCK이 발생할 수 도 있습니다. 물론 일정 시간이 지나면 타임아웃이 되면서 정상화가 되지만, 그동안 메모리와 포트를 점유하고 있으므로 병목이 발생할 가능성이 늘게 되는 것 입니다.

• FIN_WAIT_1 : 연결을 종료하고자 하는 Initiator가 FIN packet을 보내면서 FIN_WAIT_1 상태로 들어서게 됩니다. FIN packet에 포함되는 sequence number는 랜덤한 값이 아닌 이미 3-way handshake에서 설정된 값을 이용합니다. (Active Closer, Active Close)

• CLOSE_WAIT : Initiator로 부터 FIN Packet을 받은 Receiver는 Initiator가 보낸 SN+1로 ACK(승인 번호)를 만들어서 다시 요청자에게 응답하며 CLOSE_WAIT 상태로 들어가게 됩니다. 이때 close(), shutdown() 과 같은 함수를 통해서 다음 단계로 넘어 갈 수 있습니다. 만약 연결 종료 함수가 명시적으로 호출 되지 않는 다면 다음 상태로 넘어갈 수 없기 때문에 데드락이 발생할 수 있습니다. 이때는 수동으로 종료를 할 준비를 해야하기 때문에 Passive Closer, Passive Close라고 합니다.

• FIN_WAIT_2 : Initiator가 Receiver로 부터 ACK를 받고 보냈던 SN과의 차이가 1이 마즌지 확인합니다. 하지만 아직, 수신자의 데이터 전송이 전부 끝나지 않았을 수 도 있기대 대기 상태로 들어가 연결 종료를 허락하는 FIN Packet을 기다립니다. 타임아웃을 설정했을 경우 자동으로 다음 단계로 넘어 갈 수 있습니다.

• LAST_ACK : Receiver는 자신이 처리할 데이터가 더 이상 없다면 연결 종료 함수를 호출하고, FIN Packet을 보냅니다. 이때, FIN Packet의 SN은 자신이 전송해야 하는 데이터의 SN을 그대로 사용하며 ACK도 똑같이 마지막으로 사용했던 것을 그대로 사용합니다. 이후 LAST_ACK 상태로 들어가며 ACK를 보내줄 때 까지 대기합니다.

• TIME_WAIT : Receiver로부터 FIN Packet을 받은 Initiator는 SN+1의 ACK를 생성하여 Receiver에게 응답합니다. 이후 TIME_WAIT 상태로 돌입하며 실질적인 종료라고 생각할 수 있습니다. 해당 상태는 의도하지 않은 에러로 인해 데드락에 빠지는 것을 막지 위해서 대기 시간을 설정합니다. 대기 시간은 대체로 2 MSL(Maximum Segment Lifetime)으로 정의합니다.

📙 Congestion control이란?

Congestion Control이란 말 그대로 네트워크의 혼잡 상태를 파악하고 그 상태를 해결하기 위해 데이터를 전송을 제어하는 것을 말합니다.

네트워크의 영역은 우리가 시각적으로 볼 수 없는 다양한 기술의 집약체이지만, 응답이 느려지고 있는 것은 파악을 할 수 있습니다. 이렇게 응답이 지속적으로 느려지거나 안오게 되는 경우가 발생하면 네트워크에 문제가 있다는 것을 알 수 있습니다.

위 같은 상황이 벌어지게 되면, 자연스럽게 재전송이라는 작업이 계속 반복되게 되는데 여러가지 오류가 있는 것들이 동시 다발적으로 재전송을 하게 되면 Latency가 길어지며 문제가 점점 악화가 되는 것을 잘 조율하기 위해 Initiator 측의 윈도우 크기를 조절하여 데이터의 전송량을 강제적으로 줄이는 것은 Congestion Control, 혼잡 제어라고 합니다.

Congestion Window, CWND
송신측의 윈도우는 수신측이 보내준 윈도우 크기와 네트워크 상황을 고려하여 정해집니다. Initiator는 최종 윈도우 크기를 정할 때, Receiver가 보내 준 윈도우 크기인 RWND(Receiver Window) 그리고 자신의 네트워크 상황을 고려해서 정한 윈도우 크기인 CWND 중 에서 더 작은 값을 사용합니다. 여기서 중요한 것은 조절 하는 것이 수신 측이 아닌 송신측, Initiator의 윈도우 크기라는 것 입니다. 그리고, 여기서 의미하는 윈도우 크기는 전달하는 패킷의 윈도우 크기가 아닌 혼잡 윈도우의 크기를 의미합니다.

Initialize Congestion Window

통신을 하는 중간의 응답 속도나, 타임아웃이 난다거나의 정보 등을 통해서 네트워크의 혼잡 상황을 유치할 수 있지만 혼잡 윈도우의 사이즈를 명확하게 결정하기는 애매하기 때문에 MSS(Maximum Segment Size)를 사용합니다.

$MSS = MTU-(IP_h + IP_o) - (TCP_h + TCP_o)$

• MTU (Maximum Transmission Unit) : 한번 통신 때 보낼 수 있는 최대 단위를 말합니다.

즉, MSS는 한번 전송할 때 보낼 수 있는 최대 단위가 정해져 있는 상황에서 IP header, TCP header 등 데이터가 아닌 부분을 잘라내고 진짜 데이터를 담을 수 있는 공간이 얼마나 남았는지를 나타냅니다.

AIMD(Additive Increase / Multicative Decrease)

AIMD 방식은 합 증가/ 곱 감소 방식이라는 뜻을 담고 있습니다. 해당 혼잡 회피 방법은 네트워크에 아직 별 문제가 없어 전송 속도를 빠르게 하고 싶은 경우 혼잡 윈도우의 크기를 1씩 증가시키지만, 중간에 데이터가 유실되거나 응답이 오지 않는 등의 혼잡 상태 감지되면 혼잡 윈도우 크기를 반으로 줄이는 기법입니다.

$AIMD = WS + 1 , WS * 0.5$

수식을 들여보면 혼잡 윈도우의 크기는 위의 사진처럼 톱니 모양을 가지게 됩니다. 그렇기 때문에 큰 범위에서 해당 그래프를 보게되면 시간이 가면 갈수록 네트워크에 참여한 순서와 관계 없이 모든 호스트들의 윈도우 크기가 평행 상태로 수렴하는 것을 알 수 있습니다. 하지만, 네트워크의 BandWidth가 남아도는 상황에서도 윈도우 크기를 너무 조금씩 늘리며 접근하기 때문에, 모든 대역폭을 제대로 활용하여 빠른 속도로 통신하는 것이 어려울 수 있습니다.

Slow Start

AIMD 방식은 윈도우 크기를 선형적으로 증가시키기에 대역폭을 적극 활용하여 제대로된 속도가 나오기까지 시간이 걸린다는 단점이 있습니다. 해당 Slow Start 기법은 AIMD와 비슷하지만 윈도우 크기를 증가 시킬 때는 지수적으로 증가시키다가 혼잡이 감지가 되면 윈도우 크기를 1로 줄여버리는 방식입니다.

해당 방식은 보낸 데이터의 ACK가 도착할 때마다 윈도우 크기를 증가시키기 때문에 처음에는 속도가 느리게 증가할지라도, 시간이 가면 갈수록 점점 빠르게 증가하게 됩니다.

윈도우 사이즈가 증가하는 그래프를 보면서 쉽게 알 수 있는 차이점은 네트워크 혼잡도의 최고치에 도달하는 시간입니다. AIMD는 선형적으로 윈도우 크기를 키우기 때문에 다른 호스트들이 새로 들어올 때 많은 부분은 점유 할 수 없었지만, Slow Start 방식을 사용하면 처음에는 느리다가 시간이 갈수록 AIMD보다 빠르게 윈도우 크기를 키울 수 있습니다.

TCP 빠른 재전송

Fast Retransmit은 혼잡 제어의 기법 중 하나로, 오류가 난 패킷에 대해서 다시 전송이 될때까지 계속 해당 패킷에 대한 ACK 받습니다. 그리고 혼잡한 상황이라고 판단하여 우니도우의 크기를 줄이게 됩니다. 빠른 재전송이 GBN과 비교했을 때 오류가 난 것에 대해 재전송을 하는 것은 같지만, 빠른 재전송은 오류가 난 상황에 바로 해당 패킷을 받아서 데이터의 무결성을 지키려고 하지만, GBN은 재전송이 필요한 패킷과 그 후에 오는 다른 데이터들을 같이 또 전송하기 때문에 효율성 면에서 불리한 점을 가지고 있습니다.

Flow control이란?

Flow Control이라는 것은 위에서 말했던 ARQ(Automatic Repeat Request), 즉 재전송 기반 오류 제어를 말합니다. 대표적인 흐름 제어 기법은 위에서 언급했언 Stop-and-Wait Protocol이 있고 이 단점은 보완하기 위해서 Sliding Window 방식이 있습니다.

Sliding Window

Sliding Window 방식은 Stop-and-Wait Protocol의 비효율적인 부분을 개선하기 위해서 나온 방ㅇ식입니다. 해당 방식은 수신 측이 한 번에 처리할 수 있는 데이터를 정해놓고 그때 그때 수신 측의 데이터 처리 상황을 송신 측에 알려줘 데이터의 흐름을 제어하는 방식입니다. 기존의 SNWP와 다른 점은 수신 측이 처리할 수 있는 데이터의 양을 알고 있다는 점입니다.

TCP 3-way handshake 과정에서 네트워크의 상황에 따라 윈도우의 사이즈가 결정이 되면, 안의 프레임에 대한 수신 측의 응답이 없이도 연속적으로 패킷을 전송할 수 있습니다. 그리고 이러한 윈도우의 크기는 버퍼와 패킷의 왕복 시간인 RTT 도 같이 고려하여 결정이 됩니다.

면접에 나왔던 질문

1. HTTP Pipelining vs TCP Pipe Line Protocol
2. 혼잡 제어는 커넥션을 줄여 어떤 것을 얻으려는 것인가?

References

1. UDP Table
2. UDP Usage
3. Stop-and-Wait Protocol(1)
4. GBN_SR
5. GBN_SR(2)
6. GBN_SR(3)
7. TCP