Jump to:
Navigation

01. Network의 단권화

in Study / Computer Science / Network on Blog

Internet

컴퓨터로 연결하여 TCP/IP Protocol이라는 통신 프로토콜을 이용해 정보를 주고 받는 컴퓨터 네트워크

Protocol

장치 간 통신을 위해 정해놓은 양식 및 규칙의 체계

Network간 전달 방식

  • Circuit Switching Network

    중앙 제어 전달 방식

    기차처럼 중앙에서 관리하는 방식

    중앙에 문제가 생기면 모든 시스템에 영향이 감

    • 전송 방법

      Source to Destination으로 움직일 때 전체 메세지가 Packet들로 나뉘지 않고 전달됨

  • Packet Switching Network

    목적지 주소 전달 방식

    목적지만 정하고 경로 설정 X

    => Internet은 목적지 주소 전달 방식을 채택

    • 전송 방법

      메세지가, Packet들로 나뉘어져서 전송됐다가, Destination에서 다시 결합됨

      TCP/IP의 전송방식

      원래는 Connectionless Service를 기원으로 했으나, 최근에는 Connection-Oriented Service로 바뀌는 경향이 있음

OSI Model

Open System Interconnection

ISO에서 OSI를 만듦

  • OSI 7 Layer

    • 1. Phyical Layer

      • 단위

        Bit

      • 역할

        Bit들을 전송 매체에 전기 신호로 바꾸어서 보내는 것, 인코딩 등 담당

      • 단위

        Frame

      • 역할 및 기능
        • Hop to Hop Delivery를 진행
        • 주소 제어

          이 계층에서 데이터가 추가된 Frame의 Header에는 데이터가 지나온 노드와 다음 노드의 주소(Mac)가 포함됨

        • 순서 제어

          데이터를 순차적으로 전송하기 위해 프레임 번호 부여 기능 수행 및 수신 노드에서 식별 번호를 추가하여 프레임의 순서를 제어

        • 흐름 제어

          한 번에 전송할 수 있는 데이터의 양을 제어하며 연속으로 프레임을 존솔할 때 수신 여부를 확인한느 기능을 수행

        • 오류 처리

          체크섬 등의 에러 검출 기능과 에러 정정 기능을 수행하며 오류가 발생한 경우 프레임의 재전송을 요구할 수 있음

        • 동기화

          Frame의 헤더에는 수신 측의 Frame이 도착했음을 알리는 Bit가 존재하며, Trailer에는 에러를 제어하는 Bit와 Frame의 끝을 나타내는 Bit가 존재

      • Hop to Hop Delivery

        Source to Destination으로 갈 때 한번에 가는 것이 아니라 중간 중간 여러 Network 장비들을 거쳐서 감

        Mac주소 필요

    • 3. Network Layer

      • 단위

        Datagram

      • 역할 및 기능
        • Source to Destination 전달

          IP 주소 필요

        • Routing을 통해 경로를 선택하여 전달

    • 4. Transport Layer

      • 단위

        TCP : segment

        UDP : userdatagram

      • 역할

        신뢰성이 보장되는 Process to Process Delivery를 진행,

        Port 번호 필요

        신뢰성이 보장되는 전송을 진행 (TCP, UDP)

      • Communication

        Layer to Layer Communication

    • 5. Session Layer

      응용 프로그램 계층 사이의 접속을 설정, 유지, 종료하는 역할

      사용자와 전송 계층 간의 인터페이스 역할

      데이터 점검 및 복구하는 동기화 기능 제공

      • 역할 및 기능
        • 동기화

          전송 계층으로 전송할 순서와 전송할 때 수신자 확인이 필요한 곳을 결정

        • 세션 연결 설정 및 종료

          세션 연결의 설정과 종료 및 관리 절차를 정의

        • 대화 제어

          누가 언제 보내는지를 결정

        • Communication

          Layer to Layer Communication

    • 6. Presentation Layer

      데이터 표현의 차이를 해결하기 위해 다른 형식으로 변환하거나 공통 형식을 제공하는 계층

      • 역할 및 기능
        • 암호화

          데이터의 보안을 위해 암호화와 복호화를 수행

        • 압축

          데이터의 효율적인 전송을 위해 데이터 압출 및 압축 해제를 수행

        • 코드 변환

          전송에 사용할 수 있도록 메시지(데이터)를 상호 간에 수용할 수 있는 형식으로 변환한 후 수신자에게 이해할 수 있는 형식으로 변환

      • Communication

        Layer to Layer Communication

    • 7. Application Layer

      End System에서 실행되는 Application 계층 TCI/IP는 Session, Presentation, Application Layer를 합쳐서 Application으로 함

      • Communication

        Layer to Layer Communication

  • Layer 존재 이유

    분업 위해, 효율적으로 Protocol을 디자인 하기 위해서

    만약 특정 계층의 구현이 변경되도 다른 계층에는 영향을 주지 않음

Network 장비

  • Router

    Network와 Network를 연결하는 장비

  • Repeater

    신호가 가다가 약해지면 데이터를 읽기가 어려움

    => 다시 신호를 증폭 시켜줌

  • HUB

    Repeater와 동일한데, 포트(Output)가 여러개 있는 것

  • Bridge

    예를 들어 10번 -> 50번으로 전송해야 할 때 모르면 다 보내야 하지만, 알고 있으면 굳이 다 보낼 필요 없이 50번에게만 보내면 됨

    => Bridge가 Filtering 해줌

  • Switch

    Multi Port Bridge

    위의 3개를 전부 처리함

Mac 주소

6byte의 12진수 값인 Physical Address

Local에서만 유일

Data를 Hop to Hop으로 전송을 할 때 Mac 주소는 과정을 거치면서 바뀌지만, Source와 Destination을 가리키는 IP는 바뀌지 않음

Port 주소

IP주소는 Computer에게 부여되는 번호, 전세계에 하나밖에 없는 주소

