네트워크 학습 내용 순서

1. [TIL]Web Application Basic study: OSI 7 layer outline
2. [TIL] Network OSI 7 layer: 1계층
3. [TIL] Network OSI 7 layer: 2계층
4. [TIL] Network OSI 7 layer: 3계층

이번 장에서는 전송(Transport) 계층인 4계층에 대해 알아보자.

❗️ 패킷(packet)이란 용어에 대해서
패킷이란 용어는 3계층의 데이터 단위임을 학습했다. 하지만 이 ‘패킷’이란 용어는 네트워크 전체적으로 데이터를 지칭하는 용어로도 사용되기도 한다. 그래서 이번 4계층 학습에서 언급되는 패킷들은 세그먼트가 맞지만, 3계층에서 IP 패킷으로 캡슐화되기 때문이거나 범용적으로 데이터를 나타내는 용어라고 생각하자.

1. Transport 전송 계층 개요

3계층은 한 네트워크에서 다른 네트워크로 데이터를 전송하는 과정에 중점을 두고 맞춰져있다. 그러나, 네트워크 환경은 기본적으로 비신뢰성 환경이기 때문에 전송된 패킷이 정상적응로 전달되지 않을 수도 있고, 중간이 패킷이 유실되거나 손실될 수도 있다. 또한, 여러 패킷으로 나눠서 전달될 때 순서가 잘못될 수도 있다.

이에 대한 해결책으로 4계층은 목적지에 신뢰할 수 있는 데이터를 전송할 수 있는가? 에 초점을 맞춘다. 이에 따라 역할, 전송방식이 정해진다.

1) 4계층의 역할

• 목적지까지 신뢰할 수 있는 데이터를 전송하는 역할
• 오류 점검 및 데이터의 목적지가 어떤 애플리케이션인지 식별하는 역할

2) 4계층의 전송 방식

위 역할에 따랏 4계층의 전송 방식은 ‘연결형 통신’ 과 ‘비연결형 통신’ 2가지로 나눠진다.

• 연결형 통신

  • 신뢰성과 정확성
  • 연결 필요
  • 사용되는 프로토콜: TCP (Transmission Control Protocol)
  • stateful

• 비연결형 통신

  • 효율성: 빠르게
  • 일방적인 통신 (연결 불필요)
  • 사용되는 프로토콜: UDP ex) 동영상 스트리핑 서비스
  • stateless

3) 4계층의 캡슐화, 역캡슐화 그리고 데이터 단위

4계층은 TCP 헤더 의 캡슐화, 역캡슐화가 일어나는 계층으로 이 때 데이터 단위는 segment(세그먼트) 다.

• TCP header + Application header + User data

❗️ 다시 한번 언급: 패킷(packet)이란 용어에 대해서
패킷이란 용어는 3계층의 데이터 단위임을 학습했다. 하지만 이 ‘패킷’이란 용어는 네트워크 전체적으로 데이터를 지칭하는 용어로도 사용되기도 한다. 그래서 이번 4계층 학습에서 언급되는 패킷들은 ‘세그먼트’가 맞지만, 3계층에서 IP 패킷으로 캡슐화되기 때문이거나 범용적으로 데이터를 나타내는 용어라고 생각하자.

2. TCP segment

TCP segment는 응용 계층의 데이터에서 TCP 헤더를 캡슐화하거나, 네트워크 계층의 패킷에서 IP 헤더를 역캡슐화를 하면 되는 데이터 단위다.

이 TCP 헤더에는 여러 정보들이 담겨있지만 주요 필드만을 언급하자면 다음과 같다.

• 출발지 포트 번호, 목적지 포트 번호
• 일련 번호, 확인 응답 번호
• TCP 플래그, 윈도우 크기

더 자세한 필드는 다음과 같다.

• 출발지 포트 번호 (16 bit), 목적지 포트 번호 (16 bit)
• 일련 번호(sequence number) (32 bit)
  • 송신자가 지정하는 순서 번호
  • 고유한 번호
• 확인 응답 번호(acknowledgement number) (32 bit)
  • 데이터를 정상적으로 수신했을 시 보내는 번호
  • 일련 번호에 1을 더한 값이므로, 다음 데이터의 일련 번호라고도 볼 수 있다.
  • 일련 번호 + 1
