* 역할 : Source -> Destination 까지 전송. 메시지를 일정한 크기로 자르고 관리
○ UDP (User Datagram Protocol)
1. 특징
- Unreliable data transfer : 전송이 loss 될 수 있다. 신뢰성 없는 전달
- No coneection establishment
- Simple connection state -> small header size. 매우 단순한 구조
- no congestion control
- error check
2. 왜, 어디에 쓰일까?
왜 쓸까? : UDP는 TCP와 달리 보장된 전달도 아니고, loss가 될 수도 있으며 간단히 생각하면 TCP에서 신뢰성 같은 기능을 모두 없는 프로토콜이지만 계속 꾸준히 쓰이는 이유는 cost가 싸기 때문이다. TCP는 여러 신뢰성을 넣은 만큼 무겁기 때문에 매우 심플하고 빠른 응답에 UDP가 주로 쓰인다.
어디에 쓰일까? : 스트리밍, 영상, VoIP, 게임-서버 클라이언트 통신, DNS 등등 빠른 응답, 비록 loss가 생기더라도 그렇게 데미지가 크지 않는 경우 주로 사용된다.
○ TCP
1. 특징
- reliable transfer : 신뢰성있는 전달.
- flow controlled
- congestion control
- connection - oriented
- full duplex data (전이중 전송방식. 데이터를 양방향 동시 송수신 가능한 방식)
half duplex : 양방향 하지만 한 번에 하나씩 전송만 가능한 방식 - 무전기
simplex : 단뱡항 전송 방식 - TV
2. Flow Control (흐름제어)
송신/수신측의 데이터 처리 속도 차이를 해결하기 위한 기법. 송신측 데이터 전송량 제어
i. Stop and Wait : 매번 1개씩 주거니 받거니 하는 방식.
ii. Sliding Window : 윈도우 크기를 정해서 해당 윈도우 크기만큼 패킷을 통째로 전달, ACK으로 전달 완료됐다면 창문 밀듯이 옆으로 밀면서 다음 패킷을 전달. 아래 이미지는 슬라이딩 윈도우 방식
- 3 way Handshake : TCP/IP 프로토콜을 이용해서 데이터 전송을 하기 전에 클라이언트, 서버가 정확한 전송을 보장하기 위해 세션을 수립하는 첫 3번의 과정. TCP SYN로 접속 요청 패킷을 보내고, SYN ACK으로 수락을 받는다. 이 2개는 data 없이 헤더만 전달. 이후 3번째부터는 연결이 이루어지고 Data를 포함해서 통신 시작
- 4 way Handshake : 세션을 종료하기 위한 절차로 클라이언트가 연결 종료 FIN 플래그를 전송하고, 서버는 ACK 한 후 통신을 끝낸다. 서버는 통신이 끝났으면 클라이언트에게 연결 종료 됐다는 FIN 플래그를 전송하고, 클라이언트도 확인 후 ACK을 돌려준다.
(클라이언트에서 세션 종료 후 뒤늦게 패킷이 도착하면 이 패킷은 유실된건데, 이를 위해 클라이언트는 서버로부터 받은 FIN을 수신해도 잠시 세션을 남겨놓고 잉여 패킷을 받는데 이걸 TIME_WAIT이라 한다.
3. Congestion Control (혼잡도 제어)
송신측의 데이터 전달, 네트워크 상의 데이터 처리 속도 차이 해결을 위한 기법. 송신측의 데이터 전송 속도 제어
*용어 : cwnd = Congestion Window. MSS = Maximum Segment Size
i. AIMD (Additive Increase Multiplicative Decrease)
loss가 발생하기 전까지 매번 윈도우 사이즈를 1MSS씩 증가하며 전송한다. loss 발생시 윈도우 크기를 절반으로 감소시키고 다시 반복한다.
ii. Slow Start
윈도우 사이즈를 매번 2배씩 지수적으로 증가시킨다. loss 발생 시 윈도우 크기를 1로 초기화한다.
Slow Start Threshold(한계점) 이상을 가면 그 후부터는 AIMD처럼 1MSS 씩만 증가한다.
iii. Fast Recovery
혼잡(loss)상태가 되면 윈도우 크기를 1로 줄이지 않고 반으로 줄인 후 선형증가시키는 방식이다.
iv. Fast Retransmit
네트워크 문제로 패킷이 다 안오는게 아닌, 중간에 한 패킷이 없어진 문제면 네트워크가 혼잡한게 아니기 때문에 빠른 복구를 위해서 없어진 패킷을 받기 위해 같은 ACK을 다른 Segment 올 때마다 반복 전달. 3번의 duplicate ACKs가 오면 클라이언트는 해당 패킷이 loss된걸로 알고 다시 보낸다. 상세는 아래 정책에서 작성한다.
4. TCP Congestion Control 정책
# TCP Reno와 Tahoe의 차이점
loss가 발생했을 때
A. time out (패킷을 보낸 후 Timer로 일정 시간 이상 지났는데도 아무 반응이 없는 경우) > 네트워크 자체가 혼잡한 경우
B. 3 dup Acks > 네트워크는 괜찮지만 특정 패킷이 loss된 경우를
Taeho는 차이를 두지 않고, Reno는 차이를 두는 경우다.
ssthresh 까지는 slow start로 윈도우 사이즈가 증가하고, 그 이후부터는 AIMD와 같이 1MSS 씩 윈도우 사이즈가 증가한다.
그렇게 계속 증가하던 와중 loss가 발생한다면loss에 따라
time out으로 네트워크 자체가 혼잡한 경우 ssthresh를 현재 윈도우 사이즈의 절반으로, 그리고 윈도우 사이즈를 1로 초기화한다.
3 dup ACKs로 해당 패킷이 계속 loss된거면 윈도우 사이즈도 ssthresh도 loss 발생 당시 윈도우 사이즈의 절반으로 한다.
5. SImple TCP Protocol 아이디어
reliable data transfer, Feedback(ACK, NACK), error, loss감지(Timer) 등은 PDF 참고
'강의 > 컴퓨터네트워크' 카테고리의 다른 글
Link Layer (1) | 2023.12.29 |
---|---|
Network Layer (0) | 2023.12.28 |
컴퓨터 네트워크 - Transport Layer (2) | 2023.08.29 |
컴퓨터네트워크 - Application Layer (0) | 2023.06.28 |
Application Layer - 시험 요약 정리 (0) | 2023.04.20 |