Move Fast

▶ Fast Retransmit (빠른 재전송)

- 재전송 타이머 값이 종종 상대적으로 길어지므로, 손실된 패킷의 재전송 전에 지연시간이 커진다.

- 위의 상항을 해결하고자 중복 ACKs를 통해 손실된 세그먼트를 검출한다.

- 송신측에서 바로바로 여러 개의 세그먼트를 전송할 경우, 세그먼트가 손실되면 수신측에서는 중복 ACK를 보내게 되는데, 타임아웃 전에 송신측에서 중복 ACK를 3번받게 되면 세그먼트를 즉시 전송한다. 즉, 수신측이 기다리는 순서번호의 세그먼트보다 큰 순서번호의 세그먼트가 3개 도착할 경우를 의미한다.

[ ACK2 의 중복수신 3번 이후 3번 데이터 즉시 전송 ]

▶ Flow Control

- TCP 송신자가 데이터를 너무 빠르게 또는 너무 많이 전송하여 수신버퍼가 오버플로우(Overflow)하는 것을 방지한다.

- TCP의 수신자는 수신버퍼(receive buffer)를 가지는데, 상위 계층으로 세그먼트를 보내는 애플리케이션 프로세스가 수신버퍼로부터 데이터를 읽는 속도가 느릴 수 있다.

- 목표 : 애플리케이션 프로세스의 읽는 속도 = 송신자가 데이터를 전송하는 속도

- 즉, 흐름제어는 속도를 일치시키는 서비스이다.

- Receive Window(rwnd) : 수신버퍼의 가용 바이트 수로, 송신 윈도우 크기를 결정한다.

LastByteRcvd - LastByteRead <= RcvBuffer

[밑에서 수신 받은 번호 - 위로 올려 보낸 번호 = 수신했지만 상위계층으로 전송되지 않은 데이터들]

=> 항상 수신 버퍼보다 작아야한다. 초과하면 오버플로우 발생.

rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)

    = RcvBuffer - (수신했지만 상위 계층으로 전송하지 않은 데이터들)

- 수신자는 TCP헤더에 수신버퍼안에 있는 여유공간(Receive Window, rwnd) 값을 포함함으로써 버퍼에 공간이 있음을 송신자에게 알린다.

- 수신버퍼의 크기는 소켓의 옵션을 통해 설정되는데 디폴트 값이 4096바이트이다.

▶ TCP Overview

- 점대점(Point-to-Point) : 단일 송/수신자간의 통신   ex) 일대일 통신, Unicast 전송

• Unicast : 고유 주소로 식별된 하나의 네트워크 목적지에 메시지를 전송하는 방식
• Broadcast : 송신 가능한 모든 목적지에 동일한 데이터를 전송
• Multicast : 특별한 주소 지정 방식을 통해 정해진 여러 목적지로 데이터를 전송
• 호스트가 무수히 많은 경우, Unicast로 데이터를 전송하면, 각각의 네트워크 연결마다 호스트의 컴퓨팅 리소스(자원)을 소비할 뿐 아니라 각각 다른 네트워크 대역폭을 필요로 하기 때문에 전송 비용이 많이 든다는 단점이 있다.

- 파이프라인(Pipeline) : TCP의 혼잡 제어 및 흐름 제어가 윈도우 크기(Window size)를 결정한다.

• Window size : ACK받지 않은 데이터 중 최대 송신가능한 바이트 수, 수신자가 한 번에 버퍼링할 수 있는 최대 데이터 크기
• Sliding Window : 두 개의 네트워크 호스트 간의 패킷의 흐름을 제어하기 위한 방법으로, TCP 프로토콜은 데이터의 전달을 보증해야 하므로 패킷 하나 하나가 정상적으로 전달되었음을 알리는 확인 신호(Acknowledgement, ACK)를 수신자가 송신자에게 보내야 한다.
• 패킷에 오류가 생겼을 경우, 송신측에서 해당 패킷을 재전송해야 하는데 이 때 Sliding Window가 Window Size(메모리 버퍼의 일정 영역)에 포함되는 모든 패킷을 전송하고, 패킷의 전달이 확인되는 대로 이 Window를 옆으로 옮김(Sliding)으로써 그 다음 패킷들을 전송할 준비를 한다.