• 헤더 길이(header length) (4 bit)
  • 옵션 필드가 가변적이라서 정확히 헤더의 길이를 파악하기 위해 사용
• 예약 영역 (6 bit)
  • 나중에 사용하기 위해 남겨둔 영역
• TCP 플래그 (코드 비트) (6 bit)
  • 6개 비트로 구성: SYN, ACK, FIN, URG, PSH, RST
  • 3 way handshake와 4 way handshake 와 관련
• 윈도우 크기(window size) (16 bit)
  • 한 번에 전송할 수 있는 데이터의 양
  • TCP 흐름 제어와 관련
• 체크섬(checksum) (16 bit)
  • 데이터를 보내는 중에 발생할 수 잇는 에러를 항상 검사하는데, 데이터에 대해 체크섬 방식으로 계산한 결과값을 이 필드에 저장
• 긴급 포인터(urgent pointer) (16 bit)
  • TCP 플래그의 코드 비트 URG 비트 설정과 함께 사용
• TCP 옵션

❗️ IP 헤더는 포트 번호가 아닌 ‘출발지/목적지 IP 주소’ 였던 것을 기억하자.

3. 3-way handshake & 4-way handshake

3.1 TCP flag (code bit)

위 2개의 handshake 는 TCP 헤더의 TCP flag 코드 비트 와 관련있다.

TCP의 연결 확립 과정과 연결 종료 과정에서 TCP flag 코드 비트가 중요한 역할을 한다.

그러면 코드 비트에 대해 자세히 확인해보면 다음과 같이 6 bit가 존재한다.

각 1bit를 의미한다. 각 초기 비트 값은 0이며 각 과정에서 활성화되어 1로 바뀌어 전송된다.

그리고 각 단어는 다음 의미를 가진다.

• URG: Urgent

• ACK: Acknowledgement

• PSH: Push

• RST: Reset

• SYN: Synchronize

• FIN: Finish

3.2 3-way handshake

TCP는 연결을 확립하기 위해 3-way handshake 과정을 거친다. 이 때 SYN, ACK 두 비트를 사용한다.

이 과정의 총 세 단계 순서는 다음과 같다.

상황: 클라이언트와 서버가 존재하고, 클라이언트가 서버에 ‘세션 연결 확립’을 위해 요청을 보내려는 상황

1) 연결 요청 - client –> server with SYN: 1

클라이언트가 서버에게 연결 확립을 요청한다. 이 때 SYN이 1로 활성화된 세그먼트를 서버에 전송한다.

2) 확인 및 연결 요청 - client <– server with SYN: 1, ACK: 1

클라이언트가 보낸 세그먼트를 서버가 확인하면서 서버에서도 연결을 요청하기 위해 SYN과 ACK bit가 1로 활성화된 세그먼트를 클라이언트에게 보낸다.

3) 확인 - client –> server with ACK: 1

서버가 보낸 세그먼트를 클라이언트가 확인하고, 이에 응답하기 위해 ACK bit가 1로 활성화된 세그먼트를 서버에게 보낸다.

3.3 4-way handshake

TCP는 연결을 종료하기 위해 4-way handshake 과정을 거친다. 이 때 FIN, ACK 두 비트를 사용한다.

상황: 클라이언트와 서버 간 연결을 종료하기 위해 요청을 보내려는 상황

1) 연결 종료 - client –> server with FIN: 1

클라이언트가 서버에게 연결 종료를 요청한다. 이 때 FIN이 1로 활성화된 세그먼트를 전송한다.

2) 확인 - client <– server with ACK: 1

서버는 클라이언트에게 연결 종료에 대한 응답을 하기 위해 ACK이 1로 활성화된 세그먼트를 전송한다.

3) 연결 종료 - client <– server with FIN: 1

서버도 클라이언트에게 연결 종료를 요청한다. 이 때 FIN이 1로 활성화된 세그먼트를 전송한다.

4) 확인 - client –> server with ACK: 1

