[Network] TCP/IP의 데이터를 전기 신호로 만들어 보낸다 (3)

05. IP와 이더넷의 패킷 송수신 동작

1. 패킷의 기본

TCP 담당 부분은 접속, 송수신, 연결 끊기의 각 단계에서 통신 상대와 대화할 때 IP 담당 부분에 의뢰하여 데이터를 패킷의 모습으로 만들어 상대에게 보낸다.

패킷은 헤더와 데이터의 두 부분으로 구성된다. 헤더에는 수신처를 나타내는 주소 등 제어 정보가 들어있고, 데이터에는 의뢰처에서 의뢰한 데이터가 들어있다.

먼저 패킷의 송신처가 되는 기기가 패킷을 만드는데, 헤더에는 적절한 제어 정보를 기록하고, 데이터 부분에 일정 크기의 데이터를 넣은 후 가장 가까운 중계 장치로 전송한다.

가장 가까운 중계 장치에 도착한 이후, 도착한 패킷의 정보를 조사하여 패킷의 목적지를 판단한다.

이 판단 과정에서, 수신처가 어느 방향에 있는지에 대한 정보를 기록한 표와 비슷한, 자료를 사용한다. 이를 반복하여 최종적으로 수신처의 기기에 패킷이 도착한다.

수신처에서도 회답 패킷을 보낼 때도 같은 방법으로 이루어지기 때문에 송신처, 수신처를 명확하게 구별할 필요가 없다. 따라서 송신처, 수신처를 합쳐서 엔드 노드라고 부른다.

⇒ HTTP에서는 종단 이라는 표현을 썼다. ( end to end )

⇒ 실제로는 라우터와 허브가 위 작업을 분담해서 하는데, 라우터는 다음 라우터를 찾는 일을 하고, 허브는 서브넷 안에서 패킷을 전송하여 다음 라우터로 보내는 일을 한다.

허브는 이더넷의 규칙에 따라 패킷을 운반하고, 라우터는 IP 규칙에 따라 패킷을 운반하기 때문에, IP가 목적지를 확인하고 이더넷이 보낸다고 표현할 수도 있다.

MAC 헤더 ( 이더넷 용 )

엄밀히 말해 TCP/IP 패킷에는 MAC 헤더와 IP 헤더가 따로 있다. MAC 헤더는 이더넷 용이다.

1. 전송 시, 송신자는 수신자의 IP를 IP 헤더에 기록한다.
2. 해당 IP로 가기 위해 먼저 들러야 할 라우터를 조사한다. 거기에 도착할 수 있도록 이더넷에 의뢰를 한다. ( MAC 헤더에 기록한다. )
3. 의뢰를 받은 이더넷은 나중에 MAC 헤더를 통해 자신이 어디로 보내야 하는지를 알 수 있다.
4. 라우터는 나중에 IP 헤더를 읽고 수신자가 누가 되어야 할 지를 알 수 있다.

의문점

1. 그러면 전송하기 전에 거쳐야 할 지점은 미리 다 파악이 되어 있는 걸까?

   1. 이를 위해서 이더넷이 뭔지를 좀 알아야 할 거 같다.

      ⇒ 이더넷 부분은 무선 LAN, ADSL, FTTH 등 IP의 의뢰를 받아 패킷을 운반할 수 있는 것이면 무엇이든 대체될 수 있다.

이렇게 해서 패킷을 송신하면 이더넷의 원리에 따라 움직이는 허브에 먼저 도착을 하고, 허버는 자신의 이더넷 표와 MAC 헤더를 비교하여 다음 허브, 또는 라우터로 보내준다.

라우터는 IP용 표를 확인하여 MAC 헤더에 다음 번 라우터로 갈 수 있게 해준다. ( 다음 번 라우터로 가기 위해서는 허브들을 거쳐야 하기 때문에 MAC에 다음 번 라우터를 기입하는 것. )

2. 패킷 송수신 동작의 개요

프로토콜 스택 내 IP 담당 부분의 패킷 송신 동작

