신뢰성 있는 전송보다 속도를 중요하게 여기는 프로토콜
TCP보다 적은 오버헤드로 데이터를 전송할 수 있다.
-> 실시간 통신에서 유리하다.
handshake 과정 없이 바로 데이터를 보낼 수 있다.
TCP의 흐름 제어, 혼잡 제어 기능을 지원하지 않는다.
그래서 데이터를 빠르게 전달할 수 있다.TCP 헤더보다 헤더의 크기가 작다.
이는 네트워크의 트래픽을 줄인다.
데이터 신뢰성이 없다.
데이터그램(UDP의 데이터 단위)의 무결성을 확인하기 위한 메커니즘
(송신할 때)
각 데이터를 16비트로 나누고,
모두 더한 다음 1의 보수를 취한다.
이 숫자를 데이터와 같이 보낸다.
(수신할 때)
송신할 때와 같이 체크섬을 만들고
송신할 떄 보냈던 체크섬과 비교해 검증한다.무결성을 확인할 때 사용하지만, 데이터가 변조되어도 체크섬은 문제가 없을 수도 있다.
수신자에게 패킷을 보내고 확인 응답(ACK)이 올때까지 기다린 다음,
확인 응답이 온다면, 다음 패킷을 보내는 프로토콜데이터의 순서를 보장한다는 특징이 있지만,
응답이 올떄까지 기다린다는 단점이 있다.
전송한 패킷에 대한 확인 응답을 받지 않고도, 여러 개의 패킷을 연속으로 전송하는 프로토콜
전송 속도를 높인다는 장점이 있지만,
패킷 손실로 인해 순서가 어긋나면, 어긋난 패킷부터 다시 보내야 하는 오버헤드가 발생할 수 있다.
연결지향형 프로토콜이다.
(항상 데이터를 주고받기 전 먼저 연결을 하고 주고받는다)송신자와 수신자 간의 신뢰성 있는 데이터 전송을 보장해주는 프로토콜이다.
흐름 제어와 혼잡 제어 기능을 제공한다.
데이터를 주고받기 전 연결을 하는 과정
- 클라 -> 서버 (SYN 패킷 보냄)
- 서버 -> 클라 (SYN + ACK 패킷 보냄)
- 클라 -> 서버 (ACK 패킷 보냄)
TCP 연결을 해제하는 과정
- 클라 -> 서버 (FIN 패킷 보냄)
- 서버 -> 클라 (ACK 패킷 보냄)
... (못 받은 패킷들을 받기 위해 잠깐 기다린다)- 서버 -> 클라 (FIN 패킷 보냄)
- 클라 -> 서버 (ACK 패킷 보냄)
3개의 중복된 ACK를 수신하면 바로 재전송하는 메커니즘
서버는 순서가 올바르지 않은 세그먼트를 수신하면,
마지막으로 올바르게 수신된 세그먼트의 ACK를 클라이언트에게 송신한다.
이를 이용해 클라이언트는 중복된 ACK로 세그먼트 손실을 감지할 수 있다.이는 타임아웃과 관계없이 동작하므로 빠르다고 할 수 있다.
(타임아웃을 이용한 재전송은 타임아웃이 될떄까지 재전송을 하지 않아 느리다는 단점이 있다)
수신자측 버퍼에서 오버플로우가 발생하지 않도록,
송신자의 데이터 전송 속도를 제어하는 메커니즘수신자는 ACK를 보낼 때, 수신 버퍼의 남은 사이즈를 알려준다.
송신자는 이를 보고 데이터 전송 속도를 조절한다.
네트워크 혼잡을 줄이기 위해,
송신자의 데이터 전송 속도를 제어하는 메커니즘두가지 방식이 있다.
(Additive Increase, Multiplicative Decrease)
송신자 측 버퍼를 매 RTT마다 1 MSS 씩 늘리는데,
만약 패킷 손실이 발생하면 버퍼 사이즈를 절반으로 줄인다.(Slow Start)
매 RTT 마다 송신자 측 버퍼를 두배씩 늘린다.
버퍼 사이즈가 임계값(OS가 설정)보다 커지면, 매 RTT 마다 버퍼를 1 MSS 씩 늘린다.
만약 패킷 손실이 발생하면, 임계값을 절반으로 줄이고 버파 사이즈를 초기화한다.