클라이언트는 서버에게 연결 종료에 대한 응답을 하기 위해 ACK이 1로 활성화된 세그먼트를 전송한다.

3.5 handshake의 캡슐화와 역캡슐화

handshake 과정도 캡슐화와 역캡슐화가 진행된다.

3-way handshake

A 컴퓨터와 B 컴퓨터의 3-way handshake 과정을 들어보자.

1. A 컴퓨터에서 ‘캡슐화’를 통해 SYN 비트가 1로 활성화된 데이터를 ‘전송’

2. B 컴퓨터에서 ‘역캡슐화’를 통해 SYN 비트가 1로 활성화된 데이터를 받았음을 ‘확인’

3. B 컴퓨터에서 ‘캡슐화’를 통해 다른 세그먼트로 SYN 비트 + ACK 비트가 1로 활성화된 데이터를 ‘전송’

4. A 컴퓨터에서 ‘역캡슐화’를 통해 SYN 비트 + ACK 비트가 1로 활성화된 데이터를 받았음을 ‘확인’

5. A 컴퓨터는 ‘캡슐화’를 통해 마지막으로 ACK 비트가 1로 활성화된 데이터를 ‘전송’

4-way handshake

A 컴퓨터와 B 컴퓨터의 4-way handshake 과정을 들어보자.

1. A 컴퓨터에서 ‘캡슐화’를 통해 FIN 비트가 1로 활성화된 데이터를 ‘전송’

2. B 컴퓨터에서 ‘역캡슐화’를 통해 FIN 비트가 1로 활성화된 데이터를 받았음을 ‘확인’

3. B 컴퓨터에서 ‘캡슐화’를 통해 FIN 비트가 1로 활성화된 데이터를 ‘전송’

4. A 컴퓨터에서 ‘역캡슐화’를 통해 FIN 비트가 1로 활성화된 데이터를 ‘확인’

이 과정 뿐만 아니라 컴퓨터의 모든 데이터는 전송할 때 캡슐화해서 전송하고, 받은 데이터를 뜯어볼 때는 역캡슐화한다고 보면 된다.

🔆 나중에 wireshark 프로그램을 다운로드 받으신 후 패킷 분석을 해보자.

4. TCP 에러 제어

에러 제어 개요

TCP는 전송된 세그먼트가 손실되거나 순서가 어긋났을 때 혹은 중복되었을 경우, 이에 대한 처리를 수행하는데 그 중 하나의 방법이 TCP 에러 제어 다. 이 제어를 통해 신뢰성 있는 데이터를 전송한다.

에러 제어는 에러를 검출(detection)한 후, 에러를 정정(correction)하는 과정을 거친다. 에러 검출과 에러 정정 과정에는 다음과 같은 방법들이 존재한다.

• 에러 제어
  • 에러 검출(detection)
    • CRC (Cyclic Redundancy Check)
    • Checksum(체크섬): TCP 헤더의 체크섬 필드가 데이터에 대한 에러를 검사하는 기능이 있어, 세그먼트가 전송되는 도중 에러 발생 유무를 확인
  • 에러 정정(correction): ARQ(Automatic Repeat reQuest) 방식을 사용하며, 이 방식의 종류는 다음과 같다.
    • Stop and Wait ARQ
    • Go-Back-N ARQ
    • Selective Repeat ARQ

그러면 에러 정정 방법들에 대해 자세히 알아보자.

에러 정정: Stop-and-Wait ARQ

매번 전송한 패킷에 대해 확인 응답을 받고 나서 그 다음 패킷을 전송하는 방식이다. 만약 일정 시간 동안 ACK을 받지 못하여 Timeout이 되었을 경우, 해당 패킷부터 재전송한다. 또한, 패킷 간 식별을 위해 0과 1의 패킷 혹은 ACK를 번걸아 가면서 전송한다.

확인 응답을 받을 때까지 멈춰서 기다리는 방식이기 때문에 비효율적이다.

위 그림을 기준으로 설명하자면 1, 2, 3번 패킷으로 구분되는 것이 아니라 0, 1, 0, 1번으로 구분된다.

에러 정정: Go-Back-N ARQ

