Skip to content

Latest commit

 

History

History
247 lines (148 loc) · 10.5 KB

06장_신뢰할 수 있는 데이터 전송하기_백유진.md

File metadata and controls

247 lines (148 loc) · 10.5 KB
Raw

6장. 신뢰할 수 있는 데이터 전송하기

전송 계층의 역할

1. 전송 계층의 두 가지 역할

1

1) 목적지에 신뢰할 수 있는 데이터를 전달하는 역할

  • 물리 계층, 데이터 링크 계층, 네트워크 계층의 3계층은 목적지에 데이터는 보내지만, 데이터의 무손실을 보장해주지는 않음
  • 전송 계층에는 오류를 점검하는 기능이 있음
  • 데이터가 제대로 도착했는지 확인하고, 오류가 발생하면 데이터를 재전송하도록 요청함

2) 전송된 데이터의 목적지가 어떤 애플리케이션인지 알려주는 역할

  • 전송 계층에는 전송된 데이터의 목적지가 어떤 애플리케이션인지 식별하는 기능이 있음
2 3

2. 연결형 통신과 비연결형 통신

45

전송 계층의 특징 : 신뢰성/정확성, 효율성

신뢰성/정확성

데이터를 목적지에 문제없이 전달하는 것

효율성

데이터를 빠르고 효율적으로 전달하는 것

연결형 통신

: 신뢰할 수 있고, 정확한 데이터를 전달하는 통신

  • 상대편을 여러번 확인해 가면서 통신하기 때문
  • TCP 프로토콜 사용됨
6

비연결형 통신

: 신뢰성이 보장되지는 않지만, 효율적으로 데이터를 전달하는 통신

  • 상대편을 확인하지 않고, 일방적으로 데이터를 전송하기 때문
  • UDP 프로토콜 사용됨
  • ex) 동영상
7

2. TCP의 구조

8 9

TCP 헤더

: 데이터를 전송하는 과정에서 TCP로 전송할 때 붙이는 헤더

  • TCP 헤더는 목적지가지 데이터를 제대로 전송하기 위해 필요한 정보를 가지고 있음

세그먼트(segment)

: TCP 헤더가 붙은 데이터

TCP는 신뢰성이 보장되는 연결형 통신에 사용되는 프로토콜 ‼️

🤔 **신뢰성**은 어떻게 보장될까? 💡 `3-way 핸드셰이크`

⇒ 데이터를 전송하기 위해서는 연결(connection)을 확립해야함

TCP 헤더의 코드 비트

10
  • TCP 헤더의 107번째 비트 ~ 112번째 비트까지의 6비트는 연결의 제어 정보가 기록됨
  • 각 비트의 초깃값은 0, 활성화되면 1
  • 연결을 확립하기 위해서는 SYN, ACK가 필요
    • SYN은 연결 요청, ACK는 확인 응답
  • 연결을 해제하기 위해서는 FIN, ACK가 필요
    • FIN은 연결 종료, ACK는 확인 응답

데이터를 보내기 전 연결을 확립할 때

  • 코드 비트의 SYN, ACK를 사용
  • 패킷 요청이 3번 오감

3-way 핸드셰이크(three-way handshake)

: 데이터를 보내기 전에 연결을 확립하기 위해 패킷 요청을 세 번 교환하는 것 11

  1. 컴퓨터 1이 컴퓨터 2로 연결 확립 허가를 받기 위한 요청(SYN)을 보냄
  2. 컴퓨터 2가 컴퓨터 1로 연결 확립 응답(ACK)를 보냄, 동시에 컴퓨터 2도 컴퓨터 1로 데이터를 전송하기 위해 연결 확립 요청(SYN)을 보냄
  3. 컴퓨터 1은 컴퓨터 2로 허가한다는 의미로, 연결 확립 응답(ACK)를 보냄

⇒ 연결이 확립 되는 과정에서 코드 비트의 SYN, ACK가 활성화됨

데이터 전송 후 연결을 해제할 때

  • 코드 비트의 FIN, ACK 사용
  • 패킷 요청이 4번 오감
12
  1. 컴퓨터 1에서 컴퓨터 2로 연결 종료 요청(FIN)을 보낸다.
  2. 컴퓨터 2에서 컴퓨터 1로 연결 종료 응답(ACK)을 반환한다.
  3. 또한 컴퓨터 2에서도 컴퓨터 1로 연결 종료 요청(FIN)을 보낸다.
  4. 컴퓨터 1에서 컴퓨터 2로 연결 종료 응답(ACK)을 반환한다.