데이터가 전송되어야 할 중계 지점에 대한 것은 네트워크 기기들의 역할이 되므로 IP 담당 부분은 송출만 하면 된다.

1. TCP 담당 부분이 IP 담당 부분에 패킷 송신을 의뢰하는 것부터 시작된다.
   • 데이터 조각에 TCP 헤더를 부가한 것을 IP 담당 부분에게 건네준다.
2. IP 담당 부분은 IP 헤더와 MAC 헤더를 추가한다. IP 헤더는 목적지를, MAC 헤더는 중간에 경유할 다음 번 라우터를 기록한다.
3. 이렇게 만든 패킷을 네트워크 용 하드웨어 ( 이더넷, 무선 LAN 등 )에게 건네준다. 이 책에는 LAN 어댑터 라고 통칭한다.
   • 상대에게 도착하기까지의 과정은 IP 담당 부분이 관여할 부분이 아니다.
4. 상대에게 패킷이 도착하면 회답이 돌아온다. 회답도 같은 방식으로 돌아온다.
   • 패킷을 받은 쪽은 LAN 어댑터에서 신호의 모습을 디지털 데이터의 모습으로 되돌린다.
   • IP 패킷 송수신동작은 패킷의 역할에 관계 없이 모두 똑같다.
     • 데이터가 있는지 없는지, 순서는 어떻게 되어 있는지에 대해서 일절 관여하지 않고 보내는 과정만을 책임진다.

⇒ 아래부터 세부적으로 본다.

3. 수신처 IP 주소를 기록한 IP 헤더를 만든다

IP 헤더에서 가장 중요한 것은 수신처 IP 주소이다. TCP 담당 부분에서 통지된 통신 상대의 IP 주소를 설정한다. 즉, 애플리케이션에서 통지된 통신 상대의 IP 주소다.

⇒ 애플리케이션이 주소에 대한 책임을 진다.

송신처 IP 주소도 설정한다.

송신처 IP 주소는 사실 컴퓨터 자체의 주소가 아니라 컴퓨터에 있는 LAN 어댑터의 주소기 때문에 LAN 어댑터가 여럿인 경우에는 여러 개의 IP 주소를 가질 수도 있다.

이럴 경우에는 어떤 IP 주소를 설정해야 할지에 대한 판단이 먼저 이루어진다.

패킷을 건네줄 상대를 판단하는 방법은 라우터가 IP용 표를 사용하여 다음 라우터를 결정하는 방법과 동일하다. 프로토콜 스택의 IP 담당 부분과 라우터의 패킷 송수신 부분이 똑같이 IP의 규칙을 따른다.

이 IP용 표를 경로표, 라우팅 테이블이라고 부르는데, 수신처 IP를 Network Destination 항목과 비교하여 어느 행에 해당하는지를 찾아낸다.

⇒ 일단 왼쪽의 어디까지 일치해야 하는지에 대한 규칙이 있다. ( 서브넷 마스크 관련된 내용 )

왼쪽으로부터 일치된 영역을 찾은 다음에는 Interface 항목을 확인한다. 이는 LAN 어댑터 등의 네트워크 용 인터페이스를 의미한다.

인터페이스에서 패킷을 송신하면 상대에 패킷을 건네줄 수 있다는 의미다.

Gateway는 다음 라우터의 IP 주소를 기록하게 되어 있다. 여기에 적힌 주소로 건네면 목적지에 패킷을 중계해준다는 것을 나타낸다.

경로표 맨 위에서 목적지와 넷마스크가 모두 0.0.0.0인 것은 기본 게이트웨이라고 한다.

프로토콜 번호라는 필드에도 값을 설정한다. 이는 TCP, UDP 등 프로토콜을 구분하기 위한 번호다.

4. 이더넷 용 MAC 헤더를 만든다.

IP 헤더를 만들었으면 IP 담당 부분의 앞에 MAC 헤더를 붙인다. IP 헤더의 수신처 IP 주소에 패킷을 전달하는 목적지가 쓰여져 있으므로 이것을 보고 어디로 운반해야 하는지를 판단할 수 있지만,

