전송 계층
전송 계층은 송신자와 수신자를 연결하는 통신 서비스를 지원한다
UDP
- 비연결형 프로토콜 이다.
- IP 데이터그램을 캡슐화하여 보내는 방법과 연결 설정을 하지 않고 보내는 방법을 제공한다.
- 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않음
- 이 모두가 사용자 프로세스의 몫
- 포트들을 사용하여 IP 프로토콜에 인터페이스를 제공함
- 코드가 간단할 뿐만 아니라 TCP 처럼 초기설정(initial setup)에서 요구되는 프로토콜보다 적은 메시지가 요구
- 대표적인 예시로 DNS
- 호스트 네임의 IP 주소를 찾을 필요가 있는 프로그램은, DNS 서버로 호스트 네임을 포함한 UDP 패킷을 보냄
- 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다.
- 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.
- 데이터그램 패킷 교환 방식 사용
- 패킷이 독립적으로 이동하며 최적의 경로를 선택
- 하나의 메시지에서 분할된 여러 패킷은 서로 다른 경로로 전송될 수 있으며, 이는 즉 패킷의 도착 순서가 다를 수도 있음을 의미
TCP
- 대부분의 인터넷 응용 분야들은 신뢰성 과 순차적인 전달 을 필요로 함.
- UDP 로는 이를 만족시킬 수 없으므로 다른 프로토콜이 필요하여 탄생한 것이
TCP이다. - 신뢰성이 없는 인터넷을 통해 종단간에 신뢰성 있는 바이트 스트림을 전송 하도록 특별히 설계됨
- TCP 서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 이루어짐
- TCP 에서 연결 설정은
3-way handshake를 통해 행해진다. - 모든 TCP 연결은 전이중(full-duplex), 점대점(point to point)방식
- 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미
- 점대점이란 각 연결이 정확히 2 개의 종단점을 가지고 있음을 의미
- TCP 는 멀티캐스팅이나 브로드캐스팅을 지원하지 않음
- 가상회선 패킷 교환 방식
- 관련된 패킷을 전부 같은 경로를 통해 전송하는 방법
- 가상 번호를 기반으로 가상 회선을 구성
- 패킷이 처음 출발한 순서대로 도착하기 때문에 오류 제어가 용이
3way Handshake
요약
- A -> B : 내 말 들려?
- B -> A : 잘 들려. 내 말은 들려?
- A -> B : 잘 들려!
연결하고자 하는 두 장치의 논리적 접속을 위해 사용하는 연결 확인 방식으로 3번의 확인 과정을 거친다고 해서 붙어진 이름
- SYN: 클라이언트의 ISN을 담아 SYN을 보냄
ISN은 TCP연결의 첫 번째 패킷에 할당된 임의의 시퀀스 번호- Connection을 맺을 때 사용하는 포트(Port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순처적인 Number가 전송된다면 이전의 Connection으로부터 오는 패킷으로 인식할 수 있다. 이런 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정한다.
- SYN + ACK: 서버는 클라이언트의 SYN을 수신하고 서버의 ISN을 보내며 승인 번호로 클라이언트의 ISN + 1을 보낸다
- ACK: 클라이언트는 서버의 ISN + 1한 값인 승인 번호를 담아 ACK를 서버에 보냄
이러한 과정때문에 TCP는 신뢰성이 있는 계층이라 하며, UDP는 이 과정이 없기에 신뢰성이 없는 계층
4way Handshake
요약
- A -> B: 나는 다 보냈어. 이제 끊자!
- B -> A: 알겠어! 잠시만~
- B -> A: 나도 끊을게!
- A -> B: 알겠어!
3way handshake와 반대로 가상 회선 연결을 해제하기 위한 확인 작업
- 클라이언트는 서버에 연결을 해제하겠다는 FIN 패킷을 보냄 그 후 FIN_WAIT_1 상태로 들어가 서버의 응답을 기다린다
- FIN_WAIT_1 : 자신이 보낸 FIN에 대한 ACK을 기다리거나, 상대방의 FIN을 기다리는 상태
- 서버는 클라이언트로 ACK 패킷을 보냄 그리고 CLOSE_WAIT 상태에 들어감. 클라이언트는 ACK 패킷을 받으면 FIN_WAIT_2 상태에 들어감
- CLOSE_WAIT : 상대방의 FIN을 받은 상태. 상대방 FIN에 대한 ACK를 보내고 애플리케이션에 종료를 알리는 상태
- FIN_WAIT_2 : 자신이 보낸 FIN에 대한 ACK를 받았고 상대방의 FIN을 기다리는 상태
- 서버는 ACK 패킷을 보내고 일정 시간 이후에 클라이언트에 FIN 패킷을 보냄
- 클라이언트는 TIME_WAIT 상태가 되고 다시 서버로 ACK 패킷을 보내서 서버는 CLOSE 상태가 됨 이후 클라이언트는 어느 정도 시간을 대기한 후 연결이 닫히고 모든 자원의 연결이 해제됨
- TIME_WAIT : 모든 FIN에 대한 ACK를 받고 연결 종료가 완료된 상태. 새 연결과 겹치지 않도록 일정 시간 동안 기다린 후 CLOSED 상태로 전이함
- CLOSED : 연결을 시작하기 전 기본 상태, 연결이 없는 상태
TIME_WAIT을 하는 이유?
- 지연 패킷이 발생할 경우를 대비하기 위함
- ex) Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황
- 두 장치 연결이 닫혔는지 확인하기 위함
- ex) LAST_ACK 상태에서 닫히게 되면 새로운 연결을 할 때 LAST_ACK으로 되어있어서 접속 오류가 나타나게 될 수 있음
- LAST_ACK : CLOSE-WAIT 상태를 처리 후 자신의 FIN요청을 보낸 후 FIN에 대한 ACK를 기다리는 상태
예상질문
- TCP와 UDP의 차이에 대해 설명해주세요
- HTTP가 TCP를 사용하는 이유에 대해 설명해주세요
- 3way handshake에 대해 설명해주세요
- 2way handshake를 하지 않는 이유에 대해 설명해주세요
- 4way handshake에 대해 설명해주세요
- 4way handshake에서 종료 후 TIME_WAIT 상태로 대기하는 이유에 대해 설명해주세요
출처
hello dev!!