전송계층

정문·2022년 6월 12일
0

Network

목록 보기
9/12

Transport 계층

End to End 서비스, 커넥션을 관리
TCP & UDP, 소켓을 통한 프로세스별 통신

Port

전송 계층에서 사용되며 특정 프로세스를 구분하는 단위
웹 TCP 80, FTP TCP 21

TCP(Transmission Control Protocol)

전송 제어 프로토콜, 인터넷을 구성하는 핵심 프로토콜이다. 1:1통신임

TCP 헤더

  1. Source & Dest Port : 소스 포트와 목적지 포트
  2. Sequence Number : 순서 번호, 패킷 순서화와 중복 패킷 방지
  3. Acknowledgement Number : 승인번호, 수신측에서 수신 확인하고 다음 송신 데이터 요청
  4. HLEN : 20~60
  5. TCP 제어 플래그 : TCP 회선 및 제어관리
  6. Window Size : TCP 흐름 제어, 수신 버퍼의 여유 용량을 통보
  7. Checksum : 데이터 무결성 확인
  8. Urgent Pointer : 긴급 데이터를 알림
  9. Option & Padding : 옵션, MSS 조절이나 타임스탬프

TCP 제어 플래그

6가지로 구성되며 활성화 되는 값을 비트 "1"로 표현


1. URG : 긴급함을 알림, 긴급 데이터로 우선 순위를 높여 먼저 송신
2. ACK : 확인, 수신측에서 송신된 패킷을 정상적으로 받았음을 알림
3. PSH : 버퍼링 되지 않고 바로 송신
4. RST : 비정상 상황에서 연결을 끊음
5. SYN : 연결을 맺기 위해 보내는 패킷
6. FIN : 정상 종료, 송신측에서 수신측에 연결 종료 요청

UDP(User Datagram Protocol)

신뢰성은 낮으나 데이터 전송이 빠름.
송신측은 일반적으로 데이터를 보내고 확인 안함, 1:n 통신가능

UDP 헤더

  1. Source Port : 출발지 포트
  2. Dest Port : 목적지 포트
  3. Length : 전체 데이터길이(header + data)
  4. Checksum : 데이터 무결성 확인

TCP & UDP 비교

TCP 통신 과정

3 way handshake

TCP는 연결 지향 프로토콜로 두 호스트가 통신하기 전에 연결을 위한 관계를 수립함

4 way handshake

연결을 종료하기 위해 수행되는 절차

  • 즉, TCP는 초기 연결은 3 way handshake로, 정상적인 연결 종료는 4 way handshake를 사용한다고 보면됨

TCP 상태 전이도 - Client

  1. Closed 상태에서 클라이언트가 syn을 보내게 되면 Syn_Sent상태가 됨
  2. 서버한테 Syn + Ack을 받고 잘받았으니 서버한테 Ack을 보냄
  3. 여기까지가 3 way handshake 과정. Established가 됨(커넥션 연결이 되었다고 보면됨)
  4. 종료하기 위해 서버한테 Fin을 보냄 -> Fin_Wait_1 단계가 됨
  5. 서버는 알았다고 Ack을 보냄 -> Fin_Wait_2 단계가 됨
  6. 서버가 클라이언트가 종료해도 되는지 검토를 하고 Fin을 보냄
  7. Time_Wait가 되면서 상황이 종료가 되고 클라이언트는 종료하겠다고 서버한테 Ack을 보냄
  8. Closed 상태가 됨

TCP 상태 전이도 - Server

  1. Closed상태에서 대기상태(Listen)가 됨
  2. 클라이언트한테 Syn을 받으면 Syn_Rcvd상태가 됨
  3. Syn/Ack을 보내고 클라이언트 Ack을 받으면 3 way handshake 즉, 커넥션이 맺어짐
  4. 클라이언트한테 Fin을 받으면 정상적인 종료를 해도 될거같으면 Ack을 보냄
  5. Close_Wait 상태가 됨, 일정시간 후 Last_ACK 상태가 됨
  6. 다시 Fin을 보낸 후 클라이언트가 Ack을 보내면 서버도 Closed 상태가 됨

TCP 타이머 - Retransmisson

송신측이 패킷을 매번 전송할 때마다 타이머를 카운트함.
이것을 RTO(Retransmission Timeout)이라고 함.
RTO 내 ACK 응답이 오지 않으면 재전송하는데 RTO는 RTT(Round Trip Time)에 따라서 가변적으로 변함. RTT는 소스에서 목적지까지 패킷을 보내고 받는 시간을 의미

TCP 타이머 - Persistence

윈도우(데이터 전송을 위한 버퍼) 사이즈 관련 타이머

  • 수신측에서 용량 부족으로 윈도우 사이즈 없음을 보내고 다시 용량에 여유가 생기면 송신측에 요청
  • 중간에서 윈도우 사이즈 > 0을 보내는 ACK이 유실되면 서로 통신 간 문제 발생
  • 수신측 윈도우 사이즈 = 0 을 보낼 경우 Persistence 타이머 가동 - RTO
  • Persistence 타이머가 종료되면 Probe(ACK 재전송 요청)를 보내고 타이머 재가동
  • 다시 타이머가 종료되기 전에 ACK을 수신 못하면 시간을 2배로 늘리고 Probe 재전송
  • 타이머 임계치는 60초

TCP 타이머 - Time waited

TCP 연결 종료 후에 특정 시간만 연결을 유지

TCP 타이머 - Keepalive

TCP 연결 유지 타이머

  • TCP 연결을 맺고 수신측에서 2시간동안 송신하는 패킷이 없으면 수신측은 75초 단위로 Probe 전송
  • Probe 9개를 보내고 응답이 없으면 연결종료
  • Probe 9개 이전에 응답이 있으면 타이머는 재설정됨

흐름제어(Flow Control)

송신과 수신측의 데이터 처리속도 차이를 해결

  • Sliding Window 기법
  1. 버퍼 사이즈 중 Window = 4
  2. TCP Data 중 1을 프로세스에서 Read 처리
  3. Window Size = 5, 송신측에서 Size 확인 후 데이터 전송
  • 윈도우 사이즈 = 마지막 수신한 데이터 - 프로세스가 처리한 데이터

혼잡제어(Congestion Control)

수신측으로 유입되는 트래픽의 양이 정해진 대역폭을 넘어가지 않도록 제어

  1. AIMD(Additive Increase/Multiplicative Decrease)

    패킷 전송시 문제 없으면 Windows size 1씩 증가, 타임아웃 or loss시 패킷 속도 1/2 감소, 초기에 높은 대역폭 사용불가, 미리 혼잡 상태 감지 불가

  2. Slow Start

    패킷 전송시 문제 없으면 Windows size 2배씩 증가, 혼잡 상태 발생시 1로 변경,
    사전 혼잡 상태를 기록하고 Windows size 절반까지 2배씩 증가 후 1씩 증가

  3. Fast Retransmit - TCP Tahoe / Fast Recovery - TCP Reno

    수신측에서 먼저 와야하는 패킷이 오지않고 다음 패킷이 오게 되어도 송신측에 ACK을 보냄. 송신측은 타임아웃 시간을 기다리지 않고 중복된 순번의 패킷을 3개 받으면 재전송

  4. 개선된 Fast Retransmit / Fast Recovery

    TCP New Reno, SACK(TCP Tahoe + Selective Retransmit)

profile
공부 정리 블로그

0개의 댓글