📌 Transport Layer

모깅·2023년 5월 28일

Application Layer는 OS가 제공하는 서비스를 사용하는 계층이다.
-> 그 서비스는 UDP or TCP이며 사용자가 원하는 것을 사용할 수 있도록 한다.
Transport Layer는 OS에 존재한다.
APP계층에서 만들어진 것을 데이터의 단위를 '메세지'라고 한다.
Transport Layer 전송단위는 segment이며 메세지는 segment이며 Data 영역에 들어가게 된다.

만약 UDP였다면 Port번호가 80인 segment들은 모두 같은 socket으로 갈 것이다.
-> 그러나 TCP는 4개를 모두 보고 결정한다.
-> TCP는 1:1 맵핑이 된다. (하나의 프로세스의 쓰레드 서버를 여러개 만들어서 맵핑이 된다.)

어떤 프로토콜이든 헤더를 이해하면 어떤 역할을 하는지 알 수 있으며 Header를 최소한으로 하는 것이 우리의 목표이다.
-> header는 결국에 오버헤드이기 때문이다.
chectsum을 통해 오류가 있는 데이터는 받지 않는다.
따라서, UDP는 error Detection, Multiplexing/demultiplexing 두가지의 역할을 한다.

메세지에를 쪼개서 segment에 넣게 되는데 쪼개진 메세지의 맨 처음 바이트숫자가 segment header sequence number가 된다.
ACK #10 : 나는 9번까지 잘 받았다. 10번을 원해

timer는 적당하게 잡는게 중요하다.
-> 너무 짧으면 ACk가 돌아오기 전에 재전송할 수 있고 너무 길면 유실에 대한 대비가 너무 느려진다.
-> 따라서, segment에 RTT가 얼마나 걸렸는지를 참고해서 timer를 잡으면 좋을 것이다.
-> RTT가 얼마나 걸렸는지 측정한 것을 'SampleRTT'라고 한다.
그러나 SampleRTT는 매번 다를것이다.
-> queuing delay때문이다.

timer는 sender buffer의 맨 처음에만 물려있으며 timer가 종료되면 SEND_BASE에 물려있던 segment만 재전송한다.
만약 ACK #50 을 받았다면 그 전에 있던 segment들은 beffer에서 없애고 ACK #50에 해당하는 segment로 SEND_BASE와 timer를 옮긴다.

남은 recvBuf의 양을 header의 receive window에 써서 보내주자.
-> 보내는 입장에서 얼마나 보내야 할지 알 수 있다!
recvBuf가 꽉차게 되면 sender는 segment를 보내지 않게 된다.
-> 그러나 recvBuf의 공간이 남게돼도 받는 segment가 없기 때문에 recv의 상태를 sender에게 알릴 방법이 없다.
-> 교착상태(Deadlock)이 발 생하게 된다.
-> sender는 일정 시간마다 segment(1byte)를 보내서 상대방의 recvBuf를 확인하자!
App Layer에서 내려보낸 메세지를 segment에 담는 속도에 따라 문제가 발생한다.
-> 데이터 영역에 조금 채워보내게 되면 오버헤드가 많이 발생하게 된다.
-> 그러나 MSS를 꽉 채울 때까지 기다리게 되면 시간낭비가 된다.
-> 적절한 보내는 타이밍은 어떻게 될 지 고민해야 한다.
다음 순서에 따라 보내자
1. 1 byte라도 있으면 무조건 보낸다.
2. MSS가 다 채워지면 무조건 보낸다. or ACK가 오면 몇 byte가 채워졌든 보낸다.
Recv입장에서 buffer가 MSS보다 작다면 ACK를 보낼 때 buf의 남은 공간이 0이라고 하자.
-> 그래야 sender입장에서 보내지 않을 것이다.
원래는 segment를 받으면 바로바로 ACK를 해줘야 하는데 효율성을 위해 일정 시간이 지난 후 ACK를 보내자.
지금까지는 Connection이 되어있다고 가정하고 이야기 했다.
-> 지금부터는 Connection을 맺는 방법에 대해 이야기해보자.

마지막에 ACKbit를 보냈음에도 기다리는 이유는 Recv에서 보낸 데이터들이 유실 되었을 수 있다.
-> 따라서 재전송을 해야 할 수 있기 때문에 기다린다.
window의 크기는 recvBuf의 크기나 network 상황에 따라 더 작은 데이터를 받아드릴 수 있는 크기고 정해진다.
network상황을 알 수 있는 방법은 쉽지 않기 때문에 예측해야한다.

congestion이 발생하면 같은 메세지를 또 보는 것이므로 throughput이 떨어지게 된다.
업스트림에서 나온 데이터들이 자원을 소모하고 드랍되게 되면 데이터들이 낭비되는 것이다.
-> 드랍되면 retransmit을 해야하고 retransmit은 보내야 하는 데이터의 양을 줄이게 된다.