Chapter 23. TRANSPORT LAYER : UDP AND TCP

 

---

◆ Process-to-Process Delivery

데이터 링크 계층은 node-to-node (hop-to-hop)

네트워크 계층은 host-to-host

전송 계층은? process-to-process

 

서버-클라이언트 의 관계를 갖고 있음. (서버-클라이언트 프로세스는 서로 이름 같음!)

클라이언트(로컬 호스트의 프로세스)와 서버(원격 호스트의 프로세스)사이 서비스가 필요함!

 

---

◆ Process-to-Process Delivery - Addressing

전송 계층의 주소 체계는 포트(Port) 번호를 사용한다.

포트 번호를 가지고 어느 프로세스로 가야하는지를 식별함!

 

포트 번호는 ‘0~65535’까지의 숫자로 되어 있으며(16비트로 표현), 범위에 따라 용도가 정해져 있음.

 

그중 잘 알려진 포트(well-known port)는 '0~1023'번으로, 웹 서버나 메일 서버 등의 포트 번호로 정해져있음.

 

클라이언트 프로그램은 임시 포트번호(ephemeral port number)로 자신을 임의로 지정함.('1024 ~ 65535' 권장)

서버 프로세스도 자신의 포트번호를 지정해야 하는데, 임의로 지정할 수는 없음! 잘 알려진 포트 번호를 할당함.

 

 

 

---

◆ Process-to-Process Delivery - Socket Address

: IP 주소와 Port 번호의 조합

IP주소 뒤에 :포트번호 를 붙인 것.

HTTP의 경우 기본적으로는 :80 

 

---

◆ Process-to-Process Delivery - Multiplexing / Demultiplexing

ㆍMultiplexing
: 여러 개의 소켓으로부터 들어오는 메시지들을 하나의 세그먼트로 묶어서 네트워크 계층으로 전송하는 것

  애플리케이션 계층에서 메시지를 만들고 이들은 소켓을 통해 트랜스포트 계층으로 넘어간다. 데이터는 세그먼트로 캡슐화 되고 각 세그먼트를 네트워크 계층으로 전달하는 작업을 다중화 라고 한다. 

 

ㆍDemultiplexing
: 들어온 세그먼트의 데이터를 올바른 소켓으로 전달

  트랜트포트 계층에 상대 프로세스로부터 수신된 세그먼트 필드 집합이 있다. 이들은 사전에 설정된 트랜스포트 프로토콜에 따라서 알맞게 검사가 된다.  그리고 검사가 완료된 세그먼트 집합은 올바른 소켓으로 전달된다. 이를 역다중화 라고 한다. 여러개로 분할되어서 오는 세그먼트들을 한데 모아서 소켓으로 전송시키는 과정이다.

 

---

◆ UDP vs TCP

Process 간의 전달은 Reliability(신뢰성)이 있냐 없냐에 따라 TCP/UDP로 구분함.

 

Reliability가

• 없다 - UDP
  => 빠른 Delivery 위주의 서비스. Connectionless
• 있다 - TCP
  => 신뢰성이 필요한 서비스. Connection-Oriented

 

신뢰성이 있다는 것은

메시지를 전달했는지 상대방이 확인할 수 있어야하고,

나도 그것이 갔는지 안 갔는지 확인할 수 있어야 신뢰성 있는 것.

( == 패킷 전달을 보장한다는 것!)

 

어? 근데 이런것들은 2계층에서 다 했던 거 아니야? ㅇㅇ 맞음. 근데 3계층에서가 이슈가 됨. 3계층은 전달하기 위한 최선만 다하고 에러 컨트롤, 플로우 컨트롤은 난몰랑~ 했엇음 당연히 3계층에서도 패킷 드랍 등의 이유로 온전히 전달이 못될 수있기 때문에, 얘네가 잘 갔는지 안 갔는지 확인해주고 안 갔으면 다시 보내주고 이러는 게 신뢰성 있는 4계층(TCP)의 역할임.

 

---

◆ UDP (User Datagram Protocol)

🔑Connectionless, Speed, RIP

UDP는 Connectionless이기 때문에, 오버헤드(처리하기 위해 기다리는 시간)가 없다!

생긴 것도 심플함. 보안때문에 단순한 쳌썸 정도만 함

플로우 컨트롤도 없고, 에러 컨트롤도 없음.

확인 응답 받지도 않고, 그냥 자기 보낼거를 보내기만 하는 half-duplex service

 

 

그래서 맘만 먹으면 이걸로 나쁜 짓 할 수 있음. (뒤에 TCP 혼잡제어 파트에 짧게 언급함)

 

