TCP/UDP

전송계층

IP에 의해 전달되는 패킷의 오류를 검사하고 재전송 요구 등의 제어를 담당하는 계층

 

프로토콜

프로토콜은 클라이언트와 서버가 정보를 교환할 수 있도록 하는 메세지 형식에 대한 규칙

수신 호스트가 전송 받은 메세지를 이해하려면 설계된 규칙에 따라 작성된 데이터 형식이어야 한다는 것

그렇기에 HTTP/IP/TCP/UDP는 모두 프로토콜이라고 보면 됨

 

[ TCP - 전송 제어 프로토콜 ]

IP(Internet Protocol)가 인터넷 프로토콜로서 복잡한 인터넷 망 속에서 클라이언트와 서버 간에 통신할 수 있게 IP 주소와 패킷과 같은 규칙을 통해 통신을 하게 하는 것이면 TCP(Transmission Control Protocol)는 IP 규칙으로만 통신하기에 부족하거나 불안정하던 여러 단점들(패킷 순서가 이상하거나 패킷이 유실)을 커버해 패킷 전송을 제어하여 신뢰성을 보증하는 프로토콜

IP 규칙에 써있는대로 목적지까지 다다랐으면 TCP 규칙에 써있는대로 올바르게 도착했는지 정확히 누구에게 전달되야하는지 하나하나 따지는 역할을 하는 것 단순히 목적지 뿐만 아니라 순서, 검증, 전송제어 정보가 들어있어 반드시 수신자가 정보를 받아야하는 신뢰성 있는 통신이 필요할때 사용됨

 

▶ 전송 데이터가 포장되는 과정

https://medium.com/@i01029407043/http-%EC%9B%B9-%EA%B8%B0%EB%B3%B8-%EC%A7%80%EC%8B%9D-1-37000d83705b

 

1. 전송데이터를 TCP 포장
2. 포장한 전송데이터를 IP 포장
3. 포장한 전송데이터를 이더넷 포장
4. 인터넷을 통해 상대 컴퓨터 서버에 도달하여 포장된걸 하나씩 풀며 전송데이터를 받게 됨
   
   

▶ TCP의 통신 확인

TCP는 신뢰성 프로토콜로 보내기 전 목적지가 괜찮은지 미리 확인하고 보낸 후에도 확인을 하는 프로토콜

통신을 시작할 때와 종료할 때 서로 준비가 되어있는지를 반드시 미리 먼저 물어보고 패킷을 전송할 순서를 정하고 나서야 본격적인 통신을 시작하기 때문. 이 과정을  3Way Handshake와 4 Way Handshake 과정이라고 함

통신을 시작할때 3Way를 통신을 마칠때 4Way을 함
즉, 한번 통신하는데 Handshake를 두번 해서 신뢰성을 보장

 

https://inpa.tistory.com/entry/NW-%F0%9F%8C%90-%EC%95%84%EC%A7%81%EB%8F%84-%EB%AA%A8%ED%98%B8%ED%95%9C-TCP-UDP-%EA%B0%9C%EB%85%90-%E2%9D%93-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90

 

클라이언트가 처음 서버와 통신을 하기 위해 TCP 연결을 생성할 때 SYN와 ACK이라는 패킷을 주고 받고 통신을 종료하는 과정에선 FIN이라는 패킷을 주고 받고 있음
즉, 패킷 내부에 들어있는 인증 플래그 값들을 확인하여 클라이언트와 서버가 서로 보낸 패킷의 순서와 패킷을 제대로 받았는 지를 검증하는 것

 

• 3-way handshake
  1. 클라이언트는 접속을 요청하는 SYN 패킷을 보냄
     이때 클라이언트는 응답을 기다리기위해 SYN_SENT 상태로 변함
  2. LISTEN 상태였던 서버는 SYN 요청을 받으면 클라이언트에게 요청을 수락하는 ACK 패킷과 SYN 패킷을 보냄 (서버도 클라이언트에 접속해야 양방향 통신이 되기 때문에)
     그리고 SYN_RCVD(SYN_RECEIVED)상태로 변하여 클라이언트가 ACK 패킷을 보낼 때 까지 기다리게 됨
  3. 클라이언트는 다시 서버에 ACK 패킷을 보내고 이후 ESTABLISHED 상태가 되어 데이터 통신이 가능하게 됨
