TCP 흐름, 혼잡 제어

흐름제어 

 

• 수신 버퍼의 오버플로우를 방지하기 위해 수신자의 Read속도와 송신자의 Send 속도를 일치시키는 작업
  • S&W ARQ 을 사용하면 별도 흐름제어 필요 없음
  • 파이프라이닝 기반의 Go-Back N, Selective Repeat ARQ는 흐름제어 필요
• 파이프라이닝이 연속적으로 세그먼트를 전송하지만, 무작정 무한한 데이터를 연속적으로 보낼 순 없다.

 

• 수신 버퍼
  • 수신된 세그먼트가 애플리케이션 프로세스에 의해 읽히기 전의 임시 저장 공간
• 버퍼 오버플로
  • 바이트 수신할 때 TCP는 데이터를 수신 버퍼에 저장
  • 해당 어플리케이션 프로세스는 버퍼에서 데이터를 읽지만, 수신 시점에 읽을 필요는 없음
  • 송신자가 데이터 전송을 진행하면서, 연결 수신 버퍼 오버플로 발생

 

슬라이딩 윈도우(silding window) : 버퍼

윈도우(window) - 송신 호스트가 파이프라이닝할 수 있는 최대량

즉, 윈도우의 크기만큼 확인 응답을 받지 않고도 한 번에 전송 가능하다는 의미

• 호스트들은 실제 데이터를 보내기 전에 3-Way Handshake 를 통해 연결 설정을 해줄 때 수신 호스트의 Receive Window 크기에 자신의 Send Window 크기를 맞춰 설정한다.

 

• GBN
  • 메세지 하나 보낼 때마다 윈도우 크기가 하나씩 감소하여 윈도우 크기가 0이 되면 대기한다.
    그 후, 수신자로부터 피드백(ACK)을 받을 때마다 윈도우 크기를 하나씩 늘리는 방식
    • 큐와 유사
• SR
  • 오류가 발생한 패킷만 재전송함으로써 불필요한 재전송을 피한다.
    순서가 틀리게 온 메시지는 버퍼에 저장한 다음, 올바른 순서의 패킷이 오면 버퍼에서 이전에 받았던 메시지들을 꺼내서 순서를 조합한다.
    • 큐 + 스택 활용 가능할 것 같음
• 두개의 차이 : packet 2 loss 상황에서,
  • (re)send ack1 : GBN 오류 단계로 회귀
  • send ack 3 : 일단 받아놓고 저장해놓고 나중에 처리 // 타임아웃 되면 알아서 보내줄거니까

---

 

혼잡제어(congestion control)

• 많은 트래픽으로 인해 피킷의 처리 속도가 늦어지거나 유실될 우려가 있는 네트워크 상황
  • ex : 송신량이 window 값 초과시 처리하지 못하는데 손실데이터로 간주하여 계속 재전송하는 상황
• 송신 측의 전송 속도를 적절히 조절하는 혼잡 제어 기법
  • 흐름제어 주체 : 수신 호스트 // 혼잡제어 주체 : 송신 호스트
• 혼잡 윈도우(congestion window) - 혼잡 없이 전송할 수 있을 법한 데이터양
  • 혼잡 윈도우의 크기는 송신 호스트가 어느 정도의 세그먼트를 전송해야 혼잡을 방지할 수 있는지를 직접 계산하여 알아내야 함
• 혼잡 제어 알고리즘
  • 대표 예시 
  • AIMD : Additive Increase / Multiplicative Decrease
  • 혼잡이 감지되지 않으면 : 혼잡 윈도우를 RTT 마다 1씩 선형적으로 증가
  • 혼잡이 감지되면 : 절반으로 떨어뜨림
    • 혼잡 윈도우는 톱니 모양으로 변화

• 수신 윈도우 - RWND(Receiver WiNDow) • 혼잡 윈도우 - CWND(Congestion WiNDow) • 느린 시작 임계치 - SSTHRESH(Slow Start THRESHold) • 이 값들은 일반적으로 운영체제에서 TCP의 상태를 관리하는 상태 변수의 형태로 존재

 

