[네트워크] 3.2 TCP & UDP

PADO·2020년 11월 12일

컴퓨터네트워크

컴퓨터 네트워크

목록 보기

13/27

지난 시간 배운 내용

Transport layer에 대해 배우면서, 계층의 가장 핵심적인 기능인 MUX, DEMUX

MUX 헤더에 src(돌아오라고)와 dest(찾아가라고)의 포트 번호 넣는 행위
→ 한 칸 내려가 IP 계층에서 src와 dest의 IP 주소 넣음
DEMUX sender가 보낸 헤더의 포트 번호를 보고 포트를 식별함

UDP/TCP 소켓이 dest에서의 소켓을 찾아야 함.

application 계층의 메시지를 기다리는 process에게 전달해주는 게 transport layer의 역할 (process to process communication을 support)

process를 찾는 행위 ⇒ 소켓을 찾는 행위

Connectionless demultiplexing

connectionless ⇒ UDP (at receiver)

demux는 destination에서 실행중인 여러 개의 프로세스들 중 소켓 찾기

by sender가 붙인 dest port number (destination에 도착해 layer를 올라갈 때 발생) ⇒ 같은 port number를 가진 패킷은 같은 소켓으로 도착

Client 끼리 통신하는 게 X. Client끼리는 같은 서버와 통신함

UDP에서는 여러 클라이언트가 서버의 같은 소켓으로 통신 하기 때문에 UDP segment 헤더에 있는 dest의 IP주소와 port 번호로 클라이언트를 구분해야 함

→ TCP는 서버가 두 클라이언트를 위한 각각의 전용 소켓을 하나씩 갖고 있음

→ UDP는 서버가 두 클라이언트를 위한 하나의 소켓을 가짐

(DNS 서버는 클라이언트를 위한 소켓이 하나 열림)

Connectionless demux: UDP

각 프로세스는 자신의 IP주소와 port #를 넣은 socket을 연다.

P3가 P1에게 보낸 데이터의 UDP Segment에서 source port는 9157, dest port는 6428.

6428 port를 연 P1 서버는 port #만으로 자신에게 온 메시지인지 확인할 수 없기 때문에 (같은 port를 연 다른 서버일 수 있음) IP주소를 transport 계층까지 올려 IP주소와 port #로 소켓을 찾는다. (Layering이 완벽히 이루어지지 않음)

IP주소는 network 계층만 보는 것이 아니라, 보고 한 계층 더 올려줌

= socket을 identify하는데 3계층 파라미터를 사용

P1 서버는 자신에게 온 데이터에서 source IP와 source port #를 보고 응답.

UDP: ONLY ONE SOCKET at Server for multiple clients (DNS)

Connection-oriented demux

TCP는 각 클라이언트 만의 dedicated된 socket을 열기 떄문에 return port #를 알고 있음. return 주소를 socket에게 알려줄 필요가 X

TCP socket identified by 4-tuple
- source IP address
- source port number
- dest IP address
- dest port number
server host may support many simultaneous TCP sockets:
- each socket identified by its own 4-tuple

Connection-oriented demux: TCP

(가운데의 서버에는 항상 연결을 대기하는 welcome socket이 안 그려져 있음)

서버는 Client process들 당 전부 다른 소켓을 갖고 parallel하게 처리

Client process는 모두 같은 destIP, dest port #를 갖고 있을지라도, source 정보가 다르기 때문에 다른 소켓으로 처리 가능

UDP: User Datagram Protocol

UDP(User Datagram Protocol)는 transport layer에서 포트 번호를 이용해서 application layer에서 전송된 데이터를 multiplexing해 세그먼트로 만들어 network layer로 보내고, 반대로 network layer에서 올라온 패킷을 demultiplexing해 application layer로 보낸다.

UDP 세그먼트는 다음과 같은 특징을 가진다.

"best effort" - 아무것도 보장하지 않는다.

segments may be:
- lost
- out-of-order to app
  
  : 내용이 전송 중에 손실 될 수 있고, 전송되는 세그먼트의 순서가 바뀔 수 있다.
connectionless:

no handshaking btw UDP sender, receiver ⇒ fast

each UDP segment handled independently of others

: 연결 상태를 만들지 않는다. (connectionless)

세그먼트에 추가되는 헤더가 적어 오버헤드가 적고, 빠르다
UDP use: (loss보단 throughput에 민감한 app들)

streaming multimedia apps (loss tolerant, rate sensitive)

DNS

SNMP
UDP: segment header

no connection = no conn. setup delay → fast

small header = small function

no congestion control → good for rate sensitive applications

UDP checksum (e2e checksum)

detect "errors" in transmitted segment in edge (host)

체크섬은 전송된 데이터가 변형이 되지 않았는지 확인하는 값이다.

