네트워크 프로그래밍에서 스트림과 데이터 그램의 차이점은 무엇입니까?


답변:


304

오래 전에 저는이 둘의 차이점을 설명하는 데 큰 비유를 읽었습니다. 유감스럽게도 내가 읽은 부분을 기억하지 못하지만 아이디어에 대한 저자의 의견을 밝힐 수는 없지만 어쨌든 핵심 비유에 많은 지식을 추가했습니다. 그래서 여기에 간다 :

스트림 소켓은 전화 통화와 같습니다. 한쪽은 전화를 걸고 다른 쪽은 전화를 걸고 서로 인사를하고 (TCP의 SYN / ACK) 정보를 교환합니다. 완료되면 작별 인사를합니다 (TCP의 FIN / ACK). 한쪽이 작별 인사를 듣지 못하면 예상치 못한 사건이므로 다른쪽에 전화를합니다. 일반적으로 클라이언트는 서버에 다시 연결됩니다. 전송 한 데이터와 다른 순서로 데이터가 도착하지 않을 것이라는 보장이 있으며 데이터가 손상되지 않는다는 합리적인 보증이 있습니다.

데이터 그램 소켓은 클래스에서 메모를 전달하는 것과 같습니다. 메모를 전달한 사람 바로 옆에 있지 않은 경우를 고려하십시오. 메모는 사람마다 이동합니다. 목적지에 도달하지 못할 수 있으며 목적지에 도착할 때 수정 될 수 있습니다. 같은 사람에게 두 개의 메모를 전달하면 의도하지 않은 순서대로 도착할 수 있습니다. 교실을 통과하는 메모의 경로가 같지 않을 수 있기 때문에 한 사람이 다른 사람만큼 빠르게 메모를 전달하지 못할 수 있습니다. .

따라서 정보를 순서대로 가지고 있고 손상되지 않은 경우 스트림 소켓을 사용하십시오. 파일 전송 프로토콜이 좋은 예입니다. 내용이 무작위로 섞여 있고 손상된 일부 파일을 다운로드하고 싶지 않습니다!