이더넷에는 TCP/IP 개념이 통용되지 않는다. 따라서 이더넷은 TCP/IP와 다른 구조로 패킷의 수신처를 판단하며, 이 구조를 따르지 않으면 이더넷 패킷을 운반할 수가 없다.

MAC 헤더는 이더넷 내에서 수신처를 판단 구조로 사용하는 것이다.

MAC 헤더의 맨 앞에는 수신처 MAC 주소와 송신처 MAC 주소가 있다. 이 주소들은 IP가 32비트인 것과 달리 48비트로 되어있다.

MAC 번호는 IP와 같이 그룹화된 주소 개념이 아니라 48비트 자체가 하나의 값으로서 주소를 나타낸다.

이후에는 3개의 이더 타입이라는 항목이 있다.

이 항목은 IP 헤더의 프로토콜 번호와 비슷하다. IP 헤더에서는 프로토콜 번호로 뒷부분이 패킷의 내용물이며, 어디에서 의뢰되었는지를 나타냈다. 이더 타입도 같은 역할이다.

MAC 헤더를 만들 때에는 이렇게 세 가지 항목에 값을 설정하기만 한다.

이더 타입에는 IP 프로토콜임을 나타내는 0800 이라는 값을, 다음에는 송신처 MAC 주소를 기록한다. ( 송신처 맥 주소는 OS가 기동하여 LAN 어댑터를 초기화할 때 1번만 가져오면 된다. )

수신처 MAC 주소는 다소 복잡하게 설정된다.

패킷을 건네주는 상대의 MAC 주소를 설정하여 이더넷에 의뢰해야 하므로, 라우팅 테이블에서 Gateway가 일치하는 IP 주소의 기기를 기록한다.

5. ARP로 수신처 라우터의 MAC 주소를 조사한다

ARP : Address Resolution Protocol

이더넷은 연결되어 있는 전체에게 패킷을 전달하는 브로드캐스트라는 구조가 있는데, 이 구조를 이용하여 특정 IP를 가진 기기가 있는지 전원에게 요청을 보낸다.

라우팅 테이블이 올바르다면 응답이 돌아오지만, 그렇지 않다면 상대가 없는 것으로 되어 송신 동작이 실패한다.

의문점

라우팅테이블이 올바르다면 상대가 같은 서브넷 내에 있을 거라고 되어 있는

⇒ 이해했다.

패킷을 보낼 때마다 이 동작을 하면 ARP의 패킷이 불어나기 때문에 한 번 조사한 결과는 ARP 캐시라는 메모리 영역에 보존하여 다시 이용한다.

ARP 캐시가 언제까지나 실제 주소와 같을 거라는 보장은 없기 때문에, ARP 캐시는 일정 시간이 지나면 삭제하게 되어 있다. OS 종류마다 다르지만 보통 몇 분 정도이다.

이 몇 분 내에서도 통신 장애가 발생할 가능성은 있다.

MAC 헤더를 IP 헤더의 앞에 붙이면 패킷이 완성된다. 여기까지가 IP 담당 부분의 역할이다.

6. 이더넷의 기본

이후에는 LAN 어댑터의 역할이다.

초기 형태

이더넷은 다수의 컴퓨터가 적은 비용으로 통신하기 위해 고안된 기술로, 네트워크의 실체는 케이블이다.

컴퓨터가 신호를 송신하면 네트워크 전체에 신호가 흐르고, 전원에게 신호가 도착한다. 전원에게 신호가 도착하지만 수신처 주소가 같으면 받고, 다르면 패킷을 폐기한다.

이 동작을 처리하기 위해 MAC 헤더를 이용한다. ( 패킷의 송신처, 수신처, 이더 타입에 의한 패킷 내용물 판별까지 )

( 실제로는 동시에 여러 기계가 송신을 하면 신호가 충돌하지만 그에 대한 대비책도 이미 마련되어 있고, 실무 상 복잡한 부분은 고려할 필요가 없다. )

