TCP/IP Network 기본

TCP/IP Network

OSI 7-Layer 란 ?

Application : HTTP GET 생성

Presentation : HTTP Parsing

Session : SSL or Security

Transport : Message Reliability

Network : Network IP

Data Link : Frame Header Trailer

Physical : Real Medium

TCP/IP Protocol Suite 및 그에 따른 데이터 단위

OSI 7 계층은 아주 잘 추상화 되어있긴 하지만, 실제 적용하기에는 무리가 있으며 아래의 4계층 정도로 실용화 되어있다고 한다.

그리고 TCP/IP Protocol Suite 라고 말하고, 전체 네트웍 스택을 의미한다.

Application : APDU (Application Protocol Data Unit)

Transport (TCP/UDP) : TPDU (Segment), TCP 헤더가 추가된다.

Network (IP) : Datagram : IP 헤더가 추가된다.

Link/ Physical : Frame / Packet

Encapsulation 이란 ?

위에서 보이듯이 TCP Payload 에 TCP Header 가 추가되어서 TCP Segment 가 생성되고

다시 IP Header 가 추가되어서 IP Datagram 으로 되고 이렇게 그 상위 계층의 데이터를 감싸는 것을 의미한다.

Acknowledgement Mechanism

1. Cumulative ACK : packet loss 가 발생하였고, 중복 수신된 ACK가 있다면, loss packet의 재전송 이후 해당 ACK를 받았다면, 수신된 모든 데이터에 대한 ACK로 간주
2. ACK-only segment and Piggybacking : dummy packet 즉, data body가 필요없고, ACK만 필요한 packet. 이러한 경우를 piggybacking 이라 한다.
3. Delayed ACK : ACK 도 또 하나의 네트워 트래픽을 유발하는 요소라고 판단, 대략 500msec 정도 delay 후에 모든 수신 packet의 ACK을 보내지 않고 일부만 전송
4. Duplicate ACK : 미 수신된 데이터를 송신측에 알리기 위해서 수신 못 받은 sequence의 ACK을 중복해서 전송하는 것을 의미

Retransmission Mechanism

1. Retransmission Timer : 기본적으로 정해진 재전송 타이머 안에 다음 데이터가 오지 않으면, 전송실패로 인지함
2. Estimation of RTT : Round-Trip-Time 즉 송신 후 ACK 수신까지 걸리는 시간이 유일한 재전송 메커니즘의 척도
3. Granlarity of RTO : Retransmission Time-Out 즉, 재전송 타임아웃을 어떻게 설정하는 지가 가장 중요

EWMA (Exponentially Weighted Moving Average)

ERTT = (1 - alpha) ERTT + (alpha) * SRTT

흔히 alpha 를 7/8 로 잡는데 즉, 과거의 평균치는 7/8정도의 가중치로 현재의 측정치는 1/8정도의 가중치를 둔다.

RTO (Retransmission Time Out) 구하기

RTO = ERTT + 4 * deviation

deviation = (1 - alpha) * dev + (alpha) * | SRTT - ERTT |

안정화 되면 절대값이 0에 가깝고 dev 가 감소하는 현상을 보인다.

TCP 와 UDP 의 차이점

Connection-oriented << ====== >> Connection-less

Stream-oriented << ====== >> Datagram-oriented

Reliable << ====== >> Unreliable

Flow-control << ====== >> No flow-control

Congestion-control << ====== >> No congestion-control

TCP Header 와 TCP 서비스의 특징

TCP 서비스의 특징

1. Connection-oriented : 실제 데이터를 전송 전에 syn packet (synchronizing) 을 통해서 연결되어야만 송수신이 가능하다.
2. Streaming : 데이터의 전송단위는 바이트이며, byte-oriented streaming 송수신이다.
3. Full-duplex : 송신과 수신을 동시에 할 수 있다
4. Reliable : 송신한 데이터에 대한 ACK (acknowledgement)를 통해 확인이 가능하다
5. End-to-end semantic : 중간 라우터나 네트워크를 고려하지 않고, 말단 노드간의 전송을 지향한다. (using congestion/flow control)

UDP Header 와 UDP 서비스의 특징

UDP 서비스의 특징

1. Connection-less
2. Datagram-oriented
3. Unreliable
4. Applications
   1. Multiasting
   2. Network management
   3. Routing Table Update
   4. Real-time multimedia

IP Header 와 IP 서비스의 특징

IP 서비스의 특징

1. Unreliable datagram service
2. Out of order Datagrams
3. Duplicates may be received

Fragmentation and Reassembly

Fragmentation :