스트림의 높은 오버 헤드를 원하지 않을 때 (VoIP 또는 게임 프로토콜을 고려할 때) 주문이 적시에 전달되는 것보다 중요하지 않은 경우 데이터 그램 소켓을 사용합니다 (이는 DNS가 주로 데이터 그램 프로토콜이므로 서버가 한 번에 많은 수의 요청에 매우 신속하게 응답하거나 데이터가 대상에 도달하더라도 너무 신경 쓰지 않는 경우.

VoIP / 게임 사례를 확장하기 위해 이러한 프로토콜에는 자체 데이터 순서 메커니즘이 포함됩니다. 그러나 하나의 패킷이 손상되거나 손실 된 경우, 재전송 요청을 발행하기 위해 스트림 프로토콜 (일반적으로 TCP)을 기다리지 않으려면 신속하게 복구해야합니다. TCP는 복구하는 데 최대 몇 분이 걸릴 수 있으며 게임이나 VoIP와 같은 실시간 프로토콜의 경우 3 초조차도 용납되지 않을 수 있습니다! UDP와 같은 데이터 그램 프로토콜을 사용하면 소프트웨어가 손실 된 데이터를 무시하거나 TCP보다 빨리 다시 요청하여 이러한 이벤트를 매우 빠르게 복구 할 수 있습니다.

VoIP는 손실 된 데이터를 단순히 무시하기에 적합한 후보입니다. 한 당사자는 수신이 좋지 않은 휴대 전화에서 누군가와 대화 할 때 발생하는 것과 비슷한 짧은 간격을들을 수 있습니다. 게임 프로토콜은 종종 조금 더 복잡하지만, 일반적으로 누락 된 데이터를 무시하고 (이후에 수신 된 데이터가 손실 된 데이터를 대체하는 경우) 누락 된 데이터를 다시 요청하거나 다음과 같이 완전한 상태 업데이트를 요청합니다. 클라이언트의 상태가 서버의 상태와 동기화되어 있는지 확인하십시오.


3
SYNACK의 디테일을 포함하는 것만으로도 훌륭합니다.
LazerSharks

2
이 예제 또는 매우 유사한 예제는 Linux Programming Interface에서 가져온 것입니다. 2010 년판에는 1155 페이지와 1159 페이지에 이러한 예가 들어 있습니다.
Josh

30

스트림 소켓 :

  • 서버와 클라이언트 간의 전용 및 엔드 투 엔드 채널.
  • 데이터 전송에는 TCP 프로토콜을 사용하십시오.
  • 신뢰성 있고 무손실.
  • 비슷한 순서로 데이터를 송수신합니다.
  • 분실 / 실수 데이터 복구를위한 오랜 시간

데이터 그램 소켓 :

  • 서버와 클라이언트 사이의 전용 및 엔드 투 엔드 채널이 아닙니다.
  • 데이터 전송에는 UDP를 사용하십시오.
  • 100 % 신뢰할 수 없으며 데이터가 손실 될 수 있습니다.
  • 데이터 송수신 순서가 다를 수 있습니다.
  • 손실 / 실수 데이터를 관리하거나 신속하게 복구하지 마십시오.

데이터가 동일한 순서로 전송되지 않습니까 ( "유사한"것이 아닌)? 즉. 패킷 순서 메커니즘을 스트림 소켓에 구축하는 것은 이치에 맞지 않습니다
Matthew D. Scholefield

스트림 통신의 패킷은 패킷 자체가 수신 호스트에 전달되도록 보장되지 않는다는 의미에서 "유사한"순서로 전송 및 수신되지만 TCP는 불일치를 파악하여 도착시 패킷을 다시 정렬하고 요청합니다. 그것은 길을 따라 잃어버린 것 같습니다.
Alejandro Blasco

말이 되네요 어쩌면 그 차이를 제거하고 그 아래에 넣으십시오 (정확하게 이해하고 있다면 패킷이 전송되는 순서 만 참조 할 때 두 경우 모두 데이터가 전송되거나 수신되는 순서가 아닐 수 있습니다) 똑같다).
Matthew D. Scholefield

@Rick 더 정확하게 말하면, 전송 프로토콜은 하나 이상의 네트워크 엔드 포인트에 메시지를 전달하기 때문에 소켓을 엔드 투 엔드 지점이라고합니다.
Alejandro Blasco

0

그것이 네트워크 프로그래밍이라면 소켓에서 시작하는 것이 좋은 시작이라고 생각합니다.
socket = ip + port
소켓
스트림 (TCP, 주문 및 배송 보장, 중복, 데이터 길이 또는 문자 경계, 연결 지향, 신뢰성, 동시성)
데이터 그램 (UDP, 패킷 기반, 비 연결, 데이터 그램) 크기 제한, 데이터 손실 또는 복제, 주문 보장, 신뢰할 수 없음)
원시 (하위 계층 프로토콜 IP, ICMP에 직접 액세스)
전송 프로토콜 유형에 대해 어떤 소켓이 어떤 전송 프로토콜을 사용해야하는지에 대한 엄격한 규칙을 보지 못함 그리고 양쪽 끝이 활성화 된 경우 UDP를 실현할 수 있기 때문에 신뢰성을 착각해서는 안됩니다.
신뢰성은 UDP에 존재하지 않는 전송 프로토콜로 TCP를 사용하여 시퀀스 번호 검사가 있기 때문에 전달의 신뢰성과 유사합니다. wireshark tcpdump 등과 같은 네트워크 프로토콜 분석기를 사용하여 소프트웨어가 정확히 수행하는 것을 보는 것이 좋습니다. 당신의 작업과 종이에 대한 검증 또는 이론의 종류.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.