네트워크
TCP UDP
HBean_
2022. 3. 17. 18:07
Transport Layer
- End Point 간 신뢰성 있는 데이터 전송을 담당하는 계층
- 신뢰성 : 데이터를 순차적, 안정적으로 전달
- 전송: 포트 번호에 해당하는 프로세스에 데이터를 전달
TCP (Transmission Control Protocol)
- 신뢰성 있는 데이터 통신을 가능하게 해주는 프로토콜
- 특징: Connection 연결 (3-way-handshake) > 양방향 통신
- 데이터의 순차 전송을 보장
- Flow control (송수신자 사이의 데이터 처리 속도 차이 제어)
- Congestion Control (네트워크 상 문제로 데이터 전송에 문제를 제어)
- Error Detection (오류 감지)
- 전송 단위 : 세그먼트 Segment상위 계층에서 받은 데이터를 잘라서 tcp header를 붙임
- TCP Header
- SYN : tcp가 커넥션을 연결할 때, 사용하는 Flag 비트
- FIN : 커넥션 연결을 해제할 때 사용
- ACK : 수신자 다시 전송해줄 때 제어 Flag 비트
(TLS 1.2 기준)
TCP 3-way-handshake < Connection 연결 >
- SYN 비트를 1로 설정해 패킷 송신 → 연결 신청
- SYN, ACK 비트를 1로 설정해서 패킷 송신 → ACK : 패킷 받았다는 의미, SYN : TCP는 양방향 통신이므로 연결 신청
- ACK 비트를 1로 설정해 패킷 송신 →통로 연결하고 알았다는 신호
TCP 데이터 송수신
- Client가 패킷 송신
- Server에서 ACK 송신 → 잘 받았다는 의미
- ACK를 수신하지 못하면 재전송
TCP 4-way-handshake < Connection 끊음 >
- 데이터를 전부 송신한 Client가 FIN을 1로 설정해서 패킷 송신
- Server ACK=1 송신
- Server 쪽에서 Client에게 데이터를 다 보낼 때까지 대기하다가 서버에서 패킷을 다 보낸 후 FIN 송신
- Client가 ACK 보냄
- Server ACK 받으면 연결 해제
TCP 4-way-handshake 비정상 종료 상황
- CLOSE_WAIT 상태
- 애플리케이션에서 close()를 적절하게 처리해주지 못하는 상황
- TCP 포트는 CLOSE_WAIT 상태로 계속 기다림
- 이런 상태가 많아지면 더이상 연결 불가
- FIN_WAIT_1 상태
- 상대방에 커넥션 종료 요청을 했는데, ACK를 받지 못한 상태로 계속 기다림 → 아마 서버를 찾을 수 없는 상황으로 네트워크 및 방화벽의 문제일 가능성이 있음
- 일정 시간이 지나면 Time Out이 되면 자동으로 Closed 된다.
- FIN_WAIT_2 상태
- 종료 요청 후 ACK을 받았지만, 일정 대기 시간 후에도 FIN을 받지 못하고 기다리는 상태 → 이전에 통신을 했으므로 네트워크 문제보다는 서버가 close 처리를 못하고 있는 상황일 수 있다.
- 일정 시간이 지나면 Time Out이 되면 자동으로 Closed 된다.
TCP 문제점
- 신뢰성은 보장하지만, 매번 Connection 연결로 시간 손실
- 패킷을 조금만 손실해도 재전송
- 티가 안나는 손실일 경우 단점 → 그래서 나온 개념이 UDP
UDP User Datagram Protocal
- TCP보다 신뢰성이 떨어지지만 전송 속도가 일반적으로 빠른 프로토콜
- 순차 전송❌, 흐름 제어❌, 혼잡 제어❌
- Connectionless (3-way-handshake ❌) → 단방향 통신
- Error Detection
- 비교적 데이터의 신뢰성이 중요하지 않을 때 사용 ex. 영상 스트리밍(사진의 연속)
- 단위 : User Datagram
- TCP와 달리 데이터를 쪼개지 않음
- UDP Header는 TCP에 비해 단순
UDP 데이터 송수신
- 무조건 송신자 보내버림, 수신자는 UDP 소켓 항상 열어둠
💡 POINT⭐️ - TCP, UDP의 특성을 파악해서 상황에 따라 적절한 프로토콜을 사용
출처: