(네트워크) TCP/IP 쉽게, 더 쉽게 목차 리뷰 - 3장 트랜스포트 계층

작성일 In , Disqus:

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
각 목차 뒤에 F(ront), B(ack)을 적어놨으니 자신의 직군에 맞춰 딥하게 볼지 그냥 흐름만 볼지, 아예 안 볼지 판단하길 바란다.

예를 들면 프론트는 클라이언트 측에 웹서비스를 제공해주는 일을 하는데 그 중에서 서버가 제공해주는 API로 통신을 해서 데이터를 땡겨와야 한다.
웹서비스를 제공하기 위해서는 HTTP(S) 프로토콜을 사용하고, 서버의 API와 통신할 때도 HTTP(S)로 통신을 한다.
HTTP 프로토콜은 정보 공유를 위해 만들어진 프로토콜이므로 엄청난 수의 클라이언트가 접속하게 된다.
통신을 위한 통로에 수십만명이 한 번에 들어오게 끔 하면 가능한지도 모르겠고, 매번 그 만큼의 사람이 들어오는 것도 아니고, 비용 낭비도 엄청날 것이다.
따라서 통신을 위한 통로를 독점하는 게 아니라 항상 연결을 맺고 끊어서 다른 사람들이 원활하게 접속을 하게 해준다.
예를 들면 이 통로를 통해서는 동시에 100명만 들어올 수 있게 만들고 나한테 볼 일이 끝난 애들은 다 연결을 끊는 것이다.(사실 이런 설정은 백엔드가 한다.)
이 때 연결을 위해 사용하는 프로토콜이 TCP 프로토콜이다. (UDP 프로토콜도 있지만 웹 서비스 내에서는 대부분 데이터를 손실없이 전달해주는 TCP 프로토콜을 사용한다.)
따라서 프론트 엔드 개발자라면 HTTP 프로토콜은 물론이고 TCP 프로토콜까지 알아야 어떻게 하면 통신을 최적화 할 수 있을지 생각할 수 있게 된다.

백엔드의 경우에는 HTTP(S), TCP 프로토콜만 안다고 해서 끝나는 게 아니다.
SSH 프로토콜을 이용해서 서버에 원격으로 붙어서 명령어를 날리기도 하고, FTP 프로토콜을 이용해서 파일 업로드/다운로드가 가능한 서버를 설계해야할 수도 있기 때문이다.
SSH 프로토콜을 사용하려면 여러 인증 방식 중에 키로 인증하는 방식이 있는데 그럼 공개키, 비공개키, 대칭키, 비대칭키 막 이런 내용이 나오는데 이런 보안적인 요소도 알아야한다.
이 내용은 HTTPS에 사용되는 TLS 인증서의 암호화 방식에도 적용된다.
또한 동영상 스트리밍 서버를 만든다고 하면 UDP 프로토콜을 사용한다.
기본적으로 TCP 프로토콜은 해주는 일이 많으므로(데이터 전송에 실패하면 재전송 처리 등등) 성능이 안 받쳐주는데
UDP 프로토콜(보내기만 할 뿐, 잘 받았는지 확인을 하지 않는다. 그래서 가끔 동영상이 깨져서 나오는 현상들이 나온다.
하지만 크리티컬한 이슈는 아니고 매번 똑같은 부분에서 동영상이 깨져나오는 게 아니고 네트워크 상황에 따라 달라지기 때문이다.)은 그거보다 성능이 낫기 때문이다.
또한 AWS를 사용하다보면 그 아랫단인 IP/Router/Subnet Mask 등등의 영역도 잘 알아야한다.
보안을 위해 외부에서 접근이 가능한 요소(다양한 요청을 분산해주는 로드 밸런서)와 내부에서만 접근이 가능한 요소(웹서버, DB 등등)을 구성해야하는데…
그러면 네트워크를 어떻게 구성해야할 것이며, 이 네트워크 안에 서버는 몇 대를 둘 것이며, 퍼블릭 요소들과 프라이빗 요소들은 어떻게 통신을 할 것이며
어떤 요청들을 받고 말지 네트워크부터 보안에 대한 요소들을 직접 다뤄야하는 경우가 오는데 이럴 때 이 내용들을 알고 있으면 정말 무릎을 탁 치게 되는 날이 온다.

