[Transport layer - TCP, UDP] in TCP/IP 4 layer

TCP (Transmission Control Protocol)

 

신뢰성

흐름 제어

 

흐름 제어란?

송신자와 수신의 데이터 속도가 다를 수 있기에,

송신자의 데이터 송신 속도를 제어하여, 수신자가 받을 수 있을 만큼의 데이터만 효율적으로 전송함으로써

수신의 Overflow를 방지하는 것입니다.

 

다음과 같은 방식들로 구현될 수 있습니다.

 

1. Stop & Wait

 

.

 

2. Sliding Window

 

Stop & Wait 방식을 거의 병렬적, 독립적으로, 동시에 여러개를 하는 것? 이건 저만의 생각입니다.

 

sliding window란, 수신자가 수신 가능한 크기 (= Window size) 내에서 패킷을 연속으로 전송함으로써 (ACK를 기다리지 않고), Stop & Wait에 비하여 효율을 크게 높인 것입니다.

 

사진 출처: https://intronetworks.cs.luc.edu/1/html/slidingwindows.html

 

사진의 맨 왼쪽은 Stop & Wait 방식이고, 중간과 맨 오른쪽은 서로 다른 Window 크기의 Sliding Window 방식입니다.

Sliding Window 방식을 통해 효율이 좋아졌음을 확인할 수 있습니다.

 

Window size가 4인 경우를 예로 들어 설명하겠습니다.

현재 송신자는 Window가 패킷0 ~ 패킷3 범위이고,
이 4개의 패킷을 연속으로 쭉 보냅니다.

조금 이따가 수신자로부터 ACK0가 오면,
송신자는 Window가 패킷1 ~ 패킷4 범위로 옮겨가고 (오른쪽으로 한 칸 Slide),
이제 패킷4를 보냅니다.

이번에는 수신자로부터 ACK1가 오면,
송신자는 Window가 패킷2 ~ 패킷5 범위로 옮겨가고 (오른쪽으로 한 칸 Slide),
이제 패킷5를 보냅니다.

 

위와 같은 과정 동안의 Window는 다음과 같은 형태를 띨 것입니다. 

 

사진 출처: http://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo-6.htm

 

 

이 방식에서는 오류 발생 시 자칫하면 여러 패킷이 뒤섞여 통신이 혼란을 겪을 수 있기 때문에, 발생 가능한 오류를 제어하는 방식이 다음과 같이 존재합니다.

 

2.1. GBN(Go-Back-N)

 

패킷 loss가 일어나면, 그 패킷부터 전부 다시 전송하는 방식입니다.

 

위 그림처럼, pkt2가 전송 도중에 loss되었다 칩시다.

수신자는 "pkt2를 건너뛰고" pkt3을 받았기에 "엇, loss가 있군"을 인지할 수 있으므로,
pkt3은 버리고, 
다시 ack1을 보냄으로써, 송신자에게 "나 pkt1까지만 제대로 받았어!"를 말합니다.
(이후 수신는 패킷을 받을때마다, 이것을 그냥 버리고, 여전히 마지막 ack인 ack1을 보냅니다.)

그럼,
송신자는 ack0, ack1까지는 문제 없이 받고, (또다시 받은 ack1은 무시합니다,)
ack2가 올 시간이 지나도 오지 않자 (당연합니다, 수신자가 pkt2를 제대로 못 받았으니 ack2도 보내지 않았겠지요),
pkt2부터 ~ 마지막으로 송신했던 pkt5까지 를 다시 연속으로 송신합니다.
여기서 주목할 것은, pk3~pk5는 문제가 없었던 패킷들임에도 불구하고 (pkt3은 실제로 전달되었고, pkt4와 5는 아직 timeout이 일어나지 않았습니다.) 또다시 보내야 한다는 점입니다. 비효율적이지요.

 

 

 

2.2. SR(Selective Repeat)

 

위 방식의 문제점을 해결한 것입니다.

패킷 loss가 일어나면, loss된 그 해당 패킷만 다시 보내는 방식입니다.

 

 

위 그림처럼, pkt2가 전송 도중에 loss되었다 칩시다.

수신자는 "pkt2를 건너뛰고" pkt3을 받았기에 "엇, loss가 있군"을 인지할 수 있으므로,
pkt3은 일단 buffer에 저장해두고,
ack3을 보냄으로써, 송신자에게 "나 pkt2는 건너뛰고 pkt3은 잘 받았어!"를 말합니다.
(이후 수신는 패킷을 받을때마다, 이것을 우선 buffer에 저장해두고, 그 패킷에 알맞는 ack를 보냅니다.)

