TCP 연결
TCP 특징
- 연결 지향형(Connection Oriented)
프로세스가 데이터를 다른 프로세스에게 보내기 전에 두 프로세스가 서로 핸드쉐이킹을 해야 합니다.
- 전이중(full-duplex)
서로 다른 프로세스가 서로 TCP로 연결되어 있다면 둘은 양방향으로 데이터를 전송할 수 있습니다.
- 점대점(Point-to-Point)
단일 송신자와 단일 수신자 사이의 점대점입니다.
한 송신자가 여러 수신자에게 데이터를 보내는 멀티캐스팅은 TCP에서 불가능합니다.
TCP 세그먼트 구조
TCP 세그먼트로 모아 담을 수 있는 최대 데이터의 양은 최대 세그먼트 크기(Maximun Segment Size, MSS)로 제한됩니다.
신뢰적인 데이터 전달
인터넷 네트워크 계층(IP)는 비신뢰적입니다.
- 데이터그램 전달을 보장하지 않음.
- 데이터그램이 순서대로 전달된다는 것을 보장하지 않음.
- 데이터의 무결성을 보장하지 않음.
하지만 TCP는 IP의 비신뢰적인 최선형 서비스에서 신뢰적인 데이터 전송 서비스를 제공합니다.
TCP 송신자의 사건
1. 송신자는 순서번호를 붙여 세그먼트를 생성하고 timer가 다른 세그먼트에 의해 실행중이 아니라면 timer를 시작합니다.
2. 타임아웃을 유발한 세그먼트를 재전송하고 timer를 다시 시작합니다.
3. 확인응답이 온 세그먼트를 갱신하고, 확인응답을 받지 못한 세그먼트가 존재하면 timer를 다시 시작합니다.
TCP 재전송 시나리오
호스트B가 A로부터 세그먼트를 전송 받았지만 확인 응답을 보내는 도중 타임 아웃이 발생하였습니다. 이렇게 되면 호스트 B는 호스트 A에서 재전송된 세그먼트의 바이트를 버릴 것입니다.
호스트 A는 첫 번째 타임 아웃에서 확인 응답을 받지 못한 Seq=92인 세그먼트를 재전송하고 Sep=100인 세그먼트는 ACK가 타임아웃이 되기 전에 도착하기에 전송하지 않습니다.
첫 번째 확인 응답이 분실되었지만 두 번째 확인 응답이 전달되어 호스트 A는 호스트 B가 모든 응답을 받았음을 알게 되고 아무런 세그먼트도 재전송하지 않습니다.
빠른 재전송
세그머트를 잃었을 때, 긴 타임아웃 주기는 잃어버린 패킷을 다시 보내기 전에 송신자를 오랫동안 기다리게 해서 종단 간의 지연을 증가시킵니다.
송신자는 종종 송신자가 이미 이전에 받은 확인응답에 대해 재확인 응답 세그먼트 ACK인 중복 ACK에 의해 타임아웃이 일어나기 전에 패킷 손신을 발견하게 됩니다.
만약 TCP 송신자가 같은 데이터의 3개의 중복 확인 응답을 수신한다면 3개의 세그먼트가 분실되었음을 의미합니다.
즉, TCP는 세그먼트의 타이머가 만료되기 이전에 손실 세그먼트를 재전송하는 빠른 재전송을 진행합니다.
흐름 제어
만약 송신자가 데이터를 더 빠르게 전송하면 수신자의 수신 버퍼는 오버플로우가 발생될 것입니다. TCP는 위 문제를 방지하기 위해 애플리케이션에게 흐름 제어 서비스를 제공합니다.
흐름 제어 서비스는 수신하는 애플리케이션이 읽는 속도와 송신자가 전송하는 속도를 같게 해주는데 이때 TCP는 송신자가 수신 윈도우(receive window, rcv window)라는 변수를 유지하여 흐름 제어를 제공합니다.
rcv window는 수신 측에서 가용한 버퍼 공간이 얼마나 되는 지를 송신자에게 알려주는 데 사용됩니다.
동작 방법
1. 수신자가 세그먼트에 RcvWindow의 값을 포함하는 방법으로 사용 가능한 버퍼 공간을 알려줍니다.
2. 송신자가 확인응답 되지 않은 데이터의 크기를 RcvWindow로 제한합니다.
연결 관리
TCP 송신자는 수신자와 데이터 세그먼트를 교환하기 위해 연결을 설정하고 3 handshake 기법으로 통신합니다.
TCP에서 연결을 끝내는 과정
1. 클라이언트가 FIN 비트를 1로 설정한 값을 세그먼트 헤더에 포함한 후 서버에 송신합니다.
2. 서버가 세그먼트를 수신하면 확인응답(ACK) 세그먼트를 송신합니다.
3. 서버는 그 다음에 FIN 비트를 1로 설정한 자신의 종료 세그먼트를 송신합니다.
4. 클라이언트는 서버의 종료 세그먼트에 확인 응답을 합니다.
* 약간의 변경으로 여러 개의 FIN을 처리할 수 있습니다.
혼잡제어
네트워크가 처리하기에 너무 빠르고 많은 데이터를 너무 많은 송신자들이 전송할 경우 혼잡 현상이 발생합니다. 위에서 설명한 흐름 제어와는 다른 것이고 네트워크 분야에서 상위 10대 문제 중 하나라고 합니다.
혼잡의 원인과 비용 3가지 시나리오
시나리오1 : 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터
라우터는 무한대의 버퍼를 가지고 있으며, 재전송이 없다고 가정하면 각 호스트는 최대 출력량을 R/2 만큼 가질 수 있습니다.
패킷 도착률이 링크 용량에 근접함에 따라 큐잉 지연이 심해집니다.
시나리오2 : 2개의 송신자, 유한 버퍼를 가지 하나의 라우터
버퍼에 공간이 있을 때 : λin = λout
손실에 대해서만 재전송이 발생하는 경우 : λ'in > λout
손실되지 않은 패킷에 의한 재전송이 발생하는 경우 : λ'in > λout (?)
혼잡의 비용
- 버퍼 오버플로우 때문에 버려진 패킷을 보상하기 위해 재전송을 수행
- 불필요한 재전송 : 링크가 패킷의 불필요한 복사본을 전달
시나리오3 : 4개의 송신자와 유한 버퍼를 갖는 라우터와 멀티홉 경로
잘 모르겠습니다.
두 번째 홉 라우터에서 패킷이 버려지면, 첫 번째 홉 라우터에서 두 번째 라우터에 전달한 패킷의 작업이 헛수고가 된다고합니다.
즉, 패킷이 경로상에서 버려질 때 버려지는 지점까지 패킷을 전송하는 데 사용된 상위 라우터에서 사용된 전송 용량은 낭비됩니다.
혼잡 제어에 대한 접근법
2가지 광범위한 접근 방식이 있습니다.
종단 간의 혼잡 제어
- 네트워크 계층은 어떠한 직접적인 자원도 제공하지 않습니다.
- 패킷 손실 및 지연에 기반하여 종단 시스템이 추측해야 합니다.
- TCP는 혼잡 제어를 위한 종단 간의 접근 방식을 취합니다.
네트워크 지원 혼잡 제어
- 라우터들은 네트워크 안에서 혼잡 상태와 관련하여 송신자나 수신자 모두에게 직접적인 피드백을 제공합니다.
- 하나의 비트가 혼잡을 알려줍니다. ex) TCP/IP ECN
* ECN(Explicit Congetstion Notification) : 직역하면 명시적 혼잡 알림으로 인터넷 내에서 수행되는 네트워크 지원 혼잡 제어의 한 형태입니다.
TCP 혼잡 제어 : 가법 증가, 승법 감소(AIMD)
위 그림 처럼 손실이 발생할 때까지 사용가능한 대역폭을 탐지해 송신률을 대폭 상승시키고(가법 증가), 손실 발생 이후에 송신률의 값을 1/2로 줄입니다.
TCP Slow Start(느린 시작)
연결이 시작되면 최초의 손실 사건이 발생할 때까지 전송률을 지수적으로 증가시킵니다. 즉, 최초의 전송률은 느리지만, 지수적으로 빠르게 증가됩니다.
타임아웃 사건에 대한 반응
모르겠음
TCP 리노 처리율
가법 증가, 승법 감소 특성에서 TCP 평균 처리율은 손실이 발생했을 때 윈도우 크기를 W라 하면 처리율은 W/RTT가 됩니다. 또한 손실이 발생한 이후 윈도우 크기는 W/2로 감소하기에 처리율은 W/2RTT가 됩니다.
따라서 두개의 평균을 구하면 평균 처리율은 3W/4RTT가 됩니다.
TCP 공평성
N개의 TCP 세션이 대역폭 R을 가진 같은 병목 링크를 공유한다면, 각각의 세션의 평균 전송률은 R/K가 되어야합니다.
예를 들어 2개의 커넥션이 물려있고 가법증가, 승법 감소 기법을 사용하는 상황을 가정하면
위 그림처럼 연결 1의 처리율의 증가와 감소에 따라 위 그래프 같은 결과가 되는데 연결 2도 똑같이 생각하면 결론적으로 대역폭이 비슷해집니다.
따라서 TCP는 공정하다고 할 수 있습니다. 하지만 동일한 RTT, 고정 세션 수, 혼잡 회피에서만 공정합니다.