파생형

원래는 트랜시버 케이블을 통해 케이블과 컴퓨터를 연결하는 식이었다면, 파생형에서는 리피터 허브 하나로 여러 대의 컴퓨터를 중계해주는 형태가 되었다.

( 신호를 처리하는 방식이 변했기 때문에 단순히 케이블 구조만 바뀌었다고 말할 수는 없다. )

스위칭 허브를 이용한 형태

현재 이더넷의 형태이다.

리피터 허브 대신에 스위칭 허브가 생겼으며, 이 스위칭 허브는 전원에게 신호를 보내지 않고, 수신처에게만 신호를 보낸다.

이더넷이라고 하면 이제 이 형태를 뜻하며, 송신처, 수신처의 MAC 주소와 이더 타입을 가진 것을 이더넷이라고 생각하면 된다.

7. IP 패킷을 전기나 빛의 신호로 변환하여 송신한다

메모리에 저장되어 있는 데이터는 그대로 상대에게 보낼 수 있는 게 아니다. 따라서 전기나 빛의 신호로 변환하여 케이블에 송출하는데, 이것이 송수신의 본질이다.

이 동작을 실행하는 것이 LAN 어댑터이다.

LAN 어댑터는 단독으로 동작하지 않고, LAN 드라이버 소프트웨어가 필요하다. ( 사실 드라이버가 필요한 것은 모든 하드웨어에 공통이다. )

LAN 어댑터의 구조

• 버퍼 메모리 : 송수신 패킷을 일시적으로 저장하는 메모리
• ROM : MAC 주소를 기입하는 부분
• MAC : 충돌 검출/ 다시 송신 등 이더넷의 송수신 동작을 제어하는 부분
• PHY(MAU) : 송수신 회로를 합쳐 부르는 말
• RJ-45 커넥터 : LAN 케이블의 접속부

⇒ 기기에 전원을 공급하면 OS는 LAN 드라이버로 하드웨어 초기화 작업을 수행하여 LAN 드라이버를 사용 가능한 상태로 만든다.

⇒ 이더넷 특유의 작업은, 이더넷 송수신을 제어하는 MAC 이라는 회로에 MAC 주소를 설정하는 것이다.

LAN 어댑터의 ROM에는 전세계에서 중복이 일어나지 않도록 일원화해서 관리되는 MAC 주소를 기입한다. MAC 회로는 자체에 할당된 MAC 주소가 무엇인지를 이를 통해 안다.

8. 패킷에 3개의 제어용 데이터를 추가한다

LAN 드라이버는 IP 담당 부분에서 패킷을 받으면 그것을 LAN 어댑터의 버퍼 메모리에 복사한다.

복사를 한 후, 패킷을 송신하도록 MAC 회로에 명령을 보낸다.

MAC 회로도 TCP, IP가 그랬듯이 패킷에 새로운 부분을 추가하는데, 이것들을 프리앰블과 스타트 프레임 딜리미터라는 데이터, 프레임 체크 시퀀스라는 오류 검출용 데이터를 추가한다.

여기서 프레임은 패킷과 동의어다. ( 이더넷 표준 사양에서 사용하는 용어이다. )

프리앰블

송신하는 패킷을 읽을 때 타이밍을 잡기 위한 것으로, 1과 0이 번갈아 나타나는 56비트의 데이터.

이 신호를 이용해서, 1과 0 사이의 간격을 알아낸다.

스타트 프레임 딜리미터

프리앰블이 끝나는 시점에 이어지는 11의 값으로, 패킷이 시작되는 위치를 파악한다.

디지털 데이터를 신호로 바꾸었다면, 읽을 때는 이를 역으로 돌리면 된다. 신호의 높낮이를 1과 0으로 해석하면 된다.

그러나 이 때, 실제 신호는 비트의 구분을 나타내는 보조선이 없어서 비트 길이를 알 수 없다. 예를 들어 1111이나 0000을 보내면, 1이 몇 개고, 0이 몇 개인지 구분할 수가 없게 된다.