더 아랫단이나 부가적인 요소들은 알면 +@, 몰라도 그만인 것 같은데 호기심이 충만하면 알고 싶을 것이다.
위에서 설명하지 않은 모뎀, 이더넷 카드, 랜선 등등은 사실 하드웨어 단으로 내려가는 거니 백엔드가 굳이 알 필요가 있나 싶다.(물론 알면 좋다.)
또한 데이터 전송에 실패했을 때 어떤 전략으로 재전송시킬 것인지(어플리케이션 단이 아닌 하드웨어 단에서 패킷을 처음부터 전송할 건지, 실패한 부분을 알아내서 그거부터 전송할 것인지)
이런 내용들은 내가 봤을 때는 굳이 알 필요가 있나 싶은데 분명 알아두면 어딘가는 써먹을 일이 있을테니 공부해둬야할 것 같긴 하다.

목차

  1. 컴퓨터 네트워크
  2. 네트워크 서비스와 애플리케이션 계층
  3. 트랜스포트 계층
  4. 라우팅과 인터넷 계층
  5. 하드웨어와 네트워크 인터페이스 계층
  6. 보안

3장, 트랜스포트 계층

컴퓨터로 들어온 데이터를 어떤 서비스에게 토스 할 지 포트를 보고 판단한다.
트랜스포트 계층에서 사용하는 대표적인 프로토콜은 TCP와 UDP가 있다.
OSI 7 Layer에서는 L4(Layer 4)에 해당하며 똑같이 Transport Layer이다.

3-1. 트랜스포트 계층의 역할(F/B)

컴퓨터에서 수많은 서비스가 돌아간다. (웹서비스, FTP 서비스, 이메일 서비스 등등)
근데 어떻게 들어온 데이터를 보고 올바른 서비스에게 보내는지 그 기준이 바로 포트 번호이다.
80 포트라면 웹 서비스(HTTP)에게, 443 포트여도 웹 서비스(HTTPS)에게, 21 포트라면 FTP에게 전달한다.
하지만 80이고 443이고 그 서비스를 대표하는 포트지 80포트에 내가 FTP 서비스를 열어둘 수도 있다.
그냥 디폴트로 설정하는 포트지 꼭 그 포트가 예약돼있는 건 아니다(일부는 시스템에 의해 얘약되는 경우도 있지만).

그리고 TCP와 UDP의 차이에 대해 설명하고 있는데 TCP는 데이터의 손실 없이 정확하게 전달되도록 설계된 프로토콜이라서
서로 전송 속도라던지, 전송하는 크기라던지, 실패의 경우에 재전송이라던지, 바쁘면 잠시 멈추거나 속도나 크기를 줄인다던지 완급 조절이 가능하다.
(그렇다고 모든 통신이 성공한다는 보장은 없지만…)
UDP는 전송 속도를 위주로 설계된 프로토콜이라 마구잡이로 보낸다(뭐 망나니처럼 보내지는 않겠지만).
그래서 중간에 패킷이 유실되는 경우가 발생한다. (음성 통화중 지지직 대거나 동영상을 보는데 화면이 가끔 깨져보인다거나)
이런 경우에 이게 그렇게 크리티컬한 오류는 아니지만 전송 속도가 느려서 실시간성이 보장이 안 되는 게 더 크리티컬한 이슈로 판단되기 때문이다.

3-2. 포트번호(F/B)

포트 번호는 065535의 범위 내에서 할당할 수 있는데 01023은 Well known ports라고 부른다.
주요 Well known ports는 아래와 같고 각 서비스별로 대표 포트를 사용하는 경우에는 포트 번호의 생략이 가능하다.

  • 20 FTP(액티브 모드에서는 데이터 커넥션이고 패시브 모드에서는 다이나믹 포트 내의 랜덤한 포트가 할당되는 것 같다, 파일 주고받기)
  • 21 FTP(컨트롤 커넥션, 명령어 날리기)
  • 22 SSH, SCP, SFTP
  • 23 Telnet
  • 24 SMTP
  • 53 DNS
  • 80 HTTP
  • 110 POP3
  • 443 HTTPS

1024 ~ 49151번 포트는 Registered ports라고 해서 벤더 사에서 붙이는 포트들이다.
생각 나는 게 3036 MySQL 뿐이다 ㅠㅠ…
ElasticSearch, Logstash, Kibana, Redis, PostgreSQL 등등 각종 어플리케이션에서 쓰이는 기본 포트들이 다 Registered ports에 할당이 되며
공식적인 게 아니므로 다른 어플리케이션과 충분히 충돌이 발생할 수 있다.

