TCP 통신이란?
- 네트워크 통신에서 신뢰적인 연결 방식
- TCP는 기본적으로 unreliable network에서 reliable network를 보장할 수 있도록 하는 프로토콜
- TCP는 network congestion avoidance algorithm 사용
reliable network를 보장한다는 것은 4가지 문제점
- 손실 : packet이 손실될 수 있음
- 순서 바뀜 : packet의 순서가 바뀜
- Congestion : 네트워크가 혼잡한 문제
- Overload : receiver가 overload되는 문제
흐름제어/혼합제어란?
흐름제어
- 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 방법
- Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
- 기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback한다는 점
혼합제어
- 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
전송의 전체 과정
- Application Layer : sender application layer가 socket에 data를 씀
- Transport Layer : data를 segment에 감싸고 network에 넘겨줌
- 아랫단에서 receiving node로 전송 됨. sender의 send buffer에 data를 저장하고, receiver는 receive buffer에 data 저장
- application에서 준비가 되면 buffer에 있는 것을 읽기 시작
- Flow Control의 핵심은 receiver buffer가 넘치지 않게 하는 것
- receiver는 RWND(Receive WiNDow) : receive buffer의 남은 공간을 홍보
흐름제어
- 수신측이 송신측보다 데이터 처리 속도가 빠르면 문제없지만, 송신측의 속도가 빠를 경우 문제가 생김
- 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실될 수 있으며, 손실된다면 불필요한 응답과 데이터 전송이 발생
- 이러한 위험을 줄이기 위해 송신 측의 데이터 전송량을 수신측에 따라 조절
해결 방법
Stop and Wait
: 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷 전송
Sliding Window (Go Back N ARQ)
: 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절
- 목적 : 전송은 되었지만, acked를 받지 못한 byte의 숫자를 파악하기 위해 사용하는 프로토콜
-> LastByteSent - LastByteAcked = ReceivedWindowAdvertised(마지막에 보낸 바이트 - 마지막에 확인된 바이트 = 남은 공간) == (현재 공중에 떠있는 패킷 수 = sliding window)
- 동작 방식 : 먼저 윈도우에 포함되는 모든 패킷 전송, 그 패킷들의 전달이 확인되는대로 윈도우를 옆으로 옮겨 다음 패킷 전송
Window : TCP/IP를 사용하는 모든 호스트들은 송신하기 위한 것과 수신하기 위한 2개의 Window를 가지고 있음.
호스트들은 데이터를 보내기 전에 '3 way handshake'를 통해 수신 호스트의 receive window size에 자신의 send window size를 맞춤 - 세부구조
-
송신 버퍼
200 이전의 바이트는 이미 전송됨
200~202 바이트는 전송되었으나 확인 응답 받지 못함
203~211 바이트는 아직 전송 되지 않음 -
수신 윈도우
-
송신 윈도우
수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정하게 되면 흐름제어 가능
-
송신 윈도우 이동
Before : 203~204를 전송하면 수신측에서 확인 응답 203을 보내고, 송신측은 이를 받아 After상태와 같이 수신윈도우를 203~209로 이동
After : 205~209가 전송 가능 -
Selected Repeat
혼합제어
- 송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달
-> 만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터 모두 처리 불가
-> 호스트들은 재전송 하게 되는데 이는 혼잡 가중시켜 오버플로우, 데이터 손실 발생
-> 이를 피하기 위해 송신측에서 보내는 데이터 전송속도 강제 저하- 네트워크 내에 패킷의 수가 과도하게 증가하는 현상 = 혼잡
- 흐름제어가 송신-수신 측 전송 속도 제어, 혼잡제어는 호스트와 라우터를 포함한 더 넓은 관점에서 전송 문제 다룸
해결 방법
AIMD(Additive Increase / Multiple 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를 반으로 줄이고 선형증가시키는 방법
-> 이 방법까지 사용하면 혼잡 상황을 한 번 겪은 후부터는 순수한 AIMD방식으로 작동
