컴퓨터 네트워크 - 3(Transport layer)

박승현·2023년 9월 9일

컴퓨터 네트워크

목록 보기
3/6

3.1 Transport layer service

-> TCP, UDP가 여기에 속함

Network layer vs Transport layer

  • network : 호스트간의 통신을 담당
  • transport : 프로세스 간의 통신을 담당

3.2 Multiplexing/deMultiplexing

-> 프로세스로부터 세그먼트를 받아 헤드를 붙이는 것 : 멀티 플렉싱
-> 받아서 헤더를 활용해 정확한 프로세스에게 전달 : 디 멀티 플렉싱

demultiplexing

  • 네트워크 레이어의 IP주소를 받아서 호스트를 연결
  • 포트 넘버를 사용해서 정확한 소켓(프로세스)에 전달
  • UDP와 TCP의 헤더 내용은 다르지만 source port, dest port는 공통적으로 존재함

connectionless demultiplexing

  • udp에서 사용하는 디멀티프렉싱임
  • 연결이 없음 : 도착 포트넘버만 같으면 항상 그 소켓으로 전달

connection-oriented demultiplexing

  • tcp에서 사용 : 소켓이 IP주소(도착, 출발), 포트 번호(도착, 출발) 4가지를 다 비교함

3.3 connectionless transport : UDP

   -> 과거 멀티미디어 앱, DNS SNMP에 사용
   -> 연결이 필요없고 헤더 크기가 작음

UDP segment header

  • source port, dest port : 공통
  • length : 헤더의 8바이트 + app의 전체 크기를 담고 있음

UDP CHECKSUM

  • 세크먼트 헤더에 포함, 데이터 전송간에 오류가 있는지 판별
  • Sender : 세그멘트 헤더에서 checksum 필드를 제외 app 포함 16비트 4개를 더해서 한개의 16비트를 만든 후 0과1을 뒤집어 줌(이게 checksum) -> checksum field에 담아서 보냄
  • Receiver : 받은 세그멘트에서 같은 방법으로 checksum계산, sender 헤더의 checksum필드와 비교 -> 다르면 반드시 에러, 같으면 에러가 있을수도 있지만 없다고 판단(매우 적은 케이스)

3.4 principles of reliable data transfer

rdt 1.0 : reliable transfer

  • FSM : finate state machines

1.0 : 에러, 로스 없음

- sender : app layer에서 데이터 받기, 패킷 만들고 전송, 다시 상태 유지

- receiver : 네트워크에서 페킷 받기, 데이터 꺼내서 app layer로 보내고 상태 유지

rdt 2.0 : bit error(로스는 없음)

  • checksum을 활용해서 에러 체크
  • 에러가 있으면 ack 없으면 nak를 보냄

Sender : 페킷 보내고 ack or nak를 기다림,
nak가 오면 재전송 재전송에 대한 결과 대기, ack면 다시 app layer에서 데이터 보내주길 대기

receiver : 페킷을 받으면 checksum확인 다르면 nak보내고 다시 대기 맞으면 ack보내고 app layer로 데이터 전송

2.0의 fatal flaw

  • ACK, NAK 자체의 corrupted
  • Sender 입장에서는 그냥 다시 보내버림(반복의 문제)
  • sequence number을 같이 보내 중복인지 확인할 수 있게 함

stop and wait : 하나 보내고 잘 보냈는지 확인 한 후 다시 보내는 방식

rdt 2.1 : 시퀀스 넘버, checksum의 corrupt 추가

Sender

    1. 시퀀스 넘버는 0,1,0,1을 반복

  • 0번 데이터 위에서 받아서 데이터, 체크섬, 시퀀스 전송후 대기

  • 대기 상태에서 nak가 오거나 corrupt되면 재전송 후 대기

  • corrupt가 아니면서 ack이면 시퀀스 1번이 app에서 오기를 대기함

  • 그 후 부터는 동일 하면서 시퀀스 번호만 0,1반복

Receiver

  • 0번 시퀀스 대기

  • corrupt : nak보내고 대기

  • corrupt가 아닌데 1번 시퀀스가 오면 ack보내고 대기

  • corrupt도 아니면서 0번이 오면(원하는 상태)
    데이터를 app layer로 보내고 ack보내고 1번을 대기

  • 1번 시퀀스 대기

  • 위와 동일하다

1이나 0을 대기할때 다른 시퀀스가 오는 이유 : 다른 시퀀스로 넘어가면서 ack를 보내는데 이게 sender에서 corrupt될 경우 재전송 하기 떄문

rdt2.2 : ack만을 사용

  • 어떤 시퀀스의 ack인지 명확하게 표시

1번을 기다릴때 정상적이면 1번 ack를 만들어둠
0번을 기다릴때 corrupt혹은 nak일때 이전에 만든 것을 보냄
0,1 바뀌어도 동일

rdt 3.0 : 에러와 손실

  • 일정 시간동안 ack가 안오면 재전송 : 손실이라고 판단
  • 만약 손실이 아니라 딜레이였다면? : 중복이 발생하지만 시퀀스 넘버로 해결가능

  • 0번 데이터를 페킷 만들어서 보낼 때 타이머 시작
  • 만약 corrupt나 1번에 대한 ack가 오면 그냥 아무 행동을 하지 않음 -> 타임아웃으로 재전송
  • 재전송시 타이머 재시작, ack 0번 대기
  • ack가 제대로 오면서 corrupt가 아니면 타이머 멈추고 1번에 대한 데이터 대기
  • 만약 이전에 보냈던 0번 ack가 오면 현재 1번 데이터 대기 중이니 무시하면 됨

receiver : 2.2와 동일하다

rdt 3.0 operation

,,, stop and go : 성능이 안좋다

