인터넷 상에서 데이터를 메시지 형태로 보내기 위해 IP와 함께 사용하는 프로토콜
패킷을 추적 및 관리
연결 지향 방식
흐름 제어 및 혼잡 제어
높은 신뢰성 보장
UDP보다 속도가 느림
전이중(Full-Duplex), 점대점(Point to Point) 방식
TCP는 연속성보다
신뢰성
있는 전송이 중요할 때 사용하는 프로토콜로, 파일 전송과 같은 경우에 사용된다.
3-way handshaking
과정을 통해 연결을 설정하고 4-way handshaking
을 통해 해제한다.
3-way handshaking
: 목적지와 수신지를 확실히 하여 정확한 전송을 보장하기 위해서 세션을 수립하는 과정을 의미서버 소켓은 연결만을 담당한다.
연결 과정에서 반환된 클라이언트 소켓은 데이터의 송수신에 사용된다.
서버와 클라이언트는 1대1로 연결
된다.
스트림 전송으로 전송 데이터의 크기가 무제한이다.
패킷에 대한 응답을 해야하기 때문에(시간 지연, CPU 소모) 성능이 낮다.
데이터가 손실된 경우 재전송 요청
을 하기 때문에 Streaming 서비스 등에 불리하다.
데이터는 패킷(Packet) 단위로 나뉘어 같은 목적지(IP계층)으로 전송된다. 이때 TCP는 데이터가 손실된 경우 재요청을 하며, 이를 위해서는 패킷을 추적해야 한다.
패킷(Packet)
: 인터넷에서 데이터를 전송할 때 효율적인 라우팅을 위해 데이터를 여러 개의 조각(패킷) 으로 나누어 전송한다.
즉, 데이터는 패킷 단위로 나뉘어 전송되고, 이때 각 패킷을 구분할 수 있는 식별자를 부여하고, 목적지에 도착하면 식별자를 통해 모든 패킷이 정상적으로 전송되었는지 확인하는 방식을 통해 패킷을 추적/관리한다.
데이터를 데이터그램 단위로 처리하는
비연결형 프로토콜
UDP 프로토콜에서 각각의 패킷은 다른 경로로 전송되고, 각각의 패킷은 독립적인 관계
를 지니게 되는데 이렇게 데이터를 서로 다른 경로로 독립적으로 처리하게 된다.
비연결형(connectionless) 서비스로 데이터그램 방식
을 제공한다
정보를 주고 받을 때 정보를 보내거나 받는다는 신호 절차를 거치지 않는다.
UDP 헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
신뢰성이 낮다
TCP보다 속도가 빠르다
UDP는 비연결형 서비스
이기 때문에, 연결을 설정하고 해제하는 과정이 존재하지 않는다. 서로 다른 경로로 독립적으로 처리함에도 패킷에 순서를 부여하여 재조립을 하거나, 흐름 제어 또는 혼잡 제어와 같은 기능도 처리하지 않기에 TCP보다 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만 신뢰성있는 데이터의 전송을 보장하지는 못한다는 단점이 존재한다.
따라서 신뢰성보다는 연속성이 중요한 실시간 서비스(streaming)에 자주 사용
된다.
UDP에는 연결 자체가 없어서(connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없다.
소켓 대신 IP를 기반으로 데이터를 전송한다.
서버와 클라이언트는 1대1
, 1대N
, N대M
등으로 연결될 수 있다.
데이터그램(메세지) 단위로 전송되며 그 크기는 65535바이트로, 크기가 초과하면 잘라서 보낸다.
흐름제어(flow control)가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없다.
파일 전송과 같은 신뢰성이 필요한 서비스보다 성능이 중요시 되는 경우에 사용된다.
키워드 | TCP (Transmission Control Protocol) | UDP (User Datagram Protocol) |
---|---|---|
타입 | 연결 지향적 | 데이터그램 지향적 |
신뢰성 | 목적지까지의 전송을 보장함 | 전송을 보장하지 않음 |
순서 보장 | 패킷들의 순서가 보장됨 | 패킷 순서가 보장되지 않음. 패킷 순서를 보장하기 위해서는 애플리케이션 layer에서 관리되어야 함 |
속도 | UDP보다 느림 | TCP에 비해 빠르며, 단순하고 효율적이다 |
서버와 클라이언트 간에 Socket Connection을 유지해서
언제든 양방향 통신 또는 데이터 전송이 가능하도록 하는 기술
로써, sns, 화상 채팅, 증권 거래 등에서 널리 사용된다.
실시간 채팅 앱과 같은 요구사항들을 반영하기 위해 클라이언트에서 매번 HTTP 프로토콜을 통해 서버에 요청하는 것은 비효율적
이다.
클라이언트에서 Ajax 통신 등으로 일부 보완할 수 있지만, Ajax도 결국 HTTP를 사용하기 때문에 여전히 문제가 되며, 웹 소켓
을 통해 이를 해결할 수 있다.
WebSocket은 HTTP를 통해 최초 연결되며, 이후 일정 시간이 지나면 HTTP 연결은 자동으로 끊어지고 webSocket connection은 유지된다.
HTTP와 달리 WebSocket은 stateful 프로토콜
이다.
HTTP는 stateless하기 때문에 서버에 변경사항이 생겨도 클라이언트에서 요청을 하지 않으면 변경사항이 적용되지 않는다.
반면, WebSocket은 지속적으로 connection을 유지하기 때문에 실시간으로 변경사항이 적용
된다.
WebSocket은 HTTP와 동일한 port(80)
를 사용한다.
WebSocket은 stateful 프로토콜로써 connection을 항상 유지해야하기 때문에 트래픽이 많은 경우 서버에 부담이 될 수 있다.
=> 따라서 연결이 끊어졌을 때 적절히 대응할 수 있어야 한다.