공대생 정리노트

4. 커넥션 관리 본문

HTTP 완벽 가이드

4. 커넥션 관리

woojinger 2021. 5. 15. 14:42

참고자료

HTTP 완벽 가이드


HTTP 트랜잭션 지연

HTTP 트랜잭션 처리 과정

트랜잭션 처리 시간은 TCP 커넥션 설정, 요청 전송, 응답메시지 전송에 비해 상당히 짧음

트랜잭션 지연 원인

  • 클라이언트는 URI에서 웹 서버의 IP 주소와 포트 번호를 알아내야 한다. DNS 인프라 사용해 URI 호스트 명을 IP 주소로 변환하는데 시간이 걸림(현재는 밀리초 단위)
  • TCP 커넥션 설정 시간이 소요된다(클라이언트가 TCP 커넥션 요청을 서버에게 보내고 서버가 커넥션 허가 응답 회신)
  • 요청시간, 응답시간

성능 관련 주요 요소

  • TCP 커넥션의 핸드 셰이크 설정
  • TCP의 slow start
  • 네이글 알고리즘(데이터를 모아 한 번에 전송하는 알고리즘)
  • 확인응답 지연 알고리즘
  • TIME_WAIT 지연과 포트 고갈

TCP 커넥션 핸드셰이크 지연

출처 : http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm

TCP의 ACK 패킷은 HTTP 요청 메시지 전체(IP 패킷은 인터넷상에서 수백 바이트이다)를 전달할 수 있을 만큼 큰 경우가 다.

이로 인해 크기가 작은 HTTP 트랜잭션은 50% 이상의 시간을 TCP를 구성하는 데 쓴다.

확인응답 지연

각 TCP 세그먼트는 순번과 데이터 무결성 체크섬을 가진다.

각 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 송신자에게 반환한다. 만약 송신자가 특정 시간안에 확인응답 메시지를 받지 못하면 데이터를 다시 전송

확인응답은 그 크기가 작아, TCP는 같은 방향으로 송출되는 데이터 패킷에 확인응답을 '편승(piggyback)'시킨다.

송출 데이터 패킷과 확인응답을 하나로 묶어 네트워크를 효율적으로 사용

이를 위해 확인응답 지연 알고리즘을 사용한다. 송출할 확인응답을 특정 시간(0.1s~0.2s)동안 버퍼에 저장해 두고, 편승시킬 패킷을 찾는다.

TCP slow start

TCP 커넥션은 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라서 속도 제한을 높여나간다. 인터넷의 급작스러운 부하와 혼잡 방지 위함.

slow start는 TCP가 한 번에 전송할 수 있는 패킷의 수를 제한한다. 확인 응답을 받으면 추가적으로 패킷을 더 보낼 수 있게 된다.

따라서 새로운 커넥션은 이미 어느 정도 데이터를 주고받은 커넥션보다 느리다.

네이글(Nagle) 알고리즘과 TCP_NODELAY

TCP 세그먼트는 40바이트 상당의 플래그와 헤더를 포함하여 전송하기 때문에, 작은 크기의 데이터를 포함한 많은 수의 패킷을 전송한다면 네트워크 성능은 크게 떨어진다.

네이글 알고리즘은 네트워크 효율을 위해서, 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩이로 합친다.

문제점

  • 크기가 작은 HTTP 메시지는 패킷을 채우지 못해 추가적인 데이터 기다리며 지연
  • 확인응답 지연과 함께 쓰일 경우 성능 매우 나쁨

TIME_WAIT의 누적과 포트 고갈

TCP 커넥션 종단에서 커넥션을 끊으면, 종단에는 커넥션의 IP 주소와 포트 번호를 메모리의 작은 제어영억(control block)에 기록해 놓는다. 이 정보는 같은 주소와 포트 번호를 사용하는 새로운 TCP 커넥션이 일정 시간 동안에 생성되지 않도록 하는 것. 2MSL(보통 2분) 정도 유지.

이전 커넥션과 관련된 패킷이 새로운 커넥션에 삽입되는 문제를 방지하기 위해서이다.

성능 테스트에서 많이 발생하는 문제이다.

TCP 커넥션을 맺기 위한 네 개의 값은 다음과 같다. <발신지 IP, 발신지 포트, 목적지 IP, 목적지 포트>

성능 테스트시 발신지 포트를 제외한 3개의 값은 고정이다.

이로 인해 연결 조합이 제한되어 TIME_WAIT으로 인해 순간순간 포트 재활용이 불가해진다.


HTTP 커넥션 성능 향상

  • 병렬 커넥션
  • 지속 커넥션
  • 파이프라인 커넥션
  • 다중(Multiplexed) 커넥션

병렬 커넥션

HTTP는 클라이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 한다.

각 커넥션의 지연 시간을 겹치게 하여 총 지연 시간을 줄일 수 있고, 클라이언트의 인터넷 대역폭을 한 개의 커넥션이 다 쓰는 것이 아니라 나머지 객체를 내려받는 데에 사용할 수 있다.

하지만 만약 클라이언트의 네트워크 대역폭이 좁다면, 성능상의 장점은 거의 없어진다.

또한 서버는 다수의 클라이언트가 다수의 커넥션을 사용하면 메모리 소모가 심하고 성능이 저하되기에 클라이언트에게 적은 수의 병렬 커넥션을 허용한다.

지속 커넥션

HTTP/1.1을 지원하는 기기는 처리가 완료된 이후에도 TCP 커넥션을 유지해 HTTP 요청에 재사용할 수 있다.

처리가 완료된 후에도 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라고 한다.

 

지속 커넥션 VS 병렬 커넥션

병렬 커넥션

  • 각 트랜잭션마다 새로운 커넥션을 맺고 끊어 시간과 대역폭 소모
  • 새로운 커넥션은 TCP slow start 때문에 성능 저하
  • 병렬 커넥션 수 제한 있다

지속 커넥션

  • 사전 작업과 지연 줄어든다
  • 튜닝된 커넥션(slow start 과정이 다 끝난) 커넥션 유지
  • 커넥션 수를 줄여준다

파이프라인 커넥션

파이프라인 커넥션

 

Comments