[TCP/IP 쉽게, 더 쉽게] 03. 트랜스포트 계층
들어가기 전에
여러 컴퓨터로부터 받은 데이터들은 트랜스포트 계층에서 분류된 후에 애플리케이션 계층의 프로그램에 전달되는데, 이때 사용되는 분류 기준이 포트 번호다.
이번에는 데이터가 각 애플리케이션까지 전달되는 과정과 트랜스포트 계층의 동작 방식에 대해 알아보자.
TCP
TCP = Transmission Control Protocol
➡️웹/이메일과 같이 데이터가 정확하게 전달되어야 하는 통신에 사용
➡️전송의 신뢰성 중시
UDP
UDP = User Diagram Protocol
➡️VoIP/동영상 스트리밍과 같이 전송속도가 빨라야 하는 통신에 사용
➡️전송 속도 중시
03.01 트랜스포트 계층의 역할
트랜스포트 계층은 애플리케이션에 데이터를 전달한다
➡️트랜스포트 계층은 애플리케이션 계층과 인터넷 계층 사이에 위치
참고) 인터넷 계층의 역할이 데이터를 수신지 컴퓨터까지 전달(나중에!~~)
포트 번호로 애플리케이션을 구분한다
데이터의 정확한 전달을 중시하는 TCP
➡️트랜스포트 계층의 TCP 프로토콜은 수신지에 데이터가 정확하게 전달되도록 전송 속도를 조절하거나 도달하지 않은 데이터를 재전송
데이터의 전송 속도를 중시하는 UDP
➡️VoIP/동영상 스트리밍과 같이 실시간 통신이 필요하다면 전송 속도를 중시하는 UDP 사용
03.02 포트 번호
➡️데이터를 어떤 애플리케이션의 어느 프로토콜(TCP/UDP)로 전달할지에 대해서는 포트 번호를 보고 판단
포트 번호는 컴퓨터 내부의 수신지를 표현한다
➡️트랜스포트 계층에는 인터넷 계층에서 전달한 다양한 종류의 패킷이 들어옴
➡️이 패킷들은 애플리케이션 계층에 있는 애플리케이션들에게 각각 전달되어야 하는데, 이때 어느 애플리케이션으로 보내져야 할지는 포트 번호를 보면 알 수 있음!
포트 번호의 의미
➡️포트 번호는 0~65535번까지 사용할 수 있음
➡️웰 노운 포트, 레지스터드 포트, 다이나믹 포트 세 종류로 구분
➡️웰 노운 포트는 애플리케이션 계층에서 가장 많이 사용되는 대표적인 프로토콜의 수신 포트
주요 웰 노운 포트
➡️서버 측 사용 포트는 미리 정해져 있음!
클라이언트가 사용하는 포트 번호는 그때그때 다르다
➡️클라이언트가 사용하는 포트 번호는 다이나믹 포트 번호 대역에서 자동으로 할당되기 때문에 어떤 번호가 사용될지는 미리 알 수 없음!
클라이언트와 서버의 접속이 완료되기까지의 과정
➡️먼저 클라이언트가 사용할 포트를 결정하고 이후 서버의 포트에 접속하게 됨
➡️HTTP인 경우 서버 측에서 수신 대기하는 포트 번호는 80
➡️클라이언트인 웹 브라우저는 다이나믹 포트를 사용하기 때문에 포트 번호가 애당초 정해져 있지 않음
그럼 서버는 어떻게 상대방(클라이언트)을 식별할까?
➡️서버 측의 포트 번호는 고정되어 있기 때문에 여러 클라이언트가 서버와 통신하는 과정에서 같은 포트로 요청이 몰리게 됨
➡️서버는 수신 대기를 위해 같은 포트를 사용하는 반면, 접속을 요청한 클라이언트 측은 서로 다른 IP 어드레스와 포트 번호를 사용
➡️서버는 클라의 IP 어드레스와 포트 번호를 조합하여 클라이언트를 식별할 수 있기 때문에 여러 클라와 통신하는 상황에서도 혼선이 발생하지 않음!
03.03 TCP가 정확하게 데이터를 전달하는 방법
TCP는 데이터 전송에 신뢰성을 더하기 위해 데이터를 세그먼트라는 단위로 분할하여 전송 속도를 조정하고, 데이터가 제대로 전달되지 않았을 경우 재전송을 함
➡️즉, TCP에서는 분할된 데이터를 '세그먼트'라고 부름
TCP 헤더의 구조
➡️TCP의 세그먼트는 데이터 본체에 TCP 헤더가 붙은 형태로 구성
➡️TCP 헤더에는 포트 번호나 일련번호와 같은 정보가 포함
컨트롤 비트
➡️TCP 헤더 중 컨트롤 비트는 현재 통신 상태를 표현하는 플래그 역할
➡️통신 상대에게 이 정보를 전달해서 TCP 통신을 제어하는 용도로 사용
➡️9개의 플래그 각각은 1비트 크기를 차지하여 ON/OFF 두 가지 상태 표현
예를 들어, ECE 플래그가 ON인 경우 통신 경로가 혼잡하므로 통신 속도를 늦춰달라는 의미!!
통신 개시부터 통신 종료까지의 흐름
➡️TCP 통신은 커넥션 연결에서 시작
➡️3단계로 진행되기 때문에 3방향 핸드셰이크(3-way handshake)라고 함!
일련번호와 최대 세그먼트 크기를 사전에 조율
➡️커넥션을 맺을 때 송신 측과 수신 측은 원활한 통신을 위해 사전에 일련번호와 최대 세그먼트 크기(MMS, Maximum Segment Size)를 서로 합의/조율하는 과정을 거침
➡️클라/서버 서로 제시한 MSS 크기가 다를경우 작은 값을 따라감!
연속된 데이터를 몰아서 보내면 전송 속도가 빨라짐
➡️앞서 보낸 데이터에 대한 응답을 받은 후에 다음 데이터를 보내는 방식은 통신이 정상적으로 완료되기까지 꽤 많은 시간이 소요됨
➡️대신, 응답을 기다리지 않고 연속된 데이터를 몰아서 보내면 전송 속도를 더 빠르게 향상 가능
➡️연속으로 몰아서 보내면 확인 응답 번호를 확인하는데 시차가 발생한다. 동일한 확인 응답 번호가 들어오면 전송이 실패한 것으로 간주!
한번에 받을 수 있는 데이터 크기를 통보
➡️연속해서 보내는 데이터의 양이 너무 많으면 수신 측이 제때 처리 못함
➡️수신한 데이터를 일시적으로 보관할 수 있는 버퍼라는 저장 영역을 가지고 있음
➡️수신 측은 TCP 헤더의 윈도우 사이즈에서 버퍼의 크기를 설정하고 송신 측에 통보함으로써 어느 정도 크기까지 받아 낼 수 있는지를 알려줌
클라: 윈도우 사이즈는 4000이야~
서버: MSS가 1000바이트이기 때문에 4개까지는 몰아서 보낼게
흐름 제어 - 한 번에 받아 낼 수 있는 데이터 양을 조절
➡️수신 측은 도착한 패킷들을 버퍼에 쌓아 두는 것과 동시에 이미 버퍼에 쌓인 데이터를 순차적으로 꺼내서 처리
➡️이때 수신 측 성능이 낮다면 데이터가 들어오는 속도보다 처리 속도가 느려져 문제 야기
➡️수신 측은 응답을 보낼 때 윈도우 사이즈를 설정하여 어느 정도까지 수신할 수 있는지를 수시로 알려줌
버퍼가 가득 찬 경우는 어떻게?
➡️버퍼가 가득 차면 윈도우 사이즈가 0으로 설정되고 데이터 전송은 일단 멈춤
➡️전송 재개 시점을 알기 위해 송신 측은 탐색 패킷/윈도우 프로브라고 하는 패킷을 수신 측에 보내게 되고, 수신 측의 응답을 받아 현재 윈도우 사이즈를 확인 후 전송 재개 여부를 판단
03.04 UDP가 고속으로 데이터를 전달하는 방법
UDP는 다른 처리 없이 전송만 한다!
➡️버퍼에서 데이터가 넘치더라도 그냥 놔둠
UDP 헤더
브로드캐스트와 멀티캐스트
➡️TCP에는 없는 기능
➡️하나의 패킷을 여러 수신지에 전달하는 브로드캐스트와 멀티캐스트 기능
브로드캐스트 : 파일 공유(피어 투 피어, 즉 각각의 컴퓨터가 서로 서버가 되기도 클라가 되기도)
멀티캐스트: (나중에~!)
UDP를 애플리케이션 계층으로 둘러싼다
➡️실시간 처리가 필요한 온라인 게임에서는 전송 속도가 우선인 UDP를 사용하긴 하지만(스타?), 데이터 전송의 신뢰성 역시 속도에 못지않게 중요!
➡️애플리케이션 계층에서 흐름 제어나 혼잡 제어를 구현해서 부족한 신뢰성을 보완!
