TCP/IP 흐름제어 및 혼잡제어

[TCP] 3 way handshake & 4 way handshake 이란?

 

3 way handshake 는 연결을 성립하는 과정이고 4 way handshake 는 연결을 해제하는 과정을 의미한다.

 

※ 3 way handshake - 연결성립

TCP 는 정확한 전송을 보장해야 한다.

따라서 통신하기에 앞서, 논리적인 접속을 성립하기 위해 3 way handshake 과정을 진행한다.

 

 

1. 클라이언트는 서버에게 SYN 패킷을 보낸다. (SYN(x) 는 sequence : x)
2. 서버가 SYN(x)을 받고, 클라이언트로 받았다는 신호인 ACK와 SYN 패킷을 보낸다. (sequence : y, ACK : x + 1)
3. 클라이언트는 서버의 응답인 ACK(x + 1), SYN(y) 패킷을 받고, ACK(y + 1) 를 서버로 보낸다.

 

이렇게 3번의 통신이 완료되면 연결이 성립된다.

 

※ 4 way handshake - 연결 해제

 

연결이 성립된 후에 모든 통신이 끝나면 연결을 해제해야 한다.

 

 

1. 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 보낸다.
2. 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보낸다. (모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 됨)
3. 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트에게 보낸다.
4. 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다. (아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다림)
   • 서버는 ACK를 받은 이후 소켓을 닫는다. 
   • TIME_WAIT 시간이 끝나면 클라이언트도 닫는다.

 

이렇게 4번의 통신이 끝나면 연결이 해제된다.

 

SYN Packet 과 ACK Packet 은 무엇인가?

 

SYN 는 synchronize sequence number 의 약자, ACK 는 acknowledgement 의 약자이다.

TCP Header 에는 Code Bit(Flag bit) 라는 부분이 존재하며 총 6 bit 로 이루어져 있어 각각 한 bit 들이 의미를 갖고 있다. (URG - ACK - PSH - RST - SYN - FIN 순서)

해당 위치의 비트가 1이면 해당 패키싱 어떠한 내용을 담고 있는 패킷인지를 나타낸다. (ex : SYN 패킷일 경우 000010)

 

2-way handshake 가 아닌 3-way handshake 를 사용하는 이유는 무엇인가?

 

TCP connection 은 bidirectional connection 이다.

클라이언트에서 서버에게 존재를 알리고 패킷을 보낼 수 있다는 것을 알리듯, 서버에서도 클라이언트에게 존재를 알리고 패킷을 보낼 수 있다는 신호를 보내야 한다.

그러므로 2-way handshake 보단 3-way handshake 가 더 적합하다.

 

sequence number 이 랜덤한 이유는 무엇인가?

 

초기 sequence number 를 ISN 이라고 하는데 이러한 ISN 을 난수로 생성해서 number 를 설정하는 이유는 다음과 같다.

Connection 을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다.

따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다.

서버 측에서는 패킷의 SYN 을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적 number 가 전송된다면 이전의 connection 으로부터 오는 패킷을 인식할 수 있다.

이러한 문제가 발생할 가능성을 줄이기 위해 난수로 ISN 을 설정하는 것이다.

 

 

※ TCP 통신

네트워크 통신에서 신뢰적 연결방식이다.

TCP는 기본적으로 reliable network 를 보장하도록 하는 프로토콜이다.

 

reliable network 를 보장할 때 어떠한 문제점이 있는지?

 

총 4가지 문제점이 존재한다.

1. Loss : packet이 손실될 수 있는 문제
2. Order : packet의 순서가 바뀌는 문제
3. Congestion : 네트워크의 혼잡 문제
4. Overload : receiver 측에서 과부화가 걸린 문제

 

※ 전송의 전체 과정

1. Application layer : sender application layer가 socket에 data를 쓴다. 
2. Transport layer : data를 segment에 감싸서 network layer에 넘겨준다.
3. 아랫단에서 receiving node로 전송이 된다. 이 때, sender의 send buffer에 data를 저장하고, receiver는 receive buffer에 data를 저장한다.
4. application에서 준비가 되면 이 buffer에 있는 것을 읽기 시작한다.

 