• 데이터 통신 과정
  1. Established 된 상태에서 서버에게 데이터를 보냄
  2. 서버는 잘 전송받았다고 ACK 플래그를 넣어 응답
  3. 만약 클라이언트가 서버로부터 ACK를 못받았으면 제대로 송신하지 못한걸로 판단하고 데이터를 재전송
• 4-way handshake
  1. 서버와 클라이언트가 TCP 연결이 되어있는 상태에서 클라이언트가 접속을 끊기 위해 CLOSE() 함수를 호출
     그러면 FIN 플래그를 보내게 되고 클라이언트는 FIN_WAIT1 상태로 변함
  2. 서버는 클라이언트가 CLOSE() 한다는 것을 알게되고 CLOSE_WAIT 상태로 바꾼 후 ACK 플래그를 전송
     만일 서버에서 클라이언트로 보낼 남은 데이터가 있을 경우 이때 나머지를 모두 전송
  3. ACK를 받은 클라이언트는 FIN_WAIT2로 변환되고 이때 서버는 CLOSE() 함수를 호출하고 FIN 플래그를 클라이언트에게 보냄
  4. 서버도 연결을 닫았다는 신호를 클라이언트가 수신하면 ACK 플래그를 보낸 후 TIME_WAIT 상태로 전환됨
     이 후 모든것이 끝나면 CLOSED 상태로 변환

 

Flag 종류

Flag	설명
SYN	접속요청을 할 때 보내는 패킷 TCP 접속시에 가장먼저 보내는 패킷
ACK	상대방으로부터 패킷을 받은 뒤에 잘 받았다고 알려주는 패킷 다른 플래그와 같이 출력되는 경우도 있음
PSH	데이터를 즉시 목적지로 보내라는 의미
FIN	접속종료를 위한 플래그 이 패킷을 보내는 곳이 현재 접속하고 있는 곳과 접속을 끊고자 할 때 사용

 

▶ TCP의 전송 제어 기법

TCP는 원활한 통신을 위해 전송 흐름을 제어하는 기능을 프로토콜 자체에 포함하고 있음

 

흐름제어(Flow Control)

• 수신자가 처리할 수 있는 데이터 속도가 다르기 때문에 송신 측은 수신 측의 데이터 처리 속도를 파악하고 얼마나 빠르게 어느 정도의 데이터를 전송할 지 제어
• 슬라이딩 윈도우(Sliding Window) 방식을 사용
  
  • Window 라는 데이터를 담는 공간을 동적으로 조절하여 데이터량을 조절

오류 제어(Error Control)

https://inpa.tistory.com/entry/NW-%F0%9F%8C%90-%EC%95%84%EC%A7%81%EB%8F%84-%EB%AA%A8%ED%98%B8%ED%95%9C-TCP-UDP-%EA%B0%9C%EB%85%90-%E2%9D%93-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90

• 통신 도중에 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처
• Go Bank N 기법과 Selective Repeat(선택적인 재전송) 기법을 사용
  • Go Bank N 기법: 어느 데이터로부터 오류가 발생했는지 파악하여 그 부분만 다시 순서대로 보내 제어
  • Selective Repeat 기법: 에러난 데이터만 재전송하고 그전에 받았던 순서가 잘못된 데이터 버퍼를 재정렬하여 제어

혼잡 제어(Congestion Control)

• 네트워크가 불안정하여 데이터가 원활히 통신이 안되면 제어를 통해 재전송을 하게 되는데, 재전송 작업이 반복되면 네트워크가 붕괴될 수도 있음
  따라서 네트워크 혼잡 상태가 감지되면 송식 측의 전송 데이터 크기를 조절하여 전송량을 조절