- 전이중성 데이터(Full-duplex Data) : 같은 연결 상에서 양방향 데이터 흐름

- 최대 세그먼트 크기 (Maximum Segment Size, MSS)

• 헤더를 제외하고 TCP가 실을 수 있는 최대 데이터 크기
• 기본값은 IPv4 -> 536 Byte, IPv6 -> 1220 Byte이다. 
• 최대 전송 단위(MTU)에 의해 값이 결정되며, MSS값은 헤더의 MSS 옵션 필드에 저장된다.
• 연결에 참여하는 두 장비가 서로 다른 MSS값을 갖을 수도 있다.

- 최대 전송 단위(Maximum Transmission Unit, MTU)

• 데이터 링크(2계층) 또는 네트워크(3계층)에서 하나의 프레임 또는 패킷에 담아 운반할 수 있는 헤더를 포함한 최대 데이터 크기
• 최소 권고값은 2계층 기준 1500Byte이며, 3계층 기준 IPv4는 MSS 크기에서 40byte(IP헤더+TCP헤더)를 추가한 576Byte이고, IPv6는 1280Byte이다.
• 실제로는 최대 65,646바이트 범위까지 생성가능하다.

- MTU가 IP 기반의 정보인 반면, MSS는 TCP 기반의 정보이다.

- TCP는 연결지향형으로 제어 메시지들의 교환(Handshaking)이 이루어진다. 핸드쉐이킹을 통해 데이터 교환 전에 송신자 및 수신자의 상태를 초기화한다.

- 흐름 제어(Flow Control) : 수신자의 속도에 맞춰서 송신자가 데이터를 보낸다.

▶ TCP Segment

- Source port number : 출발지 포트 번호

- Destination port number : 도착지 포트 번호

- Sequence number : 순서번호(Seq#)로, 세그먼트에서 첫 번째 바이트의 바이트 스트림 번호값이 저장된다.

- Response number : 확인응답(누적된 ACK)번호로, 상대방으로부터 받아야할 다음 바이트의 순서번호값이 저장된다.

ex) ACK100이 들어있으면 99번 데이터까지 잘 받았음을 의미한다.

- Header length : 헤더의 길이로, Option이 없으면 헤더값에 5개의 비트값이 들어간다. 그러나 일반적으로 32비트이다.

- Reservation : 나중에 다시 설명

- Control flag 

• 구체적으로 flag순서는 URG, PSH, RST, SYN, FIN이고 각각 1비트로 표현되는 값이 저장된다.

• 중요한 부분만 집어보자면, 통신과정에서 연결 설정이 필요할 때 RST, SYN, FIN을 사용한다. 

• RST는 연결을 재설정(Reset)할 때 연결을 종료하기 위한 비트값으로 비정상적인 세션 연결 끊기가 해다된다. 

• 연결 요청 시에는 SYN=1 의 비트값을 넣어 세그먼트를 전송한다.

• 연결 해제할 때는 FIN=1 의 비트값을 저장하여 세그먼트를 전송한다.

- Window : 수신측의 윈도우 크기(Window size)로, 받을 수 있는 최대 데이터 크기값이 저장되어 있다.

- TCP Checksum : 검사합(Checksum)이 저장되는 데, 체크섬값이란 세그먼트의 합에 1의 보수를 취한 값을 말하며, 수신측에서 체크섬과 세그먼트의 실제 데이터를 더한 결과를 통해 오류를 검출한다.

- Emergency Data point : 생략

- Option : 변수의 길이로 설명은 생략.

- Data : 헤더를 제외한 실제 세그먼트에 들어있는 데이터의 크기로 MSS에 의해 제한되어진다.

▶ TCP Round Trip Time, Timeout

- TCP는 신뢰적인 데이터 전송(RDT)처럼 세그먼트의 손실을 발견하기 위해 타임아웃/재전송 메커니즘을 사용한다. 이 때, 송신측에서 데이터를 전송한 후, ACK받기까지 걸린 시간을 RTT(Rount Trip Time)이라 표현한다.

- 타임아웃(timeout) 주기는 RTT보다 길어야 한다. 너무 짧으면 타임아웃이 자주 발생하여 세그먼트의 불필요한 재전송이 발생하므로 링크를 비효율적으로 사용하게 된다. 반대로 너무 길게 되면, 세그먼트의 손실에 대한 느린 대응으로 회복이 비효율적이게 된다.