패킷이 도착하지 않아 타임아웃되었을 시, 이 패킷부터 다시 차례대로 재전송하는 방식이다.

위 그림을 통해서 구체적인 예시를 들어보자.

A 에서 패킷 0번, 1번, 2번 패킷을 전송한다. 이중 1번을 제외한 패킷들을 수신했다. 수신한 패킷에 대해 ACK을 보내는데 1번 패킷을 받지 못 했으므로, 그 이후에 2번, 3번 패킷을 B가 받아도 받은 패킷을 폐기한 후, 0번 ACK을 B가 재전송한다. 1번 패킷에 대한 확인 응답 ACK이 도착하지 않아 타임아웃되어 A가 패킷을 재전송할 때 다시 순서대로 1번 패킷, 2번 패킷, 3번 패킷을 보낸다.

이처럼 뒤로 돌아가서 순서대로 다시 재전송하는 방식을 Go-Back-N 재전송 방식이다.

에러 정정: Selective Repeat ARQ

패킷이 도착하지 않아 타임아웃되었을 시 수신하지 못한 패킷만을 선택적으로 재전송하는 방식이다.

수신한 패킷에 대해 선택적으로 ACK 전송이 가능하며, 선택적 전송이 가능한 이유는 중간 패킷이 수신되지 못했을 경우 소실된 패킷 이후 패킷을 버퍼에 기록하기 때문이다. 소실된 패킷에 대한 확인 응답이 A에게 도착하지 않아 타임아웃되면 A에서 소실된 패킷이 재전송된다.

소실된 패킷이 도착되면 소실된 패킷과 그 이후에 보내진 패킷들을 함께 상위계층으로 올린다.

위 그림을 기준으로 설명해보자.

• A에서 초기에 0번, 1번, 2번 패킷이 전송된다. B에 정상적으로 도착한 건 1번 패킷을 제외한 나머지다.
• B에서는 수신한 패킷에 대해 선택적 ACK을 전송한다.
• 1번 패킷을 받지 못 했으므로, 1번 패킷 이후의 패킷은 버퍼에 저장된다.
• A에서는 이어서 3번, 4번 패킷이 전송된다. B에 정상적으로 도착했고, 이를 버퍼에 저장한다. 그리고, 이에 대해 선택적 ACK인 3번 ACK, 4번 ACK을 전송한다.
• 1번 패킷에 대한 확인응답이 A에게 도착하지 않아 타임아웃되면 A에서는 1번 패킷을 재전송한다.
• B에서는 이에 대한 1번 ACK을 전송하여 A는 확인응답을 받는다.
• B는 1번 패킷과 함께 버퍼에 저장된 2번, 3번, 4번 패킷을 상위 계층에 전송한다.

5. TCP 흐름 제어(TCP Flow Control)

송수신지의 데이터 처리 능력이 달라서 데이터가 유실될 수가 있는데 이를 방지하는 기법이다.

흐름 제어 기법에는 두 가지 방법이 있지만, 주로 슬라이딩 윈도우 기법을 사용한다.

• Stop-and-Wait
• 슬라이딩 윈도우(Sliding window): 윈도우 광고 기법

Stop-and-Wait

Stop-and-Wait은 ‘TCP 에러 제어 챕터’ 에서 설명한 것처럼 모든 패킷에 대해 확인 응답을 받아야만 다음 패킷을 전송하는 방식이기 때문에 비효율적이라는 단점이 있다.

Sliding window

반면 슬라이딩 윈도우는 송수신지에 있는 슬라이딩 윈도우 를 활용하는 방식으로 Stop-and-wait 방식과 달리 송신측에서 응답을 받지 않아도 연속적으로 전송할 수 있다. 단지 연속적으로 전송하는 게 아니라 송수신측의 윈도우 크기를 서로 알려주기 때문에 데이터 유실을 방지할 수 있는 방식이다.

즉 슬라이딩 윈도우 방식은 수신측과 송신측의 윈도우 크기를 서로 알리면서 윈도우 크기가 변한다. 먼저 윈도우 에 대해 알아보자면 송수신 각 측에서 만들어진 버퍼의 크기를 말한다.

