들어가기 앞서
해당 글은 널널한 개발자님의 인프런 강의 '외워서 끝내는 네트워크 핵심이론 - 기초'의 section4를 보고 공부한 내용을 정리한 글입니다.
TCP와 UDP
TCP와 UDP는 L4 계층을 대표하는 프로토콜. TCP가 가장 중요하지만 미래에 광범위하게 사용될 것으로 보이는 HTTP3의 경우 UDP를 사용하는 것으로 알려져 UDP가 미래에는 TCP만큼 주목 받을 것으로 보임. TCP는 UDP보다 무거우며, TCP는 연결지향, UDP는 연결을 지향하지 않음이 가장 두드러지는 차이점이다. UDP가 미래에 각광 받으리라 판단하는 이유는 전송되는 데이터의 크기와 수가 급수적으로 증가하기 때문.
TCP
TCP는 연결(Connection, Session)이라는 개념을 가짐.
TCP의 연결은 결과적으로 순서번호(sequence number)로 구현됨.
TCP의 연결은 '상태(전이)'의 개념을 동반.
UDP
UDP는 연결을 지향하지 않음.
TCP의 경우 연결 지향을 유지하기 위한 혼잡제어와 같은 메커니즘이 존재하지만, UDP는 존재하지 않음.
TCP는 배려남, UDP는 배려가 없는 나쁜 남자에 비유할 수 있다.
TCP 통신
TCP 통신은 Client와 Server라는 두 호스트로 설명할 수 있음. TCP 통신은 클라이언트로부터 시작되며, 연결지향인 TCP의 연결 종료 또한 클라이언트로부터 시작되는 것이 권장됨.
클라이언트
- 클라이언트 호스트의 프로세스(ex. 웹 브라우저 프로세스)가 TCP 통신을 위해 소켓을 생성(open)
- 프로세스의 소켓이 생성되면 클라이언트 호스트의 운영체제는 소켓에 TCP 포트 번호를 부여함 (랜덤으로 부여)
- stream 형태의 HTTP등의 애플리케이션 명세가 L4, L3로 내려가며 캡슐화 됨.
- stream -> (TCP의 경우) segment -> packet -> frame
- 포트번호, IP 주소, MAC 주소 등이 차례로 헤더에 바인딩
- L2 스위치 등을 통해 게이트웨이인 라우터를 만난 데이터는 인터넷을 통해 서버 호스트로 전송
서버
- 서버 호스트는 클라이언트의 요청 청취를 위해 소켓을 생성한 후 대기함(연결대기, listen)
- 서버 호스트의 소켓 포트는 클라이언트의 경우와는 다르게 운영체제에 의해 랜덤으로 부여되는 것이 아니라, 프로그래머 등에 의해 명시적으로 부여됨. (ex. 웹서비스 : 80)
- 서브넷 마스킹을 통해 서버 호스트의 로컬 네트워크로 들어온 클라이언트의 요청이 서버 호스트의 L3, L4 수준으로 올라가며 역캡슐화 됨.
- 서버의 소켓을 통해 클라이언트의 요청이 청취됨.
TCP 연결 과정 (3-ways handshaking)
3-ways handshaking은 TCP가 클라이언트와 서버의 연결을 수립하는 과정이며, 통신이 총 세번 왔다 갔다 한다고 해서 3 ways handshaking이라고 함.
통신에 사용되는 데이터는 TCP의 데이터 단위인 세그먼트이지만 헤더와 페이로드를 갖는 일반적인 세그먼트와는 달리 이 과정에서의 세그먼트는 페이로드 없이 IP 헤더와 TCP 헤더만 가진 상태로 전송됨.
3-ways handshaking을 통해 TCP 통신의 두 주체는 서로의 순서번호를 교환하고, MSS(Maximum segment size)와 같은 TCP 정책을 교환함.
통신이 한차례 주고 받아지는 과정이 RTT(Round Trip Time)이며 ping과 같은 프로그램은 이 RTT를 측정하는 프로그램.
- 서버로의 통신이 필요한 클라이언트는 무작위의 순서번호(sequence number)를 생성해 TCP 통신을 시작함
- 생성된 sequence number : 1000
- SYN(1000)
- 클라이언트의 SYN 요청을 받은 서버는 마찬가지로 무작위의 순서번호를 생성해 TCP 통신을 클라이언트로 전송
- 생성된 sequence number : 4000
- SYN(4000) + ACK(1001)
- 서버의 SYN, ACK 응답을 받은 클라이언트는 상태를 ESTABLISHED로 전환하고 서버로 응답 확인 메시지를 전송
- ACK(4001)
- 클라이언트의 ACK를 받은 서버는 상태를 ESTABLISHED로 전환하고 3 ways handshaking 종료
TCP 연결 종료 과정 (4-ways handshaking)
4-ways handshaking은 마찬가지로 클라이언트와 서버가 총 4번 통신을 주고 받는다는 의미이며, 연결을 종료하기 위해 각각 연결 종료 요청을 보내고, 연결 요청 확인을 보내는 쌍으로 이루어져 있음.
클라이언트가 연결 종료를 최초 요청을 할 수도, 서버가 최초 요청을 할 수도 있으나 일반적인 경우 클라이언트가 연결 종료를 요청하는 것이 권장되고, 서버가 먼저 요청을 보내는 경우는 비정상적인 경우로 간주.
서버가 먼저 연결 종료를 요청하지 않는 이유는 소켓의 회수와 관련이 있기 때문인데, 서버가 먼저 연결 종료를 시도하면 time wait이 발생하며 소켓의 낭비가 발생할 수 있다고 함.
- 클라이언트가 서버에 연결 종료 요청을 보냄
- FIN + ACK
- 클라이언트의 연결 종료 요청을 받은 서버는 연결 종료 확인 응답을 보냄
- ACK
- 서버가 클라이언트에 연결 종료 요청을 보냄
- FIN + ACK
- 클라이언트가 상태를 TIME_WAIT으로 전환하고 서버에 연결 종료 확인 응답을 보냄
- ACK
헤더 형식에 따른 TCP와 UDP의 차이점
TCP는 UDP에 비해 훨씬 무거운 헤더를 가지고 있음. 이는 TCP가 연결을 지향함을 부분적인 원인으로 두는데, TCP는 UDP가 헤더에 가지지 않는 혼잡제어, window size, 등의 정보 등을 추가적으로 들고 있음.
UDP의 경우 헤더에 출발지 포트, 도착지 포트, 본문의 길이, 체크섬만 들고 있어 TCP에 비해 가볍지만 네트워크 상에서의 데이터 전송 유실 등의 장애에 대한 어떤 보장도 하지 않음.
TCP 연결이라는 착각
TCP 연결은 클라이언트가 서버로 유선 광 케이블을 들고 가서, 실제로 네트워크를 연결하는 물리적인 연결이 아니라 '우리가 연결이 되었나 보군요' 하는 식의 논리적인 연결. 마치 양 무전기를 사이에 둔 두 사람이, 무전기를 들고 '잘 들리세요?' 하고 서로의 존재를 확인하는 형태에 가까움.
TCP 연결에서 가장 중요한 부분은 TCP의 연결이 실제로 연결이 이루어지는 물리적인 연결이 아니라, 서로의 통신으로 연결을 '확인'하는 약속에 가깝다는 부분. TCP 연결은 이러한 특징으로 인해 보안성이 없다고 하며 이 부분에 의한 해킹 사례도 있다고 함.
'네트워크' 카테고리의 다른 글
[외워서 끝내는 네트워크 핵심이론 - 응용] NAT 기반의 인터넷 공유기, 포트포워딩 (1) | 2023.04.15 |
---|---|
[외워서 끝내는 네트워크 핵심이론 - 응용] Inline, Out of Path, Proxy 구조 (0) | 2023.04.04 |
[외워서 끝내는 네트워크 핵심이론 - 기초] L3 수준에서 외울 것들 정리 (0) | 2023.03.23 |
[외워서 끝내는 네트워크 핵심이론 - 기초] L2 수준에서 외울 것들 정리 (0) | 2023.03.20 |
[외워서 끝내는 네트워크 핵심이론 - 기초] Internet 기반 네트워크 입문 정리 (0) | 2023.03.17 |