2. TCP와 UDP

이전 IP 프로토콜 통신의 한계(비연결성, 비신뢰성, 패킷 순서 문제)를 TCP가 해결해준다.

UDP는 해결해주진 않지만 어느정도 도움은 준다.

 

인터넷 프로토콜 스택의 4계층

애플리케이션	HTTP, FTP
전송	TCP, UDP
인터넷	IP
네트워크 인터페이스

 

TCP의 특징

연결 지향 - TCP 3 way handshake 논리 연결

데이터 전달 보증

순서 보장

 

신뢰할 수 있는 프로토콜이며, 현재는 대부분 TCP 통신을 이용한다.

 

TCP 3 way handshake란

 

 

요즘은 최적화를 하면서 3번째 ACK 메시지를 보낼 때 데이터를 함께 보내기도 한다고 한다.

 

주의해야 할 점이 있는데 이 과정은 물리적으로 연결된 게 아니라 개념적으로 연결된 것이다.

'개념적으로 연결됐다'는 말의 의미
중간에 노드들이 실제로 연결됐는지는 알 수 없지만 아무튼 클라이언트와 서버는 연결됐다고 치자는 논리적 연결 개념
"물리적인 선이나 회선 연결이 아니라 서로 통신할 수 있는 상태가 되었음을 양쪽이 확인했다"는 의미이다.
클라이언트가 서버가 직접 물리적으로 연결된 게 아니더라도, 중간에 라우터, 스위치, 방화벽, 중계 노드 등 여러 장비를 거치더라도 TCP 계층에서 "우리 서로 보낸 걸 받았구나"를 확인했으니 이제 신뢰성 있게 통신하자고 합의를 한 상태

 

 

데이터 전달 보증

클라이언트가 데이터를 전송하면 서버는 데이터를 잘 받음을 알리는 패킷을 전송한다.

 

순서 보장

클라이언트가 패킷1, 패킷2, 패킷3 순서로 전송했을 때

서버가 패킷1, 패킷3, 패킷2 순서로 도착한다면,

서버가 클라이언트에게 틀어진 순서, 이 예시에서는 패킷2부터 다시 보내라는 패킷을 전송한다.

이건 서버에서 최적화하는 로직에 따라 다를 수 있다.

 

UDP 특징

기능이 거의 없다. (주로 하얀 도화지에 비유됨)

 

연결 지향 - TCP 3 way handshake X

데이터 전달 보증 X

순서 보장 X

 

>>데이터 전달 및 순서가 보장되진 않지만, 단순하고 빠르다는 장점이 있다.

 

그냥 IP 통신과 거의 같지만, PORT + 체크섬 정도만 추가됨.

애플리케이션에서 추가 작업이 필요하다.

체크섬 : 내가 보낸 메시지가 맞는지 체크해주는 데이터

 

그런데도 사용하는 이유

TCP의 경우

1. 3 way handshake 오래 걸림

2. tcp 세그먼트 데이터 용량 추가

3. 이미 너무 표준화 돼있어서 내가 더 최적화 할 수 없음

 

UDP는 저런 부분에서는 강점이 있음.