컴퓨터 네트워크 - TCP(Transmission Control Protocol)

K-MOOC에서 부산대학교 유영환 교수님의 “컴퓨터 네트워킹” 강의를 수강하며 적은 노트

Transmission Control Protocol

TCP(Transmission Control Protocol)

• connection-oriented service: 송신자와 수신자 사이 커넥션이 먼저 설립되어야 함
  • point-to-point, 1:1 방식의 통신
  • full-duplex, bi-directional: 양방향성의 연결
  • handshaking mechanism: 연결에 할당되는 자원의 양 등 결정
• pipelined transmission 사용, go-back-N과 selective repeat의 혼합
• sliding window: 한 번에 보낼 수 있는 데이터 양이 동적으로 조절
  • ACK 없이도 congestion control, flow control에 따라 조절
• MSS(maximum segment size): 연결에서 보낼 수 있는 segment의 최대 사이즈

TCP 헤더

• 20 byte, word가 5개
• source port 16 bit, destination port 16 bit
• sequence number: 32 bit, 항상 0부터 시작하는 건 아님, 커넥션 연결 시 시작과 끝 번호 지정
• acknowledgement number: 32 bit, 다음 받아야 할 시퀀스 넘버
  • ex) segment에 1000 byte 들었다 가정
    • 만약 첫 번째 segment를 받음(n부터 n+999까지)
    • 그 다음 받아야 될 내용은 n+1000 = acknowledgment number
    • 즉 cumulative ACK의 역할
    • 만약 1, 2번 세그먼트를 동시에 받았다면 하나의 ACK인 n+2000만 보냄
  • 처음 송신자가 보낼 때는 비울 것이지만 노이즈 등으로 이상한 값으로 인식될 수 있음, 따라서 flag에 ACK bit 체크
• data offset: UDP의 전체 길이를 의미하는 length와 달리 TCP는 기본 헤더 20 byte에 추가 정보가 붙을 수 있으므로 데이터의 시작 위치를 알려줌, 즉 header length
• res(reserve): 혹시 추가로 담을 정보가 있으면 거기 담음, 없으면 비워 둠
• flag: data offset + res + flag = 16 bit
  • urgent, ACK, Push, Push, Reset, synchronization, Finale 1 bit 씩
  • synchronization: 클라이언트가 서버에 요청 시 1, 그 후 서버도 시퀀스 넘버를 담고 1, 그 후 클라이언트도 거기에 응답 보냄. 따라서 three-way handshake
  • Finale: 연결을 끊을 때 1
  • Reset: SYN으로 연결을 수립할 때 해당 포트에 프로세스가 없다면 1
• window size(receive window): 16 bit, flow control
  • receiver가 수용 가능한 버퍼를 넘어서 계속 전송하는 것을 막음
  • 수신 버퍼에 남아 있는 크기를 receive window에 적어 보냄
  • 수신 버퍼는 보통 4096 byte(4 kB)
• Header checksum: UDP와 동일
• urgent pointer: 혹시 다른 파일을 잘못 보냈거나 하면 전송을 중단해야 하듯, 긴급한 명령을 전달. urgent data의 위치를 알려줌, 요즘 거의 사용하지 않음

신뢰성 있는 통신

• TCP는 cumulative ack와 single retransmission timer를 쓰지만 go-Back-N과는 달리 패킷을 버리지 않음
• 패킷에 에러가 있으면 버리고 ACK 전송하지 않음
• retransmission scenario
  1. A가 sequence number 92번의 8 byte의 데이터를 보냄
  2. B가 응답으로 100번을 요구했는데 해당 ACK 사라짐
  3. A는 재전송, B는 같은 데이터니까 버리고 ACK만 재전송
• 타임아웃이 짧은 경우
  1. A가 세그먼트 2개 동시에 보냄, 92번 8 byte와 100번 20 byte
  2. B가 ACK100, ACK120 전송했는데 타임아웃이 짧아 모두 재전송
  3. B는 다시 ACK120만 보냄

타임아웃은 A와 B사이에 Round Trip Time보다 길게 해야 하지만, 처음 연결 수립 시에는 RTT를 알 수 없고, 네트워크 변동에 의해 RTT가 계속 바뀜

• TimeoutInterval: EstimatedRTT(RTT 추정값)을 결정하여 이것으로 인터벌 결정
  • 데이터를 보내면서 지속적 관찰로 sampleRTT를 측정
  • sampleRTT는 계속 변할 수 있으므로 estimatedRTT도 계속 업데이트
  • 이전의 추정값에 가중치, 새로 측정값에 가중치를 둬 이를 합산
  • RTT가 정확하지 않을 수 있으므로 safety margin을 붙임
• fast retransmit: 3개의 duplicate acks를 받으면 타임아웃 전에 재전송
  1. 세그먼트 첫 두 개를 전송, 2번째는 전송 실패
  2. 3, 4, 5번째를 전송해도 계속 ACK100을 보냄
  3. 그럼 ACK100이 3번 왔다는 말은 3, 4, 5는 잘 갔다는 말
  4. 따라서 2번째의 타임아웃이 걸리기 전이라도 2번째를 재전송

