전송계층 - TCP

TCP 통신 특징

• Point to Point
  • socket 한쌍의 통신만을 수행한다.
• reliable, in-order byte stream
  • 유실없이 순서대로 전달된다.
• pipelined
  • 한번에 여러개의 패킷을 연속적으로 전달한다.
• send & receiver buffer
  • reliable 한 데이터 전송을 위해 send와 receiver는 buffer에 데이터를 일시적으로 저장한다.
• full duplex data
  • 데이터가 양방향으로 움직인다.
• connection oriented
  • 커넥션 기반으로 데이터를 전송하기 위해 handshake 과정을 거친다.
• flow controlled
  • receiver buffer에 남는 공간 만큼 sender 가 보내는 데이터 양을 조절한다.
• congestion controlled
  • 네트워크 상황에 맞게 sender는 보내는 데이터 양을 조절한다.

TCP 세그먼트 구조

• source port, dest port (각 16비트)
• sequence number, acknowledgement number
• checksum
  • 오류 검증
• receive window
  • receive 가용 버퍼 사이즈
• flags

TCP의 신뢰성있는 데이터 전송 특징

• Pipelined segments
• cumulative acks
  • receiver가 다음에 받아야할 seq를 ack로 보낸다.
  • cumulative acks는 앞서 reciever가 보낸 ack 응답이 유실되더라도 가장 최신의 성공적으로 받은 데이터 그 다음 번호를 전달함으로써 앞서 유실된 응답을 보완할 수 있다.
• 단일 재전송 타이머
  • go-back n과 같이 단일 타이머를 사용한다.
  • go-back n방식과 다른 점은 go-back n은 timeout 발생시점 이후 모든 데이터를 재전송하지만 TCP는 timeout이 터진 그 데이터만 재전송한다.
• 재전송 기준
  • timeout
  • 중복된 ack number (권고, 3번 중복) => fast retransmit

TCP의 flow control

• 헤더 세그먼트에 receive window에 receiver의 bufferSize를 담아 전달한다.
• sender는 이 bufferSize에 맞게 데이터를 전송한다.
• 만약, receiver에 buffer가 가득차있다면 sender는 receiver buffer에 공간이 나올때까지 주기적으로 빈 데이터를 담은 요청을 보낸다.
• receiver가 보내는 ack에 window size를 알 수 있기 때문이다.

TCP 3way handshake

클라이언트와 서버가 TCP로 통신하기 위해 연결을 준비하는 작업이다.

• 클라이언트가 세그먼트 해더 Syn 필드에 1을 표시하고 초기 Seq number x를 서버에 전송한다.
• 서버는 SYN과 ACK 필드에 1을 표시하고 자신의 초시 Seq number y를, Cumulative Ack로 x+1을 클라이언트에 전송한다.
• 클라이언트는 ACK 필드에 1을 표시하고 Cumulative Ack로 y+1을 서버에 전송한다.
• 클라이언트가 3way handshake 마지막에 응답을 할 때 바로 데이터 메세지를 포함해 서버로 전송할 수 있다.
• HTTP 요청은 3way handshake가 맺어지고 나서 전송된다.

왜 2way가 아니라 3way일까?
서버 입장에서도 SYN에 대한 클라이언트의 ACK를 받아야 신뢰성있는 전송을 보장할 수 있기 때문이다.

TCP 4way handshake

연결을 맺고 있는 두 소켓을 정리하는 과정이다.

• 클라이언트가 FIN 필드에 1을 표시해 서버에 전송한다.
• 서버는 ACK 필드에 1을 표시해 서버에 전송한다.
• 서버는 FIN 필드에 1을 표시해 클라이언트에 전송한다.
• 클라이언트가 ACK 필드에 1을 표시해 서버로 전송한다.
• 클라이언트는 ACK 필드를 전송하고 일정 시간동안 소켓을 정리하지 않고 기다리는데 이는 마지막에 전송한 ACK 응답이 유실되어 서버가 FIN을 재전송하거나 서버로부터 아직 들어오지 못한 응답이 있을 가능성이 있기 때문이다.

congestion control

sender는 재전송을 줄이고 신속하게 데이터를 전송하기 위해선 receiver의 혼잡 상태와 네트워크의 혼잡 상태를 모두 고려해야한다. receiver의 혼잡 상태는 세그먼트 헤더에 담긴 receive window 사이즈로 알 수 있지만 네트워크의 혼잡 상태는 수많은 라우터에서 일일히 알려줄 수 없다. 이에 TCP 자체적으로 네트워크의 혼잡 상태를 유추하여 처리해야하는데 이 과정이 congestion control 이다. congestion control이 없으면 sender는 네트워크에서 유실된 데이터를 계속해서 재전송함으로써 네트워크의 혼잡 상황을 악화시킬 수 있다.

• slow start
  • window size를 아주 적은 양에서 부터 지수 함수 형태로 데이터 전송량을 늘려간다.
• additive increase
  • threshold 지점을 넘어서면서는 linear 형태로 데이터 전송량을 늘려간다.
• multiplicative decrease
  • 데이터 유실이 감지되면 threshold 지점을 절반으로 감소시켜 다시 위 작업을 반복한다.

TCP Tahoe vs TCP Reno

Tcp tahoe는 초기 tcp로 데이터 유실 발생시 데이터 전송양을 처음 전송양과 동일하게 대폭 줄이는 방식으로 구현되었다. 그러나 이후 개발된 TCP Reno는 데이터 유실이 감지된 상황을 기반으로 각각 다르게 동작한다.

• 3 Duplicate Acks 발생시
  • 네트워크가 크게 혼잡한 상황은 아닌 것으로 판단하고 전송양을 반만 감소
• timeout 발생시
  • 네트워크가 상당히 혼잡한 상황으로 판단하고 전송양을 처음 전송양과 동일하게 대폭 감소

둘다 threshold는 절반으로 감소시키는 것은 동일한다. 현대 TCP congestion control은 TCP Reno의 방식을 취한다.