우리는 사용자, 네트워크 서비스가 제공하는 TCP와 UDP라는 프로그램을 이용하는 거라고 했다. 이 tcp와 udp는 전송 계층에 구현되어있고, 이 계층은 OS내부에 구현되어 있어서 http가 이용할 때에는 socket api를 통해 이용하는 것임.
그림으로 표현하자면 다음과 같다.
각 계층을 통과할 때마다 데이터에는 정말 전달하려고 하는 내용 외에 전송을 위한 추가적인 정보들이 부가적으로 추가된다. 예를 들면 전송계층을 통과할 땐 전송하는 포트의 번호, 컴퓨터의 ip 주소, 목적지의 포트 번호와 ip 주소 가 포함된다. 네트워크 계층을 통과할 땐 패킷에 물리적 라우터 connection과 관련된 정보가 포함된다. 반대로 다른 컴퓨터의 각 계층을 반대로 거슬러 올라가면서 부가적으로 추가된 정보들은 껍질을 벗기듯이 버려진다. 따라서 모든 프로토콜은 각 헤더에 최소한의 정보를 담도록 설계되어 있다. 이것은 다르게 보면 헤더에 어떤 내용이 포함되어 있냐를 보고 프로토콜의 동작과 역할을 어느정도 이해할 수 있다는 이야기가 된다.
TCP는 UDP와 다르게 reliable하고 in order 를 보장하는 프로토콜이며, flow control을 제공하여 속도를 조절함으로써 이를 수행한다고 했다. 이것이 어떻게 가능한 것일까?
이것은 여러 곳에서 정보를 받아서 하나의 통로로 쭉 내려보내는 기술을 이야기 한다. 반대로 하나의 통로로 받은 정보를 여러 통로로 나누어 보내는 기술을 디 멀티 플렉싱이라고 한다. UDP의 경우 하나의 정보만을 보고 하나의 통로로 들어온 패킷을 세그먼트로 분리해서 내보낼 때 각 세그먼트가 목적지로 하는 프로세스의 소켓을 하나의 정보만 보고 찾는다. 바로 목적지로 하는 포트 넘버이다. 소스 포트 넘버가 달라도 상관없다. 즉 다대일 연결이 가능하다는 뜻이다. 그래도 하나의 기능은 제공하는데 udp에는 checksum이라는 field가 있는데 이는 전송 중에 에러가 발생했는지 알 수 있는 플래그이다. 만약 이를 통해 에러가 있었다는 것을 발견하게 되면 최소한 에러 담긴건 받지 않도록 하는 기능이 제공된다.
tcp는 소스 포트 넘버, ip 주소, 목적지 포트 넘버, ip 주소, 이 네 개의 필드를 보고 하나의 목적지를 찾는다. 무조건 1:1 연결을 해야하기 때문이다. 출발지가 다르면 다른 목적지를 향해야한다. udp와 마찬가지로 checksum field를 활용하여 bit error를 탐지한다. 그러나 reliablility와 inorder 를 보장하기 위해서 필요한 retransmission 기능을 수행하기 위해 feedback을 필요로 한다. 이 피드백메세지가 바로 ACK/NAK 필드이다. 타이머를 설정해서 타이머가 expired되기 전에 응답이 오지 않으면 유실되었다고 판단하는 것임. 타이머를 세팅하는 방법은 정답은 없고, 실험을 통해 reasonable한 값을 정하게 된다.
하지만 만약에 이 피드백 메세지가 오는 도중에 에러가 발생한다면 어떻게 해야할까? 무조건 재전송을 해버리면 리시버 입장에선 두 번째 온 정보가 재전송인지 그냥 중복된 정보인지 알 수 없다. 이를 위해서 TCP에는 sequence number가 필요하다. 이게 몇 번째 있었야 하는 정보인지 알려주는 필드인 것이다. 그래서 sequence #가 2인 정보가 두 번 온다면 이것이 재전송 되었다는 것을 알 수 있게 되는 것이다.