읽기 전

  • 불필요한 코드나 잘못 작성된 내용에 대한 지적은 언제나 환영합니다.
  • 개인적으로 사용해보면서 배운 점을 정리한 글입니다.
  • 기술면접만을 준비하기보다 비전공자 입장에서 Network의 기본적인 내용만 짚기 위해 작성되었습니다.

TCP

  • TCP : 신뢰성이 있는 애플리케이션 간의 데이터 전송을 위한 프로토콜
  • TCP에 의한 데이터 전송 절차
    1. TCP 커넥션 범위 : 3way-handshake
    2. 애플리케이션 간 데이터 송수신 : 세그먼트 분할, 혼잡 제어
    3. TCP 커넥션 끊기 : 4-way handshake
  • 플로우 제어 : 데이터 도착 상태 확인하여 재전송을 결정하거나 혼잡 시 속도를 제한하는 등의 과정
  • TCP 헤더

Technical_Interview_Network_003_001.png

  • ACK : 데이터를 바르게 수신했음을 전달

  • 시퀸스 번호 : 패킷의 맨 앞 위치 데이터가 송신 데이터의 몇 번째 바이트에 해당하는지 안내

    • 보통 시퀸스 번호의 초기값은 임의의 난수이다.(매번 1로 시작되면 보안에 취약하므로)
  • ACK 번호 : 데이터가 몇 바이트까지 수신 측에 도착했는지 송신측에 안내

TCP 커넥션 맺기

  • 3way-handshake : 데이터를 전송하기 전에 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정
  1. 접속 동작 시 송신 측에서 시퀸스 번호 초기값을 수신측에 통지
  2. 시퀸스 번호로부터 ACK 번호 산출하여 송신 측에 전송하며 수신측에서 송신측에 보내는 데이터에 대한 시퀸스 번호 초기값도 함께 전송
    • 1번 과정이 정상동작함을 알리기 위해 ACK 전송
  3. 수신측으로부터 받은 시퀸스 번호에서 ACK 번호 산출해서 서버에 보내면 완료
  • 타임아웃 값 : 네트워크 혼잡 등 미상의 사유로 ACK가 돌아오지 않을 때 정해두는 임계값, 초과 시 재전송 등 회복동작 수행

Technical_Interview_Network_003_002.png

애플리케이션 간 데이터 송수신

  • MSS(Maximum Segment Size) : 전송하고자 하는 데이터가 너무 클 때 TCP가 일정 크기로 데이터를 분할. MSS는 그 단위이다.
    • 표준 크기는 1460바이트
  • MTU(Maximum Transmission Unit) : 한 패킷으로 운반할 수 있는 최대 크기
    • 이더넷에서는 보통 1500바이트이다.

Technical_Interview_Network_003_003.png

  • 데이터의 전송

Technical_Interview_Network_003_004.png

  • MSS에 맞춰 분할된 데이터를 전송할 때 수신 측은 송신 측에 어디까지 받았는지 확인하는 ACK 전송
  • stop and wait(ping-pong 방식) : 매번 전송한 패킷에 대한 확인 응답을 받아야 다음 패킷 전송
  • 윈도우 제어 방식(Sliding Window) : 한개의 패킷만을 전송하면 시간 효율이 좋지 않아 복수의 패킷을 전송하며 수신확인을 하는 방식

Technical_Interview_Network_003_005.png

  • 윈도우 사이즈 : 수신 가능한 데이터의 최댓값
    • 일반적으로 수신 측의 버퍼 메모리의 크기가 된다.(TCP 헤더에 명시)

Technical_Interview_Network_003_006.png

오류 제어

  • 오류 검출과 재전송을 수행한다.
  • ARQ(Automatic Repeat Request) 기법을 사용해 프레임이 손상되었거나 손실되었을 경우 재전송을 통해 오류를 복구
  • Stop and Wait ARQ
    • 1개의 프레임 송신, 수신측에서 오류 발생 유무에 따라 ACK이나 NAK을 전송
    • NAK를 받거나 ACK 분실로 타임아웃이 발생하면 송신측이 데이터 재전송
  • Go Back n ARQ(슬라이딩 윈도우)
    • 프레임이 손상되거나 분실되어 NAK이나 타임아웃이 발생한 경우 정상 수신이 확인된 마지막 프레임 이후로 모든 프레임을 재전송
      • 수신측이 데이터 1을 받고 3을 받은 경우 2가 분실되었으므로 3을 폐기하고 NAK 2를 전송하여 2부터 전부 재전송 요청
      • 제대로 수신하여 ACK를 보냈음에도 ACK가 분실될 경우 송신 측은 마지막 ACK된 데이터부터 재전송
    • 오류 검출 시 연속적으로 프레임을 전송하기 때문에 전송된 모든 프레임의 복사본을 가지고 있어야 함
    • ACK : 다음 프레임 전송
    • NAK : 손상된 프레임 번호 반환
  • SR(Selective-Reject) ARQ
    • GBnARQ의 모든 프레임 재전송하는 비효율을 개선한 기법
    • 손상되거나 손실된 프레임만 재전송한다.
    • 따라서 수신측이 데이터 재정렬을 수행해야 하며 별도 버퍼가 필요하는 등 구조가 복잡