49152 ~ 65535번 포트는 다이나믹 포트라고 해서 대부분 클라이언트 측의 아웃바운드 트래픽에 포트를 할당할 때 쓰인다.
아래 시나리오를 상상해보자.

  1. 웹 브라우저 클라이언트가 웹 서버에 요청을 보낸다.
  2. 웹 서버가 응답을 보낸다.
  3. 클라이언트 컴퓨터로 왔는데 클라이언트 컴퓨터에는 다양한 어플리케이션(메일 서비스, 웹 서비스, FTP 서비스 등등)이 실행되고 있다.

위 상황에서 어떤 서비스에게 요청에 대한 응답을 보내줘야할까?
답은 1번의 과정에서 요청이 네트워크를 타고 밖으로 나갈 때 포트 번호를 달고 나간다.
이 때 할당되는 포트가 바로 다이나믹 포트 내에 해당하는 포트가 랜덤하게 붙어서 나간다.
HTTP의 경우에는 통신이 끝나면 다른 요청에 대한 연결을 맺기 위해서 이전 연결을 끊기 때문에
동일한 서버라 하더라도 매번 다른 포트를 달고 나가게 된다.
트랜스포트 계층에서 이제 그 포트를 보고 어떤 서비스에게 데이터를 보낼지 결정한다고 보면 된다.

3-3. TCP가 정확하게 데이터를 전달하는 방법

3-3-1. TCP가 하는 일(F/B)

통신 속도, 데이터 크기, 서버/클라가 바쁘면 완급 조절 등등을 한다.
또한 서버나 클라가 데이터를 못 받았을 때 재전송까지 해준다.

3-3-2. TCP 헤더의 구조(B)

TCP 헤더에는 송수신지 포트번호, 데이터의 크기, 데이터의 무결성 확인을 위한 정보나
데이터 사이즈를 위해서 패딩을 넣기도 한다.
대충 이 정도만 알고 넘어가자.

3-3-3. 컨트롤 비트(B)

TCP 헤더에 포함돼있으며 통신 상태를 표현하는 플래그이다.
전송량을 줄여달라거나 혼잡해서 받을 수 없다거나 이런 정보를 보고 통신 상태를 조절한다.
TCP 3Way Handshake에서 SYN, ACK 같은 데이터도 컨트롤 비트 내의 플래그이다.
1비트이기 때문에 8가지 플래그가 존재한다.

3-3-4. 통신 개시부터 통신 종료까지의 흐름(F/B)

그 유명한 TCP 3Way Handshake를 그림으로 표현했다.
UDP에 비하면 3Way Handshake는 오버헤드(쓸 데 없는 행위, 비용 낭비)에 해당한다.
하지만 이 3Way handshake를 통해 통신이 가능한 상태인지 알 수 있으므로 안정성 측면에서는 뛰어나다.

여담으로 HTTP 1.0 스펙과 HTTP 1.1 스펙과 HTTP 2 스펙을 아래와 같은 시나리오로 비교해보자.

HTTP 1.0(총 3Way Handshake: 2회, 요청 횟수: 2회)

  1. 클라이언트에서 index.html 파일을 요청했고 그 안에 이미지 파일이 1개 있다.
  2. index.html 파일을 요청하기 위해 클라이언트/서버가 TCP 3 Way Handshake를 한다.
  3. 연결이 맺어졌으면 요청을 보내고 index.html을 응답 받는다.
  4. 연결을 끊는다.
  5. html을 해석하다보니 이미지 파일이 필요하다.
  6. 이미지 파일을 요청하기 위해 다시 3way handshake를 한다.
  7. 연결이 맺어졌으면 요청을 보내고 이미지를 응답받는다.
  8. 연결을 끊는다.

