Transport Layer

logical communication

Transport Layer

 - Transport Layer는 process 간의 logical communication을 제공합니다.

 (저는 이 뜻을 물리적으로 직접 연결돼있진 않지만 보이지 않는 가상의 연결된 상태로 이해하고 있습니다.)

 

 - 다음에 배울 Network Layer는 host 간의 logical communication을 제공합니다.

 

 - host..? process?? 아직 헷갈린다면 Application Layer를 다시 읽고 와주세요!

 

 - Network Layer가 host까지 보내주면 Transport Layer에서 어떤 process인지 확인하고 통신하겠죠!

 

Transport Layer에서 사용하는 protocol은 크게 두 가지가 있는데 TCP / UDP입니다.

 

TCP / UDP

TCP

 - reliable, in-order delivery

 - congestion control

 - flow control

 

UDP

 - unreliable, unordered delivery

 

둘의 가장 큰 차이는 reliable(신뢰성 있는지)한지 입니다.

 

Application Layer

어떤 서비스를 사용하느냐에 따라 TCP를 사용할지 UDP를 사용할지 고민해볼 수 있습니다.

 

그럼 스트리밍 같은 서비스가 아니면 무조건 다 TCP를 쓰겠네?라고 생각할 수 있지만 Chrome은 UDP 기반의 QUIC protocol을 사용합니다.

 

Mux / DeMux

 

Mux / Demux

application layer에서 소켓을 통해 메시지가 나가고 소켓을 통해 메시지를 받는다고 했습니다.

근데 layer마다 메시지라고 부르면 구분이 가지 않아 Transport Layer에서 메시지는 "segments"라고 부릅니다.

 

multiplexing을 보면 많은 소켓으로부터 데이터를 제어한다고 합니다. "transport header"를 더해서요

이것저것 붙이지만 지금 설명에 중요한 "port number"라는 것을 붙입니다.

 

demultiplexing을 보면 받은 메시지(segments)를 올바른 소켓에 보내주기 위해 header info를 사용한다고 쓰여있습니다.

그 header info에 있는 port number를 보고 이게 어느 소켓으로 온 메시지인지를 알고 보내줍니다.

 

Connectionless demux / Connection-oriented demux

UDP의 D가 Datagram입니다. DatagramSocket이면 UDP용 socket입니다.

 

왼쪽 UDP는 destination IP address와 destination port number로 socket을 구분합니다.

오른쪽 TCP는 Source IP address, port number와 Destination IP address, port number 4가지를 확인합니다.

P2 <-> P6과 P3 <-> P5의 연결을 보면 같은 host의 연결이지만 연결마다 다른 소켓을 사용합니다.

 

UDP

 - 최선의 연결 기능만 해주지 lost가 생기거나 정렬되지 않은 채로 보내도 신경을 쓰지 않는다.

 - handshake가 없다 connection less다. 그래서 매번 handshake 하는 TCP보다 빠르다.

 

pipelining

pipelining

packet을 한 번에 1MB를 주고받을 수 있다고 하자 근데 서버한테 패킷이 도착하기까지 1초가 걸린다면 (a)의 경우 1GB 받는데 얼마나 걸릴까!

 

패킷 하나 보내고 서버에서 ACK하나 보내고.. 딱 봐도 오래 걸려 보인다.

이런 문제 때문에 일단 계속 보내다가 loss가 생기면 그 패킷 다시 보내자! 하는 방법이 2개 있다.

 

Go-Back-N / Selective Repeat

GBN은 1, 2, 3(loss), 4, 5.. 순차적으로 받다가 패킷 3을 받지 못해서 timeout이 생기면 3부터 다시 3, 4, 5... 똑같은 거 다시 보낸다.

 

SR은 말 그대로 loss난 패킷 3만(Select) 다시 보낸다(Repeat)

 

flow control & congestion control

flow control은 말 그대로 flow(흐름)을 제어한다. 보내는 쪽은 빠르게 보내는데 받는 쪽이 느리게 받는다면 처리해야 할 패킷이 쌓이게 되고 overflow가 생길 수 있다. 그래서 받는 쪽이 보내는 쪽을 control 해서 이런 문제를 예방한다.

 

congestion control은 congestion(혼잡)이라고 표현하는데

“too many sources sending too much data too fast for network to handle” 많은 사람들이 데이터를 너무 빠르게 많이 보내는 상황을 제어하려고 한다.

 

보내는 호스트가 패킷 하나 보내봤다가 잘 가면 더 보내고 안 가면 줄여 보내면서 컨트롤하는 것이다.

결국 컨트롤한다는 의미지만 어떤 host가 컨트롤하는지는 조금 달라진다.

 

TCP Tahoe / TCP Reno

보면 ssthresh라는 threshold는 가지고 있다. 그 값까지는 2배씩 하면서 늘어나다가 threshold를 지나가면 1씩 올라가고, 문제가 생기면! 아예 1로 갈 수도(Tahoe), 반으로 줄여서 다시 시작할 수도(Reno) 있다.

 

3-Way Handshake

 

3-way handshake

이거 때문에 UDP보다 느리다.

 

왜 하냐면 둘의 Sync를 맞춰서 어떻게 보낼지 준비하는 단계다. 다짜고짜 패킷 받아라! 하고 던지는 게 아니다.

Sequence Number, ACK Number를 주고받으면서(x, y로 쓰여있는데 아무 숫자라고 생각하면 된다.) Seq x를 보내면 잘 받았다는 의미로 Ack x+1을 보내준다. y도 마찬가지다.

 

Seq, Ack를 통해 패킷을 잘 받았는지 loss가 생기면 어디서부터 생겼는지 알 수 있다.

 

Security

SSL/TLS로 패킷을 암호화할 수 있습니다.

(코드 준비 중..)

 

 

 

TCP / UDP 각각의 특성을 꼭 기억해주세요!