이를 위해 클록 신호가 있다.

클록 신호는 비트의 구분을 파악하기 위해 일정 주기로 0과 1을 오가는 데이터 신호이다. 클록 신호가 아래에서 위, 또는 위에서 아래 등 변화하는 시점에 맞춰 신호의 전압이나 전류의 값을 읽는다.

( 그림 상에서, 클록 신호는 1비트에 해당하는 신호 주기보다 짧게 진동한다. )

그러나 여기에 또 문제가 발생하는데, 거리가 멀어져서 케이블이 길어지면 데이터 신호와 클록 신호가 전달되는 시간 사이에 차이가 발생하여 클록이 틀어지는 것이다. ( 측정 주기가 어긋나는 것. )

이를 해결하기 위해서 실제 신호와 이 클록 신호의 합을 통해 판별하고자 한다.

이 합성된 신호를 송신 측에서 수신측으로 보낸다.

당연하겠지만, 클록 신호와 합쳐진 신호는, 클록 신호의 변화 타이밍과 동일하게 변화가 발생한다. 따라서 변화의 타이밍을 정확하게 알 수 있고, 다시 합성 신호에서 클록을 추출하면 원래 신호를 알 수 있다.

이 때 바로 데이터를 흘리게 하면 타이밍을 맞추는 동안 놓치는 데이터가 생길 수 있으므로 프리앰블을 먼저 흐르게 하는 것이다.

패킷의 신호가 끝난 후 클록의 신호를 계속 흐르게 놔두면 타이밍을 파악한 상태를 유지할 수 있어서, 다음 번 패킷에는 타이밍을 다시 맞출 필요가 없다.

FCS

다음에 짧막하게 설명.

9. 허브를 향해 패킷을 송신한다

프리앰블, 스타트 프레임 딜리미터, FCS ( 패킷을 운반하는 도중 잡음 등의 영향으로 파형이 흐트러지는 것을 검출하기 위한, 일종의 체크섬 역할 ) 만 부여하면 케이블에 송출할 패킷이 완성된다.

이제 신호를 송신만 하면 되는데, 이 동작은 리피터 허브를 사용하는 반이중 모드와, 스위칭 허브를 사용하는 전이중 모드의 두 가지가 있다.

반이중 모드는 케이블에 다른 기기가 송신한 신호가 이미 흐르고 있는지 파악하여, 신호가 흐르고 있으면 송신 동작을 미루고 나중에 보낸다.

이후 송신이 될 때에는 MAC 회로가 패킷 전체를 1비트씩 전기신호로 변환하고, PHY 또는 MAU 라는 송수신 신호 부분에 보낸다.

이 때, 디지털 데이터를 신호로 변환하는 속도가 곧 데이터 전송 속도이다.

PHY 회로는 다시 이를 송출할 수 있는 형태로 변환하여 송신한다. ( MAC 회로에서는 PHY 말고 다른 회로가 있는 기기에서도 변환할 수 있게 공통 형식까지만으로 변환해둔다. )

PHY 회로는 송신 뿐만 아니라 수신 신호선에서 신호가 들어오는지를 감시한다.

송신하기 전에는 수신되는 신호가 있나 체크를 미리하고, 없으면 보내는데, 송신하는 도중에 신호가 들어오지 않으면 무사히 종료된다.

신호를 송신하는 도중에 수신 신호가 들어오면?

정말 작은 확률이지만 가능은 하다. 반이중 모드에서는 서로 신호가 뒤섞여서 분간할 수 없는 상태가 되는데, 이렇게 되면 송수신이 모두 무의미해진다.

따라서 충돌이 난 것을 알리기 위해 재밍 신호라는 특수한 신호를 보낸다.

이 후 잠시 대기 후에 다시 한 번 송신을 하는데, 이 대기 시간을 MAC 주소를 이용해 만든 난수로 생성하여, 다른 송신자와 다시 겹치는 일을 방지한다.

