HOME CHANGES INDEX

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
notes:udp-length [2018/05/07] – external edit 127.0.0.1notes:udp-length [2018/09/02] – gomida
Line 2: Line 2:
 ===== The maximum length of a UDP payload ===== ===== The maximum length of a UDP payload =====
 <sq> <sq>
-==== 이론적 최대 길이 ====+=== 이론적 최대 패킷 사이즈 ===
 UDP 페이로드의 이론적인 최대 길이는 16 bit 최대 값인 2<sup>16</sup>-1=65,535 bytes에서 UDP 헤더 길이 8 bytes를 제외한 65,527 bytes이다. 그러나 막상 구현을 해보면 각각의 개발자들이 서로 다른 경험을 가지게 되어 논란이 발생하곤 하는데, 이런 사태를 유발하는 원인을 추적해보자. UDP 페이로드의 이론적인 최대 길이는 16 bit 최대 값인 2<sup>16</sup>-1=65,535 bytes에서 UDP 헤더 길이 8 bytes를 제외한 65,527 bytes이다. 그러나 막상 구현을 해보면 각각의 개발자들이 서로 다른 경험을 가지게 되어 논란이 발생하곤 하는데, 이런 사태를 유발하는 원인을 추적해보자.
-\\ +</sq> 
-\\ +<sq>
-<sqtag>JAN 1980</sqtag> +
-----+
 === RFC 760, Jan 1980 === === RFC 760, Jan 1980 ===
 1980년 기술 된 [[https://tools.ietf.org/html/rfc760|RFC 760]]은 현재 운용되고 있는 IPv4의 기반이 되었던 스펙이다. 이듬해 다듬어진 [[https://tools.ietf.org/html/rfc791|RFC 791]]과 비교해 보면 기본적인 틀은 같지만 UDP에 대한 언급이 아직 없었던 것을 알 수 있다. 1980년 기술 된 [[https://tools.ietf.org/html/rfc760|RFC 760]]은 현재 운용되고 있는 IPv4의 기반이 되었던 스펙이다. 이듬해 다듬어진 [[https://tools.ietf.org/html/rfc791|RFC 791]]과 비교해 보면 기본적인 틀은 같지만 UDP에 대한 언급이 아직 없었던 것을 알 수 있다.
-\\ +</sq> 
-\\ +<sq>
-<sqtag>AUG 1980</sqtag> +
-----+
 === RFC 768, Aug 1980 === === RFC 768, Aug 1980 ===
 가장 오래 된 UDP 스펙은 1980년 기술 된 [[https://www.ietf.org/rfc/rfc768.txt|RFC 768 User Datagram Protocol]] 이다. UDP 헤더는 16 bit 길이의 Length 필드를 가지는데, UDP 헤더의 길이 8 bytes를 포함한 길이라고 명시하고 있다. 따라서 UDP가 실어 나를 수 있는 페이로드의 이론적인 최대 길이는  65,535 bytes - 8 bytes = 65,527 bytes로 계산할 수 있다. 가장 오래 된 UDP 스펙은 1980년 기술 된 [[https://www.ietf.org/rfc/rfc768.txt|RFC 768 User Datagram Protocol]] 이다. UDP 헤더는 16 bit 길이의 Length 필드를 가지는데, UDP 헤더의 길이 8 bytes를 포함한 길이라고 명시하고 있다. 따라서 UDP가 실어 나를 수 있는 페이로드의 이론적인 최대 길이는  65,535 bytes - 8 bytes = 65,527 bytes로 계산할 수 있다.
Line 27: Line 23:
   Length is the length in octets of this user datagram including this   Length is the length in octets of this user datagram including this
   header and the data. (This means the minimum value of the length is eight.)   header and the data. (This means the minimum value of the length is eight.)
-\\ +</sq> 
-<sqtag>SEP 1981</sqtag> +<sq>
-----+
 === RFC 791, Sep 1981 === === RFC 791, Sep 1981 ===
 하지만 UDP가 근본적으로 IP 네트워크에서의 운용을 상정하고 디자인되었다는 점을 상기할 필요가 있다. [[https://tools.ietf.org/html/rfc791|RFC 791]]을 살펴보면 Total Length는 IP 헤더를 포함한 데이터그램의 전체길이로 정의하고 있는데, 이렇게 되면 RFC 768의 UDP Length는 이 제약을 받게 된다. 따라서 IPv4 네트워크에서 운용한다면 UDP 페이로드의 최대길이는 65,527 bytes 에서 다시 IP 헤더의 최소길이 20 bytes를 제외한 65,507 bytes로 계산할 수 있다. 하지만 UDP가 근본적으로 IP 네트워크에서의 운용을 상정하고 디자인되었다는 점을 상기할 필요가 있다. [[https://tools.ietf.org/html/rfc791|RFC 791]]을 살펴보면 Total Length는 IP 헤더를 포함한 데이터그램의 전체길이로 정의하고 있는데, 이렇게 되면 RFC 768의 UDP Length는 이 제약을 받게 된다. 따라서 IPv4 네트워크에서 운용한다면 UDP 페이로드의 최대길이는 65,527 bytes 에서 다시 IP 헤더의 최소길이 20 bytes를 제외한 65,507 bytes로 계산할 수 있다.
Line 52: Line 47:
     Total Length is the length of the datagram, measured in octets,     Total Length is the length of the datagram, measured in octets,
     including internet header and data.     including internet header and data.
-\\+</sq> 
 +<sq>
 === 576 bytes === === 576 bytes ===
 Total Length에 관해 조금 더 살펴보자. 모든 장비가 576 bytes까지의 데이터그램을 반드시 처리할 수 있어야 함을 명시하고 있음에 주목할 필요가 있다. 바꾸어 말하면 더 큰 데이터그램의 처리는 IPv4 네트워크에서 보장되지 않는다는 것을 의미하고, 이는 UDP 관련 구현 시 서로 다른 경험을 가지게 되는 원인이 된다. Total Length에 관해 조금 더 살펴보자. 모든 장비가 576 bytes까지의 데이터그램을 반드시 처리할 수 있어야 함을 명시하고 있음에 주목할 필요가 있다. 바꾸어 말하면 더 큰 데이터그램의 처리는 IPv4 네트워크에서 보장되지 않는다는 것을 의미하고, 이는 UDP 관련 구현 시 서로 다른 경험을 가지게 되는 원인이 된다.
Line 59: Line 55:
   It is recommended that hosts only send datagrams larger than 576 octets   It is recommended that hosts only send datagrams larger than 576 octets
   if they have assurance that the destination is prepared to accept the larger datagrams.   if they have assurance that the destination is prepared to accept the larger datagrams.
-\\ +</sq> 
-<sqtag>JUL 1982</sqtag> +<sq>
-----+
 === RFC 815, Jul 1982 === === RFC 815, Jul 1982 ===
 Fragmented 데이터그램 재조립을 위한 알고리즘은 [[https://tools.ietf.org/html/rfc815|RFC 815]]에서 기술되었는데, 역시 576 bytes 이상의 길이는 구현 선택사항으로 남겨둔 채 명시하지 않았다. Fragmented 데이터그램 재조립을 위한 알고리즘은 [[https://tools.ietf.org/html/rfc815|RFC 815]]에서 기술되었는데, 역시 576 bytes 이상의 길이는 구현 선택사항으로 남겨둔 채 명시하지 않았다.
Line 71: Line 66:
   by a very large integer, greater than 576, of the implementor's choice.)   by a very large integer, greater than 576, of the implementor's choice.)
  
-\\ +</sq> 
-----+<sq>
 === Conclusion === === Conclusion ===
 따라서 UDP 페이로드의 이론적인 최대길이는 65,527 byte 이지만 IPv4 네트워크에서는 65,507 byte로 제약되며, 더불어 IP 및 UDP 헤더포함 총 576 byte 이상의 데이터그램은 IPv4 네트워크에서는 전송이 보장되지 않기에 전송경로 상에서 IP fragmentation과 reassembly를 수행하는 장비들(송신자, 수신자, 라우터)에 의해 그 최대길이가 결정되는 것을 알 수 있다. 따라서 UDP 페이로드의 이론적인 최대길이는 65,527 byte 이지만 IPv4 네트워크에서는 65,507 byte로 제약되며, 더불어 IP 및 UDP 헤더포함 총 576 byte 이상의 데이터그램은 IPv4 네트워크에서는 전송이 보장되지 않기에 전송경로 상에서 IP fragmentation과 reassembly를 수행하는 장비들(송신자, 수신자, 라우터)에 의해 그 최대길이가 결정되는 것을 알 수 있다.
 </sq> </sq>
  
Last Update
Copyright © 2010-2024.  Sunwoong Joo  All rights reserved.
Powered by DokuWiki.