전송하려는 세그먼트의 값들을 이용해 체크섬을 만들어서 세그먼트에 담아 전송한다. 세그먼트를 받은 상대는 세그먼트의 값들을 이용해 다시 체크섬을 계산하고 세그먼트에 저장된 체크섬 값과 비교한다.

sender
16bit 단위로 segment contents를 끊어 더한 후 (오버플로 돼서 캐리된 값들을 다시 더함) 1의 보수를 취한다.
receiver
sender와 같은 행위를 한 후 sender가 보낸 checksum과 다른지 비교한다
다르다면: error detected → drop or report
같다면: no error detected

(2 bits in 16-bit distance flip → 못 찾음)

e2e checksum을 하는 이유?

All 2-layer protocol cannot do checksum
error can happen at NW routers' buffer

Reliable Data Transfer Mechanism

TCP의 목적: receiver가 loss(= Gap)없이, in order로 메시지를 받는 것

→ error checking 필요

Acknowledgement: ~까지 받았어. 다음부터 보내줘 (TCP)
Negative acknowledgement: # 못 받았어. (UDP)
Sequence number: TCP는 byte단위로 data numbering.
number의 gap이 생기면 loss가 생긴 것

timer: 안 오면 언제까지 기다려야 하나? 시스템의 오버헤드

timeout = 잃어버렸다고 판단 → retransmit

Timer의 비효율성

premature timeout → retransmit, duplicated data
ACK loss → retransmit, duplicated

Pipelining & Window

Pipelining: 한 번에 여러 개 보낼 수 있다.

TCP sliding window, cumulative ACK : ACK을 받지 않아도 w만큼 data 전송

cf. TCP는 full-duplex comm.를 support (보내면서 받기)

TCP: Overview

point-to-point:

one sender, one receiver

단일 송신자와 단일 수신자를 가짐, 멀티캐스팅(단일→여럿) 불가능.

reliable, in-order byte stream:

byte 단위로 numbering

connection-oriented:

handshaking (exchange of control msgs) inits sender, receiver state before data exchange

full duplex data:

bi-directional data flow in same connection

MSS: Maximum Segment Size

flow controlled:

sender will not overwhelm receiver, window size 결정

congestion controlled:

sender will not overwhelm network, window size 결정

pipelined:

window size안에서 여러 개의 TCP segment가 ACK없이 전송 되는 것

TCP segment structure

20 bytes의 TCP 헤더

Quiz

(65: in-depth question) UDP 혹은 TCP가 demux 할 때 소켓을 식별하는 port번호 뿐만 아니라 IP 주소도 함께 사용한다. 그런데 이미 network 계층에서 자신의 IP 주소로 잘 도착한 것을 확인하고 transport 계층으로 올려준 것인데 굳이 IP 주소까지 다시 확인하고 소켓을 찾아서 demux해야하는 이유는 무엇인가? 즉, socket을 생성할 때 identification으로 자신의 port 번호 외에 IP 주소까지 사용하는 이유는 무엇인가? (힌트: 교과서(강의 슬라이드)는 호스트가 하나의 IP 주소를 가지는 경우를 가정하고 설명하고 있으나, 서버 혹은 클라이언트 호스트도 둘 이상의 network interface를 가질 수 있음)

⇒ 서로 다른 호스트가 같은 포트 번호를 사용할 수 있으므로, 포트 번호 외에 IP 주소로 머신을 식별할 수 있도록, network 계층에서 IP주소 확인 후 transport 계층에 올려보내 준다. 이 과정에서 완벽한 layering이 이루어지지 않는다.

(서버, 클라이언트 무관하게) 호스트가 둘 이상의 IP 주소를 가지고 있을 경우 (둘 이상의 network interface를 가지고 있어 둘 이상의 IPv4 주소를 가지는 경우, 혹은 하나의 network interface에 IPv4주소와 IPv6 주소를 모두 가지고 있는 경우), 다른 IP 주소를 destination IP주소로 하여 도착한 패킷은 transport 해더의 destination port 번호가 동일하더라도 다른 소켓으로 전달 되어야 한다. 이를 구별하기 위해서 application process가 소켓을 열 때 port 번호외에 IP 주소도 함께 식별하도록 하는 것이다.

추가적인 설명으로, 포트번호는 IP 주소 당 관리됩니다. 만일 어떤 DNS 서버가 두개의 IPv4 주소 23.24.25.26 과 23.24.25.27을 가지고 있다면 두개의 소켓 (23.24.25.26, 53), (23.24.25.27, 53)이 생성됩니다.

(66) Internet checksum이 발견할 수 없는 error는 어떤 경우인가?

⇒ 16-bit 차이나는 2 bits가 flip 되어 있을 때 checksum이 발견할 수 없다.