혼잡 제어

  • 라우터에 데이터가 몰려 데이터를 처리할 수 없는 경우 오류를 감지한 호스트들이 패킷을 재전송함에 따라 혼잡이 더욱 악화되어 오버플로우나 데이터 손실이 발생할 수 있음
  • 혼잡 제어의 목적 : 네트워크의 혼잡을 피하기 위해 송신측에 보내는 데이터의 속도 제한
  • 혼잡 회피(Congestion Avoidance)
    • 윈도우의 크기가 임계값에 도달하면 데이터 손실 확률이 증가
    • 데이터 손실 회피를 위해 윈도우 크기를 선형적으로 1씩 증가
    • 수신측으로부터 ACK를 수신받지 못한 경우
      1. 타임아웃 발생 : 네트워크 혼잡 발생 인식
      2. 혼잡상태 인식 시 윈도우의 크기를 1로 감소
      3. 임계값을 현재 윈도우 크기의 절반으로 감소
  • 빠른 회복(Fast Recovery)
    • 혼잡한 상태가 감지되면 윈도우 크기를 1로 줄이지 않고 절반으로 줄인 뒤 선형 증가
    • 혼잡회피와 빠른 회복 정책이 적용되면 AIMD 방식이 된다.
  • 빠른 재전송(Fast Retransmit)
    • 수신측에서 패킷을 받을 때 먼저 도착해야 할 패킷이 도착하지 않고 다음 패킷이 도착한 경우 순서대로 도착한 마지막 패킷의 다음 패킷의 번호를 전송하여 송신측이 중복된 ACK 패킷을 받아 문제가 되는 순번의 패킷을 재전송할 수 있음
    • 중복된 순번의 패킷을 3개 받으면 재전송하며 이 현상이 발생하면 혼잡이 발생했음을 인식, 윈도우 사이즈를 절반으로 줄임
  1. AIMD(Additive Increase Multicative Decrease)

    • 합 증가 / 곱 감소 알고리즘이다.
    • 처음에 패킷 하나를 보내기 시작하여 정상 동작할 때마다 윈도우 사이즈를 1씩 증가시킨다. 도중에 전송하며 패킷 전송을 실패하거나 Time out이 발생하면 윈도우 사이즈를 절반으로 줄인다.
    • 나중에 진입하는 호스트도 시간이 지나면 공평하게 전송한다는 특징이 있다.
    • 네트워크 수용 한도 주변에서는 효율적이나 초기 전송속도에서 비효율이 발생
  2. Slow Start

    • AIMD와 동일하게 초기에는 패킷을 하나씩 전송하다가 ACK 패킷이 도착할 때마다 윈도우 사이즈를 1씩 증가시킨다. 결국 이전에 보낸 패킷이 모두 도달하면 윈도우 사이즈는 2배씩 늘어난다. 따라서 윈도우 사이즈의 그래프는 지수함수 형태를 갖는다.
    • 혼잡 현상 발생 시 윈도우 사이즈를 1로 감소시킨다.
    • 초기에는 네트워크 수용량을 예측할 수 없으나 한 번 혼잡 현상을 경험하고나면 혼잡현상이 발생했던 윈도우 사이즈의 절반까지는 지수함수적으로 증가시키되 그 이후부터는 완만하게 1씩 증가시킨다.
    • 전송되는 데이터의 크기가 임계값에 도달하면 혼잡회피를 수행함

TCP 커넥션 끊기

  • 4way-handshake : 세션을 종료하기 위해 수행하는 절차
    1. FIN 비트 1 설정 후 송신측 연결 끊기 동작
    2. 수신측이 받았음을 ACK 번호를 송신
    3. 데이터 송신측이 세션을 종료하더라도 수신측은 일정 시간 대기 후 FIN 비트 1 설정 후 송신측으로 전송
      • 송신측이 보낸 데이터 패킷 중 FIN 패킷보다 느리게 수신측에게 도착할 경우 섣불리 수신측이 세션을 종료하면 유실되기 때문
    4. 송신측이 수신측의 FIN 패킷을 받으면 ACK 번호 송신하여 상호 연결 종료

Technical_Interview_Network_003_007.png

UDP

  • UDP : PC나 서버 등에 도달한 데이터를 적절한 애플리케이션에 배분하는 기능만을 수행하는 프로토콜
    • 데이터 송수신 시 UDP 헤더를 부착
  • UDP 헤더