• 혼잡 회피 알고리즘
  • slow start의 지수적 증가와는 달리, 선형적 증가 추구
  • RTT마다 혼잡 윈도우를 1MSS(Maximum Segment Size)
    
    • 회피 중 타임아웃 발생 시 혼잡 윈도우 값은 1로, 느린 시작 임계치는 혼잡이 감지된 시점의 혼잡 윈도우 값의 절반으로 초기화한 뒤 다시 느린 시작을 수행
    • 혼잡 회피 도중 세 번의 중복 ACK 세그먼트가 발생되었을 때는 혼잡 윈도우 값과 느린 시작 임계치를 대략 절반으로 떨어뜨린 뒤 빠른 회복 알고리즘을 수행
    • 이때 타임아웃이 발생한 세그먼트나 세번의 중복 ACK 세그먼트가 발생한 세그먼트는 재전송

 

 

• 빠른 회복 알고리즘
  • 세 번의 중복 ACK 세그먼트를 수신했을 때 느린 시작은 건너뛰고 혼잡 회피를 수행하는 알고리즘
  • 단, 빠른 회복 도중이라도 타임아웃이 발생하면 혼잡 윈도우 크기는 1로, 느린 시작 임계치는 혼잡이 감지된 시점의 절반으로 떨어뜨린 후 다시 느린 시작을 수행

 

 

 

---

HTTP

요청-응답 기반 프로토콜

HTTP 는 '클라이언트 - 서버 구조 기반의 요청-응답 프로토콜'

• HTTP 요청 메세지 헤더와 응답 헤더 구별 가능

 

미디어 독립적 프로토콜

• (RFC9110)
  • 자원 - HTTP 요청 대상
  • HTTP 는 자원 특성 제한 X<- 상호작용할수 있는 인터페이스를 정의
  • 대부분 자원은 URL 로 식별
• 미디어 타입
  • HTTP에서 메세지로 주고받는 자원의 종류
    • MIME(Multipurpose Internet Mail Extension Type)
    • HTTP 는 데이터 타입에 제한두지 않고, 독립적으로 동작이 가능한 미디어 독립적인 프로토콜
    • 이메일과 함꼐 동봉할 파일을 텍스트 문자로 전환 -> 이메일 시스템 통해 전달 위한 개발
      • 현재는 주로 웹을 통해서 여러 형태의 파일을 전달하는데 쓰임
      • 웹 브라우저가 웹 서버로부터 받은 데이터 해석용
  • 슬래시 기준으로 하는 '타입/서브타입'형식 구성
    • type : 데이터의 유형
    • subtype : 주어진 타입에 대한 세부유형
  • 미디어 타입에는 부가적인 설명을위해 선택적 매개변수 포함될 수있음
    • /type/subtype/value = ?
• Stateless Protocol
  • 서버가 HTTP요청을 보낸 클라이언트와 관련된 상태를 기억하지 않음
  • 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주
    • 대부분 1 : n 상황인 서버와 클라이언트 : 서버 부담
    • n:n의 구성의 경우 상태 정보 공유 작업이 번거롭고 복잡
      • 특정 클라이언트가 특정 서버에 종속되는 상황 방지
  • 확장성-scalability 와 견고성-robustness
    • 1.0 버젼의 HTTP 헤더를 이용하면 프로토콜 쉽게 확장 가능.
      • 새로운 기능을 위한 새로운 헤더에 대해 클라이언트와 서버가 서로 합의가 이뤄진다면 도입할 수 있는 확장성
• 지속 연결 프로토콜
  • 비지속 연결 
    • 추가적 요청-응답을 위해 매번 TCP 연결 수립 필요
  • Persistent Connection or Keep-Alive
    • HTTP 1.1이상
    • 하나의 TCP 연결상에서 여러개의 요청-응답을 주고 받을 수 있는 기술
  • 버전별 HTTP 프로토콜
    • TCP : 1.1~2.0
    • UDP : 3.0 ~