transport layer(2)

4. TCP

특징

• point to point
  • 소켓 한 쌍 끼리의 통신만 책임짐
• reliable, in order byte steam
• full deplex: 데이터가 양방향으로 이동함
  • 각 point가 sender buffer, receiver buffer를 소유함
• connection oriented
• flow control: receiver의 buffer가 넘치지 않는 수준으로만 데이터 전송
• congestion control: 내부 네트워크가 받아들일 수 있는 수준으로만 데이터 전송

계층간 이동 단위

• application: message - 실제 전송하고자 하는 데이터
• transport: segment - message(DATA) + Header(부가 정보)
• network: packet - segment(DATA) + Header
• link: frame - package(DATA) + Header

TCP segment 구조

• source/destination port: 출발지/목적지 port
• receive window: 현재 receiver의 가용 buffer 크기
• sequence number: data의 맨 처음 byte의 인덱스 번호
  • 100 bytes 짜리 데이터를 10개의 chunk로 나눠서 보내면 0, 10, 20 ... 이 사용됨
  • sender가 보내는 데이터 순서에 따라 생성되는 번호
• acknowledge number: receiver가 다음으로 받아야 하는 기다리는 seq num

sequence number

TCP는 양방향 데이터를 전달하는 프로토콜이기 때문에, 통신에 참여하는 양 측 모두 sender와 receiver가 될 수 있다.

두 노드가 sender와 receiver를 겸하면서 서로의 seq num를 공유하게됨

• A: 자신이 보내는 데이터의 seq num을 sequence number에 담아 보냄
• B: 이를 수신하고 자신이 보내는 데이터의 seq num을 sequence number에 담아 보내면서, ACK값을 전송
• A: B로 부터 받은 ACK를 참조하여 다음 seq num에 해당하는 데이터 전송하면서 ACK값 전송

timeout

TCP의 패킷마다 timeout을 설정하는데 이를 어떻게 설정할 것인가?

timeout이 너무 길면? timeout은 확실하게 식별할 수 있으나, 복구 시간이 느림. 짧으면? 복구는 빠르나 쓸데 없는 중복 전송이 발생함

실제로 데이터가 전송되고 돌아오는 시간을 참조하여 설정한다. 즉, RTT 를 참조한다. 그러나, RTT는 가변적이다. (segment의 이동 경로(router)가 다름, queueing delay.)

따라서, 실제 RTT를 측정하고 이에 보정된 값을 사용. 여기에 확실한 timeout을 보장하기 위해 margin을 추가

fast retransmit

그러나 timeout을 기다려서 패킷 loss를 판별하기에는 너무 시간이 오래걸리기 때문에 fast retransmit 기법을 사용하기도 한다.

같은 seq num에 대한 ack를 중복해서 3개를 받으면 패킷 loss로 판별한다.

5. Flow Control

receiver 입장에서 가용 가능한 만큼만 데이터를 전송하는 방법

receiver의 버퍼가 가득 차 데이터를 수용할 수 없는 상황이 되면 데이터가 유실될 수 있다. receiver의 버퍼는 소켓 API의 read() 에 의해 비워지는데, receiver의 버퍼가 비워질 때 까지 대기한 후 데이터를 전송

특징

• receive buffer가 받을 수 있는(가용 만큼만) 만큼만 보내야 함
• receiver는 segment header(receiver window)에 가용 버퍼 크기를 보냄

가용 버퍼 확인

receiver의 버퍼가 가득 차 sender가 데이터를 전송하지 않는 경우 sender는 receiver의 버퍼가 언제 비워질 지 모른다.

• receiver가 receiver window에 0을 보낸다.
• sender는 receiver window를 확인하고 대기 -> 이후 receiver의 버퍼가 비워짐
• sender는 receiver의 버퍼가 비워졌는지 알 수 없음

이런 경우 sender는 data가 빈 segment를 주기적으로 전송하여 receiver에 가용 버퍼가 있는지 확인한다.

6. connection management

TCP 통신시, sender와 receiver는 데이터를 교환하기 전 connection을 맺는 과정이 필요하다.

필요한 이유

• 통신에 참여하는 sender/receiver의 버퍼 상황 공유
• sender/receiver의 seq num 공유

7. 3-way handshake(connection establishment)

데이터 교환 전 sender와 receiver가 connection을 맺는 과정

• client: 연결을 요청하는 노드
• server: 연결을 수락하는 노드

