CH3. Transport Layer(1)

1. Transport-Layer Services

   : application 프로세스 사이의 논리적 통신을 제공한다.

   : Transport protocols는 end-system에서만 사용이 되어진다.

     (send-side: app message를 segment로 분해한다. rcv-side : segment들을 다시 message로 재조합 하고 application layer로 보냄)

 - Transport Service

-> Underlying IP layer : best effort network

(ex. 우체국 : 우체부가 편지를 보내기 위해 최선을 다하지만 우체부는 그 편지가 수신자에게 제대로 갔는지, 전달을 받았는지 확인을 할 방법이 없는 것이다.)

• packet loss
• out-of sequence
• Duplicate packets
•      -> TCP를 통해 이것을 해결할수 있다.
• An arbitrarily long dely
•      -> 이것은 해결을 할수가 없다.

 - Internet transport-layer protocols

-> TCP(Transmission Control Protocol)

     : Connection-oriented

     : Reliable, In-order delivery -> error 발생시 recovery를 실시한다.

     : congestion control

       -> 송신측에서 보내는 속도를 조절하여 네트워크에서 buffer overflow가 일어나지 않도록 하는것을 의미한다.

       -> network 상에는 sender가 보내는것을 임시 저장하는 buffer가 존재하고 그 buffer가 가득차게되면 다음 오는 것들이 loss가 일어나 reliable하지 않게된다. 이를 막기 위해 congestion control이 필요하게 된다.

     : flow control

       -> 송친측에서 보내는 속도를 조절하여 수신측에서 큐가 넘치지 않도록 관리를 하는 것이다.

       -> 수신측에서 송신측에서 보내는 데이터를 받아 상위계층으로 보낼때 자신이 받은 데이터들을 큐를통해 관리를 하게 되는데 이 큐보다 많은양의 데이터가 들어오는것을 막아 loss발생을 방지하는것이다.

     : Multiplexing/demultiplexing

 

-> UDP(User Datagram Protocol)

     : Connectionless

     : Unreliable, undordered delivery -> loss발생해도 조치를 하지 않는다.

     : no-frils extension of "best-effrot" IP

     : Multiplexing/demultiplexing 

 

-> TCP, UDP 모두 dealy guarantees와 bandwidth gurantees서비스를 제공하지 않는데 이는 인터넷 상의 문제이기 때문이다.

 

2. Multiplexing and demultiplexing

   : 많은 어플리케이션들은 단일 transport layer protocol을 사용한다.

-> Multiplexing : sender측에서 일어나는 것으로 여러 socket에서 오는 데이터들에 transport header를 추가하여 보낸다.

-> Demultiplexing :  segment에서의 header정보를 이용해 적절한 socket들로 보내게 된다.

 - Demultiplexing

-> 목적지의 host는 전달받은 segment들을 각자 맞는 process로 보내게 된다. (각각의 segement들은 source, dest port번호를 가진다.)

-> process들을 구분하기 위해 port #를 사용하게 된다.(0~65535)

