감 1도 없는 개발자

감 1도 없는 개발자

여행을 꿈꾸는 개발자

전송계층

Updated:

강의

http://www.kocw.net/home/search/kemView.do?kemId=1159726

전송계층

  • Relaiable Networking (End to End)

  • 네트워크의 이상적인 모습은 A에서 B로 direct하게 bit stream 형태로 가는 것이다.
  • 그러나 현실은 그렇지 않다.
  • 무한한 흐름 X, 패킷 유실, 패킷 순서 바뀜, 패킷 변조가 생긴다.
  • 이를 위해 보낼 데이터를 패킷으로 나누어 서버로 부터 응답을 받아 패킷을 유실되지 않게 문제를 해결하기 위한 해결책이 있다.
  • 그러나 이것은 네트워크의 성능 문제(지연시간, 전송률)가 있다.
  • 성능을 해결해보자.

1. Pipelining

  • 연속된 대량의 작업이 순차성을 가지고 있으나 앞의 일이 종료하지 않고도 다음 일을 시작할 수 있는 병렬성을 가진 경우 성능 향상을 위해 사용하는 기법
  • 이를 위해 두 가지 방법이 있다.

1.1 Go-Back-N

  • N개의 packet을 병렬적으로 처리

  • 송신측에서는 N개의 packet을 버퍼링(재전송하기 위해서)

  • 버퍼링이란 수신이 확실하지 않는 packet에 대하여 재전송 위하여 보관하는 공간. 즉 일단 송신하고 버퍼링에 넣는다. 버퍼링의 크기는 제한적이다.

  • 수신측에서는 순차적으로 잘 수신된 packet에 대하여 ACK를 송신하고 packet의 payload(실제 전송하고자 하는 내용)를 응용계층으로 올려 보낸다.

  • 송신측에서는 ACK를 받지 못하더라도 순차적 ACK가 온다면 수신측에서 순차적으로 해당 패킷까지 잘 받았다고 간주.

    예를 들어 1,2,3,4 패킷을 순차적으로 보냈고 수신측에서도 순차적으로 잘 받고 ACK도 다 보냈다고 가정하자. 이때 3번 패킷에 대한 ACK가 중간에 유실. 그럼 송신측에서는 각 패킷에 대한 ACK가 1,2,4만 받는다. 그럼 송신측에서는 4를 받을 때 4번에 대한 정상 ACK가 왔다면 3번도 수신측에서 잘 받았을 꺼라고 간주.

  • 송신측에서는 ACK가 온 패킷에 대해서 버퍼링에서 삭제 후 버퍼에 여유가 생기면 다음 패킷을 보내고 버퍼링에 넣는다.

  • 수신측에서 순서에 맞지 않는 패킷이 온 경우 반응

    1. 조용히 있는다.
    2. 잘 받은 마지막 패킷에 대한 ack를 전송
1.1.1 재전송 정책
  • 각 패킷 전송시에 패킷을 위한 타임 설정
  • ACK를 받으면 ACK 해당 패킷과 앞쪽 패킷 타임 소멸
  • 타임 이벤트 발생하면 해당 패킷부터 재전송
  • 추가 재전송 정책
    • N번째 패킷에 대한 ACK가 반복적으로 올 경우 N+1번째 패킷 유실을 의미
    • 예를 들어 1,2,3,4,5를 보내는대 수신측에서 2번 패킷을 못 받았다고 하자. 3번, 4번, 5번을 받고 나서 ACK를 보낼 때 3,4 ,5패킷에 대한 ACK가 아닌 1번 ACK를 연속해서 보내면 송신측에서 2번 패킷이 유실되었다고 생각하고 다시 2번부터 보낸다.
1.1.2 장단점
  • 단순(특히 수신측)
  • 간결하게 시스템의 상태가 추상화
  • 패킷 유실에 대한 복구 비용이 비싸다.

1.2 Selective Repeat

  • Go-Back-N의 단점을 보완
  • 수신측에서도 버퍼링을 가짐
  • 빠진 패킷이 있을 경우 그 뒤에 잘 도착한 패킷들을 버퍼에 보관

  • 빠진 패킷이 추후 도착하면 버퍼에 저장한 이후 패킷들까지 순차적으로 응용계층에 전달

  • 송신측에서는 보낸 패킷에 대한 ACK를 못 받고 타임 이벤트가 발생하면 다시 보낸다.
  • 이때 수신측에서는 송신측에서 보낸 패킷이 수신측의 버퍼링에 있는 패킷이라면 잘 받았다고 ACK 보낸다.