• 송신측 윈도우: Congestion window로, ‘Cwnd’ 라고 표기
• 수신측 윈도우: Receiver window로 ‘Rwnd’ 라고 표기

그러면 슬라이딩 윈도우 기법을 통한 TCP 흐름 제어를 살펴보자.

위 이미지와 아래 설명을 함께 보자.

송수신측의 윈도우 크기 모두 250이라 가정해보자.

• (0 - 250)

1. 송신지(A)에서 100 바이트 데이터를 수신측(B)에 보낸다.

2. B에서는 이 데이터를 받아 버퍼에 저장했기 때문에, 수신측 윈도우 크기는 250에서 ‘150’이 된다. 그리고 좌측 윈도우 경계선은 101로 이동된다. (101 - 250)

3. 그리고, B에서 확인 응답으로 ‘ACK 101’ 과 수신측의 현재 윈도우 크기 150을 보낸다.

• 101인 이유는 100바이트 데이터를 수신했기 때문에 그 다음 시퀀스 번호를 나타내기 위해서다.

4. A에서 이 정보를 받아 동일하게 101부터 시작해서 윈도우 크기를 150에 맞추고, 시작 경계선을 101로 맞춘다.

• 송신지 윈도우의 크기는 수신지 윈도우 크기에 맞춰서 수신측이 받을 수 있도록 크기를 맞춘다.

5. 맞춘 후, A에서 다시 B에게 50 바이트를 전송한다.

6. B에서 50 바이트 데이터를 버퍼에 저장한다. 윈도우 크기는 100으로 줄어들고, 좌측 윈도우 경계선이 151로 이동된다. (151 - 250)

7. 하지만 응용 프로세스가 B의 윈도우에 저장된 50 바이트 데이터를 처리하여 윈도우는 (151 - 300) 으로 이동되어 윈도우 크기는 150으로 늘어난다.

• 이 때 응용 프로세스가 저장된 데이터를 사용할 때 FIFO 방식으로 처리하기도 하지만, 마지막으로 받은 데이터를 처리하기도 하므로 처리되는 데이터의 순서는 때에 따라 다르다.

8. B에서 A에게 확인 응답 ACK 151 과 window 크기는 150이라는 정보를 전달한다.

9. B에서 보내진 정보를 A가 받아 B 윈도우 크기에 맞춰 A도 수정한다.

위와 같은 작업 방식으로 진행된다.

6. TCP 혼잡 제어

TCP 혼잡 제어는 네트워크 내의 데이터를 조절하여 오버플로우(overflow) 현상을 방지하는 기술 이다. 보다 구체적으로 얘기하자면 다음과 같다.

네트워크는 항상 잔잔한 상태가 아니다. 때로는 데이터의 수가 과도하게 증가하기도 하고, 데이터가 유실되기도 한다. 이런 상황을 혼잡 상황 이라 하는데, TCP는 이 혼잡 상황을 방지하거나 해결하는 제어 기능을 제공한다.

혼잡 상황이 발생하기 전과 후에 따라 제어 방식이 각각 다르다.

• 혼잡 상황 발생 전 제어 방식: 혼잡 회피
  • Slow Start
  • Additive Increase
• 혼잡 상황 발생 후 제어 방식: 혼잡 상황 해결
  • Multiplicative Decrease: ssthresh 값을 cwnd 1/2로 축소

TCP가 혼잡 상황으로 인식하는 경우

TCP가 어떤 기준으로 ‘혼잡 상황’을 인식하냐면 다음과 같이 2가지 경우에 ‘혼잡 상황’으로 인식한다.

• 세그먼트를 송신하고 타임아웃되어 재전송하는 경우
• 동일한 ACK을 3번 이상 수신하는 경우

1. 세그먼트를 송신하고 타임아웃되어 재전송하는 경우

1. TCP는 segment들을 slow start 방식으로 하나씩 전송한다. 이 때 cwnd의 값은 1이다.

2. 전송하기 시작할 때 cwnd의 값은 1이며, 1, 2, 4, 8 식으로 윈도우의 값을 지수적 증가 방식으로 윈도우 크기를 늘려 점점 세그먼트 수용량의 임계치를 늘려간다. (지수 그래프를 생각하자)