※ 흐름 제어(Flow Control)

수신측이 송신측보다 데이터 처리 속도가 빠르면 문제가 없다.

하지만 송신측의 속도가 빠르면 문제가 발생한다.

수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실이 발생하며 만약 손실 된다면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 빈번히 발생하게 된다.

이러한 리스크를 줄이기 위해 송신 측의 데이터 전송량을 수신측에 따라 조절해야 한다.

 

다음과 같은 해결방법들이 존재한다.

 

① Stop and Wait : 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법이다.

 

 

② Sliding Window (Go Back N ARQ) : 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어기법이다.

LastByteSent - LastByteAcked <= ReceiveWindowAdvertised

 

 

♣ 송신 버퍼

 

• 200 이전 바이트는 이미 전송되었고 확인 응답을 받은 상태이다.
• 200 ~ 202 바이트는 이미 전송되었으나 확인 응답을 받지 않은 상태이다.
• 203 ~ 211 바이트는 아직 전송되지 않은 상태이다.

 

♣ 수신 윈도우

 

♣ 송신 윈도우

 

수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정하게되면 흐름제어가 가능하다.

 

♣ 송신 윈도우 이동

 

• Before : 203~204를 전송하면 수신측에서 확인응답 203을 보내고, 송신측은 이를 받아 after 상태와 같이 수신 윈도우를 203 ~ 209 범위로 이동한다. 
• After : 205 ~ 209가 전송 가능한 상태이다.

 

※ 혼잡제어 (Congestion Control)

송신측의 데이터는 지역망, 인터넷으로 연결된 대형 네트워크를 통해 전달된다.

만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없다.

이런 경우 호스트들은 또 다시 재전송을 하게 되고 결국 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생시키게 된다.

따라서 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송 속도를 강제로 줄이게 되는데 이러한 작업을 혼잡 제어라고 한다.

또한 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라고 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡 제어라고 한다.

흐름 제어가 송신측과 수신측 사이의 전송속도를 다루는 반해, 혼잡 제어는 호스트와 라우터를 포함한 보다 넓은 관점에서 전송 문제를 다루게 된다.

 

해결 방법으로 AIMD 이 있다.

 

 

※ AIMD(Additive Increase / Multiplicative Decrease)

• 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
• 패킷 전송에 실패하거나 일정 시간을 넘으면 패킷의 보내는 속도를 절반으로 줄인다.
• 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형상태로 수렴하게 되는 특징이 있다.
• 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

 

※ Slow Start

• AIMD 방식이 네트워크의 수용량 주변에서는 효율적으로 작동하지만, 처음에 전송 속도를 올리는데 시간이 오래 걸리는 단점이 존재했다.
• Slow Start 방식은 AIMD와 마찬가지로 패킷을 하나씩 보내면서 시작하고, 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려준다. 즉, 한 주기가 지나면 window size가 2배로 된다.
• 전송속도는 AIMD에 반해 지수 함수 꼴로 증가한다. 대신에 혼잡 현상이 발생하면 window size를 1로 떨어뜨리게 된다.
• 처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만, 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있다.
• 그러므로 혼잡 현상이 발생하였던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킨다.

 

※ Fast Retransmit

• 빠른 재전송은 TCP의 혼잡 조절에 추가된 정책이다.
• 패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 된다.
• 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있다.
• 중복된 순번의 패킷을 3개 받으면 재전송을 하게 된다. 약간 혼잡한 상황이 일어난 것이므로 혼잡을 감지하고 window size를 줄이게 된다.

 

※ Fast Recovery

• 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다. 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.

 

 

참고 : tech-interview-for-developer/TCP (흐름제어혼잡제어).md at master · gyoogle/tech-interview-for-developer (github.com)

GitHub - gyoogle/tech-interview-for-developer: 👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖

https://www.quora.com/Why-in-a-TCP-sequence-is-a-number-taken-as-a-random-number-and-what-is-the-actual-number-at-the-start

Why in a TCP sequence, is a number taken as a random number and what is the actual number at the start?