이더넷이 혼잡해지면 다시 충돌날 수도 있는데, 이럴 때마다 대기 시간을 각자 2배로 늘린다. 이를 10번 반복하고도 안된다면 오류로 판단한다.

반이중 모드에 대한 설명은 추후에 한다.

10. 돌아온 패킷을 받는다

반대로 수신을 할 때를 보자.

리피터 허브를 이용한 반이중 동작의 이더넷에서는 리피터 허브에 접속된 케이블 전체에 신호를 흘러 보낸다. 즉 자신 뿐만 아니라 다른 누군가에게 가는 신호도 전부 들어온다.

일단 프리앰블부터 읽으며 파형에서 타이밍을 계산, 스타트 프레임 딜리미터가 나오면 다음 비트부터는 디지털 데이터로 변환하여 읽는다.

순서는 거꾸로, PHY부터 MAC 회로 쪽으로 보낸다.

패킷의 맨앞부터 읽으며 FCS를 구하고, 패킷의 마지막에 같이 보내진 FCS를 비교하여 일치 여부를 판별한다. 일치하면 제대로 된 데이터가 온 것이고, 불일치하면 오류로 간주하여 패킷을 폐기한다.

FCS에 문제가 없다면 LAN 어댑터에 설정된 MAC 주소와 비교하여 자신에게 온 게 맞는지 확인한다. 아니라면 폐기한다.

만약 자신에게 온 게 맞다면 컴퓨터에게 통지를 하는데, 이 통지는 인터럽트 라는 구조를 사용한다.

인터럽트

컴퓨터는 LAN 어댑터만 보고 있는 게 아니라 여러 가지 일을 동시에 수행하므로, 어댑트 측에서 알려주지 않으면 패킷 도착 여부를 알 수가 없다. ( LAN 드라이버도 결국 프로그램 중 하나일 뿐이다. )

따라서 컴퓨터 본체의 작업에 끼어들어, LAN 어댑터를 확인하도록 주의를 주는 것이 인터럽트다.

구체적인 동작 방법은 아래와 같다.

• LAN 어댑터가 확장 버스 슬롯 부분에 있는 인터럽트용 신호선에 신호를 보낸다.
• 컴퓨터 본체 측 인터럽트 컨트롤러를 통해 CPU와 연결되어 있기 때문에, 이 신호를 받은 CPU는 일시적으로 작업을 보류하고 OS 내부의 인터럽트 처리용 프로그램 쪽으로 전환한다.
• LAN 드라이버가 호출되고 LAN 어댑터를 제어하면서 송수신 동작을 실행한다.

인터럽트에는 번호가 할당되어 있어, LAN 어댑터를 설치할 때 번호를 해당 하드웨어로 설정한다.

인터럽트 처리용 프로그램 쪽은 하드웨어의 인터럽트 번호에 대응하도록 드라이버 소프트웨어를 등록하게 되어 있다. 지금은 자동으로 된다.

이 인터럽트가 LAN 드라이버를 동작시키는 것으로 이어지면, 버퍼 메모리로부터 패킷을 추출하고 MAC 헤더의 타입 필드 값으로부터 프로토콜을 판별한다.

즉, 웹 서버로 보내면 웹 서버에서 패킷이 돌아온다고 생각하기 쉽지만 실제로는 그렇게 한정적이지 않다.

11. 서버의 응답 패킷을 IP에서 TCP로 넘긴다

IP에서는.

웹 서버에서 패킷이 돌아온 것으로 간주하고, 프로토콜 스택의 동작을 추적한다.

서버에서 반송된 패킷의 타입은 0800이므로, LAN 드라이버는 TCP/IP 프로토콜 스택에 패킷을 건넬 것이다.

IP 담당 부분은 IP 헤더 부분을 조사하여 포맷에 문제가 없는지 확인 후 수신처 IP를 조사한다. 만약 자신의 IP가 아니라면 ICMP라는 메시지로 상대에게 오류를 통지한다.