IP datagram이 순서가 지켜지지 않는 원인 중의 하나인데, IP datagram을 라우터 상에서 잘라서 전송하는 경우가 발생한다. 즉 링크 레이어의 페이로드보다 크기가 큰 경우에는 더 작은 TCP segment들로 쪼개서 전송하게 된다. 만일에 하나의 프래그먼트가 유실되면 전체 IP datagram 은 버려진다. 결구 TCP time-out 이 발생하고 전체 TCP segment는 재전송될 것이다.

Reassembly :

이러한 Fragmented 된 segment를 받은 경우 해당 IP header의 flag 정보를 통해서 fragment 되었다는 사실을 알게되고 다시 수신 측에서 reassemble 하게 된다.

fragmentation & reassembly는 g/w 또는 router 가 이러한 작업을 할 수도 있지만 병목현상이 발생할 수 있으므로 미리 해두는 것이 좋다.

Congestion 이란 ? 그리고 언제 발생하나 ?

사전적인 의미는 폭주, 과밀, 정체 등의 의미이며, 네트워크를 큰 파이프로 생각한다면, 그러한 파이프가 꽉 들어차서 병목현상이 발생하는 상태라고 생각한다.

이러한 Congestion 상태는 두 가지의 경우에 발생할 수 있는데

1. 굵은 PIPE에서 가는 PIPE로 이동하는 경우 ( LAN 환경에서 WAN 환경으로 옮겨가는 부근)
2. 네트워크 상의 물리적인 전송량이 늘어서 허브나 라우터에서 허용한 용량이 초과한 경우

이와 같이 단순히 end-to-end 간의 flow-control 만으로는 해결하기 힘든 문제를 TCP 서비스 상에서는 고려하고 있다. 이에 비해서 UDP를 보면 정말 무식한 놈 ... 이라는 생각이 드는 것이 당연할 지도 모르겠다.

Flow-Control 이란 ?

목적 : TCP Receiver 의 buffer overflow 를 막기 위한 것 ( 상대방 end 의 트래픽을 조절한다고 보아도 된다 )

방법 : TCP sender 의 전송 rate 를 조절함

기법 : Sliding Window

적용 : Advertised Window 즉 (ACK로 수신된 TCP Header의 Receiver Window Size)

Congestion-Control 이란 ?

목적 : Routers 의 buffer overflow 를 막기 위한 것 ( 즉, 네트워크 상의 트래픽을 조절한다고 보아도 된다 )

방법 : TCP sender의 전송 rate를 조절함

기법 : Slow-Start / Congestion Avoidance / Additive Increase Multiplicative Decrease (AIMD)

적용 : 송신시에 알리는 MSS (Maximu Segment Size) 및 기타 커널에서 관리하는 cwnd 값

Loss-based Congestion-control & Delay-based Congestion-control

TCP Tahoe, Renoe, New Renoe 와 같이 지속적으로 window size 를 늘려서 손실을 발생시키도록 하여 적절한 전송 rate 를 찾아내는 방식을 loss-based cc 라고 하고

그와는 다르게 대기 시간을 기준으로 판단하는 TCP Vegas와 같은 방식을 delay-based cc라고 한다.

Congestion Avoidance Only (Slow-start, Congestion-avoidance)

TCP Slow-Start : 수신된 ACK 수 만큼 증가시켜 패킷을 전송하는 단계이며, 네트워크가 원활 한 경우에는 결과적으로 지수승으로 증가하는 것 처럼 보인다.

또한 이렇게 현재의 Window Size * 2 만큼 증가하므로 ssthresh 값을 그의 절반인 값으로 설정하는 것도 어느정도 이해가 간다.

자료를 확인한 결과 유실되기 이전의 마지막 cwnd 값을 ssthresh 값으로 저장하게 되므로, 다음 cwnd 값이 2배로 증가하게 되어있었으므로 마치 1/2으로 줄어드는 것으로 생각할 수 있다.

Congestion-Avoidance : 현재 cwnd 크기가 ssthresh값에 도달하게 되면 cwnd 값을 지수승으로 증가시키지 않고 Linear 하게 1개씩 증가시킨다.

TCP Tahoe (Fast-Retransmit, 1988 Van Jacobson - ACM SIGCOMM Congestion control and Avoidance)

WHEN Congestion ?

1. RTO (Retransmission Time Out)
2. 3 Dupacks

Slow Start Phase ( 1개의 패킷 유실 )

1. Sender 가 1~8까지 전송을 완료한 다음 (어차피 모두 송수신 버퍼를 거치므로 단계별로 체크는 힘들다) , 1 번이 loss라고 가정함.
   [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]