그럼,
송신자는 ack0, ack1까지는 문제 없이 받고, 
ack3은 일단 기록해두고,
ack2가 올 시간이 지나도 오지 않자 (당연합니다, 수신자가 pkt2를 제대로 못 받았으니 ack2도 보내지 않았겠지요),
pkt2만을 다시 송신합니다.
문제가 있었던 패킷만을 재전송하는 겁니다 (ack3을 보아하니 pkt3은 잘 보내졌음을 알 수 있고, pkt4와 5는 아직 timeout이 되지 않았으니, pkt3~5는 문제가 없습니다). 훨씬 효율적이지요.

수신자는 이제, 그동안 버리지 않고 buffer에 모아뒀던 패킷들을 처리합니다.

혼잡 제어

 

.

TCP 연결의 초기화

 

3-way handshake

장치들 간 가상 연결을 establish하기 위함입니다.

 

 

사진 출처: https://workat.tech/core-cs/tutorial/tcp-three-way-handshake-in-computer-networks-yoo7331910lh

 

 

 

TCP 연결의 종료

 

4-way handshake

장치들 간 가상 연결을 해제하기 위함입니다.

 

 

사진 출처: https://www.geeksforgeeks.org/tcp-connection-termination/?ref=lbp

 

 

---

UDP (User Datagram Protocol)

 

UDP는 TCP의 대안이고, 여러가지 상반되는 특징들이 있습니다.

 

unreliable

 

흐름 제어 없음

패킷들은 순서가 섞여 전송될 수도 있고, 아예 loss될 수도 있습니다. 송신자는 심지어 자신이 보낸 패킷들에 대한 ACK도 받지 않으니, 오류가 있는지 없는지도 알지 못합니다. 

(↔ TCP에서는 흐름 제어가 있었습니다.)

 

혼잡 제어 없음

(↔ TCP에서는 혼잡 제어가 있었습니다.)

 

connectionless

UDP에서는 송신자와 수신자 간의 직접적 연결이 없고, 따라서 handshake같은 것도 없습니다.

(↔ TCP에서는 3-way handshake를 통해 시작되는 직접적 연결이 있었죠.)

 

 

header 구조

 

 

전체 header는 다음과 같은 구조입니다.

 

사진 출처: http://www.ktword.co.kr/test/view/view.php?no=1796

 

 

그중 UDP 실제 header에는 다음과 같은 4개의 field가 있습니다.

1) 발신 포트 번호
2) 수신 포트 번호  
3) 길이: header를 포함한 패킷 전체의 길이를 byte 단위로 표시 
4) Checksum: 전송된 데이터의 무결성을 검사하는 값. 선택 항목임 (<-> TCP에선 필수 항목)

 

 

여기서 Checksum은 다음과 같은 순서로 계산합니다.

모든 field (그림 상에서 - 발신 IP 주소, 수신 IP 주소, 모두 zero, 프로토콜 ID, UDP 길이, UDP 실제 헤더(내의 발신 포트 번호, 수신 포트 번호, 길이), 데이터, zero padding)의 값을 word(= 4개의 4 bit) 단위로 모두 더합니다.
eg) f12c, 00a1, 0002, ...와 같은 값들을 모두 더해줌

이 결과가 만약 1 word보다 넘쳐 carry bit가 발생했다면 이 값을 더해줍니다.
eg) 위 결과가 0x1d230라면, 0xd230 + 0x0001 = 0xd231

이것의 1의 보수를 구해주면 이것이 최종 Checksum입니다.
eg)  0xd231 = 1101 0010 0011 0001이므로, 이것의 1의 보수인 0010 1101 1100 1110이 최종 Checksum 값이 됩니다.

 

 

장단점과 활용

 

 

TCP와 달리 흐름 제어 / 혼잡 제어가 없으므로,

정확성은 떨어지지만, 대신 속도가 빠르고 효율적이며 네트워크 부하가 덜합니다.

 

따라서, "loss가 발생해도 되지만, 대신에 속도는 빨라야 하는" 통신 상황에서 유용하게 사용됩니다.

eg) VoIP, DNS Lookup, streaming video, live broadcast, ...