한 컴퓨터 안에서 여러 개의 Internet을 사용하는 Program이 실행될 수 있음

각 Program마다 Port 번호를 할당하여 원하는 Program과 통신할 수 있도록 하는 것

16bit를 가지며, 10진법으로 표현함

TCP

  • Full Name

    Transmission Control Protocol

  • 계층

    Transport Layer

  • Stream Delivery

    Application에서 생성된 메세지를 적당한 Byte 단위로 끊어서 보내는 것

  • Buffer

    송신자와 수신자별로 각각의 송신 버퍼, 수신 버퍼가 존재

    송신 버퍼에서 상대에게 보냈다고 바로 비우지 않음

    상대가 못받았을 경우 재전송을 해주기 위함 (Sent 영역)

  • Numbering System

    TCP에서 보내는 데이터마다 숫자를 붙힘

    최초 시작 번호는 랜덤이며, 데이터들의 번호는 Segment의 첫번째 데이터의 Byte 번호

    => Sequence Number

  • ACK

    패킷을 잘 수신했다는 것을 보내는 것

    ACK에 대한 ACK은 없음 (ACK이 잘 갔는지 확인할 방법 X)

    • 종류

      • Selective ACK

        넘겨받은 Sequence Number를 ACK으로 넘기는 방법

      • Cumulative ACK

        앞으로 받고 싶은 Sequence Number를 ACK으로 넘기는 방법

        => TCP/IP 방식

  • Segment Header Format

    • 종류

      • Source Port Address

        Source Port를 가리키는 16bit

      • Destination Port Address

        Destination Port를 가리키는 16bit

      • Sequence Number

        자신의 Sequence Number를 가리키는 32bit

      • Acknowledgement Number

        수신했다는 것을 알려주기 위한 ACK 번호가 적힌 32bit

      • HLEN

        가변적인 Header의 길이를 알려주기 위한 4Bit

        Header는 20~60Byte의 크기를 가지는데, 4Bit로는 15까지 표현 가능

        => 계산한 값 * 4가 진짜 Header의 크기가 됨

      • Reserved

        처음 Design한 구조만으로는 안될 수 있어서 마련해 둔 추가적인 6 Bit

      • URG, ACK, PSH, RST, SYN, FIN
        • URG

          Urgent Pointer가 유효하다는 1Bit

        • ACK

          ACK 번호에 유효한 Data를 실어서 보내는 것이므로 확인하라는 1Bit

        • PSH

          Push 요청 1Bit

        • RST

          연결 리셋 1Bit

          처음에 연결 시 연결 거절을 할 때, 종료할 때 Time Wait 없이 바로 종료할 때 사용

        • SYN

          연결 요청 1Bit

        • FIN

          연결 종료 1Bit

      • Window Size

        Receiving Buffer의 남은 공간을 알려주는 16Bit

      • CheckSum

        패킷들이 전송되다가 물리적으로 Bit들이 바뀌는 등의 오류를 확인하기 위한 16bit

        CheckSum을 제외한 나머지를 16Bit씩 끊어서 다 더했을 때 나오는 값의 보수를 취한 값

        TCP에서는 Checksum이 의무 (UDP는 Option)

      • Urgent Pointer

        16bit

      • Options and Padding

        추가적으로 필요한 내용들이 있을 시 사용

  • Payload

    Segment, Frame 등에서 자신의 Header를 제외한 Data부분을 지칭

  • Connection Setup 과정 (3-way Handshake)

    1. Server 실행

    2. Client에서 Server로 SYN Bit를 1로 설정한 연결 요청 패킷 보냄 (SYN)

    3. Server에서도 Client에게 SYN Bit를 1로 설정 및 Client가 보낸 요청을 읽었다는 ACK (Client가 보낸 패킷의 Sequence Number + 1)을 넣어서 보냄 (SYN + ACK)

    4. Client가 Server가 보낸 요청을 읽었다는 ACK (Server가 보낸 패킷의 Sequence Number + 1)을 서버에게 보냄 (ACK)

  • Termination Setup 과정 (3-way Handshake)

    1. Client에서 Fin이 설정된 패킷 보냄
    2. Server에서 수신했다는 ACK + FIN이 설정된 패킷 보냄
    3. Client에서 수신했다는 ACK 보냄으로써 연결 종료

    Server는 각 Client마다 버퍼를 만들기 때문에 종료할 때 확실히 해서 버퍼를 없애는 과정 필요하기 때문

    • Half Close

      일반적으로 Server는 계속해서 대기하고, Client 쪽에서 먼저 종료 요청을 보냄

      이 때 무조건적으로 Server에서 FIN + ACK을 보내는 것은 아니고, 만약 더 보내야 할 Data가 남았다면 마저 보낸 다음에 다 보내고 나서야 FIN + ACK을 보내게 됨

      이처럼 한쪽은 FIN을 보내고 다른 한 쪽은 아직 FIN을 보내지 않아 완전히 종료가 되지 않은 상태를 Half-Close라고 함

  • Data Transfer

    데이터를 계속해서 보냄

    수신하는 사람은 하나의 패킷이 올 때마다 ACK을 계속해서 보낼 필요 없이, 예를 들어 1~2 데이터가 담긴 패킷을 받고 3~4가 담긴 패킷을 잘 받았다면 ACK을 5로 해서 보내면 됨

    만약 중간에 안받아진 것이 있다면 그걸 ACK으로 설정해서 다시 받으면 됨

    • Normal Operation

      ACK의 갯수를 줄여보고자 위한 RULE

      • 규칙
        1. Data를 받아서 ACK을 보낼 때, Buffer에서 보낼 것이 있는지 확인 후 보낼 데이터가 있으면 같이 보내기
        2. 데이터를 받아서 ACK을 보낼 때 보낼 데이터가 없으면 바로 ACK을 보내지 말고 50ms 만큼을 기다렸다가 그럼에도 데이터가 없으면 그때서야 ACK을 보내기
        3. Rule 2에 의해 기다리고 있는 도중 또 다른 패킷이 들어오면 그때는 더이상 기다리지 말고 ACK을 보내기
        4. 패킷 로스가 일어나는 등 긴급 상황이 일어났을 땐 ACK을 아끼지 말고 바로 보내기 (RTO가 다 지나면 패킷 로스로 간주)
        5. 못받았던 패킷을 받으면 바로 ACK을 보내기
        6. 중복된 데이터를 받아도 바로 ACK을 보내기

  • 전체 과정 Time-line

    • Client

      • SYN-SENT

        SYN을 Server에 보내고 SYN + ACK을 기다리는 구간

      • ESTABLISHED

        Server로부터 SYN + ACK을 받아서, ACK을 보낸 후 FIN을 보내기 전까지의 구간

        본격적으로 Data Transfer가 일어나는 구간

      • FIN-WAIT1

        Server로 FIN을 보내고 ACK을 기다리는 구간

        이 때 Server에서 아직 못 받은 데이터를 받을 수 있음

      • FIN-WAIT2

        Server로부터 FIN이 오기를 기다리는 구간

        만약 FIN-WAIT1 상태에서 Server에서 바로 FIN + ACK을 보냈을 경우 FIN-WAIT2 상태 없이 TIME-WAIT으로 전환

      • TIME-WAIT

        ACK을 보내고 잠시 대기하는 구간

        만약 RST + ACK을 보냈을 경우 TIME-WAIT 없이 바로 종료됨

        • MSL

          Maximum Segment Life

        • 필요한 이유

          1. 마지막으로 보낸 ACK이 제대로 전송되지 않았을 경우를 대비하는 것

            만약 Server측에서 ACK을 받지 못하면, 문제가 있다고 생각하고 다시 FIN을 전송함

            하지만 TIME-WAIT 상태가 없다면 Client는 이미 ACK을 보낸 후 종료헸으므로, 응답을 받지 못함

          2. TIME-WAIT 없이 종료 후 이전 데이터가 넘어오는 것을 대비하는 것

            TIME-WAIT이 없이 바로 종료가 된 후 모종의 이유로 다시 연결을 할 때, 만약 같은 PORT로 연결이 될 때,

            만약 이전 연결 중에 돌아다니던 DATA가 바로 수신되지 않고 DATA가 어디서 헤매면서 돌아다니다가, 새로 연결되고 나서야 도착을 해버리면, 받는 입장에서는 과거의 것인지 지금 요청한 것인지 구분이 어려움

            이것을 구분하기 위해 종료 후에도 바로 닫지 않고 일정 시간 대기했다가 종료함

            (DATA가 Network 상에서 체류하는 시간이 일정시간 이상 넘어가면 소멸됨)

    • Server

      • Listen

        Client가 연결 요청이 오기를 기다리는 구간

      • SYN-RCVD

        Client로부터 SYN 요청을 받아서, SYN + ACK을 전송하고 ACK가 오기를 기다리는 구간

      • ESTABLISHED

        Client로부터 SYN을 받고 본격적으로 Data Transfer가 일어나는 구간

      • CLOSE-WAIT

        Client에게 FIN 요청에 대한 ACK을 보낸 뒤 FIN을 보내기 전까지의 구간

        아직 보내야 할 데이터가 남았다면 이 때 마저 보냄

      • LAST-ACK

        Client에게 FIN을 보내고 ACK을 기다리는 구간

    • Window

      Data Transfer시 Data를 보내고, 그것에 해당하는 ACK을 받고 하는 식으로 하면 신뢰성 있고, 간단하지만, ACK을 Sender가 받을 때까지 Data를 보내지 않고 기다리므로 비효율적임

      => 한꺼번에 보내는게 효율적임 => Window (Byte 단위 크기를 가짐)

      Sender와 Receiver 모두 Window가 존재

      Sender쪽의 Window는 ACK을 받지 않아도 보낼 수 있는 Data의 크기

      Sender의 Window 내에는 보냈지만 아직 ACK이 오지 않은 Outstanding Bytes와 아직 보낼 수 있는 여유 공간이 존재

      Receiver에게서 ACK과 RWND 사이즈를 받으면, 그 크기를 바탕으로 계속해서 Window 사이즈를 수정

      Receiver는 아직 처리되지 않은 Data와, 받을 수 있는 여유 공간이 존재

      Window에는 Sender가 보낼 수 있는 양 (cwnd)와 Receiver가 받을 수 있는 양 (rwnd) 이 있고 Window 사이즈는 이 둘 중 작은 값으로 결정됨

    • Flow Control

      처음에 연결되고 보낼 때, 상대가 받을 수 있는 Buffer의 공간만큼 Data를 보내는데, 이 정보는 Connection을 할 때, 상대가 보낸 패킷의 Window Size를 보고서 알 수 있음 (rwnd)

    • Silly Window Syndrom

      • 정의

        보내는 데이터에 비해서 헤더의 크기가 큰 경우, 비효율적임

        송신 측에서는 보낼 데이터가 조금씩 들어올 경우 신드롬 발생

        수신 측에서는 데이터 처리가 조금씩만 되서 버퍼 내 공간이 조금만 남을 경우 발생

      • Nagle 알고리즘

        송신 측 해결책

        첫번째 데이터는 사이즈와 상관 없이 그냥 보내고, 그 패킷에 대한 ACK이 올 때까지는 데이터를 모으면서 계속 기다림

        만약 MSS(Maximum Segment Size)만큼 모이면 바로 발송

        만약 ACK이 왔으면 데이터가 적더라도 발송

      • Clark 알고리즘

        수신 측 해결책

        MSS만큼 비거나, 버퍼 크기의 절반이 비었을 때만 ACK을 전송하면서 정상적인 윈도우 크기 응답을 보내주고, 아니면 0으로 보냄

      • 확인 응답의 지연

        수신 측 해결책

        ACK 자체를 보내지 않음

        일정 크기 이상의 빈 공간이 생겼을 때 ACK을 보내고, 공간이 비기 전까지는 ACK을 보내지 않음

        => 송신 측에서도 rwnd 만큼 계속 보낸 뒤, ACK이 오지 않으므로 더 이상 보내지 않고 대기

    • SYN Flooding

      Server는 Client에게서 연결 요청이 오면 연결 요청 대기 큐에 적재한 다음, 하나씩 꺼내서 새로운 소켓을 만들어서 연결을 함

      Client가 악의적으로 보내는 쪽의 IP or Port 번호를 바꾸어서 SYN을 보낸 뒤 Server의 SYN + ACK을 받고서 ACK을 보내지 않음으로써 연결 요청 대기 큐가 꽉 차서 정상적인 사용자가 연결을 제대로 하지 못하게 끔 하는 것

      => DoS(Denial of Service) => 이것을 여러 기기에서 하면 DDos (Distributed Denial of Service)

    • 신뢰성 보장

      손실 났거나 순서가 바뀌는 등 이상한 것은 주지 않고, 정상인 것만 TCP가 보내줌

    • Fast Retransmission

      만약 3개의 중복된 ACK이 연속으로 오면, RTO Timer의 시간이 다 되지 않아도 패킷 로스로 간주하고 다시 보냄

    • Lost Acknowledgement

      중간에 ACK이 없어져도 그 다음번 ACK을 통해 문제 없이 진행할 수 있음

      But Clark 해결책 or 진짜로 Window size가 0 이어서 window를 0으로 한 패킷을 보낸 이후, 다시 여유가 생겨서 rwnd를 설정해서 ACK을 보냈는데, 이게 손실되면, Sender 쪽에서는 rwnd가 0이니까 계속해서 기다리고, Receiver 쪽에서는 크기를 설정한 rwnd를 보냈으니까 값이 오길 기다리면서 서로 교착이 생길 수 있음

      • 해결책

        • Persistence Timer

          교착 상태를 해결하기 위하여 사용

          영속 타이머가 만료되면 probe 세그먼트 전송

          => 작은 사이즈의 데이터를 보내보는 것

          => 이를 통해 상대방의 응답이 올 것이므로

          => 만약 rwnd가 0이 아닌 값으로 오면 다시 보내기 시작하면 되고, 0이면 기다리면 됨

        • Keepalive Timer

          오랜 기간 동안 idle 상태에 있는 것 방지

          서버가 2시간 동안 Client로부터 세그먼트를 전송

          받지 못하면, probe 세그먼트 전송

    • Congestion Control

      혼잡제어

      Packet Switching은 중앙에서 경로 설정 및 모니터링 을 하지 않으며 성능에 대한 보장이 되지 않음

      혼잡해지면 패킷을 버림

      딜레이는 처음에는 괜찮다가 Capacity에 가까워지기 시작하는 순간 급격하게 늘어남

      Throughput(읽는 속도) : Capacity까지는 꾸준히 늘어나다가 넘어가는 순간 패킷 로스, 재전송 등으로 인해 네트워크 속도가 감소함

      • Congestion Avoidence

        • Additive Increase

          cwnd를 일정 크기로 잡고 보냈을 때, 온전히 돌아온다면, 하나씩 더 보내보면서 반응이 온전히 돌아오는지를 확인해봄

          이를 통해 아직 혼잡이 생겼는지 아닌지를 파악 가능

          다만 적당량을 알 수가 없고, 1씩 점진적으로 진행하기에는 비효율적일 수 있음

        • Slow Start, Expotential Increase

          보내는 양을 2배씩 늘리면서 확인해보는 것

          => Threshold가 존재해서, Threshold 전까지는 2배씩 증가하지만, 넘어가면서부터는 Additive Increase 방식으로 cwnd를 늘려가면서 진행

          • Slow Start인 이유

            Flow Control은 상대가 받을 수 있는 크기만큼 바로 한꺼번에 보내는 반면, 1..2..4.. 이런 식으로 작은 값부터 시작하기 때문

        • AIMD 방식

          Additive Increase Multiple Decrease

          처음에 Threshold까지는 Slow Start 방식으로 진행하다가, Threshold에 도달하면 Additive Increase 방식으로 전환함

          3ACKS 현상 or Time-Out이 일어나면 패킷 로스로 간주하는데, Time-Out은 심각하다고 가정하고 cwnd를 1 MSS로 설정 및 Threshold 값을 window 사이즈의 절반으로 해서 다시 진행, 3ACKS는 cwnd를 절반으로 줄인 뒤 다시 진행

      • TCP Fair

        Connection 1과 Connection 2가 같은 대역폭을 공유하고 있을 때, RTT가 같다면 처음에 둘의 대역폭 사용량이 차이나더라도, 결국 AIMD로 늘리고 줄이게 되는 과정에서 동등한 대역폭을 사용하게 됨

        window size는 반응을 보고 달라지기 떄문에 RTT에 따라 달라짐

        RTT가 달라지면 1:1로 동등해지지 않음

      • Timer

        • Retransmission

          패킷 로스를 감지하기 위한 Timer

          3 Duplicated ACKS에 의해서도 감지를 하지만 Timer에 의해서도 Detect을 하는데 그 때 사용하는 Timer

          => RTT 바탕

          • RTO

            Retransmission Time Out

            처음은 초기값

            그 이후

            RTO = RTTs(평균) + 4 * RTTd(편차)

          • Smoothed RTT (RTTs)

            처음은 아무 값도 X

            첫 번째 측정 이후 => RTTs = RTTm

            그 이후

            RTTs = (7/8) * RTTs * (기존 평균값) + (1/8) * RTTm(측정값)

          • RTTd

            처음은 아무 값도 X

            첫번째 측정 이후 => RTTd = RTTm/2

            그 이후

            RTTd = (3/4) * RTTd + (1/4) * abs(RTTs-RTTm)

          • RTT

            패킷이 갔다 오는데 걸리는 시간

          • EWMA

            Expotential Weight Moving Average

            가중치를 반영한 평균

            => RTTs와 RTTd는 EWMA지만 RTO는 X (자기 자신에 대한 가중치가 없음)

          • Karn’s Algorithm

            만약 Time Out이 되서 다시 Retransmission을 했을 경우, 시간 측정 기준은 Retransmission을 했을 때를 기준으로 잡아야 함

            하지만 만약 Retransmission을 하자마자 ACK이 들어오고서 Retransmission에 대한 ACK은 모종의 이유로 사라졌을 때 온 ACK이 이전의 transmission에 대한 ACK인지 Retransmission에 대한 ACK인지 알 수가 없음

            => 재전송 되는 패킷은 RTT 계산에 쓰지 말자

        • Persistence

          교착상태를 해결하기 위하여 사용

          rwnd를 0으로 보냈다가 1 이상의 정상적인 값으로 보냈을 때 이것이 손실되어 서로 교착상태에 빠지는 것을 방지하기 위한 Timer

          Timer가 만료되면 probe 세그먼트를 전송

        • Keepalive

          오랜 기간 동안 idle 상태에 있는 것 방지

          비정상적으로 종료가 되어 Fin Fin+Ack Ack 꼴로 종료가 되지 않아서 계속해서 불필요한 연결이 유지되는 것을 방지

          서버가 2시간 동안 Client로부터 세그먼트를 전송받지 못하면 probe 세그먼트 전성

        • TIME_WAIT

          연결 종료 요청하는 대상이 TIME_WAIT에서 기다리는 시간 체크하기 위한 Timer

    • TCP Header Option

      • Single-byte

        • End of option list

          Header는 항상 한줄이 4byte인 구조

          만약 option이 4의 배수로 나뉘어 떨어지지 않을 경우 나머지 뒷공간을 채우는 아무 의미 없는 빈칸 채우기용 옵션

          한줄에 한 번만 쓸 수 있음

        • No operation

          앞 공간을 채우는 아무 의미 없는 빈칸 채우기용 옵션

          EOF와 다르게 여러 번 쓸 수 있음

      • Multiple-byte

        • Maximum segment size

          기본적으로 512byte가 최대 크기지만 Client와 Server가 최초 연결 시 서로 협의해서 조정할 수 있음 그 때를 위한 옵션

        • Window scale factor

          rwnd를 사용해서 receiver window size를 전송하는데, rwnd만으로 대규모의 크기를 표현하기에는 한계 O

          rwnd 크기를 확장하기 위한 옵션

          2 ^ (Window Scale Factor 내부에 Scale factor의 값)을 rwnd에 곱한 값이 실제 rwnd가 됨

        • Timestamp

          RTT Measurement할 때 사용

          보낸 데이터에 대한 ACK이 올 때 패킷 내부에 본인이 데이터를 보냈을 때의 시간이 들어있음

          => 이를 통해 현재 시간과 내부에 들어있는 시간 차를 이용해서 RTTm 측정 가능

          또한 PAWS 용도로도 쓰임

          • PAWS

            Protection Against Wrapped Sequence Number

            Sequence Number를 32bit 크기로 사용하는데, 통신을 주고받다 보면 썼던 Sequence Number를 다시 사용하게 될 수 있는데 늦게 들어온다던지 등의 이유로 기존 것이랑 헷갈림

            => 구분 위해서 Time Stamp Value 이용

        • SACK-permitted

          패킷 손실이 나서 중간에 데이터가 유실되었을 경우, Sender 측에서는 그것 이후로 이미 보낸 패킷들도 다 재전송함 (어느 부분을 받고, 못받았는지 구분 어려움)

          => 패킷 로스 이후의 상황을 파악하기 어려움

          이를 방지하기 위해서 최초 연결 시 옵션으로 설정해서 사용

        • SACK

          블럭 형식으로 ~부터 ~까지 받았는지를 쌓아둠

          => 이를 보고서 어디 어디를 못받았는지를 확인 가능