IP 헤더에는 플래그라는 항목이 있는데 이를 통해서 IP 프로토콜의 조각 나누기 기능이 실행되었는지 확인할 수 있다.

이는 패킷을 분할하여 보내는 것을 의미하는데, 이 경우에는 IP 담당 부분 내부에서 일시적으로 데이터를 보관하여 IP 헤더의 ID를 확인해 ID 정보가 같은 값들을 참조하게 한다.

프래그먼트 오프셋을 사용하여 패킷의 순서도 맞춘다.

이렇게 패킷을 원래의 모습으로 조립하는 동작을 리어셈블링이라고 한다.

TCP에서는.

IP 담당 부분에서 TCP 담당 부분으로 보내면, IP 헤더에 기록된 수신처 IP, 송신처 IP, TCP 헤더에 기록된 수신처 포트 번호, 송신처 포트 번호를 조사해 해당하는 소켓을 찾아낸다.

소켓은 다시 적절한 동작을 하여, 애플리케이션에게 데이터를 주거나, 접속, 연결 끊기 등 동작을 실행한다.

⇒ TCP에서 IP 헤더를 읽는 것은 역할을 침해하는 것이긴 하지만, 속도를 위해서 허용한다.

06. UDP 프로토콜을 이용한 송수신 동작

1. 수정 송신이 필요 없는 데이터의 송신은 UDP가 효율적이다

TCP 정리

데이터를 확실하면서도 효율적으로 전달하기 위함이다. 데이터가 확실하게 도착한 것을 알고, 만일 그렇지 않았다면 다시 보내기 위해, 데이터를 보낸 다음 수신 측에게 응답을 받았던 것이다.

그러나 이상이 생겼을 때 데이터를 전부 다시 보내는 것은 비효율적이라 오류가 발생한 부분만을 보내고자 하는데, 이를 위해 TCP는 복잡해졌다.

⇒ 의역(?) : 그러나 데이터 패킷이 1개 뿐이라면, 전송이 실패할 때 복잡한 절차를 거칠 필요 없이 그냥 다시 전부 보내도 된다. 어차피 데이터 전부라고 해도 1개 아닌가?

의문점

⇒ 이 해석이 맞는지 잘 모르겠다. 책의 내용이, TCP처럼 복잡하여도, 라고 되어 있지만, 원래는 TCP처럼 복잡하지 않아도 라고 해야 문맥에 맞는 거 같다. - 183P 참고

2. 제어용 짧은 데이터

DNS 서버에 대한 조회 등 제어용으로 실행되는 정보 교환은 한 개의 패킷으로 끝나는 경우가 많아서 UDP를 사용한다.

데이터를 송수신하기 전에 제어 정보를 주고 받을 필요도 없고, 접속이나 연결 끊기 단계도 없으며, 애플리케이션에서 송신 데이터를 받으면 UDP 헤더만 추가하여 IP에 바로 의뢰한다.

수신할 때도 간단한데, IP 헤더의 수신처, 송신처 IP와 UDP 헤더에 있는 수신처, 송신처 포트 번호를 소켓 정보와 결합해 데이터를 건네줄 애플리케이션을 바로 특정해낸다.

오류가 발생하여 패킷이 없어져도 확인하지 않는다.

문제가 생기면 애플리케이션이 한 번 더 보내겠거니 하고 넘긴다!

3. 음성 및 동영상 데이터

음성이나 영상 데이터를 보낼 때도 UDP를 사용한다. 음성이나 영상 데이터는 결정된 시간 안에 데이터를 건네 주어야 한다. ( 지연된다면 이미 재생되는 타이밍과 맞지 않게 되어 음성, 영상이 끊긴다. )

따라서 TCP로 보낼 경우 재생 타이밍이 맞지 않을 수 있고, 이런 경우 음이나 영상을 원래대로 되돌릴 수 없어서 데이터가 도착해도 무용지물이다.

⇒ 이는 음성이나 영상에 다소 데이터가 사라져도 치명적인 문제가 없기 때문에 가능한 것이기도 하다.