TCP 이론 (흐름제어)

• write/send 함수가 호출되는 순간 데이터는 출력버퍼로 이동
• read/recv 함수가 호출되는 순간 입력버퍼에 저장된 데이터를 읽음
• 입출력 버퍼의 특성

- 입출력 버퍼는 TCP socket 각각에 대해 별도로 존재

- 입츨력 버퍼는 socket 생성 시 자동으로 생성

- socket을 닫아도 출력버퍼에 남아있는 데이터는 계속해서 전송

- socket을 닫으면 입력버퍼에 남아있는 데이터는 소멸

- 입력버퍼의 크기를 초과하는 데이터 전송은 발생하지 않음

(TCP가 데이터의 흐름을 조절: Sliding Window)

 

• Sliding Window 프로토콜

- socket A → B: 50바이트까지 전송 괜찮음

- socket B → A: 확인

- socket A → B: 20바이트 비웠으니 50바이트까지 전송 괜찮음

- socket B → A: 확인

- 버퍼가 넘쳐 데이터가 소멸되지 않음

 

※ write/send 함수가 반환되는 시점: 전송될 데이터가 출력버퍼로 이동완료되는 시점이지만 TCP의 경우 출력버퍼로 이동된 데이터는 거의 전송이 되므로 데이터의 전송이 완료되는 시점으로 보아도 무관하다.

 

• TCP의 내부 동작원리1: 상대 socket과 연결

• 상대 socket과 연결: three-way handshaking

- [SYN(처음 연결요청에 사용되는 메시지, 동기화 메시지)] SEQ: 1000, ACK: - (비어있음)   

→ 지금 보내는 패킷에 번호 1000 부여 (이 패킷이 잘 수신되면 수신측에서 1001 번호 패킷 요청)

- [SYN+ACK(동기화 메시지와 응답메시지)] SEQ: 2000, ACK: 1001

→ SEQ: 지금 보내는 패킷에 번호 2000 부여 (이 패킷이 잘 수신되면 수신측에서 2001 번호 패킷 요청)

→ ACK: 송신측 SEQ 1000 패킷 받고 SEQ가 1001인 패킷 전송요청

- [ACK(응답메시지)] SEQ: 1001, ACK: 2001

→ SEQ: 요청했던 SEQ가 1001인 패킷 전송

→ ACK: 송신측 SEQ 2000 패킷 받고 SEQ가 2001인 패킷 전송요청

• 패킷에 번호를 부여하여 전송하고 확인하기 때문에 손실된 데이터의 확인 및 재전송이 가능 
• 이 과정을 통해 호스트간 데이터 송수신을 위한 준비가 되었음을 서로 인식

• TCP의 내부 동작원리2: 상대 socket과 데이터 송수신

• 호스트A가 호스트B에게 200 바이트를 두 개의 패킷에 나눠 전송하는 과정

- 호스트A가 SEQ: 1200인 패킷에 100바이트의 데이터를 전송

- 호스트B는 수신된 바이트 크기만큼 증가시킨 ACK: 1301 메시지를 담은 패킷을 전송하여 패킷이 제대로 수신되었음을 알림

※ ACK번호: SEQ번호 + 수신된 바이트 크기 + 1 (해당 바이트 크기만큼의 데이터를 잘받았으니 +1 SEQ번호의 패킷 요청 )

• 중간에 패킷이 소멸되는 상황

- SEQ: 1301인 패킷의 송신 오류로 소멸될 경우 호스트A에서 일정시간이 지나도 호스트B로부터 SEQ: 1301에 대한 ACK: 1402 메시지를 받지 못하기 때문에 재전송 진행

- SEQ: 0001 패킷 전송

if(Time >= TimeOut)

{

      send/write(clnt_socket, buff[SEQ], sizeof(100));

}

else if (Time_ACK<TimeOut)

{

      send/write(clnt_socket, buff[SEQ + ACK], sizeof(100));

}

 

- 데이터의 손실에 대한 재전송을 위하 TCP socket은 ACK 응답을 요구하는 패킷 전송 시에 타이머를 동작시킴

• TCP의 내부 동작원리3: 상대 socket과 연결 종료

- socket A가 종료 메시지를 socket B에 전달하고 socket B는 메세지의 수신을 socket A에게 알림

- socket B가 종료 메시지를 socket A에 전달하고 socket A는 메세지의 수신을 socket B에게 알림

- 상호간 FIN(: 종료 메시지)를 한번씩 주고받으면서 종료

• Four-way handshaking

- FIN 메시지에 포함된 ACK 5001은 앞선 ACK메시지가 송신된 뒤로 데이터 수신이 없었기 때문에 재전송되어 호스트A에 ACK 5001이 두 번 전송