-> client program

     : ephemeral port number를 사용하게 되는데 이는 os에서 사용하고 있지 않는 port number중 랜덤하게 하나를 선택하여 할당하여 주는 것을 의미한다.

     :  client 쪽 app에서는 자신의 port를 몰라도 된다.(server로 요청할때 알아서 port #를 넘기기 때문에 client의 server는 port#를 안다.)

-> server program

     : well-known port #를 사용한다.

     : server에서는 대게 port #를 고정시켜 놓고 사용을 한다.

 

 - Port Number

-> well-known ports : 0~1023까지를 사용하고 있으며 유명 서비스들을 위해 할당 되어있는 port #

-> registered ports

     : 1,024~49,151 까지의 범위를 가지고 있다.

     : 기업에서 서비스를 위해 다른것과의 port #충돌을 피하기 위해 독점적으로 port #를 사용하겠다 신청을 하여 사용한는 것

-> dynamic(private) ports

     : 49,152~65,535

     : 어떤 단체에 의해 관리되어지거나 등록되어지지 않는다.

     : 어떤 process에서든 사용이 가능해진다.

     : ephemeral ports를 위해 사용이 된다.

 - Demultiplexing

	UDP 에서의 demultiplexing     -> socket은 port# 와 IP addr가 같은것을 다 받아들인다.     -> 서로 다른 IP주소에서 보내더라도 체크할 필요 없이 그냥 자신의 IP 와 해당 port#로오는것은 받는다     -> 1 대 다 통신이 가능하게 해준다 (multicast service)
	TCP 에서의 demultiplexing      -> dest 의 port #가 같고 src의 IP주소가 다르면 서로 다른 socket을 사용하여야 한다. (여러곳에서 해당 port로 오더라도 받기로한 IP것만 받는다.)      -> 1대1 통신만 가능하다.

 

3. Connectionless trasport : UDP

-> A simple connectinoless Internet trasnport protocol

    : connection을 위한 핸드쉐이킹과정이 필요가 없으며 각각의 UDP segment들은 독립적으로 관리가 되어진다.

-> No reliability

    : segment가 loss되거나 잘못된 순서로 도착하더라고 recovery작업을 하지 않는다.

    : flow control/ congestion control을 하지 않는다.

    : error를 check를 하는 방식은 checksum을 이용하는것 이외에는 존재하지 않는다.

-> UDP 장점

    : 구현상 간단하다.

    : congestion control이 없기 때문에 sender는 빨리빨리 보낼수가 있다.

    : connectino overhead가 발생하지 않는다(connectionless의 장점)

    : 1대다 간의 통신이 가능하다.

-> 스트리밍 멀티미디어 서비스에 사용이 되어진다.

    : loss가 발생해도 된다.

    : 빠르게 보내는 것이 중요하다.

-> reliability의 경우 UDP 자체에서는 불가능하기에 application 단에서 해결을 해주어야한다. 

 

 - UDP header format

UDP header  pseudo-header

-> source port # : 자신(sender)의 port 번호를 의미한다.      -> dest port # : 상대방(receiver)의 port 번호를 의미한다.      -> total length : header와 data의 길이의 합을 의미한다.      -> checksum           : UDP에서 유일한 에러 체크 방법이다.           : 에러 감지를 위해 모든 header+data+pesudo-header를 더함           : 에러가 감지가 되면 해당 segment를 버리고, recovery 작업은 취하지 않는다.      -> sequence나 ACK가 헤더 필드에 없기 때문에 segment들이 순서대로 오는지 알수가 없다.        -> pseudo-header의 경우 check sum만을 위해 사용이 될뿐 전송이 되어지지는 않는다.      -> protocol의 규칙인 상위레이어의 데이터를 쓰는것이 아닌 하위 레이어의 데이터를 사용하게 된다.(IP addr, protocol)

 

 - UDP checksum

    -> 전송된 segment에 에러가 있는지 확인하기 위해 사용되어지는 것

    -> 데이터들을 모두 16bit 정수의 나열로 본다

    -> data들을 모두 16-bit 1's complement arithmetic을 이용하여 더하고 결과에 1's complement를 취한다.

    -> sender 측에서 checksum을 계산하여 보내고 그것을 이용하여 receiver측은 모든 데이터에 checksum까지 더해서 에러체크를 한다.

    -> 만약 해당 결과가 모두 1이라면 에러가 없는것이고, 0이 포함된다면 에러가 존재함을 의미한다.

 

ex) 10110011  10101011  01011010  11010101이란 데이터에 대한 checksum

Sender측에서의 checksum       10110011    + 10101011      101011110    +               1        01011111    + 01011010        10111001    + 11010101      110001110    +               1            10001111      (sum)       01110000     (checksum)

-> 두개의 데이터의 합에서 carry out발생시 carry out 난것을 다시 더한다.           -> 모든 데이터를 더한것이다. -> 1's complement를 이용한 checksum

Receiver측에서의 Checksum        10110011    + 10101011      101011110    +               1        01011111    + 01011010        10111001    + 11010101      110001110    +              1            10001111  +   01110000       11111111

-> checksum을 포함한 데이터들을 받고 그 데이터들을 모두 더하게 된다.               ->sum을 구하는 방식까지는 동일하다  -> checksum을 더하게 된다. -> 모든 bit가 1면 에러가 발생하지 않음을 의미한다.