2. Duplicate ACK을 버퍼에서 하나씩 체크하면서 2~4번 Dup-ACK 체크 시점에서 Fast-Retransmit [ 1 ]을 한다.
   window size = 8, ssthresh = 4, cwnd = 1 (default)
3. 현재 정상 ACK은 하나도 없고 cwnd는 1이므로 더 이상 전송이 불가능하다.
4. 마침 [ 1 ]에 대한 ACK을 수신하였다면 SS 단계이므로 2 개를 더 전송할 수 있게 된다. 여기서 8개를 전송하고 Dup-ACK 7개를 받았으므로 다른 패킷은 정상전송이라고 Cumulative-ACK을 적용할 수가 있으며 [ 9 ] [ 10 ] 을 전송할 수 있다.
   windowSize (8), ssthresh (4), cwnd (1+1)
   [ 9 ] [ 10 ]
5. 해당 [ 9] [ 10 ] 번의 ACK을 정상 수신하면서 4개를 더 전송할 수 있게 된다.
   windowSize (8), ssthresh (4), cwnd (2 + 2)
   [ 11 ] [ 12 ] [ 13 ] [ 14 ]

Congestion Avoidance Phase ( 1개의 패킷 유실 )

1. 전송 후에 ACK을 하나라도 받게되면 이제는 ssthresh 값을 cwnd 값이 초과하므로 CA단계로 옮겨지면서 cwnd 값도 1개씩 증가한다.
   windowSize (8), ssthreash (4), cwnd (4 + 1)
   [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ]

Tips

가장 오해하기 쉬운 부분이 SS 단계에서 windowSize가 8인데 더 보낼 수 있지 않냐고 생각할 수 있는데, 이는 잘못 생각하고 있는 것이며, flow-control 만을 고려할 것이 아니라 congestion-control 즉, 네트웍 상의 트래픽을 고려해야 하므로 windowSize 와 ssthresh 값 중에서 작은 것을 선택하여 전송하는 것이 맞다.

---

Slow Start Phase ( 2개의 패킷 유실 )

1. Sender 가 1~8까지 전송을 완료한 다음 (어차피 모두 송수신 버퍼를 거치므로 단계별로 체크는 힘들다) , [ 1 ] [ 3 ] 번이 loss라고 가정함.
   [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]
2. Duplicate ACK을 버퍼에서 하나씩 체크하면서 2, 4, 5번에 대한 Dup-ACK 체크 시점에서 Fast-Retransmit [ 1 ]을 한다.
   window size = 8, ssthresh = 4, cwnd = 1 (default)
3. [ 1 ]번에 대한 ACK을 받게되었으나, 8개 보내고 총 6개의 Duplicate ACK을 받았으므로 전송측에서는 어디서 loss가 발생하였는지 정확히 판단할 수는 없다.
   ssthresh (4), cwnd (1+1)
4. 내 생각으로는 [ 2 ]~ [ 8 ] 어느 것이 유실되었는지 모르므로, 어떤 패킷을 재전송 해야하는지도 모른다. 결국 RTO가 발생할 때까지 기다리는 방법밖에는 없을 것이다. 그렇다면 ssthresh 값은 절반으로 줄게되고, cwnd 값은 1로 떨어진다. 단, 여기서 RTO의 의미는 congestion 이 발생했다고 받아들이면 될 것 같다.ssthresh (4/2), cwnd (1)
   [ 3 ]
5. 다시 처음부터 SS 단계로 접근하여 진행하면 된다..

Question

다른 자료에서도 TCP Tahoe에서는 Multiple-packet-loss에 대해서는 언급하지않는다고 되어있고 [ 4 ]번 단계에서 RTO를 발생시키는 것이 맞는지 정확하게 판단이 서지 않는다.

TCP Reno (Fast-Recovery, 1990)

WHEN Congestion ?

1. RTO (Retransmission Time Out)
2. 3 Dupacks
3. Stopping flow of moving packet and acks

지속적으로 acks 계속 받는 다는 것은 한개 정도의 loss가 발생하여도 congestion은 아닐 것이라는 것을 가정한 것 같다 그래서 Fast-Recovery 단계에서 cwnd 의 크기를 조절할 때에 ssthresh + Dupacks 값으로 설정하여 빨리 복구하는 접근을 한다. 단, Partial-Ack를 사용하지 못하므로 Multiple-packet-loss 에서는 TCP Tahoe와 큰 차이가 없다는 점은 유의해야만 한다.

Slow Start Phase ( 1개의 패킷 유실 )

1. Sender 가 1~8까지 전송을 완료한 다음 (어차피 모두 송수신 버퍼를 거치므로 단계별로 체크는 힘들다) , 1 번이 loss라고 가정함.
   [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]
