! 헷갈리는 부분 !
ACK 번호는 송신 측으로부터 받은 데이터의 바로 다음에 기대되는 데이터의 순서 번호이다.
ACK 번호는 수신 측이 받은 마지막 바이트의 순서 번호에 1을 더한 값이다.
즉, 2까지 보냈으면 3을 ACK에 담아 보내는 것.
UDP에서의 패킷 === 데이터그램
데이터그램은 독립적인 패킷의 형태. 각각의 경로와 속도로 목적지에 도달할 수 있는 점에서 텔레그램의 전달 방식을 따르기 때문에 데이터그램이라고 부름.
TCP는 세그먼트(segment). 하지만 보통 패킷이라고 많이 부름.
패킷은 데이터그램을 포함하는 상위 요소.
Go-Back-N 프로토콜 처리와 TCP sliding-window 처리 과정에서의 ACK는 방식이 다름.
UDP란?
User Datagram Protocal의 약자로, Datagram을 보내는 Transport layer의 프로토콜입니다. 비연결성(3 way handshake 없음 등등)이고, 신뢰성이 없는 전송 프로토콜입니다.
따라서 별도의 흐름 제어나 오류제어를 제공하지 않기 때문에, 전송 중에 패킷이 손실되거나 세그먼트의 순서가 바뀔 수 있습니다.
일반적으로 TCP보다 빠르기 때문에, 신뢰성보다 속도가 중요한 Streaming 서비스나 DNS에서 사용합니다.
<헤더>
출발지포트 목적지포트 4byte
(헤더 + 페이로드)길이 프로토콜 체크섬 4byte
⭐️UDP의 장단점을 설명해 주세요.
첫째로, UDP는 연결 없이 데이터를 전송하기 때문에, 네트워크 지연 시간을 줄이고 빠른 데이터를 전송할 수 있습니다. 또한 흐름제어나 혼잡 제어를 하지 않기 때문에, TCP와 비교했을 때 일반적으로 빠른 속도를 가지고 있습니다. 또한 TCP에 비해 헤더가 작기 때문에 오버헤드가 적습니다.
이러한 특징으로 실시간 통신과 같은 경우에는 속도가 패킷 손실 여부보다 중요하기 때문에 연속적인 스트리밍을 할 수 있는 UDP를 사용하는 것이 더 적절합니다.
그러나 반대로 데이터의 안전성이 중요한 메일과 같은 시스템에서는 부적절하다고 할 수 있습니다.
또한 멀티캐스트와 브로드캐스트를 지원해서 하나의 송신자가 다수의 수신자에게 동시에 데이터를 전송할 수 있기 때문에, 네트워크 자원을 효율적으로 사용할 수 있습니다.
체크섬을 통해 기본적인 오류 검출을 하기 때문에 데이터의 손상 여부는 판단할 수 있으나 TCP와 달리 자동 재전송 기능이 없어 이러한 점이 단점이라고 생각할 수 있으나, 어플리케이션 수준에서 특정 요구에 맞는 맞춤형 오류 처리 전략을 구현할 수 있는 점이 장점이라고도 할 수 있습니다.
UDP 체크섬에 대해 설명해주세요.
데이터의 무결성을 하기 위한 체크섬이며, 헤더의 2byte(16bit)를 차지하고 있습니다.
데이터그램이 손실되거나 손상되었을 때를 확인하기 위해 사용합니다.
UDP 체크섬은 데이터 그램의 헤더와 페이로드를 합친 후, 이를 일정한 방식으로 계산 후 생성됩니다.
헤더와 페이로드에 대한 합성된 값이 해당 체크섬값과 일치하는지를 확인해 무결성을 검증합니다.
만약 체크섬 값이 일치하지 않으면 데이터 그램이 손상되었을 가능성이 높기 때문에, 수신자는 해당 패킷을 무시하거나 재요청을 수행하는 등의 조치를 취할 수 있습니다.
전송 후 대기 프로토콜이 뭘까요?
Stop and wait 방식은 수신자에게 데이터를 보낸 후 잘 받았다는 응답이 올 때까지 기다리는 것입니다. 수신자가 응답을 하면 다시 데이터를 보내는 것이기 때문에 매우 간단하지만, 한번 보낼 때 마다 RTT타임 만큼 기다려야 하기 때문에 성능이 떨어집니다.
전송 후 대기 프로토콜의 단점을 보완하기 위해 파이프라인 프로토콜이 등장했습니다.
파이프라인 프로토콜이 뭘까요?
파이프라닝 프로토콜은 여러 패킷을 연속적으로 전송하고, 각각에 대한 확인 응답을 기다리지 않고 바로 데이터를 한꺼번에 전송할 수 있게 하는 기술입니다. 이는 네트워크 처리량을 최대화할 수 있다는 장점이 있습니다. TCP에 사용되는 슬라이딩 윈도우 프로토콜은 파이프라이닝의 대표적인 예시라고 할 수 있습니다.
파이프라이닝 프로토콜의 대표적인 방법에는 Go-Back-N 과 Selective Repeat 이 있습니다.
먼저 Go-Back-N은 송신자가 N개의 패킷을 보내고 수신자는 이에 대해 ACK로 응답하는데, 이때 cummulative ACKs를 사용하게 됩니다. 이것은 누적 확인이라는 뜻으로, 수신자가 받은 마지막 패킷의 번호를 송신자에게 알려주는 것입니다. 또한 Reciever는 못받은 특정 패킷 이후의 패킷들은 모두 버리게 됩니다.
따라서 수신자는 누적 ACKs를 받으면 해당 패킷과 그 이후의 패킷을 모두 재전송합니다. 그러기 위해 수신자는 항상 window size 만큼의 패킷들은 버퍼에 저장하고 있어야 합니다.
이 방식은 구현이 비교적 간단하지만, 뒤에 오는 잘 도착한 패킷들을 다 버리기 때문에 효율성이 떨어진다는 단점이 있습니다.
이를 보완하기 위해 Selective Repeat 방식이 나왔습니다.이 방식은 송신자가 여러 패킷을 연속적으로 전송하지만, 손실되거나 오류가 있는 패킷만을 선택적으로 재전송하는 방식입니다.
수신자는 각 패킷에 대해 타이머를 달아 ACK을 별도로 보냅니다. 송신자는 빠진 패킷을 다시 보내고, 수신자는 이 패킷을 받아 정렬 후 Application level로 보내게 됩니다.
이러한 Selective Repeat 방식에도 문제점이 있습니다. ACK가 개별적으로 오기 때문에 해당 처리 로직이 복잡합니다.
⭐️ TCP에 대해 설명해주세요.
TCP는 안정성과 무손실을 보장하는 transport layer의 프로토콜입니다.
신뢰성을 보장하기 때문에 이러한 것들을 지원하지 않는 UDP보다는 속도가 느립니다. 따라서 신뢰성이 속도보다 중요한 경우에 쓰이고, 대표적으로 이메일, 파일 전송 등에 쓰입니다. 또한 HTTP 2.0까지 TCP 기반으로 동작합니다.
TCP의 특징은 첫 번째로, 연결 지향형 서비스 입니다. 1 : 1 통신으로, 연결을 통해 데이터 전송의 신뢰성을 보장합니다.
둘째로는 byte stream service 로, 데이터의 경계를 구분하지 않고 단순 바이트의 흐름으로 보고, 이를 묶어 세그먼트화해서 전송합니다.
셋째로는 데이터의 전송 순서와 신뢰성을 보장합니다. 이를 위해 seq와 ACK를 사용합니다.
넷째로는 데이터의 혼잡제어, 흐름 제어를 지원합니다.
다섯 번째로는 전이중 데이터 전송입니다. sender와 reciever의 구분이 없이 데이터를 주고받습니다.
여섯번째로는 멀티플렉싱입니다. 네트워크 애플리케이션이 동시에 같은 IP 주소와 물리적 네트워크 연결을 공유할 수 있도록 포트 번호를 사용하여 통신 세션을 구별합니다.
⭐️ 3 way handshake에 대해 설명해주세요.
3 way handshake란 TCP에서 데이터 전송을 위한 연결을 확립하기 위해 사용하는 것입니다.
TCP에서는 연결성이 보장되어야 하기 때문에 데이터를 주고 받기 전 이러한 방식으로 연결을 설정합니다.
sender - reciever 관계에서 (보통은 client - server) 연결을 요청하는 SYN과 확인 응답인 ACK이라는 형식이 사용됩니다.
처음 sender 가 header에 SYN Flag bit에 1을 넣고 SYN(Synchronize Sequence number)에 자신의 sequence number를 보냅니다. reciever가 패킷을 받아 연결 요청을 확인합니다.
reciever가 요청을 수락하게 되면 SYN + ACK flag bit를 둘 다 1로 채우고, 자신의 SYN에 seqence number, ACK(Acknowledgement) 상대방의 sequence number + 1로 보내게 됩니다.
sender는 확인 후 ACK 패킷을 상대방의 sequence number + 1로 보내게 됩니다. 이때 보내고 싶은 데이터도 함께 보냅니다.
이렇게 연결이 확립되고, 데이터를 주고받을 수 있습니다.
<sender> <reciever>
SYN bit 1
SEQ 10 ->
SYN bit 1
ACK bit 1
<- SEQ 100 + ACK 11
ACK bit 1
SEQ 11
ACK 101 ->
+ data
⭐️ 4 way handshake에 대해 설명해주세요.
TCP에서 연결을 종료할 때에 사용합니다.
FIN 는 세션을 종료시키는데 사용되면서, 더 이상 보낸 데이터가 없음을 나타냅니다.
클라이언트에서 close()를 호출하면 FIN flag를 보냅니다. 그 다음 서버에서 FIN을 받고 ACK 보냅니다. ACK를 받은 클라이언트는 서버의 FIN을 기다립니다. 서버는 FIN을 보냅니다.
클라이언트는 ACK를 보내고, 일정 시간을 기다리다 통신을 종료하게 됩니다. 마지막에 기다리느 이유는 서버에서 ACK 받지 못했을 경우 클라이언트에서 닫아버리면 서버는 연결을 종료하지 못하기 때문에 재전송 이 있는지 없는지 확인 하고 일정 시간 있다가 닫습니다.
<sender> <reciever>
SYN bit 1
SEQ 10 ->
SYN bit 1
ACK bit 1
<- SEQ 100 + ACK 11
ACK bit 1
SEQ 11
ACK 101 ->
+ data
배경지식
송신 측은 자신의 최종 윈도우 크기를 정할 때 수신 측이 보내준 윈도우 크기인 수신자 윈도우(RWND), 그리고 자신이 네트워크의 상황을 고려해서 정한 윈도우 크기인 혼잡 윈도우(CWND) 중에서 더 작은 값을 사용한다.
TCP 빠른 재전송에 대해서 설명해주세요.
타임아웃 전에 송신 측에서 중복 ACK를 3번받게 되면 타임아웃 시간이 지나지 않았더라도 바로 해당 세그먼트를 즉시 전송하는 것입니다.
TCP에서 ACK를 보낼 때 다음 차례인 번호를 전달하게 되는데, 중간에 패킷이 누락되면 해당 패킷을 받지 못했기 때문에 reciever가 해당 번호를 ACK에 포함하게 됩니다. 이것이 3번 반복되었을 때 손실되었다고 판단하고 바로 해당 ACK의 패킷을 다시 보내는 것입니다.
Congestion control에 대해 설명해주세요.
혼잡 제어는 TCP 프로토콜에서 네트워크의 혼잡 상태를 감지해 송신 측의 윈도우 크기를 조절해 데이터의 전송량을 줄이는 것입니다.
TCP는 혼잡 제어를 위해 addictive increase, multiplicative decrease와 slow start,라는 방법을 적절히 사용합니다.
AIMD 방식은 윈도우 크기를 1씩 증가시키고, 혼잡이 감지되면 윈도우 크기를 반으로 줄이는 것입니다. 이 방식은 윈도우 크기를 너무 조금씩 늘리면서 접근한다는 단점이 있습니다.
slow start 방식은 기본적으로는 앞의 방식과 비슷하지만 윈도우 크기를 지수적으로 증가시키다 혼잡이 감지되면 윈도우 크기를 1로 줄이는 방식입니다.
대표적으로 Reno 혼잡 제어 방식이 있는데요,
먼저 slow start로 윈도우 크기를 증가시킬 때에는 지수적으로 증가하다 threshold에 도달하면 addictive increase 방식으로 1씩 증가하고, 혼잡이 감지되면 타임아웃 방식과 3 ACK Duplicated 방식을 구분해 window size를 줄입니다.
타임아웃이 일어났을 때에는 window size를 1로 줄이고, 3ACK Duplicated 이 일어났을 때에는윈도우 크기를 해당 window size의 반으로 줄이고 다시 addictive increase방식을 사용해 하나씩 늘려갑니다.
https://evan-moon.github.io/2019/11/26/tcp-congestion-control/
MTU(Maximum Transmission Unit)는 한 세그먼트에 최대로 보낼 수 있는 데이터의 양을 나타냄
Flow control에 대해 설명해주세요.
송신 측은 수신 측의 데이터 처리 속도를 파악하고 자신이 얼마나 빠르게, 많은 데이터를 전송할 지 결정해야 하는데, 이를 제어하기 위한 방식이 flow control입니다.
대표적으로 Stop and wait 방식이 있고, sliding window 방식이 있습니다.
먼저 가장 간단한 Stop and wait 방식은 수신자에게 데이터를 보낸 후 잘 받았다는 응답이 올 때까지 기다리는 것입니다. 수신자가 응답을 하면 다시 데이터를 보내는 것이기 때문에 매우 간단하지만, 한번 보낼 때 마다 RTT타임 만큼 기다려야 하기 때문에 성능이 떨어집니다.
이러한 비효율적인 부분이 있기 때문에 TCP의 흐름 제어는 sliding window 방식을 사용합니다.
이 방식은 수신자가 한 번에 처리할 수 있는 데이터를 정해놓고, 그때그때 수신 측의 데이터 처리 상황을 송신 측에 알려줘서 송신 측의 윈도우 사이즈를 수신자의 window size에 맞춰 전송 속도를 조절하게 됩니다.
이 방식은 수신자가 처리할 수 있는 데이터의 양을 알고 있기 때문에, 하나씩 ACK를 보내지 않아도 예측이 가능합니다. 송신자와 수신자는 데이터를 담을 수 있는 각각의 버퍼와 window를 가지고 있는데, 이 윈도우 사이즈를 조절해서 보내는 데이터의 양을 조절하게 됩니다.
TCP의 슬라이딩 윈도우 방식은 송신자가 수신자의 window size와 기타 요소들 (RTT, 혼잡 제어 등등)을 고려해 window size를 잡고, 한번에 윈도우 사이즈만큼 보내고 수신자의 응답을 받으면 그 만큼 윈도우를 미는 형태로 연속적인 데이터를 보냅니다.
또한 수신자가 ACK를 보내서 성공적으로 받은 데이터의 마지막 시퀀스 번호를 ACK로 송신자에게 보내기 때문에 송신자는 패킷 전송의 응답 확인을 받을 수 있습니다.
<오류제어>
이때는 cummulative ACKs를 사용하지만 누락 패킷 이후의 패킷들을 버리지 않고 있다가 전송
Zero Window인 상황에서는 송신자는 수신자로부터 윈도우 크기가 다시 양수가 되는 신호를 받을 때까지 데이터 전송을 중단하는데, 이때 지속적인 확인을 위해 데이터가 없는 패킷을 보내서 확인합니다.