⇒ 연결을 종료할 때는 코드 비트의 FIN, ACK가 활성화됨

3. 일련번호와 확인 응답 번호의 구조

13

3-way 핸드셰이크 과정 이후, 실제 데이터를 주고 받을 때는 TCP 헤더의 일련번호와 확인 응답 번호를 사용함

일련번호(sequence number)

  • 송신 측에서 수신 측에 ‘이 데이터가 몇 번째 데이터인지’ 알려 주는 역할을 함

확인 응답 번호(acknowledgement number)

  • 수신 측이 몇 번째 데이터를 수신했는지 송신 측에 알려주는 역할을 함
  • 다음 번호의 데이터를 요청하는데도 사용됨
14
  1. 컴퓨터 1은 컴퓨터 2로 200바이트의 데이터를 전송한다.
  2. 컴퓨터 2는 데이터를 수신하고, 다음에 수신할 데이터 번호를 확인 응답 번호에 넣는다.
  3. 컴퓨터 1은 컴퓨터 2로 데이터를 전송한다.
  4. 컴퓨터 2는 데이터를 수신하고 다음에 수신할 데이터의 번호를 확인 응답 번호에 넣는다.

⇒ 데이터 전송이 완료될 때까지 1~4 과정을 반복함

⚠️ 데이터가 손상되거나 유실된 경우에는 일정 시간 동안 대기한 후에 데이터를 재전송함

⇒ 재전송 제어

참고)

데이터를 전송하기 전 단계에서 3-way 핸드셰이크 과정이 이루어지면서 일련번호와 응답 번호가 결정됨 15

🤔 세그먼트(데이터)를 하나 보낼때마다 확인 응답을 반환하는 것은 비효율적

💡 세그먼트를 연속해서 보낸 다음 확인 응답을 반환하면 효율이 높아짐

⚠️ 너무 대량의 데이터를 전송하면 수신 측에서 보관하지 못하고 넘쳐 버림

버퍼(buffer)

: 수신 측에서 연속해서 받은 세그먼트를 일시적으로 보관하는 장소

오버플로(overflow)

: 수신 측에서 대량으로 데이터를 받았을때 보관하지 못하고 넘치는 현상

윈도우 크기(window size)

: 버퍼의 한계 크기(오버플로가 발생하지 않는)

⇒ 얼마나 많은 용량의 데이터를 저장해 둘 수 있는지를 나타내는 값

윈도우 크기의 초깃값은 3-way 핸드셰이크 과정에서 정해짐(서로의 윈도우 크기를 확인함) 16

4. 포트 번호의 구조

17

🤔 목적지가 어떤 애플리케이션인지 구분하지 못하면 목적지 프로그램이 아닌 다른 프로그램으로 데이터가 전송될 수도 있음

💡 데이터가 제대로 목적지에 전달되려면 TCP 헤더의 출발지 포트 번호, 목적지 포트 번호 가 필요함

  • 포트 번호는 0~65535번을 사용할 수 있음
  • 잘 알려진 포트(well-known ports)인 0~1023번은 주요 프로토콜이 사용하도록 예약되어 있음
  • 1024번은 예약되어 있지만, 사용되지는 않는 포트
  • 1025번 이상은 랜덤 포트로, 클라이언트 측의 송신 포트로 사용됨
  • 0~1023번은 서버 측 애플리케이션에서 사용됨
18

💡 애플리케이션은 각각의 포트 번호가 있어 다른 애플리케이션과 구분될 수 있음

19

⚠️ 웹 브라우저로 접속할 때, 웹 브라우저에는 임의의 포트가 자동으로 할당됨

⇒ 서버 측은 포트 번호를 정해야함

⇒ 클라이언트 측은 임의의 포트가 자동 할당되기 때문에 정하지 않아도 됨

5. UDP의 구조

20
21

UDP 헤더

: 올바른 목적지의 애플리케이션으로 데이터를 전송하기 위해 필요한 정보가 기록되어 있음

  • UDP는 신뢰성과 정확성이 필요하지 않아 TCP에 비해 헤더에 필요한 정보가 적음

UDP 데이터그램

: UDP 헤더가 붙은 데이터

브로드캐스트

: UDP를 사용해 랜에 있는 컴퓨터나 네트워크 장비에 데이터를 일괄로 보내는 것

  • UDP는 랜에서 불특정 다수에게 브로드캐스트로 데이터를 일괄 전송함
  • 목적지를 지정하지 않으면 안되는 TCP 통신은 브로드캐스트에 적합하지 않음
22