Java의 UDP 프로토콜에 대한 간략한 소개

이 기사는 주로 UDP 프로토콜 도입에 대한 관련 정보를 자세히 소개하며, 관심 있는 친구들은 이를 참조할 수 있습니다.

1. UDP에 대한 간략한 소개

UDP는 전송 계층 프로토콜입니다. UDP 프로토콜은 TCP 프로토콜과 동일한 계층에 있지만 TCP 프로토콜과 달리 타임아웃 재전송, 오류 재전송 등의 기능을 제공하지 않으므로 신뢰할 수 없는 프로토콜입니다.

2.UDP 프로토콜 헤더

UDP 포트 번호

많은 소프트웨어에서 UDP 프로토콜을 사용해야 하기 때문에 UDP 프로토콜은 특정 플래그를 사용하여 서로 다른 프로그램에서 요구하는 데이터를 구별해야 합니다. 예를 들어 특정 UDP 프로그램 A가 시스템에 포트 3000을 등록하면 외부에서 들어오는 대상 포트 번호 3000의 모든 UDP 패킷이 프로그램에 넘겨집니다. 이론적으로 포트 번호는 2^16까지 가능합니다. 길이가 16비트이기 때문에

UDP 체크섬

이것은 선택 사항이며 모든 시스템이 UDP 패킷을 확인하고 데이터를 데이터화하는 것은 아니지만(TCP 프로토콜과 비교하면 반드시 말해야 할 사항) RFC의 표준입니다. 보낸 사람이 체크섬을 계산해야 합니다.

UDP 체크섬에는 UDP 프로토콜 헤더와 데이터가 포함됩니다. 이는 IP 체크섬과 달리 모든 데이터가 아닌 IP 데이터 헤더에만 적용됩니다. UDP와 TCP에는 모두 체크섬 계산을 위해 촬영된 의사 헤더가 포함되어 있습니다. 의사 헤더에는 IP 주소와 같은 IP 프로토콜에 포함된 정보도 포함되어 있습니다. 그 목적은 UDP가 데이터가 대상에 올바르게 도달했는지 두 번 확인할 수 있도록 하는 것입니다. 송신자가 체크섬 옵션을 설정하지 않고 수신자가 체크섬 계산에 오류를 범하는 경우 UDP 데이터는 오류 메시지 생성 없이 조용히 폐기됩니다(전달이 보장되지 않음).

UDP 길이

UDP는 65535바이트까지 매우 길 수 있습니다. 그러나 일반 네트워크에서는 일반적으로 이렇게 긴 프로토콜을 한 번에 전송할 수 없으므로(MTU 문제 포함) 데이터를 조각화해야 합니다. 물론 이러한 프로토콜은 UDP와 같은 상위 수준 프로토콜에 투명합니다. UDP는 IP 프로토콜 계층에 신경 쓸 필요가 없습니다. 데이터를 샤딩하는 방법과 관련하여 다음 장에서는 몇 가지 샤딩 전략에 대해 간략하게 설명합니다.

IP 조각화

IP는 상위 계층에서 데이터를 받은 후 IP 주소를 기반으로(라우팅을 통해) 어느 인터페이스에서 데이터를 보낼지 결정하고 데이터 크기가 일치하면 MTU 쿼리를 수행해야 합니다. MTU를 초과하면 데이터 샤딩을 수행하면 됩니다. 데이터 조각화는 상위 및 하위 계층에 투명하며 데이터는 대상에 도달한 후에만 재조립됩니다. 그러나 IP 계층은 데이터 재조립을 위한 충분한 정보를 제공합니다.

IP 헤더에서 16비트 식별 번호는 IP 패킷의 ID를 고유하게 기록하며, 13비트 슬라이스 오프셋은 IP 패킷의 위치를 ​​기록합니다. 전체 패킷. ; 이 두 개의 중간에 있는 3비트 플래그는 조각 뒤에 새로운 조각이 있는지 여부를 나타냅니다. 이 세 가지 표시기는 IP 조각화의 모든 정보를 구성하며 수신자는 이 정보를 사용하여 IP 데이터를 재구성할 수 있습니다(나중 조각이 이전 조각보다 먼저 도착하더라도 이 정보로 충분합니다).
조각화 기술은 인터넷에서 자주 사용되기 때문에 악의적인 공격을 수행하기 위해 IP 조각화 패킷을 위조하는 소프트웨어와 사람들이 끝없이 많습니다.

간단한 MTU 감지를 위해 Trancdroute 프로그램을 사용할 수 있습니다. 교과서를 참고해주세요.

UDP와 ARP 간의 대화형 사용

자주 눈에 띄지 않는 부분이며, 체계적인 구현을 위한 부분입니다. ARP 캐시가 아직 비어 있는 경우. UDP가 전송되기 전에 대상 호스트의 MAC 주소를 얻기 위해 ARP 요청을 보내야 합니다. UDP 데이터 패킷이 충분히 크고 IP 계층에서 이를 조각화해야 하는 경우 UDP 데이터 패킷이 첫 번째 조각이 ARP를 발행한다고 상상해 보십시오. 쿼리 요청 및 모든 조각은 쿼리를 보내기 전에 쿼리가 완료될 때까지 기다립니다. 이것이 실제로 사실입니까?
결과적으로 일부 시스템에서는 각 조각이 ARP 쿼리를 보내고 모든 조각이 대기하게 됩니다. 그러나 첫 번째 응답을 받을 때 호스트는 마지막 데이터 조각만 보내고 나머지는 버립니다. 이는 정말 놀라운 일입니다. 이런 식으로 조각난 데이터는 제때에 조립할 수 없기 때문에 수신 호스트는 일정 시간 내에 절대 조립할 수 없는 IP 데이터 패킷을 폐기하고 조립 시간 초과가 포함된 ICMP 메시지를 보냅니다. 실제로 많은 시스템에서는 이 오류를 생성하지 않음) 수신 호스트의 자체 싱크 버퍼가 결코 조립되지 않는 조각으로 채워지지 않도록 합니다.

ICMP 소스 억제 오류

수신 호스트의 IP 계층 캐시가 가득 차서 대상 호스트의 처리 속도가 데이터 수신 속도를 따라가지 못하는 경우 호스트에서 데이터를 전송합니다. "참을 수 없어요" ICMP 메시지.

UDP 서버 설계

UDP 프로토콜의 일부 기능은 서버 프로그램 설계에 영향을 미치며 이는 대략 다음과 같이 요약될 수 있습니다.

1. 클라이언트 IP 및 주소 관련: 서버는 클라이언트의 IP 주소 및 포트 번호를 기반으로 데이터 패킷이 합법적인지 여부를 판단할 수 있는 능력이 있어야 합니다(이는 모든 서버에서 요구되는 것 같습니다).
2. 서버에는 브로드캐스트 주소 기능을 필터링하는 기능이 있어야 합니다.
3. 데이터 입력 관련: 일반적으로 서버 시스템의 각 포트 번호는 입력 버퍼에 해당하며, 들어오는 입력은 선착순으로 서버에서 처리되기 때문에 버퍼 오버플로 문제가 불가피하게 발생합니다. 이 경우 응용 프로그램 서버 프로그램 자체가 문제를 인식하지 못한 채 UDP 패킷이 삭제될 수 있습니다.
4. 서버는 로컬 IP 주소를 제한해야 합니다. 즉, 특정 네트워크 인터페이스의 특정 포트에 자신을 바인딩할 수 있어야 합니다.

위 내용은 Java의 UDP 프로토콜에 대한 간략한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!