1. 연결을 맺고자 하는 client가 SYN bit=1로, 자신의 seq num를 전송
   • SYN bit: 1bit 짜리 플래그 값으로, handshake를 하는 동안 1로 전송
2. server가 SYN, ACK bit=1, ACK num, 자신의 seq num을 전송
   • 통신을 위한 버퍼 생성
   • SYN bit: 연결을 맺는 과정이므로 1로 설정
   • ACK bit: acknowledge number가 유효함을 설정하는 값
   • ACK num: client가 보낸 seq num에 1을 추가한 값을 보내 seq num을 정상 수신했음을 알림
   • seq num: 자신의 seq num을 전송
3. client가 ACK로 server의 seq num + 1을 보내며, 이 때 부터 데이터를 전송
   • SYN bit: 0으로 설정하여 보냄. 연결을 맺은 이후에는 0으로 설정
   • ACK num: server의 seq num을 정상 수신했음을 알림

왜 이런 과정이 필요한가

3 way handshake는 client와 server가 통신하기 전 서로 통신이 가능한 지에 대한 대한 확답을 받고, 통신에 필요한 정보(seq num, 버퍼 상황)을 공유하는 과정이다. 이 과정에서, client와 server는 서로 보낸 정보가 정상적으로 도착했는지 확인이 필요하며, 전송 이후 응답 과정을 통해 이를 알린다.

만약 2 way handshake를 사용하면 server는 자신이 보낸 seq num을 client가 정상적으로 수신했는지 알 방법이 없다.

connection closing

1. client가 더이상 전송할 데이터가 없어 FIN bit=1인 segment 전송
   • 데이터는 비어있음
2. server는 client가 보낸 FIN에 대한 ACK bit=1 을 전송하며, 추가적으로 보낼 데이터가 있다면 보낸다.
3. 이후 server도 더이상 전송할 데이터가 없으면 FIN bit=1을 전송
4. client는 server의 FIN에 대한 ACK bit=1을 전송하고 대기한다.
   • 대기하는 이유? corner case에 대한 대비
     • ACK가 유실되면? server는 connection close를 하지 못한다.
     • 만약 client가 연결을 바로 닫아버리면, server는 FIN을 계속 보내지만, client는 받을 수 없는 상황 발생
5. server는 이를 수신하고 connection close

8. Congestion control

• sender가 보내는 속도는 network, receiver의 데이터 처리 상황에 따라 결정된다.
  • receiver -> flow control
  • network -> congestion control
• TCP 특성상 network에 부하가 있으면 더욱 성능이 악화됨
  • 재전송으로 인해 network 부하가 더 커짐
  • network 상황에 따라 데이터 전송 속도를 늘리거나 줄인다

네트워크 상황을 판단하는 방법

• network assisted congestion control: 네트워크가 상황을 알려주는 방법
  • proposal일 뿐이고 구현 안됨. 불가능함
• end to end: ack 오는게 느리거나 안오면 network에 이상이 있다고 유추

네트워크 상황 파악을 위한 데이터 전송 phase

• slow start: 네트워크 상황 파악을 위해 처음에는 데이터를 조금씩 보내면서 feedback 확인
  • 보내는 데이터는 exponential하게 증가시킴
• additive increase: threshold를 지나서 부터는 보내는 데이터를 linear하게 증가
• multiplicative decrease: 패킷 loss가 발생하면 해당 시점의 threshold를 반으로 줄임. 이후 linear하게 증가

mss(miximum segment size)

• 처음에는 segment 1개를 보냄. 그 크기가 1mss
• 최초로 window 사이즈가 1mss로 설정됨
• ack가 오면 2배씩 증가
• 결국 네트워크 상황이 window size를 결정함

패킷 loss 탐지

다음 두 가지 상황에 따라 네트워크 상황이 다름

• timeout: 전체 네트워크에 이상이 있을 수 있는 상황이므로, 안전하게 데이터 전송을 처음부터 시작. tahoe 방법
• 3 duplicated ack: 하나의 패킷만 중복이 되었을 수 있는 상황이므로, 조금 도전적으로 패킷 증가를 감소된 threshold부터 시작. reno 방법

두 가지 패킷 loss 상황에 따라 다르게 행동함

최초의 threshold

• 설정에 따라 다름

TCP의 공정성

• 참여자가 균일하게 자원을 사용하는가?
• 결국 균일하도록 수렴한다