Technical_Interview_Network_003_008.png

  • TCP와 달리 UDP는 신뢰성 보장을 위한 행위를 수행하지 않기에 데이터 전송효율이 좋다.
  • 크기가 큰 데이터를 분할하는 기능도 없어 애플리케이션이 적절히 분할해야 함
  • 제어용 짧은 데이터 송수신에 사용 - DNS 조회 등
  • 음성 및 동영상 데이터 송수신에 사용 - 전화기 등
    • 전화기 음성이 제대로 수신되지 않았을 경우 해당 데이터를 재전송하기보다 묵음처리하는 것이 더 나음을 의미

DNS

  • 애플리케이션 층의 프로토콜이며 TCP가 아닌 UDP 프로토콜을 이용함
  • TCP/IP 통신을 위해서는 반드시 IP 주소가 요구되나 사용자가 모든 IP 주소를 외울 수 없다.
  • 인간의 언어로 작성된 URL을 IP주소로 바꾸기 위해 사용하는 프로토콜
  • 호스트명 : 서버, 클라이언트 PC 등의 호스트에 사용자가 이해하기 쉬운 언어로 붙인 이름
  • DNS(Domain Name System) : (서버 이름 - IP 주소), (메일주소 - 메일 서버) 등을 대응시키기 위한 시스템
  • DNS resolve / resolver : DNS 서버의 클라이언트, DNS 서버로의 조회 메시지를 전달하고 응답을 받는다.
    • Name resolution(이름 해석) : DNS에 조회하여 IP 주소 등을 조회하는 행위, resolver가 수행

DNS 서버의 기본 동작

  • 클라이언트에서 조회 메시지를 수신하고 요청한 내용에 대한 응답으로 이루어짐
  • 조회 메시지의 구조
    • 이름 : 서버 이름이나 메일의 배송 목적지(@뒤의 도메인)
    • 클래스 : 초기 DNS 구성 시 인터넷을 제외한 네트워크를 염두하여 생성
      • 현재는 인터넷의 "IN"만 존재
    • 타입 : 어떤 타입의 정보를 요구하는지 표기
      • A : 도메인의 IPv4 주소
      • AAAA : 도메인의 IPv6 주소
      • MX : 메일의 목적지
      • CNAME : 호스트명에 대응하는 별명
      • NS : 도메인명을 관리하는 DNS 서버
      • PTR : IP 주소에 대응하는 호스트명

Technical_Interview_Network_003_009.png

도메인의 계층, name resolution

  • https://abc.co.kr은 여러 개의 도메인으로 구성되어 있다.
  • 도메인명 : 도메인이 갖는 계층적 구조의 이름
  • abc.co.kr의 경우 kr 도메인 하단의 co 도메인 하단의 abc를 지칭
  • 하나의 도메인을 여러 DNS 서버에 분할 등록은 불가
  • 하나의 DNS 서버에 여러 도메인 등록은 가능
  • 루트 도메인 : 가장 최상단의 도메인으로 루트 도메인의 DNS 서버는 세계에 13개의 IP 주소 존재한다. 보통 국가 코드가 .net, .com 등에 대응되는 정보를 등록
  • 최상위 도메인 : .kr, .jp처럼 국가코드나 .com 등을 지칭한다. 일반적으로 국가 단위로 관리

Technical_Interview_Network_003_010.png

  1. 사전에 지정한 DNS 서버 캐시에 질의한 URL의 정보가 있으면 그대로 회신

  2. client가 네트워크 설정 시 사전에 명시한 DNS 서버로 요청

  3. 요청받은 DNS 서버가 주요 도메인에 질의, 하단의 .com DNS 서버 주소 응답

  4. .com DNS 서버에 질의, def 도메인의 DNS 서버 주소 응답

  5. .def DNS 서버에 질의, .abc 도메인 주소를 갖고 있어 IP 주소 전달

  6. 요청받은 DNS 서버가 클라이언트로 IP 주소 응답

  7. 회신받은 IP 주소를 이용해 통신

  • DNS 서버의 캐싱 : 매번 최상위 도메인에 질의하는 행위는 상당히 비효율적이다. 자주 쓰이는 도메인의 주소는 캐싱해두고 hit될 경우 즉시 응답, miss일 경우 조회하여 조회 비용 절감
    • 정보의 유효성 검증이 필요하므로 주기적으로 최신 상태 업데이트 알고리즘을 적용

DHCP

  • DHCP : 애플리케이션 층의 프로토콜 중 하나로 TCP/IP 설정이 제대로 되어있지 않아 오류가 발생하는 경우를 방지하기 위해 설정을 자동화하는 프로토콜
  • DHCP 클라이언트 : 이용자가 DHCP를 사용해 설정을 자동화하도록 설정한 클라이언트
    • DHCP DISCOVER : DHCP 존재 여부, 사용 가능한 TCP/IP 설정 질의
    • DHCP OFFER : TCP/IP 설정 질의에 따른 설정 제공
    • DHCP REQUEST : 설정 정보(TCP/IP설정)를 사용하겠다는 요청
    • DHCP ACK : REQUEST로 요청한 설정 정보를 사용하게 했다는 응답

+ Recent posts