Transport layer는 서로 다른 호스트에서 돌아가는 애플리케이션 프로세스 간 logical communication을 제공한다.
프로토콜은 엔드 시스템에서 돌아간다. 왜냐하면 core에 있는 라우터들은 transport layer를 구현하고 있지 않다.
그 이유는 라우터들을 거쳐 데이터들이 전달되지만 transport layer 입장에서는 거쳐가는 과정은 보이지 않고 두 엔드 시스템의 logical한 커뮤니케이션만 보게 되기 때문이다. (라우터에서는 실제로 network, data link, physical layer만 존재)
sender는 segment 단위로 메시지를 잘라서 transport layer의 헤더를 붙이고 network layer로 보낸다.
receiver는 segment들을 합쳐서 메시지를 만들고 application layer로 전달한다.
network layer에서는 host 사이에서의 logical communication(통신) 제공하고, transport layer에서는 process 사이의 ㅣogical communicaiton을 제공한다.
TCP : reliable(신뢰성 있게 전달, 보낸 그대로 도착하도록), in-order delivery(보낸 순서대로 받는 사람이 받음)
-> 전송 속도 조절(congestion control, flow control)
-> 커넥션을 맺어야 통신이 가능(connection setup)
UDP : unreliable(신뢰성 X, 중간에 날아갈 수도 있음), unordered delivery(보낸 순서 상관없이 도달)
-> 그저 전달 역할만 수행
이 위의 프로토콜 모두 안하는 것들
-> 딜레이 보장
-> 속도 유지 보장(bandwidth guarantee)
-> TCP와 UDP 모두 보장 하지 않음
application layer에 해당하는 여러 process의 date들은 소켓을 통해 transport layer로 전달이 된다.
transport layer에서 데이터들을 수집하여 segment로 캡슐화시켜서 network layer로 전달된다. 이 과정을 Multiplexing 이라고 한다.(sender가)
Demultiplexing은, network layer으로부터 받은 segment의 header 정보를 확인하여, application의 각각 올바른 소켓으로 전달해주는 과정이다.(receiver가)
연결이 없는 (less) 비연결형 demultiplexing으로, UDP에서 사용한다.
UDP 패킷을 보낼 때 목적지 주소와 포트 번호를 정해줘야 한다
서버가 UDP 패킷을 받으면 헤드에 포함된 목적지의 포트 번호를 확인하고 이 포트 번호를 사용하는 소켓으로 보내준다.
같은 목적지 주소와 같은 목적지 포트 번호를 가지고 있는 패킷은 같은 소켓으로 보내진다.
보내는 쪽의 주소와 포트 넘버가 달라도 이렇게 동작한다.

connectionless multiplexing과 반대 개념으로, TCP에서 사용한다.
TCP는 소켓을 구별하기 위해서 네 가지 정보를 모두 사용한다.(이 정보가 모두 일치해야 같은 소켓으로 전달된다 -> UDP에서는 같은 목적지 주소, 같은 목적지 포트 번호만 가지고 있으면 같은 소켓으로 보냈음)
이는 커넥션을 맺기 떄문에 가능하다. (커넥션이 없으면 누가 나에게 보냈는지 모르고, 커넥션이 있으면 receiver 입장에서 sender의 정보가 확실하니까 목적지가 같더라도 source가 다르면 다른 소켓으로 취급함)
-> source IP address, source port number, dest IP adder, dest port number
receiver는 위 네가지 정보를 모두 활용하여 segment를 적절한 소켓으로 전달해준다.
웹 서버는 TCP를 사용하는데, 클라이언트와 커넥션을 맺을 때 마다 다른 소켓을 사용한다.
사용하는 포트번호와 IP 주소는 같아도 source의 정보가 다르기 때문이다.
non-persistent HTTP는 요청마다 새 커넥션을 하기 때문에 모두 다른 소켓을 사용한다.