Pipeline protocol : ack를 받지 않고 그 다음을 보냄

  • 시퀀스 넘버가 증가 해야한다
  • 버퍼링 : 여러개의 정보를 저장할 필요가 있음
  • Go-Back-N / Selective repeat

stop and wait의 3배의 능률

Go-Back-N

  • 시퀀스 넘버 : n개 필요 n=10이면 4비트 필요

  • ack를 받음, 보내고 ack를 못받음, 아직 안보냄, 보낼 수 없음(n초과)
  • sender는 보내고 ack를 못받은 가장 오래된 패킷의 타이머를 실행 : 타임아웃되면 그 이후의 모든 노란색 패킷을 보냄

Sender

  • 정상적으로 app에서 데이터를 받음
    • base + n : 보낼 수 있는 최대 범위 -> 다음 페킷은 아 숫자보다 작아야함
    • 만족하면 버퍼 저장하고 보내면 됨
    • 만족 하지 않으면 그냥 삭제함
    • 만약 다음 보낼 페킷이 베이스와 같으면 -> 처음 보내는 상황 : 타이머 실행
    • 보내면 무조건 다음 보낼 페킷 +1
  • ack를 받고 corrupt가 없으면
    • 베이스를 받은 엑크의 번호+1로 바꿈(노란색)
    • 이때 베이스가 다음 페킷 번호와 같으면(모든 ack를 받음) 타이머 멈춤, 다르면 차이머 재시작
  • ack가 corrupt되면 그냥 아무것도 않하면 된다
  • timeout되면 : 타이머 재시작, 베이스~ 다음 페킷-1(노란색) 재전송

receiver

원하는 패킷이 오면 ack그 번호로 보내고 그거 저장
원하는 번호가 아닌 다른 모든 번호에 대해서는 미리 만들어둔 ack를 계속 전송

Selective repeat

sender

go-back-n과 다르게 ack를 뒤에거를 먼저 받을 수 있음

receiver

리시버 센더의 윈도우가 따로 있다

sender

  • ack받으면 해당하는 페킷 초록색
  • 베이스의 ack를 받으면 안받은 가장 작은 페킷으로 베이스(윈도우) 이동
  • 타임아웃 = 그 페킷 재전송, 타이머 재실행

receiver

  • ack 전송
  • out of : 뒤에 파란색이 오면 그냥 저장
  • in order : 베이스가 오면 받은거 쭉 이어져 있는거 app layer에 전송 베이스 안받은 페킷으로 이동
  • 앞에 있는게 다시 오면 ack해줘야 함 안보내면
    (sender)가 무한 전송 할수도 있음

시퀀스 넘버는 양쪽의 공간(n)을 합친거 보다 크거나 같아야 함

3.5 connection-oriented transport : TCP

시퀀스 넘버를 바이트 단위로 나눔

  • acknowledgements : 다음에 받길 원하는 번호

  • ack를 보낼떄는 받은 시퀀스에 1더해서 보냄

  • 결국 ack는 받고싶은 번호, 시퀀스는 실제로 보내는 번호

RTT : 일정하지 않음

이 식으로 평균 RTT를 구함
보통 알파 = 0.125
-> 측정한 RTT가 오래 될수록 영향력이 감소 하는 것

그래서 안전한 마진을 구해서 TIME OUT시간을 정함

reliable data transfer

TCP Sender

    1. app에서 데이터를 받음 -> 세그먼트 생성(시퀀스 넘버 : 처음 정한 번호) -> 네트워크 레이어로 전송, 넥스트 시퀀스 넘버를 기존 넘버에 여기서 보낸 데이터의 바이트만큼 더해야함(한 개의 페킷을 보내는게 아닌 바이트단위로 보내기 떄문)
      +추가로 타이머 없으면 타이머 실행
    1. 타임아웃 : 아직 ack를 안받은 세그먼트 중 시퀀스 넘버가 가장 적은 세그먼트 전송, 타이머 실행
    1. ack를 받은 경우
    • ack의 벨류 : Y -> Y-1까지는 다 받았다는 뜻
    • Y가 베이스보다 크면 Y를 베이스로 바꿈
    • 타이머

TCP Receiver

  • delayed ack : 정상적으로 받고 딜레이 후에 ack를 보내 보내는 총 갯수를 줄임

  • 딜레이 전에 또 데이터가 오면 딜레이, 새로 온 데이터 합쳐서 ack를 한번에 보냄

  • 100번을 기다리는데 120번이 오면? -> 그냥 내가 받고싶은 ack를 또 보내면 된다

  • ??

    TCP fast retransmit

  • sender가 같은 데이터의 ack를 3개 받은 경우 : triple duplicate acks -> 타임아웃을 기다리기전에 데이터가 손실 되었다고 판단, 재전송

TCP flow control

  • sender가 너무 많이 보내서 receiver가 못받는 상황을 방지
  • 리시버가 ack를 보낼떄마다 남아있는 버퍼의 사이즈를 보냄(세그먼트 헤더에 receive window)
  • 버퍼가 꽉차면 ack를 안보내는 식으로

Connection management

  • 2way 핸드쉐이크 : 메시지 왔다 갔다 끝(인간식임) -> 기계는 손실, 딜레이 때문에 사용 못함(서로 확인 불가능하기 떄문)

  • TCP 3-way handshake connection

    • 클라이언트쪽 처음에 LISTEN -> CLOSED

  • closing

  • 끝내고 싶은 쪽에서 fin
  • 반대쪽에서 ack
  • 다시 요청받은쪽에서 fin
  • 반대쪽에서 ack

congestion control

profile
박승현
KMU SW
이전 포스트

컴퓨터 네트워크 - 2(Application layer)

다음 포스트

컴퓨터 네트워크 - 4(Network layer)

0개의 댓글