[네트워크 프로토콜] 함께떠나요 네트워크 프로토콜 파티 TCP(2)

네트워크 I/O관리

세그먼트의 크기를 정확히 결정하는 것이 connection의 성능과 관련된 특성을 크게 좌우하므로 매우 중요하다.

 

세그먼트가 너무 작으면 : 네트워크의 대역폭을 낭비하게 된다. 예를들어 IP와 TCP 헤더가 적어도 40바이트를 차지하고 있는데 세그먼트 데이터가 1byte라면 그 세그먼트의 헤더 대 데이터 비율이 40:1이되어 TCP의 처리량이 형편없어진다. 

=> 초당 1Mbyte를 전송 할 수 있는 회선이 있다고 하자.. 1kbyte 짜리 파일이 있는데 이를 1byte씩 보낸다면...? 회선을 효율적으로 이용하지 못하는것이다 ㅠㅠ

 

세그먼트가 너무 크면 : 세그먼트가 MTU를 초과해서 IP데이터그램이 한번에 네트워크를 통과 할 수 없다면, 네트워크를 통과하기에 적당한 크기로 분열되어야 한다. + 물론 송신지 + 라우터 + 수신지 처리로직 부하 발생

또한 분할 작업은 안정성에 문제가 있을 수 있다. 분열을 방지 하는 것이 주어진 가상 회선에 가장 효율적인 패킷 크기를 정확하게 결정하는 데 매우 중요하다.

 

가장 효율적인 세그먼트 크기를 결정하는 데 고려해야 할 요소

- 전송 버퍼의 크기

가장 확실한 요소다. 전송버퍼가 꽉 채워지면 다른 요소랑 상관 없이 세그먼트가 전송되기 때문이다.

- 수신 버퍼의 크기

마찬가지로 수신 시스템에서 처리할 수 있는 것보다 더 많은 데이터를 전송하게 되면 분실이 발생할 수 있기 때문이다.

- MTU(최대 전송 단위)와 MRU(최대 수신 단위) 크기 

- 헤더의 크기

TCP는 생성되는 세그먼트에 IP헤더와 TCP 헤더가 저장될 수 있는 공간을 남겨두어야 한다. 이는 중요하다. MTU = (TCP 헤더 + IP 헤더 + 세그먼트)

'책에서 봤는데... MTU가 1500이라고 하던데... 세그먼트에 1500을 꽉 채워 보내야지 하하하' 하면 큰일난다. 지난번 일다닐때 현택이가 신경질내면서 알려줬었는데. 갑자기 열받으면서 고맙네. 아무튼 IP헤더 + TCP헤더가 최소 40byte니까 세그먼트는 실제로 최대 1460byte 정도 담을 수 있다. (참고로 최대 세그먼트 사이즈는 MSS라고 한다.)

 

- 데이터 크기와 적시성

가장 효율적인 세그먼트 크기를 결정하는 수식 : 전송할 데이터가 적은 경우를 제외하고는 가장 작은 저장 단위를 찾아 IP와 TCP헤더에서 필요로 하는 바이트 수를 뺀 값이다. 

전송할 데이터가 적은 경우에는 데이터의 크기가 전송되는 세그먼트의 크기를 결정한다.

 

-버퍼 크기에 대한 고려

가장 효율적인 세그먼트 크기를 결정하는 것은 부분적으로 두 시스템에서 사용하는 전송버퍼와 수신버퍼의 크기에 의해 좌우된다. 전송 버퍼가 너무 작으면 송신 시스템은 대형 세그먼트를 생성하지 못한다. 버퍼가 다 차면 세그먼트를 보내니까. 

 

버퍼의크기는 각 시스템마다 초기 설정값이 다르다. 대부분의 시스템은 사용자가 수신 버퍼의 초기 설정값을 지정하도록 허용하며 애플리케이션 개발자가 자신의 애플리케이션에 특정한 설정값을 사용하게 한다.

때로는 로컬 시스템의 전송 버퍼의 크기가 병목이 될 수도 있다.

 

TCP Header의 window 필드 - 목적지 시스템의 수신 버퍼의 크기

송신시스템은 당연하게도 자신의 전송 버퍼의 크기를 알고 있다. 그러나 세그먼트 크기를 계산하기 전에 "목적지 시스템의 수신 버퍼의 크기" 를 파악해야 한다. TCP는 각 TCP 세그먼트의 헤더에 저장된 16비트 'Window'필드를 사용하여 이러한 목적을 달성한다.

1) TCP 세그먼트가 생성될 때마다 송신 시스템은 현재 자신의 수신 버퍼 크기를 Window필드에 저장하고,

2) 세그먼트가 수신지에 도달하면 수신 시스템은 이 정보를 읽어들이고, 다음 TCP세그먼트 사이즈를 결정할 때 사용한다.

이처럼 각 시스템은 상대방의 수신 버퍼의 크기를 끊임없이 감시할 수 있어 언제라도 주어진 시점에 전송할 수 있는 데이터의 최대 용량을 결정할 수 있다.

 

Window 필드의 길이는 16비트이므로 수신 버퍼의 최대 크기를 64킬로바이트로 제한한다.

RFC1323에서 Window Scale 옵션이라고 불리는 TCP 옵션을 정의하여 두 시스템이 30비트 윈도우 크기를 사용하여 수신 버퍼의 크기를 1기가바이트까지 지정할 수 있게 한다.

+ Window 필드를 결정하는것은 생각보다 복잡한 일이라서, 별도의 알고리즘들이 존재한다.

https://pandorafms.com/blog/tcp-congestion-control/

TCP Congestion Control: basic outline and TCP CUBIC algorithm

https://tools.ietf.org/html/rfc5033

RFC 5033 - Specifying New Congestion Control Algorithms

 

MTU와 MRU 크기에 대한 고려

버퍼의 크기를 결정하는 문제는 모든 세그먼트의 크기에 영향을 미칠 수 있지만

"대부분의 경우 종단간 네트워크 연결에 사용되는 MTU와 MRU크기가 세그먼트 크기를 결정하는 요소가 된다."

예를 들어, 가장 취약한 시스템에서조차 2Kbyte 또는 그 이상의 TCP 수신 버퍼를 갖고 있다. 그러나 이더넷 네트워크의 MTU/MRU는 고작 1500byte밖애 되지 않는다. 이 경우에는 이더넷 세그먼트의 MTU/MRU 크기가 한 세그먼트에서 분열하지 않고 전송할 수 있는 최대 데이터 용량을 나타내므로 MTU/MRU 크기가 송신 시스템의 최대 세그먼트 크기가 된다.

 

일반적으로 특정 네트워크의 MTU와 MRU는 같은 값을 갖는다.