📍 들어가기 전

• TCP통신이란?
  • 기본적으로 unreliable network에서 reliable network(신뢰성있는 네트워크)를 보장할 수 있도록 하는 프로토콜
  • network congestion avoidance algoritm을 사용

• reliable network가 보장하는 4가지 문제점
  1. 손실 : 패킷이 손실될 수 있는 문제
  2. 순서 바뀜 : 패킷의 순서가 바뀌는 문제
  3. Congestion : 네트워크가 혼잡한 문제
  4. Overload : receiver가 overload되는 문제

• TCP/IP계층 -> 현재 인터넷에서 사용되는 방법
  

Network Access Layer

• OSI 7계층의 물리계층과 데이터링크 계층에 해당.
• 물리적인 주소로 MAC을 사용
• CSMA/CD, MAC, LAN 등

인터넷 계층

• OSI 7계층의 네트워크 계층에 해당
• 통신 노드 간의 IP패킷을 전송하는 기능과 라우팅 기능을 담당
• IP, ARP(Address Resolution Protocol), RARP 등

전송 계층

• OSI 7계층의 전송 계층에 해당
• 통신 노드 간의 연결을 제어하고, 신뢰성 있는 데이터를 전송
• TCP, UDP 등등

응용 계층

• OSI 7계층의 세션 계층, 표현 계층, 응용 계층에 해당
• TCP/UDP 기반의 응용 프로그램을 구현할 때 사용
• SMTP, FTP, HTTP, SSH, DNS 등등

1. 전송의 과정

위에서 첨부한 그림과 함께 흐름을 보자면,

1. 응용 계층에서 sender application layer가 socket에 data를 씀
2. 전송 계층에서 data를 segment에 감싼다. 그리고 network layer 계층에 넘긴다.
3. 이후의 계층에서 receiving node로 받고, 이때 sender의 send buffer에 data를 저장한다. receiver는 send buffer에 data를 저장한다.
4. application에서 준비가 되면 이 buffer에 있는 것을 읽는다.
   +) ✔ 이때! receiver buffer가 넘치지 않게 하는 것이 중요하다, 따라서 receiver는 RWND(Receive WiNDow) : receive buffer의 남은 공간을 홍보함.
   

2. 흐름제어/혼잡제어란?

✔ 흐름제어(endsystem 대 endsysystem)

수시 측이 송신 측보다 데이터 처리 속도가 빠르면 문제가 없지만, 송신 측의 속도가 빠를 경우 문제가 생긴다. 수신 측에서 제한된 저장 용량을 초과한 이후에 도착하는 패킷은 손실될 수 있으며, 많약 손실된다면 불필요한 추가 패킷 전송이 발생함.

즉,

• 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
• Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
• 기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback함

해결방법

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

2. Sliding Window (Go Back N ARQ)

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

• 목적 : 전송은 되었으나, acked를 받지 못한 byte의 숫자를 파악하기 위해 사용하는 프로토콜
• window : TCP/IP를 사용하는 모든 호스트들은 송신하기 위한 것과 수신하기 위한 2개의 window를 가지고 있음. 호스트들은 실제 데이터를 보내기 전에 '3-way handshaking'을 통해 수신 호스트의 receive window size에 자신의 send window size를 맞추게 된다.

• 세부구조

1. 송신버퍼
   

• 200 이전 : 전송 완료
• 200~202 : 전송은 되었으나 확인 응답을 받지 못함
• 203~211 : 미전송

2. 수신 윈도우
   

• 수신 프로세스가 다음에 처리할 바이트는 194바이트
• 수신 윈도우는 200바이트의 수신을 대기 중

3. 송신 윈도우 (확인응답되지 않은 바이트 + 전송될 바이트)
   
   수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정하게 되면 흐름제어가 가능하다. (즉, 받을 수 있는 양보다 크기 않게 보내는 것이다!)
   
4. 송신 윈도우 이동
   

• Before : 203,204 바이트를 전송하면, 수신 측에서는 확인응답으로 203 바이트를 보내고, 송신 측은 이를 받아 after와 같은 상태를 만듦
• after : 수신 윈도우를 203~209범위로 이동 시킴. 205~209까지 전송 가능 상태

5. 송신 윈도우의 축소
   

• 수신 프로세스가 데이터를 느리게 처리해서 버겁다면, 수신 윈도우의 크기를 축소 -> 송신 윈도우도 같이 크기가 축소
• 210,211 바이트 전송 후 확인 응답으로 210 받으면서 윈도우 크기를 6으로 축소함.

✔ 혼잡제어(Congestion Control)

• 송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달한다.
  만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 된다. 이런 경우 호스트들은 또 다시 재전송을 하게 되고 결국 혼잡만 가중시켜 오버플로우나, 데이터 손실을 발생하게 한다.
  따라서 네트워크의 혼잡을 피하기 위해 송신 측에서 보내는 데이터의 전송속도를 강제로 줄이게 되는 작업이다.

• 네트워크 내에 패킷의 수가 과도하게 증가하는 현상 = 혼잡
  따라서 혼잡 현장을 방지하거나 제거하는 기능을 혼잡제어라고 한다.

• 호스트와 라우터를 포함하여 흐름제어보다 넓은 관점에서 전송 문제를 다룬다.

📍 해결방법

1. AIMD(Additive Increase/Multiplicative Decrease)

처음에 패킷을 하니씩 보내고 이것이 문제없이 도착하면 window크기(=단위 시간 내에 보내는 패킷의 수)를 1씩 증가시키면서 전송하는 방법

• 패킷 전송에 실패하거나 일정 시간을 넘기면 패킷의 보내는 속도를 절반으로 줄인다.
• 공평하게, 한 호스트가 나중에 진입하더라도 처음에는 불리하지만 시간이 흐르면서 점점 평형상태로 수렴하게 되는 특징
• 문제점🤔
  • 원도우 사이즈를 하나씩 늘려가기 때문에 초기 네트워크의 큰 대역폭을 바로 사용하지 못한다.
  • 네트워크가 혼잡해지는 상황을 미리 감지할 수 없고 혼잡상태가 발생한 이후에 대역폭을 감소 시킨다는 점

2. Slow Start

시작부터 빠르게 윈도우를 증가시키고 특정 시기가 오면 윈도우를 확 줄여버리는 방식

• AIMD와 마찬가지로 처음에 패킷을 하나씩 전송한다. 패킷이 문제없이 도착하면 각각의 ACK 패킷 마다 윈도우 사이즈를 하나씩 증가시킨다. 결과적으로, 윈도우 사이즈를 두배씩 증가시킨다.

• 윈도우 사이즈를 빠르게 증가시키다가 혼잡 현상이 발생시에는 윈도우 사이즈를 1로 확 줄여버린다.

3. Fast Retransmit

• 위의 그림에서는 2,3번 세그먼트 후에 5번 세그먼트가 도착한다. 순서대로 잘 도착한 마지막 패킷의 다음 순번을 ACK패킷에 실어서 보낸다. 이러한 중복 ACK를 3개 받으면 재전송이 이루어 진다.

• 송신 측에서 설정한 타임아웃 시간이 지나지 않았어도 바로 재전송할 수 있는 것이기 때문에 빠른 전송률을 유지할 수 있다.

4. Fast Recovery(빠른 회복)

혼잡한 상태가 되면 윈도우 사이즈를 반으로 줄이고 선형증가시키는 방식

• 이 정책 후 혼잡 상황을 겪게 되면 AIMD방식으로 동작하게 된다.