- SampleRTT : 세그먼트가 송신된 시간부터 ACK 받기까지 측정된 시간으로, 재전송한 세그먼트는 무시한다. 값은 네트워크 부하에 따라 가변적이다.

- 현재 SampleRTT 값이 아닌 최근의 값들의 평균값으로 추정한다.

- 추정RTT : EstimatedRTT = (1-a) * EstimatedRTT + a * SampleRTT

일반적으로 a=0.125이고, 지수적 가중 이동 평균(EWMA)방식으로 과거 샘플들의 영향이 지수적으로 감소한다. a가 높을수록 SampleRTT에 더 영향을 준다.

- DevRTT : RTT 변화율로, SampleRTT와 EstimatedRTT의 편차값이다. 즉, 현재 RTT값이 추정 RTT값으로부터 얼마나 벗어났는가에 대한 정보이다.

- 재전송 타임아웃 주기 (Timeout Interval) = EstimatedRTT + 4 * DevRTT

- 타임아웃나서 세그먼트를 재전송하게 되면, 재전송한 세그먼트에 대한 타이머가 시작된다.

▶ TCP의 RDT

- TCP는 비신뢰적인 인터넷 네트워크 계층(IP서비스)의 상위 계층에서 신뢰적인 데이터 전달(Reliable Data Transfer, RDT) 서비스를 제공한다.

- 파이프라인되는 세그먼트 (ACK의 응답이 없어도 다수의 세그먼트를 전송가능)

- 누적된 ACKs

- 단 하나의 재전송 타이머

- 재전송은 타임아웃이 되거나, 중복 ACKs를 수신했을 경우 발생한다.

- “간소화된 TCP 송신자”는 중복 ACKs를 무시하고 흐름제어 및 혼잡제어를 무시한다.

▶ TCP 송신자의 3가지 상황(Sender Events)

- 상위 계층으로부터 수신된 데이터 : 데이터를 받았으므로 상위 계층으로부터 데이터 전송 요청이 오게 된다.

