Transport Layer(1)

June Lee·2021년 5월 11일
0

네트워크

목록 보기
4/28

전송 계층의 대표적 프로토콜

: TCPUDP

Multiplexing과 Demultiplexing

  1. Multiplexing(Sender 컴퓨터): 여러 소켓에서 전달받은 메세지를 전송 계층에서 모아서 네트워크 계층으로 전달해주는 것 (어플리케이션 계층 -> 전송 계층)

cf. UDP는 Multiplexing/Demultiplexing과 error checking을 해줌

  1. Demultiplexing(Receiver 컴퓨터): 세그먼트를 받아서 거기에서 메세지를 꺼내서 알맞은 소켓(프로세스)에 전달해주는 것 (전송 계층 -> 어플리케이션 계층)
    세그먼트(data + header)의 Header 정보를 바탕으로 어떤 소켓에 전달할지를 결정함. header에 필드가 여러 개 있는데, 그 중 중요한 것이 source port number와 dest port number. data가 header에 비해 데이터 크기가 훨씬 큼.

UDP의 Demultiplexing 기준

Destination IP + Destination Port Number

TCP의 Demultiplexing 기준

Destination IP + Destination Port Number + Source IP + Source Port Number
=> 이 네 가지 중에 하나만 달라도 다른 소켓에 전달됨. 그렇기 때문에 Connection Oriented. 어떤 destination 소켓과 연결된 소켓은 하나밖에 없기 때문.
=> 즉 웹 서버는 TCP를 사용하기 때문에 웹 서버는 각 클라이언트를 위한 소켓을 가짐


Segment

: 전송 계층에 의해 전달되는 패킷의 단위

UDP 헤더: Source Port# + Destination port# + 데이터 lenght + checksum
=> 각각이 16bit. 이론상 컴퓨터 내 port number는 0~2^15개 정도 가능.
=> checksum은 전송 중 에러가 생겼는지 판단하기 위해 사용하는 필드. 에러가 있다면 Application 계층으로 올리지 않고 버려버림. (Multiplexing, Demultiplexing, Error Checking은 UDP도 함)
->즉, UDP가 하는 일은 에러 탐지와 multiplexing/demultiplexing

UDP를 사용하는 Application Protocol 예시
: DNS, SNMP


TCP의 Reliable Data Transfer

Unreliable한 환경(Channel)에서 Reliable하게 데이터를 전송해줘야함
Unreliable한 환경의 문제점은 1) 패킷 유실 2) 패킷 에러

Reliable Data Transfer Protocol (Stop-and-Wait 상황 가정)

<에러가 있는 상황 해결>
-> 에러 검출 (checksum)
-> 피드백 (잘 받았다는 ACK, Negative Acknowledgement(NAK))
-> 재전송

<위 해결 방법의 문제점>
-> 피드백에 에러가 있는 경우 (ACK, NAK에도 checksum이 있어야함)
-> 재전송인지 아닌지 받는 입장에서는 알 수 없음
-> 패킷에 번호를 붙임 (같은 번호가 중복되면 재전송)
-> 번호가 무한대면 header가 너무 커지니까, sequence number를 최소화할 수 있어야 함(단순한 protocol에서는 0,1만으로도 가능)

<에러가 있는 상황의 protocol 정리>
sender

  • packet에 seq# 추가
  • 받은 ACK/NAK에 에러가 있는지 확인
  • 에러가 있거나 NAK인 경우 재전송

receiver

  • 받은 패킷에 에러가 있으면 NAK 보냄
  • seq#을 통해 중복된 패킷인지 확인

cf) NAK가 없는 프로토콜도 가능

  • 무조건 ACK인데 마지막으로 정상적으로 받은 seq#을 같이 보냄

<유실된 상황의 protocol>
-> 타이머를 이용해서 일정 시간이 지나면(time-out) 재전송
-> 얼만큼 기다려야 할까? reasonable time( 네트워크 오버헤드(손실이 아닌데도 자꾸 재전송해서) & loss에 대한 늦은 반응이라는 trade off가 있기 때문에 논쟁이 많은 이슈)

ex) ACK loss인 경우
sender가 time out되면 packet(1)을 재전송. 이미 packet(1)은 잘 왔지만 receiver가 ack(1)을 재전송.

profile
📝 dev wiki

0개의 댓글