UDP

  • Boundary Delivery

    Application에서 생성된 메세지 단위로 Segment를 보내는 것

  • 특징

    • Reliability 신경 안씀 (패킷 로스 등, 상대가 응답하든 말든, 버퍼가 꽉 찼든 신경 X)
    • CBD (Constant Bit Rate)로 전송 속도가 일정

IPV4

32bit로 구성된 주소, 보기 편하게 byte 단위로 끊어서 십진법으로 표현한 4개의 숫자로 표현

전세계에서 유일한 주소 (사설망 등 일부 제외)

  • Class of Address

    • A class 주소

      맨 앞의 첫번째 bit가 0이면 A 클래스

      • 범위

        0~127.~.~.~

    • B class 주소

      맨 앞의 2 bit가 10이면 B 클래스

      • 범위

        128~191.~.~.~

    • C class 주소

      맨 앞의 3 bit가 110이면 C 클래스

      • 범위

        192~223.~.~.~

    • D class 주소

      맨 앞의 4 bit가 1110이면 D 클래스

      D 클래스 주소는 Multi casting을 위해서 사용 됨, 참고로 E 클래스는 나중을 위한 것

      • 범위

        224~239.~.~.~

  • Net id and Host id

    IP 주소를 2개로 끊어서 읽을 수 있는데 앞 부분(해당 Network를 대표하는 Id)을 Net id, 뒷 부분을 Host id(같은 Network에서 구분되는 id) 라고 함

    각 Net id별로 Host id를 가지게 되는데, 만약 Host id를 1000개를 사용할 수 있는데, 2개만 사용하면 나머지 998개가 그냥 버려지므로, 효율적으로 쓰기 위함

    => Router는 Network들을 연결하기 때문에, 연결시켜주고 있는 각 네트워크별 주소와 포트의 Mac 주소를 받음

    A 클래스는 Net id가 1 byte, B 클래스는 Net id가 2 byte, C 클래스는 3byte

  • Classful Address

    Class가 있는 주소

    • Network Address

      시작 주소라고도 하며, Host id가 0인 것을 의미함

      Network의 ID처럼 쓰임

    • Special Address

      끝 주소이며, Host id가 모두 (비트로) 1인 주소를 의미

      Directed Broadcast를 위해서 사용하며 일반 Device들에게 할당 X

    • 단점

      딱 필요한 만큼 사용하기가 어려움

  • Routing Table

    • 구조

      • Network Address

        목적지 주소를 가리키는 Network Address 정보

      • Next Hop

        Network Address로 가려면 어디로 가야 하는지를 알려주는 정보

      • Interface

        구분하기 위한 Number

      모든 주소를 담기에는 너무 많음으로, 각 Network의 시작주소를 Network Address에 넣어서 관리

      => 만약 특정 Address에 대한 요청이 오면, Network의 클래스를 파악하고, 해당 Network의 Net id를 찾음

      다만 B 클래스처럼 큰 주소들은 하나의 Network로 관리 X

    • Network의 Net id 구하는 법

      1. 목적지 Address를 보고서 무슨 클래스인지 파악
      2. 클래스를 파악하고서 Net id가 몇 Byte인지 파악
      3. Net id 부분의 bit를 전부 1로 설정하고 Host id 부분은 0으로 설정한 뒤 (Netmask) 목적지 Address와 AND 연산 진행해서 추출

    • NetMask

      Net id 부분은 전부 1, Host id 부분은 전부 0으로 구성되어 있는 32bit 주소

    • SubNet

      B 클래스 주소 같이 큰 주소들은 하나의 Network로 관리 X

      하나의 Network을 세부적으로 Small Group으로 나눔

      이를 SubNet이라고 함

      2^n개의 Subnet을 만들기 위해선 Net id 외 추가적으로 n bit만큼이 필요

      => 외부에서는 SubNet이 있는지 없는지 모름, 단지 해당 Network이 자체적으로 효율적으로 관리하기 위해 설정한 것

      => SubNet을 사용하는 해당 Network와 연결된 Router만 사용한다는 것을 알고서 어떤 IP가 어떤 Subnet에 있는지만 알고 있으면 되고 SubNet이 몇 개로 구성되어 있어서 몇 bit를 봐야 SubNet 주소를 끄집어 낼 수 있는지 알 수 있으면 됨

  • Classless Address

    두 단계로 끊어서 읽는건 Classful과 동일

    단 Classful Address에서는 Byte 기준으로 끊었다면, Classless Address에서는 Bit 단위로 끊음

    또한 앞부분을 prefix, 뒷부분을 suffix라고 함

    Prefix 부분에서 구별 가능한 주소 하나하나를 Block이라고 함

    이제 Class가 사라졌으므로, 끊어읽기를 어떻게 해야 하는지를 알 수 있도록 하기 위해서 주소 뒤에 /prefix length 꼴로 추가적인 정보를 명시해주어야 함

    ex: ~~~/20

    Classless 내부에서도 Subnet을 생성할 수 있고 이때는 prefix length + subnet length까지 포함한 값을 명시해서 구분할 수 있도록 해주어야 함

    만약 각각의 Address 크기가 다른 Sub Group을 만들어야 한다면 Address 크기가 큰 것부터 할당하면서 prefix가 겹치치 않게 설정

  • Special Address

    • 종류

      • Loopback Address

        첫번째 자리가 127로 시작하는 주소

        한 컴퓨터에서 Server와 Client를 실행하고 싶을 때 사용

      • All-Zero-Address

        보통 집에서는 컴퓨터를 킬 때마다 달라지는 유동 IP를 사용

        유동 IP의 경우, 최초에 DHCP 서버에게 어떤 IP를 쓸지 물어보기 위해 패킷을 보낼 때 자기 자신의 주소를 모르기에 source를 0.0.0.0 으로 해서 보냄

        destination은 DHCP Server 주소를 모르므로 전부 1로 설정한 255.255.255.255로 해서 보냄

        • DHCP 프로토콜

          IP를 할당해주는 프로토콜

        • Limited Broadcast Address

          255.255.255.255

          Destination 주소가 모두 1로 되어 있으면 같은 네트워크 내에 불특정 모두에게 전송

          Router는 다른 네트워크로 패킷이 흘러가지 않도록 블럭함

        • Directed Broadcast Address

          Suffix가 다 1인 경우 (모든 것이 1인 Limited Broadcast Address와 차이)

          Router가 자기와 연결된 네트워크 내 모든 장치들에게 보내야 할 것이 있을 때 사용

      • 사설망

        내부적으로 사용하는 망

        ex: 192.168.~.~

  • NAT

    Network Address Translation

    사설망은 사설망을 위한 주소들(유일 X)이 있는데, 사설망에 있는 것에서 바깥으로 패킷을 날리면 해당 IP와 Port 번호를 라우터가 가지고 있는 고유 IP와 임의의 Port 번호로 바꿔서 보내고, NAT translation table에 기록해둠

    밖에서 고유 IP와 Port 번호로 응답을 보내면 Router에서 Port 번호를 보고 사설망의 어디의 몇 번 Port인지 찾아서 전해줌(NAT Translation Table로 들어가서)

  • 랑데뷰 서버

    사설망 내의 Client가 사설망 밖의 Server로 접속할 때는 NAT를 이용해서 변환시켜 보내면 되니까 문제 X

    하지만 Server를 사설망에서 실행하여, 외부의 Client가 사설망 안의 Server로 접속할 때가 문제

    => 먼저 사설망 쪽에서 접근을 했다면 Source Address를 보고서 그대로 전달하면 되지만, 아니라면 알 수가 없음

    랑데뷰 서버에 기록해두어서, 사설망 내부의 기기에 접근할 수 있는 IP 주소를 기록해두어서, 접근하고 싶을 시 랑데뷰 서버를 보고서 파악

    => Hole Punching

    사설망 내부 IP 및 포트와 할당된 IP와 할당된 포트를 기록해둠

  • Port Forwarding

    Port마다 특정 네트워크를 대입

    위의 과정을 매뉴얼화 해놓은