HTTP 1.1(총 3Way Handshake: 1회, 요청 횟수: 2회)

  1. 클라이언트에서 index.html 파일을 요청했고 그 안에 이미지 파일이 1개 있다.
  2. 요청을 보낼 때 헤더에 Keep-Alive를 설정해서 타임아웃과 타임아웃 내에서 수행할 수 있는 최대 요청갯수를 지정한다.
  3. Connection: Keep-Alive;Keep-Alive: timeout=5, max=1000
  4. 위와 같이 HTTP Request Headers에 지정을 했으면 최초 연결 이후 5초동안 이뤄지는 1000번의 요청까지는 연결을 끊지 않는다.
  5. index.html 파일을 요청하기 위해 클라이언트/서버가 TCP 3 Way Handshake를 한다.
  6. 연결이 맺어졌으면 요청을 보내고 index.html을 응답 받는다.
  7. html을 해석하다보니 이미지 파일이 필요하다.
  8. 아직 Keep-Alive에 설정한 5초 이내이고 1000개의 요청을 보낸 적이 없으므로 TCP 커넥션은 아직 끊어져있지 않은 상태니 3 way handshake를 또 할 필요는 없다.
  9. 이미지를 요청하고 응답으로 받는다.
  10. 받을 데이터를 다 받았으므로 TCP 커넥션을 끊는다.

HTTP 2(총 3Way Handshake: 1회, 요청 횟수: 1회)

  1. 클라이언트에서 index.html 파일을 요청했고 그 안에 이미지 파일이 1개 있다.
  2. 헤더에 실어 보내는 Connection과 Keep-Alive는 프로토콜 내에서 다른 메카니즘으로 처리되므로 헤더에 실어보낼 필요가 없다.
  3. 요청을 보내기 전에 TCP 3way handshake로 연결을 확립하고 요청을 보낸다.
  4. 응답 받을 때 필요한 리소스를 전부 받는다.(이미지 포함)
  5. 응답 받을 거 다 받았으니까 TCP 커넥션을 끊는다.

3-3-5. 일련번호와 최대 세그먼트 크기를 사전에 조율한다

TCP의 경우에 클라이언트와 서버 사이에 통신 가능한 세그먼트의 크기(MSS, Max Segment Size)를 정하는 과정을 설명하고 있다.

3-3-6. 데이터 전송 과정에서 일련번호는 어떻게 변화하나?

주고 받은 Segment Size에 따라 Sequence Number(일련 번호)가 증가한다.
기본적으로 Sequence Number와 확인 응답번호(acknowledge number)는 커넥션을 맺는 과정에서 1로 세팅된다.
그리고 내가 서버로 보내면 세그먼트 사이즈만큼 시퀀스 넘버가 올라간다.
그러면 서버는 정상적으로 요청을 받았다면 응답번호를 세그먼트 사이즈만큼 올린다.
그리고 다시 서버는 클라이언트로 요청을 보내는데 응답을 보내는 세그먼트 사이즈만큼 다시 서버측 시퀀스 넘버를 증가시킨다.
그 응답을 받은 클라이언트는 응답받은 세그먼트 사이즈만큼 확인 응답번호를 올린다.
이렇게 서버/클라이언트 측은 요청/응답 받은 TCP 헤더를 까서 상대 쪽에서 보낸 응답 번호와 자신의 시퀀스 넘버를 확인해서 일치하면
제대로 통신이 이루어졌다고 판단하고 아니라면 통신이 제대로 이뤄지지 않았으므로 에러 처리를 어떻게든 하는 것 같다.
정확하게 어떻게 하는지는 모르겠다.

3-3-7. 송신 실패 여부를 판단한다.

소프트웨어 단에서 재전송 처리가 아닌 하드웨어 단에서 재전송 전략을 간단하게 설명하고 있다.
가장 간단한 전략으로 데이터를 받으면 잘 받았다고 상대방에게 응답을 보내줘야하는데 내가 데이터 보냈는데
상대는 받은 적이 없으니 응답이 오는 게 없다.
따라서 일정시간이 지나도 응답이 오지 않으면 재전송한다는 그런 얘기다.

3-3-8. 연속된 데이터를 몰아서 보내면 전송 속도가 빨라진다.

요청 보내고 상대방이 보내주는 응답번호 일일이 기다리면서 그 다음에 데이터를 전송하면 안정성 측면에선 좋지만
성능 측면에서는 그닥 좋지 않다.
따라서 응답번호를 일일이 기다리지 않고 MSS만 정하고 세그먼트를 계속해서 날리고 확인 응답번호가 어떻게 오는지에 따라서
어떤 세그먼트부터 재전송할지 파악하면 된다.