2. Duplicate ACK을 버퍼에서 하나씩 체크하면서 2~4번 Dup-ACK 체크 시점에서 Fast-Retransmit [ 1 ]을 하고, Fast-Recovery 단계로 이동한다
   window size = 8, ssthresh = 4, cwnd = 1 (default)

Fast Recovery Phase ( ssthresh = cwnd / 2, cwnd = ssthresh +3Dupacks )

1. Recovi[ 2 ] [ 3 ] [ 4 ] Dupacks를 받은 시점에서도 받았다는 것 자체가 네트워크 상태가 그리 나쁘지 않다는 의미이므로, 해당 Dupacks를 의미있게 받아들여서 FastRecovery를 시도한다. 그리고 초기의 Fast-Retransmission에 대한 ACKs를 다 받게 되면 Fast-Recovery-Phase 가 종료되므로 CA로 이동
   ssthresh (4), cwnd (4+3)
   [ 9 ] [ 10 ] [ 11 ]

Congestion Avoidance Phase ( cwnd = ssthresh )

1. 여기서는 다시 cwnd값을 ssthresh와 일치시키므로 [ 9 ] ~ [ 11 ]에 대한 ACK을 받기 전이므로 [ 12 ]만 보낼 수 있다.
   ssthresh (4), cwnd (4)
   [ 12 ]

Tips

다시 생각해보니 이 부분도 좀 이상하다고 생각되며, TCP Reno의 장점은 Dup-ACK이 3개 발생되는 시점부터 Congestion Avoidance 단계로 이동하는 과정을 눈에 띄이게 향상시켰다는 점이 장점인 것 같다. 특히 패킷이 하나만 유실되었을 경우에만 그 차이를 확실히 알 수 있었다.

결국 Fast Recovery Phase 로 갈 수 있게되는 근거는 버퍼에서 해당 Dup-ACK 갯수를 파악하여 Single-Packet Loss임을 알기 때문에 FR이지 Multiple-packet-loss의 경우에는 TCP Tahoe와 별반 다를 바가 없다.

---

Slow Start Phase ( 2개의 패킷 유실 )

1. Sender 가 1~8까지 전송을 완료한 다음 (어차피 모두 송수신 버퍼를 거치므로 단계별로 체크는 힘들다) , [ 1 ] [ 3 ] 번이 loss라고 가정함.
   [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]
2. Duplicate ACK을 버퍼에서 하나씩 체크하면서 2, 4, 5번에 대한 Dup-ACK 체크 시점에서 Fast-Retransmit [ 1 ]을 하고, 수신된 Dup-ACK가 6개이므로 FR단계로 이동하지 못하고 SS 단계가 유지된다. TCP Tahoe와 동일하다.
   window size = 8, ssthresh = 4, cwnd = 1 (default)
3. Duplicate ACK을 버퍼에서 하나씩 체크하면서 2, 4, 5번에 대한 Dup-ACK 체크 시점에서 Fast-Retransmit [ 1 ]을 한다.
   window size = 8, ssthresh = 4, cwnd = 1 (default)
4. [ 1 ]번에 대한 ACK을 받게되었으나, 8개 보내고 총 6개의 Duplicate ACK을 받았으므로 전송측에서는 어디서 loss가 발생하였는지 정확히 판단할 수는 없다.
   ssthresh (4), cwnd (1+1)
5. 내 생각으로는 [ 2 ] 이 유실되었을 수도 있으므로 여기서는 [ 2 ] [ 3 ] 을 재 전송할 것이며, 해당 ACK을 기다릴 것 같다. 즉 이전의 Dup-ACK은 의미가 없을 수 있다 [ 2 ] ~ [ 8 ] 번 사이에서 어떤 패킷이 유실되었는지 알 수 없으므로 전부 재전송 하는 방법 외에는 없을 것으로 생각된다.
   ssthresh (4), cwnd (2)
6. 해당 [ 2 ] [ 3 ]에 대한 ACK이 도착하게되면 다시 Slow-Start와 동일한 상황이 발생하고
   ssthresh (4), cwnd (2+2)

Congestion Avoidance Phase ( 2개의 패킷 유실 )

1. [ 4 ] [ 5 ] [ 6 ] [ 7 ] 을 재 전송하게되고 ACK을 받는데, ssthresh를 초과하여 CA단계로 넘어간다.
   ssthresh (4), cwnd (4+1)
2. [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] 를 전송하게 되고 계속 진행된다

TCP New Reno (Multiple Packet-Loss)

WHAT TO USE ?

1. Partial Acknowledgement

TCP SACK (Selective ACK)