• 이 때 임계값은 Slow Styled Threshold, SSThresh 라는 단어를 사용한다.
• 그래서 SSThresh = 1, 2, 4, 8, 16 으로 임계치를 늘려간다.

3. cwnd가 점점 높아지면서 송신지가 설정한 임계값에 도달하여 혼잡 상황으로 갈 위험이 높다고 TCP가 판단하면 ‘Additive Increase’ 기법을 적용한다.

• Additive Increase 기법은 cwnd를 하나씩 증가하면서 혼잡을 회피하는 방식

4. 이 방식을 사용하다가 결국 혼잡 상황을 감지하면 cwnd를 다시 1로 수정하고, 송신지가 설정한 임계값의 수치를 혼잡이 감지된 SSThresh 값의 절반으로 설정한다. 즉, Multiplicative Decrease을 적용한다.

5. 다시 Slow Start와 Additive Increase 방식을 적용한다.

❗️ RTT(Round Trip Time): 네트워크 요청을 시작한 후 응답을 받는데 걸리는 시간

2. 동일한 ACK을 3번 이상 수신하는 경우

1. 이 상황에서는 Multiplicative Decrease을 적용한다.

2. 이후에는 Additive Increase 방식으로 slow start는 안하고, Additive Increase(혼접 회피)만 수행한다. 즉 cwnd가 지수적 증가를 하지 않는다.

7. 포트 번호

전송 계층(transport layer)는 연결 확립을 하고, 재전송도 가능하고, 버퍼를 통한 제어도 가능한 계층이다. 이 외에도 보내지는 데이터가 어느 어플리케이션에게 가야하는지 구분하는 기능도 가진다.

포트 번호가 바로 데이터의 목적지가 어떤 어플리케이션인지 구분 하는 기능 을 가진다. 네트워크 계층인 3계층에서는 데이터를 전송하기 위해서 상대방의 IP 주소를 필요로 했다면 전송 계층의 포트 번호는 어떤 애플리케이션이 사용되고 있는지 구분해주는 역할을 한다.

3계층인 네트워크 계층에서의 IP 헤더에는 출발지 IP 주소와 목적지 IP 주소가 있다. 그리고 현재 학습 중인 4계층인 전송 계층에서의 헤더에는 ‘출발지 포트 번호’ 와 ‘목적지 포트 번호’ 정보를 가진다.

그러면 미리 알아두면 좋은 포트 번호에 대해 정리해보자.

8. UDP (User Datagram Protocol)

앞선 내용들을 학습하면서 TCP는 신뢰성과 정확성에 초점을 두고, UDP는 효율성에 초점을 둔다고 했다. 그래서 TCP는 연결 확립 절차를 거치고, UDP는 비연결형 통신으로 동영상 스트리밍 방식에 사용된다.

TCP segment처럼 UDP 헤더가 데이터에 붙게되면 UDP 세그먼트 라고 칭한다.

• UDP segment = UDP header + 응용 헤더 + User data

그러면 UDP header에 대해 봐보자. TCP 헤더와 달리 UDP 헤더는 간단하다. 다음과 같다.

그래서 이 헤더에 있는 포트 번호를 통해 특정 애플리케이션에 UDP 세그먼트를 보낸다.

TCP 세그먼트는 3 way handshake와 4 way handshake 과정을 통해서 연결을 확립하고 종료하는 과정을 거쳤지만, UDP segment 송신은 그런 절차 없이 일방적으로, 일괄적으로 보낸다.

UDP의 이런 특성 때문에 LAN 안에 있는 모든 컴퓨터의 데이터를 일괄적으로 보낼 수 있다. 그래서 UDP는 이러한 브로드캐스트 방식의 통신에 적합하다. 하지만 TCP는 연결 확립 및 종료 과정이 있기 때문에 이 방식에는 적합하지 않다.

그래서 UDP에 대해 정리하자면 다음과 같다.

• 효율성
• 비연결형 통신으로 연결 확립 절차 x
• 브로드 캐스팅 전송

Reference

• 나노디그리 러닝스푼즈: Python & Django backend course
• 네트워크, 그림으로 이해해자