TCP vs UDP

Q. TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)란 그리고 차이는?

TCP와 UDP는 모두 전송 계층(Transport Layer)의 프로토콜입니다.
TCP는 양방향 통신으로 패킷의 올바른 순서를 보장하고 손실을 재전송하는 신뢰성과 수신자의 처리 속도를 고려하는 흐름 제어, 네트워크 혼잡을 고려하는 혼잡 제어 기능을 제공합니다. 
하지만 신뢰성, 흐름제어, 혼잡제어를 고려하는 만큼 큰 헤더와 연결을 위한 3 way handshake 때문에 큰 오버헤드가 발생합니다.

반면 UDP는 단방향 통신으로 신뢰성과 흐름제어 혼잡제어를 제공하지 않아 빠른 전송속도를 보장할 수 있습니다.

Q. 3 way handshake와 4 way handshake 사용 이유와 과정에 대해서 설명해주세요.

3 way handshake는 TCP 연결을 설정하는 과정이고 4 way handshake는 연결을 종료하는 과정입니다.
초기 시퀀스 번호를 교환하고 연결 상태를 파악하여 신뢰성을 보장하기 위하여 3 way handshake를 사용하고 안전하게 모든 데이터가 전송되었음을 보장하기 위해 4 way handshake를 사용합니다.

3 way handshake 과정은 3단계로 이루어져있는데 우선 송신자가 초기 시퀀스 번호(ISN)를 난수로 생성하고 SYN 패킷을 전송합니다. 수신자는 SYN 패킷을 받고 수신자의 초기 시퀀스 번호를 포함하여 확인했다는 SYN/ACK 패킷을 전송합니다. 클라이언트는 서버의 초기 시퀀스 번호에 대한 확인 응답을 포함한 ACK 패킷을 보내고 상호간의 시퀀스 번호를 파악한 상태로 연결이 설정됩니다.

4 way handshake 과정은 4단계로 이루어지는데 우선 송신자에서 FIN 패킷을 보냅니다. 수신자는 이를 확인하고 ACK 패킷을 전송합니다. 하지만 아직 수신자가 처리해야하는 데이터가 남아있을 수 있고, 수신자는 자신이 보내야하는 모든 데이터를 전송하면 FIN 패킷을 송신자에게 보냅니다. 송신자는 FIN 패킷을 받고 ACK를 전송하며 연결을 종료합니다.

Q. 3 way handshake에서 시퀀스 번호를 난수로 설정하는 이유가 무엇인가요?

여러 연결에서 시퀀스 번호가 중복되지 않게 하기 위함입니다.
두 연결에서 중복된 시퀀스 번호를 사용하는 경우 수신자는 어떤 패킷이 어떤 연결의 것인지 파악할 수 없고, 패킷이 손상되거나 순서가 잘못되는 등의 오류가 발생할 수 있습니다.

Q. TCP의 흐름 제어와 혼잡 제어 방법에 대해서 설명해주세요.

흐름 제어는 송신자와 수신자의 데이터 처리 속도 차이를 해결하기 위한 기법입니다.
수신자가 처리할 수 있는 데이터보다 많은 데이터를 송신자가 전송하는 경우 패킷이 손실될 수 있기 때문에 패킷 전송량을 제어합니다.
TCP는 슬라이딩 윈도우 방식을 통해 흐름 제어를 합니다. 수신 측이 잔신이 처리할 수 있는 데이터 양인 윈도우 크기를 TCP 헤더를 통해 송신 측에 알리고 송신 측은 윈도우 크기 내에서 데이터를 전송하게 됩니다. 수신 측의 처리 가능량이 변동되면 새로운 윈도우 크기를 알리는 방식으로 전송 속도를 조절합니다.

혼잡 제어는 네트워크 전체의 혼잡 때문에 패킷 손실이 발생하는 것을 방지하기 위한 기법입니다. 
송신자는 전체 네트워크 내의 혼잡도를 알 수 없기에 slow start를 통해 초기 혼잡 윈도우 크기를 작게 설정하고 매 요청마다 혼잡 윈도우 크기를 2배로 증가시킵니다. congestion avoidance를 통해 만약 윈도우 크기가 threshold에 도달하면 증가폭을 줄입니다.
3번 중복된 ack가 오면 패킷 손실로 간주하고 빠르게 재전송하는 fast tretansmit을 수행하고 혼잡 윈도우 크기를 절반으로 줄이는 fast recovery를 수행합니다.

Q. 네이글 알고리즘이란?

네이글 알고리즘은 네트워크 효율성을 높이기 위해 고안된 TCP/IP 네트워크 프로토콜의 방법입니다.

네이글 알고리즘은 버퍼가 꽉 차고 이미 전송한 패킷이 받을때까지 기다려 한번에 패킷을 전송하여 네트워크에 불필요하게 많은 작은 패킷이 전송되는 것을 방지하여 전송 효율을 높일 수 있습니다.

Q. 만약 서버에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황이 발생한다면 어떻게 되나요? 해결 방법은 무엇인가요?

TCP 헤더에 존재하는 시퀀스 넘버를 마지막 패킷의 시퀀스 넘버보다 크기 때문에 클라이언트에서는 아직 수신하지 못한 시퀀스 넘버의 패킷을 기다리게됩니다. 모든 패킷이 도착해야지만 ACK를 보내기때문에

Q. 4way handshake 과정을 상세하게 설명해주세요.
클라이언트가 FIN 패킷을 전송하지 않은 상태(ESTABLISH 상태)에서 네트워크가 단절되었다 다시 연결되었을 때 어떤 문제가 있을까요? 해결 방안은 어떤게 있을까요?

4 way handshake는 클라이언트가 서버에 FIN 패킷을 보내고 서버는 이를 확인하고 ACK 패킷을 전송합니다.
서버가 전송해야할 데이터를 다 송신하고 서버는 클라이언트에 FIN 패킷을 보냅니다. 클라이언트는 ACK를 전송하며 연결을 종료합니다.

클라이언트는 지속해서 ACK 응답을 받지 못하고 패킷이 유실되었다 판단합니다. 이후 클라이언트는 혼잡 윈도우 크기를 최소로 줄이고 처음부터 작은 사이즈의 데이터를 전송하게 됩니다.
이를 해결하기 위해서는 혼잡 윈도우의 크기를 절반으로 줄이는 fast recovery를 수행하면 됩니다.