Transport Layer - 1. Introduction

transport layer는 서로 다른 호스트에서 돌아가는 application process끼리의 logical end-to-end communication을 제공한다.
실제로는 여러곳을 경유해 목적지를 찾아가지만 application layer의 view에서는 end지점끼리 직접 연결돼 있는 것처럼 보인다.

transport layer에서
send side는 application layer로부터 내려온 message를 segments들로 쪼개서 network layer에게 전달한다.
receive side는 segment들을 다시 모아서 message를 만들고 application layer에게 올려준다.

여러 종류의 transport protocol들이 있고 인터넷에서는 TCP, UDP가 가장 많이 사용된다.

1. Transport vs. Network

network layer는 host끼리의 logical communication을 제공한다. hosts들 사이의 경로를 찾는 역할을 수행한다.
반면 transport layer에서는 application layer에서 돌아가는 process간의 logical end to end communication을 제공한다.

2. multiplexing/demultiplexing

multiplexing : 한 host의 여러 socket으로부터 나온 패킷들에 추후 식별을 위해 transport header를 붙이고 한줄기로 데이터를 전송
demultiplexing : 한줄기로 들어온 패킷들의 헤더에 담긴 port넘버를 확인하여 해당하는 process에게 패킷을 나누어주는 것

network layer에서 ip address를 확인하고 IP datagram의 payload를 상위 계층에게 넘긴다. (TCP segment)
transport layer에서 TCP segment의 헤더를 보고 port number를 확인한다. (demux)

port number는 16비트로 구성된다. (0~65535)
0~1023까지는 잘 알려진 port number로 목적이 정해져있다.

3. Internet transport layer protocols (TCP, UDP)

UDP, TCP 모두 port number를 사용해서 multiplexing/demultiplexing을 지원하고 checksum을 사용해서 error checking을 수행한다. 둘다 network layer의 IP 프로토콜 위에서 동작한다.

4. TCP

reliable transport : 100% 신뢰성을 보장한다. (전송 보장)
flow control : sender는 receiver의 buffer크기, 메모리를 초과해서 보내지 않는다. (receiver가 너무 바쁘면 천천히 보낸다)
congestion control : network가 너무 바쁘면(overloaded) sender는 보내는 양을 조절한다(throttle)
in-order보장.
반면에 timing, minimun throughput, security는 보장하지 않는다.
connecton-oriented : 데이터를 전송하기 전에 client와 server사이의 setup이 필요하다.

맨 처음 server socket을 생성할때, local host의 포트번호만 지정해준다.
client로부터 connection 요청이 오면 server는 이를 수락하여 connection socket을 만드는데 이때 목적지, ip, port를 지정해준다.
즉 서버가 만드는 connection socket은 [src IP, src port, dst IP, dst port] 로 정의될 수 있다. (한개만 달라도 새로운 connection socket 생성 가능)
client수만큼 connection socket을 만들어 데이터를 전송한다. 동일한 client여도 port를 다르게 하여 복수개의 connection을 만들 수 있다.
단 한 computer에서 두개 이상의 process가 동일한 port를 사용할수는 없다.

* C에서는 port number를 다르게 하여 [src ip, 5775, dst ip, 80], [src ip, 9157, dst ip, 80] 두개의 connection socket을 만들어 데이터를 주고 받는다.
*P4, P5, P6이 서로 다른 process처럼 나와 있지만 80포트를 사용하는 한개의 process일수도 있다. 한 개의 프로세스가 복수개의 socket을 만들 수 있다.
*여기서는 총 세개의 connection socket이 만들어졌다.

5. UDP (User Datagram Protocol)

신뢰성, flow control, congestion control, 보안, 타이밍, 순서, throughput 어느 항목도 보장하지 않는다. (내가 얼마나 빠르게, 몇개의 패킷을 보내고 있는지 등의 state를 하나도 저장하지 않기 때문에 보장할수가 없다.)
connection setup도 필요없다. 그래서 언제든지 패킷을 보내고 받을 수 있다.
connection을 위한 delay가 없고 구현의 복잡도도 없다. state를 최소한으로 저장하기 때문에 더 작은 메모리면 충분하고 패킷 자체가 simple, small해서 overhead도 적다.
그럼 udp는 왜 사용하냐고 물어볼 수 있다. 만약 내가 패킷의 90퍼센트라도 받을 필요가 있다면 (loss가 있어도 괜찮다면)
혹은 네트워크 혼잡도와 무관하게 일정 주기의 응답이 필요하다면 UDP가 사용될 수 있다.
congestion control을 안하기 때문에 주기적으로 계속 패킷을 보낼 것이다. (주기적으로 도달한다는 뜻은 아니다.)
즉 모두가 UDP를 사용하고 데이터를 많이 보내려한다면 네트워크 혼잡도를 높일 위험이 있다.
하지만 UDP를 사용하는 application layer에서 전송량을 조절하고, state를 만들어서 loss를 파악하고 재전송을 시도한다던지 할 수 있다. (application layer specific error recovery, 필요하다면 UDP의 신뢰성을 application layer에서 보강하면 된다.)

IP프로토콜 위에서 동작한다.
헤더에 추가되는 내용이 많지 않다. 하위계층으로 내려갈때 port번호, length, checksum만 추가되어 내려간다. (헤더크기가 매우 작다)
Best effort 서비스라고 한다. 결과에 상관없이 최대한 열심히 시도한다는 뜻이다. 즉 패킷의 수신 결과, 전송 order를 보장하지 않는다.
참고로 IP도 마찬가지로 best effort 서비스이다.
DNS, SNMP(이메일), 인터넷 전화, 동영상스트리밍 서비스 등에 UDP가 사용될 수 있다.

socket을 생성할때, host의 local 포트 번호는 지정하지만 destination port 번호는 따로 지정하지 않는다.

UDP 소켓을 통해 datagram을 만들어 전송할때 목적지 ip주소와 목적지 port번호를 함께 적어준다.
따라서 single 소켓으로 여러명의 client요청에 대응할 수 있다.

*소켓을 생성할때 목적지 ip, 목적지 port를 지정할 필요가 없다. 패킷을 보낼때만 지정해주면 된다.
*single 소켓으로 여러명의 client요청에 대응할 수 있다.

6. Checksum

segment를 전송할 때 bit error를 탐지한다.
송신자는 header + payload를 구분없이 16비트 integer sequence라고 생각하고 보낸다. 각 자리의 숫자들을 더한 값을 1의 보수화한 다음 그 값을 checksum field에 담는다.
송신자가 segment를 받았을때, checksum값을 직접 구한 결과와 헤더 속 checksum field에 담긴 값과 비교해서 맞는지 틀린지 검사한다.
동일하면 에러가 없다고 생각하고 (실제로는 에러가 없는걸 보장할수는 없다.). 다르면 에러가 발생한 것이다.

참고로 link layer에서도 error checking을 한다. 하지만 에러가 link layer에서 패킷 수신 후 다른 단계에서 생길수도 있는 노릇이고 모든 link가 error checking을 지원한다는 보장도 없다.
따라서 end-to-end error detection을 transport layer(TCP, UDP)에서 구현하였다.