TCP, UDP

[Network] TCP, UDP


Internet Protocol Suite

인터넷 상에서 컴퓨터들이 데이터를 주고받기 위해 사용하는 통신 규약의 모음을 일컫는 말
일반적으로 TCP/IP 를 많이 사용해서, TCP/IP Suite 라고도 부른다.


IP (Internet Protocol)

OSI layer 3 (Network Layer) 에서 동작하는 프로토콜 중 하나
출발지 컴퓨터에서 보낸 데이터를 도착지 컴퓨터 위치로 정확히 전송하는 역할을 맡는다.
비연결지향적이며, 패킷 도착 보장을 하지 않는다.
패킷 분할/병합을 지원하며, 이는 각 네트워크의 라우터가 맡아 수행한다.

  • 네트워크마다 적절한 패킷 크기가 다르기 때문에, 패킷 분할 및 병합은 각 네트워크의 Gateway(?)인 라우터가 맡아 처리한다.


TCP (Transmission Control Protocol)

OSI layer 4 (Transport Layer) 에서 동작하는 프로토콜 중 하나
패킷 전송 보장 및 흐름 제어, 혼잡 제어 등의 기능을 제공한다.

연결 과정 (3-way-handshake)

3-way-handshake
출처 : https://gyoogle.dev/blog/computer-science/network/TCP 3 way handshake & 4 way handshake.html

  • 클라이언트가 서버에게 SYN(x) 패킷을 보낸다.
  • 이를 수신한 서버는 ACK(x+1) 과 SYN(y) 메세지를 해당 클라이언트에게 보낸다.
  • 클라이언트는 서버가 보낸 ACK(x+1)을 통해 자신이 보냈던 연결 요청 패킷인 SYN(x)이 잘 도달했음을 알 수 있고, 서버가 데이터를 주고받을 준비가 되었음을 알 수 있다.
    서버의 SYN(y) 에 대한 응답인 ACK(y+1)을 서버에게 보낸다.
  • 서버는 ACK(y+1)을 수신한다. 이로써 서버는 클라이언트가 데이터를 주고받을 준비가 되었음을 알 수 있다.

종료 과정 (4-way-handshake)

4-way-handsake
출처 : https://sjlim5092.tistory.com/37

  • 클라이언트가 연결을 끊기 위해 서버에게 FIN 패킷을 보낸다.
    이 때, FIN 패킷에 Seq Number도 포함되어있다. Seq를 함께 보내는 이유는, “종료하긴 할건데, 현재 이 Seq 패킷까지 처리했으니 더 보낼 패킷이 있다면 보내고 종료해” 라는 의미를 담고있다.
  • 서버는 이를 수신하고, 응답으로 ACK 패킷을 보낸다.
    이 때 서버는 CLOSE_WAIT 상태가 되며, 애플리케이션 단에 클라이언트의 연결 종료 요청이 있었음을 알린다. 애플리케이션 단에서는 더 보낼 패킷이 있다면 마저 보낸다.
  • 애플리케이션 단에서 연결 해제 패킷 전송이 끝났다면, FIN 패킷을 보낸다.
  • 클라이언트는 서버의 FIN 패킷을 받고, ACK 패킷을 전송한 뒤 TIME_WAIT 상태에 진입한다.
    TIME_WAIT 상태로 전환하는 이유는, 만약 클라이언트가 보낸 ACK 패킷을 서버가 정상적으로 수신하지 못한 경우, 일정 시간 이후 서버는 다시 FIN 패킷을 보내올 것이다. 이 때 클라이언트가 TIME_WAIT 상태가 아닌 바로 CLOSED 상태가 됐다면 TCP 연결이 정상적으로 종료되지 못하는 상황이 발생할 수 있다.
  • 서버는 클라이언트의 ACK 패킷을 받고 CLOSED 상태가 된다.

예시로는 클라이언트가 연결을 먼저 끊는 상황을 들었지만, 서버가 먼저 FIN 패킷을 보낼 수도 있다.


UDP (User Datagram Protocol)

OSI layer 4 (Transport Layer) 에서 동작하는 프로토콜 중 하나
TCP와 다르게 비연결지향적이며, 패킷 전송을 보장하지 않는다.
UDP 패킷의 내용은 아래와 같다.

필    드 크    기
송신자의 포트 번호 16
수신자의 포트 번호 16
데이터의 길이 16
체크섬(Checksum) 16

포트 번호 정보와 데이터의 길이, 체크섬 정보만 존재한다.
즉, 패킷의 오류 검출 기능은 지원하지만, 그 외 TCP에서 지원하는 흐름 제어, 혼잡 제어 등의 기능은 지원하지 않는다.
보통 DNS Query나 게임, 실시간 동영상 플레이 같이 속도가 중요한 상황에서 쓰인다.


TCP & UDP 사용 시나리오 : 브라우저로 웹사이트 접속하기

  • 브라우저에 www.example.com을 입력한다.
  • 브라우저는 DNS에 www.example.com과 대응되는 ip주소를 UDP로 요청하고, 응답을 수신한다.
  • 브라우저는 웹사이트의 ip주소로 TCP 연결 요청을 보내고, 3-way-handshaking을 통해 브라우저와 웹사이트는 양방향 연결된다.
  • 브라우저는 연결된 TCP 세션을 통해 HTTP GET 요청을 보내고, 웹서버는 이를 수신하여 웹페이지의 HTML을 본문으로 하는 HTTP 응답을 브라우저에게 보낸다.
  • 이후 브라우저의 행동은 두 가지로 나뉜다.
    • 만약 브라우저가 HTTP 요청 시 Connection: keep-alive 헤더를 포함했고, 서버의 HTTP 응답에 Connection: keep-alive 헤더와 Keep-Alive: max=10; timeout=120; 과 같은 헤더가 있었다면 HTTP 연결은 끊어지지 않은 상태이다. 만약 수신한 HTML에 css, js와 같은 정적 파일 스크립트가 있었다면, 이들의 요청, 응답 또한 이전에 수립한 TCP 세션을 통해 전송, 수신된다.
    • 만약 브라우저가 HTTP 요청 시 Connection: keep-alive 헤더를 포함하지 않았거나 서버가 이를 지원하지 않을 경우, HTML 응답을 마지막으로 HTTP 연결 및 TCP 연결은 종료된다. 이 때 브라우저가 먼저 FIN 패킷을 보내면서 4-way-handshake를 통해 안전하게 TCP 연결이 종료된다.
0%