3-3-9. 한번에 받을 수 있는 데이터 크기를 통보한다.

위에 연속된 데이터를 몰아서 보내면 전송 속도가 빨라지는 장점이 있지만
너무 몰아서 많이 보내다보면 서버가 바쁘면 데이터를 제대로 처리하지 못할 수도 있으므로
서버 측에는 버퍼를 두고 그 버퍼에 모아두고 처리한다.
이때 이 버퍼 사이즈는 TCP 헤더의 윈도우 사이즈 필드에 설정해서 데이터를 보내는 측(송신 측)에 통보를 하면
송신 측은 아 MSS는 얼마고 윈도우 사이즈는 얼마니 최대 몇 개를 몰아서 보내면 될지 계산해서 적당히 보내게 된다.

3-3-10. 한 번에 받아낼 수 있는 데이터 양을 조절한다.

수신 측은 받은 패킷들을 버퍼에 쌓아두면서 버퍼에 쌓인 데이터를 동시에 순차적으로 처리한다.
근데 보내주는 애가 엄청 빨리 보내고 받는 애는 그걸 처리할 능력이 되지 않을 수 있으니
보내는 애한테 현재 윈도우 사이즈(수용 가능한 버퍼 사이즈)를 수시로 알려준다.
이 과정을 흐름 제어(Flow Control)이라고 한다.

3-3-11. 버퍼가 가득 찬 경우

윈도우 사이즈가 0이면 윈도우 사이즈 0이라는 세그먼트와 함께 윈도우 프로브(Window Probe)라는 패킷을 응답한다.
이 응답을 받으면 송신 측은 요청을 중단하고, 전송 재개 시점을 알기 위해 수신 측에 윈도우 프로브 패킷을 보내서 윈도우 사이즈를 알아낸다.
윈도우 사이즈가 빈 공간이 생기면 그 때부터 다시 전송을 재개한다.

3-3-12. 네트워크의 혼잡 상태를 확인한다.

버퍼에 여유 공간이 있어서 윈도우 사이즈가 0이 아니어도 그 아랫단인 인터넷 계층이나 네트워크 인터페이스 계층이 혼잡한 경우도 있다.
이러한 경우에도 정상적인 통신이 불가능하므로 인터넷 계층의 패킷에서 헤더에 혼잡 플래그를 ON으로 달린 패킷이 넘어오게 된다.
이 패킷을 받은 수신측은 송신측에게 컨트롤 비트에 ECE(통신 경로가 혼잡해서 수신할 수 없을 수도 있다) 플래그를 붙여서 응답을 해준다.
그러면 송신측은 컨트롤 비트에 CWR(통신 경로가 혼잡해서 전송량을 줄이겠다) 플래그를 붙여서 패킷을 보내면서 통신 속도도 더불여 낮추게 된다.

중간에 누락된 패킷을 재전송하는 전략에는 여러가지가 있다.
전송 속도를 높이기 위해 데이터를 연속해서 보내다보니 응답으로 온 응답번호와 내가 보낸 시퀀스 넘버가 일치하지 않아서 데이터 전송에 실패했다는 것을 깨달았으면
패킷 재전송 시도를 해야하는데 가장 간단한 거는 처음부터 다시 보내는 건데 효율이 매우 떨어진다.
아니면 그 다음으로 쉬운 방법은 시퀀스 넘버와 응답번호의 싱크가 깨진 패킷부터 다시 보내면 되는 전략이 있다.
그 다음 전략은 누락된 패킷이 뭔지만 캐치해서 보내는 전략이 있는데 이를 SACK(Selective ACKnowledgement, 선택적 확인 응답)이라고 부른다.
아래로 갈 수록 효율은 좋지만 비용(복잡도나 수행을 하기 위한 성능 등등)이 많이 드는 점도 있고 해서 절충안을 마련해야하는데 하드웨어가 짱짱해지면 이 정도 비용은 껌이 되는 시대가 올 것이다.

3-4. UDP가 고속으로 데이터를 전달하는 방법(B)

UDP는 TCP에 비해 상당히 간단한 프로토콜이다.
위의 TCP가 했던 흐름 제어(윈도우 사이즈를 수시로 주고받는 과정), 실패한 패킷 재전송, MSS 정하기, 네트워크 혼잡 상태 파악, 3way handshake 등등이 UDP에서는 무의미해진다.
왜냐하면 안 하기 때문이다.
그냥 빠르게 보내는 데에만 열중하게 된다.
실시간성이 중요한 음성/영상 프로토콜에 많이 쓰인다.
음성/영상 같은 경우에는 가끔 데이터 손실(왜곡)이 있어서 지지직 대거나 화면이 조금 깨져도 크리티컬한 문제는 아니다.
따라서 헤더도 TCP에 비하면 매우 간단하다.

하지만 UDP의 성능을 유지하면서 TCP와 같은 신뢰도를 보장하고 싶은 그런 케이스도 존재한다.
이런 경우에는 트랜스포트 계층에서는 UDP 프로토콜을 쓰지만, 애플리케이션 계층에서 흐름제어나 재전송 등등의 TCP의 역할을 어플리케이션 레벨에서 처리하기도 한다.

여기서 브로드캐스트와 멀티캐스트라는 중요한 개념이 등장한다.
브로드캐스트는 네트워크에 속한 모든 호스트(컴퓨터와 같은 기기)에게 알림을 전파?하는 개념이다.
예를 들면 공유기에 새로운 PC를 연결했을 때 사설 IP를 할당받아야하는데 어떤 IP가 비어있는지 모르니까
모든 호스트를 다 찌르면서(브로드캐스팅을 해서) IP 주소를 알아내고 비어있는 IP를 알아내야할 때 브로드캐스트가 쓰인다.
네트워크에 속한 호스트들은 거부 권한이 없다고 한다. (불쌍한 놈들 ㅠㅠ)
거부 권한이 없기 때문에 브로드캐스트 트래픽을 받은 애들은 일제히 하던 일을 중단하고 브로드캐스팅에 집중해서 본인에게 유익한 정보인지 파악한다. (마치 인터럽트 당하듯이)
그리고 본인에게 해당되는 정보가 없으면 하던 일을 마저하고, 자신에게 해당되는 내용이면 그에 맞게 처리를 한다.
브로드캐스트는 네트워크 전체에게 트래픽을 보내는 것으로 네트워크를 혼잡하게 할 뿐 아니라 수신측의 성능 저하도 유발한다.

멀티캐스트는 네트워크 내의 특정 그룹에게만 데이터를 전송해야할 때 쓰는 방법이다.
브로드캐스트로 전부 다한테 공지하려면 보안에 민감한 정보도 있을테고 오버헤드도 심하기 때문에 이런 방식을 쓴다.
멀티캐스트로 그룹을 나누는 방법은 IP 클래스 중에 D 클래스를 이용하면 된다고 한다.
브로드캐스트와는 달리 본인의 의지로 SUBSCRIBE 할 수 있으며 구독 해지도 할 수 있다.

그리고 책에는 나오지 않지만 유니캐스트(Unicast)라는 개념 또한 중요하다.
유니캐스트는 상대방의 물리 주소(Physical Address, 네트워크 상에서는 MAC(Media Access Control) Address를 의미한다.)를 통해 1:1 통신하는 걸 의미 한다.
대부분의 통신 방식이 유니캐스트 방식으로 진행된다.
본인의 MAC Address와 일치하지 않는 패킷은 바로 버리면 되고 CPU까지 올라오지도 않으므로 PC 성능에 영향을 미치지 않는다.

아래 링크들을 보면 도움이 많이 된다.

3-5. netstat 명령으로 네트워크의 상태 확인하기(B)

netstat 명령어로 서버와 커넥션이 제대로 맺어졌는지 어떤 상태인지 알 수 있다는 내용이다.
만약 8080 포트 서버가 제대로 떠있는지 확인하고 싶다면 netstat -na | grep 8080을 입력하면 네트워크의 연결 상태들을 볼 수 있다.
만약 해당 서버를 죽이고 싶다면 lsof -i:8080 명령어로 어떤 프로세스가 해당 포트를 물고있는지 보고 kill -9 PID 명령어(PID는 프로세스 ID)로 죽여버리면 된다.

책 마지막 부분에 패킷 캡처 도구로 Wireshark가 나오는데 크롬 개발자 도구를 쓸 수 없는 상황이나 크롬 개발자 도구에서 보이는 것보다
더 아랫단의 패킷이나 실제 데이터 통신이 어떻게 되고 있는지 디버깅 하고 싶다면 이 툴을 쓰면 된다.