1.2.1 장단점
  • 실패한 패킷에 대한 재전송이 좋아짐
  • 시스템의 추상화가 복잡

2. TCP vs UDP

  TCP UDP
신뢰성 내용 유실 X, 순서 보장 내용 유실 O
속도 고의적 지연이 존재 고의적 지연이 없음
전송단위 바이트(Byte) 패킷(데이터 그램), Send 함수 호출 단위
  • TCP의 고의적 지연이 있는 이유는 혼잡 제어를 하기 때문이다. 혼잡 제어를 하는 이유는 TCP는 패킷 수신 순서가 중요하기 때문에 이미 받은 패킷이라고 해도 순서가 맞지 않는 다면 받지 않았다고 알려준다. 따라서 서버는 패킷에 대한 순서를 지향한다. 이를 무시하고 계속해서 데이터를 보내면 네트워크 코어에서 패킷이 쌓여서 과부하가 걸려 일부 패킷을 버리게 된다. 그러면 신뢰성이 깨진다.
  • TCP의 전송단위가 바이트인 이유는 패킷이 유실되지 않기 때문에 굳이 보낼 데이터를 따로 데이터를 전송 단위화 시킬 이유가 없다.

2.1 TCP

  • Reliable Network
  • 내용 변조 감지 (checksum)
  • 혼잡제어
  • 흐름제어 : 데이터 쏠림 현상 제어
  • 포트(응용계층의 프로그램들을 구분) 개념 지원

3. 소켓 vs 포트

  • 여러개의 소켓에 한 개의 포트가 붙어 있는 형태이다. (N-1 형태)

4. TCP 헤더

  • 32bit로 구성
  • sorce 포트 + destination 포트
  • 시퀀스 number (byte)

  • ACK number (byte)

  • 헤더 길이 정보 + 플래그 정보(ex: TCP 패킷 연결 플래그) + receive window(수신에 대한 버퍼 크기)

  • checksum (내용 변조 감지를 위한 헤더. payload를 역으로 보내서 수신측에서 payload와 checksum을 더해 모두 1이면 변조가 안된 것으로 간주. 예를들어 payload가 1001이면 checksum은 0110이라고 보냄.)
  • payload (패킷에 실제 의미 있는 데이터 내용. body라고도 함)

5. 혼잡제어

  • 혼잡 인지
    • 패킷 유실 -> 혼잡상황 -> 패킷전송률 저하.
    • 패킷전송 원활 -> 비혼잡 상황 -> 패킷 전송률 상승

  • AIMD(Additive Increase Multiplicative Decrease) : 위와 같은 상황을 판단하는 것을 말함

  • 패킷 유실 판단 : ACK 신호가 timeout 안에 오지 않음
    • 타임 아웃은 너무 길면 재전송 신호가 너무 길어짐. 반대로 flase 알람 가능성
    • RTO (Retransmission Timeout) = MAX(RTT + 4 * RTT 표준편차 , 1초)
    • RTT (Round Trip Time) : 요청해서 응답까지 오는 시간, weighted moving average를 이용해서 구함

  • Fast Recovery(or Retransmission) : 1,2,3,4,5를 보내는대 수신측에서 2번 패킷을 못 받았다고 하자. 3번, 4번, 5번을 받고 나서 ACK를 보낼 때 3,4 ,5패킷에 대한 ACK가 아닌 1번 ACK를 연속해서 보내면 송신측에서 2번 패킷이 유실되었다고 생각하고 다시 2번부터 보낸다

  • Slow Start : 네트워크 이상 시 CW(connection window)를 1로 바꾼다. 문제는 cw 증가가 너무 느림.
    • CW를 패킷이라고 보면 됨
    • 패킷이 타임아웃이 안나면 CW를 1나씩 더 증가시켜 보냄. 그러나 문제는 선형적을 증가하므로 느림
    • 따라서 어느 일정 구간까지는 기하급수적으로 속도를 늘게 하기 위해서 사용
    • 예를 들어 1개가 성공하면 2개 보내고 2개가 성공하면 4개 보내고 4개 성공하면 8개 보낸다.
    • 그러면 중간에 너무 증가해서 속도가 느려지면 다시 1로 감소시킨다.
    • 그러면 아래 그림처럼 그래프가 바뀜

You may also enjoy