• TCP에는 Tahoe, Reno, New Reno, Cubic, Elastic-TCP ..등 다양한 혼잡 제어 기법이 존재

 

[ UDP - 사용자 데이터그램 프로토콜 ]

TCP vs UDP

	TCP	UDP
연결방식	연결형 서비스	비연결형 서비스
패킷교환	가상 회선 방식	데이터그램 방식
전송 순서 보장	보장함	보장하지 않음
신뢰성	높음	낮음
전송 속도	느림	빠름

 

TCP는 신뢰성이 높고 느리다는 반면 UDP는 신뢰성이 낮고 빠름

 

신뢰성 있는 통신을 하도록 TCP는 핸드쉐이크 과정을 거치는 등에 데이터 하나를 전송하기 위한 밑작업이 많음

하지만 인터넷 기술이 발전하면서 전송해야하는 데이터의 크기가 점점 커져가며 동시에 빠른 통신이 필요해짐

HTTP 2.0에서는 한번 연결된 TCP 회선을 길게 유지하고 데이터도 스트림이라는 특수한 형태로 보내는 식으로 극복을 했지만 TCP 자체가 가지는 근본적인 특징 때문에 결과적으로 속도의 한계가 있었음

 

반면 UDP(User Datagram Protocol)는 데이터그램 방식을 사용하는 프로토콜이기 때문에 애초에 각각의 패킷 간의 순서가 존재하지 않은 독립적인 패킷을 사용함

데이터그램 방식은 패킷의 목적지만 정해져있다면 중간 경로는 어딜 타든 신경쓰지 않기 때문에 핸드쉐이크 과정 같은 연결 설정이 필요 없게 됨(잘받았는 응답 패킷 없이 무지성으로 보내기만 하는 것)

 

즉, UDP는 신뢰성을 확보하기 위해 거치던 TCP의 과정을 거치지 않기 때문에 속도가 더 빠를 수 밖에 없는 것

UDP는 실시간 영상 스트리밍과 같은 고용량 데이터를 다루는 곳에서 이용됨

또한 HTTP/3에서는 TCP를 버리고 UDP를 채택했음

 

UDP 커스터 마이징

TCP와 UDP의 큰 차이점은 속도와 신뢰성인데 UDP는 커스터마이징이 가능하기 때문에 UDP 자체는 헤더에 들은게 없어 신뢰성이 낮고 제어 기능도 없지만 개발자에 구현에 따라 변경 가능함

 

QUIU(Quick UDP Internet Connetions는 UDP를 기반으로 TCP + TLS + HTTP의 기능을 모두 구현하는 프로토콜

HTTP/3이 UDP를 채택했다는 것은 정확히 말하면 UDP 기반으로 만들어진 QUIC 프로토콜을 채택했다는 뜻

QUIC는 TCP를 사용하지 않기 땜문에 통신을 시작할때 3 Way Handshake 과정을 거치지 않아도 됨

 

클라이언트가 보낸 요청을 서버가 처리한 후 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이라고 하는데 TCP 연결을 생성하기 위해 기본적으로 1RTT가 필요하고 여기에 TLS를 사용한 암호화까지 한다고 하면 TLS의 자체 핸드쉐이크까지 더해져 총 3RTT가 필요함

 

반면 QUIU는 첫 연결 설정에 1RTT만 소요됨. TCP 핸드쉐이크 과정을 거치지 않으며 TLS 자체를 내포하고 있기 때문에 연결 설정에 필요한 정보와 함께 데이터도 보내버리기 때문. 또한 한 번 연결에 성공했다면 서버는 그 설정을 캐싱해놓고 있다가 다음 연결 때는 캐싱해놓은 설정을 사용하여 바로 연결을 성립시키기 때문에 0RTT만으로 바로 통신을 시작할 수 있음

 

이밖에도 패킷 손실 감지에 걸리는 시간 단축되었으며 클라이언트의 IP가 바뀌어도 연결이 유지되어 모바일에서 와이파이를 바꾸어도 끊김이 없어지게 되었음