(67) 만일 모든 계층 프로토콜들이 error checking과 retransmission을 한다고 해도 end host에 있는 transport 계층에서 UDP 혹은 TCP가 하는 error checking이 필요한 경우가 있다. 어떤 경우인가?

⇒

NW routers' buffer에서 loss가 발생할 수 있다.
모든 end host의 2계층이 checksum 과정을 수행하진 않는다.

모든 계층 (2계층) 프토토콜들이 error checking을 한다고 하였으므로, 답은 아래만 적으면 되겠습니다.

중간 라우터의 버퍼 메모리에서 발생하는 에러는 중간 노드들의 2계층에서 실행하는 error checking으로는 감지할 수 없으므로 (ingress에서 들어올때 OK로 확인했으나 output buffer 에서 flip된다음 그 flip된것을 checksum하여 보낸다면 수신측 2계층은 이미 오류가 난것을 checksum하게됨)

(68) TCP가 point-to-multipoint (multicast) 방식의 communication 구현에는 부적절한 이유는?

⇒ ~~각 client마다의 dedicated된 socket을 사용하므로 point-to-point 방식의 communication만이 가능하다.~~

(1) Multicast (혹은 broadcast)는 sender가 메시지를 보내기만 하지 받지 않으므로 receiver 측이 sender가 보낸 세그먼트(패킷)에 대해 일일이 잘 받았는지 응답(response 혹은 ACK)을 보내는 TCP 와는 맞지 않는다.

(2) multicast는 sender 소켓이 한번 전송하면 중간 라우터에서 여러 수신자에게 전송하는 것을 구현하는 방식이다. 그러므로 sending rate을 조정하는 flow control을 하기 위해서 어느 receiver 버퍼의 상태를 반영 해야 하는지 알 수없다.

(3) 만일 TCP로 multicast를 구현한다면 sender가 보낸 메시지를 여러 수신자들 중 한 수신자라도 제대로 받지 못한 경우 재전송이 일어나며, 이는 정상적으로 메시지를 받은 나머지 수신자들에게도 불필요하게 재전송이 일어나 네트워크 자원의 낭비가 발생하게 된다.

(69) reliable data transfer를 구현할 때 수신측에서 이미 정상적으로 받은 데이터를 다시 수신하게 되는 경우 두 가지를 설명하시오.

⇒

sender로 ACK이 도착하기 전 timeout이 걸린 경우
sender로의 ACK이 손실 된 경우

(1) 송신측에서 전송한 데이터가 잘 수신되었는지 확인하기 위한 타이머의 timeout 값을 너무 짧게두어 정상적으로 전송된 데이터의 ACK이 timeout 이후에 도착한 경우

(2) 수신측에서 데이터를 정상으로 받은 후 전송한 ACK이 중간 네트워크에서 loss된 경우

(70) T/F를 표시하시오.

(a) UDP가 error checking 후 bit error를 감지한 경우 반드시 application에게 report 한다.

⇒ F. report 하거나 drop 할 수 있다.

(b) UDP의 checksum과 TCP의 checksum은 알고리즘이 다르다.

⇒ F. 필드는 다르나 알고리즘은 같다.

⇒ T

(d) TCP는 양쪽 호스트에서 sending을 동시에 수행하는 full duplex 통신을 지원할 수 있다.

⇒ T.

UDP는 어떤 type의 통신을 지원하느냐고 묻는다면 UDP를 사용하는 응용에 따라 half-duplex와 full-duplex 모두 가능합니다.

(e) TCP는 application 계층에서 보낸 메세지 단위로 loss를 감지하고 재전송을 수행한다.

⇒ F. 메시지를 byte 단위로 numbering해 loss를 감지하고 재전송을 수행한다.

(f) Sender TCP가 sending rate을 조정할 때 상대 TCP의 receiver 버퍼 상태는 고려해서 조정하나 중간 라우터의 버퍼 상황까지는 고려하지 않는다.

⇒ F. NW router들의 버퍼 상황을 고려하는 congestion control을 수행한다.

(g) receiver TCP가 받은 TCP 세그먼트 해더의 ACK flag bit가 0 인 경우에도 ack number 필드를 읽는다.

⇒ ?

만일 A 호스트의 TCP가 호스트 B로 부터 segment를 받았을때 해더의 ACK flag가 0이라는 것의 의미는 B가 A로 부터 이전에 받은 segment들은 모두 ACK 했기때문에 더 이상 ACK할 segment (즉 마지막 ACK 이후 새로 받은 segment)가 없다는 의미입니다.

(h) receiver TCP가 받은 TCP 세그먼트 해더의 sequence number 필드 값은 body에 실려있는 데이터의 첫번째 바이트에 붙여진 sequence number이다.

⇒ ?

T sequence number field는 byte단위로 data를 넘버링한 필드

PADO

이전 포스트

[네트워크] 3.1 Transport Layer

다음 포스트