Delivery

  • Direct Delivery

    같은 Network에서 다른 Network로 가지 않고 전달하는 것

    다른 Network에서 넘어와서 Router를 통해서 전달되는 것도 Direct Delivery => Router가 최종 목적지로 전달하는 것

  • Indirect Delivery

    다른 Network로 가기 위해 Router에게 보내는 것

    Router가 Router에게 보내는 것

  • Forwarding

    Routing Table을 보고 일을 하고서 Next Hop으로 갈 수 있게끔 Interface에 Packet을 놓는 것

    => Routing Table도 같이 일을 함

    • 종류

      • Fowarding based on

  • Next Hop Method

    • Routing Tables Based On Route

      Destination과 현재 위치에서 Destination까지 가는데 거치는 모든 Route들을 적어서 보내는 것

    • Routing Tables Based On Next Hop

      Destination과 현재 위치에서 Destination까지 가기 위해 필요한 Next Hop만 적어서 보내는 것

  • Network Specific Method

    특정 Class의 Network의 모든 주소를 관리하는 Routing Table을 만들 수 없기 때문에,

    대표하는 Network에 대한 Next Hop만을 저장해서 관리함

  • Host Specific Routing

    특정 주소는 어떠한 경로로 가라고 구체적으로 적어 놓을 때도 있음

    => 이 때는 Table 안에 Host의 주소가 들어감

    Table안에는 Network주소로만 구성되는 것 X, Host 주소도 있을 수 있음

  • Default Routing

    주변에 있는 Network에 대한 정보만 가지고 있고, 저 멀리에 있는 Network에 대한 정보 가질 필요 X

    특정 네트워크 주소가 아니면 나머지는 이쪽으로 가라는 식으로 Table이 심플하게 구성되어 있음

    Routing Table은 Class 별로 존재

    EX: N1 네트워크에 해당하면 ~, 아니면 ~ 꼴로도 Table을 구성할 수 있음

  • 과정

    1. 주소를 추출함
    2. 주소의 클래스를 찾음 (Classful Address의 경우)
    3. Mask를 적용해 Network 주소 찾아냄
    4. 해당 Class의 Routing Table로 가서 정보를 찾아냄
    5. ARP로 Mac주소를 찾아냄

      • ARP

        MAC 주소 찾는 Protocol

  • Address Aggregation

    Router에는 주소에 대해서 Next Hop으로 가려면 어디로 가야하는지 Interface를 가리켜 줌 다만 예를 들어 11.1.0, 11.1.1, 11.1.2, 11.1.3 처럼 주소가 있고 이것들이 우연히 모두 같은 Interface로 간다면, 굳이 각각에 대한 것을 적지 않고 11.1에 대해 해당 Interface에 가라는 식으로 저장할 수 있음 => SubNet 개념은 X

    이런 식으로 Routing Table의 크기를 줄일 수 있음

    만약 우연히 똑같이 11.1로 시작하는데 다른 Interface로 가야한다면, 우선적으로 해당 경우에 대해서 체크 를 하는 식으로 진행

    Routing Table은 기본적으로 가장 위에 있는 것부터 확인하게 되는데, 상단에 먼저 체크해야 할 것을 올려놔서 체크를 할 수 있도록 함

  • MPLS

    Multi protocol Label Switching

    => 기존의 방식은 Routing Table이 주소를 Table에서 순차적으로 탐색해가면서 해야 해서 오래 걸리는 문제 있었음

    Header를 수정 => Ethernet과 IP Header 사이에 MPLS Header를 삽입

    In Label, Out Label, Destinaton, Out Interface가 존재하고, 자신과 연결된 곳에서만 유효한 Number를 지정해서,

    In으로 ~번 Label이 들어오면 ~번 Label로 보낼 거라는 걸 알 수 있게 함

    Destination이 같이 있어서 ~로 보낼거면 ~label로 보내야 한다는 것을 알 수 있게 함

    쉽게 얘기해서 ~로 가고 싶다면 ~ Interface로 설정을 해서 보내라 하는 식으로 구성되어 있음