---

◆ TCP (Transmission Control Protocol)

🔑 Connection-Oriented, Reliable, Stream, Flow Control, Error Control, Congestion Control

 

ㆍTCP는 Connection-Oritented.

즉 연결 지향형이다. 연결을 먼저 하고 보냄

 

보내기 전에 연결을 하고나서 데이터를 보내는 것에서 하나의 스트림을 형성한다는 의미에서,

Stream delivery service라고도 함. 유튜브 스트리밍한다 할 때 그 스트림임. 

 

ㆍ 스트림이 형성된 상태 == 두 호스트(의 소켓)가 연결되고 상호간 데이터 송수신이 가능한 상태
스트림은 한쪽 방향으로 형성됨. 양방향 통신을 하려면 입력 스트림, 출력 스트림 따로 형성되어야 함

 

 

 

ㆍFull-duplex service

: 양방향

 

ㆍPiggybacking => 흐름/오류 제어

: 수신한 데이터에 대한 확인 응답을 즉시 보내지 않고, 데이터를 보내는 패킷에 포함해서 같이 전송하는 방식

 

 

 

ㆍBuffer 사용 =>흐름/오류/혼잡 제어

3계층에서 데이터그램 스위치를 쓰기 때문에, 쪼개지고 순서가 바뀔 수도 있다. 

때문에 버퍼에다 넣어두고 보내졌는지 아닌지, 들어왔는지 안왔는지 카운트해가면서 관리함.

 

[송신측]

Sent 부분은 보냈는데 확인 응답 아직 못받은 애들(응답 받으면 빈 공간됨)

Not sent 는 이제 다음에 보낼 애들(Next byte to send에 있는 애를 보냄). 혼잡 고려해서 조정해서 전송함.

흰 공간은 비워진 부분. Sent, Not sent 얘네들로 채워질 수 있음

 

[수신측]

Not read 는 수신 되었지만, 아직 수신 프로세스가 읽지 않은 부분(읽으면 빈 공간 됨)

흰 공간은 비워진 부분.

 

---

■ TCP 세그먼트 구조

 

 

 

ㆍSequence number =>흐름/오류 제어

내가 보내는 세그먼트마다 번호를 붙인다.

데이터 스트림의 순서 확인, 수신 확인의 기능도함.

받은 사람이 이걸 보고 어? 순서가 바꼈네! 기다리자~ 하는 것임

 

 

ㆍAcknowledgment number

바이트 번호 x를 잘 수신했으면, x+1번을 넣어서 보냄 (확인 응답과 데이터는 piggyback 가능)

 

 

ㆍControl
- Flow, connection establish, termination, transfer mode. .... 설정

URG : 이거 긴급한 데이터야!!!!

ACK : 확인 응답. 

PSH : 지금 데이터 보낼거야 밑에거 전부 다 데이터야

RST : 연결 리셋!

SYN : 너 살아있어? 확인

FIN : 연결 종료!

 

 

ㆍWindow Size => 흐름 제어

내 윈도우 사이즈 조정해서 적당히 보내줘~

rwnd란 수신자 윈도우를 뜻함

 

 

ㆍChecksum => 오류 제어

UDP와 같은 그 쳌썸

 

---

■ TCP 연결 과정

TCP는 연결 지향형이므로, 연결 해야겠지? 그럼 어떻게 연결하느냐?

ㆍThree-way handshaking

 

① 클라이언트가 SYN 세그먼트 전송(순서 번호 동기화 목적) .
- 너 살아있어?

② 서버는 SYN + ACK 세그먼트 전송 .
- ㅇㅇ 나 살아있어. 너도?

③ 클라이언트는 ACK 세그먼트 전송 .
- ㅇㅇ 

 

※ SYN Flooding - three way handshaking의 취약점을 이용한 공격 Handshaking 2단계 이후, 서버는 클라이언트가 3단계 ACK 응답을 주기까지 일정시간동안 이 연결을 que에 쌓아두고 기다림 (일정 시간이 지나면 초기화함.) 그런데 달라는 ACK 응답은 주지 않고, (que 초기화 시간이 되기 전에) 1단계 SYN 요청만 계~속해서 많이 보내서 악의적으로 서버가 다른 클라이언트와 연결 요청을 못받게 하는 방법이 SYN Flooding.

 

---

■ TCP 종료 과정

Half- close 방식 (일부만 종료) 

'반만 종료' 한다는 뜻으로, 입력 스트림/출력 스트림 중에 하나만 닫는 거.

안정적인 연결 종료를 위해 사용함!

그림에서 서버가 Half-close 할 때, 출력 스트림은 종료하고 입력 스트림은 열어둠.