• 순서번호(Seq#)를 가진 세그먼트 생성 (Seq# : 세그먼트의 첫 번째 바이트의 바이트 스트림 번호)

• 타이머가 실행되지 않고 있으면 타이머를 시작한다.

• 타이머의 만료주기는 Timout Interval 로 계산한다.

- 타임아웃 : 타임아웃에 의해 세그먼트가 재전송되고, 전송했으나 ACK 받지 않은 가장 오래된 세그먼트에 대해 타이머가 다시 시작한다.

- ACK를 수신한 경우 : 이전에 ACK받지 않은 세그먼트의 ACK 이면, 해당 세그먼트를 ACK 응답된 세그먼트로 표시한다. 즉, 윈도우 크기를 조정한다. 아직 ACK받지 못한 세그먼트들이 존재한다면 타이머를 시작한다.

NextSeqNum = InitialSeqNum

SendBase = InitialSeqNum   //송신했으나 ACK되지 않은 가장 오래된 순서 번호

loop(forever) {

switch(event) {

event : data received from application above // 상위 계층으로부터 수신된 데이터

create TCP segment with sequence number NextSeqNum // 다음 순서번호를 가진 TCP 세그먼트 생성

if(timer currently not running) { // 아직 타이머가 시작하지 않았다면

    start timer //타이머 시작

}

pass segment to IP // 생성한 세그먼트 목적지 IP주소로 전송

NextSeqNum = NextSeqNum + length(data) // 전송할 세그먼트의 순서번호 변경

event : timer timeout // 타임아웃

retransmit not-yet-acknowledged segment with smallest sequence number

start timer

event : ACK received, with ACK field value of y //y번의 ACK를 수신한 경우

if (y > SendBase) { // 누적된 ACK가 도착한 경우(새 데이터가 온 경우)

SendBase = y;

if (there are currently not-yet-acknowledged segments) { //아직 ACK받지 않은 데이터가 남은 경우

    start timer //타이머 시작

}

}

}

}

- 세 가지 상황에 대한 재전송 시나리오

▶ TCP 수신자의 4가지 상황(Receiver Events)

<문제가 없는 상황>

- 기다리는 순서번호의 세그먼트가 도착. 즉, 이전의 데이터들은 모두 ACK받은 경우

 => 지연된 ACK 발생. 다음 세그먼트를 위한 500ms의 ACK타이머가 설정되고, 시간 안에 다음 세그먼트가 오지 않을 경우 ACK를 전송한다.

[ 오른쪽이 지연된 ACK의 모습 ]

- 기다리는 순서번호의 세그먼트가 도착. 하나의 다른 세그먼트가 ACK 지연시간(500ms)안에 수신된 경우

 => 하나의 누적 ACK를 송신측으로 즉시 전송한다.

<문제가 있는 상황>

- 기다리는 것보다 높은 순서번호를 가진 세그먼트가 도착. 즉, 송신측에서 여러 개의 세그먼트를 전송한 후 중간 세그먼트가 손실된 경우 => 즉시 기다리는 바이트의 순서번호에 해당하는 중복 ACK를 전송한다. 이 때, 보낼 세그먼트가 없더라도 ACK를 위해 헤더만 별도로 생성하여 송신측으로 전송한다. (ACK는 항상 세그먼트의 헤더에 포함되어 있음 - piggybacked ACK 방식)

- 위의 상황에서 발생한 갭(손실된 세그먼트)를 부분적으로 또는 모두 채워주는 세그먼트가 도착한 경우 => 부분적으로 도착하면 아직 받지 못한 세그먼트 중 가장 낮은(오래된) 순서번호의 ACK를 전송한다. 모두 도착했다면 위의 상황에서 높은 순서번호를 가진 세그먼트의 다음 세그먼트의 순서번호를 가진 ACK를 전송한다.

[ 왼쪽은 중복ACK, 오른쪽은 갭을 채우는 세그먼트가 모두 도착한 경우 ]

▶ Reliable Data Transfer(신뢰성 있는 데이터 전송, 이하 RDT)

- 현재까지 송수신간의 신뢰성 있는 데이터 전송 프로토콜을 개발해왔고, 단계적으로 그 과정을 살펴볼 것이다.

- 단방향 데이터 전송만을 고려해왔으나 제어 정보는 양방향으로 전송한다.

- RDT에서는 송신자와 수신자를 명시하기 위해 유한 상태 머신(Finite State Machines, FSM)을 사용한다.

[FSM]

▶ RDT 1.0

- 신뢰성 있는(오류 없는) 채널에서 신뢰적인 데이터 전송

- 하위 채널에 비트 오류가 없고 패킷(3계층 데이터 단위)의 손실이 없다.

- 송신자와 수신자가 분리된 유한 상태 머신을 가지고 있다.

- 송신자가 데이터에 헤더를 씌워 패킷으로 만들어 하위 채널로 데이터(패킷)를 전송하면, 수신자는 하위채널로부터 데이터를 받는다.

[ 각 2개의 상태를 가지고 있음 ] 

▶ RDT 2.0

- 하위 채널이 패킷에 비트 오류를 일으킬 가능성이 있다.

- 해결책으로 헤더에 설정한 체크섬(Checksum)을 통해 오류를 검출한다.

- RDT 1.0의 오류복구 기능 : 수신자의 피드백 ACK, NAK

• Acknowledgements (ACK) : 수신자가 송신자에게 “패킷이 잘 도착했음.“을 알리는 방식으로 송신자는 수신자로부터 ACK를 받으면 다음 패킷을 전송한다.
• Negative Acknowledgements (NAK) : 수신자가 송신자에게 “패킷에 오류가 발생했음.“을 알리는 방식으로 송신자는 NAK를 받는 즉시 오류 패킷을 재전송한다.

- 문제점 : ACK/NAK에서도 오류가 발생할 수 있다.

• 수신측이 보낸 ACK/NAK에 오류가 발생하여 송신측이 계속 기다리게 된다.
• 송신측에서 오류가 났는지 모르고 있으며, 패킷을 재전송할 수 없다.
• 송신측에서 중복패킷을 전송할 경우 수신측은 중복수신을 하게 된다.
• 즉, 비효율적인 링크 사용이 증가한다.

▶ RDT 2.1

- RDT 2.0의 해결책 : 각각의 패킷에 순서번호(Seq#)를 추가한다. 그러면 수신측에서 순서번호가 같은 패킷(중복패킷)을 버리게 되므로 중복수신이 방지된다.

- 송신자의 입장

• 패킷에 순서번호(0, 1) 추가 : 패킷은 0번->1번->0번->1번의 순서를 가진다. 즉, 0과 1의 상태로 기억된다.
• 수신된 ACK/NAK의 오류 여부에 대한 상태가 추가되어 RDT 2.0보다 상태 수가 2배 증가하므로 총 4개의 상태를 가진다.

- 수신자의 입장

• 순서번호로 중복 패킷의 유무를 조사한다.
• 마지막으로 보낸 ACK/NAK가 송신측에서 제대로 받았는지 알지 못한다.

▶ RDT 2.2

- NAK가 없는 채널에서의 신뢰적인 데이터 전송

- NAK가 없다는 점을 제외하고 RDT 2.1의 기능과 같다.

- 수신자는 마지막에 올바르게 수신된 패킷의 ACK를 송신자에게 전송한다.

- ACK에는 패킷의 순서번호가 포함된다.

- 송신자가 중복된(동일한 순서번호의) ACK를 받을 경우 현재 패킷을 재전송한다.(NAK를 받았을 때와 같은 동작)

ex) 송신측에서 ACK 0번을 기다리는데 ACK 1이 올 경우 순서번호 0번의 데이터를 재전송한다. 그 이유는 1번 데이터는 받았으나 0번 데이터를 못받았기 때문이다.

▶ RDT 3.0

- 하위 채널에서의 패킷들(데이터, ACK)의 손실을 고려하였으며, 체크섬 ,순서번호, 재전송 모두 도움은 되나 근본적인 해결이 충분치 않다고 판단

- 카운트다운 타이머

• ACK를 계속 기다리는 것이 비효율적이므로 송신자가 ACK에 대해 충분한 시간을 갖고 기다린다. 
• 그러나 해당 타이머 안에 못 받으면(타임아웃되면) 해당 순서번호의 패킷을 재전송한다.
• 단, 패킷이 손실되지 않고 지연되어 송신측이 똑같은 패킷을 재전송하면 중복패킷이 되나 순서번호로 이 문제를 해결할 수 있다. 순서번호가 같으면 수신측에서 드랍하기 때문이다.
• 즉, 수신자는 ACK 패킷의 순서 번호를 송신자에게 알려야 한다.

- 네트워크 프로토콜이 물리적 자원의 사용을 제한한다. 따라서 재전송을 원하는 만큼 할 수 없다.

- 기능적으로 잘 동작하지만 성능은 만족스럽지 못하다.

▶ 파이프라인 프로토콜(Pipelined Protocols)

- 배경 : RDT 3.0의 Stop-and-Wait 방식으로 인해 데이터가 많을 경우 대기 시간때문에 링크가 비효율적이게 사용되는 것의 해결책으로 나옴

- 송신자가 ACK의 응답을 받지 않고 다수의 패킷을 전송 (링크의 효율성 증가)

(즉, 송신자는 파이프라인에 최대 N개까지 ACK받지 못한 패킷들을 전송 가능)

- 순서번호 증가, 송신자와 수신자 사이에 패킷을 버퍼링해야함.

- GBN(Go-Back-N)

• 수신자는 누적된(cumulative) ACK만 전송 (수신된 패킷들의 순서번호 사이에 갭이 있으면 ACK는 응답하지 않음)
• 수신자는 비순차(out of order) 패킷으로 버퍼링하지 않는다.
• 송신자는 ACK받지 못한(문제가 생긴) 가장 오래된 패킷부터 모두 재전송 (타이머가 1개)

- Selective Repeat(선택적 반복)

• 수신된 패킷들 사이에 갭이 있더라도 갭 이후의 패킷들을 수신측에 있는 버퍼에 저장
• 즉, 수신자는 모든 패킷들에 대해 개별적으로 ACK 응답
• 상위 게층에 순차적으로 전달하기 위해 비순차 패킷들을 버퍼에 저장
• 비순차 패킷 -> 순차적으로 정렬 -> 상위 게층으로 전달
• 송신자는 개별 패킷마다 타이머를 가지고 있다.
• 문제가 생긴 패킷만 개별적으로 재전송

- TCP는 위 두개의 경우가 하이브리드된 형태로 사용한다.

▶ 전송 서비스와 프로토콜(4계층)

- 다른 호스트들이 계속 네트워크에 머물도록 응용 프로세스 간의 논리적 통신을 제공한다.

- 전송 프로토콜(Transport Protocol)은 종단점(end-system)에서 적용된다.

• 송신 호스트 : 데이터 메시지를 세그먼트로 분해하여 네트워크 계층(3계층)으로 전송한다.
• 수신 호스트 : 세그먼트들을 데이터 메시지로 재조립하여 응용 계층으로 전송한다.

- TCP와 UDP가 대표적인 전송 프로토콜이며, 그 외에도 많이 이용된다.

- Throughput(스루풋, 처리율) : 네트워크 통신에서 노드 사이 또는 파이프 사이에서 전달되는 단위 시간당 전송되는 디지털 데이터 처리량. 주로 초당 비트수(bps)가 사용된다.

▶ Transport VS Network Layer

- Network Layer(네트워크 계층, 3계층) : 호스트들 간의 논리적 통신을 돕는다.

- Transport Layer(전송 계층, 4계층) : 응용 프로세스 간의 논리적 통신을 돕는다.

- 네트워크 계층부터 하위 계층(1~3)들은 하드웨어적인 통신을 많이 다루고, 전송 계층부터 상위 계층(4~7)들은 소프트웨어적인 통신을 많이 다룬다.

▶ 인터넷 전송계층 프로토콜

- Transmission Control Protocol (전송 제어 프로토콜, 이하 TCP)

• 신뢰성 있고, 순서가 보존되는 전송 시스템
• Congestion Control(혼잡 제어), Flow Control(흐름 제어), Connection Setup(연결 설정) 등 각종 오류를 제어한다.
• 웹 브라우저들이 월드 와이드 웹에서 서버에 연결할 때 사용되며, 이메일 전송 및 파일 전송에도 사용된다.

- User Datagram Protocol (사용자 데이터그램 프로토콜, 이하 UDP)

• 신뢰성 없고, 순서가 보장되지 않는 전송 시스템
• 꼭 필요한 기능(전송)만 하고, 오류 제어와 같은 추가 기능을 필요로 하지 않는 애플리케이션에 사용된다.
• 추가 기능이 없기 때문에 오버헤드가 작고 지연 시간이 짧다는 장점이 있다.

- 이용되지 못하는 서비스 : 시간 및 대역폭이 보장되지 않으므로 스루풋도 보장되지 않는다.

여기서 “보장되지 않는다.”는 것은 1초에 100개와 같이 딱 떨어지지 않음을 의미한다.

▶ Multiplexing & Demultiplexing

- 네트워크 소켓 (Network Socket) : 컴퓨터 네트워크의 사이에 있는 프로세스 간 통신의 종착점이다. 컴퓨터 간 통신의 대부분은 IP(인터넷 프로토콜)을 기반으로 하고 있고, 네트워크 소켓의 대부분은 인터넷 소켓이다. 네트워크 통신을 위해서 송,수신측에서는 소켓을 생성하고, 이 소켓을 통해 서로 데이터를 교환한다.

- Multiplexing(다중화) at Sender : 다수의 소켓들로부터 추가 정보(목적지 주소 등)를 얻어서 전송할 데이터의 헤더에 해당 정보(목적지 주소 등)를 추가하는 기능.

- Demultiplexing(역다중화) at Receiver : 수신된 데이터를 적절한 소켓으로 전달하기 위해 헤더 정보를 이용한다. 하위 계층에서 상위 계층으로 올라갈 때마다 헤더가 작아지면서 전송할 데이터가 목적지에 도착한다.

▶ 역다중화 과정

- 호스트는 IP 데이터그램(datagram)을 수신한다.

• 각각의 데이터그램 출발지 IP주소, 목적지 IP주소를 가지고 있다.
• 각각의 데이터그램은 하나의 전송계층 세그먼트를 옮긴다.
• 각각의 세그먼트는 출발지, 목적지 포트번호(16bits)를 가지고 있다.

- 호스트는 IP주소와 포트번호를 이용하여 세그먼트를 적절한 소켓으로 안내한다.

- IP Datagram

- TCP의 Segment

- IP 데이터그램이 세그먼트를 포함하고 있다.

- 데이터 전송 과정

- 비연결형 통신, UDP의 소켓

• 생성된 소켓은 호스트 로컬 포트 번호(source port #)만 가지고 있다.
• 호스트가 UDP 세그먼트를 받으면, 세그먼트에 있는 목적지 포트 번호를 확인한다.
• 해당 포트 번호로 세그먼트를 안내한다.
• 만약 서로 다른 출발지 IP주소, 포트 번호이지만 같은 목적지 포트번호나 IP주소를 가진 IP datagram을 받으면 목적지에서 같은 소켓으로 데이터가 전송된다.

- 연결 지향형 통신, TCP의 소켓

• 출발지 IP주소, 포트번호와 목적지 IP주소, 포트번호의 네 가지 요소로 소켓이 생성되어진다.
• 수신자는 세그먼트를 적절한 소켓으로 안내하기 위해 네 가지 값 모두 이용한다.
• 송신 호스트는 동시에 많은 TCP 소켓들을 지원할 수 있다. 단 각각의 소켓들은 각자 네 가지 요소를 가진며, 이를 통해 소켓이 구분된다.
• 웹 서버(송신자)는 각각의 클라이언트를 연결하기 위해 다른 소켓들을 가진다.

▶ UDP(User Datagram Protocol)

- 추가 기능(오류제어)이 없고, 꼭 필요한 기능만 있는 인터넷 전송 프로토콜

- 세그먼트가 손실될 수 있고, 순서가 뒤바뀔 수 있다.

- 송수신 간의 연결 설정(Handshaking)을 하지 않는다.

- 각각의 UDP 세그먼트는 독립적으로 다루어진다.

- 연결 설정이 필요 없는 짧은 메시지를 주고받을 때 사용된다.

- 실시간이 중요한 스트리밍 멀티미디어와 같은 응용프로그램, 도메인 네임 서버(DNS) 및 SNMP에 이용되어진다

- 애플리케이션 맞춤형 오류 회복이 추가되면서 UDP를 통한 신뢰성 있는 데이터 전송이 가능해졌다.

 - UDP 세그먼트

• 세그먼트의 길이를 두는 이유는 가변적 길이므로 끝이 어딘지 찾기 위해 필요로 한다.
• 송수신간의 연결 설정을 나타내는 연결 상태가 없으므로 단순한 구조이다.
• 8바이트라는 작은 헤더 크기를 가진다.
• UDP는 원하는 만큼 빠르게 전송할 수 있어서 혼잡 제어(Congestion Control)이 발생하지 않는다.

- Checksum(검사합) : 중복 검사의 한 형태로 오류 검출을 위한 기능을 한다.

• 송신자는 헤더 필드가 16비트의 정수를 나열한 것으로 간주하고, 세그먼트들의 합의 1의 보수를 취한 결과(체크섬 값)를 UDP 체크섬 필드에 저장한다.
• 수신자는 받은 세그먼트 값들의 합과 체크섬 값(결과)을 더한다. 만약 계산된 체크섬이 체크섬필드의 값과 같다면 더했을 때 비트값이 전부 1인 패턴이 나와야한다. 0이 하나라도 있으면 에러가 발생한 것이다.
• 아래는 체크섬의 예시이다.

다음과 같이 4 바이트의 데이터가 있다고 치자: 0x25, 0x62, 0x3F, 0x52

1 단계: 모든 바이트를 덧셈하면 0x118이 된다.

2 단계: 1바이트의 절반(4비트, 이하 니블)을 버림으로써 0x18을 만든다.

3 단계: 0x18의 1의 보수를 얻음으로써 0xE8을 얻는다. 이것이 체크섬 바이트이다.

체크섬 바이트를 테스트하려면 원래 그룹의 바이트에 체크섬 바이트까지 모두 더하면 0x200이 된다.

다시 니블을 버림으로써 0x00이 된다. 0x00이라는 뜻은 오류가 없다는 뜻이다. (하지만 오류가 있어도 우연히 0x00이 될 수도 있다.)