---

Congestion Control

congestion control

• congestion collapse
  • 트래픽의 양이 점점 많아지면 네트워크에서 처리할 데이터의 양도 많아지고 각각의 패킷이 겪는 지연 시간도 길어짐
  • 지연 시간이 길어져 sender에서 타임아웃이 자주 일어나고, 타임아웃이 일어나면 재전송이 또 일어나 처리해야 할 새로운 패킷이 더해져 아무것도 전달하지 못하게 됨
• point-to-point 이슈인 flow control과 달리 네트워크를 공유하는 모든 노드들의 문제
• network-assisted: 여러 개의 소스를 중간의 라우터를 거치는데, 라우터가 호스트들에게 현재 혼잡 상황을 알림, 복잡하여 잘 쓰지 않음, 대표적으로 ATM
• end-to-end: 호스트들이 보낸 데이터가 얼마나 잘 도달하는가를 관찰하여 혼잡 판단
  • 대표적으로 TCP

AIMD(Additive Increase Multiplicative Decrease) approach: 천천히 증가, 줄일 땐 절반으로

• Window size 크기를 문제가 없을 때는 천천히 1 MSS씩 증가
• 혼잡을 감지했다면 반으로 확 줄임

congestion window: 네트워크가 congestion을 일으키지 않는 한도 내에서 ACK를 받지 않은 상태로 한꺼번에 전송할 수 있는 데이터의 양

• window size는 min(congestion window, receive window)보다 작음
• 네트워크 혼잡 상황에 따라 크게 변동
• slow start: 초기값은 1 MSS, ACK 수신 후 2배씩 증가
  • congestion avoidance: slow-start의 지수적인 증가가 계속되면 또 혼잡이 바로 발생하기 때문에, 이전의 cwnd 사이즈를 기억해 그 절반을 slow-start threshold로 설정
  • 따라서 계속 2배씩 증가하다가, slow-start threshold 값이 되면 Additive Increase로 1씩 증가
  • ssthresh를 넘으면 매 RTT마다 1 MSS씩 증가

---

TCP Congestion Control Algorithm

TCP의 congestion control 종류: Tahoe, Reno, SACK, NewReno가 standard로 채택

• TCP Tahoe: 1988년에 Van Jacobson. slow start, congestion avoidance
  • fast retransmit 도입: 타임 아웃 발생 전이라도 세 개의 중복된 ACK를 받으면 congestion 메커니즘을 동작하여 congestion window size를 1로 줄임
• TCP Reno
  • fast recovery 도입: 타임 아웃과 fast retransmit을 구분
    • 타임 아웃: Tahoe와 같이 slow start
    • fast retransmit: congestion window size를 1이 아닌 절반으로 줄이고 fast recovery 단계가 되어 중복이 아닌 ACK가 도착할 때까지 사이즈를 늘리지 않고 기다림.
    • fast recovery에 들어 간 단계에서도 새로운 duplicate ACK가 올 수 있으므로, 패킷이 도착할 때마다 그만큼 congestion window를 사이즈를 유지한 채 이동
    • Tahoe보다 throughput 유리
• TCP NewReno
  • 패킷 로스는 연속적으로 발생하는 경우가 많음
    • Reno: 첫 에러 발생 시 congestion window가 반으로 줄고, 또 다음 에러가 나면 또 반으로 줄고 해서 크게 줄어 듦
  • 어떤 loss를 감지하면 그 때까지 보낸 모든 패킷에 대한 ACK가 끝나기 전까지 fast recovery를 유지
• TCP SACK(Selective ACK): 96년도 제안. individual ACK 사용
  • ex) 세그먼트 1, 2, 3, 4 보내고 2가 에러
    • 일반적 TCP: cumulative ACK로, 2, 3, 4를 다시 보냄
    • Selective ACK: ACK1을 보내고 SACK3, SACK3-4를 보내 3과 4가 도달함을 알림
  • 하나의 ACK 메시지 내에 필드를 분할해 특정 segment들에 대해서 ACK 응답 보냄

---

TCP vs. UDP

TCP: 전송의 fairness 보장

1. 초기, connection 1의 throughput은 높고, connection 2의 throughput은 낮음
2. 에러를 감지하면 connection 1과 2가 congestion window 반으로 줄임
3. 둘 다 절반씩 줄지만, connection 1은 크게 줄어들고 이후 똑같이 1씩 증가
   • ex) 초기 c1=10, c2=2
   1. (10, 2) -> (20, 4) // 혼잡 발생(24)
   2. -> (10, 2) -> (11, 3) -> (12, 4) -> … -> (16, 8) // 혼잡 발생(24)
   3. -> (8, 4) -> (9, 5) -> … // 차이가 크게 줄어듦 - UDP의 경우 congestion control없이 보내고 싶은 만큼 보냄

TCP vs. UDP

TCP	UDP
reliable transfer	서비스 guarantee X
속도 느림	속도 빠름
e-mail, web browsing, 웹 서버	VolP, Music streaming
P2P 방식으로 unicast, 1:1	다양하게 multicast, broadcast

---