김영한의 실전 자바 - 고급 2편(네트워크, TCP, IP, UDP, DNS)

TCP와 IP의 차이에 대해 설명하시오

구분	TCP(Transmission Control Protocol)	IP (Internet Protocol)
역할	신뢰성 있는 데이터 전송을 담당	데이터를 목적지까지 전달하기 위한 주소 지정 및 경로 설정 담당
계층	전송 계층 (Transport Layer)	네트워크 계층 (Network Layer)
연결 방식	연결 지향형 (Connection-oriented)	비연결형 (Connectionless)
기능	- 데이터 분할 및 재조립 - 전송 오류 검출 및 복구 - 패킷의 순서 보장	- 패킷에 IP 주소 추가 - 최적의 경로를 통해 패킷 전달
신뢰성	신뢰성 보장 (패킷 손실 시 재전송)	신뢰성 비보장 (패킷 손실 시 재전송 없음)
속도	상대적으로 느림 (오류 복구 및 순서 제어를 위해)	상대적으로 빠름 (오류 복구 및 순서 제어 없음)
데이터 단위	세그먼트 (Segment)	패킷 (Packet)
주요 사용 사례	HTTP, FTP, SMTP, Telnet 등	모든 인터넷 통신의 기반 (TCP, UDP 등의 프로토콜에 의해 사용됨)

• 사실상 TCP와 IP는 비교 대상이 아님
• TCP는 Transport Layer, IP는 Network Layer기 때문에 계층 자체가 다름
• 두 프로토콜의 목적 자체가 다르며, IP는 데이터를 목적지까 전달이 목표고 TCP는 신뢰성 있는 전송을 목표로 함
• 따라서, 신뢰성 있는 전달을 위해 TCP/IP 프로토콜 스택을 사용하며, TCP/IP 가 일반적인 데이터 전송 프로토콜 스택임.

 

TCP와 UDP의 차이를 설명하시오

구분	TCP	UDP
연결 방식	연결 지향적 (3-way handshake로 연결 수립)	비연결성 (연결 설정 없이 데이터 전송)
신뢰성	신뢰성 있음 (데이터 손실 시 재전송)	신뢰성 없음 (데이터 손실 시 재전송 없음)
흐름 제어	있음 (슬라이딩 윈도우 기법 등)	없음
혼잡 제어	있음 (혼잡 상태에 따라 전송 속도 조절)	없음
데이터 순서 보장	있음 (순서대로 전송됨)	없음 (순서가 보장되지 않음)
헤더 크기	상대적으로 큼 (20바이트 이상)	상대적으로 작음 (8바이트)
속도	상대적으로 느림 (오버헤드가 많음)	상대적으로 빠름 (오버헤드가 적음)
용도	신뢰성 있는 데이터 전송이 중요한 서비스 (웹, 이메일 등)	속도가 중요한 서비스 (스트리밍, VoIP, 게임 등)

• TCP는 신뢰성 있는 데이터 전송이 필요한 경우에 사용되고, UDP는 속도가 중요한 경우나 데이터 손실을 허용할 수 있는 상황에 적합합니다.
• 예를 들어, 웹 브라우징, 파일 다운로드, 이메일 등에서는 TCP가, 스트리밍, 온라인 게임, VoIP 등에서는 UDP가 많이 사용됩니다.
• 일반적으로 우리가 Java에서 BufferedReader와 같은 클래스를 사용하면 자연스럽게 TCP를 사용하게 되며, UDP를 사용하고자 하면 DatagramSocket과 같은 클래스를 사용하면 됨.

 

MTU(Maximum Transmission Unit)가 1500B,  BufferedWriter의 버퍼 크기가 4KB, 데이터의 크기가 5KB일 경우 BufferedWriter를 통해 데이터를 보내는 플로우를 설명하시오

• 조건 정의
  • BufferedWriter의 버퍼 크기: 4KB(4096바이트)
  • 데이터 크기: 5KB(5120바이트)
  • MTU(Maximum Transmission Unit): 1500바이트
  • TCP 헤더 크기: 20바이트
  • IP 헤더 크기: 20바이트
  • MSS(Maximum Segment Size) = MTU - IP 헤더 - TCP 헤더 = 1500 - 20 - 20 = 1460바이트