Web and Http

  • WEB Page 정의

    다양한 Object들로 구성

    Object : HTML File, JPEG 등

    기본적으로 HTML로 구성 및 다양한 Object들 포함

  • HTTP

    HyperText Transfer Protocol

    Application Layer에 존재하는 Protocol

    HTTP는 TCP를 사용

    HTTP는 Stateless

    • Connection 종류

      • Non-persistent

        연결을 지속하지 않는 방식 사용자는 HTML을 받으면 그걸 파싱해서 화면에 뿌려줌

        만약에 10개의 Object들을 받아야 하면, 각각 Object 하나에 대해서 주고 받고를 확인하면서 진행

        하나의 Object 파일에 대해서 왔다 갔다 하므로 2*RTT만큼의 시간이 걸림

      • Persistent(HTTP 1.1)

        Non Persistent HTTP의 문제 때문에 Persistent 방식으로 변경

        종료를 바로 하지 않고 나중에 함

        • 방식
          • No Pipelining

            연결은 종료되지 않지만, 하나의 파일을 받으면 다음 파일을 요청하고 받는 식의 방식

          • Pipelining

            연결이 종료되지 않으면서, 전에 요청했던 파일 수신 여부와 상관없이 필요한 데이터들을 바로바로 요청

            기본적으로 Server는 파일을 보내도 TCP를 바로 끊지 않고 살려두고 Client는 뒤에 오는 Request를 종료되지 않은 Connection으로 바로 보냄

        • 단점
          • HEAD OF BLOCKING

            앞에 있는 데이터가 크면 뒤에 있는 데이터는 앞에 있는 데이터를 다 받기 전까지는 못받음

    • HTTP 2.0

      보내야 하는 Object들을 Frame으로 나누고, 한번 보낼 때, 파일 별로 순차적으로 Frame을 균등하게 보냄

