TCP와 UDP
TCP, UDP 간단 초입 설명
- TCP에만 연결(Connection, Session) 개념이 있다
- 연결은 결과적으로 순서번호로 구현된다
- 순서번호는 1,2,3 순이 아닌, 1 → (만약 첫 패킷의 크기가 400이라면) 401 → …
- 연결은 ‘상태(전이)’ 개념을 동반한다
- TCP - 배려넘치는, UDP - 배려심없는
- TCP는 보통 Client - Server 구조
TCP Client - Server 통신
- 클라이언트 프로세스가 socket을 생성 후 open
- PID를 가진 프로세스가 소켓을 열면 운영체제가 TCP Port번호를 부여
- 부여된 번호로 Server TCP/IP 층을 지나 socket에 도착
- Server가 소켓에게 열어둔 포트(웹서버는 보통 80)로 받음(listen)
- 즉, TCP 통신을 ‘시도’하려면 상대의 IP주소와 해당 프로세스의 포트번호를 알고 있어야 함
- 만약 해당 포트가 없다면? TCP에서 없다고 응답
TCP 연결 과정 (3-way handshaking)
3-way handshaking
- Client가 랜덤하게 Sequence nember를 생성
- Client : Sent 상태
- Server : Listen 상태
- Server에서 잘 받았다는 의미로 (Sequence nember+1)로 응답(ACK)하면서
Server의 Sequence nember를 전송
- Client : Sent 상태
- Server : RCVD(요청을 받은) 상태
- Client가 잘 받았다는 의미로 서버의 (Sequence nember+1)로 응답(ACK)
- Client : Established 상태
- Server : Established 상태
- 둘은 RTT의 절반만큼 정도의 시간 차가 남
- 데이터 단위는 segment
- 연결 과정에서의 segment는 payload가 없음
- IP,TCP로만 구성
- Sequence nember 뿐만 아니라 정책도 교환
- 이 때 MSS(Maximum Segment size)를 서로 알려줌
→ 한 쪽의 MSS가 작다면 작은 쪽으로 하향
- RTT의 절반만큼 Established 시간 차가 남
TCP 연결 종료 과정 (4-way handshaking)
4-way handshaking
- Client가 FIN + ACK 전송
- Client : Established
- Server : Established
- Server에서 ACK 전송
- Client : FIN_WAIT1 (내가 보낸 FIN 요청의 ACK를 기다림)
- Server : Established → CLOSE_WAIT
- Client는 Server가 보내는 FIN+ACK를 기다림 (서버가 끝냈다는 응답을 보낼 때까지)
- Client : FIN_WAIT2 (Server가 보내는 FIN 요청의 ACK를 기다림) → TIME_WAIT
- Server : CLOSE_WAIT → LAST_ACK (마지막 ACK를 기다림)
- 이 때 FIN+ACK를 받은 Client는 TIME_WAIT 상태로 들어감
- TIME_WAIT 상태에 있는 쪽이 끊자고 요청할 한 입장
- 연결의 최종 종료 전의 상태
- Client가 ACK 전송
- Client : TIME_WAIT → CLOSED (일정 시간이 지나면 진행되고 소켓을 회수)
- 소켓도 유한한 자원 중 하나이므로 회수하면서 자원을 확보해야함
- Server : CLOSED
TCP Header
- header 길이 : 32bit
- Source, Destination pory : 16bit 씩 가짐 → 포트 번호는 2^16 개가 있다 (0 ~ 65535)
- Sequence num : 3-way handshaking에 사용
- ACK num : 3-way handshaking에 사용
- Data offset의 Flag값 (Reserved 옆) : ACK, SYN, FIN, PUSH 등.. 상태
- 앞의 3개는 혼잡 제어
- 대표적인 5개의 혼잡 상황
Loss, Re-Transmission, Dup-ACK, Out Of Order, Zero Window 등
- Window Size : buffer 여유 공간
UDP Header
- header 길이 : 32bit
- Source, Destination pory : 16bit 씩 가짐
→ 마찬가지로 포트 번호는 2^16 개가 있다 (0 ~ 65535)
- 보다시피 혼잡제어x, 길이 및 Checksum 정도만 함
- 사용 상황
- IPTV 영상 송출 서버에 연결된 수많은 클라이언트
→ 굳이 느린 사람에게 맞춰 보낼 필요 없이 빠르게 일단 보냄
- 게임 서버에서 TCP 통신을 하면 가장 느린 사람에게 맞춰 프로토콜을 짜게 됨
→ UDP로 짜서 전체보다는 일부 느린 유저에게만 불리한 상황을 적용
TCP 연결은 착각
파일을 다운로드 중 LAN 케이블을 분리했다가 다시 연결하면 TCP 연결은 어떻게 되는가?
- TCP 연결은 일정시간 유지된다.
- 랜선을 뽑은 시간에 관련있긴 하다. 중요한건 유지된다는 것
- 3-way-handshaking이 끝났지만 계속해서 연결을 재확인 (heart-beat)
- 재전송 타이머의 기본 근사 값은 대략 3초
- 재전송 타이머 만료 후에도 확인 응답을 받지 못한 경우
- segment를 재전송하고 RTO(Retransmission Time-Out) 값은 2배로 증가
- 1초 → 2초 → 4초 → 8초 → 16초 간격으로 재전송
- 보통 최대 5회 재전송을 시도하고 모두 실패시 전송 오류가 발생
연결은 사실 End-point의 주관적 판단에 불과