• BufferedWriter의 처리
  • BufferedWriter는 4KB(4096바이트)를 내부 버퍼에 저장하고, 버퍼가 가득 차거나 플러시 호출시 데이터를 하위 계층으로 전송함
  • 5KB 데이터를 처리 시:
    1. 첫 번째 4KB(4096바이트)를 버퍼에서 전송.
    2. 남은 1KB(1024바이트)는 이후 전송.
• TCP 계층: 세그먼트 분할
  • TCP는 데이터를 MSS(1460바이트) 크기로 나눕니다. 각 세그먼트는 **TCP 헤더(20바이트)**를 포함합니다.  
    • 첫 번째 전송 (4KB):
      • 4096바이트를 MSS 단위로 나눕니다:
        • 첫 번째 세그먼트: 1460바이트
        • 두 번째 세그먼트: 1460바이트
        • 세 번째 세그먼트: 1176바이트 (4096 - 1460*2)
    • 두 번째 전송 (1KB):
      • 남은 1024바이트는 한 개의 세그먼트로 처리됩니다:
        • 네 번째 세그먼트: 1024바이트
• IP 계층: 패킷 처리
  • TCP 세그먼트는 **IP 헤더(20바이트)**를 추가하여 IP 패킷으로 변환됩니다.
    • 첫 번째 전송의 각 세그먼트:
      • 첫 번째 패킷: 1460(TCP 세그먼트) + 20(IP 헤더) = 1480바이트
      • 두 번째 패킷: 1460(TCP 세그먼트) + 20(IP 헤더) = 1480바이트
      • 세 번째 패킷: 1176(TCP 세그먼트) + 20(IP 헤더) = 1196바이트
    • 두 번째 전송:
      • 네 번째 패킷: 1024(TCP 세그먼트) + 20(IP 헤더) = 1044바이트
• 데이터 링크 계층: 전송
  • 데이터 링크 계층에서 IP 패킷을 **프레임(Frame)**으로 변환하여 물리적 네트워크를 통해 전송합니다.
  • MTU(1500바이트)를 초과하지 않는 패킷만 전송되며, 분할은 TCP/IP 계층에서 이미 처리되었기 때문에 추가 작업이 필요 없습니다.
• 데이터 재조립
  • TCP의 세그먼트에는 세그먼트의 번호가 있기 때문에 수신측에서는 수신한 세그먼트의 번호에 따라 순서가 다를 경우 다시 재조립을 진행
• TCP의 데이터 전송 기법(슬라이딩 윈도우)
  • 세그먼트를 하나 보내면 받는 쪽에서는 ACK 1460을 보냄(세그먼트의 사이즈가 1460이었기 따문에 다음에 받을 데이터는 1460번 부터라는 의미)
  • 송신 측은 다시 1460부터 세그먼트를 보내며, 이게 반복되는게 기본 구조.
  • 하지만, 이런식으로 통신하면 한 번에 하나의 데이터밖에 주고 받을 수 없기 때문에 효율적이지 못해서 슬라이딩 윈도우 기법을 사용
  • 예를 들어, 윈도우 사이즈가 3이면, 최대 3개 만큼 동시에 보낼 수 있으며, 송수신이 하나라도 완료되면 추가로 하나의 송수신 작업이 시작 됨.
  • 위도우의 사이즈가 커지면 효율성은 높아지지만 담을 수 있는 네트워크 버퍼의 사이즈보다도 커지며 혼잡도가 높아지는 문제가 발생할 수 있음.
  • 일반적인 윈도우 크기는 64KB ~ 256KB 범위이며, 초기에는 작은 윈도우 크기에서 시작하여 네트워크 상태가 좋아짐에 따라 사이즈는 동적으로 커질 수 있음.

 

AWS의 Route53에 abc.def라는 도메인이 나의 특정 ALB의 DNS 네임을 가리키게 등록했다고 하자. 누군가 abc.def 사이트에 접속할 때 발생하는 플로우를 설명하시오

1. 사용자가 도메인에 접속 시도

• 사용자가 웹 브라우저에 abc.def를 입력하면, 브라우저는 DNS 쿼리를 발생시킵니다.
• 이 DNS 쿼리는 abc.def 도메인이 어떤 IP 주소를 가리키는지 확인하기 위한 요청입니다.