IPv4

Network Layer의 Protocol

  • IPv4 Datagram 구조

    • Total Length

      Header와 Data를 포함한 전체 길이가 무조건 46바이트 이상이 되어야 함

      근데 46바이트 이상이 되지 못하면, 뒤에 Padding을 붙혀서 강제로 46바이트를 맞춰줘야 함

      단 이 때 뒤에 남은 Padding은 유효한 데이터가 아님을 알 수 있도록 해야 함

      => 전체 길이를 알려주어야 함 => 16bit의 Total length에 표기

    • Time to Live

      Hop to Hop을 얼마나 할 건지 설정

      목적지에 가지 못하고 Loop 되는 것을 막고 자동 소멸될 수 있도록 하기 위함

    • HLEN

      4bit의 헤더 길이 알려주는 것

      HLEN값 * 4를 해야지 실질적인 Header길이 알 수 있음

    • MTU

      Maximum length of data

      허용할 수 있는 IP Datagram의 Maximum이 틀림

      만약 Maximum이 작아서 패킷들을 분할해서 보내야 할 때면 Data 부분만 분할되고 헤더는 분할이 안됨

    • Flag Field

      3bit인데 상위 1bit는 쓰지 않고 뒤에 있는 두 bit만 사용

      분할할 지 말지 설정하는 옵션

      • D 옵션

        Do not fragment

        크기가 한번에 다 안들어가면 분할을 해야 함

        다만 분할을 하지 말라고 이 옵션이 켜져 있는데, 한번에 다 안들어가면 그냥 버려버림

      • M 옵션

        More fragment

        만약 Fragment로 다 쪼갠 다음 목적지에 모여서 조합을 할 때, 쓰이는 필드

        만약 Fragment로 나눌 경우 Strict Source Route와 Loose Source Route 옵션은 Fragment에도 복사되지만 나머지는 복사되지 않음

        => 만약 이게 켜져 있다면 아직 뒤에 더 올 수 있는 fragment가 있다는 것

        => 마지막 패킷을 구분하기 위해 쓰는 것

    • Fragmentation offset

      다만 Move Fragment가 켜져 있을 때 이게 처음 패킷인지 중간 패킷인지 알 방법이 X

      => Fragmentation Offset으로 구분

      최대 패킷 크기는 6만~까지 65535까지 보낼 수 있는데, 13bit로는 대략 8천정도까지밖에 포함 안됨

      => Fragmentation Offset * 8정도로 계산하면 모든 구역을 표현할 수 있음

      => Fragmentation Offset * 8로 실제 Offset을 계산할 수 있음

      보낼 땐 시작 위치를 8로 나눈 값을 Fragmentation Offset으로 설정해서 보냄

    • Identification

      Sequence Number처럼 번호 붙임

      손실 여부 아닌 재조합 목적

    • Option

      • 종류
        • Single Byte

          둘 다 빈 공간 채우는 용

          • No Operation
          • End of Option
        • Multiple Byte
          • Record Route

            어디를 지나서 왔는지를 기록할 수 있는 옵션

            Router가 나가는 쪽의 주소를 쓰게 됨

          • Strict Source Route

            가는 경로를 패킷에 써주는 방식

            원래는 보내는 쪽 주소와 받는 쪽 주소만 받고 보내게 되지만, 이 옵션을 키면 가는 경로를 부여할 수 있음

            그리고 도착하면 포인터로 가리키고 있던 곳의 주소와 Destination을 바꾸면서 진행함

            => 자연스럽게 경로를 설정했던 공간은 도착하고 나면 내가 지나왔던 곳들을 기록한 곳으로 바뀌게 됨

            경로가 없으면 그냥 버려버림

          • Loose Source Route

            경로를 지정하긴 하지만 Strict와 달리 경로 사이사이에 다른 곳을 들렀다가 가도 됨

            => 당장 다음 경로 안보인다고 버리지 않음

          • Time Stamp

            기본적으로 출발할 때의 시간을 적는데, 옵션에 따라서 적을 정보가 조금씩 달라짐

            • 옵션
              • 시간만
              • IP주소랑 시간
              • IP주소는 주어졌고, 시간만 적음

  • Network 설정 필요 요소

    • IP주소

    • Subnet Mask

    • Next hop

    • DNS 서버 주소

  • IP Checksum, TCP Checksum 차이

    IP header checksum은 IP 헤더에 대해서만 check함 TCP checksum은 TCP 헤더와 payload(데이터)까지 check함

  • Ping

    Ping을 쓰는 이유는 RTT를 측정하기 위함도 있지만, Domain의 서버가 Network에 연결되어 있는지 안되어 있는지를 확인하는 용도

    -R 옵션을 주면 record route 옵션 가능

  • traceroute

    Record Route + domain name까지 가는 RTT를 3번 구함

    -g 옵션을 주면 loose source route가 됨

    -G 옵션을 주면 strict source route가 됨

  • Reassembly table

    ID가 있는 패킷들을 리스트로 관리하는데, Timeout 값이 정해져 있고 시간이 지나면 재조립 못함, 가지고 있던 거 다버림

    TCP 크기를 크게 하면 데이터를 많이 옮길 수 있어서 좋아보이지만, TCP가 크면 fragmentation을 더 잘게 해야 하고 그러면 패킷 로스가 일어날 확률이 늘어나며 감지 시간도 오래 걸림

© 2025. Na2te All rights reserved.