=> 클라이언트로부터 데이터를 받을 수는 있는 상태! 

 

 

EX)

클라이언트 입장에서는 서버의 송신이 언제 끝날지 모르니까 언제까지 입력함수를 호출해야 되는지 모름.

따라서 서버가 클라이언트에게로 EOF(끝났음을 알려주는 문자)를 보내서 알려줘야 하는데,

데이터 안에 저런 문자가 포함되어 있을수도 있고 ㅠㅠ막 보내기 애매하다!

=> 출력 스트림 종료시 EOF를 함수 반환값으로 알려줌 (데이터랑 구별되니까 

=> 클라이언트는 끝났다는 거 알 수 있고, 서버는 아직 클라이언트 응답은 받을 수 있음! 이게바로 윈윈?~

 

(입/출력 스트림 모두 종료해도 EOF 가긴 함. 근데, 클라이언트가 중요한 데이터 보낼 게 남아있었다면?

못 듣고 끝나게 됨 ㅠㅠ 따라서 '나 이제 말 끝났다~' 까지만 알려줄 수 있는게 Half-close임.)

 

---

■ TCP 혼잡 제어

TCP에서는 혼잡 제어 서비스를 제공함.

 

ㆍSlow start

나로 인해서 네트워크가 어떻게 될지 모르니까, 쪼끔씩 보내기 시작해서 점점 늘려 나가는 방식.

아까 나왔던 Buffer 개념으로 쌓아두고 조금씩 보냄.

 

혼잡이란 중간에 네트워크들이 트래픽이 많아져서 문제가 생겼을 때를 의미

즉 패킷이 도착했는데 굉징히 늦게 왔다든지, 와야되는데 안왔다든지..

(3계층이 connectionless니까 packet이 drop될 수도 있음. 라우터는 자기한테 패킷 너무 많이오면 랜덤으로 드랍함 (RED))

TCP이면 받아서 응답을 줘야하는데, 타이머 안에 안 온 경우!! => 혼잡이라고 생각하자

 

ㆍTimer

4계층에서도 응답에 대한 타이머가 걸려있음

타이머 안에 도착을 안하면 네트워크 안에 혼잡이 생겼구나~ 라고 생각함

보낼거 많이 있어도, 계속 보내기만 하면 혼잡이 생길 게 분명함.

 

처음에  보낼 때는 이 네트워크가 바쁜지, 안 바쁜지 모름

그러니까 처음에 내가 보낼꺼 조심스럽게 찔끔 내보냄 → 응답오면 좀 더 많이 보냄 → ….

...이렇게 크기를 조금씩 늘려서 보냄

 

그런데 그러다가 타임아웃이 걸리면 어떻게 대처할지에 관한 두 알고리즘을 소개하겠음.

 

    ▶TCP Tahoe Algorithm

: 타임아웃시 다시 처음으로 떨어뜨려서 출발~…

 

예를들어

1 2 4 까진 보내졋는데, 8부터 안된다  → 그러면 다시 1 2 4까지(이전에 안된 양의 절반 정도) 보낸 후에

이다음부터는 찔끔씩 5 6 7 8..이렇게 증가하면서 보내는 것

 

 

    ▶TCP Reno Algorithm 개념 기억

: 타임아웃시 처음까지 안 빼고, 한번만 더 도전해보자 해서 쪼끔만 내려서 시도해보다가

걸리면 다시 처음으로 내려서 조심스럽게 보내는 것…

 

현재 주로 사용되는 알고리즘임!

 

※ Slow start말고, AIMD라는 것도 있슴 Slow start의 문제는, 네트워크가 많이 좋아졌는데도 처음부터 찔끔찔끔 보내서 시간이 많이 걸릴 수 있다는 것임 그래서 그냥 어느 정도 레벨에서 스타트해보자! 라는 개념

 

 

////근데, UDP는 이 짓을 하나?////

UDP는 ACK가 없어서, 지가 네트워크가 어떤지 판단할 수가 없음. 

그래서 똑같이 네트워크가 죽어나갈 때 TCP만 피해봄ㅠㅠ

(UDP 는 난몰랑~하고 걍 보냄. 그러다 보니까 공격하는 놈들은 UDP로 짬. 트래픽 냅다 보내는 그런 공격)

이건 공평하지않아!!!!!!

그래서 라우터에서 패킷 드랍할 때는, UDP 프로토콜 패킷들을 주로 드랍시킴

(3계층 헤더에 보면 프로토콜이 있는데, 거기에 TCP인지 UDP인지 담겨있음. 그거 보고 드랍함)