2. DNS 쿼리 전파

• DNS 서버 검색: 브라우저는 우선 로컬 DNS 캐시를 확인하고, 만약 해당 도메인 정보가 없으면, 인터넷에 존재하는 DNS 서버들을 통해 정보를 찾기 시작합니다.
  • 이때 처음에는 루트 DNS 서버를 통해 쿼리가 시작됩니다.
  • 루트 DNS 서버는 도메인에 해당하는 최상위 도메인(TLD) 서버를 알려줍니다. 예를 들어, abc.def는 .def라는 최상위 도메인에 해당하므로 .def의 TLD 서버로 쿼리가 전달됩니다.

3. TLD 서버에서 Route 53 네임서버로 전달

• TLD DNS 서버는 해당 도메인의 네임서버 정보(즉, Route 53 네임서버)를 반환합니다. 이때, Route 53이 관리하는 abc.def 도메인에 대한 네임서버 정보가 포함됩니다.
  • 예를 들어, abc.def 도메인의 네임서버는 ns-xxxx.awsdns-xx.com과 같은 형식일 수 있습니다.
• TLD 서버는 Route 53 네임서버의 주소를 반환하고, 이제 DNS 쿼리는 Route 53에 전달됩니다.

4. Route 53에서 DNS 레코드 조회

• Route 53 네임서버는 abc.def 도메인에 대한 A 레코드(또는 Alias 레코드)를 조회합니다.
  • 이 A 레코드는 abc.def가 어떤 IP 주소를 가리키는지를 정의합니다.
  • 만약 abc.def가 로드밸런서를 가리키도록 설정되어 있다면, Route 53은 해당 로드밸런서의 DNS 주소를 반환합니다.

5. 로드밸런서의 IP 주소 또는 DNS 반환

• Route 53은 abc.def 도메인에 설정된 A 레코드나 Alias 레코드의 값을 반환합니다.
  • A 레코드는 abc.def 도메인에 해당하는 IP 주소를 반환합니다.
  • Alias 레코드는 로드밸런서의 DNS 주소를 반환할 수 있습니다. 예를 들어, my-load-balancer-1234567890.us-west-2.elb.amazonaws.com과 같은 로드밸런서의 DNS 주소를 반환합니다.

6. 최종 IP 주소로 요청 전달

• 사용자의 브라우저는 이제 Route 53에서 받은 IP 주소나 로드밸런서의 DNS 주소를 통해 최종적으로 연결을 시도합니다.
• 로드밸런서가 DNS 주소인 경우: 로드밸런서는 EC2 인스턴스나 다른 리소스들로 트래픽을 라우팅하고, 최종적으로 사용자가 요청한 리소스를 전달합니다.

7. 결과적으로

사용자가 abc.def에 접속하면, 외부 DNS 서버가 먼저 Route 53 네임서버로 쿼리를 전달하고, Route 53은 해당 도메인의 A 레코드(또는 Alias 레코드)를 반환하여 로드밸런서의 DNS 주소나 IP 주소를 제공하게 됩니다. 이 정보를 기반으로 최종적으로 사용자는 해당 리소스에 연결됩니다.

간단한 플로우

1. 사용자가 abc.def에 접속.
2. DNS 쿼리가 루트 DNS 서버로 전달.
3. 루트 DNS 서버는 TLD 서버로 쿼리 전달.
4. TLD 서버는 Route 53 네임서버 정보 반환.
5. Route 53에서 A 레코드 또는 Alias 레코드를 조회하여 IP 주소 또는 로드밸런서 DNS 주소 반환.
6. 사용자는 해당 IP 또는 DNS 주소로 접속하여 리소스를 사용.

 

자바의 InetAddress를 통해서 호스트 이름을 IP 주소 조회를 하는 과정은?

• 시스템의 호스트 파일을 먼저 확인한다.
  • /etc/hosts (리눅스, mac)
  • C:\Windows\System32\drivers\etc\hosts (윈도우,Windows)
• 호스트 파일에 정의되어 있지 않다면, DNS 서버에 요청해서 IP 주소를 얻는다.